< draft-ietf-emailcore-rfc5321bis-08.txt   draft-ietf-emailcore-rfc5321bis-09.txt >
EMAILCORE J. Klensin EMAILCORE J. Klensin
Internet-Draft 31 December 2021 Internet-Draft 1 February 2022
Obsoletes: 5321, 1846, 7504, 7505 (if approved) Obsoletes: 5321, 1846, 7504, 7505 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: 4 July 2022 Expires: 5 August 2022
Simple Mail Transfer Protocol Simple Mail Transfer Protocol
draft-ietf-emailcore-rfc5321bis-08 draft-ietf-emailcore-rfc5321bis-09
Abstract Abstract
This document is a specification of the basic protocol for Internet This document is a specification of the basic protocol for Internet
electronic mail transport. It (including text carried forward from electronic mail transport. It (including text carried forward from
RFC 5321) consolidates, updates, and clarifies several previous RFC 5321) consolidates, updates, and clarifies several previous
documents, making all or parts of most of them obsolete. It covers documents, making all or parts of most of them obsolete. It covers
the SMTP extension mechanisms and best practices for the contemporary the SMTP extension mechanisms and best practices for the contemporary
Internet, but does not provide details about particular extensions. Internet, but does not provide details about particular extensions.
The document also provides information about use of SMTP for other The document also provides information about use of SMTP for other
than strict mail transport and delivery. This document replaces RFC than strict mail transport and delivery. This document replaces RFC
5321, the earlier version with the same title. 5321, the earlier version with the same title.
// JcK 20211029 Note in Draft: Adjusted in version -06. Decided the
// details belong in either the Introduction or the A/S, not the
// Abstract. And it makes the Abstract a tad shorter, which is good.
Notes on Reading This Working Draft Notes on Reading This Working Draft
This working draft is extensively annotated with information about Early versions of this working draft were extensively annotated with
changes made over the decade since RFC 5321 appeared, especially when information, primarily in about changes made over the decade since
those changes might be controversial or should get careful review. RFC 5321 appeared, especially when those changes might be
Anything marked in CREF comments with "[5321bis]" is current. In controversial or should get careful review. Most of those
general, unless those are marked with "[[Note in Draft", in the annotations and associated questions are marked in CREF comments
contents of an "Editor's note", or are in the "Errata Summary" ("//" in the text form). Starting with version -09 of the draft,
appendix (Appendix H.1, they are just notes on changes that have annotations and notes that were no longer relevant are being pruned
already been made and where those changes originated. As one can to improve readability In general, any annotations or comments not
tell from the dates (when they are given), this document has been marked with "[[Note in Draft", in the contents of an "Editor's note",
periodically updated over a very long period of time. or are in the "Errata Summary" appendix (Appendix H.1, they are just
notes on changes that have already been made and where those changes
originated. As one can tell from the dates (when they are given),
this document has been periodically updated over a very long period
of time.
As people review or try to use this document, it may be worth paying As people review or try to use this document, it may be worth paying
special attention to the historical discussion in Section 1.2. special attention to the historical discussion in Section 1.2.
This evolving draft should be discussed on the emailcore@ietf.org This evolving draft should be discussed on the emailcore@ietf.org
list. list.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 2, line 20 skipping to change at page 2, line 20
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 4 July 2022. This Internet-Draft will expire on 5 August 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7
1.1. Transport of Electronic Mail . . . . . . . . . . . . . . 7 1.1. Transport of Electronic Mail . . . . . . . . . . . . . . 7
1.2. History and Context for This Document . . . . . . . . . . 7 1.2. History and Context for This Document . . . . . . . . . . 7
1.3. Document Conventions . . . . . . . . . . . . . . . . . . 9 1.3. Document Conventions . . . . . . . . . . . . . . . . . . 9
2. The SMTP Model . . . . . . . . . . . . . . . . . . . . . . . 9 2. The SMTP Model . . . . . . . . . . . . . . . . . . . . . . . 9
2.1. Basic Structure . . . . . . . . . . . . . . . . . . . . . 9 2.1. Basic Structure . . . . . . . . . . . . . . . . . . . . . 9
2.2. The Extension Model . . . . . . . . . . . . . . . . . . . 12 2.2. The Extension Model . . . . . . . . . . . . . . . . . . . 11
2.2.1. Background . . . . . . . . . . . . . . . . . . . . . 12 2.2.1. Background . . . . . . . . . . . . . . . . . . . . . 11
2.2.2. Definition and Registration of Extensions . . . . . . 13 2.2.2. Definition and Registration of Extensions . . . . . . 12
2.2.3. Special Issues with Extensions . . . . . . . . . . . 13 2.2.3. Special Issues with Extensions . . . . . . . . . . . 13
2.3. SMTP Terminology . . . . . . . . . . . . . . . . . . . . 14 2.3. SMTP Terminology . . . . . . . . . . . . . . . . . . . . 13
2.3.1. Mail Objects . . . . . . . . . . . . . . . . . . . . 14 2.3.1. Mail Objects . . . . . . . . . . . . . . . . . . . . 13
2.3.2. Senders and Receivers . . . . . . . . . . . . . . . . 14 2.3.2. Senders and Receivers . . . . . . . . . . . . . . . . 14
2.3.3. Mail Agents and Message Stores . . . . . . . . . . . 15 2.3.3. Mail Agents and Message Stores . . . . . . . . . . . 14
2.3.4. Host . . . . . . . . . . . . . . . . . . . . . . . . 15 2.3.4. Host . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.5. Domain Names . . . . . . . . . . . . . . . . . . . . 15 2.3.5. Domain Names . . . . . . . . . . . . . . . . . . . . 15
2.3.6. Buffer and State Table . . . . . . . . . . . . . . . 16 2.3.6. Buffer and State Table . . . . . . . . . . . . . . . 16
2.3.7. Commands and Replies . . . . . . . . . . . . . . . . 17 2.3.7. Commands and Replies . . . . . . . . . . . . . . . . 16
2.3.8. Lines . . . . . . . . . . . . . . . . . . . . . . . . 17 2.3.8. Lines . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.9. Message Content and Mail Data . . . . . . . . . . . . 17 2.3.9. Message Content and Mail Data . . . . . . . . . . . . 17
2.3.10. Originator, Delivery, Relay, and Gateway Systems . . 18 2.3.10. Originator, Delivery, Relay, and Gateway Systems . . 17
2.3.11. Mailbox and Address . . . . . . . . . . . . . . . . . 18 2.3.11. Mailbox and Address . . . . . . . . . . . . . . . . . 18
2.4. General Syntax Principles and Transaction Model . . . . . 19 2.4. General Syntax Principles and Transaction Model . . . . . 18
3. The SMTP Procedures: An Overview . . . . . . . . . . . . . . 20 3. The SMTP Procedures: An Overview . . . . . . . . . . . . . . 20
3.1. Session Initiation . . . . . . . . . . . . . . . . . . . 20 3.1. Session Initiation . . . . . . . . . . . . . . . . . . . 20
3.2. Client Initiation . . . . . . . . . . . . . . . . . . . . 21 3.2. Client Initiation . . . . . . . . . . . . . . . . . . . . 21
3.3. Mail Transactions . . . . . . . . . . . . . . . . . . . . 22 3.3. Mail Transactions . . . . . . . . . . . . . . . . . . . . 21
3.4. Address Modification and Expansion . . . . . . . . . . . 24 3.4. Address Modification and Expansion . . . . . . . . . . . 24
3.4.1. Forwarding for Address Correction or Updating . . . . 24 3.4.1. Forwarding for Address Correction or Updating . . . . 24
3.4.2. Aliases and Mailing Lists . . . . . . . . . . . . . . 25 3.4.2. Aliases and Mailing Lists . . . . . . . . . . . . . . 25
3.4.2.1. Simple Aliases . . . . . . . . . . . . . . . . . 26 3.4.2.1. Simple Aliases . . . . . . . . . . . . . . . . . 26
3.4.2.2. Mailing Lists . . . . . . . . . . . . . . . . . . 26 3.4.2.2. Mailing Lists . . . . . . . . . . . . . . . . . . 26
3.5. Commands for Debugging Addresses . . . . . . . . . . . . 27 3.5. Commands for Debugging Addresses . . . . . . . . . . . . 26
3.5.1. Overview . . . . . . . . . . . . . . . . . . . . . . 27 3.5.1. Overview . . . . . . . . . . . . . . . . . . . . . . 26
3.5.2. VRFY Normal Response . . . . . . . . . . . . . . . . 29 3.5.2. VRFY Normal Response . . . . . . . . . . . . . . . . 29
3.5.3. Meaning of VRFY or EXPN Success Response . . . . . . 30 3.5.3. Meaning of VRFY or EXPN Success Response . . . . . . 29
3.5.4. Semantics and Applications of EXPN . . . . . . . . . 30 3.5.4. Semantics and Applications of EXPN . . . . . . . . . 30
3.6. Relaying and Mail Routing . . . . . . . . . . . . . . . . 30 3.6. Relaying and Mail Routing . . . . . . . . . . . . . . . . 30
3.6.1. Mail eXchange Records and Relaying . . . . . . . . . 31 3.6.1. Mail eXchange Records and Relaying . . . . . . . . . 30
3.6.2. Message Submission Servers as Relays . . . . . . . . 31 3.6.2. Message Submission Servers as Relays . . . . . . . . 30
3.7. Mail Gatewaying . . . . . . . . . . . . . . . . . . . . . 32 3.7. Mail Gatewaying . . . . . . . . . . . . . . . . . . . . . 31
3.7.1. Header Fields in Gatewaying . . . . . . . . . . . . . 32 3.7.1. Header Fields in Gatewaying . . . . . . . . . . . . . 32
3.7.2. Received Lines in Gatewaying . . . . . . . . . . . . 33 3.7.2. Received Lines in Gatewaying . . . . . . . . . . . . 32
3.7.3. Addresses in Gatewaying . . . . . . . . . . . . . . . 33 3.7.3. Addresses in Gatewaying . . . . . . . . . . . . . . . 33
3.7.4. Other Header Fields in Gatewaying . . . . . . . . . . 33 3.7.4. Other Header Fields in Gatewaying . . . . . . . . . . 33
3.7.5. Envelopes in Gatewaying . . . . . . . . . . . . . . . 34 3.7.5. Envelopes in Gatewaying . . . . . . . . . . . . . . . 33
3.8. Terminating Sessions and Connections . . . . . . . . . . 34 3.8. Terminating Sessions and Connections . . . . . . . . . . 33
4. The SMTP Specifications . . . . . . . . . . . . . . . . . . . 35 4. The SMTP Specifications . . . . . . . . . . . . . . . . . . . 34
4.1. SMTP Commands . . . . . . . . . . . . . . . . . . . . . . 35 4.1. SMTP Commands . . . . . . . . . . . . . . . . . . . . . . 34
4.1.1. Command Semantics and Syntax . . . . . . . . . . . . 35 4.1.1. Command Semantics and Syntax . . . . . . . . . . . . 34
4.1.1.1. Extended HELLO (EHLO) or HELLO (HELO) . . . . . . 36 4.1.1.1. Extended HELLO (EHLO) or HELLO (HELO) . . . . . . 35
4.1.1.2. MAIL (MAIL) . . . . . . . . . . . . . . . . . . . 37 4.1.1.2. MAIL (MAIL) . . . . . . . . . . . . . . . . . . . 37
4.1.1.3. RECIPIENT (RCPT) . . . . . . . . . . . . . . . . 38 4.1.1.3. RECIPIENT (RCPT) . . . . . . . . . . . . . . . . 37
4.1.1.4. DATA (DATA) . . . . . . . . . . . . . . . . . . . 40 4.1.1.4. DATA (DATA) . . . . . . . . . . . . . . . . . . . 39
4.1.1.5. RESET (RSET) . . . . . . . . . . . . . . . . . . 41 4.1.1.5. RESET (RSET) . . . . . . . . . . . . . . . . . . 40
4.1.1.6. VERIFY (VRFY) . . . . . . . . . . . . . . . . . . 42 4.1.1.6. VERIFY (VRFY) . . . . . . . . . . . . . . . . . . 41
4.1.1.7. EXPAND (EXPN) . . . . . . . . . . . . . . . . . . 42 4.1.1.7. EXPAND (EXPN) . . . . . . . . . . . . . . . . . . 41
4.1.1.8. HELP (HELP) . . . . . . . . . . . . . . . . . . . 42 4.1.1.8. HELP (HELP) . . . . . . . . . . . . . . . . . . . 41
4.1.1.9. NOOP (NOOP) . . . . . . . . . . . . . . . . . . . 43 4.1.1.9. NOOP (NOOP) . . . . . . . . . . . . . . . . . . . 42
4.1.1.10. QUIT (QUIT) . . . . . . . . . . . . . . . . . . . 43 4.1.1.10. QUIT (QUIT) . . . . . . . . . . . . . . . . . . . 42
4.1.2. Command Argument Syntax . . . . . . . . . . . . . . . 44 4.1.2. Command Argument Syntax . . . . . . . . . . . . . . . 43
4.1.3. Address Literals . . . . . . . . . . . . . . . . . . 46 4.1.3. Address Literals . . . . . . . . . . . . . . . . . . 45
4.1.4. Order of Commands . . . . . . . . . . . . . . . . . . 48 4.1.4. Order of Commands . . . . . . . . . . . . . . . . . . 47
4.2. SMTP Replies . . . . . . . . . . . . . . . . . . . . . . 50 4.2. SMTP Replies . . . . . . . . . . . . . . . . . . . . . . 49
4.2.1. Reply Code Severities and Theory . . . . . . . . . . 51 4.2.1. Reply Code Severities and Theory . . . . . . . . . . 50
4.2.2. Reply Codes by Function Groups . . . . . . . . . . . 54 4.2.2. Reply Codes by Function Groups . . . . . . . . . . . 53
4.2.3. Reply Codes in Numeric Order . . . . . . . . . . . . 55 4.2.3. Reply Codes in Numeric Order . . . . . . . . . . . . 54
4.2.4. Some specific code situations and relationships . . . 57 4.2.4. Some specific code situations and relationships . . . 56
4.3. Sequencing of Commands and Replies . . . . . . . . . . . 59 4.3. Sequencing of Commands and Replies . . . . . . . . . . . 57
4.3.1. Sequencing Overview . . . . . . . . . . . . . . . . . 59 4.3.1. Sequencing Overview . . . . . . . . . . . . . . . . . 58
4.3.2. Command-Reply Sequences . . . . . . . . . . . . . . . 60 4.3.2. Command-Reply Sequences . . . . . . . . . . . . . . . 58
4.4. Trace Information . . . . . . . . . . . . . . . . . . . . 62 4.4. Trace Information . . . . . . . . . . . . . . . . . . . . 61
4.4.1. Received Header Field . . . . . . . . . . . . . . . . 62 4.4.1. Received Header Field . . . . . . . . . . . . . . . . 61
4.5. Additional Implementation Issues . . . . . . . . . . . . 66 4.5. Additional Implementation Issues . . . . . . . . . . . . 65
4.5.1. Minimum Implementation . . . . . . . . . . . . . . . 66 4.5.1. Minimum Implementation . . . . . . . . . . . . . . . 65
4.5.2. Transparency . . . . . . . . . . . . . . . . . . . . 67 4.5.2. Transparency . . . . . . . . . . . . . . . . . . . . 65
4.5.3. Sizes and Timeouts . . . . . . . . . . . . . . . . . 68 4.5.3. Sizes and Timeouts . . . . . . . . . . . . . . . . . 66
4.5.3.1. Size Limits and Minimums . . . . . . . . . . . . 68 4.5.3.1. Size Limits and Minimums . . . . . . . . . . . . 66
4.5.3.1.1. Local-part . . . . . . . . . . . . . . . . . 68 4.5.3.1.1. Local-part . . . . . . . . . . . . . . . . . 66
4.5.3.1.2. Domain . . . . . . . . . . . . . . . . . . . 68 4.5.3.1.2. Domain . . . . . . . . . . . . . . . . . . . 67
4.5.3.1.3. Path . . . . . . . . . . . . . . . . . . . . 68 4.5.3.1.3. Path . . . . . . . . . . . . . . . . . . . . 67
4.5.3.1.4. Command Line . . . . . . . . . . . . . . . . 68 4.5.3.1.4. Command Line . . . . . . . . . . . . . . . . 67
4.5.3.1.5. Reply Line . . . . . . . . . . . . . . . . . 69 4.5.3.1.5. Reply Line . . . . . . . . . . . . . . . . . 67
4.5.3.1.6. Text Line . . . . . . . . . . . . . . . . . . 69 4.5.3.1.6. Text Line . . . . . . . . . . . . . . . . . . 67
4.5.3.1.7. Message Content . . . . . . . . . . . . . . . 69 4.5.3.1.7. Message Content . . . . . . . . . . . . . . . 67
4.5.3.1.8. Recipient Buffer . . . . . . . . . . . . . . 69 4.5.3.1.8. Recipient Buffer . . . . . . . . . . . . . . 67
4.5.3.1.9. Treatment When Limits Exceeded . . . . . . . 69 4.5.3.1.9. Treatment When Limits Exceeded . . . . . . . 68
4.5.3.1.10. Too Many Recipients Code . . . . . . . . . . 70 4.5.3.1.10. Too Many Recipients Code . . . . . . . . . . 68
4.5.3.2. Timeouts . . . . . . . . . . . . . . . . . . . . 71 4.5.3.2. Timeouts . . . . . . . . . . . . . . . . . . . . 69
4.5.3.2.1. Initial 220 Message: 5 Minutes . . . . . . . 71 4.5.3.2.1. Initial 220 Message: 5 Minutes . . . . . . . 69
4.5.3.2.2. MAIL Command: 5 Minutes . . . . . . . . . . . 71 4.5.3.2.2. MAIL Command: 5 Minutes . . . . . . . . . . . 69
4.5.3.2.3. RCPT Command: 5 Minutes . . . . . . . . . . . 71 4.5.3.2.3. RCPT Command: 5 Minutes . . . . . . . . . . . 69
4.5.3.2.4. DATA Initiation: 2 Minutes . . . . . . . . . 71 4.5.3.2.4. DATA Initiation: 2 Minutes . . . . . . . . . 69
4.5.3.2.5. Data Block: 3 Minutes . . . . . . . . . . . . 71 4.5.3.2.5. Data Block: 3 Minutes . . . . . . . . . . . . 69
4.5.3.2.6. DATA Termination: 10 Minutes. . . . . . . . . 71 4.5.3.2.6. DATA Termination: 10 Minutes. . . . . . . . . 70
4.5.3.2.7. Server Timeout: 5 Minutes. . . . . . . . . . 72 4.5.3.2.7. Server Timeout: 5 Minutes. . . . . . . . . . 70
4.5.4. Retry Strategies . . . . . . . . . . . . . . . . . . 72 4.5.4. Retry Strategies . . . . . . . . . . . . . . . . . . 70
4.5.5. Messages with a Null Reverse-Path . . . . . . . . . . 74 4.5.5. Messages with a Null Reverse-Path . . . . . . . . . . 72
5. Address Resolution and Mail Handling . . . . . . . . . . . . 74 5. Address Resolution and Mail Handling . . . . . . . . . . . . 73
5.1. Locating the Target Host . . . . . . . . . . . . . . . . 75 5.1. Locating the Target Host . . . . . . . . . . . . . . . . 73
5.2. IPv6 and MX Records . . . . . . . . . . . . . . . . . . . 77 5.2. IPv6 and MX Records . . . . . . . . . . . . . . . . . . . 75
6. Problem Detection and Handling . . . . . . . . . . . . . . . 77 6. Problem Detection and Handling . . . . . . . . . . . . . . . 75
6.1. Reliable Delivery and Replies by Email . . . . . . . . . 77 6.1. Reliable Delivery and Replies by Email . . . . . . . . . 76
6.2. Unwanted, Unsolicited, and "Attack" Messages . . . . . . 78 6.2. Unwanted, Unsolicited, and "Attack" Messages . . . . . . 76
6.3. Loop Detection . . . . . . . . . . . . . . . . . . . . . 79 6.3. Loop Detection . . . . . . . . . . . . . . . . . . . . . 77
6.4. Compensating for Irregularities . . . . . . . . . . . . . 79 6.4. Compensating for Irregularities . . . . . . . . . . . . . 77
7. Security Considerations . . . . . . . . . . . . . . . . . . . 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 79
7.1. Mail Security and Spoofing . . . . . . . . . . . . . . . 81 7.1. Mail Security and Spoofing . . . . . . . . . . . . . . . 79
7.2. "Blind" Copies . . . . . . . . . . . . . . . . . . . . . 82 7.2. "Blind" Copies . . . . . . . . . . . . . . . . . . . . . 80
7.3. VRFY, EXPN, and Security . . . . . . . . . . . . . . . . 83 7.3. VRFY, EXPN, and Security . . . . . . . . . . . . . . . . 81
7.4. Mail Rerouting Based on the 251 and 551 Response Codes . 83 7.4. Mail Rerouting Based on the 251 and 551 Response Codes . 81
7.5. Information Disclosure in Announcements . . . . . . . . . 84 7.5. Information Disclosure in Announcements . . . . . . . . . 82
7.6. Information Disclosure in Trace Fields . . . . . . . . . 84 7.6. Information Disclosure in Trace Fields . . . . . . . . . 82
7.7. Information Disclosure in Message Forwarding . . . . . . 84 7.7. Information Disclosure in Message Forwarding . . . . . . 82
7.8. Local Operational Requirements and Resistance to 7.8. Local Operational Requirements and Resistance to
Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 84 Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 82
7.9. Scope of Operation of SMTP Servers . . . . . . . . . . . 85 7.9. Scope of Operation of SMTP Servers . . . . . . . . . . . 83
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 83
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 86 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 84
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 87 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 85
10.1. Normative References . . . . . . . . . . . . . . . . . . 87 10.1. Normative References . . . . . . . . . . . . . . . . . . 85
10.2. Informative References . . . . . . . . . . . . . . . . . 88 10.2. Informative References . . . . . . . . . . . . . . . . . 86
Appendix A. TCP Transport Service . . . . . . . . . . . . . . . 92 Appendix A. TCP Transport Service . . . . . . . . . . . . . . . 90
Appendix B. Generating SMTP Commands from RFC 822 Header Appendix B. Generating SMTP Commands from RFC 822 Header
Fields . . . . . . . . . . . . . . . . . . . . . . . . . 92 Fields . . . . . . . . . . . . . . . . . . . . . . . . . 90
Appendix C. Placeholder (formerly Source Routes) . . . . . . . . 94 Appendix C. Placeholder (formerly Source Routes) . . . . . . . . 92
Appendix D. Scenarios . . . . . . . . . . . . . . . . . . . . . 94 Appendix D. Scenarios . . . . . . . . . . . . . . . . . . . . . 92
D.1. A Typical SMTP Transaction Scenario . . . . . . . . . . . 94 D.1. A Typical SMTP Transaction Scenario . . . . . . . . . . . 92
D.2. Aborted SMTP Transaction Scenario . . . . . . . . . . . . 94 D.2. Aborted SMTP Transaction Scenario . . . . . . . . . . . . 92
D.3. Relayed Mail Scenario . . . . . . . . . . . . . . . . . . 95 D.3. Relayed Mail Scenario . . . . . . . . . . . . . . . . . . 93
D.4. Verifying and Sending Scenario . . . . . . . . . . . . . 97 D.4. Verifying and Sending Scenario . . . . . . . . . . . . . 95
Appendix E. Other Gateway Issues . . . . . . . . . . . . . . . . 98 Appendix E. Other Gateway Issues . . . . . . . . . . . . . . . . 96
Appendix F. Deprecated Features of RFC 821 . . . . . . . . . . . 98 Appendix F. Deprecated Features of RFC 821 . . . . . . . . . . . 96
F.1. TURN . . . . . . . . . . . . . . . . . . . . . . . . . . 99 F.1. TURN . . . . . . . . . . . . . . . . . . . . . . . . . . 97
F.2. Source Routing . . . . . . . . . . . . . . . . . . . . . 99 F.2. Source Routing . . . . . . . . . . . . . . . . . . . . . 97
F.3. HELO . . . . . . . . . . . . . . . . . . . . . . . . . . 100 F.3. HELO . . . . . . . . . . . . . . . . . . . . . . . . . . 98
F.4. #-literals . . . . . . . . . . . . . . . . . . . . . . . 100 F.4. #-literals . . . . . . . . . . . . . . . . . . . . . . . 98
F.5. Dates and Years . . . . . . . . . . . . . . . . . . . . . 100 F.5. Dates and Years . . . . . . . . . . . . . . . . . . . . . 99
F.6. Sending versus Mailing . . . . . . . . . . . . . . . . . 101 F.6. Sending versus Mailing . . . . . . . . . . . . . . . . . 99
Appendix G. Other Outstanding Issues . . . . . . . . . . . . . . 101 Appendix G. Other Outstanding Issues . . . . . . . . . . . . . . 99
G.1. IP Address literals . . . . . . . . . . . . . . . . . . . 102 G.1. IP Address literals . . . . . . . . . . . . . . . . . . . 100
G.2. Repeated Use of EHLO (closed) . . . . . . . . . . . . . . 102 G.2. Repeated Use of EHLO (closed) . . . . . . . . . . . . . . 100
G.3. Meaning of "MTA" and Related Terminology . . . . . . . . 103 G.3. Meaning of "MTA" and Related Terminology . . . . . . . . 101
G.4. Originator, or Originating System, Authentication . . . . 103 G.4. Originator, or Originating System, Authentication . . . . 101
G.5. Remove or deprecate the work-around from code 552 to 452 G.5. Remove or deprecate the work-around from code 552 to 452
(closed) . . . . . . . . . . . . . . . . . . . . . . . . 103 (closed) . . . . . . . . . . . . . . . . . . . . . . . . 101
G.6. Clarify where the protocol stands with respect to G.6. Clarify where the protocol stands with respect to
submission and TLS issues . . . . . . . . . . . . . . . 103 submission and TLS issues . . . . . . . . . . . . . . . 101
G.7. Probably-substantive Discussion Topics Identified in Other G.7. Probably-substantive Discussion Topics Identified in Other
Ways . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Ways . . . . . . . . . . . . . . . . . . . . . . . . . . 102
G.7.1. Issues with 521, 554, and 556 codes (closed) . . . . 104 G.7.1. Issues with 521, 554, and 556 codes (closed) . . . . 102
G.7.2. SMTP Model, terminology, and relationship to RFC G.7.2. SMTP Model, terminology, and relationship to RFC
5598 . . . . . . . . . . . . . . . . . . . . . . . . 104 5598 . . . . . . . . . . . . . . . . . . . . . . . . 102
G.7.3. Resolvable FQDNs and private domain names . . . . . . 104 G.7.3. Resolvable FQDNs and private domain names . . . . . . 102
G.7.4. Possible clarification about mail transactions and G.7.4. Possible clarification about mail transactions and
transaction state . . . . . . . . . . . . . . . . . . 104 transaction state . . . . . . . . . . . . . . . . . . 102
G.7.5. Issues with mailing lists, aliases, and forwarding . 105 G.7.5. Issues with mailing lists, aliases, and forwarding . 103
G.7.6. Requirements for domain name and/or IP address in G.7.6. Requirements for domain name and/or IP address in
EHLO . . . . . . . . . . . . . . . . . . . . . . . . 105 EHLO . . . . . . . . . . . . . . . . . . . . . . . . 103
G.7.7. Does the 'first digit only' and/or non-listed reply G.7.7. Does the 'first digit only' and/or non-listed reply
code text need clarification? (closed) . . . . . . . 105 code text need clarification? (closed) . . . . . . . 103
G.7.8. Size limits (closed) . . . . . . . . . . . . . . . . 105 G.7.8. Size limits (closed) . . . . . . . . . . . . . . . . 103
G.7.9. Discussion of 'blind' copies and RCPT . . . . . . . . 105 G.7.9. Discussion of 'blind' copies and RCPT . . . . . . . . 103
G.7.10. Further clarifications needed to source routes? . . . 106 G.7.10. Further clarifications needed to source routes? . . . 104
G.7.11. Should 1yz Be Revisited? (closed) . . . . . . . . . . 106 G.7.11. Should 1yz Be Revisited? (closed) . . . . . . . . . . 104
G.7.12. Review Timeout Specifications . . . . . . . . . . . . 106 G.7.12. Review Timeout Specifications . . . . . . . . . . . . 104
G.7.13. Possible SEND, SAML, SOML Loose End (closed) . . . . 106 G.7.13. Possible SEND, SAML, SOML Loose End (closed) . . . . 104
G.7.14. Abstract Update (closed) . . . . . . . . . . . . . . 106 G.7.14. Abstract Update (closed) . . . . . . . . . . . . . . 104
G.7.15. Informative References to MIME and/or Message G.7.15. Informative References to MIME and/or Message
Submission (closed) . . . . . . . . . . . . . . . . . 106 Submission (closed) . . . . . . . . . . . . . . . . . 104
G.7.16. Mail Transaction Discussion . . . . . . . . . . . . . 107 G.7.16. Mail Transaction Discussion . . . . . . . . . . . . . 105
G.7.17. Hop by hop Authentication and/or Encryption G.7.17. Hop by hop Authentication and/or Encryption
(closed) . . . . . . . . . . . . . . . . . . . . . . 107 (closed) . . . . . . . . . . . . . . . . . . . . . . 105
G.7.18. More Text About 554 Given 521, etc. . . . . . . . . . 107 G.7.18. More Text About 554 Given 521, etc. . . . . . . . . . 105
G.7.19. Minimum Lengths and Quantities . . . . . . . . . . . 107 G.7.19. Minimum Lengths and Quantities . . . . . . . . . . . 105
G.8. Enhanced Reply Codes and DSNs . . . . . . . . . . . . . . 107 G.8. Enhanced Reply Codes and DSNs . . . . . . . . . . . . . . 105
G.9. Revisiting Quoted Strings . . . . . . . . . . . . . . . . 108 G.9. Revisiting Quoted Strings . . . . . . . . . . . . . . . . 106
G.10. Internationalization . . . . . . . . . . . . . . . . . . 108 G.10. Internationalization . . . . . . . . . . . . . . . . . . 106
G.11. SMTP Clients, Servers, Senders, and Receivers . . . . . . 109 G.11. SMTP Clients, Servers, Senders, and Receivers . . . . . . 107
G.12. Extension Keywords Starting in 'X-' (closed) . . . . . . 109 G.12. Extension Keywords Starting in 'X-' (closed) . . . . . . 107
G.13. Deprecating HELO (closed) . . . . . . . . . . . . . . . . 109 G.13. Deprecating HELO (closed) . . . . . . . . . . . . . . . . 107
G.14. The FOR Clause in Trace Fields: Semantics, Security G.14. The FOR Clause in Trace Fields: Semantics, Security
Considerations, and Other Issues . . . . . . . . . . . . 110 Considerations, and Other Issues . . . . . . . . . . . . 108
G.15. Resistance to Attacks and Operational Necessity G.15. Resistance to Attacks and Operational Necessity
(closed) . . . . . . . . . . . . . . . . . . . . . . . . 110 (closed) . . . . . . . . . . . . . . . . . . . . . . . . 108
G.16. Mandatory 8BITMIME . . . . . . . . . . . . . . . . . . . 111 G.16. Mandatory 8BITMIME . . . . . . . . . . . . . . . . . . . 109
Appendix H. RFC 5321 Errata Summary and Tentative Change Log . . 111 Appendix H. RFC 5321 Errata Summary and Tentative Change Log . . 109
H.1. RFC 5321 Errata Summary . . . . . . . . . . . . . . . . . 111 H.1. RFC 5321 Errata Summary . . . . . . . . . . . . . . . . . 109
H.2. Changes from RFC 5321 (published October 2008) to the H.2. Changes from RFC 5321 (published October 2008) to the
initial (-00) version of this draft . . . . . . . . . . . 113 initial (-00) version of this draft . . . . . . . . . . . 111
H.3. Changes Among Versions of Rfc5321bis . . . . . . . . . . 114 H.3. Changes Among Versions of Rfc5321bis . . . . . . . . . . 112
H.3.1. Changes from draft-klensin-rfc5321bis-00 (posted H.3.1. Changes from draft-klensin-rfc5321bis-00 (posted
2012-12-02) to -01 . . . . . . . . . . . . . . . . . 114 2012-12-02) to -01 . . . . . . . . . . . . . . . . . 113
H.3.2. Changes from draft-klensin-rfc5321bis-01 (20191203) to H.3.2. Changes from draft-klensin-rfc5321bis-01 (20191203) to
-02 . . . . . . . . . . . . . . . . . . . . . . . . . 114 -02 . . . . . . . . . . . . . . . . . . . . . . . . . 113
H.3.3. Changes from draft-klensin-rfc5321bis-02 (2019-12-27) H.3.3. Changes from draft-klensin-rfc5321bis-02 (2019-12-27)
to -03 . . . . . . . . . . . . . . . . . . . . . . . 115 to -03 . . . . . . . . . . . . . . . . . . . . . . . 113
H.3.4. Changes from draft-klensin-rfc5321bis-03 (2020-07-02) H.3.4. Changes from draft-klensin-rfc5321bis-03 (2020-07-02)
to draft-ietf-emailcore-rfc5321bis-00 . . . . . . . . 115 to draft-ietf-emailcore-rfc5321bis-00 . . . . . . . . 113
H.3.5. Changes from draft-ietf-emailcore-rfc5321bis-00 H.3.5. Changes from draft-ietf-emailcore-rfc5321bis-00
(2020-10-06) to -01 . . . . . . . . . . . . . . . . . 115 (2020-10-06) to -01 . . . . . . . . . . . . . . . . . 114
H.3.6. Changes from draft-ietf-emailcore-rfc5321bis-01 H.3.6. Changes from draft-ietf-emailcore-rfc5321bis-01
(2020-12-25) to -02 . . . . . . . . . . . . . . . . . 116 (2020-12-25) to -02 . . . . . . . . . . . . . . . . . 114
H.3.7. Changes from draft-ietf-emailcore-rfc5321bis-02 H.3.7. Changes from draft-ietf-emailcore-rfc5321bis-02
(2021-02-21) to -03 . . . . . . . . . . . . . . . . . 116 (2021-02-21) to -03 . . . . . . . . . . . . . . . . . 115
H.3.8. Changes from draft-ietf-emailcore-rfc5321bis-03 H.3.8. Changes from draft-ietf-emailcore-rfc5321bis-03
(2021-07-10) to -04 . . . . . . . . . . . . . . . . . 118 (2021-07-10) to -04 . . . . . . . . . . . . . . . . . 116
H.3.9. Changes from draft-ietf-emailcore-rfc5321bis-04 H.3.9. Changes from draft-ietf-emailcore-rfc5321bis-04
(2021-10-03) to -05 . . . . . . . . . . . . . . . . . 118 (2021-10-03) to -05 . . . . . . . . . . . . . . . . . 117
H.3.10. Changes from draft-ietf-emailcore-rfc5321bis-05 H.3.10. Changes from draft-ietf-emailcore-rfc5321bis-05
(2021-10-24) to -06 . . . . . . . . . . . . . . . . . 119 (2021-10-24) to -06 . . . . . . . . . . . . . . . . . 117
H.3.11. Changes from draft-ietf-emailcore-rfc5321bis-06 H.3.11. Changes from draft-ietf-emailcore-rfc5321bis-06
(2021-11-07) to -07 . . . . . . . . . . . . . . . . . 120 (2021-11-07) to -07 . . . . . . . . . . . . . . . . . 118
H.3.12. Changes from draft-ietf-emailcore-rfc5321bis-07 H.3.12. Changes from draft-ietf-emailcore-rfc5321bis-07
(2021-12-04) to -08 . . . . . . . . . . . . . . . . . 120 (2021-12-04) to -08 . . . . . . . . . . . . . . . . . 119
H.3.13. Changes from draft-ietf-emailcore-rfc5321bis-08
(2021-12-31) to -09 . . . . . . . . . . . . . . . . . 120
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 123 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 123
1. Introduction 1. Introduction
1.1. Transport of Electronic Mail 1.1. Transport of Electronic Mail
The objective of the Simple Mail Transfer Protocol (SMTP) is to The objective of the Simple Mail Transfer Protocol (SMTP) is to
transfer mail reliably and efficiently. transfer mail reliably and efficiently.
skipping to change at page 9, line 28 skipping to change at page 9, line 28
Because this document has a long history and to avoid the risk of Because this document has a long history and to avoid the risk of
various errors and of confusing readers and documents that point to various errors and of confusing readers and documents that point to
this one, most examples and the domain names they contain are this one, most examples and the domain names they contain are
preserved from RFC 2821. Readers are cautioned that these are preserved from RFC 2821. Readers are cautioned that these are
illustrative examples that should not actually be used in either code illustrative examples that should not actually be used in either code
or configuration files. or configuration files.
2. The SMTP Model 2. The SMTP Model
// [5321bis] [[Editor's Note: There have been extensive and repeated
// discussions on the SMTP and IETF lists about whether this document
// should say something about hop-by-hop (MTA-to-MTA) SMTP
// authentication and, if so, what?? Note that end to end message
// authentication is almost certainly out of scope for SMTP.]] Cf.
// Appendix G.7.17
2.1. Basic Structure 2.1. Basic Structure
The SMTP design can be pictured as: The SMTP design can be pictured as:
+----------+ +----------+ +----------+ +----------+
+------+ | | | | +------+ | | | |
| User |<-->| | SMTP | | | User |<-->| | SMTP | |
+------+ | Client- |Commands/Replies| Server- | +------+ | Client- |Commands/Replies| Server- |
+------+ | SMTP |<-------------->| SMTP | +------+ +------+ | SMTP |<-------------->| SMTP | +------+
| File |<-->| | and Mail | |<-->| File | | File |<-->| | and Mail | |<-->| File |
skipping to change at page 16, line 14 skipping to change at page 16, line 14
The domain name, as described in this document and in RFC 1035 [4], The domain name, as described in this document and in RFC 1035 [4],
MUST be the entire, fully-qualified name (often referred to as an MUST be the entire, fully-qualified name (often referred to as an
"FQDN"). Other than an address literal (see Section 4.1.3) where "FQDN"). Other than an address literal (see Section 4.1.3) where
those are permitted, any string that is not a domain name in FQDN those are permitted, any string that is not a domain name in FQDN
form is no more than a reference to be interpreted locally. Such form is no more than a reference to be interpreted locally. Such
local references for domain names MUST NOT appear in any SMTP local references for domain names MUST NOT appear in any SMTP
transaction (Cf. Section 5). Mechanisms for inferring FQDNs from transaction (Cf. Section 5). Mechanisms for inferring FQDNs from
local references (including partial names or local aliases) are local references (including partial names or local aliases) are
outside of this specification and normally the province of message outside of this specification and normally the province of message
submission. Due to a history of problems, SMTP servers used for submission. Due to a history of problems, SMTP servers SHOULD NOT
initial submission of messages SHOULD NOT make such inferences make such inferences (Message Submission Servers [41] have somewhat
(Message Submission Servers [41] have somewhat more flexibility) and more flexibility) and intermediate (relay) SMTP servers MUST NOT make
intermediate (relay) SMTP servers MUST NOT make them. them.
// [rfc5321 Editor's Note 20211231] The sentence starting with
// "Mechanisms" and the one immediately following it above moved from
// Section 5.1, but perhaps they should be dropped entirely and/or
// elaborated on in the A/S.
When domain names are used in SMTP, and unless further restricted in When domain names are used in SMTP, and unless further restricted in
this document, names that can be resolved to MX RRs or address (i.e., this document, names that can be resolved to MX RRs or address (i.e.,
A or AAAA) RRs (as discussed in Section 5) are permitted, as are A or AAAA) RRs (as discussed in Section 5) are permitted, as are
CNAME RRs whose targets can be resolved, in turn, to MX or address CNAME RRs whose targets can be resolved, in turn, to MX or address
RRs. There are two exceptions to the rule requiring FQDNs: RRs. There are two exceptions to the rule requiring FQDNs:
* The domain name given in the EHLO command MUST be either a primary * The domain name given in the EHLO command MUST be either a primary
host name (a domain name that resolves to an address RR) or, if host name (a domain name that resolves to an address RR) or, if
the host has no name, an address literal, as described in the host has no name, an address literal, as described in
Section 4.1.3 and discussed further in the EHLO discussion of Section 4.1.3 and discussed further in the EHLO discussion of
Section 4.1.4. Section 4.1.4.
* The reserved mailbox name "postmaster" may be used in a RCPT * The reserved mailbox name "postmaster" MAY be used in a RCPT
command without domain qualification (see Section 4.1.1.3) and command without domain qualification (see Section 4.1.1.3) and
MUST be accepted if so used. MUST be accepted if so used.
2.3.6. Buffer and State Table 2.3.6. Buffer and State Table
SMTP sessions are stateful, with both parties carefully maintaining a SMTP sessions are stateful, with both parties carefully maintaining a
common view of the current state. In this document, we model this common view of the current state. In this document, we model this
state by a virtual "buffer" and a "state table" on the server that state by a virtual "buffer" and a "state table" on the server that
may be used by the client to, for example, "clear the buffer" or may be used by the client to, for example, "clear the buffer" or
"reset the state table", causing the information in the buffer to be "reset the state table", causing the information in the buffer to be
skipping to change at page 18, line 29 skipping to change at page 18, line 15
A "gateway" SMTP system (usually referred to just as a "gateway") A "gateway" SMTP system (usually referred to just as a "gateway")
receives mail from a client system in one transport environment and receives mail from a client system in one transport environment and
transmits it to a server system in another transport environment. transmits it to a server system in another transport environment.
Differences in protocols or message semantics between the transport Differences in protocols or message semantics between the transport
environments on either side of a gateway may require that the gateway environments on either side of a gateway may require that the gateway
system perform transformations to the message that are not permitted system perform transformations to the message that are not permitted
to SMTP relay systems. For the purposes of this specification, to SMTP relay systems. For the purposes of this specification,
firewalls that rewrite addresses should be considered as gateways, firewalls that rewrite addresses should be considered as gateways,
even if SMTP is used on both sides of them (see RFC 2979 [32]). even if SMTP is used on both sides of them (see RFC 2979 [32]).
// [5321bis] [[Note in draft/Placeholder: There has been a request to
// expand this section, possibly into a more extensive model of
// Internet mail. Comments from others solicited. In particular,
// does RFC 5598 make that suggestion OBE?]]
2.3.11. Mailbox and Address 2.3.11. Mailbox and Address
As used in this specification, an "address" is a character string As used in this specification, an "address" is a character string
that identifies a user to whom mail will be sent or a location into that identifies a user to whom mail will be sent or a location into
which mail will be deposited. The term "mailbox" refers to that which mail will be deposited. The term "mailbox" refers to that
depository. The two terms are typically used interchangeably unless depository. The two terms are typically used interchangeably unless
the distinction between the location in which mail is placed (the the distinction between the location in which mail is placed (the
mailbox) and a reference to it (the address) is important. An mailbox) and a reference to it (the address) is important. An
address normally consists of user and domain specifications. The address normally consists of user and domain specifications. The
skipping to change at page 25, line 42 skipping to change at page 25, line 23
address information or even return that information to the user. address information or even return that information to the user.
SMTP server implementations that support the 251 and/or 551 reply SMTP server implementations that support the 251 and/or 551 reply
codes SHOULD provide configuration mechanisms so that sites that codes SHOULD provide configuration mechanisms so that sites that
conclude that they would undesirably disclose information can disable conclude that they would undesirably disclose information can disable
or restrict their use. See Section 7.4 for further discussion of or restrict their use. See Section 7.4 for further discussion of
that issue. that issue.
3.4.2. Aliases and Mailing Lists 3.4.2. Aliases and Mailing Lists
// [5321bis] If "alias and list models" are explained elsewhere, Many SMTP-capable hosts support address expansion for multiple
// cross reference. Also note that this section appears to prohibit delivery via one or both of the alias and the list models. When a
// an exploder from adding List-* headers. That needs to be explicit message is delivered or forwarded to each address of an expanded list
// or finessed. form, the return address in the envelope ("MAIL FROM:") MUST be
An SMTP-capable host SHOULD support both the alias and the list changed to be the address of a person or other entity who administers
models of address expansion for multiple delivery. When a message is the list. However, in this case, the message header section (RFC
delivered or forwarded to each address of an expanded list form, the 5322 [12]) MUST be left unchanged; in particular, the "From" field of
return address in the envelope ("MAIL FROM:") MUST be changed to be the header section is unaffected.
the address of a person or other entity who administers the list.
However, in this case, the message header section (RFC 5322 [12]) // Editor's Note (temporary, 2022-01-21): Discussion durng the
MUST be left unchanged; in particular, the "From" field of the header // Interim Meeting this date indicated that the above sentence should
section is unaffected. // be removed. See mailing list.
An important mail facility is a mechanism for multi-destination An important mail facility is a mechanism for multi-destination
delivery of a single message, by transforming (or "expanding" or delivery of a single message, by transforming (or "expanding" or
"exploding") a pseudo-mailbox address into a list of destination "exploding") a pseudo-mailbox address into a list of destination
mailbox addresses. When a message is sent to such a pseudo-mailbox mailbox addresses. When a message is sent to such a pseudo-mailbox
(sometimes called an "exploder"), copies are forwarded or (sometimes called an "exploder"), copies are forwarded or
redistributed to each mailbox in the expanded list. Servers SHOULD redistributed to each mailbox in the expanded list. Servers SHOULD
simply utilize the addresses on the list; application of heuristics simply utilize the addresses on the list; application of heuristics
or other matching rules to eliminate some addresses, such as that of or other matching rules to eliminate some addresses, such as that of
the originator, is strongly discouraged. We classify such a pseudo- the originator, is strongly discouraged. We classify such a pseudo-
skipping to change at page 38, line 36 skipping to change at page 37, line 48
This command is used to identify an individual recipient of the mail This command is used to identify an individual recipient of the mail
data; multiple recipients are specified by multiple uses of this data; multiple recipients are specified by multiple uses of this
command. The argument clause contains a forward-path and may contain command. The argument clause contains a forward-path and may contain
optional parameters. optional parameters.
The forward-path consists of the required destination mailbox. When The forward-path consists of the required destination mailbox. When
mail reaches its ultimate destination, the SMTP server inserts it mail reaches its ultimate destination, the SMTP server inserts it
into the destination mailbox in accordance with its host mail into the destination mailbox in accordance with its host mail
conventions. conventions.
// JcK 20211128: above is new text in rfc5321bis-07, per notes from
// Alexey and Ned, replacing the two paragraphs and text about source
// routes that used to appear here. However, I'm a little concerned
// about "ultimate destination" as used here. The earlier text was
// about source routes and that term was defined as "the forward-path
// contains only a destination mailbox)". But, without that context
// and discussions about MDAs and what they might do, I am not sure I
// know what the term means or if it is appropriate to talk about
// SMTP servers inserting things in mailboxes if we can avoid it.
// (JcK 20211214) Following significantly rewritten for rfc5321bis-
// 08.
Prior versions of the SMTP specification included text and examples Prior versions of the SMTP specification included text and examples
in this section of use of the deprecated source route construct. If in this section of use of the deprecated source route construct. If
desired, see Appendix F.2 for discussion of that mechanism. desired, see Appendix F.2 for discussion of that mechanism.
This command appends its forward-path argument to the forward-path This command appends its forward-path argument to the forward-path
buffer; it does not change the reverse-path buffer nor the mail data buffer; it does not change the reverse-path buffer nor the mail data
buffer. buffer.
For example, mail received at relay host xyz.com with envelope For example, mail received at relay host xyz.com with envelope
commands commands
skipping to change at page 39, line 31 skipping to change at page 38, line 27
by the address record if there are no MX records). It will use by the address record if there are no MX records). It will use
envelope commands identical to the above, i.e., envelope commands identical to the above, i.e.,
MAIL FROM:<userx@y.foo.org> MAIL FROM:<userx@y.foo.org>
RCPT TO:<userc@d.bar.org> RCPT TO:<userc@d.bar.org>
Since hosts are not required to relay mail at all, xyz.com MAY also Since hosts are not required to relay mail at all, xyz.com MAY also
reject the message entirely when the RCPT command is received, using reject the message entirely when the RCPT command is received, using
a 550 code (since this is a "policy reason"). a 550 code (since this is a "policy reason").
If the SMTP server determines that a message sent to the mailbox in
the forward-path is not deliverable, it MUST either return an
appropriate response code (see Section 4.2.2) or generate a non-
delivery notification.
// Editor's Note: Following text moved from Section 4.4.1, per 2021
// November discussion, and rewritten slightly (in -09). With the
// current structure of the document, this seemed the least-bad place
// to put it. Other plausible alternatives would be to put a "Non-
// delivery Notifications" section into either Section 3 or
// Section 6.
If there were multiple failed recipients, either a single
notification listing all of the failed recipients or separate
notification messages MUST be sent for each failed recipient. For
economy of processing by the sender, the former SHOULD be used when
possible. All notification messages about undeliverable mail MUST be
sent using the MAIL command and MUST use a null return path as
discussed in Section 3.6.
If service extensions were negotiated, the RCPT command may also If service extensions were negotiated, the RCPT command may also
carry parameters associated with a particular service extension carry parameters associated with a particular service extension
offered by the server. The client MUST NOT transmit parameters other offered by the server. The client MUST NOT transmit parameters other
than those associated with a service extension offered by the server than those associated with a service extension offered by the server
in its EHLO response. in its EHLO response.
Syntax: Syntax:
rcpt = "RCPT TO:" ( "<Postmaster@" Domain ">" / "<Postmaster>" / rcpt = "RCPT TO:" ( "<Postmaster@" Domain ">" / "<Postmaster>" /
Forward-path ) [SP Rcpt-parameters] CRLF Forward-path ) [SP Rcpt-parameters] CRLF
skipping to change at page 45, line 47 skipping to change at page 44, line 40
; graphic (including itself) or SPace ; graphic (including itself) or SPace
qtextSMTP = %d32-33 / %d35-91 / %d93-126 qtextSMTP = %d32-33 / %d35-91 / %d93-126
; i.e., within a quoted string, any ; i.e., within a quoted string, any
; ASCII graphic or space is permitted ; ASCII graphic or space is permitted
; without backslash-quoting except ; without backslash-quoting except
; double-quote and the backslash itself. ; double-quote and the backslash itself.
String = Atom / Quoted-string String = Atom / Quoted-string
// JcK 20211128: Following two paragraphs reordered and text added to
// the (now) second one with statements about equivalence and
// examples. I proposed to drop "semantically" entirely from the
// description if there are no objections.
Note that the backslash, "\", is a quote character, which is used to Note that the backslash, "\", is a quote character, which is used to
indicate that the next character is to be used literally (instead of indicate that the next character is to be used literally (instead of
its normal interpretation). For example, "Joe\,Smith" indicates a its normal interpretation). For example, "Joe\,Smith" indicates a
single nine-character user name string with the comma being the single nine-character user name string with the comma being the
fourth character of that string. fourth character of that string.
While the above definition for Local-part is relatively permissive, While the above definition for Local-part is relatively permissive,
for maximum interoperability, a mailbox SHOULD NOT be defined with for maximum interoperability, a mailbox SHOULD NOT be defined with
Local-part requiring (or using) the Quoted-string form or with the Local-part requiring (or using) the Quoted-string form or with the
Local-part being case-sensitive. Further, when comparing a Local- Local-part being case-sensitive. Further, when comparing a Local-
skipping to change at page 49, line 33 skipping to change at page 48, line 33
command MUST clearly document any effect it has on the transaction command MUST clearly document any effect it has on the transaction
state. state.
There may be zero or more transactions in a session. MAIL MUST NOT There may be zero or more transactions in a session. MAIL MUST NOT
be sent if a mail transaction is already open, i.e., it should be be sent if a mail transaction is already open, i.e., it should be
sent only if no mail transaction had been started in the session, or sent only if no mail transaction had been started in the session, or
if the previous one successfully concluded with a successful DATA if the previous one successfully concluded with a successful DATA
command, or if the previous one was aborted, e.g., with a RSET or new command, or if the previous one was aborted, e.g., with a RSET or new
EHLO. EHLO.
// [5321bis] See comment about changing this convoluted discussion to // [5321bis] See comment about changing this convoluted discussion to
// talk about 'mail transaction' above. --Jck (and see Ticket #11 // talk about 'mail transaction' above. --JcK (and see Ticket #11
// correspondence with Alexey 2021-07-06) // correspondence with Alexey 2021-07-06)
If the transaction beginning command argument is not acceptable, a If the transaction beginning command argument is not acceptable, a
501 failure reply MUST be returned and the SMTP server MUST stay in 501 failure reply MUST be returned and the SMTP server MUST stay in
the same state. If the commands in a transaction are out of order to the same state. If the commands in a transaction are out of order to
the degree that they cannot be processed by the server, a 503 failure the degree that they cannot be processed by the server, a 503 failure
reply MUST be returned and the SMTP server MUST stay in the same reply MUST be returned and the SMTP server MUST stay in the same
state. state.
The last command in a session MUST be the QUIT command. The QUIT The last command in a session MUST be the QUIT command. The QUIT
skipping to change at page 55, line 31 skipping to change at page 54, line 31
553 Requested action not taken: mailbox name not allowed (e.g., 553 Requested action not taken: mailbox name not allowed (e.g.,
mailbox syntax incorrect) mailbox syntax incorrect)
354 Start mail input; end with <CRLF>.<CRLF> 354 Start mail input; end with <CRLF>.<CRLF>
554 Transaction failed (Or, historically in the case of a 554 Transaction failed (Or, historically in the case of a
connection-opening response, "No SMTP service here". 521 is now connection-opening response, "No SMTP service here". 521 is now
preferred for that function at connection-opening if the server preferred for that function at connection-opening if the server
never accepts mail.) never accepts mail.)
// [5321bis] [[Note in Draft: Revise above statement in the light
of
// new 521 code?? -- revised with rfc5321bis-04]]
4.2.3. Reply Codes in Numeric Order 4.2.3. Reply Codes in Numeric Order
211 System status, or system help reply 211 System status, or system help reply
214 Help message (Information on how to use the receiver or the 214 Help message (Information on how to use the receiver or the
meaning of a particular non-standard command; this reply is useful meaning of a particular non-standard command; this reply is useful
only to the human user) only to the human user)
220 <domain> Service ready 220 <domain> Service ready
skipping to change at page 65, line 5 skipping to change at page 63, line 36
The server must give special treatment to cases in which the The server must give special treatment to cases in which the
processing following the end of mail data indication is only processing following the end of mail data indication is only
partially successful. This could happen if, after accepting several partially successful. This could happen if, after accepting several
recipients and the mail data, the SMTP server finds that the mail recipients and the mail data, the SMTP server finds that the mail
data could be successfully delivered to some, but not all, of the data could be successfully delivered to some, but not all, of the
recipients. In such cases, the response to the DATA command MUST be recipients. In such cases, the response to the DATA command MUST be
an OK reply. However, the SMTP server MUST compose and send an an OK reply. However, the SMTP server MUST compose and send an
"undeliverable mail" notification message to the originator of the "undeliverable mail" notification message to the originator of the
message. message.
// [JcK/Alexey 20211104] The following paragraph does not seem to
// belong in this section. Where should it be moved?
A single notification listing all of the failed recipients or
separate notification messages MUST be sent for each failed
recipient. For economy of processing by the sender, the former
SHOULD be used when possible. All notification messages about
undeliverable mail MUST be sent using the MAIL command and MUST use a
null return path as discussed in Section 3.6.
The time stamp line and the return path line are formally defined as The time stamp line and the return path line are formally defined as
follows (the definitions for "FWS" and "CFWS" appear in RFC 5322 follows (the definitions for "FWS" and "CFWS" appear in RFC 5322
[12]): [12]):
Return-path-line = "Return-Path:" FWS Reverse-path <CRLF> Return-path-line = "Return-Path:" FWS Reverse-path <CRLF>
Time-stamp-line = "Received:" FWS Stamp <CRLF> Time-stamp-line = "Received:" FWS Stamp <CRLF>
Stamp = From-domain By-domain Opt-info [CFWS] ";" Stamp = From-domain By-domain Opt-info [CFWS] ";"
FWS date-time FWS date-time
skipping to change at page 68, line 24 skipping to change at page 66, line 47
Clients MAY attempt to transmit these, but MUST be prepared for a Clients MAY attempt to transmit these, but MUST be prepared for a
server to reject them if they cannot be handled by it. To the server to reject them if they cannot be handled by it. To the
maximum extent possible, implementation techniques that impose no maximum extent possible, implementation techniques that impose no
limits on the length of these objects should be used. limits on the length of these objects should be used.
Extensions to SMTP may involve the use of characters that occupy more Extensions to SMTP may involve the use of characters that occupy more
than a single octet each. This section therefore specifies lengths than a single octet each. This section therefore specifies lengths
in octets where absolute lengths, rather than character counts, are in octets where absolute lengths, rather than character counts, are
intended. intended.
// [5321bis] [[Note in Draft: Klensin 20191126: Given the controversy
// on the SMTP mailing list between 20191123 and now about maximum
// lengths, is the above adequate or is further tuning of the limit
// text below needed?
4.5.3.1.1. Local-part 4.5.3.1.1. Local-part
The maximum total length of a user name or other local-part is 64 The maximum total length of a user name or other local-part is 64
octets. octets.
4.5.3.1.2. Domain 4.5.3.1.2. Domain
The maximum total length of a domain name or number is 255 octets. The maximum total length of a domain name or number is 255 octets.
4.5.3.1.3. Path 4.5.3.1.3. Path
skipping to change at page 76, line 9 skipping to change at page 74, line 5
If one or more MX RRs are found for a given name, SMTP systems MUST If one or more MX RRs are found for a given name, SMTP systems MUST
NOT utilize any address RRs associated with that name unless they are NOT utilize any address RRs associated with that name unless they are
located using the MX RRs; the "implicit MX" rule above applies only located using the MX RRs; the "implicit MX" rule above applies only
if there are no MX records present. If MX records are present, but if there are no MX records present. If MX records are present, but
none of them are usable, this situation MUST be reported as an error. none of them are usable, this situation MUST be reported as an error.
When a domain name associated with an MX RR is looked up and the When a domain name associated with an MX RR is looked up and the
associated data field obtained, the data field of that response MUST associated data field obtained, the data field of that response MUST
contain a domain name that conforms to the specifications of contain a domain name that conforms to the specifications of
Section 2.3.5. Section 2.3.5.
[[5321bis Editor's Note: Depending on how the "null MX" discussion
unfolds, some additional text may be in order here (20140718)]] // [[5321bis Editor's Note: Depending on how the "null MX" discussion
// unfolds, some additional text may be in order here (20140718)]]
That domain name, when queried, MUST return at least one address That domain name, when queried, MUST return at least one address
record (e.g., A or AAAA RR) that gives the IP address of the SMTP record (e.g., A or AAAA RR) that gives the IP address of the SMTP
server to which the message should be directed. Any other response, server to which the message should be directed. Any other response,
specifically including a value that will return a CNAME record when specifically including a value that will return a CNAME record when
queried, lies outside the scope of this Standard. The prohibition on queried, lies outside the scope of this Standard. The prohibition on
labels in the data that resolve to CNAMEs is discussed in more detail labels in the data that resolve to CNAMEs is discussed in more detail
in RFC 2181, Section 10.3 [28]. in RFC 2181, Section 10.3 [28].
Two types of information are used to rank the host addresses: Two types of information are used to rank the host addresses:
multiple MX records, and multihomed hosts. multiple MX records, and multihomed hosts.
skipping to change at page 99, line 41 skipping to change at page 97, line 41
reject them. reject them.
Historically, for relay purposes, the forward-path may have been a Historically, for relay purposes, the forward-path may have been a
source route of the form "@ONE,@TWO:JOE@THREE", where ONE, TWO, and source route of the form "@ONE,@TWO:JOE@THREE", where ONE, TWO, and
THREE MUST be fully-qualified domain names. This form was used to THREE MUST be fully-qualified domain names. This form was used to
emphasize the distinction between an address and a route. The emphasize the distinction between an address and a route. The
mailbox (here, JOE@THREE) is an absolute address, and the route is mailbox (here, JOE@THREE) is an absolute address, and the route is
information about how to get there. The two concepts should not be information about how to get there. The two concepts should not be
confused. confused.
SMTP servers SHOULD continue to accept source route syntax as SMTP servers MAY continue to accept source route syntax as specified
specified in this appendix. If they do so, they SHOULD ignore the in this appendix. If they do so, they SHOULD ignore the routes and
routes and utilize only the target domain in the address. If they do utilize only the target domain in the address. If they do utilize
utilize the source route, the message MUST be sent to the first the source route, the message MUST be sent to the first domain shown
domain shown in the address. In particular, a server MUST NOT guess in the address.
at shortcuts within the source route. SMTP clients SHOULD NOT
attempt to utilize explicit source routing. In particular, a server MUST NOT guess at shortcuts within the source
route.
SMTP clients MUST NOT attempt to utilize explicit source routing.
If source routes appear in mail received by an SMTP server contrary If source routes appear in mail received by an SMTP server contrary
to the requirements and recommendations in this specification, RFC to the requirements and recommendations in this specification, RFC
821 and the text below should be consulted for the mechanisms for 821 and the text below should be consulted for the mechanisms for
constructing and updating the forward-path. A server that is reached constructing and updating the forward-path. A server that is reached
by means of a source route (e.g., its domain name appears first in by means of a source route (e.g., its domain name appears first in
the list in the forward-path) MUST remove its domain name from any the list in the forward-path) MUST remove its domain name from any
forward-paths in which that domain name appears before forwarding the forward-paths in which that domain name appears before forwarding the
message and MAY remove all other source routing information. Any message and MAY remove all other source routing information. Any
source route information in the reverse-path SHOULD be removed by source route information in the reverse-path SHOULD be removed by
servers conforming to this specification. servers conforming to this specification.
The following information is provided for historical information The following information is provided for historical information so
only, so that the source route syntax and application can be that the source route syntax and application can be understood if
understood if needed. needed.
Syntax: Syntax:
The original form of the <Path> production in Section 4.1.2 was: The original form of the <Path> production in Section 4.1.2 was:
Path = "<" [ A-d-l ":" ] Mailbox ">" Path = "<" [ A-d-l ":" ] Mailbox ">"
A-d-l = At-domain *( "," At-domain ) A-d-l = At-domain *( "," At-domain )
At-domain = "@" Domain At-domain = "@" Domain
skipping to change at page 104, line 4 skipping to change at page 101, line 49
Ticket #5 (fixed and closed). Ticket #5 (fixed and closed).
SHOULD requirement removed. SHOULD requirement removed.
G.6. Clarify where the protocol stands with respect to submission and G.6. Clarify where the protocol stands with respect to submission and
TLS issues TLS issues
1. submission on port 587 1. submission on port 587
2. submission on port 465 2. submission on port 465
3. TLS relay on a port different from 25 (whenever)
3. TLS relay on a port different from 25 (whenever)
4. Recommendations about general use of transport layer (hop by hop) 4. Recommendations about general use of transport layer (hop by hop)
security, particularly encryption including consideration of RFC security, particularly encryption including consideration of RFC
8314. 8314.
G.7. Probably-substantive Discussion Topics Identified in Other Ways G.7. Probably-substantive Discussion Topics Identified in Other Ways
The following issues were identified as a group in the opening Note The following issues were identified as a group in the opening Note
but called out specifically only in embedded CREF comments in but called out specifically only in embedded CREF comments in
versions of this draft prior to the first EMAILCORE version. versions of this draft prior to the first EMAILCORE version.
skipping to change at page 104, line 36 skipping to change at page 102, line 34
G.7.2. SMTP Model, terminology, and relationship to RFC 5598 G.7.2. SMTP Model, terminology, and relationship to RFC 5598
CREF comment in Section 2, CREF comment in Section 2.3.10, and CREF comment in Section 2, CREF comment in Section 2.3.10, and
comments in the introductory portion of Appendix G. comments in the introductory portion of Appendix G.
G.7.3. Resolvable FQDNs and private domain names G.7.3. Resolvable FQDNs and private domain names
Multiple CREF comments in Section 2.3.5 Multiple CREF comments in Section 2.3.5
Tickets #9 (definition of domain name), #10 (meaning of "resolvable Tickets #9 (definition of domain name), #10 (meaning of "resolvable
domain name"), and #41 (closed -- no change 2021-04-05). domain name"; closed 2021-06-12), and #41 (closed -- no change
2021-04-05).
G.7.4. Possible clarification about mail transactions and transaction G.7.4. Possible clarification about mail transactions and transaction
state state
CREF comment in Section 3.3 and also reference in Section 4.1.4 CREF comment in Section 3.3 and also reference in Section 4.1.4
Ticket #11. Ticket #11.
// See correspondence on this ticket 2021-07-06 through 2021-07-09. // See correspondence on this ticket 2021-07-06 through 2021-07-09.
G.7.5. Issues with mailing lists, aliases, and forwarding G.7.5. Issues with mailing lists, aliases, and forwarding
skipping to change at page 105, line 21 skipping to change at page 103, line 21
as Section 3.4.1 to avoid introducing inconsistencies. In addition, as Section 3.4.1 to avoid introducing inconsistencies. In addition,
there are some terminology issues about the use of the term "lists", there are some terminology issues about the use of the term "lists",
identified in erratum 1820, that should be reviewed after any more identified in erratum 1820, that should be reviewed after any more
substantive changes are made to the relevant sections. substantive changes are made to the relevant sections.
Ticket #12 and Ticket #34 (Ticket #34/ erratum 1820 resolved in -06 Ticket #12 and Ticket #34 (Ticket #34/ erratum 1820 resolved in -06
and closed). and closed).
G.7.6. Requirements for domain name and/or IP address in EHLO G.7.6. Requirements for domain name and/or IP address in EHLO
Text in Section 4.1.4; change made in -05. Text in Section 4.1.4; change made in -05.
Ticket #19. Ticket #19 (was ticket #47 -- done in rfc5321bis, more in A/S).
G.7.7. Does the 'first digit only' and/or non-listed reply code text G.7.7. Does the 'first digit only' and/or non-listed reply code text
need clarification? (closed) need clarification? (closed)
Resolved. Text in Section 4.2 changed 2021-02-08 and CREF comment in Resolved. Text in Section 4.2 changed 2021-02-08 and CREF comment in
Section 4.3.1 removed. Section 4.3.1 removed.
Perhaps unresolved -- ongoing discussion on mailing list after IETF Perhaps unresolved -- ongoing discussion on mailing list after IETF
110. 110.
Ticket #13 (fixed and closed). Ticket #13 (fixed and closed).
skipping to change at page 106, line 8 skipping to change at page 104, line 8
G.7.9. Discussion of 'blind' copies and RCPT G.7.9. Discussion of 'blind' copies and RCPT
CREF comment in Section 7.2. May also need to discussion whether CREF comment in Section 7.2. May also need to discussion whether
that terminology is politically incorrect and suggest a replacement. that terminology is politically incorrect and suggest a replacement.
Ticket #15. Ticket #15.
G.7.10. Further clarifications needed to source routes? G.7.10. Further clarifications needed to source routes?
The current text largely deprecates the use of source routes but The current text largely deprecates the use of source routes but
suggests that servers continue to support them. Is additional work suggests that servers continue to support them.
needed in this area? See CREF comment in Appendix F.2 Ticket #17 (Closed 20220125).
Ticket #17.
G.7.11. Should 1yz Be Revisited? (closed) G.7.11. Should 1yz Be Revisited? (closed)
RFC 5321 depreciated the "positive preliminary reply" response code RFC 5321 depreciated the "positive preliminary reply" response code
category with first digit "1", so that the first digit of valid SMTP category with first digit "1", so that the first digit of valid SMTP
response codes must be 2, 3, 4, or 5. It has been suggested (see response codes must be 2, 3, 4, or 5. It has been suggested (see
mail from Hector Santos with Subject "SMTP Reply code 1yz Positive mail from Hector Santos with Subject "SMTP Reply code 1yz Positive
Preliminary reply", March 5, 2020 12:56 -0500, on the SMTP list) that Preliminary reply", March 5, 2020 12:56 -0500, on the SMTP list) that
these codes should be reinstated to deal with some situations that these codes should be reinstated to deal with some situations that
became more plausible after 5321 was published. Do we need to take became more plausible after 5321 was published. Do we need to take
this back up? this up again?
Ticket #18 (no, closed). Ticket #18 (no, closed).
G.7.12. Review Timeout Specifications G.7.12. Review Timeout Specifications
RFC 5321 (and its predecessors going back to 821) specify minimum RFC 5321 (and its predecessors going back to 821) specify minimum
periods for client and server to wait before timing out. Are those periods for client and server to wait before timing out. Are those
intervals still appropriate in a world of faster processors and intervals still appropriate in a world of faster processors and
faster networks? Should they be updated and revised? Or should more faster networks? Should they be updated and revised? Or should more
qualifying language be added? qualifying language be added?
Ticket #16. Ticket #16.
skipping to change at page 107, line 14 skipping to change at page 105, line 14
G.7.16. Mail Transaction Discussion G.7.16. Mail Transaction Discussion
Does the discussion of mail transactions need more work (see CREF in Does the discussion of mail transactions need more work (see CREF in
Section 3.3.)? Section 3.3.)?
G.7.17. Hop by hop Authentication and/or Encryption (closed) G.7.17. Hop by hop Authentication and/or Encryption (closed)
Should this document discuss hop-by-hop authentication or, for that Should this document discuss hop-by-hop authentication or, for that
matter, encryption? (See CREF in Section 2.) matter, encryption? (See CREF in Section 2.)
Propose "No, it shouldn't" (20211101 conversation with Todd.) Propose "No, it shouldn't" (20211101 conversation with Todd,
reaffirmed 20220121 plenary)
Ticket #50 (work with in A/S. Closed). Ticket #50 (work with in A/S. Closed).
G.7.18. More Text About 554 Given 521, etc. G.7.18. More Text About 554 Given 521, etc.
Does reply code 554 need additional or different explanation in the Does reply code 554 need additional or different explanation in the
light of the addition of the new 521 code and/or the new (in 5321bis light of the addition of the new 521 code and/or the new (in 5321bis
Section 4.2.4.2? (See CREF in Section 4.2.3.) Section 4.2.4.2? (See CREF in Section 4.2.3.)
G.7.19. Minimum Lengths and Quantities G.7.19. Minimum Lengths and Quantities
skipping to change at page 113, line 27 skipping to change at page 111, line 27
Ticket #30 (resolved and closed). Ticket #30 (resolved and closed).
// [5321bis]Note that rejected errata have _not_ been reviewed to see // [5321bis]Note that rejected errata have _not_ been reviewed to see
// if they contain anything useful that should be discussed again // if they contain anything useful that should be discussed again
// with the possibility of rethinking and changing text. Volunteers // with the possibility of rethinking and changing text. Volunteers
// sought. // sought.
H.2. Changes from RFC 5321 (published October 2008) to the initial H.2. Changes from RFC 5321 (published October 2008) to the initial
(-00) version of this draft (-00) version of this draft
// This appendix will eventually need to be replaced by a real
// section or standalone appendix describing changes between 5321 and
// the final 5321bis.
* Acknowledgments section (Section 9) trimmed back for new document. * Acknowledgments section (Section 9) trimmed back for new document.
* Introductory paragraph to Appendix F extended to make it clear * Introductory paragraph to Appendix F extended to make it clear
that these features were deprecated a long time ago and really that these features were deprecated a long time ago and really
should not be in use any more. should not be in use any more.
* Adjusted some language to clarify that source routes really, * Adjusted some language to clarify that source routes really,
really, should not be used or depended upon. really, should not be used or depended upon.
* IPv6 address syntax replaced by a copy of the IPv6 URI syntax and * IPv6 address syntax replaced by a copy of the IPv6 URI syntax and
skipping to change at page 114, line 6 skipping to change at page 112, line 11
* Clarified the relationship between the SMTP "letters, digits, and * Clarified the relationship between the SMTP "letters, digits, and
hyphens" and DNS "preferred name syntax" (Section 2.3.5). hyphens" and DNS "preferred name syntax" (Section 2.3.5).
* Revised the reply code sections to add new 521 and 556 codes, * Revised the reply code sections to add new 521 and 556 codes,
clarify relationships, and be explicit about the requirement for clarify relationships, and be explicit about the requirement for
clients to rely on first digits rather than the sequences in clients to rely on first digits rather than the sequences in
Section 4.3.2. Section 4.3.2.
* In conjunction with the above, explicitly obsolete RFCs 1846 and * In conjunction with the above, explicitly obsolete RFCs 1846 and
7504 (but that might not be right -- see email 2021-10-03. 7504
// That might not be right -- see email 2021-10-03).
* Incorporated a correction reflecting Errata ID 2578. * Incorporated a correction reflecting Errata ID 2578.
* Some small editorial changes made to eliminate redundant * Some small editorial changes made to eliminate redundant
statements that were very close together. Other, equally small, statements that were very close together. Other, equally small,
editorial changes have been made to improve grammar or clarity. editorial changes have been made to improve grammar or clarity.
* A few questions, marked "[[5321bis Editor's Note:", or "[[Note in * A few questions, marked "[[5321bis Editor's Note:", or "[[Note in
Draft" have been added for the group to resolve. Other questions, Draft" have been added for the group to resolve. Other questions,
especially those in the errata summary, are simply included in especially those in the errata summary, are simply included in
skipping to change at page 121, line 37 skipping to change at page 120, line 10
considerations from the new Section 3.4.1. considerations from the new Section 3.4.1.
All other issues discussed during the interim appear to be unresolved All other issues discussed during the interim appear to be unresolved
and were deferred to the mailing list. and were deferred to the mailing list.
As what should be the third and final step in deprecation of source As what should be the third and final step in deprecation of source
routes and removal of them from the main text, the appendix that routes and removal of them from the main text, the appendix that
discusses them (Appendix F.2) has been rewritten, adjusting language discusses them (Appendix F.2) has been rewritten, adjusting language
and incorporating some materials from the former Appendix C. and incorporating some materials from the former Appendix C.
H.3.13. Changes from draft-ietf-emailcore-rfc5321bis-08 (2021-12-31) to
-09
* Multiple small editorial changes.
* Started tuning Appendix H.2 preparatory to an actual "Changes
from" section.
* Moved and rewrote a paragraph that seemed to be out of place from
Section 4.4.1 to Section 4.1.1.3 per November discussion. See the
note in the latter section for discussion.
* Removed "for initial submission of messages" from Section 2.3.5
and changed "may" to "MAY" in the last bullet point there, per
Interim. Removed comment/ Editor's Note from that section:
further instructions and evidence of consensus needed to do
anything additional with it.
Ticket #9
* In Section 3.4.2, rewrote the first sentence to make it
descriptive rather than normative. Also removed the last sentence
of that paragraph. Both per the editor's understanding of the
Interim's conclusions, but the latter was put in because of
problems with people thinking changing the argument to the MAIL
command also required changing "From:" in the headers, so this
should be carefully reviewed on list. Comment removed from that
section -- the dead horse has been kicked past recognition.
Ticket #4.
* In Appendix F.2, changed the requirement for server support to
MAY, and prohibited client support, for source routing. Also made
a small wording change. Per Interim.
Ticket #17
With this draft, comments in the running text ("//" at the beginning
of lines) that seem to no longer be relevant either generally or
after the discussions during the 2022-01-21 Interim are being
removed. The "Notes on Reading..." at the beginning of the document
(just below the Abstract) have been revised accordingly. Sections
from which comments were removed this time include:
* Abstract, comment introduced in -06 (No comments on it through -08
are interpreted as consent;
* Section 2 (any discussion needed will be in A/S);
* Section 2.3.10 (discussion seems to have ended);
* Section 4.1.1.3 (no further discussion during Interim, so assume
comment is no longer needed);
* Section 4.1.2 (no further discussion since -08 appeared or during
Interim, assumed to not require further work);
* Section 4.5.3.1 (further discussion will be in A/S);
* Section 4.2.2 (this comment obsolete since revision -04 of this
document).
* Cross-checked ticket notes and annotations in this document
against the ticket system. Consistent for closed tickets as of
2022-01-31.
Index Index
A C S A C S
A A
Argument Syntax Argument Syntax
ALPHA Section 4.1.2, Paragraph 2, Item 1 ALPHA Section 4.1.2, Paragraph 2, Item 1
Additional-Registered-Clauses Section 4.4.1 Additional-Registered-Clauses Section 4.4.1
Addtl-Link Section 4.4.1 Addtl-Link Section 4.4.1
skipping to change at page 123, line 22 skipping to change at page 123, line 8
Command Syntax Command Syntax
data Section 4.1.1.4, Paragraph 8, Item 1 data Section 4.1.1.4, Paragraph 8, Item 1
ehlo Section 3.2, Paragraph 1; Section 4.1.1.1, Paragraph 1 ehlo Section 3.2, Paragraph 1; Section 4.1.1.1, Paragraph 1
expn Section 4.1.1.7, Paragraph 4, Item 1 expn Section 4.1.1.7, Paragraph 4, Item 1
helo Section 4.1.1.1, Paragraph 1 helo Section 4.1.1.1, Paragraph 1
help Section 4.1.1.8, Paragraph 5, Item 1 help Section 4.1.1.8, Paragraph 5, Item 1
mail Section 4.1.1.2 mail Section 4.1.1.2
noop Section 4.1.1.9, Paragraph 4, Item 1 noop Section 4.1.1.9, Paragraph 4, Item 1
quit Section 4.1.1.10, Paragraph 5, Item 1 quit Section 4.1.1.10, Paragraph 5, Item 1
rcpt Section 4.1.1.3, Paragraph 15 rcpt Section 4.1.1.3, Paragraph 16
rset Section 4.1.1.5, Paragraph 4, Item 1 rset Section 4.1.1.5, Paragraph 4, Item 1
send, saml, soml Appendix G.7.13, Paragraph 1 send, saml, soml Appendix G.7.13, Paragraph 1
vrfy Section 4.1.1.6, Paragraph 4, Item 1 vrfy Section 4.1.1.6, Paragraph 4, Item 1
S S
Source Routes Appendix F.2 Source Routes Appendix F.2
A-d-l Appendix F.2 A-d-l Appendix F.2
At-domain Appendix F.2 At-domain Appendix F.2
Path Appendix F.2 Path Appendix F.2
 End of changes. 73 change blocks. 
270 lines changed or deleted 315 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/