    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.

    Abstract

       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
       below:

       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
       http://www.dsv.su.se/~jpalme/ietf-mail-attributes.pdf.

       Please e-mail me (Jacob Palme <jpalme@dsv.su.se>) 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
                               caution.

       "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
                               interpretations.

       "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-
                                                           mail.

       Trace of distribution lists          DL-Expansion-  RFC 1327, not for
       passed.                              History-       general usage.
                                            Indication:

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

       Special Usenet News actions only.    Control:       RFC 1036: 2.1.6,
                                                           only in Usenet
                                                           News, not in e-
                                                           mail.

       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.
                                            Information-
                                            Types:

    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:
       Allowed.

       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 ":")
       below.

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

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

       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-
                                            Encoding:

       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:,
                                            Resent-To:,
                                            Resent-cc:,
                                            Resent-bcc:,
                                            Resent-
                                            Message-ID:

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

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

       O    message is old but not
            deleted.

       D    to be deleted.

       N    new (a new message also
            sometimes is distinguished
            by not having any "Status:"
            header.

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

       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-
                                                             facto
                                                             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
                                                             MIME

    [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,
                                                             elective

    [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
            1986.

    [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
                                                             standard,
                                                             but in
                                                             reality a de-
                                                             facto
                                                             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
                                                             published

    [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://zoo.toronto.edu/pub/news.ps                still widely
            FTP://zoo.toronto.edu/pub/news.txt.Z             used and
                                                             partly
            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: jpalme@dsv.su.se
       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
       -------

       bcc
       cc
       Comments
       Date
       From
       In-Reply-To
       Keywords
       Message-ID
       Received
       References
       Reply-To
       Resent-
       Resent-bcc
       Resent-cc
       Resent-Date
       Resent-From
       Resent-From
       Resent-Message-ID
       Resent-Reply-To
       Resent-To
       Return-Path
       Sender
       Sender
       Subject
       To

       RFC 976
       -------

       "From " (followed by space, not colon (:")

    Palme                        Informational                     [Page 21]

    RFC 2076                Internet Message Headers           February 1997

       RFC 1036
       --------

       Approved
       Control
       Distribution
       Expires
       Followup-To
       Lines
       Newsgroups
       Organization
       Path
       Summary
       Xref

       RFC 1049
       --------

       Content-Type

       RFC 1327
       --------

       Alternate-recipient
       Auto-Forwarded
       Autoforwarded
       Content-Identifier
       Content-Return
       Conversion
       Conversion-With-Loss
       Delivery-Date
       Discarded-X400-IPMS-Extensions
       Discarded-X400-MTS-Extensions
       Disclose-Recipients
       DL-Expansion-History
       Expiry-Date
       Generate-Delivery-Report
       Importance
       Incomplete-Copy
       Language
       Message-Type Delivery
       Obsoletes
       Original-Encoded-Information-Types
       Prevent-NonDelivery-Report
       Priority
       Reply-By
       Report
       Sensitivity

    Palme                        Informational                     [Page 22]

    RFC 2076                Internet Message Headers           February 1997

       RFC 1505
       --------

       Encoding

       RFC 1521
       --------

       Content-Description
       Content-ID
       Content-Transfer-Encoding
       Content-Type
       MIME-Version

       RFC 1806
       --------

       Content-Disposition

       RFC 1864
       --------

       Content-MD5

       RFC 1911
       --------

       Importance
       Sensitivity

       son-of-RFC1036 [21]
       -------------------

       Also-Control
       Article-Names
       Article-Updates
       See-Also
       Supersedes

    Palme                        Informational                     [Page 23]

    RFC 2076                Internet Message Headers           February 1997

       Not Internet standard
       ---------------------

       Apparently-to
       Content-Base
       Content-Length
       Content-Location
       Content-SGML-Entity
       Encoding
       Errors-To
       Return-Receipt-To
       Fax
       "From " (not followed by ":")
       Telefax
       Fcc
       For-Comment
       For-Handling
       Mail-System-Version
       Mailer
       Organisation
       Originating-Client
       Phone
       Status
       Supersedes
       X400-Content-Return
       X-Mailer
       X-Newsreader

    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.7     Comments
       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-
               X400-MTS-Extensions
       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-
               Recipient
       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-
               Information-Types
               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]