phil@amdcad.UUCP (Phil Ngai) (01/06/87)
This is a flame, but after two months or so of having my mail bounce
every week because of smail I can't help myself. Things used to work,
maybe not in the fancy domain way, but AT LEAST THEY WORKED. Now I
have no idea if anything will work. And I can't do loopbacks to test
uucp links.
I hate smail. I don't think too highly of the people that unleashed it
on us either. This system works worse than PC-DOS. I hate it. Maybe
the authors are trying to teach me I get what I pay for. Unreliable
software.
I hate smail.
--
Butter and salt can make almost anything taste good.
Phil Ngai +1 408 749 5720
UUCP: {ucbvax,decwrl,hplabs,allegra}!amdcad!phil
ARPA: amdcad!phil@decwrl.dec.comcampbell@maynard.BSW.COM (Larry Campbell) (01/06/87)
In article <14227@amdcad.UUCP> phil@amdcad.UUCP (Phil Ngai) writes: > >I hate smail. Well, I've been using smail for two months now and I think it works very well. Perhaps there really are problems with it, but you sure can't tell from Phil's flame. Phil, it would help everyone if you could be more specific about the problems you've encountered. A flame may make you feel better, but does no one else any good at all. -- Larry Campbell The Boston Software Works, Inc. Internet: campbell@maynard.uucp 120 Fulton Street, Boston MA 02109 uucp: {alliant,wjh12}!maynard!campbell +1 617 367 6846 ARPA: campbell%maynard.uucp@harvisr.harvard.edu MCI: LCAMPBELL
joe@auspyr.UUCP (Joe Angelo) (01/07/87)
Well, I too am beginning to dislike smail ... but not becuase my mail get
bounced around ... but because (because, because, of the wonderful things...)
it doesn't even come near considering geographic area ... Eg: location!!
This, ofcourse, could be mostly the fault of pathaliases ... but I won't
point any fingers ( ^^ )
Quite often I have large pieces of mail shipped all over the country.
From Boston to Miami to Denver to Canada [back] to Miami then to San Jose.
Even though I specify a direct path (quick and fast), all it takes is
one smail site to reroute the message BACK across the country ... and two
weeks later my 99K mail gets to me.
Oh well. Smail is atleast great for domains ... but geographical domains
would also be nice (providing geographical domains are used to reach
the target geographical domain ... eg: mail to joe.ca from site.maine doesn't
need to be routed to site.europe ... you get the idea )
But I'm crazy anyways...
--
"No matter Joe Angelo, Sr. Sys. Engineer @ Austec, Inc., San Jose, CA.
where you go, ARPA: aussjo!joe@lll-tis-b.arpa PHONE: [408] 279-5533
there you UUCP: {sdencore,necntc,cbosgd,amdahl,ptsfa,dana}!aussjo!joe
are ..." UUCP: {styx,ucbvax!imagen,dlb,gould}!auspyr!joechuq%plaid@Sun.COM (Chuq Von Rospach) (01/07/87)
In article <799@maynard.BSW.COM> campbell@maynard.UUCP (Larry Campbell) writes: >In article <14227@amdcad.UUCP> phil@amdcad.UUCP (Phil Ngai) writes: >> >>I hate smail. > >Well, I've been using smail for two months now and I think it works >very well. The problems with smail are caused to the people who DON'T use smail. I'm sure smail works just wonderfully on all the sites where it has been installed and is maintained, but I see a LOT of return addresses that simply don't work anymore. There has always been a problem with bogus return addresses, but the incidence is way up in the last few months, primarily because smail sites love to send out return addresses like "mark@cbosgd.att.com" -- which is great if you have smail around to figure out where that is, but not so great if you don't -- and your sendmail system sends the message off to ARPAland looking for the machine. Which, I guess, brings forward the biggest hassle with domaining -- it assumes that everyone is doing domains, which isn't true, and likely will never be true. [Don't take this as a anti-domain argument. I could yell just as much about direct routing, and one of these days I might. The reality is there just isn't a good, compatible, reasonable mailing system, so I'm not taking sides -- both reality and domains have advantages and disadvantages. Take your choice] chuq Chuq Von Rospach chuq@sun.COM It's only a model...
tron@nsc.NSC.COM (Ronald S. Karr) (01/07/87)
In article <32@auspyr.UUCP> joe@auspyr.UUCP (Joe Angelo) writes: >it doesn't even come near considering geographic area ... Eg: location!! >This, ofcourse, could be mostly the fault of pathaliases ... but I won't >point any fingers ( ^^ ) >... >Even though I specify a direct path (quick and fast), all it takes is >one smail site to reroute the message BACK across the country ... and two >weeks later my 99K mail gets to me. The greatest problem here is not that pathalias doesn't take into account geographic areas, or that geographic domains do not exist. The problem is a lack of standardization on what costs should be used for map entries, and is also a function of the number of system administrators who just put DEMAND and DIRECT costs on lines that probably shouldn't be used for high amounts of traffic. I believe that a somewhat standard system of cost figuring that took into account poll rate, line cost, line capacity, system reliability and size, and (possibly) distance, would, if adopted by enough system administrators, yield a much more reliable path database. For example, a small widget box in the midwest which happens to poll on demand to a system on the west coast and a system on the east coast should take into account that it doesn't have leased lines or the necessary system size and performance to handle all traffic between coasts and state costs other than DEMAND, and probably much higher. Another parallel possibility here is to give a cost to a host that indicates a _through_ cost, which would raise the cost for routing _through_ a site as opposed to routing _to_ a site. Pathalias would need to be modified for this to work, but perhaps the best way to reach this midwestern machine from either cost is through those demand lines, while sites wouldn't generally want to route through this site. In this case, a low cost could be given for the lines, while a high cost is given for routing through the site. -- tron |-<=>-| ARPAnet: nsc!tron@sun.COM tron@sc.nsc.com UUCPnet: {amdahl,decwrl,hplabs,pyramid,sun}!nsc!tron
jbuck@epimass.UUCP (Joe Buck) (01/07/87)
In article <32@auspyr.UUCP> joe@auspyr.UUCP (Joe Angelo) writes: > >Well, I too am beginning to dislike smail ... but not becuase my mail get >bounced around ... but because (because, because, of the wonderful things...) >it doesn't even come near considering geographic area ... Eg: location!! >This, ofcourse, could be mostly the fault of pathaliases ... but I won't >point any fingers ( ^^ ) What makes you think that geographic distance has much to do with time or cost? It costs me less to call my parents in Washington, DC than my friends in LA (from San Jose). There are relatively few good north-south UUCP connections in California; there are many more east-west connections. Internet connections are just about instantaneous, and many companies have leased lines. There's no reason to consider geography if the pathalias data reflects true costs (unfortunately, it doesn't). I am bothered by mailers that rewrite bang-form paths. It makes it impossible to avoid ihnp4, for example. But no one should be surprised when pathalias generates 6000-mile paths in the US; that's exactly what it should do. -- - Joe Buck {hplabs,ihnp4,sun}!oliveb!epimass!jbuck HASA (A,S) Entropic Processing, Inc., Cupertino, California
gmp@rayssd.UUCP (01/08/87)
In article <14227@amdcad.UUCP> phil@amdcad.UUCP (Phil Ngai) writes: > I hate smail. I don't think too highly of the people that unleashed it > on us either. This system works worse than PC-DOS. I hate it. Maybe > the authors are trying to teach me I get what I pay for. Unreliable > software. Hmm. That seems quite odd. We've been using smail here, and I've been more than happy with it. About the only real problem there might be with it isn't really a problem with smail, and that is that smail interprets From: addresses properly, whilst many sites do the improper thing by prepending their hostname onto the From: address, the result being an improper address. This makes replies a somewhat iffy proposition, though that was true before smail came along. I believe that the UUCP-Project is still working on improving smail, so if you have some specific suggestions, why don't you spell them out? -- Greg Paris ....................... gmp@rayssd.RAY.COM {cbosgd,gatech,ihnp4,linus,mirror,uiucdcs}!rayssd!gmp ... Everything seems to be up in the air at this time ................ I need something to change your mind
phil@amdcad.UUCP (Phil Ngai) (01/08/87)
People keep asking me "what do you not like about smail?" I already said what I don't like: my mail bounces all the time now that we run smail. Before we ran smail, my mail went through with maybe 5% as many problems. Then people start asking me what particularly is going wrong. I don't know and I don't want to know. Why should I have to know all this stuff? My mail used to work great, and I didn't have to know anything then. It seems that the problems are all of different natures anyway. The one that I do sort of understand has to do with getting mail from ARPAnet sites. I thought this domain stuff worked. Not until after it is installed that I find out amdcad.amd.com makes sites like lll-crg puke. Not until after we invest a lot of time in this do we find out that the use of domains by uucp sites appears to be a disputed issue in the ARPA world. Well, eventually sun agreed to perform some vital service the nature of which I don't quite understand which allows me to receive mail from ARPA sites again. But I feel quite deceived that smail appeared to be passed off as something easy to use when important nodes such as decwrl and lll-crg don't even want to talk to amdcad.amd.com. I get the sense that smail was released to get innocent sites like mine to run it and put pressure on the sites which don't hold the same philosophy as the smail project to accept their notion of the world. I don't appreciate being used that way. But most of all I don't like my mail bouncing all over the place. Anyway, even sun apparently can only handle a limited number of sites. We were lucky enough to be accepted. What about the sites after us? ARPA mail used to work just fine. Now we have a system where only the lucky few with connections at Internet sites can get mail. Some people are going to be unhappy about this. In article <32@auspyr.UUCP> joe@auspyr.UUCP (Joe Angelo) writes: > >Well, I too am beginning to dislike smail ... but not becuase my mail get >bounced around ... but because (because, because, of the wonderful things...) >it doesn't even come near considering geographic area ... Eg: location!! >This, ofcourse, could be mostly the fault of pathaliases ... but I won't >point any fingers ( ^^ ) In this situation I don't quite blame smail. It looks like the map data is causing the problems. But there are two points here. One is that the map data is unreliable. As long as we rely on system admins who are usually saddled with more work than they can really handle to provide the map data, there will be bad or out of date paths. If something like Erik Fair's uucp logfile analyzer were coupled with software which automatically sent updates to the map data repository, then there would be some hope. The problem with mail crossing the country to get next door is of course due to the map data. It is not even necessarily incorrect. It could be faster to cross the country and delay is what pathaliases optimizes for. If it isn't faster, then the map data is wrong. The other problem is when rerouting is forced on users. Then bad data in the map knocks you out. Back when I was routing manually with the aid of uupath, I could do things like say "ah, it wants to go through ihnp4 but we know better" and avoid bad sites. Now it does whatever it pleases. What I liked to do a lot of was to take an address like fred@site.dec.com and ship it off to decwrl to handle with decwrl!fred@site.dec.com. Now smail says "ah, @ takes precendence". How am I supposed to dump addresses on a smarter site like decwrl now? No doubt this article reveals a profound ignorance on the operation of smail. I don't want to learn it. I didn't have to learn all this stuff before and my mail worked. I am not especially lazy or unknowledgable about computers and this is how I feel about smail. How do you suppose all the other users feel about this mail situation? -- Butter and salt can make almost anything taste good. Phil Ngai +1 408 749 5720 UUCP: {ucbvax,decwrl,hplabs,allegra}!amdcad!phil ARPA: amdcad!phil@decwrl.dec.com
tron@nsc.NSC.COM (Ronald S. Karr) (01/08/87)
In article <14237@amdcad.UUCP> phil@amdcad.UUCP (Phil Ngai) writes: >What I liked to do a lot of was to take an address like >fred@site.dec.com and ship it off to decwrl to handle with >decwrl!fred@site.dec.com. Now smail says "ah, @ takes precendence". >How am I supposed to dump addresses on a smarter site like decwrl now? Decwrl seems to do this just fine if you use an address like: decwrl!site.dec.com!fred So you know. -- tron |-<=>-| ARPAnet: nsc!tron@sun.COM tron@sc.nsc.com UUCPnet: {amdahl,decwrl,hplabs,pyramid,sun}!nsc!tron
simon@einode.UUCP (Simon Kenyon) (01/08/87)
to be specific about smail 1. the supplied sendmail.cf is really rather bogus. not saying i can do much better, but i try. 2. smail seems to be putting strange from lines (>From i mean) a site next to me used to run smail. i got mail from them thus: user%tcdmath@tcdmath.UUCP somebody explain this to me. using smail just to route uucp mail seems like an interesting thing to do. i'm going to try that; and remove all my domain routing crap out of my sendmail.cf -- Simon Kenyon EUnet: simon@einode.UUCP Smail: The National Software Centre, Dublin, IRELAND Phone: +353-1-716255
scott@utcs.UUCP (01/08/87)
In article <14237@amdcad.UUCP> phil@amdcad.UUCP (Phil Ngai) writes: >The other problem is when rerouting is forced on users. Then bad data >in the map knocks you out. Back when I was routing manually with the >aid of uupath, I could do things like say "ah, it wants to go through >ihnp4 but we know better" and avoid bad sites. Now it does whatever it >pleases. I think a mailer should be able to find sites using whatever information it has but more importantly it should be able to let me do it manually. All this domainizing is great but if I want to send it my own way I should be able to bypass the internal routing tables. Intermediate machines in the path should look at the mail and say "Hmm.. he routed this himself I better leave it alone." If I route it incorrectly, instead if rerouting it when it comes to a dead end, it should bounce so that I know that the path I chose was bad and I can find a new one. >What I liked to do a lot of was to take an address like >fred@site.dec.com and ship it off to decwrl to handle with >decwrl!fred@site.dec.com. Now smail says "ah, @ takes precendence". >How am I supposed to dump addresses on a smarter site like decwrl now? Try fred%site.dec.com@decwrl >No doubt this article reveals a profound ignorance on the operation of >smail. I don't want to learn it. I didn't have to learn all this stuff >before and my mail worked. I am not especially lazy or unknowledgable >about computers and this is how I feel about smail. How do you suppose >all the other users feel about this mail situation? The front end mail system should make routing completely invisible to those who want it that way so they can say fred@site.dec.com and assume it will get there (within the limits of your site knowing where site x is) but if joe smart-user wants to be able to explicitly do his routing that should be possible to (but not nessessary). Personally, I still like to route my mail myself because it seems that even short routes are changing daily. Well, it looks like my soap box has a crack in it so I'll step down now :-) scott -- "I feel fine..." ...{utzoo, decvax, ihnp4, cbosgd, utcsri, mnetor}!utcs!scott scott%utcs.toronto.edu@csnet-relay.arpa scott@utoronto.bitnet scott@utcs.utoronto.bitnet Disclaimer: The above is not actually the opinion of anyone at all but especially not the administration or staff of this institution.
lyndon@ncc.UUCP (01/09/87)
> > I believe that the UUCP-Project is still working on improving smail, > so if you have some specific suggestions, why don't you spell them out? > > -- > Greg Paris ....................... gmp@rayssd.RAY.COM > {cbosgd,gatech,ihnp4,linus,mirror,uiucdcs}!rayssd!gmp OK - here's one: It would be nice if smail could handle aliases. I find smail to be a very nice package - it gives us no trouble at all. I did try running uumail for a while, specifically to get the aliasing feature, but quickly switched back to smail (we had a number of problems that I won't go in to. Most were configuration problems that will vanish when I can spend some time with the software). There has been a problem with sites completely rewriting the bang path. Our philosophy is to route anything that shows up on ncc in the form "domain!user", "uucp_host!user", or "user@domain". This allows us to control access to directly connected sites if there are problems (well, sometimes :-), and allows us to route for downstream sites. It *also* allows a downstream user to pick an explicit path to a site if s/he so chooses. Recently we added another rule to the above: If a piece of mail arrives destined for "b!c!d" where "b" is not a machine we know about, smail attempts to prepend the necessary path to "b". This seems to help quite a bit when a downstream site tries to reply to a message with a munged up bang path in the From: line. -- Lyndon Nerenberg - Nexus Computing Corp. - lyndon@ncc.UUCP UUCP: {ihnp4,ubc-vision,vax135,watmath}!alberta!ncc!lyndon
chris@mimsy.UUCP (Chris Torek) (01/09/87)
>In article <32@auspyr.UUCP> joe@auspyr.UUCP (Joe Angelo) writes: >>Even though I specify a direct path (quick and fast), all it takes is >>one smail site to reroute the message BACK across the country ... and two >>weeks later my 99K mail gets to me. In article <4070@nsc.NSC.COM> tron@nsc.NSC.COM (Ronald S. Karr) writes: >The greatest problem here is ... a lack of standardization on what >costs should be used for map entries.... This is indeed probably the greatest problem. One thing that I have not seen mentioned, though, is that in some cases bouncing across the country several times may in fact be the fastest and cheapest route. Some companies have dedicated, high-speed links between (say) California and New York offices. Going from Palo Alto to Rochester to NYC to L.A. may be faster and less expensive than going from Palo Alto directly to L.A. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) UUCP: seismo!mimsy!chris ARPA/CSNet: chris@mimsy.umd.edu
jc@cdx39.UUCP (John Chambers) (01/09/87)
> > > I hate smail. > > I've been using smail for two months now and I think it works very well. > The problems with smail are caused to the people who DON'T use smail. All true, and all somewhat missing the point. If there were just one mailer in the universe, and we were all forced to use it, we'd likely be better off (unless it came from IBM, in which case only giants could affort to use it :-). The problems don't arise from any one mailer being bad, but rather from a multitude of incompatible mailers. What we need is not Yet Another Funny Mailer. Regardless of how marvelous one is, it just adds to the confusion. There's no way at present to impose a single standard mailer on the world, and even if there were, it is probably too early; if someone decreed that we must adopt the new foomail system, we'd be stuck forever with the moral equivalent of Fortran. What is needed is more the sort of thing that sendmail attempted to do: find a way to interface to all the existing mailers, in such a way that it is (1) reasonably easy to install (not true of sendmail); (2) reasonably easy to augment with an assortment of user interfaces; and (3) reasonably easy to invert mail paths automatically. Whether such is even possible, I don't know (though I'd like to find a way to work on it). > [Don't take this as a anti-domain argument. I could yell just as > much about direct routing, and one of these days I might. It seems to me that both are inherently desirable. General-purpose mail messaging can benifit greatly from a domain-based approach. On the other hand, if I need to get a megabyte of code from here to our site in Phoenix, and we have a direct link, I sure don't want some mailer to decide that, since the modem is busy at the moment, it will "help" me by mailing it indirectly via moskvax (which, unbeknownst to me, has email links to both of the sites). I mean, some of that code is company confidential, f'Gawd's sake. The mailer had damn well better send it along the path I specified. If it doesn't, I'm gonna go and shoot it down. One of the nice things about the good ol' uucp mailer is that I can give it a totally dumb mail path, and it will do it exactly what I tell it to do, without trying to outsmart me. I've grown to really appreciate that, after having got mail bounced back by "smart" mailers that find a "better" path that happens not to work for some reason. Sigh. -- John M Chambers Phone: 617/364-2000x7304 Email: ...{adelie,bu-cs,harvax,inmet,mcsbos,mit-eddie,mot[bos]}!cdx39!{jc,news,root,usenet,uucp} Smail: Codex Corporation; Mailstop C1-30; 20 Cabot Blvd; Mansfield MA 02048-1193 Clever-Saying: If we can't fix it, it ain't broke.
jc@cdx39.UUCP (John Chambers) (01/09/87)
> > What I liked to do a lot of was to take an address like > > fred@site.dec.com and ship it off to decwrl to handle with > > decwrl!fred@site.dec.com. Now smail says "ah, @ takes precendence". > > How am I supposed to dump addresses on a smarter site like decwrl now? > > Try fred%site.dec.com@decwrl > Which brings up an opportunity to remake an old observation: Many of the problems with email paths are due to the existence of a lot of "operators" like '!', '@', '%', '.', and so on, without agreement among the mailers about their precedence. Imagine the fun if the people who write compilers each had their own ideas about the "right" operator precedence. No, you don't have to imagine it; just use some complicated expressions in C that involve the non-traditional operators (i.e., anything other than "+-*/"). Experienced C programmers often throw up their hands at the task of memorizing the precedence table, and just use lots and lots of "unnecessary" parentheses. It has been centuries since mathematicians worked figured out that parentheses are valuable; they even conventionally use several types of "brackets" for readability: (a*[b/sqrt(c)-{x/y}]*17). Scanning for parens is easy to code. Occasionally I've seen the hint that mailers should do this, and (if you have the source code), it could be profitably added to all existing mailers. Instead of using paths like those above, we should start putting pressure on anyone responsible (i.e., anyone with source code :-) to add code that in effect says "This mailer only understands the parts of a mail path that is outside all bracketing characters, after first stripping off all outside brackets, of course". Anything within barckets would be passed to the next mailer for it to ponder. If we could pressure the folks with source to all the mailers, we could then use paths like: decwrl!(fred@site.dec.com) {decwrl!fred@}site.dec.com [fred%site.dec.com]@decwrl fred%(site.dec.com@decwrl) and the results would be unambiguous. This would allow us to force mail through a known working path, even when the "intelligent" mailers were (typically through no fault of their own; the map data isn't good) not able to do it correctly. Hey, you guys with the source code, what do you think of this? It's worked for mathematicians for ages; it can work for us, too. How fast can you add it to your mailer? -- John M Chambers Phone: 617/364-2000x7304 Email: ...{adelie,bu-cs,harvax,inmet,mcsbos,mit-eddie,mot[bos]}!cdx39!{jc,news,root,usenet,uucp} Smail: Codex Corporation; Mailstop C1-30; 20 Cabot Blvd; Mansfield MA 02048-1193 Clever-Saying: If we can't fix it, it ain't broke.
tp@ndmce.uucp (Terry Poot) (01/09/87)
In article <32@auspyr.UUCP> joe@auspyr.UUCP (Joe Angelo) writes: > >Well, I too am beginning to dislike smail ... but not becuase my mail get >Even though I specify a direct path (quick and fast), all it takes is >one smail site to reroute the message BACK across the country ... and two >weeks later my 99K mail gets to me. Note that this is an installation option. I use smail, and my site is set up to use the path you hand it. I use pathalias to find the path to ONLY the next site in the path. If the incomming path tells me to send it to a machine I am connected to, I will. If it says to send it elsewhere, I use pathalias to determine how. If I can't figure it out, I send it to a backbone site, in hopes they have better maps (thanks to the forwarding-relay patch that was posted to the net). (My software can't return it, so this actually gives the sender a better chance of getting it back if it is completely bogus.) smail offers the ability to configure it so that it ignores the supplied path and routes to the destination. I find this to be extremely anti-social, and I wish that that capability had not been provided, as it causes exactly the kind of behavior you describe. By the way, one advantage of always using pathalias to route to the next hop is that I can keep paths working if a neighbor renames his site, or if I drop a link. Pathalias handles these for me. If I didn't use it, it would drop the floor. Now, what I hate is all the sites running sendmail that louse up the From: line, and the way that mailx louses up my outgoing domain format addresses! -- Terry Poot, Nathan D. Maier Consulting Engineers, (214)739-4741 8800 N. Central Expressway, Suite 300, Dallas, Tx 75231, USA UUCP: { seismo | cbosgd | ihnp4 | sun!convex | allegra!convex }!ndmce!tp ARPA: ndmce!tp@seismo.css.gov CSNET: ndmce!tp@smu
bblue@crash.UUCP (Bill Blue) (01/10/87)
In article <4071@nsc.NSC.COM> tron@nsc.UUCP (Ronald S. Karr) writes: >In article <14237@amdcad.UUCP> phil@amdcad.UUCP (Phil Ngai) writes: >>What I liked to do a lot of was to take an address like >>fred@site.dec.com and ship it off to decwrl to handle with >>decwrl!fred@site.dec.com. Now smail says "ah, @ takes precendence". >>How am I supposed to dump addresses on a smarter site like decwrl now? > >Decwrl seems to do this just fine if you use an address like: > > decwrl!site.dec.com!fred fred@site.dec.com@decwrl Will also work nicely. Anytime you need to sneak syntax by smail that would normally be altered, use the above example. --Bill
edc@altnet.UUCP (Eric D. Christensen) (01/10/87)
In article <4070@nsc.NSC.COM> tron@nsc.UUCP (Ronald S. Karr) writes: > >I believe that a somewhat standard system of cost figuring that took >into account poll rate, line cost, line capacity, system reliability >and size, and (possibly) distance, would, if adopted by enough system >administrators, yield a much more reliable path database. > >Another parallel possibility here is to give a cost to a host that >indicates a _through_ cost, which would raise the cost for routing >_through_ a site as opposed to routing _to_ a site. I too believe that with the growth of the net a more effective cost scheme should probably be considered. The current system is so arbitrary that mail often jumps all over the place using "cheap" routes, which results in certain hub system (i.e. ihnp4) to be overloaded. The end result is cheap, but slow mail and a lot of frustration for all. By the way (minor flame here), how come everybody and their dog claims to have a DEMAND or DIRECT connection to ihnp4? Is it any wonder poor ihnp4 is totaly buried in mail? Perhaps some sort of binary ored cost mechanism would be a more effiecent system. This has the advantage that few changes would need to be made to pathalias to invoke it. Something like the following could be considered: 1 Dedicated Line 2 Direct (Demand) Connect 4 Polled System 10 LAN 20 High Speed (>9600 baud) 40 Low Speed (<9600 baud) 100 Local System (<100 miles) 200 Short [sic] Haul (<1000 miles) 400 Long Haul (>1000 miles) One advantage to a system like this is that it can take geographical proximity into account. It could also be much less arbitrary as far as the cost value associated with a particular link. Of course the system administrators would have to stay honest for this to work. Obviously this is only an idea to kick around. Please, no nasty abuse about me posting a half baked idea... I'm making this up as I go along. It's only meant to be food for thought. I'd like to hear your thoughts on the subject. Don't mail them to me though, post them so we can get some global feedback. Besides, I am NOT volunteering to rewrite pathalias or anything. There are lots of people out there who are much better qualified than I to take on an evdevor such as this. Cheers- -- Eric D. Christensen UUCP: ihnp4!sun!altos86!altnet!edc AT&T: (408) 433-3614 Altos Computer Systems Snail Mail: 399 West Trimble Road Customer Support Division San Jose, Calif. 95131 USA
tp@ndmce.uucp (Terry Poot) (01/10/87)
In article <1286@ncc.UUCP> lyndon@ncc.UUCP (Lyndon Nerenberg) writes: >OK - here's one: > > It would be nice if smail could handle aliases. > Here is a quick fix, if you can configure it for your system. I set my mailers up to call the following shell script rather than smail. It does aliasing and then passes the new address list to smail. It doesn't nest aliases, and it treats them as case insensitive. The alias file is named /usr/lib/uucp/Aliases and has the following format: alias:<TAB>address Where of course <TAB> is a real tab. An alias is a list of one or more addresses, where an address is either something you can pass to smail, or a '|' followed by a program invocation. In the latter case, there is one caveat, no spaces are allowed. However any '#' characters will be translated to spaces before the command is executed. Program invocations and mail addresses can be mixed. I set mailx to use this directly, and set the binmail program that comes with smail to call it rather than smail. I also am lucky enough to be able to change the PATH that uuxqt uses, so I but this in my local bin directory and call it rmail, and I get alias handling on incoming mail as well. It has been working here for a month or so at least. This is just a quick hack, and if anyone makes any improvements, please send them back to me. ---------------- cut here, and watch the .signature --------------- : Mail aliasing script. Please send any comments or improvements to: : Terry Poot, Nathan D. Maier Consulting Engineers, (214)739-4741 : 8800 N. Central Expressway, Suite 300, Dallas, Tx 75231, USA : UUCP: { seismo | cbosgd | ihnp4 | sun!convex | allegra!convex }!ndmce!tp : ARPA: ndmce!tp@seismo.css.gov CSNET: ndmce!tp@smu : UUCP Domain based: tp@ndmce.com dest="" list="" plist="" STDIN="" Aliases=/usr/lib/uucp/Aliases for name in $* do if grep -i \^${name}: $Aliases >/dev/null then dest="`grep -i \^${name}: $Aliases|cut -f2-` $dest" else dest="$name $dest" fi done for name in $dest do case $name in \|*) : plist="$name $plist" ;; *) : list="$name $list" ;; esac done if [ "$plist" ] then STDIN="< /tmp/rmail$$" cat >/tmp/rmail$$ for name in $plist do cmd=`echo $name|cut -c2-|tr '#' ' '` eval $cmd $STDIN done fi if [ "$list" ] then exec /l/bin/smail $list $STDIN fi if [ "$STDIN" ] then rm -f /tmp/rmail$$ fi ---------------- cut here --------------------- Here are a few pieces from my alias file, by way of example. The TP alias allows me to get mail to tp, TP, Tp, or tP, as this is case insensitive. As there is no nesting, this doesn't cause a loop. As you see EVERYTHING coming in gets aliased, so this script has been used a lot, and is stable. I've tested the program forwarding, though I don't have any real examples. The one below is concocted for illustrative purposes. ---------------- cut here --------------------- Poot: tp postmaster: tp root: tp Terry.F.Poot: tp Terry.Poot: tp Terry: tp TP: tp TP14: tp usenet: tp uuadm: tp uucp: tp prog: |/l/bin/prog#arg1#arg2#arg3 ------------- cut here ------------------- -- Terry Poot, Nathan D. Maier Consulting Engineers, (214)739-4741 8800 N. Central Expressway, Suite 300, Dallas, Tx 75231, USA UUCP: { seismo | cbosgd | ihnp4 | sun!convex | allegra!convex }!ndmce!tp ARPA: ndmce!tp@seismo.css.gov CSNET: ndmce!tp@smu
david@ukma.ms.uky.csnet (David Herron, NPR Lover) (01/10/87)
In article <32@auspyr.UUCP> joe@auspyr.UUCP (Joe Angelo) writes: >Quite often I have large pieces of mail shipped all over the country. >From Boston to Miami to Denver to Canada [back] to Miami then to San Jose. >Even though I specify a direct path (quick and fast), all it takes is >one smail site to reroute the message BACK across the country ... and two >weeks later my 99K mail gets to me. No, the problem is not with smail. The problem is with the data which is being given to pathalias. The map is a description of a directed graph with weights on each edge. All pathalias does is compute a least-cost-spanning-tree of the graph. Since everybody which generates map data has different methodologies for assigning the weights then it's no wonder that paths can be screwy... Another point to consider is that in some cases it is CHEAPER to make the cross country transfer ... communications technology has made geographic considerations less and less and less important. A company (AT&T for instance) may advertise it's internal network in the map allowing everybody else on the net to use them. Then because of the weights assigned to that internal link (DIRECT or HOURLY both seem to be reasonable weights) pathalias will very likely decide to route a buncha stuff over that link.... -- David Herron, cbosgd!ukma!david, david@UKMA.BITNET, david@ms.uky.csnet (I'm also "postmaster", "news", "netnews", "uucp", "mmdf", and ...) "Don't put your money in South Africa -- Give it to me!" -- Cerebus
pdb@sei.cmu.edu (Patrick Barron) (01/10/87)
In article <649@crash.UUCP> bblue@crash.UUCP (Bill Blue) writes: > > fred@site.dec.com@decwrl > >Will also work nicely. Anytime you need to sneak syntax by smail >that would normally be altered, use the above example. > >--Bill Remember, though, if you're trying to get mail out over the Internet, the above address is illegal according to RFC822, which explicitly specifies that only ONE '@' sign be present in the address. --Pat.
jim@otto.UUCP (Jim Thompson) (01/11/87)
Summary:
Expires:
Sender:
Followup-To:
Distribution:
Keywords:
Hey, I don't understand the problem. I use smail, and really like it.
Mail sent to foo@bar gets 'routed' there. mail sent to 'a!b!c!d' gets
pushed on the uucp mailer. If, perchance, we don't talk to 'a' then
smail tries to build a route to 'a', if that fails, smail tries to build
a path to 'c', then 'b'. If some other site sends mail through 'otto' then
and it is a valid path, nothing gets touched. (i.e. we talk to the
machine 'a' in the above example), if not, then the rest of the rules
are followed. If smail can't find your silly machine, or any other
in the path, THEN the mail bounces..
--
--Jim
____________________________________________________________________________
| try: {akgua,ihnp4,mirror,sdcrdcf}!otto!jim Jim Thompson |
| for "smart" mailers -- jim@otto.UUCP Las Vegas Sun |
| 2551 Green Valley Pkwy |
| <My company doesn't care what I think..> Henderson, Nv. 89015 |
| "All of life is a blur of Republicans and meat" (702) 454-4636 |
----------------------------------------------------------------------------page@ulowell.UUCP (Bob Page) (01/12/87)
In article <1286@ncc.UUCP> lyndon@ncc.UUCP (Lyndon Nerenberg) writes: > It would be nice if smail could handle aliases. pathalias does, so why have smail do it too? ..Bob -- Bob Page, U of Lowell CS Dept. ulowell!page, page@ulowell.CSNET
lyndon@ncc.UUCP (01/17/87)
In article <929@ulowell.UUCP>, page@ulowell.UUCP (Bob Page) writes: > In article <1286@ncc.UUCP> lyndon@ncc.UUCP (Lyndon Nerenberg) writes: > > It would be nice if smail could handle aliases. > > pathalias does, so why have smail do it too? What I was referring to was aliases ala sendmail and the /usr/lib/aliases file. I guess this has been added to smail 2.0. WRT the request for smail 2.0 source I made, I have five people who sent mail requesting I forward it if I get it, but nobody seems to have it :-) Help somebody please! -- Lyndon Nerenberg - Nexus Computing Corp. - lyndon@ncc.UUCP UUCP: {ihnp4,ubc-vision,vax135,watmath}!alberta!ncc!lyndon
tron@nsc.UUCP (01/17/87)
In article <4982@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >In article <4070@nsc.NSC.COM> tron@nsc.NSC.COM (Ronald S. Karr) writes: >>The greatest problem here is ... a lack of standardization on what >>costs should be used for map entries.... > ... Some companies have dedicated, high-speed links >between (say) California and New York offices. Going from Palo >Alto to Rochester to NYC to L.A. may be faster and less expensive >than going from Palo Alto directly to L.A. Thus, a well thought-out standard for computing costs should give very low costs to direct high-capacity links, though it may be preferable to use two short-distance direct links to get to a site rather than using two long-distance direct links. This last point is certainly open to debate. -- tron |-<=>-| ARPAnet: nsc!tron@sun.COM tron@sc.nsc.com UUCPnet: {amdahl,decwrl,hplabs,pyramid,sun}!nsc!tron
tron@nsc.UUCP (01/17/87)
In article <272@.altnet.UUCP> edc@altnet.UUCP (Eric D. Christensen) writes: >Perhaps some sort of binary ored cost mechanism would be a more effiecent >system. This has the advantage that few changes would need to be made >to pathalias to invoke it. Something like the following could be considered: > > 1 Dedicated Line > 2 Direct (Demand) Connect > 4 Polled System > 10 LAN > 20 High Speed (>9600 baud) > 40 Low Speed (<9600 baud) > 100 Local System (<100 miles) > 200 Short [sic] Haul (<1000 miles) > 400 Long Haul (>1000 miles) A useful starting point, though I would suggest adding a digit to each of these to allow a +/-HIGH and +/- LOW on the values. However, experimentation with pathalias must be done to ensure that this does the correct thing. Note that this means that it is better to go through 350 dedicated lines than to use one long haul line, though this may be a technicality. -- tron |-<=>-| ARPAnet: nsc!tron@sun.COM tron@sc.nsc.com UUCPnet: {amdahl,decwrl,hplabs,pyramid,sun}!nsc!tron
ewiles@netxcom.UUCP (Edwin Wiles) (01/21/87)
In article <4076@nsc.nsc.com> tron@nsc.UUCP (Ronald S. Karr) writes: >In article <272@.altnet.UUCP> edc@altnet.UUCP (Eric D. Christensen) writes: > > > > [...edited...suggestion of binary or'ed cost system, nicely done! ] > > > >A useful starting point, though I would suggest adding a digit to each of these >to allow a +/-HIGH and +/- LOW on the values. However, experimentation with >pathalias must be done to ensure that this does the correct thing. Note that >this means that it is better to go through 350 dedicated lines than to use >one long haul line, though this may be a technicality. Then I would suggest that you add something like a 'max-hops' value that would limit this kind of insanity. You'd have to be carefull though, you don't want to keep people from mailing to some site that only has one path to it that happens to be one hop longer than your limit! -- Edwin Wiles seismo!sundc!netxcom!ewiles Net Express, Inc. 1953 Gallows Rd. Suite 300 Vienna, VA 22180