Common Internet Message Header Fields

Versions: 00 01 02 03 04 05 06 07 08                                    
Network Working Group                                     Jacob Palme
Internet Draft                               Stockholm University/KTH
draft-palme-mailext-headers-05.txt                             Sweden
Category: Informational                                Date: May 2001
Revision of: RFC 2076                          Expires: November 2001

                   Common Internet Message Header Fields

                         Status of this Memo

This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups.  Note that
other groups may also distribute working documents as

Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time.  It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
"work in progress."

The list of current Internet-Drafts can be accessed at

The list of Internet-Draft Shadow Directories can be accessed at

Copyright (C) The Internet Society 2001. All Rights


This memo contains tables of commonly occurring header fields in
headings of e-mail messages. The document compiles information from
other RFCs such as RFC 822, RFC 1036, RFC 1123, RFC 2156, RFC 1496,
RFC 1766, RFC 2183, RFC 1864, RFC 2421 and RFC 2045. A few commonly
occurring header fields which are not defined in RFCs are also
included. For each header field, the memo gives a short description
and a reference to the RFC in which the header field is defined.

The latest, revised version of this document can be found at URL The version at that
URL may be more recent than the version published as an RFC.

Another list of headers can be found at URL

                   Changes since previous version

This document is a revision of RFC 2076. The following new header
fields, not included in RFC 2076, have been added:
Abuse-Reports-To:, Also-Control, Approved-By, Content-Alias, Content-
Alternative, Content-Class, Content-Conversion, Content-Features,
Content-ID, Delivered-To, Disposition-Notification-Options,
Disposition-Notification-To, Expiry-Date, For-Approval, List-Archive,
List-Digest, List-Help, List-ID, List-Owner, List-Post, List-
Software, List-Subscribe, List-Unsubscribe, List-URL, Mail-Copies-
To:, Original-Recipient, Originator, Originator-Info, Path, PICS-
Label, NNTP-Posting-Host, Posted-To:, Read-Receipt-To, Received,
Registered-Mail-Reply-Requested-By, Replaces, Return-Receipt-
Requested, Speech-Act, Translated-By. Translation-Of, User-Agent, X-
Confirm-Reading-To, X-Complaints-To:, X-Envelope-From, X-Envelope-To,
X-Face, X-List-Host, X-Listserver, X-Loop, X-MIME-Autoconverted, X-No-
Archive, X-OriginalArrivalTime, X-Priority, X-Report-Abuse-To, X-
Sender, X-X-Sender, X-UIDL, X-URL, X-URI.

                          Table of contents

      Abstract                                                       2
      Changes since previous version                                 2
1. Introduction                                                     3
2. Use of gatewaying header fields                                  5
3. Table of header fields                                           5
      3.1 Phrases used in the tables                                 5
      3.2 Trace information                                          6
      3.3 Format and control information                             7
      3.4 Sender and recipient indication                            8
      3.5 Response control                                          13
      3.6 Message identification and referral header fields         16
      3.7 Other textual header fields                               19
      3.8 Header fields containing dates and times                  19
      3.9 Quality information                                       20
      3.10 Language information                                     21
      3.11 Size information                                         21
      3.12 Conversion control                                       22
      3.13 Encoding information                                     22
      3.14 Resent-header fields                                     24
      3.15 Security and reliability                                 25
      3.16 Mailing list control                                     25
      3.17 Miscellaneous                                            26
4. Acknowledgments                                                 28
Copyright and disclaimer                                           28
5. References                                                      29
6. Author's address                                                31
Appendix A:                                                        32
Header fields sorted by Internet RFC document in which they
appear.                                                            32
      RFC 822                                                       32
      RFC 976                                                       32
      RFC 1049                                                      32
      RFC 1036                                                      33
      RFC 1123                                                      33
      RFC 2156                                                      33
      RFC 1505                                                      34
      RFC 1766                                                      34
      RFC 2183                                                      34
      RFC 1864                                                      34
      RFC 2421                                                      34
      RFC 2045                                                      34
      RFC 2110                                                      34
      RFC 2369                                                      34
      son-of-RFC1036 [21]                                           35
      draft-ietf-receipt                                            35
      World Wide Web Consortium (W3C) Recommendations               35
      Not Internet standard (as of May 2001)                        35
Appendix B: Alphabetical index                                     36

                          1. Introduction

Many different Internet standards and RFCs define header fields which
may occur on Internet Mail Messages and Usenet News Articles. The
intention of this document is to list all such header fields in one
document as an aid to people developing message systems or interested
in Internet Mail standards.

The document contains all header fields which the author has found in
the following Internet standards: RFC 822 [2], RFC 1036 [3], RFC 1123
[5], RFC 2156 [7], RFC 1496 [8], RFC 2045 [11], RFC 1766 [12], RFC
2183 [14], RFC 1864[17] and RFC 2421[20]. Note in particular that
heading attributes defined in PEM (RFC 1421-1424) and MOSS (RFC 1848
[16]) are not included. PEM and MOSS header fields only appear inside
the body of a message, and thus are not header fields 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. Some additional header fields which often can be found in
e-mail headings but are not part of any Internet standard are also

The author does not promise that this document contains a complete
list of all heading fields which are specified in any standard or
used by any mailer.

For each header field, the document gives a short description and a
reference to the Internet standard or RFC, in which they are defined.

The header field names given here are spelled the same way as when
they are actually used. This is usually American but sometimes
English spelling.  One header field in particular,
"Organisation/Organization", occurs in e-mail header fields 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 field    One field in the heading, beginning with a field
                 name, colon, and followed by the field value(s). The
                 words "heading field" and "header" are also
                 sometimes used with this meaning.

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
header fields which should be included in this memo but are not.

                  2. Use of gatewaying header fields

RFC 2156 defines a number of new header fields in Internet mail,
which are defined to map header fields which X.400 has but which were
previously not standardized in Internet mail. The fact that a header
field occurs in RFC 2156 indicates that it is recommended for use in
gatewaying messages between X.400 and Internet mail, but does not
mean that the header field is recommended for messages wholly within
Internet mail. Some of these header fields may eventually see
widespread implementation and use in Internet mail, but at the time
of this writing (2001) they are not widely implemented or used.

Header fields 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 header fields are not standardized for
use in Internet e-mail and should be handled with caution by e-mail

                       3. Table of header fields

**** 3.1 Phrases used in the tables

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

"not standardized       Used to mark header fields defined only in RFC
for use in e-mail"      1036 for use in Usenet News. These header
                         fields 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 field is not specified in any of
                         referenced RFCs which define Internet
                         protocols, including Internet Standards, draft
                         standards or proposed standards. The header
                         field appears here because it often appears in
                         e-mail or Usenet News. Usage of these header
                         fields is not in general recommended. Some
                         header field proposed in ongoing IETF
                         standards development work, but not yet
                         accepted, are also marked in this way.

"discouraged"           This header field, which is non-standard, is
                         known to create problems and should not be
                         generated. Handling of such header fields in
                         incoming mail should be done with great

"controversial"         The meaning and usage of this header field is
                         controversial, i.e. different implementors
                         have chosen to implement the header field in
                         different ways. Because of this, such header
                         fields should be handled with caution and
                         understanding of the different possible

"experimental"          This header field is used for newly defined
                         header fields, 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.

**** 3.2 Trace information

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

List of MTAs passed.                 Path:           RFC 1036: 2.1.6,
                                                      only in Usenet
                                                      News, not in e-

Trace of MTAs which a message has    Received:       RFC 822: 4.3.2,
passed.                                              RFC 1123: 5.2.8.

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.

The netnews host, to which this      NNTP-Posting-   Non-standard,
article was originally posted.       Host:           common in netnews
Useful for finding the sender of
spams. Since this header is added
by the news server, it is a
little more difficult to forge
than other header fields.

**** 3.3 Format and control information

Special Usenet News commands and     Also-Control:   son-of-RFC1036
a normal article at the same                         [21], non-
time.                                                standard, only in
                                                      Usenet News, not
                                                      in e-mail

Controls whether this message may    Alternate-      RFC 2156, 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 a MIME body part is to be    Content-        RFC 2183,
shown inline or is an attachment;    Disposition:    experimental
can also indicate a suggested
filename for use when saving an
attachment to a file.

Can have the values "voice-          Message-        Non-standard
message", "fax-message", "pager-     Context:
message", "multimedia-message",
"text-message", "none"

Only in Usenet News, contains        Control:        RFC 1036: 2.1.6,
commands to be performed by News                     only in Usenet
agents.                                              News, not in e-

Whether recipients are to be told    Disclose-       RFC 2156, 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: header fields.

An indicator that this message is    MIME-Version:   RFC 2045: 4.
formatted according to the MIME
standard, and an indication of
which version of MIME is

Which body part types occur in       Original-       RFC 2156, not for
this message.                        Encoded-        general usage.

**** 3.4 Sender and recipient indication

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

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.

Name of the moderator of a           Approved-By:    Non-standard, used
mailing list, and who has                            by some mailing
approved this message for                            list expansion
distribution to the members of                       systems.
the list.
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.

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

Geographical or organizational       Distribution:   RFC 1036: 2.2.7,
limitation on where this article                     not standardized
can be distributed. Value can be                     for use in e-mail.
a compete or incomplete domain
names, also various special
values are accepted like "world",
"usenet", "USA", etc.

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

Primary recipients, who are          For-Approval:   Non-standard
requested to approve 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.

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

(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.      (not followed
                                      by a colon)
Sometimes called "From_" header

(1) This header field should         From (not       not standardized
never appear in e-mail being         followed by a   for use in e-mail
sent, and should thus not appear     colon)
in this memo. It is however
included, since people often ask
about it.

This header field 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 field 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
field should NOT be used to find
an address to which replies to a
message are to be sent.

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 field (not followed by
":") below.

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

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
field also in e-mail although it                     for use in e-mail.
is not standardized there.
Unfortunately, the header field
can appear in e-mail with three
different and contradictory

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

(b) In a message adressed to some
mail to news gateways, indicates
the newsgroup(s) that the message
is to be posted to.

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

See also: "Posted-To:".

Sometimes used in Usenet News in     Originator:     Non-standard in
similar ways to "Sender:"                            Usenet News,
                                                      Experimental in
Also used in printing protocols.                     RFC 1528.

Contains information about the       Originator-     Non-standard [25]
authentication of the originator     Info:
in a format which is not easily
used to send email to, to avoid
the problems with "Sender" and "X-

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

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, RFC
header field. Should be                              1036.
according to RFC 822, but what
kind of authentication is not
clear. Some implementations
expect that the e-mail address
used in this field can be used to
reach the sender, others do not.
See also "X-Sender".

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

If the sender in the envelope        X-Envelope-     Non-standard.
(SMTP "RCTP TO") is not the same     From:
as the senders in the "From" or
"Sender" RFC822 header fields,
some mail servers add this to the
RFC822 header fields as an aid to
clients which would otherwise not
be able to display this

If the recipient in the envelope     X-Envelope-     Non-standard.
(SMTP "MAIL FROM") is not            To:,
included in the CC list, some        Envelope-To:
mail servers add this to the
RFC822 header field as an aid to
clients which would otherwise not
be able to display the envelope

48x48 bitmap with picture of the     X-Face:         Non-Standard
sender of this message.

Indication in the mail header of     X-RCPT-TO:      Non-standard
recipient on the SMTP envelope.

Some mail software expect            X-Sender:       Non-standard
"Sender:" to be an e-mail address
which you can send mail to.
However, some mail software has
as the best authenticated sender
a POP or IMAP account, which you
might not be able to send to.
Because of this, some mail
software put the POP or IMAP
account into an X-sender header
field instead of a Sender header
field, to indicate that you may
not be able to send e-mail to
this address. See also "X-X-

Another use of" X-Sender:" is
that some e-mail software, which
wants to insert a "Sender:"
header, will first change an
existing "Sender:" header to "X-
Sender". This use is actually
often the same as that described
in the previous paragraph, since
the new "Sender:" is added
because it is better
authenticated than the old value.

Even though some systems put the     X-X-Sender:     Non-standard
POP or IMAP account name into the
"X-Sender:" instead of the Sender
header field, some mail software
tries to send to the "X-Sender:"
too. To stop this, some systems
have begun to use "X-X-Sender:"
to indicate an authentication of
the sender which might not be
useable to send e-mail to. See
also "Originator-Info:"

When a message is sent both to       Posted-To:      Non-standard
netnews and e-mail, this header
is used in the e-mail version of
the message to indicate which
newsgroup it was sent to. This
header thus contains the same
information as the "Newsgroups:"
header in the netnews version of
the message.

E-mail address of administrator      X-Admin:        Non-standard
of a server, through which this
message was submitted.

**** 3.5 Response control

Indicates whether the content of     Content-        RFC 2156, not for
a message is to be returned with     Return:         general usage.
non-delivery notifications.
For future options on disposition    Disposition-    RFC 2298
notifications.                       Notification-

Indicate that the sender wants a     Disposition-    RFC 2298
dispoisition notification when       Notification-
this message is received (read,      To:
processed, etc.) by its

Address to which notifications       Errors-To:,     Non-standard,
are to be sent and a request to      Return-         discouraged, some
get delivery notifications.          Receipt-To:,    of them widely
Internet standards recommend,        Read-Receipt-   used.
however, the use of MAIL FROM and    To:, X-
Return-Path, not Errors-To, for      Confirm-
where delivery notifications are     reading-to:,
to be sent.                          Return-

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 field 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 field
does not say anything about where
follow-up in e-mail is to be

The value of this header field
should be one or more newsgroup

The special value "poster" as in
"Followup-To: poster" means that
replies are to be sent as e-mail
to the author only.

Whether a delivery report is         Generate-       RFC 2156, not for
wanted at successful delivery.       Delivery-       general usage.
Default is not to generate such a    Report:
Original Recipient information       Original-       RFC 2298
for inclusion in disposition         Recipient

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

This header field is meant to        Reply-To:       RFC 822: 4.4.3,
indicate where the sender wants                      RFC 1036: 2.2.1
replies to go. Unfortunately,                        controversial.
this is 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.).

Some mail systems use this header    Reply-To2
field 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 field. These
practices are controversial. The
personal opinion of the author of
this RFC is that this header
field should be avoided except in
special cases, but this is a
personal opinion not shared by
all specialists in the area.

Indicates where to send complains    Abuse-Reports-  non-standard
if you get a message which you       To:, X-
think is against the laws or         Complaints-
rules.                               To:, X-Report-

Used in netnews articles to          Mail-Copies-    non-standard, but
indicate that followup (=replies)    To:             commonly supported
should be sent to the indicated e-                   by newsreaders
mail address.
Possible future change of name       X400-Content-   non-standard
for "Content-Return:"                Return:

**** 3.6 Message identification and referral header fields

Reference to specially important     Article-        son-of-RFC1036
articles for a particular Usenet     Names:          [21], non-standard
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.

Used in addition to Content-         Content-        Work in progress
Location if this content part can    Alias:
be retrieved through more than
one URI. Only one of them is
allowed in the Content-Location,
the other can be specified in

Base to be used for resolving        Content-Base:   RFC 2110
relative URIs within this content

Unique ID of one body part of the    Content-ID:     RFC 2045: 7.
content of a message.
URI with which the content of        Content-        RFC 2110
this content part might be           Location:
Used by some automatic services      Delivered-To:   non-standard
(mainly MLMs and autoresponders)     or
for the purpose of loop              X-Loop:
detection. The service adds the
Delivered-To header to outgoing
messages, with its e-mail address
as a value, and discards incoming
messages which already have it.

Reference to message which this      In-Reply-To:    RFC 822: 4.6.2.
message is a reply to.
Unique ID of this message.           Message-ID:     RFC 822: 4.6.1
                                                      RFC 1036: 2.1.5.

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

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.
Still another name for similar       Replaces:       non-standard,
functionality as for "Obsoletes:"                    proposed in IETF
and "Supersedes:". This may                          USEFOR working
become the most recommended                          group
header in the future, but is
still under discussion in IETF
standards development work.

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

Commonly used in Usenet News in      Supersedes:     son-of-RFC1036
similar ways to the "Obsoletes"                      [21], non-standard
header field 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.

Mailbox of the person who made       Translated-     non-standard
the translation.                     By:

Reference to the Message-ID of a     Translation-    non-standard
message, which the current           Of:
message is a translation of.

Unique identifier for a message,     X-UIDL:         non-standard
local to a particular local
mailbox store. The UIDL
identifier is defined in the POP3
standard, but not the "X-UIDL:"

Similar usage as "X-URL". The URI    X-URI:          Non-standard
can be either a URL or a URN.
URNs are meant to become more
persistent references to
resources than URLs.

Sometimes used with the same         X-URL:          Non-standard
meaning as "Content-Location:",
sometimes to indicate the web
home page of the sender or of his

The UID, as defined in the IMAP      X-IMAP:         Non-standard
standard. Only used in internal
mailbox storage in some mail
systems, should never be visible
to a user.

**** 3.7 Other textual header fields

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

Description of a particular body     Content-        RFC 2045: 8.
part of a message, for example a     Description:
caption for an image body part.
A text string which identifies       Content-        RFC 2156, not for
the content of a message.            Identifier:     general usage.

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

See Organization above.              Organisation:   Non-standard.

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

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.

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
field for text which you want to
ensure that the recipient gets.

**** 3.8 Header fields containing dates and times

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

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

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 2156, 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 2156, not for
requested (not demanded).                            general usage.

Time when this message was           X-OriginalArr   Non-standard
delivered into the message           ivalTime:
transport system (usually the
same time as in the last
"Received:" header)

**** 3.9 Quality information

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

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

Ratings label to control             PICS-Label:     REC-PICS-labels,
selection (filtering) of messages                    W3C document [23].
according to the PICS protocol.
Sometimes used as a priority         Precedence:     Non-standard,
value which can influence                            controversial,
transmission speed and delivery.                     widely used.
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.

Can be "normal", "urgent" or "non-   Priority:       RFC 2156, not for
urgent" and can influence                            general usage.
transmission speed and delivery.
How sensitive it is to disclose      Sensitivity:    RFC 2156 and
this message to other people than                    RFC 2421, proposed
the specified recipients. Values:
Personal, private, company
confidential. The absence of this
header field in messages
gatewayed from X.400 indicates
that the message is not

Yet another priority indication.     X-MSMail-       Non-standard

Values: 1 (Highest), 2 (High), 3     X-Priority:     Non-standard [24]
(Normal), 4 (Low), 5 (Lowest). 3
(Normal) is default if the field
is omitted.

**** 3.10 Language information

Can include a code for the           Content-        RFC 1766, proposed
natural language used in a           Language:       standard.
message, e.g. "en" for English.
Can include a code for the           Language:       RFC 2156, not for
natural language used in a                           general usage.
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 field should not
be used when sending a message
through the net. The use of this
header field 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.

**** 3.12 Conversion control

Information on where an              Content-        Non-standard [27].
alternative variant of this          Alternative:
document might be found.
Non-standard variant of              Content-        Non-standard.
Conversion: with the same values.    Conversion:

The body of this message may not     Conversion:     RFC 2156, not for
be converted from one character                      general usage.
set to another. Values:
Prohibited and allowed.

The body of this message may not     Conversion-     RFC 2156, 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

Type information of the content      Content-        non-standard
in some class hierarchy. Class       Class:
hierarchies are commonly used to
classify data structures in
software development.

Can give more detailed               Content-        Proposed Standard,
information about the Content-       Features:       RFC 2912
Type. Example:

   (& (Type="image/tiff")
   (image-coding=MH) (MRC-mode=0)
   (ua-media=stationery) )

This header is meant to be used
when you can choose between
different versions of a resource,
such as when using

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 2045: 6.
message body.                        Transfer-

Format of content (character set     Content-Type:   RFC 1049,
etc.) Note that the values for                       RFC 1123: 5.2.13,
this header field are defined in                     RFC 1766: 4.1
different ways in RFC 1049 and in                    RFC 2045: 5.
MIME (RFC 2045), look for the
"MIME-version" header field 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 1049 has
"historic" status.

RFC 1766 defines a parameter
"difference" to this header

Various other Content-Type define
various additional parameters.
For example, the parameter
"charset" is mandatory for all
textual Content-Types.

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.

Only used with the value             Message-Type:   RFC 2156, not for
"Delivery Report" to indicates                       general usage.
that this is a delivery report
gatewayed from X.400.

Information about conversion of      X-MIME-         non-standard
this message on the path from        Autoconverted:
sender to recipient, like
conversion between MIME encoding
formats. Note: Auto-conversion
may invalidate digital seals and

**** 3.14 Resent-header fields

When manually forwarding a           Resent-Reply-   RFC 822: C.3.3.
message, header fields referring     To:,
to the forwarding, not to the        Resent-From:,
original message.  Note: MIME        Resent-
specifies another way of             Sender:,
resending messages, using the        Resent-From:,
"Message" 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 Mailing list control

Contains URL to use to browse the    List-Archive:   RFC 2369 [26]
archives of the mailing list from
which this message was relayed.

URL to use to get a subscription     List-Digest:    Non-standard
to the digest version of the
mailing list from which this
message was relayed.

Contains URL to use to get a         List-Help:      RFC 2369 [26]
information about the mailing
list from which this message was

Stores an identification of the      List-ID:        RFC 2919 [27].
mailing list, through which this
message was distributed.

Non-standard precursors to List-     Mailing-        Non-standard
ID and List-Post.                    List:, X-

Contains URL to send e-mail to       List-Owner:     RFC 2369 [26]
the owner of the mailing list
from which this message was

Contains URL to use to send          List-Post:      RFC 2369 [26]
contributions to the mailing list
from which this message was

Information about the software       List-           Non-standard, has
used in a mailing list expander      Software:       been considered
through which this message has                       for inclusion in
passed.                                              [26].

Contains URL to use to get a         List-           RFC 2369 [26]
subscription to the mailing list     Subscribe:
from which this message was

Contains URL to use to               List-           RFC 2369 [26]
unsubscribe the mailing list from    Unsubscribe:
which this message was relayed.

Contains URL where information of    List-URL:       Non-standard
various kinds about the mailing
list from which this message was

Information about the server and     X-              Non-standard.
software used in a mailing list      Listserver:,    Recommended to use
expander through which this          X-List-Host:    "List-Software"
message has passed. Warning:                         instead.
"Listserv" is a trademark and
should not be used for other than
the "Listserv" product. Use,
instead the "List-Software"
header field.

**** 3.17 Miscellaneous

Has been automatically forwarded.    Autoforwarded   RFC 2156, not for
                                      :               general usage.

Can be used in Internet mail to      Discarded-      RFC 2156, 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 2156, not for
indicate X.400 MTS extensions        X400-MTS-       general usage.
which could not be mapped to         Extensions:
Internet mail format.
Name of file in which a copy of      Fcc:            Non-standard.
this message is stored.
Speech act categoriztion of a        Speech-Act:     Non-standard
message, examples of speeach acts
are Question, Idea, More,
Promise, Sad, Happy, Angry,
summary, Decision
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:"
      header field.

Combinations of these characters
can occur, such as "Status: OR"
to indicate that a message is
downloaded but not deleted.

Do not archive this message in       X-No-Archive:   Non-standard
publicly available archives.         Yes

                           4. Acknowledgments

Harald Tveit Alvestrand, Neil Carpenter, William C. Carpenter, Rob
Chandhok, Ned Freed, Olle J„rnefors, Jukka Korpela, Usi Paz, Martin
Platt, Keith Moore, Robert A. Rosenberg, Mark Symons, Nick Smith
Michael C. Tiernan and several other people have helped me with
compiling this list. I especially thank Ned Freed and Olle J„rnefors
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].

                  Copyright and disclaimer

The IETF takes no position regarding the validity or scope
of any intellectual property or other rights that might be
claimed to pertain to the implementation or use of the
technology described in this document or the extent to
which any license under such rights might or might not be
available; neither does it represent that it has made any
effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track
and standards-related documentation can be found in BCP-11.
Copies of claims of rights made available for publication
and any assurances of licenses to be made available, or the
result of an attempt made to obtain a general license or
permission for the use of such proprietary rights by
implementors or users of this specification can be obtained
from the IETF Secretariat."

The IETF invites any interested party to bring to its
attention any copyrights, patents or patent applications,
or other proprietary rights which may cover technology that
may be required to practice this standard. Please address
the information to the IETF Executive Director.

Copyright (C) The Internet Society (date). All Rights

This document and translations of it may be copied and
furnished to others, and derivative works that comment on
or otherwise explain it or assist in its implmentation may
be prepared, copied, published and distributed, in whole or
in part, without restriction of any kind, provided that the
above copyright notice and this paragraph are included on
all such copies and derivative works. However, this
document itself may not be modified in any way, such as by
removing the copyright notice or references to the Internet
Society or other Internet organizations, except as needed
for the purpose of developing Internet standards in which
case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to
translate it into languages other than English.

The limited permissions granted above are perpetual and
will not be revoked by the Internet Society or its
successors or assigns.

                             5. References

Ref.    Author, title                                    IETF status
                                                          (May 2001)
-----   ---------------------------------------------    -----------
[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 field header    Historic
         field for internet messages", RFC 1049, March

[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
         field for Internet Messages", RFC 1505,
         August 1993.

[7]     S. Hardcastle-Kille: "Mapping between            Proposed
         X.400(1988) / ISO 10021 and RFC 822",  RFC       standard,
         2156 January 1998.                               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 field Header       Non-standard
         field for Internet Messages", RFC 1154, April

[10]    A. Costanzo, D. Robinson: "Encoding Header       Experimental
         field Header field for Internet Messages",
         RFC 1505, August 1993.

[11]    N. Freed & N. Borenstein: "MIME (Multipurpose    Draft
         Internet Mail Extensions) Part One: Format of    Standard,
         Internet Message Bodies. RFC 2045. November      elective

[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
         field", RFC 2183, 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
         field Header field, RFC 1864, October 1995.      standard

[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. Header fielding, H.           Informatio
         Frystyk: Hypertext Transfer Protocol --          nal
         HTTP/1.0, RFC 1945.

[20]    G. Vaudreuil: Voice Profile for Internet         Proposed
         Mail, RFC 2421 Feburary 1998.

[21]    H. Spencer: News Article Format and              Not even an
         Transmission, June 1994,                         RFC, but
         FTP://              still widely
         FTP://             used and
                                                          partly almost
         This document is often referenced under the      a de-facto
         name "son-of-RFC1036".                           standard for
                                                          Usenet News

[23]    PICS Label Distribution Label Syntax and         Other
         Communication Protocols, World Wide Web          standard
         Consortium, October 1996.

[24]    Eudora Pro Macintosh User Manual, Qualcomm       Non-standard
         Inc., 1988-1995.

[25]    C. Newman: Originator-Info Message Header        Non-standard
         field. work in progress, July 1997.

[26]    Grant Neufeld and Joshua D. Baer: The Use of     Proposed
         URLs as Meta-Syntax for Core Mail List           standard
         Commands and their Transport through Message
         Header fields, RFC 2369, July 1998.

[27]    G. Klyne (ed.): Content Negotiation for          Non-standard
         Facsimile Using Internet Mail, Work in
         progress, March 2000.

[27]    R. Chandhok, G. Wenger: List-IDE: A              Proposed
         Structured Field and Namespace for the           standard
         Identification if Mailing Lists, RFC 2919,
         March 2001.

                           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

                              Appendix A:
Header fields sorted by Internet RFC document in which they appear.

RFC 822


RFC 976

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

RFC 1049


RFC 1036


RFC 1123


RFC 2156

Auto-forwarded see Autoforwarded

RFC 1505


RFC 1766


RFC 2183


RFC 1864


RFC 2045


RFC 2110


RFC 2298


RFC 2369


RFC 2421


son-of-RFC1036 [21]


RFC 2912


RFC 2919:


World Wide Web Consortium (W3C) Recommendations


Not Internet standard (as of May 2001)

"From " (not followed by ":")

                    Appendix B: Alphabetical index

Section Header field
------- ------------

3.5     Abuse-Reports-To
3.3     Also-Control
3.3     Alternate-Recipient
3.4     Apparently-To
3.4     Approved
3.4     Approved-By
3.6     Article-Names
3.6     Article-Updates
         Auto-Forwarded see Autoforwarded
3.17    Autoforwarded
3.4     bcc
3.4     cc
         Client, see Originating-Client
         Comment, see For-Comment
3.6     Content-Alias
3.12    Content-Alternative
3.6     Content-Base
3.13    Content-Class
3.12    Content-Conversion
3.7     Content-Description
3.3     Content-Disposition
3.13    Content-Features
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
         Copy, see Incomplete-Copy
3.8     Date, see also Delivery-Date, Received, Expires, Expiry-
3.6     Delivered-To
3.8     Delivery-Date
         Delivery-Report, see Generate-Delivery-Report, Prevent-
         Delivery-Report, Non-Delivery-Report, Content-Type
         Description, see Content-Description
3.17    Discarded-X400-IPMS-Extensions
3.17    Discarded-X400-MTS-Extensions
3.3     Disclose-Recipients
         Disposition, see also Content-Disposition
3.5     Disposition-Notification-Options
3.5     Disposition-Notification-To
3.4     Distribution
3.2     DL-Expansion-History
3.13    Encoding see also Content-Transfer-Encoding
3.4     Errors-To
3.8     Expires
3.8     Expiry-Date
         Extension see Discarded-X400-IPMS-Extensions, Discarded-
3.4     Fax see also Telefax
3.17    Fcc
3.4     Followup-To
3.4     For-Approval
3.4     For-Comment
3.4     For-Handling
         Forwarded, see Autoforwarded
3.4     From (not followed by (":" or preceded by ">")
3.4     From (followed by ":")
3.4     Generate-Delivery-Report
         Handling, see For-Handling
         History, see DL-Expansion-History
         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
         Label, see PICS-Label
3.10    Language see also Content-Language
         Length see Content-Length
3.11    Lines
3.16    List-Archive
3.16    List-Digest
3.16    List-Help
3.16    List-ID
3.16    List-Owner
3.16    List-Post
3.16    List-Software
3.16    List-Subscribe
3.16    List-URL
3.16    List-Unsubscribe
         Loss, see Conversion-With-Loss
3.16    Mailing-List, see also X-Mailing-List
3.5     Mail-Copies-To
3.4     Mail-System-Version see also X-mailer
3.4     Mailer
         MD5 see Content-MD5
3.3     Message-Context
3.6     Message-ID
3.13    Message-Type
3.3     MIME-Version
3.4     Newsgroups
         Newsreader, see X-Newsreader
3.3     NNTP-Posting-Host
3.6     Obsoletes
3.7     Organisation
3.7     Organization
3.3     Original-Encoded-Information-Types
3.6     Original-Recipient
3.4     Originating-Client
3.4     Originator
3.4     Originator-Info see also Sender
3.2     Path
3.4     Phone
3.9     PICS-Label
3.4     Posted-To
3.9     Precedence
3.4     Prevent-NonDelivery-Report
3.9     Priority
3.5     Read-Reciept-To
3.2     Received
         Recipient, see To, cc, bcc, Alternate-Recipient, Disclose-
3.6     References
3.5     Registered-Mail-Reply-Requested-By
3.6     Replaces
3.8     Reply-By
3.4     Reply-To, see also In-Reply-To, References
3.14    Resent-
         Return see Content-Return
3.2     Return-Path
3.5     Return-Receipt-Requested
3.5     Return-Receipt-To
3.6     See-Also
3.4     Sender
3.9     Sensitivity
3.17    Speech-Act
3.17    Status
3.7     Subject
3.7     Summary
3.6     Supersedes
3.4     Telefax see also Fax
3.4     To
         Transfer-Encoding see Content-Transfer-Encoding
3.6     Translated-By
3.6     Translation-Of
         Type see Content-Type, Message-Type, Original-Encoded-
3.4     User-Agent
         Version, see MIME-Version, X-Mailer
3.4     X-Admin
3.4     X-Complaints-To
3.5     X-Confirm-Reading-To
3.4     X-Envelope-From
3.4     X-Envelope-To
3.4     X-Face
3.6     X-IMAP
3.16    X-List-Host
3.16    X-Listserver
3.6     X-Loop
3.16    X-Mailing-List, see also Mailing-List
3.4     X-Mailer see also Mail-System-Version
3.13    X-MIME-Autoconverted
3.4     X-MimeOLE
3.9     X-MSMail-Priority
3.4     X-Newsreader
3.17    X-No-Archive
3.8     X-OriginalArrivaltime
3.9     X-Priority
3.4     X-Report-Abuse-To
3.4     X-RCPT-TO
3.4     X-Sender see also Originator-Info
3.6     X-UIDL
3.6     X-URI
3.6     X-URL see also Content-Location
3.4     X-X-Sender see also Originator-Info
3.4     X400-Content-Return
3.15    Xref