idnits 2.17.1 draft-palme-mailext-headers-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Found some kind of copyright notice around line 35 but it does not match any copyright boilerplate known by this tool. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == There are 2 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 1500 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 406 has weird spacing: '...osed to bcc...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 1998) is 9598 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '2' on line 1009 looks like a reference -- Missing reference section? '3' on line 1013 looks like a reference -- Missing reference section? '5' on line 1031 looks like a reference -- Missing reference section? '7' on line 1039 looks like a reference -- Missing reference section? '8' on line 1043 looks like a reference -- Missing reference section? '11' on line 1056 looks like a reference -- Missing reference section? '12' on line 1061 looks like a reference -- Missing reference section? '14' on line 1068 looks like a reference -- Missing reference section? '17' on line 1081 looks like a reference -- Missing reference section? '20' on line 1097 looks like a reference -- Missing reference section? '16' on line 1077 looks like a reference -- Missing reference section? '1' on line 1006 looks like a reference -- Missing reference section? '18' on line 1084 looks like a reference -- Missing reference section? '15' on line 1073 looks like a reference -- Missing reference section? '19' on line 1093 looks like a reference -- Missing reference section? '21' on line 1256 looks like a reference -- Missing reference section? '25' on line 1117 looks like a reference -- Missing reference section? '24' on line 1114 looks like a reference -- Missing reference section? '23' on line 1110 looks like a reference -- Missing reference section? '26' on line 1121 looks like a reference -- Missing reference section? '13' on line 1065 looks like a reference -- Missing reference section? '4' on line 1022 looks like a reference -- Missing reference section? '6' on line 1035 looks like a reference -- Missing reference section? '9' on line 1048 looks like a reference -- Missing reference section? '10' on line 1052 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 27 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Jacob Palme 2 Internet Draft Stockholm University/KTH 3 Sweden 4 Category: Informational Date: January 1998 5 Revision of: RFC 2076 Expires: July 1998 7 Common Internet Message Header Fields 9 Status of this Memo 11 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its 15 areas, and its working groups. Note that other groups may also 16 distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet- 21 Drafts as reference material or to cite them other than as 22 ``work in progress.'' 24 To learn the current status of any Internet-Draft, please check 25 the ``1id-abstracts.txt'' listing contained in the Internet- 26 Drafts Shadow Directories on ftp.is.co.za (Africa), 27 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), 28 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 30 This memo provides information for the Internet community. This 31 memo does not specify an Internet standard of any kind, since 32 this document is mainly a compilation of information taken from 33 other RFCs.. Distribution of this memo is unlimited. 35 Copyright (C) The Internet Society 1998. All Rights Reserved. 37 Abstract 39 This memo contains a table of commonly occurring header fields in 40 headings of e-mail messages. The document compiles information from 41 other RFCs such as RFC 822, RFC 1036, RFC 1123, RFC 1327, RFC 1496, RFC 42 2045, RFC 1766, RFC 1806, RFC 1864 and RFC 1911. A few commonly 43 occurring header fields which are not defined in RFCs are also 44 included. For each header field, the memo gives a short description and 45 a reference to the RFC in which the header field is defined. 47 This document is a revision of RFC 2076. The following new header 48 fields, not included in RFC 2076, have been added: Content-Alias, 49 Disposition-Notification-Options, Disposition-Notification-To, Expiry- 50 Date, For-Approval, List-Archive, List-Help, List-ID, List-Owner, List- 51 Post, List-Software, List-Subscribe, List-Unsubscribe, Original- 52 Recipient, PICS-Label, X-Envelope-From, X-Envelope-To, X-List-Host, X- 53 Listserver, X-MIME-Autoconverted, X-No-Archive, X-Priority, X-UIDL. 55 Table of contents 57 1. Introduction 58 2. Use of gatewaying header fields 59 3. Table of header fields 60 3.1 Phrases used in the tables 61 3.2 Trace information 62 3.3 Format and control information 63 3.4 Sender and recipient indication 64 3.5 Response control 65 3.6 Message identification and referral header fields 66 3.7 Other textual header fields 67 3.8 Header fields containing dates and times 68 3.9 Quality information 69 3.10 Language information 70 3.11 Size information 71 3.12 Conversion control 72 3.13 Encoding information 73 3.14 Resent-header fields 74 3.15 Security and reliability 75 3.16 Mailing list control 76 3.17 Miscellaneous 77 4. Acknowledgments 78 5. References 79 6. Author's address 80 Appendix A: Header fields sorted by Internet RFC document in 81 which they appear. 82 Appendix B: Alphabetical index 84 1. Introduction 86 Many different Internet standards and RFCs define header fields which 87 may occur on Internet Mail Messages and Usenet News Articles. The 88 intention of this document is to list all such header fields in one 89 document as an aid to people developing message systems or interested 90 in Internet Mail standards. 92 The document contains all header fields which the author has 93 found in the following Internet standards: RFC 822 [2], 94 RFC 1036 [3], RFC 1123 [5], RFC 1327 [7], RFC 1496 [8], RFC 2045 [11], 95 RFC 1766 [12], RFC 1806 [14], RFC 1864[17] and RFC 1911[20]. Note in 96 particular that heading attributes defined in PEM (RFC 1421-1424) and 97 MOSS (RFC 1848 [16]) are not included. PEM and MOSS header fields only 98 appear inside the body of a message, and thus are not header fields in 99 the RFC 822 sense. Mail attributes in envelopes, i.e. attributes 100 controlling the message transport mechanism between mail and news 101 servers, are not included. This means that attributes from SMTP [1], 102 UUCP [18] and NNTP [15] are mainly not covered either. Headings used 103 only in HTTP [19] are not included yet, but may be included in future 104 version of this memo. Some additional header fields which often can be 105 found in e-mail headings but are not part of any Internet standard are 106 also included. 108 For each header field, the document gives a short description and 109 a reference to the Internet standard or RFC, in which they are defined. 111 The header field names given here are spelled the same way as when they 112 are actually used. This is usually American but sometimes English 113 spelling. One header field in particular, "Organisation/Organization", 114 occurs in e-mail header fields sometimes with the English and other 115 times with the American spelling. 117 The following words are used in this memo with the meaning specified 118 below: 120 heading Formatted text at the top of a message, ended by a 121 blank line 123 header field One field in the heading, beginning with a field 124 name, colon, and followed by the field value(s). The 125 words "heading field" and "header" are also 126 sometimes used with this meaning. 128 It is my intention to continue updating this document after its 129 publication as an RFC. The latest version, which may be more up-to-date 130 (but also less fully checked out) will be kept available for 131 downloading from URL 132 http://www.dsv.su.se/~jpalme/ietf/ietf-mail-attributes.html. 134 Please e-mail me (Jacob Palme ) if you have noted 135 header fields which should be included in this memo but are not. 137 2. Use of gatewaying header fields 139 RFC 1327 defines a number of new header fields in Internet mail, which 140 are defined to map header fields which X.400 has but which were 141 previously not standardized in Internet mail. The fact that a header 142 field occurs in RFC 1327 indicates that it is recommended for use in 143 gatewaying messages between X.400 and Internet mail, but does not mean 144 that the header field is recommended for messages wholly within 145 Internet mail. Some of these header fields may eventually see 146 widespread implementation and use in Internet mail, but at the time of 147 this writing (1996) they are not widely implemented or used. 149 Header fields defined only in RFC 1036 for use in Usenet News sometimes 150 appear in mail messages, either because the messages have been 151 gatewayed from Usenet News to e-mail, or because the messages were 152 written in combined clients supporting both e-mail and Usenet News in 153 the same client. These header fields are not standardized for use in 154 Internet e-mail and should be handled with caution by e-mail agents. 156 3. Table of header fields 158 3.1 Phrases used in the tables 160 "not for general Used to mark header fields which are defined 161 usage" in RFC 1327 for use in messages from or to 162 Internet mail/X.400 gateways. These header 163 fields have not been standardized for general 164 usage in the exchange of messages between 165 Internet mail-based systems. 167 "not standardized Used to mark header fields defined only in RFC 168 for use in e-mail" 1036 for use in Usenet News. These header 169 fields have no standard meaning when appearing 170 in e-mail, some of them may even be used in 171 different ways by different software. When 172 appearing in e-mail, they should be handled 173 with caution. Note that RFC 1036, although 174 generally used as a de-facto standard for 175 Usenet News, is not an official IETF standard 176 or even on the IETF standards track. 178 "non-standard" This header field is not specified in any of 179 referenced RFCs which define Internet 180 protocols, including Internet Standards, draft 181 standards or proposed standards. The header 182 field appears here because it often appears in 183 e-mail or Usenet News. Usage of these header 184 fields is not in general recommended. Some 185 header field proposed in ongoing IETF 186 standards development work, but not yet 187 accepted, are also marked in this way. 189 "discouraged" This header field, which is non-standard, is 190 known to create problems and should not be 191 generated. Handling of such header fields in 192 incoming mail should be done with great 193 caution. 195 "controversial" The meaning and usage of this header field is 196 controversial, i.e. different implementors 197 have chosen to implement the header field in 198 different ways. Because of this, such header 199 fields should be handled with caution and 200 understanding of the different possible 201 interpretations. 203 "experimental" This header field is used for newly defined 204 header fields, which are to be tried out 205 before entering the IETF standards track. 206 These should only be used if both 207 communicating parties agree on using them. In 208 practice, some experimental protocols become 209 de-facto-standards before they are made into 210 IETF standards. 212 3.2 Trace information 214 Used to convey the information Return-Path: RFC 821, 215 from the MAIL FROM envelope RFC 1123: 5.2.13. 216 attribute in final delivery, when 217 the message leaves the SMTP 218 environment in which "MAIL FROM" 219 is used. 221 Trace of MTAs which a message has Received: RFC 822: 4.3.2, 222 passed. RFC 1123: 5.2.8. 224 List of MTAs passed. Path: RFC 1036: 2.1.6, 225 only in Usenet 226 News, not in e- 227 mail. 229 Trace of distribution lists DL-Expansion- RFC 1327, not for 230 passed. History- general usage. 231 Indication: 233 3.3 Format and control information 235 An indicator that this message is MIME-Version: RFC 2045: 4. 236 formatted according to the MIME 237 standard, and an indication of 238 which version of MIME is 239 utilized. 241 Only in Usenet News, contains Control: RFC 1036: 2.1.6, 242 commands to be performed by News only in Usenet 243 agents. News, not in e- 244 mail. 246 Special Usenet News commands and Also-Control: son-of-RFC1036 247 a normal article at the same [21], non- 248 time. standard, only in 249 Usenet News, not 250 in e-mail 252 Which body part types occur in Original- RFC 1327, not for 253 this message. Encoded- general usage. 254 Information- 255 Types: 257 Controls whether this message may Alternate- RFC 1327, not for 258 be forwarded to alternate Recipient: general usage. 259 recipients such as a postmaster 260 if delivery is not possible to 261 the intended recipient. Default: 262 Allowed. 264 Whether recipients are to be told Disclose- RFC 1327, not for 265 the names of other recipients of Recipients: general usage. 266 the same message. This is 267 primarily an X.400 facility. In 268 X.400, this is an envelope 269 attribute and refers to 270 disclosure of the envelope 271 recipient list. Disclosure of 272 other recipients is in Internet 273 mail done via the To:, cc: and 274 bcc: header fields. 276 Whether a MIME body part is to be Content- RFC 1806, 277 shown inline or is an attachment; Disposition: experimental 278 can also indicate a suggested 279 filename for use when saving an 280 attachment to a file. 282 3.4 Sender and recipient indication 284 Authors or persons taking From: RFC 822: 4.4.1, 285 responsibility for the message. RFC 1123: 5.2.15- 286 16, 5.3.7, 287 Note difference from the "From " RFC 1036 2.1.1 288 header field (not followed by 289 ":") below. 291 (1) This header field should From (not not standardized 292 never appear in e-mail being followed by a for use in e-mail 293 sent, and should thus not appear colon) 294 in this memo. It is however 295 included, since people often ask 296 about it. 298 This header field is used in the 299 so-called Unix mailbox format, 300 also known as Berkely mailbox 301 format or the MBOX format. This 302 is a format for storing a set of 303 messages in a file. A line 304 beginning with "From " is used to 305 separate successive messages in 306 such files. 308 This header field will thus 309 appear when you use a text editor 310 to look at a file in the Unix 311 mailbox format. Some mailers also 312 use this format when printing 313 messages on paper. 315 The information in this header 316 field should NOT be used to find 317 an address to which replies to a 318 message are to be sent. 320 (2) Used in Usenet News mail From RFC 976: 2.4 for 321 transport, to indicate the path or use in Usenet News 322 through which an article has gone >From 323 when transferred to a new host. (not followed 324 by a colon) 325 Sometimes called "From_" header 326 field. 328 Name of the moderator of the Approved: RFC 1036: 2.2.11, 329 newsgroup to which this article not standardized 330 is sent; necessary on an article for use in e-mail. 331 sent to a moderated newsgroup to 332 allow its distribution to the 333 newsgroup members. Also used on 334 certain control messages, which 335 are only performed if they are 336 marked as Approved. 338 The person or agent submitting Sender: RFC 822: 4.4.2, 339 the message to the network, if RFC 1123: 5.2.15- 340 other than shown by the From: 16, 5.3.7. 341 header field. Should be 342 authenticated, 343 according to RFC 822, but what 344 kind of authentication is not 345 clear. Some implementations 346 expect that the e-mail address 347 used in this field can be used to 348 reach the sender, others do not. 349 See also "X-Sender". 351 Some mail software expect X-Sender: Non-standard 352 "Sender:" to be an e-mail address 353 which you can send mail to. 354 However, some mail software has 355 as the best authenticated sender 356 a POP or IMAP account, which you 357 might not be able to send to. 358 Because of this, some mail 359 software put the POP or IMAP 360 account into an X-sender header 361 field instead of a Sender header 362 field, to indicate that you may 363 not be able to send e-mail to 364 this address. See also "X-X- 365 Sender". 367 Another use of" X-Sender:" is 368 that some e-mail software, which 369 wants to insert a "Sender:" 370 header, will first change an 371 existing "Sender:" header to "X- 372 Sender". This use is actually 373 often the same as that described 374 in the previous paragraph, since 375 the new "Sender:" is added 376 because it is better 377 authenticated than the old value. 379 Even though some systems put the X-X-Sender: Non-standard 380 POP or IMAP account name into the 381 "X-Sender:" instead of the Sender 382 header field, some mail software 383 tries to send to the "X-Sender:" 384 too. To stop this, some systems 385 have begun to use "X-X-Sender:" 386 to indicate an authentication of 387 the sender which might not be 388 useable to send e-mail to. See 389 also "Originator-Info:" 391 Contains information about the Originator- Non-standard [25] 392 authentication of the originator Info: 393 in a format which is not easily 394 used to send email to, to avoid 395 the problems with "Sender" and "X- 396 Sender". 398 Primary recipients. To: RFC 822: 4.5.1, 399 RFC 1123: 5.2.15- 400 16, 5.3.7. 402 Secondary, informational cc: RFC 822: 4.5.2, 403 recipients. (cc = Carbon Copy) RFC 1123. 5.2.15- 404 16, 5.3.7. 406 Recipients not to be disclosed to bcc: RFC 822: 4.5.3, 407 other recipients. (bcc = Blind RFC 1123: 5.2.15- 408 Carbon Copy). 16, 5.3.7. 410 Primary recipients, who are For-Handling: Non-standard 411 requested to handle the 412 information in this message or 413 its attachments. 415 Primary recipients, who are For-Comment: Non-standard 416 requested to comment on the 417 information in this message or 418 its attachments. 420 Primary recipients, who are For-Approval: Non-standard 421 requested to approve the 422 information in this message or 423 its attachments. 425 In Usenet News: group(s) to which Newsgroups: RFC 1036: 2.1.3, 426 this article was posted. not standardized 427 Some systems provide this header and controversial 428 field also in e-mail although it for use in e-mail. 429 is not standardized there. 431 Unfortunately, the header field 432 can appear in e-mail with two 433 different and contradictory 434 meanings: 436 (a) Indicating the newsgroup 437 recipient of an article/message 438 sent to both e-mail and Usenet 439 News recipients. 441 (b) In a personally addressed 442 reply to an article in a news- 443 group, indicating the newsgroup 444 in which this discussion 445 originated. 447 Inserted by Sendmail when there Apparently- Non-standard, 448 is no "To:" recipient in the To: discouraged, 449 original message, listing mentioned in 450 recipients derived from the RFC 1211. 451 envelope into the message 452 heading. This behavior is not 453 quite proper, MTAs should not 454 modify headings (except inserting 455 Received lines), and it can in 456 some cases cause Bcc recipients 457 to be wrongly divulged to non-Bcc 458 recipients. 460 Geographical or organizational Distribution: RFC 1036: 2.2.7, 461 limitation on where this article not standardized 462 can be distributed. Value can be for use in e-mail. 463 a compete or incomplete domain 464 names, also various special 465 values are accepted like "world", 466 "usenet", "USA", etc. 468 Fax number of the originator. Fax:, Non-standard. 469 Telefax: 471 Phone number of the originator. Phone: Non-standard. 473 If the recipient in the envelope X-Envelope-To Non-standard. 474 (SMTP "MAIL FROM") is not 475 included in the CC list, some 476 mail servers add this to the 477 RFC822 header field as an aid to 478 clients which would otherwise not 479 be able to display the envelope 480 recipients. 482 If the sender in the envelope X-Envelope- Non-standard. 483 (SMTP "RCTP TO") is not the same From 484 as the senders in the "From" or 485 "Sender" RFC822 header fields, 486 some mail servers add this to the 487 RFC822 header fields as an aid to 488 clients which would otherwise not 489 be able to display this 490 information. 492 Information about the client Mail-System- Non-standard. 493 software of the originator. Version:, 494 Mailer:, 495 Originating- 496 Client:, X- 497 Mailer, X- 498 Newsreader 500 3.5 Response control 502 This header field is meant to Reply-To: RFC 822: 4.4.3, 503 indicate where the sender wants RFC 1036: 2.2.1 504 replies to go. Unfortunately, controversial. 505 this is ambiguous, since there 506 are different kinds of replies, 507 which the sender may wish to go 508 to different addresses. In 509 particular, there are personal 510 replies intended for only one 511 person, and group replies, 512 intended for the whole group of 513 people who read the replied-to 514 message (often a mailing list, 515 anewsgroup name cannot appear 516 here because of different syntax, 517 see "Followup-To" below.). 519 Some mail systems use this header 520 field to indicate a better form 521 of the e-mail address of the 522 sender. Some mailing list 523 expanders puts the name of the 524 list in this header field. These 525 practices are controversial. The 526 personal opinion of the author of 527 this RFC is that this header 528 field should be avoided except in 529 special cases, but this is a 530 personal opinion not shared by 531 all specialists in the area. 533 Used in Usenet News to indicate Followup-To: RFC 1036: 2.2.3, 534 that future discussions (=follow- not standardized 535 up) on an article should go to a for use in e-mail. 536 different set of newsgroups than 537 the replied-to article. The most 538 common usage is when an article 539 is posted to several newsgroups, 540 and further discussions is to 541 take place in only one of them. 543 In e-mail, this header field may 544 occur in a message which is sent 545 to both e-mail and Usenet News, 546 to show where follow-up in Usenet 547 news is wanted. The header field 548 does not say anything about where 549 follow-up in e-mail is to be 550 sent. 552 Note that the value of this 553 header field must always be one 554 or more newsgroup names, never e- 555 mail addresses. 557 Address to which notifications Errors-To:, Non-standard, 558 are to be sent and a request to Return- discouraged. 559 get delivery notifications. Receipt-To: 560 Internet standards recommend, 561 however, the use of RCPT TO and 562 Return-Path, not Errors-To, for 563 where delivery notifications are 564 to be sent. 566 Whether non-delivery report is Prevent- RFC 1327, not for 567 wanted at delivery error. Default NonDelivery- general usage. 568 is to want such a report. Report: 570 Whether a delivery report is Generate- RFC 1327, not for 571 wanted at successful delivery. Delivery- general usage. 572 Default is not to generate such a Report: 573 report. 575 Indicates whether the content of Content- RFC 1327, not for 576 a message is to be returned with Return: general usage. 577 non-delivery notifications. 579 Possible future change of name X400-Content- non-standard 580 for "Content-Return:" Return: 582 Indicate that the sender wants a Disposition- draft-ietf-receipt- 583 dispoisition notification when Notification- 03.txt (standard 584 this message is received (read, To to be) 585 processed, etc.) by its 586 receipents. 588 For future options on disposition Disposition- draft-ietf-receipt- 589 notifications. Notification- 03.txt (standard 590 Options to be) 592 Original Recipient information Original- draft-ietf-receipt- 593 for inclusion in disposition Recipient 03.txt (standard 594 notifications. to be) 596 3.6 Message identification and referral header fields 598 Unique ID of this message. Message-ID: RFC 822: 4.6.1 599 RFC 1036: 2.1.5. 601 Unique ID of one body part of the Content-ID: RFC 2045: 7. 602 content of a message. 604 Base to be used for resolving Content-Base: RFC 2110 605 relative URIs within this content 606 part. 608 URI with which the content of Content- RFC 2110 609 this content part might be Location: 610 retrievable. 612 Used in addition to Content- Content- Internet draft 613 Location if this content part can Alias: 614 be retrieved through more than 615 one URI. Only one of them is 616 allowed in the Content-Location, 617 the other can be specified in 618 Content-Alias. 620 Sometimes used with the same X-URL: Non-standard 621 meaning as "Content-Location:", 622 sometimes to indicate the web 623 home page of the sender or of his 624 organisation. 626 Reference to message which this In-Reply-To: RFC 822: 4.6.2. 627 message is a reply to. 629 In e-mail: reference to other References: RFC 822: 4.6.3 630 related messages, in Usenet News: RFC 1036: 2.1.5. 631 reference to replied-to-articles. 633 References to other related See-Also: Son-of-RFC1036 634 articles in Usenet News. [21], non-standard 636 Reference to previous message Obsoletes: RFC 1327, not for 637 being corrected and replaced. general usage. 638 Compare to "Supersedes:" below. 639 This field may in the future be 640 replaced with "Supersedes:". 642 Commonly used in Usenet News in Supersedes: son-of-RFC1036 643 similar ways to the "Obsoletes" [21], non-standard 644 header field described above. In 645 Usenet News, however, Supersedes 646 causes a full deletion of the 647 replaced article in the server, 648 while "Supersedes" and 649 "Obsoletes" in e-mail is 650 implemented in the client and 651 often does not remove the old 652 version of the text. 654 Unique identifier for a message, X-UIDL: non-standard 655 local to a particular local 656 mailbox store. The UIDL 657 identifier is defined in the POP3 658 standard, but not the "X-UIDL:" 659 header. 661 Only in Usenet News, similar to Article- son-of-RFC1036 662 "Supersedes:" but does not cause Updates: [21], non-standard 663 the referenced article to be 664 physically deleted. 666 Reference to specially important Article- son-of-RFC1036 667 articles for a particular Usenet Names: [21], non-standard 668 Newsgroup. 670 3.7 Other textual header fields 672 Search keys for data base Keywords: RFC 822: 4.7.1 673 retrieval. RFC 1036: 2.2.9. 675 Title, heading, subject. Often Subject: RFC 822: 4.7.1 676 used as thread indicator for RFC 1036: 2.1.4. 677 messages replying to or 678 commenting on other messages. 680 Comments on a message. Comments: RFC 822: 4.7.2. 682 Description of a particular body Content- RFC 2045: 8. 683 part of a message, for example a Description: 684 caption for an image body part. 686 Organization to which the sender Organization: RFC 1036: 2.2.8, 687 of this article belongs. not standardized 688 for use in e-mail. 690 See Organization above. Organisation: Non-standard. 692 Short text describing a longer Summary: RFC 1036: 2.2.10, 693 article. Warning: Some mail not standardized 694 systems will not display this for use in e-mail, 695 text to the recipient. Because of discouraged. 696 this, do not use this header 697 field for text which you want to 698 ensure that the recipient gets. 700 A text string which identifies Content- RFC 1327, not for 701 the content of a message. Identifier: general usage. 703 3.8 Header fields containing dates and times 705 The time when a message was Delivery- RFC 1327, not for 706 delivered to its recipient. Date: general usage. 708 In Internet, the date when a Date: RFC 822: 5.1, 709 message was written, in X.400, RFC 1123: 5.2.14 710 the time a message was submitted. RFC 1036: 2.1.2. 711 Some Internet mail systems also 712 use the date when the message was 713 submitted. 715 A suggested expiration date. Can Expires: RFC 1036: 2.2.4, 716 be used both to limit the time of not standardized 717 an article which is not for use in e-mail. 718 meaningful after a certain date, 719 and to extend the storage of 720 important articles. 722 Time at which a message loses its Expiry-Date: RFC 1327, not for 723 validity. This field may in the general usage. 724 future be replaced by "Expires:". 726 Latest time at which a reply is Reply-By: RFC 1327, not for 727 requested (not demanded). general usage. 729 3.9 Quality information 731 Can be "normal", "urgent" or "non- Priority: RFC 1327, not for 732 urgent" and can influence general usage. 733 transmission speed and delivery. 735 Values: 1 (Highest), 2 (High), 3 X-Priority: Non-standard [24] 736 (Normal), 4 (Low), 5 (Lowest). 3 737 (Normal) is default if the field 738 is omitted. 740 Sometimes used as a priority Precedence: Non-standard, 741 value which can influence controversial. 742 transmission speed and delivery. 743 Common values are "bulk" and 744 "first-class". Other uses is to 745 control automatic replies and to 746 control return-of-content 747 facilities, and to stop mailing 748 list loops. 750 A hint from the originator to the Importance: RFC 1327 and 751 recipients about how important a RFC 1911, 752 message is. Values: High, normal experimental 753 or low. Not used to control 754 transmission speed. 756 How sensitive it is to disclose Sensitivity: RFC 1327 and 757 this message to other people than RFC 1911, 758 the specified recipients. Values: experimental 759 Personal, private, company 760 confidential. The absence of this 761 header field in messages 762 gatewayed from X.400 indicates 763 that the message is not 764 sensitive. 766 Body parts are missing. Incomplete- RFC 1327, not for 767 Copy: general usage. 769 Ratings label to control PICS-Label: REC-PICS-labels, 770 selection (filtering) of messages W3C document [23]. 771 according to the PICS protocol. 773 3.10 Language information 775 Can include a code for the Language: RFC 1327, not for 776 natural language used in a general usage. 777 message, e.g. "en" for English. 779 Can include a code for the Content- RFC 1766, proposed 780 natural language used in a Language: standard. 781 message, e.g. "en" for English. 783 3.11 Size information 785 Inserted by certain mailers to Content- Non-standard, 786 indicate the size in bytes of the Length: discouraged. 787 message text. This is part of a 788 format some mailers use when 789 showing a message to its users, 790 and this header field should not 791 be used when sending a message 792 through the net. The use of this 793 header field in transmission of a 794 message can cause several 795 robustness and interoperability 796 problems. 798 Size of the message. Lines: RFC 1036: 2.2.12, 799 not standardized 800 for use in e-mail. 802 3.12 Conversion control 804 The body of this message may not Conversion: RFC 1327, not for 805 be converted from one character general usage. 806 set to another. Values: 807 Prohibited and allowed. 809 Non-standard variant of Content- Non-standard. 810 Conversion: with the same values. Conversion: 812 The body of this message may not Conversion- RFC 1327, not for 813 be converted from one character With-Loss: general usage. 814 set to another if information 815 will be lost. Values: Prohibited 816 and allowed. 818 3.13 Encoding information 820 Format of content (character set Content-Type: RFC 1049, 821 etc.) Note that the values for RFC 1123: 5.2.13, 822 this header field are defined in RFC 2045: 5. 823 different ways in RFC 1049 and in RFC 1766: 4.1 824 MIME (RFC 2045), look for the 825 "MIME-version" header field to 826 understand if Content-Type is to 827 be interpreted according to RFC 828 1049 or according to MIME. The 829 MIME definition should be used in 830 generating mail. 832 RFC 1766 defines a parameter 833 "difference" to this header 834 field. 836 Information from the SGML entity Content-SGML- non-standard 837 declaration corresponding to the Entity: 838 entity contained in the body of 839 the body part. 841 Coding method used in a MIME Content- RFC 2045: 6. 842 message body. Transfer- 843 Encoding: 845 Only used with the value Message-Type: RFC 1327, not for 846 "Delivery Report" to indicates general usage. 847 that this is a delivery report 848 gatewayed from X.400. 850 Used in several different ways by Encoding: RFC 1154, 851 different mail systems. Some use RFC 1505, 852 it for a kind of content-type experimental. 853 information, some for encoding 854 and length information, some for 855 a kind of boundary information, 856 some in other ways. 858 Information about conversion of X-MIME- non-standard 859 this message on the path from Autoconverted: 860 sender to recipient, like 861 conversion between MIME encoding 862 formats. Note: Auto-conversion 863 may invalidate digital seals and 864 signatures. 866 3.14 Resent-header fields 868 When manually forwarding a Resent-Reply- RFC 822: C.3.3. 869 message, header fields referring To:, 870 to the forwarding, not to the Resent-From:, 871 original message. Note: MIME Resent- 872 specifies another way of Sender:, 873 resending messages, using the Resent-From:, 874 "Message" Content-Type. Resent-Date:, 875 Resent-To:, 876 Resent-cc:, 877 Resent-bcc:, 878 Resent- 879 Message-ID: 881 3.15 Security and reliability 883 Checksum of content to ensure Content-MD5: RFC 1864, proposed 884 that it has not been modified. standard. 886 Used in Usenet News to store Xref: RFC 1036: 2.2.13, 887 information to avoid showing a only in Usenet 888 reader the same article twice if News, not in e- 889 it was sent to more than one mail. 890 newsgroup. Only for local usage 891 within one Usenet News server, 892 should not be sent between 893 servers. 895 3.16 Mailing list control 896 Contains URL to use to get a List- Non-standard [26] 897 subscription to the mailing list Subscribe 898 from which this message was 899 relayed. 901 Contains URL to use to List- Non-standard [26] 902 unsubscribe the mailing list from Unsubscribe 903 which this message was relayed. 905 Contains URL to send e-mail to List-Owner Non-standard [26] 906 the owner of the mailing list 907 from which this message was 908 relayed. 910 Contains URL to use to get a List-Help Non-standard [26] 911 information about the mailing 912 list from which this message was 913 relayed. 915 Contains URL to use to send List-Post Non-standard [26] 916 contributions to the mailing list 917 from which this message was 918 relayed. 920 Contains URL to use to browse the List-Archive Non-standard [26] 921 archives of the mailing list from 922 which this message was relayed. 924 Information about the software List-Software Non-standard, has 925 used in a mailing list expander been considered 926 through which this message has for inclusion in 927 passed. [26]. 929 Stores the URN of the mailing List-ID Non-standard, has 930 list, through which this message been considered 931 was distributed. for inclusion in 932 [26]. 934 Information about the software X-Listserver Non-standard. 935 used in a mailing list expander 936 through which this message has 937 passed. Warning: "Listserv" is a 938 trademark and should not be used 939 for other than the "Listserv" 940 product. Use, instead the "List- 941 Software" header field. 943 3.17 Miscellaneous 945 Name of file in which a copy of Fcc: Non-standard. 946 this message is stored. 948 Has been automatically forwarded. Auto- RFC 1327, not for 949 Forwarded: general usage. 951 Can be used in Internet mail to Discarded- RFC 1327, not for 952 indicate X.400 IPM extensions X400-IPMS- general usage. 953 which could not be mapped to Extensions: 954 Internet mail format. 956 Can be used in Internet mail to Discarded- RFC 1327, not for 957 indicate X.400 MTS extensions X400-MTS- general usage. 958 which could not be mapped to Extensions: 959 Internet mail format. 961 This field is used by some mail Status: Non-standard, 962 delivery systems to indicate the should never 963 status of delivery for this appear in mail in 964 message when stored. Common transit. 965 values of this field are: 967 U message is not downloaded 968 and not deleted. 970 R message is read or 971 downloaded. 973 O message is old but not 974 deleted. 976 D to be deleted. 978 N new (a new message also 979 sometimes is distinguished 980 by not having any "Status:" 981 header field. 983 Combinations of these characters 984 can occur, such as "Status: OR" 985 to indicate that a message is 986 downloaded but not deleted. 988 Do not archive this message in X-No-Archive: Non-standard 989 publicly available archives. Yes 991 4. Acknowledgments 993 Harald Tveit Alvestrand, Ned Freed, Olle J�rnefors, Keith Moore, Nick 994 Smith and several other people have helped me with compiling this list. 995 I especially thank Ned Freed and Olle J�rnefors for their thorough 996 review and many helpful suggestions for improvements. I alone take 997 responsibility for any errors which may still be in the list. 999 An earlier version of this list has been published as part of [13]. 1001 5. References 1003 Ref. Author, title IETF status 1004 (July 1996) 1005 ----- --------------------------------------------- ----------- 1006 [1] J. Postel: "Simple Mail Transfer Protocol", Standard, 1007 STD 10, RFC 821, August 1982. Recommended 1009 [2] D. Crocker: "Standard for the format of ARPA Standard, 1010 Internet text messages." STD 11, RFC 822, Recommended 1011 August 1982. 1013 [3] M.R. Horton, R. Adams: "Standard for Not an offi- 1014 interchange of USENET messages", RFC 1036, cial IETF 1015 December 1987. standard, 1016 but in 1017 reality a de- 1018 facto 1019 standard for 1020 Usenet News 1022 [4] M. Sirbu: "A Content-Type header field header Standard, 1023 field for internet messages", RFC 1049, March Recommended, 1024 1988. but can in 1025 the future 1026 be expected 1027 to be 1028 replaced by 1029 MIME 1031 [5] R. Braden (editor): "Requirements for Standard, 1032 Internet Hosts -- Application and Support", Required 1033 STD-3, RFC 1123, October 1989. 1035 [6] D. Robinson, R. Ullman: "Encoding Header Non-standard 1036 field Header field for Internet Messages", 1037 RFC 1154, April 1990. 1039 [7] S. Hardcastle-Kille: "Mapping between Proposed 1040 X.400(1988) / ISO 10021 and RFC 822", RFC standard, 1041 1327 May 1992. elective 1043 [8] H. Alvestrand & J. Romaguera: "Rules for Proposed 1044 Downgrading Messages from X.400/88 to standard, 1045 X.400/84 When MIME Content-Types are Present elective 1046 in the Messages", RFC 1496, August 1993. 1048 [9] A. Costanzo: "Encoding Header field Header Non-standard 1049 field for Internet Messages", RFC 1154, April 1050 1990. 1052 [10] A. Costanzo, D. Robinson: "Encoding Header Experimental 1053 field Header field for Internet Messages", 1054 RFC 1505, August 1993. 1056 [11] N. Freed & N. Borenstein: "MIME (Multipurpose Draft 1057 Internet Mail Extensions) Part One: Format of Standard, 1058 Internet Message Bodies. RFC 2945. November elective 1059 1996. 1061 [12] H. Alvestrand: "Tags for the Identification Proposed 1062 of Languages", RFC 1766, February 1995. standard, 1063 elective 1065 [13] J. Palme: "Electronic Mail", Artech House Non-standard 1066 publishers, London-Boston January 1995. 1068 [14] R. Troost, S. Dorner: "Communicating Experimental 1069 Presentation Information in Internet 1070 Messages: The Content-Disposition Header 1071 field", RFC 1806, June 1995. 1073 [15] B. Kantor, P. Lapsley, "Network News Transfer Proposed 1074 Protocol: "A Proposed Standard for the Stream- standard 1075 Based Transmission of News", RFC 977, January 1076 1986. 1077 [16] 1848 PS S. Crocker, N. Freed, J. Galvin, Proposed 1078 S. Murphy, "MIME Object Security Services", standard 1079 RFC 1848, March 1995. 1081 [17] J. Myers, M. Rose: The Content-MD5 Header Draft 1082 field Header field, RFC 1864, October 1995. standard 1084 [18] M. Horton, UUCP mail interchange format Not an offi- 1085 standard, RFC 976, Januari 1986. cial IETF 1086 standard, 1087 but in 1088 reality a de- 1089 facto 1090 standard for 1091 Usenet News 1093 [19] T. Berners-Lee, R. Header fielding, H. IETF draft 1094 Frystyk: Hypertext Transfer Protocol -- 1095 HTTP/1.0, draft-ietf-http-v10-spec-04.txt. 1097 [20] G. Vaudreuil: Voice Profile for Internet Experimental 1098 Mail, RFC 1911, February 1996. 1100 [21] H. Spencer: News Article Format and Not even an 1101 Transmission, June 1994, RFC, but 1102 FTP://zoo.toronto.edu/pub/news.ps.Z still widely 1103 FTP://zoo.toronto.edu/pub/news.txt.Z used and 1104 partly 1105 This document is often referenced under the almost a de- 1106 name "son-of-RFC1036". facto 1107 standard for 1108 Usenet News 1110 [23] PICS Label Distribution Label Syntax and Other 1111 Communication Protocols, World Wide Web standard 1112 Consortium, October 1996. 1114 [24] Eudora Pro Macintosh User Manual, Qualcomm Non-standard 1115 Inc., 1988-1995. 1117 [25] C. Newman: Originator-Info Message Header Non-standard 1118 field. draft-newman-msgheader field-originfo- 1119 01.txt, July 1997. 1121 [26] Grant Neufeld and Joshua D. Baer: The Use of IETF draft 1122 URLs as Meta-Syntax for Core Mail List 1123 Commands and their Transport through Message 1124 Header fields, draft-baer-listspec-01.txt, 1125 September 1997. 1127 6. Author's address 1129 Jacob Palme Phone: +46-8-16 16 67 1130 Stockholm University/KTH Fax: +46-8-783 08 29 1131 Electrum 230 E-mail: jpalme@dsv.su.se 1132 S-164 40 Kista, Sweden 1134 Appendix A: 1135 Header fields sorted by Internet RFC document in which they appear. 1137 RFC 822 1138 ------- 1140 bcc 1141 cc 1142 Comments 1143 Date 1144 From 1145 In-Reply-To 1146 Keywords 1147 Message-ID 1148 Received 1149 References 1150 Reply-To 1151 Resent- 1152 Resent-bcc 1153 Resent-cc 1154 Resent-Date 1155 Resent-From 1156 Resent-From 1157 Resent-Message-ID 1158 Resent-Reply-To 1159 Resent-To 1160 Return-Path 1161 Sender 1162 Sender 1163 Subject 1164 To 1166 RFC 976 1167 ------- 1169 "From " (followed by space, not colon (:") 1171 RFC 1036 1172 -------- 1174 Approved 1175 Control 1176 Distribution 1177 Expires 1178 Followup-To 1179 Lines 1180 Newsgroups 1181 Organization 1182 Path 1183 Summary 1184 Xref 1186 RFC 1049 1187 -------- 1189 Content-Type 1191 RFC 1327 1192 -------- 1194 Alternate-recipient 1195 Auto-Forwarded 1196 Autoforwarded 1197 Content-Identifier 1198 Content-Return 1199 Conversion 1200 Conversion-With-Loss 1201 Delivery-Date 1202 Discarded-X400-IPMS-Extensions 1203 Discarded-X400-MTS-Extensions 1204 Disclose-Recipients 1205 DL-Expansion-History 1206 Expiry-Date 1207 Generate-Delivery-Report 1208 Importance 1209 Incomplete-Copy 1210 Language 1211 Message-Type Delivery 1212 Obsoletes 1213 Original-Encoded-Information-Types 1214 Prevent-NonDelivery-Report 1215 Priority 1216 Reply-By 1217 Report 1218 Sensitivity 1220 RFC 1505 1221 -------- 1223 Encoding 1225 RFC 2045 1226 -------- 1228 Content-Description 1229 Content-ID 1230 Content-Transfer-Encoding 1231 Content-Type 1232 MIME-Version 1234 RFC 1806 1235 -------- 1237 Content-Disposition 1239 RFC 1864 1240 -------- 1242 Content-MD5 1244 RFC 1911 1245 -------- 1247 Importance 1248 Sensitivity 1250 RFC 2110 1251 -------- 1253 Content-Base 1254 Content-Location 1256 son-of-RFC1036 [21] 1257 ------------------- 1259 Also-Control 1260 Article-Names 1261 Article-Updates 1262 See-Also 1263 Supersedes 1265 draft-ietf-receipt 1266 ------------------ 1267 Disposition-Notification-To 1268 Disposition-Notification-Options 1269 Original-Recipient 1271 World Wide Web Consortium (W3C) Recommendations 1272 ----------------------------------------------- 1274 Pics-Label 1276 Not Internet standard 1277 --------------------- 1279 "From " (not followed by ":") 1280 Apparently-to 1281 Content-Alias 1282 Content-Length 1283 Content-SGML-Entity 1284 Encoding 1285 Errors-To 1286 Fax 1287 Fcc 1288 For-Approval 1289 For-Comment 1290 For-Handling 1291 List-Archive 1292 List-Help 1293 List-ID 1294 List-Owner 1295 List-Post 1296 List-Software 1297 List-Subscribe 1298 List-Unsubscribe 1299 Mail-System-Version 1300 Mailer 1301 Organisation 1302 Originating-Client 1303 Originator-Info 1304 Phone 1305 Return-Receipt-To 1306 Status 1307 Supersedes 1308 Telefax 1309 X-Envelope-From 1310 X-Envelope-To 1311 X-Mailer 1312 X-MIME-Autoconverted 1313 X-Newsreader 1314 X-No-Archive 1315 X-Priority 1316 X-Sender 1317 X-UIDL 1318 X-URL 1319 X-X-Sender 1320 X400-Content-Return 1322 Appendix B: Alphabetical index 1324 Section Header field 1325 ------- ------------ 1327 3.3 Also-Control 1328 3.3 Alternate-Recipient 1329 3.4 Apparently-To 1330 3.4 Approved 1331 3.6 Article-Names 1332 3.6 Article-Updates 1333 3.17 Auto-Forwarded 1334 3.4 bcc 1335 3.4 cc 1336 Client, see Originating-Client 1337 Comment, see For-Comment 1338 3.7 Comments 1339 3.6 Content-Alias 1340 3.6 Content-Base 1341 3.12 Content-Conversion 1342 3.7 Content-Description 1343 3.3 Content-Disposition 1344 3.6 Content-ID 1345 3.7 Content-Identifier 1346 3.10 Content-Language see also Language 1347 3.11 Content-Length 1348 3.6 Content-Location 1349 3.15 Content-MD5 1350 3.4 Content-Return 1351 3.13 Content-SGML-Entity 1352 3.13 Content-Transfer-Encoding 1353 3.13 Content-Type 1354 3.3 Control 1355 3.12 Conversion 1356 3.12 Conversion-With-Loss 1357 Copy, see Incomplete-Copy 1358 3.8 Date 1359 Date, see also Delivery-Date, Received, Expires, Expiry- 1360 Date 1361 3.8 Delivery-Date 1362 Delivery-Report, see Generate-Delivery-Report, Prevent- 1363 Delivery-Report, Non-Delivery-Report, Content-Type 1364 Description, see Content-Description 1365 3.17 Discarded-X400-IPMS-Extensions 1366 3.17 Discarded-X400-MTS-Extensions 1367 3.3 Disclose-Recipients 1368 Disposition, see also Content-Disposition 1369 3.5 Disposition-Notification-Options 1370 3.5 Disposition-Notification-To 1371 3.4 Distribution 1372 3.2 DL-Expansion-History-Indication 1373 3.13 Encoding see also Content-Transfer-Encoding 1374 3.4 Errors-To 1375 3.8 Expires 1376 3.8 Expiry-Date 1377 Extension see Discarded-X400-IPMS-Extensions, Discarded- 1378 X400-MTS-Extensions 1379 3.4 Fax 1380 3.17 Fcc 1381 3.4 Followup-To 1382 3.4 For-Approval 1383 3.4 For-Comment 1384 3.4 For-Handling 1385 Forwarded, see Auto-Forwarded 1386 3.4 From 1387 3.4 Generate-Delivery-Report 1388 Handling, see For-Handling 1389 History, see DL-Expansion-History-Indication 1390 ID, see Content-ID and Message-ID 1391 Identifier, see Content-ID and Message-ID 1392 3.9 Importance 1393 3.6 In-Reply-To 1394 3.9 Incomplete-Copy 1395 3.7 Keywords 1396 Label, see PICS-Label 1397 3.10 Language see also Content-Language 1398 Length see Content-Length 1399 3.11 Lines 1400 3.16 List-Archive 1401 3.16 List-Help 1402 3.16 List-ID 1403 3.16 List-Owner 1404 3.16 List-Post 1405 3.16 List-Software 1406 3.16 List-Subscribe 1407 3.16 List-Unsubscribe 1408 Loss, see Conversion-With-Loss 1409 3.4 Mail-System-Version see also X-mailer 1410 3.4 Mailer 1411 MD5 see Content-MD5 1412 3.6 Message-ID 1413 3.13 Message-Type 1414 3.3 MIME-Version 1415 3.4 Newsgroups 1416 Newsreader, see X-Newsreader 1417 3.6 Obsoletes 1418 3.7 Organisation 1419 3.7 Organization 1420 3.3 Original-Encoded-Information-Types 1421 3.6 Original-Recipient 1422 3.4 Originating-Client 1423 3.4 Originator-Info see also Sender 1424 3.2 Path 1425 3.4 Phone 1426 3.9 PICS-Label 1427 3.9 Precedence 1428 3.4 Prevent-NonDelivery-Report 1429 3.9 Priority 1430 3.2 Received 1431 Recipient, see To, cc, bcc, Alternate-Recipient, Disclose- 1432 Recipient 1433 3.6 References 1434 3.8 Reply-By 1435 3.4 Reply-To, see also In-Reply-To, References 1436 3.14 Resent- 1437 Return see also Content-Return 1438 3.2 Return-Path 1439 3.5 Return-Receipt-To 1440 3.6 See-Also 1441 3.4 Sender 1442 3.9 Sensitivity 1443 3.17 Status 1444 3.7 Subject 1445 3.7 Summary 1446 3.6 Supersedes 1447 3.4 Telefax 1448 3.4 To 1449 Transfer-Encoding see Content-Transfer-Encoding 1450 Type see Content-Type, Message-Type, Original-Encoded- 1451 Information-Types 1452 Version, see MIME-Version, X-Mailer 1453 3.4 X-Envelope-From 1454 3.4 X-Envelope-To 1455 3.16 X-List-Host 1456 3.16 X-Listserver 1457 3.4 X-Mailer see also Mail-System-Version 1458 3.13 X-MIME-Autoconverted 1459 3.4 X-Newsreader 1460 3.17 X-No-Archive 1461 3.9 X-Priority 1462 3.4 X-Sender see also Originator-Info 1463 3.6 X-UIDL 1464 3.6 X-URL see also Content-Location 1465 3.4 X-X-Sender see also Originator-Info 1466 3.4 X400-Content-Return 1467 3.15 Xref