7Network Working Group J. Palme
8Request for Comments: 2076 Stockholm University/KTH
9Category: Informational February 1997
12 Common Internet Message Headers
16 This memo provides information for the Internet community. This memo
17 does not specify an Internet standard of any kind. Distribution of
18 this memo is unlimited.
22 This memo contains a table of commonly occurring headers in headings
23 of e-mail messages. The document compiles information from other RFCs
24 such as RFC 822, RFC 1036, RFC 1123, RFC 1327, RFC 1496, RFC 1521,
25 RFC 1766, RFC 1806, RFC 1864 and RFC 1911. A few commonly occurring
26 headers which are not defined in RFCs are also included. For each
27 header, the memo gives a short description and a reference to the RFC
28 in which the header is defined.
31 1. Introduction.............................................. 2
32 2. Use of gatewaying headers................................. 3
33 3. Table of headers.......................................... 3
34 3.1 Phrases used in the tables.......................... 3
35 3.2 Trace information................................... 5
36 3.3 Format and control information...................... 5
37 3.4 Sender and recipient indication..................... 6
38 3.5 Response control.................................... 9
39 3.6 Message identification and referral headers......... 11
40 3.7 Other textual headers............................... 12
41 3.8 Headers containing dates and times.................. 13
42 3.9 Quality information................................. 13
43 3.10 Language information............................... 14
44 3.11 Size information................................... 14
45 3.12 Conversion control................................. 15
46 3.13 Encoding information............................... 15
47 3.14 Resent-headers..................................... 16
48 3.15 Security and reliability........................... 16
49 3.16 Miscellaneous...................................... 16
50 4. Acknowledgments........................................... 18
58Palme Informational [Page 1]
60RFC 2076 Internet Message Headers February 1997
63 5. References................................................ 18
64 6. Author's Address.......................................... 20
66 Headers sorted by Internet RFC document in which they appear. 21
68 Alphabetical index........................................... 25
72 Many different Internet standards and RFCs define headers which may
73 occur on Internet Mail Messages and Usenet News Articles. The
74 intention of this document is to list all such headers in one
75 document as an aid to people developing message systems or interested
76 in Internet Mail standards.
78 The document contains all headers which the author has found in the
79 following Internet standards: , RFC 822 [2], RFC 1036 [3], RFC 1123
80 [5], RFC 1327 [7], RFC 1496 [8], RFC 1521 [11], RFC 1766 [12], RFC
81 1806 [14], RFC 1864[17] and RFC 1911[20]. Note in particular that
82 heading attributes defined in PEM (RFC 1421-1424) and MOSS (RFC 1848
83 [16]) are not included. PEM and MOSS headers only appear inside the
84 body of a message, and thus are not headers in the RFC 822 sense.
85 Mail attributes in envelopes, i.e. attributes controlling the message
86 transport mechanism between mail and news servers, are not included.
87 This means that attributes from SMTP [1], UUCP [18] and NNTP [15] are
88 mainly not covered either. Headings used only in HTTP [19] are not
89 included yet, but may be included in future version of this memo. A
90 few additional headers which often can be found in e-mail headings
91 but are not part of any Internet standard are also included.
93 For each header, the document gives a short description and a
94 reference to the Internet standard or RFC, in which they are defined.
96 The header names given here are spelled the same way as when they are
97 actually used. This is usually American but sometimes English
98 spelling. One header in particular, "Organisation/Organization",
99 occurs in e-mail headers sometimes with the English and other times
100 with the American spelling.
102 The following words are used in this memo with the meaning specified
105 heading Formatted text at the top of a message, ended by a
108 header = heading One field in the heading, beginning with a field
109 field name, colon, and followed by the field value(s)
114Palme Informational [Page 2]
116RFC 2076 Internet Message Headers February 1997
119 It is my intention to continue updating this document after its
120 publication as an RFC. The latest version, which may be more up-to-
121 date (but also less fully checked out) will be kept available for
123 http://www.dsv.su.se/~jpalme/ietf-mail-attributes.pdf.
125 Please e-mail me (Jacob Palme <jpalme@dsv.su.se>) if you have noted
126 headers which should be included in this memo but are not.
1282. Use of gatewaying headers
130 RFC 1327 defines a number of new headers in Internet mail, which are
131 defined to map headers which X.400 has but which were previously not
132 standardized in Internet mail. The fact that a header occurs in RFC
133 1327 indicates that it is recommended for use in gatewaying messages
134 between X.400 and Internet mail, but does not mean that the header is
135 recommended for messages wholly within Internet mail. Some of these
136 headers may eventually see widespread implementation and use in
137 Internet mail, but at the time of this writing (1996) they are not
138 widely implemented or used.
140 Headers defined only in RFC 1036 for use in Usenet News sometimes
141 appear in mail messages, either because the messages have been
142 gatewayed from Usenet News to e-mail, or because the messages were
143 written in combined clients supporting both e-mail and Usenet News in
144 the same client. These headers are not standardized for use in
145 Internet e-mail and should be handled with caution by e-mail agents.
1493.1 Phrases used in the tables
151 "not for general Used to mark headers which are defined in RFC
152 usage" 1327 for use in messages from or to Internet
153 mail/X.400 gateways. These headers have not
154 been standardized for general usage in the
155 exchange of messages between Internet mail-
170Palme Informational [Page 3]
172RFC 2076 Internet Message Headers February 1997
175 "not standardized Used to mark headers defined only in RFC 1036
176 for use in e-mail" for use in Usenet News. These headers have no
177 standard meaning when appearing in e-mail,
178 some of them may even be used in different
179 ways by different software. When appearing in
180 e-mail, they should be handled with caution.
181 Note that RFC 1036, although generally used as
182 a de-facto standard for Usenet News, is not an
183 official IETF standard or even on the IETF
186 "non-standard" This header is not specified in any of
187 referenced RFCs which define Internet
188 protocols, including Internet Standards, draft
189 standards or proposed standards. The header
190 appears here because it often appears in e-
191 mail or Usenet News. Usage of these headers is
192 not in general recommended. Some header
193 proposed in ongoing IETF standards development
194 work, but not yet accepted, are also marked in
197 "discouraged" This header, which is non-standard, is known
198 to create problems and should not be
199 generated. Handling of such headers in
200 incoming mail should be done with great
203 "controversial" The meaning and usage of this header is
204 controversial, i.e. different implementors
205 have chosen to implement the header in
206 different ways. Because of this, such headers
207 should be handled with caution and
208 understanding of the different possible
211 "experimental" This header is used for newly defined headers,
212 which are to be tried out before entering the
213 IETF standards track. These should only be
214 used if both communicating parties agree on
215 using them. In practice, some experimental
216 protocols become de-facto-standards before
217 they are made into IETF standards.
226Palme Informational [Page 4]
228RFC 2076 Internet Message Headers February 1997
233 Used to convey the information Return-Path: RFC 821,
234 from the MAIL FROM envelope RFC 1123: 5.2.13.
235 attribute in final delivery, when
236 the message leaves the SMTP
237 environment in which "MAIL FROM"
240 Trace of MTAs which a message has Received: RFC 822: 4.3.2,
241 passed. RFC 1123: 5.2.8.
243 List of MTAs passed. Path: RFC 1036: 2.1.6,
248 Trace of distribution lists DL-Expansion- RFC 1327, not for
249 passed. History- general usage.
2523.3 Format and control information
254 An indicator that this message is MIME-Version: RFC 1521: 3.
255 formatted according to the MIME
256 standard, and an indication of
257 which version of MIME is
260 Special Usenet News actions only. Control: RFC 1036: 2.1.6,
265 Special Usenet News actions and a Also-Control: son-of-RFC1036
266 normal article at the same time. [21], non-
271 Which body part types occur in Original- RFC 1327, not for
272 this message. Encoded- general usage.
282Palme Informational [Page 5]
284RFC 2076 Internet Message Headers February 1997
287 Controls whether this message may Alternate- RFC 1327, not for
288 be forwarded to alternate Recipient: general usage.
289 recipients such as a postmaster
290 if delivery is not possible to
291 the intended recipient. Default:
294 Whether recipients are to be told Disclose- RFC 1327, not for
295 the names of other recipients of Recipients: general usage.
296 the same message. This is
297 primarily an X.400 facility. In
298 X.400, this is an envelope
299 attribute and refers to
300 disclosure of the envelope
301 recipient list. Disclosure of
302 other recipients is in Internet
303 mail done via the To:, cc: and
306 Whether a MIME body part is to be Content- RFC 1806,
307 shown inline or is an attachment; Disposition: experimental
308 can also indicate a suggested
309 filename for use when saving an
310 attachment to a file.
3123.4 Sender and recipient indication
314 Authors or persons taking From: RFC 822: 4.4.1,
315 responsibility for the message. RFC 1123: 5.2.15-
317 Note difference from the "From " RFC 1036 2.1.1
318 header (not followed by ":")
322 (1) This header should never From not standardized
323 appear in e-mail being sent, and for use in e-mail
324 should thus not appear in this
325 memo. It is however included,
326 since people often ask about it.
338Palme Informational [Page 6]
340RFC 2076 Internet Message Headers February 1997
343 This header is used in the so-
344 called Unix mailbox format, also
345 known as Berkely mailbox format
346 or the MBOX format. This is a
347 format for storing a set of
348 messages in a file. A line
349 beginning with "From " is used to
350 separate successive messages in
353 This header will thus appear when
354 you use a text editor to look at
355 a file in the Unix mailbox
356 format. Some mailers also use
357 this format when printing
360 The information in this header
361 should NOT be used to find an
362 address to which replies to a
363 message are to be sent.
365 (2) Used in Usenet News mail From RFC 976: 2.4 for
366 transport, to indicate the path or use in Usenet News
367 through which an article has gone >From
368 when transferred to a new host.
370 Sometimes called "From_" header.
372 Name of the moderator of the Approved: RFC 1036: 2.2.11,
373 newsgroup to which this article not standardized
374 is sent; necessary on an article for use in e-mail.
375 sent to a moderated newsgroup to
376 allow its distribution to the
377 newsgroup members. Also used on
378 certain control messages, which
379 are only performed if they are
382 The person or agent submitting Sender: RFC 822: 4.4.2,
383 the message to the network, if RFC 1123: 5.2.15-
384 other than shown by the From: 16, 5.3.7.
387 Primary recipients. To: RFC 822: 4.5.1,
394Palme Informational [Page 7]
396RFC 2076 Internet Message Headers February 1997
399 Secondary, informational cc: RFC 822: 4.5.2,
400 recipients. (cc = Carbon Copy) RFC 1123. 5.2.15-
403 Recipients not to be disclosed to bcc: RFC 822: 4.5.3,
404 other recipients. (bcc = Blind RFC 1123: 5.2.15-
405 Carbon Copy). 16, 5.3.7.
407 Primary recipients, who are For-Handling: Non-standard
408 requested to handle the
409 information in this message
412 Primary recipients, who are For-Comment: Non-standard
413 requested to comment on the
414 information in this message
417 In Usenet News: group(s) to which Newsgroups: RFC 1036: 2.1.3,
418 this article was posted. not standardized
419 Some systems provide this header and controversial
420 also in e-mail although it is not for use in e-mail.
423 Unfortunately, the header can
424 appear in e-mail with two
425 different and contradictory
428 (a) Indicating the newsgroup
429 recipient of an article/message
430 sent to both e-mail and Usenet
433 (b) In a personally addressed
434 reply to an article in a news-
435 group, indicating the newsgroup
436 in which this discussion
450Palme Informational [Page 8]
452RFC 2076 Internet Message Headers February 1997
455 Inserted by Sendmail when there Apparently- Non-standard,
456 is no "To:" recipient in the To: discouraged,
457 original message, listing mentioned in
458 recipients derived from the RFC 1211.
459 envelope into the message
460 heading. This behavior is not
461 quite proper, MTAs should not
462 modify headings (except inserting
463 Received lines), and it can in
464 some cases cause Bcc recipients
465 to be wrongly divulged to non-Bcc
468 Geographical or organizational Distribution: RFC 1036: 2.2.7,
469 limitation on where this article not standardized
470 can be distributed. for use in e-mail.
472 Fax number of the originator. Fax:, Non-standard.
475 Phone number of the originator. Phone: Non-standard.
477 Information about the client Mail-System- Non-standard.
478 software of the originator. Version:,
487 This header is meant to indicate Reply-To: RFC 822: 4.4.3,
488 where the sender wants replies to RFC 1036: 2.2.1
489 go. Unfortunately, this is controversial.
490 ambiguous, since there are
491 different kinds of replies, which
492 the sender may wish to go to
493 different addresses. In
494 particular, there are personal
495 replies intended for only one
496 person, and group replies,
497 intended for the whole group of
498 people who read the replied-to
499 message (often a mailing list,
500 anewsgroup name cannot appear
501 here because of different syntax,
502 see "Followup-To" below.).
506Palme Informational [Page 9]
508RFC 2076 Internet Message Headers February 1997
511 Some mail systems use this header
512 to indicate a better form of the
513 e-mail address of the sender.
514 Some mailing list expanders puts
515 the name of the list in this
516 header. These practices are
517 controversial. The personal
518 opinion of the author of this RFC
519 is that this header should be
520 avoided except in special cases,
521 but this is a personal opinion
522 not shared by all specialists in
525 Used in Usenet News to indicate Followup-To: RFC 1036: 2.2.3,
526 that future discussions (=follow- not standardized
527 up) on an article should go to a for use in e-mail.
528 different set of newsgroups than
529 the replied-to article. The most
530 common usage is when an article
531 is posted to several newsgroups,
532 and further discussions is to
533 take place in only one of them.
535 In e-mail, this header may occur
536 in a message which is sent to
537 both e-mail and Usenet News, to
538 show where follow-up in Usenet
539 news is wanted. The header does
540 not say anything about where
541 follow-up in e-mail is to be
544 Note that the value of this
545 header must always be one or more
546 newsgroup names, never e-mail
549 Address to which notifications Errors-To:, Non-standard,
550 are to be sent and a request to Return- discouraged.
551 get delivery notifications. Receipt-To:
552 Internet standards recommend,
553 however, the use of RCPT TO and
554 Return-Path, not Errors-To, for
555 where delivery notifications are
562Palme Informational [Page 10]
564RFC 2076 Internet Message Headers February 1997
567 Whether non-delivery report is Prevent- RFC 1327, not for
568 wanted at delivery error. Default NonDelivery- general usage.
569 is to want such a report. Report:
571 Whether a delivery report is Generate- RFC 1327, not for
572 wanted at successful delivery. Delivery- general usage.
573 Default is not to generate such a Report:
576 Indicates whether the content of Content- RFC 1327, not for
577 a message is to be returned with Return: general usage.
578 non-delivery notifications.
580 Possible future change of name X400-Content- non-standard
581 for "Content-Return:" Return:
5833.6 Message identification and referral headers
585 Unique ID of this message. Message-ID: RFC 822: 4.6.1
588 Unique ID of one body part of the Content-ID: RFC 1521: 6.1.
589 content of a message.
591 Base to be used for resolving Content-Base: Non-standard
592 relative URIs within this content
595 URI with which the content of Content- Non-standard
596 this content part might be Location:
599 Reference to message which this In-Reply-To: RFC 822: 4.6.2.
600 message is a reply to.
602 In e-mail: reference to other References: RFC 822: 4.6.3
603 related messages, in Usenet News: RFC 1036: 2.1.5.
604 reference to replied-to-articles.
606 References to other related See-Also: Son-of-RFC1036
607 articles in Usenet News. [21], non-standard
609 Reference to previous message Obsoletes: RFC 1327, not for
610 being corrected and replaced. general usage.
611 Compare to "Supersedes:" below.
612 This field may in the future be
613 replaced with "Supersedes:".
618Palme Informational [Page 11]
620RFC 2076 Internet Message Headers February 1997
623 Commonly used in Usenet News in Supersedes: son-of-RFC1036
624 similar ways to the "Obsoletes" [21], non-standard
625 header described above. In Usenet
626 News, however, Supersedes causes
627 a full deletion of the replaced
628 article in the server, while
629 "Supersedes" and "Obsoletes" in e-
630 mail is implemented in the client
631 and often does not remove the old
634 Only in Usenet News, similar to Article- son-of-RFC1036
635 "Supersedes:" but does not cause Updates: [21], non-standard
636 the referenced article to be
639 Reference to specially important Article- son-of-RFC1036
640 articles for a particular Usenet Names: [21], non-standard
6433.7 Other textual headers
645 Search keys for data base Keywords: RFC 822: 4.7.1
646 retrieval. RFC 1036: 2.2.9.
648 Title, heading, subject. Often Subject: RFC 822: 4.7.1
649 used as thread indicator for RFC 1036: 2.1.4.
650 messages replying to or
651 commenting on other messages.
653 Comments on a message. Comments: RFC 822: 4.7.2.
655 Description of a particular body Content- RFC 1521: 6.2.
656 part of a message. Description:
658 Organization to which the sender Organization: RFC 1036: 2.2.8,
659 of this article belongs. not standardized
662 See Organization above. Organisation: Non-standard.
664 Short text describing a longer Summary: RFC 1036: 2.2.10,
665 article. Warning: Some mail not standardized
666 systems will not display this for use in e-mail,
667 text to the recipient. Because of discouraged.
668 this, do not use this header for
669 text which you want to ensure
670 that the recipient gets.
674Palme Informational [Page 12]
676RFC 2076 Internet Message Headers February 1997
679 A text string which identifies Content- RFC 1327, not for
680 the content of a message. Identifier: general usage.
6823.8 Headers containing dates and times
684 The time when a message was Delivery- RFC 1327, not for
685 delivered to its recipient. Date: general usage.
687 In Internet, the date when a Date: RFC 822: 5.1,
688 message was written, in X.400, RFC 1123: 5.2.14
689 the time a message was submitted. RFC 1036: 2.1.2.
690 Some Internet mail systems also
691 use the date when the message was
694 A suggested expiration date. Can Expires: RFC 1036: 2.2.4,
695 be used both to limit the time of not standardized
696 an article which is not for use in e-mail.
697 meaningful after a certain date,
698 and to extend the storage of
701 Time at which a message loses its Expiry-Date: RFC 1327, not for
702 validity. This field may in the general usage.
703 future be replaced by "Expires:".
705 Latest time at which a reply is Reply-By: RFC 1327, not for
706 requested (not demanded). general usage.
7083.9 Quality information
710 Can be "normal", "urgent" or "non- Priority: RFC 1327, not for
711 urgent" and can influence general usage.
712 transmission speed and delivery.
714 Sometimes used as a priority Precedence: Non-standard,
715 value which can influence controversial,
716 transmission speed and delivery. discouraged.
717 Common values are "bulk" and
718 "first-class". Other uses is to
719 control automatic replies and to
720 control return-of-content
721 facilities, and to stop mailing
730Palme Informational [Page 13]
732RFC 2076 Internet Message Headers February 1997
735 A hint from the originator to the Importance: RFC 1327 and
736 recipients about how important a RFC 1911,
737 message is. Values: High, normal experimental
738 or low. Not used to control
741 How sensitive it is to disclose Sensitivity: RFC 1327 and
742 this message to other people than RFC 1911,
743 the specified recipients. Values: experimental
744 Personal, private, company
745 confidential. The absence of this
746 header in messages gatewayed from
747 X.400 indicates that the message
750 Body parts are missing. Incomplete- RFC 1327, not for
7533.10 Language information
755 Can include a code for the Language: RFC 1327, not for
756 natural language used in a general usage.
757 message, e.g. "en" for English.
759 Can include a code for the Content- RFC 1766, proposed
760 natural language used in a Language: standard.
761 message, e.g. "en" for English.
765 Inserted by certain mailers to Content- Non-standard,
766 indicate the size in bytes of the Length: discouraged.
767 message text. This is part of a
768 format some mailers use when
769 showing a message to its users,
770 and this header should not be
771 used when sending a message
772 through the net. The use of this
773 header in transmission of a
774 message can cause several
775 robustness and interoperability
778 Size of the message. Lines: RFC 1036: 2.2.12,
786Palme Informational [Page 14]
788RFC 2076 Internet Message Headers February 1997
7913.12 Conversion control
793 The body of this message may not Conversion: RFC 1327, not for
794 be converted from one character general usage.
795 set to another. Values:
796 Prohibited and allowed.
798 Non-standard variant of Content- Non-standard.
799 Conversion: with the same values. Conversion:
801 The body of this message may not Conversion- RFC 1327, not for
802 be converted from one character With-Loss: general usage.
803 set to another if information
804 will be lost. Values: Prohibited
8073.13 Encoding information
809 Format of content (character set Content-Type: RFC 1049,
810 etc.) Note that the values for RFC 1123: 5.2.13,
811 this header are defined in RFC 1521: 4.
812 different ways in RFC 1049 and in RFC 1766: 4.1
813 MIME (RFC 1521), look for the
814 "MIME-version" header to
815 understand if Content-Type is to
816 be interpreted according to RFC
817 1049 or according to MIME. The
818 MIME definition should be used in
821 RFC 1766 defines a parameter
822 "difference" to this header.
824 Information from the SGML entity Content-SGML- non-standard
825 declaration corresponding to the Entity:
826 entity contained in the body of
829 Coding method used in a MIME Content- RFC 1521: 5.
830 message body. Transfer-
833 Only used with the value Message-Type: RFC 1327, not for
834 "Delivery Report" to indicates general usage.
835 that this is a delivery report
836 gatewayed from X.400.
842Palme Informational [Page 15]
844RFC 2076 Internet Message Headers February 1997
847 Used in several different ways by Encoding: RFC 1154,
848 different mail systems. Some use RFC 1505,
849 it for a kind of content-type experimental.
850 information, some for encoding
851 and length information, some for
852 a kind of boundary information,
857 When manually forwarding a Resent-Reply- RFC 822: C.3.3.
858 message, headers referring to the To:,
859 forwarding, not to the original Resent-From:,
860 message. Note: MIME specifies Resent-
861 another way of resending Sender:,
862 messages, using the "Message" Resent-From:,
863 Content-Type. Resent-Date:,
8703.15 Security and reliability
872 Checksum of content to ensure Content-MD5: RFC 1864, proposed
873 that it has not been modified. standard.
875 Used in Usenet News to store Xref: RFC 1036: 2.2.13,
876 information to avoid showing a only in Usenet
877 reader the same article twice if News, not in e-
878 it was sent to more than one mail.
879 newsgroup. Only for local usage
880 within one Usenet News server,
881 should not be sent between
886 Name of file in which a copy of Fcc: Non-standard.
887 this message is stored.
889 Has been automatically forwarded. Auto- RFC 1327, not for
890 Forwarded: general usage.
898Palme Informational [Page 16]
900RFC 2076 Internet Message Headers February 1997
903 Can be used in Internet mail to Discarded- RFC 1327, not for
904 indicate X.400 IPM extensions X400-IPMS- general usage.
905 which could not be mapped to Extensions:
906 Internet mail format.
908 Can be used in Internet mail to Discarded- RFC 1327, not for
909 indicate X.400 MTS extensions X400-MTS- general usage.
910 which could not be mapped to Extensions:
911 Internet mail format.
913 This field is used by some mail Status: Non-standard,
914 delivery systems to indicate the should never
915 status of delivery for this appear in mail in
916 message when stored. Common transit.
917 values of this field are:
919 U message is not downloaded
925 O message is old but not
930 N new (a new message also
931 sometimes is distinguished
932 by not having any "Status:"
935 Combinations of these characters
936 can occur, such as "Status: OR"
937 to indicate that a message is
938 downloaded but not deleted.
954Palme Informational [Page 17]
956RFC 2076 Internet Message Headers February 1997
961 Harald Tveit Alvestrand, Ned Freed, Olle Jdrnefors, Keith Moore, Nick
962 Smith and several other people have helped me with compiling this
963 list. I especially thank Ned Freed and Olle Jdrnefors for their
964 thorough review and many helpful suggestions for improvements. I
965 alone take responsibility for any errors which may still be in the
968 An earlier version of this list has been published as part of [13].
972Ref. Author, title IETF status
974----- --------------------------------------------- -----------
975[1] J. Postel: "Simple Mail Transfer Protocol", Standard,
976 STD 10, RFC 821, August 1982. Recommended
978[2] D. Crocker: "Standard for the format of ARPA Standard,
979 Internet text messages." STD 11, RFC 822, Recommended
982[3] M.R. Horton, R. Adams: "Standard for Not an offi-
983 interchange of USENET messages", RFC 1036, cial IETF
984 December 1987. standard,
991[4] M. Sirbu: "A Content-Type header header for Standard,
992 internet messages", RFC 1049, March 1988. Recommended,
1000[5] R. Braden (editor): "Requirements for Standard,
1001 Internet Hosts -- Application and Support", Required
1002 STD-3, RFC 1123, October 1989.
1004[6] D. Robinson, R. Ullman: "Encoding Header Non-standard
1005 Header for Internet Messages", RFC 1154,
1010Palme Informational [Page 18]
1012RFC 2076 Internet Message Headers February 1997
1015[7] S. Hardcastle-Kille: "Mapping between Proposed
1016 X.400(1988) / ISO 10021 and RFC 822", RFC standard,
1017 1327 May 1992. elective
1019[8] H. Alvestrand & J. Romaguera: "Rules for Proposed
1020 Downgrading Messages from X.400/88 to standard,
1021 X.400/84 When MIME Content-Types are Present elective
1022 in the Messages", RFC 1496, August 1993.
1024[9] A. Costanzo: "Encoding Header Header for Non-standard
1025 Internet Messages", RFC 1154, April 1990.
1027[10] A. Costanzo, D. Robinson: "Encoding Header Experimental
1028 Header for Internet Messages", RFC 1505,
1031[11] N. Borenstein & N. Freed: "MIME (Multipurpose Draft
1032 Internet Mail Extensions) Part One: Standard,
1033 Mechanisms for Specifying and Describing the elective
1034 Format of Internet Message Bodies", RFC 1521,
1037[12] H. Alvestrand: "Tags for the Identification Proposed
1038 of Languages", RFC 1766, February 1995. standard,
1041[13] J. Palme: "Electronic Mail", Artech House Non-standard
1042 publishers, London-Boston January 1995.
1044[14] R. Troost, S. Dorner: "Communicating Experimental
1045 Presentation Information in Internet
1046 Messages: The Content-Disposition Header",
1047 RFC 1806, June 1995.
1049[15] B. Kantor, P. Lapsley, "Network News Transfer Proposed
1050 Protocol: "A Proposed Standard for the Stream- standard
1051 Based Transmission of News", RFC 977, January
1054[16] 1848 PS S. Crocker, N. Freed, J. Galvin, Proposed
1055 S. Murphy, "MIME Object Security Services", standard
1056 RFC 1848, March 1995.
1058[17] J. Myers, M. Rose: The Content-MD5 Header Draft
1059 Header, RFC 1864, October 1995. standard
1066Palme Informational [Page 19]
1068RFC 2076 Internet Message Headers February 1997
1071[18] M. Horton, UUCP mail interchange format Not an offi-
1072 standard, RFC 976, Januari 1986. cial IETF
1080[19] T. Berners-Lee, R. Headering, H. Frystyk: Not an official
1081 Hypertext Transfer Protocol -- HTTP/1.0, IETF standard,
1082 RFC 1945, May 1996. but the defacto
1088[20] G. Vaudreuil: Voice Profile for Internet Experimental
1089 Mail, RFC 1911, February 1996.
1091[21] H. Spencer: News Article Format and Not even an
1092 Transmission, June 1994, RFC, but
1093 FTP://zoo.toronto.edu/pub/news.ps still widely
1094 FTP://zoo.toronto.edu/pub/news.txt.Z used and
1096 This document is often referenced under the almost a de-
1097 name "son-of-RFC1036". facto
1104 Jacob Palme Phone: +46-8-16 16 67
1105 Stockholm University/KTH Fax: +46-8-783 08 29
1106 Electrum 230 E-mail: jpalme@dsv.su.se
1107 S-164 40 Kista, Sweden
1122Palme Informational [Page 20]
1124RFC 2076 Internet Message Headers February 1997
1128 Headers sorted by Internet RFC document in which they appear.
1162 "From " (followed by space, not colon (:")
1178Palme Informational [Page 21]
1180RFC 2076 Internet Message Headers February 1997
1212 Conversion-With-Loss
1214 Discarded-X400-IPMS-Extensions
1215 Discarded-X400-MTS-Extensions
1217 DL-Expansion-History
1219 Generate-Delivery-Report
1223 Message-Type Delivery
1225 Original-Encoded-Information-Types
1226 Prevent-NonDelivery-Report
1234Palme Informational [Page 22]
1236RFC 2076 Internet Message Headers February 1997
1249 Content-Transfer-Encoding
1290Palme Informational [Page 23]
1292RFC 2076 Internet Message Headers February 1997
1295 Not Internet standard
1296 ---------------------
1307 "From " (not followed by ":")
1346Palme Informational [Page 24]
1348RFC 2076 Internet Message Headers February 1997
1354 Section Heading-header
1355 ------- --------------
1358 3.3 Alternate-Recipient
1366 Client, see Originating-Client
1369 3.12 Content-Conversion
1370 3.7 Content-Description
1371 3.3 Content-Disposition
1373 3.7 Content-Identifier
1374 3.10 Content-Language see also Language
1376 3.6 Content-Location
1379 3.13 Content-SGML-Entity
1380 3.13 Content-Transfer-Encoding
1384 3.12 Conversion-With-Loss
1387 Delivery-Report, see Generate-Delivery-Report, Prevent-
1388 Delivery-Report, Non-Delivery-Report, Content-Type
1389 Description, see Content-Description
1390 3.16 Discarded-X400-IPMS-Extensions
1391 3.16 Discarded-X400-MTS-Extensions
1392 3.3 Disclose-Recipients
1393 Disposition, see Content-Disposition
1395 3.2 DL-Expansion-History-Indication
1396 3.13 Encoding see also Content-Transfer-Encoding
1402Palme Informational [Page 25]
1404RFC 2076 Internet Message Headers February 1997
1408 Extension see Discarded-X400-IPMS-Extensions, Discarded-
1413 Forwarded, see Auto-Forwarded
1417 3.4 Generate-Delivery-Report
1418 History, see DL-Expansion-History-Indication
1419 ID, see Content-ID and Message-ID
1420 Identifier, see Content-ID and Message-ID
1425 3.10 Language see also Content-Language
1426 Length see Content-Length
1428 3.4 Mail-System-Version see also X-mailer
1435 Newsreader, see X-Newsreader
1439 3.3 Original-Encoded-Information-Types
1440 3.4 Originating-Client
1444 3.4 Prevent-NonDelivery-Report
1447 Recipient, see To, cc, bcc, Alternate-Recipient, Disclose-
1451 3.4 Reply-To, see also In-Reply-To, References
1453 Return see also Content-Return
1458Palme Informational [Page 26]
1460RFC 2076 Internet Message Headers February 1997
1463 3.5 Return-Receipt-To
1473 Transfer-Encoding see Content-Transfer-Encoding
1474 Type see Content-Type, Message-Type, Original-Encoded-
1476 Version, see MIME-Version, X-Mailer
1477 3.4 X400-Content-Return
1478 3.4 X-Mailer see also Mail-System-Version
1514Palme Informational [Page 27]