When working on an algorithm on what will need to be checked and what can
override what else in Unified SPF there are number of issues to consider
and addressing them requires certain design and review process which has
so far not been done in correct technical form.
1. First of all we need to look at each identity separately and decide if
it is possible in current email world for every legitimate emailer to
be compliant with requirements for that identify verification. An
identity that everyone (except spammers about who I really don't care
much about) can be compliant with should be REQUIRED for checking under
Unified SPF. Of these identities, the identity that is more likely to
be abused should be checked first (more likely chance of early
detection of bad mail).
2. Then we have identities where not every legitimate sender can be compliant
with. In that case we need to look at situations where this non-compliance
exists and see which other identites can one expect to be positively
verified at the same time. The question that has to be considered
most carefully is if overriding this identity with positive results
of other identities opens a hole in authentication system - so
overriding MUST NOT be made easy.
-----------------------------------------------------------------------------
SPF Identity | Possibility of Compliance
-----------------------------------------------------------------------------
SPF2.0/HELO | All normal systems can comply
SPF2.0/PTR | Most can comply except situations with "uncooperative" ISP
SPF2.0/MFROM | ReturnPath identity verification fails with most forwarders
SPF2.0/SUBMIT | All normal systems can comply.
-----------------------------------------------------------------------------
I have left DomainKeys and email siging out of it, but I'll note for the
record that DomainKeys will fail with all mail lists as well as few other
cases of forwarding. There are of course email siging proposals that are
desigined not to have their signature fail in such cases, but this is all
off-topic to SPF as SPF aimes to verify email during SMTP session and
email siging verification requires verification after DATA and is also a
lot more CPU consuming operation (that means verification of all email
signatures should ALWAYS come last in any unified scheme).
As far as 4 identities I listed above, EHLO is the one that is safe to
check on (all systems can comply if they want) and is more often to be
forged then non-existant SUBMITTER, so it'll have to be the one to be
chekced first.
Next one is SUBMITTER extension to MAIL as in either marid-submitter or
leibzon-responsible-submitter drafts (marid-submitter makes SUBMITTER
be the same as PRA while leibzon-responsible-submitter views it as purely
RFC2821 identity, but otherwise its the same). The new responsible email
address is added by systems that changed email direction so I'm prepared
to argue that unlike MFROM, this should never really fail if properly
used. That means it is safe to make it REQUIRED check right after HELO.
Next comes Mail-From which is what SPF Classic is all about and what most
on this list seems most interested in. As I noted, it fails with forwarders
and people want a way out of this situation to be able to whitelist every
forwarder. The proposal to allow MAIL-From through if either HELO or
SUBMITTER check is ok is unfortunetly not sufficiently bullet-proof, it is
simply too easy for bad guy to just use some other domain that he controls
(maybe a through-away domain that is immediatly given up) to bypass this
kind of setup. Besides that as you quickly would note the HELO and SUBMITTER
should verify no matter what mail-from does so making mail-from dependent
on buys you nothing.
The other available identity is PTR. The interesting part is that for bad
guys its actually a lot harder to get forged PTR name then it is with HELO
domains. First of many of them use zombie computers whose PTRs are not
under their control. For those situations where it is under their control,
we end-up with their ip block rather then through-away domain and ips are
a lot easier to block against using existing RBL system. On the other hand
legitimate forwarding system would be able to get his ISP to setup correct
PTR record (and if they run forwardedr on consumer-grade dsl I would not
trust such a forwarding system; but as far as I know all forwarding
systems do in fact reside on dedicated business lines from ISP or on
dedicated servers).
Now going back to PTR, as noted in some cases with consumer end-user lines
ISPs are not very good at setting PTR to what that end-user wants. Some
want to override that with simple EHLO - that may work but I already noted
that EHLO is supposed to be correct either way. PTR is actually more
usefull to see if it maybe zombie machine so I think overriding it should
require more then just simple EHLO, I think having MAIL-FROM being correct
would be ok as far as not making PTR check necessary.
So in the end I see list of checks as following:
-----------------------------------------------------------------
Step | SPF Identity | Result of verification
-----+---------------+-------------------------------------------
1 | SPF2.0/HELO | If Fail -> reject, otherwise go to 2
2 | SPF2.0/SUBMIT | If Fail -> reject, otherwise go to 3
3 | SPF2.0/MFROM | if Pass -> accept email, otherwise go to 4
4 | SPF2.0/PTR | If Fail and #1 was not Pass -> reject
-----------------------------------------------------------------
---
William Leibzon, Elan Networks:
mailto: william(_at_)elan(_dot_)net
Anti-Spam and Email Security Research Worksite:
http://www.elan.net/~william/emailsecurity/