< draft-ietf-emailcore-rfc5321bis-05.txt   draft-ietf-emailcore-rfc5321bis-06.txt >
EMAILCORE J. Klensin EMAILCORE J. Klensin
Internet-Draft October 24, 2021 Internet-Draft 8 November 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 27, 2022 Expires: 12 May 2022
Simple Mail Transfer Protocol Simple Mail Transfer Protocol
draft-ietf-emailcore-rfc5321bis-05 draft-ietf-emailcore-rfc5321bis-06
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. The document also provides information about
transport and delivery protocol, this specification also contains use of SMTP for other than strict mail transport and delivery. This
information that is important to its use as a "mail submission" document replaces RFC 5321, the earlier version with the same title.
protocol for "split-UA" (User Agent) mail reading systems and mobile
environments. This document replaces RFC 5321, the earlier version // JcK 20211029 Note in Draft: Adjusted in version -06. Decided the
with the same title. // details belong in either the Introduction or the A/S, not the
[[CREF1: Note in Draft: Except for the last sentence, the above is // Abstract. And it makes the Abstract a tad shorter, which is good.
unchanged from 5321 and may need adjusting in the light of RFC 6409
(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. special attention to the historical discussion in Section 1.2.
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,
especially for locating commands, if the subsections containing the
commands were listed. The source XML is marked up with "toc=include"
attributes to facilitate that. Unfortunately, there is apparently a
bug in the current version of xml2rfc v2 (persisting into October
2021, one that also appeared in the version used to generate RFC
5321, that prevents those subsections from appearing in the TOC. The
command names can now be found in the index, but the index is to page
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 27, 2022. This Internet-Draft will expire on 12 May 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/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Revised BSD License text as
include Simplified BSD License text as described in Section 4.e of described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Revised BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7
1.1. Transport of Electronic Mail . . . . . . . . . . . . . . 6 1.1. Transport of Electronic Mail . . . . . . . . . . . . . . 7
1.2. History and Context for This Document . . . . . . . . . . 7 1.2. History and Context for This Document . . . . . . . . . . 7
1.3. Document Conventions . . . . . . . . . . . . . . . . . . 8 1.3. Document Conventions . . . . . . . . . . . . . . . . . . 9
2. The SMTP Model . . . . . . . . . . . . . . . . . . . . . . . 8 2. The SMTP Model . . . . . . . . . . . . . . . . . . . . . . . 9
2.1. Basic Structure . . . . . . . . . . . . . . . . . . . . . 9 2.1. Basic Structure . . . . . . . . . . . . . . . . . . . . . 9
2.2. The Extension Model . . . . . . . . . . . . . . . . . . . 11 2.2. The Extension Model . . . . . . . . . . . . . . . . . . . 11
2.2.1. Background . . . . . . . . . . . . . . . . . . . . . 11 2.2.1. Background . . . . . . . . . . . . . . . . . . . . . 12
2.2.2. Definition and Registration of Extensions . . . . . . 12 2.2.2. Definition and Registration of Extensions . . . . . . 13
2.2.3. Special Issues with Extensions . . . . . . . . . . . 13 2.2.3. Special Issues with Extensions . . . . . . . . . . . 13
2.3. SMTP Terminology . . . . . . . . . . . . . . . . . . . . 13 2.3. SMTP Terminology . . . . . . . . . . . . . . . . . . . . 14
2.3.1. Mail Objects . . . . . . . . . . . . . . . . . . . . 13 2.3.1. Mail Objects . . . . . . . . . . . . . . . . . . . . 14
2.3.2. Senders and Receivers . . . . . . . . . . . . . . . . 14 2.3.2. Senders and Receivers . . . . . . . . . . . . . . . . 14
2.3.3. Mail Agents and Message Stores . . . . . . . . . . . 14 2.3.3. Mail Agents and Message Stores . . . . . . . . . . . 15
2.3.4. Host . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3.4. Host . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.5. Domain Names . . . . . . . . . . . . . . . . . . . . 15 2.3.5. Domain Names . . . . . . . . . . . . . . . . . . . . 15
2.3.6. Buffer and State Table . . . . . . . . . . . . . . . 16 2.3.6. Buffer and State Table . . . . . . . . . . . . . . . 16
2.3.7. Commands and Replies . . . . . . . . . . . . . . . . 16 2.3.7. Commands and Replies . . . . . . . . . . . . . . . . 16
2.3.8. Lines . . . . . . . . . . . . . . . . . . . . . . . . 16 2.3.8. Lines . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.9. Message Content and Mail Data . . . . . . . . . . . . 16 2.3.9. Message Content and Mail Data . . . . . . . . . . . . 17
2.3.10. Originator, Delivery, Relay, and Gateway Systems . . 17 2.3.10. Originator, Delivery, Relay, and Gateway Systems . . 17
2.3.11. Mailbox and Address . . . . . . . . . . . . . . . . . 17 2.3.11. Mailbox and Address . . . . . . . . . . . . . . . . . 18
2.4. General Syntax Principles and Transaction Model . . . . . 18 2.4. General Syntax Principles and Transaction Model . . . . . 18
3. The SMTP Procedures: An Overview . . . . . . . . . . . . . . 19 3. The SMTP Procedures: An Overview . . . . . . . . . . . . . . 20
3.1. Session Initiation . . . . . . . . . . . . . . . . . . . 20 3.1. Session Initiation . . . . . . . . . . . . . . . . . . . 20
3.2. Client Initiation . . . . . . . . . . . . . . . . . . . . 20 3.2. Client Initiation . . . . . . . . . . . . . . . . . . . . 21
3.3. Mail Transactions . . . . . . . . . . . . . . . . . . . . 21 3.3. Mail Transactions . . . . . . . . . . . . . . . . . . . . 21
3.4. Forwarding for Address Correction or Updating . . . . . . 24 3.4. Forwarding for Address Correction or Updating . . . . . . 24
3.5. Commands for Debugging Addresses . . . . . . . . . . . . 24 3.5. Commands for Debugging Addresses . . . . . . . . . . . . 25
3.5.1. Overview . . . . . . . . . . . . . . . . . . . . . . 25 3.5.1. Overview . . . . . . . . . . . . . . . . . . . . . . 25
3.5.2. VRFY Normal Response . . . . . . . . . . . . . . . . 27 3.5.2. VRFY Normal Response . . . . . . . . . . . . . . . . 27
3.5.3. Meaning of VRFY or EXPN Success Response . . . . . . 27 3.5.3. Meaning of VRFY or EXPN Success Response . . . . . . 28
3.5.4. Semantics and Applications of EXPN . . . . . . . . . 28 3.5.4. Semantics and Applications of EXPN . . . . . . . . . 28
3.6. Relaying and Mail Routing . . . . . . . . . . . . . . . . 28 3.6. Relaying and Mail Routing . . . . . . . . . . . . . . . . 29
3.6.1. Source Routes and Relaying . . . . . . . . . . . . . 28 3.6.1. Source Routes and Relaying . . . . . . . . . . . . . 29
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 . . . . . . . . 30
3.7. Mail Gatewaying . . . . . . . . . . . . . . . . . . . . . 30 3.7. Mail Gatewaying . . . . . . . . . . . . . . . . . . . . . 31
3.7.1. Header Fields in Gatewaying . . . . . . . . . . . . . 30 3.7.1. Header Fields in Gatewaying . . . . . . . . . . . . . 31
3.7.2. Received Lines in Gatewaying . . . . . . . . . . . . 31 3.7.2. Received Lines in Gatewaying . . . . . . . . . . . . 31
3.7.3. Addresses in Gatewaying . . . . . . . . . . . . . . . 31 3.7.3. Addresses in Gatewaying . . . . . . . . . . . . . . . 32
3.7.4. Other Header Fields in Gatewaying . . . . . . . . . . 31 3.7.4. Other Header Fields in Gatewaying . . . . . . . . . . 32
3.7.5. Envelopes in Gatewaying . . . . . . . . . . . . . . . 32 3.7.5. Envelopes in Gatewaying . . . . . . . . . . . . . . . 32
3.8. Terminating Sessions and Connections . . . . . . . . . . 32 3.8. Terminating Sessions and Connections . . . . . . . . . . 33
3.9. Mailing Lists and Aliases . . . . . . . . . . . . . . . . 33 3.9. Aliases and Mailing Lists . . . . . . . . . . . . . . . . 34
3.9.1. Alias . . . . . . . . . . . . . . . . . . . . . . . . 33 3.9.1. Simple Aliases . . . . . . . . . . . . . . . . . . . 34
3.9.2. List . . . . . . . . . . . . . . . . . . . . . . . . 34 3.9.2. Mailing Lists . . . . . . . . . . . . . . . . . . . . 34
4. The SMTP Specifications . . . . . . . . . . . . . . . . . . . 34 4. The SMTP Specifications . . . . . . . . . . . . . . . . . . . 35
4.1. SMTP Commands . . . . . . . . . . . . . . . . . . . . . . 34 4.1. SMTP Commands . . . . . . . . . . . . . . . . . . . . . . 35
4.1.1. Command Semantics and Syntax . . . . . . . . . . . . 34 4.1.1. Command Semantics and Syntax . . . . . . . . . . . . 35
4.1.2. Command Argument Syntax . . . . . . . . . . . . . . . 42 4.1.1.1. Extended HELLO (EHLO) or HELLO (HELO) . . . . . . 36
4.1.1.2. MAIL (MAIL) . . . . . . . . . . . . . . . . . . . 37
4.1.1.3. RECIPIENT (RCPT) . . . . . . . . . . . . . . . . 38
4.1.1.4. DATA (DATA) . . . . . . . . . . . . . . . . . . . 39
4.1.1.5. RESET (RSET) . . . . . . . . . . . . . . . . . . 41
4.1.1.6. VERIFY (VRFY) . . . . . . . . . . . . . . . . . . 41
4.1.1.7. EXPAND (EXPN) . . . . . . . . . . . . . . . . . . 41
4.1.1.8. HELP (HELP) . . . . . . . . . . . . . . . . . . . 42
4.1.1.9. NOOP (NOOP) . . . . . . . . . . . . . . . . . . . 42
4.1.1.10. QUIT (QUIT) . . . . . . . . . . . . . . . . . . . 42
4.1.2. Command Argument Syntax . . . . . . . . . . . . . . . 43
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 . . . . . . . . . . . . . . . . . . 47
4.1.5. Private-Use Commands . . . . . . . . . . . . . . . . 48 4.2. SMTP Replies . . . . . . . . . . . . . . . . . . . . . . 49
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 . . . . . . . . . . . 53
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 . . . 56
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 . . . . . . . . . . . . . . . . . 58
4.3.2. Command-Reply Sequences . . . . . . . . . . . . . . . 58 4.3.2. Command-Reply Sequences . . . . . . . . . . . . . . . 58
4.4. Trace Information . . . . . . . . . . . . . . . . . . . . 60 4.4. Trace Information . . . . . . . . . . . . . . . . . . . . 61
4.4.1. Received Header Field . . . . . . . . . . . . . . . . 60 4.4.1. Received Header Field . . . . . . . . . . . . . . . . 61
4.5. Additional Implementation Issues . . . . . . . . . . . . 64 4.5. Additional Implementation Issues . . . . . . . . . . . . 65
4.5.1. Minimum Implementation . . . . . . . . . . . . . . . 64 4.5.1. Minimum Implementation . . . . . . . . . . . . . . . 65
4.5.2. Transparency . . . . . . . . . . . . . . . . . . . . 65 4.5.2. Transparency . . . . . . . . . . . . . . . . . . . . 66
4.5.3. Sizes and Timeouts . . . . . . . . . . . . . . . . . 66 4.5.3. Sizes and Timeouts . . . . . . . . . . . . . . . . . 66
4.5.3.1. Size Limits and Minimums . . . . . . . . . . . . 66
4.5.3.1.1. Local-part . . . . . . . . . . . . . . . . . 67
4.5.3.1.2. Domain . . . . . . . . . . . . . . . . . . . 67
4.5.3.1.3. Path . . . . . . . . . . . . . . . . . . . . 67
4.5.3.1.4. Command Line . . . . . . . . . . . . . . . . 67
4.5.3.1.5. Reply Line . . . . . . . . . . . . . . . . . 67
4.5.3.1.6. Text Line . . . . . . . . . . . . . . . . . . 67
4.5.3.1.7. Message Content . . . . . . . . . . . . . . . 68
4.5.3.1.8. Recipient Buffer . . . . . . . . . . . . . . 68
4.5.3.1.9. Treatment When Limits Exceeded . . . . . . . 68
4.5.3.1.10. Too Many Recipients Code . . . . . . . . . . 69
4.5.3.2. Timeouts . . . . . . . . . . . . . . . . . . . . 69
4.5.3.2.1. Initial 220 Message: 5 Minutes . . . . . . . 70
4.5.3.2.2. MAIL Command: 5 Minutes . . . . . . . . . . . 70
4.5.3.2.3. RCPT Command: 5 Minutes . . . . . . . . . . . 70
4.5.3.2.4. DATA Initiation: 2 Minutes . . . . . . . . . 70
4.5.3.2.5. Data Block: 3 Minutes . . . . . . . . . . . . 70
4.5.3.2.6. DATA Termination: 10 Minutes. . . . . . . . . 70
4.5.3.2.7. Server Timeout: 5 Minutes. . . . . . . . . . 70
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 . . . . . . . . . . 73
5. Address Resolution and Mail Handling . . . . . . . . . . . . 72 5. Address Resolution and Mail Handling . . . . . . . . . . . . 73
5.1. Locating the Target Host . . . . . . . . . . . . . . . . 72 5.1. Locating the Target Host . . . . . . . . . . . . . . . . 73
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 . . . . . . . . . . . . . . . 76
6.1. Reliable Delivery and Replies by Email . . . . . . . . . 75 6.1. Reliable Delivery and Replies by Email . . . . . . . . . 76
6.2. Unwanted, Unsolicited, and "Attack" Messages . . . . . . 76 6.2. Unwanted, Unsolicited, and "Attack" Messages . . . . . . 77
6.3. Loop Detection . . . . . . . . . . . . . . . . . . . . . 77 6.3. Loop Detection . . . . . . . . . . . . . . . . . . . . . 78
6.4. Compensating for Irregularities . . . . . . . . . . . . . 77 6.4. Compensating for Irregularities . . . . . . . . . . . . . 78
7. Security Considerations . . . . . . . . . . . . . . . . . . . 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 80
7.1. Mail Security and Spoofing . . . . . . . . . . . . . . . 79 7.1. Mail Security and Spoofing . . . . . . . . . . . . . . . 80
7.2. "Blind" Copies . . . . . . . . . . . . . . . . . . . . . 80 7.2. "Blind" Copies . . . . . . . . . . . . . . . . . . . . . 81
7.3. VRFY, EXPN, and Security . . . . . . . . . . . . . . . . 80 7.3. VRFY, EXPN, and Security . . . . . . . . . . . . . . . . 81
7.4. Mail Rerouting Based on the 251 and 551 Response 7.4. Mail Rerouting Based on the 251 and 551 Response Codes . 82
Codes . . . . . . . . . . . . . . . . . . . . . . . . . . 81 7.5. Information Disclosure in Announcements . . . . . . . . . 82
7.5. Information Disclosure in Announcements . . . . . . . . . 81 7.6. Information Disclosure in Trace Fields . . . . . . . . . 83
7.6. Information Disclosure in Trace Fields . . . . . . . . . 82 7.7. Information Disclosure in Message Forwarding . . . . . . 83
7.7. Information Disclosure in Message Forwarding . . . . . . 82 7.8. Local Operational Requirement and Resistance to
7.8. Local Operational Requirement and Resistance to Attacks . 82 Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 83
7.9. Scope of Operation of SMTP Servers . . . . . . . . . . . 82
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 83
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 84
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 85
10.1. Normative References . . . . . . . . . . . . . . . . . . 85
10.2. Informative References . . . . . . . . . . . . . . . . . 86
7.9. Scope of Operation of SMTP Servers . . . . . . . . . . . 83
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 84
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 85
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 86
10.1. Normative References . . . . . . . . . . . . . . . . . . 86
10.2. Informative References . . . . . . . . . . . . . . . . . 87
Appendix A. TCP Transport Service . . . . . . . . . . . . . . . 91 Appendix A. TCP Transport Service . . . . . . . . . . . . . . . 91
Appendix B. Generating SMTP Commands from RFC 822 Header Fields 91 Appendix B. Generating SMTP Commands from RFC 822 Header
Appendix C. Source Routes . . . . . . . . . . . . . . . . . . . 92 Fields . . . . . . . . . . . . . . . . . . . . . . . . . 91
Appendix D. Scenarios . . . . . . . . . . . . . . . . . . . . . 93 Appendix C. Source Routes . . . . . . . . . . . . . . . . . . . 93
D.1. A Typical SMTP Transaction Scenario . . . . . . . . . . . 93 Appendix D. Scenarios . . . . . . . . . . . . . . . . . . . . . 94
D.2. Aborted SMTP Transaction Scenario . . . . . . . . . . . . 94 D.1. A Typical SMTP Transaction Scenario . . . . . . . . . . . 94
D.2. Aborted SMTP Transaction Scenario . . . . . . . . . . . . 95
D.3. Relayed Mail Scenario . . . . . . . . . . . . . . . . . . 95 D.3. Relayed Mail Scenario . . . . . . . . . . . . . . . . . . 95
D.4. Verifying and Sending Scenario . . . . . . . . . . . . . 96 D.4. Verifying and Sending Scenario . . . . . . . . . . . . . 97
Appendix E. Other Gateway Issues . . . . . . . . . . . . . . . . 97 Appendix E. Other Gateway Issues . . . . . . . . . . . . . . . . 98
Appendix F. Deprecated Features of RFC 821 . . . . . . . . . . . 97 Appendix F. Deprecated Features of RFC 821 . . . . . . . . . . . 98
F.1. TURN . . . . . . . . . . . . . . . . . . . . . . . . . . 97 F.1. TURN . . . . . . . . . . . . . . . . . . . . . . . . . . 99
F.2. Source Routing . . . . . . . . . . . . . . . . . . . . . 97 F.2. Source Routing . . . . . . . . . . . . . . . . . . . . . 99
F.3. HELO . . . . . . . . . . . . . . . . . . . . . . . . . . 98 F.3. HELO . . . . . . . . . . . . . . . . . . . . . . . . . . 99
F.4. #-literals . . . . . . . . . . . . . . . . . . . . . . . 98 F.4. #-literals . . . . . . . . . . . . . . . . . . . . . . . 99
F.5. Dates and Years . . . . . . . . . . . . . . . . . . . . . 98 F.5. Dates and Years . . . . . . . . . . . . . . . . . . . . . 100
F.6. Sending versus Mailing . . . . . . . . . . . . . . . . . 98 F.6. Sending versus Mailing . . . . . . . . . . . . . . . . . 100
Appendix G. Other Outstanding Issues . . . . . . . . . . . . . . 99 Appendix G. Other Outstanding Issues . . . . . . . . . . . . . . 100
G.1. IP Address literals . . . . . . . . . . . . . . . . . . . 100 G.1. IP Address literals . . . . . . . . . . . . . . . . . . . 101
G.2. Repeated Use of EHLO . . . . . . . . . . . . . . . . . . 100 G.2. Repeated Use of EHLO . . . . . . . . . . . . . . . . . . 101
G.3. Meaning of "MTA" and Related Terminology . . . . . . . . 100 G.3. Meaning of "MTA" and Related Terminology . . . . . . . . 102
G.4. Originator, or Originating System, Authentication . . . . 101 G.4. Originator, or Originating System, Authentication . . . . 102
G.5. Remove or deprecate the work-around from code 552 to 452 101 G.5. Remove or deprecate the work-around from code 552 to
452 . . . . . . . . . . . . . . . . . . . . . . . . . . 102
G.6. Clarify where the protocol stands with respect to G.6. Clarify where the protocol stands with respect to
submission and TLS issues . . . . . . . . . . . . . . . . 101 submission and TLS issues . . . . . . . . . . . . . . . 102
G.7. Probably-substantive Discussion Topics Identified in G.7. Probably-substantive Discussion Topics Identified in Other
Other Ways . . . . . . . . . . . . . . . . . . . . . . . 101 Ways . . . . . . . . . . . . . . . . . . . . . . . . . . 103
G.7.1. Issues with 521, 554, and 556 codes . . . . . . . . . 101 G.7.1. Issues with 521, 554, and 556 codes . . . . . . . . . 103
G.7.2. SMTP Model, terminology, and relationship to RFC 5598 102 G.7.2. SMTP Model, terminology, and relationship to RFC
G.7.3. Resolvable FQDNs and private domain names . . . . . . 102 5598 . . . . . . . . . . . . . . . . . . . . . . . . 103
G.7.3. Resolvable FQDNs and private domain names . . . . . . 103
G.7.4. Possible clarification about mail transactions and G.7.4. Possible clarification about mail transactions and
transaction state . . . . . . . . . . . . . . . . . . 102 transaction state . . . . . . . . . . . . . . . . . . 103
G.7.5. Issues with mailing lists, aliases, and forwarding . 102 G.7.5. Issues with mailing lists, aliases, and forwarding . 104
G.7.6. Requirements for domain name and/or IP address in G.7.6. Requirements for domain name and/or IP address in
EHLO . . . . . . . . . . . . . . . . . . . . . . . . 102 EHLO . . . . . . . . . . . . . . . . . . . . . . . . 104
G.7.7. Does the 'first digit only' and/or non-listed reply G.7.7. Does the 'first digit only' and/or non-listed reply
code text need clarification? . . . . . . . . . . . . 102 code text need clarification? . . . . . . . . . . . . 104
G.7.8. Size limits . . . . . . . . . . . . . . . . . . . . . 103 G.7.8. Size limits . . . . . . . . . . . . . . . . . . . . . 104
G.7.9. Discussion of 'blind' copies and RCPT . . . . . . . . 103 G.7.9. Discussion of 'blind' copies and RCPT . . . . . . . . 104
G.7.10. Further clarifications needed to source routes? . . . 103 G.7.10. Further clarifications needed to source routes? . . . 105
G.7.11. Should 1yz Be Revisited? . . . . . . . . . . . . . . 103 G.7.11. Should 1yz Be Revisited? . . . . . . . . . . . . . . 105
G.7.12. Review Timeout Specifications . . . . . . . . . . . . 103 G.7.12. Review Timeout Specifications . . . . . . . . . . . . 105
G.7.13. Possible SEND, SAML, SOML Loose End . . . . . . . . . 104 G.7.13. Possible SEND, SAML, SOML Loose End . . . . . . . . . 105
G.7.14. Abstract Update . . . . . . . . . . . . . . . . . . . 104 G.7.14. Abstract Update . . . . . . . . . . . . . . . . . . . 105
G.7.15. Informative References to MIME and/or Message G.7.15. Informative References to MIME and/or Message
Submission . . . . . . . . . . . . . . . . . . . . . 104 Submission . . . . . . . . . . . . . . . . . . . . . 105
G.7.16. Mail Transaction Discussion . . . . . . . . . . . . . 104 G.7.16. Mail Transaction Discussion . . . . . . . . . . . . . 106
G.7.17. Hop-by-hop Authentication and/or Encryption . . . . . 104 G.7.17. Hop by hop Authentication and/or Encryption . . . . . 106
G.7.18. More Text About 554 Given 521, etc. . . . . . . . . . 104 G.7.18. More Text About 554 Given 521, etc. . . . . . . . . . 106
G.7.19. Minimum Lengths and Quantities . . . . . . . . . . . 104 G.7.19. Minimum Lengths and Quantities . . . . . . . . . . . 106
G.8. Enhanced Reply Codes and DSNs . . . . . . . . . . . . . . 104 G.8. Enhanced Reply Codes and DSNs . . . . . . . . . . . . . . 106
G.9. Revisiting Quoted Strings . . . . . . . . . . . . . . . . 105 G.9. Revisiting Quoted Strings . . . . . . . . . . . . . . . . 107
G.10. Internationalization . . . . . . . . . . . . . . . . . . 105 G.10. Internationalization . . . . . . . . . . . . . . . . . . 107
G.11. SMTP Clients, Servers, Senders, and Receivers . . . . . . 106 G.11. SMTP Clients, Servers, Senders, and Receivers . . . . . . 108
G.12. Extension Keywords Starting in 'X-' . . . . . . . . . . . 106 G.12. Extension Keywords Starting in 'X-' . . . . . . . . . . . 108
G.13. Deprecating HELO . . . . . . . . . . . . . . . . . . . . 106 G.13. Deprecating HELO . . . . . . . . . . . . . . . . . . . . 108
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 . . . . . . . . . . . . 109
G.15. Resistance to Attacks and Operational Necessity . . . . . 108 G.15. Resistance to Attacks and Operational Necessity . . . . . 109
G.16. Mandatory 8BITMIME . . . . . . . . . . . . . . . . . . . 108 G.16. Mandatory 8BITMIME . . . . . . . . . . . . . . . . . . . 110
Appendix H. RFC 5321 Errata Summary and Tentative Change Log . . 108 Appendix H. RFC 5321 Errata Summary and Tentative Change Log . . 110
H.1. RFC 5321 Errata Summary . . . . . . . . . . . . . . . . . 108 H.1. RFC 5321 Errata Summary . . . . . . . . . . . . . . . . . 110
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 . . . . . . . . . . . 112
H.3. Changes Among Versions of Rfc5321bis . . . . . . . . . . 111 H.3. Changes Among Versions of Rfc5321bis . . . . . . . . . . 113
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 . . . . . . . . . . . . . . . . . 113
H.3.2. Changes from draft-klensin-rfc5321bis-01 (20191203) H.3.2. Changes from draft-klensin-rfc5321bis-01 (20191203) to
to -02 . . . . . . . . . . . . . . . . . . . . . . . 111 -02 . . . . . . . . . . . . . . . . . . . . . . . . . 113
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 . . . . . . . . . . . . . . . . . . . . . . . 112 to -03 . . . . . . . . . . . . . . . . . . . . . . . 114
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 . . . . . . . . 114
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 . . . . . . . . . . . . . . . . . 114
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 . . . . . . . . . . . . . . . . . 115
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 . . . . . . . . . . . . . . . . . 115
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 . . . . . . . . . . . . . . . . . 116
H.3.9. Changes from draft-ietf-emailcore-rfc5321bis-04 H.3.9. Changes from draft-ietf-emailcore-rfc5321bis-04
(2021-10-03) to -05 . . . . . . . . . . . . . . . . . 115 (2021-10-03) to -05 . . . . . . . . . . . . . . . . . 117
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 H.3.10. Changes from draft-ietf-emailcore-rfc5321bis-05
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 117 (2021-10-24) to -06 . . . . . . . . . . . . . . . . . 118
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 120
1. Introduction 1. Introduction
1.1. Transport of Electronic Mail 1.1. Transport of Electronic Mail
The objective of the Simple Mail Transfer Protocol (SMTP) is to The objective of the Simple Mail Transfer Protocol (SMTP) is to
transfer mail reliably and efficiently. transfer mail reliably and efficiently.
SMTP is independent of the particular transmission subsystem and SMTP is independent of the particular transmission subsystem and
requires only a reliable ordered data stream channel. While this requires only a reliable ordered data stream channel. While this
skipping to change at page 7, line 29 skipping to change at page 7, line 41
identify the appropriate next-hop destination for a message being identify the appropriate next-hop destination for a message being
transported. transported.
1.2. History and Context for This Document 1.2. History and Context for This Document
This document is a specification of the basic protocol for the This document is a specification of the basic protocol for the
Internet electronic mail transport. It consolidates, updates and Internet electronic mail transport. It consolidates, updates and
clarifies, but does not add new or change existing functionality of clarifies, but does not add new or change existing functionality of
the following: the following:
o the original SMTP (Simple Mail Transfer Protocol) specification of * the original SMTP (Simple Mail Transfer Protocol) specification of
RFC 821 [3], RFC 821 [3],
o domain name system requirements and implications for mail * domain name system requirements and implications for mail
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], * the clarifications and applicability statements in RFC 1123 [5],
o the new error codes added by RFC 1846 [20] and later by RFC 7504 * 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 * material drawn from the SMTP Extension mechanisms in RFC 1869
[22]. [22].
It also includes editorial and clarification changes that were made It also includes editorial and clarification changes that were made
to RFC 2821 [30] to bring that specification to Draft Standard and to RFC 2821 [30] to bring that specification to Draft Standard and
similar changes to RFC 5321 [50] to bring the current document to similar changes to RFC 5321 [50] to bring the current document to
Internet Standard. Internet Standard.
It may help the reader to understand that, to reduce the risk of It may help the reader to understand that, to reduce the risk of
introducing errors, large parts of the document essentially merge the introducing errors, large parts of the document essentially merge the
earlier specifications listed in the bullet points above rather than earlier specifications listed in the bullet points above rather than
providing a completely rewritten, reorganized, and integrated providing a completely rewritten, reorganized, and integrated
description of SMTP. An index is provided to assist in the quest for description of SMTP. An index is provided to assist in the quest for
information. information.
It obsoletes RFCs 5321 [50] (the earlier version of this It obsoletes RFCs 5321 [50] (the earlier version of this
specification), 1846 [20] and incorporates the substance of 7504 specification), 1846 [20] and incorporates the substance of 7504
[48]7504 (specification of reply codes), and 7505 [49] (the "Null MX" [48]7504 (specification of reply codes), and 7505 [49] (the "Null MX"
specification). specification).
[[CREF2: JcK: 202107219: does the text that follows need rewriting?
See comment in Abstract.]] // 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.
[[CREF3: [rfc5321bis 20210317] Would this be an appropriate place to
mention RFC 2045 (MIME) and/or RFC 6409 (Message Submission)?]] // [rfc5321bis 20210317] Would this be an appropriate place to
// mention RFC 2045 (MIME) and/or RFC 6409 (Message Submission)?
// Suggestion (20211104): Other relevant documents and their
// relationships are discussed in a forthcoming Applicability
// Statement [51].
1.3. Document Conventions 1.3. Document Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1]. As each document are to be interpreted as described in RFC 2119 [1]. As each
of these terms was intentionally and carefully chosen to improve the of these terms was intentionally and carefully chosen to improve the
interoperability of email, each use of these terms is to be treated interoperability of email, each use of these terms is to be treated
as a conformance requirement. as a conformance requirement.
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
[[CREF4: [5321bis] [[Editor's Note: There have been extensive and // [5321bis] [[Editor's Note: There have been extensive and repeated
repeated discussions on the SMTP and IETF lists about whether this // discussions on the SMTP and IETF lists about whether this document
document should say something about hop-by-hop (MTA-to-MTA) SMTP // 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.]] Cf.
// Appendix G.7.17
2.1. Basic Structure 2.1. Basic Structure
The SMTP design can be pictured as: The SMTP design can be pictured as:
+----------+ +----------+ +----------+ +----------+
+------+ | | | | +------+ | | | |
| User |<-->| | SMTP | | | User |<-->| | SMTP | |
+------+ | Client- |Commands/Replies| Server- | +------+ | Client- |Commands/Replies| Server- |
+------+ | SMTP |<-------------->| SMTP | +------+ +------+ | SMTP |<-------------->| SMTP | +------+
skipping to change at page 11, line 49 skipping to change at page 12, line 30
Unless the different characteristics of HELO must be identified for Unless the different characteristics of HELO must be identified for
interoperability purposes, this document discusses only EHLO. interoperability purposes, this document discusses only EHLO.
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, * The SMTP command EHLO, superseding the earlier HELO,
o a registry of SMTP service extensions, * a registry of SMTP service extensions,
o additional parameters to the SMTP MAIL and RCPT commands, and
o optional replacements for commands defined in this protocol, such * additional parameters to the SMTP MAIL and RCPT commands, and
* 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 [55]. 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; * the textual name of the SMTP service extension;
o the EHLO keyword value associated with the extension; * the EHLO keyword value associated with the extension;
o the syntax and possible values of parameters associated with the * the syntax and possible values of parameters associated with the
EHLO keyword value; EHLO keyword value;
o any additional SMTP verbs associated with the extension * any additional SMTP verbs associated with the extension
(additional verbs will usually be, but are not required to be, the (additional verbs will usually be, but are not required to be, the
same as the EHLO keyword value); same as the EHLO keyword value);
o any new parameters the extension associates with the MAIL or RCPT * any new parameters the extension associates with the MAIL or RCPT
verbs; verbs;
o a description of how support for the extension affects the * 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 * 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.
Any keyword value presented in the EHLO response MUST correspond to a Any keyword value presented in the EHLO response MUST correspond to a
Standard, Standards-Track, or IESG-approved Experimental SMTP service Standard, Standards-Track, or IESG-approved Experimental SMTP service
extension registered with IANA. A conforming server MUST NOT offer extension registered with IANA. A conforming server MUST NOT offer
keyword values that are not described in a registered extension. keyword values that are not described in a registered extension.
Additional verbs and parameter names are bound by the same rules as
EHLO keywords; specifically, verbs beginning with "X" are local
extensions that may not be registered or standardized. Conversely,
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
understood in that context. In particular, extensions can change the understood in that context. In particular, extensions can change the
minimum limits specified in Section 4.5.3, can change the ASCII minimum limits specified in Section 4.5.3, can change the ASCII
character set requirement as mentioned above, or can introduce some character set requirement as mentioned above, or can introduce some
optional modes of message handling. optional modes of message handling.
In particular, if an extension implies that the delivery path In particular, if an extension implies that the delivery path
skipping to change at page 14, line 31 skipping to change at page 15, line 13
clarity. clarity.
2.3.3. Mail Agents and Message Stores 2.3.3. Mail Agents and Message Stores
Additional mail system terminology became common after RFC 821 was Additional mail system terminology became common after RFC 821 was
published and, where convenient, is used in this specification. In published and, where convenient, is used in this specification. In
particular, SMTP servers and clients provide a mail transport service particular, SMTP servers and clients provide a mail transport service
and therefore act as "Mail Transfer Agents" (MTAs). "Mail User and therefore act as "Mail Transfer Agents" (MTAs). "Mail User
Agents" (MUAs or UAs) are normally thought of as the sources and Agents" (MUAs or UAs) are normally thought of as the sources and
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 or, more commonly
("delivery") MTA would be thought of as handing the mail off to an in recent years, a specialized variation on an MTA called a
MUA (or at least transferring responsibility to it, e.g., by "Submission Server" (MSA) [42]. . At the other end of the process,
depositing the message in a "message store"). However, while these the final ("delivery") MTA would be thought of as handing the mail
terms are used with at least the appearance of great precision in off to an MUA (or at least transferring responsibility to it, e.g.,
other environments, the implied boundaries between MUAs and MTAs by depositing the message in a "message store"). However, while
these terms are used with at least the appearance of great precision
in 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 30 skipping to change at page 16, line 11
of a CNAME RR) or the label of Mail eXchanger records to be used to of a CNAME RR) or the label of Mail eXchanger records to be used to
deliver mail instead of representing a host name. See RFC 1035 [4] deliver mail instead of representing a host name. See RFC 1035 [4]
and Section 5 of this specification. and Section 5 of this specification.
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 particular, names that can be
be resolved to MX RRs or address (i.e., A or AAAA) RRs (as discussed resolved to MX RRs or address (i.e., A or AAAA) RRs (as discussed in
in Section 5) are permitted, as are CNAME RRs whose targets can be 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. Local nicknames or
[[CREF6: [[5321bis Editor's Note: it is not clear whether "In other unqualified names MUST NOT be used. There are two exceptions to the
words" really meant "for example" or it is was intended that the only rule requiring FQDNs:
labels permitted are those that own records in one of the above RR
types]]]]
Local nicknames or unqualified names MUST NOT be used. There are two
exceptions to the rule requiring FQDNs:
o The domain name given in the EHLO command MUST be either a primary * 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
Section 4.1.4. Section 4.1.4.
o The reserved mailbox name "postmaster" may be used in a RCPT * The reserved mailbox name "postmaster" may be used in a RCPT
command without domain qualification (see Section 4.1.1.3) and command without domain qualification (see Section 4.1.1.3) and
MUST be accepted if so used. MUST be accepted if so used.
2.3.6. Buffer and State Table 2.3.6. Buffer and State Table
SMTP sessions are stateful, with both parties carefully maintaining a SMTP sessions are stateful, with both parties carefully maintaining a
common view of the current state. In this document, we model this common view of the current state. In this document, we model this
state by a virtual "buffer" and a "state table" on the server that state by a virtual "buffer" and a "state table" on the server that
may be used by the client to, for example, "clear the buffer" or may be used by the client to, for example, "clear the buffer" or
"reset the state table", causing the information in the buffer to be "reset the state table", causing the information in the buffer to be
skipping to change at page 17, line 33 skipping to change at page 18, line 9
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]).
[[CREF7: [5321bis] [[Note in draft/Placeholder: There has been a // [5321bis] [[Note in draft/Placeholder: There has been a request to
request to expand this section, possibly into a more extensive model // expand this section, possibly into a more extensive model of
of Internet mail. Comments from others solicited. In particular, // 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
the distinction between the location in which mail is placed (the the distinction between the location in which mail is placed (the
mailbox) and a reference to it (the address) is important. An mailbox) and a reference to it (the address) is important. An
address normally consists of user and domain specifications. The address normally consists of user and domain specifications. The
skipping to change at page 20, line 27 skipping to change at page 21, line 7
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 521 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 521 [[CREF8: (or 554?]] response on connection opening SHOULD a 521
provide enough information in the reply text to facilitate debugging
of the sending system. See Section 4.2.4.2. // (or 554?)
response on connection opening SHOULD provide enough information in
the reply text to facilitate debugging 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 23, line 10
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). [[CREF9: [5321bis]: this section would extensions (see Section 2.2).
be improved by being more specific about where mail transactions // [5321bis]: this section would be improved by being more specific
begin and end and then talking about "transaction state" here, rather // about where mail transactions begin and end and then talking about
than specific prior commands. --JcK]] // "transaction state" here, rather 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
alternative specified in a service extension). alternative specified in a service extension).
DATA <CRLF> DATA <CRLF>
skipping to change at page 24, line 26 skipping to change at page 25, line 5
of the "final" address through the SMTP protocol as a side effect of of the "final" address through the SMTP protocol as a side effect of
the forwarding activity. This may be especially important when the the forwarding activity. This may be especially important when the
final address may not even be reachable by the sender. Consequently, final address may not even be reachable by the sender. Consequently,
the "forwarding" mechanisms described in Section 3.2 of RFC 821, and the "forwarding" mechanisms described in Section 3.2 of RFC 821, and
especially the 251 (corrected destination) and 551 reply codes from especially the 251 (corrected destination) and 551 reply codes from
RCPT must be evaluated carefully by implementers and, when they are RCPT must be evaluated carefully by implementers and, when they are
available, by those configuring systems (see also Section 7.4). available, by those configuring systems (see also Section 7.4).
In particular: In particular:
o Servers MAY forward messages when they are aware of an address * Servers MAY forward messages when they are aware of an address
change. When they do so, they MAY either provide address-updating change. When they do so, they MAY either provide address-updating
information with a 251 code, or may forward "silently" and return information with a 251 code, or may forward "silently" and return
a 250 code. However, if a 251 code is used, they MUST NOT assume a 250 code. However, if a 251 code is used, they MUST NOT assume
that the client will actually update address information or even that the client will actually update address information or even
return that information to the user. return that information to the user.
Alternately, Alternately,
o Servers MAY reject messages or return them as non-deliverable when * Servers MAY reject messages or return them as non-deliverable when
they cannot be delivered precisely as addressed. When they do so, they cannot be delivered precisely as addressed. When they do so,
they MAY either provide address-updating information with a 551 they MAY either provide address-updating information with a 551
code, or may reject the message as undeliverable with a 550 code code, or may reject the message as undeliverable with a 550 code
and no address-specific information. However, if a 551 code is and no address-specific information. However, if a 551 code is
used, they MUST NOT assume that the client will actually update used, they MUST NOT assume that the client will actually update
address information or even return that information to the user. address information or even return that information to the user.
SMTP server implementations that support the 251 and/or 551 reply SMTP server implementations that support the 251 and/or 551 reply
codes SHOULD provide configuration mechanisms so that sites that codes SHOULD provide configuration mechanisms so that sites that
conclude that they would undesirably disclose information can disable conclude that they would undesirably disclose information can disable
skipping to change at page 29, line 19 skipping to change at page 29, line 44
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.
[[CREF10: Text below reflects proposed replacement of the paragraph ( // Text below reflects proposed replacement of the paragraph ( edited
edited version of suggestion by D Crocker 2021-03-17 17:23 email). // version of suggestion by D Crocker 2021-03-17 17:23 email). Cf.
Cf. Ticket #30:]] // Ticket #30:
This specification does not deal with the verification of return This specification does not deal with the verification of return
paths. Server efforts to verify a return path and actions to be paths. Server efforts to verify a return path and actions to be
taken under various circumstances are outside the scope of this taken under various circumstances are outside the scope of this
specification.for use in delivery notifications. specification.
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 32, line 27 skipping to change at page 33, line 14
3.8. Terminating Sessions and Connections 3.8. Terminating Sessions and Connections
An SMTP connection is terminated when the client sends a QUIT An SMTP connection is terminated when the client sends a QUIT
command. The server responds with a positive reply code, after which command. The server responds with a positive reply code, after which
it closes the connection. it closes the connection.
An SMTP server MUST NOT intentionally close the connection under An SMTP server MUST NOT intentionally close the connection under
normal operational circumstances (see Section 7.8) except: normal operational circumstances (see Section 7.8) except:
o After receiving a QUIT command and responding with a 221 reply. * After receiving a QUIT command and responding with a 221 reply.
o After detecting the need to shut down the SMTP service and * After detecting the need to shut down the SMTP service and
returning a 421 reply code. This reply code can be issued after returning a 421 reply code. This reply code can be issued after
the server receives any command or, if necessary, asynchronously the server receives any command or, if necessary, asynchronously
from command receipt (on the assumption that the client will from command receipt (on the assumption that the client will
receive it after the next command is issued). receive it after the next command is issued).
o After a timeout, as specified in Section 4.5.3.2, occurs waiting * After a timeout, as specified in Section 4.5.3.2, occurs waiting
for the client to send a command or data. for the client to send a command or data.
In particular, a server that closes connections in response to In particular, a server that closes connections in response to
commands that are not understood is in violation of this commands that are not understood is in violation of this
specification. Servers are expected to be tolerant of unknown specification. Servers are expected to be tolerant of unknown
commands, issuing a 500 reply and awaiting further instructions from commands, issuing a 500 reply and awaiting further instructions from
the client. the client.
An SMTP server that is forcibly shut down via external means SHOULD An SMTP server that is forcibly shut down via external means SHOULD
attempt to send a line containing a 421 reply code to the SMTP client attempt to send a line containing a 421 reply code to the SMTP client
skipping to change at page 33, line 15 skipping to change at page 34, line 5
treat the mail transaction as if a 421 response had been received and treat the mail transaction as if a 421 response had been received and
act accordingly. act accordingly.
There are circumstances, contrary to the intent of this 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. Aliases and Mailing Lists
[[CREF11: [5321bis] If "alias and list models" are explained // [5321bis] If "alias and list models" are explained elsewhere,
elsewhere, cross reference". Also note that this section appears to // cross reference. Also note that this section appears to prohibit
prohibit an exploder from adding List-* headers. That needs to be // an exploder from adding List-* headers. That needs to be explicit
finessed.]] // or 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
section is unaffected. section is unaffected.
An important mail facility is a mechanism for multi-destination An important mail facility is a mechanism for multi-destination
skipping to change at page 33, line 42 skipping to change at page 34, line 32
"exploding") a pseudo-mailbox address into a list of destination "exploding") a pseudo-mailbox address into a list of destination
mailbox addresses. When a message is sent to such a pseudo-mailbox mailbox addresses. When a message is sent to such a pseudo-mailbox
(sometimes called an "exploder"), copies are forwarded or (sometimes called an "exploder"), copies are forwarded or
redistributed to each mailbox in the expanded list. Servers SHOULD redistributed to each mailbox in the expanded list. Servers SHOULD
simply utilize the addresses on the list; application of heuristics simply utilize the addresses on the list; application of heuristics
or other matching rules to eliminate some addresses, such as that of or other matching rules to eliminate some addresses, such as that of
the originator, is strongly discouraged. We classify such a pseudo- the originator, is strongly discouraged. We classify such a pseudo-
mailbox as an "alias" or a "list", depending upon the expansion mailbox as an "alias" or a "list", depending upon the expansion
rules. rules.
3.9.1. Alias 3.9.1. Simple Aliases
To expand an alias, the recipient mailer simply replaces the pseudo- To expand an alias, the recipient mailer simply replaces the pseudo-
mailbox address in the envelope with each of the expanded addresses mailbox address in the envelope with each of the expanded addresses
in turn; the rest of the envelope and the message body are left in turn; the rest of the envelope and the message body are left
unchanged. The message is then delivered or forwarded to each unchanged. The message is then delivered or forwarded to each
expanded address. expanded address.
3.9.2. List 3.9.2. Mailing Lists
A mailing list may be said to operate by "redistribution" rather than Processing of a mailing list may be said to operate by
by "forwarding". To expand a list, the recipient mailer replaces the "redistribution" rather than by "forwarding" (as in the simple alias
pseudo-mailbox address in the envelope with each of the expanded case in the subsection above). To expand a list, the recipient
addresses in turn. The return (backward-pointing) address in the mailer replaces the pseudo-mailbox address in the envelope with each
envelope is changed so that all error messages generated by the final of the expanded addresses in turn. The return (backward-pointing)
deliveries will be returned to a list administrator, not to the address in the envelope is changed so that all error messages
message originator, who generally has no control over the contents of generated by the final deliveries will be returned to a list
the list and will typically find error messages annoying. Note that administrator, not to the message originator, who generally has no
the key difference between handling aliases (Section 3.9.1) and control over the contents of the list and will typically find error
forwarding (this subsection) is the change to the backward-pointing messages annoying. Note that the key difference between handling
address in this case. When a list constrains its processing to the simple aliases Section 3.9.1 and redistribution (this subsection) is
very limited set of modifications and actions described here, it is the change to the backward-pointing address. When a system managing
attempting to emulate an MTA; such lists can be treated as a a list constrains its processing to the very limited set of
continuation in email transit. modifications and actions described here, it is acting as part of an
MTA; such list processing, like alias processing, can be treated as a
continuation of email transit.
There exist mailing lists that perform additional, sometimes Mailing list management systems do exist that perform additional,
extensive, modifications to a message and its envelope. Such mailing sometimes extensive, modifications to a message and its envelope.
lists need to be viewed as full MUAs, which accept a delivery and Such mailing lists need to be viewed as MUAs that accept a message
post a new message. delivery and then submit a new message for multiple recipients.
4. The SMTP Specifications 4. The SMTP Specifications
4.1. SMTP Commands 4.1. SMTP Commands
4.1.1. Command Semantics and Syntax 4.1.1. Command Semantics and Syntax
The SMTP commands define the mail transfer or the mail system The SMTP commands define the mail transfer or the mail system
function requested by the user. SMTP commands are character strings function requested by the user. SMTP commands are character strings
terminated by <CRLF>. The commands themselves are alphabetic terminated by <CRLF>. The commands themselves are alphabetic
skipping to change at page 36, line 4 skipping to change at page 36, line 43
client MUST issue HELO or EHLO before starting a mail transaction. client MUST issue HELO or EHLO before starting a mail transaction.
These commands, and a "250 OK" reply to one of them, confirm that These commands, and a "250 OK" reply to one of them, confirm that
both the SMTP client and the SMTP server are in the initial state, both the SMTP client and the SMTP server are in the initial state,
that is, there is no transaction in progress and all state tables and that is, there is no transaction in progress and all state tables and
buffers are cleared. buffers are cleared.
Syntax: Syntax:
ehlo = "EHLO" SP ( Domain / address-literal ) CRLF ehlo = "EHLO" SP ( Domain / address-literal ) CRLF
helo = "HELO" SP Domain CRLF helo = "HELO" SP Domain CRLF
Normally, the response to EHLO will be a multiline reply. Each line Normally, the response to EHLO will be a multiline reply. Each line
of the response contains a keyword and, optionally, one or more of the response contains a keyword and, optionally, one or more
parameters. Following the normal syntax for multiline replies, these parameters. Following the normal syntax for multiline replies, these
keywords follow the code (250) and a hyphen for all but the last keywords follow the code (250) and a hyphen for all but the last
line, and the code and a space for the last line. The syntax for a line, and the code and a space for the last line. The syntax for a
positive response, using the ABNF notation and terminal symbols of positive response, using the ABNF notation and terminal symbols of
RFC 5234 [11], is: RFC 5234 [11], is:
ehlo-ok-rsp = ( "250" SP Domain [ SP ehlo-greet ] CRLF ) ehlo-ok-rsp = ( "250" SP Domain [ SP ehlo-greet ] CRLF )
/ ( "250-" Domain [ SP ehlo-greet ] CRLF / ( "250-" Domain [ SP ehlo-greet ] CRLF
*( "250-" ehlo-line CRLF ) *( "250-" ehlo-line CRLF )
"250" SP ehlo-line CRLF ) "250" SP ehlo-line CRLF )
ehlo-greet = 1*(%d0-9 / %d11-12 / %d14-127) ehlo-greet = 1*(%d0-9 / %d11-12 / %d14-127)
; string of any characters other than CR or LF ; string of any characters other than CR or LF
ehlo-line = ehlo-keyword *( SP ehlo-param ) ehlo-line = ehlo-keyword *( SP ehlo-param )
ehlo-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") ehlo-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
; additional syntax of ehlo-params depends on ; additional syntax of ehlo-params depends on
; ehlo-keyword ; ehlo-keyword
ehlo-param = 1*(%d33-126) ehlo-param = 1*(%d33-126)
; any CHAR excluding <SP> and all ; any CHAR excluding <SP> and all
; control characters (US-ASCII 0-31 and 127 ; control characters (US-ASCII 0-31 and 127
; inclusive) ; inclusive)
Although EHLO keywords may be specified in upper, lower, or mixed Although EHLO keywords may be specified in upper, lower, or mixed
case, they MUST always be recognized and processed in a case- case, they MUST always be recognized and processed in a case-
insensitive manner. This is simply an extension of practices insensitive manner. This is simply an extension of practices
specified in RFC 821 and Section 2.4. specified in RFC 821 and Section 2.4.
The EHLO response MUST contain keywords (and associated parameters if The EHLO response MUST contain keywords (and associated parameters if
required) for all commands not listed as "required" in Section 4.5.1 required) for all commands not listed as "required" in Section 4.5.1.
excepting only private-use commands as described in Section 4.1.5.
Private-use commands MAY be listed.
4.1.1.2. MAIL (MAIL) 4.1.1.2. MAIL (MAIL)
This command is used to initiate a mail transaction in which the mail This command is used to initiate a mail transaction in which the mail
data is delivered to an SMTP server that may, in turn, deliver it to data is delivered to an SMTP server that may, in turn, deliver it to
one or more mailboxes or pass it on to another system (possibly using one or more mailboxes or pass it on to another system (possibly using
SMTP). The argument clause contains a reverse-path and may contain SMTP). The argument clause contains a reverse-path and may contain
optional parameters. In general, the MAIL command may be sent only optional parameters. In general, the MAIL command may be sent only
when no mail transaction is in progress, see Section 4.1.4. when no mail transaction is in progress, see Section 4.1.4.
skipping to change at page 37, line 21 skipping to change at page 38, line 10
This command clears the reverse-path buffer, the forward-path buffer, This command clears the reverse-path buffer, the forward-path buffer,
and the mail data buffer, and it inserts the reverse-path information and the mail data buffer, and it inserts the reverse-path information
from its argument clause into the reverse-path buffer. from its argument clause into the reverse-path buffer.
If service extensions were negotiated, the MAIL command may also If service extensions were negotiated, the MAIL command may also
carry parameters associated with a particular service extension. carry parameters associated with a particular service extension.
Syntax: Syntax:
mail = "MAIL FROM:" Reverse-path mail = "MAIL FROM:" Reverse-path
[SP Mail-parameters] CRLF [SP Mail-parameters] CRLF
4.1.1.3. RECIPIENT (RCPT) 4.1.1.3. RECIPIENT (RCPT)
This command is used to identify an individual recipient of the mail This command is used to identify an individual recipient of the mail
data; multiple recipients are specified by multiple uses of this data; multiple recipients are specified by multiple uses of this
command. The argument clause contains a forward-path and may contain command. The argument clause contains a forward-path and may contain
optional parameters. optional parameters.
The forward-path normally consists of the required destination The forward-path normally consists of the required destination
skipping to change at page 38, line 35 skipping to change at page 39, line 25
a 550 code (since this is a "policy reason"). a 550 code (since this is a "policy reason").
If service extensions were negotiated, the RCPT command may also If service extensions were negotiated, the RCPT command may also
carry parameters associated with a particular service extension carry parameters associated with a particular service extension
offered by the server. The client MUST NOT transmit parameters other offered by the server. The client MUST NOT transmit parameters other
than those associated with a service extension offered by the server than those associated with a service extension offered by the server
in its EHLO response. in its EHLO response.
Syntax: Syntax:
rcpt = "RCPT TO:" ( "<Postmaster@" Domain ">" / "<Postmaster>" / rcpt = "RCPT TO:" ( "<Postmaster@" Domain ">" / "<Postmaster>" /
Forward-path ) [SP Rcpt-parameters] CRLF Forward-path ) [SP Rcpt-parameters] CRLF
Note that, in a departure from the usual rules for Note that, in a departure from the usual rules for
local-parts, the "Postmaster" string shown above is local-parts, the "Postmaster" string shown above is
treated as case-insensitive. treated as case-insensitive.
4.1.1.4. DATA (DATA) 4.1.1.4. DATA (DATA)
The receiver normally sends a 354 response to DATA, and then treats The receiver normally sends a 354 response to DATA, and then treats
the lines (strings ending in <CRLF> sequences, as described in the lines (strings ending in <CRLF> sequences, as described in
skipping to change at page 42, line 50 skipping to change at page 43, line 34
specified in the parameter's defining RFC. specified in the parameter's defining RFC.
4.1.2. Command Argument Syntax 4.1.2. Command Argument Syntax
The syntax of the argument clauses of the above commands (using the The syntax of the argument clauses of the above commands (using the
syntax specified in RFC 5234 [11] where applicable) is given below. syntax specified in RFC 5234 [11] where applicable) is given below.
Some of the productions given below are used only in conjunction with Some of the productions given below are used only in conjunction with
source routes as described in Appendix C. Some terminals not defined source routes as described in Appendix C. Some terminals not defined
in this document, but are defined elsewhere, specifically: in this document, but are defined elsewhere, specifically:
In the "core" syntax in Appendix B of RFC 5234 [11]: ALPHA , CRLF * In the "core" syntax in Appendix B of RFC 5234 [11]: ALPHA , CRLF
, DIGIT , HEXDIG , and SP , DIGIT , HEXDIG , and SP
In the message format syntax in RFC 5322 [12]: atext , CFWS , and
* In the message format syntax in RFC 5322 [12]: atext , CFWS , and
FWS . FWS .
Reverse-path = Path / "<>" Reverse-path = Path / "<>"
Forward-path = Path Forward-path = Path
Path = "<" [ A-d-l ":" ] Mailbox ">" Path = "<" [ A-d-l ":" ] Mailbox ">"
A-d-l = At-domain *( "," At-domain ) A-d-l = At-domain *( "," At-domain )
; Note that this form, the so-called "source ; Note that this form, the so-called "source
skipping to change at page 45, line 26 skipping to change at page 46, line 10
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).
[[CREF12: [5321bis] Proposed erratum 4315 (2015-03-27) suggests yet
another modification to the IPv6 address literal syntax, based on // [5321bis] Proposed erratum 4315 (2015-03-27) suggests yet another
part on RFC 5952. We should consider whether those, or other, // modification to the IPv6 address literal syntax, based on part on
modifications are appropriate and/or whether, given both the issues // RFC 5952. We should consider whether those, or other,
of spam/malware and servers supporting multiple domains, it it time // modifications are appropriate and/or whether, given both the
to deprecate mailboxes containing address literals entirely (EHLO // issues of spam/malware and servers supporting multiple domains, it
fields may be a different issue). If we are going to allow IPv6 // it time to deprecate mailboxes containing address literals
address literals, it may be time to incorporate something by // entirely (EHLO fields may be a different issue). If we are going
reference rather than including specific syntax here (RFC 5952 is 14 // to allow IPv6 address literals, it may be time to incorporate
pages long and does not contain any ABNF).]] // something by reference rather than including specific syntax here
// (RFC 5952 is 14 pages long and does not contain any ABNF).
Specifically: Specifically:
IPv4-address-literal = Snum 3("." Snum) IPv4-address-literal = Snum 3("." Snum)
IPv6-address-literal = "IPv6:" IPv6-addr IPv6-address-literal = "IPv6:" IPv6-addr
General-address-literal = Standardized-tag ":" 1*dcontent General-address-literal = Standardized-tag ":" 1*dcontent
Standardized-tag = Ldh-str Standardized-tag = Ldh-str
skipping to change at page 47, line 14 skipping to change at page 47, line 47
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 has an address record matching the IP address of the client. command has an address record matching the IP address of the client.
[[CREF13: JcK 20211022: Note that Alessandro's email of 2021-10-13
proposes adding "See [A/S] for further discussion." after that // JcK 20211022: Note that Alessandro's email of 2021-10-13 proposes
sentence. Can the WG please make a decision?]] // adding "See [A/S] for further discussion." after that sentence.
[[CREF14: JcK 20211022: Additional question: should we be clear that // Noting that phrasing could get us in trouble if the A/S takes a
this refers to a forward lookup of the domain name, not a reverse // long time to complete, can the WG please make a decision?
lookup of the address? ]] // JcK 20211022: Additional question: should we be clear that this
// refers to a forward lookup of the domain name, not a reverse
// lookup of the address?
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 47, line 48 skipping to change at page 48, line 35
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. [[CREF15: [5321bis] See comment about changing this convoluted EHLO.
discussion to talk about 'mail transaction' above. --Jck (and see // [5321bis] See comment about changing this convoluted discussion to
Ticket #11 correspondence with Alexey 2021-07-06)]] // talk about 'mail transaction' above. --Jck (and see 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.
The last command in a session MUST be the QUIT command. The QUIT The last command in a session MUST be the QUIT command. The QUIT
command SHOULD be used by the client SMTP to request connection command SHOULD be used by the client SMTP to request connection
closure, even when no session opening command was sent and accepted. closure, even when no session opening command was sent and accepted.
4.1.5. Private-Use Commands
As specified in Section 2.2.2, commands starting in "X" may be used
by bilateral agreement between the client (sending) and server
(receiving) SMTP agents. An SMTP server that does not recognize such
a command is expected to reply with "500 Command not recognized". An
extended SMTP server MAY list the feature names associated with these
private commands in the response to the EHLO command.
Commands sent or accepted by SMTP systems that do not start with "X"
MUST conform to the requirements of Section 2.2.2.
4.2. SMTP Replies 4.2. SMTP Replies
Replies to SMTP commands serve to ensure the synchronization of Replies to SMTP commands serve to ensure the synchronization of
requests and actions in the process of mail transfer and to guarantee requests and actions in the process of mail transfer and to guarantee
that the SMTP client always knows the state of the SMTP server. that the SMTP client always knows the state of the SMTP server.
Every command MUST generate exactly one reply. Every command MUST generate exactly one reply.
The details of the command-reply sequence are described in The details of the command-reply sequence are described in
Section 4.3. Section 4.3.
skipping to change at page 54, line 11 skipping to change at page 54, line 28
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, historically in the case of a 554 Transaction failed (Or, historically in the case of a
connection-opening response, "No SMTP service here". 521 is now connection-opening response, "No SMTP service here". 521 is now
preferred for that function at connection-opening if the server preferred for that function at connection-opening if the server
never accepts mail.) never accepts mail.)
[[CREF16: [5321bis] [[Note in Draft: Revise above statement in the
light of new 521 code?? -- revised with rfc5321bis-04]] ]] // [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 56, line 36 skipping to change at page 57, line 5
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
related to SMTP processing. related to SMTP processing.
[[CREF17: [JcK 20210904]: do we want/need to discuss temporary server // [JcK 20210904]: do we want/need to discuss temporary server
outages? And is the discussion above sufficient to obsolete RFC 7505 // outages? And is the discussion above sufficient to obsolete RFC
or do we need either more text or some pretense to claim to update // 7505 or do we need either more text or some pretense to claim to
it.]] // 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 * delivering the message (if the recipient mailbox exists), or
o if attempts to deliver the message fail due to transient * 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
intervals as specified in Section 4.5.4. intervals as specified in Section 4.5.4.
o if attempts to deliver the message fail due to permanent * if attempts to deliver the message fail due to permanent
conditions, or if repeated attempts to deliver the message fail conditions, or if repeated attempts to deliver the message fail
due to transient conditions, returning appropriate notification to due to transient conditions, returning appropriate notification to
the sender of the original message (using the address in the SMTP the sender of the original message (using the address in the SMTP
MAIL command). MAIL command).
When an SMTP server returns a temporary error status (4yz) code after When an SMTP server returns a temporary error status (4yz) code after
the DATA command is completed with <CRLF>.<CRLF>, it MUST NOT make a the DATA command is completed with <CRLF>.<CRLF>, it MUST NOT make a
subsequent attempt to deliver that message. The SMTP client retains subsequent attempt to deliver that message. The SMTP client retains
responsibility for the delivery of that message and may either return responsibility for the delivery of that message and may either return
it to the user or requeue it for a subsequent attempt (see it to the user or requeue it for a subsequent attempt (see
skipping to change at page 59, line 20 skipping to change at page 59, line 40
not accepting arguments (DATA, RSET, QUIT) SHOULD return a 501 not accepting arguments (DATA, RSET, QUIT) SHOULD return a 501
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, 556 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
- S: 250
S: 250
E: 552, 451, 452, 550, 553, 503, 455, 555 E: 552, 451, 452, 550, 553, 503, 455, 555
RCPT RCPT
S: 250, 251 (but see Section 3.4 for discussion of 251 and 551) - S: 250, 251 (but see Section 3.4 for discussion of 251 and 551)
E: 550, 551, 552 (obsolete for "too many recipients; see E: 550, 551, 552 (obsolete for "too many recipients; see
Section 4.5.3.1.10, 553, 450, 451, 452, 503, 455, 555 Section 4.5.3.1.10, 553, 450, 451, 452, 503, 455, 555
DATA DATA
I: 354 -> data -> S: 250 - I: 354 -> data -> S: 250
E: 552, 554, 451, 452 o E: 552, 554, 451, 452
E: 450, 550 (rejections for policy reasons) o E: 450, 550 (rejections for policy reasons)
E: 503, 554 - E: 503, 554
RSET RSET
S: 250 - S: 250
VRFY VRFY
S: 250, 251, 252 - S: 250, 251, 252
E: 550, 551, 553, 502, 504 E: 550, 551, 553, 502, 504
EXPN EXPN
S: 250, 252 - S: 250, 252
E: 550, 500, 502, 504 E: 550, 500, 502, 504
HELP HELP
S: 211, 214 - S: 211, 214
E: 502, 504 E: 502, 504
NOOP NOOP
S: 250 - S: 250
QUIT QUIT
S: 221 - S: 221
4.4. Trace Information 4.4. Trace Information
Trace information is used to provide an audit trail of message Trace information is used to provide an audit trail of message
handling. In addition, it indicates a route back to the sender of handling. In addition, it indicates a route back to the sender of
the message. the message.
4.4.1. Received Header Field 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, * 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 * The ID clause MAY contain an "@" as suggested in RFC 822, but this
is not required. is not required.
o If the FOR clause appears, it MUST contain exactly one <path> * If the FOR clause appears, it MUST contain exactly one <path>
entry, even when multiple RCPT commands have been given. Multiple entry, even when multiple RCPT commands have been given. Multiple
<path>s raise some security issues and have been deprecated, see <path>s raise some security issues and have been deprecated, see
Section 7.2. Section 7.2.
An Internet mail program MUST NOT change or delete a Received: line An Internet mail program MUST NOT change or delete a Received: line
that was previously added to the message header section. SMTP that was previously added to the message header section. SMTP
servers MUST prepend Received lines to messages; they MUST NOT change servers MUST prepend Received lines to messages; they MUST NOT change
the order of existing lines or insert Received lines in any other the order of existing lines or insert Received lines in any other
location. location.
skipping to change at page 62, line 36 skipping to change at page 63, line 14
Historical note: Text in RFC 822 that appears to contraindicate the Historical note: Text in RFC 822 that appears to contraindicate the
use of the Return-path header field (or the envelope reverse-path use of the Return-path header field (or the envelope reverse-path
address from the MAIL command) if the destination for error messages address from the MAIL command) if the destination for error messages
is not applicable on the Internet. The reverse-path address (as is not applicable on the Internet. The reverse-path address (as
copied into the Return-path) MUST be used as the target of any mail copied into the Return-path) MUST be used as the target of any mail
containing delivery error messages. containing delivery error messages.
In particular: In particular:
o a gateway from SMTP -> elsewhere SHOULD insert a return-path * 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 * 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
information to the SMTP envelope or combine it with information information to the SMTP envelope or combine it with information
present in the envelope of the other transport system to construct present in the envelope of the other transport system to construct
the reverse-path argument to the MAIL command in the SMTP the reverse-path argument to the MAIL command in the SMTP
envelope. envelope.
The server must give special treatment to cases in which the The server must give special treatment to cases in which the
processing following the end of mail data indication is only processing following the end of mail data indication is only
partially successful. This could happen if, after accepting several partially successful. This could happen if, after accepting several
recipients and the mail data, the SMTP server finds that the mail recipients and the mail data, the SMTP server finds that the mail
data could be successfully delivered to some, but not all, of the data could be successfully delivered to some, but not all, of the
recipients. In such cases, the response to the DATA command MUST be recipients. In such cases, the response to the DATA command MUST be
an OK reply. However, the SMTP server MUST compose and send an an OK reply. However, the SMTP server MUST compose and send an
"undeliverable mail" notification message to the originator of the "undeliverable mail" notification message to the originator of the
message. message.
// [JcK/Alexey 20211104] The following paragraph does not seem to
// belong in this section. Where should it be moved?
A single notification listing all of the failed recipients or A single notification listing all of the failed recipients or
separate notification messages MUST be sent for each failed separate notification messages MUST be sent for each failed
recipient. For economy of processing by the sender, the former recipient. For economy of processing by the sender, the former
SHOULD be used when possible. Note that the key difference between SHOULD be used when possible. All notification messages about
handling aliases (Section 3.9.1) and forwarding (this subsection) is undeliverable mail MUST be sent using the MAIL command and MUST use a
the change to the backward-pointing address in this case. All null return path as discussed in Section 3.6.
notification messages about undeliverable mail MUST be sent using the
MAIL command and MUST use a null return path as discussed in
Section 3.6.
The time stamp line and the return path line are formally defined as The time stamp line and the return path line are formally defined as
follows (the definitions for "FWS" and "CFWS" appear in RFC 5322 follows (the definitions for "FWS" and "CFWS" appear in RFC 5322
[12]): [12]):
Return-path-line = "Return-Path:" FWS Reverse-path <CRLF> Return-path-line = "Return-Path:" FWS Reverse-path <CRLF>
Time-stamp-line = "Received:" FWS Stamp <CRLF> Time-stamp-line = "Received:" FWS Stamp <CRLF>
Stamp = From-domain By-domain Opt-info [CFWS] ";" Stamp = From-domain By-domain Opt-info [CFWS] ";"
FWS date-time FWS date-time
; where "date-time" is as defined in RFC 5322 [12] ; where "date-time" is as defined in RFC 5322 [12]
; but the "obs-" forms, especially two-digit ; but the "obs-" forms, especially two-digit
; years, are prohibited in SMTP and MUST NOT be used. ; years, are prohibited in SMTP and MUST NOT be used.
From-domain = "FROM" FWS Extended-Domain From-domain = "FROM" FWS Extended-Domain
By-domain = CFWS "BY" FWS Extended-Domain By-domain = CFWS "BY" FWS Extended-Domain
skipping to change at page 64, line 4 skipping to change at page 64, line 28
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, ]]
// [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
; Authority (IANA). "Via" is primarily of value ; Authority (IANA). "Via" is primarily of value
; with non-Internet transports. SMTP servers ; with non-Internet transports. SMTP servers
; SHOULD NOT use unregistered names. ; SHOULD NOT use unregistered names.
Protocol = "ESMTP" / "SMTP" / Attdl-Protocol Protocol = "ESMTP" / "SMTP" / Attdl-Protocol
Addtl-Protocol = Atom
Addtl-Protocol = Atom
; Additional standard names for protocols are ; Additional standard names for protocols are
; registered with the Internet Assigned Numbers ; registered with the Internet Assigned Numbers
; Authority (IANA) in the "mail parameters" ; Authority (IANA) in the "mail parameters"
; registry [8]. SMTP servers SHOULD NOT ; registry [8]. SMTP servers SHOULD NOT
; use unregistered names. ; use unregistered names.
4.5. Additional Implementation Issues 4.5. Additional Implementation Issues
4.5.1. Minimum Implementation 4.5.1. Minimum Implementation
skipping to change at page 65, line 30 skipping to change at page 66, line 13
so as to avoid blocking messages that are not part of such attacks. so as to avoid blocking messages that are not part of such attacks.
4.5.2. Transparency 4.5.2. Transparency
Without some provision for data transparency, the character sequence Without some provision for data transparency, the character sequence
"<CRLF>.<CRLF>" ends the mail text and cannot be sent by the user. "<CRLF>.<CRLF>" ends the mail text and cannot be sent by the user.
In general, users are not aware of such "forbidden" sequences. To In general, users are not aware of such "forbidden" sequences. To
allow all user composed text to be transmitted transparently, the allow all user composed text to be transmitted transparently, the
following procedures are used: following procedures are used:
o Before sending a line of mail text, the SMTP client checks the * Before sending a line of mail text, the SMTP client checks the
first character of the line. If it is a period, one additional first character of the line. If it is a period, one additional
period is inserted at the beginning of the line. period is inserted at the beginning of the line.
o When a line of mail text is received by the SMTP server, it checks * When a line of mail text is received by the SMTP server, it checks
the line. If the line is composed of a single period, it is the line. If the line is composed of a single period, it is
treated as the end of mail indicator. If the first character is a treated as the end of mail indicator. If the first character is a
period and there are other characters on the line, the first period and there are other characters on the line, the first
character is deleted. character is deleted.
The mail data may contain any of the 128 ASCII characters. All The mail data may contain any of the 128 ASCII characters. All
characters are to be delivered to the recipient's mailbox, including characters are to be delivered to the recipient's mailbox, including
spaces, vertical and horizontal tabs, and other control characters. spaces, vertical and horizontal tabs, and other control characters.
If the transmission channel provides an 8-bit byte (octet) data If the transmission channel provides an 8-bit byte (octet) data
stream, the 7-bit ASCII codes are transmitted, right justified, in stream, the 7-bit ASCII codes are transmitted, right justified, in
skipping to change at page 66, line 27 skipping to change at page 67, line 10
Clients MAY attempt to transmit these, but MUST be prepared for a Clients MAY attempt to transmit these, but MUST be prepared for a
server to reject them if they cannot be handled by it. To the server to reject them if they cannot be handled by it. To the
maximum extent possible, implementation techniques that impose no maximum extent possible, implementation techniques that impose no
limits on the length of these objects should be used. limits on the length of these objects should be used.
Extensions to SMTP may involve the use of characters that occupy more Extensions to SMTP may involve the use of characters that occupy more
than a single octet each. This section therefore specifies lengths than a single octet each. This section therefore specifies lengths
in octets where absolute lengths, rather than character counts, are in octets where absolute lengths, rather than character counts, are
intended. intended.
[[CREF19: [5321bis] [[Note in Draft: Klensin 20191126: Given the // [5321bis] [[Note in Draft: Klensin 20191126: Given the controversy
controversy on the SMTP mailing list between 20191123 and now about // on the SMTP mailing list between 20191123 and now about maximum
maximum lengths, is the above adequate or is further tuning of the // lengths, is the above adequate or is further tuning of the limit
limit text below needed? ]]]] // 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
The maximum total length of a domain name or number is 255 octets. The maximum total length of a domain name or number is 255 octets.
skipping to change at page 78, line 29 skipping to change at page 79, line 35
great concern about fixes applied by a relay or delivery SMTP server great concern about fixes applied by a relay or delivery SMTP server
that has little or no knowledge of the user or client machine. Many that has little or no knowledge of the user or client machine. Many
of these issues are addressed by using a separate protocol, such as of these issues are addressed by using a separate protocol, such as
that defined in RFC 6409 [42], for message submission, rather than that defined in RFC 6409 [42], for message submission, rather than
using originating SMTP servers for that purpose. using originating SMTP servers for that purpose.
The following changes to a message being processed MAY be applied The following changes to a message being processed MAY be applied
when necessary by an originating SMTP server, or one used as the when necessary by an originating SMTP server, or one used as the
target of SMTP as an initial posting (message submission) protocol: target of SMTP as an initial posting (message submission) protocol:
o Addition of a message-id field when none appears * Addition of a message-id field when none appears
o Addition of a date, time, or time zone when none appears * Addition of a date, time, or time zone when none appears
o Correction of addresses to proper FQDN format * Correction of addresses to proper FQDN format
The less information the server has about the client, the less likely The less information the server has about the client, the less likely
these changes are to be correct and the more caution and conservatism these changes are to be correct and the more caution and conservatism
should be applied when considering whether or not to perform fixes should be applied when considering whether or not to perform fixes
and how. These changes MUST NOT be applied by an SMTP server that and how. These changes MUST NOT be applied by an SMTP server that
provides an intermediate relay function. provides an intermediate relay function.
In all cases, properly operating clients supplying correct In all cases, properly operating clients supplying correct
information are preferred to corrections by the SMTP server. In all information are preferred to corrections by the SMTP server. In all
cases, documentation SHOULD be provided in trace header fields and/or cases, documentation SHOULD be provided in trace header fields and/or
skipping to change at page 80, line 16 skipping to change at page 81, 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. [[CREF20: [rfc5321bis] [[Note in draft - extension header fields.
Suggestion from 20070124 that got lost: delete "especially" and "the // [rfc5321bis] [[Note in draft - Suggestion from 20070124 that got
full set of" -- copying the first one can be as harmful as copying // lost: delete "especially" and "the full set of" -- copying the
all of them, at least without verifying that the addresses do appear // first one can be as harmful as copying all of them, at least
in the headers. See G.7.9 and ticket #15.]] Since this rule is often // without verifying that the addresses do appear in the headers.
violated in practice, and cannot be enforced, sending SMTP systems // See G.7.9 and ticket #15.Since this rule is often violated in
that are aware of "bcc" use MAY find it helpful to send each blind practice, and cannot be enforced, sending SMTP systems that are aware
copy as a separate message transaction containing only a single RCPT of "bcc" use MAY find it helpful to send each blind copy as a
command. separate message transaction containing only a single RCPT command.
There is no inherent relationship between either "reverse" (from the There is no inherent relationship between either "reverse" (from the
MAIL command) or "forward" (RCPT) addresses in the SMTP transaction MAIL command) or "forward" (RCPT) addresses in the SMTP transaction
("envelope") and the addresses in the header section. Receiving ("envelope") and the addresses in the header section. Receiving
systems SHOULD NOT attempt to deduce such relationships and use them systems SHOULD NOT attempt to deduce such relationships and use them
to alter the header section of the message for delivery. The popular to alter the header section of the message for delivery. The popular
"Apparently-to" header field is a violation of this principle as well "Apparently-to" header field is a violation of this principle as well
as a common source of unintended information disclosure and SHOULD as a common source of unintended information disclosure and SHOULD
NOT be used. NOT be used.
skipping to change at page 83, line 23 skipping to change at page 84, line 22
used in response to EHLO (or HELO), MAIL, or RCPT as appropriate. used in response to EHLO (or HELO), MAIL, or RCPT as appropriate.
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 * The first, "Simple Mail Transfer Protocol (SMTP) Service
Extensions" [52], 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.
specified in Section 2.2.2, no entry may be made in this registry Entries may be made only for service extensions (and associated
that starts in an "X". Entries may be made only for service keywords, parameters, or verbs) that are defined in Standards-
extensions (and associated keywords, parameters, or verbs) that Track or Experimental RFCs specifically approved by the IESG for
are defined in Standards-Track or Experimental RFCs specifically this purpose.
approved by the IESG for this purpose.
o The second registry, "Address Literal Tags" [53], consists of * 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" [52], established by RFC 821 * 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 85, line 24 skipping to change at page 86, line 21
10.1. Normative References 10.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate [1] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[2] American National Standards Institute (formerly United [2] American National Standards Institute (formerly United
States of America Standards Institute), "USA Code for States of America Standards Institute), "USA Code for
Information Interchange", ANSI X3.4-1968, 1968. Information Interchange", ANSI X3.4-1968, 1968. ANSI
X3.4-1968 has been replaced by newer versions with slight
ANSI X3.4-1968 has been replaced by newer versions with modifications, but the 1968 version remains definitive for
slight modifications, but the 1968 version remains the Internet.
definitive for the Internet.
[3] Postel, J., "Simple Mail Transfer Protocol", STD 10, [3] Postel, J., "Simple Mail Transfer Protocol", STD 10,
RFC 821, DOI 10.17487/RFC0821, August 1982, RFC 821, DOI 10.17487/RFC0821, August 1982,
<https://www.rfc-editor.org/info/rfc821>. <https://www.rfc-editor.org/info/rfc821>.
[4] Mockapetris, P., "Domain names - implementation and [4] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>. November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[5] Braden, R., Ed., "Requirements for Internet Hosts - [5] Braden, R., Ed., "Requirements for Internet Hosts -
skipping to change at page 86, line 23 skipping to change at page 87, line 19
[10] Hinden, R. and S. Deering, "IP Version 6 Addressing [10] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>. 2006, <https://www.rfc-editor.org/info/rfc4291>.
[11] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [11] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
[12] Resnick, P., "Internet Message Format", RFC 5322, [12] Resnick, P., Ed., "Internet Message Format", RFC 5322,
September 2008. DOI 10.17487/RFC5322, October 2008,
<https://www.rfc-editor.org/info/rfc5322>.
10.2. Informative References 10.2. Informative References
[13] Crocker, D., "STANDARD FOR THE FORMAT OF ARPA INTERNET [13] Crocker, D., "STANDARD FOR THE FORMAT OF ARPA INTERNET
TEXT MESSAGES", STD 11, RFC 822, DOI 10.17487/RFC0822, TEXT MESSAGES", STD 11, RFC 822, DOI 10.17487/RFC0822,
August 1982, <https://www.rfc-editor.org/info/rfc822>. August 1982, <https://www.rfc-editor.org/info/rfc822>.
[14] Butler, M., Postel, J., Chase, D., Goldberger, J., and J. [14] Butler, M., Postel, J., Chase, D., Goldberger, J., and J.
Reynolds, "Post Office Protocol: Version 2", RFC 937, Reynolds, "Post Office Protocol: Version 2", RFC 937,
DOI 10.17487/RFC0937, February 1985, DOI 10.17487/RFC0937, February 1985,
skipping to change at page 90, line 14 skipping to change at page 91, line 9
[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] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, [50] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
DOI 10.17487/RFC5321, October 2008, DOI 10.17487/RFC5321, October 2008,
<https://www.rfc-editor.org/info/rfc5321>. <https://www.rfc-editor.org/info/rfc5321>.
[51] Klensin, J., Ed., Murchison, K., Ed., and E. Sam, Ed., [51] Klensin, J.C., Ed., Murchison, K., Ed., and E. Sam, Ed.,
"Applicability Statement for IETF Core Email Protocols", "Applicability Statement for IETF Core Email Protocols", 6
August 2021, <https://datatracker.ietf.org/doc/draft-ietf- August 2021, <https://datatracker.ietf.org/doc/draft-ietf-
emailcore-as/>. emailcore-as/>.
[52] Internet Assigned Number Authority (IANA), "IANA Mail [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>.
[53] 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>.
[54] 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
[55] 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 reflect whatever you
Notes in draft: RFC Editor: Please adjust date field to want for a registry that is updated periodically. IANA:
reflect whatever you want for a registry that is updated Please determine if the above URL is a sufficiently stable
periodically. IANA: Please determine if the above URL is reference and adjust as appropriate if it is not.
a sufficiently stable reference and adjust as appropriate
if it is not.
Appendix A. TCP Transport Service Appendix A. TCP Transport Service
The TCP connection supports the transmission of 8-bit bytes. The The TCP connection supports the transmission of 8-bit bytes. The
SMTP data is 7-bit ASCII characters. Each character is transmitted SMTP data is 7-bit ASCII characters. Each character is transmitted
as an 8-bit byte with the high-order bit cleared to zero. Service as an 8-bit byte with the high-order bit cleared to zero. Service
extensions may modify this rule to permit transmission of full 8-bit extensions may modify this rule to permit transmission of full 8-bit
data bytes as part of the message body, or, if specifically designed data bytes as part of the message body, or, if specifically designed
to do so, in SMTP commands or responses. to do so, in SMTP commands or responses.
skipping to change at page 99, line 22 skipping to change at page 100, line 43
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
hence the latter as well). In most cases, those divergences call for hence the latter as well). In most cases, those divergences call for
revision of the Technical Specification to match the practice, revision of the Technical Specification to match the practice,
clarification of the specification text in other ways, or a more clarification of the specification text in other ways, or a more
comprehensive explanation of why the practices recommended by the comprehensive explanation of why the practices recommended by the
specification should really be followed. specification should really be followed.
Those discussions raised two other issues, which were that Those discussions raised two other issues, which were that
o The publication of the Submission Server specification of RFC 6409 * The publication of the Submission Server specification of RFC 6409
in November 2011 may not have been fully reflected in RFC 5321 in November 2011 may not have been fully reflected in RFC 5321
(despite the even earlier publication of RFC 4409) and (despite the even earlier publication of RFC 4409) and
o There may be inconsistencies between the July 2009 Internet Mail * There may be inconsistencies between the July 2009 Internet Mail
Architecture description of RFC 5598 and the model described in Architecture description of RFC 5598 and the model described in
RFC 5321. The issue called out in Appendix G.3 below may be an RFC 5321. The issue called out in Appendix G.3 below may be an
example of one of those inconsistencies. example of one of those inconsistencies.
Those discrepancies should be identified and discussed and decisions Those discrepancies should be identified and discussed and decisions
made to fix them (and where) or to ignore them and let them continue. made to fix them (and where) or to ignore them and let them continue.
There has also been discussion on the mailing list, perhaps amounting There has also been discussion on the mailing list, perhaps amounting
to very rough consensus, that any revision of RFC 5321 and/or 5322 to very rough consensus, that any revision of RFC 5321 and/or 5322
should be accompanied by a separate Applicability Statement document should be accompanied by a separate Applicability Statement document
skipping to change at page 102, line 23 skipping to change at page 103, line 43
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.
[[CREF21: See correspondence on this ticket 2021-07-06 through // 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",
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 (Ticket #34/ erratum 1820 may be resolved
in -06).
G.7.6. Requirements for domain name and/or IP address in EHLO G.7.6. Requirements for domain name and/or IP address in EHLO
Text in Section 4.1.4; change made in -05. Text in Section 4.1.4; change made in -05.
Ticket #19. Ticket #19.
G.7.7. Does the 'first digit only' and/or non-listed reply code text G.7.7. Does the 'first digit only' and/or non-listed reply code text
need clarification? need clarification?
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
skipping to change at page 104, line 21 skipping to change at page 105, line 49
G.7.14. Abstract Update G.7.14. Abstract Update
Does the Abstract need to be modified in the light of RFC 6409 or Does the Abstract need to be modified in the light of RFC 6409 or
other changes? other changes?
G.7.15. Informative References to MIME and/or Message Submission G.7.15. Informative References to MIME and/or Message Submission
Should RFC 2045 (MIME) and/or RFC 6409 (Message Submission) be Should RFC 2045 (MIME) and/or RFC 6409 (Message Submission) be
referenced at the end of Section 1.2? referenced at the end of Section 1.2?
Ticket #53.
G.7.16. Mail Transaction Discussion G.7.16. Mail Transaction Discussion
Does the discussion of mail transactions need more work (see CREF in Does the discussion of mail transactions need more work (see CREF in
Section 3.3.)? Section 3.3.)?
G.7.17. Hop-by-hop Authentication and/or Encryption G.7.17. Hop by hop Authentication and/or Encryption
Should this document discuss hop-by-hop authentication or, for that Should this document discuss hop-by-hop authentication or, for that
matter, encryption? (See CREF in Section 2.) matter, encryption? (See CREF in Section 2.)
Propose "No, it shouldn't" (20211101 conversation with Todd.)
Ticket #50.
G.7.18. More Text About 554 Given 521, etc. G.7.18. More Text About 554 Given 521, etc.
Does reply code 554 need additional or different explanation in the Does reply code 554 need additional or different explanation in the
light of the addition of the new 521 code and/or the new (in 5321bis light of the addition of the new 521 code and/or the new (in 5321bis
Section 4.2.4.2? (See CREF in Section 4.2.3.) Section 4.2.4.2? (See CREF in Section 4.2.3.)
G.7.19. Minimum Lengths and Quantities G.7.19. Minimum Lengths and Quantities
Are the minimum lengths and quantities specified in Section 4.5.3 Are the minimum lengths and quantities specified in Section 4.5.3
skipping to change at page 106, line 38 skipping to change at page 108, line 25
and sending commands before the incoming transaction is complete), and sending commands before the incoming transaction is complete),
RFC 5321 continues to use the original terminology in some places. RFC 5321 continues to use the original terminology in some places.
Should we revisit that usage, possibly even returning to consistent Should we revisit that usage, possibly even returning to consistent
use of the original terminology? use of the original terminology?
G.12. Extension Keywords Starting in 'X-' G.12. Extension Keywords Starting in 'X-'
Section 2.2.2 contains a discussion of SMTP keywords starting in "X". Section 2.2.2 contains a discussion of SMTP keywords starting in "X".
Given general experience with such things and RFC 6648, is there any Given general experience with such things and RFC 6648, is there any
reason to not deprecate that practice entirely and remove that text? reason to not deprecate that practice entirely and remove that text?
If we do so, should Section 4.1.5 be dropped or rewritten to make If we do so, should the former Section 4.1.5 be dropped or rewritten
clear this is an obsolete practice? to make clear this is an obsolete practice?
Ticket #42. 4.1.5 eliminated in rfc5321bis-06.
Ticket #42 (resolved with -06??).
G.13. Deprecating HELO G.13. Deprecating HELO
RFC 5321 (and 2821 before it) very carefully circle around the status RFC 5321 (and 2821 before it) very carefully circle around the status
of HELO, even recommending its use as a fallback when EHLO is sent of HELO, even recommending its use as a fallback when EHLO is sent
and a "command not recognized" response is received. We are just a and a "command not recognized" response is received. We are just a
few months short of 20 years; is it time to deprecate the thing and few months short of 20 years; is it time to deprecate the thing and
clean out some or all of that text? And, given a recent (4Q2020) clean out some or all of that text? And, given a recent (4Q2020)
discussion on the EMAILCORE list, should EHLO be explicitly bound to discussion on the EMAILCORE list, should EHLO be explicitly bound to
SMTP over TCP with the older transports allowed only with HELO? SMTP over TCP with the older transports allowed only with HELO?
skipping to change at page 108, line 32 skipping to change at page 110, line 22
Appendix H. RFC 5321 Errata Summary and Tentative Change Log Appendix H. RFC 5321 Errata Summary and Tentative Change Log
[[RFC Editor: Please remove this section before publication.]] [[RFC Editor: Please remove this section before publication.]]
H.1. RFC 5321 Errata Summary H.1. RFC 5321 Errata Summary
This document addresses the following errata filed against RFC 5321 This document addresses the following errata filed against RFC 5321
since its publication in October 2008 [54]. As with the previous since its publication in October 2008 [54]. As with the previous
appendix, ticket numbers included below reference appendix, ticket numbers included below reference
https://trac.ietf.org/trac/emailcore/report/1 . [[CREF22: [[Note in https://trac.ietf.org/trac/emailcore/report/1 .
Draft: Items with comments below have not yet been resolved as // [[Note in Draft: Items with comments below have not yet been
errata. As of the end of November 2020, none of them have been // resolved as errata. As of the end of November 2020, none of them
checked and verified by the emailcore WG.]]]]. // have been 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. [[CREF23: [5321bis]The IPv6 syntax 4315 ABNF - IPv6 Section 4.1.3.
has been adjusted since 5321 was published (the erratum mentions // [5321bis]The IPv6 syntax has been adjusted since 5321 was
RFC 5952, but RFC 6874 and draft-carpenter-6man-rfc6874bis should // published (the erratum mentions RFC 5952, but RFC 6874 and
also be considered). See the rewritten form and the comment in draft-
the section cited in the previous sentence, at least for the RFC // carpenter-6man-rfc6874bis should also be considered). See the
5952 issues. The editor awaits instructions. See // rewritten form and the comment in the section cited in the
https://www.rfc-editor.org/errata/eid4315]] // 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. confusion in some sections Section 4.4.
Ticket #7 Ticket #7
[[CREF24: [5321bis]As Barry notes in his verifier comments on the
erratum (see https://www.rfc-editor.org/errata/eid3447), the
comments and suggestions here raise a number of interesting (and
difficult) 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 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 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 to read as well as being error prone. If we want to get
the document entirely into contemporary style, we really should
bite the bullet and do a complete rewrite. To respond to a
different point in Barry's discussion, I think an explicit
statement that 5321/5322 and their predecessors differ in places
and why would be helpful. Text, and suggestions about where to
put it, are solicited. A list of differences might be a good idea
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: // [5321bis]As Barry notes in his verifier comments on the erratum
[5321bis]Well, this is interesting because the XML is correct and // (see https://www.rfc-editor.org/errata/eid3447), the comments
the spaces are there, embedded in artwork. So either the XML2RFC and
processor at the time took those leading spaces out or the RFC // suggestions here raise a number of interesting (and difficult)
Editor improved on the document and the change was not caught in // issues. One of the issues is that the core of RFCs 5321 (and
AUTH48, perhaps because rfcdiff ignores white space. We just need // 2821) is text carried over from Jon Postel's RFC 821, a
to watch for future iterations. ]] document
// 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
// 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
// to read as well as being error prone. If we want to get the
// document entirely into contemporary style, we really should
bite
// the bullet and do a complete rewrite. To respond to a
different
// point in Barry's discussion, I think an explicit statement that
// 5321/5322 and their predecessors differ in places and why would
be
// helpful. Text, and suggestions about where to put it, are
// solicited. A list of differences might be a good idea 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.
// [5321bis]Well, this is interesting because the XML is correct
and
// the spaces are there, embedded in artwork. So either the
XML2RFC
// processor at the time took those leading spaces out or the RFC
// Editor improved on the document and the change was not caught
in
// AUTH48, perhaps because rfcdiff ignores white space. We just
need
// 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). proposed erratum suggests).
Text changed; ticket should probably be closed after WG reviews Text changed; ticket should probably be closed after WG reviews
-04. -04.
Ticket #30. Ticket #30 (resolved??).
[[CREF26: [5321bis]Note that rejected errata have _not_ been reviewed // [5321bis]Note that rejected errata have _not_ been reviewed to see
to see if they contain anything useful that should be discussed again // if they contain anything useful that should be discussed again
with the possibility of rethinking and changing text. Volunteers // with the possibility of rethinking and changing text. Volunteers
sought.]] // sought.
H.2. Changes from RFC 5321 (published October 2008) to the initial H.2. Changes from RFC 5321 (published October 2008) to the initial
(-00) version of this draft (-00) version of this draft
o Acknowledgments section (Section 9) trimmed back for new document. * Acknowledgments section (Section 9) trimmed back for new document.
o Introductory paragraph to Appendix F extended to make it clear * Introductory paragraph to Appendix F extended to make it clear
that these features were deprecated a long time ago and really that these features were deprecated a long time ago and really
should not be in use any more. should not be in use any more.
o Adjusted some language to clarify that source routes really, * Adjusted some language to clarify that source routes really,
really, should not be used or depended upon. really, should not be used or depended upon.
o IPv6 address syntax replaced by a copy of the IPv6 URI syntax and * IPv6 address syntax replaced by a copy of the IPv6 URI syntax and
a note added. a note added.
o Production index added as a first step in tying all productions to * Production index added as a first step in tying all productions to
their sources. As part of the effort to make the document more their sources. As part of the effort to make the document more
easily navigable, table of contents entries have been created for easily navigable, table of contents entries have been created for
the individual command descriptions. the individual command descriptions.
o Clarified the relationship between the SMTP "letters, digits, and * 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, * 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 * In conjunction with the above, explicitly obsolete RFCs 1846 and
7504 (but that might not be right -- see email 2021-10-03. 7504 (but that might not be right -- see email 2021-10-03.
o Incorporated a correction reflecting Errata ID 2578. * Incorporated a correction reflecting Errata ID 2578.
o Some small editorial changes made to eliminate redundant * 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 * 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
narrative comments in CREFs. narrative comments in CREFs.
o Checked and rationalized "response" (to a command) and "reply * Checked and rationalized "response" (to a command) and "reply
code" terminology. One can talk about a "999 response" but only a code" terminology. One can talk about a "999 response" but only a
"999 reply code". There is no such thing as a "response code". "999 reply code". There is no such thing as a "response code".
o Added note about length limit on mailbox names ("email * Added note about length limit on mailbox names ("email
addresses"). addresses").
o Added an "errata summary" subsection to this change log/ * Added an "errata summary" subsection to this change log/
comparison to 5321 in this Appendix. The entire Appendix will, of comparison to 5321 in this Appendix. The entire Appendix will, of
course, disappear at the time of RFC publication unless someone course, disappear at the time of RFC publication unless someone
wants to make a strong case for retaining it. wants to make a strong case for retaining it.
o Rationalized CREFs to 2821, 5321, 5321bis etc.; added note to * Rationalized CREFs to 2821, 5321, 5321bis etc.; added note to
readers below the Abstract. readers below the Abstract.
o Temporarily added a "Note on Reading This Working Draft" after the * Temporarily added a "Note on Reading This Working Draft" after the
Abstract. Abstract.
H.3. Changes Among Versions of Rfc5321bis H.3. Changes Among Versions of Rfc5321bis
H.3.1. Changes from draft-klensin-rfc5321bis-00 (posted 2012-12-02) to H.3.1. Changes from draft-klensin-rfc5321bis-00 (posted 2012-12-02) to
-01 -01
Substantively, these two versions differ only by suppression of the Substantively, these two versions differ only by suppression of the
CREF and other discussion associated with the evolution from RFC 2821 CREF and other discussion associated with the evolution from RFC 2821
to RFC 5321. That change includes an update to the document's Note to RFC 5321. That change includes an update to the document's Note
to Readers, the date, the file name, and the addition of this change to Readers, the date, the file name, and the addition of this change
log subsection. log subsection.
H.3.2. Changes from draft-klensin-rfc5321bis-01 (20191203) to -02 H.3.2. Changes from draft-klensin-rfc5321bis-01 (20191203) to -02
o Minor clarifications to improve text, e.g., addition of NOOP to * Minor clarifications to improve text, e.g., addition of NOOP to
the list of non-mail transaction examples in Section 4.1.4. the list of non-mail transaction examples in Section 4.1.4.
o Added topics exposed in the ietf-smtp list and the IETF list * Added topics exposed in the ietf-smtp list and the IETF list
"dogfood" discussion during December 2019 and an index listing of "dogfood" discussion during December 2019 and an index listing of
substantive issues identified only in CREFs in the prior draft as substantive issues identified only in CREFs in the prior draft as
a new Appendix G.. a new Appendix G..
H.3.3. Changes from draft-klensin-rfc5321bis-02 (2019-12-27) to -03 H.3.3. Changes from draft-klensin-rfc5321bis-02 (2019-12-27) to -03
o Added more text to Appendix G.7.1 to specifically call out the * Added more text to Appendix G.7.1 to specifically call out the
session-opening policy issues surrounding these codes. session-opening policy issues surrounding these codes.
o Added discussion of "1yz" reinstatement in Appendix G.7.11. * Added discussion of "1yz" reinstatement in Appendix G.7.11.
o Added discussion of timeouts in Appendix G.7.12. * Added discussion of timeouts in Appendix G.7.12.
o Added subsection on Enhanced Status Codes and DSNs to the * Added subsection on Enhanced Status Codes and DSNs to the
outstanding issues list Appendix G.8. outstanding issues list Appendix G.8.
o Replaced reference to RFC 1652 (8BITMIME) with the Internet * Replaced reference to RFC 1652 (8BITMIME) with the Internet
Standard version, RFC 6152. Standard version, RFC 6152.
o With help from cketti, clarified the ABNF productions whose * With help from cketti, clarified the ABNF productions whose
terminals appear in other documents. terminals appear in other documents.
o Added discussions of Quoted-string, Internationalization, and * Added discussions of Quoted-string, Internationalization, and
client-server versus sender-receiver terminology to Appendix G. client-server versus sender-receiver terminology to Appendix G.
o Added note to the Abstract. * Added note to the Abstract.
H.3.4. Changes from draft-klensin-rfc5321bis-03 (2020-07-02) to draft- H.3.4. Changes from draft-klensin-rfc5321bis-03 (2020-07-02) to draft-
ietf-emailcore-rfc5321bis-00 ietf-emailcore-rfc5321bis-00
o Added a paragraph about non-null quoted strings to Appendix G.9. * Added a paragraph about non-null quoted strings to Appendix G.9.
o Added an explicit pointer to email insecurity and TLS to * Added an explicit pointer to email insecurity and TLS to
Appendix G.6. Inspired by Ben Kaduk's comment on the WG Charter, Appendix G.6. Inspired by Ben Kaduk's comment on the WG Charter,
2020-09-09. 2020-09-09.
o Converted document from individual to emailcore WG effort. * Converted document from individual to emailcore WG effort.
H.3.5. Changes from draft-ietf-emailcore-rfc5321bis-00 (2020-10-06) to H.3.5. Changes from draft-ietf-emailcore-rfc5321bis-00 (2020-10-06) to
-01 -01
o Editorial: Corrected "blackslash" to "backslash" * Editorial: Corrected "blackslash" to "backslash"
o Rewrote the introduction to Appendix G slightly to reflect the * Rewrote the introduction to Appendix G slightly to reflect the
creation of the EMAILCORE WG. creation of the EMAILCORE WG.
o Applied fixes for repeated use of EHLO. See Appendix G.2. * Applied fixes for repeated use of EHLO. See Appendix G.2.
o Added two new questions, one about "X" extensions (Appendix G.12) * Added two new questions, one about "X" extensions (Appendix G.12)
and one about the status of HELO (Appendix G.13). and one about the status of HELO (Appendix G.13).
o Removed mention of SEND, SAML, SOML from the main body of the text * Removed mention of SEND, SAML, SOML from the main body of the text
(Ticket #20). (Ticket #20).
o Added a warning about side effects to Appendix G.7.5. * Added a warning about side effects to Appendix G.7.5.
o Added ticket numbers to descriptions of issues and changes, * Added ticket numbers to descriptions of issues and changes,
adjusted some text so relationships would be more clear, and added adjusted some text so relationships would be more clear, and added
subsections to the Appendix G and H lists to pick up on tickets subsections to the Appendix G and H lists to pick up on tickets
that were not easily identified in those sections of with the that were not easily identified in those sections of with the
text. text.
o Made several additions to the Index, including one to deal with * Made several additions to the Index, including one to deal with
SEND et al., as above. SEND et al., as above.
H.3.6. Changes from draft-ietf-emailcore-rfc5321bis-01 (2020-12-25) to H.3.6. Changes from draft-ietf-emailcore-rfc5321bis-01 (2020-12-25) to
-02 -02
o Corrected discussion mailing list to point to emailcore@ietf.org * Corrected discussion mailing list to point to emailcore@ietf.org
in the introductory note. in the introductory note.
o Added new subsection(s) to Appendix G to reflect newly discovered * Added new subsection(s) to Appendix G to reflect newly discovered
issues. issues.
o Changed "as discussed in" references in Section 4.5.5 per ticket * Changed "as discussed in" references in Section 4.5.5 per ticket
#45. #45.
o Corrected a misleading use of the term "mailbox" in Section 3.3. * Corrected a misleading use of the term "mailbox" in Section 3.3.
o Changed descriptions of use of first digit in replies per ticket * Changed descriptions of use of first digit in replies per ticket
#13. See Appendix G.7.7. #13. See Appendix G.7.7.
o Moved paragraph per ticket #28, erratum 1851. * Moved paragraph per ticket #28, erratum 1851.
o Added more clarifying cross-references, clarified some CREFs, and * Added more clarifying cross-references, clarified some CREFs, and
cleaned out some of those that no longer seemed relevant. cleaned out some of those that no longer seemed relevant.
o Removed "updates 1123" is unnecessary and obsolete. * Removed "updates 1123" is unnecessary and obsolete.
o Updated several references. * Updated several references.
H.3.7. Changes from draft-ietf-emailcore-rfc5321bis-02 (2021-02-21) to H.3.7. Changes from draft-ietf-emailcore-rfc5321bis-02 (2021-02-21) to
-03 -03
o Editorial: Fixed some instances of constructions like "RCPT TO * Editorial: Fixed some instances of constructions like "RCPT TO
command". The name of the command is RCPT. Sloppy editing in command". The name of the command is RCPT. Sloppy editing in
2008. 2008.
o Added text and cross-references to clarify the role of 452 and 552 * Added text and cross-references to clarify the role of 452 and 552
in "too many recipients" situations. in "too many recipients" situations.
o Added Appendix G.15 to discuss changes to better reflect * Added Appendix G.15 to discuss changes to better reflect
"operational necessity" issue. "operational necessity" issue.
o Added detail for erratum 5711, ticket #29. * Added detail for erratum 5711, ticket #29.
o Added new subsections of Appendix G.7 to keep some previously- * Added new subsections of Appendix G.7 to keep some previously-
unnoted CREF notes from getting lost. Also removed some CREFs unnoted CREF notes from getting lost. Also removed some CREFs
that were notes on changes made before the WG was created or that were notes on changes made before the WG was created or
appeared to no longer have value and trimmed or rewrote some of appeared to no longer have value and trimmed or rewrote some of
the remaining ones. the remaining ones.
o More discussion of Ticket #13, See Appendix G.7.7. * More discussion of Ticket #13, See Appendix G.7.7.
o Identified Ticket #41 as closed. See Appendix Appendix G.7.3; * Identified Ticket #41 as closed. See Appendix Appendix G.7.3;
notes removed from Section 2.3.5. notes removed from Section 2.3.5.
o "SHOULD" requirement for interpreting 552 "too many recipients" * "SHOULD" requirement for interpreting 552 "too many recipients"
removed from Section 4.5.3.1.10, explanation added, and text removed from Section 4.5.3.1.10, explanation added, and text
cleaned up. Also removed the parenthetical historical notes on cleaned up. Also removed the parenthetical historical notes on
the return code definitions in Section 4.2. See Appendix G.5. the return code definitions in Section 4.2. See Appendix G.5.
(Ticket #5) (Ticket #5)
o Modified Appendix G.8 to add a note about the normative status of * Modified Appendix G.8 to add a note about the normative status of
RFC 3463 and moved that reference. RFC 3463 and moved that reference.
o Several clarifications to initiation and termination of mail * Several clarifications to initiation and termination of mail
transactions in Section 4.1.4. transactions in Section 4.1.4.
o Several additional minor editorial improvements. * Several additional minor editorial improvements.
o Note for drafts -03 and -04 only, modified somewhat for -05: Some * Note for drafts -03 and -04 only, modified somewhat for -05: Some
issues are still outstanding: Notes were posted to the list on issues are still outstanding: Notes were posted to the list on
2021-07-09 about tickets #7 (closed?), #10, #14 (closed), #20, 2021-07-09 about tickets #7 (closed?), #10, #14 (closed), #20,
#30, and #42. Even though some comments about them appeared in #30, and #42. Even though some comments about them appeared in
the subsequent day or so, there appears to have been insufficient the subsequent day or so, there appears to have been insufficient
time for discussions to stabilize sufficiently for changes to be 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 * 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
ticket. If there are objections, speak up.]]
o Several other small editorial corrections. // Editor's note: change treated as Editorial without a ticket.
If
// there are objections, speak up.
o Added several notes about the possible need to add text to reflect * Several other small editorial corrections.
* Added several notes about the possible need to add text to reflect
the presence of MSAs and to clarify whether MUAs send messages the presence of MSAs and to clarify whether MUAs send messages
directly to MTAs or whether, in that case, the MUAs are just directly to MTAs or whether, in that case, the MUAs are just
incorporating MSA functions. incorporating MSA functions.
o Added new text to Appendix G.14 reflecting discussions of the * Added new text to Appendix G.14 reflecting discussions of the
Received...FOR issue. Received...FOR issue.
o Adjusted discussion of erratum 4315 (Ticket #27) to reflect more * Adjusted discussion of erratum 4315 (Ticket #27) to reflect more
recent IPv6 syntax developments. recent IPv6 syntax developments.
o Adjusted discussion of the various "mail not accepted" codes, * Adjusted discussion of the various "mail not accepted" codes,
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 H.3.9. Changes from draft-ietf-emailcore-rfc5321bis-04 (2021-10-03) to
-05 -05
o Took a first step toward rewriting and updating the introductory * Took a first step toward rewriting and updating the introductory
material. It is only a first step; suggestions welcome. material. It is only a first step; suggestions welcome.
o Minor editorial fixes. * Minor editorial fixes.
o Correct text about domain name checking in Section 4.1.4, probably * Correct text about domain name checking in Section 4.1.4, probably
fixing ticket #19. See CREF added there. fixing ticket #19. See CREF added there.
o Added Appendix G.16 a placeholder for the 8BITMIME discussion and * Added Appendix G.16 a placeholder for the 8BITMIME discussion and
possible action. possible action.
o Additional changes to the description and organization of trace * Additional changes to the description and organization of trace
field materials. Intended to resolve the 5321bis part of Ticket field materials. Intended to resolve the 5321bis part of Ticket
#7. #7.
o Remaining patch to SEND, etc., discussion in Appendix F.6 applied * Remaining patch to SEND, etc., discussion in Appendix F.6 applied
and CREF removed. and CREF removed.
o Removed discussion of "X-" and edited associated text. The fix * Removed discussion of "X-" and edited associated text. The fix
may or may not be sufficient to resolve Ticket #42. may or may not be sufficient to resolve Ticket #42.
o Verified that the problems of getting four-level sections (e.g., * Verified that the problems of getting four-level sections (e.g.,
"4.1.1.1" and other command-specific ones) into the table of "4.1.1.1" and other command-specific ones) into the table of
contents and the index reflecting page numbers still exist and contents and the index reflecting page numbers still exist and
updated the introductory note. updated the introductory note.
H.3.10. Changes from draft-ietf-emailcore-rfc5321bis-05 (2021-10-24) to
-06
* Finished making changes for "X-" and commands starting in "X".
Changes made in -05 were incomplete. This should allow closing
Ticket #42.
* Removed spurious "for use in delivery notifications" from 3.6.2.
Was just a pasting-type error.
* Changed "In other words" to "In particular" in Section 2.3.5 per
Ticket #10 and July 2021 mailing list discussion. Removed
associated CREF.
* Converted to xml2rfc v3 (thanks to John Levine for doing the hard
parts) and then modified the introductory note accordingly.
* Started reworking the Abstract -- see revised CREF there.
* Rewrote Section 2.3.3 slightly to note the existence of submission
servers and removed the CREF.
* Updated Appendix G.7.17 and slightly modified CREF note in
Section 2 -- proposed to not get 5321bis involved with this
(Ticket #50).
* Rewrote parts of Section 3.9 to clarify text amd respond to Ticket
#34.
* Inserted suggested text info CREF at end of Section 1.2. Comments
welcome. Soon.
Index Index
A A C
Argument Syntax
A-d-l 43
Additional-Registered-Clauses 64
address-literal 43
Addtl-Link 64
Addtl-Protocol 64
ALPHA 42
Argument 43
At-domain 43
atext 43
Atom 44
By-domain 63
CFWS 43
CRLF 42
dcontent 45
DIGIT 42
Domain 43
Dot-string 44
esmtp-keyword 43
esmtp-param 43
esmtp-value 43
Extended-Domain 63
For 64
Forward-Path 43
From-domain 63
FWS 43
General-address-literal 45
Greeting 49
h16 46
HEXDIG 42
ID 64
IPv4-address-literal 45
IPv6-addr 46
IPv6-address-literal 45
Keyword 43
Ldh-str 43
Let-dig 43
Link 64
Local-part 44
ls32 46
Mail-parameters 43
Mailbox 43
Opt-info 63
Path 43
Protocol 64
QcontentSMTP 44
qtextSMTP 44
quoted-pairSMTP 44
Quoted-string 44
Rcpt-parameters 43
Reply-code 49
Reply-line 49
Return-path-line 63
Reverse-Path 43
Snum 46
SP 42
Stamp 63
Standardized-tag 45
String 44
sub-domain 43
TCP-info 63
textstring 49
Time-stamp-line 63
Via 63
With 63
C A
Command Syntax Argument Syntax
data 40 A-d-l Section 4.1.2
ehlo 20, 35 ALPHA Section 4.1.2, Paragraph 2, Item 1
expn 41 Additional-Registered-Clauses Section 4.4.1
helo 35 Addtl-Link Section 4.4.1
help 41 Addtl-Protocol Section 4.4.1
mail 37 Argument Section 4.1.2
noop 41 At-domain Section 4.1.2
quit 42 Atom Section 4.1.2
rcpt 38 By-domain Section 4.4.1
rset 40 CFWS Section 4.1.2, Paragraph 2, Item 2
send, saml, soml 104 CRLF Section 4.1.2, Paragraph 2, Item 1
vrfy 40 DIGIT Section 4.1.2, Paragraph 2, Item 1
Domain Section 4.1.2
Dot-string Section 4.1.2
Extended-Domain Section 4.4.1
FWS Section 4.1.2, Paragraph 2, Item 2
For Section 4.4.1
Forward-Path Section 4.1.2
From-domain Section 4.4.1
General-address-literal Section 4.1.3
Greeting Section 4.2
HEXDIG Section 4.1.2, Paragraph 2, Item 1
ID Section 4.4.1
IPv4-address-literal Section 4.1.3
IPv6-addr Section 4.1.3
IPv6-address-literal Section 4.1.3
Keyword Section 4.1.2
Ldh-str Section 4.1.2
Let-dig Section 4.1.2
Link Section 4.4.1
Local-part Section 4.1.2
Mail-parameters Section 4.1.2
Mailbox Section 4.1.2
Opt-info Section 4.4.1
Path Section 4.1.2
Protocol Section 4.4.1
QcontentSMTP Section 4.1.2
Quoted-string Section 4.1.2
Rcpt-parameters Section 4.1.2
Reply-code Section 4.2
Reply-line Section 4.2
Return-path-line Section 4.4.1
Reverse-Path Section 4.1.2
SP Section 4.1.2, Paragraph 2, Item 1
Snum Section 4.1.3
Stamp Section 4.4.1
Standardized-tag Section 4.1.3
String Section 4.1.2
TCP-info Section 4.4.1
Time-stamp-line Section 4.4.1
Via Section 4.4.1
With Section 4.4.1
address-literal Section 4.1.2
atext Section 4.1.2, Paragraph 2, Item 2
dcontent Section 4.1.3
esmtp-keyword Section 4.1.2
esmtp-param Section 4.1.2
esmtp-value Section 4.1.2
h16 Section 4.1.3
ls32 Section 4.1.3
qtextSMTP Section 4.1.2
quoted-pairSMTP Section 4.1.2
sub-domain Section 4.1.2
textstring Section 4.2
C
Command Syntax
data Section 4.1.1.4, Paragraph 8, Item 1
ehlo Section 3.2, Paragraph 1; Section 4.1.1.1, Paragraph 1
expn Section 4.1.1.7, Paragraph 4, Item 1
helo Section 4.1.1.1, Paragraph 1
help Section 4.1.1.8, Paragraph 5, Item 1
mail Section 4.1.1.2
noop Section 4.1.1.9, Paragraph 4, Item 1
quit Section 4.1.1.10, Paragraph 5, Item 1
rcpt Section 4.1.1.3, Paragraph 17
rset Section 4.1.1.5, Paragraph 4, Item 1
send, saml, soml Appendix G.7.13, Paragraph 1
vrfy Section 4.1.1.6, Paragraph 4, Item 1
Author's Address Author's Address
John C. Klensin John C. Klensin
1770 Massachusetts Ave, Suite 322 1770 Massachusetts Ave, Suite 322
Cambridge, MA 02140 Cambridge, MA 02140
USA United States of America
EMail: john-ietf@jck.com Email: john-ietf@jck.com
 End of changes. 241 change blocks. 
597 lines changed or deleted 671 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/