[spf-discuss] Ideas for future "unified" auth schemes

There was a lot of material posted on the thread "Re: Question on a unified 
policy record approach" - I haven't made it through all of it, but perhaps 
now would be a good time to resume talking about applying SPF syntax 
against other identities.
I had sort of put this issue on the back burner while we were working on 
SPF-Classic drafts, and getting our draft pushed to the RFC editor, getting 
an RR type for our future use, etc., were higher priorities.  But I have 
started seeing discussion on SPF3, SPF2.0/helo or other slashed strings, or 
op=whatever modifiers, so perhaps those of us who care about unification 
can start to float some ideas around.
SPF Classic (v=spf1) has an inherent limitation that it is only intended 
for use against the MAIL FROM and HELO (2821) identities.  However, there 
still exists the possibility for using the SPF language for other 
identities (just not the v=spf1 part) so that domains can publish a 
2822-From policy, 2822-Sender policy, etc.  The SPF language provides an 
excellent set of mechanisms for anything that compares a domain name with a 
sending IP, so there's no real reason why it can't be applied to other 
identities.  The only thing the language lacks is a method to say "what 
identity does this apply to?" and I believe that can be addressed simply 
and well, if taken with a certain amount of deliberation and care.
To me, "Unified" means the following.  (If you have a different idea of 
what "unified" means or should mean, please question the heck out of my 
assumptions so that we can try to proceed on a common basis).
1. An IP is required.  "Unified" syntax still uses Domain and IP, and not 
much more.
The SPF syntax works quite well for correlating a Domain and an IP, and 
getting one of a small number of possibilities.  We will probably not have 
much traction if we try to apply SPF language and concepts to something 
that doesn't depend on a Domain and IP.
2. A single identity is required.  "Unified" can validate one identity with 
one IP, but doesn't link one identity with other identities.
The SPF language can tell whether one IP is allowed to use the domain in 
the identity, but it can't (shouldn't) say "X identity needs to match Y 
identity".  Identities don't outrank or trump each other.  SPF-Unified is 
only used for checking one identity at a time.
3. A single domain is required.  "Unified" doesn't compare the policies for 
multiple domains.
There is only one domain we are interested in at any given time, and that 
is the domain of the identity we are trying to validate.  An identity has 
to have one and only one domain name to play.  If we only validate one 
identity at a time, we only care about one domain at a time - that is the 
domain claimed by the identity value.
What I'm not really comfortable with is statements that say "Our Sender: 
domain will always match our 2821 MAIL FROM", or "Our HELO will always be X 
if our From: is Y".  We don't have a great technology for comparing 
multiple identities to each other to make sure they are the same or similar 
enough.  What if they are different, and looking up both domains leads to 
different/conflicting policies?  Trying to establish a correlation or 
hierarchy may be useful in some circumstances, but SPF language is not a 
good tool for that.  Therefore, I don't want to stretch SPF to try and 
create equivalences or enforce matching - we should focus on what SPF 
language does best: one identity, one domain and one IP.
Some receivers will have their own local policy that says "Check HELO, then 
MAIL FROM, then Sender."  I would like SPF to be the method that gets used 
three times in that recipe, for a different identity each time.  I don't 
want to try and stretch SPF to enforce any ordering.  SPF can't say "Allow 
HELO, but only if MAIL FROM fails" or anything like that -- it's not 
equipped for it.  For one thing, I don't think there's a strong need for 
that, but for another, what should be done if the domains are different and 
their policies are conflicting?
The following discussion probably only makes sense if the above assumptions 
are kept in mind.

Option 1. tag the scope with the version

SPF2.0/mfrom and SPF2.0/helo are examples of the "tag the string" method. 
The receiver looks up the domain (for whichever identity is currently being 
examined) and discards any policy not containing the current scope between 
"SPF2.0/" and the next space.  That means the policy for MAIL FROM could be 
found in SPF2.0/mfrom, or in SPF2.0/helo,mfrom.
This approach has the advantage of being pretty readable and readily 
understood.  However, if there are three or more policies for different 
identities, we start to strain our possible responses to the TXT query on 
the domain.
It is possible to apply a global anything-goes to a domain (for example, a 
domain that sends no email ever could have "SPF2.0 -all" with no slash.) 
The risk there is that the record might be automatically applied in the 
future to identities that we didn't think of to check before.  Having some 
sort of wildcard or "applies to all" mode is good, because I really really 
think that most domains will want the same policy for HELO, MAIL FROM, 
Sender, etc.  This should be the "easy mode"

Option 2. op=mfrom or similar modifier

I don't like the modifier option as much, because like option 1, it still 
makes the TXT longer and requires you to list everything up front.

Option 3. Scope is a macro

This idea is based on the assumption that most domains will want the same 
policy for any identity bearing that domain.  If you want the same policy 
across the board, you just don't have to use the macro at all.  If you do 
want to vary the policy for HELO or MFROM or Sender, then you have to test 
%{scope} and redirect to another TXT query.  That way, if you really need a 
different policy for different scope, you can totally have it, and you're 
not crowding the initial TXT query.
I'm assuming here that most domains can come up with a single IP list that 
embraces all possible usages of the domain, in any identity.  If you can 
come up with a list of trusted IPs for all possible uses of your domain in 
a header, publish that as the one/only rule.  If you (for whatever reason) 
want a domain used as a HELO domain but blocked from ever being a MAIL FROM 
domain, you can do that, it's just a little more complex than the single-IP 
list.
This is NOT to say that the identities need to be the same.  If the HELO 
domain is ABC.com and the Mail From domain is DEF.com, no problem, check 
HELO (using %{scope}=helo) against ABC.com and then check Mail From against 
DEF.com.  Don't make it more complex than it has to be.
In other words, we would encourage people to put together a single list of 
IPs that can be applied to all identities.  If it works for Mail From, and 
for HELO, then it probably works for just about anything.  If the set of 
IPs is allowed to use our name in MAIL FROM, but not HELO, you can probably 
accomplish this by using a slightly different name in HELO.  But, the tools 
for scope (macro) will be there for the small fraction of folks who need 
them.
OK that's all for now.  Talk to you soon.
gregc

--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>

-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription, 
please go to http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com