Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!elroy.jpl.nasa.gov!decwrl!pa.dec.com!hollie.rdg.dec.com!jch From: jch@hollie.rdg.dec.com (John Haxby) Newsgroups: comp.mail.sendmail Subject: Re: Use of Errors-To: Message-ID: <1991Mar7.083945.7053@hollie.rdg.dec.com> Date: 7 Mar 91 08:39:45 GMT References: <88419@sgi.sgi.com> <1991Mar2.212126.3567@cs.utk.edu> <1991Mar7.012743.12895@phri.nyu.edu> Sender: news@hollie.rdg.dec.com (Mr News) Reply-To: jch@hollie.rdg.dec.com (John Haxby) Organization: Digital Equipment Corporation Lines: 58 In article <1991Mar7.012743.12895@phri.nyu.edu>, roy@phri.nyu.edu (Roy Smith) writes: |> lear@turbo.bio.net (Eliot) writes: |> > You're wrong. See RFC 1123 section 5.3.3. Errors go to the sender, AS |> > SPECIFIED IN THE ENVELOPE. They SHOULD NOT go to any address based on |> > header information. |> |> Can somebody explain to me the reason they made it this way? It |> seems counter-intuitive to "hide" information in the envelope, when the |> headers are a perfectly reasonable place to put everything you need to know. That's not a trivial question. To begin with, the content is (more-or-less) hidden from the envelope, not the other way around. When you send a message through the paper postal system, the content can't see the envelope because it is inside it, and vice versa. Similarly, the return address that you write on the outside of the envelope is the one that the letter will go back to when your ex- marks it "return to sender" (you may burst into song, if you must :-) The way the physical postal system works is hardly a justification, but it provides some history. However, history is important because mail systems based around non-IDA sendmail treat the envelope and content almost identically. However, IDA-based sendmail systems and other mail systems (the ones I know of) *do* treat the envelope and content differently. Specifically, the return address (MAIL FROM:<...>) on the envelope is modified to reflect the message's path across the continent; the idea being that any rejection will follow a guaranteed path to the originator, that is, back the way it came. Addresses on the content, however, are supposed to be nice and readable, they are also supposed to work, but may not for strange reasons. If I think about this long enough, I can think of all sorts of other reasons why the content and envelope should be different. For an example, consider UUCP-style routing. The trouble with this is that you wind up with very long return addresses, I'm sure you've seen examples. The snag with these long return addresses is that, whilst they almost always work, they are equally almost always inefficient and whilst they will probably work for the next few days, they may not work a few weeks or few months hence because machine connectivity changes. The usual policy here is to knock off leading components of the route until you get to the last known host. If you then try to use this as an address to send errors to, you can come badly unstuck because, for example, the (different) route that you choose to send the return address to may not be available for a few days. There is this possibility when you send a message back along the route it came, but, typically, the error is winging its way back within a few hours or a few minutes of the original optimistically winging its way out. With all that to think about, the short and snappy answer is that the envelope sender address is more reliable than the header sender address for the purposes of error messages. The other answer, which I haven't mentioned, that other mail systems may give, is that the envelope sender address is validated whereas the content header sender address isn't (I don't believe this for sendmail-based mail systems and, to a lesser extent, for SMTP/RFC822-based mail systems). -- John Haxby, Definitively Wrong. Digital Reading, England <...!ukc!wessex!jch>