Section 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].
   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
   illustrative examples that should not actually be used in either code
   or configuration files.