< draft-ietf-emailcore-rfc5321bis-07.txt   draft-ietf-emailcore-rfc5321bis-08.txt >
EMAILCORE J. Klensin EMAILCORE J. Klensin
Internet-Draft 4 December 2021 Internet-Draft 31 December 2021
Obsoletes: 5321, 1846, 7504, 7505 (if approved) Obsoletes: 5321, 1846, 7504, 7505 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: 7 June 2022 Expires: 4 July 2022
Simple Mail Transfer Protocol Simple Mail Transfer Protocol
draft-ietf-emailcore-rfc5321bis-07 draft-ietf-emailcore-rfc5321bis-08
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 (including text carried forward from
several previous documents, making all or parts of most of them RFC 5321) consolidates, updates, and clarifies several previous
obsolete. It covers the SMTP extension mechanisms and best practices documents, making all or parts of most of them obsolete. It covers
for the contemporary Internet, but does not provide details about the SMTP extension mechanisms and best practices for the contemporary
particular extensions. The document also provides information about Internet, but does not provide details about particular extensions.
use of SMTP for other than strict mail transport and delivery. This The document also provides information about use of SMTP for other
document replaces RFC 5321, the earlier version with the same title. than strict mail transport and delivery. This document replaces RFC
5321, the earlier version with the same title.
// JcK 20211029 Note in Draft: Adjusted in version -06. Decided the // JcK 20211029 Note in Draft: Adjusted in version -06. Decided the
// details belong in either the Introduction or the A/S, not the // details belong in either the Introduction or the A/S, not the
// Abstract. And it makes the Abstract a tad shorter, which is good. // Abstract. And it makes the Abstract a tad shorter, which is good.
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.
skipping to change at page 2, line 15 skipping to change at page 2, line 20
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 7 June 2022. This Internet-Draft will expire on 4 July 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 39 skipping to change at page 2, line 44
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7
1.1. Transport of Electronic Mail . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . 9 1.3. Document Conventions . . . . . . . . . . . . . . . . . . 9
2. The SMTP Model . . . . . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . 12
2.2.1. Background . . . . . . . . . . . . . . . . . . . . . 12 2.2.1. Background . . . . . . . . . . . . . . . . . . . . . 12
2.2.2. Definition and Registration of Extensions . . . . . . 13 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 . . . . . . . . . . . . . . . . . . . . 14 2.3. SMTP Terminology . . . . . . . . . . . . . . . . . . . . 14
2.3.1. Mail Objects . . . . . . . . . . . . . . . . . . . . 14 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 . . . . . . . . . . . 15 2.3.3. Mail Agents and Message Stores . . . . . . . . . . . 15
2.3.4. Host . . . . . . . . . . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . 17
2.3.8. Lines . . . . . . . . . . . . . . . . . . . . . . . . 17 2.3.8. Lines . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.9. Message Content and Mail Data . . . . . . . . . . . . 17 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 . . 18
2.3.11. Mailbox and Address . . . . . . . . . . . . . . . . . 18 2.3.11. Mailbox and Address . . . . . . . . . . . . . . . . . 18
2.4. General Syntax Principles and Transaction Model . . . . . 18 2.4. General Syntax Principles and Transaction Model . . . . . 19
3. The SMTP Procedures: An Overview . . . . . . . . . . . . . . 20 3. The SMTP Procedures: An Overview . . . . . . . . . . . . . . 20
3.1. Session Initiation . . . . . . . . . . . . . . . . . . . 20 3.1. Session Initiation . . . . . . . . . . . . . . . . . . . 20
3.2. Client Initiation . . . . . . . . . . . . . . . . . . . . 21 3.2. Client Initiation . . . . . . . . . . . . . . . . . . . . 21
3.3. Mail Transactions . . . . . . . . . . . . . . . . . . . . 21 3.3. Mail Transactions . . . . . . . . . . . . . . . . . . . . 22
3.4. Forwarding for Address Correction or Updating . . . . . . 24 3.4. Address Modification and Expansion . . . . . . . . . . . 24
3.5. Commands for Debugging Addresses . . . . . . . . . . . . 25 3.4.1. Forwarding for Address Correction or Updating . . . . 24
3.5.1. Overview . . . . . . . . . . . . . . . . . . . . . . 25 3.4.2. Aliases and Mailing Lists . . . . . . . . . . . . . . 25
3.5.2. VRFY Normal Response . . . . . . . . . . . . . . . . 27 3.4.2.1. Simple Aliases . . . . . . . . . . . . . . . . . 26
3.5.3. Meaning of VRFY or EXPN Success Response . . . . . . 28 3.4.2.2. Mailing Lists . . . . . . . . . . . . . . . . . . 26
3.5.4. Semantics and Applications of EXPN . . . . . . . . . 28 3.5. Commands for Debugging Addresses . . . . . . . . . . . . 27
3.6. Relaying and Mail Routing . . . . . . . . . . . . . . . . 29 3.5.1. Overview . . . . . . . . . . . . . . . . . . . . . . 27
3.6.1. Mail eXchange Records and Relaying . . . . . . . . . 29 3.5.2. VRFY Normal Response . . . . . . . . . . . . . . . . 29
3.6.2. Message Submission Servers as Relays . . . . . . . . 29 3.5.3. Meaning of VRFY or EXPN Success Response . . . . . . 30
3.7. Mail Gatewaying . . . . . . . . . . . . . . . . . . . . . 30 3.5.4. Semantics and Applications of EXPN . . . . . . . . . 30
3.7.1. Header Fields in Gatewaying . . . . . . . . . . . . . 31 3.6. Relaying and Mail Routing . . . . . . . . . . . . . . . . 30
3.7.2. Received Lines in Gatewaying . . . . . . . . . . . . 31 3.6.1. Mail eXchange Records and Relaying . . . . . . . . . 31
3.7.3. Addresses in Gatewaying . . . . . . . . . . . . . . . 31 3.6.2. Message Submission Servers as Relays . . . . . . . . 31
3.7.4. Other Header Fields in Gatewaying . . . . . . . . . . 32 3.7. Mail Gatewaying . . . . . . . . . . . . . . . . . . . . . 32
3.7.5. Envelopes in Gatewaying . . . . . . . . . . . . . . . 32 3.7.1. Header Fields in Gatewaying . . . . . . . . . . . . . 32
3.8. Terminating Sessions and Connections . . . . . . . . . . 32 3.7.2. Received Lines in Gatewaying . . . . . . . . . . . . 33
3.9. Aliases and Mailing Lists . . . . . . . . . . . . . . . . 33 3.7.3. Addresses in Gatewaying . . . . . . . . . . . . . . . 33
3.9.1. Simple Aliases . . . . . . . . . . . . . . . . . . . 34 3.7.4. Other Header Fields in Gatewaying . . . . . . . . . . 33
3.9.2. Mailing Lists . . . . . . . . . . . . . . . . . . . . 34 3.7.5. Envelopes in Gatewaying . . . . . . . . . . . . . . . 34
4. The SMTP Specifications . . . . . . . . . . . . . . . . . . . 34 3.8. Terminating Sessions and Connections . . . . . . . . . . 34
4.1. SMTP Commands . . . . . . . . . . . . . . . . . . . . . . 34 4. The SMTP Specifications . . . . . . . . . . . . . . . . . . . 35
4.1. SMTP Commands . . . . . . . . . . . . . . . . . . . . . . 35
4.1.1. Command Semantics and Syntax . . . . . . . . . . . . 35 4.1.1. Command Semantics and Syntax . . . . . . . . . . . . 35
4.1.1.1. Extended HELLO (EHLO) or HELLO (HELO) . . . . . . 35 4.1.1.1. Extended HELLO (EHLO) or HELLO (HELO) . . . . . . 36
4.1.1.2. MAIL (MAIL) . . . . . . . . . . . . . . . . . . . 37 4.1.1.2. MAIL (MAIL) . . . . . . . . . . . . . . . . . . . 37
4.1.1.3. RECIPIENT (RCPT) . . . . . . . . . . . . . . . . 37 4.1.1.3. RECIPIENT (RCPT) . . . . . . . . . . . . . . . . 38
4.1.1.4. DATA (DATA) . . . . . . . . . . . . . . . . . . . 39 4.1.1.4. DATA (DATA) . . . . . . . . . . . . . . . . . . . 40
4.1.1.5. RESET (RSET) . . . . . . . . . . . . . . . . . . 41 4.1.1.5. RESET (RSET) . . . . . . . . . . . . . . . . . . 41
4.1.1.6. VERIFY (VRFY) . . . . . . . . . . . . . . . . . . 41 4.1.1.6. VERIFY (VRFY) . . . . . . . . . . . . . . . . . . 42
4.1.1.7. EXPAND (EXPN) . . . . . . . . . . . . . . . . . . 41 4.1.1.7. EXPAND (EXPN) . . . . . . . . . . . . . . . . . . 42
4.1.1.8. HELP (HELP) . . . . . . . . . . . . . . . . . . . 42 4.1.1.8. HELP (HELP) . . . . . . . . . . . . . . . . . . . 42
4.1.1.9. NOOP (NOOP) . . . . . . . . . . . . . . . . . . . 42 4.1.1.9. NOOP (NOOP) . . . . . . . . . . . . . . . . . . . 43
4.1.1.10. QUIT (QUIT) . . . . . . . . . . . . . . . . . . . 42 4.1.1.10. QUIT (QUIT) . . . . . . . . . . . . . . . . . . . 43
4.1.2. Command Argument Syntax . . . . . . . . . . . . . . . 43 4.1.2. Command Argument Syntax . . . . . . . . . . . . . . . 44
4.1.3. Address Literals . . . . . . . . . . . . . . . . . . 46 4.1.3. Address Literals . . . . . . . . . . . . . . . . . . 46
4.1.4. Order of Commands . . . . . . . . . . . . . . . . . . 47 4.1.4. Order of Commands . . . . . . . . . . . . . . . . . . 48
4.2. SMTP Replies . . . . . . . . . . . . . . . . . . . . . . 49
4.2. SMTP Replies . . . . . . . . . . . . . . . . . . . . . . 50
4.2.1. Reply Code Severities and Theory . . . . . . . . . . 51 4.2.1. Reply Code Severities and Theory . . . . . . . . . . 51
4.2.2. Reply Codes by Function Groups . . . . . . . . . . . 53 4.2.2. Reply Codes by Function Groups . . . . . . . . . . . 54
4.2.3. Reply Codes in Numeric Order . . . . . . . . . . . . 55 4.2.3. Reply Codes in Numeric Order . . . . . . . . . . . . 55
4.2.4. Some specific code situations and relationships . . . 56 4.2.4. Some specific code situations and relationships . . . 57
4.3. Sequencing of Commands and Replies . . . . . . . . . . . 58 4.3. Sequencing of Commands and Replies . . . . . . . . . . . 59
4.3.1. Sequencing Overview . . . . . . . . . . . . . . . . . 58 4.3.1. Sequencing Overview . . . . . . . . . . . . . . . . . 59
4.3.2. Command-Reply Sequences . . . . . . . . . . . . . . . 59 4.3.2. Command-Reply Sequences . . . . . . . . . . . . . . . 60
4.4. Trace Information . . . . . . . . . . . . . . . . . . . . 61 4.4. Trace Information . . . . . . . . . . . . . . . . . . . . 62
4.4.1. Received Header Field . . . . . . . . . . . . . . . . 61 4.4.1. Received Header Field . . . . . . . . . . . . . . . . 62
4.5. Additional Implementation Issues . . . . . . . . . . . . 65 4.5. Additional Implementation Issues . . . . . . . . . . . . 66
4.5.1. Minimum Implementation . . . . . . . . . . . . . . . 65 4.5.1. Minimum Implementation . . . . . . . . . . . . . . . 66
4.5.2. Transparency . . . . . . . . . . . . . . . . . . . . 66 4.5.2. Transparency . . . . . . . . . . . . . . . . . . . . 67
4.5.3. Sizes and Timeouts . . . . . . . . . . . . . . . . . 67 4.5.3. Sizes and Timeouts . . . . . . . . . . . . . . . . . 68
4.5.3.1. Size Limits and Minimums . . . . . . . . . . . . 67 4.5.3.1. Size Limits and Minimums . . . . . . . . . . . . 68
4.5.3.1.1. Local-part . . . . . . . . . . . . . . . . . 67 4.5.3.1.1. Local-part . . . . . . . . . . . . . . . . . 68
4.5.3.1.2. Domain . . . . . . . . . . . . . . . . . . . 68 4.5.3.1.2. Domain . . . . . . . . . . . . . . . . . . . 68
4.5.3.1.3. Path . . . . . . . . . . . . . . . . . . . . 68 4.5.3.1.3. Path . . . . . . . . . . . . . . . . . . . . 68
4.5.3.1.4. Command Line . . . . . . . . . . . . . . . . 68 4.5.3.1.4. Command Line . . . . . . . . . . . . . . . . 68
4.5.3.1.5. Reply Line . . . . . . . . . . . . . . . . . 68 4.5.3.1.5. Reply Line . . . . . . . . . . . . . . . . . 69
4.5.3.1.6. Text Line . . . . . . . . . . . . . . . . . . 68 4.5.3.1.6. Text Line . . . . . . . . . . . . . . . . . . 69
4.5.3.1.7. Message Content . . . . . . . . . . . . . . . 68 4.5.3.1.7. Message Content . . . . . . . . . . . . . . . 69
4.5.3.1.8. Recipient Buffer . . . . . . . . . . . . . . 68 4.5.3.1.8. Recipient Buffer . . . . . . . . . . . . . . 69
4.5.3.1.9. Treatment When Limits Exceeded . . . . . . . 69 4.5.3.1.9. Treatment When Limits Exceeded . . . . . . . 69
4.5.3.1.10. Too Many Recipients Code . . . . . . . . . . 69 4.5.3.1.10. Too Many Recipients Code . . . . . . . . . . 70
4.5.3.2. Timeouts . . . . . . . . . . . . . . . . . . . . 70 4.5.3.2. Timeouts . . . . . . . . . . . . . . . . . . . . 71
4.5.3.2.1. Initial 220 Message: 5 Minutes . . . . . . . 70 4.5.3.2.1. Initial 220 Message: 5 Minutes . . . . . . . 71
4.5.3.2.2. MAIL Command: 5 Minutes . . . . . . . . . . . 70 4.5.3.2.2. MAIL Command: 5 Minutes . . . . . . . . . . . 71
4.5.3.2.3. RCPT Command: 5 Minutes . . . . . . . . . . . 70 4.5.3.2.3. RCPT Command: 5 Minutes . . . . . . . . . . . 71
4.5.3.2.4. DATA Initiation: 2 Minutes . . . . . . . . . 70 4.5.3.2.4. DATA Initiation: 2 Minutes . . . . . . . . . 71
4.5.3.2.5. Data Block: 3 Minutes . . . . . . . . . . . . 70 4.5.3.2.5. Data Block: 3 Minutes . . . . . . . . . . . . 71
4.5.3.2.6. DATA Termination: 10 Minutes. . . . . . . . . 71 4.5.3.2.6. DATA Termination: 10 Minutes. . . . . . . . . 71
4.5.3.2.7. Server Timeout: 5 Minutes. . . . . . . . . . 71 4.5.3.2.7. Server Timeout: 5 Minutes. . . . . . . . . . 72
4.5.4. Retry Strategies . . . . . . . . . . . . . . . . . . 71 4.5.4. Retry Strategies . . . . . . . . . . . . . . . . . . 72
4.5.5. Messages with a Null Reverse-Path . . . . . . . . . . 73 4.5.5. Messages with a Null Reverse-Path . . . . . . . . . . 74
5. Address Resolution and Mail Handling . . . . . . . . . . . . 74 5. Address Resolution and Mail Handling . . . . . . . . . . . . 74
5.1. Locating the Target Host . . . . . . . . . . . . . . . . 74 5.1. Locating the Target Host . . . . . . . . . . . . . . . . 75
5.2. IPv6 and MX Records . . . . . . . . . . . . . . . . . . . 76 5.2. IPv6 and MX Records . . . . . . . . . . . . . . . . . . . 77
6. Problem Detection and Handling . . . . . . . . . . . . . . . 76 6. Problem Detection and Handling . . . . . . . . . . . . . . . 77
6.1. Reliable Delivery and Replies by Email . . . . . . . . . 77 6.1. Reliable Delivery and Replies by Email . . . . . . . . . 77
6.2. Unwanted, Unsolicited, and "Attack" Messages . . . . . . 77 6.2. Unwanted, Unsolicited, and "Attack" Messages . . . . . . 78
6.3. Loop Detection . . . . . . . . . . . . . . . . . . . . . 78 6.3. Loop Detection . . . . . . . . . . . . . . . . . . . . . 79
6.4. Compensating for Irregularities . . . . . . . . . . . . . 78 6.4. Compensating for Irregularities . . . . . . . . . . . . . 79
7. Security Considerations . . . . . . . . . . . . . . . . . . . 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 81
7.1. Mail Security and Spoofing . . . . . . . . . . . . . . . 80 7.1. Mail Security and Spoofing . . . . . . . . . . . . . . . 81
7.2. "Blind" Copies . . . . . . . . . . . . . . . . . . . . . 81 7.2. "Blind" Copies . . . . . . . . . . . . . . . . . . . . . 82
7.3. VRFY, EXPN, and Security . . . . . . . . . . . . . . . . 81 7.3. VRFY, EXPN, and Security . . . . . . . . . . . . . . . . 83
7.4. Mail Rerouting Based on the 251 and 551 Response Codes . 82 7.4. Mail Rerouting Based on the 251 and 551 Response Codes . 83
7.5. Information Disclosure in Announcements . . . . . . . . . 82 7.5. Information Disclosure in Announcements . . . . . . . . . 84
7.6. Information Disclosure in Trace Fields . . . . . . . . . 83 7.6. Information Disclosure in Trace Fields . . . . . . . . . 84
7.7. Information Disclosure in Message Forwarding . . . . . . 83 7.7. Information Disclosure in Message Forwarding . . . . . . 84
7.8. Local Operational Requirements and Resistance to 7.8. Local Operational Requirements and Resistance to
Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 83 Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 84
7.9. Scope of Operation of SMTP Servers . . . . . . . . . . . 84 7.9. Scope of Operation of SMTP Servers . . . . . . . . . . . 85
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 85
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 84 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 86
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 85 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 87
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 86 10.1. Normative References . . . . . . . . . . . . . . . . . . 87
10.1. Normative References . . . . . . . . . . . . . . . . . . 86 10.2. Informative References . . . . . . . . . . . . . . . . . 88
10.2. Informative References . . . . . . . . . . . . . . . . . 87 Appendix A. TCP Transport Service . . . . . . . . . . . . . . . 92
Appendix A. TCP Transport Service . . . . . . . . . . . . . . . 91
Appendix B. Generating SMTP Commands from RFC 822 Header Appendix B. Generating SMTP Commands from RFC 822 Header
Fields . . . . . . . . . . . . . . . . . . . . . . . . . 92 Fields . . . . . . . . . . . . . . . . . . . . . . . . . 92
Appendix C. Source Routes . . . . . . . . . . . . . . . . . . . 93 Appendix C. Placeholder (formerly Source Routes) . . . . . . . . 94
Appendix D. Scenarios . . . . . . . . . . . . . . . . . . . . . 93 Appendix D. Scenarios . . . . . . . . . . . . . . . . . . . . . 94
D.1. A Typical SMTP Transaction Scenario . . . . . . . . . . . 93 D.1. A Typical SMTP Transaction Scenario . . . . . . . . . . . 94
D.2. Aborted SMTP Transaction Scenario . . . . . . . . . . . . 94 D.2. Aborted SMTP Transaction Scenario . . . . . . . . . . . . 94
D.3. Relayed Mail Scenario . . . . . . . . . . . . . . . . . . 94 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 98 F.1. TURN . . . . . . . . . . . . . . . . . . . . . . . . . . 99
F.2. Source Routing . . . . . . . . . . . . . . . . . . . . . 98 F.2. Source Routing . . . . . . . . . . . . . . . . . . . . . 99
F.3. HELO . . . . . . . . . . . . . . . . . . . . . . . . . . 98 F.3. HELO . . . . . . . . . . . . . . . . . . . . . . . . . . 100
F.4. #-literals . . . . . . . . . . . . . . . . . . . . . . . 98 F.4. #-literals . . . . . . . . . . . . . . . . . . . . . . . 100
F.5. Dates and Years . . . . . . . . . . . . . . . . . . . . . 99 F.5. Dates and Years . . . . . . . . . . . . . . . . . . . . . 100
F.6. Sending versus Mailing . . . . . . . . . . . . . . . . . 99 F.6. Sending versus Mailing . . . . . . . . . . . . . . . . . 101
Appendix G. Other Outstanding Issues . . . . . . . . . . . . . . 99 Appendix G. Other Outstanding Issues . . . . . . . . . . . . . . 101
G.1. IP Address literals . . . . . . . . . . . . . . . . . . . 100 G.1. IP Address literals . . . . . . . . . . . . . . . . . . . 102
G.2. Repeated Use of EHLO (closed) . . . . . . . . . . . . . . 100 G.2. Repeated Use of EHLO (closed) . . . . . . . . . . . . . . 102
G.3. Meaning of "MTA" and Related Terminology . . . . . . . . 101 G.3. Meaning of "MTA" and Related Terminology . . . . . . . . 103
G.4. Originator, or Originating System, Authentication . . . . 101 G.4. Originator, or Originating System, Authentication . . . . 103
G.5. Remove or deprecate the work-around from code 552 to 452 G.5. Remove or deprecate the work-around from code 552 to 452
(closed) . . . . . . . . . . . . . . . . . . . . . . . . 101 (closed) . . . . . . . . . . . . . . . . . . . . . . . . 103
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 . . . . . . . . . . . . . . . 103
G.7. Probably-substantive Discussion Topics Identified in Other G.7. Probably-substantive Discussion Topics Identified in Other
Ways . . . . . . . . . . . . . . . . . . . . . . . . . . 102 Ways . . . . . . . . . . . . . . . . . . . . . . . . . . 104
G.7.1. Issues with 521, 554, and 556 codes (closed) . . . . 102 G.7.1. Issues with 521, 554, and 556 codes (closed) . . . . 104
G.7.2. SMTP Model, terminology, and relationship to RFC G.7.2. SMTP Model, terminology, and relationship to RFC
5598 . . . . . . . . . . . . . . . . . . . . . . . . 102 5598 . . . . . . . . . . . . . . . . . . . . . . . . 104
G.7.3. Resolvable FQDNs and private domain names . . . . . . 102 G.7.3. Resolvable FQDNs and private domain names . . . . . . 104
G.7.4. Possible clarification about mail transactions and G.7.4. Possible clarification about mail transactions and
transaction state . . . . . . . . . . . . . . . . . . 102 transaction state . . . . . . . . . . . . . . . . . . 104
G.7.5. Issues with mailing lists, aliases, and forwarding . 103 G.7.5. Issues with mailing lists, aliases, and forwarding . 105
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 . . . . . . . . . . . . . . . . . . . . . . . . 103 EHLO . . . . . . . . . . . . . . . . . . . . . . . . 105
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? (closed) . . . . . . . 103 code text need clarification? (closed) . . . . . . . 105
G.7.8. Size limits (closed) . . . . . . . . . . . . . . . . 103 G.7.8. Size limits (closed) . . . . . . . . . . . . . . . . 105
G.7.9. Discussion of 'blind' copies and RCPT . . . . . . . . 103 G.7.9. Discussion of 'blind' copies and RCPT . . . . . . . . 105
G.7.10. Further clarifications needed to source routes? . . . 104 G.7.10. Further clarifications needed to source routes? . . . 106
G.7.11. Should 1yz Be Revisited? (closed) . . . . . . . . . . 104 G.7.11. Should 1yz Be Revisited? (closed) . . . . . . . . . . 106
G.7.12. Review Timeout Specifications . . . . . . . . . . . . 104 G.7.12. Review Timeout Specifications . . . . . . . . . . . . 106
G.7.13. Possible SEND, SAML, SOML Loose End (closed) . . . . 104 G.7.13. Possible SEND, SAML, SOML Loose End (closed) . . . . 106
G.7.14. Abstract Update (closed) . . . . . . . . . . . . . . 104 G.7.14. Abstract Update (closed) . . . . . . . . . . . . . . 106
G.7.15. Informative References to MIME and/or Message G.7.15. Informative References to MIME and/or Message
Submission (closed) . . . . . . . . . . . . . . . . . 104 Submission (closed) . . . . . . . . . . . . . . . . . 106
G.7.16. Mail Transaction Discussion . . . . . . . . . . . . . 105 G.7.16. Mail Transaction Discussion . . . . . . . . . . . . . 107
G.7.17. Hop by hop Authentication and/or Encryption G.7.17. Hop by hop Authentication and/or Encryption
(closed) . . . . . . . . . . . . . . . . . . . . . . 105 (closed) . . . . . . . . . . . . . . . . . . . . . . 107
G.7.18. More Text About 554 Given 521, etc. . . . . . . . . . 105 G.7.18. More Text About 554 Given 521, etc. . . . . . . . . . 107
G.7.19. Minimum Lengths and Quantities . . . . . . . . . . . 105 G.7.19. Minimum Lengths and Quantities . . . . . . . . . . . 107
G.8. Enhanced Reply Codes and DSNs . . . . . . . . . . . . . . 105 G.8. Enhanced Reply Codes and DSNs . . . . . . . . . . . . . . 107
G.9. Revisiting Quoted Strings . . . . . . . . . . . . . . . . 106 G.9. Revisiting Quoted Strings . . . . . . . . . . . . . . . . 108
G.10. Internationalization . . . . . . . . . . . . . . . . . . 106 G.10. Internationalization . . . . . . . . . . . . . . . . . . 108
G.11. SMTP Clients, Servers, Senders, and Receivers . . . . . . 107 G.11. SMTP Clients, Servers, Senders, and Receivers . . . . . . 109
G.12. Extension Keywords Starting in 'X-' (closed) . . . . . . 107 G.12. Extension Keywords Starting in 'X-' (closed) . . . . . . 109
G.13. Deprecating HELO (closed) . . . . . . . . . . . . . . . . 107 G.13. Deprecating HELO (closed) . . . . . . . . . . . . . . . . 109
G.14. The FOR Clause in Trace Fields: Semantics, Security G.14. The FOR Clause in Trace Fields: Semantics, Security
Considerations, and Other Issues . . . . . . . . . . . . 108 Considerations, and Other Issues . . . . . . . . . . . . 110
G.15. Resistance to Attacks and Operational Necessity G.15. Resistance to Attacks and Operational Necessity
(closed) . . . . . . . . . . . . . . . . . . . . . . . . 108 (closed) . . . . . . . . . . . . . . . . . . . . . . . . 110
G.16. Mandatory 8BITMIME . . . . . . . . . . . . . . . . . . . 109 G.16. Mandatory 8BITMIME . . . . . . . . . . . . . . . . . . . 111
Appendix H. RFC 5321 Errata Summary and Tentative Change Log . . 109 Appendix H. RFC 5321 Errata Summary and Tentative Change Log . . 111
H.1. RFC 5321 Errata Summary . . . . . . . . . . . . . . . . . 109 H.1. RFC 5321 Errata Summary . . . . . . . . . . . . . . . . . 111
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 . . . . . . . . . . . 111 initial (-00) version of this draft . . . . . . . . . . . 113
H.3. Changes Among Versions of Rfc5321bis . . . . . . . . . . 112 H.3. Changes Among Versions of Rfc5321bis . . . . . . . . . . 114
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 . . . . . . . . . . . . . . . . . 112 2012-12-02) to -01 . . . . . . . . . . . . . . . . . 114
H.3.2. Changes from draft-klensin-rfc5321bis-01 (20191203) to H.3.2. Changes from draft-klensin-rfc5321bis-01 (20191203) to
-02 . . . . . . . . . . . . . . . . . . . . . . . . . 112 -02 . . . . . . . . . . . . . . . . . . . . . . . . . 114
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 . . . . . . . . . . . . . . . . . . . . . . . 113 to -03 . . . . . . . . . . . . . . . . . . . . . . . 115
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 . . . . . . . . 113 to draft-ietf-emailcore-rfc5321bis-00 . . . . . . . . 115
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 . . . . . . . . . . . . . . . . . 113 (2020-10-06) to -01 . . . . . . . . . . . . . . . . . 115
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 . . . . . . . . . . . . . . . . . 114 (2020-12-25) to -02 . . . . . . . . . . . . . . . . . 116
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 . . . . . . . . . . . . . . . . . 114 (2021-02-21) to -03 . . . . . . . . . . . . . . . . . 116
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 . . . . . . . . . . . . . . . . . 116 (2021-07-10) to -04 . . . . . . . . . . . . . . . . . 118
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 . . . . . . . . . . . . . . . . . 116 (2021-10-03) to -05 . . . . . . . . . . . . . . . . . 118
H.3.10. Changes from draft-ietf-emailcore-rfc5321bis-05 H.3.10. Changes from draft-ietf-emailcore-rfc5321bis-05
(2021-10-24) to -06 . . . . . . . . . . . . . . . . . 117 (2021-10-24) to -06 . . . . . . . . . . . . . . . . . 119
H.3.11. Changes from draft-ietf-emailcore-rfc5321bis-06 H.3.11. Changes from draft-ietf-emailcore-rfc5321bis-06
(2021-11-07) to -07 . . . . . . . . . . . . . . . . . 118 (2021-11-07) to -07 . . . . . . . . . . . . . . . . . 120
H.3.12. Changes from draft-ietf-emailcore-rfc5321bis-07
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 (2021-12-04) to -08 . . . . . . . . . . . . . . . . . 120
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 120 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 123
1. Introduction 1. Introduction
1.1. Transport of Electronic Mail 1.1. Transport of Electronic Mail
The objective of the Simple Mail Transfer Protocol (SMTP) is to The objective of the Simple Mail Transfer Protocol (SMTP) is to
transfer mail reliably and efficiently. transfer mail reliably and efficiently.
SMTP is independent of the particular transmission subsystem and SMTP is independent of the particular transmission subsystem and
requires only a reliable ordered data stream channel. While this requires only a reliable ordered data stream channel. While this
skipping to change at page 8, line 4 skipping to change at page 8, line 12
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:
* the original SMTP (Simple Mail Transfer Protocol) specification of * the original SMTP (Simple Mail Transfer Protocol) specification of
RFC 821 [3], RFC 821 [3],
* 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],
* the clarifications and applicability statements in RFC 1123 [5], * the clarifications and applicability statements in RFC 1123 [5],
* 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 [45], obsoleting both of those documents, and
* 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 [47] 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 [47] (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" [45]7504 (specification of reply codes), and 7505 [46] (the "Null MX"
specification). specification).
// JcK: 202107219: does the text that follows need rewriting? See // JcK: 202107219: does the text that follows need rewriting? See
// comment in Abstract. // 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 [41] 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.
Other relevant documents and their relationships are discussed in a Other relevant documents and their relationships are discussed in a
forthcoming Applicability Statement [51]. forthcoming Applicability Statement [48].
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.
skipping to change at page 10, line 22 skipping to change at page 10, line 31
relayed. SMTP clients that transfer all traffic regardless of the relayed. SMTP clients that transfer all traffic regardless of the
target domains associated with the individual messages, or that do target domains associated with the individual messages, or that do
not maintain queues for retrying message transmissions that initially not maintain queues for retrying message transmissions that initially
cannot be completed, may otherwise conform to this specification but cannot be completed, may otherwise conform to this specification but
are not considered fully-capable. Fully-capable SMTP are not considered fully-capable. Fully-capable SMTP
implementations, including the relays used by these less capable implementations, including the relays used by these less capable
ones, and their destinations, are expected to support all of the ones, and their destinations, are expected to support all of the
queuing, retrying, and alternate address functions discussed in this queuing, retrying, and alternate address functions discussed in this
specification. In many situations and configurations, the less- specification. In many situations and configurations, the less-
capable clients discussed above SHOULD be using the message capable clients discussed above SHOULD be using the message
submission protocol (RFC 6409 [42]) rather than SMTP. submission protocol (RFC 6409 [41]) rather than SMTP.
The means by which an SMTP client, once it has determined a target The means by which an SMTP client, once it has determined a target
domain, determines the identity of an SMTP server to which a copy of domain, determines the identity of an SMTP server to which a copy of
a message is to be transferred, and then performs that transfer, are a message is to be transferred, and then performs that transfer, are
covered by this document. To effect a mail transfer to an SMTP covered by this document. To effect a mail transfer to an SMTP
server, an SMTP client establishes a two-way transmission channel to server, an SMTP client establishes a two-way transmission channel to
that SMTP server. An SMTP client determines the address of an that SMTP server. An SMTP client determines the address of an
appropriate host running an SMTP server by resolving a destination appropriate host running an SMTP server by resolving a destination
domain name to either an intermediate Mail eXchanger host or a final domain name to either an intermediate Mail eXchanger host or a final
target host. target host.
skipping to change at page 11, line 39 skipping to change at page 11, line 48
As suggested above, this protocol provides mechanisms for the As suggested above, this protocol provides mechanisms for the
transmission of mail. Historically, this transmission normally transmission of mail. Historically, this transmission normally
occurred directly from the sending user's host to the receiving occurred directly from the sending user's host to the receiving
user's host when the two hosts are connected to the same transport user's host when the two hosts are connected to the same transport
service. When they are not connected to the same transport service, service. When they are not connected to the same transport service,
transmission occurs via one or more relay SMTP servers. A very transmission occurs via one or more relay SMTP servers. A very
common case in the Internet today involves submission of the original common case in the Internet today involves submission of the original
message to an intermediate, "message submission" server, which is message to an intermediate, "message submission" server, which is
similar to a relay but has some additional properties; such servers similar to a relay but has some additional properties; such servers
are discussed in Section 2.3.10 and at some length in RFC 6409 [42]. are discussed in Section 2.3.10 and at some length in RFC 6409 [41].
An intermediate host that acts as either an SMTP relay or as a An intermediate host that acts as either an SMTP relay or as a
gateway into some other transmission environment is usually selected gateway into some other transmission environment is usually selected
through the use of the domain name service (DNS) Mail eXchanger through the use of the domain name service (DNS) Mail eXchanger
mechanism. mechanism.
2.2. The Extension Model 2.2. The Extension Model
2.2.1. Background 2.2.1. Background
In an effort that started in 1990, approximately a decade after RFC In an effort that started in 1990, approximately a decade after RFC
821 was completed, the protocol was modified with a "service 821 was completed, the protocol was modified with a "service
extensions" model that permits the client and server to agree to extensions" model that permits the client and server to agree to
utilize shared functionality beyond the original SMTP requirements. utilize shared functionality beyond the original SMTP requirements.
The SMTP extension mechanism defines a means whereby an extended SMTP The SMTP extension mechanism defines a means whereby an extended SMTP
client and server may recognize each other, and the server can inform client and server may recognize each other, and the server can inform
the client as to the service extensions that it supports. the client as to the service extensions that it supports.
skipping to change at page 13, line 7 skipping to change at page 13, line 7
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 [52]. 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:
* the textual name of the SMTP service extension; * the textual name of the SMTP service extension;
* the EHLO keyword value associated with the extension; * the EHLO keyword value associated with the extension;
* the syntax and possible values of parameters associated with the * the syntax and possible values of parameters associated with the
skipping to change at page 14, line 34 skipping to change at page 14, line 34
(see Appendix F and Appendix F.6). (see Appendix F and Appendix F.6).
The SMTP content is sent in the SMTP DATA protocol unit and has two The SMTP content is sent in the SMTP DATA protocol unit and has two
parts: the header section and the body. If the content conforms to parts: the header section and the body. If the content conforms to
other contemporary standards, the header section consists of a other contemporary standards, the header section consists of a
collection of header fields, each consisting of a header name, a collection of header fields, each consisting of a header name, a
colon, and data, structured as in the message format specification colon, and data, structured as in the message format specification
(RFC 5322 [12]); the body, if structured, is defined according to (RFC 5322 [12]); the body, if structured, is defined according to
MIME (RFC 2045 [25]). The content is textual in nature, expressed MIME (RFC 2045 [25]). The content is textual in nature, expressed
using the US-ASCII repertoire [2]. Although SMTP extensions (such as using the US-ASCII repertoire [2]. Although SMTP extensions (such as
"8BITMIME", RFC 6152 [47]) may relax this restriction for the content "8BITMIME", RFC 6152 [44]) may relax this restriction for the content
body, the content header fields are always encoded using the US-ASCII body, the content header fields are always encoded using the US-ASCII
repertoire. Two MIME extensions (RFC 2047 [26] and RFC 2231 [29]) repertoire. Two MIME extensions (RFC 2047 [26] and RFC 2231 [29])
define an algorithm for representing header values outside the US- define an algorithm for representing header values outside the US-
ASCII repertoire, while still encoding them using the US-ASCII ASCII repertoire, while still encoding them using the US-ASCII
repertoire. repertoire.
2.3.2. Senders and Receivers 2.3.2. Senders and Receivers
In RFC 821, the two hosts participating in an SMTP transaction were In RFC 821, the two hosts participating in an SMTP transaction were
described as the "SMTP-sender" and "SMTP-receiver". This document described as the "SMTP-sender" and "SMTP-receiver". This document
skipping to change at page 15, line 15 skipping to change at page 15, line 15
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 or, more commonly transmitted from a user and hand it off to an MTA or, more commonly
in recent years, a specialized variation on an MTA called a in recent years, a specialized variation on an MTA called a
"Submission Server" (MSA) [42]. . At the other end of the process, "Submission Server" (MSA) [41]. . At the other end of the process,
the final ("delivery") MTA would be thought of as handing the mail the final ("delivery") MTA would be thought of as handing the mail
off to an MUA (or at least transferring responsibility to it, e.g., off to an MUA (or at least transferring responsibility to it, e.g.,
by depositing the message in a "message store"). However, while by depositing the message in a "message store"). However, while
these terms are used with at least the appearance of great precision these terms are used with at least the appearance of great precision
in other environments, the implied boundaries between MUAs and MTAs 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
skipping to change at page 15, line 43 skipping to change at page 15, line 43
2.3.5. Domain Names 2.3.5. Domain Names
A domain name (or often just a "domain") consists of one or more A domain name (or often just a "domain") consists of one or more
components, separated by dots if more than one appears. In the case components, separated by dots if more than one appears. In the case
of a top-level domain used by itself in an email address, a single of a top-level domain used by itself in an email address, a single
string is used without any dots. This makes the requirement, string is used without any dots. This makes the requirement,
described in more detail below, that only fully-qualified domain described in more detail below, that only fully-qualified domain
names appear in SMTP transactions on the public Internet, names appear in SMTP transactions on the public Internet,
particularly important where top-level domains are involved. These particularly important where top-level domains are involved. These
components ("labels" in DNS terminology, RFC 1035 [4]) are restricted components ("labels" in the DNS terminology of RFC 1035 [4]) are
for SMTP purposes to consist of a sequence of letters, digits, and restricted for purposes of SMTP as defined here to consist of a
hyphens drawn from the ASCII character set [2] and conforming to what sequence of letters, digits, and hyphens drawn from the ASCII
RFC 1035 Section 2.3.1 calls the "preferred name syntax". Domain character set [2] and conforming to what RFC 1035 Section 2.3.1 calls
names are used as names of hosts and of other entities in the domain the "preferred name syntax". Domain names are used as names of hosts
name hierarchy. For example, a domain may refer to an alias (label and, except where additionally restricted in this document, of other
of a CNAME RR) or the label of Mail eXchanger records to be used to entities in the domain name hierarchy. For example, a domain may
deliver mail instead of representing a host name. See RFC 1035 [4] refer to a host alias (label of a CNAME RR) or the label of Mail
and Section 5 of this specification. eXchanger records to be used to deliver mail instead of representing
a host name. See RFC 1035 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"). MUST be the entire, fully-qualified name (often referred to as an
A domain name that is not in FQDN form is no more than a local alias. "FQDN"). Other than an address literal (see Section 4.1.3) where
Local aliases MUST NOT appear in any SMTP transaction. those are permitted, any string that is not a domain name in FQDN
form is no more than a reference to be interpreted locally. Such
local references for domain names MUST NOT appear in any SMTP
transaction (Cf. Section 5). Mechanisms for inferring FQDNs from
local references (including partial names or local aliases) are
outside of this specification and normally the province of message
submission. Due to a history of problems, SMTP servers used for
initial submission of messages SHOULD NOT make such inferences
(Message Submission Servers [41] have somewhat more flexibility) and
intermediate (relay) SMTP servers MUST NOT make them.
Only resolvable, fully-qualified domain names (FQDNs) are permitted // [rfc5321 Editor's Note 20211231] The sentence starting with
when domain names are used in SMTP. In particular, names that can be // "Mechanisms" and the one immediately following it above moved from
resolved to MX RRs or address (i.e., A or AAAA) RRs (as discussed in // Section 5.1, but perhaps they should be dropped entirely and/or
Section 5) are permitted, as are CNAME RRs whose targets can be // elaborated on in the A/S.
resolved, in turn, to MX or address RRs. Local nicknames or
unqualified names MUST NOT be used. There are two exceptions to the When domain names are used in SMTP, and unless further restricted in
rule requiring FQDNs: this document, names that can be resolved to MX RRs or address (i.e.,
A or AAAA) RRs (as discussed in Section 5) are permitted, as are
CNAME RRs whose targets can be resolved, in turn, to MX or address
RRs. There are two exceptions to the rule requiring FQDNs:
* 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.
* 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.
skipping to change at page 16, line 50 skipping to change at page 17, line 18
data, are transmitted from the sender to the receiver via the data, are transmitted from the sender to the receiver via the
transmission channel in "lines". transmission channel in "lines".
An SMTP reply is an acknowledgment (positive or negative) sent in An SMTP reply is an acknowledgment (positive or negative) sent in
"lines" from receiver to sender via the transmission channel in "lines" from receiver to sender via the transmission channel in
response to a command. The general form of a reply is a numeric response to a command. The general form of a reply is a numeric
completion code (indicating failure or success) usually followed by a completion code (indicating failure or success) usually followed by a
text string. The codes are for use by programs and the text is text string. The codes are for use by programs and the text is
usually intended for human users. RFC 3463 [7], specifies further usually intended for human users. RFC 3463 [7], specifies further
structuring of the reply strings, including the use of supplemental structuring of the reply strings, including the use of supplemental
and more specific completion codes (see also RFC 5248 [46]). and more specific completion codes (see also RFC 5248 [43]).
2.3.8. Lines 2.3.8. Lines
Lines consist of zero or more data characters terminated by the Lines consist of zero or more data characters terminated by the
sequence ASCII character "CR" (hex value 0D) followed immediately by sequence ASCII character "CR" (hex value 0D) followed immediately by
ASCII character "LF" (hex value 0A). This termination sequence is ASCII character "LF" (hex value 0A). This termination sequence is
denoted as <CRLF> in this document. Conforming implementations MUST denoted as <CRLF> in this document. Conforming implementations MUST
NOT recognize or generate any other character or character sequence NOT recognize or generate any other character or character sequence
as a line terminator. Limits MAY be imposed on line lengths by as a line terminator. Limits MAY be imposed on line lengths by
servers (see Section 4). servers (see Section 4).
skipping to change at page 20, line 7 skipping to change at page 20, line 20
the ultimate delivery of a severely garbled message to the recipient. the ultimate delivery of a severely garbled message to the recipient.
Delivery SMTP systems MAY reject such messages, or return them as Delivery SMTP systems MAY reject such messages, or return them as
undeliverable, rather than deliver them. In the absence of a server- undeliverable, rather than deliver them. In the absence of a server-
offered extension explicitly permitting it, a sending SMTP system is offered extension explicitly permitting it, a sending SMTP system is
not permitted to send envelope commands in any character set other not permitted to send envelope commands in any character set other
than US-ASCII. Receiving systems SHOULD reject such commands, than US-ASCII. Receiving systems SHOULD reject such commands,
normally using "500 syntax error - invalid character" replies. normally using "500 syntax error - invalid character" replies.
8-bit message content transmission MAY be requested of the server by 8-bit message content transmission MAY be requested of the server by
a client using extended SMTP facilities, notably the "8BITMIME" a client using extended SMTP facilities, notably the "8BITMIME"
extension, RFC 6152 [47]. 8BITMIME SHOULD be supported by SMTP extension, RFC 6152 [44]. 8BITMIME SHOULD be supported by SMTP
servers. However, it MUST NOT be construed as authorization to servers. However, it MUST NOT be construed as authorization to
transmit unrestricted 8-bit material, nor does 8BITMIME authorize transmit unrestricted 8-bit material, nor does 8BITMIME authorize
transmission of any envelope material in other than ASCII. 8BITMIME transmission of any envelope material in other than ASCII. 8BITMIME
MUST NOT be requested by senders for material with the high bit on MUST NOT be requested by senders for material with the high bit on
that is not in MIME format with an appropriate content-transfer that is not in MIME format with an appropriate content-transfer
encoding; servers MAY reject such messages. encoding; servers MAY reject such messages.
The metalinguistic notation used in this document corresponds to the The metalinguistic notation used in this document corresponds to the
"Augmented BNF" used in other Internet mail system documents. The "Augmented BNF" used in other Internet mail system documents. The
reader who is not familiar with that syntax should consult the ABNF reader who is not familiar with that syntax should consult the ABNF
skipping to change at page 24, line 23 skipping to change at page 24, line 42
When the RFC 822 format ([13], [12]) is being used, the mail data When the RFC 822 format ([13], [12]) is being used, the mail data
include the header fields such as those named Date, Subject, To, Cc, include the header fields such as those named Date, Subject, To, Cc,
and From. Server SMTP systems SHOULD NOT reject messages based on and From. Server SMTP systems SHOULD NOT reject messages based on
perceived defects in the RFC 822 or MIME (RFC 2045 [25]) message perceived defects in the RFC 822 or MIME (RFC 2045 [25]) message
header section or message body. In particular, they MUST NOT reject header section or message body. In particular, they MUST NOT reject
messages in which the numbers of Resent-header fields do not match or messages in which the numbers of Resent-header fields do not match or
Resent-to appears without Resent-from and/or Resent-date. Resent-to appears without Resent-from and/or Resent-date.
Mail transaction commands MUST be used in the order discussed above. Mail transaction commands MUST be used in the order discussed above.
3.4. Forwarding for Address Correction or Updating 3.4. Address Modification and Expansion
3.4.1. Forwarding for Address Correction or Updating
Forwarding support is most often required to consolidate and simplify Forwarding support is most often required to consolidate and simplify
addresses within, or relative to, some enterprise and less frequently addresses within, or relative to, some enterprise and less frequently
to establish addresses to link a person's prior address with a to establish addresses to link a person's prior address with a
current one. Silent forwarding of messages (without server current one. Silent forwarding of messages (without server
notification to the sender), for security or non-disclosure purposes, notification to the sender), for security or non-disclosure purposes,
is common in the contemporary Internet. is common in the contemporary Internet.
In both the enterprise and the "new address" cases, information In both the enterprise and the "new address" cases, information
hiding (and sometimes security) considerations argue against exposure hiding (and sometimes security) considerations argue against exposure
skipping to change at page 25, line 4 skipping to change at page 25, line 25
In particular: In particular:
* 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,
* 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
or restrict their use. or restrict their use. See Section 7.4 for further discussion of
that issue.
3.4.2. Aliases and Mailing Lists
// [5321bis] If "alias and list models" are explained elsewhere,
// cross reference. Also note that this section appears to prohibit
// an exploder from adding List-* headers. That needs to be explicit
// or finessed.
An SMTP-capable host SHOULD support both the alias and the list
models of address expansion for multiple delivery. When a message is
delivered or forwarded to each address of an expanded list form, the
return address in the envelope ("MAIL FROM:") MUST be changed to be
the address of a person or other entity who administers the list.
However, in this case, the message header section (RFC 5322 [12])
MUST be left unchanged; in particular, the "From" field of the header
section is unaffected.
An important mail facility is a mechanism for multi-destination
delivery of a single message, by transforming (or "expanding" or
"exploding") a pseudo-mailbox address into a list of destination
mailbox addresses. When a message is sent to such a pseudo-mailbox
(sometimes called an "exploder"), copies are forwarded or
redistributed to each mailbox in the expanded list. Servers SHOULD
simply utilize the addresses on the list; application of heuristics
or other matching rules to eliminate some addresses, such as that of
the originator, is strongly discouraged. We classify such a pseudo-
mailbox as an "alias" or a "list", depending upon the expansion
rules.
3.4.2.1. Simple Aliases
To expand an alias, the recipient mailer simply replaces the pseudo-
mailbox address in the envelope with each of the expanded addresses
in turn; the rest of the envelope and the message body are left
unchanged. The message is then delivered or forwarded to each
expanded address.
3.4.2.2. Mailing Lists
Processing of a mailing list may be said to operate by
"redistribution" rather than by "forwarding" (as in the simple alias
case in the subsection above). To expand a list, the recipient
mailer replaces the pseudo-mailbox address in the envelope with each
of the expanded addresses in turn. The return (backward-pointing)
address in the envelope is changed so that all error messages
generated by the final deliveries will be returned to a list
administrator, not to the message originator, who generally has no
control over the contents of the list and will typically find error
messages annoying. Note that the key difference between handling
simple aliases Section 3.4.2.1 and redistribution (this subsection)
is the change to the backward-pointing address. When a system
managing a list constrains its processing to the very limited set of
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.
Mailing list management systems do exist that perform additional,
sometimes extensive, modifications to a message and its envelope.
Such mailing lists need to be viewed as MUAs that accept a message
delivery and then submit a new message for multiple recipients.
3.5. Commands for Debugging Addresses 3.5. Commands for Debugging Addresses
3.5.1. Overview 3.5.1. Overview
SMTP provides commands to verify a user name or obtain the content of SMTP provides commands to verify a user name or obtain the content of
a mailing list. This is done with the VRFY and EXPN commands, which a mailing list. This is done with the VRFY and EXPN commands, which
have character string arguments. Implementations SHOULD support VRFY have character string arguments. Implementations SHOULD support VRFY
and EXPN (however, see Section 3.5.2 and Section 7.3). and EXPN (however, see Section 3.5.2 and Section 7.3).
skipping to change at page 28, line 37 skipping to change at page 30, line 25
are not in full compliance with this specification. are not in full compliance with this specification.
There may be circumstances where an address appears to be valid but There may be circumstances where an address appears to be valid but
cannot reasonably be verified in real time, particularly when a cannot reasonably be verified in real time, particularly when a
server is acting as a mail exchanger for another server or domain. server is acting as a mail exchanger for another server or domain.
"Apparent validity", in this case, would normally involve at least "Apparent validity", in this case, would normally involve at least
syntax checking and might involve verification that any domains syntax checking and might involve verification that any domains
specified were ones to which the host expected to be able to relay specified were ones to which the host expected to be able to relay
mail. In these situations, reply code 252 SHOULD be returned. These mail. In these situations, reply code 252 SHOULD be returned. These
cases parallel the discussion of RCPT verification in Section 2.1. cases parallel the discussion of RCPT verification in Section 2.1.
Similarly, the discussion in Section 3.4 applies to the use of reply Similarly, the discussion in Section 3.4.1 applies to the use of
codes 251 and 551 with VRFY (and EXPN) to indicate addresses that are reply codes 251 and 551 with VRFY (and EXPN) to indicate addresses
recognized but that would be forwarded or rejected were mail received that are recognized but that would be forwarded or rejected were mail
for them. Implementations generally SHOULD be more aggressive about received for them. Implementations generally SHOULD be more
address verification in the case of VRFY than in the case of RCPT, aggressive about address verification in the case of VRFY than in the
even if it takes a little longer to do so. case of RCPT, even if it takes a little longer to do so.
3.5.4. Semantics and Applications of EXPN 3.5.4. Semantics and Applications of EXPN
EXPN is often very useful in debugging and understanding problems EXPN is often very useful in debugging and understanding problems
with mailing lists and multiple-target-address aliases. Some systems with mailing lists and multiple-target-address aliases. Some systems
have attempted to use source expansion of mailing lists as a means of have attempted to use source expansion of mailing lists as a means of
eliminating duplicates. The propagation of aliasing systems with eliminating duplicates. The propagation of aliasing systems with
mail on the Internet for hosts (typically with MX and CNAME DNS mail on the Internet for hosts (typically with MX and CNAME DNS
records), for mailboxes (various types of local host aliases), and in records), for mailboxes (various types of local host aliases), and in
various proxying arrangements has made it nearly impossible for these various proxying arrangements has made it nearly impossible for these
skipping to change at page 29, line 37 skipping to change at page 31, line 32
Many mail-sending clients exist, especially in conjunction with Many mail-sending clients exist, especially in conjunction with
facilities that receive mail via POP3 or IMAP, that have limited facilities that receive mail via POP3 or IMAP, that have limited
capability to support some of the requirements of this specification, capability to support some of the requirements of this specification,
such as the ability to queue messages for subsequent delivery such as the ability to queue messages for subsequent delivery
attempts. For these clients, it is common practice to make private attempts. For these clients, it is common practice to make private
arrangements to send all messages to a single server for processing arrangements to send all messages to a single server for processing
and subsequent distribution. SMTP, as specified here, is not ideally and subsequent distribution. SMTP, as specified here, is not ideally
suited for this role. A standardized mail submission protocol has suited for this role. A standardized mail submission protocol has
been developed that is gradually superseding practices based on SMTP been developed that is gradually superseding practices based on SMTP
(see RFC 6409 [42]). In any event, because these arrangements are (see RFC 6409 [41]). In any event, because these arrangements are
private and fall outside the scope of this specification, they are private and fall outside the scope of this specification, they are
not described here. not described here.
It is important to note that MX records can point to SMTP servers It is important to note that MX records can point to SMTP servers
that act as gateways into other environments, not just SMTP relays that act as gateways into other environments, not just SMTP relays
and final delivery systems; see Sections 3.7 and 5. and final delivery systems; see Sections 3.7 and 5.
If an SMTP server has accepted the task of relaying the mail and If an SMTP server has accepted the task of relaying the mail and
later finds that the destination is incorrect or that the mail cannot later finds that the destination is incorrect or that the mail cannot
be delivered for some other reason, then it MUST construct an be delivered for some other reason, then it MUST construct an
skipping to change at page 33, line 30 skipping to change at page 35, line 19
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. Aliases and Mailing Lists
// [5321bis] If "alias and list models" are explained elsewhere,
// cross reference. Also note that this section appears to prohibit
// an exploder from adding List-* headers. That needs to be explicit
// or finessed.
An SMTP-capable host SHOULD support both the alias and the list
models of address expansion for multiple delivery. When a message is
delivered or forwarded to each address of an expanded list form, the
return address in the envelope ("MAIL FROM:") MUST be changed to be
the address of a person or other entity who administers the list.
However, in this case, the message header section (RFC 5322 [12])
MUST be left unchanged; in particular, the "From" field of the header
section is unaffected.
An important mail facility is a mechanism for multi-destination
delivery of a single message, by transforming (or "expanding" or
"exploding") a pseudo-mailbox address into a list of destination
mailbox addresses. When a message is sent to such a pseudo-mailbox
(sometimes called an "exploder"), copies are forwarded or
redistributed to each mailbox in the expanded list. Servers SHOULD
simply utilize the addresses on the list; application of heuristics
or other matching rules to eliminate some addresses, such as that of
the originator, is strongly discouraged. We classify such a pseudo-
mailbox as an "alias" or a "list", depending upon the expansion
rules.
3.9.1. Simple Aliases
To expand an alias, the recipient mailer simply replaces the pseudo-
mailbox address in the envelope with each of the expanded addresses
in turn; the rest of the envelope and the message body are left
unchanged. The message is then delivered or forwarded to each
expanded address.
3.9.2. Mailing Lists
Processing of a mailing list may be said to operate by
"redistribution" rather than by "forwarding" (as in the simple alias
case in the subsection above). To expand a list, the recipient
mailer replaces the pseudo-mailbox address in the envelope with each
of the expanded addresses in turn. The return (backward-pointing)
address in the envelope is changed so that all error messages
generated by the final deliveries will be returned to a list
administrator, not to the message originator, who generally has no
control over the contents of the list and will typically find error
messages annoying. Note that the key difference between handling
simple aliases Section 3.9.1 and redistribution (this subsection) is
the change to the backward-pointing address. When a system managing
a list constrains its processing to the very limited set of
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.
Mailing list management systems do exist that perform additional,
sometimes extensive, modifications to a message and its envelope.
Such mailing lists need to be viewed as MUAs that accept a 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
characters terminated by <SP> if parameters follow and <CRLF> characters terminated by <SP> if parameters follow and <CRLF>
otherwise. (In the interest of improved interoperability, SMTP otherwise. (In the interest of improved interoperability, SMTP
receivers SHOULD tolerate trailing white space before the terminating receivers SHOULD tolerate trailing white space before the terminating
<CRLF>.) The syntax of the local part of a mailbox MUST conform to <CRLF>.) The syntax of the local part of a mailbox MUST conform to
receiver site conventions and the syntax specified in Section 4.1.2. receiver site conventions and the syntax specified in Section 4.1.2.
skipping to change at page 35, line 43 skipping to change at page 36, line 13
having invalid syntax. having invalid syntax.
4.1.1.1. Extended HELLO (EHLO) or HELLO (HELO) 4.1.1.1. Extended HELLO (EHLO) or HELLO (HELO)
These commands are used to identify the SMTP client to the SMTP These commands are used to identify the SMTP client to the SMTP
server. The argument clause contains the fully-qualified domain name server. The argument clause contains the fully-qualified domain name
of the SMTP client, if one is available. In situations in which the of the SMTP client, if one is available. In situations in which the
SMTP client system does not have a meaningful domain name (e.g., when SMTP client system does not have a meaningful domain name (e.g., when
its address is dynamically allocated and no reverse mapping record is its address is dynamically allocated and no reverse mapping record is
available), the client SHOULD send an address literal (see available), the client SHOULD send an address literal (see
Section 4.1.3). Section 4.1.3). Additional discussion of domain names in SMTP
commands appears in Section 2.3.5.
RFC 2821, and some earlier informal practices, encouraged following RFC 2821, and some earlier informal practices, encouraged following
the literal by information that would help to identify the client the literal by information that would help to identify the client
system. That convention was not widely supported, and many SMTP system. That convention was not widely supported, and many SMTP
servers considered it an error. In the interest of interoperability, servers considered it an error. In the interest of interoperability,
it is probably wise for servers to be prepared for this string to it is probably wise for servers to be prepared for this string to
occur, but SMTP clients SHOULD NOT send it. occur, but SMTP clients SHOULD NOT send it.
The SMTP server identifies itself to the SMTP client in the The SMTP server identifies itself to the SMTP client in the
connection greeting reply and in the response to this command. connection greeting reply and in the response to this command.
skipping to change at page 38, line 10 skipping to change at page 38, line 36
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 consists of the required destination mailbox. When The forward-path consists of the required destination mailbox. When
mail reaches its ultimate destination, the SMTP server inserts it mail reaches its ultimate destination, the SMTP server inserts it
into the destination mailbox in accordance with its host mail into the destination mailbox in accordance with its host mail
conventions. conventions.
// JcK 20211128: above is new text, per notes from Alexey and Ned, // JcK 20211128: above is new text in rfc5321bis-07, per notes from
// replacing the two paragraphs and text about source routes that // Alexey and Ned, replacing the two paragraphs and text about source
// used to appear here. However, I'm a little concerned about // routes that used to appear here. However, I'm a little concerned
// "ultimate destination" as used here. The earlier text was about // about "ultimate destination" as used here. The earlier text was
// source routes and that term was defined as "the forward-path // about source routes and that term was defined as "the forward-path
// contains only a destination mailbox)". But, without that context // contains only a destination mailbox)". But, without that context
// and discussions about MDAs and what they might do, I am not sure I // and discussions about MDAs and what they might do, I am not sure I
// know what the term means or if it is appropriate to talk about // know what the term means or if it is appropriate to talk about
// SMTP servers inserting things in mailboxes if we can avoid it. // SMTP servers inserting things in mailboxes if we can avoid it.
// (JcK 20211202) The examples below appear to have been carried // (JcK 20211214) Following significantly rewritten for rfc5321bis-
// forward from RFC821, i.e., before RFC 974 and MX records. Nothing // 08.
// in them is actually wrong given the current (as of version -07 of
// this draft), but it seems to me that we should trim it Prior versions of the SMTP specification included text and examples
// aggressively, add a few comments explaining why a proper DNS setup in this section of use of the deprecated source route construct. If
// with MX records would be a better solution for some of these desired, see Appendix F.2 for discussion of that mechanism.
// cases, and/or move the examples to Appendix F.2. I hope that we
// can either get this on the agenda for the next interim or dicuss
// it sufficiently on the list to get a sense of the WG (including
// whether anyone cases). Otherwise I will apply editor's
// discretion.
This command appends its forward-path argument to the forward-path This command appends its forward-path argument to the forward-path
buffer; it does not change the reverse-path buffer nor the mail data buffer; it does not change the reverse-path buffer nor the mail data
buffer. buffer.
For example, mail received at relay host xyz.com with envelope For example, mail received at relay host xyz.com with envelope
commands commands
MAIL FROM:<userx@y.foo.org> MAIL FROM:<userx@y.foo.org>
RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org>
will normally be sent directly on to host d.bar.org with envelope
commands
MAIL FROM:<userx@y.foo.org>
RCPT TO:<userc@d.bar.org> RCPT TO:<userc@d.bar.org>
As provided in Appendix F.2, xyz.com MAY also choose to relay the will result in a DNS lookup for d.bar.org and transmission to the
message to hosta.int, using the envelope commands host specified in the most-preferred MX record that is available (or
MAIL FROM:<userx@y.foo.org> by the address record if there are no MX records). It will use
RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org> envelope commands identical to the above, i.e.,
or to jkl.org, using the envelope commands
MAIL FROM:<userx@y.foo.org> MAIL FROM:<userx@y.foo.org>
RCPT TO:<@jkl.org:userc@d.bar.org> RCPT TO:<userc@d.bar.org>
Attempting to use relaying this way is now strongly discouraged.
Since hosts are not required to relay mail at all, xyz.com MAY also Since hosts are not required to relay mail at all, xyz.com MAY also
reject the message entirely when the RCPT command is received, using reject the message entirely when the RCPT command is received, using
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.
skipping to change at page 43, line 45 skipping to change at page 44, line 38
* 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 = "<" Mailbox ">" Path = "<" Mailbox ">"
At-domain = "@" Domain
Mail-parameters = esmtp-param *(SP esmtp-param) Mail-parameters = esmtp-param *(SP esmtp-param)
Rcpt-parameters = esmtp-param *(SP esmtp-param) Rcpt-parameters = esmtp-param *(SP esmtp-param)
esmtp-param = esmtp-keyword ["=" esmtp-value] esmtp-param = esmtp-keyword ["=" esmtp-value]
esmtp-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") esmtp-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
esmtp-value = 1*(%d33-60 / %d62-126) esmtp-value = 1*(%d33-60 / %d62-126)
; any CHAR excluding "=", SP, and control ; any CHAR excluding "=", SP, and control
; characters. If this string is an email address, ; characters. If this string is an email address,
; i.e., a Mailbox, then the "xtext" syntax [34] ; i.e., a Mailbox, then the "xtext" syntax [34]
; SHOULD be used. ; SHOULD be used.
Keyword = Ldh-str Keyword = Ldh-str
skipping to change at page 45, line 25 skipping to change at page 46, line 17
fourth character of that string. fourth character of that string.
While the above definition for Local-part is relatively permissive, While the above definition for Local-part is relatively permissive,
for maximum interoperability, a mailbox SHOULD NOT be defined with for maximum interoperability, a mailbox SHOULD NOT be defined with
Local-part requiring (or using) the Quoted-string form or with the Local-part requiring (or using) the Quoted-string form or with the
Local-part being case-sensitive. Further, when comparing a Local- Local-part being case-sensitive. Further, when comparing a Local-
part (e.g., to a specific mailbox name), all quoting MUST be treated part (e.g., to a specific mailbox name), all quoting MUST be treated
as equivalent. A sending system SHOULD transmit the form that uses as equivalent. A sending system SHOULD transmit the form that uses
the minimum quoting possible. the minimum quoting possible.
For example, the following 3 local-parts are semantically For example, the following 3 local-parts are equivalent and MUST
equivalent and MUST compare equal: "ab cd ef", "ab\ cd ef" and compare equal: "ab cd ef", "ab\ cd ef" and "ab\ \cd ef".
"ab\ \cd ef". Similarly, "fred" and fred must compare equal. Similarly, "fred" and fred must compare equal. White space
White space reduction MUST NOT be applied to Local-part by reduction MUST NOT be applied to Local-part by intermediate
intermediate systems. systems.
Systems MUST NOT define mailboxes in such a way as to require the use Systems MUST NOT define mailboxes in such a way as to require the use
in SMTP of non-ASCII characters (octets with the high order bit set in SMTP of non-ASCII characters (octets with the high order bit set
to one) or ASCII "control characters" (decimal value 0-31 and 127). to one) or ASCII "control characters" (decimal value 0-31 and 127).
These characters MUST NOT be used in MAIL or RCPT commands or other These characters MUST NOT be used in MAIL or RCPT commands or other
commands that require mailbox names. commands that require mailbox names.
To promote interoperability and consistent with long-standing To promote interoperability and consistent with long-standing
guidance about conservative use of the DNS in naming and applications guidance about conservative use of the DNS in naming and applications
(e.g., see Section 2.3.1 of the base DNS document, RFC 1035 [4]), (e.g., see Section 2.3.1 of the base DNS document, RFC 1035 [4]),
skipping to change at page 50, line 24 skipping to change at page 51, line 4
[ SP textstring ] CRLF [ SP textstring ] CRLF
*( "220-" [ textstring ] CRLF ) *( "220-" [ textstring ] CRLF )
"220" [ SP textstring ] CRLF ) "220" [ SP textstring ] CRLF )
textstring = 1*(%d09 / %d32-126) ; HT, SP, Printable US-ASCII textstring = 1*(%d09 / %d32-126) ; HT, SP, Printable US-ASCII
Reply-line = *( Reply-code "-" [ textstring ] CRLF ) Reply-line = *( Reply-code "-" [ textstring ] CRLF )
Reply-code [ SP textstring ] CRLF Reply-code [ SP textstring ] CRLF
Reply-code = %x32-35 %x30-35 %x30-39 Reply-code = %x32-35 %x30-35 %x30-39
where "Greeting" appears only in the 220 response that announces that where "Greeting" appears only in the 220 response that announces that
the server is opening its part of the connection. (Other possible the server is opening its part of the connection. (Other possible
server responses upon connection follow the syntax of Reply-line.) server responses upon connection follow the syntax of Reply-line.)
An SMTP server SHOULD send only the reply codes listed in this An SMTP server SHOULD send only the reply codes listed in this
document or additions to the list as discussed below. An SMTP server document or additions to the list as discussed below. An SMTP server
SHOULD use the text shown in the examples whenever appropriate. SHOULD use the text shown in the examples whenever appropriate.
An SMTP client MUST determine its actions only by the reply code, not An SMTP client MUST determine its actions only by the reply code, not
by the text (except for the "change of address" 251 and 551 and, if by the text (except for the "change of address" 251 and 551 and, if
necessary, 220, 221, and 421 replies); in the general case, any text, necessary, 220, 221, and 421 replies); in the general case, any text,
including no text at all (although senders SHOULD NOT send bare including no text at all (although senders SHOULD NOT send bare
codes), MUST be acceptable. The space (blank) following the reply codes), MUST be acceptable. The space (blank) following the reply
code is considered part of the text. A Sender-SMTP MUST first test code is considered part of the text. A Sender-SMTP MUST first test
the whole 3 digit reply code it receives, as well as any accompanying the whole 3 digit reply code it receives, as well as any accompanying
supplemental codes or information (see RFC 3463 [7] and RFC 5248 supplemental codes or information (see RFC 3463 [7] and RFC 5248
[46]). If the full reply code is not recognized, and the additional [43]). If the full reply code is not recognized, and the additional
information is not recognized or missing, the Sender-SMTP MUST use information is not recognized or missing, the Sender-SMTP MUST use
the first digit (severity indication) of a reply code it receives. the first digit (severity indication) of a reply code it receives.
The list of codes that appears below MUST NOT be construed as The list of codes that appears below MUST NOT be construed as
permanent. While the addition of new codes should be a rare and permanent. While the addition of new codes should be a rare and
significant activity, with supplemental information in the textual significant activity, with supplemental information in the textual
part of the response (including enhanced status codes [7] and the part of the response (including enhanced status codes [7] and the
successors to that specification) being preferred, new codes may be successors to that specification) being preferred, new codes may be
added as the result of new Standards or Standards-Track added as the result of new Standards or Standards-Track
specifications. Consequently, a sender-SMTP MUST be prepared to specifications. Consequently, a sender-SMTP MUST be prepared to
skipping to change at page 54, line 33 skipping to change at page 54, line 45
421 <domain> Service not available, closing transmission channel 421 <domain> Service not available, closing transmission channel
(This may be a reply to any command if the service knows it must (This may be a reply to any command if the service knows it must
shut down) shut down)
521 <domain> No mail service here. 521 <domain> No mail service here.
556 No mail service at this domain. 556 No mail service at this domain.
250 Requested mail action okay, completed 250 Requested mail action okay, completed
251 User not local; will forward to <forward-path> (See Section 3.4) 251 User not local; will forward to <forward-path> (See
Section 3.4.1)
252 Cannot VRFY user, but will accept message and attempt delivery 252 Cannot VRFY user, but will accept message and attempt delivery
(See Section 3.5.3) (See Section 3.5.3)
455 Server unable to accommodate parameters 455 Server unable to accommodate parameters
555 MAIL FROM/RCPT TO parameters not recognized or not implemented 555 MAIL FROM/RCPT TO parameters not recognized or not implemented
450 Requested mail action not taken: mailbox unavailable (e.g., 450 Requested mail action not taken: mailbox unavailable (e.g.,
mailbox busy or temporarily blocked for policy reasons) mailbox busy or temporarily blocked for policy reasons)
550 Requested action not taken: mailbox unavailable (e.g., mailbox 550 Requested action not taken: mailbox unavailable (e.g., mailbox
not found, no access, or command rejected for policy reasons) not found, no access, or command rejected for policy reasons)
451 Requested action aborted: error in processing 451 Requested action aborted: error in processing
551 User not local; please try <forward-path> (See Section 3.4) 551 User not local; please try <forward-path> (See Section 3.4.1)
452 Requested action not taken: insufficient system storage 452 Requested action not taken: insufficient system storage
(preferred code for "too many recipients", see Section 4.5.3.1.10) (preferred code for "too many recipients", see Section 4.5.3.1.10)
552 Requested mail action aborted: exceeded storage allocation. 552 Requested mail action aborted: exceeded storage allocation.
553 Requested action not taken: mailbox name not allowed (e.g., 553 Requested action not taken: mailbox name not allowed (e.g.,
mailbox syntax incorrect) mailbox syntax incorrect)
354 Start mail input; end with <CRLF>.<CRLF> 354 Start mail input; end with <CRLF>.<CRLF>
skipping to change at page 55, line 36 skipping to change at page 55, line 49
214 Help message (Information on how to use the receiver or the 214 Help message (Information on how to use the receiver or the
meaning of a particular non-standard command; this reply is useful meaning of a particular non-standard command; this reply is useful
only to the human user) only to the human user)
220 <domain> Service ready 220 <domain> Service ready
221 <domain> Service closing transmission channel 221 <domain> Service closing transmission channel
250 Requested mail action okay, completed 250 Requested mail action okay, completed
251 User not local; will forward to <forward-path> (See Section 3.4) 251 User not local; will forward to <forward-path> (See
Section 3.4.1)
252 Cannot VRFY user, but will accept message and attempt delivery 252 Cannot VRFY user, but will accept message and attempt delivery
(See Section 3.5.3) (See Section 3.5.3)
354 Start mail input; end with <CRLF>.<CRLF> 354 Start mail input; end with <CRLF>.<CRLF>
421 <domain> Service not available, closing transmission channel 421 <domain> Service not available, closing transmission channel
(This may be a reply to any command if the service knows it must (This may be a reply to any command if the service knows it must
shut down) shut down)
skipping to change at page 56, line 25 skipping to change at page 56, line 40
503 Bad sequence of commands 503 Bad sequence of commands
504 Command parameter not implemented 504 Command parameter not implemented
521 No mail service (See Section 4.2.4.2.) 521 No mail service (See Section 4.2.4.2.)
550 Requested action not taken: mailbox unavailable (e.g., mailbox 550 Requested action not taken: mailbox unavailable (e.g., mailbox
not found, no access, or command rejected for policy reasons) not found, no access, or command rejected for policy reasons)
551 User not local; please try <forward-path> (See Section 3.4) 551 User not local; please try <forward-path> (See Section 3.4.1)
552 Requested mail action aborted: exceeded storage allocation. 552 Requested mail action aborted: exceeded storage allocation.
553 Requested action not taken: mailbox name not allowed (e.g., 553 Requested action not taken: mailbox name not allowed (e.g.,
mailbox syntax incorrect) mailbox syntax incorrect)
554 Transaction failed (Or, in the case of a connection-opening 554 Transaction failed (Or, in the case of a connection-opening
response, "No SMTP service here" although 521 is now preferred for response, "No SMTP service here" although 521 is now preferred for
the latter. See Section 4.2.4.2.) the latter. See Section 4.2.4.2.)
skipping to change at page 56, line 37 skipping to change at page 57, line 4
552 Requested mail action aborted: exceeded storage allocation. 552 Requested mail action aborted: exceeded storage allocation.
553 Requested action not taken: mailbox name not allowed (e.g., 553 Requested action not taken: mailbox name not allowed (e.g.,
mailbox syntax incorrect) mailbox syntax incorrect)
554 Transaction failed (Or, in the case of a connection-opening 554 Transaction failed (Or, in the case of a connection-opening
response, "No SMTP service here" although 521 is now preferred for response, "No SMTP service here" although 521 is now preferred for
the latter. See Section 4.2.4.2.) the latter. See Section 4.2.4.2.)
555 MAIL FROM/RCPT TO parameters not recognized or not implemented 555 MAIL FROM/RCPT TO parameters not recognized or not implemented
556 No mail service at this domain. (See Section 4.2.4.2.) 556 No mail service at this domain. (See Section 4.2.4.2.)
4.2.4. Some specific code situations and relationships 4.2.4. Some specific code situations and relationships
4.2.4.1. Reply Code 502 4.2.4.1. Reply Code 502
Questions have been raised as to when reply code 502 (Command not Questions have been raised as to when reply code 502 (Command not
implemented) SHOULD be returned in preference to other codes. 502 implemented) SHOULD be returned in preference to other codes. 502
SHOULD be used when the command is actually recognized by the SMTP SHOULD be used when the command is actually recognized by the SMTP
server, but not implemented. If the command is not recognized, code server, but not implemented. If the command is not recognized, code
500 SHOULD be returned. Extended SMTP systems MUST NOT list 500 SHOULD be returned. Extended SMTP systems MUST NOT list
capabilities in response to EHLO for which they will return 502 (or capabilities in response to EHLO for which they will return 502 (or
500) replies. 500) replies.
4.2.4.2. "No mail accepted" situations and the 521, 554, and 556 codes 4.2.4.2. "No mail accepted" situations and the 521, 554, and 556 codes
Codes 521, 554, and 556 are all used to report different types of "no Codes 521, 554, and 556 are all used to report different types of "no
mail accepted" situations. They differ as follows. 521 is an mail accepted" situations. They differ as follows. 521 is an
indication from a system answering on the SMTP port that it does not indication from a system answering on the SMTP port that it does not
support SMTP service (a so-called "dummy server" as discussed in RFC support SMTP service (a so-called "dummy server" as discussed in RFC
7504 [48] and elsewhere). Obviously, it requires that system exist 7504 [45] and elsewhere). Obviously, it requires that system exist
and that a connection can be made successfully to it. Because a and that a connection can be made successfully to it. Because a
system that does not accept any mail cannot meaningfully accept a system that does not accept any mail cannot meaningfully accept a
RCPT command, any commands (other than QUIT) issued after an SMTP RCPT command, any commands (other than QUIT) issued after an SMTP
server has issued a 521 reply are client (sender) errors. server has issued a 521 reply are client (sender) errors.
When a domain does not intend to accept mail and wishes to publish When a domain does not intend to accept mail and wishes to publish
that fact rather than being subjected to connection attempts, the that fact rather than being subjected to connection attempts, the
best way to accomplish that is to use the "Null MX" convention. This best way to accomplish that is to use the "Null MX" convention. This
is done by advertising a single MX RR (see Section 3.3.9 of (RFC 1035 is done by advertising a single MX RR (see Section 3.3.9 of (RFC 1035
[4]) with an RDATA section consisting of preference number 0 and a [4]) with an RDATA section consisting of preference number 0 and a
zero-length label, written in master files as ".", as the exchange zero-length label, written in master files as ".", as the exchange
domain, to denote that there exists no mail exchanger for that domain, to denote that there exists no mail exchanger for that
domain. Reply code 556 is then used by a message submission or domain. Reply code 556 is then used by a message submission or
intermediate SMTP system (see Section 1.1) to report that it cannot intermediate SMTP system (see Section 1.1) to report that it cannot
forward the message further because it knows from the DNS entry that forward the message further because it knows from the DNS entry that
the recipient domain does not accept mail. If, despite publishing the recipient domain does not accept mail. If, despite publishing
the DNS entry, the server domain chooses to respond on the SMTP port, the DNS entry, the server domain chooses to respond on the SMTP port,
it SHOULD respond with the 556 code as well. The details of the Null it SHOULD respond with the 556 code as well. The details of the Null
MX convention were first defined in RFC 7505 [49]; see that document MX convention were first defined in RFC 7505 [46]; see that document
for additional discussion of the rationale for that convention. for additional discussion of the rationale for that convention.
Reply code 554 would normally be used in response to a RCPT command Reply code 554 would normally be used in response to a RCPT command
(or extension command with similar intent) when the SMTP system (or extension command with similar intent) when the SMTP system
identifies a domain that it can (or has) determined never accepts identifies a domain that it can (or has) determined never accepts
mail. Other codes, including 554 and the temporary 450, are used for mail. Other codes, including 554 and the temporary 450, are used for
more transient situations and situations in which an SMTP server more transient situations and situations in which an SMTP server
cannot or will not deliver to (or accept mail for) a particular cannot or will not deliver to (or accept mail for) a particular
system or mailbox for policy reasons rather than ones directly system or mailbox for policy reasons rather than ones directly
related to SMTP processing. related to SMTP processing.
skipping to change at page 60, line 45 skipping to change at page 61, line 28
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.1 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
o E: 552, 554, 451, 452 o E: 552, 554, 451, 452
o 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
skipping to change at page 74, line 13 skipping to change at page 75, line 4
with a valid, non-null reverse-path. with a valid, non-null reverse-path.
Implementers of automated email processors should be careful to make Implementers of automated email processors should be careful to make
sure that the various kinds of messages with a null reverse-path are sure that the various kinds of messages with a null reverse-path are
handled correctly. In particular, such systems SHOULD NOT reply to handled correctly. In particular, such systems SHOULD NOT reply to
messages with a null reverse-path, and they SHOULD NOT add a non-null messages with a null reverse-path, and they SHOULD NOT add a non-null
reverse-path, or change a null reverse-path to a non-null one, to reverse-path, or change a null reverse-path to a non-null one, to
such messages when forwarding. such messages when forwarding.
5. Address Resolution and Mail Handling 5. Address Resolution and Mail Handling
5.1. Locating the Target Host 5.1. Locating the Target Host
Once an SMTP client lexically identifies a domain to which mail will Once an SMTP client lexically identifies a domain to which mail will
be delivered for processing (as described in Sections 2.3.5 and 3.6), be delivered for processing (as described in Sections 2.3.5 and 3.6),
a DNS lookup MUST be performed to resolve the domain name (RFC 1035 a DNS lookup MUST be performed to resolve the domain name (RFC 1035
[4]). The names are expected to be fully-qualified domain names [4]. The names are required to be fully-qualified domain names
(FQDNs): mechanisms for inferring FQDNs from partial names or local (FQDNs) as discussed in Section 2.3.5.
aliases are outside of this specification. Due to a history of
problems, SMTP servers used for initial submission of messages SHOULD
NOT make such inferences (Message Submission Servers [42] have
somewhat more flexibility) and intermediate (relay) SMTP servers MUST
NOT make them.
The lookup first attempts to locate an MX record associated with the The lookup first attempts to locate an MX record associated with the
name. If a CNAME record is found, the resulting name is processed as name. If a CNAME record is found, the resulting name is processed as
if it were the initial name. If a non-existent domain error is if it were the initial name. If a non-existent domain error is
returned, this situation MUST be reported as an error. If a returned, this situation MUST be reported as an error. If a
temporary error is returned, the message MUST be queued and retried temporary error is returned, the message MUST be queued and retried
later (see Section 4.5.4.1). If an empty list of MXs is returned, later (see Section 4.5.4.1). If an empty list of MXs is returned,
the address is treated as if it was associated with an implicit MX the address is treated as if it was associated with an implicit MX RR
RR, with a preference of 0, pointing to that host. If MX records are with a preference of 0, pointing to that host. If MX records are
present, but none of them are usable, or the implicit MX is unusable, present, but none of them are usable, or the implicit MX is unusable,
this situation MUST be reported as an error. this situation MUST be reported as an error.
When the lookup succeeds, the mapping can result in a list of
alternative delivery addresses rather than a single address. This
can be due to multiple MX records, multihoming, or both. To provide
reliable mail transmission, the SMTP client MUST be able to try (and
be prepared to retry) each of the relevant addresses in this list in
order (see below), until a delivery attempt succeeds. However, as
discussed more generally in Section 7.8 there MAY also be a
configurable limit on the number of alternate addresses that can be
tried. In any case, the SMTP client SHOULD try at least two
addresses.
If one or more MX RRs are found for a given name, SMTP systems MUST If one or more MX RRs are found for a given name, SMTP systems MUST
NOT utilize any address RRs associated with that name unless they are NOT utilize any address RRs associated with that name unless they are
located using the MX RRs; the "implicit MX" rule above applies only located using the MX RRs; the "implicit MX" rule above applies only
if there are no MX records present. If MX records are present, but if there are no MX records present. If MX records are present, but
none of them are usable, this situation MUST be reported as an error. none of them are usable, this situation MUST be reported as an error.
When a domain name associated with an MX RR is looked up and the When a domain name associated with an MX RR is looked up and the
associated data field obtained, the data field of that response MUST associated data field obtained, the data field of that response MUST
contain a domain name that conforms to the specifications of contain a domain name that conforms to the specifications of
Section 2.3.5. Section 2.3.5.
[[5321bis Editor's Note: Depending on how the "null MX" discussion [[5321bis Editor's Note: Depending on how the "null MX" discussion
unfolds, some additional text may be in order here (20140718)]] unfolds, some additional text may be in order here (20140718)]]
That domain name, when queried, MUST return at least one address That domain name, when queried, MUST return at least one address
record (e.g., A or AAAA RR) that gives the IP address of the SMTP record (e.g., A or AAAA RR) that gives the IP address of the SMTP
server to which the message should be directed. Any other response, server to which the message should be directed. Any other response,
specifically including a value that will return a CNAME record when specifically including a value that will return a CNAME record when
queried, lies outside the scope of this Standard. The prohibition on queried, lies outside the scope of this Standard. The prohibition on
labels in the data that resolve to CNAMEs is discussed in more detail labels in the data that resolve to CNAMEs is discussed in more detail
in RFC 2181, Section 10.3 [28]. in RFC 2181, Section 10.3 [28].
When the lookup succeeds, the mapping can result in a list of
alternative delivery addresses rather than a single address, because
of multiple MX records, multihoming, or both. To provide reliable
mail transmission, the SMTP client MUST be able to try (and retry)
each of the relevant addresses in this list in order, until a
delivery attempt succeeds. However, there MAY also be a configurable
limit on the number of alternate addresses that can be tried. In any
case, the SMTP client SHOULD try at least two addresses.
Two types of information are used to rank the host addresses: Two types of information are used to rank the host addresses:
multiple MX records, and multihomed hosts. multiple MX records, and multihomed hosts.
MX records contain a preference indication that MUST be used in MX records contain a numerical preference indication that MUST be
sorting if more than one such record appears (see below). Lower used in sorting if more than one such record appears. Lower numbers
numbers are more preferred than higher ones. If there are multiple are more preferred than higher ones. The sender-SMTP MUST inspect
destinations with the same preference and there is no clear reason to the list for any of the names or addresses by which it might be known
favor one (e.g., by recognition of an easily reached address), then in mail transactions. If a matching record is found, all records at
the sender-SMTP MUST randomize them to spread the load across that preference level and higher-numbered ones MUST be discarded from
multiple mail exchangers for a specific organization. consideration. If there are no records left at that point, it is an
error condition, and a 5yz reply code generated (terminating the mail
transaction) or the message MUST be returned as undeliverable. If
there is a single MX record at the most-preferred preference label,
the data field associated with that record is used as the next
destination. Otherwise, if there are multiple records with the same
preference and there is no clear reason to favor one (e.g., by
recognition of an easily reached address), then the sender-SMTP MUST
randomize them to spread the load across multiple mail exchangers for
a specific organization.
The destination host (perhaps taken from the preferred MX record) may The destination host (from either the data field of the preferred MX
be multihomed, in which case the domain name resolver will return a record of from an address records fount in an implicit MX) may be
multihomed. In those cases the domain name resolver will return a
list of alternative IP addresses. It is the responsibility of the list of alternative IP addresses. It is the responsibility of the
domain name resolver interface to have ordered this list by domain name resolver interface to have ordered this list by
decreasing preference if necessary, and the SMTP sender MUST try them decreasing preference if necessary, and the SMTP sender MUST try them
in the order presented. in the order presented.
Although the capability to try multiple alternative addresses is Although the capability to try multiple alternative addresses is
required, specific installations may want to limit or disable the use required, specific installations may want to limit or disable the use
of alternative addresses. The question of whether a sender should of alternative addresses. The question of whether a sender should
attempt retries using the different addresses of a multihomed host attempt retries using the different addresses of a multihomed host
has been controversial. The main argument for using the multiple has been controversial. The main argument for using the multiple
addresses is that it maximizes the probability of timely delivery, addresses is that it maximizes the likelihood of timely delivery, and
and indeed sometimes the probability of any delivery; the counter- indeed sometimes the likelihood of any delivery; the counter-argument
argument is that it may result in unnecessary resource use. Note is that it may result in unnecessary resource use. Note that
that resource use is also strongly determined by the sending strategy resource use is also strongly determined by the sending strategy
discussed in Section 4.5.4.1. discussed in Section 4.5.4.1.
If an SMTP server receives a message with a destination for which it If an SMTP server receives a message with a destination for which it
is a designated Mail eXchanger, it MAY relay the message (potentially is a designated Mail eXchanger, it MAY relay the message (potentially
after having rewritten the MAIL FROM and/or RCPT TO addresses), make after having rewritten the MAIL FROM and/or RCPT TO addresses), make
final delivery of the message, or hand it off using some mechanism final delivery of the message, or hand it off using some mechanism
outside the SMTP-provided transport environment. Of course, neither outside the SMTP-provided transport environment. Of course, neither
of the latter require that the list of MX records be examined of the latter require that the list of MX records be examined
further. further.
If it determines that it should relay the message without rewriting If it determines that it should relay the message without rewriting
the address, it MUST sort the MX records to determine candidates for the address, it MUST process the MX records as described above to
delivery. The records are first ordered by preference, with the determine candidates for delivery.
lowest-numbered records being most preferred. The relay host MUST
then inspect the list for any of the names or addresses by which it
might be known in mail transactions. If a matching record is found,
all records at that preference level and higher-numbered ones MUST be
discarded from consideration. If there are no records left at that
point, it is an error condition, and the message MUST be returned as
undeliverable. If records do remain, they SHOULD be tried, best
preference first, as described above.
5.2. IPv6 and MX Records 5.2. IPv6 and MX Records
In the contemporary Internet, SMTP clients and servers may be hosted In the contemporary Internet, SMTP clients and servers may be hosted
on IPv4 systems, IPv6 systems, or dual-stack systems that are on IPv4 systems, IPv6 systems, or dual-stack systems that are
compatible with either version of the Internet Protocol. The host compatible with either version of the Internet Protocol. The host
domains to which MX records point may, consequently, contain "A RR"s domains to which MX records point may, consequently, contain "A RR"s
(IPv4), "AAAA RR"s (IPv6), or any combination of them. While RFC (IPv4), "AAAA RR"s (IPv6), or any combination of them. While RFC
3974 [39] discusses some operational experience in mixed 3974 [39] discusses some operational experience in mixed
environments, it was not comprehensive enough to justify environments, it was not comprehensive enough to justify
skipping to change at page 79, line 37 skipping to change at page 80, line 37
authenticated addresses. authenticated addresses.
In response to these weak SMTP clients, many SMTP systems now In response to these weak SMTP clients, many SMTP systems now
complete messages that are delivered to them in incomplete or complete messages that are delivered to them in incomplete or
incorrect form. This strategy is generally considered appropriate incorrect form. This strategy is generally considered appropriate
when the server can identify or authenticate the client, and there when the server can identify or authenticate the client, and there
are prior agreements between them. By contrast, there is at best are prior agreements between them. By contrast, there is at best
great concern about fixes applied by a relay or delivery SMTP server great concern about fixes applied by a relay or delivery SMTP server
that has little or no knowledge of the user or client machine. Many that has little or no knowledge of the user or client machine. Many
of these issues are addressed by using a separate protocol, such as of these issues are addressed by using a separate protocol, such as
that defined in RFC 6409 [42], for message submission, rather than that defined in RFC 6409 [41], 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:
* Addition of a message-id field when none appears * Addition of a message-id field when none appears
* Addition of a date, time, or time zone when none appears * Addition of a date, time, or time zone when none appears
skipping to change at page 80, line 31 skipping to change at page 81, line 31
SMTP servers and create messages that will trick a naive recipient SMTP servers and create messages that will trick a naive recipient
into believing that they came from somewhere else. Constructing such into believing that they came from somewhere else. Constructing such
a message so that the "spoofed" behavior cannot be detected by an a message so that the "spoofed" behavior cannot be detected by an
expert is somewhat more difficult, but not sufficiently so as to be a expert is somewhat more difficult, but not sufficiently so as to be a
deterrent to someone who is determined and knowledgeable. deterrent to someone who is determined and knowledgeable.
Consequently, as knowledge of Internet mail increases, so does the Consequently, as knowledge of Internet mail increases, so does the
knowledge that SMTP mail inherently cannot be authenticated, or knowledge that SMTP mail inherently cannot be authenticated, or
integrity checks provided, at the transport level. Real mail integrity checks provided, at the transport level. Real mail
security lies only in end-to-end methods involving the message security lies only in end-to-end methods involving the message
bodies, such as those that use digital signatures (see RFC 1847 [21] bodies, such as those that use digital signatures (see RFC 1847 [21]
and, e.g., Pretty Good Privacy (PGP) in RFC 4880 [45] or Secure/ and, e.g., Pretty Good Privacy (PGP) in RFC 4880 [42] or Secure/
Multipurpose Internet Mail Extensions (S/MIME) in RFC 8551 [38]). Multipurpose Internet Mail Extensions (S/MIME) in RFC 8551 [38]).
Various protocol extensions and configuration options that provide Various protocol extensions and configuration options that provide
authentication at the transport level (e.g., from an SMTP client to authentication at the transport level (e.g., from an SMTP client to
an SMTP server) improve somewhat on the traditional situation an SMTP server) improve somewhat on the traditional situation
described above. However, in general, they only authenticate one described above. However, in general, they only authenticate one
server to another rather than a chain of relays and servers, much server to another rather than a chain of relays and servers, much
less authenticating users or user machines. Consequently, unless less authenticating users or user machines. Consequently, unless
they are accompanied by careful handoffs of responsibility in a they are accompanied by careful handoffs of responsibility in a
carefully designed trust environment, they remain inherently weaker carefully designed trust environment, they remain inherently weaker
skipping to change at page 81, line 30 skipping to change at page 82, line 30
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. extension header fields.
// [rfc5321bis] [[Note in draft - Suggestion from 20070124 that got // [rfc5321bis] [[Note in draft - Suggestion from 20070124 that got
// lost: delete "especially" and "the full set of" -- copying the // lost: delete "especially" and "the full set of" -- copying the
// first one can be as harmful as copying all of them, at least // first one can be as harmful as copying all of them, at least
// without verifying that the addresses do appear in the headers. // without verifying that the addresses do appear in the headers.
// See G.7.9 and ticket #15.Since this rule is often violated in // See G.7.9 and ticket #15.
practice, and cannot be enforced, sending SMTP systems that are aware Because this rule is often violated in practice, and cannot be
of "bcc" use MAY find it helpful to send each blind copy as a enforced, sending SMTP systems that are aware of "bcc" use MAY find
separate message transaction containing only a single RCPT command. it helpful to send each blind copy as a 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 26 skipping to change at page 84, line 36
specification may disclose host names and similar information that specification may disclose host names and similar information that
would not normally be available. This ordinarily does not pose a would not normally be available. This ordinarily does not pose a
problem, but sites with special concerns about name disclosure should problem, but sites with special concerns about name disclosure should
be aware of it. Also, the optional FOR clause should be supplied be aware of it. Also, the optional FOR clause should be supplied
with caution or not at all when multiple recipients are involved lest with caution or not at all when multiple recipients are involved lest
it inadvertently disclose the identities of "blind copy" recipients it inadvertently disclose the identities of "blind copy" recipients
to others. to others.
7.7. Information Disclosure in Message Forwarding 7.7. Information Disclosure in Message Forwarding
As discussed in Section 3.4, use of the 251 or 551 reply codes to As discussed in Section 3.4.1, use of the 251 or 551 reply codes to
identify the replacement address associated with a mailbox may identify the replacement address associated with a mailbox may
inadvertently disclose sensitive information. Sites that are inadvertently disclose sensitive information. Sites that are
concerned about those issues should ensure that they select and concerned about those issues should ensure that they select and
configure servers appropriately. configure servers appropriately.
7.8. Local Operational Requirements and Resistance to Attacks 7.8. Local Operational Requirements and Resistance to Attacks
In recent years, there has been an increase of attacks on SMTP In recent years, there has been an increase of attacks on SMTP
servers, either in conjunction with attempts to discover addresses servers, either in conjunction with attempts to discover addresses
for sending unsolicited messages or simply to make the servers for sending unsolicited messages or simply to make the servers
skipping to change at page 84, line 34 skipping to change at page 85, line 39
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:
* 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" [49], consists of SMTP service extensions with the
associated keywords, and, as needed, parameters and verbs. associated keywords, and, as needed, parameters and verbs.
Entries may be made only for service extensions (and associated Entries may be made only for service extensions (and associated
keywords, parameters, or verbs) that are defined in Standards- keywords, parameters, or verbs) that are defined in Standards-
Track or Experimental RFCs specifically approved by the IESG for Track or Experimental RFCs specifically approved by the IESG for
this purpose. this purpose.
* The second registry, "Address Literal Tags" [53], consists of * The second registry, "Address Literal Tags" [50], 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.
* The third, "Mail Transmission Types" [52], established by RFC 821 * The third, "Mail Transmission Types" [49], established by RFC 821
and renewed by this specification, is a registry of link and and renewed by this specification, is a registry of link and
protocol identifiers to be used with the "via" and "with" protocol identifiers to be used with the "via" and "with"
subclauses of the time stamp ("Received:" header field) described subclauses of the time stamp ("Received:" header field) described
in Section 4.4. Link and protocol identifiers in addition to in Section 4.4. Link and protocol identifiers in addition to
those specified in this document may be registered only by those specified in this document may be registered only by
standardization or by way of an RFC-documented, IESG-approved, standardization or by way of an RFC-documented, IESG-approved,
Experimental protocol extension. This name space is for Experimental protocol extension. This name space is for
identification and not limited in size: the IESG is encouraged to identification and not limited in size: the IESG is encouraged to
approve on the basis of clear documentation and a distinct method approve on the basis of clear documentation and a distinct method
rather than preferences about the properties of the method itself. rather than preferences about the properties of the method itself.
skipping to change at page 90, line 15 skipping to change at page 91, line 20
[39] Nakamura, M. and J. Hagino, "SMTP Operational Experience [39] Nakamura, M. and J. Hagino, "SMTP Operational Experience
in Mixed IPv4/v6 Environments", RFC 3974, in Mixed IPv4/v6 Environments", RFC 3974,
DOI 10.17487/RFC3974, January 2005, DOI 10.17487/RFC3974, January 2005,
<https://www.rfc-editor.org/info/rfc3974>. <https://www.rfc-editor.org/info/rfc3974>.
[40] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [40] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
[41] Kitterman, S., "Sender Policy Framework (SPF) for [41] Gellens, R. and J. Klensin, "Message Submission for Mail",
Authorizing Use of Domains in Email, Version 1", RFC 7208,
DOI 10.17487/RFC7208, April 2014,
<https://www.rfc-editor.org/info/rfc7208>.
[42] Gellens, R. and J. Klensin, "Message Submission for Mail",
STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011, STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011,
<https://www.rfc-editor.org/info/rfc6409>. <https://www.rfc-editor.org/info/rfc6409>.
[43] Fenton, J., "Analysis of Threats Motivating DomainKeys [42] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
Identified Mail (DKIM)", RFC 4686, DOI 10.17487/RFC4686,
September 2006, <https://www.rfc-editor.org/info/rfc4686>.
[44] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
"DomainKeys Identified Mail (DKIM) Signatures", STD 76,
RFC 6376, DOI 10.17487/RFC6376, September 2011,
<https://www.rfc-editor.org/info/rfc6376>.
[45] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
Thayer, "OpenPGP Message Format", RFC 4880, Thayer, "OpenPGP Message Format", RFC 4880,
DOI 10.17487/RFC4880, November 2007, DOI 10.17487/RFC4880, November 2007,
<https://www.rfc-editor.org/info/rfc4880>. <https://www.rfc-editor.org/info/rfc4880>.
[46] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced [43] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced
Mail System Status Codes", BCP 138, RFC 5248, Mail System Status Codes", BCP 138, RFC 5248,
DOI 10.17487/RFC5248, June 2008, DOI 10.17487/RFC5248, June 2008,
<https://www.rfc-editor.org/info/rfc5248>. <https://www.rfc-editor.org/info/rfc5248>.
[47] Klensin, J., Freed, N., Rose, M., and D. Crocker, Ed., [44] Klensin, J., Freed, N., Rose, M., and D. Crocker, Ed.,
"SMTP Service Extension for 8-bit MIME Transport", STD 71, "SMTP Service Extension for 8-bit MIME Transport", STD 71,
RFC 6152, DOI 10.17487/RFC6152, March 2011, RFC 6152, DOI 10.17487/RFC6152, March 2011,
<https://www.rfc-editor.org/info/rfc6152>. <https://www.rfc-editor.org/info/rfc6152>.
[48] Klensin, J., "SMTP 521 and 556 Reply Codes", RFC 7504, [45] Klensin, J., "SMTP 521 and 556 Reply Codes", RFC 7504,
DOI 10.17487/RFC7504, June 2015, DOI 10.17487/RFC7504, June 2015,
<https://www.rfc-editor.org/info/rfc7504>. <https://www.rfc-editor.org/info/rfc7504>.
[49] Levine, J. and M. Delany, "A "Null MX" No Service Resource [46] 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, [47] 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.C., Ed., Murchison, K., Ed., and E. Sam, Ed., [48] Klensin, J.C., Ed., Murchison, K., Ed., and E. Sam, Ed.,
"Applicability Statement for IETF Core Email Protocols", 6 "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 [49] 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 [50] 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, [51] RFC Editor, "RFC Errata - RFC 5321", 2019,
<https://www.rfc-editor.org/errata/rfc5321>. Captured <https://www.rfc-editor.org/errata/rfc5321>. Captured
2019-11-19 2019-11-19
[55] IANA, "SMTP Service Extensions", 2021, [52] 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>. Notes in draft: RFC parameters.xhtml#mail-parameters-2>. Notes in draft: RFC
Editor: Please adjust date field to reflect whatever you Editor: Please adjust date field to reflect whatever you
want for a registry that is updated periodically. IANA: want for a registry that is updated periodically. IANA:
Please determine if the above URL is a sufficiently stable Please determine if the above URL is a sufficiently stable
reference and adjust as appropriate if it is not. 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
skipping to change at page 93, line 20 skipping to change at page 94, line 5
Attempts to gateway messages using only their header "To" and "Cc" Attempts to gateway messages using only their header "To" and "Cc"
fields have repeatedly caused mail loops and other behavior adverse fields have repeatedly caused mail loops and other behavior adverse
to the proper functioning of the Internet mail environment. These to the proper functioning of the Internet mail environment. These
problems have been especially common when the message originates from problems have been especially common when the message originates from
an Internet mailing list and is distributed into the foreign an Internet mailing list and is distributed into the foreign
environment using envelope information. When these messages are then environment using envelope information. When these messages are then
processed by a header-section-only remailer, loops back to the processed by a header-section-only remailer, loops back to the
Internet environment (and the mailing list) are almost inevitable. Internet environment (and the mailing list) are almost inevitable.
Appendix C. Source Routes Appendix C. Placeholder (formerly Source Routes)
// This entire section to be removed, possibly with some material // This entire section has been removed, with some material moved
// moved into Appendix F. This comment is retained as a temporary // into Appendix F.2. This comment is retained as a temporary
// placeholder because the WG, the Ticket list, and various email // placeholder because the WG, the Ticket list, and various email
// threads refer to Appendix letters and it would not be good to // threads refer to Appendix letters and it would not be good to
// create confusion about that. // create confusion about that while rfc5321bis is under development.
Appendix D. Scenarios Appendix D. Scenarios
This section presents complete scenarios of several types of SMTP This section presents complete scenarios of several types of SMTP
sessions. In the examples, "C:" indicates what is said by the SMTP sessions. In the examples, "C:" indicates what is said by the SMTP
client, and "S:" indicates what is said by the SMTP server. client, and "S:" indicates what is said by the SMTP server.
D.1. A Typical SMTP Transaction Scenario D.1. A Typical SMTP Transaction Scenario
This SMTP example shows mail sent by Smith at host bar.com, and to This SMTP example shows mail sent by Smith at host bar.com, and to
skipping to change at page 97, line 45 skipping to change at page 98, line 45
inadequate in important ways. Systems translating between inadequate in important ways. Systems translating between
environments that do not support both envelopes and a header section environments that do not support both envelopes and a header section
and Internet mail must be written with the understanding that some and Internet mail must be written with the understanding that some
information loss is almost inevitable. information loss is almost inevitable.
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 even earlier, by RFC 1123 in 1989. Of the domain literal
1123 required support only for the dotted decimal form. With the forms, RFC 1123 required support only for the dotted decimal form.
possible exception of old, hardware-embedded, applications, there is With the possible exception of old, hardware-embedded, applications,
no longer any excuse for these features to appear on the contemporary there is no longer any excuse for these features to appear on the
Internet. contemporary Internet.
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.
F.2. Source Routing F.2. Source Routing
RFC 821 utilized the concept of explicit source routing to get mail RFC 821 utilized the concept of explicit source routing to get mail
from one host to another via a series of relays. The requirement to from one host to another via a series of relays. Source routes could
utilize source routes in regular mail traffic was eliminated by the appear in either the <forward-path> or <reverse-path> to show the
introduction of the domain name system "MX" record and the last hosts through which mail would be routed to reach the destination.
significant justification for them was eliminated by the The requirement to utilize source routes in regular mail traffic was
introduction, in RFC 1123, of a clear requirement that addresses eliminated by the introduction of the domain name system "MX" record
following an "@" must all be fully-qualified domain names. by RFC 974 in early 1986 and the last significant justification for
Consequently, the only remaining justifications for the use of source them was eliminated by the introduction, in RFC 1123, of a clear
routes are support for very old SMTP clients or MUAs and in mail requirement that addresses following an "@" must all be fully-
system debugging. They can, however, still be useful in the latter qualified domain names. Issues involving local aliases for mailboxes
circumstance and for routing mail around serious, but temporary, were addressed by the introduction of a separate specification for
problems such as problems with the relevant DNS records. mail submission [41]. Consequently, there are no remaining
justifications for the use of source routes other than support for
very old SMTP clients. Even use in mail system debugging is unlikely
to work because almost all contemporary systems either ignore or
reject them.
SMTP servers MUST continue to accept source route syntax as specified Historically, for relay purposes, the forward-path may have been a
in the main body of this document and in RFC 1123. They MAY, if source route of the form "@ONE,@TWO:JOE@THREE", where ONE, TWO, and
necessary, ignore the routes and utilize only the target domain in THREE MUST be fully-qualified domain names. This form was used to
the address. If they do utilize the source route, the message MUST emphasize the distinction between an address and a route. The
be sent to the first domain shown in the address. In particular, a mailbox (here, JOE@THREE) is an absolute address, and the route is
server MUST NOT guess at shortcuts within the source route. information about how to get there. The two concepts should not be
confused.
Clients SHOULD NOT utilize explicit source routing except under SMTP servers SHOULD continue to accept source route syntax as
unusual circumstances, such as debugging or potentially relaying specified in this appendix. If they do so, they SHOULD ignore the
around firewall or mail system configuration errors. routes and utilize only the target domain in the address. If they do
utilize the source route, the message MUST be sent to the first
domain shown in the address. In particular, a server MUST NOT guess
at shortcuts within the source route. SMTP clients SHOULD NOT
attempt to utilize explicit source routing.
If source routes appear in mail received by an SMTP server contrary
to the requirements and recommendations in this specification, RFC
821 and the text below should be consulted for the mechanisms for
constructing and 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 forward-path) MUST remove its domain name from any
forward-paths in which that domain name appears before forwarding the
message and MAY remove all other source routing information. Any
source route information in the reverse-path SHOULD be removed by
servers conforming to this specification.
The following information is provided for historical information
only, so that the source route syntax and application can be
understood if needed.
Syntax:
The original form of the <Path> production in Section 4.1.2 was:
Path = "<" [ A-d-l ":" ] Mailbox ">"
A-d-l = At-domain *( "," At-domain )
At-domain = "@" Domain
For example, suppose that a delivery service notification must be
sent for a message that arrived with:
MAIL FROM:<@a.example,@b.example:user@d.example>
The notification message MUST be sent using:
RCPT TO:<user@d.example>
F.3. HELO F.3. HELO
As discussed in Sections 3.1 and 4.1.1, EHLO SHOULD be used rather As discussed in Sections 3.1 and 4.1.1, EHLO SHOULD be used rather
than HELO when the server will accept the former. Servers MUST than HELO when the server will accept the former. Servers MUST
continue to accept and process HELO in order to support older continue to accept and process HELO in order to support older
clients. clients.
F.4. #-literals F.4. #-literals
skipping to change at page 101, line 28 skipping to change at page 103, line 31
terminology from "sender-SMTP" and "receiver-SMTP" to "SMTP client" terminology from "sender-SMTP" and "receiver-SMTP" to "SMTP client"
and "SMTP server" respectively. As things have evolved, it is and "SMTP server" respectively. As things have evolved, it is
possible that newer terminology is a source of confusion and that the possible that newer terminology is a source of confusion and that the
terminology should be changed back, something that also needs terminology should be changed back, something that also needs
discussion. discussion.
Ticket #3. Ticket #3.
G.4. Originator, or Originating System, Authentication G.4. Originator, or Originating System, Authentication
Should RFC 5321bis address authentication and related issues or Should RFC 5321bis address authentication and related issues or
should Section 3.9 or other text be reshaped (in addition to or should Section 3.4.2 or other text be reshaped (in addition to or
instead of the comment on that section) to lay a better foundation instead of the comment on that section) to lay a better foundation
for such work, either in the context of mailing lists or more for such work, either in the context of mailing lists or more
generally? generally?
This may interact with Erratum 4055 and Ticket #30 below. This may interact with Erratum 4055 and Ticket #30 below.
G.5. Remove or deprecate the work-around from code 552 to 452 (closed) G.5. Remove or deprecate the work-around from code 552 to 452 (closed)
The suggestion in Section 4.5.3.1.10 may have outlived its usefulness 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 be inconsistent with current practice. Should it be removed
and/or explicitly deprecated? and/or explicitly deprecated?
skipping to change at page 103, line 7 skipping to change at page 105, line 7
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.
// See correspondence on this ticket 2021-07-06 through 2021-07-09. // See correspondence on this ticket 2021-07-06 through 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.4.2. May also want to note forwarding as
email address portability issue. Note that, if changes are made in an email address portability issue. Note that, if changes are made
this area, they should be kept consistent with the description and in 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.1 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 #34/ erratum 1820 resolved in -06 Ticket #12 and Ticket #34 (Ticket #34/ erratum 1820 resolved in -06
and closed). and closed).
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.
skipping to change at page 105, line 35 skipping to change at page 107, line 35
Are the minimum lengths and quantities specified in Section 4.5.3 Are the minimum lengths and quantities specified in Section 4.5.3
still appropriate or do they need adjusting? (See CREF at the still appropriate or do they need adjusting? (See CREF at the
beginning of that section.) Also note potential interaction with the beginning of that section.) Also note potential interaction with the
proposed LIMITS SMTP extension (draft-freed-smtp-limits) which may proposed LIMITS SMTP extension (draft-freed-smtp-limits) which may
make this question OBE. make this question OBE.
G.8. Enhanced Reply Codes and DSNs G.8. Enhanced Reply Codes and DSNs
Enhanced Mail System Status Codes (RFC 3463) [7] were added to SMTP Enhanced Mail System Status Codes (RFC 3463) [7] were added to SMTP
before RFC 5321 was published and are now, together with a before RFC 5321 was published and are now, together with a
corresponding registry [46], widely deployed and in extensive use in corresponding registry [43], widely deployed and in extensive use in
the network. Similar, the structure and extensions options for the network. Similar, the structure and extensions options for
Delivery Status Notifications [35] is implemented, deployed, and in Delivery Status Notifications [35] is implemented, deployed, and in
wide use. Is it time to fold all or part of those mature wide use. Is it time to fold all or part of those mature
specifications into the SMTP spec or at least to mention and specifications into the SMTP spec or at least to mention and
normatively reference them? And, as an aside, do those specs need normatively reference them? And, as an aside, do those specs need
work or, if they are kept separate, is it time to move them to work or, if they are kept separate, is it time to move them to
Internet Standard? Internet Standard?
At least one of the current references to RFC 3463 indicates that it At least one of the current references to RFC 3463 indicates that it
SHOULD be used. That presumably makes the reference normative SHOULD be used. That presumably makes the reference normative
skipping to change at page 109, line 20 skipping to change at page 111, line 20
should be required. If that is the WG's conclusion, we need to should be required. If that is the WG's conclusion, we need to
figure out what to say and where to say it. figure out what to say and where to say it.
Appendix H. RFC 5321 Errata Summary and Tentative Change Log Appendix H. RFC 5321 Errata Summary and Tentative Change Log
[[RFC Editor: Please remove this section before publication.]] [[RFC Editor: Please remove this section before publication.]]
H.1. RFC 5321 Errata Summary H.1. RFC 5321 Errata Summary
This document addresses the following errata filed against RFC 5321 This document addresses the following errata filed against RFC 5321
since its publication in October 2008 [54]. As with the previous since its publication in October 2008 [51]. As with the previous
appendix, ticket numbers included below reference appendix, ticket numbers included below reference
https://trac.ietf.org/trac/emailcore/report/1 . https://trac.ietf.org/trac/emailcore/report/1 .
// [[Note in Draft: Unless marked "closed", items with comments below // [[Note in Draft: Unless marked "closed", items with comments below
// have not yet been resolved as errata.]] // have not yet been resolved as errata.]]
1683 ABNF error. (closed) Section 4.4 1683 ABNF error. (closed) Section 4.4
Ticket #23 (fixed, closed). Ticket #23 (fixed, closed).
4198 Description error. (closed) Section 4.2. 4198 Description error. (closed) Section 4.2.
RESOLVED 2020-12-14, ticket #24 (closed). RESOLVED 2020-12-14, ticket #24 (closed).
skipping to change at page 117, line 46 skipping to change at page 119, line 46
* Started reworking the Abstract -- see revised CREF there. * Started reworking the Abstract -- see revised CREF there.
* Rewrote Section 2.3.3 slightly to note the existence of submission * Rewrote Section 2.3.3 slightly to note the existence of submission
servers and removed the CREF. servers and removed the CREF.
* Updated Appendix G.7.17 and slightly modified CREF note in * Updated Appendix G.7.17 and slightly modified CREF note in
Section 2 -- proposed to not get 5321bis involved with this Section 2 -- proposed to not get 5321bis involved with this
(Ticket #50). (Ticket #50).
* Rewrote parts of Section 3.9 to clarify text amd respond to Ticket * Rewrote parts of Section 3.4.2 to clarify text amd respond to
#34. Ticket #34.
* Inserted suggested text info CREF at end of Section 1.2. Comments * Inserted suggested text info CREF at end of Section 1.2. Comments
welcome. Soon. welcome. Soon.
H.3.11. Changes from draft-ietf-emailcore-rfc5321bis-06 (2021-11-07) to H.3.11. Changes from draft-ietf-emailcore-rfc5321bis-06 (2021-11-07) to
-07 -07
* Reviewed closed tickets and discussion with co-chairs after IETF * Reviewed closed tickets and discussion with co-chairs after IETF
112 and updated text. Sections or items that are, according to 112 and updated text. Sections or items that are, according to
the ticket list, completely closed have been identified by the ticket list, completely closed have been identified by
skipping to change at page 118, line 30 skipping to change at page 120, line 30
comments through comments through
* Last sentence (about source routing) removed from Section 2.1. * Last sentence (about source routing) removed from Section 2.1.
Also adjusted text in Section 3.3, Section 4.1.1.3 but work is Also adjusted text in Section 3.3, Section 4.1.1.3 but work is
still needed there (see new CREFs in that section) and still needed there (see new CREFs in that section) and
Section 6.1. The former Appendix C and references to it have been Section 6.1. The former Appendix C and references to it have been
removed, leaving a placeholder to avoid changing subsequent removed, leaving a placeholder to avoid changing subsequent
appendix numbering before IETF Last Call (and maybe its appendix numbering before IETF Last Call (and maybe its
completion) No changes have yet been made to Appendix F.2 but it completion) No changes have yet been made to Appendix F.2 but it
is likely to require some work in the next version of the is likely to require some work in the next version of the
document. This is all about Ticket #17, which should not be document. This is entirely about Ticket #17, which should not be
closed until that appendix is updated. closed until that appendix is updated.
H.3.12. Changes from draft-ietf-emailcore-rfc5321bis-07 (2021-12-04) to
-08
Other than the partial cleanup for "forwarding" and "aliasing" and
miscellaneous editorial fixes and corrections (including cleaning out
unused references), changes in this version reflect the conclusions
of the EMAILCORE interim meeting held 2021-12-09. References to
"slides" are to the deck at https://datatracker.ietf.org/doc/slides-
interim-2021-emailcore-01-sessa-chairs-slides/ and the minutes at
https://notes.ietf.org/notes-emailcore-interim-dec-2021
* (Slides 9 through 12): Removed source route examples from
Section 4.1.1.3 and added a new paragraph explaining what happened
to them. For slides 11 and 12, see below for more general
Appendix F.2 discussion.
(Cf Appendix G.7.10 and Ticket #17.)
* (Slides 13 through 14): Domain names, Section 2.3.5. Removed
"resolvable". Changed "alias" to "host alias" (although, after
looking at the actual text, the intent seems clear from the CNAME
label comment and, of course, the term "host" has been
controversial in DNS circles and the minutes are not clear on the
desirability of this change). Inserted "MUST" for the FQDN. A
cross-reference to the domain name discussion in this section has
been added to Section 4.1.1.1 in an attempt to resolve that
discussion.
In going carefully through this material, it became obvious that
the discussions in Section 2.3.5 and Section 5 were confusing and
somewhat redundant. Those sections have been rewritten to clarify
intent, hint that extensions may modify (or have modified) a few
of the rules, improve cross-references, and remove redundant text.
Domain name issues are still under discussion on the WG mailing
list as of 2021-12-18 and it is possible that the above changes
may have introduced new issues, so additional changes are
possible.
(Cf target="G-domain"/> and Tickets #9 and maybe #10.)
* Aliasing and forwarding:
Consolidated former sections 3.4 and 3.9 into a new Section 3.4,
making them subsections. The new subsection probably still needs
work and maybe an introductory paragraph, but even bringing the
two subsections together may reduce some sources of confusion
identified on the mailing list. Added cross-reference to security
considerations from the new Section 3.4.1.
All other issues discussed during the interim appear to be unresolved
and were deferred to the mailing list.
As what should be the third and final step in deprecation of source
routes and removal of them from the main text, the appendix that
discusses them (Appendix F.2) has been rewritten, adjusting language
and incorporating some materials from the former Appendix C.
Index Index
A C A C S
A A
Argument Syntax Argument Syntax
ALPHA Section 4.1.2, Paragraph 2, Item 1 ALPHA Section 4.1.2, Paragraph 2, Item 1
Additional-Registered-Clauses Section 4.4.1 Additional-Registered-Clauses Section 4.4.1
Addtl-Link Section 4.4.1 Addtl-Link Section 4.4.1
Addtl-Protocol Section 4.4.1 Addtl-Protocol Section 4.4.1
Argument Section 4.1.2 Argument Section 4.1.2
At-domain Section 4.1.2
Atom Section 4.1.2 Atom Section 4.1.2
By-domain Section 4.4.1 By-domain Section 4.4.1
CFWS Section 4.1.2, Paragraph 2, Item 2 CFWS Section 4.1.2, Paragraph 2, Item 2
CRLF Section 4.1.2, Paragraph 2, Item 1 CRLF Section 4.1.2, Paragraph 2, Item 1
DIGIT Section 4.1.2, Paragraph 2, Item 1 DIGIT Section 4.1.2, Paragraph 2, Item 1
Domain Section 4.1.2 Domain Section 4.1.2
Dot-string Section 4.1.2 Dot-string Section 4.1.2
Extended-Domain Section 4.4.1 Extended-Domain Section 4.4.1
FWS Section 4.1.2, Paragraph 2, Item 2 FWS Section 4.1.2, Paragraph 2, Item 2
For Section 4.4.1 For Section 4.4.1
skipping to change at page 120, line 18 skipping to change at page 123, line 22
Command Syntax Command Syntax
data Section 4.1.1.4, Paragraph 8, Item 1 data Section 4.1.1.4, Paragraph 8, Item 1
ehlo Section 3.2, Paragraph 1; Section 4.1.1.1, Paragraph 1 ehlo Section 3.2, Paragraph 1; Section 4.1.1.1, Paragraph 1
expn Section 4.1.1.7, Paragraph 4, Item 1 expn Section 4.1.1.7, Paragraph 4, Item 1
helo Section 4.1.1.1, Paragraph 1 helo Section 4.1.1.1, Paragraph 1
help Section 4.1.1.8, Paragraph 5, Item 1 help Section 4.1.1.8, Paragraph 5, Item 1
mail Section 4.1.1.2 mail Section 4.1.1.2
noop Section 4.1.1.9, Paragraph 4, Item 1 noop Section 4.1.1.9, Paragraph 4, Item 1
quit Section 4.1.1.10, Paragraph 5, Item 1 quit Section 4.1.1.10, Paragraph 5, Item 1
rcpt Section 4.1.1.3, Paragraph 18 rcpt Section 4.1.1.3, Paragraph 15
rset Section 4.1.1.5, Paragraph 4, Item 1 rset Section 4.1.1.5, Paragraph 4, Item 1
send, saml, soml Appendix G.7.13, Paragraph 1 send, saml, soml Appendix G.7.13, Paragraph 1
vrfy Section 4.1.1.6, Paragraph 4, Item 1 vrfy Section 4.1.1.6, Paragraph 4, Item 1
S
Source Routes Appendix F.2
A-d-l Appendix F.2
At-domain Appendix F.2
Path Appendix F.2
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
United States of America United States of America
Email: john-ietf@jck.com Email: john-ietf@jck.com
 End of changes. 142 change blocks. 
433 lines changed or deleted 528 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/