rfc2821.txt

用C#开发实现SMTP相关技术,能接收到带附件的邮件服务功能.

   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.

3. The SMTP Procedures: An Overview

   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.

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

   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



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


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

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

3.3 Mail Transactions

   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.

   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



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


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

      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 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).
   This step of the procedure can be repeated any number of times.

   The <forward-path> can contain more than just a mailbox.
   Historically, the <forward-path> can be 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 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).

   The third step in the procedure is the DATA command (or some
   alternative specified in a service extension).



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


      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
   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), or 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.  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 RFC 822 format [7, 32] is being used, the mail data include the
   memo header items such as Date, Subject, To, Cc, From.  Server SMTP
   systems SHOULD NOT reject messages based on perceived defects in the
   RFC 822 or MIME [12] message header or message body.  In particular,




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


   they MUST NOT reject messages in which the numbers of Resent-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 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
   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.

   In particular:

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

   *  Servers MAY reject or bounce messages when they are not
      deliverable when 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.  But, 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 are strongly encouraged to provide configuration mechanisms so
   that sites which conclude that they would undesirably disclose
   information can disable or restrict their use.



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