< draft-ietf-emailcore-rfc5321bis-06.txt   draft-ietf-emailcore-rfc5321bis-07.txt >
EMAILCORE J. Klensin EMAILCORE J. Klensin
Internet-Draft 8 November 2021 Internet-Draft 4 December 2021
Obsoletes: 5321, 1846, 7504, 7505 (if approved) Obsoletes: 5321, 1846, 7504, 7505 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: 12 May 2022 Expires: 7 June 2022
Simple Mail Transfer Protocol Simple Mail Transfer Protocol
draft-ietf-emailcore-rfc5321bis-06 draft-ietf-emailcore-rfc5321bis-07
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 consolidates, updates, and clarifies electronic mail transport. It consolidates, updates, and clarifies
several previous documents, making all or parts of most of them several previous documents, making all or parts of most of them
obsolete. It covers the SMTP extension mechanisms and best practices obsolete. It covers the SMTP extension mechanisms and best practices
for the contemporary Internet, but does not provide details about for the contemporary Internet, but does not provide details about
particular extensions. The document also provides information about particular extensions. The document also provides information about
use of SMTP for other than strict mail transport and delivery. This use of SMTP for other than strict mail transport and delivery. This
skipping to change at page 2, line 15 skipping to change at page 2, line 15
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 12 May 2022. This Internet-Draft will expire on 7 June 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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
skipping to change at page 3, line 18 skipping to change at page 3, line 18
3.1. Session Initiation . . . . . . . . . . . . . . . . . . . 20 3.1. Session Initiation . . . . . . . . . . . . . . . . . . . 20
3.2. Client Initiation . . . . . . . . . . . . . . . . . . . . 21 3.2. Client Initiation . . . . . . . . . . . . . . . . . . . . 21
3.3. Mail Transactions . . . . . . . . . . . . . . . . . . . . 21 3.3. Mail Transactions . . . . . . . . . . . . . . . . . . . . 21
3.4. Forwarding for Address Correction or Updating . . . . . . 24 3.4. Forwarding for Address Correction or Updating . . . . . . 24
3.5. Commands for Debugging Addresses . . . . . . . . . . . . 25 3.5. Commands for Debugging Addresses . . . . . . . . . . . . 25
3.5.1. Overview . . . . . . . . . . . . . . . . . . . . . . 25 3.5.1. Overview . . . . . . . . . . . . . . . . . . . . . . 25
3.5.2. VRFY Normal Response . . . . . . . . . . . . . . . . 27 3.5.2. VRFY Normal Response . . . . . . . . . . . . . . . . 27
3.5.3. Meaning of VRFY or EXPN Success Response . . . . . . 28 3.5.3. Meaning of VRFY or EXPN Success Response . . . . . . 28
3.5.4. Semantics and Applications of EXPN . . . . . . . . . 28 3.5.4. Semantics and Applications of EXPN . . . . . . . . . 28
3.6. Relaying and Mail Routing . . . . . . . . . . . . . . . . 29 3.6. Relaying and Mail Routing . . . . . . . . . . . . . . . . 29
3.6.1. Source Routes and Relaying . . . . . . . . . . . . . 29 3.6.1. Mail eXchange Records and Relaying . . . . . . . . . 29
3.6.2. Mail eXchange Records and Relaying . . . . . . . . . 29 3.6.2. Message Submission Servers as Relays . . . . . . . . 29
3.6.3. Message Submission Servers as Relays . . . . . . . . 30 3.7. Mail Gatewaying . . . . . . . . . . . . . . . . . . . . . 30
3.7. Mail Gatewaying . . . . . . . . . . . . . . . . . . . . . 31
3.7.1. Header Fields in Gatewaying . . . . . . . . . . . . . 31 3.7.1. Header Fields in Gatewaying . . . . . . . . . . . . . 31
3.7.2. Received Lines in Gatewaying . . . . . . . . . . . . 31 3.7.2. Received Lines in Gatewaying . . . . . . . . . . . . 31
3.7.3. Addresses in Gatewaying . . . . . . . . . . . . . . . 32 3.7.3. Addresses in Gatewaying . . . . . . . . . . . . . . . 31
3.7.4. Other Header Fields in Gatewaying . . . . . . . . . . 32 3.7.4. Other Header Fields in Gatewaying . . . . . . . . . . 32
3.7.5. Envelopes in Gatewaying . . . . . . . . . . . . . . . 32 3.7.5. Envelopes in Gatewaying . . . . . . . . . . . . . . . 32
3.8. Terminating Sessions and Connections . . . . . . . . . . 33 3.8. Terminating Sessions and Connections . . . . . . . . . . 32
3.9. Aliases and Mailing Lists . . . . . . . . . . . . . . . . 34 3.9. Aliases and Mailing Lists . . . . . . . . . . . . . . . . 33
3.9.1. Simple Aliases . . . . . . . . . . . . . . . . . . . 34 3.9.1. Simple Aliases . . . . . . . . . . . . . . . . . . . 34
3.9.2. Mailing Lists . . . . . . . . . . . . . . . . . . . . 34 3.9.2. Mailing Lists . . . . . . . . . . . . . . . . . . . . 34
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 . . . . . . . . . . . . 35
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) . . . . . . . . . . . . . . . . . . . 39 4.1.1.4. DATA (DATA) . . . . . . . . . . . . . . . . . . . 39
4.1.1.5. RESET (RSET) . . . . . . . . . . . . . . . . . . 41 4.1.1.5. RESET (RSET) . . . . . . . . . . . . . . . . . . 41
4.1.1.6. VERIFY (VRFY) . . . . . . . . . . . . . . . . . . 41 4.1.1.6. VERIFY (VRFY) . . . . . . . . . . . . . . . . . . 41
4.1.1.7. EXPAND (EXPN) . . . . . . . . . . . . . . . . . . 41 4.1.1.7. EXPAND (EXPN) . . . . . . . . . . . . . . . . . . 41
4.1.1.8. HELP (HELP) . . . . . . . . . . . . . . . . . . . 42 4.1.1.8. HELP (HELP) . . . . . . . . . . . . . . . . . . . 42
4.1.1.9. NOOP (NOOP) . . . . . . . . . . . . . . . . . . . 42 4.1.1.9. NOOP (NOOP) . . . . . . . . . . . . . . . . . . . 42
4.1.1.10. QUIT (QUIT) . . . . . . . . . . . . . . . . . . . 42 4.1.1.10. QUIT (QUIT) . . . . . . . . . . . . . . . . . . . 42
4.1.2. Command Argument Syntax . . . . . . . . . . . . . . . 43 4.1.2. Command Argument Syntax . . . . . . . . . . . . . . . 43
4.1.3. Address Literals . . . . . . . . . . . . . . . . . . 45 4.1.3. Address Literals . . . . . . . . . . . . . . . . . . 46
4.1.4. Order of Commands . . . . . . . . . . . . . . . . . . 47 4.1.4. Order of Commands . . . . . . . . . . . . . . . . . . 47
4.2. SMTP Replies . . . . . . . . . . . . . . . . . . . . . . 49 4.2. SMTP Replies . . . . . . . . . . . . . . . . . . . . . . 49
4.2.1. Reply Code Severities and Theory . . . . . . . . . . 50 4.2.1. Reply Code Severities and Theory . . . . . . . . . . 51
4.2.2. Reply Codes by Function Groups . . . . . . . . . . . 53 4.2.2. Reply Codes by Function Groups . . . . . . . . . . . 53
4.2.3. Reply Codes in Numeric Order . . . . . . . . . . . . 54 4.2.3. Reply Codes in Numeric Order . . . . . . . . . . . . 55
4.2.4. Some specific code situations and relationships . . . 56 4.2.4. Some specific code situations and relationships . . . 56
4.3. Sequencing of Commands and Replies . . . . . . . . . . . 58
4.3. Sequencing of Commands and Replies . . . . . . . . . . . 57
4.3.1. Sequencing Overview . . . . . . . . . . . . . . . . . 58 4.3.1. Sequencing Overview . . . . . . . . . . . . . . . . . 58
4.3.2. Command-Reply Sequences . . . . . . . . . . . . . . . 58 4.3.2. Command-Reply Sequences . . . . . . . . . . . . . . . 59
4.4. Trace Information . . . . . . . . . . . . . . . . . . . . 61 4.4. Trace Information . . . . . . . . . . . . . . . . . . . . 61
4.4.1. Received Header Field . . . . . . . . . . . . . . . . 61 4.4.1. Received Header Field . . . . . . . . . . . . . . . . 61
4.5. Additional Implementation Issues . . . . . . . . . . . . 65 4.5. Additional Implementation Issues . . . . . . . . . . . . 65
4.5.1. Minimum Implementation . . . . . . . . . . . . . . . 65 4.5.1. Minimum Implementation . . . . . . . . . . . . . . . 65
4.5.2. Transparency . . . . . . . . . . . . . . . . . . . . 66 4.5.2. Transparency . . . . . . . . . . . . . . . . . . . . 66
4.5.3. Sizes and Timeouts . . . . . . . . . . . . . . . . . 66 4.5.3. Sizes and Timeouts . . . . . . . . . . . . . . . . . 67
4.5.3.1. Size Limits and Minimums . . . . . . . . . . . . 66 4.5.3.1. Size Limits and Minimums . . . . . . . . . . . . 67
4.5.3.1.1. Local-part . . . . . . . . . . . . . . . . . 67 4.5.3.1.1. Local-part . . . . . . . . . . . . . . . . . 67
4.5.3.1.2. Domain . . . . . . . . . . . . . . . . . . . 67 4.5.3.1.2. Domain . . . . . . . . . . . . . . . . . . . 68
4.5.3.1.3. Path . . . . . . . . . . . . . . . . . . . . 67 4.5.3.1.3. Path . . . . . . . . . . . . . . . . . . . . 68
4.5.3.1.4. Command Line . . . . . . . . . . . . . . . . 67 4.5.3.1.4. Command Line . . . . . . . . . . . . . . . . 68
4.5.3.1.5. Reply Line . . . . . . . . . . . . . . . . . 67 4.5.3.1.5. Reply Line . . . . . . . . . . . . . . . . . 68
4.5.3.1.6. Text Line . . . . . . . . . . . . . . . . . . 67 4.5.3.1.6. Text Line . . . . . . . . . . . . . . . . . . 68
4.5.3.1.7. Message Content . . . . . . . . . . . . . . . 68 4.5.3.1.7. Message Content . . . . . . . . . . . . . . . 68
4.5.3.1.8. Recipient Buffer . . . . . . . . . . . . . . 68 4.5.3.1.8. Recipient Buffer . . . . . . . . . . . . . . 68
4.5.3.1.9. Treatment When Limits Exceeded . . . . . . . 68 4.5.3.1.9. Treatment When Limits Exceeded . . . . . . . 69
4.5.3.1.10. Too Many Recipients Code . . . . . . . . . . 69 4.5.3.1.10. Too Many Recipients Code . . . . . . . . . . 69
4.5.3.2. Timeouts . . . . . . . . . . . . . . . . . . . . 69 4.5.3.2. Timeouts . . . . . . . . . . . . . . . . . . . . 70
4.5.3.2.1. Initial 220 Message: 5 Minutes . . . . . . . 70 4.5.3.2.1. Initial 220 Message: 5 Minutes . . . . . . . 70
4.5.3.2.2. MAIL Command: 5 Minutes . . . . . . . . . . . 70 4.5.3.2.2. MAIL Command: 5 Minutes . . . . . . . . . . . 70
4.5.3.2.3. RCPT Command: 5 Minutes . . . . . . . . . . . 70 4.5.3.2.3. RCPT Command: 5 Minutes . . . . . . . . . . . 70
4.5.3.2.4. DATA Initiation: 2 Minutes . . . . . . . . . 70 4.5.3.2.4. DATA Initiation: 2 Minutes . . . . . . . . . 70
4.5.3.2.5. Data Block: 3 Minutes . . . . . . . . . . . . 70 4.5.3.2.5. Data Block: 3 Minutes . . . . . . . . . . . . 70
4.5.3.2.6. DATA Termination: 10 Minutes. . . . . . . . . 70 4.5.3.2.6. DATA Termination: 10 Minutes. . . . . . . . . 71
4.5.3.2.7. Server Timeout: 5 Minutes. . . . . . . . . . 70 4.5.3.2.7. Server Timeout: 5 Minutes. . . . . . . . . . 71
4.5.4. Retry Strategies . . . . . . . . . . . . . . . . . . 70 4.5.4. Retry Strategies . . . . . . . . . . . . . . . . . . 71
4.5.5. Messages with a Null Reverse-Path . . . . . . . . . . 73 4.5.5. Messages with a Null Reverse-Path . . . . . . . . . . 73
5. Address Resolution and Mail Handling . . . . . . . . . . . . 73 5. Address Resolution and Mail Handling . . . . . . . . . . . . 74
5.1. Locating the Target Host . . . . . . . . . . . . . . . . 73 5.1. Locating the Target Host . . . . . . . . . . . . . . . . 74
5.2. IPv6 and MX Records . . . . . . . . . . . . . . . . . . . 75 5.2. IPv6 and MX Records . . . . . . . . . . . . . . . . . . . 76
6. Problem Detection and Handling . . . . . . . . . . . . . . . 76 6. Problem Detection and Handling . . . . . . . . . . . . . . . 76
6.1. Reliable Delivery and Replies by Email . . . . . . . . . 76 6.1. Reliable Delivery and Replies by Email . . . . . . . . . 77
6.2. Unwanted, Unsolicited, and "Attack" Messages . . . . . . 77 6.2. Unwanted, Unsolicited, and "Attack" Messages . . . . . . 77
6.3. Loop Detection . . . . . . . . . . . . . . . . . . . . . 78 6.3. Loop Detection . . . . . . . . . . . . . . . . . . . . . 78
6.4. Compensating for Irregularities . . . . . . . . . . . . . 78 6.4. Compensating for Irregularities . . . . . . . . . . . . . 78
7. Security Considerations . . . . . . . . . . . . . . . . . . . 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 80
7.1. Mail Security and Spoofing . . . . . . . . . . . . . . . 80 7.1. Mail Security and Spoofing . . . . . . . . . . . . . . . 80
7.2. "Blind" Copies . . . . . . . . . . . . . . . . . . . . . 81 7.2. "Blind" Copies . . . . . . . . . . . . . . . . . . . . . 81
7.3. VRFY, EXPN, and Security . . . . . . . . . . . . . . . . 81 7.3. VRFY, EXPN, and Security . . . . . . . . . . . . . . . . 81
7.4. Mail Rerouting Based on the 251 and 551 Response Codes . 82 7.4. Mail Rerouting Based on the 251 and 551 Response Codes . 82
7.5. Information Disclosure in Announcements . . . . . . . . . 82 7.5. Information Disclosure in Announcements . . . . . . . . . 82
7.6. Information Disclosure in Trace Fields . . . . . . . . . 83 7.6. Information Disclosure in Trace Fields . . . . . . . . . 83
7.7. Information Disclosure in Message Forwarding . . . . . . 83 7.7. Information Disclosure in Message Forwarding . . . . . . 83
7.8. Local Operational Requirement and Resistance to 7.8. Local Operational Requirements and Resistance to
Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 83 Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 83
7.9. Scope of Operation of SMTP Servers . . . . . . . . . . . 84
7.9. Scope of Operation of SMTP Servers . . . . . . . . . . . 83
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 84 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 84
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 85 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 85
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 86 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 86
10.1. Normative References . . . . . . . . . . . . . . . . . . 86 10.1. Normative References . . . . . . . . . . . . . . . . . . 86
10.2. Informative References . . . . . . . . . . . . . . . . . 87 10.2. Informative References . . . . . . . . . . . . . . . . . 87
Appendix A. TCP Transport Service . . . . . . . . . . . . . . . 91 Appendix A. TCP Transport Service . . . . . . . . . . . . . . . 91
Appendix B. Generating SMTP Commands from RFC 822 Header Appendix B. Generating SMTP Commands from RFC 822 Header
Fields . . . . . . . . . . . . . . . . . . . . . . . . . 91 Fields . . . . . . . . . . . . . . . . . . . . . . . . . 92
Appendix C. Source Routes . . . . . . . . . . . . . . . . . . . 93 Appendix C. Source Routes . . . . . . . . . . . . . . . . . . . 93
Appendix D. Scenarios . . . . . . . . . . . . . . . . . . . . . 94 Appendix D. Scenarios . . . . . . . . . . . . . . . . . . . . . 93
D.1. A Typical SMTP Transaction Scenario . . . . . . . . . . . 94 D.1. A Typical SMTP Transaction Scenario . . . . . . . . . . . 93
D.2. Aborted SMTP Transaction Scenario . . . . . . . . . . . . 95 D.2. Aborted SMTP Transaction Scenario . . . . . . . . . . . . 94
D.3. Relayed Mail Scenario . . . . . . . . . . . . . . . . . . 95 D.3. Relayed Mail Scenario . . . . . . . . . . . . . . . . . . 94
D.4. Verifying and Sending Scenario . . . . . . . . . . . . . 97 D.4. Verifying and Sending Scenario . . . . . . . . . . . . . 96
Appendix E. Other Gateway Issues . . . . . . . . . . . . . . . . 98 Appendix E. Other Gateway Issues . . . . . . . . . . . . . . . . 97
Appendix F. Deprecated Features of RFC 821 . . . . . . . . . . . 98 Appendix F. Deprecated Features of RFC 821 . . . . . . . . . . . 97
F.1. TURN . . . . . . . . . . . . . . . . . . . . . . . . . . 99 F.1. TURN . . . . . . . . . . . . . . . . . . . . . . . . . . 98
F.2. Source Routing . . . . . . . . . . . . . . . . . . . . . 99 F.2. Source Routing . . . . . . . . . . . . . . . . . . . . . 98
F.3. HELO . . . . . . . . . . . . . . . . . . . . . . . . . . 99 F.3. HELO . . . . . . . . . . . . . . . . . . . . . . . . . . 98
F.4. #-literals . . . . . . . . . . . . . . . . . . . . . . . 99 F.4. #-literals . . . . . . . . . . . . . . . . . . . . . . . 98
F.5. Dates and Years . . . . . . . . . . . . . . . . . . . . . 100 F.5. Dates and Years . . . . . . . . . . . . . . . . . . . . . 99
F.6. Sending versus Mailing . . . . . . . . . . . . . . . . . 100 F.6. Sending versus Mailing . . . . . . . . . . . . . . . . . 99
Appendix G. Other Outstanding Issues . . . . . . . . . . . . . . 100 Appendix G. Other Outstanding Issues . . . . . . . . . . . . . . 99
G.1. IP Address literals . . . . . . . . . . . . . . . . . . . 101 G.1. IP Address literals . . . . . . . . . . . . . . . . . . . 100
G.2. Repeated Use of EHLO . . . . . . . . . . . . . . . . . . 101 G.2. Repeated Use of EHLO (closed) . . . . . . . . . . . . . . 100
G.3. Meaning of "MTA" and Related Terminology . . . . . . . . 102 G.3. Meaning of "MTA" and Related Terminology . . . . . . . . 101
G.4. Originator, or Originating System, Authentication . . . . 102 G.4. Originator, or Originating System, Authentication . . . . 101
G.5. Remove or deprecate the work-around from code 552 to G.5. Remove or deprecate the work-around from code 552 to 452
452 . . . . . . . . . . . . . . . . . . . . . . . . . . 102 (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 . . . . . . . . . . . . . . . 102 submission and TLS issues . . . . . . . . . . . . . . . 101
G.7. Probably-substantive Discussion Topics Identified in Other G.7. Probably-substantive Discussion Topics Identified in Other
Ways . . . . . . . . . . . . . . . . . . . . . . . . . . 103 Ways . . . . . . . . . . . . . . . . . . . . . . . . . . 102
G.7.1. Issues with 521, 554, and 556 codes . . . . . . . . . 103 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 . . . . . . . . . . . . . . . . . . . . . . . . 103 5598 . . . . . . . . . . . . . . . . . . . . . . . . 102
G.7.3. Resolvable FQDNs and private domain names . . . . . . 103 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 . . . . . . . . . . . . . . . . . . 103 transaction state . . . . . . . . . . . . . . . . . . 102
G.7.5. Issues with mailing lists, aliases, and forwarding . 104 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 . . . . . . . . . . . . . . . . . . . . . . . . 104 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? . . . . . . . . . . . . 104 code text need clarification? (closed) . . . . . . . 103
G.7.8. Size limits . . . . . . . . . . . . . . . . . . . . . 104 G.7.8. Size limits (closed) . . . . . . . . . . . . . . . . 103
G.7.9. Discussion of 'blind' copies and RCPT . . . . . . . . 104 G.7.9. Discussion of 'blind' copies and RCPT . . . . . . . . 103
G.7.10. Further clarifications needed to source routes? . . . 105 G.7.10. Further clarifications needed to source routes? . . . 104
G.7.11. Should 1yz Be Revisited? . . . . . . . . . . . . . . 105 G.7.11. Should 1yz Be Revisited? (closed) . . . . . . . . . . 104
G.7.12. Review Timeout Specifications . . . . . . . . . . . . 105 G.7.12. Review Timeout Specifications . . . . . . . . . . . . 104
G.7.13. Possible SEND, SAML, SOML Loose End . . . . . . . . . 105 G.7.13. Possible SEND, SAML, SOML Loose End (closed) . . . . 104
G.7.14. Abstract Update . . . . . . . . . . . . . . . . . . . 105 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 . . . . . . . . . . . . . . . . . . . . . 105 Submission (closed) . . . . . . . . . . . . . . . . . 104
G.7.16. Mail Transaction Discussion . . . . . . . . . . . . . 106 G.7.16. Mail Transaction Discussion . . . . . . . . . . . . . 105
G.7.17. Hop by hop Authentication and/or Encryption . . . . . 106 G.7.17. Hop by hop Authentication and/or Encryption
G.7.18. More Text About 554 Given 521, etc. . . . . . . . . . 106 (closed) . . . . . . . . . . . . . . . . . . . . . . 105
G.7.19. Minimum Lengths and Quantities . . . . . . . . . . . 106 G.7.18. More Text About 554 Given 521, etc. . . . . . . . . . 105
G.8. Enhanced Reply Codes and DSNs . . . . . . . . . . . . . . 106 G.7.19. Minimum Lengths and Quantities . . . . . . . . . . . 105
G.9. Revisiting Quoted Strings . . . . . . . . . . . . . . . . 107 G.8. Enhanced Reply Codes and DSNs . . . . . . . . . . . . . . 105
G.10. Internationalization . . . . . . . . . . . . . . . . . . 107 G.9. Revisiting Quoted Strings . . . . . . . . . . . . . . . . 106
G.11. SMTP Clients, Servers, Senders, and Receivers . . . . . . 108 G.10. Internationalization . . . . . . . . . . . . . . . . . . 106
G.12. Extension Keywords Starting in 'X-' . . . . . . . . . . . 108 G.11. SMTP Clients, Servers, Senders, and Receivers . . . . . . 107
G.13. Deprecating HELO . . . . . . . . . . . . . . . . . . . . 108 G.12. Extension Keywords Starting in 'X-' (closed) . . . . . . 107
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 . . . . . . . . . . . . 109 Considerations, and Other Issues . . . . . . . . . . . . 108
G.15. Resistance to Attacks and Operational Necessity . . . . . 109 G.15. Resistance to Attacks and Operational Necessity
G.16. Mandatory 8BITMIME . . . . . . . . . . . . . . . . . . . 110 (closed) . . . . . . . . . . . . . . . . . . . . . . . . 108
Appendix H. RFC 5321 Errata Summary and Tentative Change Log . . 110 G.16. Mandatory 8BITMIME . . . . . . . . . . . . . . . . . . . 109
H.1. RFC 5321 Errata Summary . . . . . . . . . . . . . . . . . 110 Appendix H. RFC 5321 Errata Summary and Tentative Change Log . . 109
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 . . . . . . . . . . . 112 initial (-00) version of this draft . . . . . . . . . . . 111
H.3. Changes Among Versions of Rfc5321bis . . . . . . . . . . 113 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 . . . . . . . . . . . . . . . . . 113 2012-12-02) to -01 . . . . . . . . . . . . . . . . . 112
H.3.2. Changes from draft-klensin-rfc5321bis-01 (20191203) to H.3.2. Changes from draft-klensin-rfc5321bis-01 (20191203) to
-02 . . . . . . . . . . . . . . . . . . . . . . . . . 113 -02 . . . . . . . . . . . . . . . . . . . . . . . . . 112
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 . . . . . . . . . . . . . . . . . . . . . . . 114 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 . . . . . . . . 114 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 . . . . . . . . . . . . . . . . . 114 (2020-10-06) to -01 . . . . . . . . . . . . . . . . . 113
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 . . . . . . . . . . . . . . . . . 115 (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 . . . . . . . . . . . . . . . . . 115 (2021-02-21) to -03 . . . . . . . . . . . . . . . . . 114
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 . . . . . . . . . . . . . . . . . 116 (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 . . . . . . . . . . . . . . . . . 117 (2021-10-03) to -05 . . . . . . . . . . . . . . . . . 116
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 . . . . . . . . . . . . . . . . . 118 (2021-10-24) to -06 . . . . . . . . . . . . . . . . . 117
H.3.11. Changes from draft-ietf-emailcore-rfc5321bis-06
(2021-11-07) to -07 . . . . . . . . . . . . . . . . . 118
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 120 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 120
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 8, line 42 skipping to change at page 8, line 44
in RFC 6409 [42] is now preferred to direct use of SMTP; more in RFC 6409 [42] is now preferred to direct use of SMTP; more
discussion of that subject appears in that document. discussion of that subject appears in that document.
Section 2.3 provides definitions of terms specific to this document. Section 2.3 provides definitions of terms specific to this document.
Except when the historical terminology is necessary for clarity, this Except when the historical terminology is necessary for clarity, this
document uses the current 'client' and 'server' terminology to document uses the current 'client' and 'server' terminology to
identify the sending and receiving SMTP processes, respectively. identify the sending and receiving SMTP processes, respectively.
A companion document, RFC 5322 [12], discusses message header A companion document, RFC 5322 [12], discusses message header
sections and bodies and specifies formats and structures for them. sections and bodies and specifies formats and structures for them.
Other relevant documents and their relationships are discussed in a
// [rfc5321bis 20210317] Would this be an appropriate place to forthcoming Applicability Statement [51].
// mention RFC 2045 (MIME) and/or RFC 6409 (Message Submission)?
// Suggestion (20211104): Other relevant documents and their
// relationships are discussed in a forthcoming Applicability
// Statement [51].
1.3. Document Conventions 1.3. Document Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1]. As each document are to be interpreted as described in RFC 2119 [1]. As each
of these terms was intentionally and carefully chosen to improve the of these terms was intentionally and carefully chosen to improve the
interoperability of email, each use of these terms is to be treated interoperability of email, each use of these terms is to be treated
as a conformance requirement. as a conformance requirement.
skipping to change at page 11, line 43 skipping to change at page 11, line 43
user's host when the two hosts are connected to the same transport user's host when the two hosts are connected to the same transport
service. When they are not connected to the same transport service, service. When they are not connected to the same transport service,
transmission occurs via one or more relay SMTP servers. A very transmission occurs via one or more relay SMTP servers. A very
common case in the Internet today involves submission of the original common case in the Internet today involves submission of the original
message to an intermediate, "message submission" server, which is message to an intermediate, "message submission" server, which is
similar to a relay but has some additional properties; such servers similar to a relay but has some additional properties; such servers
are discussed in Section 2.3.10 and at some length in RFC 6409 [42]. are discussed in Section 2.3.10 and at some length in RFC 6409 [42].
An intermediate host that acts as either an SMTP relay or as a An intermediate host that acts as either an SMTP relay or as a
gateway into some other transmission environment is usually selected gateway into some other transmission environment is usually selected
through the use of the domain name service (DNS) Mail eXchanger through the use of the domain name service (DNS) Mail eXchanger
mechanism. Explicit "source" routing (see Section 5 and Appendix C mechanism.
and Appendix F.2) SHOULD NOT be used.
2.2. The Extension Model 2.2. The Extension Model
2.2.1. Background 2.2.1. Background
In an effort that started in 1990, approximately a decade after RFC In an effort that started in 1990, approximately a decade after RFC
821 was completed, the protocol was modified with a "service 821 was completed, the protocol was modified with a "service
extensions" model that permits the client and server to agree to extensions" model that permits the client and server to agree to
utilize shared functionality beyond the original SMTP requirements. utilize shared functionality beyond the original SMTP requirements.
The SMTP extension mechanism defines a means whereby an extended SMTP The SMTP extension mechanism defines a means whereby an extended SMTP
client and server may recognize each other, and the server can inform client and server may recognize each other, and the server can inform
skipping to change at page 22, line 24 skipping to change at page 22, line 24
send the same address again) or temporary (i.e., the address might be send the same address again) or temporary (i.e., the address might be
accepted if the client tries again later). Despite the apparent accepted if the client tries again later). Despite the apparent
scope of this requirement, there are circumstances in which the scope of this requirement, there are circumstances in which the
acceptability of the reverse-path may not be determined until one or acceptability of the reverse-path may not be determined until one or
more forward-paths (in RCPT commands) can be examined. In those more forward-paths (in RCPT commands) can be examined. In those
cases, the server MAY reasonably accept the reverse-path (with a 250 cases, the server MAY reasonably accept the reverse-path (with a 250
reply) and then report problems after the forward-paths are received reply) and then report problems after the forward-paths are received
and examined. Normally, failures produce 550 or 553 replies. and examined. Normally, failures produce 550 or 553 replies.
Historically, the <reverse-path> was permitted to contain more than Historically, the <reverse-path> was permitted to contain more than
just a mailbox; however, contemporary systems SHOULD NOT use source just a mailbox; however source routing is now deprecated (see
routing (see Appendix C). Appendix F.2).
The optional <mail-parameters> are associated with negotiated SMTP The optional <mail-parameters> are associated with negotiated SMTP
service extensions (see Section 2.2). service extensions (see Section 2.2).
The second step in the procedure is the RCPT command. This step of The second step in the procedure is the RCPT command. This step of
the procedure can be repeated any number of times. the procedure can be repeated any number of times.
RCPT TO:<forward-path> [ SP <rcpt-parameters> ] <CRLF> RCPT TO:<forward-path> [ SP <rcpt-parameters> ] <CRLF>
The first or only argument to this command includes a forward-path The first or only argument to this command includes a forward-path
(normally a mailbox local-part and domain, always surrounded by "<" (normally a mailbox local-part and domain, always surrounded by "<"
and ">" brackets) identifying one recipient. If accepted, the SMTP and ">" brackets) identifying one recipient. If accepted, the SMTP
server returns a "250 OK" reply and stores the forward-path. If the server returns a "250 OK" reply and stores the forward-path. If the
recipient is known not to be a deliverable address, the SMTP server recipient is known not to be a deliverable address, the SMTP server
returns a 550 reply, typically with a string such as "no such user - returns a 550 reply, typically with a string such as "no such user -
" and the mailbox name (other circumstances and reply codes are " and the mailbox name (other circumstances and reply codes are
possible). possible).
The <forward-path> can contain more than just a mailbox.
Historically, the <forward-path> was permitted to contain a source Historically, the <forward-path> was permitted to contain a source
routing list of hosts and the destination mailbox; however, routing list of hosts and the destination mailbox; however, source
contemporary SMTP clients SHOULD NOT utilize source routes (see routes are now deprecated (see Appendix F.2). Restricted-capability
Appendix C). Servers MUST be prepared to encounter a list of source clients MUST NOT assume that any SMTP server on the Internet can be
routes in the forward-path, but they SHOULD ignore the routes or MAY used as their mail processing (relaying) site. If a RCPT command
decline to support the relaying they imply. Similarly, servers MAY appears without a previous MAIL command, the server MUST return a 503
decline to accept mail that is destined for other hosts or systems. "Bad sequence of commands" response. The optional <rcpt-parameters>
These restrictions make a server useless as a relay for clients that are associated with negotiated SMTP service extensions (see
do not support full SMTP functionality. Consequently, restricted- Section 2.2).
capability clients MUST NOT assume that any SMTP server on the
Internet can be used as their mail processing (relaying) site. If a
RCPT command appears without a previous MAIL command, the server MUST
return a 503 "Bad sequence of commands" response. The optional
<rcpt-parameters> are associated with negotiated SMTP service
extensions (see Section 2.2).
// [5321bis]: this section would be improved by being more specific // [5321bis]: this section would be improved by being more specific
// about where mail transactions begin and end and then talking about // about where mail transactions begin and end and then talking about
// "transaction state" here, rather than specific prior commands. // "transaction state" here, rather than specific prior commands.
// --JcK // --JcK
Since it has been a common source of errors, it is worth noting that Since it has been a common source of errors, it is worth noting that
spaces are not permitted on either side of the colon following FROM spaces are not permitted on either side of the colon following FROM
in the MAIL command or TO in the RCPT command. The syntax is exactly in the MAIL command or TO in the RCPT command. The syntax is exactly
as given above. as given above.
skipping to change at page 29, line 7 skipping to change at page 29, line 9
have attempted to use source expansion of mailing lists as a means of have attempted to use source expansion of mailing lists as a means of
eliminating duplicates. The propagation of aliasing systems with eliminating duplicates. The propagation of aliasing systems with
mail on the Internet for hosts (typically with MX and CNAME DNS mail on the Internet for hosts (typically with MX and CNAME DNS
records), for mailboxes (various types of local host aliases), and in records), for mailboxes (various types of local host aliases), and in
various proxying arrangements has made it nearly impossible for these various proxying arrangements has made it nearly impossible for these
strategies to work consistently, and mail systems SHOULD NOT attempt strategies to work consistently, and mail systems SHOULD NOT attempt
them. them.
3.6. Relaying and Mail Routing 3.6. Relaying and Mail Routing
3.6.1. Source Routes and Relaying 3.6.1. Mail eXchange Records and Relaying
In general, the availability of Mail eXchanger records in the domain
name system (RFC 1035 [4], RFC 974 [16]) makes the use of explicit
source routes in the Internet mail system unnecessary. Many
historical problems with the interpretation of explicit source routes
have made their use undesirable. SMTP clients SHOULD NOT generate
explicit source routes except under unusual circumstances. SMTP
servers MAY decline to act as mail relays or to accept addresses that
specify source routes. When route information is encountered, SMTP
servers MAY ignore the route information and simply send to the final
destination specified as the last element in the route and SHOULD do
so. There has been an invalid practice of using names that do not
appear in the DNS as destination names, with the senders counting on
the intermediate hosts specified in source routing to resolve any
problems. If source routes are stripped, this practice will cause
failures. This is one of several reasons why SMTP clients MUST NOT
generate invalid source routes or depend on serial resolution of
names in such routes.
When source routes are not used, the process described in RFC 821 for
constructing a reverse-path from the forward-path is not applicable
and the reverse-path at the time of delivery will simply be the
address that appeared in the MAIL command.
3.6.2. Mail eXchange Records and Relaying
A relay SMTP server is usually the target of a DNS MX record that A relay SMTP server is usually the target of a DNS MX record that
designates it, rather than the final delivery system. The relay designates it, rather than the final delivery system. The relay
server may accept or reject the task of relaying the mail in the same server may accept or reject the task of relaying the mail in the same
way it accepts or rejects mail for a local user. If it accepts the way it accepts or rejects mail for a local user. If it accepts the
task, it then becomes an SMTP client, establishes a transmission task, it then becomes an SMTP client, establishes a transmission
channel to the next SMTP server specified in the DNS (according to channel to the next SMTP server specified in the DNS (according to
the rules in Section 5), and sends it the mail. If it declines to the rules in Section 5), and sends it the mail. If it declines to
relay mail to a particular address for policy reasons, a 550 response relay mail to a particular address for policy reasons, a 550 response
SHOULD be returned. SHOULD be returned.
// Text below reflects proposed replacement of the paragraph ( edited
// version of suggestion by D Crocker 2021-03-17 17:23 email). Cf.
// Ticket #30:
This specification does not deal with the verification of return This specification does not deal with the verification of return
paths. Server efforts to verify a return path and actions to be paths. Server efforts to verify a return path and actions to be
taken under various circumstances are outside the scope of this taken under various circumstances are outside the scope of this
specification. specification.
3.6.3. Message Submission Servers as Relays 3.6.2. Message Submission Servers as Relays
Many mail-sending clients exist, especially in conjunction with Many mail-sending clients exist, especially in conjunction with
facilities that receive mail via POP3 or IMAP, that have limited facilities that receive mail via POP3 or IMAP, that have limited
capability to support some of the requirements of this specification, capability to support some of the requirements of this specification,
such as the ability to queue messages for subsequent delivery such as the ability to queue messages for subsequent delivery
attempts. For these clients, it is common practice to make private attempts. For these clients, it is common practice to make private
arrangements to send all messages to a single server for processing arrangements to send all messages to a single server for processing
and subsequent distribution. SMTP, as specified here, is not ideally and subsequent distribution. SMTP, as specified here, is not ideally
suited for this role. A standardized mail submission protocol has suited for this role. A standardized mail submission protocol has
been developed that is gradually superseding practices based on SMTP been developed that is gradually superseding practices based on SMTP
skipping to change at page 37, line 43 skipping to change at page 37, line 27
This command is used to initiate a mail transaction in which the mail This command is used to initiate a mail transaction in which the mail
data is delivered to an SMTP server that may, in turn, deliver it to data is delivered to an SMTP server that may, in turn, deliver it to
one or more mailboxes or pass it on to another system (possibly using one or more mailboxes or pass it on to another system (possibly using
SMTP). The argument clause contains a reverse-path and may contain SMTP). The argument clause contains a reverse-path and may contain
optional parameters. In general, the MAIL command may be sent only optional parameters. In general, the MAIL command may be sent only
when no mail transaction is in progress, see Section 4.1.4. when no mail transaction is in progress, see Section 4.1.4.
The reverse-path consists of the sender mailbox. Historically, that The reverse-path consists of the sender mailbox. Historically, that
mailbox might optionally have been preceded by a list of hosts, but mailbox might optionally have been preceded by a list of hosts, but
that behavior is now deprecated (see Appendix C). In some types of that behavior is now deprecated (see Appendix F.2). In some types of
reporting messages for which a reply is likely to cause a mail loop reporting messages for which a reply is likely to cause a mail loop
(for example, mail delivery and non-delivery notifications), the (for example, mail delivery and non-delivery notifications), the
reverse-path may be null (see Section 3.6). reverse-path may be null (see Section 3.6).
This command clears the reverse-path buffer, the forward-path buffer, This command clears the reverse-path buffer, the forward-path buffer,
and the mail data buffer, and it inserts the reverse-path information and the mail data buffer, and it inserts the reverse-path information
from its argument clause into the reverse-path buffer. from its argument clause into the reverse-path buffer.
If service extensions were negotiated, the MAIL command may also If service extensions were negotiated, the MAIL command may also
carry parameters associated with a particular service extension. carry parameters associated with a particular service extension.
skipping to change at page 38, line 20 skipping to change at page 38, line 5
mail = "MAIL FROM:" Reverse-path mail = "MAIL FROM:" Reverse-path
[SP Mail-parameters] CRLF [SP Mail-parameters] CRLF
4.1.1.3. RECIPIENT (RCPT) 4.1.1.3. RECIPIENT (RCPT)
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 normally consists of the required destination The forward-path consists of the required destination mailbox. When
mailbox. Sending systems SHOULD NOT generate the optional list of mail reaches its ultimate destination, the SMTP server inserts it
hosts known as a source route. Receiving systems MUST recognize into the destination mailbox in accordance with its host mail
source route syntax but SHOULD strip off the source route conventions.
specification and utilize the domain name associated with the mailbox
as if the source route had not been provided.
Similarly, relay hosts SHOULD strip or ignore source routes, and // JcK 20211128: above is new text, per notes from Alexey and Ned,
names MUST NOT be copied into the reverse-path. When mail reaches // replacing the two paragraphs and text about source routes that
its ultimate destination (the forward-path contains only a // used to appear here. However, I'm a little concerned about
destination mailbox), the SMTP server inserts it into the destination // "ultimate destination" as used here. The earlier text was about
mailbox in accordance with its host mail conventions. // 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 20211202) The examples below appear to have been carried
// forward from RFC821, i.e., before RFC 974 and MX records. Nothing
// in them is actually wrong given the current (as of version -07 of
// this draft), but it seems to me that we should trim it
// aggressively, add a few comments explaining why a proper DNS setup
// with MX records would be a better solution for some of these
// cases, and/or move the examples to Appendix F.2. I hope that we
// can either get this on the agenda for the next interim or dicuss
// it sufficiently on the list to get a sense of the WG (including
// whether anyone cases). Otherwise I will apply editor's
// discretion.
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
MAIL FROM:<userx@y.foo.org> MAIL FROM:<userx@y.foo.org>
RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org> RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org>
will normally be sent directly on to host d.bar.org with envelope will normally be sent directly on to host d.bar.org with envelope
commands commands
MAIL FROM:<userx@y.foo.org> MAIL FROM:<userx@y.foo.org>
RCPT TO:<userc@d.bar.org> RCPT TO:<userc@d.bar.org>
As provided in Appendix C, xyz.com MAY also choose to relay the As provided in Appendix F.2, xyz.com MAY also choose to relay the
message to hosta.int, using the envelope commands message to hosta.int, using the envelope commands
MAIL FROM:<userx@y.foo.org> MAIL FROM:<userx@y.foo.org>
RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org> RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org>
or to jkl.org, using the envelope commands or to jkl.org, using the envelope commands
MAIL FROM:<userx@y.foo.org> MAIL FROM:<userx@y.foo.org>
RCPT TO:<@jkl.org:userc@d.bar.org> RCPT TO:<@jkl.org:userc@d.bar.org>
Attempting to use relaying this way is now strongly discouraged. Attempting to use relaying this way is now strongly discouraged.
skipping to change at page 43, line 30 skipping to change at page 43, line 30
and if the definition of the specific parameter does not mandate the and if the definition of the specific parameter does not mandate the
use of another code, it should return code 455. use of another code, it should return code 455.
Errors specific to particular parameters and their values will be Errors specific to particular parameters and their values will be
specified in the parameter's defining RFC. specified in the parameter's defining RFC.
4.1.2. Command Argument Syntax 4.1.2. Command Argument Syntax
The syntax of the argument clauses of the above commands (using the The syntax of the argument clauses of the above commands (using the
syntax specified in RFC 5234 [11] where applicable) is given below. syntax specified in RFC 5234 [11] where applicable) is given below.
Some of the productions given below are used only in conjunction with Some terminals not defined in this document, but are defined
source routes as described in Appendix C. Some terminals not defined elsewhere, specifically:
in this document, but are defined elsewhere, specifically:
* In the "core" syntax in Appendix B of RFC 5234 [11]: ALPHA , CRLF * In the "core" syntax in Appendix B of RFC 5234 [11]: ALPHA , CRLF
, DIGIT , HEXDIG , and SP , DIGIT , HEXDIG , and SP
* In the message format syntax in RFC 5322 [12]: atext , CFWS , and * In the message format syntax in RFC 5322 [12]: atext , CFWS , and
FWS . FWS .
Reverse-path = Path / "<>" Reverse-path = Path / "<>"
Forward-path = Path Forward-path = Path
Path = "<" [ A-d-l ":" ] Mailbox ">" Path = "<" Mailbox ">"
A-d-l = At-domain *( "," At-domain )
; Note that this form, the so-called "source
; route", MUST BE accepted, SHOULD NOT be
; generated, and SHOULD be ignored.
At-domain = "@" Domain At-domain = "@" Domain
Mail-parameters = esmtp-param *(SP esmtp-param) Mail-parameters = esmtp-param *(SP esmtp-param)
Rcpt-parameters = esmtp-param *(SP esmtp-param) Rcpt-parameters = esmtp-param *(SP esmtp-param)
esmtp-param = esmtp-keyword ["=" esmtp-value] esmtp-param = esmtp-keyword ["=" esmtp-value]
esmtp-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") esmtp-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
esmtp-value = 1*(%d33-60 / %d62-126) esmtp-value = 1*(%d33-60 / %d62-126)
; any CHAR excluding "=", SP, and control ; any CHAR excluding "=", SP, and control
; characters. If this string is an email address, ; characters. If this string is an email address,
; i.e., a Mailbox, then the "xtext" syntax [34] ; i.e., a Mailbox, then the "xtext" syntax [34]
; SHOULD be used. ; SHOULD be used.
Keyword = Ldh-str Keyword = Ldh-str
skipping to change at page 45, line 13 skipping to change at page 45, line 7
; 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
indicate that the next character is to be used literally (instead of
its normal interpretation). For example, "Joe\,Smith" indicates a
single nine-character user name string with the comma being the
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 host that expects to receive mail for maximum interoperability, a mailbox SHOULD NOT be defined with
SHOULD avoid defining mailboxes where the Local-part requires (or Local-part requiring (or using) the Quoted-string form or with the
uses) the Quoted-string form or where the Local-part is case- Local-part being case-sensitive. Further, when comparing a Local-
sensitive. For any purposes that require generating or comparing part (e.g., to a specific mailbox name), all quoting MUST be treated
Local-parts (e.g., to specific mailbox names), all quoted forms MUST as equivalent. A sending system SHOULD transmit the form that uses
be treated as equivalent, and the sending system SHOULD transmit the the minimum quoting possible.
form that uses the minimum quoting possible.
For example, the following 3 local-parts are semantically
equivalent and MUST compare equal: "ab cd ef", "ab\ cd ef" and
"ab\ \cd ef". Similarly, "fred" and fred must compare equal.
White space reduction MUST NOT be applied to Local-part by
intermediate systems.
Systems MUST NOT define mailboxes in such a way as to require the use Systems MUST NOT define mailboxes in such a way as to require the use
in SMTP of non-ASCII characters (octets with the high order bit set in SMTP of non-ASCII characters (octets with the high order bit set
to one) or ASCII "control characters" (decimal value 0-31 and 127). to one) or ASCII "control characters" (decimal value 0-31 and 127).
These characters MUST NOT be used in MAIL or RCPT commands or other These characters MUST NOT be used in MAIL or RCPT commands or other
commands that require mailbox names. commands that require mailbox names.
Note that the backslash, "\", is a quote character, which is used to
indicate that the next character is to be used literally (instead of
its normal interpretation). For example, "Joe\,Smith" indicates a
single nine-character user name string with the comma being the
fourth character of that string.
To promote interoperability and consistent with long-standing To promote interoperability and consistent with long-standing
guidance about conservative use of the DNS in naming and applications guidance about conservative use of the DNS in naming and applications
(e.g., see Section 2.3.1 of the base DNS document, RFC 1035 [4]), (e.g., see Section 2.3.1 of the base DNS document, RFC 1035 [4]),
characters outside the set of alphabetic characters, digits, and characters outside the set of alphabetic characters, digits, and
hyphen MUST NOT appear in domain name labels for SMTP clients or hyphen MUST NOT appear in domain name labels for SMTP clients or
servers. In particular, the underscore character is not permitted. servers. In particular, the underscore character is not permitted.
SMTP servers that receive a command in which invalid character codes SMTP servers that receive a command in which invalid character codes
have been employed, and for which there are no other reasons for have been employed, and for which there are no other reasons for
rejection, MUST reject that command with a 501 response (this rule, rejection, MUST reject that command with a 501 response (this rule,
like others, could be overridden by appropriate SMTP extensions). like others, could be overridden by appropriate SMTP extensions).
skipping to change at page 73, line 9 skipping to change at page 73, line 37
specification. specification.
As discussed above, when the SMTP server receives mail from a As discussed above, when the SMTP server receives mail from a
particular host address, it could activate its own SMTP queuing particular host address, it could activate its own SMTP queuing
mechanisms to retry any mail pending for that host address. mechanisms to retry any mail pending for that host address.
4.5.5. Messages with a Null Reverse-Path 4.5.5. Messages with a Null Reverse-Path
There are several types of notification messages that are required by There are several types of notification messages that are required by
existing and proposed Standards to be sent with a null reverse-path, existing and proposed Standards to be sent with a null reverse-path,
namely non-delivery notifications as discussed in Section 3.6.2 and namely non-delivery notifications as discussed in Section 3.6.1 and
Section 3.6.3, other kinds of Delivery Status Notifications (DSNs, Section 3.6.2, other kinds of Delivery Status Notifications (DSNs,
RFC 3461 [34]), and Message Disposition Notifications (MDNs, RFC 8098 RFC 3461 [34]), and Message Disposition Notifications (MDNs, RFC 8098
[37]). All of these kinds of messages are notifications about a [37]). All of these kinds of messages are notifications about a
previous message, and they are sent to the reverse-path of the previous message, and they are sent to the reverse-path of the
previous mail message. (If the delivery of such a notification previous mail message. (If the delivery of such a notification
message fails, that usually indicates a problem with the mail system message fails, that usually indicates a problem with the mail system
of the host to which the notification message is addressed. For this of the host to which the notification message is addressed. For this
reason, at some hosts the MTA is set up to forward such failed reason, at some hosts the MTA is set up to forward such failed
notification messages to someone who is able to fix problems with the notification messages to someone who is able to fix problems with the
mail system, e.g., via the postmaster alias.) mail system, e.g., via the postmaster alias.)
skipping to change at page 76, line 13 skipping to change at page 77, line 4
of the relevant networks and any conversions that might be necessary, of the relevant networks and any conversions that might be necessary,
or will be obvious (e.g., an IPv6-only client need not attempt to or will be obvious (e.g., an IPv6-only client need not attempt to
look up A RRs or attempt to reach IPv4-only servers). Designers of look up A RRs or attempt to reach IPv4-only servers). Designers of
SMTP implementations that might run in IPv6 or dual-stack SMTP implementations that might run in IPv6 or dual-stack
environments should study the procedures above, especially the environments should study the procedures above, especially the
comments about multihomed hosts, and, preferably, provide mechanisms comments about multihomed hosts, and, preferably, provide mechanisms
to facilitate operational tuning and mail interoperability between to facilitate operational tuning and mail interoperability between
IPv4 and IPv6 systems while considering local circumstances. IPv4 and IPv6 systems while considering local circumstances.
6. Problem Detection and Handling 6. Problem Detection and Handling
6.1. Reliable Delivery and Replies by Email 6.1. Reliable Delivery and Replies by Email
When the receiver-SMTP accepts a piece of mail (by sending a "250 OK" When the receiver-SMTP accepts a piece of mail (by sending a "250 OK"
message in response to DATA), it is accepting responsibility for message in response to DATA), it is accepting responsibility for
delivering or relaying the message. It must take this responsibility delivering or relaying the message. It must take this responsibility
seriously. It MUST NOT lose the message for frivolous reasons, such seriously. It MUST NOT lose the message for frivolous reasons, such
as because the host later crashes or because of a predictable as because the host later crashes or because of a predictable
resource shortage. Some reasons that are not considered frivolous resource shortage. Some reasons that are not considered frivolous
are discussed in the next subsection and in Section 7.8. are discussed in the next subsection and in Section 7.8.
If there is a delivery failure after acceptance of a message, the If there is a delivery failure after acceptance of a message, the
receiver-SMTP MUST formulate and mail a notification message. This receiver-SMTP MUST formulate and mail a notification message. This
notification MUST be sent using a null ("<>") reverse-path in the notification MUST be sent using a null ("<>") reverse-path in the
envelope. The recipient of this notification MUST be the address envelope. The recipient of this notification MUST be the address
from the envelope return path (or the Return-Path: line). However, from the envelope return path (or the Return-Path: line). However,
if this address is null ("<>"), the receiver-SMTP MUST NOT send a if this address is null ("<>"), the receiver-SMTP MUST NOT send a
notification. Obviously, nothing in this section can or should notification. Obviously, nothing in this section can or should
prohibit local decisions (i.e., as part of the same system prohibit local decisions (i.e., as part of the same system
environment as the receiver-SMTP) to log or otherwise transmit environment as the receiver-SMTP) to log or otherwise transmit
information about null address events locally if that is desired. If information about null address events locally if that is desired.
the address is an explicit source route, it MUST be stripped down to
its final hop.
For example, suppose that an error notification must be sent for a
message that arrived with:
MAIL FROM:<@a,@b:user@d>
The notification message MUST be sent using:
RCPT TO:<user@d>
Some delivery failures after the message is accepted by SMTP will be Some delivery failures after the message is accepted by SMTP will be
unavoidable. For example, it may be impossible for the receiving unavoidable. For example, it may be impossible for the receiving
SMTP server to validate all the delivery addresses in RCPT command(s) SMTP server to validate all the delivery addresses in RCPT command(s)
due to a "soft" domain system error, because the target is a mailing due to a "soft" domain system error, because the target is a mailing
list (see earlier discussion of RCPT), or because the server is list (see earlier discussion of RCPT), or because the server is
acting as a relay and has no immediate access to the delivering acting as a relay and has no immediate access to the delivering
system. system.
To avoid receiving duplicate messages as the result of timeouts, a To avoid receiving duplicate messages as the result of timeouts, a
skipping to change at page 83, line 26 skipping to change at page 83, line 32
to others. to others.
7.7. Information Disclosure in Message Forwarding 7.7. Information Disclosure in Message Forwarding
As discussed in Section 3.4, use of the 251 or 551 reply codes to As discussed in Section 3.4, use of the 251 or 551 reply codes to
identify the replacement address associated with a mailbox may identify the replacement address associated with a mailbox may
inadvertently disclose sensitive information. Sites that are inadvertently disclose sensitive information. Sites that are
concerned about those issues should ensure that they select and concerned about those issues should ensure that they select and
configure servers appropriately. configure servers appropriately.
7.8. Local Operational Requirement and Resistance to Attacks 7.8. Local Operational Requirements and Resistance to Attacks
In recent years, there has been an increase of attacks on SMTP In recent years, there has been an increase of attacks on SMTP
servers, either in conjunction with attempts to discover addresses servers, either in conjunction with attempts to discover addresses
for sending unsolicited messages or simply to make the servers for sending unsolicited messages or simply to make the servers
inaccessible to others (i.e., as an application-level denial of inaccessible to others (i.e., as an application-level denial of
service attack). There may also be important local circumstances service attack). There may also be important local circumstances
that justify departures from some of the limits specified in this that justify departures from some of the limits specified in this
documents especially ones involving maximums or minimums. While the documents especially ones involving maximums or minimums. While the
means of doing so are beyond the scope of this Standard, rational means of doing so are beyond the scope of this Standard, rational
operational behavior requires that servers be permitted to detect operational behavior requires that servers be permitted to detect
skipping to change at page 93, line 7 skipping to change at page 93, line 22
fields have repeatedly caused mail loops and other behavior adverse fields have repeatedly caused mail loops and other behavior adverse
to the proper functioning of the Internet mail environment. These to the proper functioning of the Internet mail environment. These
problems have been especially common when the message originates from problems have been especially common when the message originates from
an Internet mailing list and is distributed into the foreign an Internet mailing list and is distributed into the foreign
environment using envelope information. When these messages are then environment using envelope information. When these messages are then
processed by a header-section-only remailer, loops back to the processed by a header-section-only remailer, loops back to the
Internet environment (and the mailing list) are almost inevitable. Internet environment (and the mailing list) are almost inevitable.
Appendix C. Source Routes Appendix C. Source Routes
Historically, the <reverse-path> was a reverse source routing list of // This entire section to be removed, possibly with some material
hosts and a source mailbox. The first host in the <reverse-path> was // moved into Appendix F. This comment is retained as a temporary
historically the host sending the MAIL command; today, source routes // placeholder because the WG, the Ticket list, and various email
SHOULD NOT appear in the reverse-path. Similarly, the <forward-path> // threads refer to Appendix letters and it would not be good to
may be a source routing lists of hosts and a destination mailbox. // create confusion about that.
However, in general, the <forward-path> SHOULD contain only a mailbox
and domain name, relying on the domain name system to supply routing
information if required. The use of source routes is deprecated (see
Appendix F.2); while servers MUST be prepared to receive and handle
them as discussed in Section 3.3 and Appendix F.2, clients SHOULD NOT
transmit them and this section is included in the current
specification only to provide context. It has been modified somewhat
from the material in RFC 821 to prevent server actions that might
confuse clients or subsequent servers that do not expect a full
source route implementation.
Historically, for relay purposes, the forward-path may have been a
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
emphasize the distinction between an address and a route. The
mailbox (here, JOE@THREE) is an absolute address, and the route is
information about how to get there. The two concepts should not be
confused.
If source routes are used contrary to requirements and
recommendations elsewhere in this specification, RFC 821 and the text
below should be consulted for the mechanisms for 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 the list in the
forward-path) MUST remove its domain name from any forward-paths in
which that domain name appears before forwarding the message and MAY
remove all other source routing information. The reverse-path SHOULD
NOT be updated by servers conforming to this specification.
Notice that the forward-path and reverse-path appear in the SMTP
commands and replies, but not necessarily in the message. That is,
there is no need for these paths and especially this syntax to appear
in the "To:" , "From:", "CC:", etc. fields of the message header
section. Conversely, SMTP servers MUST NOT derive final message
routing information from message header fields.
When the list of hosts is present despite the recommendations and
requirements above, it is a "reverse" source route and indicates that
the mail was relayed through each host on the list (the first host in
the list was the most recent relay). This list is used as a source
route to return non-delivery notices to the sender. If, contrary to
the recommendations here, a relay host adds itself to the beginning
of the list, it MUST use its name as known in the transport
environment to which it is relaying the mail rather than that of the
transport environment from which the mail came (if they are
different). Note that a situation could easily arise in which some
relay hosts add their names to the reverse source route and others do
not, generating discontinuities in the routing list. This is another
reason why servers needing to return a message SHOULD ignore the
source route entirely and simply use the domain as specified in the
Mailbox.
Appendix D. Scenarios Appendix D. Scenarios
This section presents complete scenarios of several types of SMTP This section presents complete scenarios of several types of SMTP
sessions. In the examples, "C:" indicates what is said by the SMTP sessions. In the examples, "C:" indicates what is said by the SMTP
client, and "S:" indicates what is said by the SMTP server. client, and "S:" indicates what is said by the SMTP server.
D.1. A Typical SMTP Transaction Scenario D.1. A Typical SMTP Transaction Scenario
This SMTP example shows mail sent by Smith at host bar.com, and to This SMTP example shows mail sent by Smith at host bar.com, and to
skipping to change at page 101, line 38 skipping to change at page 100, line 38
The specification is unclear about whether IP address literals, The specification is unclear about whether IP address literals,
particularly IP address literals used as arguments to the EHLO particularly IP address literals used as arguments to the EHLO
command, are required to be accepted or whether they are allowed to command, are required to be accepted or whether they are allowed to
be rejected as part of the general "operational necessity" exception. be rejected as part of the general "operational necessity" exception.
Some have suggested that rejection of them is so common as an anti- Some have suggested that rejection of them is so common as an anti-
spam measure that the use of such literals should be deprecated spam measure that the use of such literals should be deprecated
entirely in the specification, others that the are still useful and entirely in the specification, others that the are still useful and
used and/or that, whatever is said about IP address literals within used and/or that, whatever is said about IP address literals within
an SMTP session (e.g., in MAIL or RCPT commands), they should an SMTP session (e.g., in MAIL or RCPT commands), they should
continue to be allowed (and required) in EHLO. continue to be allowed (and required) in EHLO.
Ticket #1. Ticket #1 (issue for A/S).
G.2. Repeated Use of EHLO G.2. Repeated Use of EHLO (closed)
While the specification says that an SMTP client's sending EHLO again While the specification says that an SMTP client's sending EHLO again
after it has been issued (starting an SMTP session and treats it as after it has been issued (starting an SMTP session and treats it as
if RSET had been sent (closing the session) followed by EHLO, there if RSET had been sent (closing the session) followed by EHLO, there
are apparently applications, at least some of them involving setting are apparently applications, at least some of them involving setting
up of secure connections, in which the second EHLO is required and up of secure connections, in which the second EHLO is required and
does not imply RSET. Does the specification need to be adjusted to does not imply RSET. Does the specification need to be adjusted to
reflect or call out those cases? reflect or call out those cases?
After extended discussion in October 2020, it appears that the After extended discussion in October 2020, it appears that the
easiest fix to these problems is to clarify the conditions for easiest fix to these problems is to clarify the conditions for
termination of a mail transaction in Section 3.3 and to clearly termination of a mail transaction in Section 3.3 and to clearly
specify the effect of a second (or subsequent) EHLO command in specify the effect of a second (or subsequent) EHLO command in
Section 4.1.4. Section 4.1.4.
See also Appendix G.7.4. See also Appendix G.7.4.
Ticket #2. Both changes have been made in draft-ietf-emailcore- Ticket #2. (closed - Both changes have been made in draft-ietf-
rfc5321bis-01. emailcore-rfc5321bis-01).
G.3. Meaning of "MTA" and Related Terminology G.3. Meaning of "MTA" and Related Terminology
A terminology issue has come up about what the term "MTA" actually A terminology issue has come up about what the term "MTA" actually
refers to, a question that became at least slightly more complicated refers to, a question that became at least slightly more complicated
when we formalized RFC 6409 Submission Servers. Does the document when we formalized RFC 6409 Submission Servers. Does the document
need to be adjusted to be more clear about this topic? Note that the need to be adjusted to be more clear about this topic? Note that the
answer may interact with the question asked in Section 2 above. answer may interact with the question asked in Section 2 above.
Possibly along the same lines, RFC 2821 changed the RFC 821 Possibly along the same lines, RFC 2821 changed the RFC 821
terminology from "sender-SMTP" and "receiver-SMTP" to "SMTP client" terminology from "sender-SMTP" and "receiver-SMTP" to "SMTP client"
skipping to change at page 102, line 34 skipping to change at page 101, line 34
G.4. Originator, or Originating System, Authentication G.4. Originator, or Originating System, Authentication
Should RFC 5321bis address authentication and related issues or Should RFC 5321bis address authentication and related issues or
should Section 3.9 or other text be reshaped (in addition to or should Section 3.9 or other text be reshaped (in addition to or
instead of the comment on that section) to lay a better foundation instead of the comment on that section) to lay a better foundation
for such work, either in the context of mailing lists or more for such work, either in the context of mailing lists or more
generally? generally?
This may interact with Erratum 4055 and Ticket #30 below. This may interact with Erratum 4055 and Ticket #30 below.
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)
The suggestion in Section 4.5.3.1.10 may have outlived its usefulness The suggestion in Section 4.5.3.1.10 may have outlived its usefulness
and/or be inconsistent with current practice. Should it be removed and/or be inconsistent with current practice. Should it be removed
and/or explicitly deprecated? and/or explicitly deprecated?
Ticket #5. 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
skipping to change at page 103, line 14 skipping to change at page 102, line 14
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.
G.7.1. Issues with 521, 554, and 556 codes G.7.1. Issues with 521, 554, and 556 codes (closed)
See new Section 4.2.4.2. More text may be needed, there or See new Section 4.2.4.2. More text may be needed, there or
elsewhere, about choices of codes in response to initial opening and elsewhere, about choices of codes in response to initial opening and
to EHLO, especially to deal with selective policy rejections. In to EHLO, especially to deal with selective policy rejections. In
particular, should we more strongly discourage the use of 554 on particular, should we more strongly discourage the use of 554 on
initial opening. And should we make up a 421 code (or a new 4yz initial opening. And should we make up a 421 code (or a new 4yz
code, perhaps 454) code for situations where the server is code, perhaps 454) code for situations where the server is
temporarily out of service? temporarily out of service?
Ticket #6. Ticket #6 (closed).
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, #10 and #41. Tickets #9 (definition of domain name), #10 (meaning of "resolvable
domain name"), and #41 (closed -- no change 2021-04-05).
Ticket #41 marked "closed no change", per email 2021-0405.
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
CREF comment in Section 3.9. May also want to note forwarding as an CREF comment in Section 3.9. May also want to note forwarding as an
email address portability issue. Note that, if changes are made in email address portability issue. Note that, if changes are made in
this area, they should be kept consistent with the description and this area, they should be kept consistent with the description and
discussion of the 251 and 551 in Section 4.2 and Section 3.5 as well discussion of the 251 and 551 in Section 4.2 and Section 3.5 as well
as Section 3.4 to avoid introducing inconsistencies. In addition, as Section 3.4 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 may be resolved Ticket #12 and Ticket #34 (Ticket #34/ erratum 1820 resolved in -06
in -06). 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.
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? 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. Ticket #13 (fixed and closed).
G.7.8. Size limits G.7.8. Size limits (closed)
Once a decision is made about line length rules for RFC 5322bis, Once a decision is made about line length rules for RFC 5322bis,
review the size limit discussions in this document, particularly the review the size limit discussions in this document, particularly the
CREF comment (Note in Draft) at the end of the introductory material CREF comment (Note in Draft) at the end of the introductory material
to Section 4.5.3 to be sure this document says what we want it to to Section 4.5.3 to be sure this document says what we want it to
say. (See the additional question about minimum quantities, etc., in say. (See the additional question about minimum quantities, etc., in
Appendix G.7.19.) Appendix G.7.19.)
Ticket #14 (closed - no action) and maybe Ticket #38 (to A/S). Ticket #14 (closed - no action) and maybe Ticket #38 (to A/S).
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. Is additional work
needed in this area? See CREF comment in Appendix C needed in this area? See CREF comment in Appendix F.2
Ticket #17. Ticket #17.
G.7.11. Should 1yz Be Revisited? 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 back up?
Ticket #18. 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.
G.7.13. Possible SEND, SAML, SOML Loose End G.7.13. Possible SEND, SAML, SOML Loose End (closed)
Per discussion (and Ticket #20), the text about SEND, SAML, and SOML Per discussion (and Ticket #20), the text about SEND, SAML, and SOML
has been removed from the main body of the document so that the only has been removed from the main body of the document so that the only
discussion of them now appears in Appendix F.6. Per the editor's discussion of them now appears in Appendix F.6. Per the editor's
note in that appendix, is any further discussion needed? note in that appendix, is any further discussion needed?
Ticket #20 (closed)
G.7.14. Abstract Update G.7.14. Abstract Update (closed)
Does the Abstract need to be modified in the light of RFC 6409 or Does the Abstract need to be modified in the light of RFC 6409 or
other changes? other changes?
Ticket #52 (changes made; closed)
G.7.15. Informative References to MIME and/or Message Submission G.7.15. Informative References to MIME and/or Message Submission
(closed)
Should RFC 2045 (MIME) and/or RFC 6409 (Message Submission) be Should RFC 2045 (MIME) and/or RFC 6409 (Message Submission) be
referenced at the end of Section 1.2? referenced at the end of Section 1.2?
Ticket #53. Ticket #53 (more general reference to the A/S, closed).
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 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.)
Ticket #50. 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
Are the minimum lengths and quantities specified in Section 4.5.3 Are the minimum lengths and quantities specified in Section 4.5.3
skipping to change at page 107, line 28 skipping to change at page 106, line 28
widely not read or ignored. Do we need to do something else? If we widely not read or ignored. Do we need to do something else? If we
do an Applicability Statement, would it be useful to either reference do an Applicability Statement, would it be useful to either reference
the discussion in this document from there or to move the discussion the discussion in this document from there or to move the discussion
there and reference it (normatively?) from here? there and reference it (normatively?) from here?
There has been a separate discussion of empty quoted strings in There has been a separate discussion of empty quoted strings in
addresses, i.e., whether the <qtextSMTP> production should be addresses, i.e., whether the <qtextSMTP> production should be
required to included at least one non-whitespace character. It is required to included at least one non-whitespace character. It is
separate from this issue but would be further impacted or distorted separate from this issue but would be further impacted or distorted
from the considerations identified in this Section. from the considerations identified in this Section.
Text modified in -07.
Ticket #21. May also interact with Ticket #35. Ticket #21. May also interact with Ticket #35.
G.10. Internationalization G.10. Internationalization
RFC 5321 came long before work on internationalization of email RFC 5321 came long before work on internationalization of email
addresses and headers (other than by use of encoded words in MINE) addresses and headers (other than by use of encoded words in MINE)
and specifically before the work of the EAI WG leading to the and specifically before the work of the EAI WG leading to the
SMTPUTF8 specifications, specifically RFCs 6530ff. The second SMTPUTF8 specifications, specifically RFCs 6530ff. The second
explanatory paragraph at the end of Section 4.1.2 ("Systems MUST NOT explanatory paragraph at the end of Section 4.1.2 ("Systems MUST NOT
define mailboxes ...") is an extremely strong prohibition against the define mailboxes ...") is an extremely strong prohibition against the
skipping to change at page 107, line 49 skipping to change at page 107, line 4
about message content in Section 2.3.1 an equally strong one for about message content in Section 2.3.1 an equally strong one for
content. Would it be appropriate to add something like "in the content. Would it be appropriate to add something like "in the
absence of relevant extensions" there? Also, given [mis]behavior absence of relevant extensions" there? Also, given [mis]behavior
seen in the wild, does that paragraph (or an A/S) need an explicit seen in the wild, does that paragraph (or an A/S) need an explicit
caution about SMTP servers or clients assuming they can apply the caution about SMTP servers or clients assuming they can apply the
popular web convention of using %NN sequences as a way to encode non- popular web convention of using %NN sequences as a way to encode non-
ASCII characters (<pct-encoded> in RFC 3986) and assuming some later ASCII characters (<pct-encoded> in RFC 3986) and assuming some later
system will interpret it as they expect? Would it be appropriate to system will interpret it as they expect? Would it be appropriate to
add an Internationalization Considerations section to the body of add an Internationalization Considerations section to the body of
this document if only for the purpose of pointing people elsewhere? this document if only for the purpose of pointing people elsewhere?
More broadly, while the EAI WG's extensions for non-ASCII headers and More broadly, while the EAI WG's extensions for non-ASCII headers and
addresses are explicitly out of scope for the EMAILCORE WG (at least addresses are explicitly out of scope for the EMAILCORE WG (at least
for 5321bis (and 5322bis), those documents make assumptions and for 5321bis (and 5322bis), those documents make assumptions and
interpretations of the core documents. Are there areas in which interpretations of the core documents. Are there areas in which
5321bis could and should be clarified to lay a more solid foundation 5321bis could and should be clarified to lay a more solid foundation
for the EAI/SMTPUTF8 work and, if so, what are they? for the EAI/SMTPUTF8 work and, if so, what are they?
G.11. SMTP Clients, Servers, Senders, and Receivers G.11. SMTP Clients, Servers, Senders, and Receivers
RFC 821 used the terms "SMTP-sender" and "SMTP-receiver". In RFC RFC 821 used the terms "SMTP-sender" and "SMTP-receiver". In RFC
2821 (and hence in 5321), we switched that to "client" and "server" 2821 (and hence in 5321), we switched that to "client" and "server"
(See the discussion in Section 1.2). In part because a relay is a (See the discussion in Section 1.2). In part because a relay is a
server and then a client (in some recent practice, even interleaving server and then a client (in some recent practice, even interleaving
the two functions by opening the connection to the next host in line the two functions by opening the connection to the next host in line
and sending commands before the incoming transaction is complete), and sending commands before the incoming transaction is complete),
RFC 5321 continues to use the original terminology in some places. RFC 5321 continues to use the original terminology in some places.
Should we revisit that usage, possibly even returning to consistent Should we revisit that usage, possibly even returning to consistent
use of the original terminology? use of the original terminology?
G.12. Extension Keywords Starting in 'X-' G.12. Extension Keywords Starting in 'X-' (closed)
Section 2.2.2 contains a discussion of SMTP keywords starting in "X". Section 2.2.2 contains a discussion of SMTP keywords starting in "X".
Given general experience with such things and RFC 6648, is there any Given general experience with such things and RFC 6648, is there any
reason to not deprecate that practice entirely and remove that text? reason to not deprecate that practice entirely and remove that text?
If we do so, should the former Section 4.1.5 be dropped or rewritten If we do so, should the former Section 4.1.5 be dropped or rewritten
to make clear this is an obsolete practice? to make clear this is an obsolete practice?
4.1.5 eliminated in rfc5321bis-06. 4.1.5 eliminated in rfc5321bis-06.
Ticket #42 (resolved with -06??). Ticket #42 (resolved with -06 and closed).
G.13. Deprecating HELO G.13. Deprecating HELO (closed)
RFC 5321 (and 2821 before it) very carefully circle around the status RFC 5321 (and 2821 before it) very carefully circle around the status
of HELO, even recommending its use as a fallback when EHLO is sent of HELO, even recommending its use as a fallback when EHLO is sent
and a "command not recognized" response is received. We are just a and a "command not recognized" response is received. We are just a
few months short of 20 years; is it time to deprecate the thing and few months short of 20 years; is it time to deprecate the thing and
clean out some or all of that text? And, given a recent (4Q2020) clean out some or all of that text? And, given a recent (4Q2020)
discussion on the EMAILCORE list, should EHLO be explicitly bound to discussion on the EMAILCORE list, should EHLO be explicitly bound to
SMTP over TCP with the older transports allowed only with HELO? SMTP over TCP with the older transports allowed only with HELO?
While those questions may seem independent, separating them is fairly While those questions may seem independent, separating them is fairly
hard given the way the text is now constructed. hard given the way the text is now constructed.
Resolved 2021-01-19: No change Resolved 2021-01-19: No change
Ticket #43. Ticket #43 (closed).
G.14. The FOR Clause in Trace Fields: Semantics, Security G.14. The FOR Clause in Trace Fields: Semantics, Security
Considerations, and Other Issues Considerations, and Other Issues
The FOR clause in time-stamp ("Received:") fields is seriously under- The FOR clause in time-stamp ("Received:") fields is seriously under-
defined. It is optional, the syntax is clear, but its semantics and defined. It is optional, the syntax is clear, but its semantics and
use, while perhaps obvious from content and the application of common use, while perhaps obvious from content and the application of common
sense, have never been defined ("never" going back to 821). Do we sense, have never been defined ("never" going back to 821). Do we
want to better define it? Is there any chance that a definition want to better define it? Is there any chance that a definition
would invalid existing, conforming and sensible, implementations? If would invalid existing, conforming and sensible, implementations? If
skipping to change at page 109, line 43 skipping to change at page 108, line 43
There is probably an error in Section 7.6. Its last sentence implies There is probably an error in Section 7.6. Its last sentence implies
a possible interaction between messages with multiple recipients and a possible interaction between messages with multiple recipients and
the FOR clause of trace fields. However, because the syntax of the the FOR clause of trace fields. However, because the syntax of the
FOR clause only allows one Mailbox (or Path), it isn't clear if that FOR clause only allows one Mailbox (or Path), it isn't clear if that
statement is meaningful. Should it be revised to discuss other statement is meaningful. Should it be revised to discuss other
situations in which including FOR might not be desirable from a situations in which including FOR might not be desirable from a
security or privacy standpoint? (See above -- this paragraph security or privacy standpoint? (See above -- this paragraph
deliberately not changed in -04). deliberately not changed in -04).
Ticket #55 Ticket #55
G.15. Resistance to Attacks and Operational Necessity G.15. Resistance to Attacks and Operational Necessity (closed)
Section 7.8 is often cited as allowing an exception to the rules of Section 7.8 is often cited as allowing an exception to the rules of
the specification for reasons of operational necessity, not just the specification for reasons of operational necessity, not just
attack resistance. I (JcK) believe the broader interpretation was attack resistance. I (JcK) believe the broader interpretation was
intended by YAM (the section was new in RFC 5321). Recommendation: intended by YAM (the section was new in RFC 5321). Recommendation:
change the title to explicitly include "Local Operational change the title to explicitly include "Local Operational
Requirements" and add text to indicate that attack resistance is not Requirements" and add text to indicate that attack resistance is not
the only possible source of such requirements. the only possible source of such requirements.
Ticket #48 (done, closed)
G.16. Mandatory 8BITMIME G.16. Mandatory 8BITMIME
There was extensive discussion on the mailing list in October 2021 There was extensive discussion on the mailing list in October 2021
about messages with and without 8-bit (i.e., octets with the leading about messages with and without 8-bit (i.e., octets with the leading
on) content and a tentative conclusion that support for 8BITMIME on) content and a tentative conclusion that support for 8BITMIME
should be required. If that is the WG's conclusion, we need to should be required. If that is the WG's conclusion, we need to
figure out what to say and where to say it. figure out what to say and where to say it.
Appendix H. RFC 5321 Errata Summary and Tentative Change Log Appendix H. RFC 5321 Errata Summary and Tentative Change Log
[[RFC Editor: Please remove this section before publication.]] [[RFC Editor: Please remove this section before publication.]]
H.1. RFC 5321 Errata Summary H.1. RFC 5321 Errata Summary
This document addresses the following errata filed against RFC 5321 This document addresses the following errata filed against RFC 5321
since its publication in October 2008 [54]. As with the previous since its publication in October 2008 [54]. As with the previous
appendix, ticket numbers included below reference appendix, ticket numbers included below reference
https://trac.ietf.org/trac/emailcore/report/1 . https://trac.ietf.org/trac/emailcore/report/1 .
// [[Note in Draft: Items with comments below have not yet been // [[Note in Draft: Unless marked "closed", items with comments below
// resolved as errata. As of the end of November 2020, none of them // have not yet been resolved as errata.]]
// have been checked and verified by the emailcore WG.]]
1683 ABNF error. Section 4.4 1683 ABNF error. (closed) Section 4.4
Ticket #23. Ticket #23 (fixed, closed).
4198 Description error. Section 4.2. 4198 Description error. (closed) Section 4.2.
RESOLVED, ticket #24, 2020-12-14. RESOLVED 2020-12-14, ticket #24 (closed).
2578 Syntax description error. Section 4.1.2 2578 Syntax description error. (closed) Section 4.1.2
Ticket #25 (fixed, closed)
1543 Wrong code in description Section 3.8 1543 Wrong code in description (closed) Section 3.8
Ticket #26 Ticket #26 (fixed, closed)
4315 ABNF - IPv6 Section 4.1.3. 4315 ABNF - IPv6 Section 4.1.3 (closed).
// [5321bis]The IPv6 syntax has been adjusted since 5321 was // [5321bis]The IPv6 syntax has been adjusted since 5321 was
// published (the erratum mentions RFC 5952, but RFC 6874 and // published (the erratum mentions RFC 5952, but RFC 6874 and
draft- draft-
// carpenter-6man-rfc6874bis should also be considered). See the // carpenter-6man-rfc6874bis should also be considered). See the
// rewritten form and the comment in the section cited in the // rewritten form and the comment in the section cited in the
// previous sentence, at least for the RFC 5952 issues. The // previous sentence, at least for the RFC 5952 issues. The
editor editor
// awaits instructions. See https://www.rfc-editor.org/errata/ // awaits instructions. See https://www.rfc-editor.org/errata/
// eid4315 // eid4315
Ticket #27. Ticket #27 (closed 2021-01-19).
5414 ABNF for Quoted-string Section 4.1.2 5414 ABNF for Quoted-string (closed) Section 4.1.2
Ticket #22. Ticket #22 (fixed, closed).
1851 Location of text on unexpected close Section 4.1.1.5. Text 1851 Location of text on unexpected close Section 4.1.1.5 (closed).
moved per email 2020-12-31. Text moved per email 2020-12-31.
Ticket #28. Ticket #28 (fixed, closed).
3447 Use of normative language (e.g., more "MUST"s), possible 3447 Use of normative language (e.g., more "MUST"s), possible
confusion in some sections Section 4.4. confusion in some sections Section 4.4.
Ticket #7 Ticket #7
// [5321bis]As Barry notes in his verifier comments on the erratum // [5321bis]As Barry notes in his verifier comments on the erratum
// (see https://www.rfc-editor.org/errata/eid3447), the comments // (see https://www.rfc-editor.org/errata/eid3447), the comments
and and
// suggestions here raise a number of interesting (and difficult) // suggestions here raise a number of interesting (and difficult)
// issues. One of the issues is that the core of RFCs 5321 (and // issues. One of the issues is that the core of RFCs 5321 (and
skipping to change at page 111, line 41 skipping to change at page 110, line 41
different different
// point in Barry's discussion, I think an explicit statement that // point in Barry's discussion, I think an explicit statement that
// 5321/5322 and their predecessors differ in places and why would // 5321/5322 and their predecessors differ in places and why would
be be
// helpful. Text, and suggestions about where to put it, are // helpful. Text, and suggestions about where to put it, are
// solicited. A list of differences might be a good idea too, but // solicited. A list of differences might be a good idea too, but
// getting it right might be more work than there is available // getting it right might be more work than there is available
energy energy
// to do correctly. // to do correctly.
5711 Missing leading spaces in example Appendix D.3. 5711 Missing leading spaces in example Appendix D.3 (closed).
// [5321bis]Well, this is interesting because the XML is correct // [5321bis]Well, this is interesting because the XML is correct
and and
// the spaces are there, embedded in artwork. So either the // the spaces are there, embedded in artwork. So either the
XML2RFC XML2RFC
// processor at the time took those leading spaces out or the RFC // processor at the time took those leading spaces out or the RFC
// Editor improved on the document and the change was not caught // Editor improved on the document and the change was not caught
in in
// AUTH48, perhaps because rfcdiff ignores white space. We just // AUTH48, perhaps because rfcdiff ignores white space. We just
need need
// to watch for future iterations. // to watch for future iterations.
As of 2021-03-15, both the txt and html-ized versions of draft- As of 2021-03-15, both the txt and html-ized versions of draft-
ietf-emailcore-rfc5321bis-02 were showing identical output for ietf-emailcore-rfc5321bis-02 were showing identical output for
both parts of the example, so the problem appears to be OBE at both parts of the example, so the problem appears to be OBE at
worst. worst.
Ticket #29 (closed 2021-03-16) Ticket #29 (closed 2021-03-16)
4055 Erratum claims the the description of SPF and DKIM is wrong. 4055 (closed) Erratum claims the the description of SPF and DKIM is
It is not clear what 5321bis should really say about them, but the wrong. It is not clear what 5321bis should really say about them,
current text probably needs work (or dropping, which is what the but the current text probably needs work (or dropping, which is
proposed erratum suggests). what the proposed erratum suggests).
Text changed; ticket should probably be closed after WG reviews Text changed; ticket should probably be closed after WG reviews
-04. -04.
Ticket #30 (resolved??). 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
* Acknowledgments section (Section 9) trimmed back for new document. * Acknowledgments section (Section 9) trimmed back for new document.
skipping to change at page 116, line 42 skipping to change at page 115, line 42
(Ticket #5) (Ticket #5)
* Modified Appendix G.8 to add a note about the normative status of * Modified Appendix G.8 to add a note about the normative status of
RFC 3463 and moved that reference. RFC 3463 and moved that reference.
* Several clarifications to initiation and termination of mail * Several clarifications to initiation and termination of mail
transactions in Section 4.1.4. transactions in Section 4.1.4.
* Several additional minor editorial improvements. * Several additional minor editorial improvements.
* Note for drafts -03 and -04 only, modified somewhat for -05: Some * Note for drafts -03 and -04 only, modified somewhat for -05 but
issues are still outstanding: Notes were posted to the list on outdated from -06 forward: Some issues are still outstanding:
2021-07-09 about tickets #7 (closed?), #10, #14 (closed), #20, Notes were posted to the list on 2021-07-09 about tickets #7
#30, and #42. Even though some comments about them appeared in (5322bis issue), #10 , #14 (closed), #20 (closed), #30 (closed),
the subsequent day or so, there appears to have been insufficient and #42 (closed). Even though some comments about them appeared
time for discussions to stabilize sufficiently for changes to be in the subsequent day or so, there appears to have been
included in this version of the I-D. insufficient time for discussions to stabilize sufficiently for
changes to be included in this version of the I-D.
H.3.8. Changes from draft-ietf-emailcore-rfc5321bis-03 (2021-07-10) to H.3.8. Changes from draft-ietf-emailcore-rfc5321bis-03 (2021-07-10) to
-04 -04
* Clarified that the "period" in <CRLF>.<CRLF> is really the ASCII * Clarified that the "period" in <CRLF>.<CRLF> is really the ASCII
one in Section 3.3. one in Section 3.3.
// Editor's note: change treated as Editorial without a ticket. // Editor's note: change treated as Editorial without a ticket.
If If
// there are objections, speak up. // there are objections, speak up.
skipping to change at page 118, line 9 skipping to change at page 117, line 13
possible action. possible action.
* Additional changes to the description and organization of trace * Additional changes to the description and organization of trace
field materials. Intended to resolve the 5321bis part of Ticket field materials. Intended to resolve the 5321bis part of Ticket
#7. #7.
* Remaining patch to SEND, etc., discussion in Appendix F.6 applied * Remaining patch to SEND, etc., discussion in Appendix F.6 applied
and CREF removed. and CREF removed.
* Removed discussion of "X-" and edited associated text. The fix * Removed discussion of "X-" and edited associated text. The fix
may or may not be sufficient to resolve Ticket #42. may or may not be sufficient to resolve Ticket #42 (later closed).
* Verified that the problems of getting four-level sections (e.g., * Verified that the problems of getting four-level sections (e.g.,
"4.1.1.1" and other command-specific ones) into the table of "4.1.1.1" and other command-specific ones) into the table of
contents and the index reflecting page numbers still exist and contents and the index reflecting page numbers still exist and
updated the introductory note. updated the introductory note.
H.3.10. Changes from draft-ietf-emailcore-rfc5321bis-05 (2021-10-24) to H.3.10. Changes from draft-ietf-emailcore-rfc5321bis-05 (2021-10-24) to
-06 -06
* Finished making changes for "X-" and commands starting in "X". * Finished making changes for "X-" and commands starting in "X".
skipping to change at page 118, line 48 skipping to change at page 118, line 5
* Updated Appendix G.7.17 and slightly modified CREF note in * Updated Appendix G.7.17 and slightly modified CREF note in
Section 2 -- proposed to not get 5321bis involved with this Section 2 -- proposed to not get 5321bis involved with this
(Ticket #50). (Ticket #50).
* Rewrote parts of Section 3.9 to clarify text amd respond to Ticket * Rewrote parts of Section 3.9 to clarify text amd respond to Ticket
#34. #34.
* Inserted suggested text info CREF at end of Section 1.2. Comments * Inserted suggested text info CREF at end of Section 1.2. Comments
welcome. Soon. welcome. Soon.
H.3.11. Changes from draft-ietf-emailcore-rfc5321bis-06 (2021-11-07) to
-07
* Reviewed closed tickets and discussion with co-chairs after IETF
112 and updated text. Sections or items that are, according to
the ticket list, completely closed have been identified by
"(closed)" in or near their titles.
* Changed the suggestion for references to other documents mentioned
in G.7.14 and Section 1.2 to actual text. Cleaned things up and,
per note from Alexey 2021-11-17, have marked Ticket #53 as closed.
* New text added and old text replaced about quotes in
Section 4.1.2, text rearranged and edited a bit per Appendix G.9,
and CREF added about alternatives. Changes reflect mailing list
comments through
* Last sentence (about source routing) removed from Section 2.1.
Also adjusted text in Section 3.3, Section 4.1.1.3 but work is
still needed there (see new CREFs in that section) and
Section 6.1. The former Appendix C and references to it have been
removed, leaving a placeholder to avoid changing subsequent
appendix numbering before IETF Last Call (and maybe its
completion) No changes have yet been made to Appendix F.2 but it
is likely to require some work in the next version of the
document. This is all about Ticket #17, which should not be
closed until that appendix is updated.
Index Index
A C A C
A A
Argument Syntax Argument Syntax
A-d-l Section 4.1.2
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
Addtl-Protocol Section 4.4.1 Addtl-Protocol Section 4.4.1
Argument Section 4.1.2 Argument Section 4.1.2
At-domain Section 4.1.2 At-domain Section 4.1.2
Atom Section 4.1.2 Atom Section 4.1.2
By-domain Section 4.4.1 By-domain Section 4.4.1
CFWS Section 4.1.2, Paragraph 2, Item 2 CFWS Section 4.1.2, Paragraph 2, Item 2
CRLF Section 4.1.2, Paragraph 2, Item 1 CRLF Section 4.1.2, Paragraph 2, Item 1
skipping to change at page 120, line 33 skipping to change at page 120, line 18
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 17 rcpt Section 4.1.1.3, Paragraph 18
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
Author's Address Author's Address
John C. Klensin John C. Klensin
1770 Massachusetts Ave, Suite 322 1770 Massachusetts Ave, Suite 322
Cambridge, MA 02140 Cambridge, MA 02140
United States of America United States of America
 End of changes. 118 change blocks. 
329 lines changed or deleted 280 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/