Xref: utzoo comp.mail.uucp:1571 comp.mail.headers:372 Path: utzoo!attcan!uunet!husc6!mailrus!ames!pasteur!ucbvax!decwrl!palo-alto!vixie From: vixie@palo-alto.DEC.COM (Paul Vixie) Newsgroups: comp.mail.uucp,comp.mail.headers Subject: Re: Real data to support my claim that '-d sun' is the way to go. Message-ID: <3721@palo-alto.DEC.COM> Date: 7 Aug 88 22:36:59 GMT References: <3703@palo-alto.DEC.COM> <10139@g.ms.uky.edu> Organization: DEC Western Research Lab Lines: 92 In article <10139@g.ms.uky.edu> david@ms.uky.edu (David Herron -- One of the vertebrae) writes: # In article <3703@palo-alto.DEC.COM> vixie@palo-alto.DEC.COM (Paul Vixie) writes: # >Return-Path: sun!pacbell!vixie!paul # >Subject: test, From: line in @ notation (From: paul@vixie.uu.net) # >From: Paul A Vixie # > # >--- # >This first one is replyable, though for a strange reason. decwrl would send # >it to "sun!" who would see "vixie.uu.net!" and say "ah, uunet.uu.net is the # >MX for *.uu.net, so I'll send it to uunet.uu.net who will deliver it # >further." The message didn't come through uunet to get to decwrl; why # >should it have to go back that way? # # Why are you surprised at this? Maybe you haven't read rfc976? Though # I'd be surprised if you hadn't. Anyway, this is a classic case of # garbage-in garbage-out. You told it to do something (i.e. that you're # part of the uu.net domain) so it's merely doing the right thing for # what it knows. Nope. If something comes in from the outside in user@dom.ain format, RFC82{1/2} says that the "dom.ain" part must be registered with the NIC. Therefore it makes no sense to rewrite into "sun!dom.ain!user" UNLESS THE MESSAGE IS GOING INSIDE SUN'S INTERNAL NETWORK and even then it's of questionable value. user@dom.ain is replayable on its own, I tell you! RFC82{1/2} _demands_ that it be replyable on its own. One could charitably assume that Sun.COM sees the bang-path in the "To:" or envelope recipient and decides that it is gatewaying between two different networks -- except that the message _came in_ from the same network it would be leaving on: UUCP. What's actually going on is that Sun.COM doesn't run IDA or any other variant of Sendmail that lets you rewrite the envelope differently than you rewrite the headers. They don't see this problem as important enough to justify the extra headache of not doing unto the "From:" line as they do to the "From_" line. Pfaa. I obviously disagree. I could almost make a case for them rewriting "vixie!paul" into "sun!vixie!paul" since the next site in the path might not know what "vixie!" means. But they could at least see if Sun.COM (itself!) knows what "vixie!" means, since they are _mandating_ that the reply come back through them. # >Return-Path: sun!pacbell!vixie!paul # >Subject: test, From: line in @ notation (From: paul@vixie.UUCP) # >From: Paul A Vixie # > # >--- # >This message is unreplyable. This is why I have "-d sun" in my makepaths # >script. I can't fault Sun.COM for rewriting u@h.UUCP to h!u since they # >mean the same thing; adding "sun!" to the front of the result is just # >plain wrong and there is no modern defense for the practice. # # If they are running a passive re-router then it would be replyable. # I do not know what they are running, but passive re-routing (to use # your terms) is simple to put up -- even under sendmail :-) -- and # does wonders for the usability of the system. True, _if_ they ran a passive router, the message would be replyable and I would not be bitching as loudly as I am. They don't. The message is not replyable -- "sun!" bounces it on the way back through. Note that running a passive router doesn't make it okay to rewrite headers that don't belong to you; it just makes the crime less heinous (sp?). The only time when the header sender or recipient can be correctly rewritten is when the message is crossing the boundary between one network and another -- and that is decidedly not the case here. # I agree that simply prepending sun! to a From: line is *wrong*. The implication is that rewriting into a homogenous form and adding one's host name in that form would be okay -- and it's not. That is, rewriting vixie!paul into sun!vixie!paul or paul@vixie.uucp into paul%vixie@sun.com is no better than rewriting vixie!paul into vixie!paul@sun or paul@vixie.uucp into sun!paul@vixie.uucp In _neither_ case is it okay to mess around with the header addresses AT ALL. They can do this if the message is bound for BITNET or the inside of their own network; they cannot do this when the message is passing from one Internet site to another with Sun.COM as simply an intermediary. The assumption is that if it comes in over UUCP or is going out over UUCP then it's not Internet traffic. This is false. UUCP is one of several common transport mediums over with Internet mail can flow. So by all means, do unto the envelope sender and recipient what you must do to make the message palatable to the medium it's going out over. But please leave the header sender and recipients alone! (Unless you're a gateway, as I said.) -- Paul Vixie Digital Equipment Corporation Work: vixie@dec.com Play: paul@vixie.UUCP Western Research Laboratory uunet!decwrl!vixie uunet!vixie!paul Palo Alto, California, USA +1 415 853 6600 +1 415 864 7013