Re: Re: Use of New Mask Mechanism

Frank Ellermann wrote:
> Radu Hociung wrote:
> > 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.
I agree with you, the spec is (at least relatively) simple and clear. 
But there are corner cases it does not cover, and it currently imposes 
heavy loads on the DNS system. Heavy as in much heavier than any other 
application so far. At least that is my opinion, and I have 
substantiated it with empirical evidence.
Programming and engineering are (almost) completely different 
disciplines. Just like if you can cut things, it doesn't mean you can 
cook ;) But this is a more philosophical discussion.
> 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.
Would you mind expanding or providing references to this discussion on 
DNS with the IESG member? I'd be interested to see what the concern was 
and how it was addressed. Thanks.
> > 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.
I would love to get rid of a few things in SPF1, but that would break 
many records and all existing implementations. Obsoletion makes it 
easier to plan, stage and implement the removal of features with minimal 
disruption. On the other hand, if the ptr, %{i} and %{l} macros were so 
demonstrably evil that they'd be more of a risk than a benefit, I'd say 
remove them now. For one, I can't demonstrate that.

> > 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.
I don't know what op= was about, or what you're trying to point me to. I 
don't get it.

> > 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.
Ah... I see your point now, and I stand corrected. The two methods are 
more functionally equivalent than I realized so far.
I will look more carefully into the cost and benefit of each method 
(with this new understanding), and then decide if I should push the mask 
modifier further.
At a glance, m= still looks attractive, because it would allow a long 
daisy chained record list to avoid the second query at least 90% of the 
time if the mask is narrow enough. Also, it uses fewer characters 
overall (the "v=spf1 " and "+all" in the included record are not needed, 
the mask can use the shorter netblock syntax, the name of the modifier 
is 1 byte instead of 3). The include method requires that at least two 
queries be done in all cases.
I'll sleep on this some more.

Thank you for helping me see your point.

> > I have been reading through the archives quite often,
> > fascinating stuff in there sometimes.
> 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).
Indeed I found some of those conversation, but so far none that mention 
the inherent unreliability of A and MX mechanisms, as used by SPF, that 
is due to load balancing DNS servers.
I'll keep looking.

> 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.
While I was wrong to say your method was not equivalent, I did not 
overlook the include method. Initially I thought it could be used too, 
but didn't figure out the +all trick. The main reason why I thought an 
include is not an appropriate solution is because it requires an extra 
query, and is somewhat space inefficient as I mentioned above.
I'd like to maintain my support for the m= mechanism for the time being, 
and make it clear that after I've done some more in depth math and soul 
searching, I will have some proof why its cost/benefit ratio, and as a 
result, my continued support of if.
> > 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".
Not your fault, but mine, this time. :) I was the one unable to 
understand. Sorry for burning your energy with it.

Thanks,
Radu.