--On Monday, 23 April, 2007 03:34 +0200 Frank Ellermann
<nobody(_at_)xyzzy(_dot_)claranet(_dot_)de> wrote:
Hector Santos wrote:
This changes CODE!!! My code!!
Pardon ? Users of a server using your code certainly expect
that there is precisely one Return-Path, reflecting the MAIL
FROM as seen by the final delivery MTA.
I'd bet that your code already does this, or do you keep crappy
Return-Paths inserted by prior hops in the header ? What would
users do with that, where "user" can be anything from a stupid
vacation script and other auto-responders up to gateways.
What does this have to to with SMTP?
SMTP specifies who, when. what, and how for the Return-Path.
In RFC 2822 you also find that there's at most one
Return-Path, not more.
...
Frank, Hector,
FWIW, let me give a different view of this issue, a view that is
consistent with 2821. For the purposes of this note, I'll
ignore both whether it is consistent with the current state of
2821bis or with various perceptions of today's changing reality.
Along the transport path, multiple Return-path headers may
happen and may happen regardless of whatever a standard says.
They may happen because someone misbehaves. They may happen
because something thought it was a final delivery server and
then ended up having to relay or gateway the mail because of
something that happened downstream ... and did so at a point
where the relevant code could not rescan the headers to be sure
that the previously-inserted Return-path header was removed.
In any of those cases, a receiving MUA, or the delivery system
immediately in front of it, has to be prepared to deal with a
header collection that contains more than one Return-path and to
figure out either
(i) how to ignore all but one of them or
(ii) to decide that a message with two (or more)
Return-paths in it is such a heinous situation that the
entire message should be immediately discarded without
comment. Even if one liked NDN messages, one can't
return one in this case because making a choice of where
to return it turns the case into (i).
I suggest to you that any real mail product that serves real
customers who can choose other products will make the first
choice --to figure out how to deliver the message if it can
possibly be delivered -- because it is generally the only choice
users will accept. It may decide to deliver it with several
demerit points for the excessive Return-path headers, or drop it
in a "possibly junk" folder, but it will deliver it. And, if
the user decides to accept and process the thing, the MUA, or
mail store, or delivery system will somehow figure out which
Return-path header(s) to ignore.
Now, I think that is the reality, regardless of what any
standard says. The implications of that reality are the reason
why 2821 says "you may take that out" rather than "you are
really, really, evil if you don't take it out". Even if the
latter were there, it would not guarantee the receiver that
multiple Return-paths would not show up. And, if the receiver
can't be guaranteed that, then it needs a coping strategy -- one
that might fall anywhere on the spectrum from "simplistic" to
"really clever heuristics".
In theory, one could assign "likelihood that a message is bogus"
scores on the basis on whether the standard say MAY, SHOULD NOT,
or MUST NOT. But in practice, for this sort of situation (many
others are different), that would be likely to be
non-productive. The dynamics of these situations change, the
"badness" of an extra Return-path header varies with context
(e.g., I'd be reluctant to get very excited about two of three
Return-path headers with exactly the same content) and the life
expectancy of a standard is just too long relative to changes in
bad guy (or sloppy implementation) behavior to provide good
guidance.
So while I'm happy to change the document in whatever way Tony
says there is consensus, I am having a lot of trouble seeing
what all the excitement is about.
regards,
john