< draft-ietf-emailcore-rfc5321bis-00.txt   draft-ietf-emailcore-rfc5321bis-01.txt >
EMAILCORE J. Klensin EMAILCORE J. Klensin
Internet-Draft October 6, 2020 Internet-Draft December 25, 2020
Obsoletes: 5321, 1846, 7504 (if Obsoletes: 5321, 1846, 7504 (if
approved) approved)
Updates: 1123 (if approved) Updates: 1123 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: April 9, 2021 Expires: June 28, 2021
Simple Mail Transfer Protocol Simple Mail Transfer Protocol
draft-ietf-emailcore-rfc5321bis-00 draft-ietf-emailcore-rfc5321bis-01
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. Although SMTP was designed as a mail particular extensions. Although SMTP was designed as a mail
transport and delivery protocol, this specification also contains transport and delivery protocol, this specification also contains
skipping to change at page 2, line 23 skipping to change at page 2, line 23
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 April 9, 2021. This Internet-Draft will expire on June 28, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 52 skipping to change at page 2, line 52
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1. Transport of Electronic Mail . . . . . . . . . . . . . . 6 1.1. Transport of Electronic Mail . . . . . . . . . . . . . . 6
1.2. History and Context for This Document . . . . . . . . . . 6 1.2. History and Context for This Document . . . . . . . . . . 6
1.3. Document Conventions . . . . . . . . . . . . . . . . . . 7 1.3. Document Conventions . . . . . . . . . . . . . . . . . . 7
2. The SMTP Model . . . . . . . . . . . . . . . . . . . . . . . 8 2. The SMTP Model . . . . . . . . . . . . . . . . . . . . . . . 8
2.1. Basic Structure . . . . . . . . . . . . . . . . . . . . . 8 2.1. Basic Structure . . . . . . . . . . . . . . . . . . . . . 8
2.2. The Extension Model . . . . . . . . . . . . . . . . . . . 10 2.2. The Extension Model . . . . . . . . . . . . . . . . . . . 10
2.2.1. Background . . . . . . . . . . . . . . . . . . . . . 10 2.2.1. Background . . . . . . . . . . . . . . . . . . . . . 10
2.2.2. Definition and Registration of Extensions . . . . . . 11 2.2.2. Definition and Registration of Extensions . . . . . . 11
2.2.3. Special Issues with Extensions . . . . . . . . . . . 12 2.2.3. Special Issues with Extensions . . . . . . . . . . . 12
2.3. SMTP Terminology . . . . . . . . . . . . . . . . . . . . 12 2.3. SMTP Terminology . . . . . . . . . . . . . . . . . . . . 13
2.3.1. Mail Objects . . . . . . . . . . . . . . . . . . . . 13 2.3.1. Mail Objects . . . . . . . . . . . . . . . . . . . . 13
2.3.2. Senders and Receivers . . . . . . . . . . . . . . . . 13 2.3.2. Senders and Receivers . . . . . . . . . . . . . . . . 13
2.3.3. Mail Agents and Message Stores . . . . . . . . . . . 13 2.3.3. Mail Agents and Message Stores . . . . . . . . . . . 13
2.3.4. Host . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3.4. Host . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.5. Domain Names . . . . . . . . . . . . . . . . . . . . 14 2.3.5. Domain Names . . . . . . . . . . . . . . . . . . . . 14
2.3.6. Buffer and State Table . . . . . . . . . . . . . . . 15 2.3.6. Buffer and State Table . . . . . . . . . . . . . . . 15
2.3.7. Commands and Replies . . . . . . . . . . . . . . . . 15 2.3.7. Commands and Replies . . . . . . . . . . . . . . . . 15
2.3.8. Lines . . . . . . . . . . . . . . . . . . . . . . . . 16 2.3.8. Lines . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3.9. Message Content and Mail Data . . . . . . . . . . . . 16 2.3.9. Message Content and Mail Data . . . . . . . . . . . . 16
2.3.10. Originator, Delivery, Relay, and Gateway Systems . . 16 2.3.10. Originator, Delivery, Relay, and Gateway Systems . . 16
2.3.11. Mailbox and Address . . . . . . . . . . . . . . . . . 17 2.3.11. Mailbox and Address . . . . . . . . . . . . . . . . . 17
2.4. General Syntax Principles and Transaction Model . . . . . 17 2.4. General Syntax Principles and Transaction Model . . . . . 17
3. The SMTP Procedures: An Overview . . . . . . . . . . . . . . 19 3. The SMTP Procedures: An Overview . . . . . . . . . . . . . . 19
3.1. Session Initiation . . . . . . . . . . . . . . . . . . . 19 3.1. Session Initiation . . . . . . . . . . . . . . . . . . . 19
3.2. Client Initiation . . . . . . . . . . . . . . . . . . . . 20 3.2. Client Initiation . . . . . . . . . . . . . . . . . . . . 20
3.3. Mail Transactions . . . . . . . . . . . . . . . . . . . . 20 3.3. Mail Transactions . . . . . . . . . . . . . . . . . . . . 20
3.4. Forwarding for Address Correction or Updating . . . . . . 23 3.4. Forwarding for Address Correction or Updating . . . . . . 23
3.5. Commands for Debugging Addresses . . . . . . . . . . . . 24 3.5. Commands for Debugging Addresses . . . . . . . . . . . . 24
3.5.1. Overview . . . . . . . . . . . . . . . . . . . . . . 24 3.5.1. Overview . . . . . . . . . . . . . . . . . . . . . . 24
3.5.2. VRFY Normal Response . . . . . . . . . . . . . . . . 26 3.5.2. VRFY Normal Response . . . . . . . . . . . . . . . . 26
3.5.3. Meaning of VRFY or EXPN Success Response . . . . . . 26 3.5.3. Meaning of VRFY or EXPN Success Response . . . . . . 27
3.5.4. Semantics and Applications of EXPN . . . . . . . . . 27 3.5.4. Semantics and Applications of EXPN . . . . . . . . . 27
3.6. Relaying and Mail Routing . . . . . . . . . . . . . . . . 27 3.6. Relaying and Mail Routing . . . . . . . . . . . . . . . . 27
3.6.1. Source Routes and Relaying . . . . . . . . . . . . . 27 3.6.1. Source Routes and Relaying . . . . . . . . . . . . . 27
3.6.2. Mail eXchange Records and Relaying . . . . . . . . . 28 3.6.2. Mail eXchange Records and Relaying . . . . . . . . . 28
3.6.3. Message Submission Servers as Relays . . . . . . . . 28 3.6.3. Message Submission Servers as Relays . . . . . . . . 29
3.7. Mail Gatewaying . . . . . . . . . . . . . . . . . . . . . 29 3.7. Mail Gatewaying . . . . . . . . . . . . . . . . . . . . . 30
3.7.1. Header Fields in Gatewaying . . . . . . . . . . . . . 30 3.7.1. Header Fields in Gatewaying . . . . . . . . . . . . . 30
3.7.2. Received Lines in Gatewaying . . . . . . . . . . . . 30 3.7.2. Received Lines in Gatewaying . . . . . . . . . . . . 30
3.7.3. Addresses in Gatewaying . . . . . . . . . . . . . . . 30 3.7.3. Addresses in Gatewaying . . . . . . . . . . . . . . . 31
3.7.4. Other Header Fields in Gatewaying . . . . . . . . . . 31 3.7.4. Other Header Fields in Gatewaying . . . . . . . . . . 31
3.7.5. Envelopes in Gatewaying . . . . . . . . . . . . . . . 31 3.7.5. Envelopes in Gatewaying . . . . . . . . . . . . . . . 31
3.8. Terminating Sessions and Connections . . . . . . . . . . 31 3.8. Terminating Sessions and Connections . . . . . . . . . . 31
3.9. Mailing Lists and Aliases . . . . . . . . . . . . . . . . 32 3.9. Mailing Lists and Aliases . . . . . . . . . . . . . . . . 32
3.9.1. Alias . . . . . . . . . . . . . . . . . . . . . . . . 33 3.9.1. Alias . . . . . . . . . . . . . . . . . . . . . . . . 33
3.9.2. List . . . . . . . . . . . . . . . . . . . . . . . . 33 3.9.2. List . . . . . . . . . . . . . . . . . . . . . . . . 33
4. The SMTP Specifications . . . . . . . . . . . . . . . . . . . 33 4. The SMTP Specifications . . . . . . . . . . . . . . . . . . . 33
4.1. SMTP Commands . . . . . . . . . . . . . . . . . . . . . . 33 4.1. SMTP Commands . . . . . . . . . . . . . . . . . . . . . . 33
4.1.1. Command Semantics and Syntax . . . . . . . . . . . . 33 4.1.1. Command Semantics and Syntax . . . . . . . . . . . . 33
4.1.2. Command Argument Syntax . . . . . . . . . . . . . . . 42 4.1.2. Command Argument Syntax . . . . . . . . . . . . . . . 42
4.1.3. Address Literals . . . . . . . . . . . . . . . . . . 44 4.1.3. Address Literals . . . . . . . . . . . . . . . . . . 44
4.1.4. Order of Commands . . . . . . . . . . . . . . . . . . 45 4.1.4. Order of Commands . . . . . . . . . . . . . . . . . . 46
4.1.5. Private-Use Commands . . . . . . . . . . . . . . . . 47 4.1.5. Private-Use Commands . . . . . . . . . . . . . . . . 47
4.2. SMTP Replies . . . . . . . . . . . . . . . . . . . . . . 47 4.2. SMTP Replies . . . . . . . . . . . . . . . . . . . . . . 48
4.2.1. Reply Code Severities and Theory . . . . . . . . . . 49 4.2.1. Reply Code Severities and Theory . . . . . . . . . . 49
4.2.2. Reply Codes by Function Groups . . . . . . . . . . . 52 4.2.2. Reply Codes by Function Groups . . . . . . . . . . . 52
4.2.3. Reply Codes in Numeric Order . . . . . . . . . . . . 53 4.2.3. Reply Codes in Numeric Order . . . . . . . . . . . . 53
4.2.4. Some specific code situations and relationships . . . 55 4.2.4. Some specific code situations and relationships . . . 55
4.3. Sequencing of Commands and Replies . . . . . . . . . . . 56 4.3. Sequencing of Commands and Replies . . . . . . . . . . . 56
4.3.1. Sequencing Overview . . . . . . . . . . . . . . . . . 56 4.3.1. Sequencing Overview . . . . . . . . . . . . . . . . . 56
4.3.2. Command-Reply Sequences . . . . . . . . . . . . . . . 57 4.3.2. Command-Reply Sequences . . . . . . . . . . . . . . . 57
4.4. Trace Information . . . . . . . . . . . . . . . . . . . . 59 4.4. Trace Information . . . . . . . . . . . . . . . . . . . . 59
4.5. Additional Implementation Issues . . . . . . . . . . . . 63 4.5. Additional Implementation Issues . . . . . . . . . . . . 63
4.5.1. Minimum Implementation . . . . . . . . . . . . . . . 63 4.5.1. Minimum Implementation . . . . . . . . . . . . . . . 63
4.5.2. Transparency . . . . . . . . . . . . . . . . . . . . 64 4.5.2. Transparency . . . . . . . . . . . . . . . . . . . . 64
4.5.3. Sizes and Timeouts . . . . . . . . . . . . . . . . . 65 4.5.3. Sizes and Timeouts . . . . . . . . . . . . . . . . . 65
4.5.4. Retry Strategies . . . . . . . . . . . . . . . . . . 69 4.5.4. Retry Strategies . . . . . . . . . . . . . . . . . . 69
4.5.5. Messages with a Null Reverse-Path . . . . . . . . . . 71 4.5.5. Messages with a Null Reverse-Path . . . . . . . . . . 71
5. Address Resolution and Mail Handling . . . . . . . . . . . . 71 5. Address Resolution and Mail Handling . . . . . . . . . . . . 71
5.1. Locating the Target Host . . . . . . . . . . . . . . . . 71 5.1. Locating the Target Host . . . . . . . . . . . . . . . . 72
5.2. IPv6 and MX Records . . . . . . . . . . . . . . . . . . . 73 5.2. IPv6 and MX Records . . . . . . . . . . . . . . . . . . . 74
6. Problem Detection and Handling . . . . . . . . . . . . . . . 74 6. Problem Detection and Handling . . . . . . . . . . . . . . . 74
6.1. Reliable Delivery and Replies by Email . . . . . . . . . 74 6.1. Reliable Delivery and Replies by Email . . . . . . . . . 74
6.2. Unwanted, Unsolicited, and "Attack" Messages . . . . . . 75 6.2. Unwanted, Unsolicited, and "Attack" Messages . . . . . . 75
6.3. Loop Detection . . . . . . . . . . . . . . . . . . . . . 76 6.3. Loop Detection . . . . . . . . . . . . . . . . . . . . . 76
6.4. Compensating for Irregularities . . . . . . . . . . . . . 76 6.4. Compensating for Irregularities . . . . . . . . . . . . . 76
7. Security Considerations . . . . . . . . . . . . . . . . . . . 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 78
7.1. Mail Security and Spoofing . . . . . . . . . . . . . . . 77 7.1. Mail Security and Spoofing . . . . . . . . . . . . . . . 78
7.2. "Blind" Copies . . . . . . . . . . . . . . . . . . . . . 78 7.2. "Blind" Copies . . . . . . . . . . . . . . . . . . . . . 79
7.3. VRFY, EXPN, and Security . . . . . . . . . . . . . . . . 79 7.3. VRFY, EXPN, and Security . . . . . . . . . . . . . . . . 79
7.4. Mail Rerouting Based on the 251 and 551 Response 7.4. Mail Rerouting Based on the 251 and 551 Response
Codes . . . . . . . . . . . . . . . . . . . . . . . . . . 80 Codes . . . . . . . . . . . . . . . . . . . . . . . . . . 80
7.5. Information Disclosure in Announcements . . . . . . . . . 80 7.5. Information Disclosure in Announcements . . . . . . . . . 80
7.6. Information Disclosure in Trace Fields . . . . . . . . . 80 7.6. Information Disclosure in Trace Fields . . . . . . . . . 81
7.7. Information Disclosure in Message Forwarding . . . . . . 80 7.7. Information Disclosure in Message Forwarding . . . . . . 81
7.8. Resistance to Attacks . . . . . . . . . . . . . . . . . . 81 7.8. Resistance to Attacks . . . . . . . . . . . . . . . . . . 81
7.9. Scope of Operation of SMTP Servers . . . . . . . . . . . 81 7.9. Scope of Operation of SMTP Servers . . . . . . . . . . . 81
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 82
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 83 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 83
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 84
10.1. Normative References . . . . . . . . . . . . . . . . . . 83 10.1. Normative References . . . . . . . . . . . . . . . . . . 84
10.2. Informative References . . . . . . . . . . . . . . . . . 84 10.2. Informative References . . . . . . . . . . . . . . . . . 85
Appendix A. TCP Transport Service . . . . . . . . . . . . . . . 89 Appendix A. TCP Transport Service . . . . . . . . . . . . . . . 90
Appendix B. Generating SMTP Commands from RFC 822 Header Fields 89 Appendix B. Generating SMTP Commands from RFC 822 Header Fields 90
Appendix C. Source Routes . . . . . . . . . . . . . . . . . . . 90 Appendix C. Source Routes . . . . . . . . . . . . . . . . . . . 91
Appendix D. Scenarios . . . . . . . . . . . . . . . . . . . . . 91 Appendix D. Scenarios . . . . . . . . . . . . . . . . . . . . . 92
D.1. A Typical SMTP Transaction Scenario . . . . . . . . . . . 91 D.1. A Typical SMTP Transaction Scenario . . . . . . . . . . . 92
D.2. Aborted SMTP Transaction Scenario . . . . . . . . . . . . 92 D.2. Aborted SMTP Transaction Scenario . . . . . . . . . . . . 93
D.3. Relayed Mail Scenario . . . . . . . . . . . . . . . . . . 93 D.3. Relayed Mail Scenario . . . . . . . . . . . . . . . . . . 94
D.4. Verifying and Sending Scenario . . . . . . . . . . . . . 94 D.4. Verifying and Sending Scenario . . . . . . . . . . . . . 95
Appendix E. Other Gateway Issues . . . . . . . . . . . . . . . . 95 Appendix E. Other Gateway Issues . . . . . . . . . . . . . . . . 96
Appendix F. Deprecated Features of RFC 821 . . . . . . . . . . . 95 Appendix F. Deprecated Features of RFC 821 . . . . . . . . . . . 96
F.1. TURN . . . . . . . . . . . . . . . . . . . . . . . . . . 95 F.1. TURN . . . . . . . . . . . . . . . . . . . . . . . . . . 96
F.2. Source Routing . . . . . . . . . . . . . . . . . . . . . 95 F.2. Source Routing . . . . . . . . . . . . . . . . . . . . . 96
F.3. HELO . . . . . . . . . . . . . . . . . . . . . . . . . . 96 F.3. HELO . . . . . . . . . . . . . . . . . . . . . . . . . . 97
F.4. #-literals . . . . . . . . . . . . . . . . . . . . . . . 96 F.4. #-literals . . . . . . . . . . . . . . . . . . . . . . . 97
F.5. Dates and Years . . . . . . . . . . . . . . . . . . . . . 96 F.5. Dates and Years . . . . . . . . . . . . . . . . . . . . . 97
F.6. Sending versus Mailing . . . . . . . . . . . . . . . . . 96 F.6. Sending versus Mailing . . . . . . . . . . . . . . . . . 97
Appendix G. Other Outstanding Issues . . . . . . . . . . . . . . 97 Appendix G. Other Outstanding Issues . . . . . . . . . . . . . . 98
G.1. IP Address Literals . . . . . . . . . . . . . . . . . . . 98 G.1. IP Address literals . . . . . . . . . . . . . . . . . . . 99
G.2. Repeated Use of EHLO . . . . . . . . . . . . . . . . . . 98 G.2. Repeated Use of EHLO . . . . . . . . . . . . . . . . . . 99
G.3. Meaning of "MTA" and Related Terminology . . . . . . . . 98 G.3. Meaning of "MTA" and Related Terminology . . . . . . . . 99
G.4. Originator, or Originating System, Authentication . . . . 98 G.4. Originator, or Originating System, Authentication . . . . 100
G.5. Remove or deprecate the work-around from code 552 to 452 99 G.5. Remove or deprecate the work-around from code 552 to 452 100
G.6. Clarify where the protocol stands with respect to G.6. Clarify where the protocol stands with respect to
submission and TLS issues . . . . . . . . . . . . . . . . 99 submission and TLS issues . . . . . . . . . . . . . . . . 100
G.7. Probably-substantive Discussion Topics Identified in G.7. Probably-substantive Discussion Topics Identified in
Other Ways . . . . . . . . . . . . . . . . . . . . . . . 99 Other Ways . . . . . . . . . . . . . . . . . . . . . . . 100
G.7.1. Issues with 521, 554, and 556 codes . . . . . . . . . 99 G.7.1. Issues with 521, 554, and 556 codes . . . . . . . . . 100
G.7.2. SMTP Model, terminology, and relationship to RFC 5598 99 G.7.2. SMTP Model, terminology, and relationship to RFC 5598 101
G.7.3. Resolvable FQDNs and private domain names . . . . . . 99 G.7.3. Resolvable FQDNs and private domain names . . . . . . 101
G.7.4. Possible clarification about mail transactions and G.7.4. Possible clarification about mail transactions and
transaction state . . . . . . . . . . . . . . . . . . 99 transaction state . . . . . . . . . . . . . . . . . . 101
G.7.5. Issues with mailing lists, aliases, and forwarding . 100 G.7.5. Issues with mailing lists, aliases, and forwarding . 101
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 . . . . . . . . . . . . . . . . . . . . . . . . 100 EHLO . . . . . . . . . . . . . . . . . . . . . . . . 101
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? . . . . . . . . . . . . 100 code text need clarification? . . . . . . . . . . . . 101
G.7.8. Size limits . . . . . . . . . . . . . . . . . . . . . 100 G.7.8. Size limits . . . . . . . . . . . . . . . . . . . . . 101
G.7.9. Discussion of 'blind' copies and RCPT . . . . . . . . 100 G.7.9. Discussion of 'blind' copies and RCPT . . . . . . . . 102
G.7.10. Further clarifications needed to source routes? . . . 100 G.7.10. Further clarifications needed to source routes? . . . 102
G.7.11. Should 1yz Be Revisited? . . . . . . . . . . . . . . 100 G.7.11. Should 1yz Be Revisited? . . . . . . . . . . . . . . 102
G.7.12. Review Timeout Specifications . . . . . . . . . . . . 100 G.7.12. Review Timeout Specifications . . . . . . . . . . . . 102
G.8. Enhanced Reply Codes and DSNs . . . . . . . . . . . . . . 101 G.7.13. Possible SEND, SAML, SOML Loose End . . . . . . . . . 102
G.9. Revisiting Quoted Strings . . . . . . . . . . . . . . . . 101 G.8. Enhanced Reply Codes and DSNs . . . . . . . . . . . . . . 102
G.10. Internationalization . . . . . . . . . . . . . . . . . . 101 G.9. Revisiting Quoted Strings . . . . . . . . . . . . . . . . 103
G.11. SMTP Clients, Servers, Senders, and Receivers . . . . . . 102 G.10. Internationalization . . . . . . . . . . . . . . . . . . 103
Appendix H. Change log for RFC 5321bis . . . . . . . . . . . . . 102 G.11. SMTP Clients, Servers, Senders, and Receivers . . . . . . 104
H.1. RFC 5321 Errata Summary . . . . . . . . . . . . . . . . . 102 G.12. Extension Keywords Starting in 'X-' . . . . . . . . . . . 104
G.13. Deprecating HELO . . . . . . . . . . . . . . . . . . . . 104
Appendix H. RFC 5321 Errata Summary and Tentative Change Log . . 104
H.1. RFC 5321 Errata Summary . . . . . . . . . . . . . . . . . 104
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 . . . . . . . . . . . 103 initial (-00) version of this draft . . . . . . . . . . . 106
H.3. Changes Among Versions of Rfc5321bis . . . . . . . . . . 105 H.3. Changes Among Versions of Rfc5321bis . . . . . . . . . . 107
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 . . . . . . . . . . . . . . . . . 105 2012-12-02) to -01 . . . . . . . . . . . . . . . . . 107
H.3.2. Changes from draft-klensin-rfc5321bis-01 (20191203) H.3.2. Changes from draft-klensin-rfc5321bis-01 (20191203)
to -02 . . . . . . . . . . . . . . . . . . . . . . . 105 to -02 . . . . . . . . . . . . . . . . . . . . . . . 107
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 . . . . . . . . . . . . . . . . . . . . . . . 105 to -03 . . . . . . . . . . . . . . . . . . . . . . . 108
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 . . . . . . . . 106 to draft-ietf-emailcore-rfc5321bis-00 . . . . . . . . 108
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 H.3.5. Changes from draft-ietf-emailcore-rfc5321bis-00
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 108 (2020-10-06) to -01 . . . . . . . . . . . . . . . . . 108
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 111
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.
SMTP is independent of the particular transmission subsystem and SMTP is independent of the particular transmission subsystem and
requires only a reliable ordered data stream channel. While this requires only a reliable ordered data stream channel. While this
skipping to change at page 20, line 34 skipping to change at page 20, line 36
3.3. Mail Transactions 3.3. Mail Transactions
There are three steps to SMTP mail transactions. The transaction There are three steps to SMTP mail transactions. The transaction
starts with a MAIL command that gives the sender identification. (In starts with a MAIL command that gives the sender identification. (In
general, the MAIL command may be sent only when no mail transaction general, the MAIL command may be sent only when no mail transaction
is in progress; see Section 4.1.4.) A series of one or more RCPT is in progress; see Section 4.1.4.) A series of one or more RCPT
commands follows, giving the receiver information. Then, a DATA commands follows, giving the receiver information. Then, a DATA
command initiates transfer of the mail data and is terminated by the command initiates transfer of the mail data and is terminated by the
"end of mail" data indicator, which also confirms the transaction. "end of mail" data indicator, which also confirms the transaction.
Mail transactions are also terminated by the RSET command
(Section 4.1.1.5), the sending of an EHLO command (Section 3.2), or
the sending of a QUIT command (Section 3.8) which terminates both any
active mail transaction and the SMTP connection.
The first step in the procedure is the MAIL command. The first step in the procedure is the MAIL command.
MAIL FROM:<reverse-path> [SP <mail-parameters> ] <CRLF> MAIL FROM:<reverse-path> [SP <mail-parameters> ] <CRLF>
This command tells the SMTP-receiver that a new mail transaction is This command tells the SMTP-receiver that a new mail transaction is
starting and to reset all its state tables and buffers, including any starting and to reset all its state tables and buffers, including any
recipients or mail data. The <reverse-path> portion of the first or recipients or mail data. The <reverse-path> portion of the first or
only argument contains the source mailbox (between "<" and ">" only argument contains the source mailbox (between "<" and ">"
brackets), which can be used to report errors (see Section 4.2 for a brackets), which can be used to report errors (see Section 4.2 for a
discussion of error reporting). If accepted, the SMTP server returns discussion of error reporting). If accepted, the SMTP server returns
skipping to change at page 43, line 37 skipping to change at page 43, line 47
QcontentSMTP = qtextSMTP / quoted-pairSMTP QcontentSMTP = qtextSMTP / quoted-pairSMTP
quoted-pairSMTP = %d92 %d32-126 quoted-pairSMTP = %d92 %d32-126
; i.e., backslash followed by any ASCII ; i.e., backslash followed by any ASCII
; 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 blackslash-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
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 host that expects to receive mail
SHOULD avoid defining mailboxes where the Local-part requires (or SHOULD avoid defining mailboxes where the Local-part requires (or
uses) the Quoted-string form or where the Local-part is case- uses) the Quoted-string form or where the Local-part is case-
sensitive. For any purposes that require generating or comparing sensitive. For any purposes that require generating or comparing
Local-parts (e.g., to specific mailbox names), all quoted forms MUST Local-parts (e.g., to specific mailbox names), all quoted forms MUST
be treated as equivalent, and the sending system SHOULD transmit the be treated as equivalent, and the sending system SHOULD transmit the
form that uses the minimum quoting possible. form that uses the minimum quoting possible.
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
skipping to change at page 46, line 8 skipping to change at page 46, line 18
used. used.
A session that will contain mail transactions MUST first be A session that will contain mail transactions MUST first be
initialized by the use of the EHLO command. An SMTP server SHOULD initialized by the use of the EHLO command. An SMTP server SHOULD
accept commands for non-mail transactions (e.g., VRFY, EXPN, or NOOP) accept commands for non-mail transactions (e.g., VRFY, EXPN, or NOOP)
without this initialization. without this initialization.
An EHLO command MAY be issued by a client later in the session. If An EHLO command MAY be issued by a client later in the session. If
it is issued after the session begins and the EHLO command is it is issued after the session begins and the EHLO command is
acceptable to the SMTP server, the SMTP server MUST clear all buffers acceptable to the SMTP server, the SMTP server MUST clear all buffers
and reset the state exactly as if a RSET command had been issued. In and reset the state exactly as if a RSET command had been issued
other words, the sequence of RSET followed immediately by EHLO is (specifically, it terminates any mail transaction that was in
redundant, but not harmful other than in the performance cost of progress, see Section 3.3). In other words, the sequence of RSET
executing unnecessary commands. followed immediately by EHLO is redundant, but not harmful other than
in the performance cost of executing unnecessary commands. However
the response to an additional EHLO command MAY be different from that
from prior ones; the client MUST rely only on the responses from the
most recent EHLO command.
If the EHLO command is not acceptable to the SMTP server, 501, 500, If the EHLO command is not acceptable to the SMTP server, 501, 500,
502, or 550 failure replies MUST be returned as appropriate. The 502, or 550 failure replies MUST be returned as appropriate. The
SMTP server MUST stay in the same state after transmitting these SMTP server MUST stay in the same state after transmitting these
replies that it was in before the EHLO was received. replies that it was in before the EHLO was received.
The SMTP client MUST, if possible, ensure that the domain parameter The SMTP client MUST, if possible, ensure that the domain parameter
to the EHLO command is a primary host name as specified for this to the EHLO command is a primary host name as specified for this
command in Section 2.3.5. If this is not possible (e.g., when the command in Section 2.3.5. If this is not possible (e.g., when the
client's address is dynamically assigned and the client does not have client's address is dynamically assigned and the client does not have
skipping to change at page 46, line 50 skipping to change at page 47, line 17
servers SHOULD process these normally (that is, not return a 503 servers SHOULD process these normally (that is, not return a 503
code) even if no EHLO command has yet been received; clients SHOULD code) even if no EHLO command has yet been received; clients SHOULD
open a session with EHLO before sending these commands. open a session with EHLO before sending these commands.
If these rules are followed, the example in RFC 821 that shows "550 If these rules are followed, the example in RFC 821 that shows "550
access denied to you" in response to an EXPN command is incorrect access denied to you" in response to an EXPN command is incorrect
unless an EHLO command precedes the EXPN or the denial of access is unless an EHLO command precedes the EXPN or the denial of access is
based on the client's IP address or other authentication or based on the client's IP address or other authentication or
authorization-determining mechanisms. authorization-determining mechanisms.
The MAIL command (or the obsolete SEND, SOML, or SAML commands) The MAIL command begins a mail transaction. Once started, a mail
transaction consists of a transaction beginning command, one or more
[[5321bis Editor's Note: is there any reason to not clean those RCPT commands, and a DATA command, in that order. A mail transaction
commands out of this entirely, replacing them with, e.g., a strong may be aborted by the RSET, a new EHLO, or the QUIT command. There
reference to Appendix F.6]] may be zero or more transactions in a session. MAIL MUST NOT be sent
begins a mail transaction. Once started, a mail transaction consists if a mail transaction is already open, i.e., it should be sent only
of a transaction beginning command, one or more RCPT commands, and a if no mail transaction had been started in the session, or if the
DATA command, in that order. A mail transaction may be aborted by previous one successfully concluded with a successful DATA command,
the RSET, a new EHLO, or the QUIT command. There may be zero or more or if the previous one was aborted, e.g., with a RSET or new EHLO.
transactions in a session. MAIL (or SEND, SOML, or SAML) MUST NOT be [[CREF14: [5321bis] 2821ter note: see comment about changing this
sent if a mail transaction is already open, i.e., it should be sent convoluted discussion to talk about 'mail transaction' above.
only if no mail transaction had been started in the session, or if
the previous one successfully concluded with a successful DATA
command, or if the previous one was aborted, e.g., with a RSET or new
EHLO. [[CREF14: [5321bis] 2821ter note: see comment about changing
this convoluted discussion to talk about 'mail transaction' above.
--Jck]] --Jck]]
If the transaction beginning command argument is not acceptable, a If the transaction beginning command argument is not acceptable, a
501 failure reply MUST be returned and the SMTP server MUST stay in 501 failure reply MUST be returned and the SMTP server MUST stay in
the same state. If the commands in a transaction are out of order to the same state. If the commands in a transaction are out of order to
the degree that they cannot be processed by the server, a 503 failure the degree that they cannot be processed by the server, a 503 failure
reply MUST be returned and the SMTP server MUST stay in the same reply MUST be returned and the SMTP server MUST stay in the same
state. state.
The last command in a session MUST be the QUIT command. The QUIT The last command in a session MUST be the QUIT command. The QUIT
skipping to change at page 62, line 14 skipping to change at page 62, line 24
"undeliverable mail" notification message to the originator of the "undeliverable mail" notification message to the originator of the
message. message.
A single notification listing all of the failed recipients or A single notification listing all of the failed recipients or
separate notification messages MUST be sent for each failed separate notification messages MUST be sent for each failed
recipient. For economy of processing by the sender, the former recipient. For economy of processing by the sender, the former
SHOULD be used when possible. Note that the key difference between SHOULD be used when possible. Note that the key difference between
handling aliases (Section 3.9.1) and forwarding (this subsection) is handling aliases (Section 3.9.1) and forwarding (this subsection) is
the change to the backward-pointing address in this case. All the change to the backward-pointing address in this case. All
notification messages about undeliverable mail MUST be sent using the notification messages about undeliverable mail MUST be sent using the
MAIL command (even if they result from processing the obsolete SEND, MAIL command and MUST use a null return path as discussed in
SOML, or SAML commands) and MUST use a null return path as discussed Section 3.6.
in Section 3.6.
The time stamp line and the return path line are formally defined as The time stamp line and the return path line are formally defined as
follows (the definitions for "FWS" and "CFWS" appear in RFC 5322 follows (the definitions for "FWS" and "CFWS" appear in RFC 5322
[11]): [11]):
Return-path-line = "Return-Path:" FWS Reverse-path <CRLF> Return-path-line = "Return-Path:" FWS Reverse-path <CRLF>
Time-stamp-line = "Received:" FWS Stamp <CRLF> Time-stamp-line = "Received:" FWS Stamp <CRLF>
Stamp = From-domain By-domain Opt-info [CFWS] ";" Stamp = From-domain By-domain Opt-info [CFWS] ";"
skipping to change at page 79, line 8 skipping to change at page 79, line 28
extension header fields. [[CREF26: [rfc5321bis] [[Note in draft - extension header fields. [[CREF26: [rfc5321bis] [[Note in draft -
Suggestion from 20070124 that got lost: delete "especially" and "the Suggestion from 20070124 that got lost: delete "especially" and "the
full set of" -- copying the first one can be as harmful as copying full set of" -- copying the first one can be as harmful as copying
all of them, at least without verifying that the addresses do appear all of them, at least without verifying that the addresses do appear
in the headers.]] Arnt Gulbrandsen, arnt@oryx.com, 2007.01.24 in the headers.]] Arnt Gulbrandsen, arnt@oryx.com, 2007.01.24
1121+0100]] Since this rule is often violated in practice, and cannot 1121+0100]] Since this rule is often violated in practice, and cannot
be enforced, sending SMTP systems that are aware of "bcc" use MAY be enforced, sending SMTP systems that are aware of "bcc" use MAY
find it helpful to send each blind copy as a separate message find it helpful to send each blind copy as a separate message
transaction containing only a single RCPT command. transaction containing only a single RCPT command.
There is no inherent relationship between either "reverse" (from There is no inherent relationship between either "reverse" (from the
MAIL, SAML, etc., commands) or "forward" (RCPT) addresses in the SMTP MAIL command) or "forward" (RCPT) addresses in the SMTP transaction
transaction ("envelope") and the addresses in the header section. ("envelope") and the addresses in the header section. Receiving
Receiving systems SHOULD NOT attempt to deduce such relationships and systems SHOULD NOT attempt to deduce such relationships and use them
use them to alter the header section of the message for delivery. to alter the header section of the message for delivery. The popular
The popular "Apparently-to" header field is a violation of this "Apparently-to" header field is a violation of this principle as well
principle as well as a common source of unintended information as a common source of unintended information disclosure and SHOULD
disclosure and SHOULD NOT be used. NOT be used.
7.3. VRFY, EXPN, and Security 7.3. VRFY, EXPN, and Security
As discussed in Section 3.5, individual sites may want to disable As discussed in Section 3.5, individual sites may want to disable
either or both of VRFY or EXPN for security reasons (see below). As either or both of VRFY or EXPN for security reasons (see below). As
a corollary to the above, implementations that permit this MUST NOT a corollary to the above, implementations that permit this MUST NOT
appear to have verified addresses that are not, in fact, verified. appear to have verified addresses that are not, in fact, verified.
If a site disables these commands for security reasons, the SMTP If a site disables these commands for security reasons, the SMTP
server MUST return a 252 response, rather than a code that could be server MUST return a 252 response, rather than a code that could be
confused with successful or unsuccessful verification. confused with successful or unsuccessful verification.
skipping to change at page 83, line 22 skipping to change at page 83, line 39
Those contributions of course include the original specification of Those contributions of course include the original specification of
SMTP in RFC 821. A considerable quantity of text from RFC 821 still SMTP in RFC 821. A considerable quantity of text from RFC 821 still
appears in this document as do several of Jon's original examples appears in this document as do several of Jon's original examples
that have been updated only as needed to reflect other changes in the that have been updated only as needed to reflect other changes in the
specification. specification.
The following filed errata against RFC 5321 that were not rejected at The following filed errata against RFC 5321 that were not rejected at
the time of submission: Jasen Betts, Adrien de Croy Guillaume Fortin- the time of submission: Jasen Betts, Adrien de Croy Guillaume Fortin-
Debigare Roberto Javier Godoy, David Romerstein, Dominic Sayers, Debigare Roberto Javier Godoy, David Romerstein, Dominic Sayers,
Rodrigo Speller, Alessandro Vesely, and Brett Watson. In addition, Rodrigo Speller, Alessandro Vesely, and Brett Watson. In addition,
specific suggestions that led to corrections and improvements in this specific suggestions that led to corrections and improvements in
version were received from Ned Freed, Barry Leiba, Ivar Lumi, Pete early versions of the current specification were received from Ned
Resnick, and others. Freed, Barry Leiba, Ivar Lumi, Pete Resnick, Hector Santos, Paul
Smith and others.
chetti contributed an analysis that clarify the ABNF productions that chetti contributed an analysis that clarified the ABNF productions
implicitly reference other document. that implicitly reference other documents.
[[CREF27: Most errata and comments after 2019-07-01 have not yet been [[CREF27: Some errata and comments after 2019-07-01 have not yet been
captured in this version of the draft. ]] captured in this version of the draft. ]]
The EMAILCORE Working Group was chartered in September 2020 with
Alexey Melnikov and Seth Blank and co-chairs. Without their
leadership and technical contributions, this document would never
have been completed.
10. References 10. References
10.1. Normative References 10.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate [1] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[2] American National Standards Institute (formerly United [2] American National Standards Institute (formerly United
skipping to change at page 96, line 47 skipping to change at page 97, line 47
the Internet mail system. the Internet mail system.
F.6. Sending versus Mailing F.6. Sending versus Mailing
In addition to specifying a mechanism for delivering messages to In addition to specifying a mechanism for delivering messages to
user's mailboxes, RFC 821 provided additional, optional, commands to user's mailboxes, RFC 821 provided additional, optional, commands to
deliver messages directly to the user's terminal screen. These deliver messages directly to the user's terminal screen. These
commands (SEND, SAML, SOML) were rarely implemented, and changes in commands (SEND, SAML, SOML) were rarely implemented, and changes in
workstation technology and the introduction of other protocols may workstation technology and the introduction of other protocols may
have rendered them obsolete even where they are implemented. have rendered them obsolete even where they are implemented.
[[5321bis Editor's Note: does this need a stronger reference to 821,
2821, and/or 5321?]]
[[5321bis Editor's Note: does this need a stronger reference to 821,
2821, and/or 5321? Also, is anything else needed given the removal
of these commands and comments about, e.g., their opening mail
transaction sessions, from the mail body of the text?]]
Clients SHOULD NOT provide SEND, SAML, or SOML as services. Servers Clients SHOULD NOT provide SEND, SAML, or SOML as services. Servers
MAY implement them. If they are implemented by servers, the MAY implement them. If they are implemented by servers, the
implementation model specified in RFC 821 MUST be used and the implementation model specified in RFC 821 MUST be used and the
command names MUST be published in the response to the EHLO command. command names MUST be published in the response to the EHLO command.
Appendix G. Other Outstanding Issues Appendix G. Other Outstanding Issues
[[RFC Editor: Please remove this section before publication.]] [[RFC Editor: Please remove this section before publication.]]
In December 2019, an issue was raised on the ietf-smtp@ietf.org list In December 2019, an issue was raised on the ietf-smtp@ietf.org list
skipping to change at page 97, line 44 skipping to change at page 98, line 46
made to fix them (and where) or to ignore them and let them continue. made to fix them (and where) or to ignore them and let them continue.
There has also been discussion on the mailing list, perhaps amounting There has also been discussion on the mailing list, perhaps amounting
to very rough consensus, that any revision of RFC 5321 and/or 5322 to very rough consensus, that any revision of RFC 5321 and/or 5322
should be accompanied by a separate Applicability Statement document should be accompanied by a separate Applicability Statement document
that would make recommendations about applicability or best practices that would make recommendations about applicability or best practices
in particular areas rather than trying to get everything into the two in particular areas rather than trying to get everything into the two
technical specifications. This appendix does not attempt to identify technical specifications. This appendix does not attempt to identify
which issues should get which treatment. which issues should get which treatment.
Until and unless there is a WG with appropriate leadership and This work is now (starting in the last half of 2020) being considered
tracking mechanisms, this appendix will act as a temporary record of in the EMAILCORE WG. This appendix will act as a temporary record of
issues that should be discussed and decided upon before a revised issues that should be discussed and decided upon before a revised
SMTP specification (or a related Applicability Statement) is SMTP specification (or a related Applicability Statement) is
published, issues that have not been reflected in errata (see published, issues that have not been reflected in errata (see
Appendix H.1 below for those covered by errata). Appendix H.1 below for those covered by errata).
G.1. IP Address Literals Ticket numbers listed below reference the list in
https://trac.ietf.org/trac/emailcore/report/1 .
G.1. IP Address literals
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.
G.2. Repeated Use of EHLO G.2. Repeated Use of EHLO
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
easiest fix to these problems is to clarify the conditions for
termination of a mail transaction in Section 3.3 and to clearly
specify the effect of a second (or subsequent) EHLO command in
Section 4.1.4.
See also Appendix G.7.4.
Ticket #2. Both changes have been made in draft-ietf-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"
and "SMTP server" respectively. As things have evolved, it is and "SMTP server" respectively. As things have evolved, it is
possible that newer terminology is a source of confusion and that the possible that newer terminology is a source of confusion and that the
terminology should be changed back, something that also needs terminology should be changed back, something that also needs
discussion. discussion.
Ticket #3.
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.
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
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.
G.6. Clarify where the protocol stands with respect to submission and G.6. Clarify where the protocol stands with respect to submission and
TLS issues TLS issues
1. submission on port 587 1. submission on port 587
2. submission on port 465 2. submission on port 465
3. TLS relay on a port different from 25 (whenever) 3. TLS relay on a port different from 25 (whenever)
skipping to change at page 99, line 35 skipping to change at page 100, line 48
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 earlier but called out specifically only in embedded CREF comments in earlier
(-00 and -01) versions of this draft. (-00 and -01) versions of this draft.
G.7.1. Issues with 521, 554, and 556 codes G.7.1. Issues with 521, 554, and 556 codes
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. to EHLO, especially to deal with selective policy rejections.
Ticket #6.
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 and also CREF comment in Section 2.3.10 CREF comment in Section 2 and also CREF comment in Section 2.3.10
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.
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.
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. email address portability issue. Note that, if changes are made in
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
as Section 3.4 to avoid introducing inconsistencies. In addition,
there are some terminology issues about the use of the term "lists",
identified in erratum 1820, that should be reviewed after any more
substantive changes are made to the relevant sections.
Ticket #12 and Ticket #34.
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
CREF comment in Section 4.1.4 CREF comment in Section 4.1.4
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?
CREF comments in Section 4.2 and Section 4.3.1 CREF comments in Section 4.2 and Section 4.3.1
Ticket #13.
G.7.8. Size limits G.7.8. Size limits
CREF comment in Section 4.5.3 Once a decision is made about line length rules for RFC 5322bis,
review the size limit discussions in this document, particularly the
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
say.
Ticket #14 and maybe Ticket #38.
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 alto 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.
G.7.10. Further clarifications needed to source routes? G.7.10. Further clarifications needed to source routes?
CREF comment in Appendix C The current text largely deprecates the use of source routes but
suggests that servers continue to support them. Is additional work
needed in this area? See CREF comment in Appendix C
Ticket #17.
G.7.11. Should 1yz Be Revisited? G.7.11. Should 1yz Be Revisited?
RFC 5421 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.
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.
G.7.13. Possible SEND, SAML, SOML Loose End
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
discussion of them now appears in Appendix F.6. Per the editor's
note in that appendix, is any further discussion needed?
G.8. Enhanced Reply Codes and DSNs G.8. Enhanced Reply Codes and DSNs
Enhanced Mail System Status Codes [34] were added to SMTP before RFC Enhanced Mail System Status Codes [34] were added to SMTP before RFC
5321 was published and are now, together with a corresponding 5321 was published and are now, together with a corresponding
registry [46], widely deployed and in extensive use in the network. registry [46], widely deployed and in extensive use in the network.
Similar, the structure and extensions options for Delivery Status Similar, the structure and extensions options for Delivery Status
Notifications [35] is implemented, deployed, and in wide use. Is it Notifications [35] is implemented, deployed, and in wide use. Is it
time to fold all or part of those mature specifications into the SMTP time to fold all or part of those mature specifications into the SMTP
spec or at least to mention and normatively reference them? And, as spec or at least to mention and normatively reference them? And, as
an aside do those specs need work or, if they are kept separate, is an aside, do those specs need work or, if they are kept separate, is
it time to move them to Internet Standard? it time to move them to Internet Standard?
G.9. Revisiting Quoted Strings G.9. Revisiting Quoted Strings
Recent discussions both in and out of the IETF have highlighted Recent discussions both in and out of the IETF have highlighted
instances of non-compliance with the specification of a Local-part instances of non-compliance with the specification of a Local-part
consisting of a Quoted-string, whether any content of QcontentSMTP consisting of a Quoted-string, whether any content of QcontentSMTP
that actually requires special treatment consists of qtextSMTP, that actually requires special treatment consists of qtextSMTP,
quoted-pairSMTP, or both. Section 4.1.2 (of RFC 5321, repeated quoted-pairSMTP, or both. Section 4.1.2 (of RFC 5321, repeated
above) ends with a few paragraphs of warnings (essentially a partial above) ends with a few paragraphs of warnings (essentially a partial
skipping to change at page 101, line 40 skipping to change at page 103, line 32
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.
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
use of non-ASCII characters. Would it be appropriate to add use of non-ASCII characters. Would it be appropriate to add
skipping to change at page 102, line 23 skipping to change at page 104, line 17
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?
Appendix H. Change log for RFC 5321bis G.12. Extension 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
reason to not deprecate that practice entirely and remove that text?
If we do so, should Section 4.1.5 be dropped or rewritten to make
clear this is an obsolete practice?
Ticket #42.
G.13. Deprecating HELO
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
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
clean out some or all of that text? And, given a recent (4Q2020)
discussion on the EMAILCORE list, should EHLO be explicitly bound to
SMTP over TCP with the older transports allowed only with HELO?
While those questions may seem independent, separating them is fairly
hard given the way the text is now constructed.
Ticket #43.
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 [52] [[CREF31: [[Note in Draft: since its publication in October 2008 [52]. As with the previous
Items with comments below have not yet been resolved.]]]] appendix, ticket numbers included below reference
https://trac.ietf.org/trac/emailcore/report/1 . [[CREF31: [[Note in
Draft: Items with comments below have not yet been resolved as
errata. As of the end of November 2020, none of them have been
checked and verified by the emailcore WG.]]]].
1683 ABNF error. Section 4.4 1683 ABNF error. Section 4.4
Ticket #23.
4198 Description error. Section 4.2 4198 Description error. Section 4.2.
RESOLVED, ticket #24, 2020-12-14.
2578 Syntax description error. Section 4.1.2 2578 Syntax description error. Section 4.1.2
1543 Wrong code in description Section 3.8 1543 Wrong code in description Section 3.8
Ticket #26
4315 ABNF - IPv6 Section 4.1.3. [[CREF32: [5321bis]The IPv6 syntax 4315 ABNF - IPv6 Section 4.1.3. [[CREF32: [5321bis]The IPv6 syntax
has been adjusted since 5321 was published. See the rewritten has been adjusted since 5321 was published. See the rewritten
form and the comment in the section cited in the previous form and the comment in the section cited in the previous
sentence. The editor awaits instructions. See https://www.rfc- sentence. The editor awaits instructions. See https://www.rfc-
editor.org/errata/eid4315]] editor.org/errata/eid4315]]
Ticket #27.
5414 ABNF for Quoted-string Section 4.1.2 5414 ABNF for Quoted-string Section 4.1.2
Ticket #22.
1851 Location of text on unexpected close Section 4.1.1.5. 1851 Location of text on unexpected close Section 4.1.1.5.
[[CREF33: [5321bis]Matter of taste, editor seeks advice.]] [[CREF33: [5321bis]Matter of taste, editor seeks advice.]]
Ticket #28.
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. [[CREF34: [5321bis]As confusion in some sections Section 4.4. [[CREF34: [5321bis]As
Barry notes in his verifier comments on the erratum (see Barry notes in his verifier comments on the erratum (see
https://www.rfc-editor.org/errata/eid3447), the comments and https://www.rfc-editor.org/errata/eid3447), the comments 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
2821) is text carried over from Jon Postel's RFC 821, a document 2821) is text carried over from Jon Postel's RFC 821, a document
that was not only written in a different style than the IETF uses that was not only written in a different style than the IETF uses
today but that was written at a time when no one had dreamt of RFC today but that was written at a time when no one had dreamt of RFC
skipping to change at page 103, line 33 skipping to change at page 106, line 9
getting it right might be more work than there is available energy getting it right might be more work than there is available energy
to do correctly. ]] to do correctly. ]]
5711 Missing leading spaces in example Appendix D.3. [[CREF35: 5711 Missing leading spaces in example Appendix D.3. [[CREF35:
[5321bis]Well, this is interesting because the XML is correct and [5321bis]Well, this is interesting because the XML is correct and
the spaces are there, embedded in artwork. So either the XML2RFC the spaces are there, embedded in artwork. So either the 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 in Editor improved on the document and the change was not caught in
AUTH48, perhaps because rfcdiff ignores white space. We just need AUTH48, perhaps because rfcdiff ignores white space. We just need
to watch for future iterations. ]] to watch for future iterations. ]]
Ticket #29.
4055 Erratum claims the the description of SPF and DKIM is wrong.
It is not clear what 5321bis should really say about them, but the
current text probably needs work (or dropping, which is what the
proposed erratum suggests). See 5321bis Editor's Note in
Section 3.6.2.
Ticket #30.
[[CREF36: [5321bis]Note that rejected errata have _not_ been reviewed [[CREF36: [5321bis]Note that rejected errata have _not_ been reviewed
to see if they contain anything useful that should be discussed again to see 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
o Acknowledgments section (Section 9) trimmed back for new document. o Acknowledgments section (Section 9) trimmed back for new document.
skipping to change at page 106, line 16 skipping to change at page 108, line 44
ietf-emailcore-rfc5321bis-00 ietf-emailcore-rfc5321bis-00
o Added a paragraph about non-null quoted strings to Appendix G.9. o Added a paragraph about non-null quoted strings to Appendix G.9.
o Added an explicit pointer to email insecurity and TLS to o Added an explicit pointer to email insecurity and TLS to
Appendix G.6. Inspired by Ben Kaduk's comment on the WG Charter, Appendix G.6. Inspired by Ben Kaduk's comment on the WG Charter,
2020-09-09. 2020-09-09.
o Converted document from individual to emailcore WG effort. o Converted document from individual to emailcore WG effort.
H.3.5. Changes from draft-ietf-emailcore-rfc5321bis-00 (2020-10-06) to
-01
o Editorial: Corrected "blackslash" to "backslash"
o Rewrote the introduction to Appendix G slightly to reflect the
creation of the EMAILCORE WG.
o Applied fixes for repeated use of EHLO. See Appendix G.2.
o Added two new questions, one about "X" extensions (Appendix G.12)
and one about the status of HELO (Appendix G.13).
o Removed mention of SEND, SAML, SOML from the main body of the text
(Ticket #20).
o Added a warning about side effects to Appendix G.7.5.
o Added ticket numbers to descriptions of issues and changes,
adjusted some text so relationships would be more clear, and added
subsections to the Appendix G and H lists to pick up on tickets
that were not easily identified in those sections of with the
text.
o Made several additions to the Index, including one to deal with
SEND et al., as above.
Index Index
A A
Argument Syntax Argument Syntax
A-d-l 42 A-d-l 42
Additional-Registered-Clauses 63 Additional-Registered-Clauses 63
address-literal 43 address-literal 43
Addtl-Link 63 Addtl-Link 63
Addtl-Protocol 63 Addtl-Protocol 63
ALPHA 42 ALPHA 42
Argument 42 Argument 43
At-domain 42 At-domain 42
atext 42 atext 42
Atom 43 Atom 43
By-domain 62 By-domain 62
CFWS 42 CFWS 42
CRLF 42 CRLF 42
dcontent 45 dcontent 45
DIGIT 42 DIGIT 42
Domain 43 Domain 43
Dot-string 43 Dot-string 43
esmtp-keyword 42 esmtp-keyword 42
esmtp-param 42 esmtp-param 42
esmtp-value 42 esmtp-value 43
Extended-Domain 62 Extended-Domain 62
For 63 For 63
Forward-Path 42 Forward-Path 42
From-domain 62 From-domain 62
FWS 42 FWS 42
General-address-literal 45 General-address-literal 45
Greeting 48 Greeting 48
h16 45 h16 45
HEXDIG 42 HEXDIG 42
ID 63 ID 63
IPv4-address-literal 45 IPv4-address-literal 45
IPv6-addr 45 IPv6-addr 45
IPv6-address-literal 45 IPv6-address-literal 45
Keyword 42 Keyword 43
Ldh-str 43 Ldh-str 43
Let-dig 43 Let-dig 43
Link 63 Link 63
Local-part 43 Local-part 43
ls32 45 ls32 45
Mail-parameters 42 Mail-parameters 42
Mailbox 43 Mailbox 43
Opt-info 62 Opt-info 63
Path 42 Path 42
Protocol 63 Protocol 63
QcontentSMTP 43 QcontentSMTP 43
qtextSMTP 43 qtextSMTP 43
quoted-pairSMTP 43 quoted-pairSMTP 43
Quoted-string 43 Quoted-string 43
Rcpt-parameters 42 Rcpt-parameters 42
Reply-code 48 Reply-code 48
Reply-line 48 Reply-line 48
Return-path-line 62 Return-path-line 62
Reverse-Path 42 Reverse-Path 42
Snum 45 Snum 45
SP 42 SP 42
Stamp 62 Stamp 62
Standardized-tag 45 Standardized-tag 45
String 43 String 43
sub-domain 43 sub-domain 43
TCP-info 62 TCP-info 62
textstring 48 textstring 48
Time-stamp-line 62 Time-stamp-line 62
Via 62 Via 63
With 62 With 63
C C
Command Syntax Command Syntax
data 39 data 39
ehlo 20, 34
expn 40 expn 40
help 40 helo 34
help 41
mail 36 mail 36
noop 41 noop 41
quit 41 quit 41
rcpt 38 rcpt 38
rset 39 rset 40
send, saml, soml 102
vrfy 40 vrfy 40
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
USA USA
EMail: john-ietf@jck.com EMail: john-ietf@jck.com
 End of changes. 78 change blocks. 
134 lines changed or deleted 266 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/