Re: Use of New Mask Mechanism

David MacQuigg wrote:
> At 01:33 PM 3/26/2005 -0500, Radu wrote:
>
> > David MacQuigg wrote:
> >
> > > At 11:53 AM 3/26/2005 -0500, Radu wrote:
> > >
> > > > Once again, the mask would not work as a mechanism (unless it was in 
> > > > include, like Frank mentioned), because each mechanism can return a 
> > > > match. the mask modifiers can return a match only after *all of 
> > > > them* have been checked against the IP. Think of a mask like m=65/6 
> > > > m=214/6. For senders in the 214 net, your proposed -!ip4 mechanism 
> > > > would wrongfully declare the 214 sources as "FAIL".
> > >
> > > Oops.  I thought I understood these masks, but I missed it.  OK, so 
> > > what this "mask" mechanism really says is, the IP address must match 
> > > one or another mask range AND match at least one of the subsequent 
> > > mechanisms.
> >
> > Almost :)
> >
> > Please, let's never call it a mechanism again, to avoid confusion. It 
> > really is a *modifier* !!! Actually a *set of modifiers* are only 
> > meaningful together. Individually, each mask modifier doesn't mean 
> > anything, because it doesn't tell enough to allow the checker to stop 
> > evaluating.
>
> Good point.  It's a modifier, not a mechanism.
>
> > And what it really says is: Somewhere in the included/redirected 
> > records, there are more IP mechanisms that match some of the IPs in 
> > the mask range. It's a "summary" of the remaining records, if you 
> > wish. The summary includes more IPs than the records themselves, but 
> > it serves well to tell authoritatively what IPs *aren't* in the 
> > subsequent includes. It also serves to tell you what the all at the 
> > very end of the record chain says the to do with unmatching IPs 
> > ("fail", "softfail", etc), so that you don't need to scan the whole 
> > chain to find out what the domain owner wants you to do.
> > Somehow I/we need to find a description of this that would be very 
> > clear, so that implementers of SPF checkers know what to do. It is 
> > clearly a description/language problem because you're not alone 
> > getting a grasp on its meaning.
>
> How about
>
>    record           = version [mask] terms *SP
>    version          = "v=spf1"
>
>    mask             = *( 1*SP m= ipblock )
>
> After processing the mask, if there is any match, proceed with the terms 
> as usual.  If there is no match, skip processing any terms except 'all', 
> and don't call for any remainder of a truncated record.
Thats good, except the earliest the mask can be evaluated is after the 
A/MX/exists mechanisms. For instance, an exists:{i}.domain.com cannot be 
 covered by a mask. The only reason why a compiler might leave 
a/mx/exists mechanisms in the compiled record is if they contain macros 
that cannot be expanded at compile time (such as i, l, and possibly s).
I was planning on worrying about truncated records. I was going to 
assume that the checker cannot receive a truncated record, because the 
resolver library takes care of using TCP as necessary. In any case, for 
compiled records this should only happen if the compiler screwed up and 
created a record that is cannot fit in a UDP packet. I would treat that 
as a bug that must be fixed, as opposed to a condition that must be 
handled by the checkers.
So, since I'm assuming that the checker receives the entire record, the 
masks could be evaluated when the first include/redirect mechanism is 
encountered. This would mean that the mask does not need to cover IP 
addresses in the top record, as they are free to check.
Radu.