Hector Santos wrote:
Part of the problem with integrating new DNS/domain based
validation methods is the overhead in the DNS lookup process.
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.
nxdomain
none
success (i.e., a SPF,, CSV record exist)
DNS server downtime/timeout issues
For SPF the philosophy of result codes is very simple:
NONE == whatever it is, it has no sender policy
PASS (etc.) == valid policy with result PASS (etc.)
TempError == temporary trouble (e.g. a DNS timeout),
maybe try again later
PermError == broken sender policy, dare not come back
before you fixed your sender policy
The latter case includes all recursive NXDOMAIN problems.
Of course you're not forced to reject any SPF errors.
Basically, the idea of:
No Brackets ==> presumed DOMAIN
is not a practical idea to implement because systems will
endure a very high volume of HELO hits such as:
HELO #.#.#.#
Fine, reject it if you don't like it. As far as SPF is
concerned #.#.#.# doesn't have a sender policy => NONE.
You'd get the same result NONE for HELO [#.#.#.#] with
SPF, working as designed, it's about sender policies.
For a "receiver policy" you could accept HELO [#.#.#.#]
coming from IP #.#.#.#
You could also accept HELO #.#.#.# from IP #.#.#.#. If
the IP is different it starts to get ugly, maybe reject
it, or treat it like a FAIL, your decision. But don't
say that this was a "sender policy", because it was not.
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 />
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