ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] why we should clearly specify domain existence

2008-05-27 08:10:48
Tony Finch wrote:


Why not simply reject "bogusmx", and don't bother to check ADSP ?
 
You seem to be arguing that if an implementer thinks the NXDOMAIN
check is too weak, then they should use whatever validity check
they think is suitable.

Yes, but of course ADSP implementations should not report NXDOMAIN
when they checked something else.  If you want a result NOMAILFQDN
instead of NXDOMAIN, stating that NOMAILFQDN can be determined as
specified in 2821bis chapter 5, and an NXDOMAIN check is (only) a
minimal approximation, then I'm fine with it (apparently John's
ADSP draft does this).  

But you have to rename the corresponding result, that is important
for the Authentication-Results.  Digression, at one point in the
SPF history a draft claimed that a domain literal is a "malformed
domain", and that was simply wrong.  If some receivers don't like
domain literals they can decide this without SPF, or here without
ADSP.  Chapter 5 in 2821bis does not discuss domain literals, for
obvious reasons (actually only "obvious" in an IPv4-only world).

The whole point of ADSP's domain validity check is to define 
when an implementation should not bother to check ADSP.

It's also the definition of result "nxdomain" in Murray's draft,
if you want "nomailfqdn" (or a similar name), where NXDOMAIN is
only a proper subset, it's okay.  

While we're busy renaming ADSP results, could anybody here explain
the idea of "all" vs. "discardable" ?  I don't see the difference.

One of the more dubious SPF concepts is SOFTFAIL vs. (hard) FAIL,
and "all" smells like SOFTFAIL for me.  The real thing is a FAIL,
what receivers finally do with it is their decision.

 Frank

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

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