📄 smtp_rfc2821.txt
字号:
Network Working Group J. Klensin, Editor
Request for Comments: 2821 AT&T Laboratories
Obsoletes: 821, 974, 1869 April 2001
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.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
This document is a self-contained specification of the basic protocol
for the Internet electronic mail transport. It consolidates, updates
and clarifies, but doesn't add new or change existing functionality
of the following:
- the original SMTP (Simple Mail Transfer Protocol) specification of
RFC 821 [30],
- domain name system requirements and implications for mail
transport from RFC 1035 [22] and RFC 974 [27],
- the clarifications and applicability statements in RFC 1123 [2],
and
- material drawn from the SMTP Extension mechanisms [19].
It obsoletes RFC 821, RFC 974, and updates RFC 1123 (replaces 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.
Klensin Standards Track [Page 1]
RFC 2821 Simple Mail Transfer Protocol April 2001
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 POP [3, 26]
and IMAP [6]. Additional submission issues are discussed in RFC 2476
[15].
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 [32] discusses message headers, message bodies
and formats and structures for them, and their relationship.
Table of Contents
1. Introduction .................................................. 4
2. The SMTP Model ................................................ 5
2.1 Basic Structure .............................................. 5
2.2 The Extension Model .......................................... 7
2.2.1 Background ................................................. 7
2.2.2 Definition and Registration of Extensions .................. 8
2.3 Terminology .................................................. 9
2.3.1 Mail Objects ............................................... 10
2.3.2 Senders and Receivers ...................................... 10
2.3.3 Mail Agents and Message Stores ............................. 10
2.3.4 Host ....................................................... 11
2.3.5 Domain ..................................................... 11
2.3.6 Buffer and State Table ..................................... 11
2.3.7 Lines ...................................................... 12
2.3.8 Originator, Delivery, Relay, and Gateway Systems ........... 12
2.3.9 Message Content and Mail Data .............................. 13
2.3.10 Mailbox and Address ....................................... 13
2.3.11 Reply ..................................................... 13
2.4 General Syntax Principles and Transaction Model .............. 13
3. The SMTP Procedures: An Overview .............................. 15
3.1 Session Initiation ........................................... 15
3.2 Client Initiation ............................................ 16
3.3 Mail Transactions ............................................ 16
3.4 Forwarding for Address Correction or Updating ................ 19
Klensin Standards Track [Page 2]
RFC 2821 Simple Mail Transfer Protocol April 2001
3.5 Commands for Debugging Addresses ............................. 20
3.5.1 Overview ................................................... 20
3.5.2 VRFY Normal Response ....................................... 22
3.5.3 Meaning of VRFY or EXPN Success Response ................... 22
3.5.4 Semantics and Applications of EXPN ......................... 23
3.6 Domains ...................................................... 23
3.7 Relaying ..................................................... 24
3.8 Mail Gatewaying .............................................. 25
3.8.1 Header Fields in Gatewaying ................................ 26
3.8.2 Received Lines in Gatewaying ............................... 26
3.8.3 Addresses in Gatewaying .................................... 26
3.8.4 Other Header Fields in Gatewaying .......................... 27
3.8.5 Envelopes in Gatewaying .................................... 27
3.9 Terminating Sessions and Connections ......................... 27
3.10 Mailing Lists and Aliases ................................... 28
3.10.1 Alias ..................................................... 28
3.10.2 List ...................................................... 28
4. The SMTP Specifications ....................................... 29
4.1 SMTP Commands ................................................ 29
4.1.1 Command Semantics and Syntax ............................... 29
4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO) ................... 29
4.1.1.2 MAIL (MAIL) .............................................. 31
4.1.1.3 RECIPIENT (RCPT) ......................................... 31
4.1.1.4 DATA (DATA) .............................................. 33
4.1.1.5 RESET (RSET) ............................................. 34
4.1.1.6 VERIFY (VRFY) ............................................ 35
4.1.1.7 EXPAND (EXPN) ............................................ 35
4.1.1.8 HELP (HELP) .............................................. 35
4.1.1.9 NOOP (NOOP) .............................................. 35
4.1.1.10 QUIT (QUIT) ............................................. 36
4.1.2 Command Argument Syntax .................................... 36
4.1.3 Address Literals ........................................... 38
4.1.4 Order of Commands .......................................... 39
4.1.5 Private-use Commands ....................................... 40
4.2 SMTP Replies ................................................ 40
4.2.1 Reply Code Severities and Theory ........................... 42
4.2.2 Reply Codes by Function Groups ............................. 44
4.2.3 Reply Codes in Numeric Order .............................. 45
4.2.4 Reply Code 502 ............................................. 46
4.2.5 Reply Codes After DATA and the Subsequent <CRLF>.<CRLF> .... 46
4.3 Sequencing of Commands and Replies ........................... 47
4.3.1 Sequencing Overview ........................................ 47
4.3.2 Command-Reply Sequences .................................... 48
4.4 Trace Information ............................................ 49
4.5 Additional Implementation Issues ............................. 53
4.5.1 Minimum Implementation ..................................... 53
4.5.2 Transparency ............................................... 53
4.5.3 Sizes and Timeouts ......................................... 54
Klensin Standards Track [Page 3]
RFC 2821 Simple Mail Transfer Protocol April 2001
4.5.3.1 Size limits and minimums ................................. 54
4.5.3.2 Timeouts ................................................. 56
4.5.4 Retry Strategies ........................................... 57
4.5.4.1 Sending Strategy ......................................... 58
4.5.4.2 Receiving Strategy ....................................... 59
4.5.5 Messages with a null reverse-path .......................... 59
5. Address Resolution and Mail Handling .......................... 60
6. Problem Detection and Handling ................................ 62
6.1 Reliable Delivery and Replies by Email ....................... 62
6.2 Loop Detection ............................................... 63
6.3 Compensating for Irregularities .............................. 63
7. Security Considerations ....................................... 64
7.1 Mail Security and Spoofing ................................... 64
7.2 "Blind" Copies ............................................... 65
7.3 VRFY, EXPN, and Security ..................................... 65
7.4 Information Disclosure in Announcements ...................... 66
7.5 Information Disclosure in Trace Fields ....................... 66
7.6 Information Disclosure in Message Forwarding ................. 67
7.7 Scope of Operation of SMTP Servers ........................... 67
8. IANA Considerations ........................................... 67
9. References .................................................... 68
10. Editor's Address ............................................. 70
11. Acknowledgments .............................................. 70
Appendices ....................................................... 71
A. TCP Transport Service ......................................... 71
B. Generating SMTP Commands from RFC 822 Headers ................. 71
C. Source Routes ................................................. 72
D. Scenarios ..................................................... 73
E. Other Gateway Issues .......................................... 76
F. Deprecated Features of RFC 821 ................................ 76
Full Copyright Statement ......................................... 79
1. Introduction
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 describe some of them.
An important feature of SMTP is its capability to transport mail
across networks, usually referred to as "SMTP mail relaying" (see
section 3.8). 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
Klensin Standards Track [Page 4]
RFC 2821 Simple Mail Transfer Protocol April 2001
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 [22, 27] (and
section 5 of this document) are used to identify the appropriate
next-hop destination for a message being transported.
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 domain name(s) to which mail messages
are to be transferred is a local matter, and is not addressed by this
document. In some cases, the domain name(s) transferred to, or
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 [3, 26] or IMAP [6]
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -