Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!pt.cs.cmu.edu!andrew.cmu.edu!cfe+ From: cfe+@andrew.cmu.edu (Craig F. Everhart) Newsgroups: comp.mail.misc Subject: Re: Replying to mail... is there a general theory? Message-ID: Date: 13 Jul 89 15:34:08 GMT References: <3483@portia.Stanford.EDU> <207@unmvax.unm.edu>, <3724@ogccse.ogc.edu> Organization: Information Technology Center, Carnegie Mellon, Pittsburgh, PA Lines: 27 In-Reply-To: <3724@ogccse.ogc.edu> There are two classes of reply: error bounces and human-like replies. There are different rules for each class. For human-like replies, follow RFC822 and use Reply-to: if it exists, or From:. Do NOT fall back on Sender: or Return-path: or From_. Remember, what's happening here is that a human is supposed to really be doing the addressing, and a user-agent program is simply offering an assist. If the user-agent program can't find the proper header to suggest as the default answer, then it shouldn't be guessing on substandard information. The user can do that guessing once the UA program has announced that the correct headers aren't there. (Variation: you can also use the Resent-Reply-to: (falling back on Resent-From:) information, possibly for a different class of reply. Still other classes of replies might also include the To:/CC:/Resent-To:/Resent-CC: addresses.) For error bounces, there's an independent collection of hair. In a pure RFC822 world, you'd use the Sender: address, falling back on From: should Sender: not exist. As implemented in the RFC821 world (using SMTP), you'd use the ``envelope From'' information, which comes across as the argument to SMTP's ``MAIL FROM:'' command. This information is supposed to be recorded in the Return-path: field when a message is finally delivered; depending where the rejection happens, it may be before final delivery occurs. I believe that the comparable information is recorded in From_ lines in UUCP-land, but I'm a UUCP-mail novice. Craig Everhart