idnits 2.17.1 draft-delany-nullmx-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 12. -- Found old boilerplate from RFC 3978, Section 5.5 on line 191. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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.) ** There is 1 instance of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([STD13], [RFC2821]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 134: '...SMTP servers MAY 550 reject mail sent ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (5 April 2005) is 6961 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'STD13' ** Obsolete normative reference: RFC 2821 (Obsoleted by RFC 5321) Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT Mark Delany, Editor 2 Title: draft-delany-nullmx-00.txt Yahoo! Inc 3 Expires: 4 October 2005 5 April 2005 5 A NULL MX Resource Record means "I never accept email" 7 Status of this Memo 9 By submitting this Internet-Draft, each author represents that any 10 applicable patent or other IPR claims of which he or she is aware have 11 been or will be disclosed, and any of which he or she becomes aware 12 will be disclosed, in accordance with Section 6 of BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering Task 15 Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/1id-abstracts.html 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html 29 Abstract 31 A common strategy of SMTP servers when deciding whether to accept an 32 email or not, is to ensure that the 2821.MailFrom contains a domain 33 willing to accept non-delivery email (aka bounces). 35 When the 2821.MailFrom domain has a DNS MX Resource Record (RR), it is 36 making an explicit statement that it is willing to accept 37 email. However, when the domain has just a DNS A (or AAAA) RR, there 38 is no such clarity as most hosts on the Internet advertise an A RR 39 regardless of whether they want to accept email or not. 41 The NULL MX RR formalizes the existing mechanism by which a domain 42 communicates that it will never accept email. 44 Introduction 46 This document formally defines the "NULL MX" as a simple mechanism by 47 which a domain can indicate that it will never accept email. 49 SMTP clients have a prescribed sequence for resolving how to deliver 50 email to a domain. Section 5 of RFC2821 [RFC2821] covers this in 51 detail, but in essence the SMTP client first looks up a DNS MX RR and 52 if that is not found it falls back to looking up a DNS A RR. 54 However, many domains do not accept email, but do have A records. If 55 they have no MX records then senders will attempt to deliver mail to 56 those A records. 58 If there is no SMTP listener at that address then the message will be 59 attempted repeatedly for a long period before the sending MTA gives up 60 on delivery. This will delay notification to the sender in the case of 61 misdirected mail, and will consume resources at the sender. 63 If the domain has an SMTP listener at that address that rejects all 64 connections (for instance with a 554 response as a connection-opening 65 response) or has MX records pointing to such a listener then the 66 sender will be notified in a timely fashion, but resources (generating 67 a bounce) will still be consumed by the sender and it requires 68 additional services to be provided which wouldn't usually be needed. 70 These resource usage problems are exacerbated when large volumes of 71 email are sent using falsified email addresses in a domain which does 72 not accept email as its envelope sender, causing large numbers of 73 bounces to be generated and to consume large amounts of resources 74 (spool space and outgoing TCP sessions) at the sender of the bounces. 76 This document formally defines a NULL MX as an alternative which will 77 cause all mail delivery attempts to a domain to fail immediately, 78 without any reconfiguration of existing MTAs. 80 SMTP server benefits 82 Being able to detect domains that never accept email offers many 83 resource savings to an SMTP server. In the first instance, it can 84 choose to reject email during the SMTP conversation that does not 85 present a deliverable 2821.MailFrom domain. 87 In the second instance, if an SMTP server accepts an email, it can be 88 confident that an attempt to send a non-delivery email will likely be 89 answered by another SMTP server. This greatly helps to reduce 90 non-delivery queues. This contrasts greatly with the current situation 91 where a non-delivery email for, eg, www.example.net, will sit in the 92 queue for a full queue lifetime as SMTP connection attempts to 93 www.example.net simply timeout. 95 Parallel Considerations 97 Clearly the perpetrators of abusive mail can adapt such that the "vast 98 class of email" that this mechanism helps identify, simply move over 99 to using 2821.MailFrom domains that have valid MX RRs. 101 Certainly this is true, but the direct benefits to the SMTP server still 102 apply. When an SMTP server queues a non-delivery email, the target 103 domain will accept the email or give a definitive rejection so the queue 104 entry will be removed promptly, thus keeping the queues short. 106 More importantly, there are parallel developments in Internet email, 107 particularly in sender authentication, that provide better mechanisms 108 for SMTP servers to authenticate email from those domains that do 109 legitimately accept email. 111 The NULL MX Resource Record 113 To indicate that a domain never accepts email, it advertises a 114 solitary MX RR with a RDATA section consisting of an arbitrary 115 preference number 0, and a dot terminated null string as the mail 116 exchanger domain, to denote that there exists no mail exchanger for a 117 domain. 119 The dot termination denotes that the null MX domain is considered to 120 be absolute, and not relative to the origin of the zone, the behavior 121 of dot termination and the formatting of this record is as described 122 in STD13 [STD13]. 124 The interpretation of a NULL MX RR only applies when the domain as a 125 single MX RR. If a domain advertises multiple MX RRs, the 126 interpretation is unchanged from that defined by RFC2821. 128 The "I never send email" Corollary 130 A presumption of an SMTP server when presented with an "I never accept 131 email MX" might be to decline to accept such email as it knows that a 132 non-delivery will never be accepted. 134 SMTP servers MAY 550 reject mail sent by a MAIL FROM domain that has a 135 NULL MX record. 137 Security Considerations 139 SMTP mail is inherently insecure in that it is feasible for even 140 fairly casual users to negotiate directly with SMTP servers. This 141 proposal is about eliminating one small section of SMTP insecurity. 143 It is claimed that there are legitimate cases where a domain may send 144 email but never wants to receive email. SMTP servers that reject mail 145 from domains that advertise a NULL MX risk losing email from those 146 domains. 148 Normative References 150 [STD13] Mockapetris, P., DOMAIN NAMES - CONCEPTS AND 151 FACILITIES", STD 13, November, 1987. 153 [RFC2821] Klesin, J., Editor, "Simple Mail Transfer Protocol", 154 RFC 2821, April 2001. 156 Acknowledgments 158 The editor wishes to thank Steve Atkins, James Lick, John Levine, der 159 Mouse, Daniel Quinlan and Suresh Ramasubramanian for their valuable 160 suggestions and constructive criticism. 162 Editor's Address 164 Mark Delany 165 Yahoo! Inc 166 701 First Avenue 167 Sunnyvale, CA 95087 168 USA 170 Email: mx0dot@yahoo.com 172 Please send comments to the editor at the above address. This feedback 173 email address will remain valid until this draft expires or is 174 replaced with a subsequent revision. 176 Copyright Notice 178 Copyright (C) The Internet Society (2005). 180 This document is subject to the rights, licenses and restrictions 181 contained in BCP 78, and except as set forth therein, the authors 182 retain all their rights. 184 This document and the information contained herein are provided on 185 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 186 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 187 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 188 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 189 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 190 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 191 PARTICULAR PURPOSE. 193 RCS: $Id: draft-delany-nullmx-00.txt,v 1.2 2005/04/05 15:42:29 markd Exp $