< draft-ietf-emailcore-rfc5321bis-04.txt   draft-ietf-emailcore-rfc5321bis-05.txt >
EMAILCORE J. Klensin EMAILCORE J. Klensin
Internet-Draft October 3, 2021 Internet-Draft October 24, 2021
Obsoletes: 5321, 1846, 7504, 7505 (if Obsoletes: 5321, 1846, 7504, 7505 (if
approved) approved)
Intended status: Standards Track Intended status: Standards Track
Expires: April 6, 2022 Expires: April 27, 2022
Simple Mail Transfer Protocol Simple Mail Transfer Protocol
draft-ietf-emailcore-rfc5321bis-04 draft-ietf-emailcore-rfc5321bis-05
Abstract Abstract
This document is a specification of the basic protocol for Internet This document is a specification of the basic protocol for Internet
electronic mail transport. It consolidates, updates, and clarifies electronic mail transport. It consolidates, updates, and clarifies
several previous documents, making all or parts of most of them several previous documents, making all or parts of most of them
obsolete. It covers the SMTP extension mechanisms and best practices obsolete. It covers the SMTP extension mechanisms and best practices
for the contemporary Internet, but does not provide details about for the contemporary Internet, but does not provide details about
particular extensions. Although SMTP was designed as a mail particular extensions. Although SMTP was designed as a mail
transport and delivery protocol, this specification also contains transport and delivery protocol, this specification also contains
information that is important to its use as a "mail submission" information that is important to its use as a "mail submission"
protocol for "split-UA" (User Agent) mail reading systems and mobile protocol for "split-UA" (User Agent) mail reading systems and mobile
environments. This document replaces the earlier version with the environments. This document replaces RFC 5321, the earlier version
same title in RFC 5321. with the same title.
[[CREF1: Note in Draft: Except for the last sentence, the above is [[CREF1: Note in Draft: Except for the last sentence, the above is
unchanged from 5321 and may need adjusting in the light of RFC 6409 unchanged from 5321 and may need adjusting in the light of RFC 6409
(Message Submission) as an Internet Standard.]] (Message Submission) as an Internet Standard.]]
Notes on Reading This Working Draft Notes on Reading This Working Draft
This working draft is extensively annotated with information about This working draft is extensively annotated with information about
changes made over the decade since RFC 5321 appeared, especially when changes made over the decade since RFC 5321 appeared, especially when
those changes might be controversial or should get careful review. those changes might be controversial or should get careful review.
Anything marked in CREF comments with "[5321bis]" is current. In Anything marked in CREF comments with "[5321bis]" is current. In
general, unless those are marked with "[[Note in Draft", in the general, unless those are marked with "[[Note in Draft", in the
contents of an "Editor's note", or are in the "Errata Summary" contents of an "Editor's note", or are in the "Errata Summary"
appendix (Appendix H.1, they are just notes on changes that have appendix (Appendix H.1, they are just notes on changes that have
already been made and where those changes originated. As one can already been made and where those changes originated. As one can
tell from the dates (when they are given), this document has been tell from the dates (when they are given), this document has been
periodically updated over a very long period of time. periodically updated over a very long period of time.
As people review or try to use this document, it may be worth paying As people review or try to use this document, it may be worth paying
special attention to the historical discussion in Section 1.2. The special attention to the historical discussion in Section 1.2.
decision to merge documents rather than do a complete rewrite was
motivated by weighing the risks of inadvertently introducing changes
against greater readability and deciding to preserve close
approximations to original text and document structures in most
cases. One result is that information may not be be organized as the
reader might expect. An index is provided to assist in the quest for
information.
This evolving draft should be discussed on the emailcore@ietf.org 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 were listed. The source XML is marked up with "toc=include" commands were listed. The source XML is marked up with "toc=include"
attributes to facilitate that. Unfortunately, there is apparently a attributes to facilitate that. Unfortunately, there is apparently a
bug in the current version of xml2rfc v2, one that also appeared in bug in the current version of xml2rfc v2 (persisting into October
the version used ot generate RFC 5321, that prevents those 2021, one that also appeared in the version used to generate RFC
subsections from appearing in the TOC. The command names can now be 5321, that prevents those subsections from appearing in the TOC. The
found in the index, but the index is to page numbers, not section command names can now be found in the index, but the index is to page
numbers. Both problems have been reported. numbers, not section 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 April 6, 2022. This Internet-Draft will expire on April 27, 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 4, line 21 skipping to change at page 4, line 21
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 . . . . . . . . . . . 52 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 . . . 55 4.2.4. Some specific code situations and relationships . . . 55
4.3. Sequencing of Commands and Replies . . . . . . . . . . . 57 4.3. Sequencing of Commands and Replies . . . . . . . . . . . 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.4.1. Received Header Field . . . . . . . . . . . . . . . . 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
5. Address Resolution and Mail Handling . . . . . . . . . . . . 72 5. Address Resolution and Mail Handling . . . . . . . . . . . . 72
5.1. Locating the Target Host . . . . . . . . . . . . . . . . 72 5.1. Locating the Target Host . . . . . . . . . . . . . . . . 72
5.2. IPv6 and MX Records . . . . . . . . . . . . . . . . . . . 75 5.2. IPv6 and MX Records . . . . . . . . . . . . . . . . . . . 75
6. Problem Detection and Handling . . . . . . . . . . . . . . . 75 6. Problem Detection and Handling . . . . . . . . . . . . . . . 75
skipping to change at page 6, line 4 skipping to change at page 6, line 5
G.7.11. Should 1yz Be Revisited? . . . . . . . . . . . . . . 103 G.7.11. Should 1yz Be Revisited? . . . . . . . . . . . . . . 103
G.7.12. Review Timeout Specifications . . . . . . . . . . . . 103 G.7.12. Review Timeout Specifications . . . . . . . . . . . . 103
G.7.13. Possible SEND, SAML, SOML Loose End . . . . . . . . . 104 G.7.13. Possible SEND, SAML, SOML Loose End . . . . . . . . . 104
G.7.14. Abstract Update . . . . . . . . . . . . . . . . . . . 104 G.7.14. Abstract Update . . . . . . . . . . . . . . . . . . . 104
G.7.15. Informative References to MIME and/or Message G.7.15. Informative References to MIME and/or Message
Submission . . . . . . . . . . . . . . . . . . . . . 104 Submission . . . . . . . . . . . . . . . . . . . . . 104
G.7.16. Mail Transaction Discussion . . . . . . . . . . . . . 104 G.7.16. Mail Transaction Discussion . . . . . . . . . . . . . 104
G.7.17. Hop-by-hop Authentication and/or Encryption . . . . . 104 G.7.17. Hop-by-hop Authentication and/or Encryption . . . . . 104
G.7.18. More Text About 554 Given 521, etc. . . . . . . . . . 104 G.7.18. More Text About 554 Given 521, etc. . . . . . . . . . 104
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 . . . . . 108 G.15. Resistance to Attacks and Operational Necessity . . . . . 108
G.16. Mandatory 8BITMIME . . . . . . . . . . . . . . . . . . . 108
Appendix H. RFC 5321 Errata Summary and Tentative Change Log . . 108 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 . . . . . . . . . . . 110 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 . . . . . . . . . . . . . . . . . . . . . . . 112
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 . . . . . . . . . . . . . . . . . 113 (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
H.3.8. Changes from draft-ietf-emailcore-rfc5321bis-03 H.3.8. Changes from draft-ietf-emailcore-rfc5321bis-03
(2021-07-10) to -04 . . . . . . . . . . . . . . . . . 114 (2021-07-10) to -04 . . . . . . . . . . . . . . . . . 114
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 H.3.9. Changes from draft-ietf-emailcore-rfc5321bis-04
(2021-10-03) to -05 . . . . . . . . . . . . . . . . . 115
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 117 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
skipping to change at page 7, line 39 skipping to change at page 7, line 43
transport from RFC 1035 [4] and RFC 974 [16], transport from RFC 1035 [4] and RFC 974 [16],
o the clarifications and applicability statements in RFC 1123 [5], o the clarifications and applicability statements in RFC 1123 [5],
o the new error codes added by RFC 1846 [20] and later by RFC 7504 o the new error codes added by RFC 1846 [20] and later by RFC 7504
[48], obsoleting both of those documents, and [48], obsoleting both of those documents, and
o material drawn from the SMTP Extension mechanisms in RFC 1869 o material drawn from the SMTP Extension mechanisms in RFC 1869
[22]. [22].
o Editorial and clarification changes to RFC 2821 [30] to bring that It also includes editorial and clarification changes that were made
specification to Draft Standard. to RFC 2821 [30] to bring that specification to Draft Standard and
similar changes to RFC 5321 [50] to bring the current document to
It obsoletes RFC 821, RFC 974, RFC 1869, and RFC 2821 and updates RFC Internet Standard.
1123 (replacing the mail transport materials of RFC 1123). However,
RFC 821 specifies some features that were not in significant use in
the Internet by the mid-1990s and (in appendices) some additional
transport models. Those sections are omitted here in the interest of
clarity and brevity; readers needing them should refer to RFC 821.
It also includes some additional material from RFC 1123 that required It may help the reader to understand that, to reduce the risk of
amplification. This material has been identified in multiple ways, introducing errors, large parts of the document essentially merge the
mostly by tracking flaming on various lists and newsgroups and earlier specifications listed in the bullet points above rather than
problems of unusual readings or interpretations that have appeared as providing a completely rewritten, reorganized, and integrated
the SMTP extensions have been deployed. Where this specification description of SMTP. An index is provided to assist in the quest for
moves beyond consolidation and actually differs from earlier information.
documents, it supersedes them technically as well as textually.
It obsoletes RFCs 5321 [50] (the earlier version of this
specification), 1846 [20] and incorporates the substance of 7504
[48]7504 (specification of reply codes), and 7505 [49] (the "Null MX"
specification).
[[CREF2: JcK: 202107219: does the text that follows need rewriting? [[CREF2: JcK: 202107219: does the text that follows need rewriting?
See comment in Abstract. ]] 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
skipping to change at page 11, line 49 skipping to change at page 12, line 4
SMTP is widely deployed and high-quality implementations have proven SMTP is widely deployed and high-quality implementations have proven
to be very robust. However, the Internet community now considers to be very robust. However, the Internet community now considers
some services to be important that were not anticipated when the some services to be important that were not anticipated when the
protocol was first designed. If support for those services is to be protocol was first designed. If support for those services is to be
added, it must be done in a way that permits older implementations to added, it must be done in a way that permits older implementations to
continue working acceptably. The extension framework consists of: continue working acceptably. The extension framework consists of:
o The SMTP command EHLO, superseding the earlier HELO, o The SMTP command EHLO, superseding the earlier HELO,
o a registry of SMTP service extensions, o a registry of SMTP service extensions,
o additional parameters to the SMTP MAIL and RCPT commands, and o additional parameters to the SMTP MAIL and RCPT commands, and
o optional replacements for commands defined in this protocol, such o optional replacements for commands defined in this protocol, such
as for DATA in non-ASCII transmissions (RFC 3030 [33]). as for DATA in non-ASCII transmissions (RFC 3030 [33]).
SMTP's strength comes primarily from its simplicity. Experience with SMTP's strength comes primarily from its simplicity. Experience with
many protocols has shown that protocols with few options tend towards many protocols has shown that protocols with few options tend towards
ubiquity, whereas protocols with many options tend towards obscurity. ubiquity, whereas protocols with many options tend towards obscurity.
Each and every extension, regardless of its benefits, must be Each and every extension, regardless of its benefits, must be
carefully scrutinized with respect to its implementation, deployment, carefully scrutinized with respect to its implementation, deployment,
and interoperability costs. In many cases, the cost of extending the and interoperability costs. In many cases, the cost of extending the
SMTP service will likely outweigh the benefit. SMTP service will likely outweigh the benefit.
2.2.2. Definition and Registration of Extensions 2.2.2. Definition and Registration of Extensions
The IANA maintains a registry of SMTP service extensions [53]. A The IANA maintains a registry of SMTP service extensions [55]. A
corresponding EHLO keyword value is associated with each extension. corresponding EHLO keyword value is associated with each extension.
Each service extension registered with the IANA must be defined in a Each service extension registered with the IANA must be defined in a
formal Standards-Track or IESG-approved Experimental protocol formal Standards-Track or IESG-approved Experimental protocol
document. The definition must include: document. The definition must include:
o the textual name of the SMTP service extension; o the textual name of the SMTP service extension;
o the EHLO keyword value associated with the extension; o the EHLO keyword value associated with the extension;
o the syntax and possible values of parameters associated with the o the syntax and possible values of parameters associated with the
skipping to change at page 12, line 45 skipping to change at page 12, line 47
o any new parameters the extension associates with the MAIL or RCPT o any new parameters the extension associates with the MAIL or RCPT
verbs; verbs;
o a description of how support for the extension affects the o a description of how support for the extension affects the
behavior of a server and client SMTP; and behavior of a server and client SMTP; and
o the increment by which the extension is increasing the maximum o the increment by which the extension is increasing the maximum
length of the commands MAIL and/or RCPT, over that specified in length of the commands MAIL and/or RCPT, over that specified in
this Standard. this Standard.
In addition, any EHLO keyword value starting with an upper or lower Any keyword value presented in the EHLO response MUST correspond to a
case "X" refers to a local SMTP service extension used exclusively Standard, Standards-Track, or IESG-approved Experimental SMTP service
through bilateral agreement. Keywords beginning with "X" MUST NOT be extension registered with IANA. A conforming server MUST NOT offer
used in a registered service extension. Conversely, keyword values keyword values that are not described in a registered extension.
presented in the EHLO response that do not begin with "X" MUST
correspond to a Standard, Standards-Track, or IESG-approved
Experimental SMTP service extension registered with IANA. A
conforming server MUST NOT offer non-"X"-prefixed keyword values that
are not described in a registered extension.
Additional verbs and parameter names are bound by the same rules as Additional verbs and parameter names are bound by the same rules as
EHLO keywords; specifically, verbs beginning with "X" are local EHLO keywords; specifically, verbs beginning with "X" are local
extensions that may not be registered or standardized. Conversely, extensions that may not be registered or standardized. Conversely,
verbs not beginning with "X" must always be registered. verbs not beginning with "X" must always be registered.
2.2.3. Special Issues with Extensions 2.2.3. Special Issues with Extensions
Extensions that change fairly basic properties of SMTP operation are Extensions that change fairly basic properties of SMTP operation are
permitted. The text in other sections of this document must be permitted. The text in other sections of this document must be
skipping to change at page 17, line 21 skipping to change at page 17, line 21
This specification makes a distinction among four types of SMTP This specification makes a distinction among four types of SMTP
systems, based on the role those systems play in transmitting systems, based on the role those systems play in transmitting
electronic mail. An "originating" system (sometimes called an SMTP electronic mail. An "originating" system (sometimes called an SMTP
originator) introduces mail into the Internet or, more generally, originator) introduces mail into the Internet or, more generally,
into a transport service environment. A "delivery" SMTP system is into a transport service environment. A "delivery" SMTP system is
one that receives mail from a transport service environment and one that receives mail from a transport service environment and
passes it to a mail user agent or deposits it in a message store that passes it to a mail user agent or deposits it in a message store that
a mail user agent is expected to subsequently access. A "relay" SMTP a mail user agent is expected to subsequently access. A "relay" SMTP
system (usually referred to just as a "relay") receives mail from an system (usually referred to just as a "relay") receives mail from an
SMTP client and transmits it, without modification to the message SMTP client and transmits it, without modification to the message
data other than adding trace information, to another SMTP server for data other than adding trace information (see Section 4.4), to
further relaying or for delivery. another SMTP server for further relaying or for delivery.
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]).
skipping to change at page 30, line 21 skipping to change at page 30, line 21
to prevent loops in error reporting is to specify a null reverse-path to prevent loops in error reporting is to specify a null reverse-path
in the MAIL command of a notification message. When such a message in the MAIL command of a notification message. When such a message
is transmitted, the reverse-path MUST be set to null (see is transmitted, the reverse-path MUST be set to null (see
Section 4.5.5 for additional discussion). A MAIL command with a null Section 4.5.5 for additional discussion). A MAIL command with a null
reverse-path appears as follows: reverse-path appears as follows:
MAIL FROM:<> MAIL FROM:<>
As discussed in Section 6.4, a relay SMTP has no need to inspect or As discussed in Section 6.4, a relay SMTP has no need to inspect or
act upon the header section or body of the message data and MUST NOT act upon the header section or body of the message data and MUST NOT
do so except to add its own "Received:" header field (Section 4.4) do so except to add its own "Received:" header field (Section 4.4.1
and, optionally, to attempt to detect looping in the mail system (see and possibly other trace header fields) and, optionally, to attempt
Section 6.3). Of course, this prohibition also applies to any to detect looping in the mail system (see Section 6.3). Of course,
modifications of these header fields or text (see also Section 7.9). this prohibition also applies to any modifications of these header
fields or text (see also Section 7.9).
3.7. Mail Gatewaying 3.7. Mail Gatewaying
While the relay function discussed above operates within the Internet While the relay function discussed above operates within the Internet
SMTP transport service environment, MX records or various forms of SMTP transport service environment, MX records or various forms of
explicit routing may require that an intermediate SMTP server perform explicit routing may require that an intermediate SMTP server perform
a translation function between one transport service and another. As a translation function between one transport service and another. As
discussed in Section 2.3.10, when such a system is at the boundary discussed in Section 2.3.10, when such a system is at the boundary
between two transport service environments, we refer to it as a between two transport service environments, we refer to it as a
"gateway" or "gateway SMTP". "gateway" or "gateway SMTP".
skipping to change at page 47, line 13 skipping to change at page 47, line 13
replies that it was in before the EHLO was received. replies that it was in before the EHLO was received.
The SMTP client MUST, if possible, ensure that the domain parameter The SMTP client MUST, if possible, ensure that the domain parameter
to the EHLO command is a primary host name as specified for this to the EHLO command is a primary host name as specified for this
command in Section 2.3.5. If this is not possible (e.g., when the command in Section 2.3.5. If this is not possible (e.g., when the
client's address is dynamically assigned and the client does not have client's address is dynamically assigned and the client does not have
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 has an address record matching the IP address of the client.
[[CREF13: [5321bis] [[Note in draft -- proposed change to "An SMTP [[CREF13: JcK 20211022: Note that Alessandro's email of 2021-10-13
server MAY verify that the domain name argument in the EHLO command proposes adding "See [A/S] for further discussion." after that
has an address record matching the IP address of the client." ]] sentence. Can the WG please make a decision?]]
However, if the verification fails, the server MUST NOT refuse to [[CREF14: JcK 20211022: Additional question: should we be clear that
accept a message on that basis. Information captured in the this refers to a forward lookup of the domain name, not a reverse
verification attempt is for logging and tracing purposes. Note that lookup of the address? ]]
this prohibition applies to the matching of the parameter to its IP
address only; see Section 7.9 for a more extensive discussion of
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
skipping to change at page 53, line 4 skipping to change at page 52, line 49
4.2.2. Reply Codes by Function Groups 4.2.2. Reply Codes by Function Groups
500 Syntax error, command unrecognized (This may include errors such 500 Syntax error, command unrecognized (This may include errors such
as command line too long) as command line too long)
501 Syntax error in parameters or arguments 501 Syntax error in parameters or arguments
502 Command not implemented (see Section 4.2.4.1) 502 Command not implemented (see Section 4.2.4.1)
503 Bad sequence of commands 503 Bad sequence of commands
504 Command parameter not implemented
504 Command parameter not implemented
211 System status, or system help reply 211 System status, or system help reply
214 Help message (Information on how to use the receiver or the 214 Help message (Information on how to use the receiver or the
meaning of a particular non-standard command; this reply is useful meaning of a particular non-standard command; this reply is useful
only to the human user) only to the human user)
220 <domain> Service ready 220 <domain> Service ready
221 <domain> Service closing transmission channel 221 <domain> Service closing transmission channel
skipping to change at page 56, line 29 skipping to change at page 56, line 23
best way to accomplish that is to use the "Null MX" convention. This best way to accomplish that is to use the "Null MX" convention. This
is done by advertising a single MX RR (see Section 3.3.9 of (RFC 1035 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 [4]) with an RDATA section consisting of preference number 0 and a
zero-length label, written in master files as ".", as the exchange zero-length label, written in master files as ".", as the exchange
domain, to denote that there exists no mail exchanger for that domain, to denote that there exists no mail exchanger for that
domain. Reply code 556 is then used by a message submission or domain. Reply code 556 is then used by a message submission or
intermediate SMTP system (see Section 1.1) to report that it cannot intermediate SMTP system (see Section 1.1) to report that it cannot
forward the message further because it knows from the DNS entry that forward the message further because it knows from the DNS entry that
the recipient domain does not accept mail. If, despite publishing the recipient domain does not accept mail. If, despite publishing
the DNS entry, the server domain chooses to respond on the SMTP port, 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 it SHOULD respond with the 556 code as well. The details of the Null
MX convention were first defined in RFC 7505 [49]; see that document MX convention were first defined in RFC 7505 [49]; see that document
for additional discussion of the rationale for that convention. for additional discussion of the rationale for that convention.
Reply code 554 would normally be used in response to a RCPT command Reply code 554 would normally be used in response to a RCPT command
(or extension command with similar intent) when the SMTP system (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
skipping to change at page 60, line 39 skipping to change at page 60, line 34
NOOP NOOP
S: 250 S: 250
QUIT QUIT
S: 221 S: 221
4.4. Trace Information 4.4. Trace Information
Trace information is used to provide an audit trail of message
handling. In addition, it indicates a route back to the sender of
the message.
4.4.1. Received Header Field
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) at the beginning of the message content, or "Received" information) at the beginning of the message content,
as 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
skipping to change at page 82, line 8 skipping to change at page 82, line 8
actually secure an SMTP server rather than hope that trying to actually secure an SMTP server rather than hope that trying to
conceal known vulnerabilities by hiding the server's precise identity conceal known vulnerabilities by hiding the server's precise identity
will provide more protection. Sites are encouraged to evaluate the will provide more protection. Sites are encouraged to evaluate the
tradeoff with that issue in mind; implementations SHOULD minimally tradeoff with that issue in mind; implementations SHOULD minimally
provide for making type and version information available in some way provide for making type and version information available in some way
to other network hosts. to other network hosts.
7.6. Information Disclosure in Trace Fields 7.6. Information Disclosure in Trace Fields
In some circumstances, such as when mail originates from within a LAN In some circumstances, such as when mail originates from within a LAN
whose hosts are not directly on the public Internet, trace whose hosts are not directly on the public Internet, trace (e.g.,
("Received") header fields produced in conformance with this "Received") header fields produced in conformance with this
specification may disclose host names and similar information that specification may disclose host names and similar information that
would not normally be available. This ordinarily does not pose a would not normally be available. This ordinarily does not pose a
problem, but sites with special concerns about name disclosure should problem, but sites with special concerns about name disclosure should
be aware of it. Also, the optional FOR clause should be supplied be aware of it. Also, the optional FOR clause should be supplied
with caution or not at all when multiple recipients are involved lest with caution or not at all when multiple recipients are involved lest
it inadvertently disclose the identities of "blind copy" recipients it inadvertently disclose the identities of "blind copy" recipients
to others. to others.
7.7. Information Disclosure in Message Forwarding 7.7. Information Disclosure in Message Forwarding
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" [50], consists of SMTP service extensions with the Extensions" [52], 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" [51], consists of o The second registry, "Address Literal Tags" [53], 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" [50], established by RFC 821 o The third, "Mail Transmission Types" [52], 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 90, line 10 skipping to change at page 90, line 10
[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] Levine, J. and M. Delany, "A "Null MX" No Service Resource [49] Levine, J. and M. Delany, "A "Null MX" No Service Resource
Record for Domains That Accept No Mail", RFC 7505, Record for Domains That Accept No Mail", RFC 7505,
DOI 10.17487/RFC7505, June 2015, DOI 10.17487/RFC7505, June 2015,
<https://www.rfc-editor.org/info/rfc7505>. <https://www.rfc-editor.org/info/rfc7505>.
[50] Internet Assigned Number Authority (IANA), "IANA Mail [50] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
DOI 10.17487/RFC5321, October 2008,
<https://www.rfc-editor.org/info/rfc5321>.
[51] Klensin, J., Ed., Murchison, K., Ed., and E. Sam, Ed.,
"Applicability Statement for IETF Core Email Protocols",
August 2021, <https://datatracker.ietf.org/doc/draft-ietf-
emailcore-as/>.
[52] 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>.
[51] Internet Assigned Number Authority (IANA), "Address [53] 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>.
[52] RFC Editor, "RFC Errata - RFC 5321", 2019, [54] 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, [55] 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
reflect whatever you want for a registry that is updated reflect whatever you want for a registry that is updated
periodically. IANA: Please determine if the above URL is periodically. IANA: Please determine if the above URL is
a sufficiently stable reference and adjust as appropriate a sufficiently stable reference and adjust as appropriate
if it is not. if it is not.
Appendix A. TCP Transport Service Appendix A. TCP Transport Service
skipping to change at page 98, line 48 skipping to change at page 98, line 48
F.6. Sending versus Mailing F.6. Sending versus Mailing
In addition to specifying a mechanism for delivering messages to In addition to specifying a mechanism for delivering messages to
user's mailboxes, RFC 821 provided additional, optional, commands to user's mailboxes, RFC 821 provided additional, optional, commands to
deliver messages directly to the user's terminal screen. These deliver messages directly to the user's terminal screen. These
commands (SEND, SAML, SOML) were rarely implemented, and changes in commands (SEND, SAML, SOML) were rarely implemented, and changes in
workstation technology and the introduction of other protocols may workstation technology and the introduction of other protocols may
have rendered them obsolete even where they are implemented. have rendered them obsolete even where they are implemented.
[[5321bis Editor's Note: does this need a stronger reference to 821, Clients SHOULD NOT use SEND, SAML, or SOML commands. If a server
2821, and/or 5321? Also, is anything else needed given the removal implements them, the implementation model specified in RFC 821 [3]
of these commands and comments about, e.g., their opening mail MUST be used and the command names MUST be published in the response
transaction sessions, from the mail body of the text?]] to the EHLO command.
Clients SHOULD NOT provide SEND, SAML, or SOML as services. Servers
MAY implement them. If they are implemented by servers, the
implementation model specified in RFC 821 MUST be used and the
command names MUST be published in the response to the EHLO command.
Appendix G. Other Outstanding Issues Appendix G. Other Outstanding Issues
[[RFC Editor: Please remove this section before publication.]] [[RFC Editor: Please remove this section before publication.]]
In December 2019, an issue was raised on the ietf-smtp@ietf.org list In December 2019, an issue was raised on the ietf-smtp@ietf.org list
that led to a broad discussion of ways in which existing practice had that led to a broad discussion of ways in which existing practice had
diverged from the specifications and recommendations of RFC 5321 in diverged from the specifications and recommendations of RFC 5321 in
the more than eleven years since it was published (some of those the more than eleven years since it was published (some of those
issues probably affect the boundary between RFC 5321 and 5322 and issues probably affect the boundary between RFC 5321 and 5322 and
skipping to change at page 102, line 43 skipping to change at page 102, line 40
this area, they should be kept consistent with the description and this area, they should be kept consistent with the description and
discussion of the 251 and 551 in Section 4.2 and Section 3.5 as well discussion of the 251 and 551 in Section 4.2 and Section 3.5 as well
as Section 3.4 to avoid introducing inconsistencies. In addition, as Section 3.4 to avoid introducing inconsistencies. In addition,
there are some terminology issues about the use of the term "lists", there are some terminology issues about the use of the term "lists",
identified in erratum 1820, that should be reviewed after any more identified in erratum 1820, that should be reviewed after any more
substantive changes are made to the relevant sections. substantive changes are made to the relevant sections.
Ticket #12 and Ticket #34. Ticket #12 and Ticket #34.
G.7.6. Requirements for domain name and/or IP address in EHLO G.7.6. Requirements for domain name and/or IP address in EHLO
CREF comment in Section 4.1.4 Text in Section 4.1.4; change made in -05.
Ticket #19. Ticket #19.
G.7.7. Does the 'first digit only' and/or non-listed reply code text G.7.7. Does the 'first digit only' and/or non-listed reply code text
need clarification? need clarification?
Resolved. Text in Section 4.2 changed 2021-02-08 and CREF comment in Resolved. Text in Section 4.2 changed 2021-02-08 and CREF comment in
Section 4.3.1 removed. Section 4.3.1 removed.
Perhaps unresolved -- ongoing discussion on mailing list after IETF Perhaps unresolved -- ongoing discussion on mailing list after IETF
110. 110.
skipping to change at page 108, line 15 skipping to change at page 108, line 15
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.
G.16. Mandatory 8BITMIME
There was extensive discussion on the mailing list in October 2021
about messages with and without 8-bit (i.e., octets with the leading
on) content and a tentative conclusion that support for 8BITMIME
should be required. If that is the WG's conclusion, we need to
figure out what to say and where to say it.
Appendix H. RFC 5321 Errata Summary and Tentative Change Log Appendix H. RFC 5321 Errata Summary and Tentative Change Log
[[RFC Editor: Please remove this section before publication.]] [[RFC Editor: Please remove this section before publication.]]
H.1. RFC 5321 Errata Summary H.1. RFC 5321 Errata Summary
This document addresses the following errata filed against RFC 5321 This document addresses the following errata filed against RFC 5321
since its publication in October 2008 [52]. As with the previous since its publication in October 2008 [54]. As with the previous
appendix, ticket numbers included below reference appendix, ticket numbers included below reference
https://trac.ietf.org/trac/emailcore/report/1 . [[CREF22: [[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.
skipping to change at page 109, line 10 skipping to change at page 109, line 16
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. [[CREF24: [5321bis]As confusion in some sections Section 4.4.
Barry notes in his verifier comments on the erratum (see Ticket #7
https://www.rfc-editor.org/errata/eid3447), the comments and [[CREF24: [5321bis]As Barry notes in his verifier comments on the
suggestions here raise a number of interesting (and difficult) erratum (see https://www.rfc-editor.org/errata/eid3447), the
issues. One of the issues is that the core of RFCs 5321 (and comments and suggestions here raise a number of interesting (and
2821) is text carried over from Jon Postel's RFC 821, a document difficult) issues. One of the issues is that the core of RFCs
that was not only written in a different style than the IETF uses 5321 (and 2821) is text carried over from Jon Postel's RFC 821, a
today but that was written at a time when no one had dreamt of RFC document that was not only written in a different style than the
2119 or even the IETF itself. It appears to me that trying to IETF uses today but that was written at a time when no one had
patch that style might easily result in a document that is harder dreamt of RFC 2119 or even the IETF itself. It appears to me that
to read as well as being error prone. If we want to get the trying to patch that style might easily result in a document that
document entirely into contemporary style, we really should bite is harder to read as well as being error prone. If we want to get
the bullet and do a complete rewrite. To respond to a different the document entirely into contemporary style, we really should
point in Barry's discussion, I think an explicit statement that bite the bullet and do a complete rewrite. To respond to a
5321/5322 and their predecessors differ in places and why would be different point in Barry's discussion, I think an explicit
helpful. Text, and suggestions about where to put it, are statement that 5321/5322 and their predecessors differ in places
solicited. A list of differences might be a good idea too, but and why would be helpful. Text, and suggestions about where to
getting it right might be more work than there is available energy put it, are solicited. A list of differences might be a good idea
to do correctly. ]] too, but getting it right might be more work than there is
available energy to do correctly. ]]
5711 Missing leading spaces in example Appendix D.3. [[CREF25: 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
skipping to change at page 114, line 22 skipping to change at page 114, line 38
(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 drafts -03 and -04 only: Notes were posted to the list on o Note for drafts -03 and -04 only, modified somewhat for -05: Some
2021-07-09 about tickets #7, #10, #14 (closed), #19, #20, $30, and issues are still outstanding: Notes were posted to the list on
#42. Even though some comments about them appeared in the 2021-07-09 about tickets #7 (closed?), #10, #14 (closed), #20,
subsequent day or so, there appears to have been insufficient time #30, and #42. Even though some comments about them appeared in
for discussions to stabilize sufficiently for changes to be the subsequent day or so, there appears to have been insufficient
time for discussions to stabilize sufficiently for changes to be
included 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 H.3.8. Changes from draft-ietf-emailcore-rfc5321bis-03 (2021-07-10) to
-04 -04
o Clarified that the "period" in <CRLF>.<CRLF> is really the ASCII o Clarified that the "period" in <CRLF>.<CRLF> is really the ASCII
one in Section 3.3. one in Section 3.3.
[[CREF27: Editor's note: change treated as Editorial without a [[CREF27: Editor's note: change treated as Editorial without a
ticket. If there are objections, speak up.]] ticket. If there are objections, speak up.]]
skipping to change at page 115, line 12 skipping to change at page 115, line 29
rewrote Section 4.2.4.2, annotated and inserted cross-references rewrote Section 4.2.4.2, annotated and inserted cross-references
in relevant response code descriptions and (tentatively) in relevant response code descriptions and (tentatively)
identified this document as obsoleting RFC 7505. Editor's guess, identified this document as obsoleting RFC 7505. Editor's guess,
reinforced by a brief conversation with John Levine (lead author reinforced by a brief conversation with John Levine (lead author
of 7505), is that we should incorporate text as needed and of 7505), is that we should incorporate text as needed and
obsolete it. The changes include replacing the reference to the obsolete it. The changes include replacing the reference to the
"nullMX" I-D with RFC 7505, which I am appalled that neither I nor "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, anyone else noticed earlier. Cf. Appendix G.7.1, Section 4.2.4.2,
and Ticket #6. and Ticket #6.
H.3.9. Changes from draft-ietf-emailcore-rfc5321bis-04 (2021-10-03) to
-05
o Took a first step toward rewriting and updating the introductory
material. It is only a first step; suggestions welcome.
o Minor editorial fixes.
o Correct text about domain name checking in Section 4.1.4, probably
fixing ticket #19. See CREF added there.
o Added Appendix G.16 a placeholder for the 8BITMIME discussion and
possible action.
o Additional changes to the description and organization of trace
field materials. Intended to resolve the 5321bis part of Ticket
#7.
o Remaining patch to SEND, etc., discussion in Appendix F.6 applied
and CREF removed.
o Removed discussion of "X-" and edited associated text. The fix
may or may not be sufficient to resolve Ticket #42.
o Verified that the problems of getting four-level sections (e.g.,
"4.1.1.1" and other command-specific ones) into the table of
contents and the index reflecting page numbers still exist and
updated the introductory note.
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 43 address-literal 43
Addtl-Link 64 Addtl-Link 64
Addtl-Protocol 64 Addtl-Protocol 64
ALPHA 42 ALPHA 42
 End of changes. 42 change blocks. 
114 lines changed or deleted 148 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/