📄 rfc2076.txt
字号:
Can include a code for the Content- RFC 1766, proposed natural language used in a Language: standard. message, e.g. "en" for English.3.11 Size information Inserted by certain mailers to Content- Non-standard, indicate the size in bytes of the Length: discouraged. message text. This is part of a format some mailers use when showing a message to its users, and this header should not be used when sending a message through the net. The use of this header in transmission of a message can cause several robustness and interoperability problems. Size of the message. Lines: RFC 1036: 2.2.12, not standardized for use in e-mail.Palme Informational [Page 14]RFC 2076 Internet Message Headers February 19973.12 Conversion control The body of this message may not Conversion: RFC 1327, not for be converted from one character general usage. set to another. Values: Prohibited and allowed. Non-standard variant of Content- Non-standard. Conversion: with the same values. Conversion: The body of this message may not Conversion- RFC 1327, not for be converted from one character With-Loss: general usage. set to another if information will be lost. Values: Prohibited and allowed.3.13 Encoding information Format of content (character set Content-Type: RFC 1049, etc.) Note that the values for RFC 1123: 5.2.13, this header are defined in RFC 1521: 4. different ways in RFC 1049 and in RFC 1766: 4.1 MIME (RFC 1521), look for the "MIME-version" header to understand if Content-Type is to be interpreted according to RFC 1049 or according to MIME. The MIME definition should be used in generating mail. RFC 1766 defines a parameter "difference" to this header. Information from the SGML entity Content-SGML- non-standard declaration corresponding to the Entity: entity contained in the body of the body part. Coding method used in a MIME Content- RFC 1521: 5. message body. Transfer- Encoding: Only used with the value Message-Type: RFC 1327, not for "Delivery Report" to indicates general usage. that this is a delivery report gatewayed from X.400.Palme Informational [Page 15]RFC 2076 Internet Message Headers February 1997 Used in several different ways by Encoding: RFC 1154, different mail systems. Some use RFC 1505, it for a kind of content-type experimental. information, some for encoding and length information, some for a kind of boundary information, some in other ways.3.14 Resent-headers When manually forwarding a Resent-Reply- RFC 822: C.3.3. message, headers referring to the To:, forwarding, not to the original Resent-From:, message. Note: MIME specifies Resent- another way of resending Sender:, messages, using the "Message" Resent-From:, Content-Type. Resent-Date:, Resent-To:, Resent-cc:, Resent-bcc:, Resent- Message-ID:3.15 Security and reliability Checksum of content to ensure Content-MD5: RFC 1864, proposed that it has not been modified. standard. Used in Usenet News to store Xref: RFC 1036: 2.2.13, information to avoid showing a only in Usenet reader the same article twice if News, not in e- it was sent to more than one mail. newsgroup. Only for local usage within one Usenet News server, should not be sent between servers.3.16 Miscellaneous Name of file in which a copy of Fcc: Non-standard. this message is stored. Has been automatically forwarded. Auto- RFC 1327, not for Forwarded: general usage.Palme Informational [Page 16]RFC 2076 Internet Message Headers February 1997 Can be used in Internet mail to Discarded- RFC 1327, not for indicate X.400 IPM extensions X400-IPMS- general usage. which could not be mapped to Extensions: Internet mail format. Can be used in Internet mail to Discarded- RFC 1327, not for indicate X.400 MTS extensions X400-MTS- general usage. which could not be mapped to Extensions: Internet mail format. This field is used by some mail Status: Non-standard, delivery systems to indicate the should never status of delivery for this appear in mail in message when stored. Common transit. values of this field are: U message is not downloaded and not deleted. R message is read or downloaded. O message is old but not deleted. D to be deleted. N new (a new message also sometimes is distinguished by not having any "Status:" header. Combinations of these characters can occur, such as "Status: OR" to indicate that a message is downloaded but not deleted.Palme Informational [Page 17]RFC 2076 Internet Message Headers February 19974. Acknowledgments Harald Tveit Alvestrand, Ned Freed, Olle Jdrnefors, Keith Moore, Nick Smith and several other people have helped me with compiling this list. I especially thank Ned Freed and Olle Jdrnefors for their thorough review and many helpful suggestions for improvements. I alone take responsibility for any errors which may still be in the list. An earlier version of this list has been published as part of [13].5. ReferencesRef. Author, title IETF status (July 1996)----- --------------------------------------------- -----------[1] J. Postel: "Simple Mail Transfer Protocol", Standard, STD 10, RFC 821, August 1982. Recommended[2] D. Crocker: "Standard for the format of ARPA Standard, Internet text messages." STD 11, RFC 822, Recommended August 1982.[3] M.R. Horton, R. Adams: "Standard for Not an offi- interchange of USENET messages", RFC 1036, cial IETF December 1987. standard, but in reality a de- facto standard for Usenet News[4] M. Sirbu: "A Content-Type header header for Standard, internet messages", RFC 1049, March 1988. Recommended, but can in the future be expected to be replaced by MIME[5] R. Braden (editor): "Requirements for Standard, Internet Hosts -- Application and Support", Required STD-3, RFC 1123, October 1989.[6] D. Robinson, R. Ullman: "Encoding Header Non-standard Header for Internet Messages", RFC 1154, April 1990.Palme Informational [Page 18]RFC 2076 Internet Message Headers February 1997[7] S. Hardcastle-Kille: "Mapping between Proposed X.400(1988) / ISO 10021 and RFC 822", RFC standard, 1327 May 1992. elective[8] H. Alvestrand & J. Romaguera: "Rules for Proposed Downgrading Messages from X.400/88 to standard, X.400/84 When MIME Content-Types are Present elective in the Messages", RFC 1496, August 1993.[9] A. Costanzo: "Encoding Header Header for Non-standard Internet Messages", RFC 1154, April 1990.[10] A. Costanzo, D. Robinson: "Encoding Header Experimental Header for Internet Messages", RFC 1505, August 1993.[11] N. Borenstein & N. Freed: "MIME (Multipurpose Draft Internet Mail Extensions) Part One: Standard, Mechanisms for Specifying and Describing the elective Format of Internet Message Bodies", RFC 1521, Sept 1993.[12] H. Alvestrand: "Tags for the Identification Proposed of Languages", RFC 1766, February 1995. standard, elective[13] J. Palme: "Electronic Mail", Artech House Non-standard publishers, London-Boston January 1995.[14] R. Troost, S. Dorner: "Communicating Experimental Presentation Information in Internet Messages: The Content-Disposition Header", RFC 1806, June 1995.[15] B. Kantor, P. Lapsley, "Network News Transfer Proposed Protocol: "A Proposed Standard for the Stream- standard Based Transmission of News", RFC 977, January 1986.[16] 1848 PS S. Crocker, N. Freed, J. Galvin, Proposed S. Murphy, "MIME Object Security Services", standard RFC 1848, March 1995.[17] J. Myers, M. Rose: The Content-MD5 Header Draft Header, RFC 1864, October 1995. standardPalme Informational [Page 19]RFC 2076 Internet Message Headers February 1997[18] M. Horton, UUCP mail interchange format Not an offi- standard, RFC 976, Januari 1986. cial IETF standard, but in reality a de- facto standard for Usenet News[19] T. Berners-Lee, R. Headering, H. Frystyk: Not an official Hypertext Transfer Protocol -- HTTP/1.0, IETF standard, RFC 1945, May 1996. but the defacto standard until the next version is published[20] G. Vaudreuil: Voice Profile for Internet Experimental Mail, RFC 1911, February 1996.[21] H. Spencer: News Article Format and Not even an Transmission, June 1994, RFC, but FTP://zoo.toronto.edu/pub/news.ps still widely FTP://zoo.toronto.edu/pub/news.txt.Z used and partly This document is often referenced under the almost a de- name "son-of-RFC1036". facto standard for Usenet News6. Author's Address Jacob Palme Phone: +46-8-16 16 67 Stockholm University/KTH Fax: +46-8-783 08 29 Electrum 230 E-mail: jpalme@dsv.su.se S-164 40 Kista, SwedenPalme Informational [Page 20]RFC 2076 Internet Message Headers February 1997Appendix A: Headers sorted by Internet RFC document in which they appear. RFC 822 ------- bcc cc Comments Date From
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -