Difference between revisions of "RFC2076"
(One intermediate revision by the same user not shown) | |||
Line 5: | Line 5: | ||
Common Internet Message Headers | Common Internet Message Headers | ||
− | Status of this Memo | + | '''Status of this Memo''' |
This memo provides information for the Internet community. This memo | This memo provides information for the Internet community. This memo | ||
Line 11: | Line 11: | ||
this memo is unlimited. | this memo is unlimited. | ||
− | Abstract | + | '''Abstract''' |
This memo contains a table of commonly occurring headers in headings | This memo contains a table of commonly occurring headers in headings | ||
of e-mail messages. The document compiles information from other RFCs | 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, | + | such as [[RFC822|RFC 822]], [[RFC1036|RFC 1036]], [[RFC1123|RFC 1123]], [[RFC1327|RFC 1327]], [[RFC1496|RFC 1496]], [[RFC1521|RFC 1521]], |
− | RFC 1766, RFC 1806, RFC 1864 and RFC 1911. A few commonly occurring | + | [[RFC1766|RFC 1766]], [[RFC1806|RFC 1806]], [[RFC1864|RFC 1864]] and [[RFC1911|RFC 1911]]. A few commonly occurring |
headers which are not defined in RFCs are also included. For each | 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 | header, the memo gives a short description and a reference to the RFC | ||
Line 22: | Line 22: | ||
Table of contents | Table of contents | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
Appendix A: | Appendix A: | ||
Headers sorted by Internet RFC document in which they appear. 21 | Headers sorted by Internet RFC document in which they appear. 21 | ||
Appendix B: | Appendix B: | ||
− | |||
== Introduction == | == Introduction == | ||
Line 59: | Line 36: | ||
The document contains all headers which the author has found in the | The document contains all headers which the author has found in the | ||
− | following Internet standards: , RFC 822 [2], RFC 1036 [3], RFC 1123 | + | following Internet standards: , [[RFC822|RFC 822]] [2], [[RFC1036|RFC 1036]] [3], [[RFC1123|RFC 1123]] |
− | [5], RFC 1327 [7], RFC 1496 [8], RFC 1521 [11], RFC 1766 [12], RFC | + | [5], [[RFC1327|RFC 1327]] [7], [[RFC1496|RFC 1496]] [8], [[RFC1521|RFC 1521]] [11], [[RFC1766|RFC 1766]] [12], RFC |
− | 1806 [14], RFC 1864[17] and RFC 1911[20]. Note in particular that | + | 1806 [14], [[RFC1864|RFC 1864]][17] and [[RFC1911|RFC 1911]][20]. Note in particular that |
− | heading attributes defined in PEM (RFC 1421-1424) and MOSS (RFC 1848 | + | heading attributes defined in PEM ([[RFC1421|RFC 1421]]-1424) and MOSS ([[RFC1848|RFC 1848]] |
[16]) are not included. PEM and MOSS headers only appear inside the | [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. | + | body of a message, and thus are not headers in the [[RFC822|RFC 822]] sense. |
Mail attributes in envelopes, i.e. attributes controlling the message | Mail attributes in envelopes, i.e. attributes controlling the message | ||
transport mechanism between mail and news servers, are not included. | transport mechanism between mail and news servers, are not included. | ||
Line 102: | Line 79: | ||
== Use of gatewaying headers == | == Use of gatewaying headers == | ||
− | RFC 1327 defines a number of new headers in Internet mail, which are | + | [[RFC1327|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 | 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 | standardized in Internet mail. The fact that a header occurs in RFC | ||
Line 112: | Line 89: | ||
widely implemented or used. | widely implemented or used. | ||
− | Headers defined only in RFC 1036 for use in Usenet News sometimes | + | Headers defined only in [[RFC1036|RFC 1036]] for use in Usenet News sometimes |
appear in mail messages, either because the messages have been | appear in mail messages, either because the messages have been | ||
gatewayed from Usenet News to e-mail, or because the messages were | gatewayed from Usenet News to e-mail, or because the messages were | ||
Line 130: | Line 107: | ||
based systems. | based systems. | ||
− | "not standardized Used to mark headers defined only in RFC 1036 | + | "not standardized Used to mark headers defined only in [[RFC1036|RFC 1036]] |
for use in e-mail" for use in Usenet News. These headers have no | for use in e-mail" for use in Usenet News. These headers have no | ||
standard meaning when appearing in e-mail, | standard meaning when appearing in e-mail, | ||
Line 136: | Line 113: | ||
ways by different software. When appearing in | ways by different software. When appearing in | ||
e-mail, they should be handled with caution. | e-mail, they should be handled with caution. | ||
− | Note that RFC 1036, although generally used as | + | Note that [[RFC1036|RFC 1036]], although generally used as |
a de-facto standard for Usenet News, is not an | a de-facto standard for Usenet News, is not an | ||
official IETF standard or even on the IETF | official IETF standard or even on the IETF | ||
Line 176: | Line 153: | ||
=== Trace information === | === Trace information === | ||
− | Used to convey the information Return-Path: RFC 821, | + | Used to convey the information Return-Path: [[RFC821|RFC 821]], |
− | from the MAIL FROM envelope RFC 1123: 5.2.13. | + | from the MAIL FROM envelope [[RFC1123|RFC 1123]]: 5.2.13. |
attribute in final delivery, when | attribute in final delivery, when | ||
the message leaves the SMTP | the message leaves the SMTP | ||
Line 183: | Line 160: | ||
is used. | is used. | ||
− | Trace of MTAs which a message has Received: RFC 822: 4.3.2, | + | Trace of MTAs which a message has Received: [[RFC822|RFC 822]]: 4.3.2, |
− | passed. RFC 1123: 5.2.8. | + | passed. [[RFC1123|RFC 1123]]: 5.2.8. |
− | List of MTAs passed. Path: RFC 1036: 2.1.6, | + | List of MTAs passed. Path: [[RFC1036|RFC 1036]]: 2.1.6, |
only in Usenet | only in Usenet | ||
News, not in e- | News, not in e- | ||
mail. | mail. | ||
− | Trace of distribution lists DL-Expansion- RFC 1327, not for | + | Trace of distribution lists DL-Expansion- [[RFC1327|RFC 1327]], not for |
passed. History- general usage. | passed. History- general usage. | ||
Indication: | Indication: | ||
Line 197: | Line 174: | ||
=== Format and control information === | === Format and control information === | ||
− | An indicator that this message is MIME-Version: RFC 1521: 3. | + | An indicator that this message is MIME-Version: [[RFC1521|RFC 1521]]: 3. |
formatted according to the MIME | formatted according to the MIME | ||
standard, and an indication of | standard, and an indication of | ||
Line 203: | Line 180: | ||
utilized. | utilized. | ||
− | Special Usenet News actions only. Control: RFC 1036: 2.1.6, | + | Special Usenet News actions only. Control: [[RFC1036|RFC 1036]]: 2.1.6, |
only in Usenet | only in Usenet | ||
News, not in e- | News, not in e- | ||
Line 214: | Line 191: | ||
in e-mail | in e-mail | ||
− | Which body part types occur in Original- RFC 1327, not for | + | Which body part types occur in Original- [[RFC1327|RFC 1327]], not for |
this message. Encoded- general usage. | this message. Encoded- general usage. | ||
Information- | Information- | ||
Types: | Types: | ||
− | Controls whether this message may Alternate- RFC 1327, not for | + | Controls whether this message may Alternate- [[RFC1327|RFC 1327]], not for |
be forwarded to alternate Recipient: general usage. | be forwarded to alternate Recipient: general usage. | ||
recipients such as a postmaster | recipients such as a postmaster | ||
Line 226: | Line 203: | ||
Allowed. | Allowed. | ||
− | Whether recipients are to be told Disclose- RFC 1327, not for | + | Whether recipients are to be told Disclose- [[RFC1327|RFC 1327]], not for |
the names of other recipients of Recipients: general usage. | the names of other recipients of Recipients: general usage. | ||
the same message. This is | the same message. This is | ||
Line 238: | Line 215: | ||
bcc: headers. | bcc: headers. | ||
− | Whether a MIME body part is to be Content- RFC 1806, | + | Whether a MIME body part is to be Content- [[RFC1806|RFC 1806]], |
shown inline or is an attachment; Disposition: experimental | shown inline or is an attachment; Disposition: experimental | ||
can also indicate a suggested | can also indicate a suggested | ||
Line 246: | Line 223: | ||
=== Sender and recipient indication === | === Sender and recipient indication === | ||
− | Authors or persons taking From: RFC 822: 4.4.1, | + | Authors or persons taking From: [[RFC822|RFC 822]]: 4.4.1, |
− | responsibility for the message. RFC 1123: 5.2.15- | + | responsibility for the message. [[RFC1123|RFC 1123]]: 5.2.15- |
16, 5.3.7, | 16, 5.3.7, | ||
− | Note difference from the "From " RFC 1036 2.1.1 | + | Note difference from the "From " [[RFC1036|RFC 1036]] 2.1.1 |
header (not followed by ":") | header (not followed by ":") | ||
below. | below. | ||
Line 281: | Line 258: | ||
message are to be sent. | message are to be sent. | ||
− | (2) Used in Usenet News mail From RFC 976: 2.4 for | + | (2) Used in Usenet News mail From [[RFC976|RFC 976]]: 2.4 for |
transport, to indicate the path or use in Usenet News | transport, to indicate the path or use in Usenet News | ||
through which an article has gone >From | through which an article has gone >From | ||
Line 288: | Line 265: | ||
Sometimes called "From_" header. | Sometimes called "From_" header. | ||
− | Name of the moderator of the Approved: RFC 1036: 2.2.11, | + | Name of the moderator of the Approved: [[RFC1036|RFC 1036]]: 2.2.11, |
newsgroup to which this article not standardized | newsgroup to which this article not standardized | ||
is sent; necessary on an article for use in e-mail. | is sent; necessary on an article for use in e-mail. | ||
Line 298: | Line 275: | ||
marked as Approved. | marked as Approved. | ||
− | The person or agent submitting Sender: RFC 822: 4.4.2, | + | The person or agent submitting Sender: [[RFC822|RFC 822]]: 4.4.2, |
− | the message to the network, if RFC 1123: 5.2.15- | + | the message to the network, if [[RFC1123|RFC 1123]]: 5.2.15- |
other than shown by the From: 16, 5.3.7. | other than shown by the From: 16, 5.3.7. | ||
header. | header. | ||
− | Primary recipients. To: RFC 822: 4.5.1, | + | Primary recipients. To: [[RFC822|RFC 822]]: 4.5.1, |
− | RFC 1123: 5.2.15- | + | [[RFC1123|RFC 1123]]: 5.2.15- |
16, 5.3.7. | 16, 5.3.7. | ||
− | Secondary, informational cc: RFC 822: 4.5.2, | + | Secondary, informational cc: [[RFC822|RFC 822]]: 4.5.2, |
− | recipients. (cc = Carbon Copy) RFC 1123. 5.2.15- | + | recipients. (cc = Carbon Copy) [[RFC1123|RFC 1123]]. 5.2.15- |
16, 5.3.7. | 16, 5.3.7. | ||
− | Recipients not to be disclosed to bcc: RFC 822: 4.5.3, | + | Recipients not to be disclosed to bcc: [[RFC822|RFC 822]]: 4.5.3, |
− | other recipients. (bcc = Blind RFC 1123: 5.2.15- | + | other recipients. (bcc = Blind [[RFC1123|RFC 1123]]: 5.2.15- |
Carbon Copy). 16, 5.3.7. | Carbon Copy). 16, 5.3.7. | ||
Line 325: | Line 302: | ||
or its attachments. | or its attachments. | ||
− | In Usenet News: group(s) to which Newsgroups: RFC 1036: 2.1.3, | + | In Usenet News: group(s) to which Newsgroups: [[RFC1036|RFC 1036]]: 2.1.3, |
this article was posted. not standardized | this article was posted. not standardized | ||
Some systems provide this header and controversial | Some systems provide this header and controversial | ||
Line 350: | Line 327: | ||
is no "To:" recipient in the To: discouraged, | is no "To:" recipient in the To: discouraged, | ||
original message, listing mentioned in | original message, listing mentioned in | ||
− | recipients derived from the RFC 1211. | + | recipients derived from the [[RFC1211|RFC 1211]]. |
envelope into the message | envelope into the message | ||
heading. This behavior is not | heading. This behavior is not | ||
Line 360: | Line 337: | ||
recipients. | recipients. | ||
− | Geographical or organizational Distribution: RFC 1036: 2.2.7, | + | Geographical or organizational Distribution: [[RFC1036|RFC 1036]]: 2.2.7, |
limitation on where this article not standardized | limitation on where this article not standardized | ||
can be distributed. for use in e-mail. | can be distributed. for use in e-mail. | ||
Line 379: | Line 356: | ||
=== Response control === | === Response control === | ||
− | This header is meant to indicate Reply-To: RFC 822: 4.4.3, | + | This header is meant to indicate Reply-To: [[RFC822|RFC 822]]: 4.4.3, |
− | where the sender wants replies to RFC 1036: 2.2.1 | + | where the sender wants replies to [[RFC1036|RFC 1036]]: 2.2.1 |
go. Unfortunately, this is controversial. | go. Unfortunately, this is controversial. | ||
ambiguous, since there are | ambiguous, since there are | ||
Line 410: | Line 387: | ||
the area. | the area. | ||
− | Used in Usenet News to indicate Followup-To: RFC 1036: 2.2.3, | + | Used in Usenet News to indicate Followup-To: [[RFC1036|RFC 1036]]: 2.2.3, |
that future discussions (=follow- not standardized | that future discussions (=follow- not standardized | ||
up) on an article should go to a for use in e-mail. | up) on an article should go to a for use in e-mail. | ||
Line 443: | Line 420: | ||
to be sent. | to be sent. | ||
− | Whether non-delivery report is Prevent- RFC 1327, not for | + | Whether non-delivery report is Prevent- [[RFC1327|RFC 1327]], not for |
wanted at delivery error. Default NonDelivery- general usage. | wanted at delivery error. Default NonDelivery- general usage. | ||
is to want such a report. Report: | is to want such a report. Report: | ||
− | Whether a delivery report is Generate- RFC 1327, not for | + | Whether a delivery report is Generate- [[RFC1327|RFC 1327]], not for |
wanted at successful delivery. Delivery- general usage. | wanted at successful delivery. Delivery- general usage. | ||
Default is not to generate such a Report: | Default is not to generate such a Report: | ||
report. | report. | ||
− | Indicates whether the content of Content- RFC 1327, not for | + | Indicates whether the content of Content- [[RFC1327|RFC 1327]], not for |
a message is to be returned with Return: general usage. | a message is to be returned with Return: general usage. | ||
non-delivery notifications. | non-delivery notifications. | ||
Line 461: | Line 438: | ||
=== Message identification and referral headers === | === Message identification and referral headers === | ||
− | Unique ID of this message. Message-ID: RFC 822: 4.6.1 | + | Unique ID of this message. Message-ID: [[RFC822|RFC 822]]: 4.6.1 |
− | RFC 1036: 2.1.5. | + | [[RFC1036|RFC 1036]]: 2.1.5. |
− | Unique ID of one body part of the Content-ID: RFC 1521: 6.1. | + | Unique ID of one body part of the Content-ID: [[RFC1521|RFC 1521]]: 6.1. |
content of a message. | content of a message. | ||
Line 475: | Line 452: | ||
retrievable. | retrievable. | ||
− | Reference to message which this In-Reply-To: RFC 822: 4.6.2. | + | Reference to message which this In-Reply-To: [[RFC822|RFC 822]]: 4.6.2. |
message is a reply to. | message is a reply to. | ||
− | In e-mail: reference to other References: RFC 822: 4.6.3 | + | In e-mail: reference to other References: [[RFC822|RFC 822]]: 4.6.3 |
− | related messages, in Usenet News: RFC 1036: 2.1.5. | + | related messages, in Usenet News: [[RFC1036|RFC 1036]]: 2.1.5. |
reference to replied-to-articles. | reference to replied-to-articles. | ||
Line 485: | Line 462: | ||
articles in Usenet News. [21], non-standard | articles in Usenet News. [21], non-standard | ||
− | Reference to previous message Obsoletes: RFC 1327, not for | + | Reference to previous message Obsoletes: [[RFC1327|RFC 1327]], not for |
being corrected and replaced. general usage. | being corrected and replaced. general usage. | ||
Compare to "Supersedes:" below. | Compare to "Supersedes:" below. | ||
Line 513: | Line 490: | ||
=== Other textual headers === | === Other textual headers === | ||
− | Search keys for data base Keywords: RFC 822: 4.7.1 | + | Search keys for data base Keywords: [[RFC822|RFC 822]]: 4.7.1 |
− | retrieval. RFC 1036: 2.2.9. | + | retrieval. [[RFC1036|RFC 1036]]: 2.2.9. |
− | Title, heading, subject. Often Subject: RFC 822: 4.7.1 | + | Title, heading, subject. Often Subject: [[RFC822|RFC 822]]: 4.7.1 |
− | used as thread indicator for RFC 1036: 2.1.4. | + | used as thread indicator for [[RFC1036|RFC 1036]]: 2.1.4. |
messages replying to or | messages replying to or | ||
commenting on other messages. | commenting on other messages. | ||
− | Comments on a message. Comments: RFC 822: 4.7.2. | + | Comments on a message. Comments: [[RFC822|RFC 822]]: 4.7.2. |
− | Description of a particular body Content- RFC 1521: 6.2. | + | Description of a particular body Content- [[RFC1521|RFC 1521]]: 6.2. |
part of a message. Description: | part of a message. Description: | ||
− | Organization to which the sender Organization: RFC 1036: 2.2.8, | + | Organization to which the sender Organization: [[RFC1036|RFC 1036]]: 2.2.8, |
of this article belongs. not standardized | of this article belongs. not standardized | ||
for use in e-mail. | for use in e-mail. | ||
Line 532: | Line 509: | ||
See Organization above. Organisation: Non-standard. | See Organization above. Organisation: Non-standard. | ||
− | Short text describing a longer Summary: RFC 1036: 2.2.10, | + | Short text describing a longer Summary: [[RFC1036|RFC 1036]]: 2.2.10, |
article. Warning: Some mail not standardized | article. Warning: Some mail not standardized | ||
systems will not display this for use in e-mail, | systems will not display this for use in e-mail, | ||
Line 540: | Line 517: | ||
that the recipient gets. | that the recipient gets. | ||
− | A text string which identifies Content- RFC 1327, not for | + | A text string which identifies Content- [[RFC1327|RFC 1327]], not for |
the content of a message. Identifier: general usage. | the content of a message. Identifier: general usage. | ||
=== Headers containing dates and times === | === Headers containing dates and times === | ||
− | The time when a message was Delivery- RFC 1327, not for | + | The time when a message was Delivery- [[RFC1327|RFC 1327]], not for |
delivered to its recipient. Date: general usage. | delivered to its recipient. Date: general usage. | ||
− | In Internet, the date when a Date: RFC 822: 5.1, | + | In Internet, the date when a Date: [[RFC822|RFC 822]]: 5.1, |
− | message was written, in X.400, RFC 1123: 5.2.14 | + | message was written, in X.400, [[RFC1123|RFC 1123]]: 5.2.14 |
− | the time a message was submitted. RFC 1036: 2.1.2. | + | the time a message was submitted. [[RFC1036|RFC 1036]]: 2.1.2. |
Some Internet mail systems also | Some Internet mail systems also | ||
use the date when the message was | use the date when the message was | ||
submitted. | submitted. | ||
− | A suggested expiration date. Can Expires: RFC 1036: 2.2.4, | + | A suggested expiration date. Can Expires: [[RFC1036|RFC 1036]]: 2.2.4, |
be used both to limit the time of not standardized | be used both to limit the time of not standardized | ||
an article which is not for use in e-mail. | an article which is not for use in e-mail. | ||
Line 562: | Line 539: | ||
important articles. | important articles. | ||
− | Time at which a message loses its Expiry-Date: RFC 1327, not for | + | Time at which a message loses its Expiry-Date: [[RFC1327|RFC 1327]], not for |
validity. This field may in the general usage. | validity. This field may in the general usage. | ||
future be replaced by "Expires:". | future be replaced by "Expires:". | ||
− | Latest time at which a reply is Reply-By: RFC 1327, not for | + | Latest time at which a reply is Reply-By: [[RFC1327|RFC 1327]], not for |
requested (not demanded). general usage. | requested (not demanded). general usage. | ||
=== Quality information === | === Quality information === | ||
− | Can be "normal", "urgent" or "non- Priority: RFC 1327, not for | + | Can be "normal", "urgent" or "non- Priority: [[RFC1327|RFC 1327]], not for |
urgent" and can influence general usage. | urgent" and can influence general usage. | ||
transmission speed and delivery. | transmission speed and delivery. | ||
Line 585: | Line 562: | ||
list loops. | list loops. | ||
− | A hint from the originator to the Importance: RFC 1327 and | + | A hint from the originator to the Importance: [[RFC1327|RFC 1327]] and |
− | recipients about how important a RFC 1911, | + | recipients about how important a [[RFC1911|RFC 1911]], |
message is. Values: High, normal experimental | message is. Values: High, normal experimental | ||
or low. Not used to control | or low. Not used to control | ||
transmission speed. | transmission speed. | ||
− | How sensitive it is to disclose Sensitivity: RFC 1327 and | + | How sensitive it is to disclose Sensitivity: [[RFC1327|RFC 1327]] and |
− | this message to other people than RFC 1911, | + | this message to other people than [[RFC1911|RFC 1911]], |
the specified recipients. Values: experimental | the specified recipients. Values: experimental | ||
Personal, private, company | Personal, private, company | ||
Line 600: | Line 577: | ||
is not sensitive. | is not sensitive. | ||
− | Body parts are missing. Incomplete- RFC 1327, not for | + | Body parts are missing. Incomplete- [[RFC1327|RFC 1327]], not for |
Copy: general usage. | Copy: general usage. | ||
3.10 Language information | 3.10 Language information | ||
− | Can include a code for the Language: RFC 1327, not for | + | Can include a code for the Language: [[RFC1327|RFC 1327]], not for |
natural language used in a general usage. | natural language used in a general usage. | ||
message, e.g. "en" for English. | message, e.g. "en" for English. | ||
− | Can include a code for the Content- RFC 1766, proposed | + | Can include a code for the Content- [[RFC1766|RFC 1766]], proposed |
natural language used in a Language: standard. | natural language used in a Language: standard. | ||
message, e.g. "en" for English. | message, e.g. "en" for English. | ||
Line 628: | Line 605: | ||
problems. | problems. | ||
− | Size of the message. Lines: RFC 1036: 2.2.12, | + | Size of the message. Lines: [[RFC1036|RFC 1036]]: 2.2.12, |
not standardized | not standardized | ||
for use in e-mail. | for use in e-mail. | ||
Line 634: | Line 611: | ||
3.12 Conversion control | 3.12 Conversion control | ||
− | The body of this message may not Conversion: RFC 1327, not for | + | The body of this message may not Conversion: [[RFC1327|RFC 1327]], not for |
be converted from one character general usage. | be converted from one character general usage. | ||
set to another. Values: | set to another. Values: | ||
Line 642: | Line 619: | ||
Conversion: with the same values. Conversion: | Conversion: with the same values. Conversion: | ||
− | The body of this message may not Conversion- RFC 1327, not for | + | The body of this message may not Conversion- [[RFC1327|RFC 1327]], not for |
be converted from one character With-Loss: general usage. | be converted from one character With-Loss: general usage. | ||
set to another if information | set to another if information | ||
Line 650: | Line 627: | ||
3.13 Encoding information | 3.13 Encoding information | ||
− | Format of content (character set Content-Type: RFC 1049, | + | Format of content (character set Content-Type: [[RFC1049|RFC 1049]], |
− | etc.) Note that the values for RFC 1123: 5.2.13, | + | etc.) Note that the values for [[RFC1123|RFC 1123]]: 5.2.13, |
− | this header are defined in RFC 1521: 4. | + | this header are defined in [[RFC1521|RFC 1521]]: 4. |
− | different ways in RFC 1049 and in RFC 1766: 4.1 | + | different ways in [[RFC1049|RFC 1049]] and in [[RFC1766|RFC 1766]]: 4.1 |
− | MIME (RFC 1521), look for the | + | MIME ([[RFC1521|RFC 1521]]), look for the |
"MIME-version" header to | "MIME-version" header to | ||
understand if Content-Type is to | understand if Content-Type is to | ||
Line 662: | Line 639: | ||
generating mail. | generating mail. | ||
− | RFC 1766 defines a parameter | + | [[RFC1766|RFC 1766]] defines a parameter |
"difference" to this header. | "difference" to this header. | ||
Line 670: | Line 647: | ||
the body part. | the body part. | ||
− | Coding method used in a MIME Content- RFC 1521: 5. | + | Coding method used in a MIME Content- [[RFC1521|RFC 1521]]: 5. |
message body. Transfer- | message body. Transfer- | ||
Encoding: | Encoding: | ||
− | Only used with the value Message-Type: RFC 1327, not for | + | Only used with the value Message-Type: [[RFC1327|RFC 1327]], not for |
"Delivery Report" to indicates general usage. | "Delivery Report" to indicates general usage. | ||
that this is a delivery report | that this is a delivery report | ||
gatewayed from X.400. | gatewayed from X.400. | ||
− | Used in several different ways by Encoding: RFC 1154, | + | Used in several different ways by Encoding: [[RFC1154|RFC 1154]], |
− | different mail systems. Some use RFC 1505, | + | different mail systems. Some use [[RFC1505|RFC 1505]], |
it for a kind of content-type experimental. | it for a kind of content-type experimental. | ||
information, some for encoding | information, some for encoding | ||
Line 689: | Line 666: | ||
3.14 Resent-headers | 3.14 Resent-headers | ||
− | When manually forwarding a Resent-Reply- RFC 822: C.3.3. | + | When manually forwarding a Resent-Reply- [[RFC822|RFC 822]]: C.3.3. |
message, headers referring to the To:, | message, headers referring to the To:, | ||
forwarding, not to the original Resent-From:, | forwarding, not to the original Resent-From:, | ||
Line 704: | Line 681: | ||
3.15 Security and reliability | 3.15 Security and reliability | ||
− | Checksum of content to ensure Content-MD5: RFC 1864, proposed | + | Checksum of content to ensure Content-MD5: [[RFC1864|RFC 1864]], proposed |
that it has not been modified. standard. | that it has not been modified. standard. | ||
− | Used in Usenet News to store Xref: RFC 1036: 2.2.13, | + | Used in Usenet News to store Xref: [[RFC1036|RFC 1036]]: 2.2.13, |
information to avoid showing a only in Usenet | information to avoid showing a only in Usenet | ||
reader the same article twice if News, not in e- | reader the same article twice if News, not in e- | ||
Line 721: | Line 698: | ||
this message is stored. | this message is stored. | ||
− | Has been automatically forwarded. Auto- RFC 1327, not for | + | Has been automatically forwarded. Auto- [[RFC1327|RFC 1327]], not for |
Forwarded: general usage. | Forwarded: general usage. | ||
− | Can be used in Internet mail to Discarded- RFC 1327, not for | + | Can be used in Internet mail to Discarded- [[RFC1327|RFC 1327]], not for |
indicate X.400 IPM extensions X400-IPMS- general usage. | indicate X.400 IPM extensions X400-IPMS- general usage. | ||
which could not be mapped to Extensions: | which could not be mapped to Extensions: | ||
Internet mail format. | Internet mail format. | ||
− | Can be used in Internet mail to Discarded- RFC 1327, not for | + | Can be used in Internet mail to Discarded- [[RFC1327|RFC 1327]], not for |
indicate X.400 MTS extensions X400-MTS- general usage. | indicate X.400 MTS extensions X400-MTS- general usage. | ||
which could not be mapped to Extensions: | which could not be mapped to Extensions: | ||
Line 778: | Line 755: | ||
----- --------------------------------------------- ----------- | ----- --------------------------------------------- ----------- | ||
[1] J. Postel: "Simple Mail Transfer Protocol", Standard, | [1] J. Postel: "Simple Mail Transfer Protocol", Standard, | ||
− | STD 10, RFC 821, August 1982. Recommended | + | [[STD10|STD 10]], [[RFC821|RFC 821]], August 1982. Recommended |
[2] D. Crocker: "Standard for the format of ARPA Standard, | [2] D. Crocker: "Standard for the format of ARPA Standard, | ||
− | Internet text messages." STD 11, RFC 822, Recommended | + | Internet text messages." [[STD11|STD 11]], [[RFC822|RFC 822]], Recommended |
August 1982. | August 1982. | ||
[3] M.R. Horton, R. Adams: "Standard for Not an offi- | [3] M.R. Horton, R. Adams: "Standard for Not an offi- | ||
− | interchange of USENET messages", RFC 1036, cial IETF | + | interchange of USENET messages", [[RFC1036|RFC 1036]], cial IETF |
December 1987. standard, | December 1987. standard, | ||
but in | but in | ||
Line 794: | Line 771: | ||
[4] M. Sirbu: "A Content-Type header header for Standard, | [4] M. Sirbu: "A Content-Type header header for Standard, | ||
− | internet messages", RFC 1049, March 1988. Recommended, | + | internet messages", [[RFC1049|RFC 1049]], March 1988. Recommended, |
but can in | but can in | ||
the future | the future | ||
Line 804: | Line 781: | ||
[5] R. Braden (editor): "Requirements for Standard, | [5] R. Braden (editor): "Requirements for Standard, | ||
Internet Hosts -- Application and Support", Required | Internet Hosts -- Application and Support", Required | ||
− | STD-3, RFC 1123, October 1989. | + | STD-3, [[RFC1123|RFC 1123]], October 1989. |
[6] D. Robinson, R. Ullman: "Encoding Header Non-standard | [6] D. Robinson, R. Ullman: "Encoding Header Non-standard | ||
− | Header for Internet Messages", RFC 1154, | + | Header for Internet Messages", [[RFC1154|RFC 1154]], |
April 1990. | April 1990. | ||
[7] S. Hardcastle-Kille: "Mapping between Proposed | [7] S. Hardcastle-Kille: "Mapping between Proposed | ||
− | X.400(1988) / ISO 10021 and RFC 822", RFC standard, | + | X.400(1988) / ISO 10021 and [[RFC822|RFC 822]]", RFC standard, |
1327 May 1992. elective | 1327 May 1992. elective | ||
Line 817: | Line 794: | ||
Downgrading Messages from X.400/88 to standard, | Downgrading Messages from X.400/88 to standard, | ||
X.400/84 When MIME Content-Types are Present elective | X.400/84 When MIME Content-Types are Present elective | ||
− | in the Messages", RFC 1496, August 1993. | + | in the Messages", [[RFC1496|RFC 1496]], August 1993. |
[9] A. Costanzo: "Encoding Header Header for Non-standard | [9] A. Costanzo: "Encoding Header Header for Non-standard | ||
− | Internet Messages", RFC 1154, April 1990. | + | Internet Messages", [[RFC1154|RFC 1154]], April 1990. |
[10] A. Costanzo, D. Robinson: "Encoding Header Experimental | [10] A. Costanzo, D. Robinson: "Encoding Header Experimental | ||
− | Header for Internet Messages", RFC 1505, | + | Header for Internet Messages", [[RFC1505|RFC 1505]], |
August 1993. | August 1993. | ||
Line 829: | Line 806: | ||
Internet Mail Extensions) Part One: Standard, | Internet Mail Extensions) Part One: Standard, | ||
Mechanisms for Specifying and Describing the elective | Mechanisms for Specifying and Describing the elective | ||
− | Format of Internet Message Bodies", RFC 1521, | + | Format of Internet Message Bodies", [[RFC1521|RFC 1521]], |
Sept 1993. | Sept 1993. | ||
[12] H. Alvestrand: "Tags for the Identification Proposed | [12] H. Alvestrand: "Tags for the Identification Proposed | ||
− | of Languages", RFC 1766, February 1995. standard, | + | of Languages", [[RFC1766|RFC 1766]], February 1995. standard, |
elective | elective | ||
Line 842: | Line 819: | ||
Presentation Information in Internet | Presentation Information in Internet | ||
Messages: The Content-Disposition Header", | Messages: The Content-Disposition Header", | ||
− | RFC 1806, June 1995. | + | [[RFC1806|RFC 1806]], June 1995. |
[15] B. Kantor, P. Lapsley, "Network News Transfer Proposed | [15] B. Kantor, P. Lapsley, "Network News Transfer Proposed | ||
Protocol: "A Proposed Standard for the Stream- standard | Protocol: "A Proposed Standard for the Stream- standard | ||
− | Based Transmission of News", RFC 977, January | + | Based Transmission of News", [[RFC977|RFC 977]], January |
1986. | 1986. | ||
[16] 1848 PS S. Crocker, N. Freed, J. Galvin, Proposed | [16] 1848 PS S. Crocker, N. Freed, J. Galvin, Proposed | ||
S. Murphy, "MIME Object Security Services", standard | S. Murphy, "MIME Object Security Services", standard | ||
− | RFC 1848, March 1995. | + | [[RFC1848|RFC 1848]], March 1995. |
[17] J. Myers, M. Rose: The Content-MD5 Header Draft | [17] J. Myers, M. Rose: The Content-MD5 Header Draft | ||
− | Header, RFC 1864, October 1995. standard | + | Header, [[RFC1864|RFC 1864]], October 1995. standard |
[18] M. Horton, UUCP mail interchange format Not an offi- | [18] M. Horton, UUCP mail interchange format Not an offi- | ||
− | standard, RFC 976, Januari 1986. cial IETF | + | standard, [[RFC976|RFC 976]], Januari 1986. cial IETF |
standard, | standard, | ||
but in | but in | ||
Line 867: | Line 844: | ||
[19] T. Berners-Lee, R. Headering, H. Frystyk: Not an official | [19] T. Berners-Lee, R. Headering, H. Frystyk: Not an official | ||
Hypertext Transfer Protocol -- HTTP/1.0, IETF standard, | Hypertext Transfer Protocol -- HTTP/1.0, IETF standard, | ||
− | RFC 1945, May 1996. but the defacto | + | [[RFC1945|RFC 1945]], May 1996. but the defacto |
standard until | standard until | ||
the next | the next | ||
Line 874: | Line 851: | ||
[20] G. Vaudreuil: Voice Profile for Internet Experimental | [20] G. Vaudreuil: Voice Profile for Internet Experimental | ||
− | Mail, RFC 1911, February 1996. | + | Mail, [[RFC1911|RFC 1911]], February 1996. |
[21] H. Spencer: News Article Format and Not even an | [21] H. Spencer: News Article Format and Not even an | ||
Line 896: | Line 873: | ||
Headers sorted by Internet RFC document in which they appear. | Headers sorted by Internet RFC document in which they appear. | ||
− | RFC 822 | + | [[RFC822|RFC 822]] |
------- | ------- | ||
Line 925: | Line 902: | ||
To | To | ||
− | RFC 976 | + | [[RFC976|RFC 976]] |
------- | ------- | ||
"From " (followed by space, not colon (:") | "From " (followed by space, not colon (:") | ||
− | RFC 1036 | + | [[RFC1036|RFC 1036]] |
-------- | -------- | ||
Line 945: | Line 922: | ||
Xref | Xref | ||
− | RFC 1049 | + | [[RFC1049|RFC 1049]] |
-------- | -------- | ||
Content-Type | Content-Type | ||
− | RFC 1327 | + | [[RFC1327|RFC 1327]] |
-------- | -------- | ||
Line 979: | Line 956: | ||
Sensitivity | Sensitivity | ||
− | RFC 1505 | + | [[RFC1505|RFC 1505]] |
-------- | -------- | ||
Encoding | Encoding | ||
− | RFC 1521 | + | [[RFC1521|RFC 1521]] |
-------- | -------- | ||
Line 993: | Line 970: | ||
MIME-Version | MIME-Version | ||
− | RFC 1806 | + | [[RFC1806|RFC 1806]] |
-------- | -------- | ||
Content-Disposition | Content-Disposition | ||
− | RFC 1864 | + | [[RFC1864|RFC 1864]] |
-------- | -------- | ||
Content-MD5 | Content-MD5 | ||
− | RFC 1911 | + | [[RFC1911|RFC 1911]] |
-------- | -------- | ||
Line 1,161: | Line 1,138: | ||
3.4 X-Newsreader | 3.4 X-Newsreader | ||
3.15 Xref | 3.15 Xref | ||
+ | |||
+ | [[Category:Informational]] |
Latest revision as of 14:56, 19 October 2020
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
Appendix A: Headers sorted by Internet RFC document in which they appear. 21 Appendix B:
Contents
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)
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 <[email protected]>) if you have noted headers which should be included in this memo but are not.
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.
Table of headers
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.
"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.
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:
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:
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.
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.
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.
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.
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
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.).
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.
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:
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:".
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.
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.
A text string which identifies Content- RFC 1327, not for the content of a message. Identifier: general usage.
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.
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.
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.
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.
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.
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.
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].
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.
[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
[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
Author's Address
Jacob Palme Phone: +46-8-16 16 67 Stockholm University/KTH Fax: +46-8-783 08 29 Electrum 230 E-mail: [email protected] S-164 40 Kista, Sweden
Appendix A: Headers sorted by Internet RFC document in which they appear.
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
"From " (followed by space, not colon (:")
Approved Control Distribution Expires Followup-To Lines Newsgroups Organization Path Summary Xref
Content-Type
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
Encoding
Content-Description Content-ID Content-Transfer-Encoding Content-Type MIME-Version
Content-Disposition
Content-MD5
Importance Sensitivity
son-of-RFC1036 [21]
Also-Control Article-Names Article-Updates See-Also Supersedes
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
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
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
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