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
reasons:
(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
below.
john
--On Wednesday, 18 April, 2007 14:10 -0700 SM <sm(_at_)resistor(_dot_)net>
wrote:
In Section 4.4:
I suggest changing the MAY to SHOULD in the following
paragraph:
It is sometimes difficult for an SMTP server to determine
whether or
not it is making final delivery since forwarding or other
operations
may occur after the message is accepted for delivery.
Consequently,
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
headers
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
paragraph:
o a gateway from elsewhere -> SMTP MUST delete any
Return-path
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
reverse
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.
Regards,
-sm