This is a combined Gen-ART and OPS-DIR review. Boilerplate for both follows ... I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at: <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the operational area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Document: draft-ietf-appsawg-nullmx-08 Reviewer: David L. Black Review Date: August 12, 2014 IETF LC End Date: August 25, 2014 Summary: This draft is on the right track, but has open issues described in the review. This draft is a short specification of a NULL MX resource record whose publication in the DNS indicates that a domain does not accept email. Good news: The one remaining nit from the Gen-ART review of the -05 version has been corrected in the -08 version. Bad news: idnits 2.13.00 noted the added downref to RFC 1846, for which the draft is now in a second IETF Last Call. A draft has just been submitted to replace RFC 1846 (Experimental) with a Standards Track RFC: https://datatracker.ietf.org/doc/draft-klensin-rfc1846bis/ The IESG should decide whether to proceed with the downref to RFC 1846bis vs. publish the 1846bis draft as a standards track RFC and reference it. That decision is the open issue in this review of the nullmx draft. >From an operational perspective, the added SMTP status codes for null MX errors (one of which is the cause of the downref) are an improvement, in that they enable more precise reporting of the reason for email not being delivered. Thanks, --David > -----Original Message----- > From: Black, David > Sent: Friday, July 25, 2014 10:46 AM > To: standards@xxxxxxxxx; mx0dot@xxxxxxxxx; General Area Review Team (gen- > art@xxxxxxxx); ops-dir@xxxxxxxx > Cc: apps-discuss@xxxxxxxx; ietf@xxxxxxxx; Black, David > Subject: Gen-ART and OPS-Dir review of draft-ietf-appsawg-nullmx-06 > > The -06 version of this draft addresses the topics raised in the Gen-ART > review of the -05 version, except that Section 1 is still missing from > the Table of Contents (possible xml2rfc problem?). > > Summary: Ready with nits. > > Thanks, > --David > > > > -----Original Message----- > > From: Black, David > > Sent: Thursday, July 17, 2014 12:39 AM > > To: standards@xxxxxxxxx; mx0dot@xxxxxxxxx; General Area Review Team (gen- > > art@xxxxxxxx); ops-dir@xxxxxxxx > > Cc: apps-discuss@xxxxxxxx; ietf@xxxxxxxx; Black, David > > Subject: Gen-ART and OPS-Dir review of draft-ietf-appsawg-nullmx-05 > > > > This is a combined Gen-ART and OPS-DIR review. > > Boilerplate for both follows ... > > > > I am the assigned Gen-ART reviewer for this draft. For background on > > Gen-ART, please see the FAQ at: > > > > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > > > Please resolve these comments along with any other Last Call comments > > you may receive. > > > > I have reviewed this document as part of the Operational directorate's > ongoing > > effort to review all IETF documents being processed by the IESG. These > > comments > > were written primarily for the benefit of the operational area directors. > > Document editors and WG chairs should treat these comments just like any > other > > last call comments. > > > > Document: draft-ietf-appsawg-nullmx-05 > > Reviewer: David L. Black > > Review Date: July 16, 2014 > > IETF LC End Date: July 17, 2014 > > IESG Telechat Date: August 7, 2014 > > > > Summary: This draft is on the right track, but has open issues > > described in the review. > > > > This draft is a short specification of a NULL MX resource record whose > > publication in the DNS indicates that a domain does not accept email. > > > > I found one relatively minor issue. > > > > Minor Issues: > > > > Something is wrong with this paragraph in the Security Considerations > section: > > > > In the unlikely event that a domain legitimately sends email but does > > not want to receive email, SMTP servers that reject mail from domains > > that advertise a NULL MX risk losing email from those domains. The > > normal way to send mail for which a sender wants no responses remains > > unchanged, by using an empty RFC5321.MailFrom address. > > > > Why is that treated as a security consideration? In light of the first > > paragraph in Section 4.3 stating that it's acceptable for SMTP clients to > > not send email to domains that publish NULL MX records, this text ought to > > be recommending that such a domain (legitimately sends email but does not > > want to receive email) SHOULD NOT publish a NULL MX record and SHOULD > provide > > an SMTP server that promptly rejects all email delivery attempt. It can > > then further explain that not following the "SHOULD NOT" causes lost email > > as described in the quoted text, and not following the "SHOULD" causes long > > delivery timeouts as described in Section 2. I'd also suggest moving this > > discussion to Section 4.3 so that it follows the first paragraph there. > > > > Nits: > > > > Section 1 is missing from Table of Contents. > > > > First paragraph in Section 4.1: > > "address is not deliverable" -> "the email is not deliverable" > > > > Second paragraph in Section 4.1 assumes that all or most domains that > > do not accept email also publish NULL MX records. That assumption should > > be stated as part of the first sentence of the paragraph, as the immediately > > preceding paragraph is about the benefits of individual domains publishing > > NULL MX records. > > > > In Section 4.3, please provide text descriptions of the 550 reply code and > > 5.1.2 enhanced status code. > > > > OLD > > 550 reply code > > NEW > > 550 reply code (Requested action not taken: mailbox unavailable) > [RFC5321] > > > > OLD > > 5.1.2 enhanced status code > > NEW > > 5.1.2 enhanced status code (Permanent Failure, Bad destination system > > address) > > > > idnits 2.13.01 didn't find anything to complain about. > > > > --- Selected RFC 5706 Appendix A Q&A for OPS-Dir review --- > > > > A.1.1 Has deployment been discussed? > > > > Yes, and NULL MX records are already deployed in the DNS. > > > > A.1.5. Has the impact on network operation been discussed? > > > > Yes, in general, NULL MX records have significant operational > > benefits as described in the draft. > > > > A.2. Do you anticipate any manageability issues with the specification? > > > > No. This is a minor extension to an existing use of DNS resource > > records. > > > > Thanks, > > --David > > ---------------------------------------------------- > > David L. Black, Distinguished Engineer > > EMC Corporation, 176 South St., Hopkinton, MA 01748 > > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > > david.black@xxxxxxx Mobile: +1 (978) 394-7754 > > ----------------------------------------------------