Summary: Putting sender_agents into the spec would allow for
the classic SPF and updated Sender-ID tests to separately
authenticate the one (and different) thing they each
authenticate, and authenticate that one thing well.
Whether an incoming email has a forged bounce address is a different
question from whether it has body forged header information.
SPF classic with SRS gave recipients a pre-DATA test for forged bounce
addresses, but SPF classic with SPF by itself gives recipients no tests
for forged header info.
Sender-ID gives recipients a post-DATA test(1) for some forged header
info, but Sender-ID by itself gives recipients no way to test for forged
bounce addresses.(2)
These two tests test for different things--why not do both?
1. If we do classic SPF tests, (and do SRS on forwarding and
SES/BATV-at-source), then:
A. Recipients can know when they can safely bounce messages,
and reject those that fail SPF tests.
B. Senders can implement SES/BATV on all their new outgoing
messages, so that they will never be a victim of receiving
bounce forgeries directed at their domain. (Other than
from denial-of-service types of attacks.)
So both senders and recipients have ways to avoid being victims
of forged bounces. (At least when the return-path domain
participates.)
2. Then if sender_agents is added to Sender-ID and we do Sender-ID
tests on the body headers, we'll have solved the phishing problem,
(among domains who care to participate, at least.)
--> But you *have* to have something like sender_agents, (or digital
--> signatures) to do this sort of full anti-phishing test.
With the above mindset, we're doing SPF tests to authenticate the
return-path, and Sender-ID-with-sender-agents tests to authenticate the
forwarding-hop-path.(4)
We can do the SPF test before DATA, but since we can't do the complete
Sender-ID tests until after DATA anyway, a SUBMITTER "sneak peak"
doesn't isn't really needed--we could simply get rid of SUBMITTER
altogether(3), and Sender-ID-looking-in-the-headers will still continue
to work fine.
Using SRS for classic-spf checks doesn't require a change in the SMTP
protocol, or a new keyword to be added to the protocol, nor is a
layer-violation, as it were, between 2821 and 2822.
IMHO, this is a much cleaner solution than trying to get one or the
other of those two types of tests to test both types of things.
But you need sender_agents to do the end-to-end anti-phishing test.
Notes:
(1) Even with SUBMITTER, you have to wait until after DATA to see if
SUBMITTER really matched up with the PRA.
(2) With both classic SPF and Sender-ID, *Senders* can use SES,
(or BATV) to prevent forged bounces from reaching *them*. That's
all fine and good (and I've long been for it), but it still
requires *recipients* to do a callback-verification test, which
takes a lot longer than SPF classic type tests.
(3) If you still want SUBMITTER for other reasons, there's no need to
get rid of it--but there's no need to *require* it for Sender-ID
or have flag days or the like.
--
Mark Shewmaker
mark(_at_)primefactor(_dot_)com