Subject: Re: Gen-ART and OPS-Dir review of draft-ietf-appsawg-nullmx-06

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 3 Aug 2014 23:17:31 +0000

On Fri, Jul 25, 2014 at 10:45:43AM -0400, Black, David wrote:

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

I finally read the complete draft, additional suggested changes
(git diff for the .xml document):

    * semantic is an adjective, semantics is a plural noun that is usually
      (properly) treated as singular, and there is no need to invent the
      singular "semantic".

    * In many fonts it is difficult to see the difference between "1" and
      "l" (which is the point of the example, but the example itself is
      then confusing).

    * More clear about what is rejected by the MSA when it rejects a
      recipient with a nullmx domain.

    * More clear about what one is more confident about when one
      rejects nullmx domains.

    * Plausibly better text about need for return addresses, the original
      needs some sort of change if not this.

    * The first item in security considerations seemed rather contrived.
      Nullmx plays little role in whether or not message origin information
      is subject to forgery.   If the goal is to state that nullmx
      discourages forgeries that assert origin in domains that don't
      send email, and thereby makes some forgeries less attractive, it
      should say so more plainly.

diff --git a/draft-ietf-appsawg-nullmx-06.xml b/draft-ietf-appsawg-nullmx-06.xml
index 055c136..1f228ee 100644
--- a/draft-ietf-appsawg-nullmx-06.xml
+++ b/draft-ietf-appsawg-nullmx-06.xml
@@ -97,7 +97,7 @@ significant operational efficiencies.
 	   accepts email for a domain. Section 5 of <xref target="RFC5321" /> covers this in
 	   detail, but in essence the SMTP client first looks up a DNS MX RR and
 	   if that is not found it falls back to looking up a DNS A or AAAA RR.
-	   Hence this overloads an email service semantic onto a DNS record with a different primary mission.
+	   Hence this overloads email service semantics onto a DNS record with a different primary mission.
 	</t><t>
 	   If a domain has no MX records, senders will attempt to deliver mail to
 	   the hosts at the domain's A or AAAA record's addresses.
@@ -140,7 +140,7 @@ significant operational efficiencies.
 	   Mail often has an incorrect address due to user error, where the
 	   address was mistranscribed or misunderstood, for example, to
 	   [email-masked] or [email-masked] or [email-masked]
-	   rather than [email-masked].
+	   (numeral "1" instead of letter "l") rather than [email-masked].
 	   Null MX allows a mail system to report the delivery failure when 
 	   the user sends the message, rather than hours or days later.
 	</t><t>
@@ -153,8 +153,8 @@ significant operational efficiencies.
 	   It will discover on the first sending attempt that an address
 	   is not deliverable, avoiding queuing and retries.
 	</t><t>
-	   When a submission or SMTP server rejects a message due to a domain's
-	   null MX record, it SHOULD use a 550 reply code
+	   When a submission or SMTP server rejects an envelope recipient
+	   whose domain has a null MX record, it SHOULD use a 550 reply code
 	   (Requested action not taken: mailbox unavailable) and a
 	   <xref target="RFC3463">5.1.2 enhanced status code</xref>
 	   (Permanent failure: Bad destination system address).
@@ -162,7 +162,7 @@ significant operational efficiencies.
 	   A receiving SMTP server that
 	   chooses to reject email during the SMTP conversation that
 	   presents an undeliverable RFC5321.MailFrom or RFC5322.From domain
-	   can be more confident that a subsequent attempt
+	   can be more confident that for other messages it accepts a subsequent attempt
 	   to send a Delivery Status Notification or other response will
 	   reach a recipient SMTP server.
 	</t><t>
@@ -179,8 +179,8 @@ significant operational efficiencies.
 	   Null MX is primarily intended for domains that do not send or receive
 	   any mail, but mail is sent to them anyway due to mistakes or malice.
 	   Many receiving systems reject mail that has an invalid return address.
-	   Return addresses are needed for sending handling feedback about messages.
-	   Also, an invalid return address often signals that the message is spam.
+	   Return addresses are needed to allow the sender to handle message delivery errors.
+	   An invalid return address often signals that the message is spam.
 	   Hence mail systems SHOULD NOT publish a null MX record for domains
 	   that they use in RFC5321.MailFrom or RFC5322.From addresses.
 	   If a server nonetheless does so, it risks having its mail rejected.
@@ -198,11 +198,6 @@ significant operational efficiencies.
 
      <section title="Security Considerations">
 	<t>
-	   SMTP mail is inherently insecure since it does not validate any of
-	   the e-mail addresses in the message or envelope. This
-	   specification is about eliminating one small section of SMTP insecurity.
-	</t>
-	<t>
 	   Within the DNS, a null MX RR is an ordinary MX record and presents no
 	   new security issues.
 	   If desired, it can be secured in the same manner as any other DNS record

-- 
	Viktor.