Network Working Group Jacob Palme
Internet Draft Stockholm University/KTH
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
http://www.dsv.su.se/jpalme/ietf/mail-headers/. 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
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
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  35
World Wide Web Consortium (W3C) Recommendations 35
Not Internet standard (as of May 2001) 35
Appendix B: Alphabetical index 36
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 , RFC 1036 , RFC 1123
, RFC 2156 , RFC 1496 , RFC 2045 , RFC 1766 , RFC
2183 , RFC 1864 and RFC 2421. Note in particular that
heading attributes defined in PEM (RFC 1421-1424) and MOSS (RFC 1848
) 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 , UUCP  and
NNTP  are mainly not covered either. Headings used only in HTTP
 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
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 <email@example.com>) 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
**** 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"
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 , non-
time. standard, only in
Usenet News, not
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:
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.
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-
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
Primary recipients, who are For-Comment: Non-standard
requested to comment on the
information in this message or
Primary recipients, who are For-Handling: Non-standard
requested to handle the
information in this message or
(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
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
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-
Note difference from the "From " RFC 1036 2.1.1
header field (not followed by
Information about the client Mail-System- Non-standard.
software of the originator. Version:,
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
(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,
Also used in printing protocols. RFC 1528.
Contains information about the Originator- Non-standard 
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-
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
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
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.
For future options on disposition Disposition- RFC 2298
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
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: , non-standard
Only in Usenet News, similar to Article- son-of-RFC1036
"Supersedes:" but does not cause Updates: , non-standard
the referenced article to be
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. , non-standard
Commonly used in Usenet News in Supersedes: son-of-RFC1036
similar ways to the "Obsoletes" , 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
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
**** 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
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 .
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
facilities, and to stop mailing
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 
(Normal), 4 (Low), 5 (Lowest). 3
(Normal) is default if the field
**** 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,
for use in e-mail.
**** 3.12 Conversion control
Information on where an Content- Non-standard .
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
**** 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
Can give more detailed Content- Proposed Standard,
information about the Content- Features: RFC 2912
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
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
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 
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 
information about the mailing
list from which this message was
Stores an identification of the List-ID: RFC 2919 .
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 
the owner of the mailing list
from which this message was
Contains URL to use to send List-Post: RFC 2369 
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
Contains URL to use to get a List- RFC 2369 
subscription to the mailing list Subscribe:
from which this message was
Contains URL to use to List- RFC 2369 
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"
**** 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,
This field is used by some mail Status: Non-standard,
delivery systems to indicate the should never
status of delivery for this appear in mail in
message when stored. Common transit.
values of this field are:
U message is not downloaded
and not deleted.
R message is read or
O message is old but not
D to be deleted.
N new (a new message also
sometimes is distinguished
by not having any "Status:"
Combinations of these characters
can occur, such as "Status: OR"
to indicate that a message is
downloaded but not deleted.
Do not archive this message in X-No-Archive: Non-standard
publicly available archives. Yes
Harald Tveit Alvestrand, Neil Carpenter, William C. Carpenter, Rob
Chandhok, Ned Freed, Olle Jrnefors, 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 Jrnefors
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 .
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.
Ref. Author, title IETF status
----- --------------------------------------------- -----------
 J. Postel: "Simple Mail Transfer Protocol", Standard,
STD 10, RFC 821, August 1982. Recommended
 D. Crocker: "Standard for the format of ARPA Standard,
Internet text messages." STD 11, RFC 822, Recommended
 M.R. Horton, R. Adams: "Standard for Not an offi-
interchange of USENET messages", RFC 1036, cial IETF
December 1987. standard,
reality a de-
 M. Sirbu: "A Content-Type header field header Historic
field for internet messages", RFC 1049, March
 R. Braden (editor): "Requirements for Standard,
Internet Hosts -- Application and Support", Required
STD-3, RFC 1123, October 1989.
 D. Robinson, R. Ullman: "Encoding Header Non-standard
field for Internet Messages", RFC 1505,
 S. Hardcastle-Kille: "Mapping between Proposed
X.400(1988) / ISO 10021 and RFC 822", RFC standard,
2156 January 1998. elective
 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.
 A. Costanzo: "Encoding Header field Header Non-standard
field for Internet Messages", RFC 1154, April
 A. Costanzo, D. Robinson: "Encoding Header Experimental
field Header field for Internet Messages",
RFC 1505, August 1993.
 N. Freed & N. Borenstein: "MIME (Multipurpose Draft
Internet Mail Extensions) Part One: Format of Standard,
Internet Message Bodies. RFC 2045. November elective
 H. Alvestrand: "Tags for the Identification Proposed
of Languages", RFC 1766, February 1995. standard,
 J. Palme: "Electronic Mail", Artech House Non-standard
publishers, London-Boston January 1995.
 R. Troost, S. Dorner: "Communicating Experimental
Presentation Information in Internet
Messages: The Content-Disposition Header
field", RFC 2183, June 1995.
 B. Kantor, P. Lapsley, "Network News Transfer Proposed
Protocol: "A Proposed Standard for the Stream- standard
Based Transmission of News", RFC 977, January
 1848 PS S. Crocker, N. Freed, J. Galvin, Proposed
S. Murphy, "MIME Object Security Services", standard
RFC 1848, March 1995.
 J. Myers, M. Rose: The Content-MD5 Header Draft
field Header field, RFC 1864, October 1995. standard
 M. Horton, UUCP mail interchange format Not an offi-
standard, RFC 976, Januari 1986. cial IETF
reality a de-
 T. Berners-Lee, R. Header fielding, H. Informatio
Frystyk: Hypertext Transfer Protocol -- nal
HTTP/1.0, RFC 1945.
 G. Vaudreuil: Voice Profile for Internet Proposed
Mail, RFC 2421 Feburary 1998.
 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 a de-facto
name "son-of-RFC1036". standard for
 PICS Label Distribution Label Syntax and Other
Communication Protocols, World Wide Web standard
Consortium, October 1996.
 Eudora Pro Macintosh User Manual, Qualcomm Non-standard
 C. Newman: Originator-Info Message Header Non-standard
field. work in progress, July 1997.
 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.
 G. Klyne (ed.): Content Negotiation for Non-standard
Facsimile Using Internet Mail, Work in
progress, March 2000.
 R. Chandhok, G. Wenger: List-IDE: A Proposed
Structured Field and Namespace for the standard
Identification if Mailing Lists, RFC 2919,
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: firstname.lastname@example.org
S-164 40 Kista, Sweden
Header fields sorted by Internet RFC document in which they appear.
"From " (followed by space, not colon (:")
Auto-forwarded see Autoforwarded
World Wide Web Consortium (W3C) Recommendations
Not Internet standard (as of May 2001)
"From " (not followed by ":")
Appendix B: Alphabetical index
Section Header field
Auto-Forwarded see Autoforwarded
Client, see Originating-Client
Comment, see For-Comment
3.10 Content-Language see also Language
Copy, see Incomplete-Copy
3.8 Date, see also Delivery-Date, Received, Expires, Expiry-
Delivery-Report, see Generate-Delivery-Report, Prevent-
Delivery-Report, Non-Delivery-Report, Content-Type
Description, see Content-Description
Disposition, see also Content-Disposition
3.13 Encoding see also Content-Transfer-Encoding
Extension see Discarded-X400-IPMS-Extensions, Discarded-
3.4 Fax see also Telefax
Forwarded, see Autoforwarded
3.4 From (not followed by (":" or preceded by ">")
3.4 From (followed by ":")
Handling, see For-Handling
History, see DL-Expansion-History
ID, see Content-ID and Message-ID
Identifier, see Content-ID and Message-ID
Label, see PICS-Label
3.10 Language see also Content-Language
Length see Content-Length
Loss, see Conversion-With-Loss
3.16 Mailing-List, see also X-Mailing-List
3.4 Mail-System-Version see also X-mailer
MD5 see Content-MD5
Newsreader, see X-Newsreader
3.4 Originator-Info see also Sender
Recipient, see To, cc, bcc, Alternate-Recipient, Disclose-
3.4 Reply-To, see also In-Reply-To, References
Return see Content-Return
3.4 Telefax see also Fax
Transfer-Encoding see Content-Transfer-Encoding
Type see Content-Type, Message-Type, Original-Encoded-
Version, see MIME-Version, X-Mailer
3.16 X-Mailing-List, see also Mailing-List
3.4 X-Mailer see also Mail-System-Version
3.4 X-Sender see also Originator-Info
3.6 X-URL see also Content-Location
3.4 X-X-Sender see also Originator-Info