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
alice(_at_)www(_dot_)example(_dot_)com or
alice(_at_)example(_dot_)org or alice(_at_)examp1e(_dot_)com
- rather than alice(_at_)example(_dot_)com.
+ (numeral "1" instead of letter "l") rather than
alice(_at_)example(_dot_)com.
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.