< draft-ietf-emailcore-rfc5321bis-03.txt   draft-ietf-emailcore-rfc5321bis-04.txt >
EMAILCORE J. Klensin EMAILCORE J. Klensin
Internet-Draft July 10, 2021 Internet-Draft October 3, 2021
Obsoletes: 5321, 1846, 7504 (if Obsoletes: 5321, 1846, 7504, 7505 (if
approved) approved)
Intended status: Standards Track Intended status: Standards Track
Expires: January 11, 2022 Expires: April 6, 2022
Simple Mail Transfer Protocol Simple Mail Transfer Protocol
draft-ietf-emailcore-rfc5321bis-03 draft-ietf-emailcore-rfc5321bis-04
Abstract Abstract
This document is a specification of the basic protocol for Internet This document is a specification of the basic protocol for Internet
electronic mail transport. It consolidates, updates, and clarifies electronic mail transport. It consolidates, updates, and clarifies
several previous documents, making all or parts of most of them several previous documents, making all or parts of most of them
obsolete. It covers the SMTP extension mechanisms and best practices obsolete. It covers the SMTP extension mechanisms and best practices
for the contemporary Internet, but does not provide details about for the contemporary Internet, but does not provide details about
particular extensions. Although SMTP was designed as a mail particular extensions. Although SMTP was designed as a mail
transport and delivery protocol, this specification also contains transport and delivery protocol, this specification also contains
skipping to change at page 2, line 12 skipping to change at page 2, line 12
approximations to original text and document structures in most approximations to original text and document structures in most
cases. One result is that information may not be be organized as the 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 reader might expect. An index is provided to assist in the quest for
information. information.
This evolving draft should be discussed on the emailcore@ietf.org This evolving draft should be discussed on the emailcore@ietf.org
list. list.
Technology Note: The table of contents would be much easier to use, Technology Note: The table of contents would be much easier to use,
especially for locating commands, if the subsections containing the especially for locating commands, if the subsections containing the
commands where listed. The source XML is marked up with commands were listed. The source XML is marked up with "toc=include"
"toc=include" attributes to facilitate that. Unfortunately, there is attributes to facilitate that. Unfortunately, there is apparently a
apparently a bug in the current version of xml2rfc v2, one that also bug in the current version of xml2rfc v2, one that also appeared in
appeared in the version used ot generate RFC 5321, that prevents the version used ot generate RFC 5321, that prevents those
those subsections from appearing in the TOC. The command names can subsections from appearing in the TOC. The command names can now be
now be found in the index, but the index is to page numbers, not found in the index, but the index is to page numbers, not section
section numbers. Both problems have been reported. numbers. Both problems have been reported.
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 January 11, 2022. This Internet-Draft will expire on April 6, 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 45 skipping to change at page 3, line 45
3.5. Commands for Debugging Addresses . . . . . . . . . . . . 24 3.5. Commands for Debugging Addresses . . . . . . . . . . . . 24
3.5.1. Overview . . . . . . . . . . . . . . . . . . . . . . 25 3.5.1. Overview . . . . . . . . . . . . . . . . . . . . . . 25
3.5.2. VRFY Normal Response . . . . . . . . . . . . . . . . 27 3.5.2. VRFY Normal Response . . . . . . . . . . . . . . . . 27
3.5.3. Meaning of VRFY or EXPN Success Response . . . . . . 27 3.5.3. Meaning of VRFY or EXPN Success Response . . . . . . 27
3.5.4. Semantics and Applications of EXPN . . . . . . . . . 28 3.5.4. Semantics and Applications of EXPN . . . . . . . . . 28
3.6. Relaying and Mail Routing . . . . . . . . . . . . . . . . 28 3.6. Relaying and Mail Routing . . . . . . . . . . . . . . . . 28
3.6.1. Source Routes and Relaying . . . . . . . . . . . . . 28 3.6.1. Source Routes and Relaying . . . . . . . . . . . . . 28
3.6.2. Mail eXchange Records and Relaying . . . . . . . . . 29 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 . . . . . . . . . . . . . 31 3.7.1. Header Fields in Gatewaying . . . . . . . . . . . . . 30
3.7.2. Received Lines in Gatewaying . . . . . . . . . . . . 31 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 . . . . . . . . . . 32 3.7.4. Other Header Fields in Gatewaying . . . . . . . . . . 31
3.7.5. Envelopes in Gatewaying . . . . . . . . . . . . . . . 32 3.7.5. Envelopes in Gatewaying . . . . . . . . . . . . . . . 32
3.8. Terminating Sessions and Connections . . . . . . . . . . 32 3.8. Terminating Sessions and Connections . . . . . . . . . . 32
3.9. Mailing Lists and Aliases . . . . . . . . . . . . . . . . 33 3.9. Mailing Lists and Aliases . . . . . . . . . . . . . . . . 33
3.9.1. Alias . . . . . . . . . . . . . . . . . . . . . . . . 34 3.9.1. Alias . . . . . . . . . . . . . . . . . . . . . . . . 33
3.9.2. List . . . . . . . . . . . . . . . . . . . . . . . . 34 3.9.2. List . . . . . . . . . . . . . . . . . . . . . . . . 34
4. The SMTP Specifications . . . . . . . . . . . . . . . . . . . 34 4. The SMTP Specifications . . . . . . . . . . . . . . . . . . . 34
4.1. SMTP Commands . . . . . . . . . . . . . . . . . . . . . . 34 4.1. SMTP Commands . . . . . . . . . . . . . . . . . . . . . . 34
4.1.1. Command Semantics and Syntax . . . . . . . . . . . . 34 4.1.1. Command Semantics and Syntax . . . . . . . . . . . . 34
4.1.2. Command Argument Syntax . . . . . . . . . . . . . . . 43 4.1.2. Command Argument Syntax . . . . . . . . . . . . . . . 42
4.1.3. Address Literals . . . . . . . . . . . . . . . . . . 45 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 . . . . . . . . . . . . . . . . 48 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 . . . . . . . . . . 50 4.2.1. Reply Code Severities and Theory . . . . . . . . . . 50
4.2.2. Reply Codes by Function Groups . . . . . . . . . . . 53 4.2.2. Reply Codes by Function Groups . . . . . . . . . . . 52
4.2.3. Reply Codes in Numeric Order . . . . . . . . . . . . 54 4.2.3. Reply Codes in Numeric Order . . . . . . . . . . . . 54
4.2.4. Some specific code situations and relationships . . . 56 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 . . . . . . . . . . . 57
4.3.1. Sequencing Overview . . . . . . . . . . . . . . . . . 57 4.3.1. Sequencing Overview . . . . . . . . . . . . . . . . . 57
4.3.2. Command-Reply Sequences . . . . . . . . . . . . . . . 58 4.3.2. Command-Reply Sequences . . . . . . . . . . . . . . . 58
4.4. Trace Information . . . . . . . . . . . . . . . . . . . . 60 4.4. Trace Information . . . . . . . . . . . . . . . . . . . . 60
4.5. Additional Implementation Issues . . . . . . . . . . . . 64 4.5. Additional Implementation Issues . . . . . . . . . . . . 64
4.5.1. Minimum Implementation . . . . . . . . . . . . . . . 64 4.5.1. Minimum Implementation . . . . . . . . . . . . . . . 64
4.5.2. Transparency . . . . . . . . . . . . . . . . . . . . 65 4.5.2. Transparency . . . . . . . . . . . . . . . . . . . . 65
4.5.3. Sizes and Timeouts . . . . . . . . . . . . . . . . . 66 4.5.3. Sizes and Timeouts . . . . . . . . . . . . . . . . . 66
4.5.4. Retry Strategies . . . . . . . . . . . . . . . . . . 70 4.5.4. Retry Strategies . . . . . . . . . . . . . . . . . . 70
4.5.5. Messages with a Null Reverse-Path . . . . . . . . . . 72 4.5.5. Messages with a Null Reverse-Path . . . . . . . . . . 72
skipping to change at page 6, line 13 skipping to change at page 6, line 13
G.7.19. Minimum Lengths and Quantities . . . . . . . . . . . 104 G.7.19. Minimum Lengths and Quantities . . . . . . . . . . . 104
G.8. Enhanced Reply Codes and DSNs . . . . . . . . . . . . . . 104 G.8. Enhanced Reply Codes and DSNs . . . . . . . . . . . . . . 104
G.9. Revisiting Quoted Strings . . . . . . . . . . . . . . . . 105 G.9. Revisiting Quoted Strings . . . . . . . . . . . . . . . . 105
G.10. Internationalization . . . . . . . . . . . . . . . . . . 105 G.10. Internationalization . . . . . . . . . . . . . . . . . . 105
G.11. SMTP Clients, Servers, Senders, and Receivers . . . . . . 106 G.11. SMTP Clients, Servers, Senders, and Receivers . . . . . . 106
G.12. Extension Keywords Starting in 'X-' . . . . . . . . . . . 106 G.12. Extension Keywords Starting in 'X-' . . . . . . . . . . . 106
G.13. Deprecating HELO . . . . . . . . . . . . . . . . . . . . 106 G.13. Deprecating HELO . . . . . . . . . . . . . . . . . . . . 106
G.14. The FOR Clause in Trace Fields: Semantics, Security G.14. The FOR Clause in Trace Fields: Semantics, Security
Considerations, and Other Issues . . . . . . . . . . . . 107 Considerations, and Other Issues . . . . . . . . . . . . 107
G.15. Resistance to Attacks and Operational Necessity . . . . . 107 G.15. Resistance to Attacks and Operational Necessity . . . . . 108
Appendix H. RFC 5321 Errata Summary and Tentative Change Log . . 107 Appendix H. RFC 5321 Errata Summary and Tentative Change Log . . 108
H.1. RFC 5321 Errata Summary . . . . . . . . . . . . . . . . . 108 H.1. RFC 5321 Errata Summary . . . . . . . . . . . . . . . . . 108
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 . . . . . . . . . . . 109 initial (-00) version of this draft . . . . . . . . . . . 110
H.3. Changes Among Versions of Rfc5321bis . . . . . . . . . . 111 H.3. Changes Among Versions of Rfc5321bis . . . . . . . . . . 111
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 . . . . . . . . . . . . . . . . . 111 2012-12-02) to -01 . . . . . . . . . . . . . . . . . 111
H.3.2. Changes from draft-klensin-rfc5321bis-01 (20191203) H.3.2. Changes from draft-klensin-rfc5321bis-01 (20191203)
to -02 . . . . . . . . . . . . . . . . . . . . . . . 111 to -02 . . . . . . . . . . . . . . . . . . . . . . . 111
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 . . . . . . . . . . . . . . . . . . . . . . . 111 to -03 . . . . . . . . . . . . . . . . . . . . . . . 111
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 . . . . . . . . 112 to draft-ietf-emailcore-rfc5321bis-00 . . . . . . . . 112
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 . . . . . . . . . . . . . . . . . 112 (2020-10-06) to -01 . . . . . . . . . . . . . . . . . 112
H.3.6. Changes from draft-ietf-emailcore-rfc5321bis-01 H.3.6. Changes from draft-ietf-emailcore-rfc5321bis-01
(2020-12-25) to -02 . . . . . . . . . . . . . . . . . 112 (2020-12-25) to -02 . . . . . . . . . . . . . . . . . 113
H.3.7. Changes from draft-ietf-emailcore-rfc5321bis-02 H.3.7. Changes from draft-ietf-emailcore-rfc5321bis-02
(2021-02-21) to -03 . . . . . . . . . . . . . . . . . 113 (2021-02-21) to -03 . . . . . . . . . . . . . . . . . 113
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 H.3.8. Changes from draft-ietf-emailcore-rfc5321bis-03
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 116 (2021-07-10) to -04 . . . . . . . . . . . . . . . . . 114
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 117
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 8, line 7 skipping to change at page 8, line 9
clarity and brevity; readers needing them should refer to RFC 821. clarity and brevity; readers needing them should refer to RFC 821.
It also includes some additional material from RFC 1123 that required It also includes some additional material from RFC 1123 that required
amplification. This material has been identified in multiple ways, amplification. This material has been identified in multiple ways,
mostly by tracking flaming on various lists and newsgroups and mostly by tracking flaming on various lists and newsgroups and
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.
[[CREF2: JcK: 202107219: does the text that follows need rewriting?
See comment in Abstract. ]]
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 [14], RFC 1939 [23]) and IMAP (RFC 3501 Protocol (POP) (RFC 937 [14], RFC 1939 [23]) and IMAP (RFC 3501
[36]). In general, the separate mail submission protocol specified [36]). In general, the separate mail submission protocol specified
in RFC 6409 [42] is now preferred to direct use of SMTP; more in RFC 6409 [42] is now preferred to direct use of SMTP; more
discussion of that subject appears in that document. discussion of that subject appears in that document.
Section 2.3 provides definitions of terms specific to this document. Section 2.3 provides definitions of terms specific to this document.
Except when the historical terminology is necessary for clarity, this Except when the historical terminology is necessary for clarity, this
document uses the current 'client' and 'server' terminology to document uses the current 'client' and 'server' terminology to
identify the sending and receiving SMTP processes, respectively. identify the sending and receiving SMTP processes, respectively.
A companion document, RFC 5322 [12], discusses message header A companion document, RFC 5322 [12], discusses message header
sections and bodies and specifies formats and structures for them. sections and bodies and specifies formats and structures for them.
[[CREF2: [rfc5321bis 20210317] Would this be an appropriate place to [[CREF3: [rfc5321bis 20210317] Would this be an appropriate place to
mention RFC 2045 (MIME) and/or RFC 6409 (Message Submission)?]] mention RFC 2045 (MIME) and/or RFC 6409 (Message Submission)?]]
1.3. Document Conventions 1.3. Document Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1]. As each document are to be interpreted as described in RFC 2119 [1]. As each
of these terms was intentionally and carefully chosen to improve the of these terms was intentionally and carefully chosen to improve the
interoperability of email, each use of these terms is to be treated interoperability of email, each use of these terms is to be treated
as a conformance requirement. as a conformance requirement.
Because this document has a long history and to avoid the risk of Because this document has a long history and to avoid the risk of
various errors and of confusing readers and documents that point to various errors and of confusing readers and documents that point to
this one, most examples and the domain names they contain are this one, most examples and the domain names they contain are
preserved from RFC 2821. Readers are cautioned that these are preserved from RFC 2821. Readers are cautioned that these are
illustrative examples that should not actually be used in either code illustrative examples that should not actually be used in either code
or configuration files. or configuration files.
2. The SMTP Model 2. The SMTP Model
[[CREF3: [5321bis] [[Editor's Note: There have been extensive and [[CREF4: [5321bis] [[Editor's Note: There have been extensive and
repeated discussions on the SMTP and IETF lists about whether this repeated discussions on the SMTP and IETF lists about whether this
document should say something about hop-by-hop (MTA-to-MTA) SMTP document should say something about hop-by-hop (MTA-to-MTA) SMTP
authentication and, if so, what?? Note that end to end message authentication and, if so, what?? Note that end to end message
authentication is almost certainly out of scope for SMTP.]]]] authentication is almost certainly out of scope for SMTP.]]]]
2.1. Basic Structure 2.1. Basic Structure
The SMTP design can be pictured as: The SMTP design can be pictured as:
+----------+ +----------+ +----------+ +----------+
skipping to change at page 14, line 43 skipping to change at page 14, line 43
targets of mail. At the source, an MUA might collect mail to be targets of mail. At the source, an MUA might collect mail to be
transmitted from a user and hand it off to an MTA; the final transmitted from a user and hand it off to an MTA; the final
("delivery") MTA would be thought of as handing the mail off to an ("delivery") MTA would be thought of as handing the mail off to an
MUA (or at least transferring responsibility to it, e.g., by MUA (or at least transferring responsibility to it, e.g., by
depositing the message in a "message store"). However, while these depositing the message in a "message store"). However, while these
terms are used with at least the appearance of great precision in terms are used with at least the appearance of great precision in
other environments, the implied boundaries between MUAs and MTAs other environments, the implied boundaries between MUAs and MTAs
often do not accurately match common, and conforming, practices with often do not accurately match common, and conforming, practices with
Internet mail. Hence, the reader should be cautious about inferring Internet mail. Hence, the reader should be cautious about inferring
the strong relationships and responsibilities that might be implied the strong relationships and responsibilities that might be implied
if these terms were used elsewhere. if these terms were used elsewhere
.[[CREF5: JcK 20210729: Does the above need to be rewritten to
identify the MSA role? ]]
2.3.4. Host 2.3.4. Host
For the purposes of this specification, a host is a computer system For the purposes of this specification, a host is a computer system
attached to the Internet (or, in some cases, to a private TCP/IP attached to the Internet (or, in some cases, to a private TCP/IP
network) and supporting the SMTP protocol. Hosts are known by names network) and supporting the SMTP protocol. Hosts are known by names
(see the next section); they SHOULD NOT be identified by numerical (see the next section); they SHOULD NOT be identified by numerical
addresses, i.e., by address literals as described in Section 4.1.2. addresses, i.e., by address literals as described in Section 4.1.2.
2.3.5. Domain Names 2.3.5. Domain Names
skipping to change at page 15, line 34 skipping to change at page 15, line 36
The domain name, as described in this document and in RFC 1035 [4], The domain name, as described in this document and in RFC 1035 [4],
is the entire, fully-qualified name (often referred to as an "FQDN"). is the entire, fully-qualified name (often referred to as an "FQDN").
A domain name that is not in FQDN form is no more than a local alias. A domain name that is not in FQDN form is no more than a local alias.
Local aliases MUST NOT appear in any SMTP transaction. Local aliases MUST NOT appear in any SMTP transaction.
Only resolvable, fully-qualified domain names (FQDNs) are permitted Only resolvable, fully-qualified domain names (FQDNs) are permitted
when domain names are used in SMTP. In other words, names that can when domain names are used in SMTP. In other words, names that can
be resolved to MX RRs or address (i.e., A or AAAA) RRs (as discussed be resolved to MX RRs or address (i.e., A or AAAA) RRs (as discussed
in Section 5) are permitted, as are CNAME RRs whose targets can be in Section 5) are permitted, as are CNAME RRs whose targets can be
resolved, in turn, to MX or address RRs. resolved, in turn, to MX or address RRs.
[[CREF4: [[5321bis Editor's Note: it is not clear whether "In other [[CREF6: [[5321bis Editor's Note: it is not clear whether "In other
words" really meant "for example" or it is was intended that the only words" really meant "for example" or it is was intended that the only
labels permitted are those that own records in one of the above RR labels permitted are those that own records in one of the above RR
types]]]] types]]]]
Local nicknames or unqualified names MUST NOT be used. There are two Local nicknames or unqualified names MUST NOT be used. There are two
exceptions to the rule requiring FQDNs: exceptions to the rule requiring FQDNs:
o The domain name given in the EHLO command MUST be either a primary o The domain name given in the EHLO command MUST be either a primary
host name (a domain name that resolves to an address RR) or, if host name (a domain name that resolves to an address RR) or, if
the host has no name, an address literal, as described in the host has no name, an address literal, as described in
Section 4.1.3 and discussed further in the EHLO discussion of Section 4.1.3 and discussed further in the EHLO discussion of
skipping to change at page 17, line 33 skipping to change at page 17, line 33
A "gateway" SMTP system (usually referred to just as a "gateway") A "gateway" SMTP system (usually referred to just as a "gateway")
receives mail from a client system in one transport environment and receives mail from a client system in one transport environment and
transmits it to a server system in another transport environment. transmits it to a server system in another transport environment.
Differences in protocols or message semantics between the transport Differences in protocols or message semantics between the transport
environments on either side of a gateway may require that the gateway environments on either side of a gateway may require that the gateway
system perform transformations to the message that are not permitted system perform transformations to the message that are not permitted
to SMTP relay systems. For the purposes of this specification, to SMTP relay systems. For the purposes of this specification,
firewalls that rewrite addresses should be considered as gateways, firewalls that rewrite addresses should be considered as gateways,
even if SMTP is used on both sides of them (see RFC 2979 [32]). even if SMTP is used on both sides of them (see RFC 2979 [32]).
[[CREF5: [5321bis] [[Note in draft/Placeholder: There has been a [[CREF7: [5321bis] [[Note in draft/Placeholder: There has been a
request to expand this section, possibly into a more extensive model request to expand this section, possibly into a more extensive model
of Internet mail. Comments from others solicited. In particular, of Internet mail. Comments from others solicited. In particular,
does RFC 5598 make that suggestion OBE?]] ]] does RFC 5598 make that suggestion OBE?]] ]]
2.3.11. Mailbox and Address 2.3.11. Mailbox and Address
As used in this specification, an "address" is a character string As used in this specification, an "address" is a character string
that identifies a user to whom mail will be sent or a location into that identifies a user to whom mail will be sent or a location into
which mail will be deposited. The term "mailbox" refers to that which mail will be deposited. The term "mailbox" refers to that
depository. The two terms are typically used interchangeably unless depository. The two terms are typically used interchangeably unless
skipping to change at page 20, line 20 skipping to change at page 20, line 20
SMTP server implementations MAY include identification of their SMTP server implementations MAY include identification of their
software and version information in the connection greeting reply software and version information in the connection greeting reply
after the 220 code, a practice that permits more efficient isolation after the 220 code, a practice that permits more efficient isolation
and repair of any problems. Implementations MAY make provision for and repair of any problems. Implementations MAY make provision for
SMTP servers to disable the software and version announcement where SMTP servers to disable the software and version announcement where
it causes security concerns. While some systems also identify their it causes security concerns. While some systems also identify their
contact point for mail problems, this is not a substitute for contact point for mail problems, this is not a substitute for
maintaining the required "postmaster" address (see Section 4). maintaining the required "postmaster" address (see Section 4).
The SMTP protocol allows a server to formally reject a mail session The SMTP protocol allows a server to formally reject a mail session
while still allowing the initial connection as follows: a 554 while still allowing the initial connection as follows: a 521
response MAY be given in the initial connection opening message response MAY be given in the initial connection opening message
instead of the 220. A server taking this approach MUST still wait instead of the 220. A server taking this approach MUST still wait
for the client to send a QUIT (see Section 4.1.1.10) before closing for the client to send a QUIT (see Section 4.1.1.10) before closing
the connection and SHOULD respond to any intervening commands with the connection and SHOULD respond to any intervening commands with
"503 bad sequence of commands". Since an attempt to make an SMTP "503 bad sequence of commands". Since an attempt to make an SMTP
connection to such a system is probably in error, a server returning connection to such a system is probably in error, a server returning
a 554 response on connection opening SHOULD provide enough a 521 [[CREF8: (or 554?]] response on connection opening SHOULD
information in the reply text to facilitate debugging of the sending provide enough information in the reply text to facilitate debugging
system. of the sending system. See Section 4.2.4.2.
3.2. Client Initiation 3.2. Client Initiation
Once the server has sent the greeting (welcoming) message and the Once the server has sent the greeting (welcoming) message and the
client has received it, the client normally sends the EHLO command to client has received it, the client normally sends the EHLO command to
the server, indicating the client's identity. In addition to opening the server, indicating the client's identity. In addition to opening
the session, use of EHLO indicates that the client is able to process the session, use of EHLO indicates that the client is able to process
service extensions and requests that the server provide a list of the service extensions and requests that the server provide a list of the
extensions it supports. Older SMTP systems that are unable to extensions it supports. Older SMTP systems that are unable to
support service extensions, and contemporary clients that do not support service extensions, and contemporary clients that do not
skipping to change at page 22, line 31 skipping to change at page 22, line 31
routes in the forward-path, but they SHOULD ignore the routes or MAY routes in the forward-path, but they SHOULD ignore the routes or MAY
decline to support the relaying they imply. Similarly, servers MAY decline to support the relaying they imply. Similarly, servers MAY
decline to accept mail that is destined for other hosts or systems. decline to accept mail that is destined for other hosts or systems.
These restrictions make a server useless as a relay for clients that These restrictions make a server useless as a relay for clients that
do not support full SMTP functionality. Consequently, restricted- do not support full SMTP functionality. Consequently, restricted-
capability clients MUST NOT assume that any SMTP server on the capability clients MUST NOT assume that any SMTP server on the
Internet can be used as their mail processing (relaying) site. If a Internet can be used as their mail processing (relaying) site. If a
RCPT command appears without a previous MAIL command, the server MUST RCPT command appears without a previous MAIL command, the server MUST
return a 503 "Bad sequence of commands" response. The optional return a 503 "Bad sequence of commands" response. The optional
<rcpt-parameters> are associated with negotiated SMTP service <rcpt-parameters> are associated with negotiated SMTP service
extensions (see Section 2.2). [[CREF6: [5321bis]: this section would extensions (see Section 2.2). [[CREF9: [5321bis]: this section would
be improved by being more specific about where mail transactions be improved by being more specific about where mail transactions
begin and end and then talking about "transaction state" here, rather begin and end and then talking about "transaction state" here, rather
than specific prior commands. --JcK]] than specific prior commands. --JcK]]
Since it has been a common source of errors, it is worth noting that Since it has been a common source of errors, it is worth noting that
spaces are not permitted on either side of the colon following FROM spaces are not permitted on either side of the colon following FROM
in the MAIL command or TO in the RCPT command. The syntax is exactly in the MAIL command or TO in the RCPT command. The syntax is exactly
as given above. as given above.
The third step in the procedure is the DATA command (or some The third step in the procedure is the DATA command (or some
skipping to change at page 23, line 8 skipping to change at page 23, line 8
If accepted, the SMTP server returns a 354 Intermediate reply and If accepted, the SMTP server returns a 354 Intermediate reply and
considers all succeeding lines up to but not including the end of considers all succeeding lines up to but not including the end of
mail data indicator to be the message text. When the end of text is mail data indicator to be the message text. When the end of text is
successfully received and stored, the SMTP-receiver sends a "250 OK" successfully received and stored, the SMTP-receiver sends a "250 OK"
reply. reply.
Since the mail data is sent on the transmission channel, the end of Since the mail data is sent on the transmission channel, the end of
mail data must be indicated so that the command and reply dialog can mail data must be indicated so that the command and reply dialog can
be resumed. SMTP indicates the end of the mail data by sending a be resumed. SMTP indicates the end of the mail data by sending a
line containing only a "." (period or full stop). A transparency line containing only a "." (period or full stop, hex 2E). A
procedure is used to prevent this from interfering with the user's transparency procedure is used to prevent this from interfering with
text (see Section 4.5.2). the user's text (see Section 4.5.2).
The end of mail data indicator also confirms the mail transaction and The end of mail data indicator also confirms the mail transaction and
tells the SMTP server to now process the stored recipients and mail tells the SMTP server to now process the stored recipients and mail
data. If accepted, the SMTP server returns a "250 OK" reply. The data. If accepted, the SMTP server returns a "250 OK" reply. The
DATA command can fail at only two points in the protocol exchange: DATA command can fail at only two points in the protocol exchange:
If there was no MAIL, or no RCPT, command, or all such commands were If there was no MAIL, or no RCPT, command, or all such commands were
rejected, the server MAY return a "command out of sequence" (503) or rejected, the server MAY return a "command out of sequence" (503) or
"no valid recipients" (554) reply in response to the DATA command. "no valid recipients" (554) reply in response to the DATA command.
If one of those replies (or any other 5yz reply) is received, the If one of those replies (or any other 5yz reply) is received, the
skipping to change at page 29, line 19 skipping to change at page 29, line 19
A relay SMTP server is usually the target of a DNS MX record that A relay SMTP server is usually the target of a DNS MX record that
designates it, rather than the final delivery system. The relay designates it, rather than the final delivery system. The relay
server may accept or reject the task of relaying the mail in the same server may accept or reject the task of relaying the mail in the same
way it accepts or rejects mail for a local user. If it accepts the way it accepts or rejects mail for a local user. If it accepts the
task, it then becomes an SMTP client, establishes a transmission task, it then becomes an SMTP client, establishes a transmission
channel to the next SMTP server specified in the DNS (according to channel to the next SMTP server specified in the DNS (according to
the rules in Section 5), and sends it the mail. If it declines to the rules in Section 5), and sends it the mail. If it declines to
relay mail to a particular address for policy reasons, a 550 response relay mail to a particular address for policy reasons, a 550 response
SHOULD be returned. SHOULD be returned.
[[CREF7: Proposed replacement for next paragraph (D Crocker [[CREF10: Text below reflects proposed replacement of the paragraph (
2021-03-17 17:23 email), Cf. Ticket #30: This specification does not edited version of suggestion by D Crocker 2021-03-17 17:23 email).
deal with the verification of a return path. Server efforts to Cf. Ticket #30:]]
verify a return path are outside the scope of this specification.]]
This specification does not deal with the verification of return This specification does not deal with the verification of return
paths for use in delivery notifications. Recent work, such as that paths. Server efforts to verify a return path and actions to be
on SPF [41] and DKIM [43] [44], has been done to provide ways to taken under various circumstances are outside the scope of this
ascertain that an address is valid or belongs to the person who specification.for use in delivery notifications.
actually sent the message. A server MAY attempt to verify the return
path before using its address for delivery notifications, but methods
of doing so are not defined here nor is any particular method
recommended at this time.
[[5321bis Editor's Note: Proposed erratum (4055) suggests that DKIM
and SPF have nothing to do with this and that everything after the
first sentence in the paragraph above should be dropped. An
alternative would be to tune the texts. ???]]
3.6.3. Message Submission Servers as Relays 3.6.3. Message Submission Servers as Relays
Many mail-sending clients exist, especially in conjunction with Many mail-sending clients exist, especially in conjunction with
facilities that receive mail via POP3 or IMAP, that have limited facilities that receive mail via POP3 or IMAP, that have limited
capability to support some of the requirements of this specification, capability to support some of the requirements of this specification,
such as the ability to queue messages for subsequent delivery such as the ability to queue messages for subsequent delivery
attempts. For these clients, it is common practice to make private attempts. For these clients, it is common practice to make private
arrangements to send all messages to a single server for processing arrangements to send all messages to a single server for processing
and subsequent distribution. SMTP, as specified here, is not ideally and subsequent distribution. SMTP, as specified here, is not ideally
skipping to change at page 33, line 28 skipping to change at page 33, line 16
There are circumstances, contrary to the intent of this There are circumstances, contrary to the intent of this
specification, in which an SMTP server may receive an indication that specification, in which an SMTP server may receive an indication that
the underlying TCP connection has been closed or reset. To preserve the underlying TCP connection has been closed or reset. To preserve
the robustness of the mail system, SMTP servers SHOULD be prepared 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 for this condition and SHOULD treat it as if a QUIT had been received
before the connection disappeared. before the connection disappeared.
3.9. Mailing Lists and Aliases 3.9. Mailing Lists and Aliases
[[CREF8: [5321bis] If "alias and list models" are explained [[CREF11: [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
the address of a person or other entity who administers the list. the address of a person or other entity who administers the list.
However, in this case, the message header section (RFC 5322 [12]) However, in this case, the message header section (RFC 5322 [12])
MUST be left unchanged; in particular, the "From" field of the header MUST be left unchanged; in particular, the "From" field of the header
skipping to change at page 45, line 39 skipping to change at page 45, line 26
the error) is blocked. To bypass this barrier, a special literal the error) is blocked. To bypass this barrier, a special literal
form of the address is allowed as an alternative to a domain name. form of the address is allowed as an alternative to a domain name.
For IPv4 addresses, this form uses four small decimal integers For IPv4 addresses, this form uses four small decimal integers
separated by dots and enclosed by brackets such as [123.255.37.2], separated by dots and enclosed by brackets such as [123.255.37.2],
which indicates an (IPv4) Internet Address in sequence-of-octets which indicates an (IPv4) Internet Address in sequence-of-octets
form. For IPv6 and other forms of addressing that might eventually form. For IPv6 and other forms of addressing that might eventually
be standardized, the form consists of a standardized "tag" that be standardized, the form consists of a standardized "tag" that
identifies the address syntax, a colon, and the address itself, in a identifies the address syntax, a colon, and the address itself, in a
format specified as part of the relevant standards (i.e., RFC 4291 format specified as part of the relevant standards (i.e., RFC 4291
[10] for IPv6). [10] for IPv6).
[[CREF9: [5321bis] Proposed erratum 4315 (2015-03-27) suggests yet [[CREF12: [5321bis] Proposed erratum 4315 (2015-03-27) suggests yet
another modification to the IPv6 address literal syntax, based on another modification to the IPv6 address literal syntax, based on
part on RFC 5952. We should consider whether those, or other, part on RFC 5952. We should consider whether those, or other,
modifications are appropriate and/or whether, given both the issues modifications are appropriate and/or whether, given both the issues
of spam/malware and servers supporting multiple domains, it it time of spam/malware and servers supporting multiple domains, it it time
to deprecate mailboxes containing address literals entirely (EHLO to deprecate mailboxes containing address literals entirely (EHLO
fields may be a different issue). If we are going to allow IPv6 fields may be a different issue). If we are going to allow IPv6
address literals, it may be time to incorporate something by address literals, it may be time to incorporate something by
reference rather than including specific syntax here (RFC 5952 is 14 reference rather than including specific syntax here (RFC 5952 is 14
pages long and does not contain any ABNF).]] pages long and does not contain any ABNF).]]
skipping to change at page 47, line 25 skipping to change at page 47, line 14
The SMTP client MUST, if possible, ensure that the domain parameter The SMTP client MUST, if possible, ensure that the domain parameter
to the EHLO command is a primary host name as specified for this to the EHLO command is a primary host name as specified for this
command in Section 2.3.5. If this is not possible (e.g., when the command in Section 2.3.5. If this is not possible (e.g., when the
client's address is dynamically assigned and the client does not have client's address is dynamically assigned and the client does not have
an obvious name), an address literal SHOULD be substituted for the an obvious name), an address literal SHOULD be substituted for the
domain name. domain name.
An SMTP server MAY verify that the domain name argument in the EHLO An SMTP server MAY verify that the domain name argument in the EHLO
command actually corresponds to the IP address of the client. command actually corresponds to the IP address of the client.
[[CREF10: [5321bis] [[Note in draft -- proposed change to "An SMTP [[CREF13: [5321bis] [[Note in draft -- proposed change to "An SMTP
server MAY verify that the domain name argument in the EHLO command server MAY verify that the domain name argument in the EHLO command
has an address record matching the IP address of the client." ]] has an address record matching the IP address of the client." ]]
However, if the verification fails, the server MUST NOT refuse to However, if the verification fails, the server MUST NOT refuse to
accept a message on that basis. Information captured in the accept a message on that basis. Information captured in the
verification attempt is for logging and tracing purposes. Note that verification attempt is for logging and tracing purposes. Note that
this prohibition applies to the matching of the parameter to its IP this prohibition applies to the matching of the parameter to its IP
address only; see Section 7.9 for a more extensive discussion of address only; see Section 7.9 for a more extensive discussion of
rejecting incoming connections or mail messages. rejecting incoming connections or mail messages.
[[CREF14: JcK 20210822: Whatever is done wit the above, it will
ultimately need a pointer to more discussion in the A/S.]]
The NOOP, HELP, EXPN, VRFY, and RSET commands can be used at any time The NOOP, HELP, EXPN, VRFY, and RSET commands can be used at any time
during a session, or without previously initializing a session. SMTP during a session, or without previously initializing a session. SMTP
servers SHOULD process these normally (that is, not return a 503 servers SHOULD process these normally (that is, not return a 503
code) even if no EHLO command has yet been received; clients SHOULD code) even if no EHLO command has yet been received; clients SHOULD
open a session with EHLO before sending these commands. open a session with EHLO before sending these commands.
If these rules are followed, the example in RFC 821 that shows "550 If these rules are followed, the example in RFC 821 that shows "550
access denied to you" in response to an EXPN command is incorrect access denied to you" in response to an EXPN command is incorrect
unless an EHLO command precedes the EXPN or the denial of access is unless an EHLO command precedes the EXPN or the denial of access is
based on the client's IP address or other authentication or based on the client's IP address or other authentication or
skipping to change at page 48, line 15 skipping to change at page 48, line 5
SMTP extensions (see Section 2.2) may create additional commands that SMTP extensions (see Section 2.2) may create additional commands that
initiate, abort, or end the transaction.More generally, any new initiate, abort, or end the transaction.More generally, any new
command MUST clearly document any effect it has on the transaction command MUST clearly document any effect it has on the transaction
state. state.
There may be zero or more transactions in a session. MAIL MUST NOT There may be zero or more transactions in a session. MAIL MUST NOT
be sent if a mail transaction is already open, i.e., it should be be sent if a mail transaction is already open, i.e., it should be
sent only if no mail transaction had been started in the session, or sent only if no mail transaction had been started in the session, or
if the previous one successfully concluded with a successful DATA if the previous one successfully concluded with a successful DATA
command, or if the previous one was aborted, e.g., with a RSET or new command, or if the previous one was aborted, e.g., with a RSET or new
EHLO. [[CREF11: [5321bis] See comment about changing this convoluted EHLO. [[CREF15: [5321bis] See comment about changing this convoluted
discussion to talk about 'mail transaction' above. --Jck (and see discussion to talk about 'mail transaction' above. --Jck (and see
Ticket #11 correspondence with Alexey 2021-07-06)]] Ticket #11 correspondence with Alexey 2021-07-06)]]
If the transaction beginning command argument is not acceptable, a If the transaction beginning command argument is not acceptable, a
501 failure reply MUST be returned and the SMTP server MUST stay in 501 failure reply MUST be returned and the SMTP server MUST stay in
the same state. If the commands in a transaction are out of order to the same state. If the commands in a transaction are out of order to
the degree that they cannot be processed by the server, a 503 failure the degree that they cannot be processed by the server, a 503 failure
reply MUST be returned and the SMTP server MUST stay in the same reply MUST be returned and the SMTP server MUST stay in the same
state. state.
skipping to change at page 54, line 22 skipping to change at page 54, line 10
452 Requested action not taken: insufficient system storage 452 Requested action not taken: insufficient system storage
(preferred code for "too many recipients", see Section 4.5.3.1.10) (preferred code for "too many recipients", see Section 4.5.3.1.10)
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, historically in the case of a
response, "No SMTP service here") connection-opening response, "No SMTP service here". 521 is now
[[CREF12: [5321bis] [[Note in Draft: Revise above statement in the preferred for that function at connection-opening if the server
light of new 521 code??]] ]] never accepts mail.)
[[CREF16: [5321bis] [[Note in Draft: Revise above statement in the
light of new 521 code?? -- revised with rfc5321bis-04]] ]]
4.2.3. Reply Codes in Numeric Order 4.2.3. Reply Codes in Numeric Order
211 System status, or system help reply 211 System status, or system help reply
214 Help message (Information on how to use the receiver or the 214 Help message (Information on how to use the receiver or the
meaning of a particular non-standard command; this reply is useful meaning of a particular non-standard command; this reply is useful
only to the human user) only to the human user)
220 <domain> Service ready 220 <domain> Service ready
skipping to change at page 55, line 29 skipping to change at page 55, line 18
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
521 No mail service 521 No mail service (See Section 4.2.4.2.)
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)
551 User not local; please try <forward-path> (See Section 3.4) 551 User not local; please try <forward-path> (See Section 3.4)
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)
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" although 521 is now preferred for
the latter. See Section 4.2.4.2.)
555 MAIL FROM/RCPT TO parameters not recognized or not implemented 555 MAIL FROM/RCPT TO parameters not recognized or not implemented
556 No mail service at this domain. 556 No mail service at this domain. (See Section 4.2.4.2.)
4.2.4. Some specific code situations and relationships 4.2.4. Some specific code situations and relationships
4.2.4.1. Reply Code 502 4.2.4.1. Reply Code 502
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
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 [20] and elsewhere). Obviously, it requires that system exist 7504 [48] 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.
used by a message submission or intermediate SMTP system (see
Section 1.1) to report that it cannot forward the message further When a domain does not intend to accept mail and wishes to publish
because it knows (e.g., from a DNS entry [51]) that the recipient that fact rather than being subjected to connection attempts, the
domain does not accept mail. It would normally be used in response best way to accomplish that is to use the "Null MX" convention. This
to a RCPT or similar (extension) command when the SMTP system is done by advertising a single MX RR (see Section 3.3.9 of (RFC 1035
[4]) with an RDATA section consisting of preference number 0 and a
zero-length label, written in master files as ".", as the exchange
domain, to denote that there exists no mail exchanger for that
domain. Reply code 556 is then used by a message submission or
intermediate SMTP system (see Section 1.1) to report that it cannot
forward the message further because it knows from the DNS entry that
the recipient domain does not accept mail. If, despite publishing
the DNS entry, the server domain chooses to respond on the SMTP port,
it SHOULD respond with the 566 code as well. The details of the Null
MX convention were first defined in RFC 7505 [49]; see that document
for additional discussion of the rationale for that convention.
Reply code 554 would normally be used in response to a RCPT command
(or extension command with similar intent) when the SMTP system
identifies a domain that it can (or has) determined never accepts identifies a domain that it can (or has) determined never accepts
mail. Other codes, including 554 and the temporary 450, are used for mail. Other codes, including 554 and the temporary 450, are used for
more transient situations and situations in which an SMTP server more transient situations and situations in which an SMTP server
cannot or will not deliver to (or accept mail for) a particular cannot or will not deliver to (or accept mail for) a particular
system or mailbox for policy reasons rather than ones directly system or mailbox for policy reasons rather than ones directly
related to SMTP processing. related to SMTP processing.
[[CREF17: [JcK 20210904]: do we want/need to discuss temporary server
outages? And is the discussion above sufficient to obsolete RFC 7505
or do we need either more text or some pretense to claim to update
it.]]
4.2.4.3. Reply Codes after DATA and the Subsequent <CRLF>.<CRLF> 4.2.4.3. Reply Codes after DATA and the Subsequent <CRLF>.<CRLF>
When an SMTP server returns a positive completion status (2yz code) When an SMTP server returns a positive completion status (2yz code)
after the DATA command is completed with <CRLF>.<CRLF>, it accepts after the DATA command is completed with <CRLF>.<CRLF>, it accepts
responsibility for: responsibility for:
o delivering the message (if the recipient mailbox exists), or o delivering the message (if the recipient mailbox exists), or
o if attempts to deliver the message fail due to transient o if attempts to deliver the message fail due to transient
conditions, retrying delivery some reasonable number of times at conditions, retrying delivery some reasonable number of times at
skipping to change at page 59, line 21 skipping to change at page 59, line 29
message if arguments are supplied in the absence of EHLO- message if arguments are supplied in the absence of EHLO-
advertised extensions. advertised extensions.
421 Service shutting down and closing transmission channel 421 Service shutting down and closing transmission channel
Specific sequences are: Specific sequences are:
CONNECTION ESTABLISHMENT CONNECTION ESTABLISHMENT
S: 220 S: 220
E: 521, 554 E: 521, 554, 556
EHLO or HELO EHLO or HELO
S: 250 S: 250
E: 504 (a conforming implementation could return this code only E: 504 (a conforming implementation could return this code only
in fairly obscure cases), 550, 502 (permitted only with an old- in fairly obscure cases), 550, 502 (permitted only with an old-
style server that does not support EHLO) style server that does not support EHLO)
MAIL MAIL
skipping to change at page 60, line 36 skipping to change at page 60, line 41
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) beginning of the message content, as or "Received" information) at the beginning of the message content,
discussed in Section 4.1.1.4. 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 62, line 20 skipping to change at page 62, line 27
path header fields before adding their own. path header fields before adding their own.
The primary purpose of the Return-path is to designate the address to The primary purpose of the Return-path is to designate the address to
which messages indicating non-delivery or other mail system failures which messages indicating non-delivery or other mail system failures
are to be sent. For this to be unambiguous, exactly one return path are to be sent. For this to be unambiguous, exactly one return path
SHOULD be present when the message is delivered. Systems using RFC SHOULD be present when the message is delivered. Systems using RFC
822 syntax with non-SMTP transports SHOULD designate an unambiguous 822 syntax with non-SMTP transports SHOULD designate an unambiguous
address, associated with the transport envelope, to which error address, associated with the transport envelope, to which error
reports (e.g., non-delivery messages) should be sent. reports (e.g., non-delivery messages) should be sent.
Historical note: Text in RFC 822 that appears to contradict the use Historical note: Text in RFC 822 that appears to contraindicate the
of the Return-path header field (or the envelope reverse-path address use of the Return-path header field (or the envelope reverse-path
from the MAIL command) as the destination for error messages is not address from the MAIL command) if the destination for error messages
applicable on the Internet. The reverse-path address (as copied into is not applicable on the Internet. The reverse-path address (as
the Return-path) MUST be used as the target of any mail containing copied into the Return-path) MUST be used as the target of any mail
delivery error messages. containing delivery error messages.
In particular: In particular:
o a gateway from SMTP -> elsewhere SHOULD insert a return-path o a gateway from SMTP -> elsewhere SHOULD insert a return-path
header field, unless it is known that the "elsewhere" transport header field, unless it is known that the "elsewhere" transport
also uses Internet domain addresses and maintains the envelope also uses Internet domain addresses and maintains the envelope
sender address separately. sender address separately.
o a gateway from elsewhere -> SMTP SHOULD delete any return-path o a gateway from elsewhere -> SMTP SHOULD delete any return-path
header field present in the message, and either copy that header field present in the message, and either copy that
skipping to change at page 63, line 44 skipping to change at page 64, line 4
TCP-info = address-literal / ( Domain FWS address-literal ) TCP-info = address-literal / ( Domain FWS address-literal )
; Information derived by server from TCP connection ; Information derived by server from TCP connection
; not client EHLO. ; not client EHLO.
Opt-info = [Via] [With] [ID] [For] Opt-info = [Via] [With] [ID] [For]
[Additional-Registered-Clauses] [Additional-Registered-Clauses]
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 [12] ; msg-id is defined in RFC 5322 [12]
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)
[[CREF18: [5321bis] 5321 errata #1683, 20090215, ]]
[[CREF13: [5321bis] 5321 errata #1683, 20090215, ]]
; 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
; registered with the Internet Assigned Numbers ; registered with the Internet Assigned Numbers
skipping to change at page 66, line 24 skipping to change at page 66, line 27
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.
[[CREF14: [5321bis] [[Note in Draft: Klensin 20191126: Given the [[CREF19: [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 80, line 16 skipping to change at page 80, line 16
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. [[CREF15: [rfc5321bis] [[Note in draft - extension header fields. [[CREF20: [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. See G.7.9 and ticket #15.]] Since this rule is often in the headers. See G.7.9 and ticket #15.]] Since this rule is often
violated in practice, and cannot be enforced, sending SMTP systems violated in practice, and cannot be enforced, sending SMTP systems
that are aware of "bcc" use MAY find it helpful to send each blind that are aware of "bcc" use MAY find it helpful to send each blind
copy as a separate message transaction containing only a single RCPT copy as a separate message transaction containing only a single RCPT
command. 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 24 skipping to change at page 83, line 24
8. IANA Considerations 8. IANA Considerations
IANA maintains three registries in support of this specification, all IANA maintains three registries in support of this specification, all
of which were created for RFC 2821 or earlier. This document expands of which were created for RFC 2821 or earlier. This document expands
the third one as specified below. The registry references listed are the third one as specified below. The registry references listed are
as of the time of publication; IANA does not guarantee the locations as of the time of publication; IANA does not guarantee the locations
associated with the URLs. The registries are as follows: associated with the URLs. The registries are as follows:
o The first, "Simple Mail Transfer Protocol (SMTP) Service o The first, "Simple Mail Transfer Protocol (SMTP) Service
Extensions" [49], consists of SMTP service extensions with the Extensions" [50], consists of SMTP service extensions with the
associated keywords, and, as needed, parameters and verbs. As associated keywords, and, as needed, parameters and verbs. As
specified in Section 2.2.2, no entry may be made in this registry specified in Section 2.2.2, no entry may be made in this registry
that starts in an "X". Entries may be made only for service that starts in an "X". Entries may be made only for service
extensions (and associated keywords, parameters, or verbs) that extensions (and associated keywords, parameters, or verbs) that
are defined in Standards-Track or Experimental RFCs specifically are defined in Standards-Track or Experimental RFCs specifically
approved by the IESG for this purpose. approved by the IESG for this purpose.
o The second registry, "Address Literal Tags" [50], consists of o The second registry, "Address Literal Tags" [51], consists of
"tags" that identify forms of domain literals other than those for "tags" that identify forms of domain literals other than those for
IPv4 addresses (specified in RFC 821 and in this document). The IPv4 addresses (specified in RFC 821 and in this document). The
initial entry in that registry is for IPv6 addresses (specified in initial entry in that registry is for IPv6 addresses (specified in
this document). Additional literal types require standardization this document). Additional literal types require standardization
before being used; none are anticipated at this time. before being used; none are anticipated at this time.
o The third, "Mail Transmission Types" [49], established by RFC 821 o The third, "Mail Transmission Types" [50], established by RFC 821
and renewed by this specification, is a registry of link and and renewed by this specification, is a registry of link and
protocol identifiers to be used with the "via" and "with" protocol identifiers to be used with the "via" and "with"
subclauses of the time stamp ("Received:" header field) described subclauses of the time stamp ("Received:" header field) described
in Section 4.4. Link and protocol identifiers in addition to in Section 4.4. Link and protocol identifiers in addition to
those specified in this document may be registered only by those specified in this document may be registered only by
standardization or by way of an RFC-documented, IESG-approved, standardization or by way of an RFC-documented, IESG-approved,
Experimental protocol extension. This name space is for Experimental protocol extension. This name space is for
identification and not limited in size: the IESG is encouraged to identification and not limited in size: the IESG is encouraged to
approve on the basis of clear documentation and a distinct method approve on the basis of clear documentation and a distinct method
rather than preferences about the properties of the method itself. rather than preferences about the properties of the method itself.
skipping to change at page 84, line 46 skipping to change at page 84, line 46
appears in this document as do several of Jon's original examples appears in this document as do several of Jon's original examples
that have been updated only as needed to reflect other changes in the that have been updated only as needed to reflect other changes in the
specification. specification.
The following filed errata against RFC 5321 that were not rejected at The following filed errata against RFC 5321 that were not rejected at
the time of submission: Jasen Betts, Adrien de Croy Guillaume Fortin- the time of submission: Jasen Betts, Adrien de Croy Guillaume Fortin-
Debigare Roberto Javier Godoy, David Romerstein, Dominic Sayers, Debigare Roberto Javier Godoy, David Romerstein, Dominic Sayers,
Rodrigo Speller, Alessandro Vesely, and Brett Watson. Some of those Rodrigo Speller, Alessandro Vesely, and Brett Watson. Some of those
individuals made additional suggestions after the EMAILCORE WG was individuals made additional suggestions after the EMAILCORE WG was
initiated. In addition to the above, several of whom continued to initiated. In addition to the above, several of whom continued to
make other suggestons, specific suggestions that led to corrections make other suggestions, specific suggestions that led to corrections
and improvements in early versions of the current specification were and improvements in early versions of the current specification were
received from Dave Crocker, Ned Freed, Arnt Gulbrandsen, Tony Hansen, received from Dave Crocker, Ned Freed, Arnt Gulbrandsen, Tony Hansen,
Barry Leiba, Ivar Lumi, Pete Resnick, Hector Santos, Paul Smith and Barry Leiba, Ivar Lumi, Pete Resnick, Hector Santos, Paul Smith and
others. 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.
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 as co-chairs. Todd Herr replaced Seth Alexey Melnikov and Seth Blank as co-chairs. Todd Herr replaced Seth
skipping to change at page 90, line 5 skipping to change at page 90, line 5
[47] Klensin, J., Freed, N., Rose, M., and D. Crocker, Ed., [47] Klensin, J., Freed, N., Rose, M., and D. Crocker, Ed.,
"SMTP Service Extension for 8-bit MIME Transport", STD 71, "SMTP Service Extension for 8-bit MIME Transport", STD 71,
RFC 6152, DOI 10.17487/RFC6152, March 2011, RFC 6152, DOI 10.17487/RFC6152, March 2011,
<https://www.rfc-editor.org/info/rfc6152>. <https://www.rfc-editor.org/info/rfc6152>.
[48] Klensin, J., "SMTP 521 and 556 Reply Codes", RFC 7504, [48] Klensin, J., "SMTP 521 and 556 Reply Codes", RFC 7504,
DOI 10.17487/RFC7504, June 2015, DOI 10.17487/RFC7504, June 2015,
<https://www.rfc-editor.org/info/rfc7504>. <https://www.rfc-editor.org/info/rfc7504>.
[49] Internet Assigned Number Authority (IANA), "IANA Mail [49] Levine, J. and M. Delany, "A "Null MX" No Service Resource
Record for Domains That Accept No Mail", RFC 7505,
DOI 10.17487/RFC7505, June 2015,
<https://www.rfc-editor.org/info/rfc7505>.
[50] Internet Assigned Number Authority (IANA), "IANA Mail
Parameters", 2007, Parameters", 2007,
<http://www.iana.org/assignments/mail-parameters>. <http://www.iana.org/assignments/mail-parameters>.
[50] Internet Assigned Number Authority (IANA), "Address [51] Internet Assigned Number Authority (IANA), "Address
Literal Tags", 2007, Literal Tags", 2007,
<http://www.iana.org/assignments/address-literal-tags>. <http://www.iana.org/assignments/address-literal-tags>.
[51] Levine, J. and M. Delany, "A "Null MX" No Service Resource
Record for Domains that Accept No Mail", September 2014,
<https://datatracker.ietf.org/doc/draft-ietf-appsawg-
nullmx/>.
[52] RFC Editor, "RFC Errata - RFC 5321", 2019, [52] RFC Editor, "RFC Errata - RFC 5321", 2019,
<https://www.rfc-editor.org/errata/rfc5321>. <https://www.rfc-editor.org/errata/rfc5321>.
Captured 2019-11-19 Captured 2019-11-19
[53] IANA, "SMTP Service Extensions", 2021, [53] IANA, "SMTP Service Extensions", 2021,
<https://www.iana.org/assignments/mail-parameters/mail- <https://www.iana.org/assignments/mail-parameters/mail-
parameters.xhtml#mail-parameters-2>. parameters.xhtml#mail-parameters-2>.
Notes in draft: RFC Editor: Please adjust date field to Notes in draft: RFC Editor: Please adjust date field to
skipping to change at page 93, line 6 skipping to change at page 93, line 6
Historically, for relay purposes, the forward-path may have been a Historically, for relay purposes, the forward-path may have been a
source route of the form "@ONE,@TWO:JOE@THREE", where ONE, TWO, and source route of the form "@ONE,@TWO:JOE@THREE", where ONE, TWO, and
THREE MUST be fully-qualified domain names. This form was used to THREE MUST be fully-qualified domain names. This form was used to
emphasize the distinction between an address and a route. The emphasize the distinction between an address and a route. The
mailbox (here, JOE@THREE) is an absolute address, and the route is mailbox (here, JOE@THREE) is an absolute address, and the route is
information about how to get there. The two concepts should not be information about how to get there. The two concepts should not be
confused. confused.
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 specification, 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,
skipping to change at page 101, line 49 skipping to change at page 101, line 49
G.7. Probably-substantive Discussion Topics Identified in Other Ways G.7. Probably-substantive Discussion Topics Identified in Other Ways
The following issues were identified as a group in the opening Note The following issues were identified as a group in the opening Note
but called out specifically only in embedded CREF comments in but called out specifically only in embedded CREF comments in
versions of this draft prior to the first EMAILCORE version. versions of this draft prior to the first EMAILCORE version.
G.7.1. Issues with 521, 554, and 556 codes G.7.1. Issues with 521, 554, and 556 codes
See new Section 4.2.4.2. More text may be needed, there or See new Section 4.2.4.2. More text may be needed, there or
elsewhere, about choices of codes in response to initial opening and elsewhere, about choices of codes in response to initial opening and
to EHLO, especially to deal with selective policy rejections. to EHLO, especially to deal with selective policy rejections. In
particular, should we more strongly discourage the use of 554 on
initial opening. And should we make up a 421 code (or a new 4yz
code, perhaps 454) code for situations where the server is
temporarily out of service?
Ticket #6. Ticket #6.
G.7.2. SMTP Model, terminology, and relationship to RFC 5598 G.7.2. SMTP Model, terminology, and relationship to RFC 5598
CREF comment in Section 2, CREF comment in Section 2.3.10, and CREF comment in Section 2, CREF comment in Section 2.3.10, and
comments in the introductory portion of Appendix G. comments in the introductory portion of Appendix G.
G.7.3. Resolvable FQDNs and private domain names G.7.3. Resolvable FQDNs and private domain names
Multiple CREF comments in Section 2.3.5 Multiple CREF comments in Section 2.3.5
Tickets #9, #10 and #41. Tickets #9, #10 and #41.
Ticket #41 marked "closed no change", per email 2021-0405. Ticket #41 marked "closed no change", per email 2021-0405.
G.7.4. Possible clarification about mail transactions and transaction G.7.4. Possible clarification about mail transactions and transaction
state state
CREF comment in Section 3.3 and also reference in Section 4.1.4 CREF comment in Section 3.3 and also reference in Section 4.1.4
Ticket #11. Ticket #11.
[[CREF16: See correspondence on this ticket 2021-07-06 through [[CREF21: See correspondence on this ticket 2021-07-06 through
2021-07-09.]] 2021-07-09.]]
G.7.5. Issues with mailing lists, aliases, and forwarding G.7.5. Issues with mailing lists, aliases, and forwarding
CREF comment in Section 3.9. May also want to note forwarding as an CREF comment in Section 3.9. May also want to note forwarding as an
email address portability issue. Note that, if changes are made in email address portability issue. Note that, if changes are made in
this area, they should be kept consistent with the description and this area, they should be kept consistent with the description and
discussion of the 251 and 551 in Section 4.2 and Section 3.5 as well discussion of the 251 and 551 in Section 4.2 and Section 3.5 as well
as Section 3.4 to avoid introducing inconsistencies. In addition, as Section 3.4 to avoid introducing inconsistencies. In addition,
there are some terminology issues about the use of the term "lists", there are some terminology issues about the use of the term "lists",
skipping to change at page 103, line 13 skipping to change at page 103, line 17
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. (See the additional question about minimum quantities, etc., in say. (See the additional question about minimum quantities, etc., in
Appendix G.7.19.) Appendix G.7.19.)
Ticket #14 and maybe Ticket #38. Ticket #14 (closed - no action) and maybe Ticket #38 (to A/S).
G.7.9. Discussion of 'blind' copies and RCPT G.7.9. Discussion of 'blind' copies and RCPT
CREF comment in Section 7.2. May also need to discussion whether CREF comment in Section 7.2. May also need to discussion whether
that terminology is politically incorrect and suggest a replacement. that terminology is politically incorrect and suggest a replacement.
Ticket #15. Ticket #15.
G.7.10. Further clarifications needed to source routes? G.7.10. Further clarifications needed to source routes?
The current text largely deprecates the use of source routes but The current text largely deprecates the use of source routes but
skipping to change at page 107, line 22 skipping to change at page 107, line 22
The FOR clause in time-stamp ("Received:") fields is seriously under- The FOR clause in time-stamp ("Received:") fields is seriously under-
defined. It is optional, the syntax is clear, but its semantics and defined. It is optional, the syntax is clear, but its semantics and
use, while perhaps obvious from content and the application of common use, while perhaps obvious from content and the application of common
sense, have never been defined ("never" going back to 821). Do we sense, have never been defined ("never" going back to 821). Do we
want to better define it? Is there any chance that a definition want to better define it? Is there any chance that a definition
would invalid existing, conforming and sensible, implementations? If would invalid existing, conforming and sensible, implementations? If
we do want to define semantics, draft text and advice as to where it we do want to define semantics, draft text and advice as to where it
should go are invited. should go are invited.
(Paragraph added 2021-08-18)
In particular, recentdiscussions point strongly to the need for a
statement to the effect that the value of the for clause must contain
one of the addresses that caused the message to be routed to the
recipient of this message copy (thanks Ned), that no mare than one
address can appear, and that showing one address when there are
multiple RCPT commands may be a security and/or privacy issue (thanks
Ned and Viktor and see <https://mailarchive.ietf.org/arch/msg/ietf-
smtp/hMkwHT-6bi_AwYIxbFJBX5pqjiA>). More detailed or specific
guidance, including case analysis, are probably material for the A/s,
but that is obviously up to the WG.
Note the existing discussions in Section 7.2 and Section 7.6 as they Note the existing discussions in Section 7.2 and Section 7.6 as they
may need adjustment, or at least cross-references, especially if FOR may need adjustment, or at least cross-references, especially if FOR
is more precisely defined. is more precisely defined.
There is probably an error in Section 7.6. Its last sentence implies There is probably an error in Section 7.6. Its last sentence implies
a possible interaction between messages with multiple recipients and a possible interaction between messages with multiple recipients and
the FOR clause of trace fields. However, because the syntax of the the FOR clause of trace fields. However, because the syntax of the
FOR clause only allows one Mailbox (or Path), it isn't clear if that FOR clause only allows one Mailbox (or Path), it isn't clear if that
statement is meaningful. Should it be revised to discuss other statement is meaningful. Should it be revised to discuss other
situations in which including FOR might not be desirable from a situations in which including FOR might not be desirable from a
security or privacy standpoint? security or privacy standpoint? (See above -- this paragraph
deliberately not changed in -04).
Ticket #55
G.15. Resistance to Attacks and Operational Necessity G.15. Resistance to Attacks and Operational Necessity
Section 7.8 is often cited as allowing an exception to the rules of Section 7.8 is often cited as allowing an exception to the rules of
the specification for reasons of operational necessity, not just the specification for reasons of operational necessity, not just
attack resistance. I (JcK) believe the broader interpretation was attack resistance. I (JcK) believe the broader interpretation was
intended by YAM (the section was new in RFC 5321). Recommendation: intended by YAM (the section was new in RFC 5321). Recommendation:
change the title to explicitly include "Local Operational change the title to explicitly include "Local Operational
Requirements" and add text to indicate that attack resistance is not Requirements" and add text to indicate that attack resistance is not
the only possible source of such requirements. the only possible source of such requirements.
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 . [[CREF17: [[Note in https://trac.ietf.org/trac/emailcore/report/1 . [[CREF22: [[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. [[CREF18: [5321bis]The IPv6 syntax 4315 ABNF - IPv6 Section 4.1.3. [[CREF23: [5321bis]The IPv6 syntax
has been adjusted since 5321 was published. See the rewritten has been adjusted since 5321 was published (the erratum mentions
form and the comment in the section cited in the previous RFC 5952, but RFC 6874 and draft-carpenter-6man-rfc6874bis should
sentence. The editor awaits instructions. See https://www.rfc- also be considered). See the rewritten form and the comment in
editor.org/errata/eid4315]] the section cited in the previous sentence, at least for the RFC
5952 issues. The editor awaits instructions. See
https://www.rfc-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. Text 1851 Location of text on unexpected close Section 4.1.1.5. Text
moved per email 2020-12-31. 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. [[CREF19: [5321bis]As confusion in some sections Section 4.4. [[CREF24: [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. [[CREF20: 5711 Missing leading spaces in example Appendix D.3. [[CREF25:
[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. ]]
As of 2021-03-15, both the txt and html-ized versions of draft- As of 2021-03-15, both the txt and html-ized versions of draft-
ietf-emailcore-rfc5321bis-02 were showing identical output for ietf-emailcore-rfc5321bis-02 were showing identical output for
both parts of the example, so the problem appears to be OBE at both parts of the example, so the problem appears to be OBE at
worst. worst.
Ticket #29 (closed 2021-03-16) Ticket #29 (closed 2021-03-16)
4055 Erratum claims the the description of SPF and DKIM is wrong. 4055 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).
Section 3.6.2. Text changed; ticket should probably be closed after WG reviews
-04.
Ticket #30. Ticket #30.
[[CREF21: [5321bis]Note that rejected errata have _not_ been reviewed [[CREF26: [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 110, line 19 skipping to change at page 110, line 36
o Clarified the relationship between the SMTP "letters, digits, and o Clarified the relationship between the SMTP "letters, digits, and
hyphens" and DNS "preferred name syntax" (Section 2.3.5). hyphens" and DNS "preferred name syntax" (Section 2.3.5).
o Revised the reply code sections to add new 521 and 556 codes, o Revised the reply code sections to add new 521 and 556 codes,
clarify relationships, and be explicit about the requirement for clarify relationships, and be explicit about the requirement for
clients to rely on first digits rather than the sequences in clients to rely on first digits rather than the sequences in
Section 4.3.2. Section 4.3.2.
o In conjunction with the above, explicitly obsolete RFCs 1846 and o In conjunction with the above, explicitly obsolete RFCs 1846 and
7504. 7504 (but that might not be right -- see email 2021-10-03.
o Incorporated a correction reflecting Errata ID 2578. o Incorporated a correction reflecting Errata ID 2578.
o Some small editorial changes made to eliminate redundant o Some small editorial changes made to eliminate redundant
statements that were very close together. Other, equally small, statements that were very close together. Other, equally small,
editorial changes have been made to improve grammar or clarity. editorial changes have been made to improve grammar or clarity.
o A few questions, marked "[[5321bis Editor's Note:", or "[[Note in o A few questions, marked "[[5321bis Editor's Note:", or "[[Note in
Draft" have been added for the group to resolve. Other questions, Draft" have been added for the group to resolve. Other questions,
especially those in the errata summary, are simply included in especially those in the errata summary, are simply included in
skipping to change at page 114, line 13 skipping to change at page 114, line 22
(Ticket #5) (Ticket #5)
o Modified Appendix G.8 to add a note about the normative status of o Modified Appendix G.8 to add a note about the normative status of
RFC 3463 and moved that reference. RFC 3463 and moved that reference.
o Several clarifications to initiation and termination of mail o Several clarifications to initiation and termination of mail
transactions in Section 4.1.4. transactions in Section 4.1.4.
o Several additional minor editorial improvements. o Several additional minor editorial improvements.
o Note for this particular draft only: Notes were posted to the list o Note for drafts -03 and -04 only: Notes were posted to the list on
on 2021-07-09 about tickets #7, #10, #14, #19, #20, $30, and #42. 2021-07-09 about tickets #7, #10, #14 (closed), #19, #20, $30, and
Even though some comments about them appeared in the subsequent #42. Even though some comments about them appeared in the
day or so, there appears to have been insufficient time for subsequent day or so, there appears to have been insufficient time
discussions to stabilize sufficiently for changes to be included for discussions to stabilize sufficiently for changes to be
in this version of the I-D. included in this version of the I-D.
H.3.8. Changes from draft-ietf-emailcore-rfc5321bis-03 (2021-07-10) to
-04
o Clarified that the "period" in <CRLF>.<CRLF> is really the ASCII
one in Section 3.3.
[[CREF27: Editor's note: change treated as Editorial without a
ticket. If there are objections, speak up.]]
o Several other small editorial corrections.
o Added several notes about the possible need to add text to reflect
the presence of MSAs and to clarify whether MUAs send messages
directly to MTAs or whether, in that case, the MUAs are just
incorporating MSA functions.
o Added new text to Appendix G.14 reflecting discussions of the
Received...FOR issue.
o Adjusted discussion of erratum 4315 (Ticket #27) to reflect more
recent IPv6 syntax developments.
o Adjusted discussion of the various "mail not accepted" codes,
rewrote Section 4.2.4.2, annotated and inserted cross-references
in relevant response code descriptions and (tentatively)
identified this document as obsoleting RFC 7505. Editor's guess,
reinforced by a brief conversation with John Levine (lead author
of 7505), is that we should incorporate text as needed and
obsolete it. The changes include replacing the reference to the
"nullMX" I-D with RFC 7505, which I am appalled that neither I nor
anyone else noticed earlier. Cf. Appendix G.7.1, Section 4.2.4.2,
and Ticket #6.
Index Index
A A
Argument Syntax Argument Syntax
A-d-l 43 A-d-l 43
Additional-Registered-Clauses 64 Additional-Registered-Clauses 64
address-literal 44 address-literal 43
Addtl-Link 64 Addtl-Link 64
Addtl-Protocol 64 Addtl-Protocol 64
ALPHA 43 ALPHA 42
Argument 43 Argument 43
At-domain 43 At-domain 43
atext 43 atext 43
Atom 44 Atom 44
By-domain 63 By-domain 63
CFWS 43 CFWS 43
CRLF 43 CRLF 42
dcontent 46 dcontent 45
DIGIT 43 DIGIT 42
Domain 43 Domain 43
Dot-string 44 Dot-string 44
esmtp-keyword 43 esmtp-keyword 43
esmtp-param 43 esmtp-param 43
esmtp-value 43 esmtp-value 43
Extended-Domain 63 Extended-Domain 63
For 63 For 64
Forward-Path 43 Forward-Path 43
From-domain 63 From-domain 63
FWS 43 FWS 43
General-address-literal 46 General-address-literal 45
Greeting 49 Greeting 49
h16 46 h16 46
HEXDIG 43 HEXDIG 42
ID 63 ID 64
IPv4-address-literal 45 IPv4-address-literal 45
IPv6-addr 46 IPv6-addr 46
IPv6-address-literal 46 IPv6-address-literal 45
Keyword 43 Keyword 43
Ldh-str 44 Ldh-str 43
Let-dig 44 Let-dig 43
Link 64 Link 64
Local-part 44 Local-part 44
ls32 46 ls32 46
Mail-parameters 43 Mail-parameters 43
Mailbox 44 Mailbox 43
Opt-info 63 Opt-info 63
Path 43 Path 43
Protocol 64 Protocol 64
QcontentSMTP 44 QcontentSMTP 44
qtextSMTP 44 qtextSMTP 44
quoted-pairSMTP 44 quoted-pairSMTP 44
Quoted-string 44 Quoted-string 44
Rcpt-parameters 43 Rcpt-parameters 43
Reply-code 49 Reply-code 49
Reply-line 49 Reply-line 49
Return-path-line 63 Return-path-line 63
Reverse-Path 43 Reverse-Path 43
Snum 46 Snum 46
SP 43 SP 42
Stamp 63 Stamp 63
Standardized-tag 46 Standardized-tag 45
String 44 String 44
sub-domain 43 sub-domain 43
TCP-info 63 TCP-info 63
textstring 49 textstring 49
Time-stamp-line 63 Time-stamp-line 63
Via 63 Via 63
With 63 With 63
C C
Command Syntax Command Syntax
data 40 data 40
ehlo 20, 35 ehlo 20, 35
expn 41 expn 41
helo 35 helo 35
help 41 help 41
mail 37 mail 37
noop 42 noop 41
quit 42 quit 42
rcpt 39 rcpt 38
rset 40 rset 40
send, saml, soml 104 send, saml, soml 104
vrfy 41 vrfy 40
Author's Address Author's Address
John C. Klensin John C. Klensin
1770 Massachusetts Ave, Suite 322 1770 Massachusetts Ave, Suite 322
Cambridge, MA 02140 Cambridge, MA 02140
USA USA
EMail: john-ietf@jck.com EMail: john-ietf@jck.com
 End of changes. 81 change blocks. 
137 lines changed or deleted 209 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/