On Tue, Jul 13, 2004 at 10:04:17AM -0700, Jonathan Gardner wrote:
|
| The IETF MARID working group has decided to not adopt XML anywhere in the
| standard. They are currently working out the last few details, but what I
| see, it looks like SPF will be adopted and published as an IETF standard
| virtually unchanged. Therefore, a large chunk of Sender ID has been
| abandoned, and Sender ID is virtually no longer relevant. Only SPF and a
| few other similar protocols and procedures are being discussed.
Well, the big difference between SPF Classic and Sender ID
is that Sender ID does the check against the PRA from the
headers, which is (thanks to SUBMITTER) available at 2821
time, before DATA. SPF Classic does the check against the
MAIL FROM. The reason for focusing on PRA scope was because
of the perception that phishing is a big problem.
Here's the SenderID algorithm in a nutshell, presented as a
normative use case. If you look carefully, you'll see that
99% of what we wanted to accomplish with SPF Classic
survives. (... if a few key assumptions are met.)
The SUBMITTER trick is only used in forwarding situations.
If it is absent, you get to use the MAIL FROM value.
1) we assume a receiver MTA supports ESMTP SUBMITTER.
2) we assume that the receiving end-user has made known to
his receiver the list of addresses which forward to him.
3) If a sender offers MAIL FROM:<...> SUBMITTER=<submitter>,
you see if the submitter is in your whitelist. If it is
not, you reject. If it is, you run the spf_test against
it. If it passes, you accept. If it does anything but
pass --- even if the result is "neutral" or "unknown" ---
you reject. You get to do this because you expect any
sending MTA that provides SUBMITTER to publish SPF
records for itself. If it didn't publish SPF, there'd be
no point in providing SUBMITTER. This is a *stronger*
statement than SPF Classic allows you to make.
4) If a sender offers only MAIL FROM:<return-path>, with no
SUBMITTER, you test the return-path. If it fails, you
reject. If it passes, you make your local policy
decision on the basis of your reputation system,
whitelist, what-have-you.
If (2) does not hold --- if a receiver mail system has no
way to offer per-user whitelisting of sender addresses ---
then you can substitute a distributed reputation system that
knows whether a given SUBMITTER is likely to be a legitimate
forwarder or not. Trusted-forwarder.org can serve this purpose.
The above argument treats only with pre-DATA envelope information.
The reason I say that Sender ID accomplishes the goals of
SPF is because I expect SUBMITTER to not be present except
in forwarding situations. When it is not present, you can
use MAIL FROM. And you get the bounce protection that SPF
Classic was designed to provide in the first place.
So really Sender ID, during envelope time, is pretty much
the same thing as SPF Classic, except you get an additional
parameter to work with, and that parameter is required to
return a PASS. That parameter is also subject to
whitelisting --- if it isn't on your whitelist you can dump
it, even if the auth result is a pass.
Once you get into the headers, you apply the PRA algorithm.
We expect the next generation of MUAs to display some sort
of "green light" when the PRA algorithm works.
cheers
meng