idnits 2.17.1 draft-ietf-mailext-mail-attributes-05.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. 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. 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: ---------------------------------------------------------------------------- == Line 335 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 1997) is 9963 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '2' on line 768 looks like a reference -- Missing reference section? '3' on line 772 looks like a reference -- Missing reference section? '5' on line 790 looks like a reference -- Missing reference section? '7' on line 798 looks like a reference -- Missing reference section? '8' on line 801 looks like a reference -- Missing reference section? '11' on line 813 looks like a reference -- Missing reference section? '12' on line 819 looks like a reference -- Missing reference section? '14' on line 826 looks like a reference -- Missing reference section? '17' on line 839 looks like a reference -- Missing reference section? '20' on line 855 looks like a reference -- Missing reference section? '16' on line 835 looks like a reference -- Missing reference section? '1' on line 765 looks like a reference -- Missing reference section? '18' on line 842 looks like a reference -- Missing reference section? '15' on line 831 looks like a reference -- Missing reference section? '19' on line 851 looks like a reference -- Missing reference section? '21' on line 988 looks like a reference -- Missing reference section? '13' on line 823 looks like a reference -- Missing reference section? '4' on line 781 looks like a reference -- Missing reference section? '6' on line 794 looks like a reference -- Missing reference section? '9' on line 806 looks like a reference -- Missing reference section? '10' on line 809 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 2 warnings (==), 23 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 draft-ietf-mailext-mail-attributes-05.txt Sweden 4 Category: Informational July 1996 5 Expires January 1997 7 Common Internet Message Headers 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its 13 areas, and its working groups. Note that other groups may also 14 distribute working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other 18 documents at any time. It is inappropriate to use Internet- 19 Drafts as reference material or to cite them other than as 20 ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check 23 the ``1id-abstracts.txt'' listing contained in the Internet- 24 Drafts Shadow Directories on ftp.is.co.za (Africa), 25 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), 26 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 28 This memo provides information for the Internet community. This 29 memo does not specify an Internet standard of any kind, since 30 this document is mainly a compilation of information taken from 31 other RFCs.. Distribution of this memo is unlimited. 33 Abstract 35 This memo contains a table of commonly occurring headers in headings of 36 e-mail messages. The document compiles information from other RFCs such 37 as RFC 822, RFC 1036, RFC 1123, RFC 1327, RFC 1496, RFC 1521, RFC 1766, 38 RFC 1806, RFC 1864 and RFC 1911. A few commonly occurring headers 39 which are not defined in RFCs are also included. For each header, the 40 memo gives a short description and a reference to the RFC in which the 41 header is defined. 43 Table of contents 45 1. Introduction 46 2. Use of gatewaying headers 47 3. Table of headers 48 3.1 Phrases used in the tables 49 3.2 Trace information 50 3.3 Format and control information 51 3.4 Sender and recipient indication 52 3.5 Response control 53 3.6 Message identification and referral headers 54 3.7 Other textual headers 55 3.8 Headers containing dates and times 56 3.9 Quality information 57 3.10 Language information 58 3.11 Size information 59 3.12 Conversion control 60 3.13 Encoding information 61 3.14 Resent-headers 62 3.15 Security and reliability 63 3.16 Miscellaneous 64 4. Acknowledgments 65 5. References 66 6. Author's address 67 Appendix A: 68 Headers sorted by Internet RFC document in which they appear. 69 Appendix B: 70 Alphabetical index 72 1. Introduction 74 Many different Internet standards and RFCs define headers which 75 may occur on Internet Mail Messages and Usenet News Articles. The 76 intention of this document is to list all such headers in one 77 document as an aid to people developing message systems or interested 78 in Internet Mail standards. 80 The document contains all headers which the author has 81 found in the following Internet standards: , RFC 822 [2], 82 RFC 1036 [3], RFC 1123 [5], RFC 1327 [7], RFC 1496 [8], RFC 1521 [11], 83 RFC 1766 [12], RFC 1806 [14], RFC 1864[17] and RFC 1911[20]. Note in 84 particular that heading attributes defined in PEM (RFC 1421-1424) and 85 MOSS (RFC 1848 [16]) are not included. PEM and MOSS headers only appear 86 inside the body of a message, and thus are not headers in the RFC 822 87 sense. Mail attributes in envelopes, i.e. attributes controlling the 88 message transport mechanism between mail and news servers, are not 89 included. This means that attributes from SMTP [1], UUCP [18] and NNTP 90 [15] are mainly not covered either. Headings used only in HTTP [19] are 91 not included yet, but may be included in future version of this memo. A 92 few additional headers which often can be found in e-mail headings but 93 are not part of any Internet standard are also included. 95 For each header, the document gives a short description and 96 a reference to the Internet standard or RFC, in which they are defined. 98 The header names given here are spelled the same way as when they are 99 actually used. This is usually American but sometimes English spelling. 100 One header in particular, "Organisation/Organization", occurs in e-mail 101 headers sometimes with the English and other times with the American 102 spelling. 104 The following words are used in this memo with the meaning specified 105 below: 107 heading Formatted text at the top of a message, ended by a 108 blank line 110 header = heading One field in the heading, beginning with a field 111 field name, colon, and followed by the field value(s) 113 It is my intention to continue updating this document after its 114 publication as an RFC. The latest version, which may be more up-to-date 115 (but also less fully checked out) will be kept available for 116 downloading from URL 117 http://www.dsv.su.se/~jpalme/ietf-mail-attributes.pdf. 119 Please e-mail me (Jacob Palme ) if you have noted 120 headers which should be included in this memo but are not. 122 2. Use of gatewaying headers 124 RFC 1327 defines a number of new headers in Internet mail, which are 125 defined to map headers which X.400 has but which were previously not 126 standardized in Internet mail. The fact that a header occurs in RFC 127 1327 indicates that it is recommended for use in gatewaying messages 128 between X.400 and Internet mail, but does not mean that the header is 129 recommended for messages wholly within Internet mail. Some of these 130 headers may eventually see widespread implementation and use in 131 Internet mail, but at the time of this writing (1996) they are not 132 widely implemented or used. 134 Headers defined only in RFC 1036 for use in Usenet News sometimes 135 appear in mail messages, either because the messages have been 136 gatewayed from Usenet News to e-mail, or because the messages were 137 written in combined clients supporting both e-mail and Usenet News in 138 the same client. These headers are not standardized for use in Internet 139 e-mail and should be handled with caution by e-mail agents. 141 3. Table of headers 143 3.1 Phrases used in the tables 145 "not for general Used to mark headers which are defined in RFC 146 usage" 1327 for use in messages from or to Internet 147 mail/X.400 gateways. These headers have not 148 been standardized for general usage in the 149 exchange of messages between Internet mail- 150 based systems. 152 "not standardized Used to mark headers defined only in RFC 1036 153 for use in e-mail" for use in Usenet News. These headers have no 154 standard meaning when appearing in e-mail, 155 some of them may even be used in different 156 ways by different software. When appearing in 157 e-mail, they should be handled with caution. 158 Note that RFC 1036, although generally used as 159 a de-facto standard for Usenet News, is not an 160 official IETF standard or even on the IETF 161 standards track. 163 "non-standard" This header is not specified in any of 164 referenced RFCs which define Internet 165 protocols, including Internet Standards, draft 166 standards or proposed standards. The header 167 appears here because it often appears in e- 168 mail or Usenet News. Usage of these headers is 169 not in general recommended. Some header 170 proposed in ongoing IETF standards development 171 work, but not yet accepted, are also marked in 172 this way. 174 "discouraged" This header, which is non-standard, is known 175 to create problems and should not be 176 generated. Handling of such headers in 177 incoming mail should be done with great 178 caution. 180 "controversial" The meaning and usage of this header is 181 controversial, i.e. different implementors 182 have chosen to implement the header in 183 different ways. Because of this, such headers 184 should be handled with caution and 185 understanding of the different possible 186 interpretations. 188 "experimental" This header is used for newly defined headers, 189 which are to be tried out before entering the 190 IETF standards track. These should only be 191 used if both communicating parties agree on 192 using them. In practice, some experimental 193 protocols become de-facto-standards before 194 they are made into IETF standards. 196 3.2 Trace information 198 Used to convey the information Return-Path: RFC 821, 199 from the MAIL FROM envelope RFC 1123: 5.2.13. 200 attribute in final delivery, when 201 the message leaves the SMTP 202 environment in which "MAIL FROM" 203 is used. 205 Trace of MTAs which a message has Received: RFC 822: 4.3.2, 206 passed. RFC 1123: 5.2.8. 208 List of MTAs passed. Path: RFC 1036: 2.2.6, 209 only in Usenet 210 News, not in e- 211 mail. 213 Trace of distribution lists DL-Expansion- RFC 1327, not for 214 passed. History- general usage. 215 Indication: 217 3.3 Format and control 218 information 220 An indicator that this message is MIME-Version: RFC 1521: 3. 221 formatted according to the MIME 222 standard, and an indication of 223 which version of MIME is 224 utilized. 226 Special Usenet News actions only. Control: RFC 1036: 2.1.6, 227 only in Usenet 228 News, not in e- 229 mail. 231 Special Usenet News actions and a Also-Control: son-of-RFC1036 232 normal article at the same time. [21], non- 233 standard, only in 234 Usenet News, not 235 in e-mail 237 Which body part types occur in Original- RFC 1327, not for 238 this message. Encoded- general usage. 239 Information- 240 Types: 242 Controls whether this message may Alternate- RFC 1327, not for 243 be forwarded to alternate Recipient: general usage. 244 recipients such as a postmaster 245 if delivery is not possible to 246 the intended recipient. Default: 247 Allowed. 249 Whether recipients are to be told Disclose- RFC 1327, not for 250 the names of other recipients of Recipients: general usage. 251 the same message. This is 252 primarily an X.400 facility. In 253 X.400, this is an envelope 254 attribute and refers to 255 disclosure of the envelope 256 recipient list. Disclosure of 257 other recipients is in Internet 258 mail done via the To:, cc: and 259 bcc: headers. 261 Whether a MIME body part is to be Content- RFC 1806, 262 shown inline or is an attachment; Disposition: experimental 263 can also indicate a suggested 264 filename for use when saving an 265 attachment to a file. 267 3.4 Sender and recipient 268 indication 270 Authors or persons taking From: RFC 822: 4.4.1, 271 responsibility for the message. RFC 1123: 5.2.15- 272 16, 5.3.7, 273 Note difference from the "From " RFC 1036 2.1.1 274 header (not followed by ":") 275 below. 277 (1) This header should never From not standardized 278 appear in e-mail being sent, and for use in e-mail 279 should thus not appear in this 280 memo. It is however included, 281 since people often ask about it. 283 This header is used in the so- 284 called Unix mailbox format, also 285 known as Berkely mailbox format 286 or the MBOX format. This is a 287 format for storing a set of 288 messages in a file. A line 289 beginning with "From " is used to 290 separate successive messages in 291 such files. 293 This header will thus appear when 294 you use a text editor to look at 295 a file in the Unix mailbox 296 format. Some mailers also use 297 this format when printing 298 messages on paper. 300 The information in this header 301 should NOT be used to find an 302 address to which replies to a 303 message are to be sent. 305 (2) Used in Usenet News mail From RFC 976: 2.4 for 306 transport, to indicate the path or use in Usenet News 307 through which an article has gone >From 308 when transferred to a new host. 310 Sometimes called "From_" header. 312 Name of the moderator of the Approved: RFC 1036: 2.2.11, 313 newsgroup to which this article not standardized 314 is sent; necessary on an article for use in e-mail. 315 sent to a moderated newsgroup to 316 allow its distribution to the 317 newsgroup members. Also used on 318 certain control messages, which 319 are only performed if they are 320 marked as Approved. 322 The person or agent submitting Sender: RFC 822: 4.4.2, 323 the message to the network, if RFC 1123: 5.2.15- 324 other than shown by the From: 16, 5.3.7. 325 header. 327 Primary recipients. To: RFC 822: 4.5.1, 328 RFC 1123: 5.2.15- 329 16, 5.3.7. 331 Secondary, informational cc: RFC 822: 4.5.2, 332 recipients. (cc = Carbon Copy) RFC 1123. 5.2.15- 333 16, 5.3.7. 335 Recipients not to be disclosed to bcc: RFC 822: 4.5.3, 336 other recipients. (bcc = Blind RFC 1123: 5.2.15- 337 Carbon Copy). 16, 5.3.7. 339 In Usenet News: group(s) to which Newsgroups: RFC 1036: 2.1.3, 340 this article was posted. not standardized 341 Some systems provide this header and controversial 342 also in e-mail although it is not for use in e-mail. 343 standardized there. 345 Unfortunately, the header can 346 appear in e-mail with two 347 different and contradictory 348 meanings: 350 (a) Indicating the newsgroup 351 recipient of an article/message 352 sent to both e-mail and Usenet 353 News recipients. 355 (b) In a personally addressed 356 reply to an article in a news- 357 group, indicating the newsgroup 358 in which this discussion 359 originated. 361 Inserted by Sendmail when there Apparently- Non-standard, 362 is no "To:" recipient in the To: discouraged, 363 original message, listing mentioned in 364 recipients derived from the RFC 1211. 365 envelope into the message 366 heading. This behavior is not 367 quite proper, MTAs should not 368 modify headings (except inserting 369 Received lines), and it can in 370 some cases cause Bcc recipients 371 to be wrongly divulged to non-Bcc 372 recipients. 374 Geographical or organizational Distribution: RFC 1036: 2.2.7, 375 limitation on where this article not standardized 376 can be distributed. for use in e-mail. 378 Fax number of the originator. Fax:, Non-standard. 379 Telefax: 381 Phone number of the originator. Phone: Non-standard. 383 Information about the client Mail-System- Non-standard. 384 software of the originator. Version:, 385 Mailer:, 386 Originating- 387 Client:, X- 388 Mailer, X- 389 Newsreader 391 3.5 Response control 393 This header is meant to indicate Reply-To: RFC 822: 4.4.3, 394 where the sender wants replies to RFC 1036: 2.2.1 395 go. Unfortunately, this is controversial. 396 ambiguous, since there are 397 different kinds of replies, which 398 the sender may wish to go to 399 different addresses. In 400 particular, there are personal 401 replies intended for only one 402 person, and group replies, 403 intended for the whole group of 404 people who read the replied-to 405 message (often a mailing list, 406 anewsgroup name cannot appear 407 here because of different syntax, 408 see "Followup-To" below.). 410 Some mail systems use this header 411 to indicate a better form of the 412 e-mail address of the sender. 413 Some mailing list expanders puts 414 the name of the list in this 415 header. These practices are 416 controversial. The personal 417 opinion of the author of this RFC 418 is that this header should be 419 avoided except in special cases, 420 but this is a personal opinion 421 not shared by all specialists in 422 the area. 424 Used in Usenet News to indicate Followup-To: RFC 1036: 2.2.3, 425 that future discussions (=follow- not standardized 426 up) on an article should go to a for use in e-mail. 427 different set of newsgroups than 428 the replied-to article. The most 429 common usage is when an article 430 is posted to several newsgroups, 431 and further discussions is to 432 take place in only one of them. 434 In e-mail, this header may occur 435 in a message which is sent to 436 both e-mail and Usenet News, to 437 show where follow-up in Usenet 438 news is wanted. The header does 439 not say anything about where 440 follow-up in e-mail is to be 441 sent. 443 Note that the value of this 444 header must always be one or more 445 newsgroup names, never e-mail 446 addresses. 448 Address to which notifications Errors-To:, Non-standard, 449 are to be sent and a request to Return- discouraged. 450 get delivery notifications. Receipt-To: 451 Internet standards recommend, 452 however, the use of RCPT TO and 453 Return-Path, not Errors-To, for 454 where delivery notifications are 455 to be sent. 457 Whether non-delivery report is Prevent- RFC 1327, not for 458 wanted at delivery error. Default NonDelivery- general usage. 459 is to want such a report. Report: 461 Whether a delivery report is Generate- RFC 1327, not for 462 wanted at successful delivery. Delivery- general usage. 463 Default is not to generate such a Report: 464 report. 466 Indicates whether the content of Content- RFC 1327, not for 467 a message is to be returned with Return: general usage. 468 non-delivery notifications. 470 Possible future change of name X400-Content- non-standard 471 for "Content-Return:" Return: 473 3.6 Message identification and 474 referral headers 476 Unique ID of this message. Message-ID: RFC 822: 4.6.1 477 RFC 1036: 2.1.5. 479 Unique ID of one body part of the Content-ID: RFC 1521: 6.1. 480 content of a message. 482 Base to be used for resolving Content-Base: Non-standard 483 relative URIs within this content 484 part. 486 URI with which the content of Content- Non-standard 487 this content part might be Location: 488 retrievable. 490 Reference to message which this In-Reply-To: RFC 822: 4.6.2. 491 message is a reply to. 493 In e-mail: reference to other References: RFC 822: 4.6.3 494 related messages, in Usenet News: RFC 1036: 2.1.5. 495 reference to replied-to-articles. 497 References to other related Also-See: Son-of-RFC1036 498 articles in Usenet News. [21], non-standard 500 Reference to previous message Obsoletes: RFC 1327, not for 501 being corrected and replaced. general usage. 502 Compare to "Supersedes:" below. 503 This field may in the future be 504 replaced with "Supersedes:". 506 Commonly used in Usenet News in Supersedes: son-of-RFC1036 507 similar ways to the "Obsoletes" [21], non-standard 508 header described above. In Usenet 509 News, however, Supersedes causes 510 a full deletion of the replaced 511 article in the server, while 512 "Supersedes" and "Obsoletes" in e- 513 mail is implemented in the client 514 and often does not remove the old 515 version of the text. 517 Only in Usenet News, similar to Article- son-of-RFC1036 518 "Supersedes:" but does not cause Updates: [21], non-standard 519 the referenced article to be 520 physically deleted. 522 Reference to specially important Article- son-of-RFC1036 523 articles for a particular Usenet Names: [21], non-standard 524 Newsgroup. 526 3.7 Other textual headers 528 Search keys for data base Keywords: RFC 822: 4.7.1 529 retrieval. RFC 1036: 2.2.9. 531 Title, heading, subject. Often Subject: RFC 822: 4.7.1 532 used as thread indicator for RFC 1036: 2.1.4. 533 messages replying to or 534 commenting on other messages. 536 Comments on a message. Comments: RFC 822: 4.7.2. 538 Description of a particular body Content- RFC 1521: 6.2. 539 part of a message. Description: 541 Organization to which the sender Organization: RFC 1036: 2.2.8, 542 of this article belongs. not standardized 543 for use in e-mail. 545 See Organization above. Organisation: Non-standard. 547 Short text describing a longer Summary: RFC 1036: 2.2.10, 548 article. Warning: Some mail not standardized 549 systems will not display this for use in e-mail, 550 text to the recipient. Because of discouraged. 551 this, do not use this header for 552 text which you want to ensure 553 that the recipient gets. 555 A text string which identifies Content- RFC 1327, not for 556 the content of a message. Identifier: general usage. 558 3.8 Headers containing dates and 559 times 561 The time when a message was Delivery- RFC 1327, not for 562 delivered to its recipient. Date: general usage. 564 In Internet, the date when a Date: RFC 822: 5.1, 565 message was written, in X.400, RFC 1123: 5.2.14 566 the time a message was submitted. RFC 1036: 2.1.2. 567 Some Internet mail systems also 568 use the date when the message was 569 submitted. 571 A suggested expiration date. Can Expires: RFC 1036: 2.2.4, 572 be used both to limit the time of not standardized 573 an article which is not for use in e-mail. 574 meaningful after a certain date, 575 and to extend the storage of 576 important articles. 578 Time at which a message loses its Expiry-Date: RFC 1327, not for 579 validity. This field may in the general usage. 580 future be replaced by "Expires:". 582 Latest time at which a reply is Reply-By: RFC 1327, not for 583 requested (not demanded). general usage. 585 3.9 Quality information 587 Can be "normal", "urgent" or "non- Priority: RFC 1327, not for 588 urgent" and can influence general usage. 589 transmission speed and delivery. 591 Sometimes used as a priority Precedence: Non-standard, 592 value which can influence controversial, 593 transmission speed and delivery. discouraged. 594 Common values are "bulk" and 595 "first-class". Other uses is to 596 control automatic replies and to 597 control return-of-content 598 facilities, and to stop mailing 599 list loops. 601 A hint from the originator to the Importance: RFC 1327 and 602 recipients about how important a RFC 1911, 603 message is. Values: High, normal experimental 604 or low. Not used to control 605 transmission speed. 607 How sensitive it is to disclose Sensitivity: RFC 1327 and 608 this message to other people than RFC 1911, 609 the specified recipients. Values: experimental 610 Personal, private, company 611 confidential. The absence of this 612 header in messages gatewayed from 613 X.400 indicates that the message 614 is not sensitive. 616 Body parts are missing. Incomplete- RFC 1327, not for 617 Copy: general usage. 619 3.10 Language information 621 Can include a code for the Language: RFC 1327, not for 622 natural language used in a general usage. 623 message, e.g. "en" for English. 625 Can include a code for the Content- RFC 1766, proposed 626 natural language used in a Language: standard. 627 message, e.g. "en" for English. 629 3.11 Size information 631 Inserted by certain mailers to Content- Non-standard, 632 indicate the size in bytes of the Length: discouraged. 633 message text. This is part of a 634 format some mailers use when 635 showing a message to its users, 636 and this header should not be 637 used when sending a message 638 through the net. The use of this 639 header in transmission of a 640 message can cause several 641 robustness and interoperability 642 problems. 644 Size of the message. Lines: RFC 1036: 2.2.12, 645 not standardized 646 for use in e-mail. 648 3.12 Conversion control 650 The body of this message may not Conversion: RFC 1327, not for 651 be converted from one character general usage. 652 set to another. Values: 653 Prohibited and allowed. 655 Non-standard variant of Content- Non-standard. 656 Conversion: with the same values. Conversion: 658 The body of this message may not Conversion- RFC 1327, not for 659 be converted from one character With-Loss: general usage. 660 set to another if information 661 will be lost. Values: Prohibited 662 and allowed. 664 3.13 Encoding information 666 Format of content (character set Content-Type: RFC 1049, 667 etc.) Note that the values for RFC 1123: 5.2.13, 668 this header are defined in RFC 1521: 4. 669 different ways in RFC 1049 and in RFC 1766: 4.1 670 MIME (RFC 1521), look for the 671 "MIME-version" header to 672 understand if Content-Type is to 673 be interpreted according to RFC 674 1049 or according to MIME. The 675 MIME definition should be used in 676 generating mail. 678 RFC 1766 defines a parameter 679 "difference" to this header. 681 Information from the SGML entity Content-SGML- non-standard 682 declaration corresponding to the Entity: 683 entity contained in the body of 684 the body part. 686 Coding method used in a MIME Content- RFC 1521: 5. 687 message body. Transfer- 688 Encoding: 690 Only used with the value Message-Type: RFC 1327, not for 691 "Delivery Report" to indicates general usage. 692 that this is a delivery report 693 gatewayed from X.400. 695 Used in several different ways by Encoding: RFC 1154, 696 different mail systems. Some use RFC 1505, 697 it for a kind of content-type experimental. 698 information, some for encoding 699 and length information, some for 700 a kind of boundary information, 701 some in other ways. 703 3.14 Resent-headers 705 When manually forwarding a Resent-Reply- RFC 822: C.3.3. 706 message, headers referring to the To:, 707 forwarding, not to the original Resent-From:, 708 message. Note: MIME specifies Resent- 709 another way of resending Sender:, 710 messages, using the "Message" Resent-From:, 711 Content-Type. Resent-Date:, 712 Resent-To:, 713 Resent-cc:, 714 Resent-bcc:, 715 Resent- 716 Message-ID: 718 3.15 Security and reliability 720 Checksum of content to ensure Content-MD5: RFC 1864, proposed 721 that it has not been modified. standard. 723 Used in Usenet News to store Xref: RFC 1036: 2.2.13, 724 information to avoid showing a only in Usenet 725 reader the same article twice if News, not in e- 726 it was sent to more than one mail. 727 newsgroup. Only for local usage 728 within one Usenet News server, 729 should not be sent between 730 servers. 732 3.16 Miscellaneous 734 Name of file in which a copy of Fcc: Non-standard. 735 this message is stored. 737 Has been automatically forwarded. Auto- RFC 1327, not for 738 Forwarded: general usage. 740 Can be used in Internet mail to Discarded- RFC 1327, not for 741 indicate X.400 IPM extensions X400-IPMS- general usage. 742 which could not be mapped to Extensions: 743 Internet mail format. 745 Can be used in Internet mail to Discarded- RFC 1327, not for 746 indicate X.400 MTS extensions X400-MTS- general usage. 747 which could not be mapped to Extensions: 748 Internet mail format. 750 4. Acknowledgments 752 Harald Tveit Alvestrand, Ned Freed, Olle J�rnefors, Keith Moore, Nick 753 Smith and several other people have helped me with compiling this list. 754 I especially thank Ned Freed and Olle J�rnefors for their thorough 755 review and many helpful suggestions for improvements. I alone take 756 responsibility for any errors which may still be in the list. 758 An earlier version of this list has been published as part of [13]. 760 5. References 762 Ref. Author, title IETF status 763 (July 1996) 764 ----- --------------------------------------------- ----------- 765 [1] J. Postel: "Simple Mail Transfer Protocol", Standard, 766 STD 10, RFC 821, August 1982. Recommended 768 [2] D. Crocker: "Standard for the format of ARPA Standard, 769 Internet text messages." STD 11, RFC 822, Recommended 770 August 1982. 772 [3] M.R. Horton, R. Adams: "Standard for Not an offi- 773 interchange of USENET messages", RFC 1036, cial IETF 774 December 1987. standard, 775 but in 776 reality a de- 777 facto 778 standard for 779 Usenet News 781 [4] M. Sirbu: "A Content-Type header header for Standard, 782 internet messages", RFC 1049, March 1988. Recommended, 783 but can in 784 the future 785 be expected 786 to be 787 replaced by 788 MIME 790 [5] R. Braden (editor): "Requirements for Standard, 791 Internet Hosts -- Application and Support", Required 792 STD-3, RFC 1123, October 1989. 794 [6] D. Robinson, R. Ullman: "Encoding Header Non-standard 795 Header for Internet Messages", RFC 1154, 796 April 1990. 798 [7] S. Hardcastle-Kille: "Mapping between Proposed 799 X.400(1988) / ISO 10021 and RFC 822", RFC standard, 800 1327 May 1992. elective 801 [8] H. Alvestrand & J. Romaguera: "Rules for Proposed 802 Downgrading Messages from X.400/88 to standard, 803 X.400/84 When MIME Content-Types are Present elective 804 in the Messages", RFC 1496, August 1993. 806 [9] A. Costanzo: "Encoding Header Header for Non-standard 807 Internet Messages", RFC 1154, April 1990. 809 [10] A. Costanzo, D. Robinson: "Encoding Header Experimental 810 Header for Internet Messages", RFC 1505, 811 August 1993. 813 [11] N. Borenstein & N. Freed: "MIME (Multipurpose Draft 814 Internet Mail Extensions) Part One: Standard, 815 Mechanisms for Specifying and Describing the elective 816 Format of Internet Message Bodies", RFC 1521, 817 Sept 1993. 819 [12] H. Alvestrand: "Tags for the Identification Proposed 820 of Languages", RFC 1766, February 1995. standard, 821 elective 823 [13] J. Palme: "Electronic Mail", Artech House Non-standard 824 publishers, London-Boston January 1995. 826 [14] R. Troost, S. Dorner: "Communicating Experimental 827 Presentation Information in Internet 828 Messages: The Content-Disposition Header", 829 RFC 1806, June 1995. 831 [15] B. Kantor, P. Lapsley, "Network News Transfer Proposed 832 Protocol: "A Proposed Standard for the Stream- standard 833 Based Transmission of News", RFC 977, January 834 1986. 835 [16] 1848 PS S. Crocker, N. Freed, J. Galvin, Proposed 836 S. Murphy, "MIME Object Security Services", standard 837 RFC 1848, March 1995. 839 [17] J. Myers, M. Rose: The Content-MD5 Header Draft 840 Header, RFC 1864, October 1995. standard 842 [18] M. Horton, UUCP mail interchange format Not an offi- 843 standard, RFC 976, Januari 1986. cial IETF 844 standard, 845 but in 846 reality a de- 847 facto 848 standard for 849 Usenet News 851 [19] T. Berners-Lee, R. Headering, H. Frystyk: IETF draft 852 Hypertext Transfer Protocol -- HTTP/1.0, 853 draft-ietf-http-v10-spec-04.txt. 855 [20] G. Vaudreuil: Voice Profile for Internet Experimental 856 Mail, RFC 1911, February 1996. 858 [21] H. Spencer: News Article Format and Not even an 859 Transmission, June 1994, RFC, but 860 FTP://zoo.toronto.edu/pub/news.ps still widely 861 FTP://zoo.toronto.edu/pub/news.txt used and 862 partly 863 This document is often reference under the almost a de- 864 name "son-of-RFC1036". facto 865 standard for 866 Usenet News 868 6. Author's address 870 Jacob Palme Phone: +46-8-16 16 67 871 Stockholm University/KTH Fax: +46-8-783 08 29 872 Electrum 230 E-mail: jpalme@dsv.su.se 873 S-164 40 Kista, Sweden 874 Appendix A: 875 Headers sorted by Internet RFC document in which they appear. 877 RFC 822 878 ------- 880 bcc 881 cc 882 Comments 883 Date 884 From 885 In-Reply-To 886 Keywords 887 Message-ID 888 Received 889 References 890 Reply-To 891 Resent- 892 Resent-bcc 893 Resent-cc 894 Resent-Date 895 Resent-From 896 Resent-From 897 Resent-Message-ID 898 Resent-Reply-To 899 Resent-To 900 Return-Path 901 Sender 902 Sender 903 Subject 904 To 906 RFC 976 907 ------- 909 "From " (followed by space, not colon (:") 911 RFC 1036 912 -------- 914 Approved 915 Control 916 Distribution 917 Expires 918 Followup-To 919 Lines 920 Newsgroups 921 Organization 922 Path 923 Summary 924 Xref 925 RFC 1049 926 -------- 928 Content-Type 930 RFC 1327 931 -------- 933 Alternate-recipient 934 Auto-Forwarded 935 Autoforwarded 936 Content-Identifier 937 Content-Return 938 Conversion 939 Conversion-With-Loss 940 Delivery-Date 941 Discarded-X400-IPMS-Extensions 942 Discarded-X400-MTS-Extensions 943 Disclose-Recipients 944 DL-Expansion-History 945 Expiry-Date 946 Generate-Delivery-Report 947 Importance 948 Incomplete-Copy 949 Language 950 Message-Type Delivery 951 Obsoletes 952 Original-Encoded-Information-Types 953 Prevent-NonDelivery-Report 954 Priority 955 Reply-By 956 Report 957 Sensitivity 959 RFC 1505 960 -------- 962 Encoding 964 RFC 1521 965 -------- 967 Content-Description 968 Content-ID 969 Content-Transfer-Encoding 970 Content-Type 971 MIME-Version 973 RFC 1806 974 -------- 976 Content-Disposition 977 RFC 1864 978 -------- 980 Content-MD5 982 RFC 1911 983 -------- 985 Importance 986 Sensitivity 988 son-of-RFC1036 [21] 989 ------------------- 991 Also-Control 992 Article-Names 993 Article-Updates 994 See-Also 995 Supersedes 997 Not Internet standard 998 --------------------- 1000 Apparently-to 1001 Content-Base 1002 Content-Length 1003 Content-Location 1004 Content-SGML-Entity 1005 Encoding 1006 Errors-To 1007 Return-Receipt-To 1008 Fax 1009 "From " (not followed by ":") 1010 Telefax 1011 Fcc 1012 Mail-System-Version 1013 Mailer 1014 Organisation 1015 Originating-Client 1016 Phone 1017 Supersedes 1018 X400-Content-Return 1019 X-Mailer 1020 X-Newsreader 1021 Appendix B: 1022 Alphabetical index 1024 Section Heading-header 1025 ------- -------------- 1027 3.3 Also-Control 1028 3.6 Also-See 1029 3.3 Alternate-Recipient 1030 3.4 Apparently-To 1031 3.4 Approved 1032 3.6 Article-Names 1033 3.6 Article-Updates 1034 3.16 Auto-Forwarded 1035 3.4 bcc 1036 3.4 cc 1037 Client, see Originating-Client 1038 3.7 Comments 1039 3.6 Content-Base 1040 3.12 Content-Conversion 1041 3.7 Content-Description 1042 3.3 Content-Disposition 1043 3.6 Content-ID 1044 3.7 Content-Identifier 1045 3.10 Content-Language see also Language 1046 3.11 Content-Length 1047 3.6 Content-Location 1048 3.15 Content-MD5 1049 3.4 Content-Return 1050 3.13 Content-SGML-Entity 1051 3.13 Content-Transfer-Encoding 1052 3.13 Content-Type 1053 3.3 Control 1054 3.12 Conversion 1055 3.12 Conversion-With-Loss 1056 3.8 Date 1057 3.8 Delivery-Date 1058 Delivery-Report, see Generate-Delivery-Report, Prevent- 1059 Delivery-Report, Non-Delivery-Report, Content-Type 1060 Description, see Content-Description 1061 3.16 Discarded-X400-IPMS-Extensions 1062 3.16 Discarded-X400-MTS-Extensions 1063 3.3 Disclose-Recipients 1064 Disposition, see Content-Disposition 1065 3.4 Distribution 1066 3.2 DL-Expansion-History-Indication 1067 3.13 Encoding see also Content-Transfer-Encoding 1068 3.4 Errors-To 1069 3.8 Expires 1070 Extension see Discarded-X400-IPMS-Extensions, Discarded- 1071 X400-MTS-Extensions 1072 3.4 Fax 1073 3.16 Fcc 1074 3.4 Followup-To 1075 Forwarded, see Auto-Forwarded 1076 3.4 From 1077 3.4 Generate-Delivery-Report 1078 History, see DL-Expansion-History-Indication 1079 ID, see Content-ID and Message-ID 1080 Identifier, see Content-ID and Message-ID 1081 3.9 Importance 1082 3.6 In-Reply-To 1083 3.9 Incomplete-Copy 1084 3.7 Keywords 1085 3.10 Language see also Content-Language 1086 Length see Content-Length 1087 3.11 Lines 1088 3.4 Mail-System-Version see also X-mailer 1089 3.4 Mailer 1090 MD5 see Content-MD5 1091 3.6 Message-ID 1092 3.13 Message-Type 1093 3.3 MIME-Version 1094 3.4 Newsgroups 1095 Newsreader, see X-Newsreader 1096 3.6 Obsoletes 1097 3.7 Organisation 1098 3.7 Organization 1099 3.3 Original-Encoded-Information-Types 1100 3.4 Originating-Client 1101 3.2 Path 1102 3.4 Phone 1103 3.9 Precedence 1104 3.4 Prevent-NonDelivery-Report 1105 3.9 Priority 1106 3.2 Received 1107 Recipient, see To, cc, bcc, Alternate-Recipient, Disclose- 1108 Recipient 1109 3.6 References 1110 3.8 Reply-By 1111 3.4 Reply-To, see also In-Reply-To, References 1112 3.14 Resent- 1113 Return see also Content-Return 1114 3.2 Return-Path 1115 3.5 Return-Receipt-To 1116 3.4 Sender 1117 3.9 Sensitivity 1118 3.7 Subject 1119 3.7 Summary 1120 3.6 Supersedes 1121 3.4 Telefax 1122 3.4 To 1123 Transfer-Encoding see Content-Transfer-Encoding 1124 Type see Content-Type, Message-Type, Original-Encoded- 1125 Information-Types 1126 Version, see MIME-Version, X-Mailer 1127 3.4 X400-Content-Return 1128 3.4 X-Mailer see also Mail-System-Version 1129 3.4 X-Newsreader 1130 3.15 Xref