From: Greg Connor
Sent: Monday, June 07, 2004 1:22 AM
Hi Michael (and spf team),
Thanks for the summary. Here are a couple of additional items to
consider adding or changing.
<...>
RSR uses a deprecated syntax. Source routes are declared no longer
supported by a more recent RFC. Since it has been mothballed, and many
many MTAs don't support it, I would say that putting RSR back into active
use amounts to a change in SMTP. You would need an RFC to do so,
or else a
force stronger than RFCs that causes people to update MTAs.
Therefore RSR has about the same problem as SUBMITTER in that regard,
except that SUBMITTER is optional for NewSPF+PRA, not required, whereas
OldSPF+RSR requires global adoption of RSR before we can turn off
trustedforwarders.org.
I generally agree with Greg's post, but I have a comment on the above. RSR
and SUBMITTER are just two different ways of transmitting current sender
information in MAIL FROM:. Greg's comments above compare
NewSPF+PRA+SUBMITTER to OldSPF+RSR. This isn't really a good comparison
since RSR is merely an alternative for SUBMITTER. You _could_ consider the
old SPF + RSR, but that combination is inferior to the new SPF + RSR and
thus not worth keeping in the table, IMHO. I think a more useful comparison
is NewSPF(w/PRA)+SUBMITTER vs. NewSPF(w/PRA)+RSR. This is a better way to
contrast the two approaches from each other and from the other forwarding
methods presented. To keep things more compact, perhaps you could just note
that the new SPF includes PRA extraction and uses that for the SPF check
when no current sender information is available before DATA.
Using the above assumption and comparing NewSPF+SUBMITTER to NewSPF+RSR, the
same current sender information is transmitted in MAIL FROM:, only the
syntax is different. It is an important implementation detail, but that's
the only difference. Both allow fallback to the PRA extraction from the
headers. Both use the current sender information in MAIL FROM:, when
available, to permit rejection before DATA. Both require forwarders to
create the headers they should have been creating all along before it is
safe to turn off trustedforwarders.org. Forwarders would not be required to
implement SUBMITTER nor RSR, though it is strongly encouraged in order to
save everyone's bandwidth.
As Greg pointed out, if enough forwarders implement the current sender
information in MAIL FROM:, we can switch over to always doing the SPF check
on MAIL FROM: and just use the PRA as an additional after-DATA test. Until
that happens, we can use PRA from the headers and reject at the end of DATA.
While I don't personally like that, it does keep the mail flowing and makes
a gradual transition feasible, which is a plus point for the new SPF.
--
Seth Goodman