[Top] [All Lists]

Re: Strict RFC x821 Compliant: HELO/EHLO

2005-07-06 07:48:54

----- 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


Hector Santos, Santronics Software, Inc.