< draft-ietf-emailcore-rfc5321bis-01.txt   draft-ietf-emailcore-rfc5321bis-02.txt >
EMAILCORE J. Klensin EMAILCORE J. Klensin
Internet-Draft December 25, 2020 Internet-Draft February 21, 2021
Obsoletes: 5321, 1846, 7504 (if Obsoletes: 5321, 1846, 7504 (if
approved) approved)
Updates: 1123 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: June 28, 2021 Expires: August 25, 2021
Simple Mail Transfer Protocol Simple Mail Transfer Protocol
draft-ietf-emailcore-rfc5321bis-01 draft-ietf-emailcore-rfc5321bis-02
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
information that is important to its use as a "mail submission" information that is important to its use as a "mail submission"
protocol for "split-UA" (User Agent) mail reading systems and mobile protocol for "split-UA" (User Agent) mail reading systems and mobile
environments. This document replaces the earlier version with the environments. This document replaces the earlier version with the
same title in RFC 5321. same title in RFC 5321.
[[CREF1: Note in Draft: Except for the last sentence, the above is [[CREF1: Note in Draft: Except for the last sentence, the above is
unchanged from 5321 and may need adjusting in the light of RFC 6409 unchanged from 5321 and may need adjusting in the light of RFC 6409
as an Internet Standard.]] (Message Submission) as an Internet Standard.]]
Note on Reading This Working Draft Note on Reading This Working Draft
This working draft is extensively annotated with information about This working draft is extensively annotated with information about
changes made over the decade since RFC 5321 appeared, especially when changes made over the decade since RFC 5321 appeared, especially when
those changes might be controversial or should get careful review. those changes might be controversial or should get careful review.
Anything marked in CREF comments with "[5321bis]" is current. In Anything marked in CREF comments with "[5321bis]" is current. In
general, unless those are marked with "[[Note in Draft", in the general, unless those are marked with "[[Note in Draft", in the
contents of an "Editor's note", or are in the "Errata Summary" contents of an "Editor's note", or are in the "Errata Summary"
appendix (Appendix H.1, they are just notes on changes that have appendix (Appendix H.1, they are just notes on changes that have
already been made and where those changes originated. Comments already been made and where those changes originated. Comments
identified as "2821ter" arose after the Last Call on what became identified as "2821ter" arose after the Last Call on what became
RFC5321, sometimes before AUTH48 on that document or a bit later. RFC5321, sometimes before AUTH48 on that document or a bit later.
Those, of course, should still be reviewed. Surviving comments about Those, of course, should still be reviewed. Surviving comments about
rfc5321bis-00 followed by a letter indicate intermediate working rfc5321bis-00 followed by a letter indicate intermediate working
versions of this draft and can be ignored unless the origin of versions of this draft and can be ignored unless the origin of
changes is important. As one can tell from the dates (when they are changes is important. As one can tell from the dates (when they are
given), this document has been periodically updated over a very long given), this document has been periodically updated over a very long
period of time. period of time.
This evolving draft should be discussed on the ietf-smtp@ietf.org As people review or try to use this document, it may be worth paying
special attention to the historical discussion in Section 1.2. The
decision to merge documents rather than do a complete rewrite was
motivated by weighing the risks of inadvertently introducing changes
against greater readability and deciding to preserve close
approximations to original text and document structures in most
cases. One result is that information may not be be organized as the
reader might expect. An index is provided to assist in the quest for
information.
This evolving draft should be discussed on the emailcore@ietf.org
list. list.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 June 28, 2021. This Internet-Draft will expire on August 25, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 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 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
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 . . . . . . . . . . 7
1.3. Document Conventions . . . . . . . . . . . . . . . . . . 7 1.3. Document Conventions . . . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . . . . . . . . . . . 11
2.2.1. Background . . . . . . . . . . . . . . . . . . . . . 10 2.2.1. Background . . . . . . . . . . . . . . . . . . . . . 11
2.2.2. Definition and Registration of Extensions . . . . . . 11 2.2.2. Definition and Registration of Extensions . . . . . . 12
2.2.3. Special Issues with Extensions . . . . . . . . . . . 12 2.2.3. Special Issues with Extensions . . . . . . . . . . . 13
2.3. SMTP Terminology . . . . . . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . . . 14
2.3.3. Mail Agents and Message Stores . . . . . . . . . . . 13 2.3.3. Mail Agents and Message Stores . . . . . . . . . . . 14
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 . . . . . . . . . . . . . . . 16
2.3.7. Commands and Replies . . . . . . . . . . . . . . . . 15 2.3.7. Commands and Replies . . . . . . . . . . . . . . . . 16
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 . . 17
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 . . . . . 18
3. The SMTP Procedures: An Overview . . . . . . . . . . . . . . 19 3. The SMTP Procedures: An Overview . . . . . . . . . . . . . . 19
3.1. Session Initiation . . . . . . . . . . . . . . . . . . . 19 3.1. Session Initiation . . . . . . . . . . . . . . . . . . . 20
3.2. Client Initiation . . . . . . . . . . . . . . . . . . . . 20 3.2. Client Initiation . . . . . . . . . . . . . . . . . . . . 20
3.3. Mail Transactions . . . . . . . . . . . . . . . . . . . . 20 3.3. Mail Transactions . . . . . . . . . . . . . . . . . . . . 21
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 . . . . . . . . . . . . . . . . 27
3.5.3. Meaning of VRFY or EXPN Success Response . . . . . . 27 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 . . . . . . . . . 28
3.6. Relaying and Mail Routing . . . . . . . . . . . . . . . . 27 3.6. Relaying and Mail Routing . . . . . . . . . . . . . . . . 28
3.6.1. Source Routes and Relaying . . . . . . . . . . . . . 27 3.6.1. Source Routes and Relaying . . . . . . . . . . . . . 28
3.6.2. Mail eXchange Records and Relaying . . . . . . . . . 28 3.6.2. Mail eXchange Records and Relaying . . . . . . . . . 29
3.6.3. Message Submission Servers as Relays . . . . . . . . 29 3.6.3. Message Submission Servers as Relays . . . . . . . . 29
3.7. Mail Gatewaying . . . . . . . . . . . . . . . . . . . . . 30 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 . . . . . . . . . . . . 31
3.7.3. Addresses in Gatewaying . . . . . . . . . . . . . . . 31 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 . . . . . . . . . . . . . . . 32
3.8. Terminating Sessions and Connections . . . . . . . . . . 31 3.8. Terminating Sessions and Connections . . . . . . . . . . 32
3.9. Mailing Lists and Aliases . . . . . . . . . . . . . . . . 32 3.9. Mailing Lists and Aliases . . . . . . . . . . . . . . . . 33
3.9.1. Alias . . . . . . . . . . . . . . . . . . . . . . . . 33 3.9.1. Alias . . . . . . . . . . . . . . . . . . . . . . . . 33
3.9.2. List . . . . . . . . . . . . . . . . . . . . . . . . 33 3.9.2. List . . . . . . . . . . . . . . . . . . . . . . . . 34
4. The SMTP Specifications . . . . . . . . . . . . . . . . . . . 33 4. The SMTP Specifications . . . . . . . . . . . . . . . . . . . 34
4.1. SMTP Commands . . . . . . . . . . . . . . . . . . . . . . 33 4.1. SMTP Commands . . . . . . . . . . . . . . . . . . . . . . 34
4.1.1. Command Semantics and Syntax . . . . . . . . . . . . 33 4.1.1. Command Semantics and Syntax . . . . . . . . . . . . 34
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 . . . . . . . . . . . . . . . . . . 45
4.1.4. Order of Commands . . . . . . . . . . . . . . . . . . 46 4.1.4. Order of Commands . . . . . . . . . . . . . . . . . . 46
4.1.5. Private-Use Commands . . . . . . . . . . . . . . . . 47 4.1.5. Private-Use Commands . . . . . . . . . . . . . . . . 48
4.2. SMTP Replies . . . . . . . . . . . . . . . . . . . . . . 48 4.2. SMTP Replies . . . . . . . . . . . . . . . . . . . . . . 48
4.2.1. Reply Code Severities and Theory . . . . . . . . . . 49 4.2.1. Reply Code Severities and Theory . . . . . . . . . . 50
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 . . . . . . . . . . . . 54
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 . . . . . . . . . . . 57
4.3. Sequencing of Commands and Replies . . . . . . . . . . . 56 4.3.1. Sequencing Overview . . . . . . . . . . . . . . . . . 57
4.3.1. Sequencing Overview . . . . . . . . . . . . . . . . . 56 4.3.2. Command-Reply Sequences . . . . . . . . . . . . . . . 58
4.3.2. Command-Reply Sequences . . . . . . . . . . . . . . . 57 4.4. Trace Information . . . . . . . . . . . . . . . . . . . . 60
4.4. Trace Information . . . . . . . . . . . . . . . . . . . . 59 4.5. Additional Implementation Issues . . . . . . . . . . . . 64
4.5. Additional Implementation Issues . . . . . . . . . . . . 63 4.5.1. Minimum Implementation . . . . . . . . . . . . . . . 64
4.5.1. Minimum Implementation . . . . . . . . . . . . . . . 63 4.5.2. Transparency . . . . . . . . . . . . . . . . . . . . 65
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 . . . . . . . . . . . . 72
5.1. Locating the Target Host . . . . . . . . . . . . . . . . 72 5.1. Locating the Target Host . . . . . . . . . . . . . . . . 72
5.2. IPv6 and MX Records . . . . . . . . . . . . . . . . . . . 74 5.2. IPv6 and MX Records . . . . . . . . . . . . . . . . . . . 74
6. Problem Detection and Handling . . . . . . . . . . . . . . . 74 6. Problem Detection and Handling . . . . . . . . . . . . . . . 75
6.1. Reliable Delivery and Replies by Email . . . . . . . . . 74 6.1. Reliable Delivery and Replies by Email . . . . . . . . . 75
6.2. Unwanted, Unsolicited, and "Attack" Messages . . . . . . 75 6.2. Unwanted, Unsolicited, and "Attack" Messages . . . . . . 76
6.3. Loop Detection . . . . . . . . . . . . . . . . . . . . . 76 6.3. Loop Detection . . . . . . . . . . . . . . . . . . . . . 77
6.4. Compensating for Irregularities . . . . . . . . . . . . . 76 6.4. Compensating for Irregularities . . . . . . . . . . . . . 77
7. Security Considerations . . . . . . . . . . . . . . . . . . . 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 78
7.1. Mail Security and Spoofing . . . . . . . . . . . . . . . 78 7.1. Mail Security and Spoofing . . . . . . . . . . . . . . . 78
7.2. "Blind" Copies . . . . . . . . . . . . . . . . . . . . . 79 7.2. "Blind" Copies . . . . . . . . . . . . . . . . . . . . . 79
7.3. VRFY, EXPN, and Security . . . . . . . . . . . . . . . . 79 7.3. VRFY, EXPN, and Security . . . . . . . . . . . . . . . . 80
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 81
7.5. Information Disclosure in Announcements . . . . . . . . . 80 7.5. Information Disclosure in Announcements . . . . . . . . . 81
7.6. Information Disclosure in Trace Fields . . . . . . . . . 81 7.6. Information Disclosure in Trace Fields . . . . . . . . . 81
7.7. Information Disclosure in Message Forwarding . . . . . . 81 7.7. Information Disclosure in Message Forwarding . . . . . . 81
7.8. Resistance to Attacks . . . . . . . . . . . . . . . . . . 81 7.8. Resistance to Attacks . . . . . . . . . . . . . . . . . . 82
7.9. Scope of Operation of SMTP Servers . . . . . . . . . . . 81 7.9. Scope of Operation of SMTP Servers . . . . . . . . . . . 82
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 82
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 83 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 84
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 84 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 84
10.1. Normative References . . . . . . . . . . . . . . . . . . 84 10.1. Normative References . . . . . . . . . . . . . . . . . . 84
10.2. Informative References . . . . . . . . . . . . . . . . . 85 10.2. Informative References . . . . . . . . . . . . . . . . . 85
Appendix A. TCP Transport Service . . . . . . . . . . . . . . . 90 Appendix A. TCP Transport Service . . . . . . . . . . . . . . . 90
Appendix B. Generating SMTP Commands from RFC 822 Header Fields 90 Appendix B. Generating SMTP Commands from RFC 822 Header Fields 90
Appendix C. Source Routes . . . . . . . . . . . . . . . . . . . 91 Appendix C. Source Routes . . . . . . . . . . . . . . . . . . . 91
Appendix D. Scenarios . . . . . . . . . . . . . . . . . . . . . 92 Appendix D. Scenarios . . . . . . . . . . . . . . . . . . . . . 92
D.1. A Typical SMTP Transaction Scenario . . . . . . . . . . . 92 D.1. A Typical SMTP Transaction Scenario . . . . . . . . . . . 92
D.2. Aborted SMTP Transaction Scenario . . . . . . . . . . . . 93 D.2. Aborted SMTP Transaction Scenario . . . . . . . . . . . . 93
D.3. Relayed Mail Scenario . . . . . . . . . . . . . . . . . . 94 D.3. Relayed Mail Scenario . . . . . . . . . . . . . . . . . . 94
skipping to change at page 5, line 38 skipping to change at page 5, line 51
G.7.10. Further clarifications needed to source routes? . . . 102 G.7.10. Further clarifications needed to source routes? . . . 102
G.7.11. Should 1yz Be Revisited? . . . . . . . . . . . . . . 102 G.7.11. Should 1yz Be Revisited? . . . . . . . . . . . . . . 102
G.7.12. Review Timeout Specifications . . . . . . . . . . . . 102 G.7.12. Review Timeout Specifications . . . . . . . . . . . . 102
G.7.13. Possible SEND, SAML, SOML Loose End . . . . . . . . . 102 G.7.13. Possible SEND, SAML, SOML Loose End . . . . . . . . . 102
G.8. Enhanced Reply Codes and DSNs . . . . . . . . . . . . . . 102 G.8. Enhanced Reply Codes and DSNs . . . . . . . . . . . . . . 102
G.9. Revisiting Quoted Strings . . . . . . . . . . . . . . . . 103 G.9. Revisiting Quoted Strings . . . . . . . . . . . . . . . . 103
G.10. Internationalization . . . . . . . . . . . . . . . . . . 103 G.10. Internationalization . . . . . . . . . . . . . . . . . . 103
G.11. SMTP Clients, Servers, Senders, and Receivers . . . . . . 104 G.11. SMTP Clients, Servers, Senders, and Receivers . . . . . . 104
G.12. Extension Keywords Starting in 'X-' . . . . . . . . . . . 104 G.12. Extension Keywords Starting in 'X-' . . . . . . . . . . . 104
G.13. Deprecating HELO . . . . . . . . . . . . . . . . . . . . 104 G.13. Deprecating HELO . . . . . . . . . . . . . . . . . . . . 104
Appendix H. RFC 5321 Errata Summary and Tentative Change Log . . 104 G.14. The FOR Clause in Trace Fields: Semantics, Security
H.1. RFC 5321 Errata Summary . . . . . . . . . . . . . . . . . 104 Considerations, and Other Issues . . . . . . . . . . . . 105
Appendix H. RFC 5321 Errata Summary and Tentative Change Log . . 105
H.1. RFC 5321 Errata Summary . . . . . . . . . . . . . . . . . 105
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 . . . . . . . . . . . 106 initial (-00) version of this draft . . . . . . . . . . . 107
H.3. Changes Among Versions of Rfc5321bis . . . . . . . . . . 107 H.3. Changes Among Versions of Rfc5321bis . . . . . . . . . . 108
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 . . . . . . . . . . . . . . . . . 107 2012-12-02) to -01 . . . . . . . . . . . . . . . . . 108
H.3.2. Changes from draft-klensin-rfc5321bis-01 (20191203) H.3.2. Changes from draft-klensin-rfc5321bis-01 (20191203)
to -02 . . . . . . . . . . . . . . . . . . . . . . . 107 to -02 . . . . . . . . . . . . . . . . . . . . . . . 108
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 . . . . . . . . . . . . . . . . . . . . . . . 108 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 . . . . . . . . 108 to draft-ietf-emailcore-rfc5321bis-00 . . . . . . . . 109
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 . . . . . . . . . . . . . . . . . 108 (2020-10-06) to -01 . . . . . . . . . . . . . . . . . 109
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 H.3.6. Changes from draft-ietf-emailcore-rfc5321bis-01
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 111 (2020-12-25) to -02 . . . . . . . . . . . . . . . . . 110
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 112
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 7, line 33 skipping to change at page 8, line 4
problems of unusual readings or interpretations that have appeared as problems of unusual readings or interpretations that have appeared as
the SMTP extensions have been deployed. Where this specification the SMTP extensions have been deployed. Where this specification
moves beyond consolidation and actually differs from earlier moves beyond consolidation and actually differs from earlier
documents, it supersedes them technically as well as textually. documents, it supersedes them technically as well as textually.
Although SMTP was designed as a mail transport and delivery protocol, Although SMTP was designed as a mail transport and delivery protocol,
this specification also contains information that is important to its this specification also contains information that is important to its
use as a "mail submission" protocol, as recommended for Post Office use as a "mail submission" protocol, as recommended for Post Office
Protocol (POP) (RFC 937 [13], RFC 1939 [22]) and IMAP (RFC 3501 Protocol (POP) (RFC 937 [13], RFC 1939 [22]) and IMAP (RFC 3501
[36]). In general, the separate mail submission protocol specified [36]). In general, the separate mail submission protocol specified
in RFC 4409 [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 [11], discusses message header A companion document, RFC 5322 [11], discusses message header
sections and bodies and specifies formats and structures for them. sections and bodies and specifies formats and structures for them.
skipping to change at page 9, line 11 skipping to change at page 9, line 31
relayed. SMTP clients that transfer all traffic regardless of the relayed. SMTP clients that transfer all traffic regardless of the
target domains associated with the individual messages, or that do target domains associated with the individual messages, or that do
not maintain queues for retrying message transmissions that initially not maintain queues for retrying message transmissions that initially
cannot be completed, may otherwise conform to this specification but cannot be completed, may otherwise conform to this specification but
are not considered fully-capable. Fully-capable SMTP are not considered fully-capable. Fully-capable SMTP
implementations, including the relays used by these less capable implementations, including the relays used by these less capable
ones, and their destinations, are expected to support all of the ones, and their destinations, are expected to support all of the
queuing, retrying, and alternate address functions discussed in this queuing, retrying, and alternate address functions discussed in this
specification. In many situations and configurations, the less- specification. In many situations and configurations, the less-
capable clients discussed above SHOULD be using the message capable clients discussed above SHOULD be using the message
submission protocol (RFC 4409 [42]) rather than SMTP. submission protocol (RFC 6409 [42]) rather than SMTP.
The means by which an SMTP client, once it has determined a target The means by which an SMTP client, once it has determined a target
domain, determines the identity of an SMTP server to which a copy of domain, determines the identity of an SMTP server to which a copy of
a message is to be transferred, and then performs that transfer, are a message is to be transferred, and then performs that transfer, are
covered by this document. To effect a mail transfer to an SMTP covered by this document. To effect a mail transfer to an SMTP
server, an SMTP client establishes a two-way transmission channel to server, an SMTP client establishes a two-way transmission channel to
that SMTP server. An SMTP client determines the address of an that SMTP server. An SMTP client determines the address of an
appropriate host running an SMTP server by resolving a destination appropriate host running an SMTP server by resolving a destination
domain name to either an intermediate Mail eXchanger host or a final domain name to either an intermediate Mail eXchanger host or a final
target host. target host.
skipping to change at page 10, line 26 skipping to change at page 10, line 45
As suggested above, this protocol provides mechanisms for the As suggested above, this protocol provides mechanisms for the
transmission of mail. Historically, this transmission normally transmission of mail. Historically, this transmission normally
occurred directly from the sending user's host to the receiving occurred directly from the sending user's host to the receiving
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 4409 [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. Explicit "source" routing (see Section 5 and Appendix C
and Appendix F.2) SHOULD NOT be used. [[CREF3: [5321bis] JcK and Appendix F.2) SHOULD NOT be used. [[CREF3: [5321bis] JcK
20090123 - redundant sentence removed.]] 20090123 - redundant sentence removed.]]
2.2. The Extension Model 2.2. The Extension Model
2.2.1. Background 2.2.1. Background
skipping to change at page 16, line 31 skipping to change at page 17, line 4
these characters except when they are intended as line terminators these characters except when they are intended as line terminators
and then MUST, as indicated above, transmit them only as a <CRLF> and then MUST, as indicated above, transmit them only as a <CRLF>
sequence. sequence.
2.3.9. Message Content and Mail Data 2.3.9. Message Content and Mail Data
The terms "message content" and "mail data" are used interchangeably The terms "message content" and "mail data" are used interchangeably
in this document to describe the material transmitted after the DATA in this document to describe the material transmitted after the DATA
command is accepted and before the end of data indication is command is accepted and before the end of data indication is
transmitted. Message content includes the message header section and transmitted. Message content includes the message header section and
the possibly structured message body. The MIME specification (RFC the possibly structured message body. In the absence of extensions,
2045 [24]) provides the standard mechanisms for structured message both are required to be ASCII (see Section 2.3.1). The MIME
bodies. specification (RFC 2045 [24]) provides the standard mechanisms for
structured message bodies.
2.3.10. Originator, Delivery, Relay, and Gateway Systems 2.3.10. Originator, Delivery, Relay, and Gateway Systems
This specification makes a distinction among four types of SMTP This specification makes a distinction among four types of SMTP
systems, based on the role those systems play in transmitting systems, based on the role those systems play in transmitting
electronic mail. An "originating" system (sometimes called an SMTP electronic mail. An "originating" system (sometimes called an SMTP
originator) introduces mail into the Internet or, more generally, originator) introduces mail into the Internet or, more generally,
into a transport service environment. A "delivery" SMTP system is into a transport service environment. A "delivery" SMTP system is
one that receives mail from a transport service environment and one that receives mail from a transport service environment and
passes it to a mail user agent or deposits it in a message store that passes it to a mail user agent or deposits it in a message store that
skipping to change at page 21, line 28 skipping to change at page 22, line 6
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 and domain, always surrounded by "<" and ">" (normally a mailbox local-part and domain, always surrounded by "<"
brackets) identifying one recipient. If accepted, the SMTP server and ">" brackets) identifying one recipient. If accepted, the SMTP
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. 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,
contemporary SMTP clients SHOULD NOT utilize source routes (see contemporary SMTP clients SHOULD NOT utilize source routes (see
Appendix C). Servers MUST be prepared to encounter a list of source Appendix C). Servers MUST be prepared to encounter a list of source
skipping to change at page 29, line 16 skipping to change at page 29, line 41
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
(see RFC 4409 [42]). In any event, because these arrangements are (see RFC 6409 [42]). In any event, because these arrangements are
private and fall outside the scope of this specification, they are private and fall outside the scope of this specification, they are
not described here. not described here.
It is important to note that MX records can point to SMTP servers It is important to note that MX records can point to SMTP servers
that act as gateways into other environments, not just SMTP relays that act as gateways into other environments, not just SMTP relays
and final delivery systems; see Sections 3.7 and 5. and final delivery systems; see Sections 3.7 and 5.
If an SMTP server has accepted the task of relaying the mail and If an SMTP server has accepted the task of relaying the mail and
later finds that the destination is incorrect or that the mail cannot later finds that the destination is incorrect or that the mail cannot
be delivered for some other reason, then it MUST construct an be delivered for some other reason, then it MUST construct an
skipping to change at page 32, line 34 skipping to change at page 33, line 12
before exiting. The SMTP client will normally read the 421 reply before exiting. The SMTP client will normally read the 421 reply
code after sending its next command. code after sending its next command.
SMTP clients that experience a connection close, reset, or other SMTP clients that experience a connection close, reset, or other
communications failure due to circumstances not under their control communications failure due to circumstances not under their control
(in violation of the intent of this specification but sometimes (in violation of the intent of this specification but sometimes
unavoidable) SHOULD, to maintain the robustness of the mail system, unavoidable) SHOULD, to maintain the robustness of the mail system,
treat the mail transaction as if a 421 response had been received and treat the mail transaction as if a 421 response had been received and
act accordingly. act accordingly.
There are circumstances, contrary to the intent of this
specification, in which an SMTP server may receive an indication that
the underlying TCP connection has been closed or reset. To preserve
the robustness of the mail system, SMTP servers SHOULD be prepared
for this condition and SHOULD treat it as if a QUIT had been received
before the connection disappeared.
3.9. Mailing Lists and Aliases 3.9. Mailing Lists and Aliases
[[CREF10: [5321bis] If "alias and list models" are explained [[CREF10: [5321bis] If "alias and list models" are explained
elsewhere, cross reference". Also note that this section appears to elsewhere, cross reference". Also note that this section appears to
prohibit an exploder from adding List-* headers. That needs to be prohibit an exploder from adding List-* headers. That needs to be
finessed.]] finessed.]]
An SMTP-capable host SHOULD support both the alias and the list An SMTP-capable host SHOULD support both the alias and the list
models of address expansion for multiple delivery. When a message is models of address expansion for multiple delivery. When a message is
delivered or forwarded to each address of an expanded list form, the delivered or forwarded to each address of an expanded list form, the
return address in the envelope ("MAIL FROM:") MUST be changed to be return address in the envelope ("MAIL FROM:") MUST be changed to be
skipping to change at page 39, line 49 skipping to change at page 40, line 32
immediately after EHLO, before EHLO is issued in the session, after immediately after EHLO, before EHLO is issued in the session, after
an end of data indicator has been sent and acknowledged, or an end of data indicator has been sent and acknowledged, or
immediately before a QUIT. An SMTP server MUST NOT close the immediately before a QUIT. An SMTP server MUST NOT close the
connection as the result of receiving a RSET; that action is reserved connection as the result of receiving a RSET; that action is reserved
for QUIT (see Section 4.1.1.10). for QUIT (see Section 4.1.1.10).
Since EHLO implies some additional processing and response by the Since EHLO implies some additional processing and response by the
server, RSET will normally be more efficient than reissuing that server, RSET will normally be more efficient than reissuing that
command, even though the formal semantics are the same. command, even though the formal semantics are the same.
There are circumstances, contrary to the intent of this
specification, in which an SMTP server may receive an indication that
the underlying TCP connection has been closed or reset. To preserve
the robustness of the mail system, SMTP servers SHOULD be prepared
for this condition and SHOULD treat it as if a QUIT had been received
before the connection disappeared.
Syntax: Syntax:
rset = "RSET" CRLF rset = "RSET" CRLF
4.1.1.6. VERIFY (VRFY) 4.1.1.6. VERIFY (VRFY)
This command asks the receiver to confirm that the argument This command asks the receiver to confirm that the argument
identifies a user or mailbox. If it is a user name, information is identifies a user or mailbox. If it is a user name, information is
returned as specified in Section 3.5. returned as specified in Section 3.5.
skipping to change at page 49, line 4 skipping to change at page 49, line 26
[ SP textstring ] CRLF [ SP textstring ] CRLF
*( "220-" [ textstring ] CRLF ) *( "220-" [ textstring ] CRLF )
"220" [ SP textstring ] CRLF ) "220" [ SP textstring ] CRLF )
textstring = 1*(%d09 / %d32-126) ; HT, SP, Printable US-ASCII textstring = 1*(%d09 / %d32-126) ; HT, SP, Printable US-ASCII
Reply-line = *( Reply-code "-" [ textstring ] CRLF ) Reply-line = *( Reply-code "-" [ textstring ] CRLF )
Reply-code [ SP textstring ] CRLF Reply-code [ SP textstring ] CRLF
Reply-code = %x32-35 %x30-35 %x30-39 Reply-code = %x32-35 %x30-35 %x30-39
where "Greeting" appears only in the 220 response that announces that where "Greeting" appears only in the 220 response that announces that
the server is opening its part of the connection. (Other possible the server is opening its part of the connection. (Other possible
server responses upon connection follow the syntax of Reply-line.) server responses upon connection follow the syntax of Reply-line.)
An SMTP server SHOULD send only the reply codes listed in this An SMTP server SHOULD send only the reply codes listed in this
document or additions to the list as discussed below. document or additions to the list as discussed below.
[[CREF15: [5321bis] 20140804: New text to clear up ambiguity.]] [[CREF15: [5321bis] 20140804: New text to clear up ambiguity.]]
An SMTP server SHOULD use the text shown in the examples whenever An SMTP server SHOULD use the text shown in the examples whenever
appropriate. appropriate.
An SMTP client MUST determine its actions only by the reply code, not An SMTP client MUST determine its actions only by the reply code, not
by the text (except for the "change of address" 251 and 551 and, if by the text (except for the "change of address" 251 and 551 and, if
necessary, 220, 221, and 421 replies); in the general case, any text, necessary, 220, 221, and 421 replies); in the general case, any text,
including no text at all (although senders SHOULD NOT send bare including no text at all (although senders SHOULD NOT send bare
codes), MUST be acceptable. The space (blank) following the reply codes), MUST be acceptable. The space (blank) following the reply
code is considered part of the text. Whenever possible, a sender- code is considered part of the text. A Sender-SMTP MUST first test
SMTP SHOULD test the first digit (severity indication) of a reply the whole 3 digit reply code it receives, as well as any accompanying
code it receives. supplemental codes or information (see RFC 3463 [RFC3463] and RFC
[[CREF16: [5321bis] 20141209 [[Note in Draft: What is that sentence 5248 [RFC5248]). If the full reply code is not recognized, and the
supposed to be tell us? Test the first digit and examine the others additional information is not recognized or missing, the Sender-SMTP
only if necessary? Note the interaction between this and various MUST use the first digit (severity indication) of a reply code it
flaps about adding new codes.]]]] receives.
The list of codes that appears below MUST NOT be construed as The list of codes that appears below MUST NOT be construed as
permanent. While the addition of new codes should be a rare and permanent. While the addition of new codes should be a rare and
significant activity, with supplemental information in the textual significant activity, with supplemental information in the textual
part of the response (including enhanced status codes [34] and the part of the response (including enhanced status codes [34] and the
successors to that specification) successors to that specification)
[[CREF17: [5321bis] 20140802: New text for clarity]] [[CREF16: [5321bis] 20140802: New text for clarity]]
being preferred, new codes may be added as the result of new being preferred, new codes may be added as the result of new
Standards or Standards-Track specifications. Consequently, a sender- Standards or Standards-Track specifications. Consequently, a sender-
SMTP MUST be prepared to handle codes not specified in this document SMTP MUST be prepared to handle codes not specified in this document
and MUST do so by interpreting the first digit only. and MUST do so by interpreting the first digit only.
In the absence of extensions negotiated with the client, SMTP servers In the absence of extensions negotiated with the client, SMTP servers
MUST NOT send reply codes whose first digits are other than 2, 3, 4, MUST NOT send reply codes whose first digits are other than 2, 3, 4,
or 5. Clients that receive such out-of-range codes SHOULD normally or 5. Clients that receive such out-of-range codes SHOULD normally
treat them as fatal errors and terminate the mail transaction. treat them as fatal errors and terminate the mail transaction.
skipping to change at page 52, line 27 skipping to change at page 53, line 4
4.2.2. Reply Codes by Function Groups 4.2.2. Reply Codes by Function Groups
500 Syntax error, command unrecognized (This may include errors such 500 Syntax error, command unrecognized (This may include errors such
as command line too long) as command line too long)
501 Syntax error in parameters or arguments 501 Syntax error in parameters or arguments
502 Command not implemented (see Section 4.2.4.1) 502 Command not implemented (see Section 4.2.4.1)
503 Bad sequence of commands 503 Bad sequence of commands
504 Command parameter not implemented 504 Command parameter not implemented
211 System status, or system help reply 211 System status, or system help reply
214 Help message (Information on how to use the receiver or the 214 Help message (Information on how to use the receiver or the
meaning of a particular non-standard command; this reply is useful meaning of a particular non-standard command; this reply is useful
only to the human user) only to the human user)
220 <domain> Service ready 220 <domain> Service ready
221 <domain> Service closing transmission channel 221 <domain> Service closing transmission channel
421 <domain> Service not available, closing transmission channel 421 <domain> Service not available, closing transmission channel
(This may be a reply to any command if the service knows it must (This may be a reply to any command if the service knows it must
shut down) shut down)
hangText="521"><domain> No mail service here. [[CREF18: 521 <domain> No mail service here. [[CREF17: [5321bis]20140804:
[5321bis]20140804: Specific code introduced with RFC 1846, updated Specific code introduced with RFC 1846, updated and specified in
and specified in draft-klensin-smtp-521code.]] draft-klensin-smtp-521code.]]
556 No mail service at this domain. [[CREF19: [5321bis] 20140912: 556 No mail service at this domain. [[CREF18: [5321bis] 20140912:
Specific code introduced in draft-klensin-smtp-521code-02 (RFC Specific code introduced in draft-klensin-smtp-521code-02 (RFC
7504), largely for nullMX]] 7504), largely for nullMX]]
250 Requested mail action okay, completed 250 Requested mail action okay, completed
251 User not local; will forward to <forward-path> (See Section 3.4) 251 User not local; will forward to <forward-path> (See Section 3.4)
252 Cannot VRFY user, but will accept message and attempt delivery 252 Cannot VRFY user, but will accept message and attempt delivery
(See Section 3.5.3) (See Section 3.5.3)
skipping to change at page 53, line 25 skipping to change at page 54, line 4
450 Requested mail action not taken: mailbox unavailable (e.g., 450 Requested mail action not taken: mailbox unavailable (e.g.,
mailbox busy or temporarily blocked for policy reasons) mailbox busy or temporarily blocked for policy reasons)
550 Requested action not taken: mailbox unavailable (e.g., mailbox 550 Requested action not taken: mailbox unavailable (e.g., mailbox
not found, no access, or command rejected for policy reasons) not found, no access, or command rejected for policy reasons)
451 Requested action aborted: error in processing 451 Requested action aborted: error in processing
551 User not local; please try <forward-path> (See Section 3.4) 551 User not local; please try <forward-path> (See Section 3.4)
452 Requested action not taken: insufficient system storage 452 Requested action not taken: insufficient system storage
552 Requested mail action aborted: exceeded storage allocation 552 Requested mail action aborted: exceeded storage allocation
553 Requested action not taken: mailbox name not allowed (e.g., 553 Requested action not taken: mailbox name not allowed (e.g.,
mailbox syntax incorrect) mailbox syntax incorrect)
354 Start mail input; end with <CRLF>.<CRLF> 354 Start mail input; end with <CRLF>.<CRLF>
554 Transaction failed (Or, in the case of a connection-opening 554 Transaction failed (Or, in the case of a connection-opening
response, "No SMTP service here") response, "No SMTP service here")
[[CREF20: [5321bis] [[Note in Draft: Revise above statement in the [[CREF19: [5321bis] [[Note in Draft: Revise above statement in the
light of new 521 code??]] ]] light of new 521 code??]] ]]
4.2.3. Reply Codes in Numeric Order 4.2.3. Reply Codes in Numeric Order
211 System status, or system help reply 211 System status, or system help reply
214 Help message (Information on how to use the receiver or the 214 Help message (Information on how to use the receiver or the
meaning of a particular non-standard command; this reply is useful meaning of a particular non-standard command; this reply is useful
only to the human user) only to the human user)
skipping to change at page 55, line 26 skipping to change at page 56, line 7
Questions have been raised as to when reply code 502 (Command not Questions have been raised as to when reply code 502 (Command not
implemented) SHOULD be returned in preference to other codes. 502 implemented) SHOULD be returned in preference to other codes. 502
SHOULD be used when the command is actually recognized by the SMTP SHOULD be used when the command is actually recognized by the SMTP
server, but not implemented. If the command is not recognized, code server, but not implemented. If the command is not recognized, code
500 SHOULD be returned. Extended SMTP systems MUST NOT list 500 SHOULD be returned. Extended SMTP systems MUST NOT list
capabilities in response to EHLO for which they will return 502 (or capabilities in response to EHLO for which they will return 502 (or
500) replies. 500) replies.
4.2.4.2. "No mail accepted" situations and the 521, 554, and 556 codes 4.2.4.2. "No mail accepted" situations and the 521, 554, and 556 codes
[[CREF21: [5321bis] This section is new with 5321bis. ]] [[CREF20: [5321bis] This section is new with 5321bis. ]]
Codes 521, 554, and 556 are all used to report different types of "no Codes 521, 554, and 556 are all used to report different types of "no
mail accepted" situations. They differ as follows. 521 is an mail accepted" situations. They differ as follows. 521 is an
indication from a system answering on the SMTP port that it does not indication from a system answering on the SMTP port that it does not
support SMTP service (a so-called "dummy server" as discussed in RFC support SMTP service (a so-called "dummy server" as discussed in RFC
1846 [19] and elsewhere). Obviously, it requires that system exist 1846 [19] and elsewhere). Obviously, it requires that system exist
and that a connection can be made successfully to it. Because a and that a connection can be made successfully to it. Because a
system that does not accept any mail cannot meaningfully accept a system that does not accept any mail cannot meaningfully accept a
RCPT command, any commands (other than QUIT) issued after an SMTP RCPT command, any commands (other than QUIT) issued after an SMTP
server has issued a 521 reply are client (sender) errors. 556 is server has issued a 521 reply are client (sender) errors. 556 is
skipping to change at page 57, line 35 skipping to change at page 58, line 13
220 [10.0.0.1] Clueless host service ready 220 [10.0.0.1] Clueless host service ready
The table below lists alternative success and failure replies for The table below lists alternative success and failure replies for
each command. These SHOULD be strictly adhered to. A receiver MAY each command. These SHOULD be strictly adhered to. A receiver MAY
substitute text in the replies, but the meanings and actions implied substitute text in the replies, but the meanings and actions implied
by the code numbers and by the specific command reply sequence MUST by the code numbers and by the specific command reply sequence MUST
be preserved. However, in order to provide robustness as SMTP is be preserved. However, in order to provide robustness as SMTP is
extended and evolves, the discussion in Section 4.2.1 still applies: extended and evolves, the discussion in Section 4.2.1 still applies:
all SMTP clients MUST be prepared to accept any code that conforms to all SMTP clients MUST be prepared to accept any code that conforms to
the discussion in that section and MUST be prepared to interpret it the discussion in that section and MUST be prepared to interpret it
on the basis of its first digit only. [[CREF22: [5321bis] 20140914: on the basis of its first digit only.
Above sentence is new text based on yet another round of discussions
about "invalid codes".]]
4.3.2. Command-Reply Sequences 4.3.2. Command-Reply Sequences
Each command is listed with its usual possible replies. The prefixes Each command is listed with its usual possible replies. The prefixes
used before the possible replies are "I" for intermediate, "S" for used before the possible replies are "I" for intermediate, "S" for
success, and "E" for error. Since some servers may generate other success, and "E" for error. Since some servers may generate other
replies under special circumstances, and to allow for future replies under special circumstances, and to allow for future
extension, SMTP clients SHOULD, when possible, interpret only the extension, SMTP clients SHOULD, when possible, interpret only the
first digit of the reply and MUST be prepared to deal with first digit of the reply and MUST be prepared to deal with
unrecognized reply codes by interpreting the first digit only. unrecognized reply codes by interpreting the first digit only.
skipping to change at page 59, line 26 skipping to change at page 60, line 4
RSET RSET
S: 250 S: 250
VRFY VRFY
S: 250, 251, 252 S: 250, 251, 252
E: 550, 551, 553, 502, 504 E: 550, 551, 553, 502, 504
EXPN EXPN
S: 250, 252 S: 250, 252
E: 550, 500, 502, 504 E: 550, 500, 502, 504
HELP HELP
S: 211, 214 S: 211, 214
E: 502, 504 E: 502, 504
NOOP NOOP
S: 250 S: 250
QUIT QUIT
S: 221 S: 221
4.4. Trace Information 4.4. Trace Information
When an SMTP server receives a message for delivery or further When an SMTP server receives a message for delivery or further
processing, it MUST insert trace (often referred to as "time stamp" processing, it MUST insert trace (often referred to as "time stamp"
or "Received" information) [[CREF23: [5321bis] See note on or "Received" information) beginning of the message content, as
rfc5321bis-00c above]] information at the beginning of the message discussed in Section 4.1.1.4.
content, as discussed in Section 4.1.1.4.
This line MUST be structured as follows: This line MUST be structured as follows:
o The FROM clause, which MUST be supplied in an SMTP environment, o The FROM clause, which MUST be supplied in an SMTP environment,
SHOULD contain both (1) the name of the source host as presented SHOULD contain both (1) the name of the source host as presented
in the EHLO command and (2) an address literal containing the IP in the EHLO command and (2) an address literal containing the IP
address of the source, determined from the TCP connection. address of the source, determined from the TCP connection.
o The ID clause MAY contain an "@" as suggested in RFC 822, but this o The ID clause MAY contain an "@" as suggested in RFC 822, but this
is not required. is not required.
skipping to change at page 63, line 18 skipping to change at page 63, line 40
Via = CFWS "VIA" FWS Link Via = CFWS "VIA" FWS Link
With = CFWS "WITH" FWS Protocol With = CFWS "WITH" FWS Protocol
ID = CFWS "ID" FWS ( Atom / msg-id ) ID = CFWS "ID" FWS ( Atom / msg-id )
; msg-id is defined in RFC 5322 [11] ; msg-id is defined in RFC 5322 [11]
For = CFWS "FOR" FWS ( Path / Mailbox ) For = CFWS "FOR" FWS ( Path / Mailbox )
Additional-Registered-Clauses = 1* (CFWS Atom FWS String) Additional-Registered-Clauses = 1* (CFWS Atom FWS String)
[[CREF24: [5321bis] 5321 errata #1683, 20090215, [[CREF21: [5321bis] 5321 errata #1683, 20090215,
Roberto Javier Godoy, rjgodoy@fich.unl.edu.ar]] Roberto Javier Godoy, rjgodoy@fich.unl.edu.ar]]
; Additional standard clauses may be added in this ; Additional standard clauses may be added in this
; location by future standards and registration with ; location by future standards and registration with
; IANA. SMTP servers SHOULD NOT use unregistered ; IANA. SMTP servers SHOULD NOT use unregistered
; names. See Section 8. ; names. See Section 8.
Link = "TCP" / Addtl-Link Link = "TCP" / Addtl-Link
Addtl-Link = Atom Addtl-Link = Atom
; Additional standard names for links are ; Additional standard names for links are
skipping to change at page 65, line 36 skipping to change at page 66, line 10
Clients MAY attempt to transmit these, but MUST be prepared for a Clients MAY attempt to transmit these, but MUST be prepared for a
server to reject them if they cannot be handled by it. To the server to reject them if they cannot be handled by it. To the
maximum extent possible, implementation techniques that impose no maximum extent possible, implementation techniques that impose no
limits on the length of these objects should be used. limits on the length of these objects should be used.
Extensions to SMTP may involve the use of characters that occupy more Extensions to SMTP may involve the use of characters that occupy more
than a single octet each. This section therefore specifies lengths than a single octet each. This section therefore specifies lengths
in octets where absolute lengths, rather than character counts, are in octets where absolute lengths, rather than character counts, are
intended. intended.
[[CREF25: [5321bis] [[Note in Draft: Klensin 20191126: Given the [[CREF22: [5321bis] [[Note in Draft: Klensin 20191126: Given the
controversy on the SMTP mailing list between 20191123 and now about controversy on the SMTP mailing list between 20191123 and now about
maximum lengths, is the above adequate or is further tuning of the maximum lengths, is the above adequate or is further tuning of the
limit text below needed? ]]]] limit text below needed? ]]]]
4.5.3.1.1. Local-part 4.5.3.1.1. Local-part
The maximum total length of a user name or other local-part is 64 The maximum total length of a user name or other local-part is 64
octets. octets.
4.5.3.1.2. Domain 4.5.3.1.2. Domain
skipping to change at page 71, line 24 skipping to change at page 71, line 47
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.7, other namely non-delivery notifications as discussed in Section 3.6.2 and
kinds of Delivery Status Notifications (DSNs, RFC 3461 [33]), and Section 3.6.3, other kinds of Delivery Status Notifications (DSNs,
Message Disposition Notifications (MDNs, RFC 3798 [37]). All of RFC 3461 [33]), and Message Disposition Notifications (MDNs, RFC 8098
these kinds of messages are notifications about a previous message, [37]). All of these kinds of messages are notifications about a
and they are sent to the reverse-path of the previous mail message. previous message, and they are sent to the reverse-path of the
(If the delivery of such a notification message fails, that usually previous mail message. (If the delivery of such a notification
indicates a problem with the mail system of the host to which the message fails, that usually indicates a problem with the mail system
notification message is addressed. For this reason, at some hosts of the host to which the notification message is addressed. For this
the MTA is set up to forward such failed notification messages to reason, at some hosts the MTA is set up to forward such failed
someone who is able to fix problems with the mail system, e.g., via notification messages to someone who is able to fix problems with the
the postmaster alias.) mail system, e.g., via the postmaster alias.)
All other types of messages (i.e., any message which is not required All other types of messages (i.e., any message which is not required
by a Standards-Track RFC to have a null reverse-path) SHOULD be sent by a Standards-Track RFC to have a null reverse-path) SHOULD be sent
with a valid, non-null reverse-path. with a valid, non-null reverse-path.
Implementers of automated email processors should be careful to make Implementers of automated email processors should be careful to make
sure that the various kinds of messages with a null reverse-path are sure that the various kinds of messages with a null reverse-path are
handled correctly. In particular, such systems SHOULD NOT reply to handled correctly. In particular, such systems SHOULD NOT reply to
messages with a null reverse-path, and they SHOULD NOT add a non-null messages with a null reverse-path, and they SHOULD NOT add a non-null
reverse-path, or change a null reverse-path to a non-null one, to reverse-path, or change a null reverse-path to a non-null one, to
skipping to change at page 77, line 30 skipping to change at page 78, line 7
authenticated addresses. authenticated addresses.
In response to these weak SMTP clients, many SMTP systems now In response to these weak SMTP clients, many SMTP systems now
complete messages that are delivered to them in incomplete or complete messages that are delivered to them in incomplete or
incorrect form. This strategy is generally considered appropriate incorrect form. This strategy is generally considered appropriate
when the server can identify or authenticate the client, and there when the server can identify or authenticate the client, and there
are prior agreements between them. By contrast, there is at best are prior agreements between them. By contrast, there is at best
great concern about fixes applied by a relay or delivery SMTP server great concern about fixes applied by a relay or delivery SMTP server
that has little or no knowledge of the user or client machine. Many that has little or no knowledge of the user or client machine. Many
of these issues are addressed by using a separate protocol, such as of these issues are addressed by using a separate protocol, such as
that defined in RFC 4409 [42], for message submission, rather than that defined in RFC 6409 [42], for message submission, rather than
using originating SMTP servers for that purpose. using originating SMTP servers for that purpose.
The following changes to a message being processed MAY be applied The following changes to a message being processed MAY be applied
when necessary by an originating SMTP server, or one used as the when necessary by an originating SMTP server, or one used as the
target of SMTP as an initial posting (message submission) protocol: target of SMTP as an initial posting (message submission) protocol:
o Addition of a message-id field when none appears o Addition of a message-id field when none appears
o Addition of a date, time, or time zone when none appears o Addition of a date, time, or time zone when none appears
skipping to change at page 78, line 24 skipping to change at page 78, line 48
into believing that they came from somewhere else. Constructing such into believing that they came from somewhere else. Constructing such
a message so that the "spoofed" behavior cannot be detected by an a message so that the "spoofed" behavior cannot be detected by an
expert is somewhat more difficult, but not sufficiently so as to be a expert is somewhat more difficult, but not sufficiently so as to be a
deterrent to someone who is determined and knowledgeable. deterrent to someone who is determined and knowledgeable.
Consequently, as knowledge of Internet mail increases, so does the Consequently, as knowledge of Internet mail increases, so does the
knowledge that SMTP mail inherently cannot be authenticated, or knowledge that SMTP mail inherently cannot be authenticated, or
integrity checks provided, at the transport level. Real mail integrity checks provided, at the transport level. Real mail
security lies only in end-to-end methods involving the message security lies only in end-to-end methods involving the message
bodies, such as those that use digital signatures (see RFC 1847 [20] bodies, such as those that use digital signatures (see RFC 1847 [20]
and, e.g., Pretty Good Privacy (PGP) in RFC 4880 [45] or Secure/ and, e.g., Pretty Good Privacy (PGP) in RFC 4880 [45] or Secure/
Multipurpose Internet Mail Extensions (S/MIME) in RFC 3851 [38]). Multipurpose Internet Mail Extensions (S/MIME) in RFC 8551 [38]).
Various protocol extensions and configuration options that provide Various protocol extensions and configuration options that provide
authentication at the transport level (e.g., from an SMTP client to authentication at the transport level (e.g., from an SMTP client to
an SMTP server) improve somewhat on the traditional situation an SMTP server) improve somewhat on the traditional situation
described above. However, in general, they only authenticate one described above. However, in general, they only authenticate one
server to another rather than a chain of relays and servers, much server to another rather than a chain of relays and servers, much
less authenticating users or user machines. Consequently, unless less authenticating users or user machines. Consequently, unless
they are accompanied by careful handoffs of responsibility in a they are accompanied by careful handoffs of responsibility in a
carefully designed trust environment, they remain inherently weaker carefully designed trust environment, they remain inherently weaker
than end-to-end mechanisms that use digitally signed messages rather than end-to-end mechanisms that use digitally signed messages rather
skipping to change at page 79, line 18 skipping to change at page 79, line 41
Addresses that do not appear in the message header section may appear Addresses that do not appear in the message header section may appear
in the RCPT commands to an SMTP server for a number of reasons. The in the RCPT commands to an SMTP server for a number of reasons. The
two most common involve the use of a mailing address as a "list two most common involve the use of a mailing address as a "list
exploder" (a single address that resolves into multiple addresses) exploder" (a single address that resolves into multiple addresses)
and the appearance of "blind copies". Especially when more than one and the appearance of "blind copies". Especially when more than one
RCPT command is present, and in order to avoid defeating some of the RCPT command is present, and in order to avoid defeating some of the
purpose of these mechanisms, SMTP clients and servers SHOULD NOT copy purpose of these mechanisms, SMTP clients and servers SHOULD NOT copy
the full set of RCPT command arguments into the header section, the full set of RCPT command arguments into the header section,
either as part of trace header fields or as informational or private- either as part of trace header fields or as informational or private-
extension header fields. [[CREF26: [rfc5321bis] [[Note in draft - extension header fields. [[CREF23: [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 the There is no inherent relationship between either "reverse" (from the
skipping to change at page 83, line 47 skipping to change at page 84, line 30
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 specific suggestions that led to corrections and improvements in
early versions of the current specification were received from Ned early versions of the current specification were received from Ned
Freed, Barry Leiba, Ivar Lumi, Pete Resnick, Hector Santos, Paul Freed, Barry Leiba, Ivar Lumi, Pete Resnick, Hector Santos, Paul
Smith and others. Smith and others.
chetti contributed an analysis that clarified the ABNF productions chetti contributed an analysis that clarified the ABNF productions
that implicitly reference other documents. that implicitly reference other documents.
[[CREF27: Some errata and comments after 2019-07-01 have not yet been [[CREF24: 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 The EMAILCORE Working Group was chartered in September 2020 with
Alexey Melnikov and Seth Blank and co-chairs. Without their Alexey Melnikov and Seth Blank and co-chairs. Without their
leadership and technical contributions, this document would never leadership and technical contributions, this document would never
have been completed. have been completed.
10. References 10. References
10.1. Normative References 10.1. Normative References
skipping to change at page 87, line 36 skipping to change at page 88, line 18
[35] Moore, K. and G. Vaudreuil, "An Extensible Message Format [35] Moore, K. and G. Vaudreuil, "An Extensible Message Format
for Delivery Status Notifications", RFC 3464, for Delivery Status Notifications", RFC 3464,
DOI 10.17487/RFC3464, January 2003, DOI 10.17487/RFC3464, January 2003,
<https://www.rfc-editor.org/info/rfc3464>. <https://www.rfc-editor.org/info/rfc3464>.
[36] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION [36] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
<https://www.rfc-editor.org/info/rfc3501>. <https://www.rfc-editor.org/info/rfc3501>.
[37] Hansen, T., Ed. and G. Vaudreuil, Ed., "Message [37] Hansen, T., Ed. and A. Melnikov, Ed., "Message Disposition
Disposition Notification", RFC 3798, DOI 10.17487/RFC3798, Notification", STD 85, RFC 8098, DOI 10.17487/RFC8098,
May 2004, <https://www.rfc-editor.org/info/rfc3798>. February 2017, <https://www.rfc-editor.org/info/rfc8098>.
[38] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail [38] Schaad, J., Ramsdell, B., and S. Turner, "Secure/
Extensions (S/MIME) Version 3.1 Message Specification", Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
RFC 3851, DOI 10.17487/RFC3851, July 2004, Message Specification", RFC 8551, DOI 10.17487/RFC8551,
<https://www.rfc-editor.org/info/rfc3851>. April 2019, <https://www.rfc-editor.org/info/rfc8551>.
[39] Nakamura, M. and J. Hagino, "SMTP Operational Experience [39] Nakamura, M. and J. Hagino, "SMTP Operational Experience
in Mixed IPv4/v6 Environments", RFC 3974, in Mixed IPv4/v6 Environments", RFC 3974,
DOI 10.17487/RFC3974, January 2005, DOI 10.17487/RFC3974, January 2005,
<https://www.rfc-editor.org/info/rfc3974>. <https://www.rfc-editor.org/info/rfc3974>.
[40] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [40] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
[41] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) [41] Kitterman, S., "Sender Policy Framework (SPF) for
for Authorizing Use of Domains in E-Mail, Version 1", Authorizing Use of Domains in Email, Version 1", RFC 7208,
RFC 4408, DOI 10.17487/RFC4408, April 2006, DOI 10.17487/RFC7208, April 2014,
<https://www.rfc-editor.org/info/rfc4408>. <https://www.rfc-editor.org/info/rfc7208>.
[42] Gellens, R. and J. Klensin, "Message Submission for Mail", [42] Gellens, R. and J. Klensin, "Message Submission for Mail",
RFC 4409, DOI 10.17487/RFC4409, April 2006, STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011,
<https://www.rfc-editor.org/info/rfc4409>. <https://www.rfc-editor.org/info/rfc6409>.
[43] Fenton, J., "Analysis of Threats Motivating DomainKeys [43] Fenton, J., "Analysis of Threats Motivating DomainKeys
Identified Mail (DKIM)", RFC 4686, DOI 10.17487/RFC4686, Identified Mail (DKIM)", RFC 4686, DOI 10.17487/RFC4686,
September 2006, <https://www.rfc-editor.org/info/rfc4686>. September 2006, <https://www.rfc-editor.org/info/rfc4686>.
[44] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, [44] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
J., and M. Thomas, "DomainKeys Identified Mail (DKIM) "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
Signatures", RFC 4871, DOI 10.17487/RFC4871, May 2007, RFC 6376, DOI 10.17487/RFC6376, September 2011,
<https://www.rfc-editor.org/info/rfc4871>. <https://www.rfc-editor.org/info/rfc6376>.
[45] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. [45] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
Thayer, "OpenPGP Message Format", RFC 4880, Thayer, "OpenPGP Message Format", RFC 4880,
DOI 10.17487/RFC4880, November 2007, DOI 10.17487/RFC4880, November 2007,
<https://www.rfc-editor.org/info/rfc4880>. <https://www.rfc-editor.org/info/rfc4880>.
[46] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced [46] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced
Mail System Status Codes", BCP 138, RFC 5248, Mail System Status Codes", BCP 138, RFC 5248,
DOI 10.17487/RFC5248, June 2008, DOI 10.17487/RFC5248, June 2008,
<https://www.rfc-editor.org/info/rfc5248>. <https://www.rfc-editor.org/info/rfc5248>.
skipping to change at page 91, line 50 skipping to change at page 91, line 50
from the material in RFC 821 to prevent server actions that might from the material in RFC 821 to prevent server actions that might
confuse clients or subsequent servers that do not expect a full confuse clients or subsequent servers that do not expect a full
source route implementation. source route implementation.
Historically, for relay purposes, the forward-path may have been a Historically, for relay purposes, the forward-path may have been a
source route of the form "@ONE,@TWO:JOE@THREE", where ONE, TWO, and source route of the form "@ONE,@TWO:JOE@THREE", where ONE, TWO, and
THREE MUST be fully-qualified domain names. This form was used to THREE MUST be fully-qualified domain names. This form was used to
emphasize the distinction between an address and a route. The emphasize the distinction between an address and a route. The
mailbox (here, JOE@THREE) is an absolute address, and the route is mailbox (here, JOE@THREE) is an absolute address, and the route is
information about how to get there. The two concepts should not be information about how to get there. The two concepts should not be
confused.[[CREF28: [5321bis]JcK 20090123: Tightened this and the next confused. [[CREF25: [5321bis]JcK 20090123: Tightened this and the
paragraph to be clear that this doesn't authorize source route use.]] next paragraph to be clear that this doesn't authorize source route
use.]]
If source routes are used contrary to requirements and If source routes are used contrary to requirements and
recommendations elsewhere in this specfiication, RFC 821 and the text recommendations elsewhere in this specfiication, RFC 821 and the text
below should be consulted for the mechanisms for constructing and below should be consulted for the mechanisms for constructing and
updating the forward-path. A server that is reached by means of a 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 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 forward-path) MUST remove its domain name from any forward-paths in
which that domain name appears before forwarding the message and MAY which that domain name appears before forwarding the message and MAY
remove all other source routing information. The reverse-path SHOULD remove all other source routing information. The reverse-path SHOULD
NOT be updated by servers conforming to this specification. NOT be updated by servers conforming to this specification.
Notice that the forward-path and reverse-path appear in the SMTP Notice that the forward-path and reverse-path appear in the SMTP
commands and replies, but not necessarily in the message. That is, commands and replies, but not necessarily in the message. That is,
there is no need for these paths and especially this syntax to appear there is no need for these paths and especially this syntax to appear
in the "To:" , "From:", "CC:", etc. fields of the message header in the "To:" , "From:", "CC:", etc. fields of the message header
section. Conversely, SMTP servers MUST NOT derive final message section. Conversely, SMTP servers MUST NOT derive final message
routing information from message header fields. routing information from message header fields.
When the list of hosts is present despite the recommendations and When the list of hosts is present despite the recommendations and
requirements [[CREF29: [5321bis]JcK 20090123 "and requrements" requirements [[CREF26: [5321bis]JcK 20090123 "and requrements"
added]] above, it is a "reverse" source route and indicates that the added]] 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 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 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 to return non-delivery notices to the sender. If, contrary to the
recommendations here, a relay host adds itself to the beginning of recommendations here, a relay host adds itself to the beginning of
the list, it MUST use its name as known in the transport environment 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 to which it is relaying the mail rather than that of the transport
environment from which the mail came (if they are different). Note environment from which the mail came (if they are different). Note
that a situation could easily arise in which some relay hosts add that a situation could easily arise in which some relay hosts add
their names to the reverse source route and others do not, generating their names to the reverse source route and others do not, generating
skipping to change at page 96, line 28 skipping to change at page 96, line 28
Appendix F. Deprecated Features of RFC 821 Appendix F. Deprecated Features of RFC 821
A few features of RFC 821 have proven to be problematic and SHOULD A few features of RFC 821 have proven to be problematic and SHOULD
NOT be used in Internet mail. Some of these features were deprecated NOT be used in Internet mail. Some of these features were deprecated
in RFC 2821 in 2001; source routing and two-digit years in dates were in RFC 2821 in 2001; source routing and two-digit years in dates were
deprecated by RFC 1123 in 1989. Of the domain literal forms, RFC deprecated by RFC 1123 in 1989. Of the domain literal forms, RFC
1123 required support only for the dotted decimal form. With the 1123 required support only for the dotted decimal form. With the
possible exception of old, hardware-embedded, applications, there is possible exception of old, hardware-embedded, applications, there is
no longer any excuse for these features to appear on the contemporary no longer any excuse for these features to appear on the contemporary
Internet. [[CREF30: [5321bis] (2821ter) 2821bis Last Call Comment]] Internet. [[CREF27: [5321bis] (2821ter) 2821bis Last Call Comment]]
F.1. TURN F.1. TURN
This command, described in RFC 821, raises important security issues This command, described in RFC 821, raises important security issues
since, in the absence of strong authentication of the host requesting since, in the absence of strong authentication of the host requesting
that the client and server switch roles, it can easily be used to that the client and server switch roles, it can easily be used to
divert mail from its correct destination. Its use is deprecated; divert mail from its correct destination. Its use is deprecated;
SMTP systems SHOULD NOT use it unless the server can authenticate the SMTP systems SHOULD NOT use it unless the server can authenticate the
client. client.
skipping to change at page 101, line 40 skipping to change at page 101, line 40
Ticket #12 and Ticket #34. 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. 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 Resolved. Text in Section 4.2 changed 2021-02-08 and CREF comment in
Section 4.3.1 removed.
Ticket #13. Ticket #13.
G.7.8. Size limits G.7.8. Size limits
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. say.
Ticket #14 and maybe Ticket #38. Ticket #14 and maybe Ticket #38.
skipping to change at page 103, line 42 skipping to change at page 103, line 42
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
use of non-ASCII characters. Would it be appropriate to add use of non-ASCII characters in SMTP commands and the requirements
something like "in the absence of relevant extensions" there? Also, about message content in Section 2.3.1 an equally strong one for
given [mis]behavior seen in the wild, does that paragraph (or an A/S) content. Would it be appropriate to add something like "in the
need an explicit caution about SMTP servers or clients assuming they absence of relevant extensions" there? Also, given [mis]behavior
can apply the popular web convention of using %NN sequences as a way seen in the wild, does that paragraph (or an A/S) need an explicit
to encode non-ASCII characters (<pct-encoded> in RFC 3986) and caution about SMTP servers or clients assuming they can apply the
assuming some later system will interpret it as they expect? Would popular web convention of using %NN sequences as a way to encode non-
it be appropriate to add an Internationalization Considerations ASCII characters (<pct-encoded> in RFC 3986) and assuming some later
section to the body of this document if only for the purpose of system will interpret it as they expect? Would it be appropriate to
pointing people elsewhere? add an Internationalization Considerations section to the body of
this document if only for the purpose of pointing people elsewhere?
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
for 5321bis (and 5322bis), those documents make assumptions and
interpretations of the core documents. Are there areas in which
5321bis could and should be clarified to lay a more solid foundation
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.
skipping to change at page 104, line 37 skipping to change at page 104, line 46
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
Ticket #43. Ticket #43.
G.14. The FOR Clause in Trace Fields: Semantics, Security
Considerations, and Other Issues
The FOR clause in time-stamp ("Received:") fields is seriously under-
defined. It is optional, the syntax is clear, but its semantics and
use, while perhaps obvious from content and the application of common
sense, have never been defined ("never" going back to 821). Do we
want to better define it? Is there any chance that a definition
would invalid existing, conforming and sensible, implementations? If
we do want to define semantics, draft text and advice as to where it
should go are invited.
Note the existing discussions in Section 7.2 and Section 7.6 as they
may need adjustment, or at least cross-references, if FOR is more
precisely defined.
There is probably an error in Section 7.6. Its last sentence implies
a possible interaction between messages with multiple recipients and
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
statement is meaningful. Should it be revised to discuss other
situations in which including FOR might not be desirable from a
security or privacy standpoint?
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 [52]. As with the previous since its publication in October 2008 [52]. As with the previous
appendix, ticket numbers included below reference appendix, ticket numbers included below reference
https://trac.ietf.org/trac/emailcore/report/1 . [[CREF31: [[Note in https://trac.ietf.org/trac/emailcore/report/1 . [[CREF28: [[Note in
Draft: Items with comments below have not yet been resolved as Draft: Items with comments below have not yet been resolved as
errata. As of the end of November 2020, none of them have been errata. As of the end of November 2020, none of them have been
checked and verified by the emailcore WG.]]]]. checked and verified by the emailcore WG.]]]].
1683 ABNF error. Section 4.4 1683 ABNF error. Section 4.4
Ticket #23. Ticket #23.
4198 Description error. Section 4.2. 4198 Description error. Section 4.2.
RESOLVED, ticket #24, 2020-12-14. 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 Ticket #26
4315 ABNF - IPv6 Section 4.1.3. [[CREF32: [5321bis]The IPv6 syntax 4315 ABNF - IPv6 Section 4.1.3. [[CREF29: [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. Ticket #27.
5414 ABNF for Quoted-string Section 4.1.2 5414 ABNF for Quoted-string Section 4.1.2
Ticket #22. 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. Text
[[CREF33: [5321bis]Matter of taste, editor seeks advice.]] moved per email 2020-12-31.
Ticket #28. 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. [[CREF30: [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
2119 or even the IETF itself. It appears to me that trying to 2119 or even the IETF itself. It appears to me that trying to
patch that style might easily result in a document that is harder patch that style might easily result in a document that is harder
to read as well as being error prone. If we want to get the to read as well as being error prone. If we want to get the
document entirely into contemporary style, we really should bite document entirely into contemporary style, we really should bite
the bullet and do a complete rewrite. To respond to a different the bullet and do a complete rewrite. To respond to a 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 be 5321/5322 and their predecessors differ in places and why would 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 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. [[CREF31:
[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. Ticket #29.
4055 Erratum claims the the description of SPF and DKIM is wrong. 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 It is not clear what 5321bis should really say about them, but the
current text probably needs work (or dropping, which is what the current text probably needs work (or dropping, which is what the
proposed erratum suggests). See 5321bis Editor's Note in proposed erratum suggests). See 5321bis Editor's Note in
Section 3.6.2. Section 3.6.2.
Ticket #30. Ticket #30.
[[CREF36: [5321bis]Note that rejected errata have _not_ been reviewed [[CREF32: [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.
o Introductory paragraph to Appendix F extended to make it clear o Introductory paragraph to Appendix F extended to make it clear
skipping to change at page 109, line 22 skipping to change at page 110, line 10
o Added ticket numbers to descriptions of issues and changes, o Added ticket numbers to descriptions of issues and changes,
adjusted some text so relationships would be more clear, and added adjusted some text so relationships would be more clear, and added
subsections to the Appendix G and H lists to pick up on tickets subsections to the Appendix G and H lists to pick up on tickets
that were not easily identified in those sections of with the that were not easily identified in those sections of with the
text. text.
o Made several additions to the Index, including one to deal with o Made several additions to the Index, including one to deal with
SEND et al., as above. SEND et al., as above.
H.3.6. Changes from draft-ietf-emailcore-rfc5321bis-01 (2020-12-25) to
-02
o Corrected discussion mailing list to point to emailcore@ietf.org
in the introductory note.
o Added new subsection(s) to Appendix G to reflect newly discovered
issues.
o Changed "as discussed in" references in Section 4.5.5 per ticket
#45.
o Corrected a misleading use of the term "mailbox" in Section 3.3.
o Changed descriptions of use of first digit in replies per ticket
#13. See Appendix G.7.7.
o Moved paragraph per ticket #28, erratum 1851.
o Added more clarifying cross-references, clarified some CREFs, and
cleaned out some of those that no longer seemed relevant.
o Removed "updates 1123" is unnecessary and obsolete.
o Updated several references.
Index Index
A A
Argument Syntax Argument Syntax
A-d-l 42 A-d-l 43
Additional-Registered-Clauses 63 Additional-Registered-Clauses 63
address-literal 43 address-literal 43
Addtl-Link 63 Addtl-Link 64
Addtl-Protocol 63 Addtl-Protocol 64
ALPHA 42 ALPHA 42
Argument 43 Argument 43
At-domain 42 At-domain 43
atext 42 atext 43
Atom 43 Atom 44
By-domain 62 By-domain 63
CFWS 42 CFWS 43
CRLF 42 CRLF 42
dcontent 45 dcontent 45
DIGIT 42 DIGIT 42
Domain 43 Domain 43
Dot-string 43 Dot-string 44
esmtp-keyword 42 esmtp-keyword 43
esmtp-param 42 esmtp-param 43
esmtp-value 43 esmtp-value 43
Extended-Domain 62 Extended-Domain 63
For 63 For 63
Forward-Path 42 Forward-Path 43
From-domain 62 From-domain 63
FWS 42 FWS 43
General-address-literal 45 General-address-literal 45
Greeting 48 Greeting 49
h16 45 h16 46
HEXDIG 42 HEXDIG 42
ID 63 ID 63
IPv4-address-literal 45 IPv4-address-literal 45
IPv6-addr 45 IPv6-addr 46
IPv6-address-literal 45 IPv6-address-literal 45
Keyword 43 Keyword 43
Ldh-str 43 Ldh-str 43
Let-dig 43 Let-dig 43
Link 63 Link 63
Local-part 43 Local-part 44
ls32 45 ls32 46
Mail-parameters 42 Mail-parameters 43
Mailbox 43 Mailbox 43
Opt-info 63 Opt-info 63
Path 42 Path 43
Protocol 63 Protocol 64
QcontentSMTP 43 QcontentSMTP 44
qtextSMTP 43 qtextSMTP 44
quoted-pairSMTP 43 quoted-pairSMTP 44
Quoted-string 43 Quoted-string 44
Rcpt-parameters 42 Rcpt-parameters 43
Reply-code 48 Reply-code 49
Reply-line 48 Reply-line 49
Return-path-line 62 Return-path-line 63
Reverse-Path 42 Reverse-Path 43
Snum 45 Snum 46
SP 42 SP 42
Stamp 62 Stamp 63
Standardized-tag 45 Standardized-tag 45
String 43 String 44
sub-domain 43 sub-domain 43
TCP-info 62 TCP-info 63
textstring 48 textstring 49
Time-stamp-line 62 Time-stamp-line 63
Via 63 Via 63
With 63 With 63
C C
Command Syntax Command Syntax
data 39 data 40
ehlo 20, 34 ehlo 20, 35
expn 40 expn 41
helo 34 helo 35
help 41 help 41
mail 36 mail 37
noop 41 noop 41
quit 41 quit 42
rcpt 38 rcpt 38
rset 40 rset 40
send, saml, soml 102 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
 End of changes. 100 change blocks. 
209 lines changed or deleted 279 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/