rfc2822.txt

RFC 的详细文档！

   interpreted string is either a quoted-string or a dot-atom.  If the
   string can be represented as a dot-atom (that is, it contains no
   characters other than atext characters or "." surrounded by atext



Resnick                     Standards Track                    [Page 16]

RFC 2822                Internet Message Format               April 2001


   characters), then the dot-atom form SHOULD be used and the
   quoted-string form SHOULD NOT be used. Comments and folding white
   space SHOULD NOT be used around the "@" in the addr-spec.

addr-spec       =       local-part "@" domain

local-part      =       dot-atom / quoted-string / obs-local-part

domain          =       dot-atom / domain-literal / obs-domain

domain-literal  =       [CFWS] "[" *([FWS] dcontent) [FWS] "]" [CFWS]

dcontent        =       dtext / quoted-pair

dtext           =       NO-WS-CTL /     ; Non white space controls

                        %d33-90 /       ; The rest of the US-ASCII
                        %d94-126        ;  characters not including "[",
                                        ;  "]", or "\"

   The domain portion identifies the point to which the mail is
   delivered. In the dot-atom form, this is interpreted as an Internet
   domain name (either a host name or a mail exchanger name) as
   described in [STD3, STD13, STD14].  In the domain-literal form, the
   domain is interpreted as the literal Internet address of the
   particular host.  In both cases, how addressing is used and how
   messages are transported to a particular host is covered in the mail
   transport document [RFC2821].  These mechanisms are outside of the
   scope of this document.

   The local-part portion is a domain dependent string.  In addresses,
   it is simply interpreted on the particular host as a name of a
   particular mailbox.

3.5 Overall message syntax

   A message consists of header fields, optionally followed by a message
   body.  Lines in a message MUST be a maximum of 998 characters
   excluding the CRLF, but it is RECOMMENDED that lines be limited to 78
   characters excluding the CRLF.  (See section 2.1.1 for explanation.)
   In a message body, though all of the characters listed in the text
   rule MAY be used, the use of US-ASCII control characters (values 1
   through 8, 11, 12, and 14 through 31) is discouraged since their
   interpretation by receivers for display is not guaranteed.







Resnick                     Standards Track                    [Page 17]

RFC 2822                Internet Message Format               April 2001


message         =       (fields / obs-fields)
                        [CRLF body]

body            =       *(*998text CRLF) *998text

   The header fields carry most of the semantic information and are
   defined in section 3.6.  The body is simply a series of lines of text
   which are uninterpreted for the purposes of this standard.

3.6. Field definitions

   The header fields of a message are defined here.  All header fields
   have the same general syntactic structure: A field name, followed by
   a colon, followed by the field body.  The specific syntax for each
   header field is defined in the subsequent sections.

   Note: In the ABNF syntax for each field in subsequent sections, each
   field name is followed by the required colon.  However, for brevity
   sometimes the colon is not referred to in the textual description of
   the syntax.  It is, nonetheless, required.

   It is important to note that the header fields are not guaranteed to
   be in a particular order.  They may appear in any order, and they
   have been known to be reordered occasionally when transported over
   the Internet.  However, for the purposes of this standard, header
   fields SHOULD NOT be reordered when a message is transported or
   transformed.  More importantly, the trace header fields and resent
   header fields MUST NOT be reordered, and SHOULD be kept in blocks
   prepended to the message.  See sections 3.6.6 and 3.6.7 for more
   information.

   The only required header fields are the origination date field and
   the originator address field(s).  All other header fields are
   syntactically optional.  More information is contained in the table
   following this definition.

fields          =       *(trace
                          *(resent-date /
                           resent-from /
                           resent-sender /
                           resent-to /
                           resent-cc /
                           resent-bcc /
                           resent-msg-id))
                        *(orig-date /
                        from /
                        sender /
                        reply-to /



Resnick                     Standards Track                    [Page 18]

RFC 2822                Internet Message Format               April 2001


                        to /
                        cc /
                        bcc /
                        message-id /
                        in-reply-to /
                        references /
                        subject /
                        comments /
                        keywords /
                        optional-field)

   The following table indicates limits on the number of times each
   field may occur in a message header as well as any special
   limitations on the use of those fields.  An asterisk next to a value
   in the minimum or maximum column indicates that a special restriction
   appears in the Notes column.

Field           Min number      Max number      Notes

trace           0               unlimited       Block prepended - see
                                                3.6.7

resent-date     0*              unlimited*      One per block, required
                                                if other resent fields
                                                present - see 3.6.6

resent-from     0               unlimited*      One per block - see
                                                3.6.6

resent-sender   0*              unlimited*      One per block, MUST
                                                occur with multi-address
                                                resent-from - see 3.6.6

resent-to       0               unlimited*      One per block - see
                                                3.6.6

resent-cc       0               unlimited*      One per block - see
                                                3.6.6

resent-bcc      0               unlimited*      One per block - see
                                                3.6.6

resent-msg-id   0               unlimited*      One per block - see
                                                3.6.6

orig-date       1               1

from            1               1               See sender and 3.6.2



Resnick                     Standards Track                    [Page 19]

RFC 2822                Internet Message Format               April 2001


sender          0*              1               MUST occur with multi-
                                                address from - see 3.6.2

reply-to        0               1

to              0               1

cc              0               1

bcc             0               1

message-id      0*              1               SHOULD be present - see
                                                3.6.4

in-reply-to     0*              1               SHOULD occur in some
                                                replies - see 3.6.4

references      0*              1               SHOULD occur in some
                                                replies - see 3.6.4

subject         0               1

comments        0               unlimited

keywords        0               unlimited

optional-field  0               unlimited

   The exact interpretation of each field is described in subsequent
   sections.

3.6.1. The origination date field

   The origination date field consists of the field name "Date" followed
   by a date-time specification.

orig-date       =       "Date:" date-time CRLF

   The origination date specifies the date and time at which the creator
   of the message indicated that the message was complete and ready to
   enter the mail delivery system.  For instance, this might be the time
   that a user pushes the "send" or "submit" button in an application
   program.  In any case, it is specifically not intended to convey the
   time that the message is actually transported, but rather the time at
   which the human or other creator of the message has put the message
   into its final form, ready for transport.  (For example, a portable
   computer user who is not connected to a network might queue a message




Resnick                     Standards Track                    [Page 20]

RFC 2822                Internet Message Format               April 2001


   for delivery.  The origination date is intended to contain the date
   and time that the user queued the message, not the time when the user
   connected to the network to send the message.)

3.6.2. Originator fields

   The originator fields of a message consist of the from field, the
   sender field (when applicable), and optionally the reply-to field.
   The from field consists of the field name "From" and a
   comma-separated list of one or more mailbox specifications.  If the
   from field contains more than one mailbox specification in the
   mailbox-list, then the sender field, containing the field name
   "Sender" and a single mailbox specification, MUST appear in the
   message.  In either case, an optional reply-to field MAY also be
   included, which contains the field name "Reply-To" and a
   comma-separated list of one or more addresses.

from            =       "From:" mailbox-list CRLF

sender          =       "Sender:" mailbox CRLF

reply-to        =       "Reply-To:" address-list CRLF

   The originator fields indicate the mailbox(es) of the source of the
   message.  The "From:" field specifies the author(s) of the message,
   that is, the mailbox(es) of the person(s) or system(s) responsible
   for the writing of the message.  The "Sender:" field specifies the
   mailbox of the agent responsible for the actual transmission of the
   message.  For example, if a secretary were to send a message for
   another person, the mailbox of the secretary would appear in the
   "Sender:" field and the mailbox of the actual author would appear in
   the "From:" field.  If the originator of the message can be indicated
   by a single mailbox and the author and transmitter are identical, the
   "Sender:" field SHOULD NOT be used.  Otherwise, both fields SHOULD
   appear.

   The originator fields also provide the information required when
   replying to a message.  When the "Reply-To:" field is present, it
   indicates the mailbox(es) to which the author of the message suggests
   that replies be sent.  In the absence of the "Reply-To:" field,
   replies SHOULD by default be sent to the mailbox(es) specified in the
   "From:" field unless otherwise specified by the person composing the
   reply.

   In all cases, the "From:" field SHOULD NOT contain any mailbox that
   does not belong to the author(s) of the message.  See also section
   3.6.3 for more information on forming the destination addresses for a
   reply.



Resnick                     Standards Track                    [Page 21]

RFC 2822                Internet Message Format               April 2001


3.6.3. Destination address fields

   The destination fields of a message consist of three possible fields,
   each of the same form: The field name, which is either "To", "Cc", or
   "Bcc", followed by a comma-separated list of one or more addresses
   (either mailbox or group syntax).