[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07 08                                    
Network Working Group                                       Jacob Palme
Internet Draft                                 Stockholm University/KTH
Category: Informational                              Date: January 1998
Revision of: RFC 2076                                Expires: July 1998

                  Common Internet Message Header Fields

                        Status of this Memo


  This document is an Internet-Draft.  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.

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

  To learn the current status of any Internet-Draft, please check
  the ``1id-abstracts.txt'' listing contained in the Internet-
  Drafts Shadow Directories on ftp.is.co.za (Africa),
  nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
  ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).

  This memo provides information for the Internet community. This
  memo does not specify an Internet standard of any kind, since
  this document is mainly a compilation of information taken from
  other RFCs.. Distribution of this memo is unlimited.

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


This memo contains a table 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 1327, RFC 1496, RFC
2045, RFC 1766, RFC 1806, RFC 1864 and RFC 1911. 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.

This document is a revision of RFC 2076. The following new header
fields, not included in RFC 2076, have been added: Content-Alias,
Disposition-Notification-Options, Disposition-Notification-To, Expiry-
Date, For-Approval, List-Archive, List-Help, List-ID, List-Owner, List-
Post, List-Software, List-Subscribe, List-Unsubscribe, Original-
Recipient, PICS-Label, X-Envelope-From, X-Envelope-To, X-List-Host, X-
Listserver, X-MIME-Autoconverted, X-No-Archive, X-Priority, X-UIDL.

                         Table of contents

1. Introduction
2. Use of gatewaying header fields
3. Table of header fields
     3.1 Phrases used in the tables
     3.2 Trace information
     3.3 Format and control information
     3.4 Sender and recipient indication
     3.5 Response control
     3.6 Message identification and referral header fields
     3.7 Other textual header fields
     3.8 Header fields containing dates and times
     3.9 Quality information
     3.10 Language information
     3.11 Size information
     3.12 Conversion control
     3.13 Encoding information
     3.14 Resent-header fields
     3.15 Security and reliability
     3.16 Mailing list control
     3.17 Miscellaneous
4. Acknowledgments
5. References
6. Author's address
Appendix A: Header fields sorted by Internet RFC document in
which they appear.
Appendix B: Alphabetical index

                         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 1327 [7], RFC 1496 [8], RFC 2045 [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 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 included.

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 <jpalme@dsv.su.se>) if you have noted
header fields which should be included in this memo but are not.

                 2. Use of gatewaying header fields

RFC 1327 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 1327 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 (1996) 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 agents.

                      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 1327 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

Used to convey the information       Return-Path:    RFC 821,
from the MAIL FROM envelope                          RFC 1123: 5.2.13.
attribute in final delivery, when
the message leaves the SMTP
environment in which "MAIL FROM"
is used.

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

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

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

3.3 Format and control information

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

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-

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

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

Controls whether this message may    Alternate-      RFC 1327, not for
be forwarded to alternate            Recipient:      general usage.
recipients such as a postmaster
if delivery is not possible to
the intended recipient. Default:

Whether recipients are to be told    Disclose-       RFC 1327, not for
the names of other recipients of     Recipients:     general usage.
the same message. This is
primarily an X.400 facility. In
X.400, this is an envelope
attribute and refers to
disclosure of the envelope
recipient list. Disclosure of
other recipients is in Internet
mail done via the To:, cc: and
bcc: header fields.

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

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

(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

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 field. Should be
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".

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

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-

Primary recipients.                  To:             RFC 822: 4.5.1,
                                                     RFC 1123: 5.2.15-
                                                     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.

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.

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

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

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

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

Geographical or organizational       Distribution:   RFC 1036: 2.2.7,
limitation on where this article                     not standardized
can be distributed. 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.

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

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

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

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

3.5 Response control

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

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

Note that the value of this
header field 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.

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

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

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

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

Indicate that the sender wants a     Disposition-    draft-ietf-receipt-
dispoisition notification when       Notification-   03.txt (standard
this message is received (read,      To              to be)
processed, etc.) by its

For future options on disposition    Disposition-    draft-ietf-receipt-
notifications.                       Notification-   03.txt (standard
                                     Options         to be)

Original Recipient information       Original-       draft-ietf-receipt-
for inclusion in disposition         Recipient       03.txt (standard
notifications.                                       to be)

3.6 Message identification and referral header fields

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 2045: 7.
content of a message.

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

URI with which the content of        Content-        RFC 2110
this content part might be           Location:

Used in addition to Content-         Content-        Internet draft
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

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

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

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.

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

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

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

3.7 Other textual header fields

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 2045: 8.
part of a message, for example a     Description:
caption for an image body part.

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

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

3.8 Header fields containing dates and times

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

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

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

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

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

3.9 Quality information

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

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.

Sometimes used as a priority         Precedence:     Non-standard,
value which can influence                            controversial.
transmission speed and delivery.
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.

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 field in messages
gatewayed from X.400 indicates
that the message is not

Body parts are missing.              Incomplete-     RFC 1327, 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.

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

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 field are defined in                     RFC 2045: 5.
different ways in RFC 1049 and in                    RFC 1766: 4.1
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 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 2045: 6.
message body.                        Transfer-

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

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.

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 get a         List-           Non-standard [26]
subscription to the mailing list     Subscribe
from which this message was

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

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

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

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

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

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

Stores the URN of the mailing        List-ID         Non-standard, has
list, through which this message                     been considered
was distributed.                                     for inclusion in

Information about the software       X-Listserver    Non-standard.
used in a mailing list expander
through which this message has
passed. Warning: "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

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.

Can be used in Internet mail to      Discarded-      RFC 1327, not for
indicate X.400 IPM extensions        X400-IPMS-      general usage.
which could not be mapped to         Extensions:
Internet mail format.

Can be used in Internet mail to      Discarded-      RFC 1327, not for
indicate X.400 MTS extensions        X400-MTS-       general usage.
which could not be mapped to         Extensions:
Internet mail format.

This field is used by some mail      Status:         Non-standard,
delivery systems to indicate the                     should never
status of delivery for this                          appear in mail in
message when stored. Common                          transit.
values of this field are:

U    message is not downloaded
     and not deleted.

R    message is read or

O    message is old but not

D    to be deleted.

N    new (a new message also
     sometimes is distinguished
     by not having any "Status:"
     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, Ned Freed, Olle Järnefors, Keith Moore, Nick
Smith 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].

                            5. References

Ref.    Author, title                                    IETF status
                                                         (July 1996)
-----   ---------------------------------------------    -----------
[1]     J. Postel: "Simple Mail Transfer Protocol",      Standard,
        STD 10, RFC 821, August 1982.                    Recommended

[2]     D. Crocker: "Standard for the format of ARPA     Standard,
        Internet text messages." STD 11, RFC 822,        Recommended
        August 1982.

[3]     M.R. Horton, R. Adams: "Standard for             Not an offi-
        interchange of USENET messages", RFC 1036,       cial IETF
        December 1987.                                   standard,
                                                         but in
                                                         reality a de-
                                                         standard for
                                                         Usenet News

[4]     M. Sirbu: "A Content-Type header field header    Standard,
        field for internet messages", RFC 1049, March    Recommended,
        1988.                                            but can in
                                                         the future
                                                         be expected
                                                         to be
                                                         replaced by

[5]     R. Braden (editor): "Requirements for            Standard,
        Internet Hosts -- Application and Support",      Required
        STD-3, RFC 1123, October 1989.

[6]     D. Robinson, R. Ullman: "Encoding Header         Non-standard
        field Header field for Internet Messages",
        RFC 1154, April 1990.

[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 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 2945. 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 1806, June 1995.

[15]    B. Kantor, P. Lapsley, "Network News Transfer    Proposed
        Protocol: "A Proposed Standard for the Stream-   standard
        Based Transmission of News", RFC 977, January
[16]    1848  PS   S. Crocker, N. Freed, J. Galvin,      Proposed
        S. Murphy, "MIME Object Security Services",      standard
        RFC 1848, March 1995.

[17]    J. Myers, M. Rose: The Content-MD5 Header        Draft
        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.           IETF draft
        Frystyk: Hypertext Transfer Protocol --
        HTTP/1.0, draft-ietf-http-v10-spec-04.txt.

[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.Z              still widely
        FTP://zoo.toronto.edu/pub/news.txt.Z             used and
        This document is often referenced under the      almost a de-
        name "son-of-RFC1036".                           facto
                                                         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. draft-newman-msgheader field-originfo-
        01.txt, July 1997.

[26]    Grant Neufeld and Joshua D. Baer: The Use of     IETF draft
        URLs as Meta-Syntax for Core Mail List
        Commands and their Transport through Message
        Header fields, draft-baer-listspec-01.txt,
        September 1997.

                          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

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

RFC 822


RFC 976

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

RFC 1036


RFC 1049


RFC 1327

Message-Type Delivery

RFC 1505


RFC 2045


RFC 1806


RFC 1864


RFC 1911


RFC 2110


son-of-RFC1036 [21]



World Wide Web Consortium (W3C) Recommendations


Not Internet standard

"From " (not followed by ":")

                   Appendix B: Alphabetical index

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

3.3     Also-Control
3.3     Alternate-Recipient
3.4     Apparently-To
3.4     Approved
3.6     Article-Names
3.6     Article-Updates
3.17    Auto-Forwarded
3.4     bcc
3.4     cc
        Client, see Originating-Client
        Comment, see For-Comment
3.6     Content-Alias
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
        Copy, see Incomplete-Copy
3.8     Date
        Date, see also Delivery-Date, Received, Expires, Expiry-
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-Indication
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
3.17    Fcc
3.4     Followup-To
3.4     For-Approval
3.4     For-Comment
3.4     For-Handling
        Forwarded, see Auto-Forwarded
3.4     From
3.4     Generate-Delivery-Report
        Handling, see For-Handling
        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
        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-Help
3.16    List-ID
3.16    List-Owner
3.16    List-Post
3.16    List-Software
3.16    List-Subscribe
3.16    List-Unsubscribe
        Loss, see Conversion-With-Loss
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.6     Original-Recipient
3.4     Originating-Client
3.4     Originator-Info see also Sender
3.2     Path
3.4     Phone
3.9     PICS-Label
3.9     Precedence
3.4     Prevent-NonDelivery-Report
3.9     Priority
3.2     Received
        Recipient, see To, cc, bcc, Alternate-Recipient, Disclose-
3.6     References
3.8     Reply-By
3.4     Reply-To, see also In-Reply-To, References
3.14    Resent-
        Return see also Content-Return
3.2     Return-Path
3.5     Return-Receipt-To
3.6     See-Also
3.4     Sender
3.9     Sensitivity
3.17    Status
3.7     Subject
3.7     Summary
3.6     Supersedes
3.4     Telefax
3.4     To
        Transfer-Encoding see Content-Transfer-Encoding
        Type see Content-Type, Message-Type, Original-Encoded-
        Version, see MIME-Version, X-Mailer
3.4     X-Envelope-From
3.4     X-Envelope-To
3.16    X-List-Host
3.16    X-Listserver
3.4     X-Mailer see also Mail-System-Version
3.13    X-MIME-Autoconverted
3.4     X-Newsreader
3.17    X-No-Archive
3.9     X-Priority
3.4     X-Sender see also Originator-Info
3.6     X-UIDL
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