Protocol Action: 'A "Null MX" No Service Resource Record for Domains that Accept No Mail' to Proposed Standard (draft-ietf-appsawg-nullmx-08.txt)

The IESG <iesg-secretary@ietf.org> Thu, 28 August 2014 18:42 UTC

Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Subject: Protocol Action: 'A "Null MX" No Service Resource Record for Domains that Accept No Mail' to Proposed Standard (draft-ietf-appsawg-nullmx-08.txt)
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140828184230.1493.26279.idtracker@ietfa.amsl.com>
Date: Thu, 28 Aug 2014 11:42:30 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf-announce/OtF34RfXk4s7O4eWaggk31U3lPE
Cc: RFC Editor <rfc-editor@rfc-editor.org>
Reply-To: ietf@ietf.org

The IESG has approved the following document:
- 'A "Null MX" No Service Resource Record for Domains that Accept No
Mail'
  (draft-ietf-appsawg-nullmx-08.txt) as Proposed Standard

This document is the product of the Applications Area Working Group.

The IESG contact persons are Barry Leiba and Pete Resnick.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-appsawg-nullmx/




Technical Summary

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.

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

Personnel

The Document Shepherd is Dave Crocker, and the responsible
Area Director is Barry Leiba.


RFC Editor notes

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.

In addition, please make the following change in Section 6:

OLD
   Code:              X.7.26
NEW
   Code:              X.7.27
END


IANA notes
As code X.7.26 has since been taken by draft-ietf-appsawg-email-auth-codes-07,
please note that the code will actually be X.7.27 now.

Protocol Action: 'A "Null MX" No Service Resource… The IESG