Frank Ellermann wrote:
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.
Show me in the current draft where it says that modifiers of the same
kind cannot be evaluated in context with each other (ie, "group")
I remember seeing something like:
Unrecognized modifiers SHOULD be ignored no matter where in a record,
nor how often. This allows implementations of this document to
handle records with modifiers that are defined in other
specifications.
Which appears to specifically allow new modifiers to appear multiple times.
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.
It can and it does.
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.
You will have to define these terms before you use them in an argument
on an SPF1 topic. I'm not familiar, nor do I wish to spend time now on
learning PRA.
Also, please show where in the spf-classic draft are 'composite' or
'grouped' modifiers disallowed.
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>)
Well, I have based my code on his, so I have learnt it inside out. Some
things could have been more efficient, but until you release your
version, please refrain from putting down someone elses.
And the critical point you missed earlier: I am not a programmer. I am
an engineer.
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.
Maybe when it matures more, spf2 will also take a closer look on its
resource usage. And DNS queries are a resource.
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.
So perhaps it's an emotional attachment to op= that doesn't allow you to
see the benefit of m= ?
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.
Dude, they're not equivalent!!!
Elementary or not. Latin or greek.
Since your -include is a non match, evaluation would CONTINUE, expanding
the following redirects until it reaches the -all, N queries later.
My mask would terminate the evaluation right then and there, before the
first redirect=
The purpose of the mask is to avoid lookups, and that's what it does.
Prove that wrong and I'll let it go.
I never said there are not other ways to arrive to the same evaluation
result, but I did say that there are none as cheap.
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.
I have been reading through the archives quite often, fascinating stuff
in there sometimes.
Including the dude who figured out that a cluster of mechanisms with the
same prefix can be reordered without changing the meaning of the record,
such that expensive mechanisms are left till the end. (related to a
recent spf-devel discussion)
But I didn't find them looking into ramifications of DNS such as the
load balancing feature of DNS. A lot of stuff has been overlooked.
Claiming that nothing has been overlooked is like saying 'never'.... and
you know what they say about saying 'never'. ;)
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.
Prove that it is, and we'll burn it. :)
I'll even yell out "Burn, evil modifier, burn!".
But prove it first. Until you do, the idea is valid, as confirmed by
several people on this list.
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>
Fine by me :)
Radu.