Network Working Group Jacob Palme Internet Draft Stockholm draft-palme-mailext-headers-08.txt University/KTH Category: Informational Sweden Revision of: RFC 2076 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 Abstract 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 Used to mark header fields which are usage" 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 Used to mark header fields defined for use in e- only in RFC 1036 for use in Usenet mail" 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 DL- RFC 2156, not passed. Expansion- for general History: usage. List of MTAs passed. Path: RFC 1036: 2.1.6, only in Usenet News, not in e-mail. Trace of MTAs which a Received: RFC 2822: RFC message has passed. 1123: 5.2.8. Used to convey the Return- RFC 821, information from the MAIL Path: RFC 1123: FROM envelope attribute in 5.2.13. final delivery, when the message leaves the SMTP environment in which "MAIL FROM" is used. The netnews host, to which NNTP- Non-standard, this article was originally Posting- common in posted. Useful for finding Host: netnews the sender of spams. Since this header is added by the news server, it is a little more difficult to forge than other header fields. **** 3.3 Format and control information Special Usenet News commands Also- son-of-RFC1036 and a normal article at the Control: [21], non- same time. standard, only in Usenet News, not in e-mail Controls whether this Alternate- RFC 2156, not message may be forwarded to Recipient: for general alternate recipients such as usage. a postmaster if delivery is not possible to the intended recipient. Default: Allowed. Whether a MIME body part is Content- RFC 2183, to be shown inline or is an Disposition experimental attachment; can also : indicate a suggested filename for use when saving an attachment to a file. Can have the values "voice- Message- Non-standard message", "fax-message", Context: "pager-message", "multimedia- message", "text-message", "none" Only in Usenet News, Control: RFC 1036: contains commands to be 2.1.6, only in performed by News agents. Usenet News, not in e-mail. Whether recipients are to be Disclose- RFC 2156, not told the names of other Recipients: for general recipients of the same usage. message. This is primarily an X.400 facility. In X.400, this is an envelope attribute and refers to disclosure of the envelope recipient list. Disclosure of other recipients is in Internet mail done via the To:, cc: and bcc: header fields. An indicator that this MIME- RFC 2045: 4. message is formatted Version: according to the MIME standard, and an indication of which version of MIME is utilized. Which body part types occur Original- RFC 2156, not in this message. Encoded- for general Information- usage. Types: **** 3.4 Sender and recipient indication Inserted by Sendmail when Apparently- Non-standard, there is no "To:" recipient To: discouraged, in the original message, mentioned in listing recipients derived RFC 1211. 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. Name of the moderator of the Approved: RFC 1036: newsgroup to which this 2.2.11, not article is sent; necessary standardized on an article sent to a for use in e- moderated newsgroup to allow mail. its distribution to the newsgroup members. Also used on certain control messages, which are only performed if they are marked as Approved. Name of the moderator of a Approved- Non-standard, mailing list, and who has By: used by some approved this message for mailing list distribution to the members expansion of the list. systems. Recipients not to be bcc: RFC 2822:, disclosed to other RFC 1123: recipients. (bcc = Blind 5.2.15-16, Carbon Copy). 5.3.7, RFC 2156, RFC 2532, RFC 3297. Secondary, informational cc: RFC 2822:, recipients. (cc = Carbon RFC 1123. Copy) 5.2.15-16, 5.3.7. Geographical or Distributio RFC 1036: organizational limitation on n: 2.2.7, not where this article can be standardized distributed. Value can be a for use in e- compete or incomplete domain mail. names, also various special values are accepted like "world", "usenet", "USA", etc. Fax number of the Fax:, Non-standard. originator. Telefax: Primary recipients, who are For- Non-standard requested to approve the Approval: information in this message or its attachments. Primary recipients, who are For- Non-standard requested to comment on the Comment: information in this message or its attachments. Primary recipients, who are For- Non-standard requested to handle the Handling: information in this message or its attachments. (2) Used in Usenet News mail From RFC 976: 2.4 transport, to indicate the or for use in path through which an >From Usenet News article has gone when (not transferred to a new host. followed by a colon) Sometimes called "From_" header field. (1) This header field should From (not not never appear in e-mail being followed by standardized sent, and should thus not a colon) for use in e- appear in this memo. It is mail however included, since people often ask about it. This header field is used in the so-called Unix mailbox format, also known as Berkely mailbox format or the MBOX format. This is a format for storing a set of messages in a file. A line beginning with "From " is used to separate successive messages in such files. This header field will thus appear when you use a text editor to look at a file in the Unix mailbox format. Some mailers also use this format when printing messages on paper. The information in this header field should NOT be used to find an address to which replies to a message are to be sent. Authors or persons taking From: RFC 2822:, responsibility for the RFC 1123: message. 5.2.15-16, 5.3.7, Note difference from the RFC 1036 2.1.1 "From " header field (not followed by ":") below. Information about the client Mail-System- Non-standard. software of the originator. Version:, Mailer:, Originating- Client:, X- Mailer, X- Newsreader, X-MimeOLE:, User-Agent: In Usenet News: group(s) to Newsgroups: RFC 1036: which this article was 2.1.3, not posted. standardized Some systems provide this and header field also in e-mail controversial although it is not for use in e- standardized there. mail. 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:". Sometimes used in Usenet Originator: Non-standard in News in similar ways to Usenet News, "Sender:" Experimental in RFC 1528. Also used in printing protocols. Contains information about Originator- Non-standard the authentication of the Info: [25] originator in a format which is not easily used to send email to, to avoid the problems with "Sender" and "X-Sender". Phone number of the Phone: Non-standard. originator. The person or agent Sender: RFC 822: 4.4.2, submitting the message to RFC 2822 3.6.2, the network, if other than RFC 1123: shown by the From: header 5.2.15-16, field. Should be 5.3.7, RFC authenticated, 1036. according to RFC 822, but what kind of authentication is not clear. Some implementations expect that the e-mail address used in this field can be used to reach the sender, others do not. See also "X-Sender". Primary recipients. To: RFC 2822:, RFC 1123: 5.2.15-16, 5.3.7. If the sender in the X-Envelope- Non-standard. envelope (SMTP "RCTP TO") is From: 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. If the recipient in the X-Envelope- Non-standard. envelope (SMTP "MAIL FROM") To:, is not included in the CC Envelope- list, some mail servers add To: this to the RFC 2822 header field as an aid to clients which would otherwise not be able to display the envelope recipients. 48x48 bitmap with picture of X-Face: Non-Standard the sender of this message. Indication in the mail X-RCPT-TO: Non-standard header of recipient on the SMTP envelope. Some mail software expect X-Sender: Non-standard "Sender:" to be an e-mail address which you can send mail to. However, some mail software has as the best authenticated sender a POP or IMAP account, which you might not be able to send to. Because of this, some mail software put the POP or IMAP account into an X- sender header field instead of a Sender header field, to indicate that you may not be able to send e-mail to this address. See also "X-X- 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. Even though some systems put X-X-Sender: Non-standard 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:" When a message is sent both Posted-To: Non-standard 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. E-mail address of X-Admin: Non-standard administrator of a server, through which this message was submitted. **** 3.5 Response control Indicates whether the Content- RFC 2156, not content of a message is to Return: for general be returned with non- usage. delivery notifications. For future options on Disposition- RFC 2298 disposition notifications. Notificatio n-Options: Indicate that the sender Disposition- RFC 2298 wants a dispoisition Notificatio notification when this n-To: message is received (read, processed, etc.) by its receipents. Address to which Errors-To:, Non-standard, notifications are to be sent Return- discouraged, and a request to get Receipt- some of them delivery notifications. To:, widely used. Internet standards Read- recommend, however, the use Receipt- of MAIL FROM and Return- To:, X- Path, not Errors-To, for Confirm- where delivery notifications reading- are to be sent. to:, Return- Receipt- Requested, Registered- Mail-Reply- Requested- By: Used in Usenet News to Followup- RFC 1036: indicate that future To: 2.2.3, not discussions (=follow-up) on standardized an article should go to a for use in e- different set of newsgroups mail. 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. Whether a delivery report is Generate- RFC 2156, not wanted at successful Delivery- for general delivery. Default is not to Report: usage. generate such a report. Original Recipient Original- RFC 2298 information for inclusion in Recipient disposition notifications. Whether non-delivery report Prevent- RFC 2156, not is wanted at delivery error. NonDelivery- for general Default is to want such a Report: usage. report. This header field is meant Reply-To: RFC 2822:, to indicate where the sender RFC 1036: 2.2.1 wants replies to go. controversial. 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.). Some mail systems use this Reply-To2 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 Mail- Non-standard, replies to this message Followup- see should be sent, which are To: http://cr.yp.to intended for all who read /proto/replyto. the replied-to message, not html only for its author. Similar to "Reply-To:" but Mail-Reply- Non-standard, more unambiguosly specifies To: see that this is the address for http://cr.yp.to rpelies to the author only, /proto/replyto. not to any other recipients html of the replied-to message. Indicates where to send Abuse- non-standard complains if you get a Reports- message which you think is To:, X- against the laws or rules. Complaints- To:, X- Report- Abuse-To: Used in netnews articles to Mail-Copies- non-standard, indicate that followup To: but commonly (=replies) should be sent to supported by the indicated e-mail newsreaders address. Possible future change of X400- non-standard name for "Content-Return:" Content- Return: **** 3.6 Message identification and referral header fields Reference to specially Article- son-of-RFC1036 important articles for a Names: [21], non- particular Usenet Newsgroup. standard Only in Usenet News, similar Article- son-of-RFC1036 to "Supersedes:" but does Updates: [21], non- not cause the referenced standard article to be physically deleted. Used in addition to Content- Content- Work in Location if this content Alias: progress 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. Base to be used for Content- RFC 2110 resolving relative URIs Base: within this content part. Unique ID of one body part Content-ID: RFC 2045: 7. of the content of a message. URI with which the content Content- RFC 2110 of this content part might Location: be retrievable. Used by some automatic Delivered- non-standard services (mainly MLMs and To: autoresponders) for the or purpose of loop detection. X-Loop: The service adds the Delivered-To header to outgoing messages, with its e-mail address as a value, and discards incoming messages which already have it. Reference to message which In-Reply- RFC 2822 this message is a reply to. 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. Unique ID of this message. Message-ID: RFC 2822, RFC 1036: 2.1.5. Reference to previous Obsoletes: RFC 2156, not message being corrected and for general replaced. Compare to usage. "Supersedes:" below. This field may in the future be replaced with "Supersedes:". The "References:" field will References: RFC 2822, contain the contents of the RFC 1036: parent's "References:" field 2.1.5. (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. Still another name for Replaces: non-standard, similar functionality as for proposed in "Obsoletes:" and IETF USEFOR "Supersedes:". This may working group become the most recommended header in the future, but is still under discussion in IETF standards development work. References to other related See-Also: Son-of-RFC1036 articles in Usenet News. [21], non- standard Commonly used in Usenet News Supersedes: son-of-RFC1036 in similar ways to the [21], non- "Obsoletes" header field standard described above. In Usenet News, however, Supersedes causes a full deletion of the replaced article in the server, while "Supersedes" and "Obsoletes" in e-mail is implemented in the client and often does not remove the old version of the text. Mailbox of the person who Translated- non-standard made the translation. By: Reference to the Message-ID Translation- non-standard of a message, which the Of: current message is a translation of. Unique identifier for a X-UIDL: non-standard message, local to a particular local mailbox store. The UIDL identifier is defined in the POP3 standard, but not the "X- UIDL:" header. Similar usage as "X-URL". X-URI: Non-standard The URI can be either a URL or a URN. URNs are meant to become more persistent references to resources than URLs. Sometimes used with the same X-URL: Non-standard meaning as "Content- Location:", sometimes to indicate the web home page of the sender or of his organisation. The UID, as defined in the X-IMAP: Non-standard IMAP standard. Only used in internal mailbox storage in some mail systems, should never be visible to a user. **** 3.7 Other textual header fields Comments on a message. Comments: RFC 2822 Description of a particular Content- RFC 2045: 8. body part of a message, for Description example a caption for an : image body part. A text string which Content- RFC 2156, not identifies the content of a Identifier: for general message. usage. Search keys for data base Keywords: RFC 2822 retrieval. RFC 1036: 2.2.9. See Organization above. Organisatio Non-standard. n: Organization to which the Organizatio RFC 1036: sender of this article n: 2.2.8, not belongs. standardized for use in e- mail. Title, heading, subject. Subject: RFC 2822, Often used as thread RFC 1036: indicator for messages 2.1.4. replying to or commenting on other messages. Short text describing a Summary: RFC 1036: longer article. Warning: 2.2.10, not Some mail systems will not standardized display this text to the for use in e- recipient. Because of this, mail, do not use this header field discouraged. for text which you want to ensure that the recipient gets. **** 3.8 Header fields containing dates and times In Internet, the date when a Date: RFC 2822, message was written, in RFC 1123: X.400, the time a message 5.2.14 was submitted. Some Internet RFC 1036: mail systems also use the 2.1.2. date when the message was submitted. The time when a message was Delivery- RFC 2156, not delivered to its recipient. Date: for general usage. A suggested expiration date. Expires: RFC 1036: Can be used both to limit 2.2.4, not the time of an article which standardized is not meaningful after a for use in e- certain date, and to extend mail. the storage of important articles. Time at which a message Expiry- RFC 2156, not loses its validity. This Date: for general field may in the future be usage. replaced by "Expires:". Latest time at which a reply Reply-By: RFC 2156, not is requested (not demanded). for general usage. Time when this message was X-OriginalA Non-standard delivered into the message rrivalTime: transport system (usually the same time as in the last "Received:" header) **** 3.9 Quality information A hint from the originator Importance: RFC 2156 and to the recipients about how RFC 2421, important a message is. proposed Values: High, normal or low. Not used to control transmission speed. Body parts are missing. Incomplete- RFC 2156, not Copy: for general usage. Ratings label to control PICS-Label: REC-PICS- selection (filtering) of labels, W3C messages according to the document [23]. PICS protocol. Sometimes used as a (a) Precedence: Non-standard, priority value which can controversial, influence transmission speed widely used. and delivery. Common values Because it is are "bulk" and "first- used for so class". Other uses is to (b) many different control automatic replies purposes, there like delivery status reports is a risk that and vacation notices and to creator and (c) control return-of- user of this content facilities, and to header mean (d) stop mailing list loops, different (e) things. Can be "normal", "urgent" or Priority: RFC 2156, not "non-urgent" and can for general influence transmission speed usage. and delivery. How sensitive it is to Sensitivity RFC 2156 and disclose this message to : RFC 2421, other people than the proposed 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. Yet another priority X-MSMail- Non-standard indication. Priority: Values: 1 (Highest), 2 X-Priority: Non-standard (High), 3 (Normal), 4 (Low), [24] 5 (Lowest). 3 (Normal) is default if the field is omitted. **** 3.10 Language information Can include a code for the Content- RFC 1766, natural language used in a Language: proposed message, e.g. "en" for standard. English. Can include a code for the Language: RFC 2156, not natural language used in a for general message, e.g. "en" for usage. English. **** 3.11 Size information Inserted by certain mailers Content- Non-standard, to indicate the size in Length: discouraged. 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. 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 Content- Non-standard alternative variant of this Alternative [27]. document might be found. : Non-standard variant of Content- Non-standard. Conversion: with the same Conversion: values. The body of this message may Conversion: RFC 2156, not not be converted from one for general character set to another. usage. Values: Prohibited and allowed. The body of this message may Conversion- RFC 2156, not not be converted from one With-Loss: for general character set to another if usage. information will be lost. Values: Prohibited and allowed. **** 3.13 Encoding information Type information of the Content- non-standard content in some class Class: hierarchy. Class hierarchies are commonly used to classify data structures in software development. Can give more detailed Content- Proposed information about the Features: Standard, RFC Content-Type. Example: 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 Content- non-standard entity declaration SGML- corresponding to the entity Entity: contained in the body of the body part. Coding method used in a MIME Content- RFC 2045: 6. message body. Transfer- Encoding: Format of content (character Content- RFC 1049, set etc.) Note that the Type: RFC 1123: values for this header field 5.2.13, are defined in different RFC 1766: 4.1 ways in RFC 1049 and in MIME RFC 2045: 5. (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. Used in several different Encoding: RFC 1154, ways by different mail RFC 1505, systems. Some use it for a experimental. kind of content-type information, some for encoding and length information, some for a kind of boundary information, some in other ways. Only used with the value Message- RFC 2156, not "Delivery Report" to Type: for general indicates that this is a usage. delivery report gatewayed from X.400. Information about conversion X-MIME- non-standard of this message on the path Autoconverte from sender to recipient, d: like conversion between MIME encoding formats. Note: Auto- conversion may invalidate digital seals and signatures. **** 3.14 Resent-header fields When manually forwarding a Resent- RFC 2822 message, header fields Reply-To:, referring to the forwarding, Resent- not to the original message. From:, Note: MIME specifies another Resent- way of resending messages, Sender:, using the "Message" Content- Resent- Type. Date:, Resent-To:, Resent-cc:, Resent- bcc:, Resent- Message-ID: **** 3.15 Security and reliability Checksum of content to Content- RFC 1864, ensure that it has not been MD5: proposed modified. standard. Used in Usenet News to store Xref: RFC 1036: information to avoid showing 2.2.13, only in a reader the same article Usenet News, twice if it was sent to more not in e-mail. than one newsgroup. Only for local usage within one Usenet News server, should not be sent between servers. Used in Usenet News to stop Cancel- Non-standard rough cancels. Lock:, Crypthographic methods are Cancel-Key used to ensure that only the original author of an article can cancel it. **** 3.16 Mailing list control Contains URL to use to List- RFC 2369 [26] browse the archives of the Archive: mailing list from which this message was relayed. URL to use to get a List- Non-standard subscription to the digest Digest: version of the mailing list from which this message was relayed. Contains URL to use to get a List-Help: RFC 2369 [26] information about the mailing list from which this message was relayed. Stores an identification of List-ID: RFC 2919 [27]. the mailing list, through which this message was distributed. Non-standard precursors to Mailing- Non-standard List-ID and List-Post. List:, X- Mailing- List: Contains URL to send e-mail List-Owner: RFC 2369 [26] to the owner of the mailing list from which this message was relayed. Contains URL to use to send List-Post: RFC 2369 [26] contributions to the mailing list from which this message was relayed. Information about the List- Non-standard, software used in a mailing Software: has been list expander through which considered for this message has passed. inclusion in [26]. Contains URL to use to get a List- RFC 2369 [26] subscription to the mailing Subscribe: list from which this message was relayed. Contains URL to use to List- RFC 2369 [26] unsubscribe the mailing list Unsubscribe from which this message was : relayed. Contains URL where List-URL: Non-standard information of various kinds about the mailing list from which this message was relayed. Information about the server X- Non-standard. and software used in a Listserver: Recommended to mailing list expander , X-List- use "List- through which this message Host: Software" has passed. Warning: instead. "Listserv" is a trademark and should not be used for other than the "Listserv" product. Use, instead the "List-Software" header field. **** 3.17 Miscellaneous Has been automatically Autoforward RFC 2156, not forwarded. ed: for general usage. Can be used in Internet mail Discarded- RFC 2156, not to indicate X.400 IPM X400-IPMS- for general extensions which could not Extensions: usage. be mapped to Internet mail format. Can be used in Internet mail Discarded- RFC 2156, not to indicate X.400 MTS X400-MTS- for general extensions which could not Extensions: usage. be mapped to Internet mail format. Name of file in which a copy Fcc: Non-standard. of this message is stored. Speech act categoriztion of Speech-Act: Non-standard a message, examples of speeach acts are Question, Idea, More, Promise, Sad, Happy, Angry, summary, Decision This field is used by some Status: Non-standard, mail delivery systems to should never indicate the status of appear in mail delivery for this message in transit. 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. Do not archive this message X-No- Non-standard in publicly available Archive: archives. Yes 4. Acknowledgments Harald Tveit Alvestrand, Neil Carpenter, William C. Carpenter, Rob Chandhok, Ned Freed, Olle Jrnefors, 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 Jrnefors for their thorough review and many helpful suggestions for improvements. I alone take responsibility for any errors which may still be in the list. An earlier version of this list has been published as part of [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 Proposed Protocol", RFC 2821, April 2001. Standard [2] P. Resnick: "Internet Message Format" Proposed STD 11, RFC 2822, April 2001. Standard [3] M.R. Horton, R. Adams: "Standard for Not an interchange of USENET messages", RFC offi-cial 1036, December 1987. IETF standard, but in reality a de-facto standard for Usenet News [4] M. Sirbu: "A Content-Type header Historic field header field for internet messages", RFC 1049, March 1988. [5] R. Braden (editor): "Requirements for Standard, Internet Hosts -- Application and Required Support", STD-3, RFC 1123, October 1989. [6] D. Robinson, R. Ullman: "Encoding Non- Header field for Internet Messages", standard RFC 1505, August 1993. [7] S. Hardcastle-Kille: "Mapping between Proposed X.400(1988) / ISO 10021 and RFC standard, 2822", RFC 2156 January 1998. elective [8] H. Alvestrand & J. Romaguera: "Rules Proposed for Downgrading Messages from standard, X.400/88 to X.400/84 When MIME elective Content-Types are Present in the Messages", RFC 1496, August 1993. [9] A. Costanzo: "Encoding Header field Non- Header field for Internet Messages", standard RFC 1154, April 1990. [10] A. Costanzo, D. Robinson: "Encoding Experiment Header field Header field for al Internet Messages", RFC 1505, August 1993. [11] N. Freed & N. Borenstein: "MIME Draft (Multipurpose Internet Mail Standard, Extensions) Part One: Format of elective Internet Message Bodies. RFC 2045. November 1996. [12] H. Alvestrand: "Tags for the Best Identification of Languages", RFC Current 3066, January 2001. Practice, elective [13] J. Palme: "Electronic Mail", Artech Non- House publishers, London-Boston standard January 1995. [14] R. Troost, S. Dorner: "Communicating Experimental Presentation Information in Internet Messages: The Content-Disposition Header field", RFC 2183, June 1995. [15] B. Kantor, P. Lapsley, "Network News Proposed Transfer Protocol: "A Proposed standard Standard for the Stream-Based Transmission of News", RFC 977, January 1986. [16] 1848 PS S. Crocker, N. Freed, J. Proposed Galvin, S. Murphy, "MIME Object standard Security Services", RFC 1848, March 1995. [17] J. Myers, M. Rose: The Content-MD5 Draft Header field Header field, RFC 1864, standard October 1995. [18] M. Horton, UUCP mail interchange Not an format standard, RFC 976, Januari offi-cial 1986. IETF standard, but in reality a de-facto standard for Usenet News [19] R. Fielding, J. Gettys, J. Mogul, H. Draft Frystyk, L. Masinter, P. Leach, T. standard Berners-Lee: Hypertext Transfer Protocol -- HTTP/1.1, June 1999. [20] G. Vaudreuil: Voice Profile for Proposed Internet Mail, RFC 2421 Feburary 1998. [21] H. Spencer: News Article Format and Not even an Transmission, June 1994, RFC, but FTP://zoo.toronto.edu/pub/news.ps.Z still FTP://zoo.toronto.edu/pub/news.txt.Z widely used and partly This document is often referenced almost a de- under the name "son-of-RFC1036". facto standard for Usenet News [23] PICS Label Distribution Label Syntax Other and Communication Protocols, World standard Wide Web Consortium, October 1996. [24] Eudora Pro Macintosh User Manual, Non- Qualcomm Inc., 1988-1995. standard [25] C. Newman: Originator-Info Message Non- Header field. work in progress, July standard 1997. [26] Grant Neufeld and Joshua D. Baer: The Proposed Use of URLs as Meta-Syntax for Core standard Mail List Commands and their Transport through Message Header fields, RFC 2369, July 1998. [27] G. Klyne (ed.): Content Negotiation Non- for Facsimile Using Internet Mail, standard Work in progress, March 2000. [27] R. Chandhok, G. Wenger: List-IDE: A Proposed Structured Field and Namespace for standard the Identification if Mailing Lists, RFC 2919, March 2001. [28] Jukka "Yucca" Korpela: Quick Non- reference to Internet message standard headers, http://www.cs.tut.fi/~jkorpela/header s.html, October 2001. 6. Author's address Jacob Palme Phone: +46-8-16 16 67 Stockholm University/KTH Fax: +46-8-783 08 29 Forum 100 E-mail: jpalme@dsv.su.se S-164 40 Kista, Sweden Appendix A: Header fields sorted by Internet RFC document in which they appear. RFC 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 Sectio Header field n ------------ ------ - 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
Datatracker
Report a datatracker bug
draft-palme-mailext-headers-08
None
| Document | Document type |
Expired Internet-Draft
(individual in gen area)
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Author |
Jacob Palme
Email authors |
||
| RFC stream |
|
||
| Intended RFC status | Informational | ||
| Other formats |