Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


Network Working Group J. Palme Request for Comments: 2076 Stockholm University/KTH Category: Informational February 1997

                  Common Internet Message Headers

Status of this Memo

 This memo provides information for the Internet community.  This memo
 does not specify an Internet standard of any kind.  Distribution of
 this memo is unlimited.


 This memo contains a table of commonly occurring headers in headings
 of e-mail messages. The document compiles information from other RFCs
 such as RFC 822, RFC 1036, RFC 1123, RFC 1327, RFC 1496, RFC 1521,
 RFC 1766, RFC 1806, RFC 1864 and RFC 1911. A few commonly occurring
 headers which are not defined in RFCs are also included. For each
 header, the memo gives a short description and a reference to the RFC
 in which the header is defined.

Table of contents

 1. Introduction..............................................  2
 2. Use of gatewaying headers.................................  3
 3. Table of headers..........................................  3
      3.1 Phrases used in the tables..........................  3
      3.2 Trace information...................................  5
      3.3 Format and control information......................  5
      3.4 Sender and recipient indication.....................  6
      3.5 Response control....................................  9
      3.6 Message identification and referral headers......... 11
      3.7 Other textual headers............................... 12
      3.8 Headers containing dates and times.................. 13
      3.9 Quality information................................. 13
      3.10 Language information............................... 14
      3.11 Size information................................... 14
      3.12 Conversion control................................. 15
      3.13 Encoding information............................... 15
      3.14 Resent-headers..................................... 16
      3.15 Security and reliability........................... 16
      3.16 Miscellaneous...................................... 16
 4. Acknowledgments........................................... 18

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

 5. References................................................ 18
 6. Author's Address.......................................... 20
 Appendix A:
 Headers sorted by Internet RFC document in which they appear. 21
 Appendix B:
 Alphabetical index........................................... 25

1. Introduction

 Many different Internet standards and RFCs define headers which may
 occur on Internet Mail Messages and Usenet News Articles. The
 intention of this document is to list all such headers in one
 document as an aid to people developing message systems or interested
 in Internet Mail standards.
 The document contains all headers which the author has found in the
 following Internet standards: , RFC 822 [2], RFC 1036 [3], RFC 1123
 [5], RFC 1327 [7], RFC 1496 [8], RFC 1521 [11], RFC 1766 [12], RFC
 1806 [14], RFC 1864[17] and RFC 1911[20]. Note in particular that
 heading attributes defined in PEM (RFC 1421-1424) and MOSS (RFC 1848
 [16]) are not included. PEM and MOSS headers only appear inside the
 body of a message, and thus are not headers in the RFC 822 sense.
 Mail attributes in envelopes, i.e. attributes controlling the message
 transport mechanism between mail and news servers, are not included.
 This means that attributes from SMTP [1], UUCP [18] and NNTP [15] are
 mainly not covered either. Headings used only in HTTP [19] are not
 included yet, but may be included in future version of this memo. A
 few additional headers which often can be found in e-mail headings
 but are not part of any Internet standard are also included.
 For each header, the document gives a short description and a
 reference to the Internet standard or RFC, in which they are defined.
 The header names given here are spelled the same way as when they are
 actually used. This is usually American but sometimes English
 spelling.  One header in particular, "Organisation/Organization",
 occurs in e-mail headers sometimes with the English and other times
 with the American spelling.
 The following words are used in this memo with the meaning specified
 heading           Formatted text at the top of a message, ended by a
                   blank line
 header = heading  One field in the heading, beginning with a field
 field             name, colon, and followed by the field value(s)

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

 It is my intention to continue updating this document after its
 publication as an RFC. The latest version, which may be more up-to-
 date (but also less fully checked out) will be kept available for
 downloading from URL
 Please e-mail me (Jacob Palme <>) if you have noted
 headers which should be included in this memo but are not.

2. Use of gatewaying headers

 RFC 1327 defines a number of new headers in Internet mail, which are
 defined to map headers which X.400 has but which were previously not
 standardized in Internet mail. The fact that a header occurs in RFC
 1327 indicates that it is recommended for use in gatewaying messages
 between X.400 and Internet mail, but does not mean that the header is
 recommended for messages wholly within Internet mail. Some of these
 headers may eventually see widespread implementation and use in
 Internet mail, but at the time of this writing (1996) they are not
 widely implemented or used.
 Headers defined only in RFC 1036 for use in Usenet News sometimes
 appear in mail messages, either because the messages have been
 gatewayed from Usenet News to e-mail, or because the messages were
 written in combined clients supporting both e-mail and Usenet News in
 the same client. These headers are not standardized for use in
 Internet e-mail and should be handled with caution by e-mail agents.

3. Table of headers

3.1 Phrases used in the tables

 "not for general        Used to mark headers which are defined in RFC
 usage"                  1327 for use in messages from or to Internet
                         mail/X.400 gateways. These headers have not
                         been standardized for general usage in the
                         exchange of messages between Internet mail-
                         based systems.

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

 "not standardized       Used to mark headers defined only in RFC 1036
 for use in e-mail"      for use in Usenet News. These headers have no
                         standard meaning when appearing in e-mail,
                         some of them may even be used in different
                         ways by different software. When appearing in
                         e-mail, they should be handled with caution.
                         Note that RFC 1036, although generally used as
                         a de-facto standard for Usenet News, is not an
                         official IETF standard or even on the IETF
                         standards track.
 "non-standard"          This header is not specified in any of
                         referenced RFCs which define Internet
                         protocols, including Internet Standards, draft
                         standards or proposed standards. The header
                         appears here because it often appears in e-
                         mail or Usenet News. Usage of these headers is
                         not in general recommended. Some header
                         proposed in ongoing IETF standards development
                         work, but not yet accepted, are also marked in
                         this way.
 "discouraged"           This header, which is non-standard, is known
                         to create problems and should not be
                         generated. Handling of such headers in
                         incoming mail should be done with great
 "controversial"         The meaning and usage of this header is
                         controversial, i.e. different implementors
                         have chosen to implement the header in
                         different ways. Because of this, such headers
                         should be handled with caution and
                         understanding of the different possible
 "experimental"          This header is used for newly defined headers,
                         which are to be tried out before entering the
                         IETF standards track. These should only be
                         used if both communicating parties agree on
                         using them. In practice, some experimental
                         protocols become de-facto-standards before
                         they are made into IETF standards.

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

3.2 Trace information

 Used to convey the information       Return-Path:   RFC 821,
 from the MAIL FROM envelope                         RFC 1123: 5.2.13.
 attribute in final delivery, when
 the message leaves the SMTP
 environment in which "MAIL FROM"
 is used.
 Trace of MTAs which a message has    Received:      RFC 822: 4.3.2,
 passed.                                             RFC 1123: 5.2.8.
 List of MTAs passed.                 Path:          RFC 1036: 2.1.6,
                                                     only in Usenet
                                                     News, not in e-
 Trace of distribution lists          DL-Expansion-  RFC 1327, not for
 passed.                              History-       general usage.

3.3 Format and control information

 An indicator that this message is    MIME-Version:  RFC 1521: 3.
 formatted according to the MIME
 standard, and an indication of
 which version of MIME is
 Special Usenet News actions only.    Control:       RFC 1036: 2.1.6,
                                                     only in Usenet
                                                     News, not in e-
 Special Usenet News actions and a    Also-Control:  son-of-RFC1036
 normal article at the same time.                    [21], non-
                                                     standard, only in
                                                     Usenet News, not
                                                     in e-mail
 Which body part types occur in       Original-      RFC 1327, not for
 this message.                        Encoded-       general usage.

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

 Controls whether this message may    Alternate-     RFC 1327, not for
 be forwarded to alternate            Recipient:     general usage.
 recipients such as a postmaster
 if delivery is not possible to
 the intended recipient. Default:
 Whether recipients are to be told    Disclose-      RFC 1327, not for
 the names of other recipients of     Recipients:    general usage.
 the same message. This is
 primarily an X.400 facility. In
 X.400, this is an envelope
 attribute and refers to
 disclosure of the envelope
 recipient list. Disclosure of
 other recipients is in Internet
 mail done via the To:, cc: and
 bcc: headers.
 Whether a MIME body part is to be    Content-       RFC 1806,
 shown inline or is an attachment;    Disposition:   experimental
 can also indicate a suggested
 filename for use when saving an
 attachment to a file.

3.4 Sender and recipient indication

 Authors or persons taking            From:          RFC 822: 4.4.1,
 responsibility for the message.                     RFC 1123: 5.2.15-
                                                     16, 5.3.7,
 Note difference from the "From "                    RFC 1036 2.1.1
 header (not followed by ":")
 (1) This header should never         From           not standardized
 appear in e-mail being sent, and                    for use in e-mail
 should thus not appear in this
 memo. It is however included,
 since people often ask about it.

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

 This header is used in the so-
 called Unix mailbox format, also
 known as Berkely mailbox format
 or the MBOX format. This is a
 format for storing a set of
 messages in a file. A line
 beginning with "From " is used to
 separate successive messages in
 such files.
 This header will thus appear when
 you use a text editor to look at
 a file in the Unix mailbox
 format. Some mailers also use
 this format when printing
 messages on paper.
 The information in this header
 should NOT be used to find an
 address to which replies to a
 message are to be sent.
 (2) Used in Usenet News mail         From           RFC 976: 2.4 for
 transport, to indicate the path      or             use in Usenet News
 through which an article has gone    >From
 when transferred to a new host.
 Sometimes called "From_" header.
 Name of the moderator of the         Approved:      RFC 1036: 2.2.11,
 newsgroup to which this article                     not standardized
 is sent; necessary on an article                    for use in e-mail.
 sent to a moderated newsgroup to
 allow its distribution to the
 newsgroup members. Also used on
 certain control messages, which
 are only performed if they are
 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.
 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
 (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

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
 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.
 Phone number of the originator.      Phone:         Non-standard.
 Information about the client         Mail-System-   Non-standard.
 software of the originator.          Version:,
                                      Client:, X-
                                      Mailer, X-

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
 Note that the value of this
 header must always be one or more
 newsgroup names, never e-mail
 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:
 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
 URI with which the content of        Content-       Non-standard
 this content part might be           Location:
 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

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
 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.
 Can include a code for the           Content-       RFC 1766, proposed
 natural language used in a           Language:      standard.
 message, e.g. "en" for English.

3.11 Size information

 Inserted by certain mailers to       Content-       Non-standard,
 indicate the size in bytes of the    Length:        discouraged.
 message text. This is part of a
 format some mailers use when
 showing a message to its users,
 and this header should not be
 used when sending a message
 through the net. The use of this
 header in transmission of a
 message can cause several
 robustness and interoperability
 Size of the message.                 Lines:         RFC 1036: 2.2.12,
                                                     not standardized
                                                     for use in e-mail.

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

3.12 Conversion control

 The body of this message may not     Conversion:    RFC 1327, not for
 be converted from one character                     general usage.
 set to another. Values:
 Prohibited and allowed.
 Non-standard variant of              Content-       Non-standard.
 Conversion: with the same values.    Conversion:
 The body of this message may not     Conversion-    RFC 1327, not for
 be converted from one character      With-Loss:     general usage.
 set to another if information
 will be lost. Values: Prohibited
 and allowed.

3.13 Encoding information

 Format of content (character set     Content-Type:  RFC 1049,
 etc.) Note that the values for                      RFC 1123: 5.2.13,
 this header are defined in                          RFC 1521: 4.
 different ways in RFC 1049 and in                   RFC 1766: 4.1
 MIME (RFC 1521), look for the
 "MIME-version" header to
 understand if Content-Type is to
 be interpreted according to RFC
 1049 or according to MIME. The
 MIME definition should be used in
 generating mail.
 RFC 1766 defines a parameter
 "difference" to this header.
 Information from the SGML entity     Content-SGML-  non-standard
 declaration corresponding to the     Entity:
 entity contained in the body of
 the body part.
 Coding method used in a MIME         Content-       RFC 1521: 5.
 message body.                        Transfer-
 Only used with the value             Message-Type:  RFC 1327, not for
 "Delivery Report" to indicates                      general usage.
 that this is a delivery report
 gatewayed from X.400.

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

 Used in several different ways by    Encoding:      RFC 1154,
 different mail systems. Some use                    RFC 1505,
 it for a kind of content-type                       experimental.
 information, some for encoding
 and length information, some for
 a kind of boundary information,
 some in other ways.

3.14 Resent-headers

 When manually forwarding a           Resent-Reply-  RFC 822: C.3.3.
 message, headers referring to the    To:,
 forwarding, not to the original      Resent-From:,
 message.  Note: MIME specifies       Resent-
 another way of resending             Sender:,
 messages, using the "Message"        Resent-From:,
 Content-Type.                        Resent-Date:,

3.15 Security and reliability

 Checksum of content to ensure        Content-MD5:   RFC 1864, proposed
 that it has not been modified.                      standard.
 Used in Usenet News to store         Xref:          RFC 1036: 2.2.13,
 information to avoid showing a                      only in Usenet
 reader the same article twice if                    News, not in e-
 it was sent to more than one                        mail.
 newsgroup. Only for local usage
 within one Usenet News server,
 should not be sent between

3.16 Miscellaneous

 Name of file in which a copy of      Fcc:           Non-standard.
 this message is stored.
 Has been automatically forwarded.    Auto-          RFC 1327, not for
                                      Forwarded:     general usage.

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

 Can be used in Internet mail to      Discarded-     RFC 1327, not for
 indicate X.400 IPM extensions        X400-IPMS-     general usage.
 which could not be mapped to         Extensions:
 Internet mail format.
 Can be used in Internet mail to      Discarded-     RFC 1327, not for
 indicate X.400 MTS extensions        X400-MTS-      general usage.
 which could not be mapped to         Extensions:
 Internet mail format.
 This field is used by some mail      Status:         Non-standard,
 delivery systems to indicate the                     should never
 status of delivery for this                          appear in mail in
 message when stored. Common                          transit.
 values of this field are:
 U    message is not downloaded
      and not deleted.
 R    message is read or
 O    message is old but not
 D    to be deleted.
 N    new (a new message also
      sometimes is distinguished
      by not having any "Status:"
 Combinations of these characters
 can occur, such as "Status: OR"
 to indicate that a message is
 downloaded but not deleted.

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

4. Acknowledgments

 Harald Tveit Alvestrand, Ned Freed, Olle Jdrnefors, Keith Moore, Nick
 Smith and several other people have helped me with compiling this
 list.  I especially thank Ned Freed and Olle Jdrnefors for their
 thorough review and many helpful suggestions for improvements. I
 alone take responsibility for any errors which may still be in the
 An earlier version of this list has been published as part of [13].

5. References

Ref. Author, title IETF status

                                                       (July 1996)

—– ——————————————— ———– [1] J. Postel: "Simple Mail Transfer Protocol", Standard,

      STD 10, RFC 821, August 1982.                    Recommended

[2] D. Crocker: "Standard for the format of ARPA Standard,

      Internet text messages." STD 11, RFC 822,        Recommended
      August 1982.

[3] M.R. Horton, R. Adams: "Standard for Not an offi-

      interchange of USENET messages", RFC 1036,       cial IETF
      December 1987.                                   standard,
                                                       but in
                                                       reality a de-
                                                       standard for
                                                       Usenet News

[4] M. Sirbu: "A Content-Type header header for Standard,

      internet messages", RFC 1049, March 1988.        Recommended,
                                                       but can in
                                                       the future
                                                       be expected
                                                       to be
                                                       replaced by

[5] R. Braden (editor): "Requirements for Standard,

      Internet Hosts -- Application and Support",      Required
      STD-3, RFC 1123, October 1989.

[6] D. Robinson, R. Ullman: "Encoding Header Non-standard

      Header for Internet Messages", RFC 1154,
      April 1990.

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

[7] S. Hardcastle-Kille: "Mapping between Proposed

      X.400(1988) / ISO 10021 and RFC 822",  RFC       standard,
      1327 May 1992.                                   elective

[8] H. Alvestrand & J. Romaguera: "Rules for Proposed

      Downgrading Messages from X.400/88 to            standard,
      X.400/84 When MIME Content-Types are Present     elective
      in the Messages", RFC 1496, August 1993.

[9] A. Costanzo: "Encoding Header Header for Non-standard

      Internet Messages", RFC 1154, April 1990.

[10] A. Costanzo, D. Robinson: "Encoding Header Experimental

      Header for Internet Messages", RFC 1505,
      August 1993.

[11] N. Borenstein & N. Freed: "MIME (Multipurpose Draft

      Internet Mail Extensions) Part One:              Standard,
      Mechanisms for Specifying and Describing the     elective
      Format of Internet Message Bodies", RFC 1521,
      Sept 1993.

[12] H. Alvestrand: "Tags for the Identification Proposed

      of Languages", RFC 1766, February 1995.          standard,

[13] J. Palme: "Electronic Mail", Artech House Non-standard

      publishers, London-Boston January 1995.

[14] R. Troost, S. Dorner: "Communicating Experimental

      Presentation Information in Internet
      Messages: The Content-Disposition Header",
      RFC 1806, June 1995.

[15] B. Kantor, P. Lapsley, "Network News Transfer Proposed

      Protocol: "A Proposed Standard for the Stream-   standard
      Based Transmission of News", RFC 977, January

[16] 1848 PS S. Crocker, N. Freed, J. Galvin, Proposed

      S. Murphy, "MIME Object Security Services",      standard
      RFC 1848, March 1995.

[17] J. Myers, M. Rose: The Content-MD5 Header Draft

      Header, RFC 1864, October 1995.                  standard

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

[18] M. Horton, UUCP mail interchange format Not an offi-

      standard, RFC 976, Januari 1986.                 cial IETF
                                                       but in
                                                       reality a de-
                                                       standard for
                                                       Usenet News

[19] T. Berners-Lee, R. Headering, H. Frystyk: Not an official

      Hypertext Transfer Protocol -- HTTP/1.0,         IETF standard,
      RFC 1945, May 1996.                              but the defacto
                                                       standard until
                                                       the next
                                                       version is

[20] G. Vaudreuil: Voice Profile for Internet Experimental

      Mail, RFC 1911, February 1996.

[21] H. Spencer: News Article Format and Not even an

      Transmission, June 1994,                         RFC, but
      FTP://                still widely
      FTP://             used and
      This document is often referenced under the      almost a de-
      name "son-of-RFC1036".                           facto
                                                       standard for
                                                       Usenet News

6. Author's Address

 Jacob Palme                          Phone: +46-8-16 16 67
 Stockholm University/KTH             Fax: +46-8-783 08 29
 Electrum 230                         E-mail:
 S-164 40 Kista, Sweden

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

Appendix A:

 Headers sorted by Internet RFC document in which they appear.
 RFC 822
 RFC 976
 "From " (followed by space, not colon (:")

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

 RFC 1036
 RFC 1049
 RFC 1327
 Message-Type Delivery

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

 RFC 1505
 RFC 1521
 RFC 1806
 RFC 1864
 RFC 1911
 son-of-RFC1036 [21]

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

 Not Internet standard
 "From " (not followed by ":")

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

Appendix B:

 Alphabetical index
 Section Heading-header
 ------- --------------
 3.3     Also-Control
 3.3     Alternate-Recipient
 3.4     Apparently-To
 3.4     Approved
 3.6     Article-Names
 3.6     Article-Updates
 3.16    Auto-Forwarded
 3.4     bcc
 3.4     cc
         Client, see Originating-Client
 3.6     Content-Base
 3.12    Content-Conversion
 3.7     Content-Description
 3.3     Content-Disposition
 3.6     Content-ID
 3.7     Content-Identifier
 3.10    Content-Language see also Language
 3.11    Content-Length
 3.6     Content-Location
 3.15    Content-MD5
 3.4     Content-Return
 3.13    Content-SGML-Entity
 3.13    Content-Transfer-Encoding
 3.13    Content-Type
 3.3     Control
 3.12    Conversion
 3.12    Conversion-With-Loss
 3.8     Date
 3.8     Delivery-Date
         Delivery-Report, see Generate-Delivery-Report, Prevent-
         Delivery-Report, Non-Delivery-Report, Content-Type
         Description, see Content-Description
 3.16    Discarded-X400-IPMS-Extensions
 3.16    Discarded-X400-MTS-Extensions
 3.3     Disclose-Recipients
         Disposition, see Content-Disposition
 3.4     Distribution
 3.2     DL-Expansion-History-Indication
 3.13    Encoding see also Content-Transfer-Encoding
 3.4     Errors-To

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

 3.8     Expires
         Extension see Discarded-X400-IPMS-Extensions, Discarded-
 3.4     Fax
 3.16    Fcc
 3.4     Followup-To
         Forwarded, see Auto-Forwarded
 3.4     For-Comment
 3.4     For-Handling
 3.4     From
 3.4     Generate-Delivery-Report
         History, see DL-Expansion-History-Indication
         ID, see Content-ID and Message-ID
         Identifier, see Content-ID and Message-ID
 3.9     Importance
 3.6     In-Reply-To
 3.9     Incomplete-Copy
 3.7     Keywords
 3.10    Language see also Content-Language
         Length see Content-Length
 3.11    Lines
 3.4     Mail-System-Version see also X-mailer
 3.4     Mailer
         MD5 see Content-MD5
 3.6     Message-ID
 3.13    Message-Type
 3.3     MIME-Version
 3.4     Newsgroups
         Newsreader, see X-Newsreader
 3.6     Obsoletes
 3.7     Organisation
 3.7     Organization
 3.3     Original-Encoded-Information-Types
 3.4     Originating-Client
 3.2     Path
 3.4     Phone
 3.9     Precedence
 3.4     Prevent-NonDelivery-Report
 3.9     Priority
 3.2     Received
         Recipient, see To, cc, bcc, Alternate-Recipient, Disclose-
 3.6     References
 3.8     Reply-By
 3.4     Reply-To, see also In-Reply-To, References
 3.14    Resent-
         Return see also Content-Return
 3.2     Return-Path

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

 3.5     Return-Receipt-To
 3.6     See-Also
 3.4     Sender
 3.9     Sensitivity
 3.16    Status
 3.7     Subject
 3.7     Summary
 3.6     Supersedes
 3.4     Telefax
 3.4     To
         Transfer-Encoding see Content-Transfer-Encoding
         Type see Content-Type, Message-Type, Original-Encoded-
         Version, see MIME-Version, X-Mailer
 3.4     X400-Content-Return
 3.4     X-Mailer see also Mail-System-Version
 3.4     X-Newsreader
 3.15    Xref

Palme Informational [Page 27]

/data/webs/external/dokuwiki/data/pages/rfc/rfc2076.txt · Last modified: 1997/02/20 23:35 by

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki