Network Working Group
Internet Draft
draft-palme-mailext-mail-attributes-01.txt
Category: Informational
Revision of: RFC 2076
Jacob Palme
Stockholm University/KTH Sweden
Date: May 1999
Expires: November 1999



This document is also available in
Adobe Acrobat (PDF) and plain text versions.

 

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 1998. All Rights Reserved.

Abstract


This memo contains a table of commonly occurring header fields in headings of e-mail messages. The document compiles information from other RFCs such as RFC 822, RFC 1036, RFC 1123, RFC 1327, RFC 1496, RFC 1766, RFC 1806, RFC 1864, RFC 1911 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.

This document is a revision of RFC 2076. The following new header fields, not included in RFC 2076, have been added:
Also-Control, Content-Alias, Content-Conversion, Content-Features, Disposition-Notification-Options, Disposition-Notification-To, Expiry-Date, For-Approval, List-Archive, List-Help, List-ID, List-Owner, List-Post, List-Software, List-Subscribe, List-Unsubscribe, Original-Recipient, Originator, Originator-Info, Path, PICS-Label, Replaces, Speech-Act, Translated-By. Translation-Of, X-Envelope-From, X-Envelope-To, X-List-Host, X-Listserver, X-MIME-Autoconverted, X-No-Archive, X-Priority, X-Sender, X-X-Sender, X-UIDL, X-URL, X-URI


Table of contents


1. Introduction
2. Use of gatewaying header fields
3. Table of header fields
 4. Acknowledgments
Copyright and disclaimer
5. References
6. Author's address
Appendix A: Header fields sorted by Internet RFC document in which they appear.
 Appendix B: Alphabetical index

1. Introduction


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

The document contains all header fields which the author has
found in the following Internet standards: RFC 822 [2],
RFC 1036 [3], RFC 1123 [5], RFC 1327 [7], RFC 1496 [8], RFC 2045 [11], RFC 1766 [12], RFC 1806 [14], RFC 1864[17] and RFC 1911[20]. Note in particular that heading attributes defined in PEM (RFC 1421-1424) and MOSS (RFC 1848 [16]) are not included. PEM and MOSS header fields only appear inside the body of a message, and thus are not header fields in the RFC 822 sense. Mail attributes in envelopes, i.e. attributes controlling the message transport mechanism between mail and news servers, are not included. This means that attributes from SMTP [1], UUCP [18] and NNTP [15] are mainly not covered either. Headings used only in HTTP [19] are not included yet, but may be included in future version of this memo. Some additional header fields which often can be found in e-mail headings but are not part of any Internet standard are also included.

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

The header field names given here are spelled the same way as when they are actually used. This is usually American but sometimes English spelling. One header field in particular, "Organisation/Organization", occurs in e-mail header fields sometimes with the English and other times with the American spelling.

The following words are used in this memo with the meaning specified 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://dsv.su.se/jpalme/ietf/ietf-ietf-mail-attributes.html

Please e-mail me (Jacob Palme <jpalme@dsv.su.se>) if you have noted header fields which should be included in this memo but are not.


2. Use of gatewaying header fields


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

Header fields defined only in RFC 1036 for use in Usenet News sometimes appear in mail messages, either because the messages have been gatewayed from Usenet News to e-mail, or because the messages were written in combined clients supporting both e-mail and Usenet News in the same client. These header fields are not standardized for use in Internet e-mail and should be handled with caution by e-mail agents.


3. Table of header fields

3.1 Phrases used in the tables


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


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.
Trace of MTAs which a message has passed.
Received:
RFC 822: 4.3.2, RFC 1123: 5.2.8.
List of MTAs passed.
Path:
RFC 1036: 2.1.6, only in Usenet News, not in e-mail.
Trace of distribution lists passed.
DL-Expansion-History-Indication:
RFC 1327, not for general usage.

3.3 Format and control information


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.
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.
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
Which body part types occur in this message.
Original-Encoded-Information-Types:
RFC 1327, not for general usage.
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 1327, not for general usage.
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 1327, 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 1806, experimental

3.4 Sender and recipient indication


Authors or persons taking responsibility for the message.

Note difference from the "From " header field (not followed by ":") below.

From:
RFC 822: 4.4.1,
RFC 1123: 5.2.15-16, 5.3.7,
RFC 1036 2.1.1
(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
(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
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.
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 1123: 5.2.15-16, 5.3.7, RFC 1036.
Sometimes used in Usenet News in similar ways to "Sender:"
Originator:
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
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]
Primary recipients.
To:
RFC 822: 4.5.1,
RFC 1123: 5.2.15-16, 5.3.7.
Secondary, informational recipients. (cc = Carbon Copy)
cc:
RFC 822: 4.5.2,
RFC 1123. 5.2.15-16, 5.3.7.
Recipients not to be disclosed to other recipients. (bcc = Blind Carbon Copy).
bcc:
RFC 822: 4.5.3,
RFC 1123: 5.2.15-16, 5.3.7.
Primary recipients, who are requested to handle the information in this message or its attachments.
For-Handling:
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 approve the information in this message or its attachments.
For-Approval:
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.
Newsgroups:
RFC 1036: 2.1.3, not standardized and controversial for use in e-mail.
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.
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.
Phone number of the originator.
Phone:
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 RFC822 header field as an aid to clients which would otherwise not be able to display the envelope recipients.
X-Envelope-To
Non-standard.
If the sender in the envelope (SMTP "RCTP TO") is not the same as the senders in the "From" or "Sender" RFC822 header fields, some mail servers add this to the RFC822 header fields as an aid to clients which would otherwise not be able to display this information.
X-Envelope-From
Non-standard.
Information about the client software of the originator.
Mail-System-Version:, Mailer:, Originating-Client:, X-Mailer, X-Newsreader
Non-standard.

3.5 Response control


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 822: 4.4.3,
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.


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.
Followup-To:
RFC 1036: 2.2.3, not standardized for use in e-mail.
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.


Note that the value of this header field must always be one or more newsgroup names, never e-mail addresses.


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:
Non-standard, discouraged.
Whether non-delivery report is wanted at delivery error. Default is to want such a report.
Prevent-NonDelivery-Report:
RFC 1327, not for general usage.
Whether a delivery report is wanted at successful delivery. Default is not to generate such a report.
Generate-Delivery-Report:
RFC 1327, not for general usage.
Indicates whether the content of a message is to be returned with non-delivery notifications.
Content-Return:
RFC 1327, not for general usage.
Possible future change of name for "Content-Return:"
X400-Content-Return:
non-standard
Indicate that the sender wants a dispoisition notification when this message is received (read, processed, etc.) by its receipents.
Disposition-Notification-To
RFC 2298
For future options on disposition notifications.
Disposition-Notification-Options
RFC 2298
Original Recipient information for inclusion in disposition notifications.
Original-Recipient
RFC 2298

3.6 Message identification and referral header fields


Unique ID of this message.
Message-ID:
RFC 822: 4.6.1
RFC 1036: 2.1.5.
Unique ID of one body part of the content of a message.
Content-ID:
RFC 2045: 7.
Base to be used for resolving relative URIs within this content part.
Content-Base:
RFC 2110
URI with which the content of this content part might be retrievable.
Content-Location:
RFC 2110
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
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
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
Reference to message which this message is a reply to.
In-Reply-To:
RFC 822: 4.6.2.
In e-mail: reference to other related messages, in Usenet News: reference to replied-to-articles.
References:
RFC 822: 4.6.3
RFC 1036: 2.1.5.
References to other related articles in Usenet News.
See-Also:
Son-of-RFC1036 [21], non-standard
Reference to previous message being corrected and replaced. Compare to "Supersedes:" below. This field may in the future be replaced with "Supersedes:".
Obsoletes:
RFC 1327, not for general usage.
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
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
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
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
Reference to specially important articles for a particular Usenet Newsgroup.
Article-Names:
son-of-RFC1036 [21], non-standard
Reference to the Message-ID of a message, which the current message is a translation of.
Translation-Of:
non-standard
Mailbox of the person who made the translation.
Translated-By:
non-standard

3.7 Other textual header fields


Search keys for data base retrieval.
Keywords:
RFC 822: 4.7.1
RFC 1036: 2.2.9.
Title, heading, subject. Often used as thread indicator for messages replying to or commenting on other messages.
Subject:
RFC 822: 4.7.1
RFC 1036: 2.1.4.
Comments on a message.
Comments:
RFC 822: 4.7.2.
Description of a particular body part of a message, for example a caption for an image body part.
Content-Description:
RFC 2045: 8.
Organization to which the sender of this article belongs.
Organization:
RFC 1036: 2.2.8, not standardized for use in e-mail.
See Organization above.
Organisation:
Non-standard.
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.
A text string which identifies the content of a message.
Content-Identifier:
RFC 1327, not for general usage.

3.8 Header fields containing dates and times


The time when a message was delivered to its recipient.
Delivery-Date:
RFC 1327, not for general usage.
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 822: 5.1,
RFC 1123: 5.2.14
RFC 1036: 2.1.2.
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 1327, not for general usage.
Latest time at which a reply is requested (not demanded).
Reply-By:
RFC 1327, not for general usage.

3.9 Quality information


Can be "normal", "urgent" or "non-urgent" and can influence transmission speed and delivery.
Priority:
RFC 1327, not for general usage.
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]
Sometimes used as a priority value which can influence transmission speed and delivery. Common values are "bulk" and "first-class". Other uses is to control automatic replies and to control return-of-content facilities, and to stop mailing list loops.
Precedence:
Non-standard, controversial.
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 1327 and
RFC 1911, experimental
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 1327 and
RFC 1911, experimental
Body parts are missing.
Incomplete-Copy:
RFC 1327, 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].

3.10 Language information


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

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.

3.12 Conversion control


The body of this message may not be converted from one character set to another. Values: Prohibited and allowed.
Conversion:
RFC 1327, not for general usage.
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 if information will be lost. Values: Prohibited and allowed.
Conversion-With-Loss:
RFC 1327, not for general usage.

3.13 Encoding information


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 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 2045: 5.
RFC 1766: 4.1
Can give more detailed information about the Content-Type. Example:

(& (color=binary)
(image-file-structure=TIFF-S)
(dpi=200)
(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.
Content-Features:
non-standard
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.
Only used with the value "Delivery Report" to indicates that this is a delivery report gatewayed from X.400.
Message-Type:
RFC 1327, not for general usage.
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.
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-From:, Resent-Date:, Resent-To:, Resent-cc:, Resent-bcc:, Resent-Message-ID:
RFC 822: C.3.3.

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.

3.16 Mailing list control


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 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 get a information about the mailing list from which this message was relayed.
List-Help
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]
Contains URL to use to browse the archives of the mailing list from which this message was relayed.
List-Archive
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].
Stores the URN of the mailing list, through which this message was distributed.
List-ID
Non-standard, has been considered for inclusion in [26].
Information about the 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
Non-standard.

3.17 Miscellaneous


Name of file in which a copy of this message is stored.
Fcc:
Non-standard.
Has been automatically forwarded.
Auto-Forwarded:
RFC 1327, 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 1327, 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 1327, not for general usage.
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
Speech act categoriztion of a message, examples of speeach acts are Question, Idea, More, Promise, Sad, Happy, Angry, summary, Decision
Speech-Act:
Non-standard


4. Acknowledgments


Harald Tveit Alvestrand, Ned Freed, Olle Järnefors, Keith Moore, Nick Smith and several other people have helped me with compiling this list. I especially thank Ned Freed and Olle Järnefors for their thorough review and many helpful suggestions for improvements. I alone take responsibility for any errors which may still be in the list.

An earlier version of this list has been published as part of [13].


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 1996)
-----------
[1]
J. Postel: "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
Standard, Recommended
[2]
D. Crocker: "Standard for the format of ARPA Internet text messages." STD 11, RFC 822, August 1982.
Standard, Recommended
[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.
Standard, Recommended, but can in the future be expected to be replaced by MIME
[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 Header field for Internet Messages", RFC 1154, April 1990.
Non-standard
[7]
S. Hardcastle-Kille: "Mapping between X.400(1988) / ISO 10021 and RFC 822", RFC 1327 May 1992.
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 2945. November 1996.
Draft Standard, elective
[12]
H. Alvestrand: "Tags for the Identification of Languages", RFC 1766, February 1995.
Proposed standard, 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 1806, 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]
T. Berners-Lee, R. Header fielding, H. Frystyk: Hypertext Transfer Protocol -- HTTP/1.0, RFC 1945.
Informational
[20]
G. Vaudreuil: Voice Profile for Internet Mail, RFC 1911, February 1996.
Experimental
[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


6. Author's address


Jacob Palme
Stockholm University/KTH
Electrum 230
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 822

-------

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

RFC 976

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

RFC 1036

--------

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

RFC 1049

--------

Content-Type

RFC 1327

--------

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

RFC 1505

--------

Encoding

RFC 2045

--------

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

RFC 1806

--------

Content-Disposition

RFC 1864
--------

Content-MD5

RFC 1911

--------

Importance
Sensitivity

RFC 2110

--------

Content-Base
Content-Location

RFC 2369

--------

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

son-of-RFC1036 [21]

-------------------

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

draft-ietf-receipt

------------------

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

World Wide Web Consortium (W3C) Recommendations

-----------------------------------------------

Pics-Label

Not Internet standard

---------------------

"From " (not followed by ":")
Apparently-to
Content-Alias
Content-Length
Content-SGML-Entity
Encoding
Errors-To
Fax
Fcc
For-Approval
For-Comment
For-Handling
List-ID
Mail-System-Version
Mailer
Organisation
Originating-Client
Originator-Info
Phone
Return-Receipt-To
Speech-Act
Status
Supersedes
Telefax
Translated-By
Translation-Of
X-Envelope-From
X-Envelope-To
X-Mailer
X-MIME-Autoconverted
X-Newsreader
X-No-Archive
X-Priority
X-Sender
X-UIDL
X-URI
X-URL
X-X-Sender
X400-Content-Return


Appendix B: Alphabetical index


Section
-------
Header field
------------
3.3
Also-Control
3.3
Alternate-Recipient
3.4
Apparently-To
3.4
Approved
3.6
Article-Names
3.6
Article-Updates
3.17
Auto-Forwarded
3.4
bcc
3.4
cc

Client, see Originating-Client

Comment, see For-Comment
3.7
Comments
3.6
Content-Alias
3.6
Content-Base
3.12
Content-Conversion
3.7
Content-Description
3.3
Content-Disposition
3.6
Content-ID
3.7
Content-Identifier
3.10
Content-Language see also Language
3.11
Content-Length
3.6
Content-Location
3.15
Content-MD5
3.4
Content-Return
3.13
Content-SGML-Entity
3.13
Content-Transfer-Encoding
3.13
Content-Type
3.3
Control
3.12
Conversion
3.12
Conversion-With-Loss

Copy, see Incomplete-Copy
3.8
Date

Date, see also Delivery-Date, Received, Expires, Expiry-Date
3.8
Delivery-Date

Delivery-Report, see Generate-Delivery-Report, Prevent-Delivery-Report, Non-Delivery-Report, Content-Type

Description, see Content-Description
3.17
Discarded-X400-IPMS-Extensions
3.17
Discarded-X400-MTS-Extensions
3.3
Disclose-Recipients

Disposition, see also Content-Disposition
3.5
Disposition-Notification-Options
3.5
Disposition-Notification-To
3.4
Distribution
3.2
DL-Expansion-History-Indication
3.13
Encoding see also Content-Transfer-Encoding
3.4
Errors-To
3.8
Expires
3.8
Expiry-Date

Extension see Discarded-X400-IPMS-Extensions, Discarded-X400-MTS-Extensions
3.4
Fax
3.17
Fcc
3.4
Followup-To
3.4
For-Approval
3.4
For-Comment
3.4
For-Handling

Forwarded, see Auto-Forwarded
3.4
From
3.4
Generate-Delivery-Report

Handling, see For-Handling

History, see DL-Expansion-History-Indication

ID, see Content-ID and Message-ID

Identifier, see Content-ID and Message-ID
3.9
Importance
3.6
In-Reply-To
3.9
Incomplete-Copy
3.7
Keywords

Label, see PICS-Label
3.10
Language see also Content-Language

Length see Content-Length
3.11
Lines
3.16
List-Archive
3.16
List-Help
3.16
List-ID
3.16
List-Owner
3.16
List-Post
3.16
List-Software
3.16
List-Subscribe
3.16
List-Unsubscribe

Loss, see Conversion-With-Loss
3.4
Mail-System-Version see also X-mailer
3.4
Mailer

MD5 see Content-MD5
3.6
Message-ID
3.13
Message-Type
3.3
MIME-Version
3.4
Newsgroups

Newsreader, see X-Newsreader
3.6
Obsoletes
3.7
Organisation
3.7
Organization
3.3
Original-Encoded-Information-Types
3.6
Original-Recipient
3.4
Originating-Client
3.4
Originator-Info see also Sender
3.2
Path
3.4
Phone
3.9
PICS-Label
3.9
Precedence
3.4
Prevent-NonDelivery-Report
3.9
Priority
3.2
Received

Recipient, see To, cc, bcc, Alternate-Recipient, Disclose-Recipient
3.6
References
3.8
Reply-By
3.4
Reply-To, see also In-Reply-To, References
3.14
Resent-

Return see also Content-Return
3.2
Return-Path
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
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

Version, see MIME-Version, X-Mailer
3.4
X-Envelope-From
3.4
X-Envelope-To
3.16
X-List-Host
3.16
X-Listserver
3.4
X-Mailer see also Mail-System-Version
3.13
X-MIME-Autoconverted
3.4
X-Newsreader
3.17
X-No-Archive
3.9
X-Priority
3.4
X-Sender see also Originator-Info
3.6
X-UIDL
3.6
X-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