idnits 2.17.1 draft-delany-nullmx-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 3, 2014) is 3764 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC4408' is mentioned on line 199, but not defined ** Obsolete undefined reference: RFC 4408 (Obsoleted by RFC 7208) == Unused Reference: 'RFC1034' is defined on line 188, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 191, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Levine 3 Internet-Draft Taughannock Networks 4 Intended status: Standards Track M. Delany 5 Expires: July 7, 2014 Apple Inc. 6 January 3, 2014 8 A NULL MX Resource Record for Domains that Accept No Mail 9 draft-delany-nullmx-02 11 Abstract 13 When the 5321.MailFrom domain in an e-mail message has a DNS MX 14 Resource Record (RR), it is making an explicit statement that it is 15 willing to accept email. However, when the domain has just a DNS A 16 or AAAA RR, there mail clients cannot easily tell whether the domain 17 accepts mail, as many hosts on the Internet advertise an A or AAAA RR 18 regardless of whether they want to accept email. 20 The NULL MX RR formalizes the existing mechanism by which a domain 21 announces that it accepts no mail. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on July 7, 2014. 40 Copyright Notice 42 Copyright (c) 2014 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. SMTP server benefits . . . . . . . . . . . . . . . . . . . . 3 59 3. Parallel Considerations . . . . . . . . . . . . . . . . . . . 3 60 4. The NULL MX Resource Record . . . . . . . . . . . . . . . . . 4 61 5. Domains that do not send mail . . . . . . . . . . . . . . . . 4 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 63 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 65 7.2. Inforrmative References . . . . . . . . . . . . . . . . . 5 66 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 5 67 A.1. Change from -01 to -02 . . . . . . . . . . . . . . . . . 5 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 70 1. Introduction 72 This document formally defines the "NULL MX" as a simple mechanism by 73 which a domain can indicate that it will never accept email. 75 SMTP clients have a prescribed sequence for resolving how to deliver 76 email to a domain. Section 5 of [RFC5321] covers this in detail, but 77 in essence the SMTP client first looks up a DNS MX RR and if that is 78 not found it falls back to looking up a DNS A or AAAA RR. 80 Many domains do not accept email, but do have A or AAAA records. If 81 they have no MX records, senders will attempt to deliver mail to 82 those A or AAAA records. 84 If there is no SMTP listener at that address, the message will be 85 attempted repeatedly for a long period, typically a week, before the 86 sending MTA gives up. This will delay notification to the sender in 87 the case of misdirected mail, and will consume resources at the 88 sender. 90 If the domain has an SMTP listener at that address that rejects all 91 connections (for instance with a 554 response as a connection-opening 92 response) or has MX records pointing to such a listener then the 93 sender will be notified in a timely fashion, but resources 94 (generating a bounce) will still be consumed by the sender and it 95 requires additional services to be provided which provide little 96 benefit to the domain. 98 These resource usage problems are exacerbated when large volumes of 99 email are sent using forged email addresses in a domain which does 100 not accept email as its envelope sender, causing large numbers of 101 bounces to be generated and to consume large amounts of resources at 102 the sender of the bounces. 104 This document defines a NULL MX that will cause all mail delivery 105 attempts to a domain to fail immediately, without any reconfiguration 106 of existing MTAs. 108 2. SMTP server benefits 110 Being able to detect domains that never accept email offers many 111 resource savings to an SMTP server. In the first instance, it can 112 choose to reject email during the SMTP conversation that does not 113 present a deliverable 5321.MailFrom domain. 115 In the second instance, if an SMTP server accepts an email, it can be 116 confident that an attempt to send a non-delivery email will likely be 117 answered by another SMTP server. This greatly helps to reduce non- 118 delivery queues. This contrasts greatly with the current situation 119 where a non-delivery email for, e.g., www.example.net, will sit in 120 the queue for a full queue lifetime as SMTP connection attempts to 121 www.example.net simply time out. 123 3. Parallel Considerations 125 Clearly the perpetrators of abusive mail can adapt such that the 126 "vast class of email" that this mechanism helps identify, simply move 127 over to using 5321.MailFrom domains that have valid MX RRs. 129 While this is true, the direct benefits to the SMTP server still 130 apply. When an SMTP server queues a non-delivery email, the target 131 domain will accept the email or give a definitive rejection so the 132 queue entry will be removed promptly, thus keeping the queues short. 134 There is also a fair amount of mail that is just misaddressed by 135 people who mistranscribed or misunderstood an e-mail address, for 136 example, alice@www.example.com or alice@examp1e.com rather than 137 alice@example.com. NULL MX allows a mail system to report the 138 delivery failure when the user sends the message, rather than hours 139 or days later. 141 4. The NULL MX Resource Record 143 To indicate that a domain never accepts email, it advertises a single 144 MX RR with a RDATA section consisting of preference number 0, and a 145 dot, i.e., the DNS root, as the mail exchanger domain, to denote that 146 there exists no mail exchanger for a domain. (The DNS root is not a 147 valid host name, which avoids any possibility that a NULL MX record 148 could be confused with an ordinary MX record.) 150 The interpretation of a NULL MX RR only applies when the domain has a 151 single MX RR. If a domain advertises multiple MX RRs including a 152 NULL MX, the interpretation is as described in RFC5321. 154 5. Domains that do not send mail 156 An SMTP server when presented with an "I never accept email" MX might 157 decline to accept such email as it knows that a response or non- 158 delivery notice will never be accepted, and that legitimate mail 159 rarely comes from domains that do not accept replies. 161 SMTP servers that reject mail because a MAIL FROM domain has a NULL 162 MX record should use a 550 reply code. 164 Although NULL MX may imply that a domain sends no mail, it does not 165 sat so explicitly. Operators may want to publish SPF [RFC4408] -ALL 166 policies to make an explicit statement. 168 6. Security Considerations 170 SMTP mail is inherently insecure in that it is feasible for even 171 fairly casual users to negotiate directly with SMTP servers. This 172 proposal is about eliminating one small section of SMTP insecurity. 174 In the unlikely event that a domain legitimately sends email but 175 never wants to receive email, SMTP servers that reject mail from 176 domains that advertise a NULL MX risk losing email from those 177 domains. Note that the normal way to send mail for which a sender 178 wants no responses remains unchanged, by using an empty 5321.MailFrom 179 address. 181 Within the DNS, a NULL MX RR is an ordinary MX record and presents no 182 new security issues. 184 7. References 186 7.1. Normative References 188 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 189 STD 13, RFC 1034, November 1987. 191 [RFC1035] Mockapetris, P., "Domain names - implementation and 192 specification", STD 13, RFC 1035, November 1987. 194 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 195 October 2008. 197 7.2. Inforrmative References 199 [RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) 200 for Authorizing Use of Domains in E-Mail, Version 1", RFC 201 4408, April 2006. 203 Appendix A. Change Log 205 *NOTE TO RFC EDITOR: This section may be removed upon publication of 206 this document as an RFC.* 208 A.1. Change from -01 to -02 210 Note that SPF -ALL is how you say you send no mail. 212 Authors' Addresses 214 John Levine 215 Taughannock Networks 216 PO Box 727 217 Trumansburg, NY 14886 219 Phone: +1 831 480 2300 220 Email: standards@taugh.com 221 URI: http://jl.ly 223 Mark Delany 224 Apple Inc. 225 1 Infinite Loop 226 Cupertino, CA 95014 228 Email: mx0dot@yahoo.com