idnits 2.17.1 draft-ietf-appsawg-nullmx-03.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 date (June 4, 2014) is 3586 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: 'RFC7208' is mentioned on line 216, but not defined == Missing Reference: 'RFC5598' is mentioned on line 213, but not defined Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). 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: December 6, 2014 Apple Inc. 6 June 4, 2014 8 A NULL MX Resource Record for Domains that Accept No Mail 9 draft-ietf-appsawg-nullmx-03 11 Abstract 13 Internet mail determines the address of a receiving server through 14 the DNS, first by looking for an MX record and then by looking for an 15 A/AAAA record as a fallback. Unfortunately this means that the A/ 16 AAAA record is taken to be mail server address even when that address 17 does not accept mail. The NULL MX RR formalizes the existing 18 mechanism by which a domain announces that it accepts no mail, which 19 permits significant operational efficiencies. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on December 6, 2014. 38 Copyright Notice 40 Copyright (c) 2014 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 3. SMTP Server Benefits . . . . . . . . . . . . . . . . . . . . 3 57 4. Parallel Considerations . . . . . . . . . . . . . . . . . . . 3 58 5. The NULL MX Resource Record . . . . . . . . . . . . . . . . . 4 59 6. Domains that Do Not Send Mail . . . . . . . . . . . . . . . . 4 60 7. Security Considerations . . . . . . . . . . . . . . . . . . . 4 61 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 63 8.2. Inforrmative References . . . . . . . . . . . . . . . . . 5 64 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 5 65 A.1. Change to appsawg-nullmx-03 . . . . . . . . . . . . . . . 5 66 A.2. Change to appsawg-nullmx-02 . . . . . . . . . . . . . . . 5 67 A.3. Change to appsawg-nullmx-1 . . . . . . . . . . . . . . . 6 68 A.4. Change to appsawg-nullmx-0 . . . . . . . . . . . . . . . 6 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 71 1. Conventions Used in This Document 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in [RFC2119]. 77 2. Introduction 79 This document formally defines the "NULL MX" as a simple mechanism by 80 which a domain can indicate that it does not accept email. 82 SMTP clients have a prescribed sequence for identifying a server that 83 accepts email for a domain. Section 5 of [RFC5321] covers this in 84 detail, but in essence the SMTP client first looks up a DNS MX RR and 85 if that is not found it falls back to looking up a DNS A or AAAA RR. 86 Hence this overloads an email service semantic onto a DNS record with 87 a different primary mission. 89 If a domain has no MX records, senders will attempt to deliver mail 90 to the hosts at the domain's A or AAAA record's addresses. However 91 many domains do not accept email. 93 If there is no SMTP listener at the A/AAAA address, message delivery 94 will be attempted repeatedly for a long period, typically a week, 95 before the sending MTA gives up. This will delay notification to the 96 sender in the case of misdirected mail, and will consume resources at 97 the sender. 99 An operator could set up an SMTP listener at that address that 100 rejects all connections (for instance with a 554 reply code as a 101 connection-opening response) or have an MX record pointing to such a 102 listener, to notify senders in a timely fashion. But resources 103 (generating a bounce) will still be consumed by the sender and it 104 requires additional services that offer little benefit to the domain. 106 These resource usage problems are exacerbated when large volumes of 107 email are sent using forged email addresses from a domain that does 108 not accept email as its envelope sender, causing large numbers of 109 bounces to be generated and to consume large amounts of resources at 110 the senders of the bounces. 112 This document defines a NULL MX that will cause all mail delivery 113 attempts to a domain to fail immediately, without requiring domains 114 to create SMTP listeners dedicated to preventing delivery attempts. 116 3. SMTP Server Benefits 118 The ability to detect domains that do not accept email offers many 119 resource savings to an SMTP server. It can choose to reject email 120 during the SMTP conversation that presents an undeliverable 121 RFC5321.MailFrom domain. A sending server will discover on the first 122 sending attempt that an address is not deliverable, avoiding queuing 123 and retries. 125 Also, if an SMTP server accepts a message, it can be more confident 126 that an attempt to send a Delivery Status Notification or other 127 response will reach a recipient SMTP server. 129 4. Parallel Considerations 131 Senders of abusive email often use return addresses with domain names 132 that do not accept mail. These senders typically adapt quickly, and 133 would move over to using RFC5321.MailFrom domains that have valid MX 134 RRs. 136 While this is true, the direct benefits to the SMTP server still 137 apply. When an SMTP server queues a non-delivery email, the target 138 domain will accept the email or give a definitive rejection so the 139 queue entry will be removed promptly, thus keeping the queues short. 141 There is also a fair amount of mail that is just misaddressed by 142 people who mistranscribed or misunderstood an e-mail address, for 143 example, alice@www.example.com or alice@example.org or 144 alice@examp1e.com rather than alice@example.com. NULL MX allows a 145 mail system to report the delivery failure when the user sends the 146 message, rather than hours or days later. 148 5. The NULL MX Resource Record 150 To indicate that a domain does not accept email, it advertises a 151 single MX RR (see [RFC1035], section 3.3.9) with an RDATA section 152 consisting of preference number 0, and a dot, i.e., the DNS root, as 153 the exchange domain, to denote that there exists no mail exchanger 154 for a domain. (The DNS root is not a valid host name, which avoids 155 any possibility that a NULL MX record could be confused with an 156 ordinary MX record.) 158 The interpretation of a NULL MX RR only applies when the domain has a 159 single MX RR. A domain SHOULD NOT advertise multiple MX RRs 160 including a NULL MX, but if it does, the interpretation is as 161 described in [RFC5321]. 163 6. Domains that Do Not Send Mail 165 The operator of an SMTP server might prefer to reject mail sent from 166 domains that publish NULL MX, since a response or non-delivery notice 167 will not be accepted, and legitimate mail rarely comes from domains 168 that do not accept replies. 170 SMTP servers that reject mail because a MAIL FROM domain has a NULL 171 MX record SHOULD use a 550 reply code and a 5.1.2 enhanced status 172 code [RFC3463]. 174 A domain that does not accept mail, as declared by NULL MX, often 175 will also not send mail. Operators can publish SPF [RFC7208] -all 176 policies to make an explicit declaration that the domain is not valid 177 in the RFC5321.MailFrom command. 179 7. Security Considerations 181 SMTP mail is inherently insecure in that it is feasible for even 182 fairly casual users to negotiate directly with SMTP servers. This 183 specification is about eliminating one small section of SMTP 184 insecurity. 186 In the unlikely event that a domain legitimately sends email but does 187 not want to receive email, SMTP servers that reject mail from domains 188 that advertise a NULL MX risk losing email from those domains. The 189 normal way to send mail for which a sender wants no responses remains 190 unchanged, by using an empty RFC5321.MailFrom address. 192 Within the DNS, a NULL MX RR is an ordinary MX record and presents no 193 new security issues. 195 8. References 197 8.1. Normative References 199 [RFC1035] Mockapetris, P., "Domain names - implementation and 200 specification", STD 13, RFC 1035, November 1987. 202 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 203 Requirement Levels", BCP 14, RFC 2119, March 1997. 205 [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 206 3463, January 2003. 208 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 209 October 2008. 211 8.2. Inforrmative References 213 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July 214 2009. 216 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for 217 Authorizing Use of Domains in Email, Version 1", RFC 7208, 218 April 2014. 220 Appendix A. Change Log 222 *NOTE TO RFC EDITOR: This section may be removed upon publication of 223 this document as an RFC.* 225 A.1. Change to appsawg-nullmx-03 227 Editorial nits per Murray. 229 A.2. Change to appsawg-nullmx-02 231 Should not publish NULL MX with other MX. 233 Never say never. 235 Add 5.1.2 enhanced status code. 237 Minor editorial changes. 239 A.3. Change to appsawg-nullmx-1 241 Editorial improvements per D. Crocker's review. 243 A.4. Change to appsawg-nullmx-0 245 Fix typos. 247 Authors' Addresses 249 John Levine 250 Taughannock Networks 251 PO Box 727 252 Trumansburg, NY 14886 254 Phone: +1 831 480 2300 255 Email: standards@taugh.com 256 URI: http://jl.ly 258 Mark Delany 259 Apple Inc. 260 1 Infinite Loop 261 Cupertino, CA 95014 263 Email: mx0dot@yahoo.com