rfc2076.txt

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

   marked as Approved.

   The person or agent submitting       Sender:        RFC 822: 4.4.2,
   the message to the network, if                      RFC 1123: 5.2.15-
   other than shown by the From:                       16, 5.3.7.
   header.

   Primary recipients.                  To:            RFC 822: 4.5.1,
                                                       RFC 1123: 5.2.15-
                                                       16, 5.3.7.




Palme                        Informational                      [Page 7]

RFC 2076                Internet Message Headers           February 1997


   Secondary, informational             cc:            RFC 822: 4.5.2,
   recipients. (cc = Carbon Copy)                      RFC 1123. 5.2.15-
                                                       16, 5.3.7.

   Recipients not to be disclosed to    bcc:           RFC 822: 4.5.3,
   other recipients. (bcc = Blind                      RFC 1123: 5.2.15-
   Carbon Copy).                                       16, 5.3.7.

   Primary recipients, who are          For-Handling:  Non-standard
   requested to handle the
   information in this message
   or its attachments.

   Primary recipients, who are          For-Comment:   Non-standard
   requested to comment on the
   information in this message
   or its attachments.

   In Usenet News: group(s) to which    Newsgroups:    RFC 1036: 2.1.3,
   this article was posted.                            not standardized
   Some systems provide this header                    and controversial
   also in e-mail although it is not                   for use in e-mail.
   standardized there.

   Unfortunately, the header can
   appear in e-mail with two
   different and contradictory
   meanings:

   (a) Indicating the newsgroup
   recipient of an article/message
   sent to both e-mail and Usenet
   News recipients.

   (b) In a personally addressed
   reply to an article in a news-
   group, indicating the newsgroup
   in which this discussion
   originated.












Palme                        Informational                      [Page 8]

RFC 2076                Internet Message Headers           February 1997


   Inserted by Sendmail when there      Apparently-    Non-standard,
   is no "To:" recipient in the         To:            discouraged,
   original message, listing                           mentioned in
   recipients derived from the                         RFC 1211.
   envelope into the message
   heading. This behavior is not
   quite proper, MTAs should not
   modify headings (except inserting
   Received lines), and it can in
   some cases cause Bcc recipients
   to be wrongly divulged to non-Bcc
   recipients.

   Geographical or organizational       Distribution:  RFC 1036: 2.2.7,
   limitation on where this article                    not standardized
   can be distributed.                                 for use in e-mail.

   Fax number of the originator.        Fax:,          Non-standard.
                                        Telefax:

   Phone number of the originator.      Phone:         Non-standard.

   Information about the client         Mail-System-   Non-standard.
   software of the originator.          Version:,
                                        Mailer:,
                                        Originating-
                                        Client:, X-
                                        Mailer, X-
                                        Newsreader

3.5 Response control

   This header is meant to indicate     Reply-To:      RFC 822: 4.4.3,
   where the sender wants replies to                   RFC 1036: 2.2.1
   go. Unfortunately, this is                          controversial.
   ambiguous, since there are
   different kinds of replies, which
   the sender may wish to go to
   different addresses. In
   particular, there are personal
   replies intended for only one
   person, and group replies,
   intended for the whole group of
   people who read the replied-to
   message (often a mailing list,
   anewsgroup name cannot appear
   here because of different syntax,
   see "Followup-To" below.).



Palme                        Informational                      [Page 9]

RFC 2076                Internet Message Headers           February 1997


   Some mail systems use this header
   to indicate a better form of the
   e-mail address of the sender.
   Some mailing list expanders puts
   the name of the list in this
   header. These practices are
   controversial. The personal
   opinion of the author of this RFC
   is that this header should be
   avoided except in special cases,
   but this is a personal opinion
   not shared by all specialists in
   the area.

   Used in Usenet News to indicate      Followup-To:   RFC 1036: 2.2.3,
   that future discussions (=follow-                   not standardized
   up) on an article should go to a                    for use in e-mail.
   different set of newsgroups than
   the replied-to article. The most
   common usage is when an article
   is posted to several newsgroups,
   and further discussions is to
   take place in only one of them.

   In e-mail, this header may occur
   in a message which is sent to
   both e-mail and Usenet News, to
   show where follow-up in Usenet
   news is wanted. The header does
   not say anything about where
   follow-up in e-mail is to be
   sent.

   Note that the value of this
   header must always be one or more
   newsgroup names, never e-mail
   addresses.

   Address to which notifications       Errors-To:,    Non-standard,
   are to be sent and a request to      Return-        discouraged.
   get delivery notifications.          Receipt-To:
   Internet standards recommend,
   however, the use of RCPT TO and
   Return-Path, not Errors-To, for
   where delivery notifications are
   to be sent.





Palme                        Informational                     [Page 10]

RFC 2076                Internet Message Headers           February 1997


   Whether non-delivery report is       Prevent-       RFC 1327, not for
   wanted at delivery error. Default    NonDelivery-   general usage.
   is to want such a report.            Report:

   Whether a delivery report is         Generate-      RFC 1327, not for
   wanted at successful delivery.       Delivery-      general usage.
   Default is not to generate such a    Report:
   report.

   Indicates whether the content of     Content-       RFC 1327, not for
   a message is to be returned with     Return:        general usage.
   non-delivery notifications.

   Possible future change of name       X400-Content-  non-standard
   for "Content-Return:"                Return:

3.6 Message identification and referral headers

   Unique ID of this message.           Message-ID:    RFC 822: 4.6.1
                                                       RFC 1036: 2.1.5.

   Unique ID of one body part of the    Content-ID:    RFC 1521: 6.1.
   content of a message.

   Base to be used for resolving        Content-Base:  Non-standard
   relative URIs within this content
   part.

   URI with which the content of        Content-       Non-standard
   this content part might be           Location:
   retrievable.

   Reference to message which this      In-Reply-To:   RFC 822: 4.6.2.
   message is a reply to.

   In e-mail: reference to other        References:    RFC 822: 4.6.3
   related messages, in Usenet News:                   RFC 1036: 2.1.5.
   reference to replied-to-articles.

   References to other related          See-Also:      Son-of-RFC1036
   articles in Usenet News.                            [21], non-standard

   Reference to previous message        Obsoletes:     RFC 1327, not for
   being corrected and replaced.                       general usage.
   Compare to "Supersedes:" below.
   This field may in the future be
   replaced with "Supersedes:".




Palme                        Informational                     [Page 11]

RFC 2076                Internet Message Headers           February 1997


   Commonly used in Usenet News in      Supersedes:    son-of-RFC1036
   similar ways to the "Obsoletes"                     [21], non-standard
   header described above. In Usenet
   News, however, Supersedes causes
   a full deletion of the replaced
   article in the server, while
   "Supersedes" and "Obsoletes" in e-
   mail is implemented in the client
   and often does not remove the old
   version of the text.

   Only in Usenet News, similar to      Article-       son-of-RFC1036
   "Supersedes:" but does not cause     Updates:       [21], non-standard
   the referenced article to be
   physically deleted.

   Reference to specially important     Article-       son-of-RFC1036
   articles for a particular Usenet     Names:         [21], non-standard
   Newsgroup.

3.7 Other textual headers

   Search keys for data base            Keywords:      RFC 822: 4.7.1
   retrieval.                                          RFC 1036: 2.2.9.

   Title, heading, subject. Often       Subject:       RFC 822: 4.7.1
   used as thread indicator for                        RFC 1036: 2.1.4.
   messages replying to or
   commenting on other messages.

   Comments on a message.               Comments:      RFC 822: 4.7.2.

   Description of a particular body     Content-       RFC 1521: 6.2.
   part of a message.                   Description:

   Organization to which the sender     Organization:  RFC 1036: 2.2.8,
   of this article belongs.                            not standardized
                                                       for use in e-mail.

   See Organization above.              Organisation:  Non-standard.

   Short text describing a longer       Summary:       RFC 1036: 2.2.10,
   article. Warning: Some mail                         not standardized
   systems will not display this                       for use in e-mail,
   text to the recipient. Because of                    discouraged.
   this, do not use this header for
   text which you want to ensure
   that the recipient gets.



Palme                        Informational                     [Page 12]

RFC 2076                Internet Message Headers           February 1997


   A text string which identifies       Content-       RFC 1327, not for
   the content of a message.            Identifier:    general usage.

3.8 Headers containing dates and times

   The time when a message was          Delivery-      RFC 1327, not for
   delivered to its recipient.          Date:          general usage.

   In Internet, the date when a         Date:          RFC 822: 5.1,
   message was written, in X.400,                      RFC 1123: 5.2.14
   the time a message was submitted.                   RFC 1036: 2.1.2.
   Some Internet mail systems also
   use the date when the message was
   submitted.

   A suggested expiration date. Can     Expires:       RFC 1036: 2.2.4,
   be used both to limit the time of                   not standardized
   an article which is not                             for use in e-mail.
   meaningful after a certain date,
   and to extend the storage of
   important articles.

   Time at which a message loses its    Expiry-Date:   RFC 1327, not for
   validity. This field may in the                     general usage.
   future be replaced by "Expires:".

   Latest time at which a reply is      Reply-By:      RFC 1327, not for
   requested (not demanded).                           general usage.

3.9 Quality information

   Can be "normal", "urgent" or "non-   Priority:      RFC 1327, not for
   urgent" and can influence                           general usage.
   transmission speed and delivery.

   Sometimes used as a priority         Precedence:    Non-standard,
   value which can influence                           controversial,
   transmission speed and delivery.                    discouraged.
   Common values are "bulk" and
   "first-class". Other uses is to
   control automatic replies and to
   control return-of-content
   facilities, and to stop mailing
   list loops.







Palme                        Informational                     [Page 13]

RFC 2076                Internet Message Headers           February 1997


   A hint from the originator to the    Importance:    RFC 1327 and
   recipients about how important a                    RFC 1911,
   message is. Values: High, normal                    experimental
   or low. Not used to control
   transmission speed.

   How sensitive it is to disclose      Sensitivity:   RFC 1327 and
   this message to other people than                   RFC 1911,
   the specified recipients. Values:                   experimental
   Personal, private, company
   confidential. The absence of this
   header in messages gatewayed from
   X.400 indicates that the message
   is not sensitive.

   Body parts are missing.              Incomplete-    RFC 1327, not for
                                        Copy:          general usage.

3.10 Language information

   Can include a code for the           Language:      RFC 1327, not for
   natural language used in a                          general usage.
   message, e.g. "en" for English.