And then I forgot to change the subject line. Sigh. - Tony
Tony Hansen wrote:
Stephen Farrell wrote:
> Please just answer "keep", "modify", or "remove" in this thread, and
> use a different subject line for any discussion.
(Using a different subject line as requested.)
My conclusions from reading ssp-03 and the proposed rewording of section
4.3 found in levine-adsp-00 and otis-adsp-02 is that:
* ssp-03 and levine-adsp-00 require that you check that the domain
exists. otis-adsp-02 makes it an optional test.
* checking NXDOMAIN is not a perfect check for the test "is this
domain a MAIL SYSTEM", but can be considered a "sufficient" check for
the purposes of ADSP.
* levine-adsp-00 provides a superset of methods for *how* to
determine if the domain exists: the NXDOMAIN test and the "check MX &
A/AAAA" method from SMTP. It leaves it up to the implementation to
choose the algorithm that works best for it.
* otis-adsp-02 only specifies the "check MX & A/AAAA" method from
SMTP, but indicates that an NXDOMAIN return value breaks out of the
first part of the test.
* as implied by otis-adsp-02, checking NXDOMAIN can be treated as an
optimization for one of the failure paths of the "check MX & A/AAAA"
method. (If you check for the MX records and get NXDOMAIN, you know you
don't need to explicitly check for A/AAAA records because you've already
been told that they don't exist.)
* from discussions on the list, not all implementations may be able
to take advantage of that optimization.
Weighing the above, I find the text in levine-adsp-00 as the most
palatable wording for this test. Hence my "modify" vote.
Tony Hansen
tony(_at_)att(_dot_)com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html