idnits 2.17.1 draft-ietf-mailext-mail-attributes-04.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-24) 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 18) being 59 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 293 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 (November 1996) is 10022 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '2' on line 673 looks like a reference -- Missing reference section? '3' on line 677 looks like a reference -- Missing reference section? '5' on line 695 looks like a reference -- Missing reference section? '7' on line 703 looks like a reference -- Missing reference section? '8' on line 707 looks like a reference -- Missing reference section? '11' on line 719 looks like a reference -- Missing reference section? '12' on line 725 looks like a reference -- Missing reference section? '14' on line 732 looks like a reference -- Missing reference section? '17' on line 745 looks like a reference -- Missing reference section? '16' on line 741 looks like a reference -- Missing reference section? '1' on line 670 looks like a reference -- Missing reference section? '18' on line 748 looks like a reference -- Missing reference section? '15' on line 737 looks like a reference -- Missing reference section? '19' on line 757 looks like a reference -- Missing reference section? '13' on line 729 looks like a reference -- Missing reference section? '4' on line 686 looks like a reference -- Missing reference section? '6' on line 699 looks like a reference -- Missing reference section? '9' on line 712 looks like a reference -- Missing reference section? '10' on line 715 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 21 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-04.txt Sweden 4 Category: Informational May 1996 5 Expires November 1996 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 and RFC 1864. A few commonly occurring headers which are not 39 defined in RFCs are also included. For each header, the memo gives a 40 short description and a reference to the RFC in which the header is 41 defined. 43 Table of contents 45 1. Introduction 47 2. Use of gatewaying headers 49 3. Table of headers 51 3.1 Phrases used in the tables 52 3.2 Trace information 53 3.3 Format and control information 54 3.4 Sender and recipient indication 55 3.5 Response control 56 3.6 Message identification and referral headers 57 3.7 Other textual headers 58 3.8 Headers containing dates and times 59 3.9 Quality information 60 3.10 Language information 61 3.11 Size information 62 3.12 Conversion control 63 3.13 Encoding information 64 3.14 Resent-headers 65 3.15 Security and reliability 66 3.16 Miscellaneous 68 4. Acknowledgments 70 5. References 72 6. Author's address 74 Appendix A: Headers sorted by Internet RFC document in which 75 they appear 77 Appendix B: Alphabetical index 78 1. Introduction 80 Many different Internet standards and RFCs define headers which 81 may occur on Internet Mail Messages and Network News Articles. The 82 intention of this document is to list all such headers in one 83 document as an aid to people developing message systems or interested 84 in Internet Mail standards. 86 The document contains all headers which the author has 87 found in the following Internet standards: , RFC 822 [2], 88 RFC 1036 [3], RFC 1123 [5], RFC 1327 [7], RFC 1496 [8], RFC 1521 [11], 89 RFC 1766 [12], RFC 1806 [14] and RFC 1864[17]. Note in particular that 90 heading attributes defined in PEM (RFC 1421-1424) and MOSS (RFC 1848 91 [16]) are not included. PEM and MOSS headers only appear inside the 92 body of a message, and thus are not headers in the RFC 822 sense. Mail 93 attributes in envelopes, i.e. attributes controlling the message 94 transport mechanism between mail and news servers, are not included. 95 This means that attributes from SMTP [1], UUCP [18] and NNTP [15] are 96 not covered either. Headings used only in HTTP [19] are not included 97 yet, but may be included in future version of this memo. A few 98 additional headers which often can be found in e-mail headings but are 99 not part of any Internet standard are also included. 101 For each header, the document gives a short description and 102 a reference to the Internet standard or RFC, in which they are defined. 104 The header names given here are spelled the same way as when they are 105 actually used. This is usually American but sometimes English spelling. 106 One header in particular, "Organisation/Organization", occurs in e-mail 107 headers sometimes with the English and other times with the American 108 spelling. 110 The following words are used in this memo with the meaning specified 111 below: 113 heading Formatted text at the top of a message, ended by a 114 blank line 116 header = heading One field in the heading, beginning with a field 117 field name, colon, and followed by the field value(s) 119 It is my intention to continue updating this document after its 120 publication as an RFC. The latest version, which may be more up-to-date 121 (but also less fully checked out) will be kept available for 122 downloading by anonymous FTP from URL 123 http://www.dsv.su.se/~jpalme/ietf-mail-attributes.pdf. 125 Please e-mail me (Jacob Palme ) if you have noted 126 headers which should be included in this memo but are not. 128 2. Use of gatewaying headers 130 RFC 1327 defines a number of new headers in Internet mail, which 131 are defined to map headers which X.400 has but which were 132 previously not standardized in Internet mail. The fact that a 133 header occurs in RFC 1327 indicates that it is recommended for 134 use in gatewaying messages between X.400 and Internet mail, but 135 does not mean that the header is recommended for messages wholly 136 within Internet mail. Some of these headers may eventually see 137 widespread implementation and use in Internet mail, but at the time of 138 this writing (May 1996) they are not widely implemented or used. 140 Headers defined in RFC 1036 for use in Usenet News sometimes appear 141 in mail messages, either because the messages have been gatewayed 142 from Usenet News to e-mail, or because the messages were written in 143 combined clients supporting both e-mail and Usenet News in the same 144 client. These headers are not standardized for use in Internet e-mail 145 and should be handled with caution by e-mail agents. 147 3. Table of headers 149 3.1 Phrases used in the tables 151 "not for general Used to mark headers which are defined in RFC 152 usage" 1327 for use in messages from or to Internet 153 mail/X.400 gateways. These headers have not 154 been standardized for general usage in the 155 exchange of messages between Internet mail- 156 based systems. 158 "not standardized Used to mark headers defined only in RFC 1036 159 for use in e-mail" for use in Usenet News. These headers have no 160 standard meaning when appearing in e-mail, 161 some of them may even be used in different 162 ways by different software. When appearing in 163 e-mail, they should be handled with caution. 164 Note that RFC 1036, although generally used as 165 a standard for Usenet News, is not an accepted 166 IETF standard or on the IETF standards track. 168 "non-standard" This header is not specified in any of 169 referenced RFCs which define Internet 170 protocols, including Internet Standards, draft 171 standards or proposed standards. The header 172 appears here because it often appears in e- 173 mail or Usenet News. Usage of these headers is 174 not in general recommended. 176 "discouraged" This header, which is non-standard, is known 177 to create problems and should not be 178 generated. Handling of such headers in 179 incoming mail should be done with great 180 caution. 182 "controversial" The meaning and usage of this header is 183 controversial, i.e. different implementors 184 have chosen to implement the header in 185 different ways. Because of this, such headers 186 should be handled with caution and 187 understanding of the different possible 188 interpretations. 190 "experimental" This header is used for newly defined headers, 191 which are to be tried out before entering the 192 IETF standards track. These should only be 193 used if both communicating parties agree on 194 using them. In practice, some experimental 195 protocols become de-facto-standards before 196 they are made into IETF standards. 198 3.2 Trace information 199 Used to convey the information Return-Path: RFC 821, 200 from the MAIL FROM envelope RFC 1123: 5.2.13. 201 attribute in final delivery, when 202 the message leaves the SMTP 203 environment in which "MAIL FROM" 204 is used. 206 Trace of MTAs which a message has Received: RFC 822: 4.3.2, 207 passed. RFC 1123: 5.2.8. 209 List of MTAs passed. Path: RFC 1036: 2.2.6, 210 only in Usenet 211 News, not in e- 212 mail. 214 Trace of distribution lists DL-Expansion- RFC 1327, not for 215 passed. History- general usage. 216 Indication: 218 3.3 Format and control 219 information 221 An indicator that this message is MIME-Version: RFC 1521: 3. 222 formatted according to the MIME 223 standard, and an indication of 224 which version of MIME is 225 utilized. 227 Special Usenet News actions. Control: RFC 1036: 2.1.6, 228 only in Usenet 229 News, not in e- 230 mail. 232 Which body part types occur in Original- RFC 1327, not for 233 this message. Encoded- general usage. 234 Information- 235 Types: 237 Controls whether this message may Alternate- RFC 1327, not for 238 be forwarded to alternate Recipient: general usage. 239 recipients such as a postmaster 240 if delivery is not possible to 241 the intended recipient. Default: 242 Allowed. 244 Whether recipients are to be told Disclose- RFC 1327, not for 245 the names of other recipients of Recipients: general usage. 246 the same message. This is 247 primarily an X.400 facility. In 248 X.400, this is an envelope 249 attribute and refers to 250 disclosure of the envelope 251 recipient list. Disclosure of 252 other recipients is in Internet 253 mail done via the To:, cc: and 254 bcc: headers. 256 Whether a MIME body part is to be Content- RFC 1806, 257 shown inline or is an attachment; Disposition: experimental 258 can also indicate a suggested 259 filename for use when saving an 260 attachment to a file. 262 3.4 Sender and recipient 263 indication 265 Authors or persons taking From: RFC 822: 4.4.1, 266 responsibility for the message. RFC 1123: 5.2.15- 267 16, 5.3.7, 268 RFC 1036 2.1.1 270 Name of the moderator of the Approved: RFC 1036: 2.2.11, 271 newsgroup to which this message not standardized 272 is sent; necessary on an article for use in e-mail. 273 sent to a moderated newsgroup to 274 allow its distribution to the 275 newsgroup members. Also used on 276 certain control messages, which 277 are only performed if they are 278 marked as Approved. 280 The person or agent submitting Sender: RFC 822: 4.4.2, 281 the message to the network, if RFC 1123: 5.2.15- 282 other than shown by the From: 16, 5.3.7. 283 header. 285 Primary recipients. To: RFC 822: 4.5.1, 286 RFC 1123: 5.2.15- 287 16, 5.3.7. 289 Secondary, informational cc: RFC 822: 4.5.2, 290 recipients. (cc = Carbon Copy) RFC 1123. 5.2.15- 291 16, 5.3.7. 293 Recipients not to be disclosed to bcc: RFC 822: 4.5.3, 294 other recipients. (bcc = Blind RFC 1123: 5.2.15- 295 Carbon Copy). 16, 5.3.7. 297 In Usenet News: group(s) to which Newsgroups: RFC 1036: 2.1.3, 298 this article was posted. not standardized 299 Some systems provide this header and controversial 300 also in e-mail although it is not for use in e-mail. 301 standardized there. 302 Unfortunately, the header can 303 appear in e-mail with two 304 different and contradictory 305 meanings: 306 (a) Indicates the newsgroup 307 recipient of a message sent to 308 both e-mail and Usenet News 309 recipients. 310 (b) In a personally addressed 311 reply to a message in a news- 312 group, indicate the newsgroup in 313 which this discussion originated. 315 Inserted by Sendmail when there Apparently- Non-standard, 316 is no "To:" recipient in the To: discouraged, 317 original message, listing mentioned in 318 recipients derived from the RFC 1211. 319 envelope into the message 320 heading. This behavior is not 321 quite proper, MTAs should not 322 modify headings (except inserting 323 Received lines), and it can in 324 some cases cause Bcc recipients 325 to be wrongly divulged to non-Bcc 326 recipients. 328 Geographical or organizational Distribution: RFC 1036: 2.2.7, 329 limitation on where this message not standardized 330 can be distributed. for use in e-mail. 332 Fax number of the originator. Fax:, Non-standard. 333 Telefax: 335 Phone number of the originator. Phone: Non-standard. 337 Information about the client Mail-System- Non-standard. 338 software of the originator. Version:, 339 Mailer:, 340 Originating- 341 Client:, X- 342 Mailer, X- 343 Newsreader 345 3.5 Response control 347 This header is meant to indicate Reply-To: RFC 822: 4.4.3, 348 where the sender wants replies to RFC 1036: 2.2.1 349 go. Unfortunately, this is controversial. 350 ambiguous, since there are 351 different kinds of replies, which 352 the sender may wish to go to 353 different addresses. In 354 particular, there are personal 355 replies intended for only one 356 person, and group replies, 357 intended for the whole group of 358 people who read the replied-to 359 message (often a mailing list). 361 Some mail systems use this header 362 to indicate a better form of the 363 e-mail address of the sender. 364 Some mailing list expanders puts 365 the name of the list in this 366 header. These practices are 367 controversial. The personal 368 opinion of the author of this RFC 369 is that this header should be 370 avoided except in special cases, 371 but this is a personal opinion 372 not shared by all specialists in 373 the area. 375 Used in Usenet News to indicate Followup-To: RFC 1036: 2.2.3, 376 that future discussions (=follow- not standardized 377 up) on an article should go to a for use in e-mail. 378 different set of newsgroups than 379 the replied-to article. The most 380 common usage is when an article 381 is posted to several newsgroups, 382 and further discussions is to 383 take place in only one of them. 385 In e-mail, this header is used in 386 a message which is sent to both e- 387 mail and Usenet News, to show 388 where follow-up in Usenet news is 389 wanted. The header does not say 390 anything about where follow-up in 391 e-mail is to be sent. 393 Note that the value of this 394 header must always be one or more 395 newsgroup names, never e-mail 396 addresses. 398 Address to which notifications Errors-To:, Non-standard, 399 are to be sent and a request to Return- discouraged. 400 get delivery notifications. Receipt-To: 401 Internet standards recommend, 402 however, the use of RCPT TO and 403 Return-Path, not Errors-To, for 404 where delivery notifications are 405 to be sent. 407 Whether non-delivery report is Prevent- RFC 1327, not for 408 wanted at delivery error. Default NonDelivery- general usage. 409 is to want such a report. Report: 411 Whether a delivery report is Generate- RFC 1327, not for 412 wanted at successful delivery. Delivery- general usage. 413 Default is not to generate such a Report: 414 report. 416 Indicates whether the content of Content- RFC 1327, not for 417 a message is to be returned with Return: general usage. 418 non-delivery notifications. 420 3.6 Message identification and 421 referral headers 423 Unique ID of this message. Message-ID: RFC 822: 4.6.1 424 RFC 1036: 2.1.5. 426 Unique ID of one body part of the Content-ID: RFC 1521: 6.1. 427 content of a message. 429 Reference to message which this In-Reply-To: RFC 822: 4.6.2. 430 message is a reply to. 432 Reference to other related References: RFC 822: 4.6.3 433 messages. RFC 1036: 2.1.5. 435 Reference to previous message Obsoletes: RFC 1327, not for 436 being corrected and replaced. general usage. 437 Compare to "Supersedes:" below. 439 Commonly used in Usenet News in Supersedes: Non-standard. 440 similar ways to the "Obsoletes" 441 header described above. In Usenet 442 News, however, Supersedes causes 443 a full deletion of the replaced 444 message in the server, while 445 Obsoletes is implemented in the 446 client and often does not remove 447 the old version of the text. 449 3.7 Other textual headers 451 Search keys for data base Keywords: RFC 822: 4.7.1 452 retrieval. RFC 1036: 2.2.9. 454 Title, heading, subject. Often Subject: RFC 822: 4.7.1 455 used as thread indicator for RFC 1036: 2.1.4. 456 messages replying to or 457 commenting on other messages. 459 Comments on a message. Comments: RFC 822: 4.7.2. 461 Description of a particular body Content- RFC 1521: 6.2. 462 part of a message. Description: 464 Organization to which the sender Organization: RFC 1036: 2.2.8, 465 of this message belongs. not standardized 466 for use in e-mail. 468 See Organization above. Organisation: Non-standard. 470 Short text describing a longer Summary: RFC 1036: 2.2.10, 471 message. Warning: Some mail not standardized 472 systems will not display this for use in e-mail, 473 text to the recipient. Because of discouraged. 474 this, do not use this header for 475 text which you want to ensure 476 that the recipient gets. 478 A text string which identifies Content- RFC 1327, not for 479 the content of a message. Identifier: general usage. 481 3.8 Headers containing dates and 482 times 484 The time when a message was Delivery- RFC 1327, not for 485 delivered to its recipient. Date: general usage. 487 In Internet, the date when a Date: RFC 822: 5.1, 488 message was written, in X.400, RFC 1123: 5.2.14 489 the time a message was submitted. RFC 1036: 2.1.2. 490 Some Internet mail systems also 491 use the date when the message was 492 submitted. 494 A suggested expiration date. Can Expires: RFC 1036: 2.2.4, 495 be used both to limit the time of not standardized 496 an article which is not for use in e-mail. 497 meaningful after a certain date, 498 and to extend the storage of 499 important articles. 501 Time at which a message loses its Expiry-Date: RFC 1327, not for 502 validity. general usage. 504 Latest time at which a reply is Reply-By: RFC 1327, not for 505 requested (not demanded). general usage. 507 3.9 Quality information 509 Can be "normal", "urgent" or "non- Priority: RFC 1327, not for 510 urgent" and can influence general usage. 511 transmission speed and delivery. 513 Sometimes used as a priority Precedence: Non-standard, 514 value which can influence controversial, 515 transmission speed and delivery. discouraged. 516 Common values are "bulk" and 517 "first-class". Other uses is to 518 control automatic replies and to 519 control return-of-content 520 facilities, and to stop mailing 521 list loops. 523 A hint from the originator to the Importance: RFC 1327, not for 524 recipients about how important a general usage. 525 message is. Values: High, normal 526 or low. Not used to control 527 transmission speed. 529 How sensitive it is to disclose Sensitivity: RFC 1327, not for 530 this message to other people than general usage. 531 the specified recipients. Values: 532 Personal, private, company 533 confidential. The absence of this 534 header in messages gatewayed from 535 X.400 indicates that the message 536 is not sensitive. 538 Body parts are missing. Incomplete- RFC 1327, not for 539 Copy: general usage. 541 3.10 Language information 543 Can include a code for the Language: RFC 1327, not for 544 natural language used in a general usage. 545 message, e.g. "en" for English. 547 Can include a code for the Content- RFC 1766, proposed 548 natural language used in a Language: standard. 549 message, e.g. "en" for English. 551 3.11 Size information 553 Inserted by certain mailers to Content- Non-standard, 554 indicate the size in bytes of the Length: discouraged. 555 message text. This is part of a 556 format some mailers use when 557 showing a message to its users, 558 and this header should not be 559 used when sending a message 560 through the net. The use of this 561 header in transmission of a 562 message can cause several 563 robustness and interoperability 564 problems. 566 Size of the message. Lines: RFC 1036: 2.2.12, 567 not standardized 568 for use in e-mail. 570 3.12 Conversion control 572 The body of this message may not Conversion: RFC 1327, not for 573 be converted from one character general usage. 574 set to another. Values: 575 Prohibited and allowed. 577 Non-standard variant of Content- Non-standard. 578 Conversion: with the same values. Conversion: 580 The body of this message may not Conversion- RFC 1327, not for 581 be converted from one character With-Loss: general usage. 582 set to another if information 583 will be lost. Values: Prohibited 584 and allowed. 586 3.13 Encoding information 588 Format of content (character set Content-Type: RFC 1049, 589 etc.) Note that the values for RFC 1123: 5.2.13, 590 this header are defined in RFC 1521: 4. 591 different ways in RFC 1049 and in 592 MIME (RFC 1521), look for the 593 "MIME-version" header to 594 understand if Content-Type is to 595 be interpreted according to RFC 596 1049 or according to MIME. The 597 MIME definition should be used in 598 generating mail. 600 Coding method used in a MIME Content- RFC 1521: 5. 601 message body. Transfer- 602 Encoding: 604 Only used with the value Message-Type: RFC 1327, not for 605 "Delivery Report" to indicates general usage. 606 that this is a delivery report 607 gatewayed from X.400. 609 Used in several different ways by Encoding: RFC 1154, 610 different mail systems. Some use RFC 1505, 611 it for a kind of content-type experimental. 612 information, some for encoding 613 and length information, some for 614 a kind of boundary information, 615 some in other ways. 617 3.14 Resent-headers 619 When manually forwarding a Resent-Reply- RFC 822: C.3.3. 620 message, headers referring to the To:, 621 forwarding, not to the original Resent-From:, 622 message. Note: MIME specifies Resent- 623 another way of resending Sender:, 624 messages, using the "Message" Resent-From:, 625 Content-Type. Resent-Date:, 626 Resent-To:, 627 Resent-cc:, 628 Resent-bcc:, 629 Resent- 630 Message-ID: 632 3.15 Security and reliability 634 Checksum of content to ensure Content-MD5: RFC 1864, proposed 635 that it has not been modified. standard. 637 3.16 Miscellaneous 639 Name of file in which a copy of Fcc: Non-standard. 640 this message is stored. 642 Has been automatically forwarded. Auto- RFC 1327, not for 643 Forwarded: general usage. 645 Can be used in Internet mail to Discarded- RFC 1327, not for 646 indicate X.400 IPM extensions X400-IPMS- general usage. 647 which could not be mapped to Extensions: 648 Internet mail format. 650 Can be used in Internet mail to Discarded- RFC 1327, not for 651 indicate X.400 MTS extensions X400-MTS- general usage. 652 which could not be mapped to Extensions: 653 Internet mail format. 655 4. Acknowledgments 657 Harald Tveit Alvestrand, Ned Freed, Olle J�rnefors, Keith Moore, Nick 658 Smith and several other people have helped me with compiling this list. 659 I especially thank Ned Freed and Olle J�rnefors for their thorough 660 review and many helpful suggestions for improvements. I alone take 661 responsibility for any errors which may still be in the list. 663 An earlier version of this list has been published as part of [13]. 665 5. References 667 Ref. Author, title IETF status 668 (May 1996) 669 ----- --------------------------------------------- ----------- 670 [1] J. Postel: "Simple Mail Transfer Protocol", Standard, 671 STD 10, RFC 821, August 1982. Recommended 673 [2] D. Crocker: "Standard for the format of ARPA Standard, 674 Internet text messages." STD 11, RFC 822, Recommended 675 August 1982. 677 [3] M.R. Horton, R. Adams: "Standard for Not an offi- 678 interchange of USENET messages", RFC 1036, cial IETF 679 December 1987. standard, 680 but in 681 reality a de- 682 facto 683 standard for 684 Usenet News 686 [4] M. Sirbu: "A Content-Type header header for Standard, 687 internet messages", RFC 1049, March 1988. Recommended, 688 but can in 689 the future 690 be expected 691 to be 692 replaced by 693 MIME 695 [5] R. Braden (editor): "Requirements for Standard, 696 Internet Hosts -- Application and Support", Required 697 STD-3, RFC 1123, October 1989. 699 [6] D. Robinson, R. Ullman: "Encoding Header Non-standard 700 Header for Internet Messages", RFC 1154, 701 April 1990. 703 [7] S. Hardcastle-Kille: "Mapping between Proposed 704 X.400(1988) / ISO 10021 and RFC 822", RFC standard, 705 1327 May 1992. elective 707 [8] H. Alvestrand & J. Romaguera: "Rules for Proposed 708 Downgrading Messages from X.400/88 to standard, 709 X.400/84 When MIME Content-Types are Present elective 710 in the Messages", RFC 1496, August 1993. 712 [9] A. Costanzo: "Encoding Header Header for Non-standard 713 Internet Messages", RFC 1154, April 1990. 715 [10] A. Costanzo, D. Robinson: "Encoding Header Experimental 716 Header for Internet Messages", RFC 1505, 717 August 1993. 719 [11] N. Borenstein & N. Freed: "MIME (Multipurpose Draft 720 Internet Mail Extensions) Part One: Standard, 721 Mechanisms for Specifying and Describing the elective 722 Format of Internet Message Bodies", RFC 1521, 723 Sept 1993. 725 [12] H. Alvestrand: "Tags for the Identification Proposed 726 of Languages", RFC 1766, February 1995. standard, 727 elective 729 [13] J. Palme: "Electronic Mail", Artech House Non-standard 730 publishers, London-Boston January 1995. 732 [14] R. Troost, S. Dorner: "Communicating Experimental 733 Presentation Information in Internet 734 Messages: The Content-Disposition Header", 735 RFC 1806, June 1995. 737 [15] B. Kantor, P. Lapsley, "Network News Transfer Proposed 738 Protocol: "A Proposed Standard for the Stream- standard 739 Based Transmission of News", RFC 977, January 740 1986. 741 [16] 1848 PS S. Crocker, N. Freed, J. Galvin, Proposed 742 S. Murphy, "MIME Object Security Services", standard 743 RFC 1848, March 1995. 745 [17] J. Myers, M. Rose: The Content-MD5 Header Draft 746 Header, RFC 1864, October 1995. standard 748 [18] M. Horton, UUCP mail interchange format Not an offi- 749 standard, RFC 976, Januari 1986. cial IETF 750 standard, 751 but in 752 reality a de- 753 facto 754 standard for 755 Usenet News 757 [19] T. Berners-Lee, R. Headering, H. Frystyk: IETF draft 758 Hypertext Transfer Protocol -- HTTP/1.0, 759 draft-ietf-http-v10-spec-04.txt. 761 6. Author's address 763 Jacob Palme Phone: +46-8-16 16 67 764 Stockholm University/KTH Fax: +46-8-783 08 29 765 Electrum 230 E-mail: jpalme@dsv.su.se 766 S-164 40 Kista, Sweden 768 Appendix A: 769 Headers sorted by Internet RFC document in which they appear. 771 RFC 822 772 ------- 774 bcc 775 cc 776 Comments 777 Date 778 From 779 In-Reply-To 780 Keywords 781 Message-ID 782 Received 783 References 784 Reply-To 785 Resent- 786 Resent-bcc 787 Resent-cc 788 Resent-Date 789 Resent-From 790 Resent-From 791 Resent-Message-ID 792 Resent-Reply-To 793 Resent-To 794 Return-Path 795 Sender 796 Sender 797 Subject 798 To 799 RFC 1036 800 -------- 802 Approved 803 Control 804 Distribution 805 Expires 806 Followup-To 807 Lines 808 Newsgroups 809 Organization 810 Path 811 Summary 813 RFC 1049 814 -------- 816 Content-Type 818 RFC 1327 819 -------- 821 Alternate-recipient 822 Auto-Forwarded 823 Autoforwarded 824 Content-Identifier 825 Content-Return 826 Conversion 827 Conversion-With-Loss 828 Delivery-Date 829 Discarded-X400-IPMS-Extensions 830 Discarded-X400-MTS-Extensions 831 Disclose-Recipients 832 DL-Expansion-History 833 Expiry-Date 834 Generate-Delivery-Report 835 Importance 836 Incomplete-Copy 837 Language 838 Message-Type Delivery 839 Obsoletes 840 Original-Encoded-Information-Types 841 Prevent-NonDelivery-Report 842 Priority 843 Reply-By 844 Report 845 Sensitivity 847 RFC 1505 848 -------- 850 Encoding 851 RFC 1521 852 -------- 854 Content-Description 855 Content-ID 856 Content-Transfer-Encoding 857 Content-Type 858 MIME-Version 860 RFC 1806 861 -------- 863 Content-Disposition 865 RFC 1864 866 -------- 868 Content-MD5 870 Not Internet standard 871 --------------------- 873 Apparently-to 874 Content-length 875 Encoding 876 Errors-To 877 Return-Receipt-To 878 Fax 879 Telefax 880 Fcc 881 Mail-System-Version 882 Mailer 883 Organisation 884 Originating-Client 885 Phone 886 Supersedes 887 X-Mailer 888 X-Newsreader 889 Appendix B: 890 Alphabetical index 892 Section Heading-header 893 ------- -------------- 895 3.3 Alternate-Recipient 896 3.4 Apparently-To 897 3.4 Approved 898 3.16 Auto-Forwarded 899 3.4 bcc 900 3.4 cc 901 Client, see Originating-Client 902 3.7 Comments 903 3.12 Content-Conversion 904 3.7 Content-Description 905 3.3 Content-Disposition 906 3.6 Content-ID 907 3.7 Content-Identifier 908 3.10 Content-Language see also Language 909 3.11 Content-Length 910 3.15 Content-MD5 911 3.4 Content-Return 912 3.13 Content-Transfer-Encoding 913 3.13 Content-Type 914 3.3 Control 915 3.12 Conversion 916 3.12 Conversion-With-Loss 917 3.8 Date 918 3.8 Delivery-Date 919 Delivery-Report, see Generate-Delivery-Report, Prevent- 920 Delivery-Report, Non-Delivery-Report, Content-Type 921 Description, see Content-Description 922 3.16 Discarded-X400-IPMS-Extensions 923 3.16 Discarded-X400-MTS-Extensions 924 3.3 Disclose-Recipients 925 Disposition, see Content-Disposition 926 3.4 Distribution 927 3.2 DL-Expansion-History-Indication 928 3.13 Encoding see also Content-Transfer-Encoding 929 3.4 Errors-To 930 3.8 Expires 931 Extension see Discarded-X400-IPMS-Extensions, Discarded- 932 X400-MTS-Extensions 933 3.4 Fax 934 3.16 Fcc 935 3.4 Followup-To 936 Forwarded, see Auto-Forwarded 937 3.4 From 938 3.4 Generate-Delivery-Report 939 History, see DL-Expansion-History-Indication 940 ID, see Content-ID and Message-ID 941 Identifier, see Content-ID and Message-ID 943 3.9 Importance 944 3.6 In-Reply-To 945 3.9 Incomplete-Copy 946 3.7 Keywords 947 3.10 Language see also Content-Language 948 Length see Content-Length 949 3.11 Lines 950 3.4 Mail-System-Version see also X-mailer 951 3.4 Mailer 952 MD5 see Content-MD5 953 3.6 Message-ID 954 3.13 Message-Type 955 3.3 MIME-Version 956 3.4 Newsgroups 957 Newsreader, see X-Newsreader 958 3.6 Obsoletes 959 3.7 Organisation 960 3.7 Organization 961 3.3 Original-Encoded-Information-Types 962 3.4 Originating-Client 963 3.2 Path 964 3.4 Phone 965 3.9 Precedence 966 3.4 Prevent-NonDelivery-Report 967 3.9 Priority 968 3.2 Received 969 Recipient, see To, cc, bcc, Alternate-Recipient, Disclose- 970 Recipient 971 3.6 References 972 3.8 Reply-By 973 3.4 Reply-To, see also In-Reply-To, References 974 3.14 Resent- 975 Return see also Content-Return 976 3.2 Return-Path 977 3.5 Return-Receipt-To 978 3.4 Sender 979 3.9 Sensitivity 980 3.7 Subject 981 3.7 Summary 982 3.6 Supersedes 983 3.4 Telefax 984 3.4 To 985 Transfer-Encoding see Content-Transfer-Encoding 986 Type see Content-Type, Message-Type, Original-Encoded- 987 Information-Types 988 Version, see MIME-Version, X-Mailer 989 3.4 X-Mailer see also Mail-System-Version 990 3.4 X-Newsreader