spf-discuss
[Top] [All Lists]

Re: Re: DNS load research

2005-03-25 13:58:16
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.


<Prev in Thread] Current Thread [Next in Thread>