idnits 2.17.1 draft-ietf-drums-MHRegistry-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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-02', 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 655 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 482 has weird spacing: '...ecurity sta...' == Unrecognized Status in 'Category: Informational; Replaces RFC 2076', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- 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 (May 1998) is 9470 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 411, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 426, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 434, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 438, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 442, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 446, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 452, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 455, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 459, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 465, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 469, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 472, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 477, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 481, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 485, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 488, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 496, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 500, but no explicit reference was found in the text == Unused Reference: '22' is defined on line 511, but no explicit reference was found in the text == Unused Reference: '23' is defined on line 515, but no explicit reference was found in the text == Unused Reference: '24' is defined on line 519, but no explicit reference was found in the text ** Obsolete normative reference: RFC 821 (ref. '1') (Obsoleted by RFC 2821) -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 1036 (ref. '3') (Obsoleted by RFC 5536, RFC 5537) ** Downref: Normative reference to an Historic RFC: RFC 1049 (ref. '4') ** Obsolete normative reference: RFC 1154 (ref. '6') (Obsoleted by RFC 1505) ** Obsolete normative reference: RFC 822 (ref. '7') (Obsoleted by RFC 2822) ** Downref: Normative reference to an Historic RFC: RFC 1496 (ref. '8') -- Duplicate reference: RFC1154, mentioned in '9', was also mentioned in '6'. ** Obsolete normative reference: RFC 1154 (ref. '9') (Obsoleted by RFC 1505) ** Downref: Normative reference to an Experimental RFC: RFC 1505 (ref. '10') ** 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) -- Possible downref: Non-RFC (?) normative reference: ref. '13' ** Obsolete normative reference: RFC 1806 (ref. '14') (Obsoleted by RFC 2183) ** Obsolete normative reference: RFC 977 (ref. '15') (Obsoleted by RFC 3977) ** Downref: Normative reference to an Historic RFC: RFC 1848 (ref. '16') ** Downref: Normative reference to an Unknown state RFC: RFC 976 (ref. '18') ** Downref: Normative reference to an Informational draft: draft-ietf-http-v10-spec (ref. '19') ** 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) -- Unexpected draft version: The latest known version of draft-ietf-mailext-mail-attributes is -06, but you're referring to -07. ** Downref: Normative reference to an Informational draft: draft-ietf-mailext-mail-attributes (ref. '22') -- Possible downref: Non-RFC (?) normative reference: ref. '23' -- Possible downref: Non-RFC (?) normative reference: ref. '24' Summary: 27 errors (**), 0 flaws (~~), 25 warnings (==), 9 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-02.txt November 1997 4 Category: Informational; Replaces RFC 2076 Expires May 1998 6 Mail and Netnews 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 and netnews software products 35 use various e-mail and netnews header fields. This document 36 specifies a procedure for the registration of e-mail and netnews 37 header field names, to reduce the risk that two different products 38 use the same header name in different ways (homonyms) or that 39 several different header names are used with identical meaning 40 (synonyms). 42 Table of contents 44 1. Introduction 45 2. Which Headers are Registered 46 3. Who can Register a Header Name 47 4. Registration Procedure 48 4.1 Registration Template 49 4.2 Present the Request for Registration to the 50 Community 51 4.3 Submit the Header name to the IANA for 52 Registration 53 5. Clarifications On Specific Issues 54 5.1 E-mail Requirements for a Limited Number of 55 Headers 56 5.2 Header Status 57 5.3 Requirements for a Published Specification 58 5.4 Identification of Security Considerations 59 5.5 Recommendations and Standards Status 60 6. Security Considerations 61 7. Acknowledgments 62 8. Copyright 63 9. References 64 10. Author's address 65 11. Appendix: Example of the first few entries in the 66 registry 68 1. Introduction 70 Many different Internet standards, other RFCs and e-mail software 71 products define headers which may occur on Internet mail messages 72 and/or Usenet News articles. There is an obvious risk for 74 Honomyns: The same header name is used in different ways by 75 different software products. 77 Synonyms: Several different headers for exactly the same use. 79 The solution, to allow header names beginning with "X-" for 80 non-standard header names has several drawbacks. One is that it 81 does not preclude two different products using the same "X-" 82 header name with different semantic meaning. Another is that if an 83 "X-" header gets popular and much used, and is to become a 84 standard, there is a problem with removing the "X-" in front of an 85 already much used header. 87 Because of this, an IANA registry for e-mail and Usenet News 88 header field names is needed. 90 The following words are used in this memo with the meaning 91 specified below: 93 heading Formatted text at the top of a message, ended 94 by a blank line 96 header = heading One field in the heading, beginning with a 97 field header name, colon, and followed by the field 98 value(s) 100 2. Which Headers are Registered 102 The header name registry can contain headers from the following 103 sources: 105 - Internet standards 106 - RFCs which are not Internet standards 107 - Non-Internet standards 108 - Other commonly used headers 109 - Sometimes used headers whose use is discouraged. The use of a 110 header name may be discouraged because it is badly defined, 111 ambigous or used in different ways by different software. The 112 purpose of registering discouraged headers is to avoid their use 113 in their present or any other future semantic meaning. 115 The registry is intended to contain headers used in messaging 116 (e-mail, Usenet News, etc.) but not HTTP-only headers. 118 3. Who can Register a Header Name 120 Header names from Internet standards are registered by IETF 121 together with the standard specifying the header. 123 Headers in other RFCs are registered when the RFCs are published. 125 Anyone can propose the registry of additional headers, but such 126 headers should be approved by the IETF application area managers 127 before accepted in the registry. This approval should be given if 128 the header seems reasonable and not in conflict with current usage 129 or other headers in ways which might cause problem. It is not 130 necessary for approval that the AREA manager likes the header or 131 wants it to be progressed into an IETF standard. The procedure 132 described in this memo is followed by the IANA for review and 133 approval of new e-mail and netnews headers. This is not a formal 134 standards process, but rather an administrative procedure intended 135 to allow community comment and sanity checking without excessive 136 time delay. 138 4. Registration Procedure 140 4.1 Registration Template 142 To: ietf-types@iana.org 143 Subject: Registration of e-mail header: XXX 145 E-mail header name: 147 Short description (max 100 words): 149 Encoding considerations: 151 Security considerations: 153 Interoperability considerations: 155 Published specification: 157 Applications which use this header: 159 Person & email address to contact for further information: 161 Intended usage: 163 (One of COMMON, LIMITED USE or OBSOLETE) 165 Author/Change controller: 167 (Any other information that the author deems interesting may 168 be added below this line.) 170 4.2 Present the Request for Registration to the Community 172 Send a proposed header to the "mail-headers@segate.sunet.se" 173 mailing list. This mailing list has been established for the sole 174 purpose of reviewing proposed e-mail and netnews headers. You can 175 subscribe to the list by sending a message to 176 "listserv@segate.sunet.se" containing in the text a line with 177 "subscribe mail-headers " followed by our name (not your e-mail 178 address), and unsubscribe with a message "unsubscribe 179 mail-headers". 181 Archives of this list are available 182 by anonymous FTP from 183 ftp://segate.sunet.se/lists/mail-headers/ 185 by HTTP from 186 http://segate.sunet.se/archives/mail-headers.html 188 by E-MAIL 189 send a message to 190 LISTSERV@SEGATE.SUNET.SE with the text "INDEX mail-headers" 191 to get a list of the archive files, and then a new message 192 "GET " to retrieve the archive files. 194 The FTP and E-MAIL archives are best if you want to retrieve 195 all messages during a month or more, while the HTTP archives 196 are better if you want to browse and find particular messages 197 to download. 199 The intent of the public posting is to solicit comments and 200 feedback on the choice of header name, the unambiguity of the 201 references with respect to versions and external profiling 202 information, the choice of which OIDs to use, and a review of the 203 security considerations section. It should be noted that the 204 proposed header name does not need to make sense for every 205 possible application. If the header name is intended for a limited 206 or specific use, this should be noted in the submission. 208 4.3 Submit the Header name to the IANA for Registration 210 After at least two weeks, submit the proposed header to the IANA 211 for registration. The request and supporting documentation should 212 be sent to "iana@isi.edu". IANA will ask the area directors for 213 approval. If approved, IANA will register the header, assign an 214 OID under the IANA branch, and make the header registration 215 available to the community. 217 IANA should keep a data base of registered headers. IANA should 218 regularly publish the contents of this data base in the following 219 formats, which can be generated automatically from the data base: 221 (1) In HTML format as shown in an appendix to this document. 223 (2) As plain formatted ASCII text. 225 (3) As ASCII text with HT between fields and CRLF between lines. 227 Format (1) and (2) are good for human reading, format (3) is good 228 for input to a data base. 230 The header will be listed in the periodically issued "Assigned 231 Numbers" RFC [2]. The header description may be published as an 232 Informational RFC by sending it to "rfc-editor@isi.edu" (please 233 follow the instructions to RFC authors [3]). 235 5. Clarifications On Specific Issues 237 5.1 E-mail Requirements for a Limited Number of Headers 239 Issue: In the asynchronous mail environment, where information on 240 the capabilities of the remote mail agent is not available to the 241 sender, maximum interoperability is attained by restricting the 242 number of headers used to those "common" headers expected to be 243 widely implemented. This was asserted as a reason to limit the 244 number of possible headers and resulted in a registration process 245 with a significant hurdle and delay for those registering headers. 247 5.2 Header Status 249 Any header in the registry should be marked with a status, which 250 has one of the values specified below: 252 IETF standard. Specified in an IETF standard. 254 IETF draft standard. Specified in an IETF draft standard. 256 IETF proposed Specified in an IETF proposed standard. 257 standard. 259 IETF experimental Specified in an IETF experimental 260 standard. standard. 262 X.400. Used to mark headers which are defined 263 in RFC 1327 for use in messages from or 264 to Internet mail/X.400 gateways, and 265 which have not been standardized for 266 general usage in the exchange of 267 messages between Internet mail-based 268 systems. 270 Usenet News only, De facto standard in Usenet News, may 271 not in e-mail. occur in messages gatewayed from Usenet 272 News to e-mail, no defined meaning in 273 e-mail. 275 Non-standard, only Used in Usenet News, may occur in 276 in Usenet News, not messages gatewayed from Usenet News to 277 in e-mail. e-mail, no defined meaning in e-mail. 279 Usenet news only, De facto standard in Usenet News, may 280 discouraged in occur in messages gatewayed from Usenet 281 e-mail. News to e-mail, but such practice is 282 discouraged. 284 Not standardized for Used to mark headers defined only for 285 use in e-mail. use in Usenet News. These headers have 286 no standard meaning when appearing in 287 e-mail, some of them may even be used in 288 different ways by different software. 289 When appearing in e-mail, they should be 290 handled with caution. 292 Other standard. Defined in standard developed by another 293 standards making body than IETF. 295 Non-standard. This header is not specified in any of 296 the RFCs which define Internet 297 protocols, including Internet Standards, 298 Draft Standards, Proposed Standards and 299 Experimental Standards. The header 300 appears here because it sometimes 301 appears in e-mail or Usenet News. Usage 302 of these headers is not in general 303 recommended. Some header proposed in 304 ongoing IETF standards development work, 305 but not yet accepted, are also marked in 306 this way. 308 discouraged This header, which is non-standard or 309 historical, is known to create problems 310 and should not be generated. Handling of 311 such headers in incoming mail should be 312 done with great caution. 314 controversial The meaning and usage of this header is 315 controversial, i.e. different 316 implementors have chosen to implement 317 the header in different ways. Because of 318 this, such headers should be handled 319 with caution and understanding of the 320 different possible interpretations. 322 5.3 Requirements for a Published Specification 324 If headers registered are specified in a separate document, this 325 document should be published as an RFC. Other specifications can 326 in some cases also be accepted if they are publicly available on 327 the Internet. 329 The following information should be provided when applying for 330 registry of a new e-mail or Usenet News header: 332 - Header name. 334 - Status, one of the statuses specified in section 5.2 above. 336 - If the header is specified in an RFC, the number of this RFC. 338 - If the header is specified in another standard than an RFC, a 339 reference to this standard. 341 - If the header is not specified in an RFC, a short textual 342 description should be enclosed, which describes the header, 343 its intended use and discusses security considerations. 345 - Security considerations. 347 5.4 Identification of Security Considerations 349 The registration process requires the identification of any known 350 security problems with the header name. 352 It is not required that the header be secure or that it be free 353 from risks, but that the known risks be identified. Publication of 354 a header name does not require an exhaustive security review, and 355 the security considerations. Additional security considerations 356 should be periodically published in an RFC by IANA. 358 5.5 Recommendations and Standards Status 360 Issue: The registration of a header does not imply endorsement, 361 approval, or recommendation by IANA or IETF or even certification 362 that the specification is adequate. 364 6. Security Considerations 366 This memo does not address specific security issues but outlines a 367 security review process for headers 369 7. Acknowledgments 371 Harald Tveit Alvestrand, Ned Freed, Olle J�rnefors, Keith Moore, 372 Nick Smith and several other people have helped in developing this 373 document. I alone take responsibility for any errors which may 374 still be in the list. 376 8. Copyright 378 "Copyright (C) The Internet Society (date). All Rights Reserved. 380 This document and translations of it may be copied and furnished 381 to others, and derivative works that comment on or otherwise 382 explain it or assist in its implmentation may be prepared, copied, 383 published and distributed, in whole or in part, without 384 restriction of any kind, provided that the above copyright notice 385 and this paragraph are included on all such copies and derivative 386 works. However, this document itself may not be modified in any 387 way, such as by removing the copyright notice or references to the 388 Internet Society or other Internet organizations, except as needed 389 for the purpose of developing Internet standards in which case the 390 procedures for copyrights defined in the Internet Standards 391 process must be followed, or as required to translate it into 392 languages other than English. 394 The limited permissions granted above are perpetual and will not 395 be revoked by the Internet Society or its successors or assigns. 397 This document and the information contained herein is provided on 398 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 399 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 400 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 401 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 402 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 403 PURPOSE." 405 9. References 407 Ref. Author, title IETF status 408 (July 1996) 409 ---- ------------------------------------------ ------------- 410 - 411 [1] J. Postel: "Simple Mail Transfer Standard, 412 Protocol", STD 10, RFC 821, August 1982. Recommended 414 [2] D. Crocker: "Standard for the format of Standard, 415 ARPA Internet text messages." STD 11, RFC Recommended 416 822, August 1982. 418 [3] M.R. Horton, R. Adams: "Standard for Not an 419 interchange of USENET messages", RFC 1036, offi-cial IETF 420 December 1987. standard, but 421 in reality a 422 de-facto 423 standard for 424 Usenet News 426 [4] M. Sirbu: "A Content-Type header for Standard, 427 internet messages", RFC 1049, March 1988. Recommended, 428 but can in the 429 future be 430 expected to be 431 replaced by 432 MIME 434 [5] R. Braden (editor): "Requirements for Standard, 435 Internet Hosts -- Application and Required 436 Support", STD-3, RFC 1123, October 1989. 438 [6] D. Robinson, R. Ullman: "Encoding Header Non-standard 439 for Internet Messages", RFC 1154, April 440 1990. 442 [7] S. Hardcastle-Kille: "Mapping between Proposed 443 X.400(1988) / ISO 10021 and RFC 822", RFC standard, 444 1327 May 1992. elective 446 [8] H. Alvestrand & J. Romaguera: "Rules for Proposed 447 Downgrading Messages from X.400/88 to standard, 448 X.400/84 When MIME Content-Types are elective 449 Present in the Messages", RFC 1496, August 450 1993. 452 [9] A. Costanzo: "Encoding Header for Internet Non-standard 453 Messages", RFC 1154, April 1990. 455 [10] A. Costanzo, D. Robinson: "Encoding Header Experimental 456 for Internet Messages", RFC 1505, August 457 1993. 459 [11] N. Borenstein & N. Freed: "MIME Draft Standard, 460 (Multipurpose Internet Mail Extensions) elective 461 Part One: Mechanisms for Specifying and 462 Describing the Format of Internet Message 463 Bodies", RFC 1521, Sept 1993. 465 [12] H. Alvestrand: "Tags for the Proposed 466 Identification of Languages", RFC 1766, standard, 467 February 1995. elective 469 [13] J. Palme: "Electronic Mail", Artech House Non-standard 470 publishers, London-Boston January 1995. 472 [14] R. Troost, S. Dorner: "Communicating Experimental 473 Presentation Information in Internet 474 Messages: The Content-Disposition Header", 475 RFC 1806, June 1995. 477 [15] B. Kantor, P. Lapsley, "Network News Proposed 478 Transfer Protocol: "A Proposed Standard standard 479 for the Stream-Based Transmission of 480 News", RFC 977, January 1986. 481 [16] 1848 PS S. Crocker, N. Freed, J. Proposed 482 Galvin, S. Murphy, "MIME Object Security standard 483 Services", RFC 1848, March 1995. 485 [17] J. Myers, M. Rose: The Content-MD5 Header, Draft standard 486 RFC 1864, October 1995. 488 [18] M. Horton, UUCP mail interchange format Not an 489 standard, RFC 976, Januari 1986. offi-cial IETF 490 standard, but 491 in reality a 492 de-facto 493 standard for 494 Usenet News 496 [19] T. Berners-Lee, R. Headering, H. Frystyk: IETF draft 497 Hypertext Transfer Protocol -- HTTP/1.0, 498 draft-ietf-http-v10-spec-04.txt. 500 [20] G. Vaudreuil: Voice Profile for Internet Experimental 501 Mail, RFC 1911, February 1996. 503 [21] H. Spencer: News Article Format and Not even an 504 Transmission, June 1994, RFC, but still 505 FTP://zoo.toronto.edu/pub/news.ps.Z widely used and 506 FTP://zoo.toronto.edu/pub/news.txt.Z partly almost a 507 de-facto 508 This document is often referenced under standard for 509 the name "son-of-RFC1036". Usenet News 511 [22] J. Palme: Common Internet Message Headers. Informational 512 draft-ietf-mailext-mail-attributes-07.txt. 513 January 1997. 515 [23] PICS Label Distribution Label Syntax and Other standard 516 Communication Protocols, World Wide Web 517 Consortium, October 1996. 519 [24] Eudora Pro Macintosh User Manual, Qualcomm Non-standard 520 Inc., 1988-1995. 522 10. Author's address 524 Jacob Palme Phone: +46-8-16 16 67 525 Stockholm University/KTH Fax: +46-8-783 08 29 526 Electrum 230 E-mail: jpalme@dsv.su.se 527 S-164 40 Kista, Sweden 529 11. Appendix: Example of the first few entries in the registry 531 Note 1: This example is formatted in a simple subset of HTML which 532 almost all HTML browsers can handle. 534 Note 2: When the registry is started, use the latest version of 535 draft-ietf-mailext-mail-attributes-??.txt as starting contents of 536 the registry. 538 The example below can be accessed via URL: 539 http://www.dsv.su.se/~jpalme/ietf/ehead-registry-example.html 541 542 543 544 IANA Registry of e-mail headers 545 548 551 552 554

ISI Logo 557 558 IANA Registry of e-mail headers 559 HTML 3.2 Checked!

564

565 Last update: 15 August 1997. 567

568 569 576 577 586 587 596 597 611 612 624
570 Description 571 572 Name 573 574 Reference, status 575
578 Special Usenet News actions and a normal article at the 579 same time. 580 581 Also-Control: 582 583 son-of-RFC1036 [21], non-standard, only in Usenet News, 584 not in e-mail 585
588 Controls whether this message may be forwarded to 589 alternate recipients such as a postmaster if delivery is 590 not possible to the intended recipient. Default: Allowed. 591 592 Alternate-Recipient: 593 594 RFC 1327, not for general usage. 595
598 Inserted by Sendmail when there is no "To:" recipient in 599 the original message, listing recipients derived from the 600 envelope into the message heading. This behavior is not 601 quite proper, MTAs should not modify headings (except 602 inserting Received lines), and it can in some cases cause 603 Bcc recipients to be wrongly divulged to non-Bcc 604 recipients. 606 607 Apparently-To: 608 609 Non-standard, discouraged, mentioned in RFC 1211. 610
613 Name of the moderator of the newsgroup to which this 614 article is sent; necessary on an article sent to a 615 moderated newsgroup to allow its distribution to the 616 newsgroup members. Also used on certain control 617 messages, which are only performed if they are marked 618 as Approved. 619 620 Approved: 621 622 RFC 1036: 2.2.11, not standardized for use in e-mail. 623
625 626