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(_at_)taugh(_dot_)com; mx0dot(_at_)yahoo(_dot_)com; General Area
Review Team (gen-
art(_at_)ietf(_dot_)org); ops-dir(_at_)ietf(_dot_)org
Cc: apps-discuss(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org; 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(_at_)taugh(_dot_)com; mx0dot(_at_)yahoo(_dot_)com; General
Area Review Team (gen-
art(_at_)ietf(_dot_)org); ops-dir(_at_)ietf(_dot_)org
Cc: apps-discuss(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org; 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(_dot_)black(_at_)emc(_dot_)com Mobile: +1 (978) 394-7754
----------------------------------------------------