idnits 2.17.1 draft-ietf-emailcore-rfc5321bis-11.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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. -- The draft header indicates that this document obsoletes RFC7504, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document obsoletes RFC7505, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document obsoletes RFC1846, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (24 May 2022) is 701 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'JcK 20210904' on line 2641 -- Looks like a reference, but probably isn't: '5321bis' on line 5021 -- Duplicate reference: RFC20, mentioned in '3', was also mentioned in '2'. ** Obsolete normative reference: RFC 821 (ref. '4') (Obsoleted by RFC 2821) -- Obsolete informational reference (is this intentional?): RFC 822 (ref. '14') (Obsoleted by RFC 2822) -- Obsolete informational reference (is this intentional?): RFC 974 (ref. '17') (Obsoleted by RFC 2821) -- Obsolete informational reference (is this intentional?): RFC 1869 (ref. '23') (Obsoleted by RFC 2821) -- Obsolete informational reference (is this intentional?): RFC 2821 (ref. '31') (Obsoleted by RFC 5321) -- Obsolete informational reference (is this intentional?): RFC 3501 (ref. '37') (Obsoleted by RFC 9051) -- Duplicate reference: RFC5321, mentioned in '55', was also mentioned in '50'. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 EMAILCORE J. Klensin 3 Internet-Draft 24 May 2022 4 Obsoletes: 5321, 1846, 7504, 7505 (if approved) 5 Intended status: Standards Track 6 Expires: 25 November 2022 8 Simple Mail Transfer Protocol 9 draft-ietf-emailcore-rfc5321bis-11 11 Abstract 13 This document is a specification of the basic protocol for Internet 14 electronic mail transport. It (including text carried forward from 15 RFC 5321) consolidates, updates, and clarifies several previous 16 documents, making all or parts of most of them obsolete. It covers 17 the SMTP extension mechanisms and best practices for the contemporary 18 Internet, but does not provide details about particular extensions. 19 The document also provides information about use of SMTP for other 20 than strict mail transport and delivery. This document replaces RFC 21 5321, the earlier version with the same title. 23 Notes on Reading This Working Draft 25 Early versions of this working draft were extensively annotated with 26 information, primarily in about changes made over the decade since 27 RFC 5321 appeared, especially when those changes might be 28 controversial or should get careful review. Most of those 29 annotations and associated questions are marked in CREF comments 30 ("//" in the text form). Starting with version -09 of the draft, 31 annotations and notes that were no longer relevant are being pruned 32 to improve readability In general, any annotations or comments not 33 marked with "[[Note in Draft", in the contents of an "Editor's note", 34 or are in the "Errata Summary" appendix (Appendix I.1, they are just 35 notes on changes that have already been made and where those changes 36 originated. As one can tell from the dates (when they are given), 37 this document has been periodically updated over a very long period 38 of time. 40 As people review or try to use this document, it may be worth paying 41 special attention to the historical discussion in Section 1.2. 43 This evolving draft should be discussed on the emailcore@ietf.org 44 list. 46 Status of This Memo 48 This Internet-Draft is submitted in full conformance with the 49 provisions of BCP 78 and BCP 79. 51 Internet-Drafts are working documents of the Internet Engineering 52 Task Force (IETF). Note that other groups may also distribute 53 working documents as Internet-Drafts. The list of current Internet- 54 Drafts is at https://datatracker.ietf.org/drafts/current/. 56 Internet-Drafts are draft documents valid for a maximum of six months 57 and may be updated, replaced, or obsoleted by other documents at any 58 time. It is inappropriate to use Internet-Drafts as reference 59 material or to cite them other than as "work in progress." 61 This Internet-Draft will expire on 25 November 2022. 63 Copyright Notice 65 Copyright (c) 2022 IETF Trust and the persons identified as the 66 document authors. All rights reserved. 68 This document is subject to BCP 78 and the IETF Trust's Legal 69 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 70 license-info) in effect on the date of publication of this document. 71 Please review these documents carefully, as they describe your rights 72 and restrictions with respect to this document. Code Components 73 extracted from this document must include Revised BSD License text as 74 described in Section 4.e of the Trust Legal Provisions and are 75 provided without warranty as described in the Revised BSD License. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8 80 1.1. Transport of Electronic Mail . . . . . . . . . . . . . . 8 81 1.2. History and Context for This Document . . . . . . . . . . 8 82 1.3. Document Conventions . . . . . . . . . . . . . . . . . . 10 83 2. The SMTP Model . . . . . . . . . . . . . . . . . . . . . . . 10 84 2.1. Basic Structure . . . . . . . . . . . . . . . . . . . . . 10 85 2.2. The Extension Model . . . . . . . . . . . . . . . . . . . 12 86 2.2.1. Background . . . . . . . . . . . . . . . . . . . . . 12 87 2.2.2. Definition and Registration of Extensions . . . . . . 13 88 2.2.3. Special Issues with Extensions . . . . . . . . . . . 14 89 2.3. SMTP Terminology . . . . . . . . . . . . . . . . . . . . 14 90 2.3.1. Mail Objects . . . . . . . . . . . . . . . . . . . . 14 91 2.3.2. Senders and Receivers . . . . . . . . . . . . . . . . 15 92 2.3.3. Mail Agents and Message Stores . . . . . . . . . . . 15 93 2.3.4. Host . . . . . . . . . . . . . . . . . . . . . . . . 16 94 2.3.5. Domain Names . . . . . . . . . . . . . . . . . . . . 16 95 2.3.6. Buffer and State Table . . . . . . . . . . . . . . . 17 96 2.3.7. Commands and Replies . . . . . . . . . . . . . . . . 17 97 2.3.8. Lines . . . . . . . . . . . . . . . . . . . . . . . . 18 98 2.3.9. Message Content and Mail Data . . . . . . . . . . . . 18 99 2.3.10. Originator, Delivery, Relay, and Gateway Systems . . 18 100 2.3.11. Mailbox and Address . . . . . . . . . . . . . . . . . 19 101 2.4. General Syntax Principles and Transaction Model . . . . . 19 102 3. The SMTP Procedures: An Overview . . . . . . . . . . . . . . 21 103 3.1. Session Initiation . . . . . . . . . . . . . . . . . . . 21 104 3.2. Client Initiation . . . . . . . . . . . . . . . . . . . . 22 105 3.3. Mail Transactions . . . . . . . . . . . . . . . . . . . . 22 106 3.4. Address Modification and Expansion . . . . . . . . . . . 25 107 3.4.1. Forwarding for Address Correction or Updating . . . . 25 108 3.4.2. Aliases and Mailing Lists . . . . . . . . . . . . . . 26 109 3.4.2.1. Simple Aliases . . . . . . . . . . . . . . . . . 26 110 3.4.2.2. Mailing Lists . . . . . . . . . . . . . . . . . . 27 111 3.5. Commands for Debugging Addresses . . . . . . . . . . . . 27 112 3.5.1. Overview . . . . . . . . . . . . . . . . . . . . . . 27 113 3.5.2. VRFY Normal Response . . . . . . . . . . . . . . . . 29 114 3.5.3. Meaning of VRFY or EXPN Success Response . . . . . . 30 115 3.5.4. Semantics and Applications of EXPN . . . . . . . . . 30 116 3.6. Relaying and Mail Routing . . . . . . . . . . . . . . . . 31 117 3.6.1. Mail eXchange Records and Relaying . . . . . . . . . 31 118 3.6.2. Message Submission Servers as Relays . . . . . . . . 31 119 3.7. Mail Gatewaying . . . . . . . . . . . . . . . . . . . . . 32 120 3.7.1. Header Fields in Gatewaying . . . . . . . . . . . . . 33 121 3.7.2. Received Lines in Gatewaying . . . . . . . . . . . . 33 122 3.7.3. Addresses in Gatewaying . . . . . . . . . . . . . . . 33 123 3.7.4. Other Header Fields in Gatewaying . . . . . . . . . . 34 124 3.7.5. Envelopes in Gatewaying . . . . . . . . . . . . . . . 34 125 3.8. Terminating Sessions and Connections . . . . . . . . . . 34 126 4. The SMTP Specifications . . . . . . . . . . . . . . . . . . . 35 127 4.1. SMTP Commands . . . . . . . . . . . . . . . . . . . . . . 35 128 4.1.1. Command Semantics and Syntax . . . . . . . . . . . . 35 129 4.1.1.1. Extended HELLO (EHLO) or HELLO (HELO) . . . . . . 36 130 4.1.1.2. MAIL (MAIL) . . . . . . . . . . . . . . . . . . . 38 131 4.1.1.3. RECIPIENT (RCPT) . . . . . . . . . . . . . . . . 38 132 4.1.1.4. DATA (DATA) . . . . . . . . . . . . . . . . . . . 40 133 4.1.1.5. RESET (RSET) . . . . . . . . . . . . . . . . . . 41 134 4.1.1.6. VERIFY (VRFY) . . . . . . . . . . . . . . . . . . 42 135 4.1.1.7. EXPAND (EXPN) . . . . . . . . . . . . . . . . . . 42 136 4.1.1.8. HELP (HELP) . . . . . . . . . . . . . . . . . . . 42 137 4.1.1.9. NOOP (NOOP) . . . . . . . . . . . . . . . . . . . 43 138 4.1.1.10. QUIT (QUIT) . . . . . . . . . . . . . . . . . . . 43 139 4.1.2. Command Argument Syntax . . . . . . . . . . . . . . . 44 140 4.1.3. Address Literals . . . . . . . . . . . . . . . . . . 46 141 4.1.4. Order of Commands . . . . . . . . . . . . . . . . . . 47 143 4.2. SMTP Replies . . . . . . . . . . . . . . . . . . . . . . 49 144 4.2.1. Reply Code Severities and Theory . . . . . . . . . . 51 145 4.2.2. Reply Codes by Function Groups . . . . . . . . . . . 53 146 4.2.3. Reply Codes in Numeric Order . . . . . . . . . . . . 55 147 4.2.4. Some specific code situations and relationships . . . 56 148 4.2.4.1. Reply Code 502 . . . . . . . . . . . . . . . . . 56 149 4.2.4.2. "No mail accepted" situations and the 521, 554, and 150 556 codes . . . . . . . . . . . . . . . . . . . . . 57 151 4.2.4.3. Reply Codes after DATA and the Subsequent 152 . . . . . . . . . . . . . . . . . . . . 58 153 4.3. Sequencing of Commands and Replies . . . . . . . . . . . 58 154 4.3.1. Sequencing Overview . . . . . . . . . . . . . . . . . 59 155 4.3.2. Command-Reply Sequences . . . . . . . . . . . . . . . 59 156 4.4. Trace Information . . . . . . . . . . . . . . . . . . . . 62 157 4.4.1. Received Header Field . . . . . . . . . . . . . . . . 62 158 4.5. Additional Implementation Issues . . . . . . . . . . . . 66 159 4.5.1. Minimum Implementation . . . . . . . . . . . . . . . 66 160 4.5.2. Transparency . . . . . . . . . . . . . . . . . . . . 66 161 4.5.3. Sizes and Timeouts . . . . . . . . . . . . . . . . . 67 162 4.5.3.1. Size Limits and Minimums . . . . . . . . . . . . 67 163 4.5.3.1.1. Local-part . . . . . . . . . . . . . . . . . 67 164 4.5.3.1.2. Domain . . . . . . . . . . . . . . . . . . . 68 165 4.5.3.1.3. Path . . . . . . . . . . . . . . . . . . . . 68 166 4.5.3.1.4. Command Line . . . . . . . . . . . . . . . . 68 167 4.5.3.1.5. Reply Line . . . . . . . . . . . . . . . . . 68 168 4.5.3.1.6. Text Line . . . . . . . . . . . . . . . . . . 68 169 4.5.3.1.7. Message Content . . . . . . . . . . . . . . . 68 170 4.5.3.1.8. Recipient Buffer . . . . . . . . . . . . . . 68 171 4.5.3.1.9. Treatment When Limits Exceeded . . . . . . . 69 172 4.5.3.1.10. Too Many Recipients Code . . . . . . . . . . 69 173 4.5.3.2. Timeouts . . . . . . . . . . . . . . . . . . . . 70 174 4.5.3.2.1. Initial 220 Message: 5 Minutes . . . . . . . 70 175 4.5.3.2.2. MAIL Command: 5 Minutes . . . . . . . . . . . 70 176 4.5.3.2.3. RCPT Command: 5 Minutes . . . . . . . . . . . 70 177 4.5.3.2.4. DATA Initiation: 2 Minutes . . . . . . . . . 70 178 4.5.3.2.5. Data Block: 3 Minutes . . . . . . . . . . . . 70 179 4.5.3.2.6. DATA Termination: 10 Minutes. . . . . . . . . 71 180 4.5.3.2.7. Server Timeout: 5 Minutes. . . . . . . . . . 71 181 4.5.4. Retry Strategies . . . . . . . . . . . . . . . . . . 71 182 4.5.5. Messages with a Null Reverse-Path . . . . . . . . . . 73 183 5. Address Resolution and Mail Handling . . . . . . . . . . . . 74 184 5.1. Locating the Target Host . . . . . . . . . . . . . . . . 74 185 5.2. IPv6 and MX Records . . . . . . . . . . . . . . . . . . . 76 186 6. Problem Detection and Handling . . . . . . . . . . . . . . . 76 187 6.1. Reliable Delivery and Replies by Email . . . . . . . . . 77 188 6.2. Unwanted, Unsolicited, and "Attack" Messages . . . . . . 77 189 6.3. Loop Detection . . . . . . . . . . . . . . . . . . . . . 78 190 6.4. Compensating for Irregularities . . . . . . . . . . . . . 78 192 7. Security Considerations . . . . . . . . . . . . . . . . . . . 80 193 7.1. Mail Security and Spoofing . . . . . . . . . . . . . . . 80 194 7.2. "Blind" Copies . . . . . . . . . . . . . . . . . . . . . 81 195 7.3. VRFY, EXPN, and Security . . . . . . . . . . . . . . . . 82 196 7.4. Mail Rerouting Based on the 251 and 551 Response Codes . 82 197 7.5. Information Disclosure in Announcements . . . . . . . . . 83 198 7.6. Information Disclosure in Trace Fields . . . . . . . . . 83 199 7.7. Information Disclosure in Message Forwarding . . . . . . 83 200 7.8. Local Operational Requirements and Resistance to 201 Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 83 202 7.9. Scope of Operation of SMTP Servers . . . . . . . . . . . 84 203 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 84 204 8.1. SMTP-related Registries . . . . . . . . . . . . . . . . . 84 205 8.2. New Registry Actions with . . . . . . . . 85 206 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 86 207 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 86 208 10.1. Normative References . . . . . . . . . . . . . . . . . . 86 209 10.2. Informative References . . . . . . . . . . . . . . . . . 88 210 Appendix A. TCP Transport Service . . . . . . . . . . . . . . . 92 211 Appendix B. Generating SMTP Commands from RFC 822 Header 212 Fields . . . . . . . . . . . . . . . . . . . . . . . . . 92 213 Appendix C. Placeholder (formerly Source Routes) . . . . . . . . 93 214 Appendix D. Scenarios . . . . . . . . . . . . . . . . . . . . . 93 215 D.1. A Typical SMTP Transaction Scenario . . . . . . . . . . . 94 216 D.2. Aborted SMTP Transaction Scenario . . . . . . . . . . . . 94 217 D.3. Relayed Mail Scenario . . . . . . . . . . . . . . . . . . 95 218 D.4. Verifying and Sending Scenario . . . . . . . . . . . . . 97 219 Appendix E. Other Gateway Issues . . . . . . . . . . . . . . . . 98 220 Appendix F. Deprecated Features of RFC 821 . . . . . . . . . . . 98 221 F.1. TURN . . . . . . . . . . . . . . . . . . . . . . . . . . 99 222 F.2. Source Routing . . . . . . . . . . . . . . . . . . . . . 99 223 F.3. HELO . . . . . . . . . . . . . . . . . . . . . . . . . . 100 224 F.4. #-literals . . . . . . . . . . . . . . . . . . . . . . . 100 225 F.5. Dates and Years . . . . . . . . . . . . . . . . . . . . . 101 226 F.6. Sending versus Mailing . . . . . . . . . . . . . . . . . 101 227 Appendix G. Other Outstanding Issues . . . . . . . . . . . . . . 101 228 G.1. IP Address literals . . . . . . . . . . . . . . . . . . . 102 229 G.2. Repeated Use of EHLO (closed) . . . . . . . . . . . . . . 102 230 G.3. Meaning of "MTA" and Related Terminology . . . . . . . . 102 231 G.4. Originator, or Originating System, Authentication . . . . 102 232 G.5. Remove or deprecate the work-around from code 552 to 233 452 . . . . . . . . . . . . . . . . . . . . . . . . . . 102 234 G.6. Clarify where the protocol stands with respect to 235 submission and TLS issues . . . . . . . . . . . . . . . 102 236 G.7. Probably-substantive Discussion Topics Identified in Other 237 Ways . . . . . . . . . . . . . . . . . . . . . . . . . . 103 238 G.7.1. Issues with 521, 554, and 556 codes (closed) . . . . 103 239 G.7.2. SMTP Model, terminology, and relationship to RFC 240 5598 . . . . . . . . . . . . . . . . . . . . . . . . 103 241 G.7.3. Resolvable FQDNs and private domain names (closed) . 103 242 G.7.4. Possible clarification about mail transactions and 243 transaction state . . . . . . . . . . . . . . . . . . 103 244 G.7.5. Issues with mailing lists, aliases, and forwarding . 104 245 G.7.6. Requirements for domain name and/or IP address in 246 EHLO . . . . . . . . . . . . . . . . . . . . . . . . 104 247 G.7.7. Does the 'first digit only' and/or non-listed reply 248 code text need clarification? . . . . . . . . . . . . 104 249 G.7.8. Size limits . . . . . . . . . . . . . . . . . . . . . 104 250 G.7.9. Discussion of 'blind' copies and RCPT . . . . . . . . 104 251 G.7.10. Further clarifications needed to source routes? . . . 104 252 G.7.11. Should 1yz Be Revisited? . . . . . . . . . . . . . . 104 253 G.7.12. Review Timeout Specifications . . . . . . . . . . . . 104 254 G.7.13. Possible SEND, SAML, SOML Loose End (closed) . . . . 105 255 G.7.14. Abstract Update (closed) . . . . . . . . . . . . . . 105 256 G.7.15. Informative References to MIME and/or Message 257 Submission (closed) . . . . . . . . . . . . . . . . . 105 258 G.7.16. Mail Transaction Discussion . . . . . . . . . . . . . 105 259 G.7.17. Hop by hop Authentication and/or Encryption 260 (closed) . . . . . . . . . . . . . . . . . . . . . . 105 261 G.7.18. More Text About 554 Given 521, etc. . . . . . . . . . 105 262 G.7.19. Minimum Lengths and Quantities . . . . . . . . . . . 105 263 G.8. Enhanced Reply Codes and DSNs . . . . . . . . . . . . . . 105 264 G.9. Revisiting Quoted Strings . . . . . . . . . . . . . . . . 106 265 G.10. Internationalization . . . . . . . . . . . . . . . . . . 106 266 G.11. SMTP Clients, Servers, Senders, and Receivers . . . . . . 107 267 G.12. Extension Keywords Starting in 'X-' . . . . . . . . . . . 107 268 G.13. Deprecating HELO . . . . . . . . . . . . . . . . . . . . 107 269 G.14. The FOR Clause in Trace Fields: Semantics, Security 270 Considerations, and Other Issues . . . . . . . . . . . . 107 271 G.15. Resistance to Attacks and Operational Necessity 272 (closed) . . . . . . . . . . . . . . . . . . . . . . . . 108 273 G.16. Mandatory 8BITMIME . . . . . . . . . . . . . . . . . . . 108 274 G.17. New tickets created between 2022-01-21 and 2022-03-01 . . 108 275 Appendix H. Completed Items Moved from Appendix G . . . . . . . 109 276 H.1. IP Address literals . . . . . . . . . . . . . . . . . . . 109 277 H.2. Repeated Use of EHLO (closed) . . . . . . . . . . . . . . 109 278 H.3. Meaning of "MTA" and Related Terminology . . . . . . . . 110 279 H.4. Originator, or Originating System, Authentication (to A/ 280 S) . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 281 H.5. Possible clarification about mail transactions and 282 transaction state (closed 113?) . . . . . . . . . . . . 110 283 H.6. Remove or deprecate the work-around from code 552 to 452 284 (closed) . . . . . . . . . . . . . . . . . . . . . . . . 110 285 H.7. Resolvable FQDNs and private domain names (closed) . . . 111 286 H.8. Issues with 521, 554, and 556 codes (closed) . . . . . . 111 287 H.9. Requirements for domain name and/or IP address in EHLO 288 (mostly closed, some to A/S) . . . . . . . . . . . . . . 111 289 H.10. Does the 'first digit only' and/or non-listed reply code 290 text need clarification? (closed) . . . . . . . . . . . 111 291 H.11. Size limits (closed) . . . . . . . . . . . . . . . . . . 111 292 H.12. Further clarifications needed to source routes? 293 (closed) . . . . . . . . . . . . . . . . . . . . . . . . 112 294 H.13. Should 1yz Be Revisited? (closed) . . . . . . . . . . . . 112 295 H.14. Review Timeout Specifications . . . . . . . . . . . . . . 112 296 H.15. Possible SEND, SAML, SOML Loose End (closed) . . . . . . 112 297 H.16. Abstract Update (closed) . . . . . . . . . . . . . . . . 112 298 H.17. Informative References to MIME and/or Message Submission 299 (closed) . . . . . . . . . . . . . . . . . . . . . . . . 112 300 H.18. Hop by hop Authentication and/or Encryption (closed) . . 113 301 H.19. Enhanced Reply Codes and DSNs . . . . . . . . . . . . . . 113 302 H.20. SMTP Clients, Servers, Senders, and Receivers . . . . . . 113 303 H.21. Extension Keywords Starting in 'X-' (closed) . . . . . . 114 304 H.22. Deprecating HELO (closed) . . . . . . . . . . . . . . . . 114 305 H.23. Resistance to Attacks and Operational Necessity 306 (closed) . . . . . . . . . . . . . . . . . . . . . . . . 114 307 H.24. New tickets created between 2022-01-21 and 2022-03-01 and 308 subsequently closed. . . . . . . . . . . . . . . . . . . 114 309 Appendix I. RFC 5321 Errata Summary and Tentative Change Log . . 115 310 I.1. RFC 5321 Errata Summary . . . . . . . . . . . . . . . . . 115 311 I.2. Changes from RFC 5321 (published October 2008) to the 312 initial (-00) version of this draft . . . . . . . . . . . 117 313 I.3. Changes Among Versions of rfc5321bis . . . . . . . . . . 118 314 I.3.1. Changes from draft-klensin-rfc5321bis-00 (posted 315 2012-12-02) to -01 . . . . . . . . . . . . . . . . . 118 316 I.3.2. Changes from draft-klensin-rfc5321bis-01 (20191203) to 317 -02 . . . . . . . . . . . . . . . . . . . . . . . . . 118 318 I.3.3. Changes from draft-klensin-rfc5321bis-02 (2019-12-27) 319 to -03 . . . . . . . . . . . . . . . . . . . . . . . 119 320 I.3.4. Changes from draft-klensin-rfc5321bis-03 (2020-07-02) 321 to draft-ietf-emailcore-rfc5321bis-00 . . . . . . . . 119 322 I.3.5. Changes from draft-ietf-emailcore-rfc5321bis-00 323 (2020-10-06) to -01 . . . . . . . . . . . . . . . . . 119 324 I.3.6. Changes from draft-ietf-emailcore-rfc5321bis-01 325 (2020-12-25) to -02 . . . . . . . . . . . . . . . . . 120 326 I.3.7. Changes from draft-ietf-emailcore-rfc5321bis-02 327 (2021-02-21) to -03 . . . . . . . . . . . . . . . . . 121 328 I.3.8. Changes from draft-ietf-emailcore-rfc5321bis-03 329 (2021-07-10) to -04 . . . . . . . . . . . . . . . . . 122 330 I.3.9. Changes from draft-ietf-emailcore-rfc5321bis-04 331 (2021-10-03) to -05 . . . . . . . . . . . . . . . . . 122 332 I.3.10. Changes from draft-ietf-emailcore-rfc5321bis-05 333 (2021-10-24) to -06 . . . . . . . . . . . . . . . . . 123 335 I.3.11. Changes from draft-ietf-emailcore-rfc5321bis-06 336 (2021-11-07) to -07 . . . . . . . . . . . . . . . . . 123 337 I.3.12. Changes from draft-ietf-emailcore-rfc5321bis-07 338 (2021-12-04) to -08 . . . . . . . . . . . . . . . . . 124 339 I.3.13. Changes from draft-ietf-emailcore-rfc5321bis-08 340 (2021-12-31) to -09 . . . . . . . . . . . . . . . . . 125 341 I.3.14. Changes from draft-ietf-emailcore-rfc5321bis-09 342 (2022-02-01 to -10 . . . . . . . . . . . . . . . . . 126 343 I.3.15. Changes from draft-ietf-emailcore-rfc5321bis-10 344 (2022-03-07) to -11 . . . . . . . . . . . . . . . . . 127 345 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 346 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 132 348 1. Introduction 350 1.1. Transport of Electronic Mail 352 The objective of the Simple Mail Transfer Protocol (SMTP) is to 353 transfer mail reliably and efficiently. 355 SMTP is independent of the particular transmission subsystem and 356 requires only a reliable ordered data stream channel. While this 357 document specifically discusses transport over TCP, other transports 358 are possible. Appendices to RFC 821 [4] describe some of them. 360 An important feature of SMTP is its capability to transport mail 361 across multiple networks, usually referred to as "SMTP mail relaying" 362 (see Section 3.6). A network consists of the mutually-TCP-accessible 363 hosts on the public Internet, the mutually-TCP-accessible hosts on a 364 firewall-isolated TCP/IP Intranet, or hosts in some other LAN or WAN 365 environment utilizing a non-TCP transport-level protocol. Using 366 SMTP, a process can transfer mail to another process on the same 367 network or to some other network via a relay or gateway process 368 accessible to both networks. 370 In this way, a mail message may pass through a number of intermediate 371 relay or gateway hosts on its path from sender to ultimate recipient. 372 The Mail eXchanger mechanisms of the domain name system (RFC 1035 373 [5], RFC 974 [17], and Section 5 of this document) are used to 374 identify the appropriate next-hop destination for a message being 375 transported. 377 1.2. History and Context for This Document 379 This document is a specification of the basic protocol for the 380 Internet electronic mail transport. It consolidates, updates and 381 clarifies, but does not add new or change existing functionality of 382 the following: 384 * the original SMTP (Simple Mail Transfer Protocol) specification of 385 RFC 821 [4], 387 * domain name system requirements and implications for mail 388 transport from RFC 1035 [5] and RFC 974 [17], 390 * the clarifications and applicability statements in RFC 1123 [6], 392 * the new error codes added by RFC 1846 [21] and later by RFC 7504 393 [48], obsoleting both of those documents, and 395 * material drawn from the SMTP Extension mechanisms in RFC 1869 396 [23]. 398 It also includes editorial and clarification changes that were made 399 to RFC 2821 [31] to bring that specification to Draft Standard and 400 similar changes to RFC 5321 [50] to bring the current document to 401 Internet Standard. 403 It may help the reader to understand that, to reduce the risk of 404 introducing errors, large parts of the document essentially merge the 405 earlier specifications listed in the bullet points above rather than 406 providing a completely rewritten, reorganized, and integrated 407 description of SMTP. An index is provided to assist in the quest for 408 information. 410 It obsoletes RFCs 5321 [50] (the earlier version of this 411 specification), 1846 [21] and incorporates the substance of 7504 [48] 412 (specification of reply codes), and 7505 [49] (the "Null MX" 413 specification). Although SMTP was designed as a mail transport and 414 delivery protocol, this specification also contains information that 415 is relevant to its optional use for submission of mail by users and 416 to some aspects of the Post Office Protocol (POP) (RFC 937 [15], RFC 417 1939 [24]) and IMAP (RFC 3501 [37]) protocols. In general, the 418 separate mail submission protocol specified in RFC 6409 [44] is now 419 preferred to direct use of SMTP for that function; more discussion of 420 that subject appears in that document. 422 Section 2.3 provides definitions of terms specific to this document. 423 Except when the historical terminology is necessary for clarity, this 424 document uses the current 'client' and 'server' terminology to 425 identify the sending and receiving SMTP processes, respectively. In 426 general, "sender-SMTP" and "SMTP client" are equivalent as are 427 "receiver-SMTP" and "SMTP server". 429 A companion document, RFC 5322 [13], discusses message header 430 sections and bodies and specifies formats and structures for them. 431 Other relevant documents and their relationships are discussed in a 432 forthcoming Applicability Statement [51]. 434 1.3. Document Conventions 436 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 437 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 438 document are to be interpreted as described in RFC 2119 [1]. As each 439 of these terms was intentionally and carefully chosen to improve the 440 interoperability of email, each use of these terms is to be treated 441 as a conformance requirement. 443 Because this document has a long history and to avoid the risk of 444 various errors and of confusing readers and documents that point to 445 this one, most examples and the domain names they contain are 446 preserved from RFC 2821. Readers are cautioned that these are 447 illustrative examples that should not actually be used in either code 448 or configuration files. 450 2. The SMTP Model 452 2.1. Basic Structure 454 The SMTP design can be pictured as: 456 +----------+ +----------+ 457 +------+ | | | | 458 | User |<-->| | SMTP | | 459 +------+ | Client- |Commands/Replies| Server- | 460 +------+ | SMTP |<-------------->| SMTP | +------+ 461 | File |<-->| | and Mail | |<-->| File | 462 |System| | | | | |System| 463 +------+ +----------+ +----------+ +------+ 464 SMTP client SMTP server 466 When an SMTP client has a message to transmit, it establishes a two- 467 way transmission channel to an SMTP server. The responsibility of an 468 SMTP client is to transfer mail messages to one or more SMTP servers, 469 or report its failure to do so. 471 The means by which a mail message is presented to an SMTP client, and 472 how that client determines the identifier(s) ("names") of the 473 domain(s) to which mail messages are to be transferred, are local 474 matters. They are not addressed by this document. In some cases, 475 the designated domain(s), or those determined by an SMTP client, will 476 identify the final destination(s) of the mail message. In other 477 cases, common with SMTP clients associated with implementations of 478 the POP (RFC 937 [15], RFC 1939 [24]) or IMAP (RFC 3501 [37]) 479 protocols, or when the SMTP client is inside an isolated transport 480 service environment, the domain determined will identify an 481 intermediate destination through which all mail messages are to be 482 relayed. SMTP clients that transfer all traffic regardless of the 483 target domains associated with the individual messages, or that do 484 not maintain queues for retrying message transmissions that initially 485 cannot be completed, may otherwise conform to this specification but 486 are not considered fully-capable. Fully-capable SMTP 487 implementations, including the relays used by these less capable 488 ones, and their destinations, are expected to support all of the 489 queuing, retrying, and alternate address functions discussed in this 490 specification. In many situations and configurations, the less- 491 capable clients discussed above SHOULD be using the message 492 submission protocol (RFC 6409 [44]) rather than SMTP. 494 The means by which an SMTP client, once it has determined a target 495 domain, determines the identity of an SMTP server to which a copy of 496 a message is to be transferred, and then performs that transfer, are 497 covered by this document. To effect a mail transfer to an SMTP 498 server, an SMTP client establishes a two-way transmission channel to 499 that SMTP server. An SMTP client determines the address of an 500 appropriate host running an SMTP server by resolving a destination 501 domain name to either an intermediate Mail eXchanger host or a final 502 target host. 504 An SMTP server may be either the ultimate destination or an 505 intermediate "relay" (that is, it may assume the role of an SMTP 506 client after receiving the message) or "gateway" (that is, it may 507 transport the message further using some protocol other than SMTP). 508 SMTP commands are generated by the SMTP client and sent to the SMTP 509 server. SMTP replies are sent from the SMTP server to the SMTP 510 client in response to the commands. 512 In other words, message transfer can occur in a single connection 513 between the original SMTP-sender and the final SMTP-recipient, or can 514 occur in a series of hops through intermediary systems. In either 515 case, once the server has issued a success response at the end of the 516 mail data, a formal handoff of responsibility for the message occurs: 517 the protocol requires that a server MUST accept responsibility for 518 either delivering the message or properly reporting the failure to do 519 so (see Sections 6.1, 6.2, and 7.8, below). 521 Once the transmission channel is established and initial handshaking 522 is completed, the SMTP client normally initiates a mail transaction. 523 Such a transaction consists of a series of commands to specify the 524 originator and destination of the mail and transmission of the 525 message content (including any lines in the header section or other 526 structure) itself. When the same message is sent to multiple 527 recipients, this protocol encourages the transmission of only one 528 copy of the data for all recipients at the same destination (or 529 intermediate relay) host. 531 The server responds to each command with a reply; replies may 532 indicate that the command was accepted, that additional commands are 533 expected, or that a temporary or permanent error condition exists. 534 Commands specifying the sender or recipients may include server- 535 permitted SMTP service extension requests, as discussed in 536 Section 2.2. The dialog is purposely lock-step, one-at-a-time, 537 although this can be modified by mutually agreed upon extension 538 requests such as command pipelining (RFC 2920 [32]). 540 Once a given mail message has been transmitted, the client may either 541 request that the connection be shut down or may initiate other mail 542 transactions. In addition, an SMTP client may use a connection to an 543 SMTP server for ancillary services such as verification of email 544 addresses or retrieval of mailing list subscriber addresses. 546 As suggested above, this protocol provides mechanisms for the 547 transmission of mail. Historically, this transmission normally 548 occurred directly from the sending user's host to the receiving 549 user's host when the two hosts are connected to the same transport 550 service. When they are not connected to the same transport service, 551 transmission occurs via one or more relay SMTP servers. A very 552 common case in the Internet today involves submission of the original 553 message to an intermediate, "message submission" server, which is 554 similar to a relay but has some additional properties; such servers 555 are discussed in Section 2.3.10 and at some length in RFC 6409 [44]. 556 An intermediate host that acts as either an SMTP relay or as a 557 gateway into some other transmission environment is usually selected 558 through the use of the domain name service (DNS) Mail eXchanger 559 mechanism. 561 2.2. The Extension Model 563 2.2.1. Background 565 In an effort that started in 1990, approximately a decade after RFC 566 821 was completed, the protocol was modified with a "service 567 extensions" model that permits the client and server to agree to 568 utilize shared functionality beyond the original SMTP requirements. 569 The SMTP extension mechanism defines a means whereby an extended SMTP 570 client and server may recognize each other, and the server can inform 571 the client as to the service extensions that it supports. 573 Contemporary SMTP implementations MUST support the basic extension 574 mechanisms. For instance, servers MUST support the EHLO command even 575 if they do not implement any specific extensions and clients SHOULD 576 preferentially utilize EHLO rather than HELO. (However, for 577 compatibility with older conforming implementations, SMTP clients and 578 servers MUST support the original HELO mechanisms as a fallback.) 579 Unless the different characteristics of HELO must be identified for 580 interoperability purposes, this document discusses only EHLO. 582 SMTP is widely deployed and high-quality implementations have proven 583 to be very robust. However, the Internet community now considers 584 some services to be important that were not anticipated when the 585 protocol was first designed. If support for those services is to be 586 added, it must be done in a way that permits older implementations to 587 continue working acceptably. The extension framework consists of: 589 * The SMTP command EHLO, superseding the earlier HELO, 591 * a registry of SMTP service extensions, 593 * additional parameters to the SMTP MAIL and RCPT commands, and 595 * optional replacements for commands defined in this protocol, such 596 as for DATA in non-ASCII transmissions (RFC 3030 [34]). 598 SMTP's strength comes primarily from its simplicity. Experience with 599 many protocols has shown that protocols with few options tend towards 600 ubiquity, whereas protocols with many options tend towards obscurity. 602 Each and every extension, regardless of its benefits, must be 603 carefully scrutinized with respect to its implementation, deployment, 604 and interoperability costs. In many cases, the cost of extending the 605 SMTP service will likely outweigh the benefit. 607 2.2.2. Definition and Registration of Extensions 609 The IANA maintains a registry of SMTP service extensions [56]. A 610 corresponding EHLO keyword value is associated with each extension. 611 Each service extension registered with the IANA must be defined in a 612 formal Standards-Track or IESG-approved Experimental protocol 613 document. The definition must include: 615 * the textual name of the SMTP service extension; 617 * the EHLO keyword value associated with the extension; 619 * the syntax and possible values of parameters associated with the 620 EHLO keyword value; 622 * any additional SMTP verbs associated with the extension 623 (additional verbs will usually be, but are not required to be, the 624 same as the EHLO keyword value); 626 * any new parameters the extension associates with the MAIL or RCPT 627 verbs; 629 * a description of how support for the extension affects the 630 behavior of a server and client SMTP; and 632 * the increment by which the extension is increasing the maximum 633 length of the commands MAIL and/or RCPT, over that specified in 634 this Standard. 636 Any keyword value presented in the EHLO response MUST correspond to a 637 Standard, Standards-Track, or IESG-approved Experimental SMTP service 638 extension registered with IANA. A conforming server MUST NOT offer 639 keyword values that are not described in a registered extension. 641 2.2.3. Special Issues with Extensions 643 Extensions that change fairly basic properties of SMTP operation are 644 permitted. The text in other sections of this document must be 645 understood in that context. In particular, extensions can change the 646 minimum limits specified in Section 4.5.3, can change the ASCII 647 character set requirement as mentioned above, or can introduce some 648 optional modes of message handling. 650 In particular, if an extension implies that the delivery path 651 normally supports special features of that extension, and an 652 intermediate SMTP system finds a next hop that does not support the 653 required extension, it MAY choose, based on the specific extension 654 and circumstances, to requeue the message and try later and/or try an 655 alternate MX host. If this strategy is employed, the timeout to fall 656 back to an unextended format (if one is available) SHOULD be less 657 than the normal timeout for bouncing as undeliverable (e.g., if 658 normal timeout is three days, the requeue timeout before attempting 659 to transmit the mail without the extension might be one day). 661 2.3. SMTP Terminology 663 2.3.1. Mail Objects 665 SMTP transports a mail object. A mail object contains an envelope 666 and content. 668 The SMTP envelope is sent as a series of SMTP protocol units 669 (described in Section 3). It consists of an originator address (to 670 which error reports should be directed), one or more recipient 671 addresses, and optional protocol extension material. Historically, 672 variations on the reverse-path (originator) address specification 673 command (MAIL) could be used to specify alternate delivery modes, 674 such as immediate display; those variations have now been deprecated 675 (see Appendix F and Appendix F.6). 677 The SMTP content is sent in the SMTP DATA protocol unit and has two 678 parts: the header section and the body. If the content conforms to 679 other contemporary standards, the header section consists of a 680 collection of header fields, each consisting of a header name, a 681 colon, and data, structured as in the message format specification 682 (RFC 5322 [13]); the body, if structured, is defined according to 683 MIME (RFC 2045 [26]). The content is textual in nature, expressed 684 using the ASCII repertoire [2]. Although SMTP extensions (such as 685 "8BITMIME", RFC 6152 [47]) may relax this restriction for the content 686 body, the content header fields are always encoded using the US-ASCII 687 repertoire. Two MIME extensions (RFC 2047 [27] and RFC 2231 [30]) 688 define an algorithm for representing header values outside the US- 689 ASCII repertoire, while still encoding them using the US-ASCII 690 repertoire. 692 2.3.2. Senders and Receivers 694 In RFC 821, the two hosts participating in an SMTP transaction were 695 described as the "SMTP-sender" and "SMTP-receiver". This document 696 has been changed to reflect current industry terminology and hence 697 refers to them as the "SMTP client" (or sometimes just "the client") 698 and "SMTP server" (or just "the server"), respectively. Since a 699 given host may act both as server and client in a relay situation, 700 "receiver" and "sender" terminology is still used where needed for 701 clarity. 703 2.3.3. Mail Agents and Message Stores 705 Additional mail system terminology became common after RFC 821 was 706 published and, where convenient, is used in this specification. In 707 particular, SMTP servers and clients provide a mail transport service 708 and therefore act as "Mail Transfer Agents" (MTAs). "Mail User 709 Agents" (MUAs or UAs) are normally thought of as the sources and 710 targets of mail. At the source, an MUA might collect mail to be 711 transmitted from a user and hand it off to an MTA or, more commonly 712 in recent years, a specialized variation on an MTA called a 713 "Submission Server" (MSA) [44]. . At the other end of the process, 714 the final ("delivery") MTA would be thought of as handing the mail 715 off to an MUA (or at least transferring responsibility to it, e.g., 716 by depositing the message in a "message store"). However, while 717 these terms are used with at least the appearance of great precision 718 in other environments, the implied boundaries between MUAs and MTAs 719 often do not accurately match common, and conforming, practices with 720 Internet mail. Hence, the reader should be cautious about inferring 721 the strong relationships and responsibilities that might be implied 722 if these terms were used elsewhere 724 2.3.4. Host 726 For the purposes of this specification, a host is a computer system 727 attached to the Internet (or, in some cases, to a private TCP/IP 728 network) and supporting the SMTP protocol. Hosts are known by names 729 (see the next section); they SHOULD NOT be identified by numerical 730 addresses, i.e., by address literals as described in Section 4.1.2. 732 2.3.5. Domain Names 734 A domain name (or often just a "domain") consists of one or more 735 components, separated by dots if more than one appears. In the case 736 of a top-level domain used by itself in an email address, a single 737 string is used without any dots. This makes the requirement, 738 described in more detail below, that only fully-qualified domain 739 names appear in SMTP transactions on the public Internet, 740 particularly important where top-level domains are involved. These 741 components ("labels" in the DNS terminology of RFC 1035 [5]) are 742 restricted for purposes of SMTP as defined here to consist of a 743 sequence of letters, digits, and hyphens drawn from the ASCII 744 character set [2] and conforming to what RFC 1035 Section 2.3.1 calls 745 the "preferred name syntax". Domain names are used as names of hosts 746 and, except where additionally restricted in this document, of other 747 entities in the domain name hierarchy. For example, a domain may 748 refer to a host alias (label of a CNAME RR) or the label of Mail 749 eXchanger records to be used to deliver mail instead of representing 750 a host name. See RFC 1035 and Section 5 of this specification. 752 The domain name, as described in this document and in RFC 1035 [5], 753 MUST be the entire, fully-qualified name (often referred to as an 754 "FQDN"). Other than an address literal (see Section 4.1.3) where 755 those are permitted, any string that is not a domain name in FQDN 756 form is no more than a reference to be interpreted locally. Such 757 local references for domain names MUST NOT appear in any SMTP 758 transaction (Cf. Section 5). Mechanisms for inferring FQDNs from 759 local references (including partial names or local aliases) are 760 outside of this specification and normally the province of message 761 submission. Due to a history of problems, SMTP servers SHOULD NOT 762 make such inferences (Message Submission Servers [44] have somewhat 763 more flexibility) and intermediate (relay) SMTP servers MUST NOT make 764 them. 766 When domain names are used in SMTP, and unless further restricted in 767 this document, names that can be resolved to MX RRs or address (i.e., 768 A or AAAA) RRs (as discussed in Section 5) are permitted, as are 769 CNAME RRs whose targets can be resolved, in turn, to MX or address 770 RRs. There are two exceptions to the rule requiring FQDNs: 772 * The domain name given in the EHLO command MUST be either a primary 773 host name (a domain name that resolves to an address RR) or, if 774 the host has no name, an address literal, as described in 775 Section 4.1.3 and discussed further in the EHLO discussion of 776 Section 4.1.4. 778 * The reserved mailbox name "postmaster" MAY be used in a RCPT 779 command without domain qualification (see Section 4.1.1.3) and 780 MUST be accepted if so used. 782 2.3.6. Buffer and State Table 784 SMTP sessions are stateful, with both parties carefully maintaining a 785 common view of the current state. In this document, we model this 786 state by a virtual "buffer" and a "state table" on the server that 787 may be used by the client to, for example, "clear the buffer" or 788 "reset the state table", causing the information in the buffer to be 789 discarded and the state to be returned to some previous state. 791 2.3.7. Commands and Replies 793 SMTP commands and, unless altered by a service extension, message 794 data, are transmitted from the sender to the receiver via the 795 transmission channel in "lines". 797 An SMTP reply is an acknowledgment (positive or negative) sent in 798 "lines" from receiver to sender via the transmission channel in 799 response to a command. The general form of a reply is a numeric 800 completion code (indicating failure or success) usually followed by a 801 text string. The codes are for use by programs and the text is 802 usually intended for human users. RFC 3463 [8], specifies further 803 structuring of the reply strings, including the use of supplemental 804 and more specific completion codes (see also RFC 5248 [46]). 806 2.3.8. Lines 808 Lines consist of zero or more data characters terminated by the 809 sequence ASCII character "CR" (hex value 0D) followed immediately by 810 ASCII character "LF" (hex value 0A). This termination sequence is 811 denoted as in this document. Conforming implementations MUST 812 NOT recognize or generate any other character or character sequence 813 as a line terminator. Limits MAY be imposed on line lengths by 814 servers (see Section 4). 816 In addition, the appearance of "bare" "CR" or "LF" characters in text 817 (i.e., either without the other) has a long history of causing 818 problems in mail implementations and applications that use the mail 819 system as a tool. SMTP client implementations MUST NOT transmit 820 these characters except when they are intended as line terminators 821 and then MUST, as indicated above, transmit them only as a 822 sequence. 824 2.3.9. Message Content and Mail Data 826 The terms "message content" and "mail data" are used interchangeably 827 in this document to describe the material transmitted after the DATA 828 command is accepted and before the end of data indication is 829 transmitted. Message content includes the message header section and 830 the possibly structured message body. In the absence of extensions, 831 both are required to be ASCII (see Section 2.3.1). The MIME 832 specification (RFC 2045 [26]) provides the standard mechanisms for 833 structured message bodies. 835 2.3.10. Originator, Delivery, Relay, and Gateway Systems 837 This specification makes a distinction among four types of SMTP 838 systems, based on the role those systems play in transmitting 839 electronic mail. An "originating" system (sometimes called an SMTP 840 originator) introduces mail into the Internet or, more generally, 841 into a transport service environment. A "delivery" SMTP system is 842 one that receives mail from a transport service environment and 843 passes it to a mail user agent or deposits it in a message store that 844 a mail user agent is expected to subsequently access. A "relay" SMTP 845 system (usually referred to just as a "relay") receives mail from an 846 SMTP client and transmits it, without modification to the message 847 data other than adding trace information (see Section 4.4), to 848 another SMTP server for further relaying or for delivery. 850 A "gateway" SMTP system (usually referred to just as a "gateway") 851 receives mail from a client system in one transport environment and 852 transmits it to a server system in another transport environment. 853 Differences in protocols or message semantics between the transport 854 environments on either side of a gateway may require that the gateway 855 system perform transformations to the message that are not permitted 856 to SMTP relay systems. For the purposes of this specification, 857 firewalls that rewrite addresses should be considered as gateways, 858 even if SMTP is used on both sides of them (see RFC 2979 [33]). 860 2.3.11. Mailbox and Address 862 As used in this specification, an "address" is a character string 863 that identifies a user to whom mail will be sent or a location into 864 which mail will be deposited. The term "mailbox" refers to that 865 depository. The two terms are typically used interchangeably unless 866 the distinction between the location in which mail is placed (the 867 mailbox) and a reference to it (the address) is important. An 868 address normally consists of user and domain specifications. The 869 standard mailbox naming convention is defined to be "local- 870 part@domain"; contemporary usage permits a much broader set of 871 applications than simple "user names". Consequently, and due to a 872 long history of problems when intermediate hosts have attempted to 873 optimize transport by modifying them, the local-part MUST be 874 interpreted and assigned semantics only by the host specified in the 875 domain part of the address. 877 2.4. General Syntax Principles and Transaction Model 879 SMTP commands and replies have a rigid syntax. All commands begin 880 with a command verb. All replies begin with a three digit numeric 881 code. In some commands and replies, arguments are required following 882 the verb or reply code. Some commands do not accept arguments (after 883 the verb), and some reply codes are followed, sometimes optionally, 884 by free form text. In both cases, where text appears, it is 885 separated from the verb or reply code by a space character. Complete 886 definitions of commands and replies appear in Section 4. 888 Verbs and argument values (e.g., "TO:" or "to:" in the RCPT command 889 and extension name keywords) are not case sensitive, with the sole 890 exception in this specification of a mailbox local-part (SMTP 891 Extensions may explicitly specify case-sensitive elements). That is, 892 a command verb, an argument value other than a mailbox local-part, 893 and free form text MAY be encoded in upper case, lower case, or any 894 mixture of upper and lower case with no impact on its meaning. The 895 local-part of a mailbox MUST BE treated as case sensitive. 897 Therefore, SMTP implementations MUST take care to preserve the case 898 of mailbox local-parts. In particular, for some hosts, the user 899 "smith" is different from the user "Smith". However, exploiting the 900 case sensitivity of mailbox local-parts impedes interoperability and 901 is discouraged. Mailbox domains follow normal DNS rules and are 902 hence not case sensitive. 904 A few SMTP servers, in violation of this specification (and RFC 821) 905 may require that command verbs be encoded by clients in upper case. 906 Implementations MAY wish to employ this encoding to accommodate those 907 servers. 909 The argument clause consists of a variable-length character string 910 ending with the end of the line, i.e., with the character sequence 911 . The receiver will take no action until this sequence is 912 received. 914 The syntax for each command is shown with the discussion of that 915 command. Common elements and parameters are shown in Section 4.1.2. 917 Commands and replies are composed of characters from the ASCII 918 character set [2]. When the transport service provides an 8-bit byte 919 (octet) transmission channel, each 7-bit character is transmitted, 920 right justified, in an octet with the high-order bit cleared to zero. 921 More specifically, the unextended SMTP service provides 7-bit 922 transport only. An originating SMTP client that has not successfully 923 negotiated an appropriate extension with a particular server (see the 924 next paragraph) MUST NOT transmit messages with information in the 925 high-order bit of octets. If such messages are transmitted in 926 violation of this rule, receiving SMTP servers MAY clear the high- 927 order bit or reject the message as invalid. In general, a relay SMTP 928 SHOULD assume that the message content it has received is valid and, 929 assuming that the envelope permits doing so, relay it without 930 inspecting that content. Of course, if the content is mislabeled and 931 the data path cannot accept the actual content, this may result in 932 the ultimate delivery of a severely garbled message to the recipient. 933 Delivery SMTP systems MAY reject such messages, or return them as 934 undeliverable, rather than deliver them. In the absence of a server- 935 offered extension explicitly permitting it, a sending SMTP system is 936 not permitted to send envelope commands in any character set other 937 than US-ASCII. Receiving systems SHOULD reject such commands, 938 normally using "500 syntax error - invalid character" replies. 940 8-bit message content transmission MAY be requested of the server by 941 a client using extended SMTP facilities, notably the "8BITMIME" 942 extension, RFC 6152 [47]. 8BITMIME SHOULD be supported by SMTP 943 servers. However, it MUST NOT be construed as authorization to 944 transmit unrestricted 8-bit material, nor does 8BITMIME authorize 945 transmission of any envelope material in other than ASCII. 8BITMIME 946 MUST NOT be requested by senders for material with the high bit on 947 that is not in MIME format with an appropriate content-transfer 948 encoding; servers MAY reject such messages. 950 The metalinguistic notation used in this document corresponds to the 951 "Augmented BNF" used in other Internet mail system documents. The 952 reader who is not familiar with that syntax should consult the ABNF 953 specification in RFC 5234 [12]. Metalanguage terms used in running 954 text are surrounded by pointed brackets (e.g., ) for clarity. 955 The reader is cautioned that the grammar expressed in the 956 metalanguage is not comprehensive. There are many instances in which 957 provisions in the text constrain or otherwise modify the syntax or 958 semantics implied by the grammar. 960 3. The SMTP Procedures: An Overview 962 This section contains descriptions of the procedures used in SMTP: 963 session initiation, mail transaction, forwarding mail, verifying 964 mailbox names and expanding mailing lists, and opening and closing 965 exchanges. Comments on relaying, a note on mail domains, and a 966 discussion of changing roles are included at the end of this section. 967 Several complete scenarios are presented in Appendix D. 969 3.1. Session Initiation 971 An SMTP session is initiated when a client opens a connection to a 972 server and the server responds with an opening message. 974 SMTP server implementations MAY include identification of their 975 software and version information in the connection greeting reply 976 after the 220 code, a practice that permits more efficient isolation 977 and repair of any problems. Implementations MAY make provision for 978 SMTP servers to disable the software and version announcement where 979 it causes security concerns. While some systems also identify their 980 contact point for mail problems, this is not a substitute for 981 maintaining the required "postmaster" address (see Section 4). 983 The SMTP protocol allows a server to formally reject a mail session 984 while still allowing the initial connection as follows: a 521 985 response MAY be given in the initial connection opening message 986 instead of the 220. A server taking this approach MUST still wait 987 for the client to send a QUIT (see Section 4.1.1.10) before closing 988 the connection and SHOULD respond to any intervening commands with 989 "503 bad sequence of commands". Since an attempt to make an SMTP 990 connection to such a system is probably in error, a server returning 991 a 521 992 // (or 554?) 993 response on connection opening SHOULD provide enough information in 994 the reply text to facilitate debugging of the sending system. See 995 Section 4.2.4.2. 997 3.2. Client Initiation 999 Once the server has sent the greeting (welcoming) message and the 1000 client has received it, the client normally sends the EHLO command to 1001 the server, indicating the client's identity. In addition to opening 1002 the session, use of EHLO indicates that the client is able to process 1003 service extensions and requests that the server provide a list of the 1004 extensions it supports. Older SMTP systems that are unable to 1005 support service extensions, and contemporary clients that do not 1006 require service extensions in the mail session being initiated, MAY 1007 use HELO instead of EHLO. Servers MUST NOT return the extended EHLO- 1008 style response to a HELO command. For a particular connection 1009 attempt, if the server returns a "command not recognized" response to 1010 EHLO, the client SHOULD be able to fall back and send HELO. 1012 In the EHLO command, the host sending the command identifies itself; 1013 the command may be interpreted as saying "Hello, I am " (and, 1014 in the case of EHLO, "and I support service extension requests"). 1016 3.3. Mail Transactions 1018 There are three steps to normal SMTP mail transactions. The 1019 transaction starts with a MAIL command that gives the sender 1020 identification. (In general, the MAIL command may be sent only when 1021 no mail transaction is in progress; see Section 4.1.4.) In a normal 1022 session, a series of one or more RCPT commands follows, giving the 1023 receiver information. Then, a DATA command initiates transfer of the 1024 mail data and is terminated by the "end of mail" data indicator, 1025 which also confirms (and terminates) the transaction. 1027 Mail transactions are also terminated by the RSET command 1028 (Section 4.1.1.5), the sending of an EHLO command (Section 3.2), or 1029 the sending of a QUIT command (Section 3.8). The latter terminates 1030 not only any active mail transaction but the SMTP connection itself. 1032 The first step in the procedure is the MAIL command. 1034 MAIL FROM: [SP ] 1036 This command tells the SMTP-receiver that a new mail transaction is 1037 starting and to reset all its state tables and buffers, including any 1038 recipients or mail data. The portion of the first or 1039 only argument contains the source mailbox (between "<" and ">" 1040 brackets), which can be used to report errors (see Section 4.2 for a 1041 discussion of error reporting). If accepted, the SMTP server returns 1042 a "250 OK" reply. If the mailbox specification is not acceptable for 1043 some reason, the server MUST return a reply indicating whether the 1044 failure is permanent (i.e., will occur again if the client tries to 1045 send the same address again) or temporary (i.e., the address might be 1046 accepted if the client tries again later). Despite the apparent 1047 scope of this requirement, there are circumstances in which the 1048 acceptability of the reverse-path may not be determined until one or 1049 more forward-paths (in RCPT commands) can be examined. In those 1050 cases, the server MAY reasonably accept the reverse-path (with a 250 1051 reply) and then report problems after the forward-paths are received 1052 and examined. Normally, failures produce 550 or 553 replies. 1054 Historically, the was permitted to contain more than 1055 just a mailbox; however source routing is now deprecated (see 1056 Appendix F.2). 1058 The optional are associated with negotiated SMTP 1059 service extensions (see Section 2.2). 1061 The second step in the procedure is the RCPT command. This step of 1062 the procedure can be repeated any number of times. 1064 RCPT TO: [ SP ] 1066 The first or only argument to this command includes a forward-path 1067 (normally a mailbox local-part and domain, always surrounded by "<" 1068 and ">" brackets) identifying one recipient. If accepted, the SMTP 1069 server returns a "250 OK" reply and stores the forward-path. If the 1070 recipient is known not to be a deliverable address, the SMTP server 1071 returns a 550 reply, typically with a string such as "no such user - 1072 " and the mailbox name (other circumstances and reply codes are 1073 possible). 1075 Historically, the was permitted to contain a source 1076 routing list of hosts and the destination mailbox; however, source 1077 routes are now deprecated (see Appendix F.2). Restricted-capability 1078 clients MUST NOT assume that any SMTP server on the Internet can be 1079 used as their mail processing (relaying) site. If a RCPT command 1080 appears without a previous MAIL command, the server MUST return a 503 1081 "Bad sequence of commands" response. The optional 1082 are associated with negotiated SMTP service extensions (see 1083 Section 2.2). 1085 Since it has been a common source of errors, it is worth noting that 1086 spaces are not permitted on either side of the colon following FROM 1087 in the MAIL command or TO in the RCPT command. The syntax is exactly 1088 as given above. 1090 The third step in the procedure is the DATA command (or some 1091 alternative specified in a service extension). 1093 DATA 1095 If accepted, the SMTP server returns a 354 Intermediate reply and 1096 considers all succeeding lines up to but not including the end of 1097 mail data indicator to be the message text. When the end of text is 1098 successfully received and stored, the SMTP-receiver sends a "250 OK" 1099 reply. 1101 Since the mail data is sent on the transmission channel, the end of 1102 mail data must be indicated so that the command and reply dialog can 1103 be resumed. An SMTP client indicates the end of the mail data by 1104 sending a line containing only a "." (period or full stop, hex 2E), 1105 that is the character sequence ".". A transparency 1106 procedure is used to prevent this from interfering with the user's 1107 text (see Section 4.5.2). 1109 The end of mail data indicator also confirms the mail transaction and 1110 tells the SMTP server to now process the stored recipients and mail 1111 data. If accepted, the SMTP server returns a "250 OK" reply. The 1112 DATA command can fail at only two points in the protocol exchange: 1114 If there was no MAIL, or no RCPT, command, or all such commands were 1115 rejected, the server MAY return a "command out of sequence" (503) or 1116 "no valid recipients" (554) reply in response to the DATA command. 1117 If one of those replies (or any other 5yz reply) is received, the 1118 client MUST NOT send the message data; more generally, message data 1119 MUST NOT be sent unless a 354 reply is received. 1121 If the verb is initially accepted and the 354 reply issued, the DATA 1122 command should fail only if the mail transaction was incomplete (for 1123 example, no recipients), if resources were unavailable (including, of 1124 course, the server unexpectedly becoming unavailable), or if the 1125 server determines that the message should be rejected for policy or 1126 other reasons. 1128 However, in practice, some servers do not perform recipient 1129 verification until after the message text is received. These servers 1130 SHOULD treat a failure for one or more recipients as a "subsequent 1131 failure" and return a mail message as discussed in Section 6 and, in 1132 particular, in Section 6.1. Using a "550 mailbox not found" (or 1133 equivalent) reply code after the data are accepted makes it difficult 1134 or impossible for the client to determine which recipients failed. 1136 When the RFC 822 format ([14], [13]) is being used, the mail data 1137 include the header fields such as those named Date, Subject, To, Cc, 1138 and From. Server SMTP systems SHOULD NOT reject messages based on 1139 perceived defects in the RFC 822 or MIME (RFC 2045 [26]) message 1140 header section or message body. In particular, they MUST NOT reject 1141 messages in which the numbers of Resent-header fields do not match or 1142 Resent-to appears without Resent-from and/or Resent-date. 1144 Mail transaction commands MUST be used in the order discussed above. 1146 3.4. Address Modification and Expansion 1148 3.4.1. Forwarding for Address Correction or Updating 1150 Forwarding support is most often required to consolidate and simplify 1151 addresses within, or relative to, some enterprise and less frequently 1152 to establish addresses to link a person's prior address with a 1153 current one. Silent forwarding of messages (without server 1154 notification to the sender), for security or non-disclosure purposes, 1155 is common in the contemporary Internet. 1157 In both the enterprise and the "new address" cases, information 1158 hiding (and sometimes security) considerations argue against exposure 1159 of the "final" address through the SMTP protocol as a side effect of 1160 the forwarding activity. This may be especially important when the 1161 final address may not even be reachable by the sender. Consequently, 1162 the "forwarding" mechanisms described in Section 3.2 of RFC 821, and 1163 especially the 251 (corrected destination) and 551 reply codes from 1164 RCPT must be evaluated carefully by implementers and, when they are 1165 available, by those configuring systems (see also Section 7.4). 1167 In particular: 1169 * Servers MAY forward messages when they are aware of an address 1170 change. When they do so, they MAY either provide address-updating 1171 information with a 251 code, or may forward "silently" and return 1172 a 250 code. However, if a 251 code is used, they MUST NOT assume 1173 that the client will actually update address information or even 1174 return that information to the user. 1176 Alternately, 1178 * Servers MAY reject messages or return them as non-deliverable when 1179 they cannot be delivered precisely as addressed. When they do so, 1180 they MAY either provide address-updating information with a 551 1181 code, or may reject the message as undeliverable with a 550 code 1182 and no address-specific information. However, if a 551 code is 1183 used, they MUST NOT assume that the client will actually update 1184 address information or even return that information to the user. 1186 SMTP server implementations that support the 251 and/or 551 reply 1187 codes SHOULD provide configuration mechanisms so that sites that 1188 conclude that they would undesirably disclose information can disable 1189 or restrict their use. See Section 7.4 for further discussion of 1190 that issue. 1192 3.4.2. Aliases and Mailing Lists 1194 Many SMTP-capable hosts support address expansion for multiple 1195 delivery via one or both of the alias and the list models. When a 1196 message is delivered or forwarded to each address of an expanded list 1197 form, the return address in the envelope ("MAIL FROM:") MUST be 1198 changed to be the address of a person or other entity who administers 1199 the list. This change to the MAIL command does not affect the header 1200 section of the message. 1202 An important mail facility is a mechanism for multi-destination 1203 delivery of a single message, by transforming (or "expanding" or 1204 "exploding") a pseudo-mailbox address into a list of destination 1205 mailbox addresses. When a message is sent to such a pseudo-mailbox 1206 (sometimes called an "exploder"), copies are forwarded or 1207 redistributed to each mailbox in the expanded list. Servers SHOULD 1208 simply utilize the addresses on the list; application of heuristics 1209 or other matching rules to eliminate some addresses, such as that of 1210 the originator, is strongly discouraged. We classify such a pseudo- 1211 mailbox as an "alias" or a "list", depending upon the expansion 1212 rules. 1214 3.4.2.1. Simple Aliases 1216 To expand an alias, the recipient mailer simply replaces the pseudo- 1217 mailbox address in the envelope with each of the expanded addresses 1218 in turn; the rest of the envelope and the message body are left 1219 unchanged. The message is then delivered or forwarded to each 1220 expanded address. 1222 3.4.2.2. Mailing Lists 1224 Processing of a mailing list may be said to operate by 1225 "redistribution" rather than by "forwarding" (as in the simple alias 1226 case in the subsection above). To expand a list, the recipient 1227 mailer replaces the pseudo-mailbox address in the envelope with each 1228 of the expanded addresses in turn. The return (backward-pointing) 1229 address in the envelope is changed so that all error messages 1230 generated by the final deliveries will be returned to a list 1231 administrator, not to the message originator, who generally has no 1232 control over the contents of the list and will typically find error 1233 messages annoying. Note that the key difference between handling 1234 simple aliases Section 3.4.2.1 and redistribution (this subsection) 1235 is the change to the backward-pointing address. When a system 1236 managing a list constrains its processing to the very limited set of 1237 modifications and actions described here, it is acting as part of an 1238 MTA; such list processing, like alias processing, can be treated as a 1239 continuation of email transit. 1241 Mailing list management systems do exist that perform additional, 1242 sometimes extensive, modifications to a message and its envelope. 1243 Such mailing lists need to be viewed as MUAs that accept a message 1244 delivery and then submit a new message for multiple recipients. 1246 3.5. Commands for Debugging Addresses 1248 3.5.1. Overview 1250 SMTP provides commands to verify a user name or obtain the content of 1251 a mailing list. This is done with the VRFY and EXPN commands, which 1252 have character string arguments. Implementations SHOULD support VRFY 1253 and EXPN (however, see Section 3.5.2 and Section 7.3). 1255 For the VRFY command, the string is a user name or a user name and 1256 domain (see below). If a normal (i.e., 250) response is returned, 1257 the response MAY include the full name of the user and MUST include 1258 the mailbox of the user. It MUST be in one of the following forms: 1260 User Name 1261 1262 local-part@domain 1264 When a name that is the argument to VRFY could identify more than one 1265 mailbox, the server MAY either note the ambiguity or identify the 1266 alternatives. In other words, any of the following are legitimate 1267 responses to VRFY: 1269 553 User ambiguous 1271 or 1273 553- Ambiguous; Possibilities are 1274 553-Joe Smith 1275 553-Harry Smith 1276 553 Melvin Smith 1278 or 1280 553-Ambiguous; Possibilities 1281 553- 1282 553- 1283 553 1285 Under normal circumstances, a client receiving a 553 reply would be 1286 expected to expose the result to the user. Use of exactly the forms 1287 given, and the "user ambiguous" or "ambiguous" keywords, possibly 1288 supplemented by extended reply codes, such as those described in RFC 1289 3463 [8], will facilitate automated translation into other languages 1290 as needed. Of course, a client that was highly automated or that was 1291 operating in another language than English might choose to try to 1292 translate the response to return some other indication to the user 1293 than the literal text of the reply, or to take some automated action 1294 such as consulting a directory service for additional information 1295 before reporting to the user. 1297 For the EXPN command, the string identifies a mailing list, and the 1298 successful (i.e., 250) multiline response MAY include the full name 1299 of the users and MUST give the mailboxes on the mailing list. 1301 In some hosts, the distinction between a mailing list and an alias 1302 for a single mailbox is a bit fuzzy, since a common data structure 1303 may hold both types of entries, and it is possible to have mailing 1304 lists containing only one mailbox. If a request is made to apply 1305 VRFY to a mailing list, a positive response MAY be given if a message 1306 so addressed would be delivered to everyone on the list, otherwise an 1307 error SHOULD be reported (e.g., "550 That is a mailing list, not a 1308 user" or "252 Unable to verify members of mailing list"). If a 1309 request is made to expand a user name, the server MAY return a 1310 positive response consisting of a list containing one name, or an 1311 error MAY be reported (e.g., "550 That is a user name, not a mailing 1312 list"). 1314 In the case of a successful multiline reply (normal for EXPN), 1315 exactly one mailbox is to be specified on each line of the reply. 1316 The case of an ambiguous request is discussed above. 1318 "User name" is a fuzzy term and has been used deliberately. An 1319 implementation of the VRFY or EXPN commands MUST include at least 1320 recognition of local mailboxes as "user names". However, since 1321 current Internet practice often results in a single host handling 1322 mail for multiple domains, hosts, especially hosts that provide this 1323 functionality, SHOULD accept the "local-part@domain" form as a "user 1324 name"; hosts MAY also choose to recognize other strings as "user 1325 names". 1327 The case of expanding a mailbox list requires a multiline reply, such 1328 as: 1330 C: EXPN Example-People 1331 S: 250-Jon Postel 1332 S: 250-Fred Fonebone 1333 S: 250 Sam Q. Smith 1335 or 1337 C: EXPN Executive-Washroom-List 1338 S: 550 Access Denied to You. 1340 The character string arguments of the VRFY and EXPN commands cannot 1341 be further restricted due to the variety of implementations of the 1342 user name and mailbox list concepts. On some systems, it may be 1343 appropriate for the argument of the EXPN command to be a file name 1344 for a file containing a mailing list, but again there are a variety 1345 of file naming conventions in the Internet. Similarly, historical 1346 variations in what is returned by these commands are such that the 1347 response SHOULD be interpreted very carefully, if at all, and SHOULD 1348 generally only be used for diagnostic purposes. 1350 3.5.2. VRFY Normal Response 1352 When normal (2yz or 551) responses are returned from a VRFY or EXPN 1353 request, the reply MUST include the name using a "" construction, where "domain" is a fully-qualified 1355 domain name. In circumstances exceptional enough to justify 1356 violating the intent of this specification, free-form text MAY be 1357 returned. In order to facilitate parsing by both computers and 1358 people, addresses SHOULD appear in pointed brackets. When addresses, 1359 rather than free-form debugging information, are returned, EXPN and 1360 VRFY MUST return only valid domain addresses that are usable in SMTP 1361 RCPT commands. Consequently, if an address implies delivery to a 1362 program or other system, the mailbox name used to reach that target 1363 MUST be given. Paths (explicit source routes) MUST NOT be returned 1364 by VRFY or EXPN. 1366 Server implementations SHOULD support both VRFY and EXPN. For 1367 security reasons, implementations MAY provide local installations a 1368 way to disable either or both of these commands through configuration 1369 options or the equivalent (see Section 7.3). When these commands are 1370 supported, they are not required to work across relays when relaying 1371 is supported. Since they were both optional in RFC 821, but VRFY was 1372 made mandatory in RFC 1123 [6], if EXPN is supported, it MUST be 1373 listed as a service extension in an EHLO response. VRFY MAY be 1374 listed as a convenience but, since support for it is required, SMTP 1375 clients are not required to check for its presence on the extension 1376 list before using it. 1378 3.5.3. Meaning of VRFY or EXPN Success Response 1380 A server MUST NOT return a 250 code in response to a VRFY or EXPN 1381 command unless it has actually verified the address. In particular, 1382 a server MUST NOT return 250 if all it has done is to verify that the 1383 syntax given is valid. If only a syntax check is made, 502 (Command 1384 not implemented) or 500 (Syntax error, command unrecognized) SHOULD 1385 be returned. As stated elsewhere, implementation (in the sense of 1386 actually validating addresses and returning information) of VRFY and 1387 EXPN are strongly recommended. Hence, implementations that return 1388 500 or 502 for VRFY are not in full compliance with this 1389 specification. 1391 There may be circumstances where an address appears to be valid but 1392 cannot reasonably be verified in real time, particularly when a 1393 server is acting as a mail exchanger for another server or domain. 1394 "Apparent validity", in this case, would normally involve at least 1395 syntax checking and might involve verification that any domains 1396 specified were ones to which the host expected to be able to relay 1397 mail. In these situations, reply code 252 SHOULD be returned. These 1398 cases parallel the discussion of RCPT verification in Section 2.1. 1399 Similarly, the discussion in Section 3.4.1 applies to the use of 1400 reply codes 251 and 551 with VRFY (and EXPN) to indicate addresses 1401 that are recognized but that would be forwarded or rejected were mail 1402 received for them. Implementations generally SHOULD be more 1403 aggressive about address verification in the case of VRFY than in the 1404 case of RCPT, even if it takes a little longer to do so. 1406 3.5.4. Semantics and Applications of EXPN 1408 EXPN is often very useful in debugging and understanding problems 1409 with mailing lists and multiple-target-address aliases. Some systems 1410 have attempted to use source expansion of mailing lists as a means of 1411 eliminating duplicates. The propagation of aliasing systems with 1412 mail on the Internet for hosts (typically with MX and CNAME DNS 1413 records), for mailboxes (various types of local host aliases), and in 1414 various proxying arrangements has made it nearly impossible for these 1415 strategies to work consistently, and mail systems SHOULD NOT attempt 1416 them. 1418 3.6. Relaying and Mail Routing 1420 3.6.1. Mail eXchange Records and Relaying 1422 A relay SMTP server is usually the target of a DNS MX record that 1423 designates it, rather than the final delivery system. The relay 1424 server may accept or reject the task of relaying the mail in the same 1425 way it accepts or rejects mail for a local user. If it accepts the 1426 task, it then becomes an SMTP client, establishes a transmission 1427 channel to the next SMTP server specified in the DNS (according to 1428 the rules in Section 5), and sends it the mail. If it declines to 1429 relay mail to a particular address for policy reasons, a 550 response 1430 SHOULD be returned. 1432 This specification does not deal with the verification of return 1433 paths. Server efforts to verify a return path and actions to be 1434 taken under various circumstances are outside the scope of this 1435 specification. 1437 3.6.2. Message Submission Servers as Relays 1439 Many mail-sending clients exist, especially in conjunction with 1440 facilities that receive mail via POP3 or IMAP, that have limited 1441 capability to support some of the requirements of this specification, 1442 such as the ability to queue messages for subsequent delivery 1443 attempts. For these clients, it is common practice to make private 1444 arrangements to send all messages to a single server for processing 1445 and subsequent distribution. SMTP, as specified here, is not ideally 1446 suited for this role. A standardized mail submission protocol has 1447 been developed that is gradually superseding practices based on SMTP 1448 (see RFC 6409 [44]). In any event, because these arrangements are 1449 private and fall outside the scope of this specification, they are 1450 not described here. 1452 It is important to note that MX records can point to SMTP servers 1453 that act as gateways into other environments, not just SMTP relays 1454 and final delivery systems; see Sections 3.7 and 5. 1456 If an SMTP server has accepted the task of relaying the mail and 1457 later finds that the destination is incorrect or that the mail cannot 1458 be delivered for some other reason, then it MUST construct an 1459 "undeliverable mail" notification message and send it to the 1460 originator of the undeliverable mail (as indicated by the reverse- 1461 path). Formats specified for non-delivery reports by other standards 1462 (see, for example, RFC 3461 [35] and RFC 3464 [36]) SHOULD be used if 1463 possible. 1465 This notification message must be from the SMTP server at the relay 1466 host or the host that first determines that delivery cannot be 1467 accomplished. Of course, SMTP servers MUST NOT send notification 1468 messages about problems transporting notification messages. One way 1469 to prevent loops in error reporting is to specify a null reverse-path 1470 in the MAIL command of a notification message. When such a message 1471 is transmitted, the reverse-path MUST be set to null (see 1472 Section 4.5.5 for additional discussion). A MAIL command with a null 1473 reverse-path appears as follows: 1475 MAIL FROM:<> 1477 As discussed in Section 6.4, a relay SMTP has no need to inspect or 1478 act upon the header section or body of the message data and MUST NOT 1479 do so except to add its own "Received:" header field (Section 4.4.1 1480 and possibly other trace header fields) and, optionally, to attempt 1481 to detect looping in the mail system (see Section 6.3). Of course, 1482 this prohibition also applies to any modifications of these header 1483 fields or text (see also Section 7.9). 1485 3.7. Mail Gatewaying 1487 While the relay function discussed above operates within the Internet 1488 SMTP transport service environment, MX records or various forms of 1489 explicit routing may require that an intermediate SMTP server perform 1490 a translation function between one transport service and another. As 1491 discussed in Section 2.3.10, when such a system is at the boundary 1492 between two transport service environments, we refer to it as a 1493 "gateway" or "gateway SMTP". 1495 Gatewaying mail between different mail environments, such as 1496 different mail formats and protocols, is complex and does not easily 1497 yield to standardization. However, some general requirements may be 1498 given for a gateway between the Internet and another mail 1499 environment. 1501 3.7.1. Header Fields in Gatewaying 1503 Header fields MAY be rewritten when necessary as messages are 1504 gatewayed across mail environment boundaries. This may involve 1505 inspecting the message body or interpreting the local-part of the 1506 destination address in spite of the prohibitions in Section 6.4. 1508 Other mail systems gatewayed to the Internet often use a subset of 1509 the RFC 822 header section or provide similar functionality with a 1510 different syntax, but some of these mail systems do not have an 1511 equivalent to the SMTP envelope. Therefore, when a message leaves 1512 the Internet environment, it may be necessary to fold the SMTP 1513 envelope information into the message header section. A possible 1514 solution would be to create new header fields to carry the envelope 1515 information (e.g., "X-SMTP-MAIL:" and "X-SMTP-RCPT:"); however, this 1516 would require changes in mail programs in foreign environments and 1517 might risk disclosure of private information (see Section 7.2). 1519 3.7.2. Received Lines in Gatewaying 1521 When forwarding a message into or out of the Internet environment, a 1522 gateway MUST prepend a Received: line, but it MUST NOT alter in any 1523 way a Received: line that is already in the header section. 1525 "Received:" header fields of messages originating from other 1526 environments may not conform exactly to this specification. However, 1527 the most important use of Received: lines is for debugging mail 1528 faults, and this debugging can be severely hampered by well-meaning 1529 gateways that try to "fix" a Received: line. As another consequence 1530 of trace header fields arising in non-SMTP environments, receiving 1531 systems MUST NOT reject mail based on the format of a trace header 1532 field and SHOULD be extremely robust in the light of unexpected 1533 information or formats in those header fields. 1535 The gateway SHOULD indicate the environment and protocol in the "via" 1536 clauses of Received header field(s) that it supplies. 1538 3.7.3. Addresses in Gatewaying 1540 From the Internet side, the gateway SHOULD accept all valid address 1541 formats in SMTP commands and in the RFC 822 header section, and all 1542 valid RFC 822 messages. Addresses and header fields generated by 1543 gateways MUST conform to applicable standards (including this one and 1544 RFC 5322 [13]). Gateways are, of course, subject to the same rules 1545 for handling source routes as those described for other SMTP systems 1546 in Section 3.3. 1548 3.7.4. Other Header Fields in Gatewaying 1550 The gateway MUST ensure that all header fields of a message that it 1551 forwards into the Internet mail environment meet the requirements for 1552 Internet mail. In particular, all addresses in "From:", "To:", 1553 "Cc:", etc., header fields MUST be transformed (if necessary) to 1554 satisfy the standard header syntax of RFC 5322 [13], MUST reference 1555 only fully-qualified domain names, and MUST be effective and useful 1556 for sending replies. The translation algorithm used to convert mail 1557 from the Internet protocols to another environment's protocol SHOULD 1558 ensure that error messages from the foreign mail environment are 1559 delivered to the reverse-path from the SMTP envelope, not to an 1560 address in the "From:", "Sender:", or similar header fields of the 1561 message. 1563 3.7.5. Envelopes in Gatewaying 1565 Similarly, when forwarding a message from another environment into 1566 the Internet, the gateway SHOULD set the envelope return path in 1567 accordance with an error message return address, if supplied by the 1568 foreign environment. If the foreign environment has no equivalent 1569 concept, the gateway must select and use a best approximation, with 1570 the message originator's address as the default of last resort. 1572 3.8. Terminating Sessions and Connections 1574 An SMTP connection is terminated when the client sends a QUIT 1575 command. The server responds with a positive reply code, after which 1576 it closes the connection. 1578 An SMTP server MUST NOT intentionally close the connection under 1579 normal operational circumstances (see Section 7.8) except: 1581 * After receiving a QUIT command and responding with a 221 reply. 1583 * After detecting the need to shut down the SMTP service and 1584 returning a 421 reply code. This reply code can be issued after 1585 the server receives any command or, if necessary, asynchronously 1586 from command receipt (on the assumption that the client will 1587 receive it after the next command is issued). 1589 * After a timeout, as specified in Section 4.5.3.2, occurs waiting 1590 for the client to send a command or data. 1592 In particular, a server that closes connections in response to 1593 commands that are not understood is in violation of this 1594 specification. Servers are expected to be tolerant of unknown 1595 commands, issuing a 500 reply and awaiting further instructions from 1596 the client. 1598 An SMTP server that is forcibly shut down via external means SHOULD 1599 attempt to send a line containing a 421 reply code to the SMTP client 1600 before exiting. The SMTP client will normally read the 421 reply 1601 code after sending its next command. 1603 SMTP clients that experience a connection close, reset, or other 1604 communications failure due to circumstances not under their control 1605 (in violation of the intent of this specification but sometimes 1606 unavoidable) SHOULD, to maintain the robustness of the mail system, 1607 treat the mail transaction as if a 421 response had been received and 1608 act accordingly. 1610 There are circumstances, contrary to the intent of this 1611 specification, in which an SMTP server may receive an indication that 1612 the underlying TCP connection has been closed or reset. To preserve 1613 the robustness of the mail system, SMTP servers SHOULD be prepared 1614 for this condition and SHOULD treat it as if a QUIT had been received 1615 before the connection disappeared. 1617 4. The SMTP Specifications 1619 4.1. SMTP Commands 1621 4.1.1. Command Semantics and Syntax 1623 The SMTP commands define the mail transfer or the mail system 1624 function requested by the user. SMTP commands are character strings 1625 terminated by . The commands themselves are alphabetic 1626 characters terminated by if parameters follow and 1627 otherwise. (In the interest of improved interoperability, SMTP 1628 receivers SHOULD tolerate trailing white space before the terminating 1629 .) The syntax of the local part of a mailbox MUST conform to 1630 receiver site conventions and the syntax specified in Section 4.1.2. 1631 The SMTP commands are discussed below. The SMTP replies are 1632 discussed in Section 4.2. 1634 A mail transaction involves several data objects that are 1635 communicated as arguments to different commands. The reverse-path is 1636 the argument of the MAIL command, the forward-path is the argument of 1637 the RCPT command, and the mail data is the argument of the DATA 1638 command. These arguments or data objects must be transmitted and 1639 held, pending the confirmation communicated by the end of mail data 1640 indication that finalizes the transaction. The model for this is 1641 that distinct buffers are provided to hold the types of data objects; 1642 that is, there is a reverse-path buffer, a forward-path buffer, and a 1643 mail data buffer. Specific commands cause information to be appended 1644 to a specific buffer, or cause one or more buffers to be cleared. 1646 Several commands (RSET, DATA, QUIT) are specified as not permitting 1647 parameters. In the absence of specific extensions offered by the 1648 server and accepted by the client, clients MUST NOT send such 1649 parameters and servers SHOULD reject commands containing them as 1650 having invalid syntax. 1652 4.1.1.1. Extended HELLO (EHLO) or HELLO (HELO) 1654 These commands are used to identify the SMTP client to the SMTP 1655 server. The argument clause contains the fully-qualified domain name 1656 of the SMTP client, if one is available. In situations in which the 1657 SMTP client system does not have a meaningful domain name (e.g., when 1658 its address is dynamically allocated and no reverse mapping record is 1659 available), the client SHOULD send an address literal (see 1660 Section 4.1.3). Additional discussion of domain names in SMTP 1661 commands appears in Section 2.3.5. 1663 RFC 2821, and some earlier informal practices, encouraged following 1664 the literal by information that would help to identify the client 1665 system. That convention was not widely supported, and many SMTP 1666 servers considered it an error. In the interest of interoperability, 1667 it is probably wise for servers to be prepared for this string to 1668 occur, but SMTP clients SHOULD NOT send it. 1670 The SMTP server identifies itself to the SMTP client in the 1671 connection greeting reply and in the response to this command. 1673 A client SMTP SHOULD start an SMTP session by issuing the EHLO 1674 command. If the SMTP server supports the SMTP service extensions, it 1675 will give a successful response, a failure response, or an error 1676 response. If the SMTP server, in violation of this specification, 1677 does not support any SMTP service extensions, it will generate an 1678 error response. Older client SMTP systems MAY, as discussed above, 1679 use HELO (as specified in RFC 821) instead of EHLO, and servers MUST 1680 support the HELO command and reply properly to it. In any event, a 1681 client MUST issue HELO or EHLO before starting a mail transaction. 1683 These commands, and a "250 OK" reply to one of them, confirm that 1684 both the SMTP client and the SMTP server are in the initial state, 1685 that is, there is no transaction in progress and all state tables and 1686 buffers are cleared. 1688 Syntax: 1690 ehlo = "EHLO" SP ( Domain / address-literal ) CRLF 1692 helo = "HELO" SP Domain CRLF 1694 Normally, the response to EHLO will be a multiline reply. Each line 1695 of the response contains a keyword and, optionally, one or more 1696 parameters. Following the normal syntax for multiline replies, these 1697 keywords follow the code (250) and a hyphen for all but the last 1698 line, and the code and a space for the last line. The syntax for a 1699 positive response, using the ABNF notation and terminal symbols of 1700 RFC 5234 [12], is: 1702 ehlo-ok-rsp = ( "250" SP Domain [ SP ehlo-greet ] CRLF ) 1703 / ( "250-" Domain [ SP ehlo-greet ] CRLF 1704 *( "250-" ehlo-line CRLF ) 1705 "250" SP ehlo-line CRLF ) 1707 ehlo-greet = 1*(%d0-9 / %d11-12 / %d14-127) 1708 ; string of any characters other than CR or LF 1710 ehlo-line = ehlo-keyword *( SP ehlo-param ) 1712 ehlo-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") 1713 ; additional syntax of ehlo-params depends on 1714 ; ehlo-keyword 1716 ehlo-param = 1*(%d33-126) 1717 ; any CHAR excluding and all 1718 ; control characters (US-ASCII 0-31 and 127 1719 ; inclusive) 1721 Although EHLO keywords may be specified in upper, lower, or mixed 1722 case, they MUST always be recognized and processed in a case- 1723 insensitive manner. This is simply an extension of practices 1724 specified in RFC 821 and Section 2.4. 1726 The EHLO response MUST contain keywords (and associated parameters if 1727 required) for all commands not listed as "required" in Section 4.5.1. 1729 4.1.1.2. MAIL (MAIL) 1731 This command is used to initiate a mail transaction in which the mail 1732 data is delivered to an SMTP server that may, in turn, deliver it to 1733 one or more mailboxes or pass it on to another system (possibly using 1734 SMTP). The argument clause contains a reverse-path and may contain 1735 optional parameters. In general, the MAIL command may be sent only 1736 when no mail transaction is in progress, see Section 4.1.4. 1738 The reverse-path consists of the sender mailbox. Historically, that 1739 mailbox might optionally have been preceded by a list of hosts, but 1740 that behavior is now deprecated (see Appendix F.2). In some types of 1741 reporting messages for which a reply is likely to cause a mail loop 1742 (for example, mail delivery and non-delivery notifications), the 1743 reverse-path may be null (see Section 3.6). 1745 This command clears the reverse-path buffer, the forward-path buffer, 1746 and the mail data buffer, and it inserts the reverse-path information 1747 from its argument clause into the reverse-path buffer. 1749 If service extensions were negotiated, the MAIL command may also 1750 carry parameters associated with a particular service extension. 1752 Syntax: 1754 mail = "MAIL FROM:" Reverse-path 1755 [SP Mail-parameters] CRLF 1757 4.1.1.3. RECIPIENT (RCPT) 1759 This command is used to identify an individual recipient of the mail 1760 data; multiple recipients are specified by multiple uses of this 1761 command. The argument clause contains a forward-path and may contain 1762 optional parameters. 1764 The forward-path consists of the required destination mailbox. When 1765 mail reaches its ultimate destination, the SMTP server inserts it 1766 into the destination mailbox in accordance with its host mail 1767 conventions. 1769 Prior versions of the SMTP specification included text and examples 1770 in this section of use of the deprecated source route construct. If 1771 desired, see Appendix F.2 for discussion of that mechanism. 1773 This command appends its forward-path argument to the forward-path 1774 buffer; it does not change the reverse-path buffer nor the mail data 1775 buffer. 1777 For example, mail received at relay host xyz.com with envelope 1778 commands 1780 MAIL FROM: 1781 RCPT TO: 1783 will result in a DNS lookup for d.bar.org and transmission to the 1784 host specified in the most-preferred MX record that is available (or 1785 by the address record if there are no MX records). It will use 1786 envelope commands identical to the above, i.e., 1788 MAIL FROM: 1789 RCPT TO: 1791 Since hosts are not required to relay mail at all, xyz.com MAY also 1792 reject the message entirely when the RCPT command is received, using 1793 a 550 code (since this is a "policy reason"). 1795 If the SMTP server determines that a message sent to the mailbox in 1796 the forward-path is not deliverable, it MUST either return an 1797 appropriate response code (see Section 4.2.2) or generate a non- 1798 delivery notification. 1800 If there were multiple failed recipients, either a single 1801 notification listing all of the failed recipients or separate 1802 notification messages MUST be sent for each failed recipient. For 1803 economy of processing by the sender, the former SHOULD be used when 1804 possible. All notification messages about undeliverable mail MUST be 1805 sent using the MAIL command and MUST use a null return path as 1806 discussed in Section 3.6. 1808 If service extensions were negotiated, the RCPT command may also 1809 carry parameters associated with a particular service extension 1810 offered by the server. The client MUST NOT transmit parameters other 1811 than those associated with a service extension offered by the server 1812 in its EHLO response. 1814 Syntax: 1816 rcpt = "RCPT TO:" ( "" / "" / 1817 Forward-path ) [SP Rcpt-parameters] CRLF 1818 Note that, in a departure from the usual rules for 1819 local-parts, the "Postmaster" string shown above is 1820 treated as case-insensitive. 1822 4.1.1.4. DATA (DATA) 1824 The receiver normally sends a 354 response to DATA, and then treats 1825 the lines (strings ending in sequences, as described in 1826 Section 2.3.7) following the command as mail data from the sender. 1827 This command causes the mail data to be appended to the mail data 1828 buffer. The mail data may contain any of the 128 ASCII character 1829 codes, although experience has indicated that use of control 1830 characters other than SP, HT, CR, and LF may cause problems and 1831 SHOULD be avoided when possible. 1833 The mail data are terminated by a line containing only a period, that 1834 is, the character sequence ".", where the first is 1835 actually the terminator of the previous line (see Section 4.5.2). 1836 This is the end of mail data indication. The first of this 1837 terminating sequence is also the that ends the final line of 1838 the data (message text) or, if there was no mail data, ends the DATA 1839 command itself (the "no mail data" case does not conform to this 1840 specification since it would require that neither the trace header 1841 fields required by this specification nor the message header section 1842 required by RFC 5322 [13] be transmitted). An extra MUST NOT 1843 be added, as that would cause an empty line to be added to the 1844 message. The only exception to this rule would arise if the message 1845 body were passed to the originating SMTP-sender with a final "line" 1846 that did not end in ; in that case, the originating SMTP system 1847 MUST either reject the message as invalid or add in order to 1848 have the receiving SMTP server recognize the "end of data" condition. 1850 The custom of accepting lines ending only in , as a concession to 1851 non-conforming behavior on the part of some UNIX systems, has proven 1852 to cause more interoperability problems than it solves, and SMTP 1853 server systems MUST NOT do this, even in the name of improved 1854 robustness. In particular, the sequence "." (bare line 1855 feeds, without carriage returns) MUST NOT be treated as equivalent to 1856 . as the end of mail data indication. 1858 Receipt of the end of mail data indication requires the server to 1859 process the stored mail transaction information. This processing 1860 consumes the information in the reverse-path buffer, the forward-path 1861 buffer, and the mail data buffer, and on the completion of this 1862 command these buffers are cleared. If the processing is successful, 1863 the receiver MUST send an OK reply. If the processing fails, the 1864 receiver MUST send a failure reply. The SMTP model does not allow 1865 for partial failures at this point: either the message is accepted by 1866 the server for delivery and a positive response is returned or it is 1867 not accepted and a failure reply is returned. In sending a positive 1868 "250 OK" completion reply to the end of data indication, the receiver 1869 takes full responsibility for the message (see Section 6.1). Errors 1870 that are diagnosed subsequently MUST be reported in a mail message, 1871 as discussed in Section 4.4. 1873 When the SMTP server accepts a message either for relaying or for 1874 final delivery, it inserts a trace record (also referred to 1875 interchangeably as a "time stamp line" or "Received" line) at the top 1876 of the mail data. This trace record indicates the identity of the 1877 host that sent the message, the identity of the host that received 1878 the message (and is inserting this time stamp), and the date and time 1879 the message was received. Relayed messages will have multiple time 1880 stamp lines. Details for formation of these lines, including their 1881 syntax, is specified in Section 4.4. 1883 Additional discussion about the operation of the DATA command appears 1884 in Section 3.3. 1886 Syntax: 1888 data = "DATA" CRLF 1890 4.1.1.5. RESET (RSET) 1892 This command specifies that the current mail transaction will be 1893 aborted. Any stored sender, recipients, and mail data MUST be 1894 discarded, and all buffers and state tables cleared. The receiver 1895 MUST send a "250 OK" reply to a RSET command with no arguments. A 1896 reset command may be issued by the client at any time. It is 1897 effectively equivalent to a NOOP (i.e., it has no effect) if issued 1898 immediately after EHLO, before EHLO is issued in the session, after 1899 an end of data indicator has been sent and acknowledged, or 1900 immediately before a QUIT. An SMTP server MUST NOT close the 1901 connection as the result of receiving a RSET; that action is reserved 1902 for QUIT (see Section 4.1.1.10). 1904 Since EHLO implies some additional processing and response by the 1905 server, RSET will normally be more efficient than reissuing that 1906 command, even though the formal semantics are the same. 1908 Syntax: 1910 rset = "RSET" CRLF 1912 4.1.1.6. VERIFY (VRFY) 1914 This command asks the receiver to confirm that the argument 1915 identifies a user or mailbox. If it is a user name, information is 1916 returned as specified in Section 3.5. 1918 This command has no effect on the reverse-path buffer, the forward- 1919 path buffer, or the mail data buffer. 1921 Syntax: 1923 vrfy = "VRFY" SP String CRLF 1925 4.1.1.7. EXPAND (EXPN) 1927 This command asks the receiver to confirm that the argument 1928 identifies a mailing list, and if so, to return the membership of 1929 that list. If the command is successful, a reply is returned 1930 containing information as described in Section 3.5. This reply will 1931 have multiple lines except in the trivial case of a one-member list. 1933 This command has no effect on the reverse-path buffer, the forward- 1934 path buffer, or the mail data buffer, and it may be issued at any 1935 time. 1937 Syntax: 1939 expn = "EXPN" SP String CRLF 1941 4.1.1.8. HELP (HELP) 1943 This command causes the server to send helpful information to the 1944 client. The command MAY take an argument (e.g., any command name) 1945 and return more specific information as a response. 1947 This command has no effect on the reverse-path buffer, the forward- 1948 path buffer, or the mail data buffer, and it may be issued at any 1949 time. 1951 SMTP servers SHOULD support HELP without arguments and MAY support it 1952 with arguments. 1954 Syntax: 1956 help = "HELP" [ SP String ] CRLF 1958 4.1.1.9. NOOP (NOOP) 1960 This command does not affect any parameters or previously entered 1961 commands. It specifies no action other than that the receiver send a 1962 "250 OK" reply. 1964 This command has no effect on the reverse-path buffer, the forward- 1965 path buffer, or the mail data buffer, and it may be issued at any 1966 time. If a parameter string is specified, servers SHOULD ignore it. 1968 Syntax: 1970 noop = "NOOP" [ SP String ] CRLF 1972 4.1.1.10. QUIT (QUIT) 1974 This command specifies that the receiver MUST send a "221 OK" reply, 1975 and then close the transmission channel. 1977 The receiver MUST NOT intentionally close the transmission channel 1978 until it receives and replies to a QUIT command (even if there was an 1979 error). The sender MUST NOT intentionally close the transmission 1980 channel until it sends a QUIT command, and it SHOULD wait until it 1981 receives the reply (even if there was an error response to a previous 1982 command). If the connection is closed prematurely due to violations 1983 of the above or system or network failure, the server MUST cancel any 1984 pending transaction, but not undo any previously completed 1985 transaction, and generally MUST act as if the command or transaction 1986 in progress had received a temporary error (i.e., a 4yz response). 1988 The QUIT command may be issued at any time. Any current uncompleted 1989 mail transaction will be aborted. 1991 Syntax: 1993 quit = "QUIT" CRLF 1995 4.1.1.11. Mail-Parameter and Rcpt-Parameter Error Responses 1997 If the server SMTP does not recognize or cannot implement one or more 1998 of the parameters associated with a particular MAIL or RCPT command, 1999 it will return code 555. 2001 If, for some reason, the server is temporarily unable to accommodate 2002 one or more of the parameters associated with a MAIL or RCPT command, 2003 and if the definition of the specific parameter does not mandate the 2004 use of another code, it should return code 455. 2006 Errors specific to particular parameters and their values will be 2007 specified in the parameter's defining RFC. 2009 4.1.2. Command Argument Syntax 2011 The syntax of the argument clauses of the above commands (using the 2012 syntax specified in RFC 5234 [12] where applicable) is given below. 2013 Some terminals not defined in this document, but are defined 2014 elsewhere, specifically: 2016 * In the "core" syntax in Appendix B of RFC 5234 [12]: ALPHA , CRLF 2017 , DIGIT , HEXDIG , and SP 2019 * In the message format syntax in RFC 5322 [13]: atext , CFWS , and 2020 FWS . 2022 Reverse-path = Path / "<>" 2024 Forward-path = Path 2026 Path = "<" Mailbox ">" 2028 Mail-parameters = esmtp-param *(SP esmtp-param) 2030 Rcpt-parameters = esmtp-param *(SP esmtp-param) 2032 esmtp-param = esmtp-keyword ["=" esmtp-value] 2034 esmtp-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") 2036 esmtp-value = 1*(%d33-60 / %d62-126) 2037 ; any CHAR excluding "=", SP, and control 2038 ; characters. If this string is an email address, 2039 ; i.e., a Mailbox, then the "xtext" syntax [35] 2040 ; SHOULD be used. 2042 Keyword = Ldh-str 2044 Argument = Atom 2046 Domain = sub-domain *("." sub-domain) 2048 sub-domain = Let-dig [Ldh-str] 2050 Let-dig = ALPHA / DIGIT 2052 Ldh-str = *( ALPHA / DIGIT / "-" ) Let-dig 2054 address-literal = "[" ( IPv4-address-literal / 2055 IPv6-address-literal / 2056 General-address-literal ) "]" 2057 ; See Section 4.1.3 2059 Mailbox = Local-part "@" ( Domain / address-literal ) 2061 Local-part = Dot-string / Quoted-string 2062 ; MAY be case-sensitive 2064 Dot-string = Atom *("." Atom) 2066 Atom = 1*atext 2068 Quoted-string = DQUOTE 1*QcontentSMTP DQUOTE 2070 QcontentSMTP = qtextSMTP / quoted-pairSMTP 2072 quoted-pairSMTP = %d92 %d32-126 2073 ; i.e., backslash followed by any ASCII 2074 ; graphic (including itself) or SPace 2076 qtextSMTP = %d32-33 / %d35-91 / %d93-126 2077 ; i.e., within a quoted string, any 2078 ; ASCII graphic or space is permitted 2079 ; without backslash-quoting except 2080 ; double-quote and the backslash itself. 2082 String = Atom / Quoted-string 2084 Note that the backslash, "\", is a quote character, which is used to 2085 indicate that the next character is to be used literally (instead of 2086 its normal interpretation). For example, "Joe\,Smith" indicates a 2087 single nine-character user name string with the comma being the 2088 fourth character of that string. 2090 While the above definition for Local-part is relatively permissive, 2091 for maximum interoperability, a mailbox SHOULD NOT be defined with 2092 Local-part requiring (or using) the Quoted-string form or with the 2093 Local-part being case-sensitive. Further, when comparing a Local- 2094 part (e.g., to a specific mailbox name), all quoting MUST be treated 2095 as equivalent. A sending system SHOULD transmit the form that uses 2096 the minimum quoting possible. 2098 For example, the following 3 local-parts are equivalent and MUST 2099 compare equal: "ab cd ef", "ab\^nbsp;cd^nbsp;ef" and "ab\^nbsp;\cd 2100 ef". Similarly, "fred" and fred must compare equal. White space 2101 reduction MUST NOT be applied to Local-part by intermediate 2102 systems. As particular examples, systems that are not making final 2103 delivery MUST NOT make assumptions about the relationships among 2104 "ab^nbsp;^nbsp;^nbsp; cd"@example.com and "ab^nbsp;cd"@example.com or 2105 even "^nbsp;"@example.com and ""@example.com. 2107 In the absence of extensions, systems MUST NOT define mailboxes in 2108 such a way as to require the use in SMTP of non-ASCII characters 2109 (octets with the high order bit set to one) or ASCII "control 2110 characters" (decimal value 0-31 and 127) [2][3]. Extensions have 2111 been standardized for such use [38][39]. These characters MUST NOT 2112 be used in MAIL or RCPT commands or other commands that require 2113 mailbox names. 2115 To promote interoperability and consistent with long-standing 2116 guidance about conservative use of the DNS in naming and applications 2117 (e.g., see Section 2.3.1 of the base DNS document, RFC 1035 [5]), 2118 characters outside the set of alphabetic characters, digits, and 2119 hyphen MUST NOT appear in domain name labels for SMTP clients or 2120 servers. In particular, the underscore character is not permitted. 2121 SMTP servers that receive a command in which invalid character codes 2122 have been employed, and for which there are no other reasons for 2123 rejection, MUST reject that command with a 501 response (this rule, 2124 like others, could be overridden by appropriate SMTP extensions). 2126 4.1.3. Address Literals 2128 Sometimes a host is not known to the domain name system and 2129 communication (and, in particular, communication to report and repair 2130 the error) is blocked. To bypass this barrier, a special literal 2131 form of the address is allowed as an alternative to a domain name. 2132 For IPv4 addresses, this form uses four small decimal integers 2133 separated by dots and enclosed by brackets such as [123.255.37.2], 2134 which indicates an (IPv4) Internet Address in sequence-of-octets 2135 form. For IPv6 and other forms of addressing that might eventually 2136 be standardized, the form consists of a standardized "tag" that 2137 identifies the address syntax, a colon, and the address itself, in a 2138 format specified as part of the relevant standards (i.e., RFC 4291 2139 [11] for IPv6). 2141 Specifically: 2143 IPv4-address-literal = Snum 3("." Snum) 2145 IPv6-address-literal = "IPv6:" IPv6-addr 2147 General-address-literal = Standardized-tag ":" 1*dcontent 2149 Standardized-tag = Ldh-str 2150 ; Standardized-tag MUST be specified in a 2151 ; Standards-Track RFC and registered with IANA 2153 dcontent = %d33-90 / ; Printable US-ASCII 2154 %d94-126 ; excl. "[", "\", "]" 2156 Snum = 1*3DIGIT 2157 ; representing a decimal integer 2158 ; value in the range 0 through 255 2160 IPv6-addr = 6( h16 ":" ) ls32 2161 / "::" 5( h16 ":" ) ls32 2162 / [ h16 ] "::" 4( h16 ":" ) ls32 2163 / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32 2164 / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32 2165 / [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32 2166 / [ *4( h16 ":" ) h16 ] "::" ls32 2167 / [ *5( h16 ":" ) h16 ] "::" h16 2168 / [ *6( h16 ":" ) h16 ] "::" 2169 ; This definition is consistent with the one for 2170 ; URIs [43]. 2172 ls32 = ( h16 ":" h16 ) / IPv4address 2173 ; least-significant 32 bits of address 2175 h16 = 1*4HEXDIG 2176 ; 16 bits of address represented in hexadecimal 2178 4.1.4. Order of Commands 2180 There are restrictions on the order in which these commands may be 2181 used. 2183 A session that will contain mail transactions MUST first be 2184 initialized by the use of the EHLO command. An SMTP server SHOULD 2185 accept commands for non-mail transactions (e.g., VRFY, EXPN, or NOOP) 2186 without this initialization. 2188 An EHLO command MAY be issued by a client later in the session. If 2189 it is issued after the session begins and the EHLO command is 2190 acceptable to the SMTP server, the SMTP server MUST clear all buffers 2191 and reset the state exactly as if a RSET command had been issued 2192 (specifically, it terminates any mail transaction that was in 2193 progress, see Section 3.3). In other words, the sequence of RSET 2194 followed immediately by EHLO is redundant, but not harmful other than 2195 in the performance cost of executing unnecessary commands. However 2196 the response to an additional EHLO command MAY be different from that 2197 from prior ones; the client MUST rely only on the responses from the 2198 most recent EHLO command. 2200 If the EHLO command is not acceptable to the SMTP server, 501, 500, 2201 502, or 550 failure replies MUST be returned as appropriate. The 2202 SMTP server MUST stay in the same state after transmitting these 2203 replies that it was in before the EHLO was received. 2205 The SMTP client MUST, if possible, ensure that the domain parameter 2206 to the EHLO command is a primary host name as specified for this 2207 command in Section 2.3.5. If this is not possible (e.g., when the 2208 client's address is dynamically assigned and the client does not have 2209 an obvious name), an address literal SHOULD be substituted for the 2210 domain name. 2212 An SMTP server MAY verify that the domain name argument in the EHLO 2213 command has an address record matching the IP address of the client 2214 by looking up the domain name and making the comparison. 2216 The NOOP, HELP, EXPN, VRFY, and RSET commands can be used at any time 2217 during a session, or without previously initializing a session. SMTP 2218 servers SHOULD process these normally (that is, not return a 503 2219 code) even if no EHLO command has yet been received; clients SHOULD 2220 open a session with EHLO before sending these commands. 2222 If these rules are followed, the example in RFC 821 that shows "550 2223 access denied to you" in response to an EXPN command is incorrect 2224 unless an EHLO command precedes the EXPN or the denial of access is 2225 based on the client's IP address or other authentication or 2226 authorization-determining mechanisms. 2228 A mail transaction begins with a MAIL command and then consists of 2229 one or more RCPT commands, and a DATA command, in that order. A mail 2230 transaction may be aborted by the RSET, a new EHLO, or the QUIT 2231 command. 2233 SMTP extensions (see Section 2.2) may create additional commands that 2234 initiate, abort, or end the transaction.More generally, any new 2235 command MUST clearly document any effect it has on the transaction 2236 state. 2238 There may be zero or more transactions in a session. MAIL MUST NOT 2239 be sent if a mail transaction is already open, i.e., it should be 2240 sent only if no mail transaction had been started in the session, or 2241 if the previous one successfully concluded with a successful DATA 2242 command, or if the previous one was aborted, e.g., with a RSET or new 2243 EHLO. 2245 If the transaction beginning command argument is not acceptable, a 2246 501 failure reply MUST be returned and the SMTP server MUST stay in 2247 the same state. If the commands in a transaction are out of order to 2248 the degree that they cannot be processed by the server, a 503 failure 2249 reply MUST be returned and the SMTP server MUST stay in the same 2250 state. 2252 The last command in a session MUST be the QUIT command. The QUIT 2253 command SHOULD be used by the client SMTP to request connection 2254 closure, even when no session opening command was sent and accepted. 2256 4.2. SMTP Replies 2258 Replies to SMTP commands serve to ensure the synchronization of 2259 requests and actions in the process of mail transfer and to guarantee 2260 that the SMTP client always knows the state of the SMTP server. 2261 Every command MUST generate exactly one reply. 2263 The details of the command-reply sequence are described in 2264 Section 4.3. 2266 An SMTP reply consists of a three digit number (transmitted as three 2267 numeric characters) followed by some text unless specified otherwise 2268 in this document. The number is for use by automata to determine 2269 what state to enter next; the text is for the human user. The three 2270 digits contain enough encoded information that the SMTP client need 2271 not examine the text and may either discard it or pass it on to the 2272 user, as appropriate. Exceptions are as noted elsewhere in this 2273 document. In particular, the 220, 221, 251, 421, and 551 reply codes 2274 are associated with message text that must be parsed and interpreted 2275 by machines. In the general case, the text may be receiver dependent 2276 and context dependent, so there are likely to be varying texts for 2277 each reply code. A discussion of the theory of reply codes is given 2278 in Section 4.2.1. Formally, a reply is defined to be the sequence: a 2279 three-digit code, , one line of text, and , or a multiline 2280 reply (as defined in the same section). Since, in violation of this 2281 specification, the text is sometimes not sent, clients that do not 2282 receive it SHOULD be prepared to process the code alone (with or 2283 without a trailing space character). Only the EHLO, EXPN, and HELP 2284 commands are expected to result in multiline replies in normal 2285 circumstances; however, multiline replies are allowed for any 2286 command. 2288 In ABNF, server responses are: 2290 Greeting = ( "220 " (Domain / address-literal) 2291 [ SP textstring ] CRLF ) / 2292 ( "220-" (Domain / address-literal) 2293 [ SP textstring ] CRLF 2294 *( "220-" [ textstring ] CRLF ) 2295 "220" [ SP textstring ] CRLF ) 2297 textstring = 1*(%d09 / %d32-126) ; HT, SP, Printable US-ASCII 2299 Reply-line = *( Reply-code "-" [ textstring ] CRLF ) 2300 Reply-code [ SP textstring ] CRLF 2302 Reply-code = %x32-35 %x30-35 %x30-39 2304 where "Greeting" appears only in the 220 response that announces that 2305 the server is opening its part of the connection. (Other possible 2306 server responses upon connection follow the syntax of Reply-line.) 2308 An SMTP server SHOULD send only the reply codes listed in this 2309 document or additions to the list as discussed below. An SMTP server 2310 SHOULD use the text shown in the examples whenever appropriate. 2312 An SMTP client MUST determine its actions only by the reply code, not 2313 by the text (except for the "change of address" 251 and 551 and, if 2314 necessary, 220, 221, and 421 replies); in the general case, any text, 2315 including no text at all (although senders SHOULD NOT send bare 2316 codes), MUST be acceptable. The space (blank) following the reply 2317 code is considered part of the text. A Sender-SMTP MUST first test 2318 the whole 3 digit reply code it receives, as well as any accompanying 2319 supplemental codes or information (see RFC 3463 [8] and RFC 5248 2320 [46]). If the full reply code is not recognized, and the additional 2321 information is not recognized or missing, the Sender-SMTP MUST use 2322 the first digit (severity indication) of a reply code it receives. 2324 The list of codes that appears below MUST NOT be construed as 2325 permanent. While the addition of new codes should be a rare and 2326 significant activity, with supplemental information in the textual 2327 part of the response (including enhanced status codes [8] and the 2328 successors to that specification) being preferred, new codes may be 2329 added as the result of new Standards or Standards-Track 2330 specifications. Consequently, a sender-SMTP MUST be prepared to 2331 handle codes not specified in this document and MUST do so by 2332 interpreting the first digit only. 2334 In the absence of extensions negotiated with the client, SMTP servers 2335 MUST NOT send reply codes whose first digits are other than 2, 3, 4, 2336 or 5. Clients that receive such out-of-range codes SHOULD normally 2337 treat them as fatal errors and terminate the mail transaction. 2339 4.2.1. Reply Code Severities and Theory 2341 The three digits of the reply each have a special significance. The 2342 first digit denotes whether the response is good, bad, or incomplete. 2343 An unsophisticated SMTP client, or one that receives an unexpected 2344 code, will be able to determine its next action (proceed as planned, 2345 redo, retrench, etc.) by examining this first digit. An SMTP client 2346 that wants to know approximately what kind of error occurred (e.g., 2347 mail system error, command syntax error) may examine the second 2348 digit. The third digit and any supplemental information that may be 2349 present is reserved for the finest gradation of information. 2351 There are four values for the first digit of the reply code: 2353 2yz Positive Completion reply 2354 The requested action has been successfully completed. A new 2355 request may be initiated. 2357 3yz Positive Intermediate reply 2358 The command has been accepted, but the requested action is being 2359 held in abeyance, pending receipt of further information. The 2360 SMTP client should send another command specifying this 2361 information. This reply is used in command sequence groups (i.e., 2362 in DATA). 2364 4yz Transient Negative Completion reply 2365 The command was not accepted, and the requested action did not 2366 occur. However, the error condition is temporary, and the action 2367 may be requested again. The sender should return to the beginning 2368 of the command sequence (if any). It is difficult to assign a 2369 meaning to "transient" when two different sites (receiver- and 2370 sender-SMTP agents) must agree on the interpretation. Each reply 2371 in this category might have a different time value, but the SMTP 2372 client SHOULD try again. A rule of thumb to determine whether a 2373 reply fits into the 4yz or the 5yz category (see below) is that 2374 replies are 4yz if they can be successful if repeated without any 2375 change in command form or in properties of the sender or receiver 2376 (that is, the command is repeated identically and the receiver 2377 does not put up a new implementation). 2379 5yz Permanent Negative Completion reply 2380 The command was not accepted and the requested action did not 2381 occur. The SMTP client SHOULD NOT repeat the exact request (in 2382 the same sequence). Even some "permanent" error conditions can be 2383 corrected, so the human user may want to direct the SMTP client to 2384 reinitiate the command sequence by direct action at some point in 2385 the future (e.g., after the spelling has been changed, or the user 2386 has altered the account status). 2388 It is worth noting that the file transfer protocol (FTP) [16] uses a 2389 very similar code architecture and that the SMTP codes are based on 2390 the FTP model. However, SMTP uses a one-command, one-response model 2391 (while FTP is asynchronous) and FTP's 1yz codes are not part of the 2392 SMTP model. 2394 The second digit encodes responses in specific categories: 2396 x0z Syntax: These replies refer to syntax errors, syntactically 2397 correct commands that do not fit any functional category, and 2398 unimplemented or superfluous commands. 2400 x1z Information: These are replies to requests for information, such 2401 as status or help. 2403 x2z Connections: These are replies referring to the transmission 2404 channel. 2406 x3z Unspecified. 2408 x4z Unspecified. 2410 x5z Mail system: These replies indicate the status of the receiver 2411 mail system vis-a-vis the requested transfer or other mail system 2412 action. 2414 The third digit gives a finer gradation of meaning in each category 2415 specified by the second digit. The list of replies illustrates this. 2416 Each reply text is recommended rather than mandatory, and may even 2417 change according to the command with which it is associated. On the 2418 other hand, the reply codes must strictly follow the specifications 2419 in this section. Receiver implementations should not invent new 2420 codes for slightly different situations from the ones described here, 2421 but rather adapt codes already defined. 2423 For example, a command such as NOOP, whose successful execution does 2424 not offer the SMTP client any new information, will return a 250 2425 reply. The reply is 502 when the command requests an unimplemented 2426 non-site-specific action. A refinement of that is the 504 reply for 2427 a command that is implemented, but that requests an unimplemented 2428 parameter. 2430 The reply text may be longer than a single line; in these cases the 2431 complete text must be marked so the SMTP client knows when it can 2432 stop reading the reply. This requires a special format to indicate a 2433 multiple line reply. 2435 The format for multiline replies requires that every line, except the 2436 last, begin with the reply code, followed immediately by a hyphen, 2437 "-" (also known as minus), followed by text. The last line will 2438 begin with the reply code, followed immediately by , optionally 2439 some text, and . As noted above, servers SHOULD send the 2440 if subsequent text is not sent, but clients MUST be prepared for it 2441 to be omitted. 2443 For example: 2445 250-First line 2446 250-Second line 2447 250-234 Text beginning with numbers 2448 250 The last line 2450 In a multiline reply, the reply code on each of the lines MUST be the 2451 same. It is reasonable for the client to rely on this, so it can 2452 make processing decisions based on the code in any line, assuming 2453 that all others will be the same. In a few cases, there is important 2454 data for the client in the reply "text". The client will be able to 2455 identify these cases from the current context. 2457 4.2.2. Reply Codes by Function Groups 2459 500 Syntax error, command unrecognized (This may include errors such 2460 as command line too long) 2462 501 Syntax error in parameters or arguments 2464 502 Command not implemented (see Section 4.2.4.1) 2466 503 Bad sequence of commands 2468 504 Command parameter not implemented 2470 211 System status, or system help reply 2472 214 Help message (Information on how to use the receiver or the 2473 meaning of a particular non-standard command; this reply is useful 2474 only to the human user) 2476 220 Service ready 2478 221 Service closing transmission channel 2480 421 Service not available, closing transmission channel 2481 (This may be a reply to any command if the service knows it must 2482 shut down) 2484 521 No mail service here. 2486 556 No mail service at this domain. 2488 250 Requested mail action okay, completed 2490 251 User not local; will forward to (See 2491 Section 3.4.1) 2493 252 Cannot VRFY user, but will accept message and attempt delivery 2494 (See Section 3.5.3) 2496 455 Server unable to accommodate parameters 2498 555 MAIL FROM/RCPT TO parameters not recognized or not implemented 2500 450 Requested mail action not taken: mailbox unavailable (e.g., 2501 mailbox busy or temporarily blocked for policy reasons) 2503 550 Requested action not taken: mailbox unavailable (e.g., mailbox 2504 not found, no access, or command rejected for policy reasons) 2506 451 Requested action aborted: error in processing 2508 551 User not local; please try (See Section 3.4.1) 2509 452 Requested action not taken: insufficient system storage 2510 (preferred code for "too many recipients", see Section 4.5.3.1.10) 2512 552 Requested mail action aborted: exceeded storage allocation. 2514 553 Requested action not taken: mailbox name not allowed (e.g., 2515 mailbox syntax incorrect) 2517 354 Start mail input; end with . 2519 554 Transaction failed (Or, historically in the case of a 2520 connection-opening response, "No SMTP service here". 521 is now 2521 preferred for that function at connection-opening if the server 2522 never accepts mail.) 2524 4.2.3. Reply Codes in Numeric Order 2526 211 System status, or system help reply 2528 214 Help message (Information on how to use the receiver or the 2529 meaning of a particular non-standard command; this reply is useful 2530 only to the human user) 2532 220 Service ready 2534 221 Service closing transmission channel 2536 250 Requested mail action okay, completed 2538 251 User not local; will forward to (See 2539 Section 3.4.1) 2541 252 Cannot VRFY user, but will accept message and attempt delivery 2542 (See Section 3.5.3) 2544 354 Start mail input; end with . 2546 421 Service not available, closing transmission channel 2547 (This may be a reply to any command if the service knows it must 2548 shut down) 2550 450 Requested mail action not taken: mailbox unavailable (e.g., 2551 mailbox busy or temporarily blocked for policy reasons) 2553 451 Requested action aborted: local error in processing 2555 452 Requested action not taken: insufficient system storage (also 2556 preferred code for "too many recipients", see Section 4.5.3.1.10) 2558 455 Server unable to accommodate parameters 2560 500 Syntax error, command unrecognized (This may include errors such 2561 as command line too long) 2563 501 Syntax error in parameters or arguments 2565 502 Command not implemented (see Section 4.2.4.1) 2567 503 Bad sequence of commands 2569 504 Command parameter not implemented 2571 521 No mail service (See Section 4.2.4.2.) 2573 550 Requested action not taken: mailbox unavailable (e.g., mailbox 2574 not found, no access, or command rejected for policy reasons) 2576 551 User not local; please try (See Section 3.4.1) 2578 552 Requested mail action aborted: exceeded storage allocation. 2580 553 Requested action not taken: mailbox name not allowed (e.g., 2581 mailbox syntax incorrect) 2583 554 Transaction failed (Or, in the case of a connection-opening 2584 response, "No SMTP service here" although 521 is now preferred for 2585 the latter. See Section 4.2.4.2.) 2587 555 MAIL FROM/RCPT TO parameters not recognized or not implemented 2589 556 No mail service at this domain. (See Section 4.2.4.2.) 2591 4.2.4. Some specific code situations and relationships 2593 4.2.4.1. Reply Code 502 2595 Questions have been raised as to when reply code 502 (Command not 2596 implemented) SHOULD be returned in preference to other codes. 502 2597 SHOULD be used when the command is actually recognized by the SMTP 2598 server, but not implemented. If the command is not recognized, code 2599 500 SHOULD be returned. Extended SMTP systems MUST NOT list 2600 capabilities in response to EHLO for which they will return 502 (or 2601 500) replies. 2603 4.2.4.2. "No mail accepted" situations and the 521, 554, and 556 codes 2605 Codes 521, 554, and 556 are all used to report different types of "no 2606 mail accepted" situations. They differ as follows. 521 is an 2607 indication from a system answering on the SMTP port that it does not 2608 support SMTP service (a so-called "dummy server" as discussed in RFC 2609 7504 [48] and elsewhere). Obviously, it requires that system exist 2610 and that a connection can be made successfully to it. Because a 2611 system that does not accept any mail cannot meaningfully accept a 2612 RCPT command, any commands (other than QUIT) issued after an SMTP 2613 server has issued a 521 reply are client (sender) errors. 2615 When a domain does not intend to accept mail and wishes to publish 2616 that fact rather than being subjected to connection attempts, the 2617 best way to accomplish that is to use the "Null MX" convention. This 2618 is done by advertising a single MX RR (see Section 3.3.9 of RFC 1035 2619 [5]) with an RDATA section consisting of preference number 0 and a 2620 zero-length label, written in master files as ".", as the exchange 2621 domain, to denote that there exists no mail exchanger for that 2622 domain. Reply code 556 is then used by a message submission or 2623 intermediate SMTP system (see Section 1.1) to report that it cannot 2624 forward the message further because it knows from the DNS entry that 2625 the recipient domain does not accept mail. If, despite publishing 2626 the DNS entry, the host associated with the server domain chooses to 2627 respond on the SMTP port, it SHOULD respond with the 556 code as 2628 well. The details of the Null MX convention were first defined in 2629 RFC 7505 [49]; see that document for additional discussion of the 2630 rationale for that convention. 2632 Reply code 554 would normally be used in response to a RCPT command 2633 (or extension command with similar intent) when the SMTP system 2634 identifies a domain that it can (or has) determined never accepts 2635 mail. Other codes, including 554 and the temporary 450, are used for 2636 more transient situations and situations in which an SMTP server 2637 cannot or will not deliver to (or accept mail for) a particular 2638 system or mailbox for policy reasons rather than ones directly 2639 related to SMTP processing. 2641 // [JcK 20210904]: do we want/need to discuss temporary server 2642 // outages? And is the discussion above sufficient to obsolete RFC 2643 // 7505 or do we need either more text or some pretense to claim to 2644 // update it. 2646 4.2.4.3. Reply Codes after DATA and the Subsequent . 2648 When an SMTP server returns a positive completion status (2yz code) 2649 after the DATA command is completed with ., it accepts 2650 responsibility for: 2652 * delivering the message (if the recipient mailbox exists), or 2654 * if attempts to deliver the message fail due to transient 2655 conditions, retrying delivery some reasonable number of times at 2656 intervals as specified in Section 4.5.4. 2658 * if attempts to deliver the message fail due to permanent 2659 conditions, or if repeated attempts to deliver the message fail 2660 due to transient conditions, returning appropriate notification to 2661 the sender of the original message (using the address in the SMTP 2662 MAIL command). 2664 When an SMTP server returns a temporary error status (4yz) code after 2665 the DATA command is completed with ., it MUST NOT make a 2666 subsequent attempt to deliver that message. The SMTP client retains 2667 responsibility for the delivery of that message and may either return 2668 it to the user or requeue it for a subsequent attempt (see 2669 Section 4.5.4.1). 2671 The user who originated the message SHOULD be able to interpret the 2672 return of a transient failure status (by mail message or otherwise) 2673 as a non-delivery indication, just as a permanent failure would be 2674 interpreted. If the client SMTP successfully handles these 2675 conditions, the user will not receive such a reply. 2677 When an SMTP server returns a permanent error status (5yz) code after 2678 the DATA command is completed with ., it MUST NOT make 2679 any subsequent attempt to deliver the message. As with temporary 2680 error status codes, the SMTP client retains responsibility for the 2681 message, but SHOULD NOT again attempt delivery to the same server 2682 without user review of the message and response and appropriate 2683 intervention. 2685 4.3. Sequencing of Commands and Replies 2686 4.3.1. Sequencing Overview 2688 The communication between the sender and receiver is an alternating 2689 dialogue, controlled by the sender. As such, the sender issues a 2690 command and the receiver responds with a reply. Unless other 2691 arrangements are negotiated through service extensions, the sender 2692 MUST wait for this response before sending further commands. One 2693 important reply is the connection greeting. Normally, a receiver 2694 will send a 220 "Service ready" reply when the connection is 2695 completed. The sender SHOULD wait for this greeting message before 2696 sending any commands. 2698 Note: all the greeting-type replies have the official name (the 2699 fully-qualified primary domain name) of the server host as the first 2700 word following the reply code. Sometimes the host will have no 2701 meaningful name. See Section 4.1.3 for a discussion of alternatives 2702 in these situations. 2704 For example, 2706 220 ISIF.USC.EDU Service ready 2708 or 2710 220 mail.example.com SuperSMTP v 6.1.2 Service ready 2712 or 2714 220 [10.0.0.1] Clueless host service ready 2716 The table below lists alternative success and failure replies for 2717 each command. These SHOULD be strictly adhered to. A receiver MAY 2718 substitute text in the replies, but the meanings and actions implied 2719 by the code numbers and by the specific command reply sequence MUST 2720 be preserved. However, in order to provide robustness as SMTP is 2721 extended and evolves, the discussion in Section 4.2.1 still applies: 2722 all SMTP clients MUST be prepared to accept any code that conforms to 2723 the discussion in that section and MUST be prepared to interpret it 2724 on the basis of its first digit only. 2726 4.3.2. Command-Reply Sequences 2728 Each command is listed with its usual possible replies. The prefixes 2729 used before the possible replies are "I" for intermediate, "S" for 2730 success, and "E" for error. Since some servers may generate other 2731 replies under special circumstances, and to allow for future 2732 extension, SMTP clients SHOULD, when possible, interpret only the 2733 first digit of the reply and MUST be prepared to deal with 2734 unrecognized reply codes by interpreting the first digit only. 2735 Unless extended using the mechanisms described in Section 2.2, SMTP 2736 servers MUST NOT transmit reply codes to an SMTP client that are 2737 other than three digits or that do not start in a digit between 2 and 2738 5 inclusive. 2740 These sequencing rules and, in principle, the codes themselves, can 2741 be extended or modified by SMTP extensions offered by the server and 2742 accepted (requested) by the client. However, if the target is more 2743 precise granularity in the codes, rather than codes for completely 2744 new purposes, the system described in RFC 3463 [8] SHOULD be used in 2745 preference to the invention of new codes. 2747 In addition to the codes listed below, any SMTP command can return 2748 any of the following codes if the corresponding unusual circumstances 2749 are encountered: 2751 500 For the "command line too long" case or if the command name was 2752 not recognized. Note that producing a "command not recognized" 2753 error in response to the required subset of these commands is a 2754 violation of this specification. Similarly, producing a "command 2755 too long" message for a command line shorter than 512 characters 2756 would violate the provisions of Section 4.5.3.1.4. 2758 501 Syntax error in command or arguments. In order to provide for 2759 future extensions, commands that are specified in this document as 2760 not accepting arguments (DATA, RSET, QUIT) SHOULD return a 501 2761 message if arguments are supplied in the absence of EHLO- 2762 advertised extensions. 2764 421 Service shutting down and closing transmission channel 2766 Specific sequences are: 2768 CONNECTION ESTABLISHMENT 2770 - S: 220 2771 E: 521, 554, 556 2773 EHLO or HELO 2775 - S: 250 2776 E: 504 (a conforming implementation could return this code only 2777 in fairly obscure cases), 550, 502 (permitted only with an old- 2778 style server that does not support EHLO) 2780 MAIL 2781 - S: 250 2782 E: 552, 451, 452, 550, 553, 503, 455, 555 2784 RCPT 2786 // Depending about what is done about 554 when the server is not 2787 // accepting mail from a particular domain (see Section 4.2.4.2 2788 and 2789 // Ticket #62) an additional cross-reference may be needed here 2790 and 2791 // 554 added to the list of codes. 2793 - S: 250, 251 (but see Section 3.4.1 for discussion of 251 and 2794 551) 2795 E: 550, 551, 552 (obsolete for "too many recipients; see 2796 Section 4.5.3.1.10), 553, 450, 451, 452, 503, 455, 555 2798 DATA 2800 - I: 354 -> data -> S: 250 2802 o E: 552, 554, 451, 452 2804 o E: 450, 550 (rejections for policy reasons) 2806 - E: 503, 554 2808 RSET 2810 - S: 250 2812 VRFY 2814 - S: 250, 251, 252 2815 E: 550, 551, 553, 502, 504 2817 EXPN 2819 - S: 250, 252 2820 E: 550, 500, 502, 504 2822 HELP 2824 - S: 211, 214 2825 E: 502, 504 2827 NOOP 2828 - S: 250 2830 QUIT 2832 - S: 221 2834 4.4. Trace Information 2836 Trace information is used to provide an audit trail of message 2837 handling. In addition, it indicates a route back to the sender of 2838 the message. 2840 4.4.1. Received Header Field 2842 When an SMTP server receives a message for delivery or further 2843 processing, it MUST insert trace (often referred to as "time stamp" 2844 or "Received" information) at the beginning of the message content, 2845 as discussed in Section 4.1.1.4. 2847 This line MUST be structured as follows: 2849 * The FROM clause, which MUST be supplied in an SMTP environment, 2850 SHOULD contain both (1) the name of the source host as presented 2851 in the EHLO command and (2) an address literal containing the IP 2852 address of the source, determined from the TCP connection. 2854 * The ID clause MAY contain an "@" as suggested in RFC 822, but this 2855 is not required. 2857 * If the FOR clause appears, it MUST contain exactly one 2858 entry, even when multiple RCPT commands have been given. Multiple 2859 s raise some security issues and have been deprecated, see 2860 Section 7.2. 2862 An Internet mail program MUST NOT change or delete a Received: line 2863 that was previously added to the message header section. SMTP 2864 servers MUST prepend Received lines to messages; they MUST NOT change 2865 the order of existing lines or insert Received lines in any other 2866 location. 2868 As the Internet grows, comparability of Received header fields is 2869 important for detecting problems, especially slow relays. SMTP 2870 servers that create Received header fields SHOULD use explicit 2871 offsets in the dates (e.g., -0800), rather than time zone names of 2872 any type. Local time (with an offset) SHOULD be used rather than UT 2873 when feasible. This formulation allows slightly more information 2874 about local circumstances to be specified. If UT is needed, the 2875 receiver need merely do some simple arithmetic to convert the values. 2877 Use of UT loses information about the time zone-location of the 2878 server. If it is desired to supply a time zone name, it SHOULD be 2879 included in a comment. 2881 When the delivery SMTP server makes the "final delivery" of a 2882 message, it inserts a return-path line at the beginning of the mail 2883 data. This use of return-path is required; mail systems MUST support 2884 it. The return-path line preserves the information in the from the MAIL command. Here, final delivery means the message 2886 has left the SMTP environment. Normally, this would mean it had been 2887 delivered to the destination user or an associated mail drop, but in 2888 some cases it may be further processed and transmitted by another 2889 mail system. 2891 It is possible for the mailbox in the return path to be different 2892 from the actual sender's mailbox, for example, if error responses are 2893 to be delivered to a special error handling mailbox rather than to 2894 the message sender. When mailing lists are involved, this 2895 arrangement is common and useful as a means of directing errors to 2896 the list maintainer rather than the message originator. 2898 The text above implies that the final mail data will begin with a 2899 return path line, followed by one or more time stamp lines. These 2900 lines will be followed by the rest of the mail data: first the 2901 balance of the mail header section and then the body (RFC 5322 [13]). 2903 It is sometimes difficult for an SMTP server to determine whether or 2904 not it is making final delivery since forwarding or other operations 2905 may occur after the message is accepted for delivery. Consequently, 2906 any further (forwarding, gateway, or relay) systems MAY remove the 2907 return path and rebuild the MAIL command as needed to ensure that 2908 exactly one such line appears in a delivered message. 2910 A message-originating SMTP system SHOULD NOT send a message that 2911 already contains a Return-path header field. SMTP servers performing 2912 a relay function MUST NOT inspect the message data, and especially 2913 not to the extent needed to determine if Return-path header fields 2914 are present. SMTP servers making final delivery MAY remove Return- 2915 path header fields before adding their own. 2917 The primary purpose of the Return-path is to designate the address to 2918 which messages indicating non-delivery or other mail system failures 2919 are to be sent. For this to be unambiguous, exactly one return path 2920 SHOULD be present when the message is delivered. Systems using RFC 2921 822 syntax with non-SMTP transports SHOULD designate an unambiguous 2922 address, associated with the transport envelope, to which error 2923 reports (e.g., non-delivery messages) should be sent. 2925 Historical note: Text in RFC 822 that appears to contraindicate the 2926 use of the Return-path header field (or the envelope reverse-path 2927 address from the MAIL command) if the destination for error messages 2928 is not applicable on the Internet. The reverse-path address (as 2929 copied into the Return-path) MUST be used as the target of any mail 2930 containing delivery error messages. 2932 In particular: 2934 * a gateway from SMTP -> elsewhere SHOULD insert a return-path 2935 header field, unless it is known that the "elsewhere" transport 2936 also uses Internet domain addresses and maintains the envelope 2937 sender address separately. 2939 * a gateway from elsewhere -> SMTP SHOULD delete any return-path 2940 header field present in the message, and either copy that 2941 information to the SMTP envelope or combine it with information 2942 present in the envelope of the other transport system to construct 2943 the reverse-path argument to the MAIL command in the SMTP 2944 envelope. 2946 The server must give special treatment to cases in which the 2947 processing following the end of mail data indication is only 2948 partially successful. This could happen if, after accepting several 2949 recipients and the mail data, the SMTP server finds that the mail 2950 data could be successfully delivered to some, but not all, of the 2951 recipients. In such cases, the response to the DATA command MUST be 2952 an OK reply. However, the SMTP server MUST compose and send an 2953 "undeliverable mail" notification message to the originator of the 2954 message. 2956 The time stamp line and the return path line are formally defined as 2957 follows (the definitions for "FWS" and "CFWS" appear in RFC 5322 2958 [13]): 2960 Return-path-line = "Return-Path:" FWS Reverse-path 2962 Time-stamp-line = "Received:" FWS Stamp 2964 Stamp = From-domain By-domain Opt-info [CFWS] ";" 2965 FWS date-time 2966 ; where "date-time" is as defined in RFC 5322 [13] 2967 ; but the "obs-" forms, especially two-digit 2968 ; years, are prohibited in SMTP and MUST NOT be used. 2970 From-domain = "FROM" FWS Extended-Domain 2972 By-domain = CFWS "BY" FWS Extended-Domain 2973 Extended-Domain = Domain / 2974 ( Domain FWS "(" TCP-info ")" ) / 2975 ( address-literal FWS "(" TCP-info ")" ) 2977 TCP-info = address-literal / ( Domain FWS address-literal ) 2978 ; Information derived by server from TCP connection 2979 ; not client EHLO. 2981 Opt-info = [Via] [With] [ID] [For] 2982 [Additional-Registered-Clauses] 2984 Via = CFWS "VIA" FWS Link 2986 With = CFWS "WITH" FWS Protocol 2988 ID = CFWS "ID" FWS ( Atom / msg-id ) 2989 ; msg-id is defined in RFC 5322 [13] 2991 For = CFWS "FOR" FWS ( Path / Mailbox ) 2993 Additional-Registered-Clauses = 1* (CFWS Atom FWS String) ; 2994 Additional standard clauses may be added in this 2995 ; location by future standards and registration with 2996 ; IANA. SMTP servers SHOULD NOT use unregistered 2997 ; names. See Section 8. 2999 Link = "TCP" / Addtl-Link 3001 Addtl-Link = Atom 3002 ; Additional standard names for links are 3003 ; registered with the Internet Assigned Numbers 3004 ; Authority (IANA). "Via" is primarily of value 3005 ; with non-Internet transports. SMTP servers 3006 ; SHOULD NOT use unregistered names. 3008 Protocol = "ESMTP" / "SMTP" / Attdl-Protocol 3010 Addtl-Protocol = Atom 3011 ; Additional standard names for protocols are 3012 ; registered with the Internet Assigned Numbers 3013 ; Authority (IANA) in the "mail parameters" 3014 ; registry [9]. SMTP servers SHOULD NOT 3015 ; use unregistered names. 3017 4.5. Additional Implementation Issues 3019 4.5.1. Minimum Implementation 3021 In order to make SMTP workable, the following minimum implementation 3022 MUST be provided by all receivers. The following commands MUST be 3023 supported to conform to this specification: 3025 EHLO 3026 HELO 3027 MAIL 3028 RCPT 3029 DATA 3030 RSET 3031 NOOP 3032 QUIT 3033 VRFY 3035 Any system that includes an SMTP server supporting mail relaying or 3036 delivery MUST support the reserved mailbox "postmaster" as a case- 3037 insensitive local name. This postmaster address is not strictly 3038 necessary if the server always returns 554 on connection opening (as 3039 described in Section 3.1). The requirement to accept mail for 3040 postmaster implies that RCPT commands that specify a mailbox for 3041 postmaster at any of the domains for which the SMTP server provides 3042 mail service, as well as the special case of "RCPT TO:" 3043 (with no domain specification), MUST be supported. 3045 SMTP systems are expected to make every reasonable effort to accept 3046 mail directed to Postmaster from any other system on the Internet. 3047 In extreme cases -- such as to contain a denial of service attack or 3048 other breach of security -- an SMTP server may block mail directed to 3049 Postmaster. However, such arrangements SHOULD be narrowly tailored 3050 so as to avoid blocking messages that are not part of such attacks. 3052 4.5.2. Transparency 3054 Without some provision for data transparency, the character sequence 3055 "." ends the mail text and cannot be sent by the user. 3056 In general, users are not aware of such "forbidden" sequences. To 3057 allow all user composed text to be transmitted transparently, the 3058 following procedures are used: 3060 * Before sending a line of mail text, the SMTP client checks the 3061 first character of the line. If it is a period, one additional 3062 period is inserted at the beginning of the line. 3064 * When a line of mail text is received by the SMTP server, it checks 3065 the line. If the line is composed of a single period, it is 3066 treated as the end of mail indicator. If the first character is a 3067 period and there are other characters on the line, the first 3068 character is deleted. 3070 The mail data may contain any of the 128 ASCII characters. All 3071 characters are to be delivered to the recipient's mailbox, including 3072 spaces, vertical and horizontal tabs, and other control characters. 3073 If the transmission channel provides an 8-bit byte (octet) data 3074 stream, the 7-bit ASCII codes are transmitted, right justified, in 3075 the octets, with the high-order bits cleared to zero. See 3076 Section 3.6 for special treatment of these conditions in SMTP systems 3077 serving a relay function. 3079 In some systems, it may be necessary to transform the data as it is 3080 received and stored. This may be necessary for hosts that use a 3081 different character set than ASCII as their local character set, that 3082 store data in records rather than strings, or which use special 3083 character sequences as delimiters inside mailboxes. If such 3084 transformations are necessary, they MUST be reversible, especially if 3085 they are applied to mail being relayed. 3087 4.5.3. Sizes and Timeouts 3089 4.5.3.1. Size Limits and Minimums 3091 There are several objects that have required minimum/maximum sizes. 3092 Every implementation MUST be able to receive objects of at least 3093 these sizes. Objects larger than these sizes SHOULD be avoided when 3094 possible. However, some Internet mail constructs such as encoded 3095 X.400 addresses (RFC 2156 [28]) will often require larger objects. 3096 Clients MAY attempt to transmit these, but MUST be prepared for a 3097 server to reject them if they cannot be handled by it. To the 3098 maximum extent possible, implementation techniques that impose no 3099 limits on the length of these objects should be used. 3101 Extensions to SMTP may involve the use of characters that occupy more 3102 than a single octet each. This section therefore specifies lengths 3103 in octets where absolute lengths, rather than character counts, are 3104 intended. 3106 4.5.3.1.1. Local-part 3108 The maximum total length of a user name or other local-part is 64 3109 octets. 3111 4.5.3.1.2. Domain 3113 The maximum total length of a domain name or number is 255 octets. 3115 4.5.3.1.3. Path 3117 The maximum total length of a reverse-path or forward-path is 256 3118 octets (including the punctuation and element separators). 3120 4.5.3.1.4. Command Line 3122 The maximum total length of a command line including the command word 3123 and the is 512 octets. SMTP extensions may be used to 3124 increase this limit. 3126 4.5.3.1.5. Reply Line 3128 The maximum total length of a reply line including the reply code and 3129 the is 512 octets. More information may be conveyed through 3130 multiple-line replies. 3132 4.5.3.1.6. Text Line 3134 The maximum total length of a text line including the is 1000 3135 octets (not counting the leading dot duplicated for transparency). 3136 This number may be increased by the use of SMTP Service Extensions. 3138 4.5.3.1.7. Message Content 3140 The maximum total length of a message content (including any message 3141 header section as well as the message body) MUST BE at least 64K 3142 octets. Since the introduction of Internet Standards for multimedia 3143 mail (RFC 2045 [26]), message lengths on the Internet have grown 3144 dramatically, and message size restrictions should be avoided if at 3145 all possible. SMTP server systems that must impose restrictions 3146 SHOULD implement the "SIZE" service extension of RFC 1870 [7], and 3147 SMTP client systems that will send large messages SHOULD utilize it 3148 when possible. 3150 4.5.3.1.8. Recipient Buffer 3152 The minimum total number of recipients that MUST be buffered is 100 3153 recipients. Rejection of messages (for excessive recipients) with 3154 fewer than 100 RCPT commands is a violation of this specification. 3155 The general principle that relaying SMTP server MUST NOT, and 3156 delivery SMTP servers SHOULD NOT, perform validation tests on message 3157 header fields suggests that messages SHOULD NOT be rejected based on 3158 the total number of recipients shown in header fields. A server that 3159 imposes a limit on the number of recipients MUST behave in an orderly 3160 fashion, such as rejecting additional addresses over its limit rather 3161 than silently discarding addresses previously accepted. A client 3162 that needs to deliver a message containing over 100 RCPT commands 3163 SHOULD be prepared to transmit in 100-recipient "chunks" if the 3164 server declines to accept more than 100 recipients in a single 3165 message. 3167 4.5.3.1.9. Treatment When Limits Exceeded 3169 Errors due to exceeding these limits may be reported by using the 3170 reply codes. Some examples of reply codes are: 3172 500 Line too long. 3174 or 3176 501 Path too long 3178 or 3180 452 Too many recipients (see below) 3182 or 3184 552 Too much mail data (historically also used for too many 3185 recipients (see below). 3187 4.5.3.1.10. Too Many Recipients Code 3189 RFC 821 [4] incorrectly listed the error where an SMTP server 3190 exhausts its implementation limit on the number of RCPT commands 3191 ("too many recipients") as having reply code 552. The correct reply 3192 code for this condition is 452. At the time RFC 5321 was written, 3193 the use of response code 552 by servers was sufficiently common that 3194 client implementation were advised to simply treat it as if 452 had 3195 been sent. That advice is no longer necessary or useful. 3197 When a conforming SMTP server encounters this condition, it has at 3198 least 100 successful RCPT commands in its recipient buffer. If the 3199 server is able to accept the message, then at least these 100 3200 addresses will be removed from the SMTP client's queue. When the 3201 client attempts retransmission of those addresses that received 452 3202 responses, at least 100 of these will be able to fit in the SMTP 3203 server's recipient buffer. Each retransmission attempt that is able 3204 to deliver anything will be able to dispose of at least 100 of these 3205 recipients. 3207 If an SMTP server has an implementation limit on the number of RCPT 3208 commands and this limit is exhausted, it MUST use a response code of 3209 452. If the server has a configured site-policy limitation on the 3210 number of RCPT commands, it MAY instead use a 5yz response code. In 3211 particular, if the intent is to prohibit messages with more than a 3212 site-specified number of recipients, rather than merely limit the 3213 number of recipients in a given mail transaction, it would be 3214 reasonable to return a 503 response to any DATA command received 3215 subsequent to the 452 code or to simply return the 503 after DATA 3216 without returning any previous negative response. 3218 4.5.3.2. Timeouts 3220 An SMTP client MUST provide a timeout mechanism. It MUST use per- 3221 command timeouts rather than somehow trying to time the entire mail 3222 transaction. Timeouts SHOULD be easily reconfigurable, preferably 3223 without recompiling the SMTP code. To implement this, a timer is set 3224 for each SMTP command and for each buffer of the data transfer. The 3225 latter means that the overall timeout is inherently proportional to 3226 the size of the message. 3228 Based on extensive experience with busy mail-relay hosts, the minimum 3229 per-command timeout values SHOULD be as follows: 3231 4.5.3.2.1. Initial 220 Message: 5 Minutes 3233 An SMTP client process needs to distinguish between a failed TCP 3234 connection and a delay in receiving the initial 220 greeting message. 3235 Many SMTP servers accept a TCP connection but delay delivery of the 3236 220 message until their system load permits more mail to be 3237 processed. 3239 4.5.3.2.2. MAIL Command: 5 Minutes 3241 4.5.3.2.3. RCPT Command: 5 Minutes 3243 A longer timeout is required if processing of mailing lists and 3244 aliases is not deferred until after the message was accepted. 3246 4.5.3.2.4. DATA Initiation: 2 Minutes 3248 This is while awaiting the "354 Start Input" reply to a DATA command. 3250 4.5.3.2.5. Data Block: 3 Minutes 3252 This is while awaiting the completion of each TCP SEND call 3253 transmitting a chunk of data. 3255 4.5.3.2.6. DATA Termination: 10 Minutes. 3257 This is while awaiting the "250 OK" reply. When the receiver gets 3258 the final period terminating the message data, it typically performs 3259 processing to deliver the message to a user mailbox. A spurious 3260 timeout at this point would be very wasteful and would typically 3261 result in delivery of multiple copies of the message, since it has 3262 been successfully sent and the server has accepted responsibility for 3263 delivery. See Section 6.1 for additional discussion. 3265 4.5.3.2.7. Server Timeout: 5 Minutes. 3267 An SMTP server SHOULD have a timeout of at least 5 minutes while it 3268 is awaiting the next command from the sender. 3270 4.5.4. Retry Strategies 3272 The common structure of a host SMTP implementation includes user 3273 mailboxes, one or more areas for queuing messages in transit, and one 3274 or more daemon processes for sending and receiving mail. The exact 3275 structure will vary depending on the needs of the users on the host 3276 and the number and size of mailing lists supported by the host. We 3277 describe several optimizations that have proved helpful, particularly 3278 for mailers supporting high traffic levels. 3280 Any queuing strategy MUST include timeouts on all activities on a 3281 per-command basis. A queuing strategy MUST NOT send error messages 3282 in response to error messages under any circumstances. 3284 4.5.4.1. Sending Strategy 3286 The general model for an SMTP client is one or more processes that 3287 periodically attempt to transmit outgoing mail. In a typical system, 3288 the program that composes a message has some method for requesting 3289 immediate attention for a new piece of outgoing mail, while mail that 3290 cannot be transmitted immediately MUST be queued and periodically 3291 retried by the sender. A mail queue entry will include not only the 3292 message itself but also the envelope information. 3294 The sender MUST delay retrying a particular destination after one 3295 attempt has failed. In general, the retry interval SHOULD be at 3296 least 30 minutes; however, more sophisticated and variable strategies 3297 will be beneficial when the SMTP client can determine the reason for 3298 non-delivery. 3300 Retries continue until the message is transmitted or the sender gives 3301 up; the give-up time generally needs to be at least 4-5 days. It MAY 3302 be appropriate to set a shorter maximum number of retries for non- 3303 delivery notifications and equivalent error messages than for 3304 standard messages. The parameters to the retry algorithm MUST be 3305 configurable. 3307 A client SHOULD keep a list of hosts it cannot reach and 3308 corresponding connection timeouts, rather than just retrying queued 3309 mail items. 3311 Experience suggests that failures are typically transient (the target 3312 system or its connection has crashed), favoring a policy of two 3313 connection attempts in the first hour the message is in the queue, 3314 and then backing off to one every two or three hours. 3316 The SMTP client can shorten the queuing delay in cooperation with the 3317 SMTP server. For example, if mail is received from a particular 3318 address, it is likely that mail queued for that host can now be sent. 3319 Application of this principle may, in many cases, eliminate the 3320 requirement for an explicit "send queues now" function such as ETRN, 3321 RFC 1985 [25]. 3323 The strategy may be further modified as a result of multiple 3324 addresses per host (see below) to optimize delivery time versus 3325 resource usage. 3327 An SMTP client may have a large queue of messages for each 3328 unavailable destination host. If all of these messages were retried 3329 in every retry cycle, there would be excessive Internet overhead and 3330 the sending system would be blocked for a long period. Note that an 3331 SMTP client can generally determine that a delivery attempt has 3332 failed only after a timeout of several minutes, and even a one-minute 3333 timeout per connection will result in a very large delay if retries 3334 are repeated for dozens, or even hundreds, of queued messages to the 3335 same host. 3337 At the same time, SMTP clients SHOULD use great care in caching 3338 negative responses from servers. In an extreme case, if EHLO is 3339 issued multiple times during the same SMTP connection, different 3340 answers may be returned by the server. More significantly, 5yz 3341 responses to the MAIL command MUST NOT be cached. 3343 When a mail message is to be delivered to multiple recipients, and 3344 the SMTP server to which a copy of the message is to be sent is the 3345 same for multiple recipients, then only one copy of the message 3346 SHOULD be transmitted. That is, the SMTP client SHOULD use the 3347 command sequence: MAIL, RCPT, RCPT, ..., RCPT, DATA instead of the 3348 sequence: MAIL, RCPT, DATA, ..., MAIL, RCPT, DATA. However, if there 3349 are very many addresses, a limit on the number of RCPT commands per 3350 MAIL command MAY be imposed. This efficiency feature SHOULD be 3351 implemented. 3353 Similarly, to achieve timely delivery, the SMTP client MAY support 3354 multiple concurrent outgoing mail transactions. However, some limit 3355 may be appropriate to protect the host from devoting all its 3356 resources to mail. 3358 4.5.4.2. Receiving Strategy 3360 The SMTP server SHOULD attempt to keep a pending listen on the SMTP 3361 port (specified by IANA as port 25) at all times. This requires the 3362 support of multiple incoming TCP connections for SMTP. Some limit 3363 MAY be imposed, but servers that cannot handle more than one SMTP 3364 transaction at a time are not in conformance with the intent of this 3365 specification. 3367 As discussed above, when the SMTP server receives mail from a 3368 particular host address, it could activate its own SMTP queuing 3369 mechanisms to retry any mail pending for that host address. 3371 4.5.5. Messages with a Null Reverse-Path 3373 There are several types of notification messages that are required by 3374 existing and proposed Standards to be sent with a null reverse-path, 3375 namely non-delivery notifications as discussed in Section 3.6.1 and 3376 Section 3.6.2, other kinds of Delivery Status Notifications (DSNs, 3377 RFC 3461 [35]), and Message Disposition Notifications (MDNs, RFC 8098 3378 [40]). All of these kinds of messages are notifications about a 3379 previous message, and they are sent to the reverse-path of the 3380 previous mail message. (If the delivery of such a notification 3381 message fails, that usually indicates a problem with the mail system 3382 of the host to which the notification message is addressed. For this 3383 reason, at some hosts the MTA is set up to forward such failed 3384 notification messages to someone who is able to fix problems with the 3385 mail system, e.g., via the postmaster alias.) 3387 All other types of messages (i.e., any message which is not required 3388 by a Standards-Track RFC to have a null reverse-path) SHOULD be sent 3389 with a valid, non-null reverse-path. 3391 Implementers of automated email processors should be careful to make 3392 sure that the various kinds of messages with a null reverse-path are 3393 handled correctly. In particular, such systems SHOULD NOT reply to 3394 messages with a null reverse-path, and they SHOULD NOT add a non-null 3395 reverse-path, or change a null reverse-path to a non-null one, to 3396 such messages when forwarding. 3398 5. Address Resolution and Mail Handling 3400 5.1. Locating the Target Host 3402 Once an SMTP client lexically identifies a domain to which mail will 3403 be delivered for processing (as described in Sections 2.3.5 and 3.6), 3404 a DNS lookup MUST be performed to resolve the domain name (RFC 1035 3405 [5]. The names are required to be fully-qualified domain names 3406 (FQDNs) as discussed in Section 2.3.5. 3408 The lookup first attempts to locate an MX record associated with the 3409 name. If a CNAME record is found, the resulting name is processed as 3410 if it were the initial name. If a non-existent domain error is 3411 returned, this situation MUST be reported as an error. If a 3412 temporary error is returned, the message MUST be queued and retried 3413 later (see Section 4.5.4.1). If an empty list of MXs is returned, 3414 the address is treated as if it was associated with an implicit MX RR 3415 with a preference of 0, pointing to that host. If MX records are 3416 present, but none of them are usable, or the implicit MX is unusable, 3417 this situation MUST be reported as an error. 3419 When the lookup succeeds, the mapping can result in a list of 3420 alternative delivery addresses rather than a single address. This 3421 can be due to multiple MX records, multihoming, or both. To provide 3422 reliable mail transmission, the SMTP client MUST be able to try (and 3423 be prepared to retry) each of the relevant addresses in this list in 3424 order (see below), until a delivery attempt succeeds. However, as 3425 discussed more generally in Section 7.8 there MAY also be a 3426 configurable limit on the number of alternate addresses that can be 3427 tried. In any case, the SMTP client SHOULD try at least two 3428 addresses. 3430 If one or more MX RRs are found for a given name, SMTP systems MUST 3431 NOT utilize any address RRs associated with that name unless they are 3432 located using the MX RRs; the "implicit MX" rule above applies only 3433 if there are no MX records present. If MX records are present, but 3434 none of them are usable, this situation MUST be reported as an error. 3435 That domain name also MUST be a primary host name, i.e., it is not 3436 allowed to be an alias. 3438 When a domain name associated with an MX RR is looked up and the 3439 associated data field obtained, the data field of that response MUST 3440 contain a domain name that conforms to the specifications of 3441 Section 2.3.5. That domain name, when queried, MUST return at least 3442 one address record (e.g., A or AAAA RR) that gives the IP address of 3443 the SMTP server to which the message should be directed. Any other 3444 response, specifically including a value that will return a CNAME 3445 record when queried, lies outside the scope of this Standard. The 3446 prohibition on labels in the data that resolve to CNAMEs is discussed 3447 in more detail in RFC 2181, Section 10.3 [29]. 3449 Two types of information are used to rank the host addresses: 3450 multiple MX records, and multihomed hosts. 3452 MX records contain a numerical preference indication that MUST be 3453 used in sorting if more than one such record appears. Lower numbers 3454 are more preferred than higher ones. The sender-SMTP MUST inspect 3455 the list for any of the names or addresses by which it might be known 3456 in mail transactions. If a matching record is found, all records at 3457 that preference level and higher-numbered ones MUST be discarded from 3458 consideration. If there are no records left at that point, it is an 3459 error condition, and a 5yz reply code generated (terminating the mail 3460 transaction) or the message MUST be returned as undeliverable. If 3461 there is a single MX record at the most-preferred preference label, 3462 the data field associated with that record is used as the next 3463 destination. Otherwise, if there are multiple records with the same 3464 preference and there is no clear reason to favor one (e.g., by 3465 recognition of an easily reached address), then the sender-SMTP MUST 3466 randomize them to spread the load across multiple mail exchangers for 3467 a specific organization. 3469 The destination host (from either the data field of the preferred MX 3470 record or from an address record found in an implicit MX) may be 3471 multihomed. In those cases the domain name resolver will return a 3472 list of alternative IP addresses. It is the responsibility of the 3473 domain name resolver interface to have ordered this list by 3474 decreasing preference if necessary, and the SMTP sender MUST try them 3475 in the order presented. 3477 Although the capability to try multiple alternative addresses is 3478 required, specific installations may want to limit or disable the use 3479 of alternative addresses. The question of whether a sender should 3480 attempt retries using the different addresses of a multihomed host 3481 has been controversial. The main argument for using the multiple 3482 addresses is that it maximizes the likelihood of timely delivery, and 3483 indeed sometimes the likelihood of any delivery; the counter-argument 3484 is that it may result in unnecessary resource use. Note that 3485 resource use is also strongly determined by the sending strategy 3486 discussed in Section 4.5.4.1. 3488 If an SMTP server receives a message with a destination for which it 3489 is a designated Mail eXchanger, it MAY relay the message (potentially 3490 after having rewritten the MAIL FROM and/or RCPT TO addresses), make 3491 final delivery of the message, or hand it off using some mechanism 3492 outside the SMTP-provided transport environment. Of course, neither 3493 of the latter require that the list of MX records be examined 3494 further. 3496 If it determines that it should relay the message without rewriting 3497 the address, it MUST process the MX records as described above to 3498 determine candidates for delivery. 3500 5.2. IPv6 and MX Records 3502 In the contemporary Internet, SMTP clients and servers may be hosted 3503 on IPv4 systems, IPv6 systems, or dual-stack systems that are 3504 compatible with either version of the Internet Protocol. The host 3505 domains to which MX records point may, consequently, contain "A RR"s 3506 (IPv4), "AAAA RR"s (IPv6), or any combination of them. While RFC 3507 3974 [42] discusses some operational experience in mixed 3508 environments, it was not comprehensive enough to justify 3509 standardization, and some of its recommendations appear to be 3510 inconsistent with this specification. The appropriate actions to be 3511 taken either will depend on local circumstances, such as performance 3512 of the relevant networks and any conversions that might be necessary, 3513 or will be obvious (e.g., an IPv6-only client need not attempt to 3514 look up A RRs or attempt to reach IPv4-only servers). Designers of 3515 SMTP implementations that might run in IPv6 or dual-stack 3516 environments should study the procedures above, especially the 3517 comments about multihomed hosts, and, preferably, provide mechanisms 3518 to facilitate operational tuning and mail interoperability between 3519 IPv4 and IPv6 systems while considering local circumstances. 3521 6. Problem Detection and Handling 3522 6.1. Reliable Delivery and Replies by Email 3524 When the receiver-SMTP accepts a piece of mail (by sending a "250 OK" 3525 message in response to DATA), it is accepting responsibility for 3526 delivering or relaying the message. It must take this responsibility 3527 seriously. It MUST NOT lose the message for frivolous reasons, such 3528 as because the host later crashes or because of a predictable 3529 resource shortage. Some reasons that are not considered frivolous 3530 are discussed in the next subsection and in Section 7.8. 3532 If there is a delivery failure after acceptance of a message, the 3533 receiver-SMTP MUST formulate and mail a notification message. This 3534 notification MUST be sent using a null ("<>") reverse-path in the 3535 envelope. The recipient of this notification MUST be the address 3536 from the envelope return path (or the Return-Path: line). However, 3537 if this address is null ("<>"), the receiver-SMTP MUST NOT send a 3538 notification. Obviously, nothing in this section can or should 3539 prohibit local decisions (i.e., as part of the same system 3540 environment as the receiver-SMTP) to log or otherwise transmit 3541 information about null address events locally if that is desired. 3543 Some delivery failures after the message is accepted by SMTP will be 3544 unavoidable. For example, it may be impossible for the receiving 3545 SMTP server to validate all the delivery addresses in RCPT command(s) 3546 due to a "soft" domain system error, because the target is a mailing 3547 list (see earlier discussion of RCPT), or because the server is 3548 acting as a relay and has no immediate access to the delivering 3549 system. 3551 To avoid receiving duplicate messages as the result of timeouts, a 3552 receiver-SMTP MUST seek to minimize the time required to respond to 3553 the final . end of data indicator. See RFC 1047 [18] for 3554 a discussion of this problem. 3556 6.2. Unwanted, Unsolicited, and "Attack" Messages 3558 Utility and predictability of the Internet mail system requires that 3559 messages that can be delivered should be delivered, regardless of any 3560 syntax or other faults associated with those messages and regardless 3561 of their content. If they cannot be delivered, and cannot be 3562 rejected by the SMTP server during the SMTP transaction, they should 3563 be "bounced" (returned with non-delivery notification messages) as 3564 described above. In today's world, in which many SMTP server 3565 operators have discovered that the quantity of undesirable bulk email 3566 vastly exceeds the quantity of desired mail and in which accepting a 3567 message may trigger additional undesirable traffic by providing 3568 verification of the address, those principles may not be practical. 3570 As discussed in Section 7.8 and Section 7.9 below, dropping mail 3571 without notification of the sender is permitted in practice. 3572 However, it is extremely dangerous and violates a long tradition and 3573 community expectations that mail is either delivered or returned. If 3574 silent message-dropping is misused, it could easily undermine 3575 confidence in the reliability of the Internet's mail systems. So 3576 silent dropping of messages should be considered only in those cases 3577 where there is very high confidence that the messages are seriously 3578 fraudulent or otherwise inappropriate. 3580 To stretch the principle of delivery if possible even further, it may 3581 be a rational policy to not deliver mail that has an invalid return 3582 address, although the history of the network is that users are 3583 typically better served by delivering any message that can be 3584 delivered. Reliably determining that a return address is invalid can 3585 be a difficult and time-consuming process, especially if the putative 3586 sending system is not directly accessible or does not fully and 3587 accurately support VRFY and, even if a "drop messages with invalid 3588 return addresses" policy is adopted, it SHOULD be applied only when 3589 there is near-certainty that the return addresses are, in fact, 3590 invalid. 3592 Conversely, if a message is rejected because it is found to contain 3593 hostile content (a decision that is outside the scope of an SMTP 3594 server as defined in this document), rejection ("bounce") messages 3595 SHOULD NOT be sent unless the receiving site is confident that those 3596 messages will be usefully delivered. The preference and default in 3597 these cases is to avoid sending non-delivery messages when the 3598 incoming message is determined to contain hostile content. 3600 6.3. Loop Detection 3602 Simple counting of the number of "Received:" header fields in a 3603 message has proven to be an effective, although rarely optimal, 3604 method of detecting loops in mail systems. SMTP servers using this 3605 technique SHOULD use a large rejection threshold, normally at least 3606 100 Received entries. Whatever mechanisms are used, servers MUST 3607 contain provisions for detecting and stopping trivial loops. 3609 6.4. Compensating for Irregularities 3611 Unfortunately, variations, creative interpretations, and outright 3612 violations of Internet mail protocols do occur; some would suggest 3613 that they occur quite frequently. The debate as to whether a well- 3614 behaved SMTP receiver or relay should reject a malformed message, 3615 attempt to pass it on unchanged, or attempt to repair it to increase 3616 the odds of successful delivery (or subsequent reply) began almost 3617 with the dawn of structured network mail and shows no signs of 3618 abating. Advocates of rejection claim that attempted repairs are 3619 rarely completely adequate and that rejection of bad messages is the 3620 only way to get the offending software repaired. Advocates of 3621 "repair" or "deliver no matter what" argue that users prefer that 3622 mail go through it if at all possible and that there are significant 3623 market pressures in that direction. In practice, these market 3624 pressures may be more important to particular vendors than strict 3625 conformance to the standards, regardless of the preference of the 3626 actual developers. 3628 The problems associated with ill-formed messages were exacerbated by 3629 the introduction of the split-UA mail reading protocols (Post Office 3630 Protocol (POP) version 2 [15], Post Office Protocol (POP) version 3 3631 [24], IMAP version 2 [20], and PCMAIL [19]). These protocols 3632 encouraged the use of SMTP as a posting (message submission) 3633 protocol, and SMTP servers as relay systems for these client hosts 3634 (which are often only intermittently connected to the Internet). 3635 Historically, many of those client machines lacked some of the 3636 mechanisms and information assumed by SMTP (and indeed, by the mail 3637 format protocol, RFC 822 [14]). Some could not keep adequate track 3638 of time; others had no concept of time zones; still others could not 3639 identify their own names or addresses; and, of course, none could 3640 satisfy the assumptions that underlay RFC 822's conception of 3641 authenticated addresses. 3643 In response to these weak SMTP clients, many SMTP systems now 3644 complete messages that are delivered to them in incomplete or 3645 incorrect form. This strategy is generally considered appropriate 3646 when the server can identify or authenticate the client, and there 3647 are prior agreements between them. By contrast, there is at best 3648 great concern about fixes applied by a relay or delivery SMTP server 3649 that has little or no knowledge of the user or client machine. Many 3650 of these issues are addressed by using a separate protocol, such as 3651 that defined in RFC 6409 [44], for message submission, rather than 3652 using originating SMTP servers for that purpose. 3654 The following changes to a message being processed MAY be applied 3655 when necessary by an originating SMTP server, or one used as the 3656 target of SMTP as an initial posting (message submission) protocol: 3658 * Addition of a message-id field when none appears 3660 * Addition of a date, time, or time zone when none appears 3662 * Correction of addresses to proper FQDN format 3663 The less information the server has about the client, the less likely 3664 these changes are to be correct and the more caution and conservatism 3665 should be applied when considering whether or not to perform fixes 3666 and how. These changes MUST NOT be applied by an SMTP server that 3667 provides an intermediate relay function. 3669 In all cases, properly operating clients supplying correct 3670 information are preferred to corrections by the SMTP server. In all 3671 cases, documentation SHOULD be provided in trace header fields and/or 3672 header field comments for actions performed by the servers. 3674 7. Security Considerations 3676 7.1. Mail Security and Spoofing 3678 SMTP mail is inherently insecure in that it is feasible for even 3679 fairly casual users to negotiate directly with receiving and relaying 3680 SMTP servers and create messages that will trick a naive recipient 3681 into believing that they came from somewhere else. Constructing such 3682 a message so that the "spoofed" behavior cannot be detected by an 3683 expert is somewhat more difficult, but not sufficiently so as to be a 3684 deterrent to someone who is determined and knowledgeable. 3685 Consequently, as knowledge of Internet mail increases, so does the 3686 knowledge that SMTP mail inherently cannot be authenticated, or 3687 integrity checks provided, at the transport level. Real mail 3688 security lies only in end-to-end methods involving the message 3689 bodies, such as those that use digital signatures (see RFC 1847 [22] 3690 and, e.g., Pretty Good Privacy (PGP) in RFC 4880 [45] or Secure/ 3691 Multipurpose Internet Mail Extensions (S/MIME) in RFC 8551 [41]). 3693 Various protocol extensions and configuration options that provide 3694 authentication at the transport level (e.g., from an SMTP client to 3695 an SMTP server) improve somewhat on the traditional situation 3696 described above. However, in general, they only authenticate one 3697 server to another rather than a chain of relays and servers, much 3698 less authenticating users or user machines. Consequently, unless 3699 they are accompanied by careful handoffs of responsibility in a 3700 carefully designed trust environment, they remain inherently weaker 3701 than end-to-end mechanisms that use digitally signed messages rather 3702 than depending on the integrity of the transport system. 3704 Efforts to make it more difficult for users to set envelope return 3705 path and header "From" fields to point to valid addresses other than 3706 their own are largely misguided: they frustrate legitimate 3707 applications in which mail is sent by one user on behalf of another, 3708 in which error (or normal) replies should be directed to a special 3709 address, or in which a single message is sent to multiple recipients 3710 on different hosts. (Systems that provide convenient ways for users 3711 to alter these header fields on a per-message basis should attempt to 3712 establish a primary and permanent mailbox address for the user so 3713 that Sender header fields within the message data can be generated 3714 sensibly.) 3716 This specification does not further address the authentication issues 3717 associated with SMTP other than to advocate that useful functionality 3718 not be disabled in the hope of providing some small margin of 3719 protection against a user who is trying to fake mail. 3721 7.2. "Blind" Copies 3723 Addresses that do not appear in the message header section may appear 3724 in the RCPT commands to an SMTP server for a number of reasons. The 3725 two most common involve the use of a mailing address as a "list 3726 exploder" (a single address that resolves into multiple addresses) 3727 and the appearance of "blind copies". Especially when more than one 3728 RCPT command is present, and in order to avoid defeating some of the 3729 purpose of these mechanisms, SMTP clients and servers SHOULD NOT copy 3730 the full set of RCPT command arguments into the header section, 3731 either as part of trace header fields or as informational or private- 3732 extension header fields. 3733 // [rfc5321bis] [[Note in draft - Suggestion from 20070124 that got 3734 // lost: delete "especially" and "the full set of" -- copying the 3735 // first one can be as harmful as copying all of them, at least 3736 // without verifying that the addresses do appear in the headers. 3737 // See G.7.9 and ticket #15. 3738 Because this rule is often violated in practice, and cannot be 3739 enforced, sending SMTP systems that are aware of "bcc" use MAY find 3740 it helpful to send each blind copy as a separate message transaction 3741 containing only a single RCPT command. 3743 There is no inherent relationship between either "reverse" (from the 3744 MAIL command) or "forward" (RCPT) addresses in the SMTP transaction 3745 ("envelope") and the addresses in the header section. Receiving 3746 systems SHOULD NOT attempt to deduce such relationships and use them 3747 to alter the header section of the message for delivery. The popular 3748 "Apparently-to" header field is a violation of this principle as well 3749 as a common source of unintended information disclosure and SHOULD 3750 NOT be used. 3752 7.3. VRFY, EXPN, and Security 3754 As discussed in Section 3.5, individual sites may want to disable 3755 either or both of VRFY or EXPN for security reasons (see below). As 3756 a corollary to the above, implementations that permit this MUST NOT 3757 appear to have verified addresses that are not, in fact, verified. 3758 If a site disables these commands for security reasons, the SMTP 3759 server MUST return a 252 response, rather than a code that could be 3760 confused with successful or unsuccessful verification. 3762 Returning a 250 reply code with the address listed in the VRFY 3763 command after having checked it only for syntax violates this rule. 3764 Of course, an implementation that "supports" VRFY by always returning 3765 550 whether or not the address is valid is equally not in 3766 conformance. 3768 On the public Internet, the contents of mailing lists have become 3769 popular as an address information source for so-called "spammers." 3770 The use of EXPN to "harvest" addresses has increased as list 3771 administrators have installed protections against inappropriate uses 3772 of the lists themselves. However, VRFY and EXPN are still useful for 3773 authenticated users and within an administrative domain. For 3774 example, VRFY and EXPN are useful for performing internal audits of 3775 how email gets routed to check and to make sure no one is 3776 automatically forwarding sensitive mail outside the organization. 3777 Sites implementing SMTP authentication may choose to make VRFY and 3778 EXPN available only to authenticated requestors. Implementations 3779 SHOULD still provide support for EXPN, but sites SHOULD carefully 3780 evaluate the tradeoffs. 3782 Whether disabling VRFY provides any real marginal security depends on 3783 a series of other conditions. In many cases, RCPT commands can be 3784 used to obtain the same information about address validity. On the 3785 other hand, especially in situations where determination of address 3786 validity for RCPT commands is deferred until after the DATA command 3787 is received, RCPT may return no information at all, while VRFY is 3788 expected to make a serious attempt to determine validity before 3789 generating a response code (see discussion above). 3791 7.4. Mail Rerouting Based on the 251 and 551 Response Codes 3793 Before a client uses the 251 or 551 reply codes from a RCPT command 3794 to automatically update its future behavior (e.g., updating the 3795 user's address book), it should be certain of the server's 3796 authenticity. If it does not, it may be subject to a man in the 3797 middle attack. 3799 7.5. Information Disclosure in Announcements 3801 There has been an ongoing debate about the tradeoffs between the 3802 debugging advantages of announcing server type and version (and, 3803 sometimes, even server domain name) in the greeting response or in 3804 response to the HELP command and the disadvantages of exposing 3805 information that might be useful in a potential hostile attack. The 3806 utility of the debugging information is beyond doubt. Those who 3807 argue for making it available point out that it is far better to 3808 actually secure an SMTP server rather than hope that trying to 3809 conceal known vulnerabilities by hiding the server's precise identity 3810 will provide more protection. Sites are encouraged to evaluate the 3811 tradeoff with that issue in mind; implementations SHOULD minimally 3812 provide for making type and version information available in some way 3813 to other network hosts. 3815 7.6. Information Disclosure in Trace Fields 3817 In some circumstances, such as when mail originates from within a LAN 3818 whose hosts are not directly on the public Internet, trace (e.g., 3819 "Received") header fields produced in conformance with this 3820 specification may disclose host names and similar information that 3821 would not normally be available. This ordinarily does not pose a 3822 problem, but sites with special concerns about name disclosure should 3823 be aware of it. Also, the optional FOR clause should be supplied 3824 with caution or not at all when multiple recipients are involved lest 3825 it inadvertently disclose the identities of "blind copy" recipients 3826 to others. 3828 7.7. Information Disclosure in Message Forwarding 3830 As discussed in Section 3.4.1, use of the 251 or 551 reply codes to 3831 identify the replacement address associated with a mailbox may 3832 inadvertently disclose sensitive information. Sites that are 3833 concerned about those issues should ensure that they select and 3834 configure servers appropriately. 3836 7.8. Local Operational Requirements and Resistance to Attacks 3838 In recent years, there has been an increase of attacks on SMTP 3839 servers, either in conjunction with attempts to discover addresses 3840 for sending unsolicited messages or simply to make the servers 3841 inaccessible to others (i.e., as an application-level denial of 3842 service attack). There may also be important local circumstances 3843 that justify departures from some of the limits specified in this 3844 documents especially ones involving maximums or minimums. While the 3845 means of doing so are beyond the scope of this Standard, rational 3846 operational behavior requires that servers be permitted to detect 3847 such attacks and take action to defend themselves. For example, if a 3848 server determines that a large number of RCPT commands are being 3849 sent, most or all with invalid addresses, as part of such an attack, 3850 it would be reasonable for the server to close the connection after 3851 generating an appropriate number of 5yz (normally 550) replies. 3853 7.9. Scope of Operation of SMTP Servers 3855 It is a well-established principle that an SMTP server may refuse to 3856 accept mail for any operational or technical reason that makes sense 3857 to the site providing the server. However, cooperation among sites 3858 and installations makes the Internet possible. If sites take 3859 excessive advantage of the right to reject traffic, the ubiquity of 3860 email availability (one of the strengths of the Internet) will be 3861 threatened; considerable care should be taken and balance maintained 3862 if a site decides to be selective about the traffic it will accept 3863 and process. 3865 In recent years, use of the relay function through arbitrary sites 3866 has been used as part of hostile efforts to hide the actual origins 3867 of mail. Some sites have decided to limit the use of the relay 3868 function to known or identifiable sources, and implementations SHOULD 3869 provide the capability to perform this type of filtering. When mail 3870 is rejected for these or other policy reasons, a 550 code SHOULD be 3871 used in response to EHLO (or HELO), MAIL, or RCPT as appropriate. 3873 8. IANA Considerations 3875 8.1. SMTP-related Registries 3877 IANA maintains three registries in support of this specification, the 3878 first two of which were created for RFC 2821 or earlier. The third 3879 was expanded by RFC 5321. The registry references listed are as of 3880 the time of publication; IANA does not guarantee the locations 3881 associated with the URLs. The registries are as follows: 3883 * The first, "Simple Mail Transfer Protocol (SMTP) Service 3884 Extensions" [52], consists of SMTP service extensions with the 3885 associated keywords, and, as needed, parameters and verbs. 3886 Entries may be made only for service extensions (and associated 3887 keywords, parameters, or verbs) that are defined in Standards- 3888 Track or Experimental RFCs specifically approved by the IESG for 3889 this purpose. 3891 * The second registry, "Address Literal Tags" [54], consists of 3892 "tags" that identify forms of domain literals other than those for 3893 IPv4 addresses (specified in RFC 821 and in this document). The 3894 initial entry in that registry is for IPv6 addresses (specified in 3895 this document). Additional literal types require standardization 3896 before being used; none are anticipated at this time. 3898 * The third, "Mail Transmission Types" [53], established by RFC 821 3899 and renewed by this specification, is a registry of link and 3900 protocol identifiers to be used with the "via" and "with" 3901 subclauses of the time stamp ("Received:" header field) described 3902 in Section 4.4. Link and protocol identifiers in addition to 3903 those specified in this document may be registered only by 3904 standardization or by way of an RFC-documented, IESG-approved, 3905 Experimental protocol extension. This name space is for 3906 identification and not limited in size: the IESG is encouraged to 3907 approve on the basis of clear documentation and a distinct method 3908 rather than preferences about the properties of the method itself. 3909 An additional subsection has been added to the "VIA link types" 3910 and "WITH protocol types" subsections of this registry to contain 3911 registrations of "Additional-registered-clauses" as described 3912 above. The registry will contain clause names, a description, a 3913 summary of the syntax of the associated String, and a reference. 3914 As new clauses are defined, they may, in principle, specify 3915 creation of their own registries if the Strings consist of 3916 reserved terms or keywords rather than less restricted strings. 3917 As with link and protocol identifiers, additional clauses may be 3918 registered only by standardization or by way of an RFC-documented, 3919 IESG-approved, Experimental protocol extension. The additional 3920 clause name space is for identification and is not limited in 3921 size: the IESG is encouraged to approve on the basis of clear 3922 documentation, actual use or strong signs that the clause will be 3923 used, and a distinct requirement rather than preferences about the 3924 properties of the clause itself. 3926 In addition, if additional trace header fields (i.e., in addition to 3927 Return-path and Received) are ever created, those trace fields MUST 3928 be added to the IANA registry established by BCP 90 (RFC 3864) [10] 3929 for use with RFC 5322 [13]. 3931 8.2. New Registry Actions with 3933 [IANA is requested to] To improve clarity VRFY is added to the 3934 Service Extensions Registry [52] immediately before the entry to 3935 EXPN. The Note should read: "Implementation support for VRFY is 3936 required in servers but the listing in the EHLO response is 3937 optional". See Section 3.5.2 for details on this subject. 3939 9. Acknowledgments 3941 Many people contributed to the development of RFCs 2821 and 5321. 3942 Those documents should be consulted for those acknowledgments. 3944 Neither this document nor RFCs 2821 or 5321 would have been possible 3945 without the many contribution and insights of the late Jon Postel. 3946 Those contributions of course include the original specification of 3947 SMTP in RFC 821. A considerable quantity of text from RFC 821 still 3948 appears in this document as do several of Jon's original examples 3949 that have been updated only as needed to reflect other changes in the 3950 specification. 3952 The following filed errata against RFC 5321 that were not rejected at 3953 the time of submission: Jasen Betts, Adrien de Croy Guillaume Fortin- 3954 Debigare Roberto Javier Godoy, David Romerstein, Dominic Sayers, 3955 Rodrigo Speller, Alessandro Vesely, and Brett Watson. Some of those 3956 individuals made additional suggestions after the EMAILCORE WG was 3957 initiated. In addition to the above, several of whom continued to 3958 make other suggestions, specific suggestions that led to corrections 3959 and improvements in early versions of the current specification were 3960 received from Dave Crocker, Ned Freed, Arnt Gulbrandsen, Tony Hansen, 3961 Barry Leiba, Ivar Lumi, Pete Resnick, Hector Santos, Paul Smith and 3962 others. 3964 chetti contributed an analysis that clarified the ABNF productions 3965 that implicitly reference other documents. 3967 The EMAILCORE Working Group was chartered in September 2020 with 3968 Alexey Melnikov and Seth Blank as co-chairs. Todd Herr replaced Seth 3969 Blank early in 2021. Without their leadership and technical 3970 contributions, this document would never have been completed. 3972 10. References 3974 10.1. Normative References 3976 [1] Bradner, S., "Key words for use in RFCs to Indicate 3977 Requirement Levels", BCP 14, RFC 2119, 3978 DOI 10.17487/RFC2119, March 1997, 3979 . 3981 [2] ANSI, "USA Code for Information Interchange", 3982 ANSI X3.4-1968, 1968. ANSI X3.4-1968 has been replaced by 3983 newer versions with slight modifications, but the 1968 3984 version remains definitive for the Internet. The 1968 3985 version is also described for Internet purposes in RFC 20 3986 [3]. 3988 [3] Cerf, V., "ASCII format for network interchange", STD 80, 3989 RFC 20, DOI 10.17487/RFC0020, October 1969, 3990 . 3992 [4] Postel, J., "Simple Mail Transfer Protocol", STD 10, 3993 RFC 821, DOI 10.17487/RFC0821, August 1982, 3994 . 3996 [5] Mockapetris, P., "Domain names - implementation and 3997 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 3998 November 1987, . 4000 [6] Braden, R., Ed., "Requirements for Internet Hosts - 4001 Application and Support", STD 3, RFC 1123, 4002 DOI 10.17487/RFC1123, October 1989, 4003 . 4005 [7] Klensin, J., Freed, N., and K. Moore, "SMTP Service 4006 Extension for Message Size Declaration", STD 10, RFC 1870, 4007 DOI 10.17487/RFC1870, November 1995, 4008 . 4010 [8] Vaudreuil, G., "Enhanced Mail System Status Codes", 4011 RFC 3463, DOI 10.17487/RFC3463, January 2003, 4012 . 4014 [9] Newman, C., "ESMTP and LMTP Transmission Types 4015 Registration", RFC 3848, DOI 10.17487/RFC3848, July 2004, 4016 . 4018 [10] Klyne, G., Nottingham, M., and J. Mogul, "Registration 4019 Procedures for Message Header Fields", BCP 90, RFC 3864, 4020 DOI 10.17487/RFC3864, September 2004, 4021 . 4023 [11] Hinden, R. and S. Deering, "IP Version 6 Addressing 4024 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 4025 2006, . 4027 [12] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 4028 Specifications: ABNF", STD 68, RFC 5234, 4029 DOI 10.17487/RFC5234, January 2008, 4030 . 4032 [13] Resnick, P., Ed., "Internet Message Format", RFC 5322, 4033 DOI 10.17487/RFC5322, October 2008, 4034 . 4036 10.2. Informative References 4038 [14] Crocker, D., "STANDARD FOR THE FORMAT OF ARPA INTERNET 4039 TEXT MESSAGES", STD 11, RFC 822, DOI 10.17487/RFC0822, 4040 August 1982, . 4042 [15] Butler, M., Postel, J., Chase, D., Goldberger, J., and J. 4043 Reynolds, "Post Office Protocol: Version 2", RFC 937, 4044 DOI 10.17487/RFC0937, February 1985, 4045 . 4047 [16] Postel, J. and J. Reynolds, "File Transfer Protocol", 4048 STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985, 4049 . 4051 [17] Partridge, C., "Mail routing and the domain system", 4052 STD 10, RFC 974, DOI 10.17487/RFC0974, January 1986, 4053 . 4055 [18] Partridge, C., "Duplicate messages and SMTP", RFC 1047, 4056 DOI 10.17487/RFC1047, February 1988, 4057 . 4059 [19] Lambert, M., "PCMAIL: A distributed mail system for 4060 personal computers", RFC 1056, DOI 10.17487/RFC1056, June 4061 1988, . 4063 [20] Crispin, M., "Interactive Mail Access Protocol: Version 4064 2", RFC 1176, DOI 10.17487/RFC1176, August 1990, 4065 . 4067 [21] Durand, A. and F. Dupont, "SMTP 521 Reply Code", RFC 1846, 4068 DOI 10.17487/RFC1846, September 1995, 4069 . 4071 [22] Galvin, J., Murphy, S., Crocker, S., and N. Freed, 4072 "Security Multiparts for MIME: Multipart/Signed and 4073 Multipart/Encrypted", RFC 1847, DOI 10.17487/RFC1847, 4074 October 1995, . 4076 [23] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. 4077 Crocker, "SMTP Service Extensions", STD 10, RFC 1869, 4078 DOI 10.17487/RFC1869, November 1995, 4079 . 4081 [24] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 4082 STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, 4083 . 4085 [25] De Winter, J., "SMTP Service Extension for Remote Message 4086 Queue Starting", RFC 1985, DOI 10.17487/RFC1985, August 4087 1996, . 4089 [26] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 4090 Extensions (MIME) Part One: Format of Internet Message 4091 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 4092 . 4094 [27] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 4095 Part Three: Message Header Extensions for Non-ASCII Text", 4096 RFC 2047, DOI 10.17487/RFC2047, November 1996, 4097 . 4099 [28] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): 4100 Mapping between X.400 and RFC 822/MIME", RFC 2156, 4101 DOI 10.17487/RFC2156, January 1998, 4102 . 4104 [29] Elz, R. and R. Bush, "Clarifications to the DNS 4105 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 4106 . 4108 [30] Freed, N. and K. Moore, "MIME Parameter Value and Encoded 4109 Word Extensions: Character Sets, Languages, and 4110 Continuations", RFC 2231, DOI 10.17487/RFC2231, November 4111 1997, . 4113 [31] Klensin, J., Ed., "Simple Mail Transfer Protocol", 4114 RFC 2821, DOI 10.17487/RFC2821, April 2001, 4115 . 4117 [32] Freed, N., "SMTP Service Extension for Command 4118 Pipelining", STD 60, RFC 2920, DOI 10.17487/RFC2920, 4119 September 2000, . 4121 [33] Freed, N., "Behavior of and Requirements for Internet 4122 Firewalls", RFC 2979, DOI 10.17487/RFC2979, October 2000, 4123 . 4125 [34] Vaudreuil, G., "SMTP Service Extensions for Transmission 4126 of Large and Binary MIME Messages", RFC 3030, 4127 DOI 10.17487/RFC3030, December 2000, 4128 . 4130 [35] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 4131 Extension for Delivery Status Notifications (DSNs)", 4132 RFC 3461, DOI 10.17487/RFC3461, January 2003, 4133 . 4135 [36] Moore, K. and G. Vaudreuil, "An Extensible Message Format 4136 for Delivery Status Notifications", RFC 3464, 4137 DOI 10.17487/RFC3464, January 2003, 4138 . 4140 [37] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4141 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 4142 . 4144 [38] Klensin, J. and Y. Ko, "Overview and Framework for 4145 Internationalized Email", RFC 6530, DOI 10.17487/RFC6530, 4146 February 2012, . 4148 [39] Yao, J. and W. Mao, "SMTP Extension for Internationalized 4149 Email", RFC 6531, DOI 10.17487/RFC6531, February 2012, 4150 . 4152 [40] Hansen, T., Ed. and A. Melnikov, Ed., "Message Disposition 4153 Notification", STD 85, RFC 8098, DOI 10.17487/RFC8098, 4154 February 2017, . 4156 [41] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ 4157 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 4158 Message Specification", RFC 8551, DOI 10.17487/RFC8551, 4159 April 2019, . 4161 [42] Nakamura, M. and J. Hagino, "SMTP Operational Experience 4162 in Mixed IPv4/v6 Environments", RFC 3974, 4163 DOI 10.17487/RFC3974, January 2005, 4164 . 4166 [43] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 4167 Resource Identifier (URI): Generic Syntax", STD 66, 4168 RFC 3986, DOI 10.17487/RFC3986, January 2005, 4169 . 4171 [44] Gellens, R. and J. Klensin, "Message Submission for Mail", 4172 STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011, 4173 . 4175 [45] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 4176 Thayer, "OpenPGP Message Format", RFC 4880, 4177 DOI 10.17487/RFC4880, November 2007, 4178 . 4180 [46] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced 4181 Mail System Status Codes", BCP 138, RFC 5248, 4182 DOI 10.17487/RFC5248, June 2008, 4183 . 4185 [47] Klensin, J., Freed, N., Rose, M., and D. Crocker, Ed., 4186 "SMTP Service Extension for 8-bit MIME Transport", STD 71, 4187 RFC 6152, DOI 10.17487/RFC6152, March 2011, 4188 . 4190 [48] Klensin, J., "SMTP 521 and 556 Reply Codes", RFC 7504, 4191 DOI 10.17487/RFC7504, June 2015, 4192 . 4194 [49] Levine, J. and M. Delany, "A "Null MX" No Service Resource 4195 Record for Domains That Accept No Mail", RFC 7505, 4196 DOI 10.17487/RFC7505, June 2015, 4197 . 4199 [50] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 4200 DOI 10.17487/RFC5321, October 2008, 4201 . 4203 [51] Klensin, J.C., Ed., Murchison, K., Ed., and E. Sam, Ed., 4204 "Applicability Statement for IETF Core Email Protocols", 6 4205 August 2021, . 4208 [52] Internet Assigned Number Authority (IANA), "IANA Mail 4209 Parameters: SMTP Service Extensions", 2022, 4210 . 4213 [53] Internet Assigned Number Authority (IANA), "IANA Mail 4214 Parameters: Mail Transmission Types", 2022, 4215 . 4218 [54] Internet Assigned Number Authority (IANA), "Address 4219 Literal Tags", 2007, 4220 . 4222 [55] RFC Editor, "RFC Errata - RFC 5321", 2019, 4223 . Captured 4224 2019-11-19 4226 [56] IANA, "SMTP Service Extensions", 2021, 4227 . Notes in draft: RFC 4229 Editor: Please adjust date field to reflect whatever you 4230 want for a registry that is updated periodically. IANA: 4231 Please determine if the above URL is a sufficiently stable 4232 reference and adjust as appropriate if it is not. 4234 Appendix A. TCP Transport Service 4236 The TCP connection supports the transmission of 8-bit bytes. The 4237 SMTP data is 7-bit ASCII characters. Each character is transmitted 4238 as an 8-bit byte with the high-order bit cleared to zero. Service 4239 extensions may modify this rule to permit transmission of full 8-bit 4240 data bytes as part of the message body, or, if specifically designed 4241 to do so, in SMTP commands or responses. 4243 Appendix B. Generating SMTP Commands from RFC 822 Header Fields 4245 Some systems use an RFC 822 header section (only) in a mail 4246 submission protocol, or otherwise generate SMTP commands from RFC 822 4247 header fields when such a message is handed to an MTA from a UA. 4248 While the MTA-UA protocol is a private matter, not covered by any 4249 Internet Standard, there are problems with this approach. For 4250 example, there have been repeated problems with proper handling of 4251 "bcc" copies and redistribution lists when information that 4252 conceptually belongs to the mail envelope is not separated early in 4253 processing from header field information (and kept separate). 4255 It is recommended that the UA provide its initial ("submission 4256 client") MTA with an envelope separate from the message itself. 4257 However, if the envelope is not supplied, SMTP commands SHOULD be 4258 generated as follows: 4260 1. Each recipient address from a TO, CC, or BCC header field SHOULD 4261 be copied to a RCPT command (generating multiple message copies 4262 if that is required for queuing or delivery). This includes any 4263 addresses listed in a RFC 822 "group". Any BCC header fields 4264 SHOULD then be removed from the header section. Once this 4265 process is completed, the remaining header fields SHOULD be 4266 checked to verify that at least one TO, CC, or BCC header field 4267 remains. If none do, then a BCC header field with no additional 4268 information SHOULD be inserted as specified in [13]. 4270 2. The return address in the MAIL command SHOULD, if possible, be 4271 derived from the system's identity for the submitting (local) 4272 user, and the "From:" header field otherwise. If there is a 4273 system identity available, it SHOULD also be copied to the Sender 4274 header field if it is different from the address in the From 4275 header field. (Any Sender header field that was already there 4276 SHOULD be removed.) Systems may provide a way for submitters to 4277 override the envelope return address, but may want to restrict 4278 its use to privileged users. This will not prevent mail forgery, 4279 but may lessen its incidence; see Section 7.1. 4281 When an MTA is being used in this way, it bears responsibility for 4282 ensuring that the message being transmitted is valid. The mechanisms 4283 for checking that validity, and for handling (or returning) messages 4284 that are not valid at the time of arrival, are part of the MUA-MTA 4285 interface and not covered by this specification. 4287 A submission protocol based on Standard RFC 822 information alone 4288 MUST NOT be used to gateway a message from a foreign (non-SMTP) mail 4289 system into an SMTP environment. Additional information to construct 4290 an envelope must come from some source in the other environment, 4291 whether supplemental header fields or the foreign system's envelope. 4293 Attempts to gateway messages using only their header "To" and "Cc" 4294 fields have repeatedly caused mail loops and other behavior adverse 4295 to the proper functioning of the Internet mail environment. These 4296 problems have been especially common when the message originates from 4297 an Internet mailing list and is distributed into the foreign 4298 environment using envelope information. When these messages are then 4299 processed by a header-section-only remailer, loops back to the 4300 Internet environment (and the mailing list) are almost inevitable. 4302 Appendix C. Placeholder (formerly Source Routes) 4304 // This entire section has been removed, with some material moved 4305 // into Appendix F.2. This comment is retained as a temporary 4306 // placeholder because the WG, the Ticket list, and various email 4307 // threads refer to Appendix letters and it would not be good to 4308 // create confusion about that while rfc5321bis is under development. 4310 Appendix D. Scenarios 4312 This section presents complete scenarios of several types of SMTP 4313 sessions. In the examples, "C:" indicates what is said by the SMTP 4314 client, and "S:" indicates what is said by the SMTP server. 4316 D.1. A Typical SMTP Transaction Scenario 4318 This SMTP example shows mail sent by Smith at host bar.com, and to 4319 Jones, Green, and Brown at host foo.com. Here we assume that host 4320 bar.com contacts host foo.com directly. The mail is accepted for 4321 Jones and Brown. Green does not have a mailbox at host foo.com. 4323 S: 220 foo.com Simple Mail Transfer Service Ready 4324 C: EHLO bar.com 4325 S: 250-foo.com greets bar.com 4326 S: 250-8BITMIME 4327 S: 250-SIZE 4328 S: 250-DSN 4329 S: 250 HELP 4330 C: MAIL FROM: 4331 S: 250 OK 4332 C: RCPT TO: 4333 S: 250 OK 4334 C: RCPT TO: 4335 S: 550 No such user here 4336 C: RCPT TO: 4337 S: 250 OK 4338 C: DATA 4339 S: 354 Start mail input; end with . 4340 C: Blah blah blah... 4341 C: ...etc. etc. etc. 4342 C: . 4343 S: 250 OK 4344 C: QUIT 4345 S: 221 foo.com Service closing transmission channel 4347 D.2. Aborted SMTP Transaction Scenario 4348 S: 220 foo.com Simple Mail Transfer Service Ready 4349 C: EHLO bar.com 4350 S: 250-foo.com greets bar.com 4351 S: 250-8BITMIME 4352 S: 250-SIZE 4353 S: 250-DSN 4354 S: 250 HELP 4355 C: MAIL FROM: 4356 S: 250 OK 4357 C: RCPT TO: 4358 S: 250 OK 4359 C: RCPT TO: 4360 S: 550 No such user here 4361 C: RSET 4362 S: 250 OK 4363 C: QUIT 4364 S: 221 foo.com Service closing transmission channel 4366 D.3. Relayed Mail Scenario 4368 Step 1 -- Source Host to Relay Host 4369 The source host performs a DNS lookup on XYZ.COM (the destination 4370 address) and finds DNS MX records specifying xyz.com as the best 4371 preference and foo.com as a lower preference. It attempts to open a 4372 connection to xyz.com and fails. It then opens a connection to 4373 foo.com, with the following dialogue: 4375 S: 220 foo.com Simple Mail Transfer Service Ready 4376 C: EHLO bar.com 4377 S: 250-foo.com greets bar.com 4378 S: 250-8BITMIME 4379 S: 250-SIZE 4380 S: 250-DSN 4381 S: 250 HELP 4382 C: MAIL FROM: 4383 S: 250 OK 4384 C: RCPT TO: 4385 S: 250 OK 4386 C: DATA 4387 S: 354 Start mail input; end with . 4388 C: Date: Thu, 21 May 1998 05:33:29 -0700 4389 C: From: John Q. Public 4390 C: Subject: The Next Meeting of the Board 4391 C: To: Jones@xyz.com 4392 C: 4393 C: Bill: 4394 C: The next meeting of the board of directors will be 4395 C: on Tuesday. 4396 C: John. 4397 C: . 4398 S: 250 OK 4399 C: QUIT 4400 S: 221 foo.com Service closing transmission channel 4402 Step 2 -- Relay Host to Destination Host 4403 foo.com, having received the message, now does a DNS lookup on 4404 xyz.com. It finds the same set of MX records, but cannot use the one 4405 that points to itself (or to any other host as a worse preference). 4406 It tries to open a connection to xyz.com itself and succeeds. Then 4407 we have: 4409 S: 220 xyz.com Simple Mail Transfer Service Ready 4410 C: EHLO foo.com 4411 S: 250 xyz.com is on the air 4412 C: MAIL FROM: 4413 S: 250 OK 4414 C: RCPT TO: 4415 S: 250 OK 4416 C: DATA 4417 S: 354 Start mail input; end with . 4418 C: Received: from bar.com by foo.com ; Thu, 21 May 1998 4419 C: 05:33:29 -0700 4420 C: Date: Thu, 21 May 1998 05:33:29 -0700 4421 C: From: John Q. Public 4422 C: Subject: The Next Meeting of the Board 4423 C: To: Jones@xyz.com 4424 C: 4425 C: Bill: 4426 C: The next meeting of the board of directors will be 4427 C: on Tuesday. 4428 C: John. 4429 C: . 4430 S: 250 OK 4431 C: QUIT 4432 S: 221 xyz.com Service closing transmission channel 4434 D.4. Verifying and Sending Scenario 4435 S: 220 foo.com Simple Mail Transfer Service Ready 4436 C: EHLO bar.com 4437 S: 250-foo.com greets bar.com 4438 S: 250-8BITMIME 4439 S: 250-SIZE 4440 S: 250-DSN 4441 S: 250-VRFY 4442 S: 250 HELP 4443 C: VRFY Crispin 4444 S: 250 Mark Crispin 4445 C: MAIL FROM: 4446 S: 250 OK 4447 C: RCPT TO: 4448 S: 250 OK 4449 C: DATA 4450 S: 354 Start mail input; end with . 4451 C: Blah blah blah... 4452 C: ...etc. etc. etc. 4453 C: . 4454 S: 250 OK 4455 C: QUIT 4456 S: 221 foo.com Service closing transmission channel 4458 Appendix E. Other Gateway Issues 4460 In general, gateways between the Internet and other mail systems 4461 SHOULD attempt to preserve any layering semantics across the 4462 boundaries between the two mail systems involved. Gateway- 4463 translation approaches that attempt to take shortcuts by mapping 4464 (such as mapping envelope information from one system to the message 4465 header section or body of another) have generally proven to be 4466 inadequate in important ways. Systems translating between 4467 environments that do not support both envelopes and a header section 4468 and Internet mail must be written with the understanding that some 4469 information loss is almost inevitable. 4471 Appendix F. Deprecated Features of RFC 821 4473 A few features of RFC 821 have proven to be problematic and SHOULD 4474 NOT be used in Internet mail. Some of these features were deprecated 4475 in RFC 2821 in 2001; source routing and two-digit years in dates were 4476 deprecated even earlier, by RFC 1123 in 1989. Of the domain literal 4477 forms, RFC 1123 required support only for the dotted decimal form. 4478 With the possible exception of old, hardware-embedded, applications, 4479 there is no longer any excuse for these features to appear on the 4480 contemporary Internet. 4482 F.1. TURN 4484 This command, described in RFC 821, raises important security issues 4485 since, in the absence of strong authentication of the host requesting 4486 that the client and server switch roles, it can easily be used to 4487 divert mail from its correct destination. Its use is deprecated; 4488 SMTP systems SHOULD NOT use it unless the server can authenticate the 4489 client. 4491 F.2. Source Routing 4493 RFC 821 utilized the concept of explicit source routing to get mail 4494 from one host to another via a series of relays. Source routes could 4495 appear in either the or to show the 4496 hosts through which mail would be routed to reach the destination. 4497 The requirement to utilize source routes in regular mail traffic was 4498 eliminated by the introduction of the domain name system "MX" record 4499 by RFC 974 in early 1986 and the last significant justification for 4500 them was eliminated by the introduction, in RFC 1123, of a clear 4501 requirement that addresses following an "@" must all be fully- 4502 qualified domain names. Issues involving local aliases for mailboxes 4503 were addressed by the introduction of a separate specification for 4504 mail submission [44]. Consequently, there are no remaining 4505 justifications for the use of source routes other than support for 4506 very old SMTP clients. Even use in mail system debugging is unlikely 4507 to work because almost all contemporary systems either ignore or 4508 reject them. 4510 Historically, for relay purposes, the forward-path may have been a 4511 source route of the form "@ONE,@TWO:JOE@THREE", where ONE, TWO, and 4512 THREE MUST be fully-qualified domain names. This form was used to 4513 emphasize the distinction between an address and a route. The 4514 mailbox (here, JOE@THREE) is an absolute address, and the route is 4515 information about how to get there. The two concepts should not be 4516 confused. 4518 SMTP servers MAY continue to accept source route syntax as specified 4519 in this appendix. If they do so, they SHOULD ignore the routes and 4520 utilize only the target domain in the address. If they do utilize 4521 the source route, the message MUST be sent to the first domain shown 4522 in the address. 4524 In particular, a server MUST NOT guess at shortcuts within the source 4525 route. 4527 SMTP clients MUST NOT attempt to utilize explicit source routing. 4529 If source routes appear in mail received by an SMTP server contrary 4530 to the requirements and recommendations in this specification, RFC 4531 821 and the text below should be consulted for the mechanisms for 4532 constructing and updating the forward-path. A server that is reached 4533 by means of a source route (e.g., its domain name appears first in 4534 the list in the forward-path) MUST remove its domain name from any 4535 forward-paths in which that domain name appears before forwarding the 4536 message and MAY remove all other source routing information. Any 4537 source route information in the reverse-path SHOULD be removed by 4538 servers conforming to this specification. 4540 The following information is provided for historical information so 4541 that the source route syntax and application can be understood if 4542 needed. 4544 Syntax: 4545 The original form of the production in Section 4.1.2 was: 4547 Path = "<" [ A-d-l ":" ] Mailbox ">" 4549 A-d-l = At-domain *( "," At-domain ) 4551 At-domain = "@" Domain 4553 For example, suppose that a delivery service notification must be 4554 sent for a message that arrived with: 4555 MAIL FROM:<@a.example,@b.example:user@d.example> 4556 The notification message MUST be sent using: 4557 RCPT TO: 4559 F.3. HELO 4561 As discussed in Sections 3.1 and 4.1.1, EHLO SHOULD be used rather 4562 than HELO when the server will accept the former. Servers MUST 4563 continue to accept and process HELO in order to support older 4564 clients. 4566 F.4. #-literals 4568 RFC 821 provided for specifying an Internet address as a decimal 4569 integer host number prefixed by a pound sign, "#". In practice, that 4570 form has been obsolete since the introduction of TCP/IP. It is 4571 deprecated and MUST NOT be used. 4573 F.5. Dates and Years 4575 When dates are inserted into messages by SMTP clients or servers 4576 (e.g., in trace header fields), four-digit years MUST BE used. Two- 4577 digit years are deprecated; three-digit years were never permitted in 4578 the Internet mail system. 4580 F.6. Sending versus Mailing 4582 In addition to specifying a mechanism for delivering messages to 4583 user's mailboxes, RFC 821 provided additional, optional, commands to 4584 deliver messages directly to the user's terminal screen. These 4585 commands (SEND, SAML, SOML) were rarely implemented, and changes in 4586 workstation technology and the introduction of other protocols may 4587 have rendered them obsolete even where they are implemented. 4589 Clients SHOULD NOT use SEND, SAML, or SOML commands. If a server 4590 implements them, the implementation model specified in RFC 821 [4] 4591 MUST be used and the command names MUST be published in the response 4592 to the EHLO command. 4594 Appendix G. Other Outstanding Issues 4596 [[RFC Editor: Please remove this section before publication.]] 4598 In December 2019, an issue was raised on the ietf-smtp@ietf.org list 4599 that led to a broad discussion of ways in which existing practice had 4600 diverged from the specifications and recommendations of RFC 5321 in 4601 the more than eleven years since it was published (some of those 4602 issues probably affect the boundary between RFC 5321 and 5322 and 4603 hence the latter as well). In most cases, those divergences call for 4604 revision of the Technical Specification to match the practice, 4605 clarification of the specification text in other ways, or a more 4606 comprehensive explanation of why the practices recommended by the 4607 specification should really be followed. 4609 Those discussions raised two other issues, which were that 4611 * The publication of the Submission Server specification of RFC 6409 4612 in November 2011 may not have been fully reflected in RFC 5321 4613 (despite the even earlier publication of RFC 4409) and 4615 * There may be inconsistencies between the July 2009 Internet Mail 4616 Architecture description of RFC 5598 and the model described in 4617 RFC 5321. The issue called out in Appendix H.3 below may be an 4618 example of one of those inconsistencies. 4620 Those discrepancies should be identified and discussed and decisions 4621 made to fix them (and where) or to ignore them and let them continue. 4623 There has also been discussion on the mailing list, perhaps amounting 4624 to very rough consensus, that any revision of RFC 5321 and/or 5322 4625 should be accompanied by a separate Applicability Statement document 4626 that would make recommendations about applicability or best practices 4627 in particular areas rather than trying to get everything into the two 4628 technical specifications. This appendix does not attempt to identify 4629 which issues should get which treatment. 4631 This work is now (starting in the last half of 2020) being considered 4632 in the EMAILCORE WG. This appendix will act as a temporary record of 4633 issues that should be discussed and decided upon before a revised 4634 SMTP specification (or a related Applicability Statement) is 4635 published, issues that have not been reflected in errata (see 4636 Appendix I.1 below for those covered by errata). 4638 Ticket numbers listed below and in the appendix that follows 4639 reference the list in (formerly 4641 ). 4643 G.1. IP Address literals 4645 Closed for RFC5321bis; issue for A/S. See Appendix H.1 4647 G.2. Repeated Use of EHLO (closed) 4649 Closed, see Appendix H.2 4651 G.3. Meaning of "MTA" and Related Terminology 4653 Done, note added -11, pending close, see Appendix H.3. 4655 G.4. Originator, or Originating System, Authentication 4657 This topic should be addressed in the A/S. See Appendix H.4. 4659 G.5. Remove or deprecate the work-around from code 552 to 452 4661 Closed, see Appendix H.6. 4663 G.6. Clarify where the protocol stands with respect to submission and 4664 TLS issues 4666 1. submission on port 587 4667 2. submission on port 465 4669 3. TLS relay on a port different from 25 (whenever) 4671 4. Recommendations about general use of transport layer (hop by hop) 4672 security, particularly encryption including consideration of RFC 4673 8314. 4675 This should probably be an A/S issue. 4676 Apparently no ticket assigned although related to Ticket #53 and 4677 Appendix H.17. 4679 G.7. Probably-substantive Discussion Topics Identified in Other Ways 4681 The following issues were identified as a group in the opening Note 4682 but called out specifically only in embedded CREF comments in 4683 versions of this draft prior to the first EMAILCORE version. In many 4684 cases, those CREF comments were removed after issues were closed. 4686 G.7.1. Issues with 521, 554, and 556 codes (closed) 4688 Closed, see Appendix H.8. Note additional discussion started 4689 2022-05-18 may require reopening or a new ticket, see 4690 Appendix G.7.18. There is also a loose end noted with a CREF comment 4691 in Section 3.1 4693 G.7.2. SMTP Model, terminology, and relationship to RFC 5598 4695 CREF comment in Section 2, CREF comment in Section 2.3.10, and 4696 comments in the introductory portion of Appendix G. 4697 No specific tickets assigned but most of all of these issues have 4698 been discussed and changes made as needed. Can it be closed? 4700 G.7.3. Resolvable FQDNs and private domain names (closed) 4702 Several tickets listed, all appear to be closed. See Appendix H.7. 4704 G.7.4. Possible clarification about mail transactions and transaction 4705 state 4707 Tracker says ready to be closed as of 2022-05-19 (see Appendix H.5). 4709 G.7.5. Issues with mailing lists, aliases, and forwarding 4711 CREF comment in Section 3.4.2. May also want to note forwarding as 4712 an email address portability issue. Note that, if changes are made 4713 in this area, they should be kept consistent with the description and 4714 discussion of the 251 and 551 codes in Section 4.2 and Section 3.5 as 4715 well as Section 3.4.1 to avoid introducing inconsistencies. In 4716 addition, there are some terminology issues about the use of the term 4717 "lists", identified in erratum 1820, that should be reviewed after 4718 any more substantive changes are made to the relevant sections. 4719 Ticket #12 and Ticket #34 (Ticket #34/ erratum 1820 resolved in -06 4720 and closed). (Ticket #61 identified in tracker as duplicate of 4721 Ticket #12.) 4723 G.7.6. Requirements for domain name and/or IP address in EHLO 4725 RFC5321bis parts closed (see Appendix H.9). Some work still to be 4726 done in A/S. 4728 G.7.7. Does the 'first digit only' and/or non-listed reply code text 4729 need clarification? 4731 Closed, see Appendix H.10. 4733 G.7.8. Size limits 4735 Closed, see Appendix H.11 4737 G.7.9. Discussion of 'blind' copies and RCPT 4739 CREF comment in Section 7.2. May also need to discuss whether that 4740 terminology is politically incorrect and suggest a replacement. 4741 Ticket #15. 4743 G.7.10. Further clarifications needed to source routes? 4745 Closed, see Appendix H.12 4747 G.7.11. Should 1yz Be Revisited? 4749 Closed, see Appendix H.13 4751 G.7.12. Review Timeout Specifications 4753 To be discussed in A/S, see Appendix H.14. 4755 G.7.13. Possible SEND, SAML, SOML Loose End (closed) 4757 Closed, see Appendix H.15 4759 G.7.14. Abstract Update (closed) 4761 Closed, see Appendix H.16. 4763 G.7.15. Informative References to MIME and/or Message Submission 4764 (closed) 4766 Closed, see Appendix H.17 4768 G.7.16. Mail Transaction Discussion 4770 Probably duplicate of (closed?) Ticket #11, see Appendix H.5 4772 G.7.17. Hop by hop Authentication and/or Encryption (closed) 4774 Closed (no action required in rfc5321bis), see Appendix H.18 4776 G.7.18. More Text About 554 Given 521, etc. 4778 Does reply code 554 need additional or different explanation in the 4779 light of the addition of the new 521 code and/or the new text in 4780 5321bis Section 4.2.4.2)? (See CREF after RCPT in Section 4.2.3.) 4781 Unless this is to be left to editor's discretion, 4783 G.7.19. Minimum Lengths and Quantities 4785 Are the minimum lengths and quantities specified in Section 4.5.3 4786 still appropriate or do they need adjusting? (See CREF at the 4787 beginning of that section.) Also note potential interaction with the 4788 proposed LIMITS SMTP extension (draft-freed-smtp-limits) which may 4789 make this question OBE. 4791 G.8. Enhanced Reply Codes and DSNs 4793 This is part of Ticket #40 and most of the topic should be covered in 4794 the A/S. Treated as closed, see Appendix H.19. 4796 G.9. Revisiting Quoted Strings 4798 Recent discussions both in and out of the IETF have highlighted 4799 instances of non-compliance with the specification of a Local-part 4800 consisting of a Quoted-string, whether any content of QcontentSMTP 4801 that actually requires special treatment consists of qtextSMTP, 4802 quoted-pairSMTP, or both. Section 4.1.2 (of RFC 5321, repeated 4803 above) ends with a few paragraphs of warnings (essentially a partial 4804 applicability statement), the first of which cautions against 4805 cleverness with either Quoted-string or case sensitivity as a threat 4806 to interoperability. 4808 The Quoted-string portion of that discussion has apparently been 4809 widely not read or ignored. Do we need to do something else? If we 4810 do an Applicability Statement, would it be useful to either reference 4811 the discussion in this document from there or to move the discussion 4812 there and reference it (normatively?) from here? 4814 There has been a separate discussion of empty quoted strings in 4815 addresses, i.e., whether the production should be 4816 required to included at least one non-whitespace character. It is 4817 separate from this issue but would be further impacted or distorted 4818 from the considerations identified in this Section. 4820 Text modified in -07 and further modified in -11. 4821 Ticket #21 (believed to be ready to close as of rfc5321bis-11. May 4822 also interact with Ticket #35 (which is an A/S issue). 4824 G.10. Internationalization 4826 RFC 5321 came long before work on internationalization of email 4827 addresses and headers (other than by use of encoded words in MINE) 4828 and specifically before the work of the EAI WG leading to the 4829 SMTPUTF8 specifications, specifically RFCs 6530ff. The second 4830 explanatory paragraph at the end of Section 4.1.2 ("Systems MUST NOT 4831 define mailboxes ...") is an extremely strong prohibition against the 4832 use of non-ASCII characters in SMTP commands and the requirements 4833 about message content in Section 2.3.1 an equally strong one for 4834 content. Would it be appropriate to add something like "in the 4835 absence of relevant extensions" there? Also, given [mis]behavior 4836 seen in the wild, does that paragraph (or an A/S) need an explicit 4837 caution about SMTP servers or clients assuming they can apply the 4838 popular web convention of using %NN sequences as a way to encode non- 4839 ASCII characters ( in RFC 3986) and assuming some later 4840 system will interpret it as they expect? Would it be appropriate to 4841 add an Internationalization Considerations section to the body of 4842 this document if only for the purpose of pointing people elsewhere? 4843 More broadly, while the EAI WG's extensions for non-ASCII headers and 4844 addresses are explicitly out of scope for the EMAILCORE WG (at least 4845 for 5321bis (and 5322bis), those documents make assumptions and 4846 interpretations of the core documents. Are there areas in which 4847 5321bis could and should be clarified to lay a more solid foundation 4848 for the EAI/SMTPUTF8 work and, if so, what are they? 4849 Text added in rfc5321-11, Section 4.1.2. 4850 Mentioned in Ticket #40. 4852 G.11. SMTP Clients, Servers, Senders, and Receivers 4854 Text has been adjusted, closed, see Appendix H.20. 4856 G.12. Extension Keywords Starting in 'X-' 4858 Closed, see Appendix H.21. 4860 G.13. Deprecating HELO 4862 Closed, see Appendix H.22. 4864 G.14. The FOR Clause in Trace Fields: Semantics, Security 4865 Considerations, and Other Issues 4867 The FOR clause in time-stamp ("Received:") fields is seriously under- 4868 defined. It is optional, the syntax is clear, but its semantics and 4869 use, while perhaps obvious from content and the application of common 4870 sense, have never been defined ("never" going back to 821). Do we 4871 want to better define it? Is there any chance that a definition 4872 would invalid existing, conforming and sensible, implementations? If 4873 we do want to define semantics, draft text and advice as to where it 4874 should go are invited. 4876 (Paragraph added 2021-08-18) 4877 In particular, recent discussions point strongly to the need for a 4878 statement to the effect that the value of the for clause must contain 4879 one of the addresses that caused the message to be routed to the 4880 recipient of this message copy (thanks Ned), that no mare than one 4881 address can appear, and that showing one address when there are 4882 multiple RCPT commands may be a security and/or privacy issue (thanks 4883 Ned and Viktor and see ). More detailed or specific 4885 guidance, including case analysis, are probably material for the A/s, 4886 but that is obviously up to the WG. 4888 Note the existing discussions in Section 7.2 and Section 7.6 as they 4889 may need adjustment, or at least cross-references, especially if FOR 4890 is more precisely defined. 4892 There is probably an error in Section 7.6. Its last sentence implies 4893 a possible interaction between messages with multiple recipients and 4894 the FOR clause of trace fields. However, because the syntax of the 4895 FOR clause only allows one Mailbox (or Path), it isn't clear if that 4896 statement is meaningful. Should it be revised to discuss other 4897 situations in which including FOR might not be desirable from a 4898 security or privacy standpoint? (See above -- this paragraph 4899 deliberately not changed in -04 through -11). 4900 Ticket #55 4902 G.15. Resistance to Attacks and Operational Necessity (closed) 4904 Closed, see Appendix H.23 4906 G.16. Mandatory 8BITMIME 4908 There was extensive discussion on the mailing list in October 2021 4909 about messages with and without 8-bit (i.e., octets with the leading 4910 on) content and a tentative conclusion that support for 8BITMIME 4911 should be required. If that is the WG's conclusion, we need to 4912 figure out what to say and where to say it. SHOULD added to 4913 Section 2.4 in rfc5321bis-10. 4914 Anything more probably goes to A/S. 4915 Ticket #64 (and part of Ticket #40. 4917 G.17. New tickets created between 2022-01-21 and 2022-03-01 4919 To keep issues synchronized between this document and the tracker 4920 (now at 4921 ) 4923 a list of new issues added between the January 2022 interim and the 4924 end of the week before the cutoff for completing and posting draft- 4925 ietf-emailcore-rfc5321bis-10 are listed below. 4927 * #58 Clarification of what is a domain name alias and who can 4928 substitute them (Closed 2022-05-19, see Appendix H.24) 4929 * #59 Case sensitive commands? (Marked in tracker as "ready to be 4930 closed" as of 2022-05-19. See Appendix H.24) 4931 * #60 Restricted-capability clients? Marked "ready to close" in 4932 tracker 2022-05-19. See Appendix H.24. 4933 * #61 Explaining mailing lists. Identified in tracker as duplicate 4934 of #12. See Appendix H.24 and Appendix G.7.5 for more 4935 information. 4936 * #62 null mx vs server domain in 4.2.4.2 (See Section 4.2.4.2) 4937 Per IETF113, no change, but was reopened 2022 May with additional 4938 comments. 4940 * #63 VRFY in required commands in 4.5.1 (See Section 4.5.1). 4941 Changing this would also impact Section 3.5.1, Section 3.5.2, 4942 Section 3.5.3, and Section 7.3. 4943 Document adjusted per WG discussion through 2022-05-17. 4944 Status unclear at time rfc5321bis-11 was posted. 4945 * // Editor's note: the section number redundancies are to be sure 4946 // pointers remain accurate if section numbers change. They look 4947 // silly, but are not bugs and all of Appendixes G and H disappear 4948 // before the RFC Editor gets the document. 4950 Appendix H. Completed Items Moved from Appendix G 4952 [[RFC Editor: Please remove this section before publication.]] 4954 This appendix contains items identified as "closed" and moved from 4955 Appendix G (but referenced from there) to allow easier identification 4956 and tracking of open issues. Note that the subsection names 4957 deliberately duplicate those of the earlier appendix. 4959 H.1. IP Address literals 4961 The specification is unclear about whether IP address literals, 4962 particularly IP address literals used as arguments to the EHLO 4963 command, are required to be accepted or whether they are allowed to 4964 be rejected as part of the general "operational necessity" exception. 4965 Some have suggested that rejection of them is so common as an anti- 4966 spam measure that the use of such literals should be deprecated 4967 entirely in the specification, others that the are still useful and 4968 used and/or that, whatever is said about IP address literals within 4969 an SMTP session (e.g., in MAIL or RCPT commands), they should 4970 continue to be allowed (and required) in EHLO. 4971 Ticket #1 (closed for rfc5321bis; issue for A/S). 4973 H.2. Repeated Use of EHLO (closed) 4975 While the specification says that an SMTP client's sending EHLO again 4976 after it has been issued (starting an SMTP session and treats it as 4977 if RSET had been sent (closing the session) followed by EHLO, there 4978 are apparently applications, at least some of them involving setting 4979 up of secure connections, in which the second EHLO is required and 4980 does not imply RSET. Does the specification need to be adjusted to 4981 reflect or call out those cases? 4983 After extended discussion in October 2020, it appears that the 4984 easiest fix to these problems is to clarify the conditions for 4985 termination of a mail transaction in Section 3.3 and to clearly 4986 specify the effect of a second (or subsequent) EHLO command in 4987 Section 4.1.4. 4989 See also Appendix H.5. 4990 Ticket #2. (closed - Both changes have been made in draft-ietf- 4991 emailcore-rfc5321bis-01). 4993 H.3. Meaning of "MTA" and Related Terminology 4995 A terminology issue has come up about what the term "MTA" actually 4996 refers to, a question that became at least slightly more complicated 4997 when we formalized RFC 6409 Submission Servers. Does the document 4998 need to be adjusted to be more clear about this topic? Note that the 4999 answer may interact with the question asked in Section 2 above. 5000 Possibly along the same lines, RFC 2821 changed the RFC 821 5001 terminology from "sender-SMTP" and "receiver-SMTP" to "SMTP client" 5002 and "SMTP server" respectively. As things have evolved, it is 5003 possible that newer terminology is a source of confusion and that the 5004 terminology should be changed back, something that also needs 5005 discussion. 5006 Ticket #3 (done, note added rfc5321bis-11) 5008 H.4. Originator, or Originating System, Authentication (to A/S) 5010 Should RFC 5321bis address authentication and related issues or 5011 should Section 3.4.2 or other text be reshaped (in addition to or 5012 instead of the comment on that section) to lay a better foundation 5013 for such work, either in the context of mailing lists or more 5014 generally? 5015 This may interact with Erratum 4055 and Ticket #30 below. 5017 H.5. Possible clarification about mail transactions and transaction 5018 state (closed 113?) 5020 Original CREF from Section 3.3 was 5021 [5321bis]: This section would be improved by being more specific 5022 about where mail transactions begin and end and then talking about 5023 "transaction state" here, rather than specific prior commands. --JcK 5024 and there should probably be a reference in Section 4.1.4. 5025 Ticket #11. Tracker says ready to be closed as of 2022-05-19. 5027 H.6. Remove or deprecate the work-around from code 552 to 452 (closed) 5029 The suggestion in Section 4.5.3.1.10 may have outlived its usefulness 5030 and/or be inconsistent with current practice. Should it be removed 5031 and/or explicitly deprecated? 5032 SHOULD requirement removed. 5033 Ticket #5 (fixed and closed). 5035 H.7. Resolvable FQDNs and private domain names (closed) 5037 Several CREF comments on this subject were removed from Section 2.3.5 5038 prior to rfc5321bis-10. 5039 Tickets #9 (definition of domain name; not identified in tracker), 5040 #10 (meaning of "resolvable domain name"; closed 2021-06-12), and #41 5041 (closed -- no change 2021-04-05). 5043 H.8. Issues with 521, 554, and 556 codes (closed) 5045 See new Section 4.2.4.2. More text may be needed, there or 5046 elsewhere, about choices of codes in response to initial opening and 5047 to EHLO, especially to deal with selective policy rejections. In 5048 particular, should we more strongly discourage the use of 554 on 5049 initial opening. And should we make up a 421 code (or a new 4yz 5050 code, perhaps 454) code for situations where the server is 5051 temporarily out of service? 5052 Ticket #6 (closed). 5054 H.9. Requirements for domain name and/or IP address in EHLO (mostly 5055 closed, some to A/S) 5057 Text in Section 4.1.4; change made in -05. 5058 Ticket #19 (was ticket #47 -- done in rfc5321bis, more in A/S). 5060 H.10. Does the 'first digit only' and/or non-listed reply code text 5061 need clarification? (closed) 5063 Resolved. Text in Section 4.2 changed 2021-02-08 and CREF comment in 5064 Section 4.3.1 removed. 5066 Perhaps unresolved -- ongoing discussion on mailing list after IETF 5067 110. 5068 Ticket #13 (fixed and closed). 5070 H.11. Size limits (closed) 5072 Once a decision is made about line length rules for RFC 5322bis, 5073 review the size limit discussions in this document, particularly the 5074 CREF comment (Note in Draft) at the end of the introductory material 5075 to Section 4.5.3 to be sure this document says what we want it to 5076 say. (See the additional question about minimum quantities, etc., in 5077 Appendix G.7.19.) 5078 Ticket #14 (closed - no action) and maybe Ticket #38 (to A/S). 5080 H.12. Further clarifications needed to source routes? (closed) 5082 The current text largely deprecates the use of source routes but 5083 suggests that servers continue to support them. 5084 Ticket #17 (Closed 20220125). 5086 H.13. Should 1yz Be Revisited? (closed) 5088 RFC 5321 depreciated the "positive preliminary reply" response code 5089 category with first digit "1", so that the first digit of valid SMTP 5090 response codes must be 2, 3, 4, or 5. It has been suggested (see 5091 mail from Hector Santos with Subject "SMTP Reply code 1yz Positive 5092 Preliminary reply", March 5, 2020 12:56 -0500, on the SMTP list) that 5093 these codes should be reinstated to deal with some situations that 5094 became more plausible after 5321 was published. Do we need to take 5095 this up again? 5096 Ticket #18 (no, closed). 5098 H.14. Review Timeout Specifications 5100 RFC 5321 (and its predecessors going back to 821) specify minimum 5101 periods for client and server to wait before timing out. Are those 5102 intervals still appropriate in a world of faster processors and 5103 faster networks? Should they be updated and revised? Or should more 5104 qualifying language be added? 5105 Ticket #16. 5107 H.15. Possible SEND, SAML, SOML Loose End (closed) 5109 Per discussion (and Ticket #20), the text about SEND, SAML, and SOML 5110 has been removed from the main body of the document so that the only 5111 discussion of them now appears in Appendix F.6. Per the editor's 5112 note in that appendix, is any further discussion needed? WG 5113 conclusion was "no". 5114 Ticket #20 (closed) 5116 H.16. Abstract Update (closed) 5118 Does the Abstract need to be modified in the light of RFC 6409 or 5119 other changes? 5120 Ticket #52 (changes made; closed) 5122 H.17. Informative References to MIME and/or Message Submission (closed) 5124 Should RFC 2045 (MIME) and/or RFC 6409 (Message Submission) be 5125 referenced at the end of Section 1.2? There is now a reference and 5126 brief discussion in that section. 5127 Ticket #53 (more general reference to the A/S, closed). 5129 H.18. Hop by hop Authentication and/or Encryption (closed) 5131 Should this document discuss hop-by-hop authentication or, for that 5132 matter, encryption? (See CREF in Section 2.) 5133 Propose "No, it shouldn't" (20211101 conversation with Todd, 5134 reaffirmed 20220121 plenary) 5135 Ticket #50 (work with in A/S. Closed). 5137 H.19. Enhanced Reply Codes and DSNs 5139 Enhanced Mail System Status Codes (RFC 3463) [8] were added to SMTP 5140 before RFC 5321 was published and are now, together with a 5141 corresponding registry [46], widely deployed and in extensive use in 5142 the network. Similar, the structure and extensions options for 5143 Delivery Status Notifications [36] is implemented, deployed, and in 5144 wide use. Is it time to fold all or part of those mature 5145 specifications into the SMTP spec or at least to mention and 5146 normatively reference them? And, as an aside, do those specs need 5147 work or, if they are kept separate, is it time to move them to 5148 Internet Standard? 5150 At least one of the current references to RFC 3463 indicates that it 5151 SHOULD be used. That presumably makes the reference normative 5152 because one needs that specification to know what the present 5153 document requires. It has been moved in the -03 version of this 5154 draft, but, unless it is move to Internet Standard, it will require 5155 downref treatment. 5156 Part of Ticket #40. 5158 H.20. SMTP Clients, Servers, Senders, and Receivers 5160 RFC 821 used the terms "SMTP-sender" and "SMTP-receiver". In RFC 5161 2821 (and hence in 5321), we switched that to "client" and "server" 5162 (See the discussion in Section 1.2). In part because a relay is a 5163 server and then a client (in some recent practice, even interleaving 5164 the two functions by opening the connection to the next host in line 5165 and sending commands before the incoming transaction is complete), 5166 RFC 5321 continues to use the original terminology in some places. 5167 Should we revisit that usage, possibly even returning to consistent 5168 use of the original terminology? 5169 After discussion at IETF 113, small change made to Section 1.2. 5170 Ticket #3 (closed). 5172 H.21. Extension Keywords Starting in 'X-' (closed) 5174 Section 2.2.2 contains a discussion of SMTP keywords starting in "X". 5175 Given general experience with such things and RFC 6648, is there any 5176 reason to not deprecate that practice entirely and remove that text? 5177 If we do so, should the former Section 4.1.5 be dropped or rewritten 5178 to make clear this is an obsolete practice? 5179 Material formerly in 4.1.5 eliminated in rfc5321bis-06. 5180 Ticket #42 (resolved with -06 and closed). 5182 H.22. Deprecating HELO (closed) 5184 RFC 5321 (and 2821 before it) very carefully circle around the status 5185 of HELO, even recommending its use as a fallback when EHLO is sent 5186 and a "command not recognized" response is received. We are just a 5187 few months short of 20 years; is it time to deprecate the thing and 5188 clean out some or all of that text? And, given a recent (4Q2020) 5189 discussion on the EMAILCORE list, should EHLO be explicitly bound to 5190 SMTP over TCP with the older transports allowed only with HELO? 5191 While those questions may seem independent, separating them is fairly 5192 hard given the way the text is now constructed. 5194 Resolved 2021-01-19: No change 5195 Ticket #43 (closed). 5197 H.23. Resistance to Attacks and Operational Necessity (closed) 5199 Section 7.8 is often cited as allowing an exception to the rules of 5200 the specification for reasons of operational necessity, not just 5201 attack resistance. I (JcK) believe the broader interpretation was 5202 intended by YAM (the section was new in RFC 5321). Recommendation: 5203 change the title to explicitly include "Local Operational 5204 Requirements" and add text to indicate that attack resistance is not 5205 the only possible source of such requirements. 5206 Ticket #48 (done, closed) 5208 H.24. New tickets created between 2022-01-21 and 2022-03-01 and 5209 subsequently closed. 5211 * #58 Clarification of what is a domain name alias and who can 5212 substitute them (see Section 2.3.5). Closed 2022-05-19. 5214 * #59 Case sensitive commands? (See Section 2.4). Marked in 5215 tracker as "ready to be closed" as of 2022-05-19. 5217 * #60 Restricted-capability clients? (See Section 3.3). Text in 5218 rfc5321bis-11 has been adjusted slightly in the hope of clarifying 5219 what is going on. Mailing list discussion thread: 5221 Marked "ready to close" in tracker 5223 2022-05-19. 5225 * #61 Explaining mailing lists (See Section 3.4.2). Note that 5226 Section also interacts with Tickets #4, #30, #34, Appendix H.4, 5227 #12, and Appendix G.7.5. Tracker indicates this is a duplicate of 5228 Ticket #12 5230 Appendix I. RFC 5321 Errata Summary and Tentative Change Log 5232 [[RFC Editor: Please remove this section before publication.]] 5234 I.1. RFC 5321 Errata Summary 5236 This document addresses the following errata filed against RFC 5321 5237 since its publication in October 2008 [55]. As with the previous 5238 appendix, ticket numbers included below reference 5239 https://trac.ietf.org/trac/emailcore/report/1 . 5240 // [[Note in Draft: Unless marked "closed", items with comments below 5241 // have not yet been resolved as errata.]]. 5243 1683 ABNF error. (closed) Section 4.4 5244 Ticket #23 (fixed, closed). 5246 4198 Description error. (closed) Section 4.2. 5247 RESOLVED 2020-12-14, ticket #24 (closed). 5249 2578 Syntax description error. (closed) Section 4.1.2 5250 Ticket #25 (fixed, closed) 5252 1543 Wrong code in description (closed) Section 3.8 5253 Ticket #26 (fixed, closed) 5255 4315 ABNF - IPv6 Section 4.1.3 (closed). Former description in the 5256 document body was: [5321bis]The IPv6 syntax has been adjusted 5257 since 5321 was published (the erratum mentions RFC 5952, but RFC 5258 6874 and draft-carpenter-6man-rfc6874bis should also be 5259 considered). See the rewritten form and the comment in the 5260 section cited in the previous sentence, at least for the RFC 5952 5261 issues. See https://www.rfc-editor.org/errata/eid4315 5262 Ticket #27 (closed 2021-01-19). 5264 5414 ABNF for Quoted-string (closed) Section 4.1.2 5265 Ticket #22 (fixed, closed). 5267 1851 Location of text on unexpected close Section 4.1.1.5 (closed). 5269 Text moved per email 2020-12-31. 5270 Ticket #28 (fixed, closed). 5272 3447 Use of normative language (e.g., more "MUST"s), possible 5273 confusion in some sections Section 4.4. 5274 Ticket #7 5276 // [5321bis]As Barry notes in his verifier comments on the erratum 5277 // (see https://www.rfc-editor.org/errata/eid3447), the comments 5278 and 5279 // suggestions here raise a number of interesting (and difficult) 5280 // issues. One of the issues is that the core of RFCs 5321 (and 5281 // 2821) is text carried over from Jon Postel's RFC 821, a 5282 document 5283 // that was not only written in a different style than the IETF 5284 uses 5285 // today but that was written at a time when no one had dreamt of 5286 RFC 5287 // 2119 or even the IETF itself. It appears to me that trying to 5288 // patch that style might easily result in a document that is 5289 harder 5290 // to read as well as being error prone. If we want to get the 5291 // document entirely into contemporary style, we really should 5292 bite 5293 // the bullet and do a complete rewrite. To respond to a 5294 different 5295 // point in Barry's discussion, I think an explicit statement that 5296 // 5321/5322 and their predecessors differ in places and why would 5297 be 5298 // helpful. Text, and suggestions about where to put it, are 5299 // solicited. A list of differences might be a good idea too, but 5300 // getting it right might be more work than there is available 5301 energy 5302 // to do correctly. 5304 5711 (closed) Missing leading spaces in example Appendix D.3. 5305 As of 2021-03-15, both the txt and html-ized versions of draft- 5306 ietf-emailcore-rfc5321bis-02 were showing identical output for 5307 both parts of the example, so the problem appears to be OBE at 5308 worst. 5309 Ticket #29 (closed 2021-03-16) 5311 4055 (closed) Erratum claims the the description of SPF and DKIM is 5312 wrong. It is not clear what 5321bis should really say about them, 5313 but the current text probably needs work (or dropping, which is 5314 what the proposed erratum suggests). 5315 Text changed; ticket should probably be closed after WG reviews 5316 -04. 5317 Ticket #30 (resolved and closed). 5319 // [5321bis]Note that rejected errata have _not_ been reviewed to see 5320 // if they contain anything useful that should be discussed again 5321 // with the possibility of rethinking and changing text. Volunteers 5322 // sought. 5324 I.2. Changes from RFC 5321 (published October 2008) to the initial 5325 (-00) version of this draft 5327 // This appendix will eventually need to be replaced by a real 5328 // section or standalone appendix describing changes between 5321 and 5329 // the final 5321bis. 5331 * Acknowledgments section (Section 9) trimmed back for new document. 5333 * Introductory paragraph to Appendix F extended to make it clear 5334 that these features were deprecated a long time ago and really 5335 should not be in use any more. 5337 * Adjusted some language to clarify that source routes really, 5338 really, should not be used or depended upon. 5340 * IPv6 address syntax replaced by a copy of the IPv6 URI syntax and 5341 a note added. 5343 * Production index added as a first step in tying all productions to 5344 their sources. As part of the effort to make the document more 5345 easily navigable, table of contents entries have been created for 5346 the individual command descriptions. 5348 * Clarified the relationship between the SMTP "letters, digits, and 5349 hyphens" and DNS "preferred name syntax" (Section 2.3.5). 5351 * Revised the reply code sections to add new 521 and 556 codes, 5352 clarify relationships, and be explicit about the requirement for 5353 clients to rely on first digits rather than the sequences in 5354 Section 4.3.2. 5356 * In conjunction with the above, explicitly obsolete RFCs 1846 and 5357 7504 5359 // That might not be right -- see email 2021-10-03). 5361 * Incorporated a correction reflecting Errata ID 2578. 5363 * Some small editorial changes made to eliminate redundant 5364 statements that were very close together. Other, equally small, 5365 editorial changes have been made to improve grammar or clarity. 5367 * A few questions, marked "[[5321bis Editor's Note:", or "[[Note in 5368 Draft" have been added for the group to resolve. Other questions, 5369 especially those in the errata summary, are simply included in 5370 narrative comments in CREFs. 5372 * Checked and rationalized "response" (to a command) and "reply 5373 code" terminology. One can talk about a "999 response" but only a 5374 "999 reply code". There is no such thing as a "response code". 5376 * Added note about length limit on mailbox names ("email 5377 addresses"). 5379 * Added an "errata summary" subsection to this change log/ 5380 comparison to 5321 in this Appendix. The entire Appendix will, of 5381 course, disappear at the time of RFC publication unless someone 5382 wants to make a strong case for retaining it. 5384 * Rationalized CREFs to 2821, 5321, 5321bis etc.; added note to 5385 readers below the Abstract. 5387 * Temporarily added a "Note on Reading This Working Draft" after the 5388 Abstract. 5390 I.3. Changes Among Versions of rfc5321bis 5392 I.3.1. Changes from draft-klensin-rfc5321bis-00 (posted 2012-12-02) to 5393 -01 5395 Substantively, these two versions differ only by suppression of the 5396 CREF and other discussion associated with the evolution from RFC 2821 5397 to RFC 5321. That change includes an update to the document's Note 5398 to Readers, the date, the file name, and the addition of this change 5399 log subsection. 5401 I.3.2. Changes from draft-klensin-rfc5321bis-01 (20191203) to -02 5402 * Minor clarifications to improve text, e.g., addition of NOOP to 5403 the list of non-mail transaction examples in Section 4.1.4. 5405 * Added topics exposed in the ietf-smtp list and the IETF list 5406 "dogfood" discussion during December 2019 and an index listing of 5407 substantive issues identified only in CREFs in the prior draft as 5408 a new Appendix G.. 5410 I.3.3. Changes from draft-klensin-rfc5321bis-02 (2019-12-27) to -03 5412 * Added more text to Appendix H.8 to specifically call out the 5413 session-opening policy issues surrounding these codes. 5415 * Added discussion of "1yz" reinstatement in Appendix H.13. 5417 * Added discussion of timeouts in Appendix H.14. 5419 * Added subsection on Enhanced Status Codes and DSNs to the 5420 outstanding issues list Appendix H.19. 5422 * Replaced reference to RFC 1652 (8BITMIME) with the Internet 5423 Standard version, RFC 6152. 5425 * With help from cketti, clarified the ABNF productions whose 5426 terminals appear in other documents. 5428 * Added discussions of Quoted-string, Internationalization, and 5429 client-server versus sender-receiver terminology to Appendix G. 5431 * Added note to the Abstract. 5433 I.3.4. Changes from draft-klensin-rfc5321bis-03 (2020-07-02) to draft- 5434 ietf-emailcore-rfc5321bis-00 5436 * Added a paragraph about non-null quoted strings to Appendix G.9. 5438 * Added an explicit pointer to email insecurity and TLS to 5439 Appendix G.6. Inspired by Ben Kaduk's comment on the WG Charter, 5440 2020-09-09. 5442 * Converted document from individual to emailcore WG effort. 5444 I.3.5. Changes from draft-ietf-emailcore-rfc5321bis-00 (2020-10-06) to 5445 -01 5447 * Editorial: Corrected "blackslash" to "backslash" 5448 * Rewrote the introduction to Appendix G slightly to reflect the 5449 creation of the EMAILCORE WG. 5451 * Applied fixes for repeated use of EHLO. See Appendix H.2. 5453 * Added two new questions, one about "X" extensions (Appendix H.21) 5454 and one about the status of HELO (Appendix H.22). 5456 * Removed mention of SEND, SAML, SOML from the main body of the text 5457 (Ticket #20). 5459 * Added a warning about side effects to Appendix G.7.5. 5461 * Added ticket numbers to descriptions of issues and changes, 5462 adjusted some text so relationships would be more clear, and added 5463 subsections to the Appendix G and H lists to pick up on tickets 5464 that were not easily identified in those sections of with the 5465 text. 5467 * Made several additions to the Index, including one to deal with 5468 SEND et al., as above. 5470 I.3.6. Changes from draft-ietf-emailcore-rfc5321bis-01 (2020-12-25) to 5471 -02 5473 * Corrected discussion mailing list to point to emailcore@ietf.org 5474 in the introductory note. 5476 * Added new subsection(s) to Appendix G to reflect newly discovered 5477 issues. 5479 * Changed "as discussed in" references in Section 4.5.5 per ticket 5480 #45. 5482 * Corrected a misleading use of the term "mailbox" in Section 3.3. 5484 * Changed descriptions of use of first digit in replies per ticket 5485 #13. See Appendix H.10. 5487 * Moved paragraph per ticket #28, erratum 1851. 5489 * Added more clarifying cross-references, clarified some CREFs, and 5490 cleaned out some of those that no longer seemed relevant. 5492 * Removed "updates 1123" is unnecessary and obsolete. 5494 * Updated several references. 5496 I.3.7. Changes from draft-ietf-emailcore-rfc5321bis-02 (2021-02-21) to 5497 -03 5499 * Editorial: Fixed some instances of constructions like "RCPT TO 5500 command". The name of the command is RCPT. Sloppy editing in 5501 2008. 5503 * Added text and cross-references to clarify the role of 452 and 552 5504 in "too many recipients" situations. 5506 * Added Appendix H.23 to discuss changes to better reflect 5507 "operational necessity" issue. 5509 * Added detail for erratum 5711, ticket #29. 5511 * Added new subsections of Appendix G.7 to keep some previously- 5512 unnoted CREF notes from getting lost. Also removed some CREFs 5513 that were notes on changes made before the WG was created or 5514 appeared to no longer have value and trimmed or rewrote some of 5515 the remaining ones. 5517 * More discussion of Ticket #13, See Appendix H.10. 5519 * Identified Ticket #41 as closed. See Appendix Appendix H.7; notes 5520 removed from Section 2.3.5. 5522 * "SHOULD" requirement for interpreting 552 "too many recipients" 5523 removed from Section 4.5.3.1.10, explanation added, and text 5524 cleaned up. Also removed the parenthetical historical notes on 5525 the return code definitions in Section 4.2. See Appendix H.6. 5526 (Ticket #5) 5528 * Modified Appendix H.19 to add a note about the normative status of 5529 RFC 3463 and moved that reference. 5531 * Several clarifications to initiation and termination of mail 5532 transactions in Section 4.1.4. 5534 * Several additional minor editorial improvements. 5536 * Note for drafts -03 and -04 only, modified somewhat for -05 but 5537 outdated from -06 forward: Some issues are still outstanding: 5538 Notes were posted to the list on 2021-07-09 about tickets #7 5539 (5322bis issue), #10 , #14 (closed), #20 (closed), #30 (closed), 5540 and #42 (closed). Even though some comments about them appeared 5541 in the subsequent day or so, there appears to have been 5542 insufficient time for discussions to stabilize sufficiently for 5543 changes to be included in this version of the I-D. 5545 I.3.8. Changes from draft-ietf-emailcore-rfc5321bis-03 (2021-07-10) to 5546 -04 5548 * Clarified that the "period" in . is really the ASCII 5549 one in Section 3.3. 5551 * Several other small editorial corrections. 5553 * Added several notes about the possible need to add text to reflect 5554 the presence of MSAs and to clarify whether MUAs send messages 5555 directly to MTAs or whether, in that case, the MUAs are just 5556 incorporating MSA functions. 5558 * Added new text to Appendix G.14 reflecting discussions of the 5559 Received...FOR issue. 5561 * Adjusted discussion of erratum 4315 (Ticket #27) to reflect more 5562 recent IPv6 syntax developments. 5564 * Adjusted discussion of the various "mail not accepted" codes, 5565 rewrote Section 4.2.4.2, annotated and inserted cross-references 5566 in relevant response code descriptions and (tentatively) 5567 identified this document as obsoleting RFC 7505. Editor's guess, 5568 reinforced by a brief conversation with John Levine (lead author 5569 of 7505), is that we should incorporate text as needed and 5570 obsolete it. The changes include replacing the reference to the 5571 "nullMX" I-D with RFC 7505, which I am appalled that neither I nor 5572 anyone else noticed earlier. Cf. Appendix H.8, Section 4.2.4.2, 5573 and Ticket #6. 5575 I.3.9. Changes from draft-ietf-emailcore-rfc5321bis-04 (2021-10-03) to 5576 -05 5578 * Took a first step toward rewriting and updating the introductory 5579 material. It is only a first step; suggestions welcome. 5581 * Minor editorial fixes. 5583 * Correct text about domain name checking in Section 4.1.4, probably 5584 fixing ticket #19. See CREF added there. 5586 * Added Appendix G.16 a placeholder for the 8BITMIME discussion and 5587 possible action. 5589 * Additional changes to the description and organization of trace 5590 field materials. Intended to resolve the 5321bis part of Ticket 5591 #7. 5593 * Remaining patch to SEND, etc., discussion in Appendix F.6 applied 5594 and CREF removed. 5596 * Removed discussion of "X-" and edited associated text. The fix 5597 may or may not be sufficient to resolve Ticket #42 (later closed). 5599 * Verified that the problems of getting four-level sections (e.g., 5600 "4.1.1.1" and other command-specific ones) into the table of 5601 contents and the index reflecting page numbers still exist and 5602 updated the introductory note. 5604 I.3.10. Changes from draft-ietf-emailcore-rfc5321bis-05 (2021-10-24) to 5605 -06 5607 * Finished making changes for "X-" and commands starting in "X". 5608 Changes made in -05 were incomplete. This should allow closing 5609 Ticket #42. 5611 * Removed spurious "for use in delivery notifications" from 3.6.2. 5612 Was just a pasting-type error. 5614 * Changed "In other words" to "In particular" in Section 2.3.5 per 5615 Ticket #10 and July 2021 mailing list discussion. Removed 5616 associated CREF. 5618 * Converted to xml2rfc v3 (thanks to John Levine for doing the hard 5619 parts) and then modified the introductory note accordingly. 5621 * Started reworking the Abstract -- see revised CREF there. 5623 * Rewrote Section 2.3.3 slightly to note the existence of submission 5624 servers and removed the CREF. 5626 * Updated Appendix H.18 and slightly modified CREF note in Section 2 5627 -- proposed to not get 5321bis involved with this (Ticket #50). 5629 * Rewrote parts of Section 3.4.2 to clarify text amd respond to 5630 Ticket #34. 5632 * Inserted suggested text info CREF at end of Section 1.2. Comments 5633 welcome. Soon. 5635 I.3.11. Changes from draft-ietf-emailcore-rfc5321bis-06 (2021-11-07) to 5636 -07 5638 * Reviewed closed tickets and discussion with co-chairs after IETF 5639 112 and updated text. Sections or items that are, according to 5640 the ticket list, completely closed have been identified by 5641 "(closed)" in or near their titles. 5643 * Changed the suggestion for references to other documents mentioned 5644 in G.7.14 and Section 1.2 to actual text. Cleaned things up and, 5645 per note from Alexey 2021-11-17, have marked Ticket #53 as closed. 5647 * New text added and old text replaced about quotes in 5648 Section 4.1.2, text rearranged and edited a bit per Appendix G.9, 5649 and CREF added about alternatives. Changes reflect mailing list 5650 comments through 5652 * Last sentence (about source routing) removed from Section 2.1. 5653 Also adjusted text in Section 3.3, Section 4.1.1.3 but work is 5654 still needed there (see new CREFs in that section) and 5655 Section 6.1. The former Appendix C and references to it have been 5656 removed, leaving a placeholder to avoid changing subsequent 5657 appendix numbering before IETF Last Call (and maybe its 5658 completion) No changes have yet been made to Appendix F.2 but it 5659 is likely to require some work in the next version of the 5660 document. This is entirely about Ticket #17, which should not be 5661 closed until that appendix is updated. 5663 I.3.12. Changes from draft-ietf-emailcore-rfc5321bis-07 (2021-12-04) to 5664 -08 5666 Other than the partial cleanup for "forwarding" and "aliasing" and 5667 miscellaneous editorial fixes and corrections (including cleaning out 5668 unused references), changes in this version reflect the conclusions 5669 of the EMAILCORE interim meeting held 2021-12-09. References to 5670 "slides" are to the deck at https://datatracker.ietf.org/doc/slides- 5671 interim-2021-emailcore-01-sessa-chairs-slides/ and the minutes at 5672 https://notes.ietf.org/notes-emailcore-interim-dec-2021 5674 * (Slides 9 through 12): Removed source route examples from 5675 Section 4.1.1.3 and added a new paragraph explaining what happened 5676 to them. For slides 11 and 12, see below for more general 5677 Appendix F.2 discussion. 5678 (Cf Appendix H.12 and Ticket #17.) 5680 * (Slides 13 through 14): Domain names, Section 2.3.5. Removed 5681 "resolvable". Changed "alias" to "host alias" (although, after 5682 looking at the actual text, the intent seems clear from the CNAME 5683 label comment and, of course, the term "host" has been 5684 controversial in DNS circles and the minutes are not clear on the 5685 desirability of this change). Inserted "MUST" for the FQDN. A 5686 cross-reference to the domain name discussion in this section has 5687 been added to Section 4.1.1.1 in an attempt to resolve that 5688 discussion. 5689 In going carefully through this material, it became obvious that 5690 the discussions in Section 2.3.5 and Section 5 were confusing and 5691 somewhat redundant. Those sections have been rewritten to clarify 5692 intent, hint that extensions may modify (or have modified) a few 5693 of the rules, improve cross-references, and remove redundant text. 5694 Domain name issues are still under discussion on the WG mailing 5695 list as of 2021-12-18 and it is possible that the above changes 5696 may have introduced new issues, so additional changes are 5697 possible. 5698 (Cf target="G-domain"/> and Tickets #9 and maybe #10.) 5700 * Aliasing and forwarding: 5701 Consolidated former sections 3.4 and 3.9 into a new Section 3.4, 5702 making them subsections. The new subsection probably still needs 5703 work and maybe an introductory paragraph, but even bringing the 5704 two subsections together may reduce some sources of confusion 5705 identified on the mailing list. Added cross-reference to security 5706 considerations from the new Section 3.4.1. 5708 All other issues discussed during the interim appear to be unresolved 5709 and were deferred to the mailing list. 5711 As what should be the third and final step in deprecation of source 5712 routes and removal of them from the main text, the appendix that 5713 discusses them (Appendix F.2) has been rewritten, adjusting language 5714 and incorporating some materials from the former Appendix C. 5716 I.3.13. Changes from draft-ietf-emailcore-rfc5321bis-08 (2021-12-31) to 5717 -09 5719 * Multiple small editorial changes. 5721 * Started tuning Appendix I.2 preparatory to an actual "Changes 5722 from" section. 5724 * Moved and rewrote a paragraph that seemed to be out of place from 5725 Section 4.4.1 to Section 4.1.1.3 per November discussion. See the 5726 note in the latter section for discussion. 5728 * Removed "for initial submission of messages" from Section 2.3.5 5729 and changed "may" to "MAY" in the last bullet point there, per 5730 Interim. Removed comment/ Editor's Note from that section: 5731 further instructions and evidence of consensus needed to do 5732 anything additional with it. 5733 Ticket #9 5735 * In Section 3.4.2, rewrote the first sentence to make it 5736 descriptive rather than normative. Also removed the last sentence 5737 of that paragraph. Both per the editor's understanding of the 5738 Interim's conclusions, but the latter was put in because of 5739 problems with people thinking changing the argument to the MAIL 5740 command also required changing "From:" in the headers, so this 5741 should be carefully reviewed on list. Comment removed from that 5742 section -- the dead horse has been kicked past recognition. 5743 Ticket #4. 5745 * In Appendix F.2, changed the requirement for server support to 5746 MAY, and prohibited client support, for source routing. Also made 5747 a small wording change. Per Interim. 5748 Ticket #17 5750 With this draft, comments in the running text ("//" at the beginning 5751 of lines) that seem to no longer be relevant either generally or 5752 after the discussions during the 2022-01-21 Interim are being 5753 removed. The "Notes on Reading..." at the beginning of the document 5754 (just below the Abstract) have been revised accordingly. Sections 5755 from which comments were removed this time include: 5757 * Abstract, comment introduced in -06 (No comments on it through -08 5758 are interpreted as consent; 5760 * Section 2 (any discussion needed will be in A/S); 5762 * Section 2.3.10 (discussion seems to have ended); 5764 * Section 4.1.1.3 (no further discussion during Interim, so assume 5765 comment is no longer needed); 5767 * Section 4.1.2 (no further discussion since -08 appeared or during 5768 Interim, assumed to not require further work); 5770 * Section 4.5.3.1 (further discussion will be in A/S); 5772 * Section 4.2.2 (this comment obsolete since revision -04 of this 5773 document). 5775 * Cross-checked ticket notes and annotations in this document 5776 against the ticket system. Consistent for closed tickets as of 5777 2022-01-31. 5779 I.3.14. Changes from draft-ietf-emailcore-rfc5321bis-09 (2022-02-01 to 5780 -10 5782 * Small editorial fixes, including a lingering typographical error 5783 or two. 5785 * Captured some additional sections into the TOC. 5787 * Added an additional index subsection for terminology, including 5788 the terms of Section 2.3 and a few others. More entries may be 5789 needed. 5791 * Modified Section 3.4.2 to flag continuing uncertainty about 5792 decisions in the January Interim and subsequent list discussion 5793 about some text in that Section. 5795 * Modified Section 4.2.4.2 to correct confusing phrasing and make a 5796 placeholder for a possible addition raised on email 2022-03-05. 5798 * Added Appendix G.16 and Appendix G.17 so all open (and most 5799 closed) applicable ticket numbers are identified in this document. 5801 I.3.15. Changes from draft-ietf-emailcore-rfc5321bis-10 (2022-03-07) to 5802 -11 5804 * In order to improve tracking, removed all closed items for 5805 Appendix G to a new Appendix H, making this section/ appendix into 5806 Appendix I. Stubs are retained in Appendix G so as to not mess up 5807 external references to the relevant numbers. As part of the same 5808 process and to lower the odds of things falling through the 5809 cracks, a new "Ticket Index" has been added to permit accessing 5810 text in those appendices by ticket number. As with those 5811 appendices G and H, this will disappear before the document 5812 becomes an RFC. 5814 * Small editorial fixes, e.g., "this document" in the text referred 5815 to RFC 5321 and would not be accurate for the current draft and to 5816 clarify Section 3.3 slightly. Also better identified closed items 5817 in Appendices G and H.1 and removed more now-obsolete CREF 5818 comments. 5820 * Upgraded the "ASCII" reference and removed "US-ASCII" usage. 5821 Under the principle of minimum change, more citations of X.4-1968 5822 have been left intact with RFC 20 also cited where it seemed 5823 important and a pointer has been inserted from the former 5824 reference to the latter. 5826 * Editorial improvement to the "end of mail data" discussion in 5827 Section 3.3 per a discussion that appeared on tool-discuss in July 5828 2021. No substantive change, just making the requirement 5829 painfully obvious. 5831 * Editorial improvements and additional examples in the discussion 5832 of local-part quoted strings in Section 4.1.2 as discussed in 5833 Appendix G.9 and Ticket #21. 5835 * Modified Section 3.4.2 with edited version of text specified at 5836 IETF 113 to avoid confusion about header field changes when MAIL 5837 command parameter is changed. 5839 * Addressed Ticket #3 about "sender-SMTP" versus "SMTP client" by 5840 adding a note indicating that they are equivalent (per IETF 113 5841 and Alexey's follow-up message 2022-05-5). 5843 * Addressed the VRFY issues per mailing list discussions. Ticket 5844 #63 [should be] closed. 5846 * The portion of Section 1.2 that discussed submission had gotten a 5847 bit hard to follow. It has been cleaned up a bit. I strongly 5848 recommend checking it and making suggestions if it is not to your 5849 taste. The CREF comment that was there before has been removed. 5851 Index 5853 A C S T 5855 A 5857 Argument Syntax 5858 ALPHA Section 4.1.2, Paragraph 2, Item 1 5859 Additional-Registered-Clauses Section 4.4.1, Paragraph 5860 17.26.1 5861 Addtl-Link Section 4.4.1 5862 Addtl-Protocol Section 4.4.1 5863 Argument Section 4.1.2 5864 Atom Section 4.1.2 5865 By-domain Section 4.4.1, Paragraph 17.10.1 5866 CFWS Section 4.1.2, Paragraph 2, Item 2 5867 CRLF Section 4.1.2, Paragraph 2, Item 1 5868 DIGIT Section 4.1.2, Paragraph 2, Item 1 5869 Domain Section 4.1.2 5870 Dot-string Section 4.1.2 5871 Extended-Domain Section 4.4.1 5872 FWS Section 4.1.2, Paragraph 2, Item 2 5873 For Section 4.4.1 5874 Forward-Path Section 4.1.2 5875 From-domain Section 4.4.1, Paragraph 17.8.1 5876 General-address-literal Section 4.1.3 5877 Greeting Section 4.2 5878 HEXDIG Section 4.1.2, Paragraph 2, Item 1 5879 ID Section 4.4.1 5880 IPv4-address-literal Section 4.1.3 5881 IPv6-addr Section 4.1.3 5882 IPv6-address-literal Section 4.1.3 5883 Keyword Section 4.1.2 5884 Ldh-str Section 4.1.2 5885 Let-dig Section 4.1.2 5886 Link Section 4.4.1 5887 Local-part Section 4.1.2 5888 Mail-parameters Section 4.1.2 5889 Mailbox Section 4.1.2 5890 Opt-info Section 4.4.1 5891 Path Section 4.1.2 5892 Protocol Section 4.4.1 5893 QcontentSMTP Section 4.1.2 5894 Quoted-string Section 4.1.2 5895 Rcpt-parameters Section 4.1.2 5896 Reply-code Section 4.2 5897 Reply-line Section 4.2 5898 Return-path-line Section 4.4.1, Paragraph 17.2.1 5899 Reverse-Path Section 4.1.2 5900 SP Section 4.1.2, Paragraph 2, Item 1 5901 Snum Section 4.1.3 5902 Stamp Section 4.4.1, Paragraph 17.6.1 5903 Standardized-tag Section 4.1.3 5904 String Section 4.1.2 5905 TCP-info Section 4.4.1 5906 Time-stamp-line Section 4.4.1, Paragraph 17.4.1 5907 Via Section 4.4.1 5908 With Section 4.4.1 5909 address-literal Section 4.1.2 5910 atext Section 4.1.2, Paragraph 2, Item 2 5911 dcontent Section 4.1.3 5912 esmtp-keyword Section 4.1.2 5913 esmtp-param Section 4.1.2 5914 esmtp-value Section 4.1.2 5915 h16 Section 4.1.3 5916 ls32 Section 4.1.3 5917 qtextSMTP Section 4.1.2 5918 quoted-pairSMTP Section 4.1.2 5919 sub-domain Section 4.1.2 5920 textstring Section 4.2 5922 C 5924 Command Syntax 5925 data Section 4.1.1.4, Paragraph 8, Item 1 5926 ehlo Section 3.2, Paragraph 1; Section 4.1.1.1, Paragraph 1 5927 expn Section 4.1.1.7, Paragraph 4, Item 1 5928 helo Section 4.1.1.1, Paragraph 1 5929 help Section 4.1.1.8, Paragraph 5, Item 1 5930 mail Section 4.1.1.2 5931 noop Section 4.1.1.9, Paragraph 4, Item 1 5932 quit Section 4.1.1.10, Paragraph 5, Item 1 5933 rcpt Section 4.1.1.3, Paragraph 15 5934 rset Section 4.1.1.5, Paragraph 4, Item 1 5935 send, saml, soml Appendix H.15, Paragraph 1 5936 vrfy Section 4.1.1.6, Paragraph 4, Item 1 5938 S 5940 Source Routes Appendix F.2 5941 A-d-l Appendix F.2 5942 At-domain Appendix F.2 5943 Path Appendix F.2 5945 T 5947 Terminology 5948 Address Section 2.3.11, Paragraph 1 5949 Buffer Section 2.3.6, Paragraph 1 5950 Commands and Replies Section 2.3.7, Paragraph 1 5951 Delivery SMTP Section 2.3.10, Paragraph 1 5952 Domain Names Section 2.3.5, Paragraph 1 5953 Gateway Section 2.3.10, Paragraph 2 5954 Host Section 2.3.4, Paragraph 1 5955 Lines Section 2.3.8, Paragraph 1 5956 Mail Agent Section 2.3.3, Paragraph 1 5957 Mail Data Section 2.3.9, Paragraph 1 5958 Mail object Section 2.3.1, Paragraph 1 5959 Mailbox Section 2.3.11, Paragraph 1 5960 Message Content Section 2.3.9, Paragraph 1 5961 Message Store Section 2.3.3, Paragraph 1 5962 Originator Section 2.3.10, Paragraph 1 5963 Relay SMTP Section 2.3.10, Paragraph 1 5964 Senders and Receivers Section 2.3.2, Paragraph 1 5965 State Table Section 2.3.6, Paragraph 1 5966 address RR Section 2.3.5, Paragraph 3 5967 primary host name Section 2.3.5, Paragraph 4, Item 1 5968 Ticket Index 5969 1 Appendix H.1, Paragraph 1 5970 10 Appendix G.10, Paragraph 2; Appendix H.7, Paragraph 1 5971 11 Appendix G.7.16, Paragraph 1; Appendix H.5, Paragraph 1 5972 12 Appendix G.7.5, Paragraph 1; Appendix H.24, Paragraph 5973 1.4.1 5974 13 Appendix H.10, Paragraph 2 5975 14 Appendix H.11, Paragraph 1 5976 15 Appendix G.7.9, Paragraph 1 5977 16 Appendix H.14, Paragraph 1 5978 17 Appendix H.12, Paragraph 1 5979 18 Appendix H.13, Paragraph 1 5980 19 Appendix H.9, Paragraph 1 5981 2 Appendix H.2, Paragraph 2 5982 20 Appendix H.15, Paragraph 1 5983 21 Appendix G.9, Paragraph 4 5984 22 Appendix I.1 5985 23 Appendix I.1 5986 24 Appendix I.1 5987 25 Appendix I.1 5988 26 Appendix I.1 5989 27 Appendix I.1 5990 28 Appendix I.1 5991 29 Appendix I.1 5992 3 Appendix H.3, Paragraph 1 5993 30 Appendix H.4, Paragraph 1; Appendix H.24, Paragraph 5994 1.4.1; Appendix I.1 5995 34 Appendix G.7.5, Paragraph 1; Appendix H.24, Paragraph 5996 1.4.1 5997 35 Appendix G.9, Paragraph 4 5998 38 Appendix H.11, Paragraph 1 5999 4 Appendix H.24, Paragraph 1.4.1 6000 40 Appendix G.8, Paragraph 1; Appendix G.16, Paragraph 1; 6001 Appendix H.19, Paragraph 2 6002 41 Appendix H.7, Paragraph 1 6003 42 Appendix H.21, Paragraph 1 6004 43 Appendix H.20, Paragraph 1; Appendix H.22, Paragraph 2 6005 47 Appendix H.9, Paragraph 1 6006 48 Appendix H.23, Paragraph 1 6007 5 Appendix H.6, Paragraph 1 6008 50 Appendix H.18, Paragraph 1 6009 52 Appendix H.16, Paragraph 1 6010 53 Appendix G.6, Paragraph 2; Appendix H.17, Paragraph 1 6011 55 Appendix G.14, Paragraph 4 6012 58 Appendix H.24, Paragraph 1.1.1 6013 59 Appendix H.24, Paragraph 1.2.1 6014 6 Appendix H.8, Paragraph 1 6015 60 Appendix H.24, Paragraph 1.3.1 6016 61 Appendix G.7.5, Paragraph 1; Appendix H.24, Paragraph 6017 1.4.1 6018 62 Appendix G.17, Paragraph 2.5.1 6019 63 Appendix G.17, Paragraph 2.6.1 6020 64 Appendix G.16, Paragraph 1 6021 7 Appendix I.1 6022 9 Appendix H.7, Paragraph 1 6024 Author's Address 6026 John C. Klensin 6027 1770 Massachusetts Ave, Suite 322 6028 Cambridge, MA 02140 6029 United States of America 6030 Email: john-ietf@jck.com