A "Null MX" No Service Resource Record for Domains That Accept No Mail
draft-ietf-appsawg-nullmx-10

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-appsawg-nullmx-08.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments/questions:

IANA has a question for the requested IANA action in this drafted document.

IANA understands that, upon approval of this document, there is a single action which
IANA must complete.

ACTION:
In the "Enumerated Status Codes" sub-registry of the Simple Mail Transfer Protocol (SMTP)
Enhanced Status Codes Registry located at:

http://www.iana.org/assignments/smtp-enhanced-status-codes/

the following two Sub-Codes are to be added:

Code: X.1.10
Sample Text: Recipient address has null MX
Associated basic status code: 521
Description: This status code is returned when the associated
address is marked as invalid using a null MX.
Reference: [ RFC-to-be ]
Submitter: [J. Levine and M. Delany ]
Change controller: IESG

Code: X.7.26
Sample Text: Sender address has null MX
Associated basic status code: 550
Description:      This status code is returned when the associated
                      sender address has a null MX, and the SMTP
              receiver is configured to reject mail from such
              sender (e.g. because it could not return a DSN).
Reference: [ RFC-to-be ]
Submitter: [J. Levine and M. Delany ]
Change controller: IESG

QUESTION/NOTE:
The Enumerated Status Codes subregistry is managed via Specification Required.
We have initiated a request and sent this to the designated expert for review.

Note: The actions requested in this document will not be completed until the document
has been approved for publication as an RFC. This message is only to confirm what
actions will be performed.

Please note that IANA cannot reserve specific values. We receive requests constantly and
the numbers may not be available. However, early allocation is available for some types
of registrations. For more information, please see RFC 7120.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (A "Null MX" No Service Resource Record for Domains that Accept No Mail) to Proposed Standard


The IESG has tentatively approved the following document:
- 'A "Null MX" No Service Resource Record for Domains that Accept No
Mail'
  as Proposed Standard

Changes to the document late in the review process have resulted in
the addition of a downward reference to RFC 1846, which is an
Experimental document.  This extra Last Call is specifically to ask
for comments on whether that downward reference is appropriate.

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
ietf@ietf.org mailing lists by 2014-08-25. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

  Internet mail determines the address of a receiving server through
  the DNS, first by looking for an MX record and then by looking for an
  A/AAAA record as a fallback.  Unfortunately this means that the A/
  AAAA record is taken to be mail server address even when that address
  does not accept mail.  The no service MX RR, informally called null
  MX, formalizes the existing mechanism by which a domain announces
  that it accepts no mail, without having to provide a mail server,
  which permits significant operational efficiencies.


The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-appsawg-nullmx/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-appsawg-nullmx/ballot/

No IPR declarations have been submitted directly on this I-D.

[Ballot comment]
  Senders of abusive mail often use forged undeliverable return
  addresses.  Null MX allows DSNs and other attempted responses to such
  mail to be disposed of efficiently.

What's a DSN?  Please define in the terminology section, or add a reference saying that the reader should read (X), or just expand on first use: not all readers will have the SMTP RFCs memorized. :)

Also, it's not clear to me how this is a win unless the forged undeliverable return address has a null MX.  Is that the envisioned scenario?  If so, an additional sentence or two explaining why this is likely would help to justify the existence of this paragraph; otherwise I recommend just deleting it--it's not necessary, and on the face of it it seems implausible, but I'm not a spam expert, so maybe there's a reason of which I am not aware that the spammer would set this up, or use a fake domain for which a null MX exists.

[Ballot comment]
It seems like it would be worth documenting the fact that this is likely to result in increased bogus traffic to the DNS root.  Just because "." is technically not valid doesn't mean that some DNS libraries won't accept it.  For example, `dig . A` will happily send a query.  But the root is already used to dealing with noise, and in exchange for increasing that noise floor a little, we get to potentially reduce mail noise by a lot.  So the trade-off is worth making, but it would be nice to document it.

[Ballot comment]
Version -07 added the downref to RFC 1846.

1. We intend to move 1846 to Standards Track.  That should happen quickly, but...

2. ...just to cover bases here, I intend to do a second last call on this document solely to call out the downref.  That way, even if the 1846 update doesn't go quickly, we're covered.

[Ballot comment]

Just curious - do we know or are we guessing that
this won't be an issue for DNSSEC (implementations)?
I've no info either way, so its purely curiosity,
really:-)

[Ballot comment]
I have no objection to the publication of this document and you'll
probably call me picky when I point to the last line in Section 3.

  A domain MUST NOT advertise multiple MX RRs including a null MX.

That says one of two things:
1. You must not advertise multiple MX RR if any one of them is a
  null MX.
2. You must not advertise more than one null MX, but may advertise one
  null MX along with other MX RRs.

I think you mean the former in which case...

  A domain that advertises a null MX MUST NOT advertise any other
  MX RR.

But, if you meant the latter that could also be clarified.

thors:

IANA NOT OK. Comments in tracker.
IANA Actions - YES

REVISED IANA ACTION(S):

NOTE: This (revised) review is based on version 07 of the drafted document. Please report any inaccuracies and respond to any questions as soon as possible.

IANA has a couple questions for the requested IANA action(s) in this drafted document.

IANA understands that, upon approval of this document, there is a single action which
IANA must complete.

ACTION 1:
In the "Enumerated Status Codes" sub-registry of the Simple Mail Transfer Protocol (SMTP)
Enhanced Status Codes Registry located at:

http://www.iana.org/assignments/smtp-enhanced-status-codes/

the following two Sub-Codes are to be added:

Code:              X.1.10
Sample Text:        Recipient address has null MX
Associated basic status code:  521
Description:        This status code is returned when the associated
                    address is marked as invalid using a null MX.
Reference:          [ RFC-to-be ]
Submitter:          [J. Levine and M. Delany ]
Change controller:  IESG

Code:              X.7.26
Sample Text:        Sender address has null MX
Associated basic status code:  550
Description:        This status code is returned when the associated
                    sender address has a null MX, and the SMTP receiver
                    is configured to reject mail from such sender (e.g.
                    because it could not return a DSN).
Reference:          [ RFC-to-be ]
Submitter:          [J. Levine and M. Delany ]
Change controller:  IESG

1) QUESTION/NOTE:
The Enumerated Status Codes subregistry is managed via Specification Required.
IANA has submitted a management item (Attn: Barry) to get a designated expert (or experts).
The requested sub-codes will be sent to the designated expert for review upon approval of
the management item. 

2) QUESTION: Please add the name of the specific sub-registry "Enumerated Status Codes"
to the following text in the IC section for clarity purposes:

  "IANA is requested to add the following entries to the SMTP Enhanced
  Status Codes Registry."

Note: The actions requested in this document will not be completed until the document
has been approved for publication as an RFC. This message is only to confirm what
actions will be performed.

Please note that IANA cannot reserve specific values. We receive requests constantly and
the numbers may not be available. However, early allocation is available for some types
of registrations. For more information, please see RFC 7120.

[Ballot comment]
Section 4.1 uses the acronym "DSN" without any expansion.  I assume this expands to Delivery Status Notification, which is used later in the section.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-appsawg-nullmx-05, which is currently in Last Call, and has the following comments:

We understand that, upon approval of this document, there are no IANA Actions that need completion. 

While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object.

If this assessment is not accurate, please respond as soon as possible.

1. Summary

Shepherd:  D. Crocker
Responsible Area Director: Barry Leiba

Abstract:
  Internet mail determines the address of a receiving server through
  the DNS, first by looking for an MX record and then by looking for an
  A/AAAA record as a fallback.  Unfortunately this means that the A/
  AAAA record is taken to be mail server address even when that address
  does not accept mail.  The NULL MX RR formalizes the existing
  mechanism by which a domain announces that it accepts no mail, which
  permits significant operational efficiencies.

2. Review and Consensus

This draft was reviewed and refined within the Applications Area
Working Group.  Discussion extended over a 7-month period, with a
significant, if low, level of wg participation.  Discussion included a
reasonable number of likely email suspects, along with some others.  The
document was revised a number of times in response to wg and review
comments. None of the discussion engender major disagreements or
controversies.

The document does tend to elicit some confusion between declaring a
host as a non-sender, versus a non-receiver of email.  NullMX is for
non-receivers.  (The document contains a brief commentary about
non-senders, in order to aid clarification on the distinction.)

3. Intellectual Property

The authors have explicitly confirmed that to their direct, personal
knowledge there is no IPR related to this document

4. Other Points

Shepherd comments:
The technical details of this specification are simple and straightforward.
This is a simple and useful specification that codifies some existing practice.

There is some challenge in writing the document, in that community
discussion about email tends to use words like 'sender' and 'server'
generically.  Hence they can be ambiguous.  (Yes, an SMTP client is
often referred to as a server.)  The current draft could perhaps benefit
from some more careful attention to vocabulary usage; this might be
worthy of RFC Editor staff consideration.  It is difficult for
experienced email folk to read such text as if they were naive readers.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard


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'
  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
ietf@ietf.org mailing lists by 2014-07-17. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Internet mail determines the address of a receiving server through
  the DNS, first by looking for an MX record and then by looking for an
  A/AAAA record as a fallback.  Unfortunately this means that the A/
  AAAA record is taken to be mail server address even when that address
  does not accept mail.  The NULL MX RR formalizes the existing
  mechanism by which a domain announces that it accepts no mail, which
  permits significant operational efficiencies.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-appsawg-nullmx/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-appsawg-nullmx/ballot/


No IPR declarations have been submitted directly on this I-D.

> 1. Summary
>
> Shepherd:

  D. Crocker


> Responsible Area Director:

  Barry Leiba


Abstract:

  Internet mail determines the address of a receiving server through
  the DNS, first by looking for an MX record and then by looking for an
  A/AAAA record as a fallback.  Unfortunately this means that the A/
  AAAA record is taken to be mail server address even when that address
  does not accept mail.  The NULL MX RR formalizes the existing
  mechanism by which a domain announces that it accepts no mail, which
  permits significant operational efficiencies.


> 2. Review and Consensus

  This draft was reviewed and refined within the Applications Area
Working Group.  Discussion extended over a 7-month period, with a
significant, if low, level of wg participation.  Discussion included a
reasonable number of likely email suspects, along with some others.  The
document was revised a number of times in response to wg and review
comments. None of the discussion engender major disagreements or
controversies.

  The document does tend to elicit some confusion between declaring a
host as a non-sender, versus a non-receiver of email.  NullMX is for
non-receivers.  (The document contains a brief commentary about
non-senders, in order to aid clarification on the distinction.)


> 3. Intellectual Property

The authors have explicitly confirmed that to their direct, personal
knowledge there is no IPR related to this document


> 4. Other Points

  The technical details of this specification are simple and
straightforward.


Shepherd comments:

  This is a simple and useful specification that codifies some existing
practice.

      There is some challenge in writing the document, in that community
discussion about email tends to use words like 'sender' and 'server'
generically.  Hence they can be ambiguous.  (Yes, an SMTP client is
often referred to as a server.)  The current draft could perhaps benefit
from some more careful attention to vocabulary usage; this might be
worthy of RFC Editor staff consideration.  It is difficult for
experienced email folk to read such text as if they were naive readers.

  The -04 version raises a few minor Nits, which the authors are remedying.


d/