tinkelman@ccavax.camb.com (03/02/90)
I have a question about a sendmail.cf rule. But first the background. Recently I received mail from a friend at Digital who was using a new mail system. It arrived with an illegal return address, albeit one that I, as a human, could understand. It was <uunet!decwrl!koala.enet!mrgate::add::koala::x4::graff> meaning make uucp hops to uunet and decwrl, then DECnet mail-ll to koala, then through mrgate into the message router, then to node koala (aren't we already here?), to Message Router mailbox x4, to user graff. (Simple, huh?) Despite the fact I was 99% certain that those colons would cause problems somewhere, I decided to try replying, just to see what would happen. What happened was a rejection from decwrl: > ----- Transcript of session follows ----- > 550 <koala::mrgate..add..koala..x4..graff%decwrl.dec.com>... User unknown Surprise! uunet accepted the address with those colons, passed it on to decwrl, but changed the colons into periods. It really was uunet that had made the changes. In reply to my inquiry, the postmaster at uunet said that their sendmail.cf has scattered throughout it lines like # map colons to dots everywhere..... R$*:$* $1.$2 map colons to dots I'm not a sendmail.cf expert (and I certainly don't have uunet's entire sendmail.cf in front of me to look at). I'd assume that uunet knows what they're doing. Could someone please explain it? When would the above rule make sense? -- Bob Tinkelman, Cambridge Computer Associates, Inc., 212-425-5830 bob@ccavax.camb.com or ...!uunet!ccavax!bob -- Bob Tinkelman, Cambridge Computer Associates, Inc., 212-425-5830 bob@ccavax.camb.com or ...!uunet!ccavax!bob
michael@fts1.UUCP (Michael Richardson) (03/12/90)
In article <18538.25edbe1d@ccavax.camb.com> tinkelman@ccavax.camb.com writes: >I have a question about a sendmail.cf rule. But first the background. > >Recently I received mail from a friend at Digital who was using a new >mail system. It arrived with an illegal return address, albeit one that >I, as a human, could understand. It was > > <uunet!decwrl!koala.enet!mrgate::add::koala::x4::graff> I'd really like to know why uunet insists on playing with the the internal (not envelope) From: and To: at all! (Usually deleting the (name) portion of the From: so that I may have an address but no name to associate it with...) My machine has all the maps, I understand @ addresses. And so do all the machines from myself to uunet. This wouldn't be such a problem if every little bit of mail didn't go through uunet because of their screwed up `DEMAND' markings in their map entries. Do they really dial all these people? My solution is to to `pathalias -d uunet' On some entries it adds a hop, on many it actually removes a redundant hop through uunet. -- :!mcr!: Michael C. Richardson HOME: mcr@julie.UUCP SCHOOL: mcr@doe.carleton.ca WORK: michael@fts1.UUCP I never liked staying in one place too long, but this is getting silly...
amanda@mermaid.intercon.com (Amanda Walker) (03/13/90)
In article <155@fts1.UUCP>, michael@fts1.UUCP (Michael Richardson) writes: > I'd really like to know why uunet insists on playing with the the > internal (not envelope) From: and To: at all! (Usually deleting the > (name) portion of the From: so that I may have an address but no name > to associate it with...) As I understand it, uunet's sendmail.cf rewrites domain-style addresses into bang paths whenever it thinks it's talking to a site that only understands UUCP mail, whether that site in fact does or not. A while back I asked much the same question and they said, "Oh, we'll change you from UUCP to INTERNET" or some such. Since then, no more header munging. Perhaps some site along the way is mistakenly listed as UUCP-style... -- Amanda Walker InterCon Systems Corporation "Many of the truths we cling to depend greatly upon our own point of view." --Obi-Wan Kenobi in "Return of the Jedi"
argv%turnpike@Sun.COM (Dan Heller) (03/13/90)
In article <1990Mar13.022102.14408@intercon.com> amanda@mermaid.intercon.com (Amanda Walker) writes: > In article <155@fts1.UUCP>, michael@fts1.UUCP (Michael Richardson) writes: > > I'd really like to know why uunet insists on playing with the the > > internal (not envelope) From: and To: at all! (Usually deleting the > > (name) portion of the From: so that I may have an address but no name > > to associate it with...) > > As I understand it, uunet's sendmail.cf rewrites domain-style addresses into > bang paths whenever it thinks it's talking to a site that only understands > UUCP mail, whether that site in fact does or not. A while back I asked > much the same question and they said, "Oh, we'll change you from UUCP to > INTERNET" or some such. Since then, no more header munging. Perhaps some > site along the way is mistakenly listed as UUCP-style... there seems to be a lot of problems with uunet in this respect. For example, mail going thru uunet gets all bang paths stripped off. I tested this by having someone at a site that talks to both sun and uunet via uucp send me mail to dheller@monet.berkeley.edu. She added a return-receipt-to header as well. Lines got changed, but the two that "really mattered" for delivery purposes were From: and the return-reciept. They were changed to something like: From: uunet!user Return-Receipt-To: user@uunet.UU.NET I considered these important differently than the munging it did to the To: and return-* lines since the destination machine cannot return receipt reliably. The mail going thru sun got the entire path retained properly. [%] When I got my friend to configure the mail headers to use @-style domain paths, it worked by virtue of the fact that uunet didn't touch the headers. Granted this is "correct", but I don't think this has anything to do with why it does things "wrong" with the non-domain style paths. Who maintains the mail at uunet and if s/he reds this group(s) can there be a comment of rationale for this behavior? [%] Sun is poorly configured as well -- for example, it doesn't understand "uunet.uu.net", but it *does* undersatnd "uunet.UU.NET". I didn't know you could configure sendmail to be case sensitive... and why would you? dan ----------------------------------------------------------- O'Reilly && Associates argv@sun.com / argv@ora.com 632 Petaluma Ave, Sebastopol, CA 95472 800-338-NUTS, in CA: 800-533-NUTS, FAX 707-829-0104 Opinions expressed reflect those of the author only.