Radu Hociung wrote:
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")
If the order is irrelevant, you can get this kind of group. If
you'd need more you're introducing a new concept of modifier.
But we have already seen that you 1: don't need it, 2: could
use one modifier with a comma-separated list of "masks", 3: the
"m=" idea was essentially redundant. In the latter case read
TINW for "we" until you tested it.
[global / positional / singular / multiple]
You will have to define these terms before you use them in
an argument on an SPF1 topic.
They are defined in draft-marid-protocol-03.tt, you find it in
my small "draft collection" <http://purl.net/xyzzy/home/test/>
I'm not familiar, nor do I wish to spend time now on learning
PRA.
spf2.0 IsNot only PRA, it's also spf2.0/mfrom, it's the one and
only thing MARID produced in the five months of its existence.
until you release your version, please refrain from putting
down someone elses
I did not put down any code without looking into it, I told you
potential reasons why some code _might_ ignore all "multiple
modifiers" (maybe excl. the first or last), and why it _might_
evaluate modifiers after anything else in a policy. If that's
irrelevant in your v=spf1 code it doesn't mean that it's also
irrelevant in other v=spf1 implementations.
And I'm almost sure that it must have been relevant, otherwise
some hot discussions between James, Wayne, and Mark about
exactly this minor issue would have been pointless.
the critical point you missed earlier: I am not a programmer.
I am an engineer.
That's no excuse, quite the contrary, software engineering is
the "computer science" of programming. Of course studying this
stuff is not the same as doing it in practice later. SPF is
relatively simple, the spec. is relatively clear, if you think
that that's not the case I'm lost.
And yes, I know shit about DNS. But at least I found "q=ns"
for nslookup after Wayne told me that "zone cut" ought to be
simple. Again later the IESG and others somehow convinced him
that it's not always simple - I never understood why, SPF is
one layer above DNS, not a part of it. If somebody screws his
NS up it's his problem, and no SPF problem. Never mind, the
SPF Council decided this issue as one IESG member wanted it.
Maybe when it matures more, spf2 will also take a closer look
on its resource usage. And DNS queries are a resource.
Sure, let's not only deprecate e.g. ptr but get rid of it. And
of other oddities like "exp=". Proably that would be v=spf2 or
spf2.1 or spf3.0. I'm not planning to break Sender-ID for fun,
only because "they" try to do this with "us". Especially when
both "they" and "us" includes Meng.
perhaps it's an emotional attachment to op= that doesn't
allow you to see the benefit of m= ?
Perhaps you confuse us, see below.
If you still don't get it just test it with a real policy and
<http://spf.pobox.com/why.html> Use &debug=1 for the details.
Dude, they're not equivalent!!!
Take your favourite SPF draft, read chapter 5.2, again. If the
result within the include is FAIL (as for -ip4:213/8), then the
include does not match, and the processing of the "main" policy
continues. Same for m=213/8. Test this with IP 213.0.0.1.
If the result in the include is PASS (as for +all), then the
include matches, and a matching -include is a FAIL. Same for
m=213/8. Test this with IP 214.0.0.1.
Since your -include is a non match
PASS for +all in the case of 214.0.0.1 _is_ a match. And the
"-" of "-include" is then a FAIL. Now that's the 5th time, do
you have a general problem with TRUE = not( not( TRUE )) ?
IP 214.0.0.1 misses all these "not.me" -ip4 like 213/8, it runs
into the final "+all". "+all" means PASS, PASS is a match, and
therefore -include:not.me is a FAIL for IP 214.0.0.1.
My mask would terminate the evaluation right then and there
Yes, like "my" -include:not.me. After a match you're ready,
the final result is then the "-" of "-include:not.me".
I have been reading through the archives quite often,
fascinating stuff in there sometimes.
Yes, adding Meng to the "must read" authors makes sense, if you
want more than the relevant "v=spf1 spec." topics. Much more,
therefore I didn't propose it for our "problem", or whatever it
is. For fun with include and exists Greg is also a "must read"
- he invented this "+all" trick. While others claimed that a
sender policy with "+all" is by definition bogus. It is not.
I didn't find them looking into ramifications of DNS such as
the load balancing feature of DNS.
The load balancing discussions were in spf-help:
<news://news.gmane.org/4158996F(_dot_)7BA0(_at_)xyzzy(_dot_)claranet(_dot_)de>
<news://news.gmane.org/4163769E(_dot_)7D62(_at_)xyzzy(_dot_)claranet(_dot_)de>
Sorry, I have only an "ego-archive". The thread was not very
interesting, it was identified as a potential issue for an old
idea of load balancing and / or SPF checks behind the MX, in
other words more or less what you said here.
The next hit for "load balanc" is already here in spf-discuss,
but that was the thread in October, where I wanted an overall
DNS query counter instead of Wayne's 3 counters, you probably
know it (not necessarily the thread, but definitely the idea).
A lot of stuff has been overlooked.
Sure, the "op=" stuff was a collection of such ideas: Meng's
"trusted forwarder", Hector's simplified "HELO FAIL", Scott's
"SoftPass", William's PRA-alternative, a v=spf1 opt-in PRA, and
John Levine's pseudo-zone-cut (long before CSV introduced it).
The name "op=" was Chris' idea, and originally it meant "other
protocols". I only renamed it to "optional properties", and
(ab)used it to preserve the ideas of others for some time. If
none of these ideas make it I'm not upset. It would be only
stupid if they are lost and later re-invented.
Claiming that nothing has been overlooked is like saying
'never'.... and you know what they say about saying 'never'.
In the case of "m=" the -include:not.me was overlooked by you.
Anything else about the idea behind "m=" like getting a FAIL as
soon as possible is good, and the special case of a not.me mask
is AFAIK "new". But of course I never read all articles here,
let alone old articles before Mar 2004.
Prove that it is, and we'll burn it. :)
I'll even yell out "Burn, evil modifier, burn!".
I don't have a name server for a demo with why.html, but maybe
you can emulate it, or you have a name server. Otherwise
please ask somebody else. Obviously I'm unable to explain the
concept of -include:not.me with a not.me "-ip4:127.0.0.1 +all".
Hint, that's a FAIL for all IPs excl. 127.0.0.1, for 127.0.0.1
it doesn't match. Bye, Frank