On Fri, 21 May 1999 11:14:47 EDT, Nathan Brindle <[log in to unmask]> wrote: >My reading of RFC821 and 822 indicates that the mail server should not >even be looking at the RFC822 headers. Correct me if I'm wrong but the >SMTP envelope is supposed to be the only thing the mail server looks at. RFC821: The first step in the procedure is the MAIL command. The <reverse-path> contains the source mailbox. MAIL <SP> FROM:<reverse-path> <CRLF> This command tells the SMTP-receiver that a new mail transaction is starting and to reset all its state tables and buffers, including any recipients or mail data. It gives the reverse-path which can be used to report errors. Notice it says 'can be used to report errors', not 'must...' must has a special meaning in RFC syntax. But later on it is made seemingly clearer: MAIL (MAIL) This command is used to initiate a mail transaction in which the mail data is delivered to one or more mailboxes. The argument field contains a reverse-path. The reverse-path consists of an optional list of hosts and the sender mailbox. When the list of hosts is present, it is a "reverse" source route and indicates that the mail was relayed through each host on the list (the first host in the list was the most recent relay). This list is used as a source route to return non-delivery notices to the sender. And still later in RFC821 it is clearer still: When the receiver-SMTP makes the "final delivery" of a message it inserts at the beginning of the mail data a return path line. The return path line preserves the information in the <reverse-path> from the MAIL command. Here, final delivery means the message leaves the SMTP world. Normally, this would mean it has been delivered to the destination user, but in some cases it may be further processed and transmitted by another mail system. It is possible for the mailbox in the return path be different from the actual sender's mailbox, for example, if error responses are to be delivered to a special error handling mailbox rather than the message senders. The preceding two paragraphs imply that the final mail data will begin with a return path line, followed by one or more time stamp lines. These lines will be followed by the mail data header and body [2]. See Example 8. Special mention is needed of the response and further action required when the processing following the end of mail data indication is partially successful. This could arise if after accepting several recipients and the mail data, the receiver-SMTP finds that the mail data can be successfully delivered to some of the recipients, but it cannot be to others (for example, due to mailbox space allocation problems). In such a situation, the response to the DATA command must be an OK reply. But, the receiver-SMTP must compose and send an "undeliverable mail" notification message to the originator of the message. Either a single notification which lists all of the recipients that failed to get the message, or separate notification messages must be sent for each failed recipient (see Example 7). All undeliverable mail notification messages are sent using the MAIL command (even if they result from processing a SEND, SOML, or SAML command). However, RFC822 complicates matters: 4.4.4. AUTOMATIC USE OF FROM / SENDER / REPLY-TO For systems which automatically generate address lists for replies to messages, the following recommendations are made: o The "Sender" field mailbox should be sent notices of any problems in transport or delivery of the original messages. If there is no "Sender" field, then the "From" field mailbox should be used. My thoughts are these. It seems clear from RFC821 that the message "data" (which includes the RFC822 headers) is never to be consulted in handling of undeliverable errors. i.e. the 'data' is simply a closed black-box that is being transported. However, RFC821 allows that once the 'data' reaches a 'final delivery point' it leaves the SMTP world and my enter a private mail system where other rules may well apply. Indeed this is exactly the case with systems like cc:mail (which is designed not to use the RFC821 MAIL FROM:<address> to report errors). Inside this system, only the RFC822 headers are available (in cc:mail, even the Return-Path: RFC821/RFC822 "crossover" header is not available to the mail system). Clearly this is an inadequacy with cc:mail in that the From: or Sender: may well be the correct error reporting address to use for mail originating and staying entirely within the cc:mail system. But (SMTP) mail which enters the system via a gateway, needs to have errors reported back out the same gateway, but in a manner consistent with the external (SMTP) practices. This is where cc:mail (and some other proprietary systems) fails. It applies its internal rule (uses Sender: address) to the errors reported back out to SMTP. For LISTSERV lists, the Sender: field is frequently set to the List-Address, so what is really an error message report is sent back to the list as an attempted posting! Fortunately LISTSERV is able to detect and trap this kind of message because of certain internal content headers and divert it to the List Owner as a possible error.