Re: the Seth Hypothetical

William,

I liked guy's idea to further qualify ordering of scope with if/then and 
boolean logic choices, but I don't really know if that level of flexibility 
would be needed for most implementations.  Nevertheless, I like it because 
it really does maximize the likelihood that Scope should be able to provide 
an absolute publisher intended answer for just about any combination of 
scopes thrown at it.
I suppose this paragraph is for guy to clarify.  The only problem with this 
is that I can't see an easy solution for when an SPF record processing 
server does not support one of the if/then choice standards that a domain 
publisher has placed in their TXT record.  Would such an occurance make the 
result of a comparison involving an unsupported scope return as true or 
false?  We would probably want to explicitly state how that works before 
trying to implement such logic in SPF records.
Addressing the issue of unsupported scopes on an SPF record processing 
server that uses order of scope seems easier because, I suppose that one 
must start with a core SPF and then either choose to support a given scope 
or not.  If not supporting a given scope, then skipping that scope and 
moving down the list to the next scope.  Perhaps not as flexible as guy's 
structure, but I think easier to implement.
At 02:11 PM 10/22/2004, you wrote:

> On Fri, 22 Oct 2004, Commerco WebMaster wrote:
>
> > William,
> >
> > I like this scope idea from a publishers standpoint, as it tends to avoid
> > the issue of having many different version (v=spfx) records to support
> > (perhaps even concurrently).
> >
> > Would it also be worth considering that the order of the sc= might 
> serve as
> > an order of processing for SPF record processing servers?  That way, if 
> any
> > one scope processing implementation conflicts over another, the publisher
> > is able to explicitly state their preference by the order of the intended
> > behavior for their published records to take place by following the sc=
> > list order itself.
>
> That is an interesting idea, however do remember that often when you're
> checking multiple ids, the scope for each id might come from different
> domain record. So what do you do as far as conflicts between these records
> and they have different positions of scoping modifier?
A really good point.  Perhaps it is wrong thinking on my part, but I have 
come to view redirect= as a short hand way to get SPF record processing 
servers to a common place within a given domain host structure so as to 
present a common SPF TXT record for that domain's host file (e.g. generally 
sending all sub domain SPF TXT records in domain.tld to a _spf.domain.tld ) 
unless an exception exists for a given domain's sub domain.  In this case 
(staying within the domain.tld structure), perhaps exceptions should be 
resolved at the top of the domain.tld structure or at the formal redirect= 
TXT record within that top domain.tld structure.
By doing this, I think that I have less to maintain because any changes 
impact the entire domain and thus I only have to address exceptions when I 
might need to make changes to SPF TXT records.  I don't think there is 
anything in the specification which precludes doing a redirect= to 
something outside from a domain.tld, but I treat my publishing of redirect= 
as if that were the case.  If there are no restrictions on redirect= to 
send outside of domain.tld for domain.tld records, should there be such a 
restriction added?  If this is done, what does doing that break?
I look at include: in a totally different way.  Because it was designed (as 
I understand it) to allow an up line ISP to also send messages on behalf of 
the domain with the domain holder's permission, its rules are its rules for 
each domains' publisher.  Getting back to the purpose of SPF protecting the 
identity of a given domain name itself, perhaps the rules established 
should defer back to the zone file responsible for the domain and not of 
the domain for the includes in the case of conflicts.
I have not thought through all the ways an abuser of the system might take 
advantage of that level of control, but perhaps this goes back to a thought 
I had about having a checkable registry of known valid spf record syntax 
publishers by domain.  I think of such a registry in the same way as I 
think of the ARIN whois service.  I don't check ARIN all the time because I 
don't need to, but I am glad that I can check ARIN to verify information 
when I encounter some exceptional event that makes me want to check for 
more information on an IP.
> > This could be further broadened to recommend the processing server has
> > direction as to the final processing result by using the same +/-/~/?
> > syntax that is followed in "all".  In instances where a conflict may 
> happen
> > by virtue of the published record, the earlier in the list still takes
> > precedent, irrespective of the +/-/~/? syntax.  e.g.,
> >
> > v=spf1 sc=-m,~s,p mx -all  - the record applies for Mail-From, Submit, PRA
> >
> > but would also mean that the processing order for the above mentioned
> > scopes would also be m,s,p and that if -m processing does not pass, the
> > whole transaction result is FAIL, whereas the ~s would not do this.
>
> Again same problem as above. But we should explore the idea further when
> talking about UnifiedSPF. But this also opens big holes that spammers
> maybe able to explore and generally it maybe better if recepient decides
> what he wants to check and how (but I personally want that standartized
> with something like BCP).
>
> > > Scopes as follows:
> > >  m = rfc2821 mail-from (spf classic)
> > >  h = hello
> > >  s = submit
> > >  i = ip ptr
> > >  p = microsoft pra
> After thinking it through I'm going to add two more non-identity scopes
> to above list:
>      n = nothing, means don't interpret operators after that. This allows
>          to quickly "comment out" certain part of spf record without
>          actually completely deleting it
>      a = Any or All. This means that it may match any scope, kind of like *
>          Possibly this maybe a default if scope is not present
>
> And here is example with "n" specially for Phillip:
>
> v=spf1 sc=n ?all sc=m mx -all
With a = Any or All scope, perhaps the age of the specification might 
dictate the order of processing (perhaps also the case with default no 
scope).  In other words, start with the basic SPF specification and test 
forward based upon both what the publisher has published and what the SPF 
request processing server has implemented.  However, I could see how this 
might create some processing problems, if we cannot arrive at a way to 
prioritize an order for the various proposed SPF standard extensions that 
Scope attempts to deal with.  Still, that may end up being a problem 
irrespective of implementing Scope (e.g., from multiple v=spfx records) and 
one that should be addressed somehow.
> --
> William Leibzon
> Elan Networks
> william(_at_)elan(_dot_)net
Best,

Alan Maitland
The Commerce Company - Making Commerce Simple(sm)
http://WWW.Commerco.Com/