Network Working Group Jacob Palme Internet Draft Stockholm University/KTH draft-ietf-mailext-mail-attributes-03.txt Sweden Category: Informational November 1995 Expires May 1996 Common Internet Message Attributes Status of this Memo This document is an Internet-Draft. 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.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). This memo provides information for the Internet community. This' memo does not specify an Internet standard of any kind, since this document is mainly a compilation of information taken from other RFC-s.. Distribution of this memo is unlimited. Abstract This memo contains a table of commonly occurring attributes in headings and on envelopes of e-mail messages. The document compiles information from other RFC-s such as RFC 821, RFC 822, RFC 1036, RFC 1123, RFC 1327, RFC 1496, RFC 1521, RFC 1766 and RFC 1806. A few commonly occurring attributes which are not defined in RFC-s are also included. For each attribute, the memo gives a short description and a reference to the RFC, in which the attribute is defined. The postscript version of this memo shows the changes as compared to version 02. Palme [Page 1]
draft-ietf-mailext-mail-attributes-03.txt November 1995 Table of contents 1. Introduction 2. Use of gatewaying attributes 3. Table of attributes 3.1 Phrases used in the tables 3.2 Addressing information 3.3 Envelope and format information 3.4 Sender and recipient indication 3.5 Response control 3.6 Message identification and referral attributes 3.7 Other textual attributes 3.8 Attributes containing dates and times 3.9 Quality information 3.10 Language information 3.11 Size information 3.13 Encoding information 3.14 Resent-attributes 3.15 Miscellaneous 4. Acknowledgments 5. References 6. Author's address Appendix A: Attributes sorted by Internet RFC document in which they appear Appendix B: Alphabetical index Palme [Page 2]
draft-ietf-mailext-mail-attributes-03.txt November 1995 1. Introduction Many different Internet standards and RFC-s define attributes which may occur on Internet Mail Messages and Network News Articles. The intention of this document is to list all such attributes in one document as an aid to people developing message systems or interested in Internet Mail standards. The document contains all heading attributes which the author has found in the following Internet standards: RFC 821 [1], RFC 822 [2], RFC 1036 [3], RFC 1123 [5], RFC 1327 [7], RFC 1496 [8], RFC 1521 [11], RFC 1766 [12] and RFC 1806 [14]. Note in particular that heading attributes defined in RFC 1421-1424, "Privacy Enhancement for Internet Electronic Mail", are not included. A few additional attributes which often can be found in e-mail headings but are not part of any Internet standard are also included. For each heading attribute, the document gives a short description and a reference to the Internet standard or RFC, in which they are defined. 2. Use of gatewaying attributes RFC 1327 defines a number of new attributes in Internet mail, which are defined to map attributes which X.400 has but which were previously not standardized in Internet mail. The fact that an attribute 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 attribute is recommended for messages wholly within Internet mail. Some of these attributes may eventually get accepted also for usage within Internet mail, but they are, when this is written (July 1995) not recommended for such usage. Fields defined 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 fields are however not standardized for use in Internet e-mail and should be handled with caution. Fields are given here in the spelling used in e-mail headers. This may sometimes be English, sometimes American spelling. One attribute, "Organisation/Organization" occurs in e-mail headers sometimes with English, sometimes with American spelling. Palme [Page 3]
draft-ietf-mailext-mail-attributes-03.txt November 1995 3. Table of attributes 3.1 Phrases used in the tables "not for general Used to mark attributes which are defined in usage" RFC 1327 for use in messages from or to Internet mail/X.400 gateways. These attributes have not been standardized for general usage in the exchange of messages between Internet mail-based systems. "not standardized Used to mark attributes defined only in RFC for use in e-mail" 1036 for use in Usenet News. These attributes 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 standard for Usenet News, is not an accepted IETF standard or on the IETF standards track. "non-standard" This attribute is not specified in any of those referenced RFC-s which are Internet standards, draft standards or proposed standards. The attribute appears here because it is common in e-mail or Usenet News headers. Usage of these attributes is not in general recommended. "discouraged" This attribute, which is non-standard, is known to create problems and should not be generated. Handling of such attributes in incoming mail should be done with great caution. "controversial" The meaning and usage of this attribute is controversial, i.e. different implementors have chosen to implement the attribute in different ways. Because of this, such attributes should be handled with caution and understanding of the different possible interpretations. "for limited use" Attributes defined in a so-called "experimental" Internet standard. These should be used only if both parties agree. "experimental" This attribute is used for newly defined attributes, which are to be tried out before entering the IETF standards track. Palme [Page 4]
draft-ietf-mailext-mail-attributes-03.txt November 1995 3.2 Addressing information Original sender. Should in MAIL FROM RFC 821, Internet be empty ("MAIL FROM: RFC 1123: 5.2.9. <>") when sending notifications, and be the list administrator when forwarding from a distribution list. This value may for gatewayed messages contain a chain of hosts to be passed in sequence to reach the original sender (i.e. a relative address). Used to convey the information Return-Path: RFC 821, from the MAIL FROM envelope RFC 1123: 5.2.13. attribute when the message leaves the SMTP environment in which "MAIL FROM" is used. Recipient to which message is to RCPT TO RFC 821, be delivered. Relative address RFC 1123: 5.2.6. was allowed in RFC 821, but later prohibited in RFC 1123. 3.3 Envelope and format information All that is inside the envelope. DATA RFC 821, RFC 1123: 5.2.8. Trace of MTA-s which a message Received: RFC 822: 4.3.2, has passed. RFC 1123: 5.2.8. An indicator that this message is MIME-Version: RFC 1521: 3. formatted according to the MIME standard, and an indication of which version of MIME is utilized. List of MTA-s passed. Path: RFC 1036: 2.2.6, not standardized for use in e-mail. Special Usenet News actions. Control: RFC 1036: 2.1.6, not standardized for use in e-mail. Trace of distribution lists DL-Expansion- RFC 1327, not for passed. History- general usage. Indication Palme [Page 5]
draft-ietf-mailext-mail-attributes-03.txt November 1995 Which body part types occur in Original- RFC 1327, not for this message. Encoded- general usage. Information- Types: Special informational message. Message-Type: RFC 1327, not for Delivery general usage. Report 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, such disclosure is in Internet mail done via the To:, Cc: and Bcc: heading 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 Author, approver From: RFC 822: 4.4.1, RFC 1123: 5.2.15- 16, 5.3.7. Moderator Approved: RFC 1036: 2.2.11, not standardized for use in e-mail. Sender information inside the Sender: RFC 822: 4.4.2, envelope. RFC 1123: 5.2.15- 16, 5.3.7. Main recipients. To: RFC 822: 4.5.1, RFC 1123: 5.2.15- 16, 5.3.7. Additional recipients. Cc: RFC 822: 4.5.2, RFC 1123. 5.2.15- 16, 5.3.7. Palme [Page 6]
draft-ietf-mailext-mail-attributes-03.txt November 1995 Recipients not shown to other Bcc: RFC 822: 4.5.3, recipients. RFC 1123: 5.2.15- 16, 5.3.7. In Usenet News: group to which Newsgroups: RFC 1036: 2.1.3, this article was posted. not standardized Some systems provide this field and controversial also in e-mail although it is not for use in e-mail. standardized there. Unfortunately, the field can appear in e-mail with two different and contradictory meanings: (a) Indicates the newsgroup recipient of a message sent to both e-mail and Usenet News recipients. (b) In a personally addressed reply to a message in a news- group, indicate 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, MTA-s 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. Limitation on where this message Distribution: RFC 1036: 2.2.7, can be distributed. not standardized for use in e-mail. Fax number of the originator. Fax:, Non-standard. Telefax: Phone number of the originator. Phone: Non-standard. Information about the client Mail-System- Non-standard. software of the originator. Version:, Mailer:, Originating- Client: Palme [Page 7]
draft-ietf-mailext-mail-attributes-03.txt November 1995 3.5 Response control This heading field is meant to Reply-To: RFC 822: 4.4.3, indicate where the sender wants controversial. replies to go. Unfortunately, this is ambiguous, since there are different kinds of replies, which the sender may wish to go to different addresses. In particular, there are personal replies intended for only one person, and group replies, intended for the whole group of people who read the replied-to message (often a mailing list). There has been various suggestions to differentiate between these two uses of "Reply- To", with new header fields names "Personal-Reply-To", "Group-Reply- To" or "Wide-Reply-To". None of these proposals have been accepted. In practice, "Reply-To" is often used to indicate a neater format for the e-mail address of the sender than that given in the "From" field. In this case, it would be better to put the neater format directly in the "From" field. A well-known mailing list software will optionally insert "Reply-To" with the name of the list into messages distributed by the list. The opinion of the author of this RFC is that you should avoid using "Reply-To" until IETF has defined less ambiguous constructs. This opinion is however also controversial and not shared by everyone. Palme [Page 8]
draft-ietf-mailext-mail-attributes-03.txt November 1995 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 heading field is used in a message which is sent to both e-mail and Usenet News, to show where follow-up in Usenet news is wanted. The field does not say anything about where follow-up in e-mail is to be sent. 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 RCPT TO and Return-Path, not Errors-To, for where delivery notifications are to be sent, and a new standard for delivery notifications specifies how requests for notifications are specified by a new parameter "NOTIFY" to the "RCPT TO" SMTP command. An IETF group is working on a Disposition- Do not use until standard for receipt notifica- Notification- the proposal from tions (note that this is not the To: this IETF group is same as delivery notifications). ready and accepted This group is discussing this new by IETF. heading field, but no agreement has been reached yet. 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. Palme [Page 9]
draft-ietf-mailext-mail-attributes-03.txt November 1995 Indicates whether the content of RET in DRPT In forthcoming new a message is to be returned with SMTP exten- Internet standard. non-delivery notifications. sion 3.6 Message identification and referral attributes Unique ID of this message. Message-ID: RFC 822: 4.6.1. Unique ID of one body part of the Content-ID: RFC 1521: 6.1. content of a message. Reference to message which this In-Reply-To: RFC 822: 4.6.2. message is a reply to. Reference to other related References: RFC 822: 4.6.3. messages. Reference to previous message Obsoletes: RFC 1327, not for being corrected and replaced. general usage. Used in Usenet News in similar Supersedes: Non-standard. ways to the "Obsoletes" attribute described above. 3.7 Other textual attributes Search keys for data base Keywords: RFC 822: 4.7.1. retrieval. Title, heading, subject. Subject: RFC 822: 4.7.1. Comments on a message. Comments: RFC 822: 4.7.2. Description of a particular body Content- RFC 1521: 6.2. part of a message. description: Organization to which the sender Organization: RFC 1036: 2.2.8, of this message 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, message. 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 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. Palme [Page 10]
draft-ietf-mailext-mail-attributes-03.txt November 1995 3.8 Attributes 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. 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. general usage. 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. Sometimes used as a priority Precedence: Non-standard, value which can influence controversial, transmission speed and delivery. discouraged. 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. Can be high, normal or low and is Importance: RFC 1327, not for only used in the recipient client general usage. (UA). Can be personal, private, company Sensitivity: RFC 1327, not for confidential or absent. general usage. Body parts are missing. Incomplete- RFC 1327, not for Copy: general usage. Palme [Page 11]
draft-ietf-mailext-mail-attributes-03.txt November 1995 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. Can cause several robustness and interoperability problems and is not recommended. 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. 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. 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 field are defined in RFC 1521: 4. different ways in RFC 1049 and in MIME (RFC 1521), look for the "MIME-version" heading 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. Coding method used in content. Content- RFC 1521: 5. Transfer- Encoding Palme [Page 12]
draft-ietf-mailext-mail-attributes-03.txt November 1995 Coding method used in content. Encoding: RFC 1154, RFC 1505, for limited use. 3.14 Resent-attributes When manually forwarding a Resent-Reply- RFC 822: C.3.3. message, attributes 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 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 extensions which X400-IPMS- general usage. could not be mapped to Internet Extensions: mail format. Can be used in Internet mail to Discarded- RFC 1327, not for indicate X.400 extensions which X400-MTS- general usage. could not be mapped to Internet Extensions: mail format. 4. Acknowledgments Harald Tveit Alvestrand, Keith Moore, Nick Smith and several other people have helped me with compiling this list. 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]. Palme [Page 13]
draft-ietf-mailext-mail-attributes-03.txt November 1995 5. References Ref. Author, title IETF status (July 1995) ----- --------------------------------------------- ----------- - - [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 for Standard, internet messages", RFC 1049, March 1988. Recommended. [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- Field for Internet Messages", RFC 1154, April standard. 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 for Non- Internet Messages", RFC 1154, April 1990. standard. [10] A. Costanzo, D. Robinson: "Encoding Header Experimental Field for Internet Messages", RFC 1505, . August 1993. Palme [Page 14]
draft-ietf-mailext-mail-attributes-03.txt November 1995 [11] N. Borenstein & N. Freed: "MIME (Multipurpose Draft Internet Mail Extensions) Part One: Standard, Mechanisms for Specifying and Describing the elective. Format of Internet Message Bodies", RFC 1521, Sept 1993. [12] H. Alvestrand: "Tags for the Identification Proposed of Languages", RFC 1766, February 1995. standard, elective. [13] J. Palme: "Electronic Mail", Artech House Non- publishers, London-Boston January 1995. standard. [14] R. Troost, S. Dorner: "Communicating Experimental Presentation Information in Internet . Messages: The Content-Disposition Header", RFC 1806, June 1995. 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 Palme [Page 15]
draft-ietf-mailext-mail-attributes-03.txt November 1995 Appendix A: Attributes sorted by Internet RFC document in which they appear. RFC 821 ------- DATA MAIL FROM RCPT TO RFC 822 ------- Bcc Cc Comments Date From In-Reply-To Keywords Message-ID Received References Reply-To Resent- Resent-bcc Resent-Date Resent-From Resent-From Resent-Message-ID Resent-Reply-To Resent-ToResent-cc Return-Path Sender Sender Subject To RFC 1036 -------- Approved Control Distribution Expires Followup-To Lines Newsgroups Organization Path Summary Palme [Page 16]
draft-ietf-mailext-mail-attributes-03.txt November 1995 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 1521 -------- Content-Description Content-ID Content-Transfer-Encoding Content-Type MIME-Version RFC 1806 -------- Content-Disposition Palme [Page 17]
draft-ietf-mailext-mail-attributes-03.txt November 1995 Not Internet standard --------------------- Apparently-to Content-length Encoding Errors-To Return-Receipt-To Fax Telefax Fcc Mail-System-Version Mailer Organisation Originating-Client Phone Supersedes Palme [Page 18]
draft-ietf-mailext-mail-attributes-03.txt November 1995 Appendix B: Alphabetical index Section Heading-field ------- ------------- 3.3 Alternate-Recipient 3.4 Apparently-To 3.4 Approved 3.16 Auto-Forwarded 3.4 Bcc 3.4 Cc 3.7 Comments 3.7 Content-Description 3.3 Content-Disposition 3.6 Content-ID 3.7 Content-identifier 3.10 Content-Language 3.11 Content-Length 3.5 Content-Return 3.13 Content-Transfer-Encoding 3.13 Content-Type 3.3 Control 3.12 Conversion 3.12 Conversion-With-Loss 3.3 DATA 3.8 Date 3.8 Delivery-Date 3.16 Discarded-X400-IPMS-Extensions 3.16 Discarded-X400-MTS-Extensions 3.3 Disclose-Recipients 3.5 Disposition-Notification-To 3.4 Distribution 3.3 DL-Expansion-History-Indication 3.13 Encoding 3.5 Errors-To 3.8 Expires 3.4 Fax 3.15 Fcc 3.5 Followup-To 3.4 From 3.5 Generate-Delivery-Report 3.9 Importance 3.6 In-Reply-To 3.9 Incomplete-Copy 3.7 Keywords 3.10 Language 3.11 Lines 3.2 MAIL FROM 3.4 Mail-System-Version 3.4 Mailer 3.6 Message-ID 3.3 Message-Type Palme [Page 19]
draft-ietf-mailext-mail-attributes-03.txt November 1995 3.3 MIME-Version 3.4 Newsgroups 3.6 Obsoletes 3.7 Organisation 3.7 Organization 3.3 Original-encoded-Information-Types 3.4 Originating-Client 3.3 Path 3.4 Phone 3.9 Precedence 3.5 Prevent-NonDelivery-Report 3.9 Priority 3.2 RCPT TO 3.3 Received 3.6 References 3.8 Reply-By 3.5 Reply-To 3.14 Resent- 3.5 RET in DRPT SMTP extension 3.2 Return-Path 3.5 Return-Receipt-To 3.4 Sender 3.9 Sensitivity 3.7 Subject 3.7 Summary 3.6 Supersedes 3.4 Telefax 3.4 To Palme [Page 20]
