Re: Use of New Mask Mechanism

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.
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.
> I guess this is really more of an educational problem than a syntax 
> problem.  Luckily, dummies like me won't have to create these masks, 
> we'll just see them in a compiled record, and click the "What's This" 
> button if we really want to know what they are.  Since this is syntax 
> for a compiled record only, let's not worry about making it more 
> self-explanatory.  m= is OK.
> > Also, I would revert back to my original syntax that allows m=65/6 
> > instead of requiring m=65.0.0.0/6. Both would work of course, but the 
> > simpler syntax would be legal. This is because I don't understand why 
> > that syntax has to be compatible with other systems. Maybe someone can 
> > explain. I think that as long as the checkers recognize the mask 
> > modifier, they will also know (from the draft) how to interpret its 
> > contents.
>
> I like your shorter syntax, particularly since the need for these 
> modifiers arises from records that are getting too long to squeeze into 
> a DNS packet.

Radu.