Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!uunet!pdn!tscs!tct!chip From: chip@tct.uucp (Chip Salzenberg) Newsgroups: comp.mail.misc Subject: Re: Which headers may Sendmail re-write? Message-ID: <27710AE7.1356@tct.uucp> Date: 20 Dec 90 19:03:02 GMT References: <1990Dec13.131236.25304@mp.cs.niu.edu> <276D0D6A.6581@tct.uucp> <1990Dec19.171943.18595@chinet.chi.il.us> Organization: Teltronics/TCT, Sarasota, FL Lines: 73 According to les@chinet.chi.il.us (Leslie Mikesell): >Actually, the original /bin/mail does not use anything in the >headers nor does it even require headers to be present. I knew the /bin/mailx story. Blaming /bin/mail was a thinko. Sorry. >The perverse systems that would be helped by munging are using >a version of mailx that attempts to generate replies using the >header From: but neither it nor the local transport understand >the things that are likely to appear there if you have a link >to systems bound by the requirements of RFC822. Yes, well, mailx is broken, isn't it? To my knowledge, the very existence of the From: header is an Internet (i.e. RFC822) invention. So a mailer that uses From: but can't deal with RFC822 is simply brain dead. More to the point, it is not a valid excuse for munging everyone else's headers. Before flaming me for this point of view, please remember that Mush and Elm are freely available and are good enough to be used as replacements for mailx. >I contend that the envelope return should be used by uucp sites >unless they are quite sure that the headers are always usable. Well, that's great, unless replies are to be routed according to a local paths database, like here. So we use Reply-To: and From:. Unfortunately, due to the header munging I decry, I found it necessary to add to Elm a "domainize" feature, which converts "x!y!z" to "z@y". I don't consider this Rabid Rerouting, incidentally, because it is done in the User Agent at user request. >>I contend that rewriting "user@host.valid.domain" into >>"host.valid.domain!user" in the *header* is a Bad Thing because: >> 1. Any people who are exchanging mail with Internet sites had >> better understand RFC822 addresses, if only in their minds, >> or else they're not going to have much success anyway. > >Not necessarily true. RFC976 style addressing works quite well >(path!domain!user) to connect non-RFC822 uucp sites to ones >that use domain addressing, as long as the relevant machines >handle that form correctly. Note that I said "people", not "mailers". The *people* at that site will see Usenet signatures that say "user@valid.domain", and they will eventually learn the meaning of that address form and will learn the local incantation for sending mail to such an address. So since people have to deal with domain addresses from signatures and business cards, I see no problem with asking them to do the same for addresses found in Reply-To: headers. >>In other words, a site's choice of mail transport should not affect >>the address format. > >Unfortunately that isn't the case, and I don't see anything that can >be done about it at this point. Forgive me, but I don't see that this statement has any supporting evidence. Surely it doesn't assert that a UUCP-based mail link is incapable of complying with RFC822? >In my case, smail 2.5 would not have sufficed, because it does not >pass NULL characters and I need a binary transparent transport. Sending non-ASCII in a mail message is just asking for trouble. And I don't mean only from UUCP mailers. -- Chip Salzenberg at Teltronics/TCT , "Please don't send me any more of yer scandalous email, Mr. Salzenberg..." -- Bruce Becker