Network Working Group Jacob Palme Internet Draft Stockholm University/KTH draft-palme-mailext-headers-01.txt Sweden Category: Informational Date: May 1999 Revision of: RFC 2076 Expires: November 1999 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. The latest, revised version of this document is available in plain text, HTML and Adobe Acrobat format at URL http://www.dsv.su.se/~jpalme/ietf/jp-ietf-home.html#anchor1003783 Table of contents Abstract 1 1. Introduction 3 2. Use of gatewaying header fields 6 3. Table of header fields 6 3.1 Phrases used in the tables 6 3.2 Trace information 8 3.3 Format and control information 8 3.4 Sender and recipient indication 9 3.5 Response control 14 3.6 Message identification and referral header fields 17 3.7 Other textual header fields 19 3.8 Header fields containing dates and times 20 3.9 Quality information 20 3.10 Language information 21 3.11 Size information 22 3.12 Conversion control 22 3.13 Encoding information 22 3.14 Resent-header fields 24 3.15 Security and reliability 24 3.16 Mailing list control 25 3.17 Miscellaneous 26 4. Acknowledgments 27 Copyright and disclaimer 28 5. References 28 6. Author's address 31 Appendix A: Header fields sorted by Internet RFC document in which they appear. 31 RFC 822 31 RFC 976 32 RFC 1036 32 RFC 1049 33 RFC 1327 33 RFC 1505 33 RFC 2045 33 RFC 1806 34 RFC 1911 34 RFC 2110 34 RFC 2369 34 son-of-RFC1036 [21] 34 draft-ietf-receipt 35 World Wide Web Consortium (W3C) Recommendations 35 Not Internet standard 35 Appendix B: Alphabetical index 36 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://www.dsv.su.se/~jpalme/ietf/ietf-mail-attributes.html http://www.dsv.su.se/~jpalme/ietf/mail-attributes.html and http://www.dsv.su.se/~jpalme/ietf/mail-attributes.pdf Please e-mail me (Jacob Palme <jpalme@dsv.su.se>) if you have noted header fields which should be included in this memo but are not. 2. Use of gatewaying header fields RFC 1327 defines a number of new header fields in Internet mail, which are defined to map header fields which X.400 has but which were previously not standardized in Internet mail. The fact that a header field occurs in RFC 1327 indicates that it is recommended for use in gatewaying messages between X.400 and Internet mail, but does not mean that the header field is recommended for messages wholly within Internet mail. Some of these header fields may eventually see widespread implementation and use in Internet mail, but at the time of this writing (1996) they are not widely implemented or used. Header fields defined only in RFC 1036 for use in Usenet News sometimes appear in mail messages, either because the messages have been gatewayed from Usenet News to e-mail, or because the messages were written in combined clients supporting both e-mail and Usenet News in the same client. These header fields are not standardized for use in Internet e-mail and should be handled with caution by e-mail agents. 3. Table of header fields 3.1 Phrases used in the tables "not for general Used to mark header fields which are defined usage" in RFC 1327 for use in messages from or to Internet mail/X.400 gateways. These header fields have not been standardized for general usage in the exchange of messages between Internet mail-based systems. "not standardized Used to mark header fields defined only in RFC for use in e-mail" 1036 for use in Usenet News. These header fields have no standard meaning when appearing in e-mail, some of them may even be used in different ways by different software. When appearing in e-mail, they should be handled with caution. Note that RFC 1036, although generally used as a de-facto standard for Usenet News, is not an official IETF standard or even on the IETF standards track. "non-standard" This header field is not specified in any of referenced RFCs which define Internet protocols, including Internet Standards, draft standards or proposed standards. The header field appears here because it often appears in e-mail or Usenet News. Usage of these header fields is not in general recommended. Some header field proposed in ongoing IETF standards development work, but not yet accepted, are also marked in this way. "discouraged" This header field, which is non-standard, is known to create problems and should not be generated. Handling of such header fields in incoming mail should be done with great 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 Return-Path: RFC 821, from the MAIL FROM envelope RFC 1123: 5.2.13. attribute in final delivery, when the message leaves the SMTP environment in which "MAIL FROM" is used. Trace of MTAs which a message has Received: RFC 822: 4.3.2, passed. RFC 1123: 5.2.8. List of MTAs passed. Path: RFC 1036: 2.1.6, only in Usenet News, not in e- mail. Trace of distribution lists DL-Expansion- RFC 1327, not for passed. History- general usage. Indication: 3.3 Format and control information An indicator that this message is MIME-Version: RFC 2045: 4. formatted according to the MIME standard, and an indication of which version of MIME is utilized. Only in Usenet News, contains Control: RFC 1036: 2.1.6, commands to be performed by News only in Usenet agents. News, not in e- mail. Special Usenet News commands and Also-Control: son-of-RFC1036 a normal article at the same [21], non- time. standard, only in Usenet News, not in e-mail Which body part types occur in Original- RFC 1327, not for this message. Encoded- general usage. Information- Types: Controls whether this message may Alternate- RFC 1327, not for be forwarded to alternate Recipient: general usage. recipients such as a postmaster if delivery is not possible to the intended recipient. Default: Allowed. Whether recipients are to be told Disclose- RFC 1327, not for the names of other recipients of Recipients: general usage. the same message. This is primarily an X.400 facility. In X.400, this is an envelope attribute and refers to disclosure of the envelope recipient list. Disclosure of other recipients is in Internet mail done via the To:, cc: and bcc: header fields. Whether a MIME body part is to be Content- RFC 1806, shown inline or is an attachment; Disposition: experimental can also indicate a suggested filename for use when saving an attachment to a file. 3.4 Sender and recipient indication Authors or persons taking From: RFC 822: 4.4.1, responsibility for the message. RFC 1123: 5.2.15- 16, 5.3.7, Note difference from the "From " RFC 1036 2.1.1 header field (not followed by ":") below. (1) This header field should From (not not standardized never appear in e-mail being followed by a for use in e-mail sent, and should thus not appear colon) in this memo. It is however included, since people often ask about it. This header field is used in the so-called Unix mailbox format, also known as Berkely mailbox format or the MBOX format. This is a format for storing a set of messages in a file. A line beginning with "From " is used to separate successive messages in such files. This header field will thus appear when you use a text editor to look at a file in the Unix mailbox format. Some mailers also use this format when printing messages on paper. The information in this header field should NOT be used to find an address to which replies to a message are to be sent. (2) Used in Usenet News mail From RFC 976: 2.4 for transport, to indicate the path or use in Usenet News through which an article has gone >From when transferred to a new host. (not followed by a colon) Sometimes called "From_" header field. Name of the moderator of the Approved: RFC 1036: 2.2.11, newsgroup to which this article not standardized is sent; necessary on an article for use in e-mail. sent to a moderated newsgroup to allow its distribution to the newsgroup members. Also used on certain control messages, which are only performed if they are marked as Approved. The person or agent submitting Sender: RFC 822: 4.4.2, the message to the network, if RFC 1123: 5.2.15- other than shown by the From: 16, 5.3.7, RFC header field. Should be 1036. 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". Sometimes used in Usenet News in Originator: Non-standard similar ways to "Sender:" Some mail software expect X-Sender: Non-standard "Sender:" to be an e-mail address which you can send mail to. However, some mail software has as the best authenticated sender a POP or IMAP account, which you might not be able to send to. Because of this, some mail software put the POP or IMAP account into an X-sender header field instead of a Sender header field, to indicate that you may not be able to send e-mail to this address. See also "X-X- 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 the X-X-Sender: Non-standard POP or IMAP account name into the "X-Sender:" instead of the Sender header field, some mail software tries to send to the "X-Sender:" too. To stop this, some systems have begun to use "X-X-Sender:" to indicate an authentication of the sender which might not be useable to send e-mail to. See also "Originator-Info:" Contains information about the Originator- Non-standard [25] authentication of the originator Info: in a format which is not easily used to send email to, to avoid the problems with "Sender" and "X- Sender". Primary recipients. To: RFC 822: 4.5.1, RFC 1123: 5.2.15- 16, 5.3.7. Secondary, informational cc: RFC 822: 4.5.2, recipients. (cc = Carbon Copy) RFC 1123. 5.2.15- 16, 5.3.7. Recipients not to be disclosed to bcc: RFC 822: 4.5.3, other recipients. (bcc = Blind RFC 1123: 5.2.15- Carbon Copy). 16, 5.3.7. Primary recipients, who are For-Handling: Non-standard requested to handle the information in this message or its attachments. Primary recipients, who are For-Comment: Non-standard requested to comment on the information in this message or its attachments. Primary recipients, who are For-Approval: Non-standard requested to approve the information in this message or its attachments. In Usenet News: group(s) to which Newsgroups: RFC 1036: 2.1.3, this article was posted. not standardized Some systems provide this header and controversial field also in e-mail although it for use in e-mail. is not standardized there. Unfortunately, the header field can appear in e-mail with 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. Inserted by Sendmail when there Apparently- Non-standard, is no "To:" recipient in the To: discouraged, original message, listing mentioned in recipients derived from the RFC 1211. envelope into the message heading. This behavior is not quite proper, MTAs should not modify headings (except inserting Received lines), and it can in some cases cause Bcc recipients to be wrongly divulged to non-Bcc recipients. Geographical or organizational Distribution: RFC 1036: 2.2.7, limitation on where this article not standardized can be distributed. Value can be for use in e-mail. a compete or incomplete domain names, also various special values are accepted like "world", "usenet", "USA", etc. Fax number of the originator. Fax:, Non-standard. Telefax: Phone number of the originator. Phone: Non-standard. If the recipient in the envelope X-Envelope-To Non-standard. (SMTP "MAIL FROM") is not included in the CC list, some mail servers add this to the RFC822 header field as an aid to clients which would otherwise not be able to display the envelope recipients. If the sender in the envelope X-Envelope- Non-standard. (SMTP "RCTP TO") is not the same From as the senders in the "From" or "Sender" RFC822 header fields, some mail servers add this to the RFC822 header fields as an aid to clients which would otherwise not be able to display this information. Information about the client Mail-System- Non-standard. software of the originator. Version:, Mailer:, Originating- Client:, X- Mailer, X- Newsreader 3.5 Response control This header field is meant to Reply-To: RFC 822: 4.4.3, indicate where the sender wants RFC 1036: 2.2.1 replies to go. Unfortunately, controversial. this is ambiguous, since there are different kinds of replies, which the sender may wish to go to different addresses. In particular, there are personal replies intended for only one person, and group replies, intended for the whole group of people who read the replied-to message (often a mailing list, anewsgroup name cannot appear here because of different syntax, see "Followup-To" below.). Some mail systems use this header field to indicate a better form of the e-mail address of the sender. Some mailing list expanders puts the name of the list in this header field. These practices are controversial. The personal opinion of the author of this RFC is that this header field should be avoided except in special cases, but this is a personal opinion not shared by all specialists in the area. Used in Usenet News to indicate Followup-To: RFC 1036: 2.2.3, that future discussions (=follow- not standardized up) on an article should go to a for use in e-mail. different set of newsgroups than the replied-to article. The most common usage is when an article is posted to several newsgroups, and further discussions is to take place in only one of them. In e-mail, this header field may occur in a message which is sent to both e-mail and Usenet News, to show where follow-up in Usenet news is wanted. The header field does not say anything about where follow-up in e-mail is to be 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 Errors-To:, Non-standard, are to be sent and a request to Return- discouraged. get delivery notifications. Receipt-To: Internet standards recommend, however, the use of MAIL FROM and Return-Path, not Errors-To, for where delivery notifications are to be sent. Whether non-delivery report is Prevent- RFC 1327, not for wanted at delivery error. Default NonDelivery- general usage. is to want such a report. Report: Whether a delivery report is Generate- RFC 1327, not for wanted at successful delivery. Delivery- general usage. Default is not to generate such a Report: report. Indicates whether the content of Content- RFC 1327, not for a message is to be returned with Return: general usage. non-delivery notifications. Possible future change of name X400-Content- non-standard for "Content-Return:" Return: Indicate that the sender wants a Disposition- RFC 2298 dispoisition notification when Notification- this message is received (read, To processed, etc.) by its receipents. For future options on disposition Disposition- RFC 2298 notifications. Notification- Options Original Recipient information Original- RFC 2298 for inclusion in disposition Recipient notifications. 3.6 Message identification and referral header fields Unique ID of this message. Message-ID: RFC 822: 4.6.1 RFC 1036: 2.1.5. Unique ID of one body part of the Content-ID: RFC 2045: 7. content of a message. Base to be used for resolving Content-Base: RFC 2110 relative URIs within this content part. URI with which the content of Content- RFC 2110 this content part might be Location: retrievable. Used in addition to Content- Content- Work in progress Location if this content part can Alias: be retrieved through more than one URI. Only one of them is allowed in the Content-Location, the other can be specified in Content-Alias. 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. Similar usage as "X-URL". The URI X-URI: Non-standard can be either a URL or a URN. URNs are meant to become more persistent references to resources than URLs. Reference to message which this In-Reply-To: RFC 822: 4.6.2. message is a reply to. In e-mail: reference to other References: RFC 822: 4.6.3 related messages, in Usenet News: RFC 1036: 2.1.5. reference to replied-to-articles. References to other related See-Also: Son-of-RFC1036 articles in Usenet News. [21], non-standard Reference to previous message Obsoletes: RFC 1327, not for being corrected and replaced. general usage. Compare to "Supersedes:" below. This field may in the future be replaced with "Supersedes:". Commonly used in Usenet News in Supersedes: son-of-RFC1036 similar ways to the "Obsoletes" [21], non-standard header field described above. In Usenet News, however, Supersedes causes a full deletion of the replaced article in the server, while "Supersedes" and "Obsoletes" in e-mail is implemented in the client and often does not remove the old version of the text. Still another name for similar Replaces: non-standard, functionality as for "Obsoletes:" proposed in IETF and "Supersedes:". This may USEFOR working become the most recommended group header in the future, but is still under discussion in IETF standards development work. Unique identifier for a message, X-UIDL: non-standard local to a particular local mailbox store. The UIDL identifier is defined in the POP3 standard, but not the "X-UIDL:" header. Only in Usenet News, similar to Article- son-of-RFC1036 "Supersedes:" but does not cause Updates: [21], non-standard the referenced article to be physically deleted. Reference to specially important Article- son-of-RFC1036 articles for a particular Usenet Names: [21], non-standard Newsgroup. Reference to the Message-ID of a Translation- non-standard message, which the current Of: message is a translation of. Mailbox of the person who made Translated- non-standard the translation. By: 3.7 Other textual header fields Search keys for data base Keywords: RFC 822: 4.7.1 retrieval. RFC 1036: 2.2.9. Title, heading, subject. Often Subject: RFC 822: 4.7.1 used as thread indicator for RFC 1036: 2.1.4. messages replying to or commenting on other messages. Comments on a message. Comments: RFC 822: 4.7.2. Description of a particular body Content- RFC 2045: 8. part of a message, for example a Description: caption for an image body part. Organization to which the sender Organization: RFC 1036: 2.2.8, of this article belongs. not standardized for use in e-mail. See Organization above. Organisation: Non-standard. Short text describing a longer Summary: RFC 1036: 2.2.10, article. Warning: Some mail not standardized systems will not display this for use in e-mail, text to the recipient. Because of discouraged. this, do not use this header field for text which you want to ensure that the recipient gets. A text string which identifies Content- RFC 1327, not for the content of a message. Identifier: general usage. 3.8 Header fields containing dates and times The time when a message was Delivery- RFC 1327, not for delivered to its recipient. Date: general usage. In Internet, the date when a Date: RFC 822: 5.1, message was written, in X.400, RFC 1123: 5.2.14 the time a message was submitted. RFC 1036: 2.1.2. Some Internet mail systems also use the date when the message was submitted. A suggested expiration date. Can Expires: RFC 1036: 2.2.4, be used both to limit the time of not standardized an article which is not for use in e-mail. meaningful after a certain date, and to extend the storage of important articles. Time at which a message loses its Expiry-Date: RFC 1327, not for validity. This field may in the general usage. future be replaced by "Expires:". Latest time at which a reply is Reply-By: RFC 1327, not for requested (not demanded). general usage. 3.9 Quality information Can be "normal", "urgent" or "non- Priority: RFC 1327, not for urgent" and can influence general usage. transmission speed and delivery. Values: 1 (Highest), 2 (High), 3 X-Priority: Non-standard [24] (Normal), 4 (Low), 5 (Lowest). 3 (Normal) is default if the field is omitted. Sometimes used as a priority Precedence: Non-standard, value which can influence controversial. transmission speed and delivery. Common values are "bulk" and "first-class". Other uses is to control automatic replies and to control return-of-content facilities, and to stop mailing list loops. A hint from the originator to the Importance: RFC 1327 and recipients about how important a RFC 1911, message is. Values: High, normal experimental or low. Not used to control transmission speed. How sensitive it is to disclose Sensitivity: RFC 1327 and this message to other people than RFC 1911, the specified recipients. Values: experimental Personal, private, company confidential. The absence of this header field in messages gatewayed from X.400 indicates that the message is not sensitive. Body parts are missing. Incomplete- RFC 1327, not for Copy: general usage. Ratings label to control PICS-Label: REC-PICS-labels, selection (filtering) of messages W3C document [23]. according to the PICS protocol. 3.10 Language information Can include a code for the Language: RFC 1327, not for natural language used in a general usage. message, e.g. "en" for English. Can include a code for the Content- RFC 1766, proposed natural language used in a Language: standard. message, e.g. "en" for English. 3.11 Size information Inserted by certain mailers to Content- Non-standard, indicate the size in bytes of the Length: discouraged. message text. This is part of a format some mailers use when showing a message to its users, and this header field should not be used when sending a message through the net. The use of this header field in transmission of a message can cause several robustness and interoperability problems. Size of the message. Lines: RFC 1036: 2.2.12, not standardized for use in e-mail. 3.12 Conversion control The body of this message may not Conversion: RFC 1327, not for be converted from one character general usage. set to another. Values: Prohibited and allowed. Non-standard variant of Content- Non-standard. Conversion: with the same values. Conversion: The body of this message may not Conversion- RFC 1327, not for be converted from one character With-Loss: general usage. set to another if information will be lost. Values: Prohibited and allowed. 3.13 Encoding information Format of content (character set Content-Type: RFC 1049, etc.) Note that the values for RFC 1123: 5.2.13, this header field are defined in RFC 2045: 5. different ways in RFC 1049 and in RFC 1766: 4.1 MIME (RFC 2045), look for the "MIME-version" header field to understand if Content-Type is to be interpreted according to RFC 1049 or according to MIME. The MIME definition should be used in generating mail. RFC 1766 defines a parameter "difference" to this header field. Various other Content-Type define various additional parameters. For example, the parameter "charset" is mandatory for all textual Content-Types. Can give more detailed Content- non-standard information about the Content- Features: 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. Information from the SGML entity Content-SGML- non-standard declaration corresponding to the Entity: entity contained in the body of the body part. Coding method used in a MIME Content- RFC 2045: 6. message body. Transfer- Encoding: Only used with the value Message-Type: RFC 1327, not for "Delivery Report" to indicates general usage. that this is a delivery report gatewayed from X.400. Used in several different ways by Encoding: RFC 1154, different mail systems. Some use RFC 1505, it for a kind of content-type experimental. information, some for encoding and length information, some for a kind of boundary information, some in other ways. Information about conversion of X-MIME- non-standard this message on the path from Autoconverted: sender to recipient, like conversion between MIME encoding formats. Note: Auto-conversion may invalidate digital seals and signatures. 3.14 Resent-header fields When manually forwarding a Resent-Reply- RFC 822: C.3.3. message, header fields referring To:, to the forwarding, not to the Resent-From:, original message. Note: MIME Resent- specifies another way of Sender:, resending messages, using the Resent-From:, "Message" Content-Type. Resent-Date:, Resent-To:, Resent-cc:, Resent-bcc:, Resent- Message-ID: 3.15 Security and reliability Checksum of content to ensure Content-MD5: RFC 1864, proposed that it has not been modified. standard. Used in Usenet News to store Xref: RFC 1036: 2.2.13, information to avoid showing a only in Usenet reader the same article twice if News, not in e- it was sent to more than one mail. newsgroup. Only for local usage within one Usenet News server, should not be sent between servers. 3.16 Mailing list control Contains URL to use to get a List- RFC 2369 [26] subscription to the mailing list Subscribe from which this message was relayed. Contains URL to use to List- RFC 2369 [26] unsubscribe the mailing list from Unsubscribe which this message was relayed. Contains URL to send e-mail to List-Owner RFC 2369 [26] the owner 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. Contains URL to use to send List-Post RFC 2369 [26] contributions to the mailing list from which this message was relayed. Contains URL to use to browse the List-Archive RFC 2369 [26] archives of the mailing list from which this message was relayed. Information about the software List-Software Non-standard, has used in a mailing list expander been considered through which this message has for inclusion in passed. [26]. Stores the URN of the mailing List-ID Non-standard, has list, through which this message been considered was distributed. for inclusion in [26]. Information about the software X-Listserver Non-standard. used in a mailing list expander through which this message has passed. Warning: "Listserv" is a trademark and should not be used for other than the "Listserv" product. Use, instead the "List- Software" header field. 3.17 Miscellaneous Name of file in which a copy of Fcc: Non-standard. this message is stored. Has been automatically forwarded. Auto- RFC 1327, not for Forwarded: general usage. Can be used in Internet mail to Discarded- RFC 1327, not for indicate X.400 IPM extensions X400-IPMS- general usage. which could not be mapped to Extensions: Internet mail format. Can be used in Internet mail to Discarded- RFC 1327, not for indicate X.400 MTS extensions X400-MTS- general usage. which could not be mapped to Extensions: Internet mail format. This field is used by some mail Status: Non-standard, delivery systems to indicate the should never status of delivery for this appear in mail in message when stored. Common transit. values of this field are: U message is not downloaded and not deleted. R message is read or 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 in X-No-Archive: Non-standard publicly available archives. Yes Speech act categoriztion of a Speech-Act: Non-standard message, examples of speeach acts are Question, Idea, More, Promise, Sad, Happy, Angry, summary, Decision 4. Acknowledgments Harald Tveit Alvestrand, Ned Freed, Olle Jrnefors, Keith Moore, Nick Smith 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 1996) ----- --------------------------------------------- ----------- [1] J. Postel: "Simple Mail Transfer Protocol", Standard, STD 10, RFC 821, August 1982. Recommended [2] D. Crocker: "Standard for the format of ARPA Standard, Internet text messages." STD 11, RFC 822, Recommended August 1982. [3] M.R. Horton, R. Adams: "Standard for Not an offi- interchange of USENET messages", RFC 1036, cial IETF December 1987. standard, but in reality a de- facto standard for Usenet News [4] M. Sirbu: "A Content-Type header field header Standard, field for internet messages", RFC 1049, March Recommended, 1988. but can in the future be expected to be replaced by MIME [5] R. Braden (editor): "Requirements for Standard, Internet Hosts -- Application and Support", Required STD-3, RFC 1123, October 1989. [6] D. Robinson, R. Ullman: "Encoding Header Non-standard field Header field for Internet Messages", RFC 1154, April 1990. [7] S. Hardcastle-Kille: "Mapping between Proposed X.400(1988) / ISO 10021 and RFC 822", RFC standard, 1327 May 1992. elective [8] H. Alvestrand & J. Romaguera: "Rules for Proposed Downgrading Messages from X.400/88 to standard, X.400/84 When MIME Content-Types are Present elective in the Messages", RFC 1496, August 1993. [9] A. Costanzo: "Encoding Header field Header Non-standard field for Internet Messages", RFC 1154, April 1990. [10] A. Costanzo, D. Robinson: "Encoding Header Experimental field Header field for Internet Messages", RFC 1505, August 1993. [11] N. Freed & N. Borenstein: "MIME (Multipurpose Draft Internet Mail Extensions) Part One: Format of Standard, Internet Message Bodies. RFC 2945. November elective 1996. [12] H. Alvestrand: "Tags for the Identification Proposed of Languages", RFC 1766, February 1995. standard, elective [13] J. Palme: "Electronic Mail", Artech House Non-standard publishers, London-Boston January 1995. [14] R. Troost, S. Dorner: "Communicating Experimental Presentation Information in Internet Messages: The Content-Disposition Header field", RFC 1806, June 1995. [15] B. Kantor, P. Lapsley, "Network News Transfer Proposed Protocol: "A Proposed Standard for the Stream- standard Based Transmission of News", RFC 977, January 1986. [16] 1848 PS S. Crocker, N. Freed, J. Galvin, Proposed S. Murphy, "MIME Object Security Services", standard RFC 1848, March 1995. [17] J. Myers, M. Rose: The Content-MD5 Header Draft field Header field, RFC 1864, October 1995. standard [18] M. Horton, UUCP mail interchange format Not an offi- standard, RFC 976, Januari 1986. cial IETF standard, but in reality a de- facto standard for Usenet News [19] T. Berners-Lee, R. Header fielding, H. Informatio Frystyk: Hypertext Transfer Protocol -- nal HTTP/1.0, RFC 1945. [20] G. Vaudreuil: Voice Profile for Internet Experimental Mail, RFC 1911, February 1996. [21] H. Spencer: News Article Format and Not even an Transmission, June 1994, RFC, but FTP://zoo.toronto.edu/pub/news.ps.Z still widely FTP://zoo.toronto.edu/pub/news.txt.Z used and partly This document is often referenced under the almost a de- name "son-of-RFC1036". facto standard for Usenet News [23] PICS Label Distribution Label Syntax and Other Communication Protocols, World Wide Web standard Consortium, October 1996. [24] Eudora Pro Macintosh User Manual, Qualcomm Non-standard Inc., 1988-1995. [25] C. Newman: Originator-Info Message Header Non-standard field. work in progress, July 1997. [26] Grant Neufeld and Joshua D. Baer: The Use of Proposed URLs as Meta-Syntax for Core Mail List standard Commands and their Transport through Message Header fields, RFC 2369, July 1998.. 6. Author's address Jacob Palme Phone: +46-8-16 16 67 Stockholm University/KTH Fax: +46-8-783 08 29 Electrum 230 E-mail: jpalme@dsv.su.se S-164 40 Kista, Sweden Appendix A: Header fields sorted by Internet RFC document in which they appear. RFC 822 ------- 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
Datatracker
draft-palme-mailext-headers-01
Internet-Draft
