Re: Last Call: <draft-ietf-appsawg-nullmx-05.txt> (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard

[John C Klensin <[e-mail]>]

--On Thursday, July 03, 2014 12:03 -0700 The IESG
<[e-mail]> wrote:

> The IESG has received a request from the Applications Area
> Working Group WG (appsawg) to consider the following document:
> - 'A NULL MX Resource Record for Domains that Accept No Mail'
>   <draft-ietf-appsawg-nullmx-05.txt> as Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and
> solicits final comments on this action. Please send
> substantive comments to the [e-mail] mailing lists by
> 2014-07-17. 

Hi.  For a number of reasons, many of which have been identified
by others, I find this draft and the actions it recommends
distasteful.  I see it as another step, albeit a small one, in
the direction of prioritizing the prevention of unwanted
messages or connections over successful delivery of legitimate
messages.  I continue to believe that prioritization is
undesirable, at least without fundamentally converting the email
infrastructure to an "acknowledge on delivery because there is
no expectation of successful deliveries" one rather than the
current protocols, which focus on notifications for
non-delivery.    That is not a strong technical objection and is
definitely not intended to be an argument against publication if
the IESG concludes that there is community consensus for doing
this, especially since, of the changes that could be motivated
as above, this is one of the more benign.

Hope, it would be better if the specification were historically
accurate and accurate about the protocols it cites.

The last sentence of the second paragraph of Section 5
("Security Considerations") of the spec says:

	"The normal way to send mail for which a sender wants no
	responses remains unchanged, by using an empty
	RFC5321.MailFrom address."

First, two issues of terminology:

(1)  RFC 5321 does not contain or specify notations like
"RFC5321.MailFrom".  That notation was introduced in RFC 5598, a
document that was approved as Informational with a consensus
that, IIR, included some significant desire that it not be
normative or casually treated as normative.  If this
specification wants to use that notation, that is fine.  But it
should include an explicit note to that effect in its
introduction or a Terminology section, not bury a "(see
[RFC5598] for the definitions of these terms)" reference in a
parenthetical note in Section 4.1 and then expect readers who
are looking specifically at other sections to pick up on it.

I believe that the RFC Editor's principle is that, if particular
terminology is needed to correctly understand a specification,
then the reference to the document that defines that terminology
is normative.  In this particular case, it seems inconsistent to
consider 2119 normative and 5598 informative since both are used
to define terminology without which the document cannot be
correctly understood.

(2) Second, RFC 5321 does not contain a concept that it calls an
"empty address".  The terminology it does use is "null
reverse-path" (See RFC 5321, Section 3.7).  Subject to the
above, if the authors want to say "null address in
RFC5321.MailFrom", I don't think that is sufficiently confusing
to be a problem.  But "empty address" could be construed as 
   MAIL FROM: 
in the envelope with nothing following it, and that would be bad
news.


More important, however, RFC 5321 specifies the use of a null
reverse path only for delivery failure and status notifications
and message disposition notifications (see Section 4.5.5 of RFC
5321) and constrains the recipient address to be used.     That
section also says 

	"All other types of messages (i.e., any message which is
	not required by a Standards-Track RFC to have a null
	reverse-path) SHOULD be sent with a valid, non-null
	reverse-path."

So. there isn't any "The normal way to send mail for which a
sender wants no responses" -- RFC 5321 and other specs
significantly constrain the cases in which null reverse-paths
may be used.  If this specification intends that notifications
that are generated in response to a null MX record, then that
needs to be made an explicit requirement to conform with the
language of RFC 5321.



Some additional observations that suggest this document needs
additional work before approval, probably with an intervening
additional Last Call:

(a) Sloppy DNS terminology has been the source of many problems
(see recent discussions of "dotless domains" in
draft-klensin-dotless-terminology-harmful; "hostname" used to
describe a DNS entry that contains an address RR, a DNS entry
where the owner also owns at least one address RR, and the first
(leftmost) component of an FQDN (with additional ambiguity as to
whether a zone break is implied); and considerable confusion
about terms like "resolver".  Whether the IETF steps forward to
try to clean up previous messes or not, it certainly should not
countenance making things worse.

Specifically referring to Section 3 of
draft-ietf-appsawg-nullmx-05, there is not such thing as a "NULL
MX Resource Record".  There is only an MX Resource Record that
this specification proposes to use with a convention involving
specific content in the DATA.  One could call that many things,
but "NULL MX Resource Record" isn't one of them.  

I strongly recommend that, in the spirit of the cross-area
review we talk so much about, the IESG refer this document to
DNSOP for a careful terminology check and not approve and
publish it (or its successor) until that WG has affirmatively
signed off on the terminology used.   In particular, in addition
to expressing an opinion on calling "NULL MX" a Resource Record,
DNSOP should contemplate such sentences as "A domain MUST NOT
advertise multiple MX RRs including a NULL MX" in a DNS
terminology and confusion context.   Because DNSOP has no
identified milestones, such a review should be able to get at
least as high priority as anything else it is working on.  :-(

(b) I think I know what the second paragraph of 4.1 in intended
to convey but I have now read it several times and can't be sure
that it what is says.  The parenthetical terminology note
doesn't help with readability but the problem exists even
without it.

(c) In 4.2, to my aging eyes and using fonts designed for
readability rather than high discrimination, the last "or" and
the "rather than" appear to be identical.   The difference is
that the first one uses digit-one instead of the letter-l in
"example".  "examp1e.com" (with the digit) is a registered
domain name and not on the IETF list of domain names that are
reserved for and allowed in examples.  SO I recommend (and I
think IETF policy requires) that the example be changed and that
any similar valid one be better explained.  That paragraph
should also, IMO, explicitly point out that the claimed
advantages exist only if the holders of the domains that are the
targets of the "mistranscribed or misunderstood" names actively
cooperate in establishing these records.  Experience indicates
that many such domains are registered with the express intent of
capturing and taking advantages of mistakes; owners of such
domains would have negative incentive to cooperate.

(d) It seems to me that the cases this proposal addresses are
special enough that a dedicated Extended Status Code would be in
order.  Instead, the document specifies the highly generic 5.1.2
(even those the RFC 3463 definition of X.1.2 includes "incapable
of accepting mail" and "invalid for mail" (which don't mean
quite the same thing).   Especially since there is not an
easily-located WG discussion, the document should at least
explain its choice.

(e) The issues identified above aside, the explanation in the
second paragraph of Security COnsiderations (Section 5) is
unsatisfying.  If a domain is configured so that some sending
hosts don't receive and some receiving hosts don't send, the
model specified in this document may simply be inappropriate and
shouldn't be used lest it cause lost messages.  Why can't that
simply be said, and said clearly (probably in another section
referenced from this one.

regards,
   john