----- Original Message -----
From: "Frank Ellermann" <nobody(_at_)xyzzy(_dot_)claranet(_dot_)de>
If you know that say TLD .invalid is invalid then you don't
need a DNS lookup. And if you're sure that the <toplabel>
cannot be 1*DIGIT it's almost the same situation.
Right. So once this issue of the TLD for a valid domain can not
be in the range of 0 to 255, then we have a good solid test. The
question is can this ambiguity be settled for 2821bis. I don't know.
I like to believe ICANN is not going to be that stupid.
The latter case includes all recursive NXDOMAIN problems.
Of course you're not forced to reject any SPF errors.
Right, what I am saying that if SMTP system does begin to support SPF or
anything else for that matter, the SMTP "2821bis" document should have a
discussion item that might say something like:
"Although out of scope for this document, any new
HELO/EHLO level validaiton technology
implemented should consider the DNS overhead
potential for open-ended lookups. Applying syntax field
validation checking may apply here."
"For implementators with new DNS-based proposals
based on HELO checking, they should heed the
warning of placing a network DNS burden with
open-ended lookups."
Or something of that nature.
Thinking about it, this domain literal stuff is really
tricky. If you want to check domain literal == IP you
must decode it. At least I now see why 2821 allowed the
leading zeros, we can't remove them in 2821bis. <sigh />
From what I can see from implementation experience, is the ambiguiity at
the moment is where #.#.#.# (no brackets) can be viewed as possible domain.
Plan B for known traps and pitfalls: simply document it.
Documented "bugs" are by definition features. It's not
bad enough for some new "security considerations". Bye
Right.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com