Network Working Group
Internet Draft
draft-palme-mailext-headers-08.txt
Category: Informational
Revision of: RFC 2076
Jacob Palme
Stockholm University/KTH
Sweden
Date: September 2002
Expires: March 2003

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.

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 http://www.ietf.org/ietf/1id-abstracts.txt

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

http://www.ietf.org/shadow.html.

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

Abstract

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 2822, 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 http://www.cs.tut.fi/~jkorpela/headers.html [28]

Changes since previous draft:

Corrected misspelling of "Abouse" should be "Abuse" and "Register-Mail-Reply-Requested-By" should be "Registered-Mail-Reply-Requested-By". Added some RFC references. Added some more warnings concerning "Precedence".

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
Copyright and disclaimer
5. References
6. Author's address

Appendix A:
Header fields sorted by Internet RFC document in
which they appear.
      RFC 976
      RFC 1049
      RFC 1036
      RFC 1123
      RFC 1505
      RFC 1766
      RFC 1864
      RFC 2045
      RFC 2110
      RFC 2156
      RFC 2183
      RFC 2298
      RFC 2369
      RFC 2421
      son-of-RFC1036 [21]
      RFC 2822
      RFC 2912
      RFC 2919:
      World Wide Web Consortium (W3C) Recommendations
      Not Internet standard (as of May 2001)

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

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

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

http://www.dsv.su.se/jpalme/ietf/mail-headers/

 

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 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 (2002) 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 usage"
Used to mark header fields which are defined 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 for use in e-mail"
Used to mark header fields defined only in RFC 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 caution.
"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 interpretations.
"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 passed.
DL-Expansion-History:
RFC 2156, not for general usage.
List of MTAs passed.
Path:
RFC 1036: 2.1.6, only in Usenet News, not in e-mail.
Trace of MTAs which a message has passed.
Received:
RFC 2822: RFC 1123: 5.2.8.
Used to convey the information from the MAIL FROM envelope attribute in final delivery, when the message leaves the SMTP environment in which "MAIL FROM" is used.
Return-Path:
RFC 821,
RFC 1123: 5.2.13.
The netnews host, to which this article was originally posted. 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.
NNTP-Posting-Host:
Non-standard, common in netnews

3.3 Format and control information

Special Usenet News commands and a normal article at the same time.
Also-Control:
son-of-RFC1036 [21], non-standard, only in Usenet News, not in e-mail
Controls whether this message may be forwarded to alternate recipients such as a postmaster if delivery is not possible to the intended recipient. Default: Allowed.
Alternate-Recipient:
RFC 2156, not for general usage.
Whether a MIME body part is to be shown inline or is an attachment; can also indicate a suggested filename for use when saving an attachment to a file.
Content-Disposition:
RFC 2183, experimental
Can have the values "voice-message", "fax-message", "pager-message", "multimedia-message", "text-message", "none"
Message-Context:
Non-standard
Only in Usenet News, contains commands to be performed by News agents.
Control:
RFC 1036: 2.1.6, only in Usenet News, not in e-mail.
Whether recipients are to be told the names of other recipients of 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.
Disclose-Recipients:
RFC 2156, not for general usage.
An indicator that this message is formatted according to the MIME standard, and an indication of which version of MIME is utilized.
MIME-Version:
RFC 2045: 4.
Which body part types occur in this message.
Original-Encoded-Information-Types:
RFC 2156, not for general usage.

3.4 Sender and recipient indication

Inserted by Sendmail when there is no "To:" recipient in the original message, listing recipients derived from the envelope into the message heading. This behavior is not quite proper, MTAs should not modify headings (except inserting Received lines), and it can in some cases cause Bcc recipients to be wrongly divulged to non-Bcc recipients.
Apparently-To:
Non-standard, discouraged, mentioned in
RFC 1211.
Name of the moderator of the newsgroup to which this article is sent; necessary on an article 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.
Approved:
RFC 1036: 2.2.11, not standardized for use in e-mail.
Name of the moderator of a mailing list, and who has approved this message for distribution to the members of the list.
Approved-By:
Non-standard, used by some mailing list expansion systems.
Recipients not to be disclosed to other recipients. (bcc = Blind Carbon Copy).
bcc:
RFC 2822:,
RFC 1123: 5.2.15-16, 5.3.7,
RFC 2156, RFC 2532, RFC 3297.
Secondary, informational recipients. (cc = Carbon Copy)
cc:
RFC 2822:,
RFC 1123. 5.2.15-16, 5.3.7.
Geographical or organizational limitation on where this article can be distributed. Value can be a compete or incomplete domain names, also various special values are accepted like "world", "usenet", "USA", etc.
Distribution:
RFC 1036: 2.2.7, not standardized for use in e-mail.
Fax number of the originator.
Fax:, Telefax:
Non-standard.
Primary recipients, who are requested to approve the information in this message or its attachments.
For-Approval:
Non-standard
Primary recipients, who are requested to comment on the information in this message or its attachments.
For-Comment:
Non-standard
Primary recipients, who are requested to handle the information in this message or its attachments.
For-Handling:
Non-standard
(2) Used in Usenet News mail transport, to indicate the path through which an article has gone when transferred to a new host.
Sometimes called "From_" header field.
From
or
>From
(not followed by a colon)
RFC 976: 2.4 for use in Usenet News
(1) This header field should never appear in e-mail being sent, and should thus not appear 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.
From (not followed by a colon)
not standardized for use in e-mail
Authors or persons taking responsibility for the message.
Note difference from the "From " header field (not followed by ":") below.
From:
RFC 2822:,
RFC 1123: 5.2.15-16, 5.3.7,
RFC 1036 2.1.1
Information about the client software of the originator.
Mail-System-Version:, Mailer:, Originating-Client:, X-Mailer, X-Newsreader, X-MimeOLE:, User-Agent:
Non-standard.
In Usenet News: group(s) to which this article was posted.
Some systems provide this header field also in e-mail although it is not standardized there.
Unfortunately, the header field can appear in e-mail with three different and contradictory meanings:
(a) Indicating the newsgroup recipient of an article/message sent to both e-mail and Usenet News recipients.
(b) In a 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 originated.
See also: "Posted-To:".
Newsgroups:
RFC 1036: 2.1.3, not standardized and controversial for use in e-mail.
Sometimes used in Usenet News in similar ways to "Sender:"
Also used in printing protocols.
Originator:
Non-standard in Usenet News, Experimental in RFC 1528.
Contains information about the authentication of the originator in a format which is not easily used to send email to, to avoid the problems with "Sender" and "X-Sender".
Originator-Info:
Non-standard [25]
Phone number of the originator.
Phone:
Non-standard.
The person or agent submitting the message to the network, if other than shown by the From: header field. Should be authenticated,
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".
Sender:
RFC 822: 4.4.2, RFC 2822 3.6.2,
RFC 1123: 5.2.15-16, 5.3.7, RFC 1036.
Primary recipients.
To:
RFC 2822:,
RFC 1123: 5.2.15-16, 5.3.7.
If the sender in the envelope (SMTP "RCTP TO") is not the same as the senders in the "From" or "Sender" RFC 2822 header fields, some mail servers add this to the RFC 2822 header fields as an aid to clients which would otherwise not be able to display this information.
X-Envelope-From:
Non-standard.
If the recipient in the envelope (SMTP "MAIL FROM") is not included in the CC list, some mail servers add this to the RFC 2822 header field as an aid to clients which would otherwise not be able to display the envelope recipients.
X-Envelope-To:,
Envelope-To:
Non-standard.
48x48 bitmap with picture of the sender of this message.
X-Face:
Non-Standard
Indication in the mail header of recipient on the SMTP envelope.
X-RCPT-TO:
Non-standard
Some mail software expect "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-Sender".
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.
X-Sender:
Non-standard
Even though some systems put the 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:"
X-X-Sender:
Non-standard
When a message is sent both to 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.
Posted-To:
Non-standard
E-mail address of administrator of a server, through which this message was submitted.
X-Admin:
Non-standard

3.5 Response control

Indicates whether the content of a message is to be returned with non-delivery notifications.
Content-Return:
RFC 2156, not for general usage.
For future options on disposition notifications.
Disposition-Notification-Options:
RFC 2298
Indicate that the sender wants a dispoisition notification when this message is received (read, processed, etc.) by its receipents.
Disposition-Notification-To:
RFC 2298
Address to which notifications are to be sent and a request to get delivery notifications. Internet standards recommend, however, the use of MAIL FROM and Return-Path, not Errors-To, for where delivery notifications are to be sent.
Errors-To:, Return-Receipt-To:,
Read-Receipt-To:, X-Confirm-reading-to:, Return-Receipt-Requested, Registered-Mail-Reply-Requested-By:
Non-standard, discouraged, some of them widely used.
Used in Usenet News to indicate that future discussions (=follow-up) on an article should go to a 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 sent.
The value of this header field should be one or more newsgroup names.
The special value "poster" as in "Followup-To: poster" means that replies are to be sent as e-mail to the author only.
Followup-To:
RFC 1036: 2.2.3, not standardized for use in e-mail.
Whether a delivery report is wanted at successful delivery. Default is not to generate such a report.
Generate-Delivery-Report:
RFC 2156, not for general usage.
Original Recipient information for inclusion in disposition notifications.
Original-Recipient
RFC 2298
Whether non-delivery report is wanted at delivery error. Default is to want such a report.
Prevent-NonDelivery-Report:
RFC 2156, not for general usage.
This header field is meant to indicate where the sender wants replies to go. Unfortunately, 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.).
Reply-To:
RFC 2822:,
RFC 1036: 2.2.1
controversial.
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.

Adress to which those replies to this message should be sent, which are intended for all who read the replied-to message, not only for its author.
Mail-Followup-To:
Non-standard, see
http://cr.yp.to/proto/replyto.html
Similar to "Reply-To:" but more unambiguosly specifies that this is the address for rpelies to the author only, not to any other recipients of the replied-to message.
Mail-Reply-To:
Non-standard, see
http://cr.yp.to/proto/replyto.html
Indicates where to send complains if you get a message which you think is against the laws or rules.
Abuse-Reports-To:, X-Complaints-To:, X-Report-Abuse-To:
non-standard
Used in netnews articles to indicate that followup (=replies) should be sent to the indicated e-mail address.
Mail-Copies-To:
non-standard, but commonly supported by newsreaders
Possible future change of name for "Content-Return:"
X400-Content-Return:
non-standard

3.6 Message identification and referral header fields

Reference to specially important articles for a particular Usenet Newsgroup.
Article-Names:
son-of-RFC1036 [21], non-standard
Only in Usenet News, similar to "Supersedes:" but does not cause the referenced article to be physically deleted.
Article-Updates:
son-of-RFC1036 [21], non-standard
Used in addition to Content-Location if this content part can be retrieved through more than one URI. Only one of them is allowed in the Content-Location, the other can be specified in Content-Alias.
Content-Alias:
Work in progress
Base to be used for resolving relative URIs within this content part.
Content-Base:
RFC 2110
Unique ID of one body part of the content of a message.
Content-ID:
RFC 2045: 7.
URI with which the content of this content part might be retrievable.
Content-Location:
RFC 2110
Used by some automatic services (mainly MLMs and autoresponders) for the purpose of 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.
Delivered-To:
or
X-Loop:
non-standard
Reference to message which this message is a reply to.
Note: It is better to use References instead of In-Reply-To, because many mailers produce a multitude of difficult to interpret content of the In-Reply-To header.
In-Reply-To:
RFC 2822
Unique ID of this message.
Message-ID:
RFC 2822,
RFC 1036: 2.1.5.
Reference to previous message being corrected and replaced. Compare to "Supersedes:" below. This field may in the future be replaced with "Supersedes:".
Obsoletes:
RFC 2156, not for general usage.
The "References:" field will contain the contents of the parent's "References:" field (if any) followed by the contents of the parent's "Message-ID:" field (if any).
Note: In RFC 822, this header indicated other messages, which the current message relates to. But in RFC 2822 this was changed. In Usenet News, the header has always has the new usage.
References:
RFC 2822,
RFC 1036: 2.1.5.
Still another name for similar functionality as for "Obsoletes:" and "Supersedes:". This may become the most recommended header in the future, but is still under discussion in IETF standards development work.
Replaces:
non-standard, proposed in IETF USEFOR working group
References to other related articles in Usenet News.
See-Also:
Son-of-RFC1036 [21], non-standard
Commonly used in Usenet News in similar ways to the "Obsoletes" 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.
Supersedes:
son-of-RFC1036 [21], non-standard
Mailbox of the person who made the translation.
Translated-By:
non-standard
Reference to the Message-ID of a message, which the current message is a translation of.
Translation-Of:
non-standard
Unique identifier for a message, local to a particular local mailbox store. The UIDL identifier is defined in the POP3 standard, but not the "X-UIDL:" header.
X-UIDL:
non-standard
Similar usage as "X-URL". The URI can be either a URL or a URN. URNs are meant to become more persistent references to resources than URLs.
X-URI:
Non-standard
Sometimes used with the same meaning as "Content-Location:", sometimes to indicate the web home page of the sender or of his organisation.
X-URL:
Non-standard
The UID, as defined in the IMAP standard. Only used in internal mailbox storage in some mail systems, should never be visible to a user.
X-IMAP:
Non-standard

3.7 Other textual header fields

Comments on a message.
Comments:
RFC 2822
Description of a particular body part of a message, for example a caption for an image body part.
Content-Description:
RFC 2045: 8.
A text string which identifies the content of a message.
Content-Identifier:
RFC 2156, not for general usage.
Search keys for data base retrieval.
Keywords:
RFC 2822
RFC 1036: 2.2.9.
See Organization above.
Organisation:
Non-standard.
Organization to which the sender of this article belongs.
Organization:
RFC 1036: 2.2.8, not standardized for use in e-mail.
Title, heading, subject. Often used as thread indicator for messages replying to or commenting on other messages.
Subject:
RFC 2822,
RFC 1036: 2.1.4.
Short text describing a longer article. Warning: Some mail systems will not display this text to the recipient. Because of this, do not use this header field for text which you want to ensure that the recipient gets.
Summary:
RFC 1036: 2.2.10, not standardized for use in e-mail, discouraged.

3.8 Header fields containing dates and times

In Internet, the date when a message was written, in X.400, the time a message was submitted. Some Internet mail systems also use the date when the message was submitted.
Date:
RFC 2822,
RFC 1123: 5.2.14
RFC 1036: 2.1.2.
The time when a message was delivered to its recipient.
Delivery-Date:
RFC 2156, not for general usage.
A suggested expiration date. Can be used both to limit the time of an article which is not meaningful after a certain date, and to extend the storage of important articles.
Expires:
RFC 1036: 2.2.4, not standardized for use in e-mail.
Time at which a message loses its validity. This field may in the future be replaced by "Expires:".
Expiry-Date:
RFC 2156, not for general usage.
Latest time at which a reply is requested (not demanded).
Reply-By:
RFC 2156, not for general usage.
Time when this message was delivered into the message transport system (usually the same time as in the last "Received:" header)
X-OriginalArrivalTime:
Non-standard

3.9 Quality information

A hint from the originator to the recipients about how important a message is. Values: High, normal or low. Not used to control transmission speed.
Importance:
RFC 2156 and
RFC 2421, proposed
Body parts are missing.
Incomplete-Copy:
RFC 2156, not for general usage.
Ratings label to control selection (filtering) of messages according to the PICS protocol.
PICS-Label:
REC-PICS-labels, W3C document [23].
Sometimes used as a (a) priority value which can influence transmission speed and delivery. Common values are "bulk" and "first-class". Other uses is to (b) control automatic replies like delivery status reports and vacation notices and to (c) control return-of-content facilities, and to (d) stop mailing list loops, (e)
Precedence:
Non-standard, controversial, widely used. Because it is used for so many different purposes, there is a risk that creator and user of this header mean different things.
Can be "normal", "urgent" or "non-urgent" and can influence transmission speed and delivery.
Priority:
RFC 2156, not for general usage.
How sensitive it is to disclose this message to other people than 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 sensitive.
Sensitivity:
RFC 2156 and
RFC 2421, proposed
Yet another priority indication.
X-MSMail-Priority:
Non-standard
Values: 1 (Highest), 2 (High), 3 (Normal), 4 (Low), 5 (Lowest). 3 (Normal) is default if the field is omitted.
X-Priority:
Non-standard [24]

3.10 Language information

Can include a code for the natural language used in a message, e.g. "en" for English.
Content-Language:
RFC 1766, proposed standard.
Can include a code for the natural language used in a message, e.g. "en" for English.
Language:
RFC 2156, not for general usage.

3.11 Size information

Inserted by certain mailers to indicate the size in bytes of the 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 problems.
Content-Length:
Non-standard, discouraged.
Size of the message.
Lines:
RFC 1036: 2.2.12, not standardized for use in e-mail. Will be deprecated in the future.

3.12 Conversion control

Information on where an alternative variant of this document might be found.
Content-Alternative:
Non-standard [27].
Non-standard variant of Conversion: with the same values.
Content-Conversion:
Non-standard.
The body of this message may not be converted from one character set to another. Values: Prohibited and allowed.
Conversion:
RFC 2156, not for general usage.
The body of this message may not be converted from one character set to another if information will be lost. Values: Prohibited and allowed.
Conversion-With-Loss:
RFC 2156, not for general usage.

3.13 Encoding information

Type information of the content in some class hierarchy. Class hierarchies are commonly used to classify data structures in software development.
Content-Class:
non-standard
Can give more detailed information about the Content-Type. Example:
Content-Features:
Proposed Standard, RFC 2912
Content-features:
(& (Type="image/tiff")
(color=Binary)
(image-file-structure=TIFF-S)
(dpi=200)
(dpi-xyratio=200/100)
(paper-size=A4)
(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 multipart/atlernative.
Information from the SGML entity declaration corresponding to the entity contained in the body of the body part.
Content-SGML-Entity:
non-standard
Coding method used in a MIME message body.
Content-Transfer-Encoding:
RFC 2045: 6.
Format of content (character set etc.) Note that the values for this header field are defined in different ways in RFC 1049 and in 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 field.
Various other Content-Type define various additional parameters. For example, the parameter "charset" is mandatory for all textual Content-Types.
Content-Type:
RFC 1049,
RFC 1123: 5.2.13,
RFC 1766: 4.1
RFC 2045: 5.
Used in several different ways by different mail systems. Some use it for a kind of content-type information, some for encoding and length information, some for a kind of boundary information, some in other ways.
Encoding:
RFC 1154,
RFC 1505,
experimental.
Only used with the value "Delivery Report" to indicates that this is a delivery report gatewayed from X.400.
Message-Type:
RFC 2156, not for general usage.
Information about conversion of this message on the path from sender to recipient, like conversion between MIME encoding formats. Note: Auto-conversion may invalidate digital seals and signatures.
X-MIME-Autoconverted:
non-standard

3.14 Resent-header fields

When manually forwarding a message, header fields referring to the forwarding, not to the original message. Note: MIME specifies another way of resending messages, using the "Message" Content-Type.
Resent-Reply-To:,
Resent-From:, Resent-Sender:, Resent-Date:, Resent-To:, Resent-cc:, Resent-bcc:, Resent-Message-ID:
RFC 2822

3.15 Security and reliability

Checksum of content to ensure that it has not been modified.
Content-MD5:
RFC 1864, proposed standard.
Used in Usenet News to store information to avoid showing a reader the same article twice if it was sent to more than one newsgroup. Only for local usage within one Usenet News server, should not be sent between servers.
Xref:
RFC 1036: 2.2.13, only in Usenet News, not in e-mail.
Used in Usenet News to stop rough cancels. Crypthographic methods are used to ensure that only the original author of an article can cancel it.
Cancel-Lock:,
Cancel-Key
Non-standard

3.16 Mailing list control

Contains URL to use to browse the archives of the mailing list from which this message was relayed.
List-Archive:
RFC 2369 [26]
URL to use to get a subscription to the digest version of the mailing list from which this message was relayed.
List-Digest:
Non-standard
Contains URL to use to get a information about the mailing list from which this message was relayed.
List-Help:
RFC 2369 [26]
Stores an identification of the mailing list, through which this message was distributed.
List-ID:
RFC 2919 [27].
Non-standard precursors to List-ID and List-Post.
Mailing-List:, X-Mailing-List:
Non-standard
Contains URL to send e-mail to the owner of the mailing list from which this message was relayed.
List-Owner:
RFC 2369 [26]
Contains URL to use to send contributions to the mailing list from which this message was relayed.
List-Post:
RFC 2369 [26]
Information about the software used in a mailing list expander through which this message has passed.
List-Software:
Non-standard, has been considered for inclusion in [26].
Contains URL to use to get a subscription to the mailing list from which this message was relayed.
List-Subscribe:
RFC 2369 [26]
Contains URL to use to unsubscribe the mailing list from which this message was relayed.
List-Unsubscribe:
RFC 2369 [26]
Contains URL where information of various kinds about the mailing list from which this message was relayed.
List-URL:
Non-standard
Information about the server and software 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.
X-Listserver:, X-List-Host:
Non-standard. Recommended to use "List-Software" instead.

3.17 Miscellaneous

Has been automatically forwarded.
Autoforwarded:
RFC 2156, not for general usage.
Can be used in Internet mail to indicate X.400 IPM extensions which could not be mapped to Internet mail format.
Discarded-X400-IPMS-Extensions:
RFC 2156, not for general usage.
Can be used in Internet mail to indicate X.400 MTS extensions which could not be mapped to Internet mail format.
Discarded-X400-MTS-Extensions:
RFC 2156, not for general usage.
Name of file in which a copy of this message is stored.
Fcc:
Non-standard.
Speech act categoriztion of a message, examples of speeach acts are Question, Idea, More, Promise, Sad, Happy, Angry, summary, Decision
Speech-Act:
Non-standard
This field is used by some mail delivery systems to indicate the status of delivery for this message when stored. Common values of this field are:
U message is not
Downloaded and
not deleted.
R message is read
or downloaded.
O message is old
but not deleted.
D to be deleted.
N new (a new message
also sometimes is
distinguished by
not having any
"Status:" header
field.
Combinations of these characters can occur, such as "Status: OR" to indicate that a message is downloaded but not deleted.
Status:
Non-standard, should never appear in mail in transit.
Do not archive this message in publicly available archives.
X-No-Archive: Yes
Non-standard

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, Maxim Masiutin, 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 Reserved.


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 (July 2002)

[1]
J. Klensin: "Simple Mail Transfer Protocol", RFC 2821, April 2001.
Proposed Standard
[2]
P. Resnick: "Internet Message Format" STD 11, RFC 2822, April 2001.
Proposed Standard
[3]
M.R. Horton, R. Adams: "Standard for interchange of USENET messages", RFC 1036, December 1987.
Not an offi-cial IETF standard, but in reality a de-facto standard for Usenet News
[4]
M. Sirbu: "A Content-Type header field header field for internet messages", RFC 1049, March 1988.
Historic
[5]
R. Braden (editor): "Requirements for Internet Hosts
Application and Support", STD-3, RFC 1123, October 1989.

Standard, Required
[6]
D. Robinson, R. Ullman: "Encoding Header field for Internet Messages", RFC 1505, August 1993.
Non-standard
[7]
S. Hardcastle-Kille: "Mapping between X.400(1988) / ISO 10021 and RFC 2822", RFC 2156 January 1998.
Proposed standard, elective
[8]
H. Alvestrand & J. Romaguera: "Rules for Downgrading Messages from X.400/88 to X.400/84 When MIME Content-Types are Present in the Messages", RFC 1496, August 1993.
Proposed standard, elective
[9]
A. Costanzo: "Encoding Header field Header field for Internet Messages", RFC 1154, April 1990.
Non-standard
[10]
A. Costanzo, D. Robinson: "Encoding Header field Header field for Internet Messages", RFC 1505, August 1993.
Experimental
[11]
N. Freed & N. Borenstein: "MIME (Multipurpose Internet Mail Extensions) Part One: Format of Internet Message Bodies. RFC 2045. November 1996.
Draft Standard, elective
[12]
H. Alvestrand: "Tags for the Identification of Languages", RFC 3066, January 2001.
Best Current Practice, elective
[13]
J. Palme: "Electronic Mail", Artech House publishers, London-Boston January 1995.
Non-standard
[14]
R. Troost, S. Dorner: "Communicating Presentation Information in Internet Messages: The Content-Disposition Header field", RFC 2183, June 1995.
Experimental
[15]
B. Kantor, P. Lapsley, "Network News Transfer Protocol: "A Proposed Standard for the Stream-Based Transmission of News", RFC 977, January 1986.
Proposed standard
[16]
1848 PS S. Crocker, N. Freed, J. Galvin, S. Murphy, "MIME Object Security Services", RFC 1848, March 1995.
Proposed standard
[17]
J. Myers, M. Rose: The Content-MD5 Header field Header field, RFC 1864, October 1995.
Draft standard
[18]
M. Horton, UUCP mail interchange format standard, RFC 976, Januari 1986.
Not an offi-cial IETF standard, but in reality a de-facto standard for Usenet News
[19]
R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee: Hypertext Transfer Protocol
HTTP/1.1, June 1999.

Draft standard
[20]
G. Vaudreuil: Voice Profile for Internet Mail, RFC 2421 Feburary 1998.
Proposed
[21]
H. Spencer: News Article Format and Transmission, June 1994,
FTP://zoo.toronto.edu/pub/news.ps.Z
FTP://zoo.toronto.edu/pub/news.txt.Z
This document is often referenced under the name "son-of-RFC1036".
Not even an RFC, but still widely used and partly almost a de-facto standard for Usenet News
[23]
PICS Label Distribution Label Syntax and Communication Protocols, World Wide Web Consortium, October 1996.
Other standard
[24]
Eudora Pro Macintosh User Manual, Qualcomm Inc., 1988-1995.
Non-standard
[25]
C. Newman: Originator-Info Message Header field. work in progress, July 1997.
Non-standard
[26]
Grant Neufeld and Joshua D. Baer: The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header fields, RFC 2369, July 1998.
Proposed standard
[27]
G. Klyne (ed.): Content Negotiation for Facsimile Using Internet Mail, Work in progress, March 2000.
Non-standard
[27]
R. Chandhok, G. Wenger: List-IDE: A Structured Field and Namespace for the Identification if Mailing Lists, RFC 2919, March 2001.
Proposed standard
[28]
Jukka "Yucca" Korpela: Quick reference to Internet message headers, http://www.cs.tut.fi/~jkorpela/headers.html, October 2001.
Non-standard

6. Author's address

Jacob Palme
Stockholm University/KTH
Forum 100
S-164 40 Kista, Sweden
Phone: +46-8-16 16 67
Fax: +46-8-783 08 29
E-mail: jpalme@dsv.su.se

Appendix A:

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


RFC 976



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

RFC 1049



Content-Type

RFC 1036



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

RFC 1123



Content-Type

RFC 1505



Encoding

RFC 1766



Content-Language

RFC 1864



Content-MD5

RFC 2045



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

RFC 2110



Content-Base
Content-Location

RFC 2156



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

RFC 2183



Content-Disposition

RFC 2298



Disposition-Notification-To
Disposition-Notification-Options
Original-Recipient

RFC 2369



List-Archive
List-Help
List-Owner
List-Post
List-Software
List-Subscribe
List-Unsubscribe

RFC 2421



Importance
Sensitivity

son-of-RFC1036 [21]



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

RFC 2822



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

RFC 2912



Content-Features

RFC 2919:



List-ID

World Wide Web Consortium (W3C) Recommendations



Pics-Label

Not Internet standard (as of July 2002)



"From " (not followed by ":")
Abuse-Reports-To
Apparently-To
Approved-By
Cancel-Key
Cancel-Lock
Content-Alias
Content-Alternative
Content-Class
Content-Conversion
Content-Length
Content-SGML-Entity
Delivered-To
Encoding
Errors-To
Fax
Fcc
For-Approval
For-Comment
For-Handling
List-Digest
List-URL
Mailing-List
Mail-Copies-To
Mail-Followup-To
Mail-Reply-To
Mail-System-Version
Mailer
Message-Context
NNTP-Posting-Host
Organisation
Originating-Client
Originator
Originator-Info
Phone
Posted-To
Precedence
Registered-Mail-Reply-Requested-By
Replaces
Return-Receipt-Requested
Return-Receipt-To
Read-Receipt-To
Speech-Act
Status
Supersedes
Telefax
Translated-By
Translation-Of
User-Agent
X-Admin
X-Confirm-Reading-To
X-Complaints-To
X-Envelope-From
X-Envelope-To
X-Face
X-IMAP
X-Loop
X-List-Host
X-Listserver
X-Mailer
X-Mailing-List
X-MIME-Autoconverted
X-MIMEOLE
X-MSMail-Priority
X-Newsreader
X-No-Archive
X-OriginalArrivalTime
X-Priority
X-RCPT-TO
X-Report-Abuse-To
X-Sender
X-UIDL
X-URI
X-URL
X-X-Sender
X400-Content-Return

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.15
Cancel-Lock
3.4
cc

Client, see Originating-Client

Comment, see For-Comment
3.7
Comments
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-Date
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-X400-MTS-Extensions
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.6
Mail-Followup-To
3.6
Mail-Reply-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-Recipients
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-Reply-To:
3.14
Resent-From:
3.14
Resent-Sender:
3.14
Resent-Date:
3.14
Resent-To:
3.14
Resent-Cc:
3.14
Resent-bcc:
3.14
Resent-Message-ID:
3.14
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-Information-Types
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