Radu Hociung wrote:
Well, all mask modifers evaluate as a group.
There's no such thing as "groups of modifiers" or "positional
modifiers" in v=spf1. For the latter you would need spf2.0, or
a hypothetical v=spf2 with these concepts.
So "m=-65/5 m=213/8" is equivalent to "m=-65/5 m=-213/8",
Okay, let's use the latter, that's as near to a "group" as you
can get in v=spf1, and it has the (for v=spf1 required) feature
that the order of m= modifiers is irrelevant. m=213/8 m=65/5
has the same effect. This kind of CIDR notation is AFAIK not
yet defined in v=spf1, but adding zeros if necessary is simple:
m=213.0.0.0/8 m=65.0.0.0/6
Your "m=" draft could define the usual shortcut without zeros.
The next problem: There were huge debates about "global" vs.
"positional" modifiers. spf2.0 has both, v=spf1 de facto only
"global" modifiers. A part of this debate was about "singular"
and "multiple" modifiers. At some point spf2.0 had both, and
v=spf1 had only "singular" modifiers.
That's important for implementations like Wayne's precompiled
policies (please don't ask me about the details, I never looked
into any SPF code, and I'm determined to leave it that way, as
a programmer you probably know why. <eg>)
At the moment spf2.0 doesn't say anything about this issue, it
is based on v=spf1 adding "positional" and the spf2.0 tags like
spf2.0/mfrom etc. instead of v=spf1.
At the moment all existing and non-existing v=spf1 modifiers
like "op=" are de facto "singular", the "m=" would be the first
"multiple" case. I'm just telling it as it is, and why I am
sure that the exact number of "m=" v=spf1 implementations would
be one. In other words it won't fly.
The same in "-include:not.me" style:
me. IN SPF "v=spf1 -include:not.me ..."
not.me. IN SPF "v=spf1 -ip4:65.0.0.0/6 -ip4:213.0.0.0/8 +all"
Because non-PASS mechanims in an included SPF record *do not
match*, Your example would be equivalent to
me. IN SPF "v=spf1 +all"
No. My example is equivalent to your m=65/6 m=213/8. If the
IP is _in_ 213/8, then the include:not.me does not match, same
for m=213/8. If the IP is _not_ in 213/8 (and also not in
65/6), say 214.0.0.1, then +all returns PASS, that's a match,
the -include says "FAIL for match", final result FAIL, and that
is the same result as for m=213/8.
Tertium non datur, that's a theorem in elementary logic. So
we have the same result for "IN", the same result for "NOT IN",
this is "equivalence", no theorem, the definition.
I will assume you meant:
Do not assume incorrect things. I came relatively late to SPF
in March 2004, but they really discussed anything that's easy
again and again here. As Scott said it's impossible to read
all the old nonsense, but if you pick only Wayne's articles
plus Mark Lentczner you should catch most important points as
far as the spec. is concerned.
The exact opposite.
Yes, after you changed all - in + and v.v. you got the exact
opposite, surprise. Therefore take my example as it was, check
this, and finally burn the "m=" idea as essentially redundant.
we should also legislate a punishment for manually-created
masks. ;)
After we introduced a rule where you must prove that you have
read some of Wayne's / Mark's 2004 articles before you propose
a v=spf1 modification. <beg>
Bye, Frank