Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!giza.cis.ohio-state.edu!karl From: karl@giza.cis.ohio-state.edu (Karl Kleinpaste) Newsgroups: comp.mail.uucp Subject: Re: Vicious rewriting of From: lines Message-ID: Date: 10 Dec 89 04:35:23 GMT References: <1107891037263761@thelake.UUCP> Sender: news@tut.cis.ohio-state.edu Organization: OSU Lines: 87 In-reply-to: steve@thelake.uucp's message of 7 Dec 89 16:37:26 GMT Oh, my. What an opportunity. Yet another Domain Absolutism argument. steve@thelake.uucp writes: Based on John Chew's "Inter-Network Mail Guide," I recently tried to send a note to someone whose only e-mail address is on Compuserve. BOING! ... To: 73607.1231@compuserve.com From: steve@thelake.UUCP (Steve Yelvington) Reply-To: pwcs.StPaul.GOV!stag!thelake!steve ... >>> RCPT To:<73607.1231@uccba.uc.edu> <<< 550 <73607.1231@uccba.uc.edu>... User unknown: Not a typewriter 550 ... User unknown This part isn't my fault. That specific problem is apparently caused by a mailer at (I'm guessing here, partially) uccba or CWRU, where it somehow magically strips one item out of a !-path. We have a user here who has acquaintances at Amdahl, who were trying to reach this local person via username@cis.ohio-state.edu; they got bounces back because, by the time the mail got to here, it no longer contained any reference to Ohio State in the RCPT TO:. Something similar happened in your case. I can't explain it in detail, but it's certain that it only affects shrieky addresses (!-paths) by mis-stripping something out of them, apparently the last hostname in the shriek. Putting on my sendmail.cf debugger's hat for a moment, methinks I detect a mistyped digit in a sendmail.cf RHS, e.g., someone's $1 should have been $2, or something like that. [returned mail reads:] To: 73607.1231@compuserve.com From: steve@cis.ohio-state.edu (Steve Yelvington) Reply-To: wuarchive!swbatl!pwcs!stag!thelake!steve@mailrus.cc.umich.edu This is the first time I've been teleported to Ohio State. This one _appears_to_be_ my fault; more precisely, it's your own fault, because you apparently let it escape your system looking like "From: steve@thelake" without even ".uucp" attached, much less a real domain. We are probably going to get into a religious war here, but my side of the issue reads directly from the scriptures. RFC822, section 6.2.2., "Abbreviated Domain Specification," page 29-30, reads: When a message crosses a domain boundary, all addresses must be specified in the full format, ending with the top-level name-domain in the right-most field. It is the responsibility of mail forwarding services to ensure that addresses conform with this requirement. My sendmail configuration believes in 6.2.2 deep in its heart. The interpretation of this comment from 6.2.2 is that if you send mail which passes my way which claims to be "From: user@OneWordHostName," I'm going to commit a rudeness against it. OneWordHostNames seen outside their domain of origin are a violation of the requirement to "specif[y] in the full format," that is, you didn't supply a fully-qualified domain name (FQDN) in your From: line. Two things cause this: It is a matter of local policy that mail coming from here hides the individual hostname in favor of just the domain name, so if someone tries to specify user@SomeWorkstation, it gets rewritten as user@cis.ohio-state.edu and delivered locally; and there is no way for me to determine in what context I should interpret any OneWordHostName except as part of cis.ohio-state.edu. Please note that this occurs _only_ for user@OneWordHostName. If you're _certain_ that it left your site as "steve@thelake.uucp," then I suggest that someone else mangled it into "steve@thelake" before it got this far. I leave ".uucp" and ".bitnet" domains alone, because such hostnames qualify as FQDNs in a syntactic sense, even if the domains themselves are formally invalid, semantically. I went a few rounds on this topic around October or so regarding Pete Holzmann's machine "octopus." There is (or was) a machine octopus.cis.ohio-state.edu, and mail was coming from Pete's machine as "user@octopus" without domain qualifiers. I hope it's obvious as to the nature of the conflict this creates, and hence why 6.2.2 contains this requirement. The bottom line is: Advertise RFC-conformant addresses in your From: line in the first place, and I will happily leave it unmolested; hand me something RFC-invalid, and I'll make my own personal best guess as to how to return to RFC conformance, and you're bound to lose in the process. --Karl Kleinpaste Personification of the Mailer Daemon Ohio State Computer Science