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.