Radu Hociung wrote:
Was there any reasoning in favour of the choice of 3 separate
limits?
The reasons included:
- at this moment Wayne's paper was based on his implementation,
and it was not "officially" recognized as the next SPF draft.
As far as I'm concered "official" is what I have as a pointer
in my public bookmarks, and that was draft-lentczner before
schlitt-classic was published. ;-) Okay, it was also before
the SPF Council existed.
Obviously Wayne couldn't say e.g. "40 DNS queries" if his code
implemented 10 + 10 + 10. And probably his test suite also
checks the magic number 10.
- Wayne had some attack scenarios with a huge number of MX and
PTR names. The 3 * 10 magic was the cheapest defense.
Would you mind pointing me to the archive thread that talks
about this?
Sorry, I read this list behind a mail2news gateway with an
online newsreader and have no archive. Maybe you find it with
<http://dir.gmane.org/gmane.mail.spam.spf.discuss> looking for
"processing limits" - I get 40 hits, the corresponding threads
should be after draft-lentczner (Oct) before the Council (Dec),
October and November.
Of course some of these issues were also discussed on mxcomp
(the former MARID list) and here - long before I learned WTF a
"DNS zone cut" might be... ;-)
let's keep Wayne's 3 * 10 magic. It already forces RR and
POBOX to simplify their policies.
Unfortunately the trouble is that 3*10 adds up to 111 ;)
True, but only as a theoretical worst case. In practical cases
like RR we saw 39 as "sum" of 3 * 10. A similar issue was an
old "MUST detect loops" in earlier drafts.
Of course you're still free to detect loops, and for...
a.example IN SPF "v=spf1 mx include:b.example -all"
b.example IN SPF "v=spf1 mx include:a.example -all"
...you'd detect the error before the 5th query. But it's not
more necessary to mention it in the SPF RfC as a separate MUST,
because Wayne's magic 10 also detects it after 11 queries. If
your implementation is smarter that's fine, but these details
don't belong into an RfC, the SPF RfC is for interoperability.
If there are a lot of implementation guidelines, it should be
done in separate RfCs for implementors / policy publishers /
etc. MARID had core + 3 other texts. CSV = intro / CSA / DNA,
at some point the "all-in-one" text approach fails.
And "they" (that's the "enemy" styling itself as IESG ;-) even
split the grandson-of-1036 UseFor = UsePro + UseFor + UseAge.
I think this limit is unreasonable.
Then add a configurable "private" limit like 50 queries. For
practical cases like RR you'll probably never hit it, because
the 3 * 10 magic strikes before. And if it's a malicious case,
then the last you would want to publish is your private limit.
Serious attackers can read specs and C or perl sources.
One total cumulative counter should be enough.
It's a good idea to have it and to use it in an implementation.
I'm not yet convinced that it should be _added_ to the RfC with
some hardwired public limit.
If you want to _replace_ the 3 * 10 magic by a public overall
query limit, then I'm the wrong person for this discussion, you
have to convince Wayne where I failed... ;-)
And with a reasonable single overall limit like 40 you can't
claim that loop detection is an irrelevant side-effect. That's
only true for the first magic 10.
Maybe you could get away with 10 DNS mechanisms + 40 queries
instead of 3 * 10, If some dork has more than 10 MX-names
then that's no real problem, as long as they fit in the UDP
reply. Otherwise there's already a "MAY not use TCP".
Same idea for more than 10 PTRs. Actually that could result in
a slightly shorter text, maybe Wayne would love 10+40 replacing
3*10 for this reason. I'd like 10+40, but I'd hate 3*10+40.
Bye, Frank