Re: Use of New Mask Mechanism
2005-03-26 12:19:53
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.
-- Dave
************************************************************ *
* David MacQuigg, PhD email: dmquigg-spf at yahoo.com * *
* IC Design Engineer phone: USA 520-721-4583 * * *
* Analog Design Methodologies * * *
* 9320 East Mikelyn Lane * * *
* VRS Consulting, P.C. Tucson, Arizona 85710 *
************************************************************ *
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: Re: DNS load research, (continued)
- Use of New Mask Mechanism, David MacQuigg
- Re: Use of New Mask Mechanism, Radu Hociung
- Re: Use of New Mask Mechanism, Radu Hociung
- Re: Use of New Mask Mechanism, David MacQuigg
- Re: Use of New Mask Mechanism, David MacQuigg
- Re: Use of New Mask Mechanism, Radu Hociung
- Re: Use of New Mask Mechanism,
David MacQuigg <=
- Re: Use of New Mask Mechanism, Radu Hociung
- Re: Use of New Mask Mechanism, David MacQuigg
- Re: Use of New Mask Mechanism, Radu Hociung
- Re: Use of New Mask Mechanism, David MacQuigg
- Re: Use of New Mask Mechanism, Radu Hociung
- Need for Complexity in SPF Records, David MacQuigg
- Re: Need for Complexity in SPF Records, Radu Hociung
- Re: Need for Complexity in SPF Records, David MacQuigg
- Re: Use of New Mask Mechanism, Andy Bakun
- Re: Use of New Mask Mechanism, Radu Hociung
|
|
|