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 > [EMAIL PROTECTED] > _______________________________________________ > 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
