[spf-discuss] Ramble about scopes

I don't want to talk about Sender ID, mostly because I don't think it's 
really worth spending time on.  (I'm not *objecting* to people talking 
about Sender ID, especially if it's of interest to more than two or three 
readers and the traffic on the list is slow.  So don't read that as coming 
from the list-mom... I'm just saying that I personally prefer not to pay 
attention to Sender ID.)
But, the discussion of "scopes" is an important one, especially when we're 
considering the future direction of SPF.

--Frank Ellermann <nobody(_at_)xyzzy(_dot_)claranet(_dot_)de> wrote:
> v=spf1 has no "scopes" [...]
> v=spf1 has "identities", MAIL FROM and
> HELO, but no "scopes".  Without at least positional modifiers
> it's difficult to create something like "scopes" within v=spf1.
I agree with Frank's interpretation, that SPF Classic defines two 
identities.  I've often said that there's no such thing as "scope" in SPF 
Classic, and that is a deficiency that should be remedied in a future 
version of SPF.
I personally think scopes are interesting because they would allow SPF to 
be used for new and different purposes.  It's a cool language, and might in 
the future lend itself well to other identities besides just MAIL FROM and 
HELO.
I would like to see a future version of SPF with a better definition of 
scopes and cleaner usage, but I think it's way too late to add it "scopes" 
to v=spf1

> But I recall that part of the SPF history in 2004, essentially
> there was never complete consensus, all had different ideas.
>
> I liked Mark's positional modifier approach as it is in spf2.0.
> Irony, spf2.0 later got its own global "scopes" and does not
> really need additional positional modifiers for that purpose.

Scopes are "needed" for cases where there are legitimate reasons for two 
identities (using the same domain name) to define one set of servers for 
one identity and a very different set for another identity.
But, here is where I diverge from most scope-zealots: my firm belief is 
that cases where scope is really *needed* will be very, very rare.  Why do 
I believe that?
1. Most normal users will want to use a small set of servers to send their 
mail, and the set of servers 99% of the time will be the same set whether 
the domain is used in HELO, MAIL FROM, or 2822.From:.  The cases where this 
is not true are important, but rare and specialized.
(Remember, in cases where people have different policies for HELO, MAIL 
FROM, or 2822.From:, they usually are using different domain names for 
each.  Hence, "mail1.mydomain.com" can have a pretty restrictive policy 
that includes just one IP (because it's usually only used for HELO) and 
"mydomain.com" can have a different policy if you want, without having to 
resort to scopes.)
2. Even if the way domain owners use MAIL FROM: is pretty different from 
the way they use HELO (or even 2822.From:), usually defining one list of 
servers that merges both sets is a pretty easy proposition.  Sure, you 
*could* specify things more exactly by saying that *no* server is allowed 
to use HELO mydomain.com, but they may say MAIL FROM mydomain.com.  But 
would most domain owners care?  If you trust a certain IP to use your 
domain as MAIL FROM, why not take the simple route and say that it's 
allowed to use your domain as HELO as well, even if it never does?  Merge 
the two lists of machines and get on with your life...
3. In cases where you absolutely need a scope specified, parts of the 
record might still be the same.  For example, if your MAIL FROM policy ends 
in ?all and you want a more restrictive HELO policy that ends in -all, you 
can still have the bulk of the record in the middle be the same -- it saves 
space and makes for fewer places to screw up later.

So, for me the great benefit of scopes is not that everyone needs different 
code for different identities, but because I want to encourage people to 
use the *same* spf code for multiple identities.  That means if you've gone 
to the trouble of creating an SPF record for your MAIL FROM usage, scopes 
make it easy to apply the same record to HELO as well (or a 
mostly-identical one).  Then it would truly be one-stop-shopping for 
IP-based authorization.
Given the above beliefs, I envision scopes as either positional modifiers 
(reasonably OK) or as macros (best).  For example, if you want a fairly 
open 2822.From policy, a very restrictive HELO policy, and a moderate MAIL 
FROM policy, it might look like this:
 "a mx ip4:10.1.2.0/24 scope=mfrom include:myisp.com ~all scope=helo -all 
scope=2822.from ?all"
Or like this:
 "a mx ip4:10.1.2.0/24 redirect=%{scope}.spf.%{d}"
I know a lot of people don't like macros because they are complicated, but 
if you believe as I do, that people will rarely need diverging scopes, it 
makes some sense.  The above example you can't really do with a 
comma-separated list of scopes... you pretty much have to repeat the whole 
record at least 2 times (and more times for new scopes that might come 
along)

Anyway, that's a part of my "vision" for the future of SPF...  practically 
speaking, a small part, but still somewhat important.  I look at it as an 
opportunity for SPF to "branch out" in the future.  Someone once wrote 
"Unix doesn't prevent you from doing stupid things, because that would also 
prevent you from doing very clever things".  You might feel that 2822.from 
is silly as a scope, but maybe there are domains out there that want to be 
used only for MAIL FROM and never for 2822 headers... who knows?
I look forward to working with all of you on future SPF ideas and 
directions :)
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>

-------
Sender Policy Framework: http://www.openspf.org/
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