rfc2822.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                 P. Resnick, Editor
Request for Comments: 2822                         QUALCOMM Incorporated
Obsoletes: 822                                                April 2001
Category: Standards Track


                        Internet Message Format

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract

   This standard specifies a syntax for text messages that are sent
   between computer users, within the framework of "electronic mail"
   messages.  This standard supersedes the one specified in Request For
   Comments (RFC) 822, "Standard for the Format of ARPA Internet Text
   Messages", updating it to reflect current practice and incorporating
   incremental changes that were specified in other RFCs.

Table of Contents

   1. Introduction ............................................... 3
   1.1. Scope .................................................... 3
   1.2. Notational conventions ................................... 4
   1.2.1. Requirements notation .................................. 4
   1.2.2. Syntactic notation ..................................... 4
   1.3. Structure of this document ............................... 4
   2. Lexical Analysis of Messages ............................... 5
   2.1. General Description ...................................... 5
   2.1.1. Line Length Limits ..................................... 6
   2.2. Header Fields ............................................ 7
   2.2.1. Unstructured Header Field Bodies ....................... 7
   2.2.2. Structured Header Field Bodies ......................... 7
   2.2.3. Long Header Fields ..................................... 7
   2.3. Body ..................................................... 8
   3. Syntax ..................................................... 9
   3.1. Introduction ............................................. 9
   3.2. Lexical Tokens ........................................... 9



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


   3.2.1. Primitive Tokens ....................................... 9
   3.2.2. Quoted characters ......................................10
   3.2.3. Folding white space and comments .......................11
   3.2.4. Atom ...................................................12
   3.2.5. Quoted strings .........................................13
   3.2.6. Miscellaneous tokens ...................................13
   3.3. Date and Time Specification ..............................14
   3.4. Address Specification ....................................15
   3.4.1. Addr-spec specification ................................16
   3.5 Overall message syntax ....................................17
   3.6. Field definitions ........................................18
   3.6.1. The origination date field .............................20
   3.6.2. Originator fields ......................................21
   3.6.3. Destination address fields .............................22
   3.6.4. Identification fields ..................................23
   3.6.5. Informational fields ...................................26
   3.6.6. Resent fields ..........................................26
   3.6.7. Trace fields ...........................................28
   3.6.8. Optional fields ........................................29
   4. Obsolete Syntax ............................................29
   4.1. Miscellaneous obsolete tokens ............................30
   4.2. Obsolete folding white space .............................31
   4.3. Obsolete Date and Time ...................................31
   4.4. Obsolete Addressing ......................................33
   4.5. Obsolete header fields ...................................33
   4.5.1. Obsolete origination date field ........................34
   4.5.2. Obsolete originator fields .............................34
   4.5.3. Obsolete destination address fields ....................34
   4.5.4. Obsolete identification fields .........................35
   4.5.5. Obsolete informational fields ..........................35
   4.5.6. Obsolete resent fields .................................35
   4.5.7. Obsolete trace fields ..................................36
   4.5.8. Obsolete optional fields ...............................36
   5. Security Considerations ....................................36
   6. Bibliography ...............................................37
   7. Editor's Address ...........................................38
   8. Acknowledgements ...........................................39
   Appendix A. Example messages ..................................41
   A.1. Addressing examples ......................................41
   A.1.1. A message from one person to another with simple
          addressing .............................................41
   A.1.2. Different types of mailboxes ...........................42
   A.1.3. Group addresses ........................................43
   A.2. Reply messages ...........................................43
   A.3. Resent messages ..........................................44
   A.4. Messages with trace fields ...............................46
   A.5. White space, comments, and other oddities ................47
   A.6. Obsoleted forms ..........................................47



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


   A.6.1. Obsolete addressing ....................................48
   A.6.2. Obsolete dates .........................................48
   A.6.3. Obsolete white space and comments ......................48
   Appendix B. Differences from earlier standards ................49
   Appendix C. Notices ...........................................50
   Full Copyright Statement ......................................51

1. Introduction

1.1. Scope

   This standard specifies a syntax for text messages that are sent
   between computer users, within the framework of "electronic mail"
   messages.  This standard supersedes the one specified in Request For
   Comments (RFC) 822, "Standard for the Format of ARPA Internet Text
   Messages" [RFC822], updating it to reflect current practice and
   incorporating incremental changes that were specified in other RFCs
   [STD3].

   This standard specifies a syntax only for text messages.  In
   particular, it makes no provision for the transmission of images,
   audio, or other sorts of structured data in electronic mail messages.
   There are several extensions published, such as the MIME document
   series [RFC2045, RFC2046, RFC2049], which describe mechanisms for the
   transmission of such data through electronic mail, either by
   extending the syntax provided here or by structuring such messages to
   conform to this syntax.  Those mechanisms are outside of the scope of
   this standard.

   In the context of electronic mail, messages are viewed as having an
   envelope and contents.  The envelope contains whatever information is
   needed to accomplish transmission and delivery.  (See [RFC2821] for a
   discussion of the envelope.)  The contents comprise the object to be
   delivered to the recipient.  This standard applies only to the format
   and some of the semantics of message contents.  It contains no
   specification of the information in the envelope.

   However, some message systems may use information from the contents
   to create the envelope.  It is intended that this standard facilitate
   the acquisition of such information by programs.

   This specification is intended as a definition of what message
   content format is to be passed between systems.  Though some message
   systems locally store messages in this format (which eliminates the
   need for translation between formats) and others use formats that
   differ from the one specified in this standard, local storage is
   outside of the scope of this standard.




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


   Note: This standard is not intended to dictate the internal formats
   used by sites, the specific message system features that they are
   expected to support, or any of the characteristics of user interface
   programs that create or read messages.  In addition, this standard
   does not specify an encoding of the characters for either transport
   or storage; that is, it does not specify the number of bits used or
   how those bits are specifically transferred over the wire or stored
   on disk.

1.2. Notational conventions

1.2.1. Requirements notation

   This document occasionally uses terms that appear in capital letters.
   When the terms "MUST", "SHOULD", "RECOMMENDED", "MUST NOT", "SHOULD
   NOT", and "MAY" appear capitalized, they are being used to indicate
   particular requirements of this specification.  A discussion of the
   meanings of these terms appears in [RFC2119].

1.2.2. Syntactic notation

   This standard uses the Augmented Backus-Naur Form (ABNF) notation
   specified in [RFC2234] for the formal definitions of the syntax of
   messages.  Characters will be specified either by a decimal value
   (e.g., the value %d65 for uppercase A and %d97 for lowercase A) or by
   a case-insensitive literal value enclosed in quotation marks (e.g.,
   "A" for either uppercase or lowercase A).  See [RFC2234] for the full
   description of the notation.

1.3. Structure of this document

   This document is divided into several sections.

   This section, section 1, is a short introduction to the document.

   Section 2 lays out the general description of a message and its
   constituent parts.  This is an overview to help the reader understand
   some of the general principles used in the later portions of this
   document.  Any examples in this section MUST NOT be taken as
   specification of the formal syntax of any part of a message.

   Section 3 specifies formal ABNF rules for the structure of each part
   of a message (the syntax) and describes the relationship between
   those parts and their meaning in the context of a message (the
   semantics).  That is, it describes the actual rules for the structure
   of each part of a message (the syntax) as well as a description of
   the parts and instructions on how they ought to be interpreted (the
   semantics).  This includes analysis of the syntax and semantics of



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


   subparts of messages that have specific structure.  The syntax
   included in section 3 represents messages as they MUST be created.
   There are also notes in section 3 to indicate if any of the options
   specified in the syntax SHOULD be used over any of the others.

   Both sections 2 and 3 describe messages that are legal to generate
   for purposes of this standard.

   Section 4 of this document specifies an "obsolete" syntax.  There are
   references in section 3 to these obsolete syntactic elements.  The
   rules of the obsolete syntax are elements that have appeared in
   earlier revisions of this standard or have previously been widely
   used in Internet messages.  As such, these elements MUST be
   interpreted by parsers of messages in order to be conformant to this
   standard.  However, since items in this syntax have been determined
   to be non-interoperable or to cause significant problems for
   recipients of messages, they MUST NOT be generated by creators of
   conformant messages.

   Section 5 details security considerations to take into account when
   implementing this standard.

   Section 6 is a bibliography of references in this document.

   Section 7 contains the editor's address.

   Section 8 contains acknowledgements.

   Appendix A lists examples of different sorts of messages.  These
   examples are not exhaustive of the types of messages that appear on
   the Internet, but give a broad overview of certain syntactic forms.

   Appendix B lists the differences between this standard and earlier
   standards for Internet messages.

   Appendix C has copyright and intellectual property notices.

2. Lexical Analysis of Messages

2.1. General Description

   At the most basic level, a message is a series of characters.  A
   message that is conformant with this standard is comprised of
   characters with values in the range 1 through 127 and interpreted as
   US-ASCII characters [ASCII].  For brevity, this document sometimes
   refers to this range of characters as simply "US-ASCII characters".





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


   Note: This standard specifies that messages are made up of characters
   in the US-ASCII range of 1 through 127.  There are other documents,
   specifically the MIME document series [RFC2045, RFC2046, RFC2047,
   RFC2048, RFC2049], that extend this standard to allow for values
   outside of that range.  Discussion of those mechanisms is not within
   the scope of this standard.

   Messages are divided into lines of characters.  A line is a series of
   characters that is delimited with the two characters carriage-return
   and line-feed; that is, the carriage return (CR) character (ASCII
   value 13) followed immediately by the line feed (LF) character (ASCII
   value 10).  (The carriage-return/line-feed pair is usually written in
   this document as "CRLF".)

   A message consists of header fields (collectively called "the header
   of the message") followed, optionally, by a body.  The header is a