idnits 2.17.1 draft-ietf-mailext-mail-attributes-06.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-25) 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 9) being 61 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: ---------------------------------------------------------------------------- == Line 334 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 (March 1997) is 9903 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '2' on line 794 looks like a reference -- Missing reference section? '3' on line 798 looks like a reference -- Missing reference section? '5' on line 816 looks like a reference -- Missing reference section? '7' on line 824 looks like a reference -- Missing reference section? '8' on line 828 looks like a reference -- Missing reference section? '11' on line 840 looks like a reference -- Missing reference section? '12' on line 846 looks like a reference -- Missing reference section? '14' on line 853 looks like a reference -- Missing reference section? '17' on line 866 looks like a reference -- Missing reference section? '20' on line 882 looks like a reference -- Missing reference section? '16' on line 862 looks like a reference -- Missing reference section? '1' on line 791 looks like a reference -- Missing reference section? '18' on line 869 looks like a reference -- Missing reference section? '15' on line 858 looks like a reference -- Missing reference section? '19' on line 878 looks like a reference -- Missing reference section? '21' on line 1015 looks like a reference -- Missing reference section? '13' on line 850 looks like a reference -- Missing reference section? '4' on line 807 looks like a reference -- Missing reference section? '6' on line 820 looks like a reference -- Missing reference section? '9' on line 833 looks like a reference -- Missing reference section? '10' on line 836 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 3 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-06.txt Sweden 4 Category: Informational October 1996 5 Expires March 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: Headers sorted by Internet RFC document in which 68 they appear. 69 Appendix B: Alphabetical index 71 1. Introduction 73 Many different Internet standards and RFCs define headers which 74 may occur on Internet Mail Messages and Usenet News Articles. The 75 intention of this document is to list all such headers in one 76 document as an aid to people developing message systems or interested 77 in Internet Mail standards. 79 The document contains all headers which the author has 80 found in the following Internet standards: , RFC 822 [2], 81 RFC 1036 [3], RFC 1123 [5], RFC 1327 [7], RFC 1496 [8], RFC 1521 [11], 82 RFC 1766 [12], RFC 1806 [14], RFC 1864[17] and RFC 1911[20]. Note in 83 particular that heading attributes defined in PEM (RFC 1421-1424) and 84 MOSS (RFC 1848 [16]) are not included. PEM and MOSS headers only appear 85 inside the body of a message, and thus are not headers in the RFC 822 86 sense. Mail attributes in envelopes, i.e. attributes controlling the 87 message transport mechanism between mail and news servers, are not 88 included. This means that attributes from SMTP [1], UUCP [18] and NNTP 89 [15] are mainly not covered either. Headings used only in HTTP [19] are 90 not included yet, but may be included in future version of this memo. A 91 few additional headers which often can be found in e-mail headings but 92 are not part of any Internet standard are also included. 94 For each header, the document gives a short description and 95 a reference to the Internet standard or RFC, in which they are defined. 97 The header names given here are spelled the same way as when they are 98 actually used. This is usually American but sometimes English spelling. 99 One header in particular, "Organisation/Organization", occurs in e-mail 100 headers sometimes with the English and other times with the American 101 spelling. 103 The following words are used in this memo with the meaning specified 104 below: 106 heading Formatted text at the top of a message, ended by a 107 blank line 109 header = heading One field in the heading, beginning with a field 110 field name, colon, and followed by the field value(s) 112 It is my intention to continue updating this document after its 113 publication as an RFC. The latest version, which may be more up-to-date 114 (but also less fully checked out) will be kept available for 115 downloading from URL 116 http://www.dsv.su.se/~jpalme/ietf-mail-attributes.pdf. 118 Please e-mail me (Jacob Palme ) if you have noted 119 headers which should be included in this memo but are not. 121 2. Use of gatewaying headers 123 RFC 1327 defines a number of new headers in Internet mail, which are 124 defined to map headers which X.400 has but which were previously not 125 standardized in Internet mail. The fact that a header occurs in RFC 126 1327 indicates that it is recommended for use in gatewaying messages 127 between X.400 and Internet mail, but does not mean that the header is 128 recommended for messages wholly within Internet mail. Some of these 129 headers may eventually see widespread implementation and use in 130 Internet mail, but at the time of this writing (1996) they are not 131 widely implemented or used. 133 Headers defined only in RFC 1036 for use in Usenet News sometimes 134 appear in mail messages, either because the messages have been 135 gatewayed from Usenet News to e-mail, or because the messages were 136 written in combined clients supporting both e-mail and Usenet News in 137 the same client. These headers are not standardized for use in Internet 138 e-mail and should be handled with caution by e-mail agents. 140 3. Table of headers 142 3.1 Phrases used in the tables 144 "not for general Used to mark headers which are defined in RFC 145 usage" 1327 for use in messages from or to Internet 146 mail/X.400 gateways. These headers have not 147 been standardized for general usage in the 148 exchange of messages between Internet mail- 149 based systems. 151 "not standardized Used to mark headers defined only in RFC 1036 152 for use in e-mail" for use in Usenet News. These headers have no 153 standard meaning when appearing in e-mail, 154 some of them may even be used in different 155 ways by different software. When appearing in 156 e-mail, they should be handled with caution. 157 Note that RFC 1036, although generally used as 158 a de-facto standard for Usenet News, is not an 159 official IETF standard or even on the IETF 160 standards track. 162 "non-standard" This header is not specified in any of 163 referenced RFCs which define Internet 164 protocols, including Internet Standards, draft 165 standards or proposed standards. The header 166 appears here because it often appears in e- 167 mail or Usenet News. Usage of these headers is 168 not in general recommended. Some header 169 proposed in ongoing IETF standards development 170 work, but not yet accepted, are also marked in 171 this way. 173 "discouraged" This header, which is non-standard, is known 174 to create problems and should not be 175 generated. Handling of such headers in 176 incoming mail should be done with great 177 caution. 179 "controversial" The meaning and usage of this header is 180 controversial, i.e. different implementors 181 have chosen to implement the header in 182 different ways. Because of this, such headers 183 should be handled with caution and 184 understanding of the different possible 185 interpretations. 187 "experimental" This header is used for newly defined headers, 188 which are to be tried out before entering the 189 IETF standards track. These should only be 190 used if both communicating parties agree on 191 using them. In practice, some experimental 192 protocols become de-facto-standards before 193 they are made into IETF standards. 195 3.2 Trace information 197 Used to convey the information Return-Path: RFC 821, 198 from the MAIL FROM envelope RFC 1123: 5.2.13. 199 attribute in final delivery, when 200 the message leaves the SMTP 201 environment in which "MAIL FROM" 202 is used. 204 Trace of MTAs which a message has Received: RFC 822: 4.3.2, 205 passed. RFC 1123: 5.2.8. 207 List of MTAs passed. Path: RFC 1036: 2.2.6, 208 only in Usenet 209 News, not in e- 210 mail. 212 Trace of distribution lists DL-Expansion- RFC 1327, not for 213 passed. History- general usage. 214 Indication: 216 3.3 Format and control 217 information 219 An indicator that this message is MIME-Version: RFC 1521: 3. 220 formatted according to the MIME 221 standard, and an indication of 222 which version of MIME is 223 utilized. 225 Special Usenet News actions only. Control: RFC 1036: 2.1.6, 226 only in Usenet 227 News, not in e- 228 mail. 230 Special Usenet News actions and a Also-Control: son-of-RFC1036 231 normal article at the same time. [21], non- 232 standard, only in 233 Usenet News, not 234 in e-mail 236 Which body part types occur in Original- RFC 1327, not for 237 this message. Encoded- general usage. 238 Information- 239 Types: 241 Controls whether this message may Alternate- RFC 1327, not for 242 be forwarded to alternate Recipient: general usage. 243 recipients such as a postmaster 244 if delivery is not possible to 245 the intended recipient. Default: 246 Allowed. 248 Whether recipients are to be told Disclose- RFC 1327, not for 249 the names of other recipients of Recipients: general usage. 250 the same message. This is 251 primarily an X.400 facility. In 252 X.400, this is an envelope 253 attribute and refers to 254 disclosure of the envelope 255 recipient list. Disclosure of 256 other recipients is in Internet 257 mail done via the To:, cc: and 258 bcc: headers. 260 Whether a MIME body part is to be Content- RFC 1806, 261 shown inline or is an attachment; Disposition: experimental 262 can also indicate a suggested 263 filename for use when saving an 264 attachment to a file. 266 3.4 Sender and recipient 267 indication 269 Authors or persons taking From: RFC 822: 4.4.1, 270 responsibility for the message. RFC 1123: 5.2.15- 271 16, 5.3.7, 272 Note difference from the "From " RFC 1036 2.1.1 273 header (not followed by ":") 274 below. 276 (1) This header should never From not standardized 277 appear in e-mail being sent, and for use in e-mail 278 should thus not appear in this 279 memo. It is however included, 280 since people often ask about it. 282 This header is used in the so- 283 called Unix mailbox format, also 284 known as Berkely mailbox format 285 or the MBOX format. This is a 286 format for storing a set of 287 messages in a file. A line 288 beginning with "From " is used to 289 separate successive messages in 290 such files. 292 This header will thus appear when 293 you use a text editor to look at 294 a file in the Unix mailbox 295 format. Some mailers also use 296 this format when printing 297 messages on paper. 299 The information in this header 300 should NOT be used to find an 301 address to which replies to a 302 message are to be sent. 304 (2) Used in Usenet News mail From RFC 976: 2.4 for 305 transport, to indicate the path or use in Usenet News 306 through which an article has gone >From 307 when transferred to a new host. 309 Sometimes called "From_" header. 311 Name of the moderator of the Approved: RFC 1036: 2.2.11, 312 newsgroup to which this article not standardized 313 is sent; necessary on an article for use in e-mail. 314 sent to a moderated newsgroup to 315 allow its distribution to the 316 newsgroup members. Also used on 317 certain control messages, which 318 are only performed if they are 319 marked as Approved. 321 The person or agent submitting Sender: RFC 822: 4.4.2, 322 the message to the network, if RFC 1123: 5.2.15- 323 other than shown by the From: 16, 5.3.7. 324 header. 326 Primary recipients. To: RFC 822: 4.5.1, 327 RFC 1123: 5.2.15- 328 16, 5.3.7. 330 Secondary, informational cc: RFC 822: 4.5.2, 331 recipients. (cc = Carbon Copy) RFC 1123. 5.2.15- 332 16, 5.3.7. 334 Recipients not to be disclosed to bcc: RFC 822: 4.5.3, 335 other recipients. (bcc = Blind RFC 1123: 5.2.15- 336 Carbon Copy). 16, 5.3.7. 338 In Usenet News: group(s) to which Newsgroups: RFC 1036: 2.1.3, 339 this article was posted. not standardized 340 Some systems provide this header and controversial 341 also in e-mail although it is not for use in e-mail. 342 standardized there. 344 Unfortunately, the header can 345 appear in e-mail with two 346 different and contradictory 347 meanings: 349 (a) Indicating the newsgroup 350 recipient of an article/message 351 sent to both e-mail and Usenet 352 News recipients. 354 (b) In a personally addressed 355 reply to an article in a news- 356 group, indicating the newsgroup 357 in which this discussion 358 originated. 360 Inserted by Sendmail when there Apparently- Non-standard, 361 is no "To:" recipient in the To: discouraged, 362 original message, listing mentioned in 363 recipients derived from the RFC 1211. 364 envelope into the message 365 heading. This behavior is not 366 quite proper, MTAs should not 367 modify headings (except inserting 368 Received lines), and it can in 369 some cases cause Bcc recipients 370 to be wrongly divulged to non-Bcc 371 recipients. 373 Geographical or organizational Distribution: RFC 1036: 2.2.7, 374 limitation on where this article not standardized 375 can be distributed. for use in e-mail. 377 Fax number of the originator. Fax:, Non-standard. 378 Telefax: 380 Phone number of the originator. Phone: Non-standard. 382 Information about the client Mail-System- Non-standard. 383 software of the originator. Version:, 384 Mailer:, 385 Originating- 386 Client:, X- 387 Mailer, X- 388 Newsreader 390 3.5 Response control 392 This header is meant to indicate Reply-To: RFC 822: 4.4.3, 393 where the sender wants replies to RFC 1036: 2.2.1 394 go. Unfortunately, this is controversial. 395 ambiguous, since there are 396 different kinds of replies, which 397 the sender may wish to go to 398 different addresses. In 399 particular, there are personal 400 replies intended for only one 401 person, and group replies, 402 intended for the whole group of 403 people who read the replied-to 404 message (often a mailing list, 405 anewsgroup name cannot appear 406 here because of different syntax, 407 see "Followup-To" below.). 409 Some mail systems use this header 410 to indicate a better form of the 411 e-mail address of the sender. 412 Some mailing list expanders puts 413 the name of the list in this 414 header. These practices are 415 controversial. The personal 416 opinion of the author of this RFC 417 is that this header should be 418 avoided except in special cases, 419 but this is a personal opinion 420 not shared by all specialists in 421 the area. 423 Used in Usenet News to indicate Followup-To: RFC 1036: 2.2.3, 424 that future discussions (=follow- not standardized 425 up) on an article should go to a for use in e-mail. 426 different set of newsgroups than 427 the replied-to article. The most 428 common usage is when an article 429 is posted to several newsgroups, 430 and further discussions is to 431 take place in only one of them. 433 In e-mail, this header may occur 434 in a message which is sent to 435 both e-mail and Usenet News, to 436 show where follow-up in Usenet 437 news is wanted. The header does 438 not say anything about where 439 follow-up in e-mail is to be 440 sent. 442 Note that the value of this 443 header must always be one or more 444 newsgroup names, never e-mail 445 addresses. 447 Address to which notifications Errors-To:, Non-standard, 448 are to be sent and a request to Return- discouraged. 449 get delivery notifications. Receipt-To: 450 Internet standards recommend, 451 however, the use of RCPT TO and 452 Return-Path, not Errors-To, for 453 where delivery notifications are 454 to be sent. 456 Whether non-delivery report is Prevent- RFC 1327, not for 457 wanted at delivery error. Default NonDelivery- general usage. 458 is to want such a report. Report: 460 Whether a delivery report is Generate- RFC 1327, not for 461 wanted at successful delivery. Delivery- general usage. 462 Default is not to generate such a Report: 463 report. 465 Indicates whether the content of Content- RFC 1327, not for 466 a message is to be returned with Return: general usage. 467 non-delivery notifications. 469 Possible future change of name X400-Content- non-standard 470 for "Content-Return:" Return: 472 3.6 Message identification and 473 referral headers 475 Unique ID of this message. Message-ID: RFC 822: 4.6.1 476 RFC 1036: 2.1.5. 478 Unique ID of one body part of the Content-ID: RFC 1521: 6.1. 479 content of a message. 481 Base to be used for resolving Content-Base: Non-standard 482 relative URIs within this content 483 part. 485 URI with which the content of Content- Non-standard 486 this content part might be Location: 487 retrievable. 489 Reference to message which this In-Reply-To: RFC 822: 4.6.2. 490 message is a reply to. 492 In e-mail: reference to other References: RFC 822: 4.6.3 493 related messages, in Usenet News: RFC 1036: 2.1.5. 494 reference to replied-to-articles. 496 References to other related See-Also: Son-of-RFC1036 497 articles in Usenet News. [21], non-standard 498 Reference to previous message Obsoletes: RFC 1327, not for 499 being corrected and replaced. general usage. 500 Compare to "Supersedes:" below. 501 This field may in the future be 502 replaced with "Supersedes:". 504 Commonly used in Usenet News in Supersedes: son-of-RFC1036 505 similar ways to the "Obsoletes" [21], non-standard 506 header described above. In Usenet 507 News, however, Supersedes causes 508 a full deletion of the replaced 509 article in the server, while 510 "Supersedes" and "Obsoletes" in e- 511 mail is implemented in the client 512 and often does not remove the old 513 version of the text. 515 Only in Usenet News, similar to Article- son-of-RFC1036 516 "Supersedes:" but does not cause Updates: [21], non-standard 517 the referenced article to be 518 physically deleted. 520 Reference to specially important Article- son-of-RFC1036 521 articles for a particular Usenet Names: [21], non-standard 522 Newsgroup. 524 3.7 Other textual headers 526 Search keys for data base Keywords: RFC 822: 4.7.1 527 retrieval. RFC 1036: 2.2.9. 529 Title, heading, subject. Often Subject: RFC 822: 4.7.1 530 used as thread indicator for RFC 1036: 2.1.4. 531 messages replying to or 532 commenting on other messages. 534 Comments on a message. Comments: RFC 822: 4.7.2. 536 Description of a particular body Content- RFC 1521: 6.2. 537 part of a message, for example a Description: 538 caption for an image body part. 540 Organization to which the sender Organization: RFC 1036: 2.2.8, 541 of this article belongs. not standardized 542 for use in e-mail. 544 See Organization above. Organisation: Non-standard. 546 Short text describing a longer Summary: RFC 1036: 2.2.10, 547 article. Warning: Some mail not standardized 548 systems will not display this for use in e-mail, 549 text to the recipient. Because of discouraged. 550 this, do not use this header for 551 text which you want to ensure 552 that the recipient gets. 554 A text string which identifies Content- RFC 1327, not for 555 the content of a message. Identifier: general usage. 557 3.8 Headers containing dates and 558 times 560 The time when a message was Delivery- RFC 1327, not for 561 delivered to its recipient. Date: general usage. 563 In Internet, the date when a Date: RFC 822: 5.1, 564 message was written, in X.400, RFC 1123: 5.2.14 565 the time a message was submitted. RFC 1036: 2.1.2. 566 Some Internet mail systems also 567 use the date when the message was 568 submitted. 570 A suggested expiration date. Can Expires: RFC 1036: 2.2.4, 571 be used both to limit the time of not standardized 572 an article which is not for use in e-mail. 573 meaningful after a certain date, 574 and to extend the storage of 575 important articles. 577 Time at which a message loses its Expiry-Date: RFC 1327, not for 578 validity. This field may in the general usage. 579 future be replaced by "Expires:". 581 Latest time at which a reply is Reply-By: RFC 1327, not for 582 requested (not demanded). general usage. 584 3.9 Quality information 586 Can be "normal", "urgent" or "non- Priority: RFC 1327, not for 587 urgent" and can influence general usage. 588 transmission speed and delivery. 590 Sometimes used as a priority Precedence: Non-standard, 591 value which can influence controversial, 592 transmission speed and delivery. discouraged. 593 Common values are "bulk" and 594 "first-class". Other uses is to 595 control automatic replies and to 596 control return-of-content 597 facilities, and to stop mailing 598 list loops. 600 A hint from the originator to the Importance: RFC 1327 and 601 recipients about how important a RFC 1911, 602 message is. Values: High, normal experimental 603 or low. Not used to control 604 transmission speed. 606 How sensitive it is to disclose Sensitivity: RFC 1327 and 607 this message to other people than RFC 1911, 608 the specified recipients. Values: experimental 609 Personal, private, company 610 confidential. The absence of this 611 header in messages gatewayed from 612 X.400 indicates that the message 613 is not sensitive. 615 Body parts are missing. Incomplete- RFC 1327, not for 616 Copy: general usage. 618 3.10 Language information 620 Can include a code for the Language: RFC 1327, not for 621 natural language used in a general usage. 622 message, e.g. "en" for English. 624 Can include a code for the Content- RFC 1766, proposed 625 natural language used in a Language: standard. 626 message, e.g. "en" for English. 628 3.11 Size information 630 Inserted by certain mailers to Content- Non-standard, 631 indicate the size in bytes of the Length: discouraged. 632 message text. This is part of a 633 format some mailers use when 634 showing a message to its users, 635 and this header should not be 636 used when sending a message 637 through the net. The use of this 638 header in transmission of a 639 message can cause several 640 robustness and interoperability 641 problems. 643 Size of the message. Lines: RFC 1036: 2.2.12, 644 not standardized 645 for use in e-mail. 647 3.12 Conversion control 649 The body of this message may not Conversion: RFC 1327, not for 650 be converted from one character general usage. 651 set to another. Values: 652 Prohibited and allowed. 654 Non-standard variant of Content- Non-standard. 655 Conversion: with the same values. Conversion: 657 The body of this message may not Conversion- RFC 1327, not for 658 be converted from one character With-Loss: general usage. 659 set to another if information 660 will be lost. Values: Prohibited 661 and allowed. 663 3.13 Encoding information 665 Format of content (character set Content-Type: RFC 1049, 666 etc.) Note that the values for RFC 1123: 5.2.13, 667 this header are defined in RFC 1521: 4. 668 different ways in RFC 1049 and in RFC 1766: 4.1 669 MIME (RFC 1521), look for the 670 "MIME-version" header to 671 understand if Content-Type is to 672 be interpreted according to RFC 673 1049 or according to MIME. The 674 MIME definition should be used in 675 generating mail. 677 RFC 1766 defines a parameter 678 "difference" to this header. 680 Information from the SGML entity Content-SGML- non-standard 681 declaration corresponding to the Entity: 682 entity contained in the body of 683 the body part. 685 Coding method used in a MIME Content- RFC 1521: 5. 686 message body. Transfer- 687 Encoding: 689 Only used with the value Message-Type: RFC 1327, not for 690 "Delivery Report" to indicates general usage. 691 that this is a delivery report 692 gatewayed from X.400. 694 Used in several different ways by Encoding: RFC 1154, 695 different mail systems. Some use RFC 1505, 696 it for a kind of content-type experimental. 697 information, some for encoding 698 and length information, some for 699 a kind of boundary information, 700 some in other ways. 702 3.14 Resent-headers 704 When manually forwarding a Resent-Reply- RFC 822: C.3.3. 705 message, headers referring to the To:, 706 forwarding, not to the original Resent-From:, 707 message. Note: MIME specifies Resent- 708 another way of resending Sender:, 709 messages, using the "Message" Resent-From:, 710 Content-Type. Resent-Date:, 711 Resent-To:, 712 Resent-cc:, 713 Resent-bcc:, 714 Resent- 715 Message-ID: 717 3.15 Security and reliability 719 Checksum of content to ensure Content-MD5: RFC 1864, proposed 720 that it has not been modified. standard. 722 Used in Usenet News to store Xref: RFC 1036: 2.2.13, 723 information to avoid showing a only in Usenet 724 reader the same article twice if News, not in e- 725 it was sent to more than one mail. 726 newsgroup. Only for local usage 727 within one Usenet News server, 728 should not be sent between 729 servers. 731 3.16 Miscellaneous 733 Name of file in which a copy of Fcc: Non-standard. 734 this message is stored. 736 Has been automatically forwarded. Auto- RFC 1327, not for 737 Forwarded: general usage. 739 Can be used in Internet mail to Discarded- RFC 1327, not for 740 indicate X.400 IPM extensions X400-IPMS- general usage. 741 which could not be mapped to Extensions: 742 Internet mail format. 744 Can be used in Internet mail to Discarded- RFC 1327, not for 745 indicate X.400 MTS extensions X400-MTS- general usage. 746 which could not be mapped to Extensions: 747 Internet mail format. 749 This field is used by some mail Status: Non-standard, 750 delivery systems to indicate the should never 751 status of delivery for this appear in mail in 752 message when stored. Common transit. 753 values of this field are: 755 U message is not downloaded 756 and not deleted. 758 R message is read or 759 downloaded. 761 O message is old but not 762 deleted. 764 D to be deleted. 766 N new (a new message also 767 sometimes is distinguished 768 by not having any "Status:" 769 header. 771 Combinations of these characters 772 can occur, such as "Status: OR" 773 to indicate that a message is 774 downloaded but not deleted. 776 4. Acknowledgments 778 Harald Tveit Alvestrand, Ned Freed, Olle J�rnefors, Keith Moore, Nick 779 Smith and several other people have helped me with compiling this list. 780 I especially thank Ned Freed and Olle J�rnefors for their thorough 781 review and many helpful suggestions for improvements. I alone take 782 responsibility for any errors which may still be in the list. 784 An earlier version of this list has been published as part of [13]. 786 5. References 788 Ref. Author, title IETF status 789 (July 1996) 790 ----- --------------------------------------------- ----------- 791 [1] J. Postel: "Simple Mail Transfer Protocol", Standard, 792 STD 10, RFC 821, August 1982. Recommended 794 [2] D. Crocker: "Standard for the format of ARPA Standard, 795 Internet text messages." STD 11, RFC 822, Recommended 796 August 1982. 798 [3] M.R. Horton, R. Adams: "Standard for Not an offi- 799 interchange of USENET messages", RFC 1036, cial IETF 800 December 1987. standard, 801 but in 802 reality a de- 803 facto 804 standard for 805 Usenet News 807 [4] M. Sirbu: "A Content-Type header header for Standard, 808 internet messages", RFC 1049, March 1988. Recommended, 809 but can in 810 the future 811 be expected 812 to be 813 replaced by 814 MIME 816 [5] R. Braden (editor): "Requirements for Standard, 817 Internet Hosts -- Application and Support", Required 818 STD-3, RFC 1123, October 1989. 820 [6] D. Robinson, R. Ullman: "Encoding Header Non-standard 821 Header for Internet Messages", RFC 1154, 822 April 1990. 824 [7] S. Hardcastle-Kille: "Mapping between Proposed 825 X.400(1988) / ISO 10021 and RFC 822", RFC standard, 826 1327 May 1992. elective 828 [8] H. Alvestrand & J. Romaguera: "Rules for Proposed 829 Downgrading Messages from X.400/88 to standard, 830 X.400/84 When MIME Content-Types are Present elective 831 in the Messages", RFC 1496, August 1993. 833 [9] A. Costanzo: "Encoding Header Header for Non-standard 834 Internet Messages", RFC 1154, April 1990. 836 [10] A. Costanzo, D. Robinson: "Encoding Header Experimental 837 Header for Internet Messages", RFC 1505, 838 August 1993. 840 [11] N. Borenstein & N. Freed: "MIME (Multipurpose Draft 841 Internet Mail Extensions) Part One: Standard, 842 Mechanisms for Specifying and Describing the elective 843 Format of Internet Message Bodies", RFC 1521, 844 Sept 1993. 846 [12] H. Alvestrand: "Tags for the Identification Proposed 847 of Languages", RFC 1766, February 1995. standard, 848 elective 850 [13] J. Palme: "Electronic Mail", Artech House Non-standard 851 publishers, London-Boston January 1995. 853 [14] R. Troost, S. Dorner: "Communicating Experimental 854 Presentation Information in Internet 855 Messages: The Content-Disposition Header", 856 RFC 1806, June 1995. 858 [15] B. Kantor, P. Lapsley, "Network News Transfer Proposed 859 Protocol: "A Proposed Standard for the Stream- standard 860 Based Transmission of News", RFC 977, January 861 1986. 862 [16] 1848 PS S. Crocker, N. Freed, J. Galvin, Proposed 863 S. Murphy, "MIME Object Security Services", standard 864 RFC 1848, March 1995. 866 [17] J. Myers, M. Rose: The Content-MD5 Header Draft 867 Header, RFC 1864, October 1995. standard 869 [18] M. Horton, UUCP mail interchange format Not an offi- 870 standard, RFC 976, Januari 1986. cial IETF 871 standard, 872 but in 873 reality a de- 874 facto 875 standard for 876 Usenet News 878 [19] T. Berners-Lee, R. Headering, H. Frystyk: IETF draft 879 Hypertext Transfer Protocol -- HTTP/1.0, 880 draft-ietf-http-v10-spec-04.txt. 882 [20] G. Vaudreuil: Voice Profile for Internet Experimental 883 Mail, RFC 1911, February 1996. 885 [21] H. Spencer: News Article Format and Not even an 886 Transmission, June 1994, RFC, but 887 FTP://zoo.toronto.edu/pub/news.ps.Z still widely 888 FTP://zoo.toronto.edu/pub/news.txt.Z used and 889 partly 890 This document is often referenced under the almost a de- 891 name "son-of-RFC1036". facto 892 standard for 893 Usenet News 895 6. Author's address 897 Jacob Palme Phone: +46-8-16 16 67 898 Stockholm University/KTH Fax: +46-8-783 08 29 899 Electrum 230 E-mail: jpalme@dsv.su.se 900 S-164 40 Kista, Sweden 901 Appendix A: 902 Headers sorted by Internet RFC document in which they appear. 904 RFC 822 905 ------- 907 bcc 908 cc 909 Comments 910 Date 911 From 912 In-Reply-To 913 Keywords 914 Message-ID 915 Received 916 References 917 Reply-To 918 Resent- 919 Resent-bcc 920 Resent-cc 921 Resent-Date 922 Resent-From 923 Resent-From 924 Resent-Message-ID 925 Resent-Reply-To 926 Resent-To 927 Return-Path 928 Sender 929 Sender 930 Subject 931 To 933 RFC 976 934 ------- 936 "From " (followed by space, not colon (:") 938 RFC 1036 939 -------- 941 Approved 942 Control 943 Distribution 944 Expires 945 Followup-To 946 Lines 947 Newsgroups 948 Organization 949 Path 950 Summary 951 Xref 952 RFC 1049 953 -------- 955 Content-Type 957 RFC 1327 958 -------- 960 Alternate-recipient 961 Auto-Forwarded 962 Autoforwarded 963 Content-Identifier 964 Content-Return 965 Conversion 966 Conversion-With-Loss 967 Delivery-Date 968 Discarded-X400-IPMS-Extensions 969 Discarded-X400-MTS-Extensions 970 Disclose-Recipients 971 DL-Expansion-History 972 Expiry-Date 973 Generate-Delivery-Report 974 Importance 975 Incomplete-Copy 976 Language 977 Message-Type Delivery 978 Obsoletes 979 Original-Encoded-Information-Types 980 Prevent-NonDelivery-Report 981 Priority 982 Reply-By 983 Report 984 Sensitivity 986 RFC 1505 987 -------- 989 Encoding 991 RFC 1521 992 -------- 994 Content-Description 995 Content-ID 996 Content-Transfer-Encoding 997 Content-Type 998 MIME-Version 1000 RFC 1806 1001 -------- 1003 Content-Disposition 1004 RFC 1864 1005 -------- 1007 Content-MD5 1009 RFC 1911 1010 -------- 1012 Importance 1013 Sensitivity 1015 son-of-RFC1036 [21] 1016 ------------------- 1018 Also-Control 1019 Article-Names 1020 Article-Updates 1021 See-Also 1022 Supersedes 1024 Not Internet standard 1025 --------------------- 1027 Apparently-to 1028 Content-Base 1029 Content-Length 1030 Content-Location 1031 Content-SGML-Entity 1032 Encoding 1033 Errors-To 1034 Return-Receipt-To 1035 Fax 1036 "From " (not followed by ":") 1037 Telefax 1038 Fcc 1039 Mail-System-Version 1040 Mailer 1041 Organisation 1042 Originating-Client 1043 Phone 1044 Status 1045 Supersedes 1046 X400-Content-Return 1047 X-Mailer 1048 X-Newsreader 1049 Appendix B: 1050 Alphabetical index 1052 Section Heading-header 1053 ------- -------------- 1055 3.3 Also-Control 1056 3.6 See-Also 1057 3.3 Alternate-Recipient 1058 3.4 Apparently-To 1059 3.4 Approved 1060 3.6 Article-Names 1061 3.6 Article-Updates 1062 3.16 Auto-Forwarded 1063 3.4 bcc 1064 3.4 cc 1065 Client, see Originating-Client 1066 3.7 Comments 1067 3.6 Content-Base 1068 3.12 Content-Conversion 1069 3.7 Content-Description 1070 3.3 Content-Disposition 1071 3.6 Content-ID 1072 3.7 Content-Identifier 1073 3.10 Content-Language see also Language 1074 3.11 Content-Length 1075 3.6 Content-Location 1076 3.15 Content-MD5 1077 3.4 Content-Return 1078 3.13 Content-SGML-Entity 1079 3.13 Content-Transfer-Encoding 1080 3.13 Content-Type 1081 3.3 Control 1082 3.12 Conversion 1083 3.12 Conversion-With-Loss 1084 3.8 Date 1085 3.8 Delivery-Date 1086 Delivery-Report, see Generate-Delivery-Report, Prevent- 1087 Delivery-Report, Non-Delivery-Report, Content-Type 1088 Description, see Content-Description 1089 3.16 Discarded-X400-IPMS-Extensions 1090 3.16 Discarded-X400-MTS-Extensions 1091 3.3 Disclose-Recipients 1092 Disposition, see Content-Disposition 1093 3.4 Distribution 1094 3.2 DL-Expansion-History-Indication 1095 3.13 Encoding see also Content-Transfer-Encoding 1096 3.4 Errors-To 1097 3.8 Expires 1098 Extension see Discarded-X400-IPMS-Extensions, Discarded- 1099 X400-MTS-Extensions 1100 3.4 Fax 1101 3.16 Fcc 1102 3.4 Followup-To 1103 Forwarded, see Auto-Forwarded 1104 3.4 From 1105 3.4 Generate-Delivery-Report 1106 History, see DL-Expansion-History-Indication 1107 ID, see Content-ID and Message-ID 1108 Identifier, see Content-ID and Message-ID 1109 3.9 Importance 1110 3.6 In-Reply-To 1111 3.9 Incomplete-Copy 1112 3.7 Keywords 1113 3.10 Language see also Content-Language 1114 Length see Content-Length 1115 3.11 Lines 1116 3.4 Mail-System-Version see also X-mailer 1117 3.4 Mailer 1118 MD5 see Content-MD5 1119 3.6 Message-ID 1120 3.13 Message-Type 1121 3.3 MIME-Version 1122 3.4 Newsgroups 1123 Newsreader, see X-Newsreader 1124 3.6 Obsoletes 1125 3.7 Organisation 1126 3.7 Organization 1127 3.3 Original-Encoded-Information-Types 1128 3.4 Originating-Client 1129 3.2 Path 1130 3.4 Phone 1131 3.9 Precedence 1132 3.4 Prevent-NonDelivery-Report 1133 3.9 Priority 1134 3.2 Received 1135 Recipient, see To, cc, bcc, Alternate-Recipient, Disclose- 1136 Recipient 1137 3.6 References 1138 3.8 Reply-By 1139 3.4 Reply-To, see also In-Reply-To, References 1140 3.14 Resent- 1141 Return see also Content-Return 1142 3.2 Return-Path 1143 3.5 Return-Receipt-To 1144 3.4 Sender 1145 3.9 Sensitivity 1146 3.16 Status 1147 3.7 Subject 1148 3.7 Summary 1149 3.6 Supersedes 1150 3.4 Telefax 1151 3.4 To 1152 Transfer-Encoding see Content-Transfer-Encoding 1153 Type see Content-Type, Message-Type, Original-Encoded- 1154 Information-Types 1155 Version, see MIME-Version, X-Mailer 1156 3.4 X400-Content-Return 1157 3.4 X-Mailer see also Mail-System-Version 1158 3.4 X-Newsreader 1159 3.15 Xref