rfc2821.txt

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

   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.

2.3.2 Senders and Receivers

   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.

2.3.3 Mail Agents and Message Stores

   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



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


   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.

2.3.4 Host

   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.

2.3.5 Domain

   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.

   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.

2.3.6 Buffer and State Table

   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.







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


2.3.7 Lines

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

   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.

2.3.8 Originator, Delivery, Relay, and Gateway Systems

   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.

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








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


2.3.9 Message Content and Mail Data

   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.

2.3.10 Mailbox and Address

   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-
   part@domain": 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.

2.3.11 Reply

   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.

2.4 General Syntax Principles and Transaction Model

   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.




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


   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.

   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.

   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.

   The syntax for each command is shown with the discussion of that
   command.  Common elements and parameters are shown in section 4.1.2.

   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





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


   set other than US-ASCII; receiving systems SHOULD reject such
   commands, normally using "500 syntax error - invalid character"
   replies.

   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.