idnits 2.17.1 draft-ietf-drums-MHRegistry-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. 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. ** Bad filename characters: the document name given in the document, 'draft-ietf-drums-MHRegistry-00', contains other characters than digits, lowercase letters and dash. == There is 1 instance of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 849 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 99 has weird spacing: '... header name ...' == Line 425 has weird spacing: '...ecurity sta...' == Line 475 has weird spacing: '...-Contro son-o...' == Line 490 has weird spacing: '...cle-Nam son-o...' == Line 494 has weird spacing: '...cle-Upd son-o...' == (6 more instances...) -- 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 (August 1997) is 9750 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '2' is mentioned on line 205, but not defined == Missing Reference: '22' is mentioned on line 783, but not defined == Unused Reference: '1' is defined on line 354, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 381, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 385, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 395, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 402, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 408, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 415, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 420, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 424, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 428, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 431, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 443, but no explicit reference was found in the text ** Obsolete normative reference: RFC 821 (ref. '1') (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 1036 (ref. '3') (Obsoleted by RFC 5536, RFC 5537) ** Obsolete normative reference: RFC 1154 (ref. '6') (Obsoleted by RFC 1505) ** Obsolete normative reference: RFC 822 (ref. '7') (Obsoleted by RFC 2822) -- Duplicate reference: RFC1154, mentioned in '9', was also mentioned in '6'. ** Obsolete normative reference: RFC 1154 (ref. '9') (Obsoleted by RFC 1505) ** Obsolete normative reference: RFC 1521 (ref. '11') (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) ** Obsolete normative reference: RFC 1766 (ref. '12') (Obsoleted by RFC 3066, RFC 3282) ** Obsolete normative reference: RFC 1806 (ref. '14') (Obsoleted by RFC 2183) ** Obsolete normative reference: RFC 977 (ref. '15') (Obsoleted by RFC 3977) ** Obsolete normative reference: RFC 1911 (ref. '20') (Obsoleted by RFC 2421, RFC 2422, RFC 2423) -- Duplicate reference: RFC1036, mentioned in '21', was also mentioned in '3'. ** Obsolete normative reference: RFC 1036 (ref. '21') (Obsoleted by RFC 5536, RFC 5537) Summary: 20 errors (**), 0 flaws (~~), 22 warnings (==), 4 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, Sweden 3 draft-ietf-drums-MHRegistry-00.txt January 1997 4 Category: Informational Expires August 1997 6 Mail Header Registration Procedure 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its 12 areas, and its working groups. Note that other groups may also 13 distribute working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other 17 documents at any time. It is inappropriate to use Internet- 18 Drafts as reference material or to cite them other than as 19 ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check 22 the ``1id-abstracts.txt'' listing contained in the Internet- 23 Drafts Shadow Directories on ftp.is.co.za (Africa), 24 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), 25 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 27 This memo provides information for the Internet community. This 28 memo does not specify an Internet standard of any kind, since 29 this document is mainly a compilation of information taken from 30 other RFCs.. Distribution of this memo is unlimited. 32 Abstract 34 Various IETF standards and e-mail software products use various 35 e-mail header fields. This memo specifies a procedure for the 36 registration of e-mail header field names, to reduce the risk that 37 two different mail products use the same header name in different 38 ways. A proposed initial content of the header name registry at 39 start-up is specifed in an appendix to this ietf-draft. 41 Table of contents 43 1. Introduction 44 2. Which Headers are Registered 45 3. Who can Register a Header Name 46 4. Registration Procedure 47 4.1 Present the Request for Registration to the 48 Community 49 4.2 Submit the Header name to the IANA for 50 Registration 51 5. Clarifications On Specific Issues 52 5.1 E-mail Requirements for a Limited Number of 53 Headers 54 5.2 Header Status 55 5.3 Requirements for a Published Specification 56 5.4 Identification of Security Considerations 57 5.5 Recommendations and Standards Status 58 6. Security Considerations 59 7. Acknowledgments 60 8. References 61 9. Author's address 62 10. Appendix: Proposed initial content of the IETF header 63 name registry 65 Temporary comment (not to be included in the published RFC) 67 The first version is based mainly on two previous documents: 68 RFC 1590: Media registration 69 draft-ietf-mailext-mail-attributes-07.txt 71 This version will need more discussion on at least the following 72 points: 73 - Should every header get its own OID? Would this make conversion 74 of Internet e-mail headers to X.400 eaier? 75 - How much explanation should the header registry contain for each 76 header? 77 - Which are the allowed values of the status field in the 78 registry? 80 Differences between draft-palme-MHRegistry-00.txt and this revised 81 version draft-ietf-drums-MHRegistry-00.txt: 83 Two non-standard headers have been added in the appendix, 84 "For-Comment" and "For-Handling". They are variants of "To:" which 85 indicate what action this recipient is asked to perform when 86 receiving this message. 88 1. Introduction 90 Many different Internet standards, other RFCs and e-mail software 91 products define headers which may occur on Internet mail messages 92 and/or Usenet News articles. There is an obvious risk that the 93 same header name is used in different ways by different software 94 products. 96 The solution proposed in RFC 822, to allow header names beginning 97 with "X-" for non-standard header names has several drawbacks. One 98 is that it does not preclude two different products using the same 99 "X-" header name with different semantic meaning. Another is that 100 if an "X-" header gets popular and much used, and is to become a 101 standard, there is a problem with removing the "X-" in front of an 102 already much used header. 104 Because of this, an IANA registry for e-mail and Usenet News 105 header field names is needed. 107 The following words are used in this memo with the meaning 108 specified below: 110 heading Formatted text at the top of a message, ended 111 by a blank line 113 header = heading One field in the heading, beginning with a 114 field header name, colon, and followed by the field 115 value(s) 117 2. Which Headers are Registered 119 The header name registry can contain headers from the following 120 sources: 122 - Internet standards 123 - RFCs which are not Internet standards 124 - Non-Internet standards 125 - Other commonly used headers 126 - Sometimes used headers whose use is discouraged. The use of a 127 header 128 name may be discouraged because it is badly defined, ambigous or 129 used 130 in different ways by different software. The purpose of 131 registering 132 discouraged headers is to avoid their use in their present or 133 any 134 other future semantic meaning. 136 The registry is intended to contain headers used in messaging 137 (e-mail, Usenet News, etc.) but not HTTP-only headers. 139 3. Who can Register a Header Name 141 Header names from Internet standards are registered by IETF 142 together with the standard specifying the header. 144 Headers in other RFCs are registered when the RFCs are published. 146 Anyone can propose the registry of additional headers, but such 147 headers should be approved by the IETF application area managers 148 before accepted in the registry. The procedure described in this 149 memo is followed by the IANA for review and approval of new e-mail 150 headers. This is not a formal standards process, but rather an 151 administrative procedure intended to allow community comment and 152 sanity checking without excessive time delay. 154 4. Registration Procedure 156 4.1 Present the Request for Registration to the Community 158 Send a proposed header to the "mail-headers@segate.sunet.se" 159 mailing list. This mailing list has been established for the sole 160 purpose of reviewing proposed e-mail headers. You can subscribe to 161 the list by sending a message to listserv@segate.sunet.se 162 containing in the text a line with 163 "subscribe mail-headers " followed by our name (not your e-mail 164 address), and unsubscribe with a message "unsubscribe 165 mail-headers". 167 Archives of this list are available 168 by anonymous FTP from 169 ftp://segate.sunet.se/lists/mail-headers/ 171 by HTTP from 172 http://segate.sunet.se/archives/mail-headers.html 174 by E-MAIL 175 send a message to 176 LISTSERV@SEGATE.SUNET.SE with the text "INDEX mail-headers" 177 to get a list of the archive files, and then a new message 178 "GET " to retrieve the archive files. 180 The FTP and E-MAIL archives are best if you want to retrieval 181 all messages during a month or more, while the HTTP archives 182 are better if you want to browse and find particular messages 183 to download. 185 The intent of the public posting is to solicit comments and 186 feedback on the choice of header name, the unambiguity of the 187 references with respect to versions and external profiling 188 information, the choice of which OIDs to use, and a review of the 189 security considerations section. It should be noted that the 190 proposed header name does not need to make sense for every 191 possible application. If the header name is intended for a limited 192 or specific use, this should be noted in the submission. 194 4.2 Submit the Header name to the IANA for Registration 196 After at least two weeks, submit the proposed header to the IANA 197 for registration. The request and supporting documentation should 198 be sent to "iana@isi.edu". Provided a reasonable review period has 199 elapsed, the IANA will register the header, assign an OID under 200 the IANA branch, and make the header registration available to the 201 community. 203 The header registrations will be posted in the anonymous FTP 204 directory "ftp.isi.edu:in-notes/mail-headers" and the header will 205 be listed in the periodically issued "Assigned Numbers" RFC [2]. 206 The header description may be published as an Informational RFC by 207 sending it to "rfc-editor@isi.edu" (please follow the instructions 208 to RFC authors [3]). 210 5. Clarifications On Specific Issues 212 5.1 E-mail Requirements for a Limited Number of Headers 214 Issue: In the asynchronous mail environment, where information on 215 the capabilities of the remote mail agent is not available to the 216 sender, maximum interoperability is attained by restricting the 217 number of headers used to those "common" headers expected to be 218 widely implemented. This was asserted as a reason to limit the 219 number of possible headers and resulted in a registration process 220 with a significant hurdle and delay for those registering headers. 222 5.2 Header Status 224 Any header in the registry should be marked with a status, which 225 has one of the values specified below: 227 IETF standard. Specified in an IETF standard. 229 IETF draft standard. Specified in an IETF draft standard. 231 IETF proposed Specified in an IETF proposed standard. 232 standard. 234 IETF experimental Specified in an IETF experimental 235 standard. standard. 237 X.400. Used to mark headers which are defined 238 in RFC 1327 for use in messages from or 239 to Internet mail/X.400 gateways, and 240 which have not been standardized for 241 general usage in the exchange of 242 messages between Internet mail-based 243 systems. 245 Usenet News only, De facto standard in Usenet News, may 246 not in e-mail. occur in messages gatewayed from Usenet 247 News to e-mail, no defined meaning in 248 e-mail. 250 Non-standard, only Used in Usenet News, may occur in 251 in Usenet News, not messages gatewayed from Usenet News to 252 in e-mail. e-mail, no defined meaning in e-mail. 254 Usenet news only, De facto standard in Usenet News, may 255 discouraged in occur in messages gatewayed from Usenet 256 e-mail. News to e-mail, but such practice is 257 discouraged. 259 Not standardized for Used to mark headers defined only for 260 use in e-mail. use in Usenet News. These headers have 261 no standard meaning when appearing in 262 e-mail, some of them may even be used in 263 different ways by different software. 264 When appearing in e-mail, they should be 265 handled with caution. 267 Other standard. Defined in standard developed by another 268 standards making body than IETF. 270 Non-standard. This header is not specified in any of 271 the RFCs which define Internet 272 protocols, including Internet Standards, 273 Draft Standards, Proposed Standards and 274 Experimental Standards. The header 275 appears here because it often appears in 276 e-mail or Usenet News. Usage of these 277 headers is not in general recommended. 278 Some header proposed in ongoing IETF 279 standards development work, but not yet 280 accepted, are also marked in this way. 282 discouraged This header, which is non-standard or 283 historical, is known to create problems 284 and should not be generated. Handling of 285 such headers in incoming mail should be 286 done with great caution. 288 controversial The meaning and usage of this header is 289 controversial, i.e. different 290 implementors have chosen to implement 291 the header in different ways. Because of 292 this, such headers should be handled 293 with caution and understanding of the 294 different possible interpretations. 296 5.3 Requirements for a Published Specification 298 Issue: Header registration requires an RFC specifying the header, 299 except for header names marked as discouraged in the header 300 registry. 302 The following information should be provided when applying for 303 registry of a new e-mail or Usenet News header: 305 - Header name. 307 - Status, one of the statuses specified in section 5.2 above. 309 - If the header is specified in an RFC, the number of this RFC. 311 - If the header is specified in another standard than an RFC, a 312 reference to this standard. 314 - If the header is not specified in an RFC, a textual description 315 should be enclosed, which describes the header, its intended use 316 and discusses security considerations. 318 5.4 Identification of Security Considerations 320 Issue: The registration process requires the identification of any 321 known security problems with the header name. 323 Comment: It is not required that the header be secure or that it 324 be free from risks, but that the known risks be identified. 325 Publication of a header name does not require an exhaustive 326 security review, and the security considerations section is 327 subject to continuing evaluation. Additional security 328 considerations should be periodically published in an RFC by IANA. 330 5.5 Recommendations and Standards Status 332 Issue: The registration of a header does not imply endorsement, 333 approval, or recommendation by IANA or IETF or even certification 334 that the specification is adequate. 336 6. Security Considerations 338 This memo does not address specific security issues but outlines a 339 security review process for headers 341 7. Acknowledgments 343 Harald Tveit Alvestrand, Ned Freed, Olle J�rnefors, Keith Moore, 344 Nick Smith and several other people have helped me with compiling 345 the list in the appendix. I alone take responsibility for any 346 errors which may still be in the list. 348 8. References 350 Ref. Author, title IETF status 351 (July 1996) 352 ---- ------------------------------------------ ------------- 354 [1] J. Postel: "Simple Mail Transfer Standard, 355 Protocol", STD 10, RFC 821, August 1982. Recommended 357 2] D. Crocker: "Standard for the format of Standard, 358 ARPA Internet text messages." STD 11, RFC Recommended 359 822, August 1982. 361 [3] M.R. Horton, R. Adams: "Standard for Not an 362 interchange of USENET messages", RFC 1036, offi-cial IETF 363 December 1987. standard, but 364 in reality a 365 de-facto 366 standard for 367 Usenet News 369 4] M. Sirbu: "A Content-Type header for Standard, 370 internet messages", RFC 1049, March 1988. Recommended, 371 but can in the 372 future be 373 expected to be 374 replaced by 375 MIME 377 5] R. Braden (editor): "Requirements for Standard, 378 Internet Hosts -- Application and Required 379 Support", STD-3, RFC 1123, October 1989. 381 [6] D. Robinson, R. Ullman: "Encoding Header Non-standard 382 for Internet Messages", RFC 1154, April 383 1990. 385 [7] S. Hardcastle-Kille: "Mapping between Proposed 386 X.400(1988) / ISO 10021 and RFC 822", RFC standard, 387 1327 May 1992. elective 389 8] H. Alvestrand & J. Romaguera: "Rules for Proposed 390 Downgrading Messages from X.400/88 to standard, 391 X.400/84 When MIME Content-Types are elective 392 Present in the Messages", RFC 1496, August 393 1993. 395 [9] A. Costanzo: "Encoding Header for Internet Non-standard 396 Messages", RFC 1154, April 1990. 398 10] A. Costanzo, D. Robinson: "Encoding Header Experimental 399 for Internet Messages", RFC 1505, August 400 1993. 402 [11] N. Borenstein & N. Freed: "MIME Draft Standard, 403 (Multipurpose Internet Mail Extensions) elective 404 Part One: Mechanisms for Specifying and 405 Describing the Format of Internet Message 406 Bodies", RFC 1521, Sept 1993. 408 [12] H. Alvestrand: "Tags for the Proposed 409 Identification of Languages", RFC 1766, standard, 410 February 1995. elective 412 13] J. Palme: "Electronic Mail", Artech House Non-standard 413 publishers, London-Boston January 1995. 415 [14] R. Troost, S. Dorner: "Communicating Experimental 416 Presentation Information in Internet 417 Messages: The Content-Disposition Header", 418 RFC 1806, June 1995. 420 [15] B. Kantor, P. Lapsley, "Network News Proposed 421 Transfer Protocol: "A Proposed Standard standard 422 for the Stream-Based Transmission of 423 News", RFC 977, January 1986. 424 [16] 1848 PS S. Crocker, N. Freed, J. Proposed 425 Galvin, S. Murphy, "MIME Object Security standard 426 Services", RFC 1848, March 1995. 428 [17] J. Myers, M. Rose: The Content-MD5 Header, Draft standard 429 RFC 1864, October 1995. 431 [18] M. Horton, UUCP mail interchange format Not an 432 standard, RFC 976, Januari 1986. offi-cial IETF 433 standard, but 434 in reality a 435 de-facto 436 standard for 437 Usenet News 439 19] T. Berners-Lee, R. Headering, H. Frystyk: IETF draft 440 Hypertext Transfer Protocol -- HTTP/1.0, 441 draft-ietf-http-v10-spec-04.txt. 443 [20] G. Vaudreuil: Voice Profile for Internet Experimental 444 Mail, RFC 1911, February 1996. 446 [21] H. Spencer: News Article Format and Not even an 447 Transmission, June 1994, RFC, but still 448 FTP://zoo.toronto.edu/pub/news.ps.Z widely used and 449 FTP://zoo.toronto.edu/pub/news.txt.Z partly almost a 450 de-facto 451 This document is often referenced under standard for 452 the name "son-of-RFC1036". Usenet News 454 22] J. Palme: Common Internet Message Headers. Informational 455 draft-ietf-mailext-mail-attributes-07.txt. 456 January 1997. 458 9. Author's address 460 Jacob Palme Phone: +46-8-16 16 67 461 Stockholm University/KTH Fax: +46-8-783 08 29 462 Electrum 230 E-mail: jpalme@dsv.su.se 463 S-164 40 Kista, Sweden 465 10. Appendix: Proposed initial content of the IETF header name 466 registry 468 Note: The descriptions in the leftmost columns are intentionally 469 very brief and may therefore not give a complete and fully 470 accurate description of the header. 472 Hint on usage Header name Source Status 473 -------------- ----------- ------------------ ---------------- 475 Special Usenet Also-Contro son-of-RFC1036 Non-standard, 476 News actions. l: [21]. only in Usenet 477 News, not in 478 e-mail. 480 Controls X.400 Alternate-R RFC 1327. X.400. 481 forwarding. ecipient: 483 Inserted by Apparently- RFC 1211 and [22]. Non-standard, 484 Sendmail. To: discouraged. 486 Mark of Approved: RFC 1036: 2.2.11. Only in Usenet 487 approval by News, not in 488 moderator. e-mail. 490 Specially Article-Nam son-of-RFC1036 Non-standard. 491 important es: [21]. 492 articles. 494 Revised Article-Upd son-of-RFC1036 Non-standard. 495 version ates: [21]. 496 article. 498 Has been Auto-Forwar RFC 1327. X.400. 499 automatically ded: 500 forwarded. 502 Recipients not bcc: RFC 822: 4.5.3, IETF standard. 503 to be RFC 1123: 504 disclosed. 5.2.15-16, 5.3.7. 506 Secondary cc: RFC 822: 4.5.2, IETF standard. 507 recipients. RFC 1123. 508 5.2.15-16, 5.3.7. 510 Comments on a Comments: RFC 822: 4.7.2. IETF standard. 511 message. 513 Base for Content-Bas In forthcoming Soon IETF 514 resolving e: MHTML standard. proposed 515 relative URLs. standard. 517 Conversion Content-Con See [22]. Non-standard. 518 control. version: 520 Description of Content-Des RFC 1521: 6.2. IETF draft 521 body part. cription: standard. 523 Inline or Content-Dis RFC 1806. IETF 524 attachment. position: experimental 525 standard. 527 Unique ID of Content-ID: RFC 1521: 6.1. IETF draft 528 one body part. standard. 530 Text string Content-Ide RFC 1327. X.400. 531 identifier. ntifier: 533 Language(s) of Content-Lan RFC 1766. IETF proposed 534 body part. guage: standard. 536 Size in bytes. Content-Len See [22]. Non-standard, 537 gth: discouraged. 539 URI for body Content-Loc In forthcoming Soon IETF 540 part. ation: MHTML proposed proposed 541 standard. standard. 543 Checksum of Content-MD5 RFC 1864. IETF proposed 544 content. : standard. 546 Return content Content-Ret RFC 1327. X.400. 547 in X.400 urn: 548 delivery 549 notifications? 550 . 552 From the SGML Content-SGM Other standard. 553 entity L-Entity: 554 declaration. 556 Coding method. Content-Tra RFC 1521: 5. IETF draft 557 nsfer-Encod standard. 558 ing: 560 Format of Content-Typ RFC 1049, IETF draft 561 content. e: RFC 1123: 5.2.13, standard. 562 RFC 1521: 4. 563 RFC 1766: 4.1 565 Special Usenet Control: RFC 1036: 2.1.6. Only in Usenet 566 News actions News, not in 567 only. e-mail. 569 Body may not Conversion- RFC 1327. X.400. 570 be converted With-Loss: 571 with loss. 573 Body may not Conversion: RFC 1327. X.400. 574 be converted. 576 When message Date: RFC 822: 5.1, IETF standard. 577 was created. RFC 1123: 5.2.14 578 RFC 1036: 2.1.2. 580 When message Delivery-Da RFC 1327. X.400. 581 was delivered. te: 583 X.400 Discarded-X RFC 1327. X.400. 584 extensions not 400-IPMS-Ex 585 mapped. tensions: 587 X.400 Discarded-X RFC 1327. X.400. 588 extensions not 400-MTS-Ext 589 mapped. ensions: 591 Tell recipient Disclose-Re RFC 1327. X.400. 592 about other cipients: 593 recipients. 595 Limitation of Distributio RFC 1036: 2.2.7. Usenet news 596 distribution n: only, not in 597 area. e-mail. 599 Trace of lists DL-Expansio RFC 1327. X.400. 600 passed. n-History-I 601 ndication: 603 Several Encoding: RFC 1154, IETF 604 different RFC 1505, experimental 605 incompatible standard. 606 uses. 608 Where to send Errors-To: See [22]. Non-standard, 609 notifications. discouraged. 611 Expiration Expires: RFC 1036: 2.2.4. Usenet news 612 date. only, not in 613 e-mail. 615 Expiration Expiry-Date RFC 1327. X.400. 616 date. : 618 Fax number of Fax: Non-standard. 619 the 620 originator. 622 File where Fcc: See [22]. Non-standard. 623 message is 624 stored. 626 Where to Followup-To RFC 1036: 2.2.3. Usenet news 627 discuss item : only, not in 628 further. e-mail. 630 Variant of For-Comment See [22]. Non-standard. 631 "To:" : 633 Variant of For-Handlin See [22]. Non-standard. 634 "To: g: 636 (1) Message From See [22]. Discouraged in 637 separator in transport of 638 files. e-mail. 640 (2) Usenet From RFC 976: 2.4 Usenet news 641 news delivery or only, not in 642 path. >From e-mail. 644 Author From: RFC 822: 4.4.1, IETF standard. 645 RFC 1123: 646 5.2.15-16, 5.3.7, 647 RFC 1036 2.1.1 649 Delivery Generate-De RFC 1327. X.400. 650 report livery-Repo 651 generation rt: 652 control. 654 Values: High, Importance: RFC 1327 and IETF 655 normal or low. RFC 1911. experimental 656 standard. 658 Message being In-Reply-To RFC 822: 4.6.2. 659 replied to. : 661 Body parts are Incomplete- RFC 1327. X.400. 662 missing. Copy: 664 Search keys Keywords: RFC 822: 4.7.1 665 for retrieval. RFC 1036: 2.2.9. 667 Language of Language: RFC 1327, X.400. 668 message. 670 Size of the Lines: RFC 1036: 2.2.12. Usenet news 671 message. only, not in 672 e-mail. 674 Generating Mail-System Non-standard, 675 client -Version: discouraged. 676 software. 678 Generating Mailer: Non-standard, 679 client discouraged. 680 software. 682 Unique ID of Message-ID: RFC 822: 4.6.1 IETF standard. 683 this message. RFC 1036: 2.1.5. 685 Report or Message-Typ RFC 1327. X.400. 686 message. e: 688 Version of MIME-Versio RFC 1521: 3. IETF draft 689 MIME. n: standard. 691 Newsgroups Newsgroups: RFC 1036: 2.1.3, Usenet news 692 getting this see also[22]. only, 693 article. discouraged in 694 e-mail. 696 Previous Obsoletes: RFC 1327. X.400. 697 message being 698 replaced. 700 Sender Organisatio Discouraged. 701 organzation. n: 703 Sender Organizatio RFC 1036: 2.2.8. Usenet news 704 organization. n: only, 705 discouraged in 706 e-mail. 708 Body part Original-En RFC 1327. X.400. 709 types in coded-Infor 710 message. mation-Type 711 s: 713 Generating Originating Non-standard, 714 client -Client: discouraged. 715 software. 717 List of MTAs Path: RFC 1036: 2.2.6. Usenet news 718 passed. only, not in 719 e-mail. 721 Phone number Phone: . Non-standard 722 of the 723 originator. 725 Priority, Precedence: See [22]. Non-standard, 726 might controversial, 727 influence discouraged. 728 speed. 730 Non-delivery Prevent-Non RFC 1327. X.400. 731 report Delivery-Re 732 control. port: 734 Priority, Priority: RFC 1327. X.400. 735 might 736 influence 737 speed. 739 Trace of MTAs Received: RFC 822: 4.3.2, IETF standard. 740 passed. RFC 1123: 5.2.8. 742 Reference to References: RFC 822: 4.6.3 IETF standard. 743 other RFC 1036: 2.1.5. 744 messages. 746 Latest reply Reply-By: RFC 1327. X.400. 747 time. 749 Where to send Reply-To: RFC 822: 4.4.3, IETF standard 750 replies. RFC 1036: 2.2.1 but 751 see also [22]. controversial. 753 Information Resent-Repl RFC 822: C.3.3. IETF standard. 754 about manual y-To:, 755 forwarding. Resent-From:, 756 Resent-Sender:, 757 Resent-From;, 758 Resent-Date;, 759 Resent-To:, 760 Resent-cc:, 761 Resent-bcc:, 762 Resent-Mess 763 age-ID: 765 Envelope info Return-Path RFC 821, IETF standard. 766 at final : RFC 1123: 5.2.13. 767 delivery. 769 Where to send Return-Rece See [22]. Non-standard, 770 notifications. ipt-To: discouraged. 772 Related See-Also: Son-of-RFC1036 Non-standard. 773 articles. [21]. 775 Sender if not Sender: RFC 822: 4.4.2, IETF standard. 776 same as in RFC 1123: 777 from header. 5.2.15-16, 5.3.7. 779 Disclosure Sensitivity RFC 1327 and IETF 780 secrecy. : RFC 1911. experimental 781 standard. 783 Whether Status: See [22]. Non-standard, 784 message has should never 785 been appear in mail 786 delivered. in transit. 788 Title, Subject: RFC 822: 4.7.1 IETF standard. 789 heading, RFC 1036: 2.1.4. 790 subject. 792 Short version Summary: RFC 1036: 2.2.10. Usenet news 793 of long only, 794 message. discouraged. 796 Replaces Supersedes: Son-of-RFC1036 Non-standard. 797 previous [21]. 798 article. 800 Fax number of Telefax: Non-standard. 801 the 802 originator. 804 Primary To: RFC 822: 4.5.1, IETF standard. 805 recipients. RFC 1123: 806 5.2.15-16, 5.3.7. 808 Generating X-Mailer: Non-standard. 809 client 810 software. 812 Generating X-Newsreade Non-standard. 813 client r 814 software. 816 Control of X400-Conten Non-standard. 817 content-return t-Return: 818 . 820 Other Xref: RFC 1036: 2.2.13. Usenet news 821 newsgroups only, not in 822 getting the e-mail. 823 same article.