smtp_rfc2821.txt

ssmt邮件服务器armlinux下的邮件开发

   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




Klensin                     Standards Track                     [Page 5]

RFC 2821             Simple Mail Transfer Protocol            April 2001


   ones, and their destinations, are expected to support all of the
   queuing, retrying, and alternate address functions discussed in this
   specification.

   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.

   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, 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.

   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.

   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].





Klensin                     Standards Track                     [Page 6]

RFC 2821             Simple Mail Transfer Protocol            April 2001


   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.

   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.

   Usually, intermediate hosts are determined via the DNS MX record, not
   by explicit "source" routing (see section 5 and appendices C and
   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
   added, it must be done in a way that permits older implementations to
   continue working acceptably.  The extension framework consists of:




Klensin                     Standards Track                     [Page 7]

RFC 2821             Simple Mail Transfer Protocol            April 2001


   -  The SMTP command EHLO, superseding the earlier HELO,

   -  a registry of SMTP service extensions,

   -  additional parameters to the SMTP MAIL and RCPT commands, and

   -  optional replacements for commands defined in this protocol, such
      as for DATA in non-ASCII transmissions [33].

   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:

   -  the textual name of the SMTP service extension;

   -  the EHLO keyword value associated with the extension;

   -  the syntax and possible values of parameters associated with the
      EHLO keyword value;

   -  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);

   -  any new parameters the extension associates with the MAIL or RCPT
      verbs;

   -  a description of how support for the extension affects the
      behavior of a server and client SMTP; and,

   -  the increment by which the extension is increasing the maximum
      length of the commands MAIL and/or RCPT, over that specified in
      this standard.





Klensin                     Standards Track                     [Page 8]

RFC 2821             Simple Mail Transfer Protocol            April 2001


   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.3 Terminology

   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.

   1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that
      the definition is an absolute requirement of the specification.

   2. MUST NOT   This phrase, or the phrase "SHALL NOT", mean that the
      definition is an absolute prohibition of the specification.

   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.

   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.

   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



Klensin                     Standards Track                     [Page 9]

RFC 2821             Simple Mail Transfer Protocol            April 2001


      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.)

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
   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).

   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