Subject: Another reason for sender_agents

From: Mark Shewmaker <[email-masked]>
Date: Mon, 09 Aug 2004 09:48:20 -0400

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
[email-masked]