Getting back to the original thread topic, let's kick around the idea of
reverse source routing as way to get the current sender address without
adding an extra ESMTP parameter (RFROM/FRED/DAVE). I still can't think of
any compelling reasons against it, and there seem to be a number of reasons
in favor of it.
Here's a list for discussion:
Pro's
-----
1) Already exists in RFC2821. It is deprecated, but has MUST language that
forces recipients to tolerate it. It also has MUST language that prevents
use of the source route for determining outbound message routing.
2) Existing MTA's ignore it if they are RFC2821 compliant.
3) We don't need to create an additional ESMTP parameter or advertise it at
the beginning of the ESMTP session.
4) SPF will work with SMTP as well as ESMTP.
5) SPF rules get a little simpler: _always_ do an SPF check using the
leftmost entry in MAIL FROM:.
6) Converged SPF-CID flag day rules get a little simpler.
Before flag day: do an SPF check using the leftmost entry in MAIL FROM:, get
the recipient list, go on to DATA and extract the PRA. If (SPF result ==
PASS) and (PRA == leftmost entry in MAIL FROM:), accept the message.
Otherwise, if (PRA != leftmost entry in MAIL FROM:), do an SPF check using
PRA and if (SPF result == PASS), accept the message. Otherwise, reject the
message at the end of DATA.
After flag day: do an SPF check using the leftmost entry in MAIL FROM:. If
(SPF result != PASS), reject the message before DATA. If (SPF result ==
PASS), get the recipient list, go on to DATA and extract the PRA. If (PRA
== leftmost entry in MAIL FROM:), accept the message. Otherwise, reject the
message at the end of DATA.
Con's
-----
1) MAIL FROM: gets longer with each hop.
[Comment: Pretty minor, and mitigated by Stuart Gathman's suggestion that
forwarders COULD remove all intermediate routes and then add their own.]
2) We've already got preliminary agreement among the key parties for a
solution based on a new ESMTP parameter.
[Comment: Preliminary means just that. If this solution has advantages, it
shouldn't be that hard to get the key parties to go along.]
Neither Pro nor Con
-------------------
1) Starting from MTA code that supports neither SPF nor CID, it's probably
similar effort to prepend the source address to a source route list as it is
to add the new ESMTP parameter for outgoing messages.
[Comment: What do I know? I don't write MTA code.]
--
Seth Goodman