5324 lines
221 KiB
Plaintext
5324 lines
221 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
Network Working Group J. Klensin
|
||
Request for Comments: 5321 October 2008
|
||
Obsoletes: 2821
|
||
Updates: 1123
|
||
Category: Standards Track
|
||
|
||
|
||
Simple Mail Transfer Protocol
|
||
|
||
Status of This Memo
|
||
|
||
This document specifies an Internet standards track protocol for the
|
||
Internet community, and requests discussion and suggestions for
|
||
improvements. Please refer to the current edition of the "Internet
|
||
Official Protocol Standards" (STD 1) for the standardization state
|
||
and status of this protocol. Distribution of this memo is unlimited.
|
||
|
||
Abstract
|
||
|
||
This document is a specification of the basic protocol for Internet
|
||
electronic mail transport. It consolidates, updates, and clarifies
|
||
several previous documents, making all or parts of most of them
|
||
obsolete. It covers the SMTP extension mechanisms and best practices
|
||
for the contemporary Internet, but does not provide details about
|
||
particular extensions. Although SMTP was designed as a mail
|
||
transport and delivery protocol, this specification also contains
|
||
information that is important to its use as a "mail submission"
|
||
protocol for "split-UA" (User Agent) mail reading systems and mobile
|
||
environments.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 1]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
Table of Contents
|
||
|
||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
|
||
1.1. Transport of Electronic Mail . . . . . . . . . . . . . . . 5
|
||
1.2. History and Context for This Document . . . . . . . . . . 5
|
||
1.3. Document Conventions . . . . . . . . . . . . . . . . . . . 6
|
||
2. The SMTP Model . . . . . . . . . . . . . . . . . . . . . . . . 7
|
||
2.1. Basic Structure . . . . . . . . . . . . . . . . . . . . . 7
|
||
2.2. The Extension Model . . . . . . . . . . . . . . . . . . . 9
|
||
2.2.1. Background . . . . . . . . . . . . . . . . . . . . . . 9
|
||
2.2.2. Definition and Registration of Extensions . . . . . . 10
|
||
2.2.3. Special Issues with Extensions . . . . . . . . . . . . 11
|
||
2.3. SMTP Terminology . . . . . . . . . . . . . . . . . . . . . 11
|
||
2.3.1. Mail Objects . . . . . . . . . . . . . . . . . . . . . 11
|
||
2.3.2. Senders and Receivers . . . . . . . . . . . . . . . . 12
|
||
2.3.3. Mail Agents and Message Stores . . . . . . . . . . . . 12
|
||
2.3.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . 13
|
||
2.3.5. Domain Names . . . . . . . . . . . . . . . . . . . . . 13
|
||
2.3.6. Buffer and State Table . . . . . . . . . . . . . . . . 14
|
||
2.3.7. Commands and Replies . . . . . . . . . . . . . . . . . 14
|
||
2.3.8. Lines . . . . . . . . . . . . . . . . . . . . . . . . 14
|
||
2.3.9. Message Content and Mail Data . . . . . . . . . . . . 15
|
||
2.3.10. Originator, Delivery, Relay, and Gateway Systems . . . 15
|
||
2.3.11. Mailbox and Address . . . . . . . . . . . . . . . . . 15
|
||
2.4. General Syntax Principles and Transaction Model . . . . . 16
|
||
3. The SMTP Procedures: An Overview . . . . . . . . . . . . . . . 17
|
||
3.1. Session Initiation . . . . . . . . . . . . . . . . . . . . 18
|
||
3.2. Client Initiation . . . . . . . . . . . . . . . . . . . . 18
|
||
3.3. Mail Transactions . . . . . . . . . . . . . . . . . . . . 19
|
||
3.4. Forwarding for Address Correction or Updating . . . . . . 21
|
||
3.5. Commands for Debugging Addresses . . . . . . . . . . . . . 22
|
||
3.5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 22
|
||
3.5.2. VRFY Normal Response . . . . . . . . . . . . . . . . . 24
|
||
3.5.3. Meaning of VRFY or EXPN Success Response . . . . . . . 25
|
||
3.5.4. Semantics and Applications of EXPN . . . . . . . . . . 26
|
||
3.6. Relaying and Mail Routing . . . . . . . . . . . . . . . . 26
|
||
3.6.1. Source Routes and Relaying . . . . . . . . . . . . . . 26
|
||
3.6.2. Mail eXchange Records and Relaying . . . . . . . . . . 26
|
||
3.6.3. Message Submission Servers as Relays . . . . . . . . . 27
|
||
3.7. Mail Gatewaying . . . . . . . . . . . . . . . . . . . . . 28
|
||
3.7.1. Header Fields in Gatewaying . . . . . . . . . . . . . 28
|
||
3.7.2. Received Lines in Gatewaying . . . . . . . . . . . . . 29
|
||
3.7.3. Addresses in Gatewaying . . . . . . . . . . . . . . . 29
|
||
3.7.4. Other Header Fields in Gatewaying . . . . . . . . . . 29
|
||
3.7.5. Envelopes in Gatewaying . . . . . . . . . . . . . . . 30
|
||
3.8. Terminating Sessions and Connections . . . . . . . . . . . 30
|
||
3.9. Mailing Lists and Aliases . . . . . . . . . . . . . . . . 31
|
||
3.9.1. Alias . . . . . . . . . . . . . . . . . . . . . . . . 31
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 2]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
3.9.2. List . . . . . . . . . . . . . . . . . . . . . . . . . 31
|
||
4. The SMTP Specifications . . . . . . . . . . . . . . . . . . . 32
|
||
4.1. SMTP Commands . . . . . . . . . . . . . . . . . . . . . . 32
|
||
4.1.1. Command Semantics and Syntax . . . . . . . . . . . . . 32
|
||
4.1.2. Command Argument Syntax . . . . . . . . . . . . . . . 41
|
||
4.1.3. Address Literals . . . . . . . . . . . . . . . . . . . 43
|
||
4.1.4. Order of Commands . . . . . . . . . . . . . . . . . . 44
|
||
4.1.5. Private-Use Commands . . . . . . . . . . . . . . . . . 46
|
||
4.2. SMTP Replies . . . . . . . . . . . . . . . . . . . . . . . 46
|
||
4.2.1. Reply Code Severities and Theory . . . . . . . . . . . 48
|
||
4.2.2. Reply Codes by Function Groups . . . . . . . . . . . . 50
|
||
4.2.3. Reply Codes in Numeric Order . . . . . . . . . . . . . 52
|
||
4.2.4. Reply Code 502 . . . . . . . . . . . . . . . . . . . . 53
|
||
4.2.5. Reply Codes after DATA and the Subsequent
|
||
<CRLF>.<CRLF> . . . . . . . . . . . . . . . . . . . . 53
|
||
4.3. Sequencing of Commands and Replies . . . . . . . . . . . . 54
|
||
4.3.1. Sequencing Overview . . . . . . . . . . . . . . . . . 54
|
||
4.3.2. Command-Reply Sequences . . . . . . . . . . . . . . . 55
|
||
4.4. Trace Information . . . . . . . . . . . . . . . . . . . . 57
|
||
4.5. Additional Implementation Issues . . . . . . . . . . . . . 61
|
||
4.5.1. Minimum Implementation . . . . . . . . . . . . . . . . 61
|
||
4.5.2. Transparency . . . . . . . . . . . . . . . . . . . . . 62
|
||
4.5.3. Sizes and Timeouts . . . . . . . . . . . . . . . . . . 62
|
||
4.5.3.1. Size Limits and Minimums . . . . . . . . . . . . . 62
|
||
4.5.3.1.1. Local-part . . . . . . . . . . . . . . . . . . 63
|
||
4.5.3.1.2. Domain . . . . . . . . . . . . . . . . . . . . 63
|
||
4.5.3.1.3. Path . . . . . . . . . . . . . . . . . . . . . 63
|
||
4.5.3.1.4. Command Line . . . . . . . . . . . . . . . . . 63
|
||
4.5.3.1.5. Reply Line . . . . . . . . . . . . . . . . . . 63
|
||
4.5.3.1.6. Text Line . . . . . . . . . . . . . . . . . . 63
|
||
4.5.3.1.7. Message Content . . . . . . . . . . . . . . . 63
|
||
4.5.3.1.8. Recipients Buffer . . . . . . . . . . . . . . 64
|
||
4.5.3.1.9. Treatment When Limits Exceeded . . . . . . . . 64
|
||
4.5.3.1.10. Too Many Recipients Code . . . . . . . . . . . 64
|
||
4.5.3.2. Timeouts . . . . . . . . . . . . . . . . . . . . . 65
|
||
4.5.3.2.1. Initial 220 Message: 5 Minutes . . . . . . . . 65
|
||
4.5.3.2.2. MAIL Command: 5 Minutes . . . . . . . . . . . 65
|
||
4.5.3.2.3. RCPT Command: 5 Minutes . . . . . . . . . . . 65
|
||
4.5.3.2.4. DATA Initiation: 2 Minutes . . . . . . . . . . 66
|
||
4.5.3.2.5. Data Block: 3 Minutes . . . . . . . . . . . . 66
|
||
4.5.3.2.6. DATA Termination: 10 Minutes. . . . . . . . . 66
|
||
4.5.3.2.7. Server Timeout: 5 Minutes. . . . . . . . . . . 66
|
||
4.5.4. Retry Strategies . . . . . . . . . . . . . . . . . . . 66
|
||
4.5.5. Messages with a Null Reverse-Path . . . . . . . . . . 68
|
||
5. Address Resolution and Mail Handling . . . . . . . . . . . . . 69
|
||
5.1. Locating the Target Host . . . . . . . . . . . . . . . . . 69
|
||
5.2. IPv6 and MX Records . . . . . . . . . . . . . . . . . . . 71
|
||
6. Problem Detection and Handling . . . . . . . . . . . . . . . . 71
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 3]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
6.1. Reliable Delivery and Replies by Email . . . . . . . . . . 71
|
||
6.2. Unwanted, Unsolicited, and "Attack" Messages . . . . . . . 72
|
||
6.3. Loop Detection . . . . . . . . . . . . . . . . . . . . . . 73
|
||
6.4. Compensating for Irregularities . . . . . . . . . . . . . 73
|
||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 75
|
||
7.1. Mail Security and Spoofing . . . . . . . . . . . . . . . . 75
|
||
7.2. "Blind" Copies . . . . . . . . . . . . . . . . . . . . . . 76
|
||
7.3. VRFY, EXPN, and Security . . . . . . . . . . . . . . . . . 76
|
||
7.4. Mail Rerouting Based on the 251 and 551 Response Codes . . 77
|
||
7.5. Information Disclosure in Announcements . . . . . . . . . 77
|
||
7.6. Information Disclosure in Trace Fields . . . . . . . . . . 78
|
||
7.7. Information Disclosure in Message Forwarding . . . . . . . 78
|
||
7.8. Resistance to Attacks . . . . . . . . . . . . . . . . . . 78
|
||
7.9. Scope of Operation of SMTP Servers . . . . . . . . . . . . 78
|
||
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 79
|
||
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 80
|
||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 81
|
||
10.1. Normative References . . . . . . . . . . . . . . . . . . . 81
|
||
10.2. Informative References . . . . . . . . . . . . . . . . . . 82
|
||
Appendix A. TCP Transport Service . . . . . . . . . . . . . . . . 85
|
||
Appendix B. Generating SMTP Commands from RFC 822 Header
|
||
Fields . . . . . . . . . . . . . . . . . . . . . . . 85
|
||
Appendix C. Source Routes . . . . . . . . . . . . . . . . . . . . 86
|
||
Appendix D. Scenarios . . . . . . . . . . . . . . . . . . . . . . 87
|
||
D.1. A Typical SMTP Transaction Scenario . . . . . . . . . . . 88
|
||
D.2. Aborted SMTP Transaction Scenario . . . . . . . . . . . . 89
|
||
D.3. Relayed Mail Scenario . . . . . . . . . . . . . . . . . . 90
|
||
D.4. Verifying and Sending Scenario . . . . . . . . . . . . . . 92
|
||
Appendix E. Other Gateway Issues . . . . . . . . . . . . . . . . 92
|
||
Appendix F. Deprecated Features of RFC 821 . . . . . . . . . . . 93
|
||
F.1. TURN . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
|
||
F.2. Source Routing . . . . . . . . . . . . . . . . . . . . . . 93
|
||
F.3. HELO . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
|
||
F.4. #-literals . . . . . . . . . . . . . . . . . . . . . . . . 94
|
||
F.5. Dates and Years . . . . . . . . . . . . . . . . . . . . . 94
|
||
F.6. Sending versus Mailing . . . . . . . . . . . . . . . . . . 94
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 4]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
1. Introduction
|
||
|
||
1.1. Transport of Electronic Mail
|
||
|
||
The objective of the Simple Mail Transfer Protocol (SMTP) is to
|
||
transfer mail reliably and efficiently.
|
||
|
||
SMTP is independent of the particular transmission subsystem and
|
||
requires only a reliable ordered data stream channel. While this
|
||
document specifically discusses transport over TCP, other transports
|
||
are possible. Appendices to RFC 821 [1] describe some of them.
|
||
|
||
An important feature of SMTP is its capability to transport mail
|
||
across multiple networks, usually referred to as "SMTP mail relaying"
|
||
(see Section 3.6). A network consists of the mutually-TCP-accessible
|
||
hosts on the public Internet, the mutually-TCP-accessible hosts on a
|
||
firewall-isolated TCP/IP Intranet, or hosts in some other LAN or WAN
|
||
environment utilizing a non-TCP transport-level protocol. Using
|
||
SMTP, a process can transfer mail to another process on the same
|
||
network or to some other network via a relay or gateway process
|
||
accessible to both networks.
|
||
|
||
In this way, a mail message may pass through a number of intermediate
|
||
relay or gateway hosts on its path from sender to ultimate recipient.
|
||
The Mail eXchanger mechanisms of the domain name system (RFC 1035
|
||
[2], RFC 974 [12], and Section 5 of this document) are used to
|
||
identify the appropriate next-hop destination for a message being
|
||
transported.
|
||
|
||
1.2. History and Context for This Document
|
||
|
||
This document is a specification of the basic protocol for the
|
||
Internet electronic mail transport. It consolidates, updates and
|
||
clarifies, but does not add new or change existing functionality of
|
||
the following:
|
||
|
||
o the original SMTP (Simple Mail Transfer Protocol) specification of
|
||
RFC 821 [1],
|
||
|
||
o domain name system requirements and implications for mail
|
||
transport from RFC 1035 [2] and RFC 974 [12],
|
||
|
||
o the clarifications and applicability statements in RFC 1123 [3],
|
||
and
|
||
|
||
o material drawn from the SMTP Extension mechanisms in RFC 1869
|
||
[13].
|
||
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 5]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
o Editorial and clarification changes to RFC 2821 [14] to bring that
|
||
specification to Draft Standard.
|
||
|
||
It obsoletes RFC 821, RFC 974, RFC 1869, and RFC 2821 and updates RFC
|
||
1123 (replacing the mail transport materials of RFC 1123). However,
|
||
RFC 821 specifies some features that were not in significant use in
|
||
the Internet by the mid-1990s and (in appendices) some additional
|
||
transport models. Those sections are omitted here in the interest of
|
||
clarity and brevity; readers needing them should refer to RFC 821.
|
||
|
||
It also includes some additional material from RFC 1123 that required
|
||
amplification. This material has been identified in multiple ways,
|
||
mostly by tracking flaming on various lists and newsgroups and
|
||
problems of unusual readings or interpretations that have appeared as
|
||
the SMTP extensions have been deployed. Where this specification
|
||
moves beyond consolidation and actually differs from earlier
|
||
documents, it supersedes them technically as well as textually.
|
||
|
||
Although SMTP was designed as a mail transport and delivery protocol,
|
||
this specification also contains information that is important to its
|
||
use as a "mail submission" protocol, as recommended for Post Office
|
||
Protocol (POP) (RFC 937 [15], RFC 1939 [16]) and IMAP (RFC 3501
|
||
[17]). In general, the separate mail submission protocol specified
|
||
in RFC 4409 [18] is now preferred to direct use of SMTP; more
|
||
discussion of that subject appears in that document.
|
||
|
||
Section 2.3 provides definitions of terms specific to this document.
|
||
Except when the historical terminology is necessary for clarity, this
|
||
document uses the current 'client' and 'server' terminology to
|
||
identify the sending and receiving SMTP processes, respectively.
|
||
|
||
A companion document, RFC 5322 [4], discusses message header sections
|
||
and bodies and specifies formats and structures for them.
|
||
|
||
1.3. Document Conventions
|
||
|
||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
||
document are to be interpreted as described in RFC 2119 [5]. As each
|
||
of these terms was intentionally and carefully chosen to improve the
|
||
interoperability of email, each use of these terms is to be treated
|
||
as a conformance requirement.
|
||
|
||
Because this document has a long history and to avoid the risk of
|
||
various errors and of confusing readers and documents that point to
|
||
this one, most examples and the domain names they contain are
|
||
preserved from RFC 2821. Readers are cautioned that these are
|
||
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 6]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
illustrative examples that should not actually be used in either code
|
||
or configuration files.
|
||
|
||
2. The SMTP Model
|
||
|
||
2.1. Basic Structure
|
||
|
||
The SMTP design can be pictured as:
|
||
|
||
+----------+ +----------+
|
||
+------+ | | | |
|
||
| User |<-->| | SMTP | |
|
||
+------+ | Client- |Commands/Replies| Server- |
|
||
+------+ | SMTP |<-------------->| SMTP | +------+
|
||
| File |<-->| | and Mail | |<-->| File |
|
||
|System| | | | | |System|
|
||
+------+ +----------+ +----------+ +------+
|
||
SMTP client SMTP server
|
||
|
||
When an SMTP client has a message to transmit, it establishes a two-
|
||
way transmission channel to an SMTP server. The responsibility of an
|
||
SMTP client is to transfer mail messages to one or more SMTP servers,
|
||
or report its failure to do so.
|
||
|
||
The means by which a mail message is presented to an SMTP client, and
|
||
how that client determines the identifier(s) ("names") of the
|
||
domain(s) to which mail messages are to be transferred, is a local
|
||
matter, and is not addressed by this document. In some cases, the
|
||
designated domain(s), or those determined by an SMTP client, will
|
||
identify the final destination(s) of the mail message. In other
|
||
cases, common with SMTP clients associated with implementations of
|
||
the POP (RFC 937 [15], RFC 1939 [16]) or IMAP (RFC 3501 [17])
|
||
protocols, or when the SMTP client is inside an isolated transport
|
||
service environment, the domain determined will identify an
|
||
intermediate destination through which all mail messages are to be
|
||
relayed. SMTP clients that transfer all traffic regardless of the
|
||
target domains associated with the individual messages, or that do
|
||
not maintain queues for retrying message transmissions that initially
|
||
cannot be completed, may otherwise conform to this specification but
|
||
are not considered fully-capable. Fully-capable SMTP
|
||
implementations, including the relays used by these less capable
|
||
ones, and their destinations, are expected to support all of the
|
||
queuing, retrying, and alternate address functions discussed in this
|
||
specification. In many situations and configurations, the less-
|
||
capable clients discussed above SHOULD be using the message
|
||
submission protocol (RFC 4409 [18]) rather than SMTP.
|
||
|
||
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 7]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
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
|
||
a message is to be transferred, and then performs that transfer, is
|
||
covered by this document. To effect a mail transfer to an SMTP
|
||
server, an SMTP client establishes a two-way transmission channel to
|
||
that SMTP server. An SMTP client determines the address of an
|
||
appropriate host running an SMTP server by resolving a destination
|
||
domain name to either an intermediate Mail eXchanger host or a final
|
||
target host.
|
||
|
||
An SMTP server may be either the ultimate destination or an
|
||
intermediate "relay" (that is, it may assume the role of an SMTP
|
||
client after receiving the message) or "gateway" (that is, it may
|
||
transport the message further using some protocol other than SMTP).
|
||
SMTP commands are generated by the SMTP client and sent to the SMTP
|
||
server. SMTP replies are sent from the SMTP server to the SMTP
|
||
client in response to the commands.
|
||
|
||
In other words, message transfer can occur in a single connection
|
||
between the original SMTP-sender and the final SMTP-recipient, or can
|
||
occur in a series of hops through intermediary systems. In either
|
||
case, once the server has issued a success response at the end of the
|
||
mail data, a formal handoff of responsibility for the message occurs:
|
||
the protocol requires that a server MUST accept responsibility for
|
||
either delivering the message or properly reporting the failure to do
|
||
so (see Sections 6.1, 6.2, and 7.8, below).
|
||
|
||
Once the transmission channel is established and initial handshaking
|
||
is completed, the SMTP client normally initiates a mail transaction.
|
||
Such a transaction consists of a series of commands to specify the
|
||
originator and destination of the mail and transmission of the
|
||
message content (including any lines in the header section or other
|
||
structure) itself. When the same message is sent to multiple
|
||
recipients, this protocol encourages the transmission of only one
|
||
copy of the data for all recipients at the same destination (or
|
||
intermediate relay) host.
|
||
|
||
The server responds to each command with a reply; replies may
|
||
indicate that the command was accepted, that additional commands are
|
||
expected, or that a temporary or permanent error condition exists.
|
||
Commands specifying the sender or recipients may include server-
|
||
permitted SMTP service extension requests, as discussed in
|
||
Section 2.2. The dialog is purposely lock-step, one-at-a-time,
|
||
although this can be modified by mutually agreed upon extension
|
||
requests such as command pipelining (RFC 2920 [19]).
|
||
|
||
Once a given mail message has been transmitted, the client may either
|
||
request that the connection be shut down or may initiate other mail
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 8]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
transactions. In addition, an SMTP client may use a connection to an
|
||
SMTP server for ancillary services such as verification of email
|
||
addresses or retrieval of mailing list subscriber addresses.
|
||
|
||
As suggested above, this protocol provides mechanisms for the
|
||
transmission of mail. Historically, this transmission normally
|
||
occurred directly from the sending user's host to the receiving
|
||
user's host when the two hosts are connected to the same transport
|
||
service. When they are not connected to the same transport service,
|
||
transmission occurs via one or more relay SMTP servers. A very
|
||
common case in the Internet today involves submission of the original
|
||
message to an intermediate, "message submission" server, which is
|
||
similar to a relay but has some additional properties; such servers
|
||
are discussed in Section 2.3.10 and at some length in RFC 4409 [18].
|
||
An intermediate host that acts as either an SMTP relay or as a
|
||
gateway into some other transmission environment is usually selected
|
||
through the use of the domain name service (DNS) Mail eXchanger
|
||
mechanism.
|
||
|
||
Usually, intermediate hosts are determined via the DNS MX record, not
|
||
by explicit "source" routing (see Section 5 and Appendix C and
|
||
Appendix F.2).
|
||
|
||
2.2. The Extension Model
|
||
|
||
2.2.1. Background
|
||
|
||
In an effort that started in 1990, approximately a decade after RFC
|
||
821 was completed, the protocol was modified with a "service
|
||
extensions" model that permits the client and server to agree to
|
||
utilize shared functionality beyond the original SMTP requirements.
|
||
The SMTP extension mechanism defines a means whereby an extended SMTP
|
||
client and server may recognize each other, and the server can inform
|
||
the client as to the service extensions that it supports.
|
||
|
||
Contemporary SMTP implementations MUST support the basic extension
|
||
mechanisms. For instance, servers MUST support the EHLO command even
|
||
if they do not implement any specific extensions and clients SHOULD
|
||
preferentially utilize EHLO rather than HELO. (However, for
|
||
compatibility with older conforming implementations, SMTP clients and
|
||
servers MUST support the original HELO mechanisms as a fallback.)
|
||
Unless the different characteristics of HELO must be identified for
|
||
interoperability purposes, this document discusses only EHLO.
|
||
|
||
SMTP is widely deployed and high-quality implementations have proven
|
||
to be very robust. However, the Internet community now considers
|
||
some services to be important that were not anticipated when the
|
||
protocol was first designed. If support for those services is to be
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 9]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
added, it must be done in a way that permits older implementations to
|
||
continue working acceptably. The extension framework consists of:
|
||
|
||
o The SMTP command EHLO, superseding the earlier HELO,
|
||
|
||
o a registry of SMTP service extensions,
|
||
|
||
o additional parameters to the SMTP MAIL and RCPT commands, and
|
||
|
||
o optional replacements for commands defined in this protocol, such
|
||
as for DATA in non-ASCII transmissions (RFC 3030 [20]).
|
||
|
||
SMTP's strength comes primarily from its simplicity. Experience with
|
||
many protocols has shown that protocols with few options tend towards
|
||
ubiquity, whereas protocols with many options tend towards obscurity.
|
||
|
||
Each and every extension, regardless of its benefits, must be
|
||
carefully scrutinized with respect to its implementation, deployment,
|
||
and interoperability costs. In many cases, the cost of extending the
|
||
SMTP service will likely outweigh the benefit.
|
||
|
||
2.2.2. Definition and Registration of Extensions
|
||
|
||
The IANA maintains a registry of SMTP service extensions. A
|
||
corresponding EHLO keyword value is associated with each extension.
|
||
Each service extension registered with the IANA must be defined in a
|
||
formal Standards-Track or IESG-approved Experimental protocol
|
||
document. The definition must include:
|
||
|
||
o the textual name of the SMTP service extension;
|
||
|
||
o the EHLO keyword value associated with the extension;
|
||
|
||
o the syntax and possible values of parameters associated with the
|
||
EHLO keyword value;
|
||
|
||
o any additional SMTP verbs associated with the extension
|
||
(additional verbs will usually be, but are not required to be, the
|
||
same as the EHLO keyword value);
|
||
|
||
o any new parameters the extension associates with the MAIL or RCPT
|
||
verbs;
|
||
|
||
o a description of how support for the extension affects the
|
||
behavior of a server and client SMTP; and
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 10]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
o the increment by which the extension is increasing the maximum
|
||
length of the commands MAIL and/or RCPT, over that specified in
|
||
this Standard.
|
||
|
||
In addition, any EHLO keyword value starting with an upper or lower
|
||
case "X" refers to a local SMTP service extension used exclusively
|
||
through bilateral agreement. Keywords beginning with "X" MUST NOT be
|
||
used in a registered service extension. Conversely, keyword values
|
||
presented in the EHLO response that do not begin with "X" MUST
|
||
correspond to a Standard, Standards-Track, or IESG-approved
|
||
Experimental SMTP service extension registered with IANA. A
|
||
conforming server MUST NOT offer non-"X"-prefixed keyword values that
|
||
are not described in a registered extension.
|
||
|
||
Additional verbs and parameter names are bound by the same rules as
|
||
EHLO keywords; specifically, verbs beginning with "X" are local
|
||
extensions that may not be registered or standardized. Conversely,
|
||
verbs not beginning with "X" must always be registered.
|
||
|
||
2.2.3. Special Issues with Extensions
|
||
|
||
Extensions that change fairly basic properties of SMTP operation are
|
||
permitted. The text in other sections of this document must be
|
||
understood in that context. In particular, extensions can change the
|
||
minimum limits specified in Section 4.5.3, can change the ASCII
|
||
character set requirement as mentioned above, or can introduce some
|
||
optional modes of message handling.
|
||
|
||
In particular, if an extension implies that the delivery path
|
||
normally supports special features of that extension, and an
|
||
intermediate SMTP system finds a next hop that does not support the
|
||
required extension, it MAY choose, based on the specific extension
|
||
and circumstances, to requeue the message and try later and/or try an
|
||
alternate MX host. If this strategy is employed, the timeout to fall
|
||
back to an unextended format (if one is available) SHOULD be less
|
||
than the normal timeout for bouncing as undeliverable (e.g., if
|
||
normal timeout is three days, the requeue timeout before attempting
|
||
to transmit the mail without the extension might be one day).
|
||
|
||
2.3. SMTP Terminology
|
||
|
||
2.3.1. Mail Objects
|
||
|
||
SMTP transports a mail object. A mail object contains an envelope
|
||
and content.
|
||
|
||
The SMTP envelope is sent as a series of SMTP protocol units
|
||
(described in Section 3). It consists of an originator address (to
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 11]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
which error reports should be directed), one or more recipient
|
||
addresses, and optional protocol extension material. Historically,
|
||
variations on the reverse-path (originator) address specification
|
||
command (MAIL) could be used to specify alternate delivery modes,
|
||
such as immediate display; those variations have now been deprecated
|
||
(see Appendix F and Appendix F.6).
|
||
|
||
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
|
||
other contemporary standards, the header section consists of a
|
||
collection of header fields, each consisting of a header name, a
|
||
colon, and data, structured as in the message format specification
|
||
(RFC 5322 [4]); the body, if structured, is defined according to MIME
|
||
(RFC 2045 [21]). The content is textual in nature, expressed using
|
||
the US-ASCII repertoire [6]. Although SMTP extensions (such as
|
||
"8BITMIME", RFC 1652 [22]) may relax this restriction for the content
|
||
body, the content header fields are always encoded using the US-ASCII
|
||
repertoire. Two MIME extensions (RFC 2047 [23] and RFC 2231 [24])
|
||
define an algorithm for representing header values outside the US-
|
||
ASCII repertoire, while still encoding them using the US-ASCII
|
||
repertoire.
|
||
|
||
2.3.2. Senders and Receivers
|
||
|
||
In RFC 821, the two hosts participating in an SMTP transaction were
|
||
described as the "SMTP-sender" and "SMTP-receiver". This document
|
||
has been changed to reflect current industry terminology and hence
|
||
refers to them as the "SMTP client" (or sometimes just "the client")
|
||
and "SMTP server" (or just "the server"), respectively. Since a
|
||
given host may act both as server and client in a relay situation,
|
||
"receiver" and "sender" terminology is still used where needed for
|
||
clarity.
|
||
|
||
2.3.3. Mail Agents and Message Stores
|
||
|
||
Additional mail system terminology became common after RFC 821 was
|
||
published and, where convenient, is used in this specification. In
|
||
particular, SMTP servers and clients provide a mail transport service
|
||
and therefore act as "Mail Transfer Agents" (MTAs). "Mail User
|
||
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
|
||
transmitted from a user and hand it off to an MTA; the final
|
||
("delivery") MTA would be thought of as handing the mail off to an
|
||
MUA (or at least transferring responsibility to it, e.g., by
|
||
depositing the message in a "message store"). However, while these
|
||
terms are used with at least the appearance of great precision in
|
||
other environments, the implied boundaries between MUAs and MTAs
|
||
often do not accurately match common, and conforming, practices with
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 12]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
Internet mail. Hence, the reader should be cautious about inferring
|
||
the strong relationships and responsibilities that might be implied
|
||
if these terms were used elsewhere.
|
||
|
||
2.3.4. Host
|
||
|
||
For the purposes of this specification, a host is a computer system
|
||
attached to the Internet (or, in some cases, to a private TCP/IP
|
||
network) and supporting the SMTP protocol. Hosts are known by names
|
||
(see the next section); they SHOULD NOT be identified by numerical
|
||
addresses, i.e., by address literals as described in Section 4.1.2.
|
||
|
||
2.3.5. Domain Names
|
||
|
||
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
|
||
of a top-level domain used by itself in an email address, a single
|
||
string is used without any dots. This makes the requirement,
|
||
described in more detail below, that only fully-qualified domain
|
||
names appear in SMTP transactions on the public Internet,
|
||
particularly important where top-level domains are involved. These
|
||
components ("labels" in DNS terminology, RFC 1035 [2]) are restricted
|
||
for SMTP purposes to consist of a sequence of letters, digits, and
|
||
hyphens drawn from the ASCII character set [6]. Domain names are
|
||
used as names of hosts and of other entities in the domain name
|
||
hierarchy. For example, a domain may refer to an alias (label of a
|
||
CNAME RR) or the label of Mail eXchanger records to be used to
|
||
deliver mail instead of representing a host name. See RFC 1035 [2]
|
||
and Section 5 of this specification.
|
||
|
||
The domain name, as described in this document and in RFC 1035 [2],
|
||
is the entire, fully-qualified name (often referred to as an "FQDN").
|
||
A domain name that is not in FQDN form is no more than a local alias.
|
||
Local aliases MUST NOT appear in any SMTP transaction.
|
||
|
||
Only resolvable, fully-qualified domain names (FQDNs) are permitted
|
||
when domain names are used in SMTP. In other words, names that can
|
||
be resolved to MX RRs or address (i.e., A or AAAA) RRs (as discussed
|
||
in Section 5) are permitted, as are CNAME RRs whose targets can be
|
||
resolved, in turn, to MX or address RRs. Local nicknames or
|
||
unqualified names MUST NOT be used. There are two exceptions to the
|
||
rule requiring FQDNs:
|
||
|
||
o The domain name given in the EHLO command MUST be either a primary
|
||
host name (a domain name that resolves to an address RR) or, if
|
||
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.4.
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 13]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
o The reserved mailbox name "postmaster" may be used in a RCPT
|
||
command without domain qualification (see Section 4.1.1.3) and
|
||
MUST be accepted if so used.
|
||
|
||
2.3.6. Buffer and State Table
|
||
|
||
SMTP sessions are stateful, with both parties carefully maintaining a
|
||
common view of the current state. In this document, we model this
|
||
state by a virtual "buffer" and a "state table" on the server that
|
||
may be used by the client to, for example, "clear the buffer" or
|
||
"reset the state table", causing the information in the buffer to be
|
||
discarded and the state to be returned to some previous state.
|
||
|
||
2.3.7. Commands and Replies
|
||
|
||
SMTP commands and, unless altered by a service extension, message
|
||
data, are transmitted from the sender to the receiver via the
|
||
transmission channel in "lines".
|
||
|
||
An SMTP reply is an acknowledgment (positive or negative) sent in
|
||
"lines" from receiver to sender via the transmission channel in
|
||
response to a command. The general form of a reply is a numeric
|
||
completion code (indicating failure or success) usually followed by a
|
||
text string. The codes are for use by programs and the text is
|
||
usually intended for human users. RFC 3463 [25], specifies further
|
||
structuring of the reply strings, including the use of supplemental
|
||
and more specific completion codes (see also RFC 5248 [26]).
|
||
|
||
2.3.8. Lines
|
||
|
||
Lines consist of zero or more data characters terminated by the
|
||
sequence ASCII character "CR" (hex value 0D) followed immediately by
|
||
ASCII character "LF" (hex value 0A). This termination sequence is
|
||
denoted as <CRLF> in this document. Conforming implementations MUST
|
||
NOT recognize or generate any other character or character sequence
|
||
as a line terminator. Limits MAY be imposed on line lengths by
|
||
servers (see Section 4).
|
||
|
||
In addition, the appearance of "bare" "CR" or "LF" characters in text
|
||
(i.e., either without the other) has a long history of causing
|
||
problems in mail implementations and applications that use the mail
|
||
system as a tool. SMTP client implementations MUST NOT transmit
|
||
these characters except when they are intended as line terminators
|
||
and then MUST, as indicated above, transmit them only as a <CRLF>
|
||
sequence.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 14]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
2.3.9. Message Content and Mail Data
|
||
|
||
The terms "message content" and "mail data" are used interchangeably
|
||
in this document to describe the material transmitted after the DATA
|
||
command is accepted and before the end of data indication is
|
||
transmitted. Message content includes the message header section and
|
||
the possibly structured message body. The MIME specification (RFC
|
||
2045 [21]) provides the standard mechanisms for structured message
|
||
bodies.
|
||
|
||
2.3.10. Originator, Delivery, Relay, and Gateway Systems
|
||
|
||
This specification makes a distinction among four types of SMTP
|
||
systems, based on the role those systems play in transmitting
|
||
electronic mail. An "originating" system (sometimes called an SMTP
|
||
originator) introduces mail into the Internet or, more generally,
|
||
into a transport service environment. A "delivery" SMTP system is
|
||
one that receives mail from a transport service environment and
|
||
passes it to a mail user agent or deposits it in a message store that
|
||
a mail user agent is expected to subsequently access. A "relay" SMTP
|
||
system (usually referred to just as a "relay") receives mail from an
|
||
SMTP client and transmits it, without modification to the message
|
||
data other than adding trace information, to another SMTP server for
|
||
further relaying or for delivery.
|
||
|
||
A "gateway" SMTP system (usually referred to just as a "gateway")
|
||
receives mail from a client system in one transport environment and
|
||
transmits it to a server system in another transport environment.
|
||
Differences in protocols or message semantics between the transport
|
||
environments on either side of a gateway may require that the gateway
|
||
system perform transformations to the message that are not permitted
|
||
to SMTP relay systems. For the purposes of this specification,
|
||
firewalls that rewrite addresses should be considered as gateways,
|
||
even if SMTP is used on both sides of them (see RFC 2979 [27]).
|
||
|
||
2.3.11. Mailbox and Address
|
||
|
||
As used in this specification, an "address" is a character string
|
||
that identifies a user to whom mail will be sent or a location into
|
||
which mail will be deposited. The term "mailbox" refers to that
|
||
depository. The two terms are typically used interchangeably unless
|
||
the distinction between the location in which mail is placed (the
|
||
mailbox) and a reference to it (the address) is important. An
|
||
address normally consists of user and domain specifications. The
|
||
standard mailbox naming convention is defined to be
|
||
"local-part@domain"; contemporary usage permits a much broader set of
|
||
applications than simple "user names". Consequently, and due to a
|
||
long history of problems when intermediate hosts have attempted to
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 15]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
optimize transport by modifying them, the local-part MUST be
|
||
interpreted and assigned semantics only by the host specified in the
|
||
domain part of the address.
|
||
|
||
2.4. General Syntax Principles and Transaction Model
|
||
|
||
SMTP commands and replies have a rigid syntax. All commands begin
|
||
with a command verb. All replies begin with a three digit numeric
|
||
code. In some commands and replies, arguments are required following
|
||
the verb or reply code. Some commands do not accept arguments (after
|
||
the verb), and some reply codes are followed, sometimes optionally,
|
||
by free form text. In both cases, where text appears, it is
|
||
separated from the verb or reply code by a space character. Complete
|
||
definitions of commands and replies appear in Section 4.
|
||
|
||
Verbs and argument values (e.g., "TO:" or "to:" in the RCPT command
|
||
and extension name keywords) are not case sensitive, with the sole
|
||
exception in this specification of a mailbox local-part (SMTP
|
||
Extensions may explicitly specify case-sensitive elements). That is,
|
||
a command verb, an argument value other than a mailbox local-part,
|
||
and free form text MAY be encoded in upper case, lower case, or any
|
||
mixture of upper and lower case with no impact on its meaning. The
|
||
local-part of a mailbox MUST BE treated as case sensitive.
|
||
Therefore, SMTP implementations MUST take care to preserve the case
|
||
of mailbox local-parts. In particular, for some hosts, the user
|
||
"smith" is different from the user "Smith". However, exploiting the
|
||
case sensitivity of mailbox local-parts impedes interoperability and
|
||
is discouraged. Mailbox domains follow normal DNS rules and are
|
||
hence not case sensitive.
|
||
|
||
A few SMTP servers, in violation of this specification (and RFC 821)
|
||
require that command verbs be encoded by clients in upper case.
|
||
Implementations MAY wish to employ this encoding to accommodate those
|
||
servers.
|
||
|
||
The argument clause consists of a variable-length character string
|
||
ending with the end of the line, i.e., with the character sequence
|
||
<CRLF>. The receiver will take no action until this sequence is
|
||
received.
|
||
|
||
The syntax for each command is shown with the discussion of that
|
||
command. Common elements and parameters are shown in Section 4.1.2.
|
||
|
||
Commands and replies are composed of characters from the ASCII
|
||
character set [6]. When the transport service provides an 8-bit byte
|
||
(octet) transmission channel, each 7-bit character is transmitted,
|
||
right justified, in an octet with the high-order bit cleared to zero.
|
||
More specifically, the unextended SMTP service provides 7-bit
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 16]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
transport only. An originating SMTP client that has not successfully
|
||
negotiated an appropriate extension with a particular server (see the
|
||
next paragraph) MUST NOT transmit messages with information in the
|
||
high-order bit of octets. If such messages are transmitted in
|
||
violation of this rule, receiving SMTP servers MAY clear the high-
|
||
order bit or reject the message as invalid. In general, a relay SMTP
|
||
SHOULD assume that the message content it has received is valid and,
|
||
assuming that the envelope permits doing so, relay it without
|
||
inspecting that content. Of course, if the content is mislabeled and
|
||
the data path cannot accept the actual content, this may result in
|
||
the ultimate delivery of a severely garbled message to the recipient.
|
||
Delivery SMTP systems MAY reject such messages, or return them as
|
||
undeliverable, rather than deliver them. In the absence of a server-
|
||
offered extension explicitly permitting it, a sending SMTP system is
|
||
not permitted to send envelope commands in any character set other
|
||
than US-ASCII. Receiving systems SHOULD reject such commands,
|
||
normally using "500 syntax error - invalid character" replies.
|
||
|
||
8-bit message content transmission MAY be requested of the server by
|
||
a client using extended SMTP facilities, notably the "8BITMIME"
|
||
extension, RFC 1652 [22]. 8BITMIME SHOULD be supported by SMTP
|
||
servers. However, it MUST NOT be construed as authorization to
|
||
transmit unrestricted 8-bit material, nor does 8BITMIME authorize
|
||
transmission of any envelope material in other than ASCII. 8BITMIME
|
||
MUST NOT be requested by senders for material with the high bit on
|
||
that is not in MIME format with an appropriate content-transfer
|
||
encoding; servers MAY reject such messages.
|
||
|
||
The metalinguistic notation used in this document corresponds to the
|
||
"Augmented BNF" used in other Internet mail system documents. The
|
||
reader who is not familiar with that syntax should consult the ABNF
|
||
specification in RFC 5234 [7]. Metalanguage terms used in running
|
||
text are surrounded by pointed brackets (e.g., <CRLF>) for clarity.
|
||
The reader is cautioned that the grammar expressed in the
|
||
metalanguage is not comprehensive. There are many instances in which
|
||
provisions in the text constrain or otherwise modify the syntax or
|
||
semantics implied by the grammar.
|
||
|
||
3. The SMTP Procedures: An Overview
|
||
|
||
This section contains descriptions of the procedures used in SMTP:
|
||
session initiation, mail transaction, forwarding mail, verifying
|
||
mailbox names and expanding mailing lists, and opening and closing
|
||
exchanges. Comments on relaying, a note on mail domains, and a
|
||
discussion of changing roles are included at the end of this section.
|
||
Several complete scenarios are presented in Appendix D.
|
||
|
||
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 17]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
3.1. Session Initiation
|
||
|
||
An SMTP session is initiated when a client opens a connection to a
|
||
server and the server responds with an opening message.
|
||
|
||
SMTP server implementations MAY include identification of their
|
||
software and version information in the connection greeting reply
|
||
after the 220 code, a practice that permits more efficient isolation
|
||
and repair of any problems. Implementations MAY make provision for
|
||
SMTP servers to disable the software and version announcement where
|
||
it causes security concerns. While some systems also identify their
|
||
contact point for mail problems, this is not a substitute for
|
||
maintaining the required "postmaster" address (see Section 4).
|
||
|
||
The SMTP protocol allows a server to formally reject a mail session
|
||
while still allowing the initial connection as follows: a 554
|
||
response MAY be given in the initial connection opening message
|
||
instead of the 220. A server taking this approach MUST still wait
|
||
for the client to send a QUIT (see Section 4.1.1.10) before closing
|
||
the connection and SHOULD respond to any intervening commands with
|
||
"503 bad sequence of commands". Since an attempt to make an SMTP
|
||
connection to such a system is probably in error, a server returning
|
||
a 554 response on connection opening SHOULD provide enough
|
||
information in the reply text to facilitate debugging of the sending
|
||
system.
|
||
|
||
3.2. Client Initiation
|
||
|
||
Once the server has sent the greeting (welcoming) message and the
|
||
client has received it, the client normally sends the EHLO command to
|
||
the server, indicating the client's identity. In addition to opening
|
||
the session, use of EHLO indicates that the client is able to process
|
||
service extensions and requests that the server provide a list of the
|
||
extensions it supports. Older SMTP systems that are unable to
|
||
support service extensions, and contemporary clients that do not
|
||
require service extensions in the mail session being initiated, MAY
|
||
use HELO instead of EHLO. Servers MUST NOT return the extended EHLO-
|
||
style response to a HELO command. For a particular connection
|
||
attempt, if the server returns a "command not recognized" response to
|
||
EHLO, the client SHOULD be able to fall back and send HELO.
|
||
|
||
In the EHLO command, the host sending the command identifies itself;
|
||
the command may be interpreted as saying "Hello, I am <domain>" (and,
|
||
in the case of EHLO, "and I support service extension requests").
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 18]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
3.3. Mail Transactions
|
||
|
||
There are three steps to SMTP mail transactions. The transaction
|
||
starts with a MAIL command that gives the sender identification. (In
|
||
general, the MAIL command may be sent only when no mail transaction
|
||
is in progress; see Section 4.1.4.) A series of one or more RCPT
|
||
commands follows, giving the receiver information. Then, a DATA
|
||
command initiates transfer of the mail data and is terminated by the
|
||
"end of mail" data indicator, which also confirms the transaction.
|
||
|
||
The first step in the procedure is the MAIL command.
|
||
|
||
MAIL FROM:<reverse-path> [SP <mail-parameters> ] <CRLF>
|
||
|
||
This command tells the SMTP-receiver that a new mail transaction is
|
||
starting and to reset all its state tables and buffers, including any
|
||
recipients or mail data. The <reverse-path> portion of the first or
|
||
only argument contains the source mailbox (between "<" and ">"
|
||
brackets), which can be used to report errors (see Section 4.2 for a
|
||
discussion of error reporting). If accepted, the SMTP server returns
|
||
a "250 OK" reply. If the mailbox specification is not acceptable for
|
||
some reason, the server MUST return a reply indicating whether the
|
||
failure is permanent (i.e., will occur again if the client tries to
|
||
send the same address again) or temporary (i.e., the address might be
|
||
accepted if the client tries again later). Despite the apparent
|
||
scope of this requirement, there are circumstances in which the
|
||
acceptability of the reverse-path may not be determined until one or
|
||
more forward-paths (in RCPT commands) can be examined. In those
|
||
cases, the server MAY reasonably accept the reverse-path (with a 250
|
||
reply) and then report problems after the forward-paths are received
|
||
and examined. Normally, failures produce 550 or 553 replies.
|
||
|
||
Historically, the <reverse-path> was permitted to contain more than
|
||
just a mailbox; however, contemporary systems SHOULD NOT use source
|
||
routing (see Appendix C).
|
||
|
||
The optional <mail-parameters> are associated with negotiated SMTP
|
||
service extensions (see Section 2.2).
|
||
|
||
The second step in the procedure is the RCPT command. This step of
|
||
the procedure can be repeated any number of times.
|
||
|
||
RCPT TO:<forward-path> [ SP <rcpt-parameters> ] <CRLF>
|
||
|
||
The first or only argument to this command includes a forward-path
|
||
(normally a mailbox and domain, always surrounded by "<" and ">"
|
||
brackets) identifying one recipient. If accepted, the SMTP server
|
||
returns a "250 OK" reply and stores the forward-path. If the
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 19]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
recipient is known not to be a deliverable address, the SMTP server
|
||
returns a 550 reply, typically with a string such as "no such user -
|
||
" and the mailbox name (other circumstances and reply codes are
|
||
possible).
|
||
|
||
The <forward-path> can contain more than just a mailbox.
|
||
Historically, the <forward-path> was permitted to contain a source
|
||
routing list of hosts and the destination mailbox; however,
|
||
contemporary SMTP clients SHOULD NOT utilize source routes (see
|
||
Appendix C). Servers MUST be prepared to encounter a list of source
|
||
routes in the forward-path, but they SHOULD ignore the routes or MAY
|
||
decline to support the relaying they imply. Similarly, servers MAY
|
||
decline to accept mail that is destined for other hosts or systems.
|
||
These restrictions make a server useless as a relay for clients that
|
||
do not support full SMTP functionality. Consequently, restricted-
|
||
capability clients MUST NOT assume that any SMTP server on the
|
||
Internet can be used as their mail processing (relaying) site. If a
|
||
RCPT command appears without a previous MAIL command, the server MUST
|
||
return a 503 "Bad sequence of commands" response. The optional
|
||
<rcpt-parameters> are associated with negotiated SMTP service
|
||
extensions (see Section 2.2).
|
||
|
||
Since it has been a common source of errors, it is worth noting that
|
||
spaces are not permitted on either side of the colon following FROM
|
||
in the MAIL command or TO in the RCPT command. The syntax is exactly
|
||
as given above.
|
||
|
||
The third step in the procedure is the DATA command (or some
|
||
alternative specified in a service extension).
|
||
|
||
DATA <CRLF>
|
||
|
||
If accepted, the SMTP server returns a 354 Intermediate reply and
|
||
considers all succeeding lines up to but not including the end of
|
||
mail data indicator to be the message text. When the end of text is
|
||
successfully received and stored, the SMTP-receiver sends a "250 OK"
|
||
reply.
|
||
|
||
Since the mail data is sent on the transmission channel, the end of
|
||
mail data must be indicated so that the command and reply dialog can
|
||
be resumed. SMTP indicates the end of the mail data by sending a
|
||
line containing only a "." (period or full stop). A transparency
|
||
procedure is used to prevent this from interfering with the user's
|
||
text (see Section 4.5.2).
|
||
|
||
The end of mail data indicator also confirms the mail transaction and
|
||
tells the SMTP server to now process the stored recipients and mail
|
||
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 20]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
data. If accepted, the SMTP server returns a "250 OK" reply. The
|
||
DATA command can fail at only two points in the protocol exchange:
|
||
|
||
If there was no MAIL, or no RCPT, command, or all such commands were
|
||
rejected, the server MAY return a "command out of sequence" (503) or
|
||
"no valid recipients" (554) reply in response to the DATA command.
|
||
If one of those replies (or any other 5yz reply) is received, the
|
||
client MUST NOT send the message data; more generally, message data
|
||
MUST NOT be sent unless a 354 reply is received.
|
||
|
||
If the verb is initially accepted and the 354 reply issued, the DATA
|
||
command should fail only if the mail transaction was incomplete (for
|
||
example, no recipients), if resources were unavailable (including, of
|
||
course, the server unexpectedly becoming unavailable), or if the
|
||
server determines that the message should be rejected for policy or
|
||
other reasons.
|
||
|
||
However, in practice, some servers do not perform recipient
|
||
verification until after the message text is received. These servers
|
||
SHOULD treat a failure for one or more recipients as a "subsequent
|
||
failure" and return a mail message as discussed in Section 6 and, in
|
||
particular, in Section 6.1. Using a "550 mailbox not found" (or
|
||
equivalent) reply code after the data are accepted makes it difficult
|
||
or impossible for the client to determine which recipients failed.
|
||
|
||
When the RFC 822 format ([28], [4]) is being used, the mail data
|
||
include the header fields such as those named Date, Subject, To, Cc,
|
||
and From. Server SMTP systems SHOULD NOT reject messages based on
|
||
perceived defects in the RFC 822 or MIME (RFC 2045 [21]) message
|
||
header section or message body. In particular, they MUST NOT reject
|
||
messages in which the numbers of Resent-header fields do not match or
|
||
Resent-to appears without Resent-from and/or Resent-date.
|
||
|
||
Mail transaction commands MUST be used in the order discussed above.
|
||
|
||
3.4. Forwarding for Address Correction or Updating
|
||
|
||
Forwarding support is most often required to consolidate and simplify
|
||
addresses within, or relative to, some enterprise and less frequently
|
||
to establish addresses to link a person's prior address with a
|
||
current one. Silent forwarding of messages (without server
|
||
notification to the sender), for security or non-disclosure purposes,
|
||
is common in the contemporary Internet.
|
||
|
||
In both the enterprise and the "new address" cases, information
|
||
hiding (and sometimes security) considerations argue against exposure
|
||
of the "final" address through the SMTP protocol as a side effect of
|
||
the forwarding activity. This may be especially important when the
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 21]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
final address may not even be reachable by the sender. Consequently,
|
||
the "forwarding" mechanisms described in Section 3.2 of RFC 821, and
|
||
especially the 251 (corrected destination) and 551 reply codes from
|
||
RCPT must be evaluated carefully by implementers and, when they are
|
||
available, by those configuring systems (see also Section 7.4).
|
||
|
||
In particular:
|
||
|
||
o Servers MAY forward messages when they are aware of an address
|
||
change. When they do so, they MAY either provide address-updating
|
||
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
|
||
that the client will actually update address information or even
|
||
return that information to the user.
|
||
|
||
Alternately,
|
||
|
||
o Servers MAY reject messages or return them as non-deliverable when
|
||
they cannot be delivered precisely as addressed. When they do so,
|
||
they MAY either provide address-updating information with a 551
|
||
code, or may reject the message as undeliverable with a 550 code
|
||
and no address-specific information. However, if a 551 code is
|
||
used, they MUST NOT assume that the client will actually update
|
||
address information or even return that information to the user.
|
||
|
||
SMTP server implementations that support the 251 and/or 551 reply
|
||
codes SHOULD provide configuration mechanisms so that sites that
|
||
conclude that they would undesirably disclose information can disable
|
||
or restrict their use.
|
||
|
||
3.5. Commands for Debugging Addresses
|
||
|
||
3.5.1. Overview
|
||
|
||
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
|
||
have character string arguments. Implementations SHOULD support VRFY
|
||
and EXPN (however, see Section 3.5.2 and Section 7.3).
|
||
|
||
For the VRFY command, the string is a user name or a user name and
|
||
domain (see below). If a normal (i.e., 250) response is returned,
|
||
the response MAY include the full name of the user and MUST include
|
||
the mailbox of the user. It MUST be in either of the following
|
||
forms:
|
||
|
||
User Name <local-part@domain>
|
||
local-part@domain
|
||
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 22]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
When a name that is the argument to VRFY could identify more than one
|
||
mailbox, the server MAY either note the ambiguity or identify the
|
||
alternatives. In other words, any of the following are legitimate
|
||
responses to VRFY:
|
||
|
||
553 User ambiguous
|
||
|
||
or
|
||
|
||
553- Ambiguous; Possibilities are
|
||
553-Joe Smith <jsmith@foo.com>
|
||
553-Harry Smith <hsmith@foo.com>
|
||
553 Melvin Smith <dweep@foo.com>
|
||
|
||
or
|
||
|
||
553-Ambiguous; Possibilities
|
||
553- <jsmith@foo.com>
|
||
553- <hsmith@foo.com>
|
||
553 <dweep@foo.com>
|
||
|
||
Under normal circumstances, a client receiving a 553 reply would be
|
||
expected to expose the result to the user. Use of exactly the forms
|
||
given, and the "user ambiguous" or "ambiguous" keywords, possibly
|
||
supplemented by extended reply codes, such as those described in RFC
|
||
3463 [25], will facilitate automated translation into other languages
|
||
as needed. Of course, a client that was highly automated or that was
|
||
operating in another language than English might choose to try to
|
||
translate the response to return some other indication to the user
|
||
than the literal text of the reply, or to take some automated action
|
||
such as consulting a directory service for additional information
|
||
before reporting to the user.
|
||
|
||
For the EXPN command, the string identifies a mailing list, and the
|
||
successful (i.e., 250) multiline response MAY include the full name
|
||
of the users and MUST give the mailboxes on the mailing list.
|
||
|
||
In some hosts, the distinction between a mailing list and an alias
|
||
for a single mailbox is a bit fuzzy, since a common data structure
|
||
may hold both types of entries, and it is possible to have mailing
|
||
lists containing only one mailbox. If a request is made to apply
|
||
VRFY to a mailing list, a positive response MAY be given if a message
|
||
so addressed would be delivered to everyone on the list, otherwise an
|
||
error SHOULD be reported (e.g., "550 That is a mailing list, not a
|
||
user" or "252 Unable to verify members of mailing list"). If a
|
||
request is made to expand a user name, the server MAY return a
|
||
|
||
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 23]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
positive response consisting of a list containing one name, or an
|
||
error MAY be reported (e.g., "550 That is a user name, not a mailing
|
||
list").
|
||
|
||
In the case of a successful multiline reply (normal for EXPN),
|
||
exactly one mailbox is to be specified on each line of the reply.
|
||
The case of an ambiguous request is discussed above.
|
||
|
||
"User name" is a fuzzy term and has been used deliberately. An
|
||
implementation of the VRFY or EXPN commands MUST include at least
|
||
recognition of local mailboxes as "user names". However, since
|
||
current Internet practice often results in a single host handling
|
||
mail for multiple domains, hosts, especially hosts that provide this
|
||
functionality, SHOULD accept the "local-part@domain" form as a "user
|
||
name"; hosts MAY also choose to recognize other strings as "user
|
||
names".
|
||
|
||
The case of expanding a mailbox list requires a multiline reply, such
|
||
as:
|
||
|
||
C: EXPN Example-People
|
||
S: 250-Jon Postel <Postel@isi.edu>
|
||
S: 250-Fred Fonebone <Fonebone@physics.foo-u.edu>
|
||
S: 250 Sam Q. Smith <SQSmith@specific.generic.com>
|
||
|
||
or
|
||
|
||
C: EXPN Executive-Washroom-List
|
||
S: 550 Access Denied to You.
|
||
|
||
The character string arguments of the VRFY and EXPN commands cannot
|
||
be further restricted due to the variety of implementations of the
|
||
user name and mailbox list concepts. On some systems, it may be
|
||
appropriate for the argument of the EXPN command to be a file name
|
||
for a file containing a mailing list, but again there are a variety
|
||
of file naming conventions in the Internet. Similarly, historical
|
||
variations in what is returned by these commands are such that the
|
||
response SHOULD be interpreted very carefully, if at all, and SHOULD
|
||
generally only be used for diagnostic purposes.
|
||
|
||
3.5.2. VRFY Normal Response
|
||
|
||
When normal (2yz or 551) responses are returned from a VRFY or EXPN
|
||
request, the reply MUST include the <Mailbox> name using a
|
||
"<local-part@domain>" construction, where "domain" is a fully-
|
||
qualified domain name. In circumstances exceptional enough to
|
||
justify violating the intent of this specification, free-form text
|
||
MAY be returned. In order to facilitate parsing by both computers
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 24]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
and people, addresses SHOULD appear in pointed brackets. When
|
||
addresses, rather than free-form debugging information, are returned,
|
||
EXPN and VRFY MUST return only valid domain addresses that are usable
|
||
in SMTP RCPT commands. Consequently, if an address implies delivery
|
||
to a program or other system, the mailbox name used to reach that
|
||
target MUST be given. Paths (explicit source routes) MUST NOT be
|
||
returned by VRFY or EXPN.
|
||
|
||
Server implementations SHOULD support both VRFY and EXPN. For
|
||
security reasons, implementations MAY provide local installations a
|
||
way to disable either or both of these commands through configuration
|
||
options or the equivalent (see Section 7.3). When these commands are
|
||
supported, they are not required to work across relays when relaying
|
||
is supported. Since they were both optional in RFC 821, but VRFY was
|
||
made mandatory in RFC 1123 [3], if EXPN is supported, it MUST be
|
||
listed as a service extension in an EHLO response. VRFY MAY be
|
||
listed as a convenience but, since support for it is required, SMTP
|
||
clients are not required to check for its presence on the extension
|
||
list before using it.
|
||
|
||
3.5.3. Meaning of VRFY or EXPN Success Response
|
||
|
||
A server MUST NOT return a 250 code in response to a VRFY or EXPN
|
||
command unless it has actually verified the address. In particular,
|
||
a server MUST NOT return 250 if all it has done is to verify that the
|
||
syntax given is valid. In that case, 502 (Command not implemented)
|
||
or 500 (Syntax error, command unrecognized) SHOULD be returned. As
|
||
stated elsewhere, implementation (in the sense of actually validating
|
||
addresses and returning information) of VRFY and EXPN are strongly
|
||
recommended. Hence, implementations that return 500 or 502 for VRFY
|
||
are not in full compliance with this specification.
|
||
|
||
There may be circumstances where an address appears to be valid but
|
||
cannot reasonably be verified in real time, particularly when a
|
||
server is acting as a mail exchanger for another server or domain.
|
||
"Apparent validity", in this case, would normally involve at least
|
||
syntax checking and might involve verification that any domains
|
||
specified were ones to which the host expected to be able to relay
|
||
mail. In these situations, reply code 252 SHOULD be returned. These
|
||
cases parallel the discussion of RCPT verification in Section 2.1.
|
||
Similarly, the discussion in Section 3.4 applies to the use of reply
|
||
codes 251 and 551 with VRFY (and EXPN) to indicate addresses that are
|
||
recognized but that would be forwarded or rejected were mail received
|
||
for them. Implementations generally SHOULD be more aggressive about
|
||
address verification in the case of VRFY than in the case of RCPT,
|
||
even if it takes a little longer to do so.
|
||
|
||
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 25]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
3.5.4. Semantics and Applications of EXPN
|
||
|
||
EXPN is often very useful in debugging and understanding problems
|
||
with mailing lists and multiple-target-address aliases. Some systems
|
||
have attempted to use source expansion of mailing lists as a means of
|
||
eliminating duplicates. The propagation of aliasing systems with
|
||
mail on the Internet for hosts (typically with MX and CNAME DNS
|
||
records), for mailboxes (various types of local host aliases), and in
|
||
various proxying arrangements has made it nearly impossible for these
|
||
strategies to work consistently, and mail systems SHOULD NOT attempt
|
||
them.
|
||
|
||
3.6. Relaying and Mail Routing
|
||
|
||
3.6.1. Source Routes and Relaying
|
||
|
||
In general, the availability of Mail eXchanger records in the domain
|
||
name system (RFC 1035 [2], RFC 974 [12]) makes the use of explicit
|
||
source routes in the Internet mail system unnecessary. Many
|
||
historical problems with the interpretation of explicit source routes
|
||
have made their use undesirable. SMTP clients SHOULD NOT generate
|
||
explicit source routes except under unusual circumstances. SMTP
|
||
servers MAY decline to act as mail relays or to accept addresses that
|
||
specify source routes. When route information is encountered, SMTP
|
||
servers MAY ignore the route information and simply send to the final
|
||
destination specified as the last element in the route and SHOULD do
|
||
so. There has been an invalid practice of using names that do not
|
||
appear in the DNS as destination names, with the senders counting on
|
||
the intermediate hosts specified in source routing to resolve any
|
||
problems. If source routes are stripped, this practice will cause
|
||
failures. This is one of several reasons why SMTP clients MUST NOT
|
||
generate invalid source routes or depend on serial resolution of
|
||
names.
|
||
|
||
When source routes are not used, the process described in RFC 821 for
|
||
constructing a reverse-path from the forward-path is not applicable
|
||
and the reverse-path at the time of delivery will simply be the
|
||
address that appeared in the MAIL command.
|
||
|
||
3.6.2. Mail eXchange Records and Relaying
|
||
|
||
A relay SMTP server is usually the target of a DNS MX record that
|
||
designates it, rather than the final delivery system. The relay
|
||
server may accept or reject the task of relaying the mail in the same
|
||
way it accepts or rejects mail for a local user. If it accepts the
|
||
task, it then becomes an SMTP client, establishes a transmission
|
||
channel to the next SMTP server specified in the DNS (according to
|
||
the rules in Section 5), and sends it the mail. If it declines to
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 26]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
relay mail to a particular address for policy reasons, a 550 response
|
||
SHOULD be returned.
|
||
|
||
This specification does not deal with the verification of return
|
||
paths for use in delivery notifications. Recent work, such as that
|
||
on SPF [29] and DKIM [30] [31], has been done to provide ways to
|
||
ascertain that an address is valid or belongs to the person who
|
||
actually sent the message. A server MAY attempt to verify the return
|
||
path before using its address for delivery notifications, but methods
|
||
of doing so are not defined here nor is any particular method
|
||
recommended at this time.
|
||
|
||
3.6.3. Message Submission Servers as Relays
|
||
|
||
Many mail-sending clients exist, especially in conjunction with
|
||
facilities that receive mail via POP3 or IMAP, that have limited
|
||
capability to support some of the requirements of this specification,
|
||
such as the ability to queue messages for subsequent delivery
|
||
attempts. For these clients, it is common practice to make private
|
||
arrangements to send all messages to a single server for processing
|
||
and subsequent distribution. SMTP, as specified here, is not ideally
|
||
suited for this role. A standardized mail submission protocol has
|
||
been developed that is gradually superseding practices based on SMTP
|
||
(see RFC 4409 [18]). In any event, because these arrangements are
|
||
private and fall outside the scope of this specification, they are
|
||
not described here.
|
||
|
||
It is important to note that MX records can point to SMTP servers
|
||
that act as gateways into other environments, not just SMTP relays
|
||
and final delivery systems; see Sections 3.7 and 5.
|
||
|
||
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
|
||
be delivered for some other reason, then it MUST construct an
|
||
"undeliverable mail" notification message and send it to the
|
||
originator of the undeliverable mail (as indicated by the reverse-
|
||
path). Formats specified for non-delivery reports by other standards
|
||
(see, for example, RFC 3461 [32] and RFC 3464 [33]) SHOULD be used if
|
||
possible.
|
||
|
||
This notification message must be from the SMTP server at the relay
|
||
host or the host that first determines that delivery cannot be
|
||
accomplished. Of course, SMTP servers MUST NOT send notification
|
||
messages about problems transporting notification messages. One way
|
||
to prevent loops in error reporting is to specify a null reverse-path
|
||
in the MAIL command of a notification message. When such a message
|
||
is transmitted, the reverse-path MUST be set to null (see
|
||
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 27]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
Section 4.5.5 for additional discussion). A MAIL command with a null
|
||
reverse-path appears as follows:
|
||
|
||
MAIL FROM:<>
|
||
|
||
As discussed in Section 6.4, a relay SMTP has no need to inspect or
|
||
act upon the header section or body of the message data and MUST NOT
|
||
do so except to add its own "Received:" header field (Section 4.4)
|
||
and, optionally, to attempt to detect looping in the mail system (see
|
||
Section 6.3). Of course, this prohibition also applies to any
|
||
modifications of these header fields or text (see also Section 7.9).
|
||
|
||
3.7. Mail Gatewaying
|
||
|
||
While the relay function discussed above operates within the Internet
|
||
SMTP transport service environment, MX records or various forms of
|
||
explicit routing may require that an intermediate SMTP server perform
|
||
a translation function between one transport service and another. As
|
||
discussed in Section 2.3.10, when such a system is at the boundary
|
||
between two transport service environments, we refer to it as a
|
||
"gateway" or "gateway SMTP".
|
||
|
||
Gatewaying mail between different mail environments, such as
|
||
different mail formats and protocols, is complex and does not easily
|
||
yield to standardization. However, some general requirements may be
|
||
given for a gateway between the Internet and another mail
|
||
environment.
|
||
|
||
3.7.1. Header Fields in Gatewaying
|
||
|
||
Header fields MAY be rewritten when necessary as messages are
|
||
gatewayed across mail environment boundaries. This may involve
|
||
inspecting the message body or interpreting the local-part of the
|
||
destination address in spite of the prohibitions in Section 6.4.
|
||
|
||
Other mail systems gatewayed to the Internet often use a subset of
|
||
the RFC 822 header section or provide similar functionality with a
|
||
different syntax, but some of these mail systems do not have an
|
||
equivalent to the SMTP envelope. Therefore, when a message leaves
|
||
the Internet environment, it may be necessary to fold the SMTP
|
||
envelope information into the message header section. A possible
|
||
solution would be to create new header fields to carry the envelope
|
||
information (e.g., "X-SMTP-MAIL:" and "X-SMTP-RCPT:"); however, this
|
||
would require changes in mail programs in foreign environments and
|
||
might risk disclosure of private information (see Section 7.2).
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 28]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
3.7.2. Received Lines in Gatewaying
|
||
|
||
When forwarding a message into or out of the Internet environment, a
|
||
gateway MUST prepend a Received: line, but it MUST NOT alter in any
|
||
way a Received: line that is already in the header section.
|
||
|
||
"Received:" header fields of messages originating from other
|
||
environments may not conform exactly to this specification. However,
|
||
the most important use of Received: lines is for debugging mail
|
||
faults, and this debugging can be severely hampered by well-meaning
|
||
gateways that try to "fix" a Received: line. As another consequence
|
||
of trace header fields arising in non-SMTP environments, receiving
|
||
systems MUST NOT reject mail based on the format of a trace header
|
||
field and SHOULD be extremely robust in the light of unexpected
|
||
information or formats in those header fields.
|
||
|
||
The gateway SHOULD indicate the environment and protocol in the "via"
|
||
clauses of Received header field(s) that it supplies.
|
||
|
||
3.7.3. Addresses in Gatewaying
|
||
|
||
From the Internet side, the gateway SHOULD accept all valid address
|
||
formats in SMTP commands and in the RFC 822 header section, and all
|
||
valid RFC 822 messages. Addresses and header fields generated by
|
||
gateways MUST conform to applicable standards (including this one and
|
||
RFC 5322 [4]). Gateways are, of course, subject to the same rules
|
||
for handling source routes as those described for other SMTP systems
|
||
in Section 3.3.
|
||
|
||
3.7.4. Other Header Fields in Gatewaying
|
||
|
||
The gateway MUST ensure that all header fields of a message that it
|
||
forwards into the Internet mail environment meet the requirements for
|
||
Internet mail. In particular, all addresses in "From:", "To:",
|
||
"Cc:", etc., header fields MUST be transformed (if necessary) to
|
||
satisfy the standard header syntax of RFC 5322 [4], MUST reference
|
||
only fully-qualified domain names, and MUST be effective and useful
|
||
for sending replies. The translation algorithm used to convert mail
|
||
from the Internet protocols to another environment's protocol SHOULD
|
||
ensure that error messages from the foreign mail environment are
|
||
delivered to the reverse-path from the SMTP envelope, not to an
|
||
address in the "From:", "Sender:", or similar header fields of the
|
||
message.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 29]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
3.7.5. Envelopes in Gatewaying
|
||
|
||
Similarly, when forwarding a message from another environment into
|
||
the Internet, the gateway SHOULD set the envelope return path in
|
||
accordance with an error message return address, if supplied by the
|
||
foreign environment. If the foreign environment has no equivalent
|
||
concept, the gateway must select and use a best approximation, with
|
||
the message originator's address as the default of last resort.
|
||
|
||
3.8. Terminating Sessions and Connections
|
||
|
||
An SMTP connection is terminated when the client sends a QUIT
|
||
command. The server responds with a positive reply code, after which
|
||
it closes the connection.
|
||
|
||
An SMTP server MUST NOT intentionally close the connection under
|
||
normal operational circumstances (see Section 7.8) except:
|
||
|
||
o After receiving a QUIT command and responding with a 221 reply.
|
||
|
||
o After detecting the need to shut down the SMTP service and
|
||
returning a 421 response code. This response code can be issued
|
||
after the server receives any command or, if necessary,
|
||
asynchronously from command receipt (on the assumption that the
|
||
client will receive it after the next command is issued).
|
||
|
||
o After a timeout, as specified in Section 4.5.3.2, occurs waiting
|
||
for the client to send a command or data.
|
||
|
||
In particular, a server that closes connections in response to
|
||
commands that are not understood is in violation of this
|
||
specification. Servers are expected to be tolerant of unknown
|
||
commands, issuing a 500 reply and awaiting further instructions from
|
||
the client.
|
||
|
||
An SMTP server that is forcibly shut down via external means SHOULD
|
||
attempt to send a line containing a 421 response code to the SMTP
|
||
client before exiting. The SMTP client will normally read the 421
|
||
response code after sending its next command.
|
||
|
||
SMTP clients that experience a connection close, reset, or other
|
||
communications failure due to circumstances not under their control
|
||
(in violation of the intent of this specification but sometimes
|
||
unavoidable) SHOULD, to maintain the robustness of the mail system,
|
||
treat the mail transaction as if a 451 response had been received and
|
||
act accordingly.
|
||
|
||
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 30]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
3.9. Mailing Lists and Aliases
|
||
|
||
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 [4]) 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. Alias
|
||
|
||
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. List
|
||
|
||
A mailing list may be said to operate by "redistribution" rather than
|
||
by "forwarding". 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 aliases (Section 3.9.1) and
|
||
forwarding (this subsection) is the change to the backward-pointing
|
||
address in this case. When a list constrains its processing to the
|
||
very limited set of modifications and actions described here, it is
|
||
attempting to emulate an MTA; such lists can be treated as a
|
||
continuation in email transit.
|
||
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 31]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
There exist mailing lists that perform additional, sometimes
|
||
extensive, modifications to a message and its envelope. Such mailing
|
||
lists need to be viewed as full MUAs, which accept a delivery and
|
||
post a new message.
|
||
|
||
4. The SMTP Specifications
|
||
|
||
4.1. SMTP Commands
|
||
|
||
4.1.1. Command Semantics and Syntax
|
||
|
||
The SMTP commands define the mail transfer or the mail system
|
||
function requested by the user. SMTP commands are character strings
|
||
terminated by <CRLF>. The commands themselves are alphabetic
|
||
characters terminated by <SP> if parameters follow and <CRLF>
|
||
otherwise. (In the interest of improved interoperability, SMTP
|
||
receivers SHOULD tolerate trailing white space before the terminating
|
||
<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.
|
||
The SMTP commands are discussed below. The SMTP replies are
|
||
discussed in Section 4.2.
|
||
|
||
A mail transaction involves several data objects that are
|
||
communicated as arguments to different commands. The reverse-path is
|
||
the argument of the MAIL command, the forward-path is the argument of
|
||
the RCPT command, and the mail data is the argument of the DATA
|
||
command. These arguments or data objects must be transmitted and
|
||
held, pending the confirmation communicated by the end of mail data
|
||
indication that finalizes the transaction. The model for this is
|
||
that distinct buffers are provided to hold the types of data objects;
|
||
that is, there is a reverse-path buffer, a forward-path buffer, and a
|
||
mail data buffer. Specific commands cause information to be appended
|
||
to a specific buffer, or cause one or more buffers to be cleared.
|
||
|
||
Several commands (RSET, DATA, QUIT) are specified as not permitting
|
||
parameters. In the absence of specific extensions offered by the
|
||
server and accepted by the client, clients MUST NOT send such
|
||
parameters and servers SHOULD reject commands containing them as
|
||
having invalid syntax.
|
||
|
||
4.1.1.1. Extended HELLO (EHLO) or HELLO (HELO)
|
||
|
||
These commands are used to identify the SMTP client to the SMTP
|
||
server. The argument clause contains the fully-qualified domain name
|
||
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
|
||
its address is dynamically allocated and no reverse mapping record is
|
||
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 32]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
available), the client SHOULD send an address literal (see
|
||
Section 4.1.3).
|
||
|
||
RFC 2821, and some earlier informal practices, encouraged following
|
||
the literal by information that would help to identify the client
|
||
system. That convention was not widely supported, and many SMTP
|
||
servers considered it an error. In the interest of interoperability,
|
||
it is probably wise for servers to be prepared for this string to
|
||
occur, but SMTP clients SHOULD NOT send it.
|
||
|
||
The SMTP server identifies itself to the SMTP client in the
|
||
connection greeting reply and in the response to this command.
|
||
|
||
A client SMTP SHOULD start an SMTP session by issuing the EHLO
|
||
command. If the SMTP server supports the SMTP service extensions, it
|
||
will give a successful response, a failure response, or an error
|
||
response. If the SMTP server, in violation of this specification,
|
||
does not support any SMTP service extensions, it will generate an
|
||
error response. Older client SMTP systems MAY, as discussed above,
|
||
use HELO (as specified in RFC 821) instead of EHLO, and servers MUST
|
||
support the HELO command and reply properly to it. In any event, a
|
||
client MUST issue HELO or EHLO before starting a mail transaction.
|
||
|
||
These commands, and a "250 OK" reply to one of them, confirm that
|
||
both the SMTP client and the SMTP server are in the initial state,
|
||
that is, there is no transaction in progress and all state tables and
|
||
buffers are cleared.
|
||
|
||
Syntax:
|
||
|
||
ehlo = "EHLO" SP ( Domain / address-literal ) CRLF
|
||
|
||
helo = "HELO" SP Domain CRLF
|
||
|
||
Normally, the response to EHLO will be a multiline reply. Each line
|
||
of the response contains a keyword and, optionally, one or more
|
||
parameters. Following the normal syntax for multiline replies, these
|
||
keywords follow the code (250) and a hyphen for all but the last
|
||
line, and the code and a space for the last line. The syntax for a
|
||
positive response, using the ABNF notation and terminal symbols of
|
||
RFC 5234 [7], is:
|
||
|
||
ehlo-ok-rsp = ( "250" SP Domain [ SP ehlo-greet ] CRLF )
|
||
/ ( "250-" Domain [ SP ehlo-greet ] CRLF
|
||
*( "250-" ehlo-line CRLF )
|
||
"250" SP ehlo-line CRLF )
|
||
|
||
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 33]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
ehlo-greet = 1*(%d0-9 / %d11-12 / %d14-127)
|
||
; string of any characters other than CR or LF
|
||
|
||
ehlo-line = ehlo-keyword *( SP ehlo-param )
|
||
|
||
ehlo-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
|
||
; additional syntax of ehlo-params depends on
|
||
; ehlo-keyword
|
||
|
||
ehlo-param = 1*(%d33-126)
|
||
; any CHAR excluding <SP> and all
|
||
; control characters (US-ASCII 0-31 and 127
|
||
; inclusive)
|
||
|
||
Although EHLO keywords may be specified in upper, lower, or mixed
|
||
case, they MUST always be recognized and processed in a case-
|
||
insensitive manner. This is simply an extension of practices
|
||
specified in RFC 821 and Section 2.4.
|
||
|
||
The EHLO response MUST contain keywords (and associated parameters if
|
||
required) for all commands not listed as "required" in Section 4.5.1
|
||
excepting only private-use commands as described in Section 4.1.5.
|
||
Private-use commands MAY be listed.
|
||
|
||
4.1.1.2. MAIL (MAIL)
|
||
|
||
This command is used to initiate a mail transaction in which the mail
|
||
data is delivered to an SMTP server that may, in turn, deliver it to
|
||
one or more mailboxes or pass it on to another system (possibly using
|
||
SMTP). The argument clause contains a reverse-path and may contain
|
||
optional parameters. In general, the MAIL command may be sent only
|
||
when no mail transaction is in progress, see Section 4.1.4.
|
||
|
||
The reverse-path consists of the sender mailbox. Historically, that
|
||
mailbox might optionally have been preceded by a list of hosts, but
|
||
that behavior is now deprecated (see Appendix C). In some types of
|
||
reporting messages for which a reply is likely to cause a mail loop
|
||
(for example, mail delivery and non-delivery notifications), the
|
||
reverse-path may be null (see Section 3.6).
|
||
|
||
This command clears the reverse-path buffer, the forward-path buffer,
|
||
and the mail data buffer, and it inserts the reverse-path information
|
||
from its argument clause into the reverse-path buffer.
|
||
|
||
If service extensions were negotiated, the MAIL command may also
|
||
carry parameters associated with a particular service extension.
|
||
|
||
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 34]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
Syntax:
|
||
|
||
mail = "MAIL FROM:" Reverse-path
|
||
[SP Mail-parameters] CRLF
|
||
|
||
4.1.1.3. RECIPIENT (RCPT)
|
||
|
||
This command is used to identify an individual recipient of the mail
|
||
data; multiple recipients are specified by multiple uses of this
|
||
command. The argument clause contains a forward-path and may contain
|
||
optional parameters.
|
||
|
||
The forward-path normally consists of the required destination
|
||
mailbox. Sending systems SHOULD NOT generate the optional list of
|
||
hosts known as a source route. Receiving systems MUST recognize
|
||
source route syntax but SHOULD strip off the source route
|
||
specification and utilize the domain name associated with the mailbox
|
||
as if the source route had not been provided.
|
||
|
||
Similarly, relay hosts SHOULD strip or ignore source routes, and
|
||
names MUST NOT be copied into the reverse-path. When mail reaches
|
||
its ultimate destination (the forward-path contains only a
|
||
destination mailbox), the SMTP server inserts it into the destination
|
||
mailbox in accordance with its host mail conventions.
|
||
|
||
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.
|
||
|
||
For example, mail received at relay host xyz.com with envelope
|
||
commands
|
||
|
||
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>
|
||
|
||
As provided in Appendix C, xyz.com MAY also choose to relay the
|
||
message to hosta.int, using the envelope commands
|
||
|
||
MAIL FROM:<userx@y.foo.org>
|
||
RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org>
|
||
|
||
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 35]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
or to jkl.org, using the envelope commands
|
||
|
||
MAIL FROM:<userx@y.foo.org>
|
||
RCPT TO:<@jkl.org: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
|
||
reject the message entirely when the RCPT command is received, using
|
||
a 550 code (since this is a "policy reason").
|
||
|
||
If service extensions were negotiated, the RCPT command may also
|
||
carry parameters associated with a particular service extension
|
||
offered by the server. The client MUST NOT transmit parameters other
|
||
than those associated with a service extension offered by the server
|
||
in its EHLO response.
|
||
|
||
Syntax:
|
||
|
||
rcpt = "RCPT TO:" ( "<Postmaster@" Domain ">" / "<Postmaster>" /
|
||
Forward-path ) [SP Rcpt-parameters] CRLF
|
||
|
||
Note that, in a departure from the usual rules for
|
||
local-parts, the "Postmaster" string shown above is
|
||
treated as case-insensitive.
|
||
|
||
4.1.1.4. DATA (DATA)
|
||
|
||
The receiver normally sends a 354 response to DATA, and then treats
|
||
the lines (strings ending in <CRLF> sequences, as described in
|
||
Section 2.3.7) following the command as mail data from the sender.
|
||
This command causes the mail data to be appended to the mail data
|
||
buffer. The mail data may contain any of the 128 ASCII character
|
||
codes, although experience has indicated that use of control
|
||
characters other than SP, HT, CR, and LF may cause problems and
|
||
SHOULD be avoided when possible.
|
||
|
||
The mail data are terminated by a line containing only a period, that
|
||
is, the character sequence "<CRLF>.<CRLF>", where the first <CRLF> is
|
||
actually the terminator of the previous line (see Section 4.5.2).
|
||
This is the end of mail data indication. The first <CRLF> of this
|
||
terminating sequence is also the <CRLF> that ends the final line of
|
||
the data (message text) or, if there was no mail data, ends the DATA
|
||
command itself (the "no mail data" case does not conform to this
|
||
specification since it would require that neither the trace header
|
||
fields required by this specification nor the message header section
|
||
required by RFC 5322 [4] be transmitted). An extra <CRLF> MUST NOT
|
||
be added, as that would cause an empty line to be added to the
|
||
message. The only exception to this rule would arise if the message
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 36]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
body were passed to the originating SMTP-sender with a final "line"
|
||
that did not end in <CRLF>; in that case, the originating SMTP system
|
||
MUST either reject the message as invalid or add <CRLF> in order to
|
||
have the receiving SMTP server recognize the "end of data" condition.
|
||
|
||
The custom of accepting lines ending only in <LF>, as a concession to
|
||
non-conforming behavior on the part of some UNIX systems, has proven
|
||
to cause more interoperability problems than it solves, and SMTP
|
||
server systems MUST NOT do this, even in the name of improved
|
||
robustness. In particular, the sequence "<LF>.<LF>" (bare line
|
||
feeds, without carriage returns) MUST NOT be treated as equivalent to
|
||
<CRLF>.<CRLF> as the end of mail data indication.
|
||
|
||
Receipt of the end of mail data indication requires the server to
|
||
process the stored mail transaction information. This processing
|
||
consumes the information in the reverse-path buffer, the forward-path
|
||
buffer, and the mail data buffer, and on the completion of this
|
||
command these buffers are cleared. If the processing is successful,
|
||
the receiver MUST send an OK reply. If the processing fails, the
|
||
receiver MUST send a failure reply. The SMTP model does not allow
|
||
for partial failures at this point: either the message is accepted by
|
||
the server for delivery and a positive response is returned or it is
|
||
not accepted and a failure reply is returned. In sending a positive
|
||
"250 OK" completion reply to the end of data indication, the receiver
|
||
takes full responsibility for the message (see Section 6.1). Errors
|
||
that are diagnosed subsequently MUST be reported in a mail message,
|
||
as discussed in Section 4.4.
|
||
|
||
When the SMTP server accepts a message either for relaying or for
|
||
final delivery, it inserts a trace record (also referred to
|
||
interchangeably as a "time stamp line" or "Received" line) at the top
|
||
of the mail data. This trace record indicates the identity of the
|
||
host that sent the message, the identity of the host that received
|
||
the message (and is inserting this time stamp), and the date and time
|
||
the message was received. Relayed messages will have multiple time
|
||
stamp lines. Details for formation of these lines, including their
|
||
syntax, is specified in Section 4.4.
|
||
|
||
Additional discussion about the operation of the DATA command appears
|
||
in Section 3.3.
|
||
|
||
Syntax:
|
||
|
||
data = "DATA" CRLF
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 37]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
4.1.1.5. RESET (RSET)
|
||
|
||
This command specifies that the current mail transaction will be
|
||
aborted. Any stored sender, recipients, and mail data MUST be
|
||
discarded, and all buffers and state tables cleared. The receiver
|
||
MUST send a "250 OK" reply to a RSET command with no arguments. A
|
||
reset command may be issued by the client at any time. It is
|
||
effectively equivalent to a NOOP (i.e., it has no effect) if issued
|
||
immediately after EHLO, before EHLO is issued in the session, after
|
||
an end of data indicator has been sent and acknowledged, or
|
||
immediately before a QUIT. An SMTP server MUST NOT close the
|
||
connection as the result of receiving a RSET; that action is reserved
|
||
for QUIT (see Section 4.1.1.10).
|
||
|
||
Since EHLO implies some additional processing and response by the
|
||
server, RSET will normally be more efficient than reissuing that
|
||
command, even though the formal semantics are the same.
|
||
|
||
There are circumstances, contrary to the intent of this
|
||
specification, in which an SMTP server may receive an indication that
|
||
the underlying TCP connection has been closed or reset. To preserve
|
||
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
|
||
before the connection disappeared.
|
||
|
||
Syntax:
|
||
|
||
rset = "RSET" CRLF
|
||
|
||
4.1.1.6. VERIFY (VRFY)
|
||
|
||
This command asks the receiver to confirm that the argument
|
||
identifies a user or mailbox. If it is a user name, information is
|
||
returned as specified in Section 3.5.
|
||
|
||
This command has no effect on the reverse-path buffer, the forward-
|
||
path buffer, or the mail data buffer.
|
||
|
||
Syntax:
|
||
|
||
vrfy = "VRFY" SP String CRLF
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 38]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
4.1.1.7. EXPAND (EXPN)
|
||
|
||
This command asks the receiver to confirm that the argument
|
||
identifies a mailing list, and if so, to return the membership of
|
||
that list. If the command is successful, a reply is returned
|
||
containing information as described in Section 3.5. This reply will
|
||
have multiple lines except in the trivial case of a one-member list.
|
||
|
||
This command has no effect on the reverse-path buffer, the forward-
|
||
path buffer, or the mail data buffer, and it may be issued at any
|
||
time.
|
||
|
||
Syntax:
|
||
|
||
expn = "EXPN" SP String CRLF
|
||
|
||
4.1.1.8. HELP (HELP)
|
||
|
||
This command causes the server to send helpful information to the
|
||
client. The command MAY take an argument (e.g., any command name)
|
||
and return more specific information as a response.
|
||
|
||
This command has no effect on the reverse-path buffer, the forward-
|
||
path buffer, or the mail data buffer, and it may be issued at any
|
||
time.
|
||
|
||
SMTP servers SHOULD support HELP without arguments and MAY support it
|
||
with arguments.
|
||
|
||
Syntax:
|
||
|
||
help = "HELP" [ SP String ] CRLF
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 39]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
4.1.1.9. NOOP (NOOP)
|
||
|
||
This command does not affect any parameters or previously entered
|
||
commands. It specifies no action other than that the receiver send a
|
||
"250 OK" reply.
|
||
|
||
This command has no effect on the reverse-path buffer, the forward-
|
||
path buffer, or the mail data buffer, and it may be issued at any
|
||
time. If a parameter string is specified, servers SHOULD ignore it.
|
||
|
||
Syntax:
|
||
|
||
noop = "NOOP" [ SP String ] CRLF
|
||
|
||
4.1.1.10. QUIT (QUIT)
|
||
|
||
This command specifies that the receiver MUST send a "221 OK" reply,
|
||
and then close the transmission channel.
|
||
|
||
The receiver MUST NOT intentionally close the transmission channel
|
||
until it receives and replies to a QUIT command (even if there was an
|
||
error). The sender MUST NOT intentionally close the transmission
|
||
channel until it sends a QUIT command, and it SHOULD wait until it
|
||
receives the reply (even if there was an error response to a previous
|
||
command). If the connection is closed prematurely due to violations
|
||
of the above or system or network failure, the server MUST cancel any
|
||
pending transaction, but not undo any previously completed
|
||
transaction, and generally MUST act as if the command or transaction
|
||
in progress had received a temporary error (i.e., a 4yz response).
|
||
|
||
The QUIT command may be issued at any time. Any current uncompleted
|
||
mail transaction will be aborted.
|
||
|
||
Syntax:
|
||
|
||
quit = "QUIT" CRLF
|
||
|
||
4.1.1.11. Mail-Parameter and Rcpt-Parameter Error Responses
|
||
|
||
If the server SMTP does not recognize or cannot implement one or more
|
||
of the parameters associated with a particular MAIL FROM or RCPT TO
|
||
command, it will return code 555.
|
||
|
||
If, for some reason, the server is temporarily unable to accommodate
|
||
one or more of the parameters associated with a MAIL FROM or RCPT TO
|
||
command, and if the definition of the specific parameter does not
|
||
mandate the use of another code, it should return code 455.
|
||
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 40]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
Errors specific to particular parameters and their values will be
|
||
specified in the parameter's defining RFC.
|
||
|
||
4.1.2. Command Argument Syntax
|
||
|
||
The syntax of the argument clauses of the above commands (using the
|
||
syntax specified in RFC 5234 [7] where applicable) is given below.
|
||
Some of the productions given below are used only in conjunction with
|
||
source routes as described in Appendix C. Terminals not defined in
|
||
this document, such as ALPHA, DIGIT, SP, CR, LF, CRLF, are as defined
|
||
in the "core" syntax in Section 6 of RFC 5234 [7] or in the message
|
||
format syntax in RFC 5322 [4].
|
||
|
||
Reverse-path = Path / "<>"
|
||
|
||
Forward-path = Path
|
||
|
||
Path = "<" [ A-d-l ":" ] Mailbox ">"
|
||
|
||
A-d-l = At-domain *( "," At-domain )
|
||
; Note that this form, the so-called "source
|
||
; route", MUST BE accepted, SHOULD NOT be
|
||
; generated, and SHOULD be ignored.
|
||
|
||
At-domain = "@" Domain
|
||
|
||
Mail-parameters = esmtp-param *(SP esmtp-param)
|
||
|
||
Rcpt-parameters = esmtp-param *(SP esmtp-param)
|
||
|
||
esmtp-param = esmtp-keyword ["=" esmtp-value]
|
||
|
||
esmtp-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
|
||
|
||
esmtp-value = 1*(%d33-60 / %d62-126)
|
||
; any CHAR excluding "=", SP, and control
|
||
; characters. If this string is an email address,
|
||
; i.e., a Mailbox, then the "xtext" syntax [32]
|
||
; SHOULD be used.
|
||
|
||
Keyword = Ldh-str
|
||
|
||
Argument = Atom
|
||
|
||
Domain = sub-domain *("." sub-domain)
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 41]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
sub-domain = Let-dig [Ldh-str]
|
||
|
||
Let-dig = ALPHA / DIGIT
|
||
|
||
Ldh-str = *( ALPHA / DIGIT / "-" ) Let-dig
|
||
|
||
address-literal = "[" ( IPv4-address-literal /
|
||
IPv6-address-literal /
|
||
General-address-literal ) "]"
|
||
; See Section 4.1.3
|
||
|
||
Mailbox = Local-part "@" ( Domain / address-literal )
|
||
|
||
Local-part = Dot-string / Quoted-string
|
||
; MAY be case-sensitive
|
||
|
||
|
||
Dot-string = Atom *("." Atom)
|
||
|
||
Atom = 1*atext
|
||
|
||
Quoted-string = DQUOTE *QcontentSMTP DQUOTE
|
||
|
||
QcontentSMTP = qtextSMTP / quoted-pairSMTP
|
||
|
||
quoted-pairSMTP = %d92 %d32-126
|
||
; i.e., backslash followed by any ASCII
|
||
; graphic (including itself) or SPace
|
||
|
||
qtextSMTP = %d32-33 / %d35-91 / %d93-126
|
||
; i.e., within a quoted string, any
|
||
; ASCII graphic or space is permitted
|
||
; without blackslash-quoting except
|
||
; double-quote and the backslash itself.
|
||
|
||
String = Atom / Quoted-string
|
||
|
||
While the above definition for Local-part is relatively permissive,
|
||
for maximum interoperability, a host that expects to receive mail
|
||
SHOULD avoid defining mailboxes where the Local-part requires (or
|
||
uses) the Quoted-string form or where the Local-part is case-
|
||
sensitive. For any purposes that require generating or comparing
|
||
Local-parts (e.g., to specific mailbox names), all quoted forms MUST
|
||
be treated as equivalent, and the sending system SHOULD transmit the
|
||
form that uses the minimum quoting possible.
|
||
|
||
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
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 42]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
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
|
||
commands that require mailbox names.
|
||
|
||
Note that the backslash, "\", is a quote character, which is used to
|
||
indicate that the next character is to be used literally (instead of
|
||
its normal interpretation). For example, "Joe\,Smith" indicates a
|
||
single nine-character user name string with the comma being the
|
||
fourth character of that string.
|
||
|
||
To promote interoperability and consistent with long-standing
|
||
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 [2]),
|
||
characters outside the set of alphabetic characters, digits, and
|
||
hyphen MUST NOT appear in domain name labels for SMTP clients or
|
||
servers. In particular, the underscore character is not permitted.
|
||
SMTP servers that receive a command in which invalid character codes
|
||
have been employed, and for which there are no other reasons for
|
||
rejection, MUST reject that command with a 501 response (this rule,
|
||
like others, could be overridden by appropriate SMTP extensions).
|
||
|
||
4.1.3. Address Literals
|
||
|
||
Sometimes a host is not known to the domain name system and
|
||
communication (and, in particular, communication to report and repair
|
||
the error) is blocked. To bypass this barrier, a special literal
|
||
form of the address is allowed as an alternative to a domain name.
|
||
For IPv4 addresses, this form uses four small decimal integers
|
||
separated by dots and enclosed by brackets such as [123.255.37.2],
|
||
which indicates an (IPv4) Internet Address in sequence-of-octets
|
||
form. For IPv6 and other forms of addressing that might eventually
|
||
be standardized, the form consists of a standardized "tag" that
|
||
identifies the address syntax, a colon, and the address itself, in a
|
||
format specified as part of the relevant standards (i.e., RFC 4291
|
||
[8] for IPv6).
|
||
|
||
Specifically:
|
||
|
||
IPv4-address-literal = Snum 3("." Snum)
|
||
|
||
IPv6-address-literal = "IPv6:" IPv6-addr
|
||
|
||
General-address-literal = Standardized-tag ":" 1*dcontent
|
||
|
||
Standardized-tag = Ldh-str
|
||
; Standardized-tag MUST be specified in a
|
||
; Standards-Track RFC and registered with IANA
|
||
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 43]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
dcontent = %d33-90 / ; Printable US-ASCII
|
||
%d94-126 ; excl. "[", "\", "]"
|
||
|
||
Snum = 1*3DIGIT
|
||
; representing a decimal integer
|
||
; value in the range 0 through 255
|
||
|
||
IPv6-addr = IPv6-full / IPv6-comp / IPv6v4-full / IPv6v4-comp
|
||
|
||
IPv6-hex = 1*4HEXDIG
|
||
|
||
IPv6-full = IPv6-hex 7(":" IPv6-hex)
|
||
|
||
IPv6-comp = [IPv6-hex *5(":" IPv6-hex)] "::"
|
||
[IPv6-hex *5(":" IPv6-hex)]
|
||
; The "::" represents at least 2 16-bit groups of
|
||
; zeros. No more than 6 groups in addition to the
|
||
; "::" may be present.
|
||
|
||
IPv6v4-full = IPv6-hex 5(":" IPv6-hex) ":" IPv4-address-literal
|
||
|
||
IPv6v4-comp = [IPv6-hex *3(":" IPv6-hex)] "::"
|
||
[IPv6-hex *3(":" IPv6-hex) ":"]
|
||
IPv4-address-literal
|
||
; The "::" represents at least 2 16-bit groups of
|
||
; zeros. No more than 4 groups in addition to the
|
||
; "::" and IPv4-address-literal may be present.
|
||
|
||
4.1.4. Order of Commands
|
||
|
||
There are restrictions on the order in which these commands may be
|
||
used.
|
||
|
||
A session that will contain mail transactions MUST first be
|
||
initialized by the use of the EHLO command. An SMTP server SHOULD
|
||
accept commands for non-mail transactions (e.g., VRFY or EXPN)
|
||
without this initialization.
|
||
|
||
An EHLO command MAY be issued by a client later in the session. If
|
||
it is issued after the session begins and the EHLO command is
|
||
acceptable to the SMTP server, the SMTP server MUST clear all buffers
|
||
and reset the state exactly as if a RSET command had been issued. In
|
||
other words, the sequence of RSET followed immediately by EHLO is
|
||
redundant, but not harmful other than in the performance cost of
|
||
executing unnecessary commands.
|
||
|
||
If the EHLO command is not acceptable to the SMTP server, 501, 500,
|
||
502, or 550 failure replies MUST be returned as appropriate. The
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 44]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
SMTP server MUST stay in the same state after transmitting these
|
||
replies that it was in before the EHLO was received.
|
||
|
||
The SMTP client MUST, if possible, ensure that the domain parameter
|
||
to the EHLO command is a primary host name as specified for this
|
||
command in Section 2.3.5. If this is not possible (e.g., when the
|
||
client's address is dynamically assigned and the client does not have
|
||
an obvious name), an address literal SHOULD be substituted for the
|
||
domain name.
|
||
|
||
An SMTP server MAY verify that the domain name argument in the EHLO
|
||
command actually corresponds to the IP address of the client.
|
||
However, if the verification fails, the server MUST NOT refuse to
|
||
accept a message on that basis. Information captured in the
|
||
verification attempt is for logging and tracing purposes. Note that
|
||
this prohibition applies to the matching of the parameter to its IP
|
||
address only; see Section 7.9 for a more extensive discussion of
|
||
rejecting incoming connections or mail messages.
|
||
|
||
The NOOP, HELP, EXPN, VRFY, and RSET commands can be used at any time
|
||
during a session, or without previously initializing a session. SMTP
|
||
servers SHOULD process these normally (that is, not return a 503
|
||
code) even if no EHLO command has yet been received; clients SHOULD
|
||
open a session with EHLO before sending these commands.
|
||
|
||
If these rules are followed, the example in RFC 821 that shows "550
|
||
access denied to you" in response to an EXPN command is incorrect
|
||
unless an EHLO command precedes the EXPN or the denial of access is
|
||
based on the client's IP address or other authentication or
|
||
authorization-determining mechanisms.
|
||
|
||
The MAIL command (or the obsolete SEND, SOML, or SAML commands)
|
||
begins a mail transaction. Once started, a mail transaction consists
|
||
of a transaction beginning command, one or more RCPT commands, and a
|
||
DATA command, in that order. A mail transaction may be aborted by
|
||
the RSET, a new EHLO, or the QUIT command. There may be zero or more
|
||
transactions in a session. MAIL (or SEND, SOML, or SAML) MUST NOT be
|
||
sent if a mail transaction is already open, i.e., it should be sent
|
||
only if no mail transaction had been started in the session, or if
|
||
the previous one successfully concluded with a successful DATA
|
||
command, or if the previous one was aborted, e.g., with a RSET or new
|
||
EHLO.
|
||
|
||
If the transaction beginning command argument is not acceptable, a
|
||
501 failure reply MUST be returned and the SMTP server MUST stay in
|
||
the same state. If the commands in a transaction are out of order to
|
||
the degree that they cannot be processed by the server, a 503 failure
|
||
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 45]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
reply MUST be returned and the SMTP server MUST stay in the same
|
||
state.
|
||
|
||
The last command in a session MUST be the QUIT command. The QUIT
|
||
command SHOULD be used by the client SMTP to request connection
|
||
closure, even when no session opening command was sent and accepted.
|
||
|
||
4.1.5. Private-Use Commands
|
||
|
||
As specified in Section 2.2.2, commands starting in "X" may be used
|
||
by bilateral agreement between the client (sending) and server
|
||
(receiving) SMTP agents. An SMTP server that does not recognize such
|
||
a command is expected to reply with "500 Command not recognized". An
|
||
extended SMTP server MAY list the feature names associated with these
|
||
private commands in the response to the EHLO command.
|
||
|
||
Commands sent or accepted by SMTP systems that do not start with "X"
|
||
MUST conform to the requirements of Section 2.2.2.
|
||
|
||
4.2. SMTP Replies
|
||
|
||
Replies to SMTP commands serve to ensure the synchronization of
|
||
requests and actions in the process of mail transfer and to guarantee
|
||
that the SMTP client always knows the state of the SMTP server.
|
||
Every command MUST generate exactly one reply.
|
||
|
||
The details of the command-reply sequence are described in
|
||
Section 4.3.
|
||
|
||
An SMTP reply consists of a three digit number (transmitted as three
|
||
numeric characters) followed by some text unless specified otherwise
|
||
in this document. The number is for use by automata to determine
|
||
what state to enter next; the text is for the human user. The three
|
||
digits contain enough encoded information that the SMTP client need
|
||
not examine the text and may either discard it or pass it on to the
|
||
user, as appropriate. Exceptions are as noted elsewhere in this
|
||
document. In particular, the 220, 221, 251, 421, and 551 reply codes
|
||
are associated with message text that must be parsed and interpreted
|
||
by machines. In the general case, the text may be receiver dependent
|
||
and context dependent, so there are likely to be varying texts for
|
||
each reply code. A discussion of the theory of reply codes is given
|
||
in Section 4.2.1. Formally, a reply is defined to be the sequence: a
|
||
three-digit code, <SP>, one line of text, and <CRLF>, or a multiline
|
||
reply (as defined in the same section). Since, in violation of this
|
||
specification, the text is sometimes not sent, clients that do not
|
||
receive it SHOULD be prepared to process the code alone (with or
|
||
without a trailing space character). Only the EHLO, EXPN, and HELP
|
||
commands are expected to result in multiline replies in normal
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 46]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
circumstances; however, multiline replies are allowed for any
|
||
command.
|
||
|
||
In ABNF, server responses are:
|
||
|
||
Greeting = ( "220 " (Domain / address-literal)
|
||
[ SP textstring ] CRLF ) /
|
||
( "220-" (Domain / address-literal)
|
||
[ SP textstring ] CRLF
|
||
*( "220-" [ textstring ] CRLF )
|
||
"220" [ SP textstring ] CRLF )
|
||
|
||
textstring = 1*(%d09 / %d32-126) ; HT, SP, Printable US-ASCII
|
||
|
||
Reply-line = *( Reply-code "-" [ textstring ] CRLF )
|
||
Reply-code [ SP textstring ] CRLF
|
||
|
||
Reply-code = %x32-35 %x30-35 %x30-39
|
||
|
||
where "Greeting" appears only in the 220 response that announces that
|
||
the server is opening its part of the connection. (Other possible
|
||
server responses upon connection follow the syntax of Reply-line.)
|
||
|
||
An SMTP server SHOULD send only the reply codes listed in this
|
||
document. An SMTP server SHOULD use the text shown in the examples
|
||
whenever appropriate.
|
||
|
||
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
|
||
necessary, 220, 221, and 421 replies); in the general case, any text,
|
||
including no text at all (although senders SHOULD NOT send bare
|
||
codes), MUST be acceptable. The space (blank) following the reply
|
||
code is considered part of the text. Whenever possible, a receiver-
|
||
SMTP SHOULD test the first digit (severity indication) of the reply
|
||
code.
|
||
|
||
The list of codes that appears below MUST NOT be construed as
|
||
permanent. While the addition of new codes should be a rare and
|
||
significant activity, with supplemental information in the textual
|
||
part of the response being preferred, new codes may be added as the
|
||
result of new Standards or Standards-Track specifications.
|
||
Consequently, a sender-SMTP MUST be prepared to handle codes not
|
||
specified in this document and MUST do so by interpreting the first
|
||
digit only.
|
||
|
||
In the absence of extensions negotiated with the client, SMTP servers
|
||
MUST NOT send reply codes whose first digits are other than 2, 3, 4,
|
||
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 47]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
or 5. Clients that receive such out-of-range codes SHOULD normally
|
||
treat them as fatal errors and terminate the mail transaction.
|
||
|
||
4.2.1. Reply Code Severities and Theory
|
||
|
||
The three digits of the reply each have a special significance. The
|
||
first digit denotes whether the response is good, bad, or incomplete.
|
||
An unsophisticated SMTP client, or one that receives an unexpected
|
||
code, will be able to determine its next action (proceed as planned,
|
||
redo, retrench, etc.) by examining this first digit. An SMTP client
|
||
that wants to know approximately what kind of error occurred (e.g.,
|
||
mail system error, command syntax error) may examine the second
|
||
digit. The third digit and any supplemental information that may be
|
||
present is reserved for the finest gradation of information.
|
||
|
||
There are four values for the first digit of the reply code:
|
||
|
||
2yz Positive Completion reply
|
||
The requested action has been successfully completed. A new
|
||
request may be initiated.
|
||
|
||
3yz Positive Intermediate reply
|
||
The command has been accepted, but the requested action is being
|
||
held in abeyance, pending receipt of further information. The
|
||
SMTP client should send another command specifying this
|
||
information. This reply is used in command sequence groups (i.e.,
|
||
in DATA).
|
||
|
||
4yz Transient Negative Completion reply
|
||
The command was not accepted, and the requested action did not
|
||
occur. However, the error condition is temporary, and the action
|
||
may be requested again. The sender should return to the beginning
|
||
of the command sequence (if any). It is difficult to assign a
|
||
meaning to "transient" when two different sites (receiver- and
|
||
sender-SMTP agents) must agree on the interpretation. Each reply
|
||
in this category might have a different time value, but the SMTP
|
||
client SHOULD try again. A rule of thumb to determine whether a
|
||
reply fits into the 4yz or the 5yz category (see below) is that
|
||
replies are 4yz if they can be successful if repeated without any
|
||
change in command form or in properties of the sender or receiver
|
||
(that is, the command is repeated identically and the receiver
|
||
does not put up a new implementation).
|
||
|
||
5yz Permanent Negative Completion reply
|
||
The command was not accepted and the requested action did not
|
||
occur. The SMTP client SHOULD NOT repeat the exact request (in
|
||
the same sequence). Even some "permanent" error conditions can be
|
||
corrected, so the human user may want to direct the SMTP client to
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 48]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
reinitiate the command sequence by direct action at some point in
|
||
the future (e.g., after the spelling has been changed, or the user
|
||
has altered the account status).
|
||
|
||
It is worth noting that the file transfer protocol (FTP) [34] uses a
|
||
very similar code architecture and that the SMTP codes are based on
|
||
the FTP model. However, SMTP uses a one-command, one-response model
|
||
(while FTP is asynchronous) and FTP's 1yz codes are not part of the
|
||
SMTP model.
|
||
|
||
The second digit encodes responses in specific categories:
|
||
|
||
x0z Syntax: These replies refer to syntax errors, syntactically
|
||
correct commands that do not fit any functional category, and
|
||
unimplemented or superfluous commands.
|
||
|
||
x1z Information: These are replies to requests for information, such
|
||
as status or help.
|
||
|
||
x2z Connections: These are replies referring to the transmission
|
||
channel.
|
||
|
||
x3z Unspecified.
|
||
|
||
x4z Unspecified.
|
||
|
||
x5z Mail system: These replies indicate the status of the receiver
|
||
mail system vis-a-vis the requested transfer or other mail system
|
||
action.
|
||
|
||
The third digit gives a finer gradation of meaning in each category
|
||
specified by the second digit. The list of replies illustrates this.
|
||
Each reply text is recommended rather than mandatory, and may even
|
||
change according to the command with which it is associated. On the
|
||
other hand, the reply codes must strictly follow the specifications
|
||
in this section. Receiver implementations should not invent new
|
||
codes for slightly different situations from the ones described here,
|
||
but rather adapt codes already defined.
|
||
|
||
For example, a command such as NOOP, whose successful execution does
|
||
not offer the SMTP client any new information, will return a 250
|
||
reply. The reply is 502 when the command requests an unimplemented
|
||
non-site-specific action. A refinement of that is the 504 reply for
|
||
a command that is implemented, but that requests an unimplemented
|
||
parameter.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 49]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
The reply text may be longer than a single line; in these cases the
|
||
complete text must be marked so the SMTP client knows when it can
|
||
stop reading the reply. This requires a special format to indicate a
|
||
multiple line reply.
|
||
|
||
The format for multiline replies requires that every line, except the
|
||
last, begin with the reply code, followed immediately by a hyphen,
|
||
"-" (also known as minus), followed by text. The last line will
|
||
begin with the reply code, followed immediately by <SP>, optionally
|
||
some text, and <CRLF>. As noted above, servers SHOULD send the <SP>
|
||
if subsequent text is not sent, but clients MUST be prepared for it
|
||
to be omitted.
|
||
|
||
For example:
|
||
|
||
250-First line
|
||
250-Second line
|
||
250-234 Text beginning with numbers
|
||
250 The last line
|
||
|
||
In a multiline reply, the reply code on each of the lines MUST be the
|
||
same. It is reasonable for the client to rely on this, so it can
|
||
make processing decisions based on the code in any line, assuming
|
||
that all others will be the same. In a few cases, there is important
|
||
data for the client in the reply "text". The client will be able to
|
||
identify these cases from the current context.
|
||
|
||
4.2.2. Reply Codes by Function Groups
|
||
|
||
500 Syntax error, command unrecognized (This may include errors such
|
||
as command line too long)
|
||
|
||
501 Syntax error in parameters or arguments
|
||
|
||
502 Command not implemented (see Section 4.2.4)
|
||
|
||
503 Bad sequence of commands
|
||
|
||
504 Command parameter not implemented
|
||
|
||
|
||
211 System status, or system help reply
|
||
|
||
214 Help message (Information on how to use the receiver or the
|
||
meaning of a particular non-standard command; this reply is useful
|
||
only to the human user)
|
||
|
||
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 50]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
220 <domain> Service ready
|
||
|
||
221 <domain> Service 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
|
||
shut down)
|
||
|
||
|
||
250 Requested mail action okay, completed
|
||
|
||
251 User not local; will forward to <forward-path> (See Section 3.4)
|
||
|
||
252 Cannot VRFY user, but will accept message and attempt delivery
|
||
(See Section 3.5.3)
|
||
|
||
455 Server unable to accommodate parameters
|
||
|
||
555 MAIL FROM/RCPT TO parameters not recognized or not implemented
|
||
|
||
450 Requested mail action not taken: mailbox unavailable (e.g.,
|
||
mailbox busy or temporarily blocked for policy reasons)
|
||
|
||
550 Requested action not taken: mailbox unavailable (e.g., mailbox
|
||
not found, no access, or command rejected for policy reasons)
|
||
|
||
451 Requested action aborted: error in processing
|
||
|
||
551 User not local; please try <forward-path> (See Section 3.4)
|
||
|
||
452 Requested action not taken: insufficient system storage
|
||
|
||
552 Requested mail action aborted: exceeded storage allocation
|
||
|
||
553 Requested action not taken: mailbox name not allowed (e.g.,
|
||
mailbox syntax incorrect)
|
||
|
||
354 Start mail input; end with <CRLF>.<CRLF>
|
||
|
||
554 Transaction failed (Or, in the case of a connection-opening
|
||
response, "No SMTP service here")
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 51]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
4.2.3. Reply Codes in Numeric Order
|
||
|
||
211 System status, or system help reply
|
||
|
||
214 Help message (Information on how to use the receiver or the
|
||
meaning of a particular non-standard command; this reply is useful
|
||
only to the human user)
|
||
|
||
220 <domain> Service ready
|
||
|
||
221 <domain> Service closing transmission channel
|
||
|
||
250 Requested mail action okay, completed
|
||
|
||
251 User not local; will forward to <forward-path> (See Section 3.4)
|
||
|
||
252 Cannot VRFY user, but will accept message and attempt delivery
|
||
(See Section 3.5.3)
|
||
|
||
354 Start mail input; end with <CRLF>.<CRLF>
|
||
|
||
421 <domain> Service not available, closing transmission channel
|
||
(This may be a reply to any command if the service knows it must
|
||
shut down)
|
||
|
||
450 Requested mail action not taken: mailbox unavailable (e.g.,
|
||
mailbox busy or temporarily blocked for policy reasons)
|
||
|
||
451 Requested action aborted: local error in processing
|
||
|
||
452 Requested action not taken: insufficient system storage
|
||
|
||
455 Server unable to accommodate parameters
|
||
|
||
500 Syntax error, command unrecognized (This may include errors such
|
||
as command line too long)
|
||
|
||
501 Syntax error in parameters or arguments
|
||
|
||
502 Command not implemented (see Section 4.2.4)
|
||
|
||
503 Bad sequence of commands
|
||
|
||
504 Command parameter not implemented
|
||
|
||
550 Requested action not taken: mailbox unavailable (e.g., mailbox
|
||
not found, no access, or command rejected for policy reasons)
|
||
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 52]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
551 User not local; please try <forward-path> (See Section 3.4)
|
||
|
||
552 Requested mail action aborted: exceeded storage allocation
|
||
|
||
553 Requested action not taken: mailbox name not allowed (e.g.,
|
||
mailbox syntax incorrect)
|
||
|
||
554 Transaction failed (Or, in the case of a connection-opening
|
||
response, "No SMTP service here")
|
||
|
||
555 MAIL FROM/RCPT TO parameters not recognized or not implemented
|
||
|
||
4.2.4. Reply Code 502
|
||
|
||
Questions have been raised as to when reply code 502 (Command not
|
||
implemented) SHOULD be returned in preference to other codes. 502
|
||
SHOULD be used when the command is actually recognized by the SMTP
|
||
server, but not implemented. If the command is not recognized, code
|
||
500 SHOULD be returned. Extended SMTP systems MUST NOT list
|
||
capabilities in response to EHLO for which they will return 502 (or
|
||
500) replies.
|
||
|
||
4.2.5. Reply Codes after DATA and the Subsequent <CRLF>.<CRLF>
|
||
|
||
When an SMTP server returns a positive completion status (2yz code)
|
||
after the DATA command is completed with <CRLF>.<CRLF>, it accepts
|
||
responsibility for:
|
||
|
||
o delivering the message (if the recipient mailbox exists), or
|
||
|
||
o if attempts to deliver the message fail due to transient
|
||
conditions, retrying delivery some reasonable number of times at
|
||
intervals as specified in Section 4.5.4.
|
||
|
||
o if attempts to deliver the message fail due to permanent
|
||
conditions, or if repeated attempts to deliver the message fail
|
||
due to transient conditions, returning appropriate notification to
|
||
the sender of the original message (using the address in the SMTP
|
||
MAIL command).
|
||
|
||
When an SMTP server returns a temporary error status (4yz) code after
|
||
the DATA command is completed with <CRLF>.<CRLF>, it MUST NOT make a
|
||
subsequent attempt to deliver that message. The SMTP client retains
|
||
responsibility for the delivery of that message and may either return
|
||
it to the user or requeue it for a subsequent attempt (see
|
||
Section 4.5.4.1).
|
||
|
||
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 53]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
The user who originated the message SHOULD be able to interpret the
|
||
return of a transient failure status (by mail message or otherwise)
|
||
as a non-delivery indication, just as a permanent failure would be
|
||
interpreted. If the client SMTP successfully handles these
|
||
conditions, the user will not receive such a reply.
|
||
|
||
When an SMTP server returns a permanent error status (5yz) code after
|
||
the DATA command is completed with <CRLF>.<CRLF>, it MUST NOT make
|
||
any subsequent attempt to deliver the message. As with temporary
|
||
error status codes, the SMTP client retains responsibility for the
|
||
message, but SHOULD not again attempt delivery to the same server
|
||
without user review of the message and response and appropriate
|
||
intervention.
|
||
|
||
4.3. Sequencing of Commands and Replies
|
||
|
||
4.3.1. Sequencing Overview
|
||
|
||
The communication between the sender and receiver is an alternating
|
||
dialogue, controlled by the sender. As such, the sender issues a
|
||
command and the receiver responds with a reply. Unless other
|
||
arrangements are negotiated through service extensions, the sender
|
||
MUST wait for this response before sending further commands. One
|
||
important reply is the connection greeting. Normally, a receiver
|
||
will send a 220 "Service ready" reply when the connection is
|
||
completed. The sender SHOULD wait for this greeting message before
|
||
sending any commands.
|
||
|
||
Note: all the greeting-type replies have the official name (the
|
||
fully-qualified primary domain name) of the server host as the first
|
||
word following the reply code. Sometimes the host will have no
|
||
meaningful name. See Section 4.1.3 for a discussion of alternatives
|
||
in these situations.
|
||
|
||
For example,
|
||
|
||
220 ISIF.USC.EDU Service ready
|
||
|
||
or
|
||
|
||
220 mail.example.com SuperSMTP v 6.1.2 Service ready
|
||
|
||
or
|
||
|
||
220 [10.0.0.1] Clueless host service ready
|
||
|
||
The table below lists alternative success and failure replies for
|
||
each command. These SHOULD be strictly adhered to. A receiver MAY
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 54]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
substitute text in the replies, but the meanings and actions implied
|
||
by the code numbers and by the specific command reply sequence MUST
|
||
be preserved.
|
||
|
||
4.3.2. Command-Reply Sequences
|
||
|
||
Each command is listed with its usual possible replies. The prefixes
|
||
used before the possible replies are "I" for intermediate, "S" for
|
||
success, and "E" for error. Since some servers may generate other
|
||
replies under special circumstances, and to allow for future
|
||
extension, SMTP clients SHOULD, when possible, interpret only the
|
||
first digit of the reply and MUST be prepared to deal with
|
||
unrecognized reply codes by interpreting the first digit only.
|
||
Unless extended using the mechanisms described in Section 2.2, SMTP
|
||
servers MUST NOT transmit reply codes to an SMTP client that are
|
||
other than three digits or that do not start in a digit between 2 and
|
||
5 inclusive.
|
||
|
||
These sequencing rules and, in principle, the codes themselves, can
|
||
be extended or modified by SMTP extensions offered by the server and
|
||
accepted (requested) by the client. However, if the target is more
|
||
precise granularity in the codes, rather than codes for completely
|
||
new purposes, the system described in RFC 3463 [25] SHOULD be used in
|
||
preference to the invention of new codes.
|
||
|
||
In addition to the codes listed below, any SMTP command can return
|
||
any of the following codes if the corresponding unusual circumstances
|
||
are encountered:
|
||
|
||
500 For the "command line too long" case or if the command name was
|
||
not recognized. Note that producing a "command not recognized"
|
||
error in response to the required subset of these commands is a
|
||
violation of this specification. Similarly, producing a "command
|
||
too long" message for a command line shorter than 512 characters
|
||
would violate the provisions of Section 4.5.3.1.4.
|
||
|
||
501 Syntax error in command or arguments. In order to provide for
|
||
future extensions, commands that are specified in this document as
|
||
not accepting arguments (DATA, RSET, QUIT) SHOULD return a 501
|
||
message if arguments are supplied in the absence of EHLO-
|
||
advertised extensions.
|
||
|
||
421 Service shutting down and closing transmission channel
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 55]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
Specific sequences are:
|
||
|
||
CONNECTION ESTABLISHMENT
|
||
|
||
S: 220
|
||
E: 554
|
||
|
||
EHLO or HELO
|
||
|
||
S: 250
|
||
E: 504 (a conforming implementation could return this code only
|
||
in fairly obscure cases), 550, 502 (permitted only with an old-
|
||
style server that does not support EHLO)
|
||
|
||
MAIL
|
||
|
||
S: 250
|
||
E: 552, 451, 452, 550, 553, 503, 455, 555
|
||
|
||
RCPT
|
||
|
||
S: 250, 251 (but see Section 3.4 for discussion of 251 and 551)
|
||
E: 550, 551, 552, 553, 450, 451, 452, 503, 455, 555
|
||
|
||
DATA
|
||
|
||
I: 354 -> data -> S: 250
|
||
|
||
E: 552, 554, 451, 452
|
||
|
||
E: 450, 550 (rejections for policy reasons)
|
||
|
||
E: 503, 554
|
||
|
||
RSET
|
||
|
||
S: 250
|
||
|
||
VRFY
|
||
|
||
S: 250, 251, 252
|
||
E: 550, 551, 553, 502, 504
|
||
|
||
EXPN
|
||
|
||
S: 250, 252
|
||
E: 550, 500, 502, 504
|
||
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 56]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
HELP
|
||
|
||
S: 211, 214
|
||
E: 502, 504
|
||
|
||
NOOP
|
||
|
||
S: 250
|
||
|
||
QUIT
|
||
|
||
S: 221
|
||
|
||
4.4. Trace Information
|
||
|
||
When an SMTP server receives a message for delivery or further
|
||
processing, it MUST insert trace ("time stamp" or "Received")
|
||
information at the beginning of the message content, as discussed in
|
||
Section 4.1.1.4.
|
||
|
||
This line MUST be structured as follows:
|
||
|
||
o The FROM clause, which MUST be supplied in an SMTP environment,
|
||
SHOULD contain both (1) the name of the source host as presented
|
||
in the EHLO command and (2) an address literal containing the IP
|
||
address of the source, determined from the TCP connection.
|
||
|
||
o The ID clause MAY contain an "@" as suggested in RFC 822, but this
|
||
is not required.
|
||
|
||
o If the FOR clause appears, it MUST contain exactly one <path>
|
||
entry, even when multiple RCPT commands have been given. Multiple
|
||
<path>s raise some security issues and have been deprecated, see
|
||
Section 7.2.
|
||
|
||
An Internet mail program MUST NOT change or delete a Received: line
|
||
that was previously added to the message header section. SMTP
|
||
servers MUST prepend Received lines to messages; they MUST NOT change
|
||
the order of existing lines or insert Received lines in any other
|
||
location.
|
||
|
||
As the Internet grows, comparability of Received header fields is
|
||
important for detecting problems, especially slow relays. SMTP
|
||
servers that create Received header fields SHOULD use explicit
|
||
offsets in the dates (e.g., -0800), rather than time zone names of
|
||
any type. Local time (with an offset) SHOULD be used rather than UT
|
||
when feasible. This formulation allows slightly more information
|
||
about local circumstances to be specified. If UT is needed, the
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 57]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
receiver need merely do some simple arithmetic to convert the values.
|
||
Use of UT loses information about the time zone-location of the
|
||
server. If it is desired to supply a time zone name, it SHOULD be
|
||
included in a comment.
|
||
|
||
When the delivery SMTP server makes the "final delivery" of a
|
||
message, it inserts a return-path line at the beginning of the mail
|
||
data. This use of return-path is required; mail systems MUST support
|
||
it. The return-path line preserves the information in the <reverse-
|
||
path> from the MAIL command. Here, final delivery means the message
|
||
has left the SMTP environment. Normally, this would mean it had been
|
||
delivered to the destination user or an associated mail drop, but in
|
||
some cases it may be further processed and transmitted by another
|
||
mail system.
|
||
|
||
It is possible for the mailbox in the return path to be different
|
||
from the actual sender's mailbox, for example, if error responses are
|
||
to be delivered to a special error handling mailbox rather than to
|
||
the message sender. When mailing lists are involved, this
|
||
arrangement is common and useful as a means of directing errors to
|
||
the list maintainer rather than the message originator.
|
||
|
||
The text above implies that the final mail data will begin with a
|
||
return path line, followed by one or more time stamp lines. These
|
||
lines will be followed by the rest of the mail data: first the
|
||
balance of the mail header section and then the body (RFC 5322 [4]).
|
||
|
||
It is sometimes difficult for an SMTP server to determine whether or
|
||
not it is making final delivery since forwarding or other operations
|
||
may occur after the message is accepted for delivery. Consequently,
|
||
any further (forwarding, gateway, or relay) systems MAY remove the
|
||
return path and rebuild the MAIL command as needed to ensure that
|
||
exactly one such line appears in a delivered message.
|
||
|
||
A message-originating SMTP system SHOULD NOT send a message that
|
||
already contains a Return-path header field. SMTP servers performing
|
||
a relay function MUST NOT inspect the message data, and especially
|
||
not to the extent needed to determine if Return-path header fields
|
||
are present. SMTP servers making final delivery MAY remove Return-
|
||
path header fields before adding their own.
|
||
|
||
The primary purpose of the Return-path is to designate the address to
|
||
which messages indicating non-delivery or other mail system failures
|
||
are to be sent. For this to be unambiguous, exactly one return path
|
||
SHOULD be present when the message is delivered. Systems using RFC
|
||
822 syntax with non-SMTP transports SHOULD designate an unambiguous
|
||
address, associated with the transport envelope, to which error
|
||
reports (e.g., non-delivery messages) should be sent.
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 58]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
Historical note: Text in RFC 822 that appears to contradict the use
|
||
of the Return-path header field (or the envelope reverse-path address
|
||
from the MAIL command) as the destination for error messages is not
|
||
applicable on the Internet. The reverse-path address (as copied into
|
||
the Return-path) MUST be used as the target of any mail containing
|
||
delivery error messages.
|
||
|
||
In particular:
|
||
o a gateway from SMTP -> elsewhere SHOULD insert a return-path
|
||
header field, unless it is known that the "elsewhere" transport
|
||
also uses Internet domain addresses and maintains the envelope
|
||
sender address separately.
|
||
|
||
o a gateway from elsewhere -> SMTP SHOULD delete any return-path
|
||
header field present in the message, and either copy that
|
||
information to the SMTP envelope or combine it with information
|
||
present in the envelope of the other transport system to construct
|
||
the reverse-path argument to the MAIL command in the SMTP
|
||
envelope.
|
||
|
||
The server must give special treatment to cases in which the
|
||
processing following the end of mail data indication is only
|
||
partially successful. This could happen if, after accepting several
|
||
recipients and the mail data, the SMTP server finds that the mail
|
||
data could be successfully delivered to some, but not all, of the
|
||
recipients. In such cases, the response to the DATA command MUST be
|
||
an OK reply. However, the SMTP server MUST compose and send an
|
||
"undeliverable mail" notification message to the originator of the
|
||
message.
|
||
|
||
A single notification listing all of the failed recipients or
|
||
separate notification messages MUST be sent for each failed
|
||
recipient. For economy of processing by the sender, the former
|
||
SHOULD be used when possible. Note that the key difference between
|
||
handling aliases (Section 3.9.1) and forwarding (this subsection) is
|
||
the change to the backward-pointing address in this case. All
|
||
notification messages about undeliverable mail MUST be sent using the
|
||
MAIL command (even if they result from processing the obsolete SEND,
|
||
SOML, or SAML commands) and MUST use a null return path as discussed
|
||
in Section 3.6.
|
||
|
||
The time stamp line and the return path line are formally defined as
|
||
follows (the definitions for "FWS" and "CFWS" appear in RFC 5322
|
||
[4]):
|
||
|
||
Return-path-line = "Return-Path:" FWS Reverse-path <CRLF>
|
||
|
||
Time-stamp-line = "Received:" FWS Stamp <CRLF>
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 59]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
Stamp = From-domain By-domain Opt-info [CFWS] ";"
|
||
FWS date-time
|
||
; where "date-time" is as defined in RFC 5322 [4]
|
||
; but the "obs-" forms, especially two-digit
|
||
; years, are prohibited in SMTP and MUST NOT be used.
|
||
|
||
From-domain = "FROM" FWS Extended-Domain
|
||
|
||
By-domain = CFWS "BY" FWS Extended-Domain
|
||
|
||
Extended-Domain = Domain /
|
||
( Domain FWS "(" TCP-info ")" ) /
|
||
( address-literal FWS "(" TCP-info ")" )
|
||
|
||
TCP-info = address-literal / ( Domain FWS address-literal )
|
||
; Information derived by server from TCP connection
|
||
; not client EHLO.
|
||
|
||
Opt-info = [Via] [With] [ID] [For]
|
||
[Additional-Registered-Clauses]
|
||
|
||
Via = CFWS "VIA" FWS Link
|
||
|
||
With = CFWS "WITH" FWS Protocol
|
||
|
||
ID = CFWS "ID" FWS ( Atom / msg-id )
|
||
; msg-id is defined in RFC 5322 [4]
|
||
|
||
For = CFWS "FOR" FWS ( Path / Mailbox )
|
||
|
||
Additional-Registered-Clauses = CFWS Atom FWS String
|
||
; Additional standard clauses may be
|
||
added in this
|
||
; location by future standards and
|
||
registration with
|
||
; IANA. SMTP servers SHOULD NOT use
|
||
unregistered
|
||
; names. See Section 8.
|
||
|
||
Link = "TCP" / Addtl-Link
|
||
|
||
Addtl-Link = Atom
|
||
; Additional standard names for links are
|
||
; registered with the Internet Assigned Numbers
|
||
; Authority (IANA). "Via" is primarily of value
|
||
; with non-Internet transports. SMTP servers
|
||
; SHOULD NOT use unregistered names.
|
||
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 60]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
Protocol = "ESMTP" / "SMTP" / Attdl-Protocol
|
||
|
||
Attdl-Protocol = Atom
|
||
; Additional standard names for protocols are
|
||
; registered with the Internet Assigned Numbers
|
||
; Authority (IANA) in the "mail parameters"
|
||
; registry [9]. SMTP servers SHOULD NOT
|
||
; use unregistered names.
|
||
|
||
4.5. Additional Implementation Issues
|
||
|
||
4.5.1. Minimum Implementation
|
||
|
||
In order to make SMTP workable, the following minimum implementation
|
||
MUST be provided by all receivers. The following commands MUST be
|
||
supported to conform to this specification:
|
||
|
||
EHLO
|
||
HELO
|
||
MAIL
|
||
RCPT
|
||
DATA
|
||
RSET
|
||
NOOP
|
||
QUIT
|
||
VRFY
|
||
|
||
Any system that includes an SMTP server supporting mail relaying or
|
||
delivery MUST support the reserved mailbox "postmaster" as a case-
|
||
insensitive local name. This postmaster address is not strictly
|
||
necessary if the server always returns 554 on connection opening (as
|
||
described in Section 3.1). The requirement to accept mail for
|
||
postmaster implies that RCPT commands that specify a mailbox for
|
||
postmaster at any of the domains for which the SMTP server provides
|
||
mail service, as well as the special case of "RCPT TO:<Postmaster>"
|
||
(with no domain specification), MUST be supported.
|
||
|
||
SMTP systems are expected to make every reasonable effort to accept
|
||
mail directed to Postmaster from any other system on the Internet.
|
||
In extreme cases -- such as to contain a denial of service attack or
|
||
other breach of security -- an SMTP server may block mail directed to
|
||
Postmaster. However, such arrangements SHOULD be narrowly tailored
|
||
so as to avoid blocking messages that are not part of such attacks.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 61]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
4.5.2. Transparency
|
||
|
||
Without some provision for data transparency, the character sequence
|
||
"<CRLF>.<CRLF>" ends the mail text and cannot be sent by the user.
|
||
In general, users are not aware of such "forbidden" sequences. To
|
||
allow all user composed text to be transmitted transparently, the
|
||
following procedures are used:
|
||
|
||
o Before sending a line of mail text, the SMTP client checks the
|
||
first character of the line. If it is a period, one additional
|
||
period is inserted at the beginning of the line.
|
||
|
||
o When a line of mail text is received by the SMTP server, it checks
|
||
the line. If the line is composed of a single period, it is
|
||
treated as the end of mail indicator. If the first character is a
|
||
period and there are other characters on the line, the first
|
||
character is deleted.
|
||
|
||
The mail data may contain any of the 128 ASCII characters. All
|
||
characters are to be delivered to the recipient's mailbox, including
|
||
spaces, vertical and horizontal tabs, and other control characters.
|
||
If the transmission channel provides an 8-bit byte (octet) data
|
||
stream, the 7-bit ASCII codes are transmitted, right justified, in
|
||
the octets, with the high-order bits cleared to zero. See
|
||
Section 3.6 for special treatment of these conditions in SMTP systems
|
||
serving a relay function.
|
||
|
||
In some systems, it may be necessary to transform the data as it is
|
||
received and stored. This may be necessary for hosts that use a
|
||
different character set than ASCII as their local character set, that
|
||
store data in records rather than strings, or which use special
|
||
character sequences as delimiters inside mailboxes. If such
|
||
transformations are necessary, they MUST be reversible, especially if
|
||
they are applied to mail being relayed.
|
||
|
||
4.5.3. Sizes and Timeouts
|
||
|
||
4.5.3.1. Size Limits and Minimums
|
||
|
||
There are several objects that have required minimum/maximum sizes.
|
||
Every implementation MUST be able to receive objects of at least
|
||
these sizes. Objects larger than these sizes SHOULD be avoided when
|
||
possible. However, some Internet mail constructs such as encoded
|
||
X.400 addresses (RFC 2156 [35]) will often require larger objects.
|
||
Clients MAY attempt to transmit these, but MUST be prepared for a
|
||
server to reject them if they cannot be handled by it. To the
|
||
maximum extent possible, implementation techniques that impose no
|
||
limits on the length of these objects should be used.
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 62]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
Extensions to SMTP may involve the use of characters that occupy more
|
||
than a single octet each. This section therefore specifies lengths
|
||
in octets where absolute lengths, rather than character counts, are
|
||
intended.
|
||
|
||
4.5.3.1.1. Local-part
|
||
|
||
The maximum total length of a user name or other local-part is 64
|
||
octets.
|
||
|
||
4.5.3.1.2. Domain
|
||
|
||
The maximum total length of a domain name or number is 255 octets.
|
||
|
||
4.5.3.1.3. Path
|
||
|
||
The maximum total length of a reverse-path or forward-path is 256
|
||
octets (including the punctuation and element separators).
|
||
|
||
4.5.3.1.4. Command Line
|
||
|
||
The maximum total length of a command line including the command word
|
||
and the <CRLF> is 512 octets. SMTP extensions may be used to
|
||
increase this limit.
|
||
|
||
4.5.3.1.5. Reply Line
|
||
|
||
The maximum total length of a reply line including the reply code and
|
||
the <CRLF> is 512 octets. More information may be conveyed through
|
||
multiple-line replies.
|
||
|
||
4.5.3.1.6. Text Line
|
||
|
||
The maximum total length of a text line including the <CRLF> is 1000
|
||
octets (not counting the leading dot duplicated for transparency).
|
||
This number may be increased by the use of SMTP Service Extensions.
|
||
|
||
4.5.3.1.7. Message Content
|
||
|
||
The maximum total length of a message content (including any message
|
||
header section as well as the message body) MUST BE at least 64K
|
||
octets. Since the introduction of Internet Standards for multimedia
|
||
mail (RFC 2045 [21]), message lengths on the Internet have grown
|
||
dramatically, and message size restrictions should be avoided if at
|
||
all possible. SMTP server systems that must impose restrictions
|
||
SHOULD implement the "SIZE" service extension of RFC 1870 [10], and
|
||
SMTP client systems that will send large messages SHOULD utilize it
|
||
when possible.
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 63]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
4.5.3.1.8. Recipients Buffer
|
||
|
||
The minimum total number of recipients that MUST be buffered is 100
|
||
recipients. Rejection of messages (for excessive recipients) with
|
||
fewer than 100 RCPT commands is a violation of this specification.
|
||
The general principle that relaying SMTP server MUST NOT, and
|
||
delivery SMTP servers SHOULD NOT, perform validation tests on message
|
||
header fields suggests that messages SHOULD NOT be rejected based on
|
||
the total number of recipients shown in header fields. A server that
|
||
imposes a limit on the number of recipients MUST behave in an orderly
|
||
fashion, such as rejecting additional addresses over its limit rather
|
||
than silently discarding addresses previously accepted. A client
|
||
that needs to deliver a message containing over 100 RCPT commands
|
||
SHOULD be prepared to transmit in 100-recipient "chunks" if the
|
||
server declines to accept more than 100 recipients in a single
|
||
message.
|
||
|
||
4.5.3.1.9. Treatment When Limits Exceeded
|
||
|
||
Errors due to exceeding these limits may be reported by using the
|
||
reply codes. Some examples of reply codes are:
|
||
|
||
500 Line too long.
|
||
|
||
or
|
||
|
||
501 Path too long
|
||
|
||
or
|
||
|
||
452 Too many recipients (see below)
|
||
|
||
or
|
||
|
||
552 Too much mail data.
|
||
|
||
4.5.3.1.10. Too Many Recipients Code
|
||
|
||
RFC 821 [1] incorrectly listed the error where an SMTP server
|
||
exhausts its implementation limit on the number of RCPT commands
|
||
("too many recipients") as having reply code 552. The correct reply
|
||
code for this condition is 452. Clients SHOULD treat a 552 code in
|
||
this case as a temporary, rather than permanent, failure so the logic
|
||
below works.
|
||
|
||
When a conforming SMTP server encounters this condition, it has at
|
||
least 100 successful RCPT commands in its recipients buffer. If the
|
||
server is able to accept the message, then at least these 100
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 64]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
addresses will be removed from the SMTP client's queue. When the
|
||
client attempts retransmission of those addresses that received 452
|
||
responses, at least 100 of these will be able to fit in the SMTP
|
||
server's recipients buffer. Each retransmission attempt that is able
|
||
to deliver anything will be able to dispose of at least 100 of these
|
||
recipients.
|
||
|
||
If an SMTP server has an implementation limit on the number of RCPT
|
||
commands and this limit is exhausted, it MUST use a response code of
|
||
452 (but the client SHOULD also be prepared for a 552, as noted
|
||
above). If the server has a configured site-policy limitation on the
|
||
number of RCPT commands, it MAY instead use a 5yz response code. In
|
||
particular, if the intent is to prohibit messages with more than a
|
||
site-specified number of recipients, rather than merely limit the
|
||
number of recipients in a given mail transaction, it would be
|
||
reasonable to return a 503 response to any DATA command received
|
||
subsequent to the 452 (or 552) code or to simply return the 503 after
|
||
DATA without returning any previous negative response.
|
||
|
||
4.5.3.2. Timeouts
|
||
|
||
An SMTP client MUST provide a timeout mechanism. It MUST use per-
|
||
command timeouts rather than somehow trying to time the entire mail
|
||
transaction. Timeouts SHOULD be easily reconfigurable, preferably
|
||
without recompiling the SMTP code. To implement this, a timer is set
|
||
for each SMTP command and for each buffer of the data transfer. The
|
||
latter means that the overall timeout is inherently proportional to
|
||
the size of the message.
|
||
|
||
Based on extensive experience with busy mail-relay hosts, the minimum
|
||
per-command timeout values SHOULD be as follows:
|
||
|
||
4.5.3.2.1. Initial 220 Message: 5 Minutes
|
||
|
||
An SMTP client process needs to distinguish between a failed TCP
|
||
connection and a delay in receiving the initial 220 greeting message.
|
||
Many SMTP servers accept a TCP connection but delay delivery of the
|
||
220 message until their system load permits more mail to be
|
||
processed.
|
||
|
||
4.5.3.2.2. MAIL Command: 5 Minutes
|
||
|
||
4.5.3.2.3. RCPT Command: 5 Minutes
|
||
|
||
A longer timeout is required if processing of mailing lists and
|
||
aliases is not deferred until after the message was accepted.
|
||
|
||
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 65]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
4.5.3.2.4. DATA Initiation: 2 Minutes
|
||
|
||
This is while awaiting the "354 Start Input" reply to a DATA command.
|
||
|
||
4.5.3.2.5. Data Block: 3 Minutes
|
||
|
||
This is while awaiting the completion of each TCP SEND call
|
||
transmitting a chunk of data.
|
||
|
||
4.5.3.2.6. DATA Termination: 10 Minutes.
|
||
|
||
This is while awaiting the "250 OK" reply. When the receiver gets
|
||
the final period terminating the message data, it typically performs
|
||
processing to deliver the message to a user mailbox. A spurious
|
||
timeout at this point would be very wasteful and would typically
|
||
result in delivery of multiple copies of the message, since it has
|
||
been successfully sent and the server has accepted responsibility for
|
||
delivery. See Section 6.1 for additional discussion.
|
||
|
||
4.5.3.2.7. Server Timeout: 5 Minutes.
|
||
|
||
An SMTP server SHOULD have a timeout of at least 5 minutes while it
|
||
is awaiting the next command from the sender.
|
||
|
||
4.5.4. Retry Strategies
|
||
|
||
The common structure of a host SMTP implementation includes user
|
||
mailboxes, one or more areas for queuing messages in transit, and one
|
||
or more daemon processes for sending and receiving mail. The exact
|
||
structure will vary depending on the needs of the users on the host
|
||
and the number and size of mailing lists supported by the host. We
|
||
describe several optimizations that have proved helpful, particularly
|
||
for mailers supporting high traffic levels.
|
||
|
||
Any queuing strategy MUST include timeouts on all activities on a
|
||
per-command basis. A queuing strategy MUST NOT send error messages
|
||
in response to error messages under any circumstances.
|
||
|
||
4.5.4.1. Sending Strategy
|
||
|
||
The general model for an SMTP client is one or more processes that
|
||
periodically attempt to transmit outgoing mail. In a typical system,
|
||
the program that composes a message has some method for requesting
|
||
immediate attention for a new piece of outgoing mail, while mail that
|
||
cannot be transmitted immediately MUST be queued and periodically
|
||
retried by the sender. A mail queue entry will include not only the
|
||
message itself but also the envelope information.
|
||
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 66]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
The sender MUST delay retrying a particular destination after one
|
||
attempt has failed. In general, the retry interval SHOULD be at
|
||
least 30 minutes; however, more sophisticated and variable strategies
|
||
will be beneficial when the SMTP client can determine the reason for
|
||
non-delivery.
|
||
|
||
Retries continue until the message is transmitted or the sender gives
|
||
up; the give-up time generally needs to be at least 4-5 days. It MAY
|
||
be appropriate to set a shorter maximum number of retries for non-
|
||
delivery notifications and equivalent error messages than for
|
||
standard messages. The parameters to the retry algorithm MUST be
|
||
configurable.
|
||
|
||
A client SHOULD keep a list of hosts it cannot reach and
|
||
corresponding connection timeouts, rather than just retrying queued
|
||
mail items.
|
||
|
||
Experience suggests that failures are typically transient (the target
|
||
system or its connection has crashed), favoring a policy of two
|
||
connection attempts in the first hour the message is in the queue,
|
||
and then backing off to one every two or three hours.
|
||
|
||
The SMTP client can shorten the queuing delay in cooperation with the
|
||
SMTP server. For example, if mail is received from a particular
|
||
address, it is likely that mail queued for that host can now be sent.
|
||
Application of this principle may, in many cases, eliminate the
|
||
requirement for an explicit "send queues now" function such as ETRN,
|
||
RFC 1985 [36].
|
||
|
||
The strategy may be further modified as a result of multiple
|
||
addresses per host (see below) to optimize delivery time versus
|
||
resource usage.
|
||
|
||
An SMTP client may have a large queue of messages for each
|
||
unavailable destination host. If all of these messages were retried
|
||
in every retry cycle, there would be excessive Internet overhead and
|
||
the sending system would be blocked for a long period. Note that an
|
||
SMTP client can generally determine that a delivery attempt has
|
||
failed only after a timeout of several minutes, and even a one-minute
|
||
timeout per connection will result in a very large delay if retries
|
||
are repeated for dozens, or even hundreds, of queued messages to the
|
||
same host.
|
||
|
||
At the same time, SMTP clients SHOULD use great care in caching
|
||
negative responses from servers. In an extreme case, if EHLO is
|
||
issued multiple times during the same SMTP connection, different
|
||
answers may be returned by the server. More significantly, 5yz
|
||
responses to the MAIL command MUST NOT be cached.
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 67]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
When a mail message is to be delivered to multiple recipients, and
|
||
the SMTP server to which a copy of the message is to be sent is the
|
||
same for multiple recipients, then only one copy of the message
|
||
SHOULD be transmitted. That is, the SMTP client SHOULD use the
|
||
command sequence: MAIL, RCPT, RCPT, ..., RCPT, DATA instead of the
|
||
sequence: MAIL, RCPT, DATA, ..., MAIL, RCPT, DATA. However, if there
|
||
are very many addresses, a limit on the number of RCPT commands per
|
||
MAIL command MAY be imposed. This efficiency feature SHOULD be
|
||
implemented.
|
||
|
||
Similarly, to achieve timely delivery, the SMTP client MAY support
|
||
multiple concurrent outgoing mail transactions. However, some limit
|
||
may be appropriate to protect the host from devoting all its
|
||
resources to mail.
|
||
|
||
4.5.4.2. Receiving Strategy
|
||
|
||
The SMTP server SHOULD attempt to keep a pending listen on the SMTP
|
||
port (specified by IANA as port 25) at all times. This requires the
|
||
support of multiple incoming TCP connections for SMTP. Some limit
|
||
MAY be imposed, but servers that cannot handle more than one SMTP
|
||
transaction at a time are not in conformance with the intent of this
|
||
specification.
|
||
|
||
As discussed above, when the SMTP server receives mail from a
|
||
particular host address, it could activate its own SMTP queuing
|
||
mechanisms to retry any mail pending for that host address.
|
||
|
||
4.5.5. Messages with a Null Reverse-Path
|
||
|
||
There are several types of notification messages that are required by
|
||
existing and proposed Standards to be sent with a null reverse-path,
|
||
namely non-delivery notifications as discussed in Section 3.7, other
|
||
kinds of Delivery Status Notifications (DSNs, RFC 3461 [32]), and
|
||
Message Disposition Notifications (MDNs, RFC 3798 [37]). All of
|
||
these kinds of messages are notifications about a previous message,
|
||
and they are sent to the reverse-path of the previous mail message.
|
||
(If the delivery of such a notification message fails, that usually
|
||
indicates a problem with the mail system of the host to which the
|
||
notification message is addressed. For this reason, at some hosts
|
||
the MTA is set up to forward such failed notification messages to
|
||
someone who is able to fix problems with the mail system, e.g., via
|
||
the postmaster alias.)
|
||
|
||
All other types of messages (i.e., any message which is not required
|
||
by a Standards-Track RFC to have a null reverse-path) SHOULD be sent
|
||
with a valid, non-null reverse-path.
|
||
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 68]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
Implementers of automated email processors should be careful to make
|
||
sure that the various kinds of messages with a null reverse-path are
|
||
handled correctly. In particular, such systems SHOULD NOT reply to
|
||
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
|
||
such messages when forwarding.
|
||
|
||
5. Address Resolution and Mail Handling
|
||
|
||
5.1. Locating the Target Host
|
||
|
||
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),
|
||
a DNS lookup MUST be performed to resolve the domain name (RFC 1035
|
||
[2]). The names are expected to be fully-qualified domain names
|
||
(FQDNs): mechanisms for inferring FQDNs from partial names or local
|
||
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 [18] 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
|
||
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
|
||
returned, this situation MUST be reported as an error. If a
|
||
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,
|
||
the address is treated as if it was associated with an implicit MX
|
||
RR, 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,
|
||
this situation MUST be reported as an error.
|
||
|
||
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
|
||
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
|
||
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
|
||
associated data field obtained, the data field of that response MUST
|
||
contain a domain name. 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 server to which the message should be directed.
|
||
Any other response, specifically including a value that will return a
|
||
CNAME record when queried, lies outside the scope of this Standard.
|
||
The prohibition on labels in the data that resolve to CNAMEs is
|
||
discussed in more detail in RFC 2181, Section 10.3 [38].
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 69]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
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:
|
||
multiple MX records, and multihomed hosts.
|
||
|
||
MX records contain a preference indication that MUST be used in
|
||
sorting if more than one such record appears (see below). Lower
|
||
numbers are more preferred than higher ones. If there are multiple
|
||
destinations 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
|
||
be multihomed, in which case the domain name resolver will return a
|
||
list of alternative IP addresses. It is the responsibility of the
|
||
domain name resolver interface to have ordered this list by
|
||
decreasing preference if necessary, and the SMTP sender MUST try them
|
||
in the order presented.
|
||
|
||
Although the capability to try multiple alternative addresses is
|
||
required, specific installations may want to limit or disable the use
|
||
of alternative addresses. The question of whether a sender should
|
||
attempt retries using the different addresses of a multihomed host
|
||
has been controversial. The main argument for using the multiple
|
||
addresses is that it maximizes the probability of timely delivery,
|
||
and indeed sometimes the probability of any delivery; the counter-
|
||
argument is that it may result in unnecessary resource use. Note
|
||
that resource use is also strongly determined by the sending strategy
|
||
discussed in Section 4.5.4.1.
|
||
|
||
If an SMTP server receives a message with a destination for which it
|
||
is a designated Mail eXchanger, it MAY relay the message (potentially
|
||
after having rewritten the MAIL FROM and/or RCPT TO addresses), make
|
||
final delivery of the message, or hand it off using some mechanism
|
||
outside the SMTP-provided transport environment. Of course, neither
|
||
of the latter require that the list of MX records be examined
|
||
further.
|
||
|
||
If it determines that it should relay the message without rewriting
|
||
the address, it MUST sort the MX records to determine candidates for
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 70]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
delivery. The records are first ordered by preference, with the
|
||
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
|
||
|
||
In the contemporary Internet, SMTP clients and servers may be hosted
|
||
on IPv4 systems, IPv6 systems, or dual-stack systems that are
|
||
compatible with either version of the Internet Protocol. The host
|
||
domains to which MX records point may, consequently, contain "A RR"s
|
||
(IPv4), "AAAA RR"s (IPv6), or any combination of them. While RFC
|
||
3974 [39] discusses some operational experience in mixed
|
||
environments, it was not comprehensive enough to justify
|
||
standardization, and some of its recommendations appear to be
|
||
inconsistent with this specification. The appropriate actions to be
|
||
taken either will depend on local circumstances, such as performance
|
||
of the relevant networks and any conversions that might be necessary,
|
||
or will be obvious (e.g., an IPv6-only client need not attempt to
|
||
look up A RRs or attempt to reach IPv4-only servers). Designers of
|
||
SMTP implementations that might run in IPv6 or dual-stack
|
||
environments should study the procedures above, especially the
|
||
comments about multihomed hosts, and, preferably, provide mechanisms
|
||
to facilitate operational tuning and mail interoperability between
|
||
IPv4 and IPv6 systems while considering local circumstances.
|
||
|
||
6. Problem Detection and Handling
|
||
|
||
6.1. Reliable Delivery and Replies by Email
|
||
|
||
When the receiver-SMTP accepts a piece of mail (by sending a "250 OK"
|
||
message in response to DATA), it is accepting responsibility for
|
||
delivering or relaying the message. It must take this responsibility
|
||
seriously. It MUST NOT lose the message for frivolous reasons, such
|
||
as because the host later crashes or because of a predictable
|
||
resource shortage. Some reasons that are not considered frivolous
|
||
are discussed in the next subsection and in Section 7.8.
|
||
|
||
If there is a delivery failure after acceptance of a message, the
|
||
receiver-SMTP MUST formulate and mail a notification message. This
|
||
notification MUST be sent using a null ("<>") reverse-path in the
|
||
envelope. The recipient of this notification MUST be the address
|
||
from the envelope return path (or the Return-Path: line). However,
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 71]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
if this address is null ("<>"), the receiver-SMTP MUST NOT send a
|
||
notification. Obviously, nothing in this section can or should
|
||
prohibit local decisions (i.e., as part of the same system
|
||
environment as the receiver-SMTP) to log or otherwise transmit
|
||
information about null address events locally if that is desired. If
|
||
the address is an explicit source route, it MUST be stripped down to
|
||
its final hop.
|
||
|
||
For example, suppose that an error notification must be sent for a
|
||
message that arrived with:
|
||
|
||
MAIL FROM:<@a,@b:user@d>
|
||
|
||
The notification message MUST be sent using:
|
||
|
||
RCPT TO:<user@d>
|
||
|
||
Some delivery failures after the message is accepted by SMTP will be
|
||
unavoidable. For example, it may be impossible for the receiving
|
||
SMTP server to validate all the delivery addresses in RCPT command(s)
|
||
due to a "soft" domain system error, because the target is a mailing
|
||
list (see earlier discussion of RCPT), or because the server is
|
||
acting as a relay and has no immediate access to the delivering
|
||
system.
|
||
|
||
To avoid receiving duplicate messages as the result of timeouts, a
|
||
receiver-SMTP MUST seek to minimize the time required to respond to
|
||
the final <CRLF>.<CRLF> end of data indicator. See RFC 1047 [40] for
|
||
a discussion of this problem.
|
||
|
||
6.2. Unwanted, Unsolicited, and "Attack" Messages
|
||
|
||
Utility and predictability of the Internet mail system requires that
|
||
messages that can be delivered should be delivered, regardless of any
|
||
syntax or other faults associated with those messages and regardless
|
||
of their content. If they cannot be delivered, and cannot be
|
||
rejected by the SMTP server during the SMTP transaction, they should
|
||
be "bounced" (returned with non-delivery notification messages) as
|
||
described above. In today's world, in which many SMTP server
|
||
operators have discovered that the quantity of undesirable bulk email
|
||
vastly exceeds the quantity of desired mail and in which accepting a
|
||
message may trigger additional undesirable traffic by providing
|
||
verification of the address, those principles may not be practical.
|
||
|
||
As discussed in Section 7.8 and Section 7.9 below, dropping mail
|
||
without notification of the sender is permitted in practice.
|
||
However, it is extremely dangerous and violates a long tradition and
|
||
community expectations that mail is either delivered or returned. If
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 72]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
silent message-dropping is misused, it could easily undermine
|
||
confidence in the reliability of the Internet's mail systems. So
|
||
silent dropping of messages should be considered only in those cases
|
||
where there is very high confidence that the messages are seriously
|
||
fraudulent or otherwise inappropriate.
|
||
|
||
To stretch the principle of delivery if possible even further, it may
|
||
be a rational policy to not deliver mail that has an invalid return
|
||
address, although the history of the network is that users are
|
||
typically better served by delivering any message that can be
|
||
delivered. Reliably determining that a return address is invalid can
|
||
be a difficult and time-consuming process, especially if the putative
|
||
sending system is not directly accessible or does not fully and
|
||
accurately support VRFY and, even if a "drop messages with invalid
|
||
return addresses" policy is adopted, it SHOULD be applied only when
|
||
there is near-certainty that the return addresses are, in fact,
|
||
invalid.
|
||
|
||
Conversely, if a message is rejected because it is found to contain
|
||
hostile content (a decision that is outside the scope of an SMTP
|
||
server as defined in this document), rejection ("bounce") messages
|
||
SHOULD NOT be sent unless the receiving site is confident that those
|
||
messages will be usefully delivered. The preference and default in
|
||
these cases is to avoid sending non-delivery messages when the
|
||
incoming message is determined to contain hostile content.
|
||
|
||
6.3. Loop Detection
|
||
|
||
Simple counting of the number of "Received:" header fields in a
|
||
message has proven to be an effective, although rarely optimal,
|
||
method of detecting loops in mail systems. SMTP servers using this
|
||
technique SHOULD use a large rejection threshold, normally at least
|
||
100 Received entries. Whatever mechanisms are used, servers MUST
|
||
contain provisions for detecting and stopping trivial loops.
|
||
|
||
6.4. Compensating for Irregularities
|
||
|
||
Unfortunately, variations, creative interpretations, and outright
|
||
violations of Internet mail protocols do occur; some would suggest
|
||
that they occur quite frequently. The debate as to whether a well-
|
||
behaved SMTP receiver or relay should reject a malformed message,
|
||
attempt to pass it on unchanged, or attempt to repair it to increase
|
||
the odds of successful delivery (or subsequent reply) began almost
|
||
with the dawn of structured network mail and shows no signs of
|
||
abating. Advocates of rejection claim that attempted repairs are
|
||
rarely completely adequate and that rejection of bad messages is the
|
||
only way to get the offending software repaired. Advocates of
|
||
"repair" or "deliver no matter what" argue that users prefer that
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 73]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
mail go through it if at all possible and that there are significant
|
||
market pressures in that direction. In practice, these market
|
||
pressures may be more important to particular vendors than strict
|
||
conformance to the standards, regardless of the preference of the
|
||
actual developers.
|
||
|
||
The problems associated with ill-formed messages were exacerbated by
|
||
the introduction of the split-UA mail reading protocols (Post Office
|
||
Protocol (POP) version 2 [15], Post Office Protocol (POP) version 3
|
||
[16], IMAP version 2 [41], and PCMAIL [42]). These protocols
|
||
encouraged the use of SMTP as a posting (message submission)
|
||
protocol, and SMTP servers as relay systems for these client hosts
|
||
(which are often only intermittently connected to the Internet).
|
||
Historically, many of those client machines lacked some of the
|
||
mechanisms and information assumed by SMTP (and indeed, by the mail
|
||
format protocol, RFC 822 [28]). Some could not keep adequate track
|
||
of time; others had no concept of time zones; still others could not
|
||
identify their own names or addresses; and, of course, none could
|
||
satisfy the assumptions that underlay RFC 822's conception of
|
||
authenticated addresses.
|
||
|
||
In response to these weak SMTP clients, many SMTP systems now
|
||
complete messages that are delivered to them in incomplete or
|
||
incorrect form. This strategy is generally considered appropriate
|
||
when the server can identify or authenticate the client, and there
|
||
are prior agreements between them. By contrast, there is at best
|
||
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
|
||
of these issues are addressed by using a separate protocol, such as
|
||
that defined in RFC 4409 [18], for message submission, rather than
|
||
using originating SMTP servers for that purpose.
|
||
|
||
The following changes to a message being processed MAY be applied
|
||
when necessary by an originating SMTP server, or one used as the
|
||
target of SMTP as an initial posting (message submission) protocol:
|
||
|
||
o Addition of a message-id field when none appears
|
||
|
||
o Addition of a date, time, or time zone when none appears
|
||
|
||
o Correction of addresses to proper FQDN format
|
||
|
||
The less information the server has about the client, the less likely
|
||
these changes are to be correct and the more caution and conservatism
|
||
should be applied when considering whether or not to perform fixes
|
||
and how. These changes MUST NOT be applied by an SMTP server that
|
||
provides an intermediate relay function.
|
||
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 74]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
In all cases, properly operating clients supplying correct
|
||
information are preferred to corrections by the SMTP server. In all
|
||
cases, documentation SHOULD be provided in trace header fields and/or
|
||
header field comments for actions performed by the servers.
|
||
|
||
7. Security Considerations
|
||
|
||
7.1. Mail Security and Spoofing
|
||
|
||
SMTP mail is inherently insecure in that it is feasible for even
|
||
fairly casual users to negotiate directly with receiving and relaying
|
||
SMTP servers and create messages that will trick a naive recipient
|
||
into believing that they came from somewhere else. Constructing such
|
||
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
|
||
deterrent to someone who is determined and knowledgeable.
|
||
Consequently, as knowledge of Internet mail increases, so does the
|
||
knowledge that SMTP mail inherently cannot be authenticated, or
|
||
integrity checks provided, at the transport level. Real mail
|
||
security lies only in end-to-end methods involving the message
|
||
bodies, such as those that use digital signatures (see RFC 1847 [43]
|
||
and, e.g., Pretty Good Privacy (PGP) in RFC 4880 [44] or Secure/
|
||
Multipurpose Internet Mail Extensions (S/MIME) in RFC 3851 [45]).
|
||
|
||
Various protocol extensions and configuration options that provide
|
||
authentication at the transport level (e.g., from an SMTP client to
|
||
an SMTP server) improve somewhat on the traditional situation
|
||
described above. However, in general, they only authenticate one
|
||
server to another rather than a chain of relays and servers, much
|
||
less authenticating users or user machines. Consequently, unless
|
||
they are accompanied by careful handoffs of responsibility in a
|
||
carefully designed trust environment, they remain inherently weaker
|
||
than end-to-end mechanisms that use digitally signed messages rather
|
||
than depending on the integrity of the transport system.
|
||
|
||
Efforts to make it more difficult for users to set envelope return
|
||
path and header "From" fields to point to valid addresses other than
|
||
their own are largely misguided: they frustrate legitimate
|
||
applications in which mail is sent by one user on behalf of another,
|
||
in which error (or normal) replies should be directed to a special
|
||
address, or in which a single message is sent to multiple recipients
|
||
on different hosts. (Systems that provide convenient ways for users
|
||
to alter these header fields on a per-message basis should attempt to
|
||
establish a primary and permanent mailbox address for the user so
|
||
that Sender header fields within the message data can be generated
|
||
sensibly.)
|
||
|
||
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 75]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
This specification does not further address the authentication issues
|
||
associated with SMTP other than to advocate that useful functionality
|
||
not be disabled in the hope of providing some small margin of
|
||
protection against a user who is trying to fake mail.
|
||
|
||
7.2. "Blind" Copies
|
||
|
||
Addresses that do not appear in the message header section may appear
|
||
in the RCPT commands to an SMTP server for a number of reasons. The
|
||
two most common involve the use of a mailing address as a "list
|
||
exploder" (a single address that resolves into multiple addresses)
|
||
and the appearance of "blind copies". Especially when more than one
|
||
RCPT command is present, and in order to avoid defeating some of the
|
||
purpose of these mechanisms, SMTP clients and servers SHOULD NOT copy
|
||
the full set of RCPT command arguments into the header section,
|
||
either as part of trace header fields or as informational or private-
|
||
extension header fields. Since this rule is often violated in
|
||
practice, and cannot be enforced, sending SMTP systems that are aware
|
||
of "bcc" use MAY find it helpful to send each blind copy as a
|
||
separate message transaction containing only a single RCPT command.
|
||
|
||
There is no inherent relationship between either "reverse" (from
|
||
MAIL, SAML, etc., commands) or "forward" (RCPT) addresses in the SMTP
|
||
transaction ("envelope") and the addresses in the header section.
|
||
Receiving systems SHOULD NOT attempt to deduce such relationships and
|
||
use them to alter the header section of the message for delivery.
|
||
The popular "Apparently-to" header field is a violation of this
|
||
principle as well as a common source of unintended information
|
||
disclosure and SHOULD NOT be used.
|
||
|
||
7.3. VRFY, EXPN, and Security
|
||
|
||
As discussed in Section 3.5, individual sites may want to disable
|
||
either or both of VRFY or EXPN for security reasons (see below). As
|
||
a corollary to the above, implementations that permit this MUST NOT
|
||
appear to have verified addresses that are not, in fact, verified.
|
||
If a site disables these commands for security reasons, the SMTP
|
||
server MUST return a 252 response, rather than a code that could be
|
||
confused with successful or unsuccessful verification.
|
||
|
||
Returning a 250 reply code with the address listed in the VRFY
|
||
command after having checked it only for syntax violates this rule.
|
||
Of course, an implementation that "supports" VRFY by always returning
|
||
550 whether or not the address is valid is equally not in
|
||
conformance.
|
||
|
||
On the public Internet, the contents of mailing lists have become
|
||
popular as an address information source for so-called "spammers."
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 76]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
The use of EXPN to "harvest" addresses has increased as list
|
||
administrators have installed protections against inappropriate uses
|
||
of the lists themselves. However, VRFY and EXPN are still useful for
|
||
authenticated users and within an administrative domain. For
|
||
example, VRFY and EXPN are useful for performing internal audits of
|
||
how email gets routed to check and to make sure no one is
|
||
automatically forwarding sensitive mail outside the organization.
|
||
Sites implementing SMTP authentication may choose to make VRFY and
|
||
EXPN available only to authenticated requestors. Implementations
|
||
SHOULD still provide support for EXPN, but sites SHOULD carefully
|
||
evaluate the tradeoffs.
|
||
|
||
Whether disabling VRFY provides any real marginal security depends on
|
||
a series of other conditions. In many cases, RCPT commands can be
|
||
used to obtain the same information about address validity. On the
|
||
other hand, especially in situations where determination of address
|
||
validity for RCPT commands is deferred until after the DATA command
|
||
is received, RCPT may return no information at all, while VRFY is
|
||
expected to make a serious attempt to determine validity before
|
||
generating a response code (see discussion above).
|
||
|
||
7.4. Mail Rerouting Based on the 251 and 551 Response Codes
|
||
|
||
Before a client uses the 251 or 551 reply codes from a RCPT command
|
||
to automatically update its future behavior (e.g., updating the
|
||
user's address book), it should be certain of the server's
|
||
authenticity. If it does not, it may be subject to a man in the
|
||
middle attack.
|
||
|
||
7.5. Information Disclosure in Announcements
|
||
|
||
There has been an ongoing debate about the tradeoffs between the
|
||
debugging advantages of announcing server type and version (and,
|
||
sometimes, even server domain name) in the greeting response or in
|
||
response to the HELP command and the disadvantages of exposing
|
||
information that might be useful in a potential hostile attack. The
|
||
utility of the debugging information is beyond doubt. Those who
|
||
argue for making it available point out that it is far better to
|
||
actually secure an SMTP server rather than hope that trying to
|
||
conceal known vulnerabilities by hiding the server's precise identity
|
||
will provide more protection. Sites are encouraged to evaluate the
|
||
tradeoff with that issue in mind; implementations SHOULD minimally
|
||
provide for making type and version information available in some way
|
||
to other network hosts.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 77]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
7.6. Information Disclosure in Trace Fields
|
||
|
||
In some circumstances, such as when mail originates from within a LAN
|
||
whose hosts are not directly on the public Internet, trace
|
||
("Received") header fields produced in conformance with this
|
||
specification may disclose host names and similar information that
|
||
would not normally be available. This ordinarily does not pose a
|
||
problem, but sites with special concerns about name disclosure should
|
||
be aware of it. Also, the optional FOR clause should be supplied
|
||
with caution or not at all when multiple recipients are involved lest
|
||
it inadvertently disclose the identities of "blind copy" recipients
|
||
to others.
|
||
|
||
7.7. Information Disclosure in Message Forwarding
|
||
|
||
As discussed in Section 3.4, use of the 251 or 551 reply codes to
|
||
identify the replacement address associated with a mailbox may
|
||
inadvertently disclose sensitive information. Sites that are
|
||
concerned about those issues should ensure that they select and
|
||
configure servers appropriately.
|
||
|
||
7.8. Resistance to Attacks
|
||
|
||
In recent years, there has been an increase of attacks on SMTP
|
||
servers, either in conjunction with attempts to discover addresses
|
||
for sending unsolicited messages or simply to make the servers
|
||
inaccessible to others (i.e., as an application-level denial of
|
||
service attack). While the means of doing so are beyond the scope of
|
||
this Standard, rational operational behavior requires that servers be
|
||
permitted to detect such attacks and take action to defend
|
||
themselves. For example, if a server determines that a large number
|
||
of RCPT TO commands are being sent, most or all with invalid
|
||
addresses, as part of such an attack, it would be reasonable for the
|
||
server to close the connection after generating an appropriate number
|
||
of 5yz (normally 550) replies.
|
||
|
||
7.9. Scope of Operation of SMTP Servers
|
||
|
||
It is a well-established principle that an SMTP server may refuse to
|
||
accept mail for any operational or technical reason that makes sense
|
||
to the site providing the server. However, cooperation among sites
|
||
and installations makes the Internet possible. If sites take
|
||
excessive advantage of the right to reject traffic, the ubiquity of
|
||
email availability (one of the strengths of the Internet) will be
|
||
threatened; considerable care should be taken and balance maintained
|
||
if a site decides to be selective about the traffic it will accept
|
||
and process.
|
||
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 78]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
In recent years, use of the relay function through arbitrary sites
|
||
has been used as part of hostile efforts to hide the actual origins
|
||
of mail. Some sites have decided to limit the use of the relay
|
||
function to known or identifiable sources, and implementations SHOULD
|
||
provide the capability to perform this type of filtering. When mail
|
||
is rejected for these or other policy reasons, a 550 code SHOULD be
|
||
used in response to EHLO (or HELO), MAIL, or RCPT as appropriate.
|
||
|
||
8. IANA Considerations
|
||
|
||
IANA maintains three registries in support of this specification, all
|
||
of which were created for RFC 2821 or earlier. This document expands
|
||
the third one as specified below. The registry references listed are
|
||
as of the time of publication; IANA does not guarantee the locations
|
||
associated with the URLs. The registries are as follows:
|
||
|
||
o The first, "Simple Mail Transfer Protocol (SMTP) Service
|
||
Extensions" [46], consists of SMTP service extensions with the
|
||
associated keywords, and, as needed, parameters and verbs. As
|
||
specified in Section 2.2.2, no entry may be made in this registry
|
||
that starts in an "X". Entries may be made only for service
|
||
extensions (and associated keywords, parameters, or verbs) that
|
||
are defined in Standards-Track or Experimental RFCs specifically
|
||
approved by the IESG for this purpose.
|
||
|
||
o The second registry, "Address Literal Tags" [47], consists of
|
||
"tags" that identify forms of domain literals other than those for
|
||
IPv4 addresses (specified in RFC 821 and in this document). The
|
||
initial entry in that registry is for IPv6 addresses (specified in
|
||
this document). Additional literal types require standardization
|
||
before being used; none are anticipated at this time.
|
||
|
||
o The third, "Mail Transmission Types" [46], established by RFC 821
|
||
and renewed by this specification, is a registry of link and
|
||
protocol identifiers to be used with the "via" and "with"
|
||
subclauses of the time stamp ("Received:" header field) described
|
||
in Section 4.4. Link and protocol identifiers in addition to
|
||
those specified in this document may be registered only by
|
||
standardization or by way of an RFC-documented, IESG-approved,
|
||
Experimental protocol extension. This name space is for
|
||
identification and not limited in size: the IESG is encouraged to
|
||
approve on the basis of clear documentation and a distinct method
|
||
rather than preferences about the properties of the method itself.
|
||
|
||
An additional subsection has been added to the "VIA link types"
|
||
and "WITH protocol types" subsections of this registry to contain
|
||
registrations of "Additional-registered-clauses" as described
|
||
above. The registry will contain clause names, a description, a
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 79]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
summary of the syntax of the associated String, and a reference.
|
||
As new clauses are defined, they may, in principle, specify
|
||
creation of their own registries if the Strings consist of
|
||
reserved terms or keywords rather than less restricted strings.
|
||
As with link and protocol identifiers, additional clauses may be
|
||
registered only by standardization or by way of an RFC-documented,
|
||
IESG-approved, Experimental protocol extension. The additional
|
||
clause name space is for identification and is not limited in
|
||
size: the IESG is encouraged to approve on the basis of clear
|
||
documentation, actual use or strong signs that the clause will be
|
||
used, and a distinct requirement rather than preferences about the
|
||
properties of the clause itself.
|
||
|
||
In addition, if additional trace header fields (i.e., in addition to
|
||
Return-path and Received) are ever created, those trace fields MUST
|
||
be added to the IANA registry established by BCP 90 (RFC 3864) [11]
|
||
for use with RFC 5322 [4].
|
||
|
||
9. Acknowledgments
|
||
|
||
Many people contributed to the development of RFC 2821. That
|
||
document should be consulted for those acknowledgments. For the
|
||
present document, the editor and the community owe thanks to Dawn
|
||
Mann and Tony Hansen who assisted in the very painful process of
|
||
editing and converting the internal format of the document from one
|
||
system to another.
|
||
|
||
Neither this document nor RFC 2821 would have been possible without
|
||
the many contribution and insights of the late Jon Postel. Those
|
||
contributions of course include the original specification of SMTP in
|
||
RFC 821. A considerable quantity of text from RFC 821 still appears
|
||
in this document as do several of Jon's original examples that have
|
||
been updated only as needed to reflect other changes in the
|
||
specification.
|
||
|
||
Many people made comments or suggestions on the mailing list or in
|
||
notes to the author. Important corrections or clarifications were
|
||
suggested by several people, including Matti Aarnio, Glenn Anderson,
|
||
Derek J. Balling, Alex van den Bogaerdt, Stephane Bortzmeyer, Vint
|
||
Cerf, Jutta Degener, Steve Dorner, Lisa Dusseault, Frank Ellerman,
|
||
Ned Freed, Randy Gellens, Sabahattin Gucukoglu, Philip Guenther, Arnt
|
||
Gulbrandsen, Eric Hall, Richard O. Hammer, Tony Hansen, Peter J.
|
||
Holzer, Kari Hurtta, Bryon Roche Kain, Valdis Kletnieks, Mathias
|
||
Koerber, John Leslie, Bruce Lilly, Jeff Macdonald, Mark E. Mallett,
|
||
Mark Martinec, S. Moonesamy, Lyndon Nerenberg, Chris Newman, Douglas
|
||
Otis, Pete Resnick, Robert A. Rosenberg, Vince Sabio, Hector Santos,
|
||
David F. Skoll, Paul Smith, and Brett Watson.
|
||
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 80]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
The efforts of the Area Directors -- Lisa Dusseault, Ted Hardie, and
|
||
Chris Newman -- to get this effort restarted and keep it moving, and
|
||
of an ad hoc committee with the same purpose, are gratefully
|
||
acknowledged. The members of that committee were (in alphabetical
|
||
order) Dave Crocker, Cyrus Daboo, Tony Finch, Ned Freed, Randall
|
||
Gellens, Tony Hansen, the author, and Alexey Melnikov. Tony Hansen
|
||
also acted as ad hoc chair on the mailing list reviewing this
|
||
document; without his efforts, sense of balance and fairness, and
|
||
patience, it clearly would not have been possible.
|
||
|
||
10. References
|
||
|
||
10.1. Normative References
|
||
|
||
[1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
|
||
August 1982.
|
||
|
||
[2] Mockapetris, P., "Domain names - implementation and
|
||
specification", STD 13, RFC 1035, November 1987.
|
||
|
||
[3] Braden, R., "Requirements for Internet Hosts - Application and
|
||
Support", STD 3, RFC 1123, October 1989.
|
||
|
||
[4] Resnick, P., "Internet Message Format", RFC 5322, October 2008.
|
||
|
||
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
|
||
Levels", BCP 14, RFC 2119, March 1997.
|
||
|
||
[6] American National Standards Institute (formerly United States
|
||
of America Standards Institute), "USA Code for Information
|
||
Interchange", ANSI X3.4-1968, 1968.
|
||
|
||
ANSI X3.4-1968 has been replaced by newer versions with slight
|
||
modifications, but the 1968 version remains definitive for the
|
||
Internet.
|
||
|
||
[7] Crocker, D. and P. Overell, "Augmented BNF for Syntax
|
||
Specifications: ABNF", STD 68, RFC 5234, January 2008.
|
||
|
||
[8] Hinden, R. and S. Deering, "IP Version 6 Addressing
|
||
Architecture", RFC 4291, February 2006.
|
||
|
||
[9] Newman, C., "ESMTP and LMTP Transmission Types Registration",
|
||
RFC 3848, July 2004.
|
||
|
||
[10] Klensin, J., Freed, N., and K. Moore, "SMTP Service Extension
|
||
for Message Size Declaration", STD 10, RFC 1870, November 1995.
|
||
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 81]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
[11] Klyne, G., Nottingham, M., and J. Mogul, "Registration
|
||
Procedures for Message Header Fields", BCP 90, RFC 3864,
|
||
September 2004.
|
||
|
||
10.2. Informative References
|
||
|
||
[12] Partridge, C., "Mail routing and the domain system", RFC 974,
|
||
January 1986.
|
||
|
||
[13] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D.
|
||
Crocker, "SMTP Service Extensions", STD 10, RFC 1869,
|
||
November 1995.
|
||
|
||
[14] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
|
||
April 2001.
|
||
|
||
[15] Butler, M., Postel, J., Chase, D., Goldberger, J., and J.
|
||
Reynolds, "Post Office Protocol: Version 2", RFC 937,
|
||
February 1985.
|
||
|
||
[16] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
|
||
STD 53, RFC 1939, May 1996.
|
||
|
||
[17] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
|
||
4rev1", RFC 3501, March 2003.
|
||
|
||
[18] Gellens, R. and J. Klensin, "Message Submission for Mail",
|
||
RFC 4409, April 2006.
|
||
|
||
[19] Freed, N., "SMTP Service Extension for Command Pipelining",
|
||
STD 60, RFC 2920, September 2000.
|
||
|
||
[20] Vaudreuil, G., "SMTP Service Extensions for Transmission of
|
||
Large and Binary MIME Messages", RFC 3030, December 2000.
|
||
|
||
[21] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
|
||
Extensions (MIME) Part One: Format of Internet Message Bodies",
|
||
RFC 2045, November 1996.
|
||
|
||
[22] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D.
|
||
Crocker, "SMTP Service Extension for 8bit-MIMEtransport",
|
||
RFC 1652, July 1994.
|
||
|
||
[23] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part
|
||
Three: Message Header Extensions for Non-ASCII Text", RFC 2047,
|
||
November 1996.
|
||
|
||
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 82]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
[24] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word
|
||
Extensions: Character Sets, Languages, and Continuations",
|
||
RFC 2231, November 1997.
|
||
|
||
[25] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463,
|
||
January 2003.
|
||
|
||
[26] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced Mail
|
||
System Status Codes", BCP 138, RFC 5248, June 2008.
|
||
|
||
[27] Freed, N., "Behavior of and Requirements for Internet
|
||
Firewalls", RFC 2979, October 2000.
|
||
|
||
[28] Crocker, D., "Standard for the format of ARPA Internet text
|
||
messages", STD 11, RFC 822, August 1982.
|
||
|
||
[29] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) for
|
||
Authorizing Use of Domains in E-Mail, Version 1", RFC 4408,
|
||
April 2006.
|
||
|
||
[30] Fenton, J., "Analysis of Threats Motivating DomainKeys
|
||
Identified Mail (DKIM)", RFC 4686, September 2006.
|
||
|
||
[31] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and
|
||
M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures",
|
||
RFC 4871, May 2007.
|
||
|
||
[32] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
|
||
Extension for Delivery Status Notifications (DSNs)", RFC 3461,
|
||
January 2003.
|
||
|
||
[33] Moore, K. and G. Vaudreuil, "An Extensible Message Format for
|
||
Delivery Status Notifications", RFC 3464, January 2003.
|
||
|
||
[34] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9,
|
||
RFC 959, October 1985.
|
||
|
||
[35] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping
|
||
between X.400 and RFC 822/MIME", RFC 2156, January 1998.
|
||
|
||
[36] De Winter, J., "SMTP Service Extension for Remote Message Queue
|
||
Starting", RFC 1985, August 1996.
|
||
|
||
[37] Hansen, T. and G. Vaudreuil, "Message Disposition
|
||
Notification", RFC 3798, May 2004.
|
||
|
||
[38] Elz, R. and R. Bush, "Clarifications to the DNS Specification",
|
||
RFC 2181, July 1997.
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 83]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
[39] Nakamura, M. and J. Hagino, "SMTP Operational Experience in
|
||
Mixed IPv4/v6 Environments", RFC 3974, January 2005.
|
||
|
||
[40] Partridge, C., "Duplicate messages and SMTP", RFC 1047,
|
||
February 1988.
|
||
|
||
[41] Crispin, M., "Interactive Mail Access Protocol: Version 2",
|
||
RFC 1176, August 1990.
|
||
|
||
[42] Lambert, M., "PCMAIL: A distributed mail system for personal
|
||
computers", RFC 1056, June 1988.
|
||
|
||
[43] Galvin, J., Murphy, S., Crocker, S., and N. Freed, "Security
|
||
Multiparts for MIME: Multipart/Signed and Multipart/Encrypted",
|
||
RFC 1847, October 1995.
|
||
|
||
[44] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
|
||
Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
|
||
|
||
[45] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
|
||
(S/MIME) Version 3.1 Message Specification", RFC 3851,
|
||
July 2004.
|
||
|
||
[46] Internet Assigned Number Authority (IANA), "IANA Mail
|
||
Parameters", 2007,
|
||
<http://www.iana.org/assignments/mail-parameters>.
|
||
|
||
[47] Internet Assigned Number Authority (IANA), "Address Literal
|
||
Tags", 2007,
|
||
<http://www.iana.org/assignments/address-literal-tags>.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 84]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
Appendix A. TCP Transport Service
|
||
|
||
The TCP connection supports the transmission of 8-bit bytes. The
|
||
SMTP data is 7-bit ASCII characters. Each character is transmitted
|
||
as an 8-bit byte with the high-order bit cleared to zero. Service
|
||
extensions may modify this rule to permit transmission of full 8-bit
|
||
data bytes as part of the message body, or, if specifically designed
|
||
to do so, in SMTP commands or responses.
|
||
|
||
Appendix B. Generating SMTP Commands from RFC 822 Header Fields
|
||
|
||
Some systems use an RFC 822 header section (only) in a mail
|
||
submission protocol, or otherwise generate SMTP commands from RFC 822
|
||
header fields when such a message is handed to an MTA from a UA.
|
||
While the MTA-UA protocol is a private matter, not covered by any
|
||
Internet Standard, there are problems with this approach. For
|
||
example, there have been repeated problems with proper handling of
|
||
"bcc" copies and redistribution lists when information that
|
||
conceptually belongs to the mail envelope is not separated early in
|
||
processing from header field information (and kept separate).
|
||
|
||
It is recommended that the UA provide its initial ("submission
|
||
client") MTA with an envelope separate from the message itself.
|
||
However, if the envelope is not supplied, SMTP commands SHOULD be
|
||
generated as follows:
|
||
|
||
1. Each recipient address from a TO, CC, or BCC header field SHOULD
|
||
be copied to a RCPT command (generating multiple message copies
|
||
if that is required for queuing or delivery). This includes any
|
||
addresses listed in a RFC 822 "group". Any BCC header fields
|
||
SHOULD then be removed from the header section. Once this
|
||
process is completed, the remaining header fields SHOULD be
|
||
checked to verify that at least one TO, CC, or BCC header field
|
||
remains. If none do, then a BCC header field with no additional
|
||
information SHOULD be inserted as specified in [4].
|
||
|
||
2. The return address in the MAIL command SHOULD, if possible, be
|
||
derived from the system's identity for the submitting (local)
|
||
user, and the "From:" header field otherwise. If there is a
|
||
system identity available, it SHOULD also be copied to the Sender
|
||
header field if it is different from the address in the From
|
||
header field. (Any Sender header field that was already there
|
||
SHOULD be removed.) Systems may provide a way for submitters to
|
||
override the envelope return address, but may want to restrict
|
||
its use to privileged users. This will not prevent mail forgery,
|
||
but may lessen its incidence; see Section 7.1.
|
||
|
||
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 85]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
When an MTA is being used in this way, it bears responsibility for
|
||
ensuring that the message being transmitted is valid. The mechanisms
|
||
for checking that validity, and for handling (or returning) messages
|
||
that are not valid at the time of arrival, are part of the MUA-MTA
|
||
interface and not covered by this specification.
|
||
|
||
A submission protocol based on Standard RFC 822 information alone
|
||
MUST NOT be used to gateway a message from a foreign (non-SMTP) mail
|
||
system into an SMTP environment. Additional information to construct
|
||
an envelope must come from some source in the other environment,
|
||
whether supplemental header fields or the foreign system's envelope.
|
||
|
||
Attempts to gateway messages using only their header "To" and "Cc"
|
||
fields have repeatedly caused mail loops and other behavior adverse
|
||
to the proper functioning of the Internet mail environment. These
|
||
problems have been especially common when the message originates from
|
||
an Internet mailing list and is distributed into the foreign
|
||
environment using envelope information. When these messages are then
|
||
processed by a header-section-only remailer, loops back to the
|
||
Internet environment (and the mailing list) are almost inevitable.
|
||
|
||
Appendix C. Source Routes
|
||
|
||
Historically, the <reverse-path> was a reverse source routing list of
|
||
hosts and a source mailbox. The first host in the <reverse-path> was
|
||
historically the host sending the MAIL command; today, source routes
|
||
SHOULD NOT appear in the reverse-path. Similarly, the <forward-path>
|
||
may be a source routing lists of hosts and a destination mailbox.
|
||
However, in general, the <forward-path> SHOULD contain only a mailbox
|
||
and domain name, relying on the domain name system to supply routing
|
||
information if required. The use of source routes is deprecated (see
|
||
Appendix F.2); while servers MUST be prepared to receive and handle
|
||
them as discussed in Section 3.3 and Appendix F.2, clients SHOULD NOT
|
||
transmit them and this section is included in the current
|
||
specification only to provide context. It has been modified somewhat
|
||
from the material in RFC 821 to prevent server actions that might
|
||
confuse clients or subsequent servers that do not expect a full
|
||
source route implementation.
|
||
|
||
For relay purposes, the forward-path may be a source route of the
|
||
form "@ONE,@TWO:JOE@THREE", where ONE, TWO, and THREE MUST be fully-
|
||
qualified domain names. This form is used to emphasize the
|
||
distinction between an address and a route. The mailbox (here, JOE@
|
||
THREE) is an absolute address, and the route is information about how
|
||
to get there. The two concepts should not be confused.
|
||
|
||
If source routes are used, RFC 821 and the text below should be
|
||
consulted for the mechanisms for constructing and updating the
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 86]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
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. The reverse-path SHOULD NOT be
|
||
updated by servers conforming to this specification.
|
||
|
||
Notice that the forward-path and reverse-path appear in the SMTP
|
||
commands and replies, but not necessarily in the message. That is,
|
||
there is no need for these paths and especially this syntax to appear
|
||
in the "To:" , "From:", "CC:", etc. fields of the message header
|
||
section. Conversely, SMTP servers MUST NOT derive final message
|
||
routing information from message header fields.
|
||
|
||
When the list of hosts is present despite the recommendations above,
|
||
it is a "reverse" source route and indicates that the mail was
|
||
relayed through each host on the list (the first host in the list was
|
||
the most recent relay). This list is used as a source route to
|
||
return non-delivery notices to the sender. If, contrary to the
|
||
recommendations here, a relay host adds itself to the beginning of
|
||
the list, it MUST use its name as known in the transport environment
|
||
to which it is relaying the mail rather than that of the transport
|
||
environment from which the mail came (if they are different). Note
|
||
that a situation could easily arise in which some relay hosts add
|
||
their names to the reverse source route and others do not, generating
|
||
discontinuities in the routing list. This is another reason why
|
||
servers needing to return a message SHOULD ignore the source route
|
||
entirely and simply use the domain as specified in the Mailbox.
|
||
|
||
Appendix D. Scenarios
|
||
|
||
This section presents complete scenarios of several types of SMTP
|
||
sessions. In the examples, "C:" indicates what is said by the SMTP
|
||
client, and "S:" indicates what is said by the SMTP server.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 87]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
D.1. A Typical SMTP Transaction Scenario
|
||
|
||
This SMTP example shows mail sent by Smith at host bar.com, and to
|
||
Jones, Green, and Brown at host foo.com. Here we assume that host
|
||
bar.com contacts host foo.com directly. The mail is accepted for
|
||
Jones and Brown. Green does not have a mailbox at host foo.com.
|
||
|
||
S: 220 foo.com Simple Mail Transfer Service Ready
|
||
C: EHLO bar.com
|
||
S: 250-foo.com greets bar.com
|
||
S: 250-8BITMIME
|
||
S: 250-SIZE
|
||
S: 250-DSN
|
||
S: 250 HELP
|
||
C: MAIL FROM:<Smith@bar.com>
|
||
S: 250 OK
|
||
C: RCPT TO:<Jones@foo.com>
|
||
S: 250 OK
|
||
C: RCPT TO:<Green@foo.com>
|
||
S: 550 No such user here
|
||
C: RCPT TO:<Brown@foo.com>
|
||
S: 250 OK
|
||
C: DATA
|
||
S: 354 Start mail input; end with <CRLF>.<CRLF>
|
||
C: Blah blah blah...
|
||
C: ...etc. etc. etc.
|
||
C: .
|
||
S: 250 OK
|
||
C: QUIT
|
||
S: 221 foo.com Service closing transmission channel
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 88]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
D.2. Aborted SMTP Transaction Scenario
|
||
|
||
S: 220 foo.com Simple Mail Transfer Service Ready
|
||
C: EHLO bar.com
|
||
S: 250-foo.com greets bar.com
|
||
S: 250-8BITMIME
|
||
S: 250-SIZE
|
||
S: 250-DSN
|
||
S: 250 HELP
|
||
C: MAIL FROM:<Smith@bar.com>
|
||
S: 250 OK
|
||
C: RCPT TO:<Jones@foo.com>
|
||
S: 250 OK
|
||
C: RCPT TO:<Green@foo.com>
|
||
S: 550 No such user here
|
||
C: RSET
|
||
S: 250 OK
|
||
C: QUIT
|
||
S: 221 foo.com Service closing transmission channel
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 89]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
D.3. Relayed Mail Scenario
|
||
|
||
Step 1 -- Source Host to Relay Host
|
||
|
||
The source host performs a DNS lookup on XYZ.COM (the destination
|
||
address) and finds DNS MX records specifying xyz.com as the best
|
||
preference and foo.com as a lower preference. It attempts to open a
|
||
connection to xyz.com and fails. It then opens a connection to
|
||
foo.com, with the following dialogue:
|
||
|
||
S: 220 foo.com Simple Mail Transfer Service Ready
|
||
C: EHLO bar.com
|
||
S: 250-foo.com greets bar.com
|
||
S: 250-8BITMIME
|
||
S: 250-SIZE
|
||
S: 250-DSN
|
||
S: 250 HELP
|
||
C: MAIL FROM:<JQP@bar.com>
|
||
S: 250 OK
|
||
C: RCPT TO:<Jones@XYZ.COM>
|
||
S: 250 OK
|
||
C: DATA
|
||
S: 354 Start mail input; end with <CRLF>.<CRLF>
|
||
C: Date: Thu, 21 May 1998 05:33:29 -0700
|
||
C: From: John Q. Public <JQP@bar.com>
|
||
C: Subject: The Next Meeting of the Board
|
||
C: To: Jones@xyz.com
|
||
C:
|
||
C: Bill:
|
||
C: The next meeting of the board of directors will be
|
||
C: on Tuesday.
|
||
C: John.
|
||
C: .
|
||
S: 250 OK
|
||
C: QUIT
|
||
S: 221 foo.com Service closing transmission channel
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 90]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
Step 2 -- Relay Host to Destination Host
|
||
|
||
foo.com, having received the message, now does a DNS lookup on
|
||
xyz.com. It finds the same set of MX records, but cannot use the one
|
||
that points to itself (or to any other host as a worse preference).
|
||
It tries to open a connection to xyz.com itself and succeeds. Then
|
||
we have:
|
||
|
||
S: 220 xyz.com Simple Mail Transfer Service Ready
|
||
C: EHLO foo.com
|
||
S: 250 xyz.com is on the air
|
||
C: MAIL FROM:<JQP@bar.com>
|
||
S: 250 OK
|
||
C: RCPT TO:<Jones@XYZ.COM>
|
||
S: 250 OK
|
||
C: DATA
|
||
S: 354 Start mail input; end with <CRLF>.<CRLF>
|
||
C: Received: from bar.com by foo.com ; Thu, 21 May 1998
|
||
C: 05:33:29 -0700
|
||
C: Date: Thu, 21 May 1998 05:33:22 -0700
|
||
C: From: John Q. Public <JQP@bar.com>
|
||
C: Subject: The Next Meeting of the Board
|
||
C: To: Jones@xyz.com
|
||
C:
|
||
C: Bill:
|
||
C: The next meeting of the board of directors will be
|
||
C: on Tuesday.
|
||
C: John.
|
||
C: .
|
||
S: 250 OK
|
||
C: QUIT
|
||
S: 221 foo.com Service closing transmission channel
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 91]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
D.4. Verifying and Sending Scenario
|
||
|
||
S: 220 foo.com Simple Mail Transfer Service Ready
|
||
C: EHLO bar.com
|
||
S: 250-foo.com greets bar.com
|
||
S: 250-8BITMIME
|
||
S: 250-SIZE
|
||
S: 250-DSN
|
||
S: 250-VRFY
|
||
S: 250 HELP
|
||
C: VRFY Crispin
|
||
S: 250 Mark Crispin <Admin.MRC@foo.com>
|
||
C: MAIL FROM:<EAK@bar.com>
|
||
S: 250 OK
|
||
C: RCPT TO:<Admin.MRC@foo.com>
|
||
S: 250 OK
|
||
C: DATA
|
||
S: 354 Start mail input; end with <CRLF>.<CRLF>
|
||
C: Blah blah blah...
|
||
C: ...etc. etc. etc.
|
||
C: .
|
||
S: 250 OK
|
||
C: QUIT
|
||
S: 221 foo.com Service closing transmission channel
|
||
|
||
Appendix E. Other Gateway Issues
|
||
|
||
In general, gateways between the Internet and other mail systems
|
||
SHOULD attempt to preserve any layering semantics across the
|
||
boundaries between the two mail systems involved. Gateway-
|
||
translation approaches that attempt to take shortcuts by mapping
|
||
(such as mapping envelope information from one system to the message
|
||
header section or body of another) have generally proven to be
|
||
inadequate in important ways. Systems translating between
|
||
environments that do not support both envelopes and a header section
|
||
and Internet mail must be written with the understanding that some
|
||
information loss is almost inevitable.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 92]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
Appendix F. Deprecated Features of RFC 821
|
||
|
||
A few features of RFC 821 have proven to be problematic and SHOULD
|
||
NOT be used in Internet mail.
|
||
|
||
F.1. TURN
|
||
|
||
This command, described in RFC 821, raises important security issues
|
||
since, in the absence of strong authentication of the host requesting
|
||
that the client and server switch roles, it can easily be used to
|
||
divert mail from its correct destination. Its use is deprecated;
|
||
SMTP systems SHOULD NOT use it unless the server can authenticate the
|
||
client.
|
||
|
||
F.2. Source Routing
|
||
|
||
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
|
||
utilize source routes in regular mail traffic was eliminated by the
|
||
introduction of the domain name system "MX" record and the last
|
||
significant justification for them was eliminated by the
|
||
introduction, in RFC 1123, of a clear requirement that addresses
|
||
following an "@" must all be fully-qualified domain names.
|
||
Consequently, the only remaining justifications for the use of source
|
||
routes are support for very old SMTP clients or MUAs and in mail
|
||
system debugging. They can, however, still be useful in the latter
|
||
circumstance and for routing mail around serious, but temporary,
|
||
problems such as problems with the relevant DNS records.
|
||
|
||
SMTP servers MUST continue to accept source route syntax as specified
|
||
in the main body of this document and in RFC 1123. They MAY, if
|
||
necessary, ignore the 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.
|
||
|
||
Clients SHOULD NOT utilize explicit source routing except under
|
||
unusual circumstances, such as debugging or potentially relaying
|
||
around firewall or mail system configuration errors.
|
||
|
||
F.3. HELO
|
||
|
||
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
|
||
continue to accept and process HELO in order to support older
|
||
clients.
|
||
|
||
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 93]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
F.4. #-literals
|
||
|
||
RFC 821 provided for specifying an Internet address as a decimal
|
||
integer host number prefixed by a pound sign, "#". In practice, that
|
||
form has been obsolete since the introduction of TCP/IP. It is
|
||
deprecated and MUST NOT be used.
|
||
|
||
F.5. Dates and Years
|
||
|
||
When dates are inserted into messages by SMTP clients or servers
|
||
(e.g., in trace header fields), four-digit years MUST BE used. Two-
|
||
digit years are deprecated; three-digit years were never permitted in
|
||
the Internet mail system.
|
||
|
||
F.6. Sending versus Mailing
|
||
|
||
In addition to specifying a mechanism for delivering messages to
|
||
user's mailboxes, RFC 821 provided additional, optional, commands to
|
||
deliver messages directly to the user's terminal screen. These
|
||
commands (SEND, SAML, SOML) were rarely implemented, and changes in
|
||
workstation technology and the introduction of other protocols may
|
||
have rendered them obsolete even where they are implemented.
|
||
|
||
Clients SHOULD NOT provide SEND, SAML, or SOML as services. Servers
|
||
MAY implement them. If they are implemented by servers, the
|
||
implementation model specified in RFC 821 MUST be used and the
|
||
command names MUST be published in the response to the EHLO command.
|
||
|
||
Author's Address
|
||
|
||
John C. Klensin
|
||
1770 Massachusetts Ave, Suite 322
|
||
Cambridge, MA 02140
|
||
USA
|
||
|
||
EMail: john+smtp@jck.com
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 94]
|
||
|
||
RFC 5321 SMTP October 2008
|
||
|
||
|
||
Full Copyright Statement
|
||
|
||
Copyright (C) The IETF Trust (2008).
|
||
|
||
This document is subject to the rights, licenses and restrictions
|
||
contained in BCP 78, and except as set forth therein, the authors
|
||
retain all their rights.
|
||
|
||
This document and the information contained herein are provided on an
|
||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
|
||
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
|
||
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
|
||
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||
|
||
Intellectual Property
|
||
|
||
The IETF takes no position regarding the validity or scope of any
|
||
Intellectual Property Rights or other rights that might be claimed to
|
||
pertain to the implementation or use of the technology described in
|
||
this document or the extent to which any license under such rights
|
||
might or might not be available; nor does it represent that it has
|
||
made any independent effort to identify any such rights. Information
|
||
on the procedures with respect to rights in RFC documents can be
|
||
found in BCP 78 and BCP 79.
|
||
|
||
Copies of IPR disclosures made to the IETF Secretariat and any
|
||
assurances of licenses to be made available, or the result of an
|
||
attempt made to obtain a general license or permission for the use of
|
||
such proprietary rights by implementers or users of this
|
||
specification can be obtained from the IETF on-line IPR repository at
|
||
http://www.ietf.org/ipr.
|
||
|
||
The IETF invites any interested party to bring to its attention any
|
||
copyrights, patents or patent applications, or other proprietary
|
||
rights that may cover technology that may be required to implement
|
||
this standard. Please address the information to the IETF at
|
||
ietf-ipr@ietf.org.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Klensin Standards Track [Page 95]
|
||
|