INTERNET DRAFT Mark Delany, Editor Title: draft-delany-nullmx-00.txt Yahoo! Inc Expires: 4 October 2005 5 April 2005 A NULL MX Resource Record means "I never accept email" Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract A common strategy of SMTP servers when deciding whether to accept an email or not, is to ensure that the 2821.MailFrom contains a domain willing to accept non-delivery email (aka bounces). When the 2821.MailFrom domain has a DNS MX Resource Record (RR), it is making an explicit statement that it is willing to accept email. However, when the domain has just a DNS A (or AAAA) RR, there is no such clarity as most hosts on the Internet advertise an A RR regardless of whether they want to accept email or not. The NULL MX RR formalizes the existing mechanism by which a domain communicates that it will never accept email. Delany Expires October, 2005 [Page 1]
Internet-Draft NULL MX April 2005 Introduction This document formally defines the "NULL MX" as a simple mechanism by which a domain can indicate that it will never accept email. SMTP clients have a prescribed sequence for resolving how to deliver email to a domain. Section 5 of RFC2821 [RFC2821] covers this in detail, but in essence the SMTP client first looks up a DNS MX RR and if that is not found it falls back to looking up a DNS A RR. However, many domains do not accept email, but do have A records. If they have no MX records then senders will attempt to deliver mail to those A records. If there is no SMTP listener at that address then the message will be attempted repeatedly for a long period before the sending MTA gives up on delivery. This will delay notification to the sender in the case of misdirected mail, and will consume resources at the sender. If the domain has an SMTP listener at that address that rejects all connections (for instance with a 554 response as a connection-opening response) or has MX records pointing to such a listener then the sender will be notified in a timely fashion, but resources (generating a bounce) will still be consumed by the sender and it requires additional services to be provided which wouldn't usually be needed. These resource usage problems are exacerbated when large volumes of email are sent using falsified email addresses in a domain which does not accept email as its envelope sender, causing large numbers of bounces to be generated and to consume large amounts of resources (spool space and outgoing TCP sessions) at the sender of the bounces. This document formally defines a NULL MX as an alternative which will cause all mail delivery attempts to a domain to fail immediately, without any reconfiguration of existing MTAs. SMTP server benefits Being able to detect domains that never accept email offers many resource savings to an SMTP server. In the first instance, it can choose to reject email during the SMTP conversation that does not present a deliverable 2821.MailFrom domain. In the second instance, if an SMTP server accepts an email, it can be confident that an attempt to send a non-delivery email will likely be answered by another SMTP server. This greatly helps to reduce non-delivery queues. This contrasts greatly with the current situation where a non-delivery email for, eg, www.example.net, will sit in the queue for a full queue lifetime as SMTP connection attempts to Delany Expires October, 2005 [Page 2]
Internet-Draft NULL MX April 2005 www.example.net simply timeout. Parallel Considerations Clearly the perpetrators of abusive mail can adapt such that the "vast class of email" that this mechanism helps identify, simply move over to using 2821.MailFrom domains that have valid MX RRs. Certainly this is true, but the direct benefits to the SMTP server still apply. When an SMTP server queues a non-delivery email, the target domain will accept the email or give a definitive rejection so the queue entry will be removed promptly, thus keeping the queues short. More importantly, there are parallel developments in Internet email, particularly in sender authentication, that provide better mechanisms for SMTP servers to authenticate email from those domains that do legitimately accept email. The NULL MX Resource Record To indicate that a domain never accepts email, it advertises a solitary MX RR with a RDATA section consisting of an arbitrary preference number 0, and a dot terminated null string as the mail exchanger domain, to denote that there exists no mail exchanger for a domain. The dot termination denotes that the null MX domain is considered to be absolute, and not relative to the origin of the zone, the behavior of dot termination and the formatting of this record is as described in STD13 [STD13]. The interpretation of a NULL MX RR only applies when the domain as a single MX RR. If a domain advertises multiple MX RRs, the interpretation is unchanged from that defined by RFC2821. The "I never send email" Corollary A presumption of an SMTP server when presented with an "I never accept email MX" might be to decline to accept such email as it knows that a non-delivery will never be accepted. SMTP servers MAY 550 reject mail sent by a MAIL FROM domain that has a NULL MX record. Security Considerations SMTP mail is inherently insecure in that it is feasible for even Delany Expires October, 2005 [Page 3]
Internet-Draft NULL MX April 2005 fairly casual users to negotiate directly with SMTP servers. This proposal is about eliminating one small section of SMTP insecurity. It is claimed that there are legitimate cases where a domain may send email but never wants to receive email. SMTP servers that reject mail from domains that advertise a NULL MX risk losing email from those domains. Normative References [STD13] Mockapetris, P., DOMAIN NAMES - CONCEPTS AND FACILITIES", STD 13, November, 1987. [RFC2821] Klesin, J., Editor, "Simple Mail Transfer Protocol", RFC 2821, April 2001. Acknowledgments The editor wishes to thank Steve Atkins, James Lick, John Levine, der Mouse, Daniel Quinlan and Suresh Ramasubramanian for their valuable suggestions and constructive criticism. Editor's Address Mark Delany Yahoo! Inc 701 First Avenue Sunnyvale, CA 95087 USA Email: mx0dot@yahoo.com Please send comments to the editor at the above address. This feedback email address will remain valid until this draft expires or is replaced with a subsequent revision. Copyright Notice Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE Delany Expires October, 2005 [Page 4]
Internet-Draft NULL MX April 2005 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. RCS: $Id: draft-delany-nullmx-00.txt,v 1.2 2005/04/05 15:42:29 markd Exp $ Delany Expires October, 2005 [Page 5]