-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com]On Behalf Of Radu
Hociung
Sent: Friday, March 25, 2005 3:58 PM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: Re: [spf-discuss] Re: DNS load research
Frank Ellermann wrote:
Radu Hociung wrote:
So why not use m=65.0.0.0/6 ?
Tricky. Old implementations ignore new modifiers. And new
implementations are free to ignore them.
I'm counting on this. :)
I claim that while the new mask introduces DNS traffic savings, it does
not break existing implementations or published records in any way.
Old implementations ignore it and don't save. If you believe in the old
saying "a penny saved is a penny earned", it means that old
implementations are missing out out opportunities to be more efficient,
and they will be obsoleted in time.
You could very easily
get it wrong, a sender policy resulting in FAIL with some new
implementations, and other results with other implementations.
Maybe my description of this modifier was not clear enough.
The -m=65.0.0.0/6 means:
Nowhere in the following SPF records and their included or redirected
records exist any mechanisms that would match an address *outside* of
the 65.0.0.0/6 net.
The mask does not contradict the rest of the record.
At the same time, you MUST not assume it means "any sender with an
address in the 65.0.0.0/6 block is a permitted sender".
Also, you have to look at *all masks* and only if none of them apply to
the IP in question, the processing should continue.
In the case of a long-winded daisy chained record, the '-' also brings
the default mechanism (-all) from the very last record up to the
top record.
Due to the restrictions I outlined for when a mask must not be included,
think I coverted all cases that would cause unreliability.
If I missed something, please let me know.
Not exactly user-friendly. And looking at the exactly _zero_
feedback I got for the updated "op=" draft I doubt that anybody
is interested in new modifiers. Especially no SPF implementor.
I wasn't interested in user-friendly, because the mask can only be added
reliably by a compiler (a machine). Because to get a good mask is
difficult, it is also error prone. I would not want hand-coded masks,
that's what will cause the unreliability you mentioned (mask and record
mismatch).
The spfquery debug mode will check for these rules, and tell when a mask
doesn't match the record, or when it has the potential to be unreliable.
So from this point of view, the more user-unfriendly it is, the better.
Users should *never* add masks to their records. If the compiler decides
it would be beneficial and safe to add one, in the context of the output
it is providing, it will add one.
OTOH you're an implementor, you could guarantee that there's at
least one implemetation for your mask-modififier. If you need
an XML template for an indepedent draft use my old "op=" draft,
see draft-spf-6-3-options-04.xml and the corresponding txt in
<http://purl.net/xyzzy/home/test/>
Thanks, the day will come when your document may come handy.
Radu.
I've read through this a few times and it isn't clear to me how this is
different than -ip4:.
How would:
"v=spf1 ip4:65.0.0.02 -m=65.0.0.0/6 a mx include:example.net a bunch of
other stuff -all"
be processed differently than:
"v=spf1 ip4:65.0.0.02 -ip4:65.0.0.0/6 a mx include:example.net a bunch of
other stuff -all"
I can see where there might be benifit to excluding a bunch of IP addresses
before getting into expensive mechanisms, but it isn't clear to me why you
need a new modifier. I'd appreciate it if you could contrast how you would
see the two scenarios running.
Scott Kitterman