Skip to main content

Shepherd writeup
draft-ietf-appsawg-nullmx

1. Summary

Shepherd:  D. Crocker <dcrocker@bbiw.net>
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.
Back