idnits 2.17.1 draft-ietf-mailext-mail-attributes-03.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-19) 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. 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 547 has weird spacing: '... of the len...' == Line 660 has weird spacing: '..., April sta...' -- 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 1996) is 10201 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '1' on line 636 looks like a reference -- Missing reference section? '2' on line 639 looks like a reference -- Missing reference section? '3' on line 643 looks like a reference -- Missing reference section? '5' on line 655 looks like a reference -- Missing reference section? '7' on line 663 looks like a reference -- Missing reference section? '8' on line 667 looks like a reference -- Missing reference section? '11' on line 679 looks like a reference -- Missing reference section? '12' on line 685 looks like a reference -- Missing reference section? '14' on line 692 looks like a reference -- Missing reference section? '13' on line 689 looks like a reference -- Missing reference section? '4' on line 652 looks like a reference -- Missing reference section? '6' on line 659 looks like a reference -- Missing reference section? '9' on line 672 looks like a reference -- Missing reference section? '10' on line 675 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 2 warnings (==), 16 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-03.txt Sweden 4 Category: Informational November 1995 5 Expires May 1996 7 Common Internet Message Attributes 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 RFC-s.. Distribution of this memo is unlimited. 33 Abstract 35 This memo contains a table of commonly occurring attributes in 36 headings and on envelopes of e-mail messages. The document compiles 37 information from other RFC-s such as RFC 821, RFC 822, RFC 1036, 38 RFC 1123, RFC 1327, RFC 1496, RFC 1521, RFC 1766 and RFC 1806. A few 39 commonly occurring attributes which are not defined in RFC-s are 40 also included. For each attribute, the memo gives a short 41 description and a reference to the RFC, in which the attribute 42 is defined. The postscript version of this memo shows the changes 43 as compared to version 02. 45 Table of contents 47 1. Introduction 49 2. Use of gatewaying attributes 51 3. Table of attributes 53 3.1 Phrases used in the tables 54 3.2 Addressing information 55 3.3 Envelope and format information 56 3.4 Sender and recipient indication 57 3.5 Response control 58 3.6 Message identification and referral attributes 59 3.7 Other textual attributes 60 3.8 Attributes containing dates and times 61 3.9 Quality information 62 3.10 Language information 63 3.11 Size information 64 3.13 Encoding information 65 3.14 Resent-attributes 66 3.15 Miscellaneous 68 4. Acknowledgments 70 5. References 72 6. Author's address 74 Appendix A: Attributes sorted by Internet RFC document in which 75 they appear 77 Appendix B: Alphabetical index 78 1. Introduction 80 Many different Internet standards and RFC-s define attributes which 81 may occur on Internet Mail Messages and Network News Articles. The 82 intention of this document is to list all such attributes in one 83 document as an aid to people developing message systems or interested 84 in Internet Mail standards. 86 The document contains all heading attributes which the author has 87 found in the following Internet standards: RFC 821 [1], RFC 822 [2], 88 RFC 1036 [3], RFC 1123 [5], RFC 1327 [7], RFC 1496 [8], RFC 1521 [11], 89 RFC 1766 [12] and RFC 1806 [14]. Note in particular that heading 90 attributes defined in RFC 1421-1424, "Privacy Enhancement for Internet 91 Electronic Mail", are not included. A few additional attributes which 92 often can be found in e-mail headings but are not part of any Internet 93 standard are also included. 95 For each heading attribute, the document gives a short description and 96 a reference to the Internet standard or RFC, in which they are defined. 98 2. Use of gatewaying attributes 100 RFC 1327 defines a number of new attributes in Internet mail, which 101 are defined to map attributes which X.400 has but which were 102 previously not standardized in Internet mail. The fact that an 103 attribute occurs in RFC 1327 indicates that it is recommended for 104 use in gatewaying messages between X.400 and Internet mail, but 105 does not mean that the attribute is recommended for messages wholly 106 within Internet mail. Some of these attributes may eventually get 107 accepted also for usage within Internet mail, but they are, when 108 this is written (July 1995) not recommended for such usage. 110 Fields defined in RFC 1036 for use in Usenet News sometimes appear 111 in mail messages, either because the messages have been gatewayed 112 from Usenet News to e-mail, or because the messages were written in 113 combined clients supporting both e-mail and Usenet News in the same 114 client. These fields are however not standardized for use in 115 Internet e-mail and should be handled with caution. 117 Fields are given here in the spelling used in e-mail headers. This 118 may sometimes be English, sometimes American spelling. One attribute, 119 "Organisation/Organization" occurs in e-mail headers sometimes with 120 English, sometimes with American spelling. 122 3. Table of attributes 124 3.1 Phrases used in the tables 126 "not for general Used to mark attributes which are defined in 127 usage" RFC 1327 for use in messages from or to 128 Internet mail/X.400 gateways. These attributes 129 have not been standardized for general usage 130 in the exchange of messages between Internet 131 mail-based systems. 133 "not standardized Used to mark attributes defined only in RFC 134 for use in e-mail" 1036 for use in Usenet News. These attributes 135 have no standard meaning when appearing in e- 136 mail, some of them may even be used in 137 different ways by different software. When 138 appearing in e-mail, they should be handled 139 with caution. Note that RFC 1036, although 140 generally used as a standard for Usenet News, 141 is not an accepted IETF standard or on the 142 IETF standards track. 144 "non-standard" This attribute is not specified in any of 145 those referenced RFC-s which are Internet 146 standards, draft standards or proposed 147 standards. The attribute appears here because 148 it is common in e-mail or Usenet News headers. 149 Usage of these attributes is not in general 150 recommended. 152 "discouraged" This attribute, which is non-standard, is 153 known to create problems and should not be 154 generated. Handling of such attributes in 155 incoming mail should be done with great 156 caution. 158 "controversial" The meaning and usage of this attribute is 159 controversial, i.e. different implementors 160 have chosen to implement the attribute in 161 different ways. Because of this, such 162 attributes should be handled with caution and 163 understanding of the different possible 164 interpretations. 166 "for limited use" Attributes defined in a so-called 167 "experimental" Internet standard. These should 168 be used only if both parties agree. 170 "experimental" This attribute is used for newly defined 171 attributes, which are to be tried out before 172 entering the IETF standards track. 174 3.2 Addressing information 176 Original sender. Should in MAIL FROM RFC 821, 177 Internet be empty ("MAIL FROM: RFC 1123: 5.2.9. 178 <>") when sending notifications, 179 and be the list administrator 180 when forwarding from a 181 distribution list. This value may 182 for gatewayed messages contain a 183 chain of hosts to be passed in 184 sequence to reach the original 185 sender (i.e. a relative address). 187 Used to convey the information Return-Path: RFC 821, 188 from the MAIL FROM envelope RFC 1123: 5.2.13. 189 attribute when the message leaves 190 the SMTP environment in which 191 "MAIL FROM" is used. 193 Recipient to which message is to RCPT TO RFC 821, 194 be delivered. Relative address RFC 1123: 5.2.6. 195 was allowed in RFC 821, but later 196 prohibited in RFC 1123. 198 3.3 Envelope and format 199 information 201 All that is inside the envelope. DATA RFC 821, 202 RFC 1123: 5.2.8. 204 Trace of MTA-s which a message Received: RFC 822: 4.3.2, 205 has passed. RFC 1123: 5.2.8. 207 An indicator that this message is MIME-Version: RFC 1521: 3. 208 formatted according to the MIME 209 standard, and an indication of 210 which version of MIME is 211 utilized. 213 List of MTA-s passed. Path: RFC 1036: 2.2.6, 214 not standardized 215 for use in e-mail. 217 Special Usenet News actions. Control: RFC 1036: 2.1.6, 218 not standardized 219 for use in 220 e-mail. 222 Trace of distribution lists DL-Expansion- RFC 1327, not for 223 passed. History- general usage. 224 Indication 226 Which body part types occur in Original- RFC 1327, not for 227 this message. Encoded- general usage. 228 Information- 229 Types: 231 Special informational message. Message-Type: RFC 1327, not for 232 Delivery general usage. 233 Report 235 Controls whether this message may Alternate- RFC 1327, not for 236 be forwarded to alternate Recipient: general usage. 237 recipients such as a postmaster 238 if delivery is not possible to 239 the intended recipient. Default: 240 Allowed. 242 Whether recipients are to be told Disclose- RFC 1327, not for 243 the names of other recipients of Recipients: general usage. 244 the same message. This is 245 primarily an X.400 facility, such 246 disclosure is in Internet mail 247 done via the To:, Cc: and Bcc: 248 heading fields. 250 Whether a MIME body part is to be Content- RFC 1806, 251 shown inline or is an attachment, Disposition: experimental 252 can also indicate a suggested 253 filename for use when saving an 254 attachment to a file. 256 3.4 Sender and recipient 257 indication 259 Author, approver From: RFC 822: 4.4.1, 260 RFC 1123: 5.2.15- 261 16, 5.3.7. 263 Moderator Approved: RFC 1036: 2.2.11, 264 not standardized 265 for use in e-mail. 267 Sender information inside the Sender: RFC 822: 4.4.2, 268 envelope. RFC 1123: 5.2.15- 269 16, 5.3.7. 271 Main recipients. To: RFC 822: 4.5.1, 272 RFC 1123: 5.2.15- 273 16, 5.3.7. 275 Additional recipients. Cc: RFC 822: 4.5.2, 276 RFC 1123. 5.2.15- 277 16, 5.3.7. 279 Recipients not shown to other Bcc: RFC 822: 4.5.3, 280 recipients. RFC 1123: 5.2.15- 281 16, 5.3.7. 283 In Usenet News: group to which Newsgroups: RFC 1036: 2.1.3, 284 this article was posted. not standardized 285 Some systems provide this field and controversial 286 also in e-mail although it is not for use in e-mail. 287 standardized there. 288 Unfortunately, the field can 289 appear in e-mail with two 290 different and contradictory 291 meanings: 292 (a) Indicates the newsgroup 293 recipient of a message sent to 294 both e-mail and Usenet News 295 recipients. 296 (b) In a personally addressed 297 reply to a message in a news- 298 group, indicate the newsgroup in 299 which this discussion originated. 301 Inserted by Sendmail when there Apparently- Non-standard, 302 is no "To:" recipient in the To: discouraged, 303 original message, listing mentioned in 304 recipients derived from the RFC 1211. 305 envelope into the message 306 heading. This behavior is not 307 quite proper, MTA-s should not 308 modify headings (except inserting 309 Received lines), and it can in 310 some cases cause Bcc recipients 311 to be wrongly divulged to non-Bcc 312 recipients. 314 Limitation on where this message Distribution: RFC 1036: 2.2.7, 315 can be distributed. not standardized 316 for use in e-mail. 318 Fax number of the originator. Fax:, Non-standard. 319 Telefax: 321 Phone number of the originator. Phone: Non-standard. 323 Information about the client Mail-System- Non-standard. 324 software of the originator. Version:, 325 Mailer:, 326 Originating- 327 Client: 329 3.5 Response control 331 This heading field is meant to Reply-To: RFC 822: 4.4.3, 332 indicate where the sender wants controversial. 333 replies to go. Unfortunately, 334 this is ambiguous, since there 335 are different kinds of replies, 336 which the sender may wish to go 337 to different addresses. In 338 particular, there are personal 339 replies intended for only one 340 person, and group replies, 341 intended for the whole group of 342 people who read the replied-to 343 message (often a mailing list). 345 There has been various 346 suggestions to differentiate 347 between these two uses of "Reply- 348 To", with new header fields names 349 "Personal-Reply-To", "Group-Reply- 350 To" or "Wide-Reply-To". None of 351 these proposals have been 352 accepted. 354 In practice, "Reply-To" is often 355 used to indicate a neater format 356 for the e-mail address of the 357 sender than that given in the 358 "From" field. In this case, it 359 would be better to put the neater 360 format directly in the "From" 361 field. 363 A well-known mailing list 364 software will optionally insert 365 "Reply-To" with the name of the 366 list into messages distributed by 367 the list. 369 The opinion of the author of this 370 RFC is that you should avoid 371 using "Reply-To" until IETF has 372 defined less ambiguous 373 constructs. This opinion is 374 however also controversial and 375 not shared by everyone. 377 Used in Usenet News to indicate Followup-To: RFC 1036: 2.2.3, 378 that future discussions (=follow- not standardized 379 up) on an article should go to a for use in e-mail. 380 different set of newsgroups than 381 the replied-to article. The most 382 common usage is when an article 383 is posted to several newsgroups, 384 and further discussions is to 385 take place in only one of them. 387 In e-mail, this heading field is 388 used in a message which is sent 389 to both e-mail and Usenet News, 390 to show where follow-up in Usenet 391 news is wanted. The field does 392 not say anything about where 393 follow-up in e-mail is to be 394 sent. 396 Address to which notifications Errors-To:, Non-standard, 397 are to be sent and a request to Return- discouraged. 398 get delivery notifications. Receipt-To: 399 Internet standards recommend, 400 however, the use of RCPT TO and 401 Return-Path, not Errors-To, for 402 where delivery notifications are 403 to be sent, and a new standard 404 for delivery notifications 405 specifies how requests for 406 notifications are specified by a 407 new parameter "NOTIFY" to the 408 "RCPT TO" SMTP command. 410 An IETF group is working on a Disposition- Do not use until 411 standard for receipt notifica- Notification- the proposal from 412 tions (note that this is not the To: this IETF group is 413 same as delivery notifications). ready and accepted 414 This group is discussing this new by IETF. 415 heading field, but no agreement 416 has been reached yet. 418 Whether non-delivery report is Prevent- RFC 1327, not for 419 wanted at delivery error. Default NonDelivery- general usage. 420 is to want such a report. Report: 422 Whether a delivery report is Generate- RFC 1327, not for 423 wanted at successful delivery. Delivery- general usage. 424 Default is not to generate such a Report: 425 report. 427 Indicates whether the content of Content- RFC 1327, not for 428 a message is to be returned with Return general usage. 429 non-delivery notifications. 431 Indicates whether the content of RET in DRPT In forthcoming new 432 a message is to be returned with SMTP exten- Internet standard. 433 non-delivery notifications. sion 435 3.6 Message identification and 436 referral attributes 438 Unique ID of this message. Message-ID: RFC 822: 4.6.1. 440 Unique ID of one body part of the Content-ID: RFC 1521: 6.1. 441 content of a message. 443 Reference to message which this In-Reply-To: RFC 822: 4.6.2. 444 message is a reply to. 446 Reference to other related References: RFC 822: 4.6.3. 447 messages. 449 Reference to previous message Obsoletes: RFC 1327, not for 450 being corrected and replaced. general usage. 452 Used in Usenet News in similar Supersedes: Non-standard. 453 ways to the "Obsoletes" attribute 454 described above. 456 3.7 Other textual attributes 458 Search keys for data base Keywords: RFC 822: 4.7.1. 459 retrieval. 461 Title, heading, subject. Subject: RFC 822: 4.7.1. 463 Comments on a message. Comments: RFC 822: 4.7.2. 465 Description of a particular body Content- RFC 1521: 6.2. 466 part of a message. description: 468 Organization to which the sender Organization: RFC 1036: 2.2.8, 469 of this message belongs. not standardized 470 for use in e-mail. 472 See Organization above. Organisation: Non-standard. 474 Short text describing a longer Summary: RFC 1036: 2.2.10, 475 message. Warning: Some mail not standardized 476 systems will not display this for use in e-mail, 477 text to the recipient. Because of discouraged. 478 this, do not use this field for 479 text which you want to ensure 480 that the recipient gets. 482 A text string which identifies Content- RFC 1327, not for 483 the content of a message. identifier: general usage. 485 3.8 Attributes containing dates 486 and times 488 The time when a message was Delivery- RFC 1327, not for 489 delivered to its recipient. Date: general usage. 491 In Internet, the date when a Date: RFC 822: 5.1, 492 message was written, in X.400, RFC 1123: 5.2.14. 493 the time a message was submitted. 495 A suggested expiration date. Can Expires: RFC 1036: 2.2.4, 496 be used both to limit the time of not standardized 497 an article which is not for use in e-mail. 498 meaningful after a certain date, 499 and to extend the storage of 500 important articles. 502 Time at which a message loses its Expiry-Date: RFC 1327, not for 503 validity. general usage. 505 Latest time at which a reply is Reply-By: RFC 1327, not for 506 requested (not demanded). general usage. 508 3.9 Quality information 510 Can be "normal", "urgent" or "non- Priority: RFC 1327, not for 511 urgent" and can influence general usage. 512 transmission speed and delivery. 514 Sometimes used as a priority Precedence: Non-standard, 515 value which can influence controversial, 516 transmission speed and delivery. discouraged. 517 Common values are "bulk" and 518 "first-class". Other uses is to 519 control automatic replies and to 520 control return-of-content 521 facilities, and to stop mailing 522 list loops. 524 Can be high, normal or low and is Importance: RFC 1327, not for 525 only used in the recipient client general usage. 526 (UA). 528 Can be personal, private, company Sensitivity: RFC 1327, not for 529 confidential or absent. general usage. 531 Body parts are missing. Incomplete- RFC 1327, not for 532 Copy: general usage. 534 3.10 Language information 536 Can include a code for the Language: RFC 1327, not for 537 natural language used in a general usage. 538 message, e.g. "en" for English. 540 Can include a code for the Content- RFC 1766, proposed 541 natural language used in a Language: standard. 542 message, e.g. "en" for English. 544 3.11 Size information 546 Inserted by certain mailers to Content- Non-standard, 547 indicate the size in bytes of the length: discouraged. 548 message text. Can cause several 549 robustness and interoperability 550 problems and is not recommended. 552 Size of the message. Lines: RFC 1036: 2.2.12, 553 not standardized 554 for use in e-mail. 556 3.12 Conversion control 558 The body of this message may not Conversion: RFC 1327, not for 559 be converted from one character general usage. 560 set to another. 562 The body of this message may not Conversion- RFC 1327, not for 563 be converted from one character With-Loss: general usage. 564 set to another if information 565 will be lost. 567 3.13 Encoding information 569 Format of content (character set Content-Type: RFC 1049, 570 etc.) Note that the values for RFC 1123: 5.2.13, 571 this field are defined in RFC 1521: 4. 572 different ways in RFC 1049 and in 573 MIME (RFC 1521), look for the 574 "MIME-version" heading field to 575 understand if Content-Type is to 576 be interpreted according to RFC 577 1049 or according to MIME. The 578 MIME definition should be used in 579 generating mail. 581 Coding method used in content. Content- RFC 1521: 5. 582 Transfer- 583 Encoding 585 Coding method used in content. Encoding: RFC 1154, 586 RFC 1505, 587 for limited use. 589 3.14 Resent-attributes 591 When manually forwarding a Resent-Reply- RFC 822: C.3.3. 592 message, attributes referring to To:, 593 the forwarding, not to the Resent-From:, 594 original message. Note: MIME Resent- 595 specifies another way of Sender:, 596 resending messages, using the Resent-From:, 597 "Message" Content-Type. Resent-Date:, 598 Resent-To:, 599 Resent-cc:, 600 Resent-bcc:, 601 Resent- 602 Message-ID: 604 3.15 Miscellaneous 606 Name of file in which a copy of Fcc: Non-standard. 607 this message is stored. 609 Has been automatically forwarded. Auto- RFC 1327, not for 610 Forwarded: general usage. 612 Can be used in Internet mail to Discarded- RFC 1327, not for 613 indicate X.400 extensions which X400-IPMS- general usage. 614 could not be mapped to Internet Extensions: 615 mail format. 617 Can be used in Internet mail to Discarded- RFC 1327, not for 618 indicate X.400 extensions which X400-MTS- general usage. 619 could not be mapped to Internet Extensions: 620 mail format. 622 4. Acknowledgments 624 Harald Tveit Alvestrand, Keith Moore, Nick Smith and several other 625 people have helped me with compiling this list. I alone take 626 responsibility for any errors which may still be in the list. 628 An earlier version of this list has been published as part of [13]. 630 5. References 632 Ref. Author, title IETF status 633 (July 1995) 634 ----- --------------------------------------------- ----------- 635 - - 636 [1] J. Postel: "Simple Mail Transfer Protocol", Standard, 637 STD 10, RFC 821, August 1982. Recommended. 639 [2] D. Crocker: "Standard for the format of ARPA Standard, 640 Internet text messages." STD 11, RFC 822, Recommended. 641 August 1982. 643 [3] M.R. Horton, R. Adams: "Standard for Not an offi- 644 interchange of USENET messages", RFC 1036, cial IETF 645 December 1987. standard, 646 but in 647 reality a de- 648 facto 649 standard for 650 Usenet News. 652 [4] M. Sirbu: "A Content-Type header field for Standard, 653 internet messages", RFC 1049, March 1988. Recommended. 655 [5] R. Braden (editor): "Requirements for Standard, 656 Internet Hosts -- Application and Support", Required. 657 STD-3, RFC 1123, October 1989. 659 [6] D. Robinson, R. Ullman: "Encoding Header Non- 660 Field for Internet Messages", RFC 1154, April standard. 661 1990. 663 [7] S. Hardcastle-Kille: "Mapping between Proposed 664 X.400(1988) / ISO 10021 and RFC 822", RFC standard, 665 1327 May 1992. elective. 667 [8] H. Alvestrand & J. Romaguera: "Rules for Proposed 668 Downgrading Messages from X.400/88 to standard, 669 X.400/84 When MIME Content-Types are Present elective. 670 in the Messages", RFC 1496, August 1993. 672 [9] A. Costanzo: "Encoding Header Field for Non- 673 Internet Messages", RFC 1154, April 1990. standard. 675 [10] A. Costanzo, D. Robinson: "Encoding Header Experimental 676 Field for Internet Messages", RFC 1505, . 677 August 1993. 679 [11] N. Borenstein & N. Freed: "MIME (Multipurpose Draft 680 Internet Mail Extensions) Part One: Standard, 681 Mechanisms for Specifying and Describing the elective. 682 Format of Internet Message Bodies", RFC 1521, 683 Sept 1993. 685 [12] H. Alvestrand: "Tags for the Identification Proposed 686 of Languages", RFC 1766, February 1995. standard, 687 elective. 689 [13] J. Palme: "Electronic Mail", Artech House Non- 690 publishers, London-Boston January 1995. standard. 692 [14] R. Troost, S. Dorner: "Communicating Experimental 693 Presentation Information in Internet . 694 Messages: The Content-Disposition Header", 695 RFC 1806, June 1995. 697 6. Author's address 699 Jacob Palme Phone: +46-8-16 16 67 700 Stockholm University/KTH Fax: +46-8-783 08 29 701 Electrum 230 E-mail: jpalme@dsv.su.se 702 S-164 40 Kista, Sweden 703 Appendix A: 704 Attributes sorted by Internet RFC document in which they appear. 706 RFC 821 707 ------- 709 DATA 710 MAIL FROM 711 RCPT TO 713 RFC 822 714 ------- 716 Bcc 717 Cc 718 Comments 719 Date 720 From 721 In-Reply-To 722 Keywords 723 Message-ID 724 Received 725 References 726 Reply-To 727 Resent- 728 Resent-bcc 729 Resent-Date 730 Resent-From 731 Resent-From 732 Resent-Message-ID 733 Resent-Reply-To 734 Resent-ToResent-cc 735 Return-Path 736 Sender 737 Sender 738 Subject 739 To 741 RFC 1036 742 -------- 744 Approved 745 Control 746 Distribution 747 Expires 748 Followup-To 749 Lines 750 Newsgroups 751 Organization 752 Path 753 Summary 754 RFC 1049 755 -------- 757 Content-Type 759 RFC 1327 760 -------- 762 Alternate-recipient 763 Auto-Forwarded 764 Autoforwarded 765 Content-identifier 766 Content-Return 767 Conversion 768 Conversion-With-Loss 769 Delivery-Date 770 Discarded-X400-IPMS-Extensions 771 Discarded-X400-MTS-Extensions 772 Disclose-Recipients 773 DL-Expansion-History 774 Expiry-Date 775 Generate-Delivery-Report 776 Importance 777 Incomplete-Copy 778 Language 779 Message-Type Delivery 780 Obsoletes 781 Original-Encoded-Information-Types 782 Prevent-NonDelivery-Report 783 Priority 784 Reply-By 785 Report 786 Sensitivity 788 RFC 1505 789 -------- 791 Encoding 793 RFC 1521 794 -------- 796 Content-Description 797 Content-ID 798 Content-Transfer-Encoding 799 Content-Type 800 MIME-Version 802 RFC 1806 803 -------- 805 Content-Disposition 806 Not Internet standard 807 --------------------- 809 Apparently-to 810 Content-length 811 Encoding 812 Errors-To 813 Return-Receipt-To 814 Fax 815 Telefax 816 Fcc 817 Mail-System-Version 818 Mailer 819 Organisation 820 Originating-Client 821 Phone 822 Supersedes 823 Appendix B: 824 Alphabetical index 826 Section Heading-field 827 ------- ------------- 829 3.3 Alternate-Recipient 830 3.4 Apparently-To 831 3.4 Approved 832 3.16 Auto-Forwarded 833 3.4 Bcc 834 3.4 Cc 835 3.7 Comments 836 3.7 Content-Description 837 3.3 Content-Disposition 838 3.6 Content-ID 839 3.7 Content-identifier 840 3.10 Content-Language 841 3.11 Content-Length 842 3.5 Content-Return 843 3.13 Content-Transfer-Encoding 844 3.13 Content-Type 845 3.3 Control 846 3.12 Conversion 847 3.12 Conversion-With-Loss 848 3.3 DATA 849 3.8 Date 850 3.8 Delivery-Date 851 3.16 Discarded-X400-IPMS-Extensions 852 3.16 Discarded-X400-MTS-Extensions 853 3.3 Disclose-Recipients 854 3.5 Disposition-Notification-To 855 3.4 Distribution 856 3.3 DL-Expansion-History-Indication 857 3.13 Encoding 858 3.5 Errors-To 859 3.8 Expires 860 3.4 Fax 861 3.15 Fcc 862 3.5 Followup-To 863 3.4 From 864 3.5 Generate-Delivery-Report 865 3.9 Importance 866 3.6 In-Reply-To 867 3.9 Incomplete-Copy 868 3.7 Keywords 869 3.10 Language 870 3.11 Lines 871 3.2 MAIL FROM 872 3.4 Mail-System-Version 873 3.4 Mailer 874 3.6 Message-ID 875 3.3 Message-Type 876 3.3 MIME-Version 877 3.4 Newsgroups 878 3.6 Obsoletes 879 3.7 Organisation 880 3.7 Organization 881 3.3 Original-encoded-Information-Types 882 3.4 Originating-Client 883 3.3 Path 884 3.4 Phone 885 3.9 Precedence 886 3.5 Prevent-NonDelivery-Report 887 3.9 Priority 888 3.2 RCPT TO 889 3.3 Received 890 3.6 References 891 3.8 Reply-By 892 3.5 Reply-To 893 3.14 Resent- 894 3.5 RET in DRPT SMTP extension 895 3.2 Return-Path 896 3.5 Return-Receipt-To 897 3.4 Sender 898 3.9 Sensitivity 899 3.7 Subject 900 3.7 Summary 901 3.6 Supersedes 902 3.4 Telefax 903 3.4 To