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
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
Return-path and rebuild the MAIL command as needed to
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
already contains a Return-path header. SMTP servers
relay function MUST NOT inspect the message data, and
to the extent needed to determine if Return-path headers
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
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
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.