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 ----------------------------------------------------