RFC 7505

A "Null MX" No Service Resource Record for Domains That Accept No Mail

📅 published June 2015, from ietf

This is RFC 7505, "A "Null MX" No Service Resource Record for Domains That Accept No Mail" ✨. It's a Standards Track doc from June 2015 (ISSN 2070-1721), written by John Levine of Taughannock Networks and Mark Delany of Apple Inc. Its title block doesn't list anything it obsoletes or updates 💖

Abstract ✨

Internet mail finds the receiving server through DNS. It looks for an MX record first, and if there isn't one, it falls back to an A/AAAA record. The problem is that the A/AAAA record gets treated as the mail server's address even when that address doesn't accept mail 🙃 The No Service MX RR, nicknamed "null MX", makes official the existing way a domain says "I take zero mail" without having to run a mail server. That's a huge efficiency win 💅

Status of This Memo 📜

This is an Internet Standards Track document 🔥

It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check Section 2 of RFC 5741.

For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc7505.

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication. Please read these carefully, because they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License.

Table of Contents 🗺️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
2.  Conventions Used in This Document . . . . . . . . . . . . . .   2
3.  MX Resource Records Specifying Null MX  . . . . . . . . . . .   3
4.  Effects of Null MX  . . . . . . . . . . . . . . . . . . . . .   3
  4.1.  SMTP Server Benefits  . . . . . . . . . . . . . . . . . .   3
  4.2.  Sending Mail from Domains That Publish Null MX  . . . . .   4
5.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
  7.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
  7.2.  Informative References  . . . . . . . . . . . . . . . . .   6
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   6
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1. Introduction 🧚

This doc defines the No Service MX, informally called "null MX", as a simple way for a domain to say it doesn't accept email 💌

Senders have a prescribed order for finding a server that accepts mail for a domain. Section 5 of [RFC5321] covers it in detail. Basically, the SMTP client looks up a DNS MX RR first, and if that isn't found, it falls back to a DNS A or AAAA RR. So a DNS record with a totally different main job ends up doing double duty for email 🤯

If a domain has no MX records, senders will try delivering to the hosts at the addresses in its A or AAAA records. If nothing is listening for SMTP at those addresses, delivery keeps getting retried for ages, typically a week, before the sending Mail Transfer Agent (MTA) finally gives up. That delays telling the sender about misdirected mail and eats up the sender's resources 😩

This doc defines a null MX that makes every delivery attempt to a domain fail immediately. Domains don't need to set up SMTP listeners just to block delivery attempts 🙌

2. Conventions Used in This Document 📖

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

The terms "RFC5321.MailFrom" and "RFC5322.From" are used as defined in [RFC5598].

3. MX Resource Records Specifying Null MX 🎀

To say a domain doesn't accept email, you publish a single MX RR (see Section 3.3.9 of [RFC1035]). Its RDATA is preference number 0 plus a zero-length label, written in master files as ., as the exchange domain. That's how you show the domain has no mail exchanger at all. Since . isn't a valid host name, a null MX can't get mixed up with an ordinary MX record. Using . as a pseudo-hostname for "no service available" is modeled on the SRV RR [RFC2782], where it means something similar 🦋

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

4. Effects of Null MX 💖

The null MX record comes with a bunch of efficiency and usability benefits ✨

4.1. SMTP Server Benefits

Mail often has a wrong address because of user error, like when it got mistranscribed or misunderstood. Think alice@www.example.com, alice@example.org, or alice@examp1e.com instead of alice@example.com 🙈 Null MX lets the mail system report the delivery failure when the user sends the message, instead of hours or days later.

Senders of abusive mail often use forged, undeliverable return addresses. Null MX lets Delivery Status Notifications (DSNs) and other attempted responses to that kind of mail get disposed of efficiently 🗑️

Being able to detect domains that don't accept email saves resources for SMTP clients. They discover on the very first sending attempt that an address isn't deliverable, so there's no queuing and no retries 🏃‍♀️

When a submission or SMTP relay server rejects an envelope recipient because of a domain's null MX record, it SHOULD use a 556 reply code [RFC7504] (Requested action not taken: domain does not accept mail) and a 5.1.10 enhanced status code (Permanent failure: Recipient address has null MX) 🍓

A receiving SMTP server that chooses to reject email during the SMTP conversation, because the RFC5321.MailFrom or RFC5322.From domain is undeliverable, can be more confident that a later attempt to send a DSN or other response for other messages will reach a recipient SMTP server 🌈

SMTP servers that reject mail because an RFC5321.MailFrom or RFC5322.From domain has a null MX record SHOULD use a 550 reply code (Requested action not taken: mailbox unavailable) and a 5.7.27 enhanced status code (Permanent failure: Sender address has null MX) 👑

4.2. Sending Mail from Domains That Publish Null MX 🚫

Null MX is mainly for domains that don't send or receive any mail, but still get mail sent to them anyway because of mistakes or malice 😬 Lots of receiving systems reject mail with an invalid return address, since return addresses are how the sender handles delivery errors. An invalid return address often signals spam. So mail systems SHOULD NOT publish a null MX record for domains they use in RFC5321.MailFrom or RFC5322.From addresses. If a system does it anyway, it risks having its mail rejected 💀

Operators of domains that don't send mail can publish Sender Policy Framework (SPF) "-all" policies [RFC7208] to make an explicit declaration that those domains send no mail 💅

Null MX is not meant to replace the null reverse-path described in Section 4.5.5 of RFC 5321, and it doesn't change the meaning or use of a null reverse-path 🙅‍♀️

5. Security Considerations 🔐

Within the DNS, a null MX RR is an ordinary MX record, so it presents no new security issues 🛡️ If you want, you can secure it the same way as any other DNS record using DNSSEC. Anyway, a null MX doesn't add any new security drama, and that's the iconic part 😌

6. IANA Considerations 🌸

IANA added the following entries to the "Enumerated Status Codes" subregistry of the "Simple Mail Transfer Protocol (SMTP) Enhanced Status Codes Registry" 🧾

Code:              X.1.10
Sample Text:       Recipient address has null MX
Associated basic status code:  556
Description:       This status code is returned when the associated
                   address is marked as invalid using a null MX.
Reference:         This document
Submitter:         Authors of this document
Change controller: IESG

Code:              X.7.27
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:         This document
Submitter:         Authors of this document
Change controller: IESG

7. References 📚

7.1. Normative References

[RFC1035]  Mockapetris, P., "Domain names - implementation and
           specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
           November 1987, <http://www.rfc-editor.org/info/rfc1035>.

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <http://www.rfc-editor.org/info/rfc2119>.

[RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
           DOI 10.17487/RFC5321, October 2008,
           <http://www.rfc-editor.org/info/rfc5321>.

[RFC7504]  Klensin, J., "SMTP 521 and 556 Reply Codes", RFC 7504,
           DOI 10.17487/RFC7504, June 2015,
           <http://www.rfc-editor.org/info/rfc7504>.

7.2. Informative References

[RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
           specifying the location of services (DNS SRV)", RFC 2782,
           DOI 10.17487/RFC2782, February 2000,
           <http://www.rfc-editor.org/info/rfc2782>.

[RFC5598]  Crocker, D., "Internet Mail Architecture", RFC 5598,
           DOI 10.17487/RFC5598, July 2009,
           <http://www.rfc-editor.org/info/rfc5598>.

[RFC7208]  Kitterman, S., "Sender Policy Framework (SPF) for
           Authorizing Use of Domains in Email, Version 1", RFC 7208,
           DOI 10.17487/RFC7208, April 2014,
           <http://www.rfc-editor.org/info/rfc7208>.

Acknowledgements 🫶

Big thanks to Dave Crocker for his diligent and lengthy shepherding of this document, and to the members of the APPSAWG working group for their constructive suggestions 💜

Authors' Addresses 💌

John Levine
Taughannock Networks
PO Box 727
Trumansburg, NY  14886
United States

Phone: +1 831 480 2300
Email: standards@taugh.com
URI:   http://jl.ly


Mark Delany
Apple Inc.
1 Infinite Loop
Cupertino, CA  95014
United States

Email: mx0dot@yahoo.com
📦 where this page comes from