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