A "Null MX" No Service Resource Record for Domains That Accept No Mail
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: IETF-Announce <firstname.lastname@example.org> Cc: RFC Editor <email@example.com> 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) 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.