summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2076.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2076.txt')
-rw-r--r--doc/rfc/rfc2076.txt1515
1 files changed, 1515 insertions, 0 deletions
diff --git a/doc/rfc/rfc2076.txt b/doc/rfc/rfc2076.txt
new file mode 100644
index 0000000..d271b3a
--- /dev/null
+++ b/doc/rfc/rfc2076.txt
@@ -0,0 +1,1515 @@
+
+
+
+
+
+
+Network Working Group J. Palme
+Request for Comments: 2076 Stockholm University/KTH
+Category: Informational February 1997
+
+
+ Common Internet Message Headers
+
+Status of this Memo
+
+ This memo provides information for the Internet community. This memo
+ does not specify an Internet standard of any kind. Distribution of
+ this memo is unlimited.
+
+Abstract
+
+ This memo contains a table of commonly occurring headers 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 1521,
+ RFC 1766, RFC 1806, RFC 1864 and RFC 1911. A few commonly occurring
+ headers which are not defined in RFCs are also included. For each
+ header, the memo gives a short description and a reference to the RFC
+ in which the header is defined.
+
+Table of contents
+ 1. Introduction.............................................. 2
+ 2. Use of gatewaying headers................................. 3
+ 3. Table of headers.......................................... 3
+ 3.1 Phrases used in the tables.......................... 3
+ 3.2 Trace information................................... 5
+ 3.3 Format and control information...................... 5
+ 3.4 Sender and recipient indication..................... 6
+ 3.5 Response control.................................... 9
+ 3.6 Message identification and referral headers......... 11
+ 3.7 Other textual headers............................... 12
+ 3.8 Headers containing dates and times.................. 13
+ 3.9 Quality information................................. 13
+ 3.10 Language information............................... 14
+ 3.11 Size information................................... 14
+ 3.12 Conversion control................................. 15
+ 3.13 Encoding information............................... 15
+ 3.14 Resent-headers..................................... 16
+ 3.15 Security and reliability........................... 16
+ 3.16 Miscellaneous...................................... 16
+ 4. Acknowledgments........................................... 18
+
+
+
+
+
+
+
+Palme Informational [Page 1]
+
+RFC 2076 Internet Message Headers February 1997
+
+
+ 5. References................................................ 18
+ 6. Author's Address.......................................... 20
+ Appendix A:
+ Headers sorted by Internet RFC document in which they appear. 21
+ Appendix B:
+ Alphabetical index........................................... 25
+
+1. Introduction
+
+ Many different Internet standards and RFCs define headers which may
+ occur on Internet Mail Messages and Usenet News Articles. The
+ intention of this document is to list all such headers in one
+ document as an aid to people developing message systems or interested
+ in Internet Mail standards.
+
+ The document contains all headers 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 1521 [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 headers only appear inside the
+ body of a message, and thus are not headers 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. A
+ few additional headers which often can be found in e-mail headings
+ but are not part of any Internet standard are also included.
+
+ For each header, the document gives a short description and a
+ reference to the Internet standard or RFC, in which they are defined.
+
+ The header names given here are spelled the same way as when they are
+ actually used. This is usually American but sometimes English
+ spelling. One header in particular, "Organisation/Organization",
+ occurs in e-mail headers 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 = heading One field in the heading, beginning with a field
+ field name, colon, and followed by the field value(s)
+
+
+
+
+Palme Informational [Page 2]
+
+RFC 2076 Internet Message Headers February 1997
+
+
+ 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-attributes.pdf.
+
+ Please e-mail me (Jacob Palme <jpalme@dsv.su.se>) if you have noted
+ headers which should be included in this memo but are not.
+
+2. Use of gatewaying headers
+
+ RFC 1327 defines a number of new headers in Internet mail, which are
+ defined to map headers which X.400 has but which were previously not
+ standardized in Internet mail. The fact that a header 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 is
+ recommended for messages wholly within Internet mail. Some of these
+ headers 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.
+
+ Headers 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 headers are not standardized for use in
+ Internet e-mail and should be handled with caution by e-mail agents.
+
+3. Table of headers
+
+3.1 Phrases used in the tables
+
+ "not for general Used to mark headers which are defined in RFC
+ usage" 1327 for use in messages from or to Internet
+ mail/X.400 gateways. These headers have not
+ been standardized for general usage in the
+ exchange of messages between Internet mail-
+ based systems.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Palme Informational [Page 3]
+
+RFC 2076 Internet Message Headers February 1997
+
+
+ "not standardized Used to mark headers defined only in RFC 1036
+ for use in e-mail" for use in Usenet News. These headers 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 is not specified in any of
+ referenced RFCs which define Internet
+ protocols, including Internet Standards, draft
+ standards or proposed standards. The header
+ appears here because it often appears in e-
+ mail or Usenet News. Usage of these headers is
+ not in general recommended. Some header
+ proposed in ongoing IETF standards development
+ work, but not yet accepted, are also marked in
+ this way.
+
+ "discouraged" This header, which is non-standard, is known
+ to create problems and should not be
+ generated. Handling of such headers in
+ incoming mail should be done with great
+ caution.
+
+ "controversial" The meaning and usage of this header is
+ controversial, i.e. different implementors
+ have chosen to implement the header in
+ different ways. Because of this, such headers
+ should be handled with caution and
+ understanding of the different possible
+ interpretations.
+
+ "experimental" This header is used for newly defined headers,
+ 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.
+
+
+
+
+
+
+
+
+Palme Informational [Page 4]
+
+RFC 2076 Internet Message Headers February 1997
+
+
+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 1521: 3.
+ formatted according to the MIME
+ standard, and an indication of
+ which version of MIME is
+ utilized.
+
+ Special Usenet News actions only. Control: RFC 1036: 2.1.6,
+ only in Usenet
+ News, not in e-
+ mail.
+
+ Special Usenet News actions and a Also-Control: son-of-RFC1036
+ normal article at the same time. [21], non-
+ 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:
+
+
+
+
+
+
+
+Palme Informational [Page 5]
+
+RFC 2076 Internet Message Headers February 1997
+
+
+ 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: headers.
+
+ 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 (not followed by ":")
+ below.
+
+
+ (1) This header should never From not standardized
+ appear in e-mail being sent, and for use in e-mail
+ should thus not appear in this
+ memo. It is however included,
+ since people often ask about it.
+
+
+
+
+
+
+
+
+
+
+
+Palme Informational [Page 6]
+
+RFC 2076 Internet Message Headers February 1997
+
+
+ This header 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 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
+ 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.
+
+ Sometimes called "From_" header.
+
+ 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.
+ header.
+
+ Primary recipients. To: RFC 822: 4.5.1,
+ RFC 1123: 5.2.15-
+ 16, 5.3.7.
+
+
+
+
+Palme Informational [Page 7]
+
+RFC 2076 Internet Message Headers February 1997
+
+
+ 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.
+
+ 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
+ also in e-mail although it is not for use in e-mail.
+ standardized there.
+
+ Unfortunately, the header can
+ appear in e-mail with two
+ 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 personally addressed
+ reply to an article in a news-
+ group, indicating the newsgroup
+ in which this discussion
+ originated.
+
+
+
+
+
+
+
+
+
+
+
+
+Palme Informational [Page 8]
+
+RFC 2076 Internet Message Headers February 1997
+
+
+ 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. 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:, X-
+ Mailer, X-
+ Newsreader
+
+3.5 Response control
+
+ This header is meant to indicate Reply-To: RFC 822: 4.4.3,
+ where the sender wants replies to RFC 1036: 2.2.1
+ go. Unfortunately, this is controversial.
+ 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.).
+
+
+
+Palme Informational [Page 9]
+
+RFC 2076 Internet Message Headers February 1997
+
+
+ Some mail systems use this header
+ 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. These practices are
+ controversial. The personal
+ opinion of the author of this RFC
+ is that this header 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 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 does
+ not say anything about where
+ follow-up in e-mail is to be
+ sent.
+
+ Note that the value of this
+ header 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 RCPT TO and
+ Return-Path, not Errors-To, for
+ where delivery notifications are
+ to be sent.
+
+
+
+
+
+Palme Informational [Page 10]
+
+RFC 2076 Internet Message Headers February 1997
+
+
+ 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:
+
+3.6 Message identification and referral headers
+
+ 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 1521: 6.1.
+ content of a message.
+
+ Base to be used for resolving Content-Base: Non-standard
+ relative URIs within this content
+ part.
+
+ URI with which the content of Content- Non-standard
+ this content part might be Location:
+ retrievable.
+
+ 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:".
+
+
+
+
+Palme Informational [Page 11]
+
+RFC 2076 Internet Message Headers February 1997
+
+
+ Commonly used in Usenet News in Supersedes: son-of-RFC1036
+ similar ways to the "Obsoletes" [21], non-standard
+ header 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.
+
+ 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.
+
+3.7 Other textual headers
+
+ 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 1521: 6.2.
+ part of a message. Description:
+
+ 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 for
+ text which you want to ensure
+ that the recipient gets.
+
+
+
+Palme Informational [Page 12]
+
+RFC 2076 Internet Message Headers February 1997
+
+
+ A text string which identifies Content- RFC 1327, not for
+ the content of a message. Identifier: general usage.
+
+3.8 Headers 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.
+
+ 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.
+
+
+
+
+
+
+
+Palme Informational [Page 13]
+
+RFC 2076 Internet Message Headers February 1997
+
+
+ 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 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.
+
+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 should not be
+ used when sending a message
+ through the net. The use of this
+ header 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.
+
+
+
+
+
+Palme Informational [Page 14]
+
+RFC 2076 Internet Message Headers February 1997
+
+
+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 are defined in RFC 1521: 4.
+ different ways in RFC 1049 and in RFC 1766: 4.1
+ MIME (RFC 1521), look for the
+ "MIME-version" header 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.
+
+ 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 1521: 5.
+ 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.
+
+
+
+
+
+Palme Informational [Page 15]
+
+RFC 2076 Internet Message Headers February 1997
+
+
+ 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.
+
+3.14 Resent-headers
+
+ When manually forwarding a Resent-Reply- RFC 822: C.3.3.
+ message, headers referring to the To:,
+ forwarding, not to the original Resent-From:,
+ message. Note: MIME specifies Resent-
+ another way of resending Sender:,
+ messages, using the "Message" Resent-From:,
+ 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 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.
+
+
+
+
+
+
+
+Palme Informational [Page 16]
+
+RFC 2076 Internet Message Headers February 1997
+
+
+ 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.
+
+ Combinations of these characters
+ can occur, such as "Status: OR"
+ to indicate that a message is
+ downloaded but not deleted.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Palme Informational [Page 17]
+
+RFC 2076 Internet Message Headers February 1997
+
+
+4. Acknowledgments
+
+ Harald Tveit Alvestrand, Ned Freed, Olle Jdrnefors, Keith Moore, Nick
+ Smith and several other people have helped me with compiling this
+ list. I especially thank Ned Freed and Olle Jdrnefors 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].
+
+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 header for Standard,
+ internet messages", RFC 1049, March 1988. Recommended,
+ 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
+ Header for Internet Messages", RFC 1154,
+ April 1990.
+
+
+
+Palme Informational [Page 18]
+
+RFC 2076 Internet Message Headers February 1997
+
+
+[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 Header for Non-standard
+ Internet Messages", RFC 1154, April 1990.
+
+[10] A. Costanzo, D. Robinson: "Encoding Header Experimental
+ Header for Internet Messages", RFC 1505,
+ August 1993.
+
+[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-standard
+ publishers, London-Boston January 1995.
+
+[14] R. Troost, S. Dorner: "Communicating Experimental
+ Presentation Information in Internet
+ Messages: The Content-Disposition Header",
+ 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
+ Header, RFC 1864, October 1995. standard
+
+
+
+
+
+
+Palme Informational [Page 19]
+
+RFC 2076 Internet Message Headers February 1997
+
+
+[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. Headering, H. Frystyk: Not an official
+ Hypertext Transfer Protocol -- HTTP/1.0, IETF standard,
+ RFC 1945, May 1996. but the defacto
+ standard until
+ the next
+ version is
+ published
+
+[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 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
+
+
+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 Informational [Page 20]
+
+RFC 2076 Internet Message Headers February 1997
+
+
+Appendix A:
+ Headers 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 (:")
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Palme Informational [Page 21]
+
+RFC 2076 Internet Message Headers February 1997
+
+
+ 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
+
+
+
+Palme Informational [Page 22]
+
+RFC 2076 Internet Message Headers February 1997
+
+
+ RFC 1505
+ --------
+
+ Encoding
+
+ RFC 1521
+ --------
+
+ Content-Description
+ Content-ID
+ Content-Transfer-Encoding
+ Content-Type
+ MIME-Version
+
+ RFC 1806
+ --------
+
+ Content-Disposition
+
+ RFC 1864
+ --------
+
+ Content-MD5
+
+ RFC 1911
+ --------
+
+ Importance
+ Sensitivity
+
+ son-of-RFC1036 [21]
+ -------------------
+
+ Also-Control
+ Article-Names
+ Article-Updates
+ See-Also
+ Supersedes
+
+
+
+
+
+
+
+
+
+
+
+
+
+Palme Informational [Page 23]
+
+RFC 2076 Internet Message Headers February 1997
+
+
+ Not Internet standard
+ ---------------------
+
+ Apparently-to
+ Content-Base
+ Content-Length
+ Content-Location
+ Content-SGML-Entity
+ Encoding
+ Errors-To
+ Return-Receipt-To
+ Fax
+ "From " (not followed by ":")
+ Telefax
+ Fcc
+ For-Comment
+ For-Handling
+ Mail-System-Version
+ Mailer
+ Organisation
+ Originating-Client
+ Phone
+ Status
+ Supersedes
+ X400-Content-Return
+ X-Mailer
+ X-Newsreader
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Palme Informational [Page 24]
+
+RFC 2076 Internet Message Headers February 1997
+
+
+Appendix B:
+ Alphabetical index
+
+ Section Heading-header
+ ------- --------------
+
+ 3.3 Also-Control
+ 3.3 Alternate-Recipient
+ 3.4 Apparently-To
+ 3.4 Approved
+ 3.6 Article-Names
+ 3.6 Article-Updates
+ 3.16 Auto-Forwarded
+ 3.4 bcc
+ 3.4 cc
+ Client, see Originating-Client
+ 3.7 Comments
+ 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
+ 3.8 Date
+ 3.8 Delivery-Date
+ Delivery-Report, see Generate-Delivery-Report, Prevent-
+ Delivery-Report, Non-Delivery-Report, Content-Type
+ Description, see Content-Description
+ 3.16 Discarded-X400-IPMS-Extensions
+ 3.16 Discarded-X400-MTS-Extensions
+ 3.3 Disclose-Recipients
+ Disposition, see Content-Disposition
+ 3.4 Distribution
+ 3.2 DL-Expansion-History-Indication
+ 3.13 Encoding see also Content-Transfer-Encoding
+ 3.4 Errors-To
+
+
+
+
+Palme Informational [Page 25]
+
+RFC 2076 Internet Message Headers February 1997
+
+
+ 3.8 Expires
+ Extension see Discarded-X400-IPMS-Extensions, Discarded-
+ X400-MTS-Extensions
+ 3.4 Fax
+ 3.16 Fcc
+ 3.4 Followup-To
+ Forwarded, see Auto-Forwarded
+ 3.4 For-Comment
+ 3.4 For-Handling
+ 3.4 From
+ 3.4 Generate-Delivery-Report
+ 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
+ 3.10 Language see also Content-Language
+ Length see Content-Length
+ 3.11 Lines
+ 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.4 Originating-Client
+ 3.2 Path
+ 3.4 Phone
+ 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
+
+
+
+Palme Informational [Page 26]
+
+RFC 2076 Internet Message Headers February 1997
+
+
+ 3.5 Return-Receipt-To
+ 3.6 See-Also
+ 3.4 Sender
+ 3.9 Sensitivity
+ 3.16 Status
+ 3.7 Subject
+ 3.7 Summary
+ 3.6 Supersedes
+ 3.4 Telefax
+ 3.4 To
+ Transfer-Encoding see Content-Transfer-Encoding
+ Type see Content-Type, Message-Type, Original-Encoded-
+ Information-Types
+ Version, see MIME-Version, X-Mailer
+ 3.4 X400-Content-Return
+ 3.4 X-Mailer see also Mail-System-Version
+ 3.4 X-Newsreader
+ 3.15 Xref
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Palme Informational [Page 27]
+