[Top] [All Lists]

RFC2821bis-02 Issue 22: Requiring removal of extra return-path headers in 4.4

2007-04-20 09:25:26

Hi.  Issue 22 assigned to this.

Editor's note: My recollection of the DRUMS discussion is that
these suggests should be weak, rather than stronger, for two

(i) We wanted to generally discourage relay MTA from inspecting
message headers.  Requiring that they remove return-path headers
is implicitly a requirement that they inspect headers, which is
inconsistent with the design of other parts of the specification.

(ii) Regardless of what we specify, delivery MTAs must, in
practice, be prepared to receive messages with return-path
headers already in place and hence must be really to cope with
them.  Making these requirements stronger (MAY-> SHOULD,
SHOULD-> MUST) doesn't help much with that other than, possibly,
creating a false sense of security.  

The reasons for changing our minds about that are described


--On Wednesday, 18 April, 2007 14:10 -0700 SM <sm(_at_)resistor(_dot_)net>

In Section 4.4:

I suggest changing the MAY to SHOULD in the following

    It is sometimes difficult for an SMTP server to determine
whether or
    not it is making final delivery since forwarding or other
    may occur after the message is accepted for delivery.
    any further (forwarding, gateway, or relay) systems SHOULD
remove the
    Return-path and rebuild the MAIL command as needed to
ensure that
    exactly one such line appears in a delivered message.

I'm inclined to change the following SHOULD NOT to MUST NOT.
However a well-known MTA sends a message with a Return-path
header.  If the SMTP servers performing a relay function
cannot inspect the message data to determine if Return-path
headers are present, we can reach a situation where there is
more than one Return-path header.

    A message-originating SMTP system SHOULD NOT send a
message that
    already contains a Return-path header.  SMTP servers
performing a
    relay function MUST NOT inspect the message data, and
especially not
    to the extent needed to determine if Return-path headers
are present.
    SMTP servers making final delivery MAY remove Return-path
    before adding their own.

Quoting the draft:

    "The primary purpose of the Return-path is to designate
the address to
    which messages indicating non-delivery or other mail
system failures
    are to be sent."

This is best achieved by ensuring that there is only one
Return-path header.  I suggest changing the SHOULD to MUST in:

    For this to be unambiguous, exactly one return path
    MUST be present when the message is delivered.

I suggest changing the SHOULD to MUST in the following

    o  a gateway from elsewhere -> SMTP MUST delete any
       header present in the message, and either copy that
information to
       the SMTP envelope or combine it with information
present in the
       envelope of the other transport system to construct the
       path argument to the MAIL command in the SMTP envelope.

I did not suggest changing the SHOULD for "a gateway from SMTP
-> elsewhere" as there may be local considerations in the
destination environment which require it.