< draft-klensin-rfc5321bis-01.txt   draft-klensin-rfc5321bis-02.txt >
Network Working Group J. Klensin Network Working Group J. Klensin
Internet-Draft December 3, 2019 Internet-Draft December 27, 2019
Obsoletes: 5321, 1846, 7504 (if Obsoletes: 5321, 1846, 7504 (if
approved) approved)
Updates: 1123 (if approved) Updates: 1123 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: June 5, 2020 Expires: June 29, 2020
Simple Mail Transfer Protocol Simple Mail Transfer Protocol
draft-klensin-rfc5321bis-01 draft-klensin-rfc5321bis-02
Abstract Abstract
This document is a specification of the basic protocol for Internet This document is a specification of the basic protocol for Internet
electronic mail transport. It consolidates, updates, and clarifies electronic mail transport. It consolidates, updates, and clarifies
several previous documents, making all or parts of most of them several previous documents, making all or parts of most of them
obsolete. It covers the SMTP extension mechanisms and best practices obsolete. It covers the SMTP extension mechanisms and best practices
for the contemporary Internet, but does not provide details about for the contemporary Internet, but does not provide details about
particular extensions. Although SMTP was designed as a mail particular extensions. Although SMTP was designed as a mail
transport and delivery protocol, this specification also contains transport and delivery protocol, this specification also contains
skipping to change at page 1, line 35 skipping to change at page 1, line 35
environments. environments.
Note on Reading This Working Draft Note on Reading This Working Draft
This working draft is extensively annotated with information about This working draft is extensively annotated with information about
changes made over the decade since RFC 5321 appeared, especially when changes made over the decade since RFC 5321 appeared, especially when
those changes might be controversial or should get careful review. those changes might be controversial or should get careful review.
Anything marked in CREF comments with "[5321bis]" is current. In Anything marked in CREF comments with "[5321bis]" is current. In
general, unless those are marked with "[[Note in Draft", in the general, unless those are marked with "[[Note in Draft", in the
contents of an "Editor's note", or are in the "Errata Summary" contents of an "Editor's note", or are in the "Errata Summary"
appendix (Appendix G.1, they are just notes on changes that have appendix (Appendix H.1, they are just notes on changes that have
already been made and where those changes originated. Comments already been made and where those changes originated. Comments
identified as "2821ter" arose after the Last Call on what became identified as "2821ter" arose after the Last Call on what became
RFC5321, sometimes before AUTH48 on that document or a bit later. RFC5321, sometimes before AUTH48 on that document or a bit later.
Those, of course, should still be reviewed. Surviving comments about Those, of course, should still be reviewed. Surviving comments about
rfc5321bis-00 followed by a letter indicate intermediate working rfc5321bis-00 followed by a letter indicate intermediate working
versions of this draft and can be ignored unless the origin of versions of this draft and can be ignored unless the origin of
changes is important. As one can tell from the dates (when they are changes is important. As one can tell from the dates (when they are
given), this document has been periodically updated over a very long given), this document has been periodically updated over a very long
period of time. period of time.
This evolving draft should be discussed on the ietf-smtp@ietf.org
list.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 5, 2020. This Internet-Draft will expire on June 29, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Transport of Electronic Mail . . . . . . . . . . . . . . 5 1.1. Transport of Electronic Mail . . . . . . . . . . . . . . 5
1.2. History and Context for This Document . . . . . . . . . . 5 1.2. History and Context for This Document . . . . . . . . . . 6
1.3. Document Conventions . . . . . . . . . . . . . . . . . . 7 1.3. Document Conventions . . . . . . . . . . . . . . . . . . 7
2. The SMTP Model . . . . . . . . . . . . . . . . . . . . . . . 7 2. The SMTP Model . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Basic Structure . . . . . . . . . . . . . . . . . . . . . 7 2.1. Basic Structure . . . . . . . . . . . . . . . . . . . . . 8
2.2. The Extension Model . . . . . . . . . . . . . . . . . . . 9 2.2. The Extension Model . . . . . . . . . . . . . . . . . . . 10
2.2.1. Background . . . . . . . . . . . . . . . . . . . . . 9 2.2.1. Background . . . . . . . . . . . . . . . . . . . . . 10
2.2.2. Definition and Registration of Extensions . . . . . . 10 2.2.2. Definition and Registration of Extensions . . . . . . 11
2.2.3. Special Issues with Extensions . . . . . . . . . . . 11 2.2.3. Special Issues with Extensions . . . . . . . . . . . 12
2.3. SMTP Terminology . . . . . . . . . . . . . . . . . . . . 12 2.3. SMTP Terminology . . . . . . . . . . . . . . . . . . . . 12
2.3.1. Mail Objects . . . . . . . . . . . . . . . . . . . . 12 2.3.1. Mail Objects . . . . . . . . . . . . . . . . . . . . 12
2.3.2. Senders and Receivers . . . . . . . . . . . . . . . . 12 2.3.2. Senders and Receivers . . . . . . . . . . . . . . . . 13
2.3.3. Mail Agents and Message Stores . . . . . . . . . . . 13 2.3.3. Mail Agents and Message Stores . . . . . . . . . . . 13
2.3.4. Host . . . . . . . . . . . . . . . . . . . . . . . . 13 2.3.4. Host . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.5. Domain Names . . . . . . . . . . . . . . . . . . . . 13 2.3.5. Domain Names . . . . . . . . . . . . . . . . . . . . 14
2.3.6. Buffer and State Table . . . . . . . . . . . . . . . 14 2.3.6. Buffer and State Table . . . . . . . . . . . . . . . 15
2.3.7. Commands and Replies . . . . . . . . . . . . . . . . 14 2.3.7. Commands and Replies . . . . . . . . . . . . . . . . 15
2.3.8. Lines . . . . . . . . . . . . . . . . . . . . . . . . 15 2.3.8. Lines . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.9. Message Content and Mail Data . . . . . . . . . . . . 15 2.3.9. Message Content and Mail Data . . . . . . . . . . . . 16
2.3.10. Originator, Delivery, Relay, and Gateway Systems . . 15 2.3.10. Originator, Delivery, Relay, and Gateway Systems . . 16
2.3.11. Mailbox and Address . . . . . . . . . . . . . . . . . 16 2.3.11. Mailbox and Address . . . . . . . . . . . . . . . . . 16
2.4. General Syntax Principles and Transaction Model . . . . . 16 2.4. General Syntax Principles and Transaction Model . . . . . 17
3. The SMTP Procedures: An Overview . . . . . . . . . . . . . . 18 3. The SMTP Procedures: An Overview . . . . . . . . . . . . . . 18
3.1. Session Initiation . . . . . . . . . . . . . . . . . . . 18 3.1. Session Initiation . . . . . . . . . . . . . . . . . . . 19
3.2. Client Initiation . . . . . . . . . . . . . . . . . . . . 19 3.2. Client Initiation . . . . . . . . . . . . . . . . . . . . 19
3.3. Mail Transactions . . . . . . . . . . . . . . . . . . . . 19 3.3. Mail Transactions . . . . . . . . . . . . . . . . . . . . 20
3.4. Forwarding for Address Correction or Updating . . . . . . 22 3.4. Forwarding for Address Correction or Updating . . . . . . 22
3.5. Commands for Debugging Addresses . . . . . . . . . . . . 23 3.5. Commands for Debugging Addresses . . . . . . . . . . . . 23
3.5.1. Overview . . . . . . . . . . . . . . . . . . . . . . 23 3.5.1. Overview . . . . . . . . . . . . . . . . . . . . . . 23
3.5.2. VRFY Normal Response . . . . . . . . . . . . . . . . 25 3.5.2. VRFY Normal Response . . . . . . . . . . . . . . . . 25
3.5.3. Meaning of VRFY or EXPN Success Response . . . . . . 26 3.5.3. Meaning of VRFY or EXPN Success Response . . . . . . 26
3.5.4. Semantics and Applications of EXPN . . . . . . . . . 26 3.5.4. Semantics and Applications of EXPN . . . . . . . . . 27
3.6. Relaying and Mail Routing . . . . . . . . . . . . . . . . 26 3.6. Relaying and Mail Routing . . . . . . . . . . . . . . . . 27
3.6.1. Source Routes and Relaying . . . . . . . . . . . . . 26 3.6.1. Source Routes and Relaying . . . . . . . . . . . . . 27
3.6.2. Mail eXchange Records and Relaying . . . . . . . . . 27 3.6.2. Mail eXchange Records and Relaying . . . . . . . . . 27
3.6.3. Message Submission Servers as Relays . . . . . . . . 28 3.6.3. Message Submission Servers as Relays . . . . . . . . 28
3.7. Mail Gatewaying . . . . . . . . . . . . . . . . . . . . . 29 3.7. Mail Gatewaying . . . . . . . . . . . . . . . . . . . . . 29
3.7.1. Header Fields in Gatewaying . . . . . . . . . . . . . 29 3.7.1. Header Fields in Gatewaying . . . . . . . . . . . . . 29
3.7.2. Received Lines in Gatewaying . . . . . . . . . . . . 29 3.7.2. Received Lines in Gatewaying . . . . . . . . . . . . 30
3.7.3. Addresses in Gatewaying . . . . . . . . . . . . . . . 30 3.7.3. Addresses in Gatewaying . . . . . . . . . . . . . . . 30
3.7.4. Other Header Fields in Gatewaying . . . . . . . . . . 30 3.7.4. Other Header Fields in Gatewaying . . . . . . . . . . 30
3.7.5. Envelopes in Gatewaying . . . . . . . . . . . . . . . 30 3.7.5. Envelopes in Gatewaying . . . . . . . . . . . . . . . 31
3.8. Terminating Sessions and Connections . . . . . . . . . . 30 3.8. Terminating Sessions and Connections . . . . . . . . . . 31
3.9. Mailing Lists and Aliases . . . . . . . . . . . . . . . . 31 3.9. Mailing Lists and Aliases . . . . . . . . . . . . . . . . 32
3.9.1. Alias . . . . . . . . . . . . . . . . . . . . . . . . 32 3.9.1. Alias . . . . . . . . . . . . . . . . . . . . . . . . 32
3.9.2. List . . . . . . . . . . . . . . . . . . . . . . . . 32 3.9.2. List . . . . . . . . . . . . . . . . . . . . . . . . 32
4. The SMTP Specifications . . . . . . . . . . . . . . . . . . . 32 4. The SMTP Specifications . . . . . . . . . . . . . . . . . . . 33
4.1. SMTP Commands . . . . . . . . . . . . . . . . . . . . . . 32 4.1. SMTP Commands . . . . . . . . . . . . . . . . . . . . . . 33
4.1.1. Command Semantics and Syntax . . . . . . . . . . . . 32 4.1.1. Command Semantics and Syntax . . . . . . . . . . . . 33
4.1.2. Command Argument Syntax . . . . . . . . . . . . . . . 41 4.1.2. Command Argument Syntax . . . . . . . . . . . . . . . 41
4.1.3. Address Literals . . . . . . . . . . . . . . . . . . 43 4.1.3. Address Literals . . . . . . . . . . . . . . . . . . 44
4.1.4. Order of Commands . . . . . . . . . . . . . . . . . . 45 4.1.4. Order of Commands . . . . . . . . . . . . . . . . . . 45
4.1.5. Private-Use Commands . . . . . . . . . . . . . . . . 46 4.1.5. Private-Use Commands . . . . . . . . . . . . . . . . 47
4.2. SMTP Replies . . . . . . . . . . . . . . . . . . . . . . 47 4.2. SMTP Replies . . . . . . . . . . . . . . . . . . . . . . 47
4.2.1. Reply Code Severities and Theory . . . . . . . . . . 48 4.2.1. Reply Code Severities and Theory . . . . . . . . . . 49
4.2.2. Reply Codes by Function Groups . . . . . . . . . . . 51 4.2.2. Reply Codes by Function Groups . . . . . . . . . . . 51
4.2.3. Reply Codes in Numeric Order . . . . . . . . . . . . 52 4.2.3. Reply Codes in Numeric Order . . . . . . . . . . . . 53
4.2.4. Some specific code situations and relationships . . . 54 4.2.4. Some specific code situations and relationships . . . 54
4.3. Sequencing of Commands and Replies . . . . . . . . . . . 55 4.3. Sequencing of Commands and Replies . . . . . . . . . . . 56
4.3.1. Sequencing Overview . . . . . . . . . . . . . . . . . 55 4.3.1. Sequencing Overview . . . . . . . . . . . . . . . . . 56
4.3.2. Command-Reply Sequences . . . . . . . . . . . . . . . 56 4.3.2. Command-Reply Sequences . . . . . . . . . . . . . . . 57
4.4. Trace Information . . . . . . . . . . . . . . . . . . . . 58 4.4. Trace Information . . . . . . . . . . . . . . . . . . . . 59
4.5. Additional Implementation Issues . . . . . . . . . . . . 62 4.5. Additional Implementation Issues . . . . . . . . . . . . 63
4.5.1. Minimum Implementation . . . . . . . . . . . . . . . 62 4.5.1. Minimum Implementation . . . . . . . . . . . . . . . 63
4.5.2. Transparency . . . . . . . . . . . . . . . . . . . . 63 4.5.2. Transparency . . . . . . . . . . . . . . . . . . . . 64
4.5.3. Sizes and Timeouts . . . . . . . . . . . . . . . . . 64 4.5.3. Sizes and Timeouts . . . . . . . . . . . . . . . . . 64
4.5.4. Retry Strategies . . . . . . . . . . . . . . . . . . 68 4.5.4. Retry Strategies . . . . . . . . . . . . . . . . . . 68
4.5.5. Messages with a Null Reverse-Path . . . . . . . . . . 70 4.5.5. Messages with a Null Reverse-Path . . . . . . . . . . 70
5. Address Resolution and Mail Handling . . . . . . . . . . . . 70 5. Address Resolution and Mail Handling . . . . . . . . . . . . 71
5.1. Locating the Target Host . . . . . . . . . . . . . . . . 71 5.1. Locating the Target Host . . . . . . . . . . . . . . . . 71
5.2. IPv6 and MX Records . . . . . . . . . . . . . . . . . . . 73 5.2. IPv6 and MX Records . . . . . . . . . . . . . . . . . . . 73
6. Problem Detection and Handling . . . . . . . . . . . . . . . 73 6. Problem Detection and Handling . . . . . . . . . . . . . . . 74
6.1. Reliable Delivery and Replies by Email . . . . . . . . . 73 6.1. Reliable Delivery and Replies by Email . . . . . . . . . 74
6.2. Unwanted, Unsolicited, and "Attack" Messages . . . . . . 74 6.2. Unwanted, Unsolicited, and "Attack" Messages . . . . . . 75
6.3. Loop Detection . . . . . . . . . . . . . . . . . . . . . 75 6.3. Loop Detection . . . . . . . . . . . . . . . . . . . . . 76
6.4. Compensating for Irregularities . . . . . . . . . . . . . 75 6.4. Compensating for Irregularities . . . . . . . . . . . . . 76
7. Security Considerations . . . . . . . . . . . . . . . . . . . 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 77
7.1. Mail Security and Spoofing . . . . . . . . . . . . . . . 77 7.1. Mail Security and Spoofing . . . . . . . . . . . . . . . 77
7.2. "Blind" Copies . . . . . . . . . . . . . . . . . . . . . 78 7.2. "Blind" Copies . . . . . . . . . . . . . . . . . . . . . 78
7.3. VRFY, EXPN, and Security . . . . . . . . . . . . . . . . 78 7.3. VRFY, EXPN, and Security . . . . . . . . . . . . . . . . 79
7.4. Mail Rerouting Based on the 251 and 551 Response 7.4. Mail Rerouting Based on the 251 and 551 Response
Codes . . . . . . . . . . . . . . . . . . . . . . . . . . 79 Codes . . . . . . . . . . . . . . . . . . . . . . . . . . 80
7.5. Information Disclosure in Announcements . . . . . . . . . 79 7.5. Information Disclosure in Announcements . . . . . . . . . 80
7.6. Information Disclosure in Trace Fields . . . . . . . . . 80 7.6. Information Disclosure in Trace Fields . . . . . . . . . 80
7.7. Information Disclosure in Message Forwarding . . . . . . 80 7.7. Information Disclosure in Message Forwarding . . . . . . 80
7.8. Resistance to Attacks . . . . . . . . . . . . . . . . . . 80 7.8. Resistance to Attacks . . . . . . . . . . . . . . . . . . 81
7.9. Scope of Operation of SMTP Servers . . . . . . . . . . . 80 7.9. Scope of Operation of SMTP Servers . . . . . . . . . . . 81
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 81
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 82 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 83
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 83
10.1. Normative References . . . . . . . . . . . . . . . . . . 82 10.1. Normative References . . . . . . . . . . . . . . . . . . 83
10.2. Informative References . . . . . . . . . . . . . . . . . 84 10.2. Informative References . . . . . . . . . . . . . . . . . 84
Appendix A. TCP Transport Service . . . . . . . . . . . . . . . 88 Appendix A. TCP Transport Service . . . . . . . . . . . . . . . 89
Appendix B. Generating SMTP Commands from RFC 822 Header Fields 88 Appendix B. Generating SMTP Commands from RFC 822 Header Fields 89
Appendix C. Source Routes . . . . . . . . . . . . . . . . . . . 89 Appendix C. Source Routes . . . . . . . . . . . . . . . . . . . 90
Appendix D. Scenarios . . . . . . . . . . . . . . . . . . . . . 90 Appendix D. Scenarios . . . . . . . . . . . . . . . . . . . . . 91
D.1. A Typical SMTP Transaction Scenario . . . . . . . . . . . 90 D.1. A Typical SMTP Transaction Scenario . . . . . . . . . . . 91
D.2. Aborted SMTP Transaction Scenario . . . . . . . . . . . . 91 D.2. Aborted SMTP Transaction Scenario . . . . . . . . . . . . 92
D.3. Relayed Mail Scenario . . . . . . . . . . . . . . . . . . 92 D.3. Relayed Mail Scenario . . . . . . . . . . . . . . . . . . 93
D.4. Verifying and Sending Scenario . . . . . . . . . . . . . 93 D.4. Verifying and Sending Scenario . . . . . . . . . . . . . 94
Appendix E. Other Gateway Issues . . . . . . . . . . . . . . . . 94 Appendix E. Other Gateway Issues . . . . . . . . . . . . . . . . 95
Appendix F. Deprecated Features of RFC 821 . . . . . . . . . . . 94 Appendix F. Deprecated Features of RFC 821 . . . . . . . . . . . 95
F.1. TURN . . . . . . . . . . . . . . . . . . . . . . . . . . 94 F.1. TURN . . . . . . . . . . . . . . . . . . . . . . . . . . 95
F.2. Source Routing . . . . . . . . . . . . . . . . . . . . . 94 F.2. Source Routing . . . . . . . . . . . . . . . . . . . . . 95
F.3. HELO . . . . . . . . . . . . . . . . . . . . . . . . . . 95 F.3. HELO . . . . . . . . . . . . . . . . . . . . . . . . . . 96
F.4. #-literals . . . . . . . . . . . . . . . . . . . . . . . 95 F.4. #-literals . . . . . . . . . . . . . . . . . . . . . . . 96
F.5. Dates and Years . . . . . . . . . . . . . . . . . . . . . 95 F.5. Dates and Years . . . . . . . . . . . . . . . . . . . . . 96
F.6. Sending versus Mailing . . . . . . . . . . . . . . . . . 95 F.6. Sending versus Mailing . . . . . . . . . . . . . . . . . 96
Appendix G. Change log for RFC 5321bis . . . . . . . . . . . . . 96 Appendix G. Other Outstanding Issues . . . . . . . . . . . . . . 97
G.1. RFC 5321 Errata Summary . . . . . . . . . . . . . . . . . 96 G.1. IP Address Literals . . . . . . . . . . . . . . . . . . . 98
G.2. Changes from RFC 5321 (published October 2008) to the G.2. Repeated Use of EHLO . . . . . . . . . . . . . . . . . . 98
initial (-00) version of this draft . . . . . . . . . . . 97 G.3. Meaning of "MTA" and Related Terminology . . . . . . . . 98
G.3. Changes Among Versions of Rfc5321Bis . . . . . . . . . . 98 G.4. Originator, or Originating System, Authentication . . . . 98
G.3.1. Changes from draft-klensin-rfc5321bis-00 (posted G.5. Remove or deprecate the work-around from code 552 to 452 99
2012-12-02) to -01 . . . . . . . . . . . . . . . . . 98 G.6. Clarify where the protocol stands with respect to
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 submission and TLS issues . . . . . . . . . . . . . . . . 99
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 100 G.7. Probably-substantive Discussion Topics Identified in
Other Ways . . . . . . . . . . . . . . . . . . . . . . . 99
G.7.1. Issues with 521, 554, and 556 codes . . . . . . . . . 99
G.7.2. SMTP Model, terminology, and relationship to RFC 5598 99
G.7.3. Resolvable FQDNs and private domain names . . . . . . 99
G.7.4. Possible clarification about mail transactions and
transaction state . . . . . . . . . . . . . . . . . . 99
G.7.5. Issues with mailing lists, aliases, and forwarding . 99
G.7.6. Requirements for domain name and/or IP address in
EHLO . . . . . . . . . . . . . . . . . . . . . . . . 99
G.7.7. Does the 'first digit only' and/or non-listed reply
code text need clarification? . . . . . . . . . . . . 100
G.7.8. Size limits . . . . . . . . . . . . . . . . . . . . . 100
G.7.9. Discussion of 'blind' copies and RCPT . . . . . . . . 100
G.7.10. Further clarifications needed to source routes? . . . 100
Appendix H. Change log for RFC 5321bis . . . . . . . . . . . . . 100
H.1. RFC 5321 Errata Summary . . . . . . . . . . . . . . . . . 100
H.2. Changes from RFC 5321 (published October 2008) to the
initial (-00) version of this draft . . . . . . . . . . . 101
H.3. Changes Among Versions of Rfc5321bis . . . . . . . . . . 103
H.3.1. Changes from draft-klensin-rfc5321bis-00 (posted
2012-12-02) to -01 . . . . . . . . . . . . . . . . . 103
H.3.2. Changes from draft-klensin-rfc5321bis-01 (20191203)
to -02 . . . . . . . . . . . . . . . . . . . . . . . 103
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 105
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 45, line 12 skipping to change at page 45, line 27
[[CREF11: [5321bis](2821ter) 2821bis Last Call [[CREF11: [5321bis](2821ter) 2821bis Last Call
comment]] comment]]
4.1.4. Order of Commands 4.1.4. Order of Commands
There are restrictions on the order in which these commands may be There are restrictions on the order in which these commands may be
used. used.
A session that will contain mail transactions MUST first be A session that will contain mail transactions MUST first be
initialized by the use of the EHLO command. An SMTP server SHOULD initialized by the use of the EHLO command. An SMTP server SHOULD
accept commands for non-mail transactions (e.g., VRFY or EXPN) accept commands for non-mail transactions (e.g., VRFY, EXPN, or NOOP)
without this initialization. without this initialization.
An EHLO command MAY be issued by a client later in the session. If An EHLO command MAY be issued by a client later in the session. If
it is issued after the session begins and the EHLO command is it is issued after the session begins and the EHLO command is
acceptable to the SMTP server, the SMTP server MUST clear all buffers acceptable to the SMTP server, the SMTP server MUST clear all buffers
and reset the state exactly as if a RSET command had been issued. In and reset the state exactly as if a RSET command had been issued. In
other words, the sequence of RSET followed immediately by EHLO is other words, the sequence of RSET followed immediately by EHLO is
redundant, but not harmful other than in the performance cost of redundant, but not harmful other than in the performance cost of
executing unnecessary commands. executing unnecessary commands.
skipping to change at page 82, line 43 skipping to change at page 83, line 26
specification. specification.
The following filed errata against RFC 5321 that were not rejected at The following filed errata against RFC 5321 that were not rejected at
the time of submission: Jasen Betts, Adrien de Croy Guillaume Fortin- the time of submission: Jasen Betts, Adrien de Croy Guillaume Fortin-
Debigare Roberto Javier Godoy, David Romerstein, Dominic Sayers, Debigare Roberto Javier Godoy, David Romerstein, Dominic Sayers,
Rodrigo Speller, Alessandro Vesely, and Brett Watson. In addition, Rodrigo Speller, Alessandro Vesely, and Brett Watson. In addition,
specific suggestions that led to corrections and improvements in this specific suggestions that led to corrections and improvements in this
version were received from Ned Freed, Barry Leiba, Ivar Lumi, Pete version were received from Ned Freed, Barry Leiba, Ivar Lumi, Pete
Resnick, and others. Resnick, and others.
[[CREF26: Errata and comments after 2019-12-01 have not yet been
captured in this version of the draft. ]]
10. References 10. References
10.1. Normative References 10.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate [1] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[2] American National Standards Institute (formerly United [2] American National Standards Institute (formerly United
skipping to change at page 89, line 50 skipping to change at page 90, line 50
from the material in RFC 821 to prevent server actions that might from the material in RFC 821 to prevent server actions that might
confuse clients or subsequent servers that do not expect a full confuse clients or subsequent servers that do not expect a full
source route implementation. source route implementation.
Historically, for relay purposes, the forward-path may have been a Historically, for relay purposes, the forward-path may have been a
source route of the form "@ONE,@TWO:JOE@THREE", where ONE, TWO, and source route of the form "@ONE,@TWO:JOE@THREE", where ONE, TWO, and
THREE MUST be fully-qualified domain names. This form was used to THREE MUST be fully-qualified domain names. This form was used to
emphasize the distinction between an address and a route. The emphasize the distinction between an address and a route. The
mailbox (here, JOE@THREE) is an absolute address, and the route is mailbox (here, JOE@THREE) is an absolute address, and the route is
information about how to get there. The two concepts should not be information about how to get there. The two concepts should not be
confused.[[CREF26: [5321bis]JcK 20090123: Tightened this and the next confused.[[CREF27: [5321bis]JcK 20090123: Tightened this and the next
paragraph to be clear that this doesn't authorize source route use.]] paragraph to be clear that this doesn't authorize source route use.]]
If source routes are used contrary to requirements and If source routes are used contrary to requirements and
recommendations elsewhere in this specfiication, RFC 821 and the text recommendations elsewhere in this specfiication, RFC 821 and the text
below should be consulted for the mechanisms for constructing and below should be consulted for the mechanisms for constructing and
updating the forward-path. A server that is reached by means of a updating the forward-path. A server that is reached by means of a
source route (e.g., its domain name appears first in the list in the source route (e.g., its domain name appears first in the list in the
forward-path) MUST remove its domain name from any forward-paths in forward-path) MUST remove its domain name from any forward-paths in
which that domain name appears before forwarding the message and MAY which that domain name appears before forwarding the message and MAY
remove all other source routing information. The reverse-path SHOULD remove all other source routing information. The reverse-path SHOULD
NOT be updated by servers conforming to this specification. NOT be updated by servers conforming to this specification.
Notice that the forward-path and reverse-path appear in the SMTP Notice that the forward-path and reverse-path appear in the SMTP
commands and replies, but not necessarily in the message. That is, commands and replies, but not necessarily in the message. That is,
there is no need for these paths and especially this syntax to appear there is no need for these paths and especially this syntax to appear
in the "To:" , "From:", "CC:", etc. fields of the message header in the "To:" , "From:", "CC:", etc. fields of the message header
section. Conversely, SMTP servers MUST NOT derive final message section. Conversely, SMTP servers MUST NOT derive final message
routing information from message header fields. routing information from message header fields.
When the list of hosts is present despite the recommendations and When the list of hosts is present despite the recommendations and
requirements [[CREF27: [5321bis]JcK 20090123 "and requrements" requirements [[CREF28: [5321bis]JcK 20090123 "and requrements"
added]] above, it is a "reverse" source route and indicates that the added]] above, it is a "reverse" source route and indicates that the
mail was relayed through each host on the list (the first host in the mail was relayed through each host on the list (the first host in the
list was the most recent relay). This list is used as a source route list was the most recent relay). This list is used as a source route
to return non-delivery notices to the sender. If, contrary to the to return non-delivery notices to the sender. If, contrary to the
recommendations here, a relay host adds itself to the beginning of recommendations here, a relay host adds itself to the beginning of
the list, it MUST use its name as known in the transport environment the list, it MUST use its name as known in the transport environment
to which it is relaying the mail rather than that of the transport to which it is relaying the mail rather than that of the transport
environment from which the mail came (if they are different). Note environment from which the mail came (if they are different). Note
that a situation could easily arise in which some relay hosts add that a situation could easily arise in which some relay hosts add
their names to the reverse source route and others do not, generating their names to the reverse source route and others do not, generating
skipping to change at page 92, line 18 skipping to change at page 93, line 18
The source host performs a DNS lookup on XYZ.COM (the destination The source host performs a DNS lookup on XYZ.COM (the destination
address) and finds DNS MX records specifying xyz.com as the best address) and finds DNS MX records specifying xyz.com as the best
preference and foo.com as a lower preference. It attempts to open a preference and foo.com as a lower preference. It attempts to open a
connection to xyz.com and fails. It then opens a connection to connection to xyz.com and fails. It then opens a connection to
foo.com, with the following dialogue: foo.com, with the following dialogue:
S: 220 foo.com Simple Mail Transfer Service Ready S: 220 foo.com Simple Mail Transfer Service Ready
C: EHLO bar.com C: EHLO bar.com
S: 250-foo.com greets bar.com S: 250-foo.com greets bar.com
S: 250-8BITMIME S: 250-8BITMIME
S: 250-SIZE S: 250-SIZE
S: 250-DSN S: 250-DSN
S: 250 HELP S: 250 HELP
C: MAIL FROM:<JQP@bar.com> C: MAIL FROM:<JQP@bar.com>
S: 250 OK S: 250 OK
C: RCPT TO:<Jones@XYZ.COM> C: RCPT TO:<Jones@XYZ.COM>
S: 250 OK S: 250 OK
C: DATA C: DATA
S: 354 Start mail input; end with <CRLF>.<CRLF> S: 354 Start mail input; end with <CRLF>.<CRLF>
C: Date: Thu, 21 May 1998 05:33:29 -0700 C: Date: Thu, 21 May 1998 05:33:29 -0700
C: From: John Q. Public <JQP@bar.com> C: From: John Q. Public <JQP@bar.com>
C: Subject: The Next Meeting of the Board C: Subject: The Next Meeting of the Board
C: To: Jones@xyz.com C: To: Jones@xyz.com
skipping to change at page 94, line 28 skipping to change at page 95, line 28
Appendix F. Deprecated Features of RFC 821 Appendix F. Deprecated Features of RFC 821
A few features of RFC 821 have proven to be problematic and SHOULD A few features of RFC 821 have proven to be problematic and SHOULD
NOT be used in Internet mail. Some of these features were deprecated NOT be used in Internet mail. Some of these features were deprecated
in RFC 2821 in 2001; source routing and two-digit years in dates were in RFC 2821 in 2001; source routing and two-digit years in dates were
deprecated by RFC 1123 in 1989. Of the domain literal forms, RFC deprecated by RFC 1123 in 1989. Of the domain literal forms, RFC
1123 required support only for the dotted decimal form. With the 1123 required support only for the dotted decimal form. With the
possible exception of old, hardware-embedded, applications, there is possible exception of old, hardware-embedded, applications, there is
no longer any excuse for these features to appear on the contemporary no longer any excuse for these features to appear on the contemporary
Internet. [[CREF28: [5321bis] (2821ter) 2821bis Last Call Comment]] Internet. [[CREF29: [5321bis] (2821ter) 2821bis Last Call Comment]]
F.1. TURN F.1. TURN
This command, described in RFC 821, raises important security issues This command, described in RFC 821, raises important security issues
since, in the absence of strong authentication of the host requesting since, in the absence of strong authentication of the host requesting
that the client and server switch roles, it can easily be used to that the client and server switch roles, it can easily be used to
divert mail from its correct destination. Its use is deprecated; divert mail from its correct destination. Its use is deprecated;
SMTP systems SHOULD NOT use it unless the server can authenticate the SMTP systems SHOULD NOT use it unless the server can authenticate the
client. client.
skipping to change at page 96, line 7 skipping to change at page 97, line 7
workstation technology and the introduction of other protocols may workstation technology and the introduction of other protocols may
have rendered them obsolete even where they are implemented. have rendered them obsolete even where they are implemented.
[[5321bis Editor's Note: does this need a stronger reference to 821, [[5321bis Editor's Note: does this need a stronger reference to 821,
2821, and/or 5321?]] 2821, and/or 5321?]]
Clients SHOULD NOT provide SEND, SAML, or SOML as services. Servers Clients SHOULD NOT provide SEND, SAML, or SOML as services. Servers
MAY implement them. If they are implemented by servers, the MAY implement them. If they are implemented by servers, the
implementation model specified in RFC 821 MUST be used and the implementation model specified in RFC 821 MUST be used and the
command names MUST be published in the response to the EHLO command. command names MUST be published in the response to the EHLO command.
Appendix G. Change log for RFC 5321bis Appendix G. Other Outstanding Issues
[[RFC Editor: Please remove this section before publication.]] [[RFC Editor: Please remove this section before publication.]]
G.1. RFC 5321 Errata Summary In December 2019, an issue was raised on the ietf-smtp@ietf.org list
that led to a broad discussion of ways in which existing practice had
diverged from the specifications and recommendations of RFC 5321 in
the more than eleven years since it was published (some of those
issues probably affect the boundary between RFC 5321 and 5322 and
hence the latter as well). In most cases, those divergences call for
revision of the Technical Specification to match the practice,
clarification of the specification text in other ways, or a more
comprehensive explanation of why the practices recommended by the
specification should really be followed.
Those discussions raised two other issues, which were that
o The publication of the Submission Server specification of RFC 6409
in November 2011 may not have been fully reflected in RFC 5321
(despite the even earlier publication of RFC 4409) and
o There may be inconsistencies between the July 2009 Internet Mail
Architecture description of RFC 5598 and the model described in
RFC 5321. The issue called out in Appendix G.3 below may be an
example of one of those inconsistencies.
Those discrepancies should be identified and discussed and decisions
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
to very rough consensus, that any revision of RFC 5321 and/or 5322
should be accompanied by a separate Applicability Statement document
that would make recommendations about applicability or best practices
in particular areas rather than trying to get everything into the two
technical specifications. This appendix does not attempt to identify
which issues should get which treatment.
Until and unless there is a WG with appropriate leadership and
tracking mechanisms, this appendix will act as a temporary record of
issues that should be discussed and decided upon before a revised
SMTP specification (or a related Applicability Statement) is
published, issues that have not been reflected in errata (see
Appendix H.1 below for those covered by errata).
G.1. IP Address Literals
The specification is unclear about whether IP address literals,
particularly IP address literals used as arguments to the EHLO
command, are required to be accepted or whether they are allowed to
be rejected as part of the general "operational necessity" exception.
Some have suggested that rejection of them is so common as an anti-
spam measure that the use of such literals should be deprecated
entirely in the specification, others that the are still useful and
used and/or that, whatever is said about IP address literals within
an SMTP session (e.g., in MAIL or RCPT commands), they should
continue to be allowed (and required) in EHLO.
G.2. Repeated Use of EHLO
While the specification says that an SMTP client's sending EHLO again
after it has been issued (starting an SMTP session and treats it as
if RSET had been sent (closing the session) followed by EHLO, there
are apparently applications, at least some of them involving setting
up of secure connections, in which the second EHLO is required and
does not imply RSET. Does the specification need to be adjusted to
reflect or call out those cases?
G.3. Meaning of "MTA" and Related Terminology
A terminology issue has come up about what the term "MTA" actually
refers to, a question that became at least slightly more complicated
when we formalized RFC 6409 Submission Servers. Does the document
need to be adjusted to be more clear about this topic? Note that the
answer may interact with the question asked in Section 2 above.
Possibly along the same lines, RFC 2821 changed the RFC 821
terminology from "sender-SMTP" and "receiver-SMTP" to "SMTP client"
and "SMTP server" respectively. As things have evolved, it is
possible that newer terminology is a source of confusion and that the
terminology should be changed back, something that also needs
discussion.
G.4. Originator, or Originating System, Authentication
Should RFC 5321bis address authentication and related issues or
should Section 3.9 or other text be reshaped (in addition to or
instead of the comment on that section) to lay a better foundation
for such work, either in the context of mailing lists or more
generally?
G.5. Remove or deprecate the work-around from code 552 to 452
The suggestion in Section 4.5.3.1.10 may have outlived its usefulness
and/or be inconsistent with current practice. Should it be removed
and/or explicitly deprecated?
G.6. Clarify where the protocol stands with respect to submission and
TLS issues
1. submission on port 587
2. submission on port 465
3. TLS relay on a port different from 25 (whenever)
G.7. Probably-substantive Discussion Topics Identified in Other Ways
The following issues were identified as a group in the opening Note
but called out specifically only in embedded CREF comments in earlier
(-00 and -01) versions of this draft.
G.7.1. Issues with 521, 554, and 556 codes
See new Section 4.2.4.2.
G.7.2. SMTP Model, terminology, and relationship to RFC 5598
CREF comment in Section 2 and also CREF comment in Section 2.3.10
G.7.3. Resolvable FQDNs and private domain names
Multiple CREF comments in Section 2.3.5
G.7.4. Possible clarification about mail transactions and transaction
state
CREF comment in Section 3.3 and also reference in Section 4.1.4
G.7.5. Issues with mailing lists, aliases, and forwarding
CREF comment in Section 3.9. May also want to note forwarding as an
email address portability issue.
G.7.6. Requirements for domain name and/or IP address in EHLO
CREF comment in Section 4.1.4
G.7.7. Does the 'first digit only' and/or non-listed reply code text
need clarification?
CREF comments in Section 4.2 and Section 4.3.1
G.7.8. Size limits
CREF comment in Section 4.5.3
G.7.9. Discussion of 'blind' copies and RCPT
CREF comment in Section 7.2. May alto need to discussion whether
that terminology is politically incorrect and suggest a replacement.
G.7.10. Further clarifications needed to source routes?
CREF comment in Appendix C
Appendix H. Change log for RFC 5321bis
[[RFC Editor: Please remove this section before publication.]]
H.1. RFC 5321 Errata Summary
This document addresses the following errata filed against RFC 5321 This document addresses the following errata filed against RFC 5321
since its publication in October 2008 [52]. [[CREF29: [[Note in since its publication in October 2008 [52] [[CREF30: [[Note in Draft:
Draft: Items with comments below have not yet been resolved.]]]] Items with comments below have not yet been resolved.]]]]
1683 ABNF error. Section 4.4 1683 ABNF error. Section 4.4
4198 Description error. Section 4.2 4198 Description error. Section 4.2
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
4315 ABNF - IPv6 Section 4.1.3. [[CREF30: [5321bis]The IPv6 syntax 4315 ABNF - IPv6 Section 4.1.3. [[CREF31: [5321bis]The IPv6 syntax
has been adjusted since 5321 was published. See the rewritten has been adjusted since 5321 was published. See the rewritten
form and the comment in the section cited in the previous form and the comment in the section cited in the previous
sentence. The editor awaits instructions. See https://www.rfc- sentence. The editor awaits instructions. See https://www.rfc-
editor.org/errata/eid4315]] editor.org/errata/eid4315]]
5414 ABNF for Quoted-string Section 4.1.2 5414 ABNF for Quoted-string Section 4.1.2
1851 Location of text on unexpected close Section 4.1.1.5. 1851 Location of text on unexpected close Section 4.1.1.5.
[[CREF31: [5321bis]Matter of taste, editor seeks advice.]] [[CREF32: [5321bis]Matter of taste, editor seeks advice.]]
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. [[CREF32: [5321bis]As confusion in some sections Section 4.4. [[CREF33: [5321bis]As
Barry notes in his verifier comments on the erratum (see Barry notes in his verifier comments on the erratum (see
https://www.rfc-editor.org/errata/eid3447), the comments and https://www.rfc-editor.org/errata/eid3447), the comments and
suggestions here raise a number of interesting (and difficult) suggestions here raise a number of interesting (and difficult)
issues. One of the issues is that the core of RFCs 5321 (and issues. One of the issues is that the core of RFCs 5321 (and
2821) is text carried over from Jon Postel's RFC 821, a document 2821) is text carried over from Jon Postel's RFC 821, a document
that was not only written in a different style than the IETF uses that was not only written in a different style than the IETF uses
today but that was written at a time when no one had dreamt of RFC today but that was written at a time when no one had dreamt of RFC
2119 or even the IETF itself. It appears to me that trying to 2119 or even the IETF itself. It appears to me that trying to
patch that style might easily result in a document that is harder patch that style might easily result in a document that is harder
to read as well as being error prone. If we want to get the to read as well as being error prone. If we want to get the
document entirely into contemporary style, we really should bite document entirely into contemporary style, we really should bite
the bullet and do a complete rewrite. To respond to a different the bullet and do a complete rewrite. To respond to a different
point in Barry's discussion, I think an explicit statement that point in Barry's discussion, I think an explicit statement that
5321/5322 and their predecessors differ in places and why would be 5321/5322 and their predecessors differ in places and why would be
helpful. Text, and suggestions about where to put it, are helpful. Text, and suggestions about where to put it, are
solicited. A list of differences might be a good idea too, but solicited. A list of differences might be a good idea too, but
getting it right might be more work than there is available energy getting it right might be more work than there is available energy
to do correctly. ]] to do correctly. ]]
5711 Missing leading spaces in example Appendix D.3. [[CREF33: 5711 Missing leading spaces in example Appendix D.3. [[CREF34:
[5321bis]Well, this is interesting because the XML is correct and [5321bis]Well, this is interesting because the XML is correct and
the spaces are there, embedded in artwork. So either the XML2RFC the spaces are there, embedded in artwork. So either the XML2RFC
processor at the time took those leading spaces out or the RFC processor at the time took those leading spaces out or the RFC
Editor improved on the document and the change was not caught in Editor improved on the document and the change was not caught in
AUTH48, perhaps because rfcdiff ignores white space. We just need AUTH48, perhaps because rfcdiff ignores white space. We just need
to watch for future iterations. ]] to watch for future iterations. ]]
[[CREF34: [5321bis]Note that rejected errata have _not_ been reviewed [[CREF35: [5321bis]Note that rejected errata have _not_ been reviewed
to see if they contain anything useful that should be discussed again to see if they contain anything useful that should be discussed again
with the possibility of rethinking and changing text. Volunteers with the possibility of rethinking and changing text. Volunteers
sought.]] sought.]]
G.2. Changes from RFC 5321 (published October 2008) to the initial H.2. Changes from RFC 5321 (published October 2008) to the initial
(-00) version of this draft (-00) version of this draft
o Acknowledgments section (Section 9) trimmed back for new document. o Acknowledgments section (Section 9) trimmed back for new document.
o Introductory paragraph to Appendix F extended to make it clear o Introductory paragraph to Appendix F extended to make it clear
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, o 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.
skipping to change at page 98, line 34 skipping to change at page 103, line 5
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 o 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 o Temporarily added a "Note on Reading This Working Draft" after the
Abstract. Abstract.
G.3. Changes Among Versions of Rfc5321Bis H.3. Changes Among Versions of Rfc5321bis
G.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
o Minor clarifications to improve text, e.g., addition of NOOP to
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
"dogfood" discussion during December 2019 and an index listing of
substantive issues identified only in CREFs in the prior draft as
a new Appendix G..
Index Index
A A
Argument Syntax Argument Syntax
A-d-l 41 A-d-l 42
Additional-Registered-Clauses 62 Additional-Registered-Clauses 62
address-literal 42 address-literal 42
Addtl-Link 62 Addtl-Link 63
Addtl-Protocol 62 Addtl-Protocol 63
Argument 42 Argument 42
At-domain 41 At-domain 42
Atom 42 Atom 42
By-domain 61 By-domain 62
dcontent 44 dcontent 44
Domain 42 Domain 42
Dot-string 42 Dot-string 42
esmtp-keyword 41 esmtp-keyword 42
esmtp-param 41 esmtp-param 42
esmtp-value 42 esmtp-value 42
Extended-Domain 61 Extended-Domain 62
For 62 For 62
Forward-Path 41 Forward-Path 41
From-domain 61 From-domain 62
General-address-literal 44 General-address-literal 44
Greeting 47 Greeting 48
h16 44 h16 45
ID 62 ID 62
IPv4-address-literal 44 IPv4-address-literal 44
IPv6-addr 44 IPv6-addr 45
IPv6-address-literal 44 IPv6-address-literal 44
Keyword 42 Keyword 42
Ldh-str 42 Ldh-str 42
Let-dig 42 Let-dig 42
Link 62 Link 62
Local-part 42 Local-part 42
ls32 44 ls32 45
Mail-parameters 41 Mail-parameters 42
Mailbox 42 Mailbox 42
Opt-info 62 Opt-info 62
Path 41 Path 41
Protocol 62 Protocol 63
QcontentSMTP 42 QcontentSMTP 43
qtextSMTP 42 qtextSMTP 43
quoted-pairSMTP 42 quoted-pairSMTP 43
Quoted-string 42 Quoted-string 43
Rcpt-parameters 41 Rcpt-parameters 42
Reply-code 47 Reply-code 48
Reply-line 47 Reply-line 48
Return-path-line 61 Return-path-line 61
Reverse-Path 41 Reverse-Path 41
Snum 44 Snum 44
Stamp 61 Stamp 62
Standardized-tag 44 Standardized-tag 44
String 42 String 43
sub-domain 42 sub-domain 42
TCP-info 62 TCP-info 62
textstring 47 textstring 48
Time-stamp-line 61 Time-stamp-line 62
Via 62 Via 62
With 62 With 62
C C
Command Syntax Command Syntax
data 38 data 38
expn 39 expn 40
help 40 help 40
mail 35 mail 36
noop 40 noop 40
quit 40 quit 41
rcpt 37 rcpt 37
rset 39 rset 39
vrfy 39 vrfy 39
Author's Address Author's Address
John C. Klensin John C. Klensin
1770 Massachusetts Ave, Suite 322 1770 Massachusetts Ave, Suite 322
Cambridge, MA 02140 Cambridge, MA 02140
USA USA
 End of changes. 66 change blocks. 
129 lines changed or deleted 324 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/