lmb@vsi1.UUCP (Larry Blair) (03/05/88)
I am not in favor of rerouting a local user's explicit path for several well
known reasons, the greatest of which are that you can't avoid a temporarily
dead host and that when someone's local machine matches a name in the maps,
you simply CAN'T mail to them.
(FLAME ON!)
As far as rerouting mail sent through your site goes, this should be considered
to be a no-no subject to immediate de-netting! A user several hops away has
no way to know that you are going to screw up his path. If someone routing
through your machine wants to generate a 20 hop path, that's his business, not
yours.
I propose that a new field be added to the map entry where sites that reroute
other people's mail indicate so. Pathalias should be changed to accept an
option that only uses these sites as a last resort (since I found out that
rutgers is rerouting, I changed their map entry to show all their connections
as DEAD).
---
* * O Larry Blair
* * O VICOM Systems Inc. sun!pyramid----\
* * O 2520 Junction Ave. uunet!ubvax----->!vsi1!lmb
* * O San Jose, CA 95134 ucbvax!tolerant/
* * O +1-408-432-8660kennedy@tolerant.UUCP (Bill Kennedy) (03/05/88)
In article <327@vsi1.UUCP> lmb@vsi1.UUCP (Larry Blair) writes: >I am not in favor of rerouting a local user's explicit path for several well >known reasons, the greatest of which are that you can't avoid a temporarily >dead host and that when someone's local machine matches a name in the maps, >you simply CAN'T mail to them. > >(FLAME ON!) [ ... flame agreed but deleted ] First, let me completely disclaim Tolerant, this is my opinion as SA of two small remote sites, Tolerant is nice enough to let me use their equipment. This is more than an irritation, particularly if your site, like mine, is long distance from everything. I coordinate a fairly sizeable (> 60 people) mailing list and one of the things that we go through before anyone is put on the list is verify that we have reliable email connections. So catch this, I pay LD to mail to a known-to-work path and some site gets smart, marks it up and I get to pay LD again to have it bounce, then pay LD again to send it via a worse path but to circle around the one who marked it up wrong. I have two neighbor sites who do this and it's not only time, and stomach acid, it's money! *MY* money, not the university's. If you don't think that $50-$75 a month hurts, just send it to _me_ out of _your_ pocket starting last month :-) Could someone at one of those sites that re-routes everything please explain the rationale? Some of the stuff gets routed so that it takes *days* longer to get where it's going than if it just went the way it was sent. Why must *everything* be re-routed? Someone please convince me. <My flame off> >As far as rerouting mail sent through your site goes, this should be considered >to be a no-no subject to immediate de-netting! A user several hops away has >no way to know that you are going to screw up his path. If someone routing >through your machine wants to generate a 20 hop path, that's his business, not >yours. I'll disagree with you here Larry, news reply paths are notoriously long, sometimes circular, and frequently silly. I have rn set up at each of my sites to force a re-route, arbitrarily. I will also route mail that is sent without a bang path or to a bang path I can't reach. Note that I said that "rn" forces a re-route, not "rmail". If you send me a 20 hop path, as long as I talk to the next site in it I'll pass it but from time to time I have been tempted... Finally, if I can't route it I send it to rutgers, I know _they_ will do something with it :-) Bill Kennedy ...{rutgers,cbosgd,ihnp4!petro}!ssbn!bill or bill@ssbn.WLK.COM
cik@l.cc.purdue.edu (Herman Rubin) (03/06/88)
About two years ago, I had difficulty about getting UUCP mail from my home site to another. The problem was that pathalias showed a link as DAILY when it should have been called DEAD. Now I had no problem in finding a working path, but since the "smart" mailers ignore what I tell them, mail did not get there. The mail gurus should realize that maps are always out of date in some manner, and that there may be good reasons why the "smart" mailers are, in fact, stupid. Something should be done to get the mail through! -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (ARPA or UUCP) or hrubin@purccvm.bitnet
mechjgh@tness7.UUCP (Greg Hackney ) (03/07/88)
In article <327@vsi1.UUCP> lmb@vsi1.UUCP (Larry Blair) writes: >I am not in favor of rerouting a local user's explicit path >As far as rerouting mail sent through your site goes, this should be considered >to be a no-no subject to immediate de-netting! >(since I found out that >rutgers is rerouting, I changed their map entry to show all their connections >as DEAD). Ah. So YOU are rerouting around Rutgers because you think it's the best way to treat mail. By your terms, you should be de-netted.
mike@ists (Mike Clarkson) (03/07/88)
In article <327@vsi1.UUCP>, lmb@vsi1.UUCP (Larry Blair) writes: > I am not in favor of rerouting a local user's explicit path for several well > known reasons, the greatest of which are that you can't avoid a temporarily > dead host and that when someone's local machine matches a name in the maps, > you simply CAN'T mail to them. > > (FLAME ON!) > As far as rerouting mail sent through your site goes, this should be considered > to be a no-no subject to immediate de-netting! A user several hops away has > no way to know that you are going to screw up his path. I'm finding this happening a lot recently, and I agree. I've never meet a pathalias output file that didn't need some revisions, and many of the re-routing routes are worse, not better than what they threw away. > I propose that a new field be added to the map entry where sites that reroute > other people's mail indicate so. At least it would make it easier to spot the hosts that are re-routing. Without knowing who's doing it, it's very difficult to track down mail addressing problems. -- Mike Clarkson mike@ists.UUCP Institute for Space and Terrestrial Science York University, North York, Ontario, CANADA M3J 1P3 (416) 736-5611
lmb@vsi1.UUCP (Larry Blair) (03/08/88)
In article <9@tness7.UUCP> mechjgh@tness1.UUCP (Greg Hackney) writes: %In article <327@vsi1.UUCP> lmb@vsi1.UUCP (Larry Blair) writes: % %>I am not in favor of rerouting a local user's explicit path %>As far as rerouting mail sent through your site goes, this should be considered %>to be a no-no subject to immediate de-netting! %>(since I found out that %>rutgers is rerouting, I changed their map entry to show all their connections %>as DEAD). % %Ah. So YOU are rerouting around Rutgers because you think it's %the best way to treat mail. By your terms, you should be de-netted. You missed my point! I am NOT rerouting other sites mail. I am merely helping onsite users who let their mail be autorouted avoid a site that will send the mail to who-knows-where. ---- * * O Larry Blair * * O VICOM Systems Inc. sun!pyramid----\ * * O 2520 Junction Ave. uunet!ubvax----->!vsi1!lmb * * O San Jose, CA 95134 ucbvax!tolerant/ * * O +1-408-432-8660
ambar@athena.mit.edu (Jean Marie Diaz) (03/08/88)
In article <9@tness7.UUCP> mechjgh@tness1.UUCP (Greg Hackney) writes: >In article <327@vsi1.UUCP> lmb@vsi1.UUCP (Larry Blair) writes: >>(since I found out that rutgers is rerouting, I changed their map entry >>to show all their connections as DEAD). >Ah. So YOU are rerouting around Rutgers because you think it's >the best way to treat mail. By your terms, you should be de-netted. You're confused about what "rerouting" is. If a piece of mail comes through my machine addressed: mit-eddie!spt!root, and my machine says "I know a better way to get to spt! We talk to it directly!" and sends it to spt!root instead, that's rerouting. Me editing my maps to show all routes to rutgers as DEAD is not rerouting. It means that any mail that originates on my machine (quite a bit -- we run several large mailing lists off of bloom-beacon) will not be routed through rutgers. This is a perfectly reasonable thing to do, since you're not second-guessing anyone (not even your own users, for if someone on bloom-beacon addresses mail to mit-eddie!rutgers!spam!foo, that's the path that it takes). AMBAR ambar@bloom-beacon.mit.edu {backbones}!mit-eddie!ambar
jc@minya.UUCP (John Chambers) (03/08/88)
> (FLAME ON!) > As far as rerouting mail sent through your site goes, this should be considered > to be a no-no subject to immediate de-netting! A user several hops away has > no way to know that you are going to screw up his path. I've agreed with this publicly on numerous occasions, and now find myself in a position of wishing to do it right, and not quite knowing how. The problem is the notorious sendmail, which is running on various machines over which I have Postmaster power (if I choose to accept the assignment, knowing full well that the whole thing is likely to self-destruct in my hands in 3 minutes :-). So the puzzle I have for all you mail wizards out there: Is there a simple (well, I know nothing about sendmail is simple, but I can dream, can't I?), straighforward recipe for taking an existing sendmail.cf and modifying it so that it takes bang paths literally? The problem gets somewhat more complicated by the fact that several of the machines have more than one kind of email link, so the hostname before the bang should be looked up in any of several files (or dbm databases) to find out which mailer is best to use. I have a vague, semi-mystical idea of how this is done, and I can make it work more than half the time (which seems good enough for most Postmasters, but I'm a weird, picky sort). Any good ideas? -- John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393)
brian@ucsd.EDU (Brian Kantor) (03/08/88)
Here's what we do with mail on our campus mail gateway machine "ucsd.edu": First, we turn the To: (and Cc:, etc) addresses into a canonical form to simplify further processing. Specifically: user@host -> user@host.ucsd.edu host!user -> user@host.uux user@host.uucp -> user@host.uucp user@host.any -> user@host.any Next, we do the following for special cases: 1. Is it a domain we can handle locally via uucp? i.e., user@*.cts.com -> crash!*.cts.com!user 2. Is it an on-campus host (in any of three lists)? user@campushost.ucsd.edu user@campushost.uux is resolved to the appropriate mailer (This means that campushost!user is properly handled) 3. Is it a pseudo-domain (i.e., for some attached network)? If so, we forward it to the appropriate gateway. user@host.bitnet sent to the bitnet gateway user@host.span sent to the span gateway 4. Is it a uucp host that we talk to DIRECTLY? If so, just give it to uux to send on its merry way. 5. Is it a uucp host that we don't talk to directly? If so, give it to the routing version of uux to figure out some path based on the maps and send it on its way. 6. Is it an on-machine address? If so, deliver locally. 7. It must be an Internet address. Resolve with MX and the nameserver. This is all done with sendmail; we use 'uumail' to supply the routing version of uux but that's AFTER we resolve to the uucp mailer based on the style of the hostname. The bug with this is that if someone right down the road from us and a good uucp connection starts using domain-style return addresses, we'll wind up sending mail to them through their Internet mail forwarder until I get around to putting another special-case rule in there to catch them. I probably forgot something we do; this seems too simple. Curious (and BRAVE) folk can view this wonderous sendmail.cf file in the public FTP directory on host UCSD.EDU. It mostly works; I make no claim to it being entirely bug-free. There is no such thing as bug-free software anyway. Brian Kantor UCSD Postmaster & Chief News Weenie UCSD Office of Academic Computing Academic Network Operations Group UCSD B-028, La Jolla, CA 92093 USA brian@ucsd.edu BRIAN@UCSD ucsd!brian
kennedy@tolerant.UUCP (Bill Kennedy) (03/09/88)
This morning I got another log for the fire. I had sent a piece of mail
to a legitimate machine name within a site name and my neighbor site
decided it should go a better way. Now the mailer at bellcore (who
should have nothing to do with it) is griping at me because it can not
reach site foo and it's going to just die in four more days... So I have
gotten to pay LD four times and get to again because the message is going
to just wither away at bellcore.
Misrouting mail costs time, stomach acid, and resources all along the way.
My stuff is occupying disk space at a site who is innocent of everything.
Had my neighbor sent it the way I addressed it it would have been delivered
to its destination by now. Brian Kantor is right, I suppose it's OK to
stop and say "whoah! I'm direct to that site" and short circuit it to go
direct, maybe also to pick through 20+ hops or something... BTW the path
I used works A-OK if you can keep it away from the East Coast :-(
These opinions are my own, Tolerant is nice enough to let me use their gear.
Bill Kennedy {rutgers,cbosgd,ihnp4!petro}!ssbn!bill or bill@ssbn.WLK.COMlee@uhccux.UUCP (Greg Lee) (03/09/88)
There was also a discussion of rerouting bang paths a few months ago. Then, as now, there seemed to be a consensus that it ought not be done. But it still is done -- how come? There are some sites I cannot mail to, and when the mail is returned, the header shows a routing that bears no resemblance to the one I requested, and that routing always went though rutgers. Since the path I specify is ignored, I can't seem to avoid rutgers, either. Very frustrating. The situation seems to arise when the site I want to mail to does not have an entry in the maps, so the only way to get to it is to route through a site to which it has a local connection. Greg Lee, lee@uhccux.uhcc.hawaii.edu
mechjgh@tness7.UUCP (Greg Hackney ) (03/09/88)
In article <3544@bloom-beacon.MIT.EDU> ambar@athena.mit.edu (Jean Marie Diaz) writes: >You're confused about what "rerouting" is. Aw, give me a break, Jean Marie. It was meant to be humorous in a weird sort of way... About rerouting.... One of our Vaxen is serving as a netnews feed to several sites. It handles a lot of email replies to netnews articles, most of which have very very long bang style return addresses. The path that netnews takes, is hardly ever the shortest path that pathalias would come up with. I've seen it routed all over North America just to get to the machine next door. If most of the sites did rerouting, a lot of time and money would be saved in my opinion. -- Greg Hackney Southwestern Bell Telephone Co. Texas Network Engineering Support Systems root@tness1.UUCP
kls@ditka.UUCP (Karl Swartz) (03/10/88)
In article <327@vsi1.UUCP> lmb@vsi1.UUCP (Larry Blair) writes: >I am not in favor of rerouting a local user's explicit path for several well >known reasons, the greatest of which are that you can't avoid a temporarily >dead host and that when someone's local machine matches a name in the maps, >you simply CAN'T mail to them. One of the guys at formtek (my office) had a friend who's sole connection to the world was via harvard. Apparently, harvard would either auto-route or send everything to rutgers to auto- route. The path that this guy's mail tried to take to us was something like harvard!rutgers!seismo!sun!cadre!idis!formtek!user Unfortunately, one of those links was dead about 98% of the time (names will be omitted to protect the guilty from embarrasment) and thus this guy could not get mail to us. Period. >I propose that a new field be added to the map entry where sites that reroute >other people's mail indicate so. Pathalias should be changed to accept an >option that only uses these sites as a last resort (since I found out that >rutgers is rerouting, I changed their map entry to show all their connections >as DEAD). Or you can just declare *rutgers* to be dead, or at least tell pathalias to avoid rutgers. Unfortunately, most things seem to want to go that way, and avoiding rutgers (from here, at least) leads to some *really* bizarre routings. -- Karl Swartz |UUCP decvax!formtek!ditka!kls 1-412/937-4930 office | {floyd,pitt,psuvax1}!idis!formtek!ditka!kls |BIX kswartz "I never let my schooling get in the way of my education." (Twain)
kls@ditka.UUCP (Karl Swartz) (03/10/88)
In article <475@minya.UUCP> jc@minya.UUCP (John Chambers) writes: >a position of wishing to do it right, and not quite knowing how. The problem >is the notorious sendmail, which is running on various machines over which I >have Postmaster power (if I choose to accept the assignment, knowing full well >that the whole thing is likely to self-destruct in my hands in 3 minutes :-). > >So the puzzle I have for all you mail wizards out there: Is there a simple >(well, I know nothing about sendmail is simple, but I can dream, can't I?), >straighforward recipe for taking an existing sendmail.cf and modifying it >so that it takes bang paths literally? Not sure what you mean by "takes bang paths literally". As it comes out of the box, sendmail should just pass bang paths on to the next guy, via the appropriate mechanism for reaching "the next guy". I've hacked formtek's sendmail.cf to deal with several cases; in the hope that the descriptions will help you in your quest, here they are. First, I wanted to deal with the awful, huge replies from news. In our case, this was fairly easy, since a few hops up the usual path is "cadre!PT.CS.CMU.EDU!rochester". Apparently, CMU will not forward mail that doesn't have a sender or receiver inside CMU. So, mail sent via that path *will* bounce, and I have no qualms about sending these to smail for full routing: from ruleset 0: # Force full routing of dumb mail replies R$+.cmu.edu!rochester!$+<@$+> $#reply $@rochester $:$2 # Resolve UUCP domain from UUCP mailer specifications: Mreply, P=/bin/smail, F=sDFMhum, S=13, R=23, M=100000, A=smail -R -vH$j $h!$u The other set of problems I wanted to deal with were some awfully, horribly mutilated addresses I was seeing, such as sun.com!idis!psuvax1!texsun!arc!user Say what? We might talk to sun.com via psuvax1, but certainly not directly. Hmmm. Finally figured out this sequence of events: arc: arc!user texsun: texsun!arc!user sun.com: texsun!arc!user@sun.com psuvax1: psuvax1!texsun!arc!user@sun.com idis: idis!psuvax1!texsun!arc!user@sun.com our smail: sun.com!idis!psuvax1!texsun!arc!user Simply awful. Now if we weren't running smail, it would all work, but fo all the wrong reasons. With smail, it's screwed. An even more lovely example is this one: zermatt.lcs.mit.edu!idis!psuvax1!@killington.lcs.mit.edu:rws Charming. Well, I set as my goal to untangle these messes for our unknowing users, putting things into full bang-paths to minimize confusion down the pike, and to avoid screwing up valid addresses: from ruleset 8: ### input rewriting S8 # Hacks for f***ed up addresses from down the way R$+!$+!idis!$+ $@$1!$2!idis!$3 only fix locally R$+.$-!idis!$=B!$+ $:idis!$3!$4@$1.$2 use domain format Ridis!$=B!$+ $:idis!$1<$2> focus on username R$+<@$+:$+> $1<$3@$2> convert @h: R$+<$+@$+> $1<$3%$2> map @ to % R$+<$+%$+%$+> $1!$4<$2%$3> untangle u%h2%h1 R$+<$+%$+> $1!$3!$2 force bang path R$+<$+> $1!$2 strip remaining groupers definitions from up front: # brain-damaged nodes that generate BAD addresses CBcadre pitt psuvax1 Note that ruleset 8 is called as "host dependent cleanup" from ruleset 0 in my sendmail.cf, which long ago was stock for a Sun. Note too that this seems to work for me for every case I've tried--which doesn't imply it's 100% right. I'm sure there are some address forms which I'll mangle, but which I've never seen at our site. Sorry to ramble on for so long ... I hope this helps somebody. -- Karl Swartz |UUCP decvax!formtek!ditka!kls 1-412/937-4930 office | {floyd,pitt,psuvax1}!idis!formtek!ditka!kls |BIX kswartz "I never let my schooling get in the way of my education." (Twain)
soley@ontenv.UUCP (Norman S. Soley) (03/10/88)
In article <327@vsi1.UUCP>, lmb@vsi1.UUCP (Larry Blair) writes: > (FLAME ON!) > As far as rerouting [explicitly addressed] mail sent through your site > goes, this should be considered to be a no-no subject to immediate de-netting! I agree but can we really afford to kick that much of the backbone off the net? > I propose that a new field be added to the map entry where sites that reroute > other people's mail indicate so. Agreed > Pathalias should be changed to accept an > option that only uses these sites as a last resort (since I found out that > rutgers is rerouting, I changed their map entry to show all their connections > as DEAD). I don't see the point of this. What makes the paths your pathalias generates any better (or for that matter any different) than paths generated by the offending site? Pathalias has the -a (for avoid this site) flag which can minimize you're use of bad sites why not use it? -- Norman Soley - Data Communications Analyst - Ontario Ministry of the Environment UUCP: utzoo!lsuc!ncrcan!---\ VOICE: +1 416 323 2623 {utzoo,utgpu}!sickkids!ontenv!norm ENVOY: N.SOLEY {mnetor,utgpu}!ontmoh/
jc@minya.UUCP (John Chambers) (03/11/88)
In article <1642@uhccux.UUCP>, lee@uhccux.UUCP (Greg Lee) writes: > There was also a discussion of rerouting bang paths a few months ago. > Then, as now, there seemed to be a consensus that it ought not be done. > But it still is done -- how come? Simple - because there are lots of mailers lurking around that don't follow the concensus thought. I have some sympathy here, since I've been trying to find out how to make sendmail behave correctly on quite a few systems. There are many mail packages out there that are being run by people (like myself) that only partially understand them, and they can often be made to behave sanely only on a statistical basis. (If it works most of the time, don't touch it!) Queries to "experts" tend to produce lots of arrogant insults, which doesn't help matters at all. Eventually we'll probably have some self-installing and self-correcting packages. For the present, when you submit your mail to the network, it is ending up in the jaws of lots of semi- tamed mailers whose behavior is as puzzling to the owners of the machines as it is to you and me and other mere humans. > There are some sites I cannot mail > to, and when the mail is returned, the header shows a routing that > bears no resemblance to the one I requested, and that routing always > went though rutgers. Since the path I specify is ignored, I can't > seem to avoid rutgers, either. Very frustrating. Around here, we have a lot of very similar problems with mail that stops off at harvard. I get lots of mail that came to me via paths like ...!harvard!mit-eddie!harvard!foo!harvard!bar!adelie!minya!jc. The nice thing here is to note that mit-eddie!minya is a uucp link. The map entries show both that link and adelie!minya to be DAILY, so it's not clear why eddie bounces it back to harvard. I've brought it up with those machines' postmasters, but they are very busy. In almost all cases, the mail would have been much faster if it had avoided harvard and used the original path. But harvard advertises itself (via its map listing) as a fast path to lots of machines, so lots of mail gets forwarded there. I know for a fact that a lot of mail directed my way has disappeared, never to be seen again. I've also sent myself mail from various of the places I've worked, and seen a week or two of wandering all over the world, all documented in the header. (If I could only travel so easily!) If anyone out there has written to me in the last couple of weeks, and not received a response, you might try again... If we have patience, but keep harassing the culprits who foist these "intelligent" mailers on us, maybe eventually we'll have something that works. Of course, just about then, IBM will release a new package that will be installed on half the PCs in the world and will randomly misroute anything to/from non-IBM systems. (:-) -- John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393)
zeeff@b-tech.UUCP (Jon Zeeff) (03/11/88)
Here are some quick hacks I did to smail 2.5 to "improve it". The authors
might want to consider something similar.
Add the following to the beginning of the resolve routine in resolve.c
---------------------------------------------------------
char *ptr;
/* count number of ! */
for (i=0,ptr = address; ptr = strchr(ptr,'!'); ++ptr,++i);
/* if more than 10, we want to reroute since it's probably a news reply */
if (i > 10) routing = REROUTE;
/*
sometimes someone sends mail to "user%othersite@thissite". Since
a local address (no ! or @) with a % will fail anyway, let's attempt
to fix it like a sendmail site would.
*/
if (strchr(address,'!') == NULL
&& strchr(address,'@') == NULL
&& (ptr = strrchr(address,'%'))) *ptr = '@';
-----------------------------------------------------------
In my opinion, smail is a nice piece of software. If you don't use
it, you probably should.
--
Jon Zeeff Branch Technology,
uunet!umix!b-tech!zeeff zeeff%b-tech.uucp@umix.cc.umich.edudhesi@bsu-cs.UUCP (Rahul Dhesi) (03/11/88)
In article <11@tness7.UUCP> mechjgh@tness7.UUCP (Greg Hackney) writes: >The path that netnews takes, is hardly ever the shortest >path that pathalias would come up with. I've seen it routed >all over North America just to get to the machine next door. > >If most of the sites did rerouting, a lot of time and money >would be saved in my opinion. The right way to do this is to patch smail so it will reroute when it sees a path that is longer than a threshold. This will catch most replies to the return path of a news article without affecting manually-crafted paths. This is how we do it here. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi
kennedy@tolerant.UUCP (Bill Kennedy) (03/12/88)
In article <11@tness7.UUCP> mechjgh@tness7.UUCP (Greg Hackney) writes: >In article <3544@bloom-beacon.MIT.EDU> ambar@athena.mit.edu (Jean Marie Diaz) writes: >>You're confused about what "rerouting" is. [ deleted that not petaining to my point ] >About rerouting.... > >One of our Vaxen is serving as a netnews feed to several >sites. It handles a lot of email replies to netnews articles, >most of which have very very long bang style return addresses. > >The path that netnews takes, is hardly ever the shortest >path that pathalias would come up with. I've seen it routed >all over North America just to get to the machine next door. I won't repeat my email reply to Greg, and I have already emoted about how I feel about re-routing. Also, I agree with the notion of re-routing news replies until a better technique is developed to mail them. I arbitrarily re-route netnews replies by forcing the -r flag to smail in rn (I know that might only work for me...). But let's not confuse the issue. Is it right to superimpose a news solution over a mail problem to the detriment of the mail system? >If most of the sites did rerouting, a lot of time and money >would be saved in my opinion. Poppycock and balderdash. If you had to see the amount of LD paid, disk space and cycles used to handle the bounces that these mailers generate... well, poppycock and balderdash. Some sites will actually hold mail they can't deliver, most will pack it up and send it back. Is that saving a lot of time and money? My point is that the news system is a lot better place to go tangle with the goofy paths that come with news distribution. That is done at my site before it's ever introduced into the mail system. It makes sense to me... It just wouldn't be all that hard to do. If I wasn't abbreviating replies and my news feed said he'd stop handling my mail until I did, it wouldn't take me long to comply. The opinions are my own, Tolerant is nice enough to let me use their equipment Bill Kennedy {rutgers,cbosgd,ihnp4!petro}!ssbn!bill or bill@ssbn.WLK.COM
dudek@ubglue.ksr.com (Glen Dudek) (03/13/88)
In article <202@ditka.UUCP> kls@ditka.UUCP (Karl Swartz) writes: >One of the guys at formtek (my office) had a friend who's sole >connection to the world was via harvard. Apparently, harvard >would either auto-route or send everything to rutgers to auto- >route. I was postmaster@harvard.harvard.edu from 6/85-6/87. My policy has always been to *only* look at the first host in a UUCP path, and only autoroute if we didn't talk (or didn't want to pay the long distance to talk) directly to that host. The only mail that is directed to rutgers is mail that was explicitly addressed there, or mail for which the next hop was through a host which pathalias thought was best reachable through rutgers (e.g., most ATT sites). I know for a fact that this software has not been changed to any significant degree since I left (KSR's major mail link is through harvard, surprise :-). In article <479@minya.UUCP> jc@minya.UUCP (John Chambers) writes: >Around here, we have a lot of very similar problems with mail that >stops off at harvard. I get lots of mail that came to me via paths >like ...!harvard!mit-eddie!harvard!foo!harvard!bar!adelie!minya!jc. >The nice thing here is to note that mit-eddie!minya is a uucp link. >The map entries show both that link and adelie!minya to be DAILY, >so it's not clear why eddie bounces it back to harvard. The last time I looked, putting together an up-to-date pathalias database was a large investment in time and effort. Getting one that was usable was even more so! By usable I mean one that generated workable paths for most sites. There was no good way to verify that a pathalias database was a 'good' one other than by gross inspection of some of the more commonly utilized paths. One of the more successful methods used by Nike Horton was to generate a count of paths/first hops, (e.g. 4000 hosts have 'rutgers' as the first hop in the path), and to examine this table to see if it matched expectations. Expectations, of course, were learned only through experience. Experience, of course, was learned only through mistakes. This procedure is probably better now, but the point is that it cannot be verified. In any case, the problem John Chambers writes about is probably due to out-of-date or conflicting pathalias data at least between harvard and mit-eddie. Harvard probably thinks mit-eddie!minya is the best path, since it uses SMTP to get to mit-eddie and only UUCP to get to adelie. Mit-eddie may think adelie!minya is better than its own direct UUCP to minya, and mail to adelie should (correctly) go through harvard. Perhaps the postmaster@mit-eddie eliminated the link or doesn't want to overutilize it. How is harvard to know until/unless the maps are updated? What will happen to the mail during the fuzzy in-between time while the maps are being updated if auto-routing is used? I don't even want to think about it. >...I've brought >it up with those machines' postmasters, but they are very busy. This is very true. The only reason I was able to maintain mail in a reasonable state was because I dedicated a large amount of time over 6 months to understanding the details of mail and sendmail. I know the current staff at Harvard is undermanned, and I am sure they are reluctant to dedicate the time necessary to have the confidence to make the mistakes necessary to learn the right changes to make. If you are using Harvard for auto-routing, you are relying on them to maintain their data at least as up-to-date as you would. If they do not, then you can maintain it yourself, and count on Harvard not to rewrite the path if you need to send mail through them. >...Eventually we'll probably have some self-installing and >self-correcting packages. For the present, when you submit your >mail to the network, it is ending up in the jaws of lots of semi- >tamed mailers whose behavior is as puzzling to the owners of the >machines as it is to you and me and other mere humans. This is also very true. I can understand why rutgers wants to autoroute, but I can't approve of until mail systems are self-installing, self-correcting, and self-maintaining. The UUCP maps are still bound by GIGO, and GI is still the rule. The regional map maintainers do their damndest, to their great credit, but they cannot completely verify the correctness of the UUCP data they get. >If we have patience, but keep harassing the culprits who foist these >"intelligent" mailers on us, maybe eventually we'll have something >that works. I think 'notifying them of problems' is more appropriate than 'harassing', and try and make sure you take the trouble to find the right culprits. Anyone in a UUCP path can rewrite it - it doesn't have to be harvard or rutgets. We really do need mail headers and log info which records the incoming and outgoing From: and To: addresses. How about something similar to the IP record-route option? Glen Dudek ksr!dudek@harvard.harvard.edu
jbs@fenchurch.MIT.EDU (Jeff Siegal) (03/14/88)
In article <479@minya.UUCP> jc@minya.UUCP (John Chambers) writes: >Around here, we have a lot of very similar problems with mail that >stops off at harvard. I get lots of mail that came to me via paths >like ...!harvard!mit-eddie!harvard!foo!harvard!bar!adelie!minya!jc. >The nice thing here is to note that mit-eddie!minya is a uucp link. ^^^^^^^^^^^^^^^ >The map entries show both that link and adelie!minya to be DAILY, [...] ^^^^^^^^^^^^ This is the source of the confusion. Although the minya map entry lists minya adelie(DAILY) and minya mit-eddie(DAILY) this data is only relevant for mail going _from_ minya _to_ adelie or mit-eddie. For mail going the other direction (i.e. to minya), only map entries with minya on the _right_ side have are relevant effect. But here is the real problem. The adelie map entry lists: adelie minya(HOURLY) Does adelie really talk to minya every hour? If so, the mit-eddie routing through harvard and adelie is correct. If not, the adelie map entry should be updated to reflect correct information. Jeff Siegal
grr@cbmvax.UUCP (George Robbins) (03/14/88)
In article <1642@uhccux.UUCP> lee@uhccux.UUCP (Greg Lee) writes: > There was also a discussion of rerouting bang paths a few months ago. > Then, as now, there seemed to be a consensus that it ought not be done. > But it still is done -- how come? There are some sites I cannot mail > to, and when the mail is returned, the header shows a routing that > bears no resemblance to the one I requested, and that routing always > went though rutgers. Since the path I specify is ignored, I can't > seem to avoid rutgers, either. Very frustrating. The situation > seems to arise when the site I want to mail to does not have an entry > in the maps, so the only way to get to it is to route through a site > to which it has a local connection. Well, simply put, rutgers is one of those places that runs a rerouting mailer. In general it works pretty well, and it's convienient dump just about any kind of garbage address on rutgers and have a 95%+ chance of it going somewhere useful. On the other hand I can see how some pathological cases could cause a lot of frustration. Of course, if your mail didn't include any paths through rutgers in the first place, there must be at least one other miscreant in the works. If you feel that rutgers is causing your problems, send some non-flamatory messages to rutgers!postmaster and see if you can bring Mel around to your way of thinking... -- George Robbins - now working for, uucp: {uunet|ihnp4|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
syd@dsinc.UUCP (Syd Weinstein) (03/14/88)
Cc:
Bcc:
I would also like to put in my $.02 on rerouting my mail. I have our
site repath mail from news replies, but I don't have it reroute mail.
However, almost every message we send out that is routed through
rutgers bounces back. (Currently in the last two months they are batting
85% bounced) Why, because rutgers reroutes it for us and
invariably it goes astray. Then I have to find by hand a path that
doesnt go through rutgers to route my message. (Not an easy task as
we are almost right next door to rutgers and they are a major backbone
site.)
I wish there was a way to tell rutgers in a message that I do not want
this path rerouted. Then they could reroute normal paths but not those
that I need either to test for connectivity or that I was told to use
by the sender or that rutgers bounced the first time.
--
=====================================================================
Sydney S. Weinstein, CDP, CCP
Datacomp Systems, Inc. Voice: (215) 947-9900
{allegra,bellcore,bpa,vu-vlsi}!dsinc!syd FAX: (215) 938-0235kennedy@tolerant.UUCP (Bill Kennedy) (03/17/88)
In article <3459@cbmvax.UUCP> grr@cbmvax.UUCP (George Robbins) writes: >In article <1642@uhccux.UUCP> lee@uhccux.UUCP (Greg Lee) writes: >> [ much complaining about rutgers... ] > [ explanation that rutgers reroutes ] >If you feel that rutgers is causing your problems, send some non-flamatory >messages to rutgers!postmaster and see if you can bring Mel around to >your way of thinking... I'll not repeat my feelings about this, they have been made clear. I would like to point out two things though. When rutgers agreed to be the internet forwarder for ssbn (my normal site) Mel made it quite clear what the rules were. I grumbled then, still do, but those are the rules and regardless of how often I'd like to brain them (rutgers) I'm lucky to have them as a neighbor site. Further, I have *never* had one bit of trouble getting into or out of the internet (unless there's a black hole that vacuums up bounced mail). The second point regards what problem to solve. If I am mistaken that we have tried to solve a news (long replies) problem in mail then maybe we should address it as a mail problem. There is an abundance of odd and special characters already in use but maybe one could be added that says "keep off the grass", i.e. don't re-route unless the first stop is not a neighbor site. I suggest tilde or one of the arrows. This would obviously have to be limited to "bang" addresses. I don't know what the impact would be on the sendmail community but smail would be no harder to cobble up than it is now for the @'s, %'s, et al. A companion capa- bility might be to surround an address in parens to mean "please route this". Before I implemented smail/pathalias I was delighted to have a neighbor figure out where something went. I don't think we are going to get very far convincing Mel, or anyone at rutgers who participated in the decision, to change. They are, after all, _THE_ source for the uucp maps and by definition if not default, should be expected to know who and where things are. Nor do I want to play down how angry I get when they ride roughshod over something that should have worked (I got an email note that the return rate on rutgers re-routes was a measured 85%...). I just don't think they are going to change to anything that isn't a marked improvement over what we have. Critique away at my feeble suggestions, let's get some minds working on solutions. When I get flaming drooling mad at rutgers for wrecking something I sent it helps me to remember that they had to relay the bounce as well, so the pain isn't uniquely mine. I have to get flaming drooling mad before I remember though :-). Let's change the tone and explore some alternatives. Maybe we can get Mel, Larry, and Mark involved as contributors who know what they are talking about. The opinions are strictly my own, Tolerant is nice enough to let me use their equipment, so don't blame them for me. Bill Kennedy {rutgers,cbosgd,killer}!ssbn!bill or bill@ssbn.WLK.COM
soley@ontenv.UUCP (Norman S. Soley) (03/17/88)
In article <11@tness7.UUCP>, mechjgh@tness7.UUCP (Greg Hackney ) writes: > About rerouting.... > One of our Vaxen is serving as a netnews feed to several > sites. It handles a lot of email replies to netnews articles, > most of which have very very long bang style return addresses. > The path that netnews takes, is hardly ever the shortest > path that pathalias would come up with. I've seen it routed > all over North America just to get to the machine next door. > > If most of the sites did rerouting, a lot of time and money > would be saved in my opinion. A lot more time and money would be saved if everybody used news compiled with INTERNET defined. Let's deal with the problem at it's source instead of applying a fix afterward. Unless we start generating pathalias made paths ourselves on the majority of what we send (i.e. replies to news articles) then we'll never convince anybody to lay off the occassional explicit path. Even if you can't run smail/pathalias yourself find yourself a site who will do it for you and use the internet define in the mailpaths file. I'm sure any site that is re-routing everything the see already won't care one way or the other. -- Norman Soley - Data Communications Analyst - Ontario Ministry of the Environment UUCP: utzoo!lsuc!ncrcan!---\ VOICE: +1 416 323 2623 {utzoo,utgpu}!sickkids!ontenv!norm ENVOY: N.SOLEY {mnetor,utgpu}!ontmoh/
page@swan.ulowell.edu (Bob Page) (03/18/88)
If you route through a site, you're at that site's whims to rewrite your paths, mung your From: addresses, and all kinds of other yuk. If you use pathalias and don't want to route to site 'foo', define it as dead (or at least avoid) in the pathalias command line. If you find other mailers that reroute to 'foo', avoid/dead them too. Don't go to somebody's house, hand them a fork, then call them anti-social because they don't hold their fork the way you do. If it matters that much to you, either don't go to their house or don't give them any forks. ..Bob PS Any UNIX fork analogy purely unintentional. -- Bob Page, U of Lowell CS Dept. page@swan.ulowell.edu ulowell!page "Nicaragua" is Spanish for "Vietnam."
jc@heart-of-gold (John M Chambers x7780 1E342) (03/19/88)
In article <410@ontenv.UUCP>, soley@ontenv.UUCP (Norman S. Soley) writes: > In article <11@tness7.UUCP>, mechjgh@tness7.UUCP (Greg Hackney ) writes: > > About rerouting.... > > > > If most of the sites did rerouting, a lot of time and money > > would be saved in my opinion. > > A lot more time and money would be saved if everybody used news > compiled with INTERNET defined. Let's deal with the problem at it's > source instead of applying a fix afterward. ... Well, I tried that on this machine, which has only SMTP connections, and a couple of fairly intelligent mail systems nearby. The result? EVERY response bounced back because of unknown hosts. Not even a single success that I could find. So I tried recompiling with INTERNET not defined. The result? Not a single failure since then that I've seen (and I should know, as Postmaster's mail gets forwarded to me). It's been said that something that works is preferable to something that fails. It's even more true that something that always works is preferable to something that always fails. (:-) In my experience, re-routing of explicit paths is the expensive choice. It replaces relatively cheap machine time with more expensive human time in handling all the failures. There's also the ill will it generates among the poor non-email-gurus that try using the system. That's the really expensive part. After a user has tried email a few times, and gotten half the messages back preceded by two pages of gobbledygook that include confusing error messages, most of them decide to go back to the bad old smail until email starts working better. It's often real hard to convince them that they should try again, especially when they try just one message, and it gets returned. Sigh.
rsalz@bbn.com (Rich Salz) (03/20/88)
>> A lot more time and money would be saved if everybody used news >> compiled with INTERNET defined. Let's deal with the problem at it's >Well, I tried that on this machine, which has only SMTP connections, and > [it didn't work] Not to be insulting, but I think your whole set up is suspect. Look at the from line you generate: From: jc@heart-of-gold (John M Chambers x7780 1E342) without any domain information this is a totally useless address. I would have sent this to you privately, but I obviously couldn't. I suppose I could have figured something out from the Organization and the path: Path: bbn.com!bbn!uwmcsd1!ig!agate!pasteur!ames!necntc!linus!heart-of-gold!jc Organization: Mitre Corp, Bedford, MA, USA but that's WRONG! In addition to being a gross waste of my time, there are (at least) two technical reasons against doing this. Why? Well, notice the first two hosts. They don't correspond to the Internet host names of the hosts involved: bbn is bbn.com, our gateway machine; bbn.com is any machine that gets an internal feed from this central star. Second, look at the two cross-country hops that are involved. What's that? You're not intimately familiar with all the hosts mentioned in the path? Sorry, that's the price you have to pay if you want to reliably reply along the Path line. >It's been said that something that works is preferable to something that >fails. It's even more true that something that always works is preferable >to something that always fails. (:-) Properly set up it works fine. Continuing the pithy quotes: If all you have is a hammer, everything looks like a nail. When all else fails, read the instructions. /r$ -- Please send comp.sources.unix-related mail to rsalz@uunet.uu.net.
jc@minya.UUCP (John Chambers) (03/21/88)
In article <532@fig.bbn.com>, rsalz@bbn.com (Rich Salz) writes: > >> A lot more time and money would be saved if everybody used news > >> compiled with INTERNET defined. Let's deal with the problem at it's > > >Well, I tried that on this machine, which has only SMTP connections, and > > [it didn't work] > > Not to be insulting, but I think your whole set up is suspect. I'm not insulted; I've suspected that for some time. With sendmail, I've learned that any setup is suspect. Most SAs I know admit to tweaking it until it works most of the time, and then LEAVE IT ALONE! Making it work takes a rather long time and much experimenting. Give me some more time, and maybe I'll get it right. Or I'll give up and find another wall to beat my head against. Or I'll install smail... > Look at the from line you generate: > From: jc@heart-of-gold (John M Chambers x7780 1E342) > without any domain information this is a totally useless address. Hey, you should have seen how the first few articles got labeled! Would you believe that Sun's sendmail defaults the domain to the Yellow Pages domain? Despite the fact that their manual staes quite clearly that YP domains are not related to mail domains? > I would have sent this to you privately, but I obviously couldn't. > I suppose I could have figured something out from the Organization and > the path: > Path: bbn.com!bbn!uwmcsd1!ig!agate!pasteur!ames!necntc!linus!heart-of-gold!jc > Organization: Mitre Corp, Bedford, MA, USA > but that's WRONG! In addition to being a gross waste of my time, there > are (at least) two technical reasons against doing this. Well, I got the article here on my home machine, so I went back and typed an 'R' command to vnews. It gave me the header: | To: adelie!necntc!linus!heart-of-gold!jc which is about as close to optimal as you could get. I looked at the article, and it could have used the "From " or the "Path:" lines to generate this. Granted, you got a longer path that wasn't quite as good. Responses to news ARE good candidates for autorouting. There is a bit of confusion at Mitre currently, over the proper use of domains. When internal politics clears up, you'll probably see a path from jc@heart-of-gold.mitre, but for the present, that's not a legal domain. Some machines there are foo.ARPA, but that's only legal for machines that are actually on the arpanet.... When the 'R' command gives me a very long path, I usually just tell vi to strip off most of it, up to a hostname that I recognize, or leaving the last 2 or 3. I converted my /bin/rmail to a script that first hands the mail to the /bin/rmail.real, and if that fails, bounces it to a nearby $SMARTHOST (adelie, in fact). So I get routing in that case. I don't find it much of a hassle; it's a lot less grief than is caused by all those smart routers causing my mail to bounce back. (:-) > >It's been said that something that works is preferable to something that > >fails. It's even more true that something that always works is preferable > >to something that always fails. (:-) > > Properly set up it works fine. Continuing the pithy quotes: > If all you have is a hammer, everything looks like a nail. Well, no, it doesn't. The trouble is that the IP host tables have grown so huge that not even linus can store all of them. The news at heart-of-gold comes via a real jumble of networks. My mail was getting bounced 3 or 4 levels of SMTP mailers, and none of them could identify the end machines or guess how to get the mail closer. Some of them (such as linus) are major email clearinghouses, and they couldn't help. Sigh. > When all else fails, read the instructions. Ya also gotta be smart enough to understand them. If email is to make it in the real world, it's gotta be within the capabilities of dummies like me. (:-) > Please send comp.sources.unix-related mail to rsalz@uunet.uu.net. Please send more related clever sayings to me. Especially if you have pairs that say opposite things! (:-) I've gotten bored with the standard Unix fortune file, so I wrote my own utility, and I need to initialize it. (Anyone want a copy?) -- John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393)
towfigh@phoenix.Princeton.EDU (Mark Towfigh) (03/22/88)
Since I know ZERO about the internal workings of mail, please do not
jump all over me if this is a dumb question. But here it is:
Since it is generally agreed that certain kinds of rerouting are
bad, why not have a mailer which reroutes mail by starting at the
right of the ! path, trying to connect to each host, until it gets a
direct connection, and then pass it on? At the very least it will
connect to the leftmost host, as the path should be correct.
Note that I am not assuming either an Internet or purely UUCP (=
telephone?) setup, at least I think I'm not; isn't it true that
Internet machines connect like telnet to send mail, and UUCP
machines call up a host?
It seems to me that this scheme circumvents the problem of automatic
re-routing through dead hosts, as the path is only improved if a
direct connection is found.
A second suggestion is perhaps a path-initial character ('#' for
example) could be defined to make a path re-reouting explicit (or
the other way, depending on which is preferable)? That way people
who KNOW their path can specify it, while others can hope for a path
speed up by autorouters.
I would be interested to see comments on these two schemes,
especially if I have overlooked some important detail.kennedy@tolerant.UUCP (Bill Kennedy) (03/23/88)
In article <2117@phoenix.Princeton.EDU> towfigh@phoenix.Princeton.EDU (Mark Towfigh) writes: >Since it is generally agreed that certain kinds of rerouting are >bad, why not have a mailer which reroutes mail by starting at the [ suggestions on what direction to parse path ] >the other way, depending on which is preferable)? That way people >who KNOW their path can specify it, while others can hope for a path >speed up by autorouters. As one of the louder whiners/screamers on this subject I have found a case where re-routing might be a big help (did *he* say that?). This, of course, presupposes that the volunteered path is a good one. If you are sending a mail message to a large list of addressees (I coordinate a large mailing list) and you are using smail, smail will pack as many addressees into an rmail event as will fit into the buffer size you specify at compile time. If you specify a bang path to the re-routing host and nothing else but the destination site and user you can fit more addressees into a single uucp file. The list rutgers!site1!user1 rutgers!site2!user2 ... turns into a uux command rmail site1!user1 site2!user2 ... whereas if you used an "@" path or somesuch your local smail would try to make a bang path out of it, undoubtably longer than site!user. This only applies (is useful) if the re-router is a very near neighbor with no "volunteers" in between and where the same piece of mail goes to many addressees. I have yelled enough about it where it's to a single addressee with a known-to-work path (I stand by all that yelling) so I thought it would be useful to cite a case where it's helpful. I think that Mark's proposal is OK but like a similar proposal I made a while back, I think it only applies to sites with the source to their mailer and I would guess they are in the minority. Further there would have to be some motivation/justification to dig into the mailer to put in the "new rules". In the interim it might be a worthwhile effort for each site to check their map again and make sure it accurately reflects their uucp connections. I suspect that some of the atrocities that rutgers has been accused of were the result of stale or inaccurate map data (even some of the ones that I accused them of :-) The opinions are my own, Tolerant is nice enough to let me use their equipment please don't blame them for me. Bill Kennedy {rutgers,cbosgd,ihnp4!petro}!ssbn!bill or bill@ssbn.WLK.COM
jbuck@epimass.EPI.COM (Joe Buck) (03/23/88)
In article <2117@phoenix.Princeton.EDU> towfigh@phoenix.Princeton.EDU (Mark Towfigh) writes: >Since it is generally agreed that certain kinds of rerouting are >bad, why not have a mailer which reroutes mail by starting at the >right of the ! path, trying to connect to each host, until it gets a >direct connection, and then pass it on? At the very least it will >connect to the leftmost host, as the path should be correct. This is the kind of routing that many of us think is very bad. It would work in a static UUCP network where every site always had the correct routing information. But sites go down and connections change. Even the UUCP project people's latest maps always contain errors (sometimes serious ones), simply because people don't always send in their updates right away. To get around these areas, we can use bang paths -- as long as bang paths are not munged with. A couple of years ago just about every "optimal" long-distance route went through ihnp4. Partly because of this enormous load, ihnp4 was sick a lot, and people connected with it would frequently post pleas not to route through ihnp4. But many users were unable to cooperate because "smart" mailers would change the paths to go through ihnp4 again, because that is the "optimal" route. Rerouting also makes the network untestable. It's no longer possible to verify that a connection is alive by sending a short message through a loop. One could ask the system administrator at a site, but it's amazing how many sites on the net are "on automatic", with no one left at the site who knows much about UUCP or news. "Well, Ralph set this all up but he doesn't work here any more." Correct bang paths ("correct" means that each site talks to the next one on the chain) should never be rerouted. As for news: define INTERNET, fix your mailpaths file, and you'll no longer have long paths to worry about. -- - Joe Buck {uunet,ucbvax,sun,<smart-site>}!epimass.epi.com!jbuck Old Internet mailers: jbuck%epimass.epi.com@uunet.uu.net
roberts@edsews.EDS.COM (Ted Roberts) (03/23/88)
In article <2117@phoenix.Princeton.EDU>, towfigh@phoenix.Princeton.EDU (Mark Towfigh) writes: > Since it is generally agreed that certain kinds of rerouting are > bad, why not have a mailer which reroutes mail by starting at the > right of the ! path, trying to connect to each host, until it gets a > direct connection, and then pass it on? At the very least it will > connect to the leftmost host, as the path should be correct. I don't claim to know all that much either, but a couple of problems with this approach did strike me. One example is that if you are trying to send to a site named (the infamous tut example) tut and had a path all laid out. Along the way you run into a site that talks to the tut in (I believe it was) Finland while the mail is actually directed to the tut in (I'm not sure about this one either) New Mexico. The path gets truncated, the mail goes to Finland, and somebody wonders what the heck keeps happening to their mail. > Note that I am not assuming either an Internet or purely UUCP (= > telephone?) setup, at least I think I'm not; isn't it true that > Internet machines connect like telnet to send mail, and UUCP > machines call up a host? Yes it's true. However this just makes things worse. Any local machines that you have could also screw up your mail paths. > A second suggestion is perhaps a path-initial character ('#' for > example) could be defined to make a path re-reouting explicit (or I believe this has been mentioned before and it seems to me to be a good idea. It would seem logical to me to use the character for those paths known to be correct so that re-routing would be the default. If some of the mail admins from sites that reroute are reading, maybe they could comment on this. -- Ted Roberts | My opinions are not necessarily those EDS Technical Services Division | of my employer. Does that mean I'm UUCP: roberts@edsews.EDS.COM | wrong?
jc@heart-of-gold (John M Chambers x7780 1E342) (03/25/88)
> I think that Mark's proposal is OK but like a similar proposal I made a > while back, I think it only applies to sites with the source to their > mailer and I would guess they are in the minority. Nah, you don't always need the source. If you are running uucp, it's pretty easy to do what I've often done: su # Always useful (;) mv /bin/rmail /bin/rmail.real vi /bin/rmail ... chmod +x /bin/rmail The script you put in to replace rmail gets the recipient(s) as args, and the message is on the standard input. You can do with these as you wish. I usually do something like: SMARTHOST=rutgers!seismo!ihnp4 # First, put the message into a named file. cat >/tmp/Mail$$ # Next, learn what we can about the recipients. echo 'To: "$* >/tmp/To.$$ grep '^To:" /tmp/Mail$$ >>/tmp/To.$$ ... [Assorted lookups and recipient-munging] [Leave list of recipients in $*] ... for r do # Try a list of mailers for each recipient. ... if [ $? -ne 0 ]; then # As a last resort, hand it back to uucp mail. /bin/rmail.real $r </tmp/Mail$$ fi if [ $? -ne 0 ]; then # Bounce failed mail to a smarter mailer. /bin/rmail.real $SMARTHOST!$r </tmp/Mail$$ fi if [ $? -ne 0 ]; then (echo "Can't deliver to "$r":"; cat /tmp/Mail$$) |mail Postmaster fi done rm /tmp/Mail$$ It's easy enough to make /bin/rmail into a general-purpose gateway between multiple mailers. You just hand each recipient to each mailer in turn. It's easy to include multiple database lookups, for instance. You'd think that the real hackers out there would love uucp mail, because it is so easy to modify it do do any of your favorite email tricks. Of course, if you have the source, it's even more fun... -- [Send flames; they keep it cool in this lab :-] Am I the same John Chambers as jc@minya? You decide.... Hint: That guy over at ut-sally is an imposter. (;-)
mechjgh@tness1.UUCP (Greg Hackney 214+464-2771) (04/04/88)
In article <4300@b-tech.UUCP> zeeff@b-tech.UUCP (Jon Zeeff) writes: > >Here are some quick hacks I did to smail 2.5 to "improve it". The authors >might want to consider something similar. >Add the following to the beginning of the resolve routine in resolve.c Thanks. A lot of people emailed that they preferred the rerouting of bang paths if the route was > 10 paths. I installed your mods. Now, how about a mod to tell smail to REROUTE a bang path if the path is no good. i.e. "mail foo!nobody" fails if I don't have a direct connection to foo. Or have I missed a feature? -- Greg "Opinions are like assholes, everybody has one."
zeeff@b-tech.UUCP (Jon Zeeff) (04/06/88)
In article <688@tness1.UUCP> mechjgh@tness1.UUCP (Greg Hackney) writes: >In article <4300@b-tech.UUCP> zeeff@b-tech.UUCP (Jon Zeeff) writes: > >Now, how about a mod to tell smail to REROUTE a bang path if >the path is no good. i.e. "mail foo!nobody" fails if I don't >have a direct connection to foo. > >Or have I missed a feature? I think you have (it works fine here). Do you have smart-host defined in /usr/lib/uucp/paths? --Jon -- Jon Zeeff Branch Technology, uunet!umix!b-tech!zeeff zeeff%b-tech.uucp@umix.cc.umich.edu
mikel@codas.att.com (Mikel Manitius) (04/08/88)
In article <4300@b-tech.UUCP> zeeff@b-tech.UUCP (Jon Zeeff) writes: > > Now, how about a mod to tell smail to REROUTE a bang path if > the path is no good. i.e. "mail foo!nobody" fails if I don't > have a direct connection to foo. smail [2.5] will already try to reroute any mail that failes uux if it hasn't been routed already. If the newly routed address still fails uux, then it will try to return the mail to the originiator. -- Mikel Manitius mikel@codas.att.com