On Thu, 15 Sep 2005, Dick St.Peters wrote:
[1] Aside to Frank: I believe this "end-to-end" notion is implicit in
existing RFCs, something like construction of reverse paths by moving
elements from forward path to reverse path => reverse (and forward)
source routes being collapsed to direct connection => one-hop
MAILFROMs => end-to-end MAILFROMs ... => SRS reintroducing indirect
reverse paths. That last step is the origin of my comment that I feel
my using SRS violates RFCs. I use it because only the letter of the
RFCs is violated, not the spirit - meaning DSNs still make it back to
the original MAILFROM.
I agree with your analysis. However, you are not really even
breaking the letter of your exposition of the RFCs.
Since the parties you forward mail to have (explicitly or implicitly)
authorized you to forward them mail, you have become a gateway
for their mail domain.
If the recipient has secondary MX servers, their SPF setup had better
be able to skip SPF checking for mail from those secondary MX servers.
(A lot of spf-help cases are where receivers check SPF on connections
from their secondaries!) In the same way, the SPF setup had better
be able to skip SPF checking for other gateways - like (authorized)
alias forwarders. When a recipient checks SPF for an alias
forwarder, that is just as broken as checking it for a secondary MX.
An alias forwarder in effect *is* a secondary MX - it is just
listed as part of another domain.
When you implement SRS to work around braindead recipient MTAs,
that is an internal protocol between you and the recipient - because
you are a gateway for their email "kingdom" (administrative domain).
You and the next recipient could use web services, UUCP, or any
protocol you agree upon (including SMTP). It doesn't matter, because once the
email is delivered to the original recipient, the email RFCs are
fulfilled, and anything that happens to the mail from that point
is internal processing. You are following the RFCs to the letter,
because when there is a problem, you send the DSN to original MAILFROM,
just as required. The sender never sees (and shouldn't see) the
SRS hack.
Granted, it would be nice if the domains using your forwarding
service didn't need the SRS hack. Then the DSNs would arrive faster.
A mail network where DSNs are required to emerge from the same MTA
that the original message entered is likely to be less efficient
that one where DSNs can emerge from any available MTA. But that
is an internal implementation detail between you and your
forwarding clients.
--
Stuart D. Gathman <stuart(_at_)bmsi(_dot_)com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com