<P><FONT face="courier new,courier">Network Working Group                                 J. Klensin, Editor Request for Comments: 2821                             AT&T Laboratories Obsoletes: 821, 974, 1869                                     April 2001 Updates: 1123 Category: Standards Track</FONT></P> <P> <FONT face="courier new,courier">                     Simple Mail Transfer Protocol</FONT></P> <P><FONT face="courier new,courier">Status of this Memo</FONT></P> <P><FONT face="courier new,courier">   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.</FONT></P> <P><FONT face="courier new,courier">Copyright Notice</FONT></P> <P><FONT face="courier new,courier">   Copyright (C) The Internet Society (2001).  All Rights Reserved.</FONT></P> <P><FONT face="courier new,courier">Abstract</FONT></P> <P><FONT face="courier new,courier">   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:</FONT></P> <P><FONT face="courier new,courier">   -  the original SMTP (Simple Mail Transfer Protocol) specification of       RFC 821 [30],</FONT></P> <P><FONT face="courier new,courier">   -  domain name system requirements and implications for mail       transport from RFC 1035 [22] and RFC 974 [27],</FONT></P> <P><FONT face="courier new,courier">   -  the clarifications and applicability statements in RFC 1123 [2],       and</FONT></P> <P><FONT face="courier new,courier">   -  material drawn from the SMTP Extension mechanisms [19].</FONT></P> <P><FONT face="courier new,courier">   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.</FONT></P> <P><FONT face="courier new,courier"></FONT> </P> <P><FONT face="courier new,courier"></FONT> </P> <P> <FONT face="courier new,courier">Klensin                     Standards Track                     [Page 1] RFC 2821             Simple Mail Transfer Protocol            April 2001</FONT></P> <P> <FONT face="courier new,courier">   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.</FONT></P> <P><FONT face="courier new,courier">   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].</FONT></P> <P><FONT face="courier new,courier">   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.</FONT></P> <P><FONT face="courier new,courier">   A companion document [32] discusses message headers, message bodies    and formats and structures for them, and their relationship.</FONT></P> <P><FONT face="courier new,courier">Table of Contents</FONT></P> <P><FONT face="courier new,courier">   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</FONT></P> <P><FONT face="courier new,courier"></FONT> </P> <P><FONT face="courier new,courier">Klensin                     Standards Track                     [Page 2] RFC 2821             Simple Mail Transfer Protocol            April 2001</FONT></P> <P> <FONT face="courier new,courier">   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</FONT></P> <P><FONT face="courier new,courier"></FONT> </P> <P><FONT face="courier new,courier">Klensin                     Standards Track                     [Page 3] RFC 2821             Simple Mail Transfer Protocol            April 2001</FONT></P> <P> <FONT face="courier new,courier">   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</FONT></P> <P><FONT face="courier new,courier">1. Introduction</FONT></P> <P><FONT face="courier new,courier">   The objective of the Simple Mail Transfer Protocol (SMTP) is to    transfer mail reliably and efficiently.</FONT></P> <P><FONT face="courier new,courier">   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.</FONT></P> <P><FONT face="courier new,courier">   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</FONT></P> <P><FONT face="courier new,courier"></FONT> </P> <P><FONT face="courier new,courier">Klensin                     Standards Track                     [Page 4] RFC 2821             Simple Mail Transfer Protocol            April 2001</FONT></P> <P> <FONT face="courier new,courier">   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.</FONT></P> <P><FONT face="courier new,courier">   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.</FONT></P> <P><FONT face="courier new,courier">2. The SMTP Model</FONT></P> <P><FONT face="courier new,courier">2.1 Basic Structure</FONT></P> <P><FONT face="courier new,courier">   The SMTP design can be pictured as:</FONT></P> <P><FONT face="courier new,courier">               +----------+                +----------+    +------+    |          |                |          |    | User |<-->|          |      SMTP      |          |    +------+    |  Client- |Commands/Replies| Server-  |    +------+    |   SMTP   |<-------------->|    SMTP  |    +------+    | File |<-->|          |    and Mail    |          |<-->| File |    |System|    |          |                |          |    |System|    +------+    +----------+                +----------+    +------+                 SMTP client                SMTP server</FONT></P> <P><FONT face="courier new,courier">   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.</FONT></P> <P><FONT face="courier new,courier">   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]    protocols, or when the SMTP client is inside an isolated transport    service environment, the domain name 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 domain names 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</FONT></P> <P><FONT face="courier new,courier"></FONT> </P> <P> <FONT face="courier new,courier">Klensin                     Standards Track                     [Page 5] RFC 2821             Simple Mail Transfer Protocol            April 2001</FONT></P> <P> <FONT face="courier new,courier">   ones, and their destinations, are expected to support all of the    queuing, retrying, and alternate address functions discussed in this    specification.</FONT></P> <P><FONT face="courier new,courier">   The means by which an SMTP client, once it has determined a target    domain name, 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.</FONT></P> <P><FONT face="courier new,courier">   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.</FONT></P> <P><FONT face="courier new,courier">   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, a formal handoff of responsibility for the message occurs: the    protocol requires that a server accept responsibility for either    delivering a message or properly reporting the failure to do so.</FONT></P> <P><FONT face="courier new,courier">   Once the transmission channel is established and initial handshaking    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 headers 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.</FONT></P> <P><FONT face="courier new,courier">   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 extension requests such as command    pipelining [13].</FONT></P> <P><FONT face="courier new,courier"></FONT> </P> <P><FONT face="courier new,courier"></FONT> </P> <P><FONT face="courier new,courier">Klensin                     Standards Track                     [Page 6] RFC 2821             Simple Mail Transfer Protocol            April 2001</FONT></P> <P> <FONT face="courier new,courier">   Once a given mail message has been transmitted, the client may either    request that the connection be shut down or may initiate other mail    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.</FONT></P> <P><FONT face="courier new,courier">   As suggested above, this protocol provides mechanisms for the    transmission of mail.  This transmission normally occurs 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.  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.</FONT></P> <P><FONT face="courier new,courier">   Usually, intermediate hosts are determined via the DNS MX record, not    by explicit "source" routing (see section 5 and appendices C and    F.2).</FONT></P> <P><FONT face="courier new,courier">2.2 The Extension Model</FONT></P> <P><FONT face="courier new,courier">2.2.1 Background</FONT></P> <P><FONT face="courier new,courier">   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.</FONT></P> <P><FONT face="courier new,courier">   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.</FONT></P> <P><FONT face="courier new,courier">   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    added, it must be done in a way that permits older implementations to    continue working acceptably.  The extension framework consists of:</FONT></P> <P><FONT face="courier new,courier"></FONT> </P> <P> <FONT face="courier new,courier">Klensin                     Standards Track                     [Page 7] RFC 2821             Simple Mail Transfer Protocol            April 2001</FONT></P> <P> <FONT face="courier new,courier">   -  The SMTP command EHLO, superseding the earlier HELO,</FONT></P> <P><FONT face="courier new,courier">   -  a registry of SMTP service extensions,</FONT></P> <P><FONT face="courier new,courier">   -  additional parameters to the SMTP MAIL and RCPT commands, and</FONT></P> <P><FONT face="courier new,courier">   -  optional replacements for commands defined in this protocol, such       as for DATA in non-ASCII transmissions [33].</FONT></P> <P><FONT face="courier new,courier">   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.</FONT></P> <P><FONT face="courier new,courier">   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.</FONT></P> <P><FONT face="courier new,courier">2.2.2 Definition and Registration of Extensions</FONT></P> <P><FONT face="courier new,courier">   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:</FONT></P> <P><FONT face="courier new,courier">   -  the textual name of the SMTP service extension;</FONT></P> <P><FONT face="courier new,courier">   -  the EHLO keyword value associated with the extension;</FONT></P> <P><FONT face="courier new,courier">   -  the syntax and possible values of parameters associated with the       EHLO keyword value;</FONT></P> <P><FONT face="courier new,courier">   -  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);</FONT></P> <P><FONT face="courier new,courier">   -  any new parameters the extension associates with the MAIL or RCPT       verbs;</FONT></P> <P><FONT face="courier new,courier">   -  a description of how support for the extension affects the       behavior of a server and client SMTP; and,</FONT></P> <P><FONT face="courier new,courier">   -  the increment by which the extension is increasing the maximum       length of the commands MAIL and/or RCPT, over that specified in       this standard.</FONT></P> <P><FONT face="courier new,courier"></FONT> </P> <P><FONT face="courier new,courier"></FONT> </P> <P><FONT face="courier new,courier">Klensin                     Standards Track                     [Page 8] RFC 2821             Simple Mail Transfer Protocol            April 2001</FONT></P> <P> <FONT face="courier new,courier">   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.</FONT></P> <P><FONT face="courier new,courier">   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.</FONT></P> <P><FONT face="courier new,courier">2.3 Terminology</FONT></P> <P><FONT face="courier new,courier">   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 below.</FONT></P> <P><FONT face="courier new,courier">   1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that       the definition is an absolute requirement of the specification.</FONT></P> <P><FONT face="courier new,courier">   2. MUST NOT   This phrase, or the phrase "SHALL NOT", mean that the       definition is an absolute prohibition of the specification.</FONT></P> <P><FONT face="courier new,courier">   3. SHOULD   This word, or the adjective "RECOMMENDED", mean that       there may exist valid reasons in particular circumstances to       ignore a particular item, but the full implications must be       understood and carefully weighed before choosing a different       course.</FONT></P> <P><FONT face="courier new,courier">   4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean       that there may exist valid reasons in particular circumstances       when the particular behavior is acceptable or even useful, but the       full implications should be understood and the case carefully       weighed before implementing any behavior described with this       label.</FONT></P> <P><FONT face="courier new,courier">   5. MAY   This word, or the adjective "OPTIONAL", mean that an item is       truly optional.  One vendor may choose to include the item because       a particular marketplace requires it or because the vendor feels       that it enhances the product while another vendor may omit the       same item.  An implementation which does not include a particular       option MUST be prepared to interoperate with another       implementation which does include the option, though perhaps with       reduced functionality.  In the same vein an implementation which</FONT></P> <P><FONT face="courier new,courier"></FONT> </P> <P><FONT face="courier new,courier">Klensin                     Standards Track                     [Page 9] RFC 2821             Simple Mail Transfer Protocol            April 2001</FONT></P> <P> <FONT face="courier new,courier">      does include a particular option MUST be prepared to interoperate       with another implementation which does not include the option       (except, of course, for the feature the option provides.)</FONT></P> <P><FONT face="courier new,courier">2.3.1 Mail Objects</FONT></P> <P><FONT face="courier new,courier">   SMTP transports a mail object.  A mail object contains an envelope    and content.</FONT></P> <P><FONT face="courier new,courier">   The SMTP envelope is sent as a series of SMTP protocol units    (described in section 3).  It consists of an originator address (to    which error reports should be directed); one or more recipient    addresses; and optional protocol extension material.  Historically,    variations on the recipient address specification command (RCPT TO)    could be used to specify alternate delivery modes, such as immediate    display; those variations have now been deprecated (see appendix F,    section F.6).</FONT></P> <P><FONT face="courier new,courier">   The SMTP content is sent in the SMTP DATA protocol unit and has two    parts:  the headers and the body.  If the content conforms to other    contemporary standards, the headers form a collection of field/value    pairs structured as in the message format specification [32]; the    body, if structured, is defined according to MIME [12].  The content    is textual in nature, expressed using the US-ASCII repertoire [1].    Although SMTP extensions (such as "8BITMIME" [20]) may relax this    restriction for the content body, the content headers are always    encoded using the US-ASCII repertoire.  A MIME extension [23] defines    an algorithm for representing header values outside the US-ASCII    repertoire, while still encoding them using the US-ASCII repertoire.</FONT></P> <P><FONT face="courier new,courier">2.3.2 Senders and Receivers</FONT></P> <P><FONT face="courier new,courier">   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.</FONT></P> <P><FONT face="courier new,courier">2.3.3 Mail Agents and Message Stores</FONT></P> <P><FONT face="courier new,courier">   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</FONT></P> <P><FONT face="courier new,courier"></FONT> </P> <P><FONT face="courier new,courier">Klensin                     Standards Track                    [Page 10] RFC 2821             Simple Mail Transfer Protocol            April 2001</FONT></P> <P> <FONT face="courier new,courier">   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    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.</FONT></P> <P><FONT face="courier new,courier">2.3.4 Host</FONT></P> <P><FONT face="courier new,courier">   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 "domain"); identifying them by numerical address is discouraged.</FONT></P> <P><FONT face="courier new,courier">2.3.5 Domain</FONT></P> <P><FONT face="courier new,courier">   A domain (or domain name) consists of one or more dot-separated    components.  These components ("labels" in DNS terminology [22]) are    restricted for SMTP purposes to consist of a sequence of letters,    digits, and hyphens drawn from the ASCII character set [1].  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 [22] and    section 5 of this specification.</FONT></P> <P><FONT face="courier new,courier">   The domain name, as described in this document and in [22], 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.</FONT></P> <P><FONT face="courier new,courier">2.3.6 Buffer and State Table</FONT></P> <P><FONT face="courier new,courier">   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 which    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.</FONT></P> <P><FONT face="courier new,courier"></FONT> </P> <P><FONT face="courier new,courier"></FONT> </P> <P><FONT face="courier new,courier"></FONT> </P> <P><FONT face="courier new,courier">Klensin                     Standards Track                    [Page 11] RFC 2821             Simple Mail Transfer Protocol            April 2001</FONT></P> <P> <FONT face="courier new,courier">2.3.7 Lines</FONT></P> <P><FONT face="courier new,courier">   SMTP commands and, unless altered by a service extension, message    data, are transmitted in "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.5.3).</FONT></P> <P><FONT face="courier new,courier">   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.</FONT></P> <P><FONT face="courier new,courier">2.3.8 Originator, Delivery, Relay, and Gateway Systems</FONT></P> <P><FONT face="courier new,courier">   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    which 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.</FONT></P> <P><FONT face="courier new,courier">   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 [11]).</FONT></P> <P><FONT face="courier new,courier"></FONT> </P> <P><FONT face="courier new,courier"></FONT> </P> <P><FONT face="courier new,courier"></FONT> </P> <P> <FONT face="courier new,courier">Klensin                     Standards Track                    [Page 12] RFC 2821             Simple Mail Transfer Protocol            April 2001</FONT></P> <P> <FONT face="courier new,courier">2.3.9 Message Content and Mail Data</FONT></P> <P><FONT face="courier new,courier">   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 message headers and the    possibly-structured message body.  The MIME specification [12]    provides the standard mechanisms for structured message bodies.</FONT></P> <P><FONT face="courier new,courier">2.3.10 Mailbox and Address</FONT></P> <P><FONT face="courier new,courier">   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-    </FONT><A href="mailto:part@domain"><FONT face="courier new,courier">part@domain</FONT></A><FONT face="courier new,courier">": 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    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.</FONT></P> <P><FONT face="courier new,courier">2.3.11 Reply</FONT></P> <P><FONT face="courier new,courier">   An SMTP reply is an acknowledgment (positive or negative) sent 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.  Recent work [34] has specified further structuring    of the reply strings, including the use of supplemental and more    specific completion codes.</FONT></P> <P><FONT face="courier new,courier">2.4 General Syntax Principles and Transaction Model</FONT></P> <P><FONT face="courier new,courier">   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 MUST follow 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.</FONT></P> <P><FONT face="courier new,courier"></FONT> </P> <P> <FONT face="courier new,courier">Klensin                     Standards Track                    [Page 13] RFC 2821             Simple Mail Transfer Protocol            April 2001</FONT></P> <P> <FONT face="courier new,courier">   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.  This    is NOT true of a mailbox local-part.  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.  Mailbox    domains are not case sensitive.  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.</FONT></P> <P><FONT face="courier new,courier">   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.</FONT></P> <P><FONT face="courier new,courier">   The argument field 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.</FONT></P> <P><FONT face="courier new,courier">   The syntax for each command is shown with the discussion of that    command.  Common elements and parameters are shown in section 4.1.2.</FONT></P> <P><FONT face="courier new,courier">   Commands and replies are composed of characters from the ASCII    character set [1].  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 seven bit    transport only.  An originating SMTP client which has not    successfully negotiated an appropriate extension with a particular    server 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 ultimate delivery of a    severely garbled message to the recipient.  Delivery SMTP systems MAY    reject ("bounce") such messages rather than deliver them.  No sending    SMTP system is permitted to send envelope commands in any character</FONT></P> <P><FONT face="courier new,courier"></FONT> </P> <P><FONT face="courier new,courier"></FONT> </P> <P><FONT face="courier new,courier">Klensin                     Standards Track                    [Page 14] RFC 2821             Simple Mail Transfer Protocol            April 2001</FONT></P> <P> <FONT face="courier new,courier">   set other than US-ASCII; receiving systems SHOULD reject such    commands, normally using "500 syntax error - invalid character"    replies.</FONT></P> <P><FONT face="courier new,courier">   Eight-bit message content transmission MAY be requested of the server    by a client using extended SMTP facilities, notably the "8BITMIME"    extension [20].  8BITMIME SHOULD be supported by SMTP servers.    However, it MUST not be construed as authorization to transmit    unrestricted eight bit material.  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.</FONT></P> <P><FONT face="courier new,courier">   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 [8].  Metalanguage terms used in running text are    surrounded by pointed brackets (e.g., <CRLF>) for clarity.</FONT></P> <P><FONT face="courier new,courier">3. The SMTP Procedures: An Overview</FONT></P> <P><FONT face="courier new,courier">   This section contains descriptions of the procedures used in SMTP:    session initiation, the mail transaction, forwarding mail, verifying    mailbox names and expanding mailing lists, and the 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.</FONT></P> <P><FONT face="courier new,courier">3.1 Session Initiation</FONT></P> <P><FONT face="courier new,courier">   An SMTP session is initiated when a client opens a connection to a    server and the server responds with an opening message.</FONT></P> <P><FONT face="courier new,courier">   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.5.1).</FONT></P> <P><FONT face="courier new,courier">   The SMTP protocol allows a server to formally reject a transaction    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</FONT></P> <P><FONT face="courier new,courier"></FONT> </P> <P><FONT face="courier new,courier">Klensin                     Standards Track                    [Page 15] RFC 2821             Simple Mail Transfer Protocol            April 2001</FONT></P> <P> <FONT face="courier new,courier">   "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.</FONT></P> <P><FONT face="courier new,courier">3.2 Client Initiation</FONT></P> <P><FONT face="courier new,courier">   Once the server has sent the 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 which are unable to    support service extensions and contemporary clients which 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.</FONT></P> <P><FONT face="courier new,courier">   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").</FONT></P> <P><FONT face="courier new,courier">3.3 Mail Transactions</FONT></P> <P><FONT face="courier new,courier">   There are three steps to SMTP mail transactions.  The transaction    starts with a MAIL command which 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.</FONT></P> <P><FONT face="courier new,courier">   The first step in the procedure is the MAIL command.</FONT></P> <P><FONT face="courier new,courier">      MAIL FROM:<reverse-path> [SP <mail-parameters> ] <CRLF></FONT></P> <P><FONT face="courier new,courier">   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 firs