Path: utzoo!attcan!uunet!deimos.cis.ksu.edu!mccall!tp From: tp@mccall.com Newsgroups: comp.mail.misc Subject: Re: is uunet breaking your headers? Message-ID: <2752.26638923@mccall.com> Date: 30 May 90 08:49:38 GMT References: <8955@gouda.quad.com> <13952@ucsd.Edu> Organization: The McCall Pattern Co., Manhattan, KS, USA Lines: 136 In article <13952@ucsd.Edu>, brian@ucsd.Edu (Brian Kantor) writes: > I don't know why I'm putting my foot into this one, but.... Me either... BTW, this isn't directed to Brian specifically. This is something that has bothered me for a long time, and I apologize in advance if I get a little hot about it sometimes, but it causes me major headaches. > Some uucp hosts, particularly those running sendmail, WILL update the > RFC822 "From: " line. Others don't, which means that the From: line > is of questionable integrity if the mail has ever passed through a uucp > link. The sendmail sites (and anyone foolish enough to emulate them) are wrong. Headers shouldn't be modified! This is according to RFC822. If you are using headers, they are probably rfc822 headers, and thus you should follow the rules that go with them. If you aren't using headers (i.e. you are pretending to be a dumb uucp site because that's what you think you are talking to), then you shouldn't touch them because they are part of the message. The only header used by "dumb" uucp sites is the "From " header, and that is the only one that should be modified. Since sendmail sites do muck with the header, I have to have extensive rewrite rules to clean up addresses so they are useable. I get unuseable From: lines because my neighboring site is a sendmail site. > Strictly speaking, an internet-compliant (i.e., it pays attention to > the From: line) mailer receiving mail from uucp should replace the From: > line with the From_ line (since the From: is unreliable), unless the From: > address is a valid domain-style address. You should never remove a From: header! You can add Received: lines, but you shouldn't touch the existing headers. If by internet-compliant you also mean rfc822 compliant, this is one of the rules of the game. If everybody would leave the From: line alone, it would be reliable (i.e. it would reliably be what the sender set it to). It is only next to useless because sendmail sites mung it into garbage. > Few sites do this yet. Thank God! I'm not sure how I'd EVER decode the result to a useable from address (perhaps this explains why one person here has had a great deal of trouble getting mail to or through the ucsd.edu domain). > So, because uucp requires PATHS of the form site!site!user, a > properly-operating internet-to-uucp gateway will transform a From: > address of the form user@domain to domain!user, preserving the domain > unless the domain is ".uucp", then prefix that with the gateway's uucp > address. Anything else would require the final destination of the mail > to be able to interpolate or translate addresses, and you simply can't > depend on that capability. NO! uucp does require paths. uucp also doesn't have the vaguest idea what a header line is. Even the "From " line is only so mailers can attempt to generate reply addresses. The path is the ENVELOPE of the message. Header info is NOT used for delivery. The only reason to mung a From: path is because you think it will somehow be easier for the recipient to reply to. If the from address is a bang path, it is probably inconvenient to use for any mailer that actually knows what a From: line is, since this would be an rfc822 mailer and would thus know about domains. A "dumb" mailer will use the "From " line to generate a return path. A smart mailer wants to see the domain name of the sender. Because sendmail screws this up, every smart mailer around has been modified to compensate for this by accepting bang paths, or rewriting them (usually be a set of rules that have to be hand-crafted for each site, and are never totally reliable). They are compensating for what is clearly a bug in sendmail, since by rfc822, the From: headers shouldn't be modified, ever. > Thus if the From: line is of the form > user@host.domain > (where 'domain' is NOT "uucp"), then transform the address to > gateway!host.domain!user > And that's what uunet (and ucsd, and decwrl, and lots of other gateways) > are doing. It's clearly the right thing to do by default. I disagree. My neighboring site is a sendmail site, and it took me a long time to get a set of rewrite rules that cleans up this trash about 95% of the time. I still get some of them wrong. Some examples. I have to deal with things like "user%site.something@host.domain" getting munged to "gateway!host.domain!site.something!user" or worse, "gateway!host.domain!user%site.something". The first of these might work as a bang path, but probably won't. It requires host.domain to support bang-paths, which is unlikely for any site that needs "%" to set up an address. If I try to get it back to a domain name, I get user@site.something which is wrong. The second is messier, but my rewrite rules can handle it (had to put in a whole bunch of things to deal with "%" to handle these. To make matters worse, there are usually a few more hosts at the front of the bang-path, depending on who first munged the header. Many uucp hops of a message are typically sendmail sites, and they all do this kind of munging, leading to real confusion. Some will even see the % sign in that last example above, treat it like an "@" (since there isn't one already), and generate "gate2!site.something!gateway!host.domain!user". I then try to reverse engineer this and get user@host.domain, which is wrong. This isn't useable as a bang-path either, obviously. Do you really think any of this is more useable than the original from line?! The basic problem here is there is not a clear model of what an internet-uucp gateway should be. Much of what Brian said would be true if you think of it as a gateway between an rfc822-compliant network and a non-rfc822-compliant network with certain characteristics, namely, that it supports rfc822 plus the "From " line, and that From: headers should contain bang-paths. I don't think this is the correct model. Rfc822 headers should be treated as rfc822 headers (for rfc822 mailers), or as message text (for dumb mailers that don't use headers). In either case, they shouldn't be modified, except for the possible addition of a Received: line. The "From " line should be there, and should be properly updated. A dumb mailer will use it. A smart mailer will ignore it if there are rfc822 headers (since it knows about domains, it can use an unmodified From: line), or use it if that's all there is. > Gateway sites which want to go to the trouble of also supporting uucp > "smart" hosts could have a way to leave the From lines alone, on the > declaration that the destination can handle it. But they shouldn't > DEFAULT that way. You imply by this that uucp smart hosts are the minority. Is this actually true? My mail software (DECUS uucp for VMS) acts as I have described. smail 2.whatever works as I have described (I used to run a unix machine). In fact, the docs for smail describe installing it "underneath" smail as the only known fix to the sendmail BUG that causes this behavior (it fixes it by keeping the message AWAY from sendmail). Note that NOT munging the From: line shouldn't ever cause a problem, since non-rfc822 mailers don't need it. -- Terry Poot The McCall Pattern Company (uucp: ...!rutgers!ksuvax1!mccall!tp) 615 McCall Road (800)255-2762, in KS (913)776-4041 Manhattan, KS 66502, USA