From f3741b4b34fa29cfbe96fb20916b468749fe47e2 Mon Sep 17 00:00:00 2001 From: fukachan Date: Sat, 24 Feb 2001 05:50:06 +0000 Subject: Initial revision --- Documentation/en/I-D/draft-ietf-ldapbis-url-00.txt | 752 +++ doc/devel/I-D/draft-ietf-ldapbis-url-00.txt | 752 +++ doc/devel/rfc/rfc1123.txt | 5782 ++++++++++++++++++++ doc/devel/rfc/rfc1413.txt | 451 ++ doc/devel/rfc/rfc1428.txt | 339 ++ doc/devel/rfc/rfc1521.txt | 4539 +++++++++++++++ doc/devel/rfc/rfc1651.txt | 619 +++ doc/devel/rfc/rfc1869.txt | 619 +++ doc/devel/rfc/rfc1891.txt | 1739 ++++++ doc/devel/rfc/rfc1893.txt | 843 +++ doc/devel/rfc/rfc1985.txt | 395 ++ doc/devel/rfc/rfc2034.txt | 339 ++ doc/devel/rfc/rfc2254.txt | 451 ++ doc/devel/rfc/rfc2476.txt | 843 +++ doc/devel/rfc/rfc2487.txt | 451 ++ doc/devel/rfc/rfc2554.txt | 619 +++ doc/devel/rfc/rfc821.txt | 4050 ++++++++++++++ doc/devel/rfc/rfc822.txt | 2901 ++++++++++ doc/devel/rfc/rfc974.txt | 399 ++ 19 files changed, 26883 insertions(+) create mode 100644 Documentation/en/I-D/draft-ietf-ldapbis-url-00.txt create mode 100644 doc/devel/I-D/draft-ietf-ldapbis-url-00.txt create mode 100644 doc/devel/rfc/rfc1123.txt create mode 100644 doc/devel/rfc/rfc1413.txt create mode 100644 doc/devel/rfc/rfc1428.txt create mode 100644 doc/devel/rfc/rfc1521.txt create mode 100644 doc/devel/rfc/rfc1651.txt create mode 100644 doc/devel/rfc/rfc1869.txt create mode 100644 doc/devel/rfc/rfc1891.txt create mode 100644 doc/devel/rfc/rfc1893.txt create mode 100644 doc/devel/rfc/rfc1985.txt create mode 100644 doc/devel/rfc/rfc2034.txt create mode 100644 doc/devel/rfc/rfc2254.txt create mode 100644 doc/devel/rfc/rfc2476.txt create mode 100644 doc/devel/rfc/rfc2487.txt create mode 100644 doc/devel/rfc/rfc2554.txt create mode 100644 doc/devel/rfc/rfc821.txt create mode 100644 doc/devel/rfc/rfc822.txt create mode 100644 doc/devel/rfc/rfc974.txt diff --git a/Documentation/en/I-D/draft-ietf-ldapbis-url-00.txt b/Documentation/en/I-D/draft-ietf-ldapbis-url-00.txt new file mode 100644 index 00000000..515d2467 --- /dev/null +++ b/Documentation/en/I-D/draft-ietf-ldapbis-url-00.txt @@ -0,0 +1,752 @@ + + + + + + +Network Working Group Mark Smith, Editor +Request for Comments: DRAFT Netscape Communications Corp. +Obsoletes: RFC 2255 Tim Howes + Loudcloud, Inc. + + 21 February 2001 + + + The LDAP URL Format + + + + +1. Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. Internet-Drafts are working + documents of the Internet Engineering Task Force (IETF), its areas, + and its working groups. Note that other groups may also distribute + working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet- Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + Discussion of this document should take place on the LDAP (v3) + Revison (ldapbis) Working Group mailing list . After appropriate review and discussion, this + document will be submitted as a Standards Track replacement for RFC + 2255. + +Copyright Notice + + Copyright (C) The Internet Society (2001). All Rights Reserved. + +2. Abstract + + LDAP is the Lightweight Directory Access Protocol, defined in + [RFC2251], [RFC2253], and [RFC2252]. This document describes a + format for an LDAP Uniform Resource Locator. The format describes an + LDAP search operation used to retrieve information from an LDAP + + + +Smith & Howes Intended Category: Standards Track [Page 1] + +INTERNET-DRAFT The LDAP URL Format 21 February 2001 + + + directory, or, in the context of an LDAPv3 referral or reference, the + format describes a service where an LDAP operation may be progressed. + Note: not all of the parameters of the LDAP search operation + described in [RFC2251] can be expressed using the format defined in + this document. + + This document specifies the LDAP URL format for version 3 of LDAP and + clarifies how LDAP URLs are resolved. This document also defines an + extension mechanism for LDAP URLs, so that future documents can + extend their functionality, for example, to provide access to new + LDAPv3 extensions as they are defined. + + This document replaces RFC 2255. See Appendix A for a list of changes + relative to RFC 2255. + + The key words "MUST", "MAY", and "SHOULD" used in this document are + to be interpreted as described in [RFC2119]. + +3. URL Definition + + An LDAP URL begins with the protocol prefix "ldap" and is defined by + the following grammar, following the ABNF notation defined in + [RFC2234]. + + ldapurl = scheme "://" [hostport] ["/" + [dn ["?" [attributes] ["?" [scope] + ["?" [filter] ["?" extensions]]]]]] + scheme = "ldap" + hostport = + dn = + attributes = attrdesc *("," attrdesc) + attrdesc = / "*" + scope = "base" / "one" / "sub" + filter = + extensions = extension *("," extension) + extension = ["!"] extype ["=" exvalue] + extype = token / xtoken + exvalue = + token = + xtoken = "x-" token + + The "ldap" prefix indicates an entry or entries residing in the LDAP + server running on the given hostname at the given portnumber. + + The dn is an LDAP Distinguished Name using the string format + described in [RFC2253]. It identifies the base object of the LDAP + search or the target of a non-search operation. + + + + +Smith & Howes Intended Category: Standards Track [Page 2] + +INTERNET-DRAFT The LDAP URL Format 21 February 2001 + + + The attributes construct is used to indicate which attributes should + be returned from the entry or entries. Individual attrdesc names are + as defined for AttributeDescription in [RFC2251]. + + The scope construct is used to specify the scope of the search to + perform in the given LDAP server. The allowable scopes are "base" + for a base object search, "one" for a one-level search, or "sub" for + a subtree search. + + The filter is used to specify the search filter to apply to entries + within the specified scope during the search. It has the format + specified in [RFC2254]. + + The extensions construct provides the LDAP URL with an extensibility + mechanism, allowing the capabilities of the URL to be extended in the + future. Extensions are a simple comma-separated list of type=value + pairs, where the =value portion MAY be omitted for options not + requiring it. Each type=value pair is a separate extension. These + LDAP URL extensions are not necessarily related to any of the LDAPv3 + extension mechanisms. Extensions may be supported or unsupported by + the client resolving the URL. An extension prefixed with a '!' + character (ASCII 33) is critical. An extension not prefixed with a + '!' character is non-critical. + + If an extension is supported by the client, the client MUST obey the + extension if the extension is critical. The client SHOULD obey + supported extensions that are non-critical. + + If an extension is unsupported by the client, the client MUST NOT + process the URL if the extension is critical. If an unsupported + extension is non-critical, the client MUST ignore the extension. + + If a critical extension cannot be processed successfully by the + client, the client MUST NOT process the URL. If a non-critical + extension cannot be processed successfully by the client, the client + SHOULD ignore the extension. + + Extension types prefixed by "X-" or "x-" are reserved for use in + bilateral agreements between communicating parties. Other extension + types MUST be defined in this document, or in other standards-track + documents. + + One LDAP URL extension is defined in this document (see the section + "The Bindname Extension" below). Other documents or a future version + of this document MAY define other extensions. + + Note that characters that are not safe (e.g., spaces) (as defined in + section 2.1 of RFC 2396 [RFC2396]), and the single Reserved character + + + +Smith & Howes Intended Category: Standards Track [Page 3] + +INTERNET-DRAFT The LDAP URL Format 21 February 2001 + + + '?' occurring inside a dn, filter, or other element of an LDAP URL + MUST be escaped using the % method described in section 2.4 of RFC + 2396 [RFC2396]. If a comma character ',' occurs inside an extension + value, the character MUST also be escaped using the % method. + + +4. Defaults for Fields of the LDAP URL + + Some fields of the LDAP URL are optional, as described above. In the + absence of any other specification, the following general defaults + SHOULD be used when a field is absent. Note: other documents MAY + specify different defaulting rules; for example, section 4.1.11 of + [RFC 2251] specifies a different rule for determining the correct DN + to use when it is absent in an LDAP URL that is returned as a + referral. + + hostport + The default LDAP port is TCP port 389. If no hostport is given, + the client must have some apriori knowledge of an appropriate LDAP + server to contact. + + dn + If no dn is given, the default is the zero-length DN, "". + + attributes + If the attributes part is omitted, all user attributes of the + entry or entries should be requested (e.g., by setting the + attributes field AttributeDescriptionList in the LDAP search + request to a NULL list, or (in LDAPv3) by requesting the special + attribute name "*"). + + scope + If scope is omitted, a scope of "base" is assumed. + + filter + If filter is omitted, a filter of "(objectClass=*)" is assumed. + + extensions + If extensions is omitted, no extensions are assumed. + + +5. The Bindname Extension + + This section defines an LDAP URL extension for representing the + distinguished name for a client to use when authenticating to an LDAP + directory during resolution of an LDAP URL. Clients MAY implement + this extension. + + + + +Smith & Howes Intended Category: Standards Track [Page 4] + +INTERNET-DRAFT The LDAP URL Format 21 February 2001 + + + The extension type is "bindname". The extension value is the + distinguished name of the directory entry to authenticate as, in the + same form as described for dn in the grammar above. The dn may be the + NULL string to specify unauthenticated access. The extension may be + either critical (prefixed with a '!' character) or non-critical (not + prefixed with a '!' character). + + If the bindname extension is critical, the client resolving the URL + MUST authenticate to the directory using the given distinguished name + and an appropriate authentication method. Note that for a NULL + distinguished name, no bind MAY be required to obtain anonymous + access to the directory. If the extension is non-critical, the client + MAY bind to the directory using the given distinguished name. + +6. URL Processing + + This section describes how an LDAP URL SHOULD be resolved by a + client. + + First, the client obtains a connection to the LDAP server referenced + in the URL, or an LDAP server of the client's choice if no LDAP + server is explicitly referenced. This connection MAY be opened + specifically for the purpose of resolving the URL or the client MAY + reuse an already open connection if the open connection is compatible + with the URL. The connection MAY provide confidentiality, integrity, + or other services, e.g., using TLS. Use of security services is at + the client's discretion if not specified in the URL but is encouraged + if the request or any potential responses contains sensitive + information. If the URL represents a referral for an update + operation, security services SHOULD be used. + + + Next, the client authenticates itself to the LDAP server. This step + is optional, unless the URL contains a critical bindname extension + with a non-NULL value. If a bindname extension is given, the client + proceeds according to the section above. + + If a bindname extension is not specified, the client MAY bind to the + directory using an appropriate authentication method of its own + choosing (including NULL authentication). The client may interrogate + the server to determine the most appropriate method. + + Next, the client performs the LDAP search operation specified in the + URL. Additional fields in the LDAP protocol search request, such as + sizelimit, timelimit, deref, and anything else not specified or + defaulted in the URL specification, MAY be set at the client's + discretion. + + + + +Smith & Howes Intended Category: Standards Track [Page 5] + +INTERNET-DRAFT The LDAP URL Format 21 February 2001 + + + Once the search has completed, the client MAY close the connection to + the LDAP server, or the client MAY keep the connection open for + future use. + +7. Examples + + The following are some example LDAP URLs using the format defined + above. The first example is an LDAP URL referring to the University + of Michigan entry, available from an LDAP server of the client's + choosing: + + ldap:///o=University%20of%20Michigan,c=US + + The next example is an LDAP URL referring to the University of + Michigan entry in a particular ldap server: + + ldap://ldap1.example.net/o=University%20of%20Michigan,c=US + + Both of these URLs correspond to a base object search of the + "o=University of Michigan,c=US" entry using a filter of + "(objectclass=*)", requesting all attributes. + + The next example is an LDAP URL referring to only the postalAddress + attribute of the University of Michigan entry: + + ldap://ldap1.example.net/o=University%20of%20Michigan, + c=US?postalAddress + + The corresponding LDAP search operation is the same as in the + previous example, except that only the postalAddress attribute is + requested. + + The next example is an LDAP URL referring to the set of entries found + by querying the given LDAP server on port 6666 and doing a subtree + search of the University of Michigan for any entry with a common name + of "Babs Jensen", retrieving all attributes: + + ldap://ldap1.example.net:6666/o=University%20of%20Michigan, + c=US??sub?(cn=Babs%20Jensen) + + The next example is an LDAP URL referring to all children of the c=GB + entry: + + ldap://ldap1.example.com/c=GB?objectClass?one + + The objectClass attribute is requested to be returned along with the + entries, and the default filter of "(objectclass=*)" is used. + + + + +Smith & Howes Intended Category: Standards Track [Page 6] + +INTERNET-DRAFT The LDAP URL Format 21 February 2001 + + + The next example is an LDAP URL to retrieve the mail attribute for + the LDAP entry named "o=Question?,c=US" is given below, illustrating + the use of the escaping mechanism on the reserved character '?'. + + ldap://ldap2.example.com/o=Question%3f,c=US?mail + + The next example illustrates the interaction between LDAP and URL + quoting mechanisms. + + ldap://ldap3.example.com/o=Babsco,c=US???(int=%5c00%5c00%5c00%5c04) + + The filter in this example uses the LDAP escaping mechanism of \ to + encode three zero or null bytes in the value. In LDAP, the filter + would be written as (int=\00\00\00\04). Because the \ character must + be escaped in a URL, the \'s are escaped as %5c in the URL encoding. + + The final example shows the use of the bindname extension to specify + the dn a client should use for authentication when resolving the URL. + + ldap:///??sub??bindname=cn=Manager%2co=Foo + ldap:///??sub??!bindname=cn=Manager%2co=Foo + + The two URLs are the same, except that the second one marks the + bindname extension as critical. Notice the use of the % encoding + method to encode the comma in the distinguished name value in the + bindname extension. + +8. Security Considerations + + General URL security considerations discussed in RFC 2396 [RFC2396] + are relevant for LDAP URLs. + + The use of security mechanisms when processing LDAP URLs requires + particular care, since clients may encounter many different servers + via URLs, and since URLs are likely to be processed automatically, + without user intervention. A client SHOULD have a user-configurable + policy about which servers to connect to using which security + mechanisms, and SHOULD NOT make connections that are inconsistent + with this policy. If a client chooses to reuse an existing + connection when resolving one or more LDAP URL, it MUST ensure that + the connection is compatible with the URL and that no security + policies are violated. + + Sending authentication information, no matter the mechanism, may + violate a user's privacy requirements. In the absence of specific + policy permitting authentication information to be sent to a server, + a client should use an anonymous connection. (Note that clients + conforming to previous LDAP URL specifications, where all connections + + + +Smith & Howes Intended Category: Standards Track [Page 7] + +INTERNET-DRAFT The LDAP URL Format 21 February 2001 + + + are anonymous and unprotected, are consistent with this + specification; they simply have the default security policy.) Simply + opening a connection to another server may violate some users' + privacy requirements, so clients should provide the user with a way + to control URL processing. + + Some authentication methods, in particular reusable passwords sent to + the server, may reveal easily-abused information to the remote server + or to eavesdroppers in transit, and should not be used in URL + processing unless explicitly permitted by policy. Confirmation by + the human user of the use of authentication information is + appropriate in many circumstances. Use of strong authentication + methods that do not reveal sensitive information is much preferred. + If the URL represents a referral for an update operation, strong + authentication methods SHOULD be used. Please refer to the Security + Considerations section of [RFC2829] for more information. + + The LDAP URL format allows the specification of an arbitrary LDAP + search operation to be performed when evaluating the LDAP URL. + Following an LDAP URL may cause unexpected results, for example, the + retrieval of large amounts of data, the initiation of a long-lived + search, etc. The security implications of resolving an LDAP URL are + the same as those of resolving an LDAP search query. + +9. Acknowledgements + + The LDAP URL format was originally defined at the University of + Michigan. This material is based upon work supported by the National + Science Foundation under Grant No. NCR-9416667. The support of both + the University of Michigan and the National Science Foundation is + gratefully acknowledged. + + This document is an update to RFC 2255 by Tim Howes and Mark Smith. + Changes included in this revised specification are based upon + discussions among the authors, discussions within the LDAP (v3) + Revision Working Group (ldapbis), and discussions within other IETF + Working Groups. The contributions of individuals in these working + groups is gratefully acknowledged. Several people in particular have + made valuable comments on this document; RL "Bob" Morgan, Mark Wahl, + Kurt Zeilenga, and Jim Sermersheim deserve special thanks for their + contributions. + +10. References + + [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate + Requirement Levels," RFC 2119, March 1997. + + [RFC2234] Crocker, D., Overell, P., "Augmented BNF for Syntax + + + +Smith & Howes Intended Category: Standards Track [Page 8] + +INTERNET-DRAFT The LDAP URL Format 21 February 2001 + + + Specifications: ABNF", RFC 2234, November 1997. + + [RFC2251] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory + Access Protocol (v3)", RFC 2251, December 1997. + + [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, + "Lightweight Directory Access Protocol (v3): Attribute Syntax + Definitions", RFC 2252, December 1997. + + [RFC2253] Wahl, M., Kille, S., and T. Howes, "Lightweight Directory + Access Protocol (v3): UTF-8 String Representation of Distinguished + Names", RFC 2253, December 1997. + + [RFC2254] Howes, T., "A String Representation of LDAP Search + Filters", RFC 2254, December 1997. + + [RFC2396] Berners-Lee, T., Fielding, R., and Masinter, L., "Uniform + Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. + + [RFC2829] Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan, + "Authentication Methods for LDAP", RFC 2829, May 2000. + + +11. Authors' Address + + Mark Smith, Editor + Netscape Communications Corp. + Mailstop USCA17-201 + 4170 Network Circle + Santa Clara, CA 95054 + USA + +1 650 937-3477 + mcs@netscape.com + + Tim Howes + Loudcloud, Inc. + 599 N. Mathilda Ave. + Sunnyvale, CA 94086 + USA + +1 408 744-7509 + howes@loudcloud.com + +12. Full Copyright Statement + + Copyright (C) The Internet Society (2001). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + + + +Smith & Howes Intended Category: Standards Track [Page 9] + +INTERNET-DRAFT The LDAP URL Format 21 February 2001 + + + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +13. Appendix A: Changes Since RFC 2255 + +13.1. Technical Changes + + "URL Definition" section: added missing "*" as an alternative for the + attrdesc part of the URL. It is believed that existing + implementations of RFC 2255 already support this. Added angle + brackets around free-form prose in the "dn", "hostport", "attrdesc", + "filter", "exvalue", and "token" rules. Simplified the "xtoken" rule + by removing the "X-" option (case insensitivity is taken care of by + the ABNF). Reordered rules to more closely follow the order the + elements appear in the URL. + + +13.2. Editorial Changes + + "Abstract" section: changed the text indicate that RFC 2255 is + replaced by this document (instead of RFC 1959). Added text to + indicate that LDAP URLs are used for references and referrals. Fixed + typo (replaced the nonsense phrase "to perform to retrieve" with + "used to retrieve"). Added a note to let the reader know that not + all of the parameters of the LDAP search operation described in + [RFC2251] can be expressed using this format. + + IESG Note: removed note about lack of satisfactory mandatory + + + +Smith & Howes Intended Category: Standards Track [Page 10] + +INTERNET-DRAFT The LDAP URL Format 21 February 2001 + + + authentication mechanisms. + + "URL Definition" section: removed second copy of ldapurl grammar and + following two paragraphs (editorial error in RFC 2255). Fixed line + break within '!' sequence. Reworded last paragraph to clarify which + characters must be URL escaped. Added text to indicate that LDAP + URLs are used for references and referrals. Added text that refers + to the ABNF from RFC 2234. + + "Defaults for Fields of the LDAP URL" section: added; formed by + moving text about defaults out of the "URL Definition" section. + + "URL Processing" section: clarified that connections MAY be reused + only if the open connection is compatible with the URL. Added text + to indicate that use of security services is encouraged and that they + SHOULD be used when updates are involved. Removed "dn" from + discussion of authentication methods. Added note that the client MAY + interrogate the server to determine the most appropriate method. + + "Examples" section: Modified examples to use example.com and + example.net hostnames. Added missing '?' to the LDAP URL example + whose filter contains three null bytes. Removed space after one + comma within a DN. + + "Security Considerations" section: Added a note about connection + reuse. Added a note about using strong authentication methods for + updates. Added a reference to RFC 2829. Added note that simply + opening a connection may violate some users' privacy requirements. + + "Acknowledgements" section: added statement about this being an + update to RFC 2255. Added added Kurt Zeilenga and Jim Sermersheim. + + "References" section: changed from [1] style to [RFC2251] style + throughout the document. Added references to RFCs 2234 and 2829. + Updated RFC 1738 references to the appropriate sections within RFC + 2396. + + Header and "Authors' Addresses" sections: added "editor" next to Mark + Smith's name. Updated affiliation and contact information. + + Copyright: updated the year. + + "Appendix C: Loose Ends" section: added. + + "Table of Contents" section: added. + + + + + + +Smith & Howes Intended Category: Standards Track [Page 11] + +INTERNET-DRAFT The LDAP URL Format 21 February 2001 + + +14. Appendix B: Changes Since Previous Document Revision + + This appendix lists all changes relative to the last published + revision, draft-smith-ldapv3-url-update-01.txt. Note that these + changes are also included in Appendix A, but are included here for + those who have already reviewed draft-smith-ldapv3-url-update-01.txt. + + +14.1. Technical Changes + + "URL Definition" section: added angle brackets around free-form prose + in the "dn", "hostport", "attrdesc", "filter", "exvalue", and "token" + rules. Simplified the "xtoken" rule by removing the "X-" option + (case insensitivity is taken care of by the ABNF). Reordered rules + to more closely follow the order the elements appear in the URL. + + +14.2. Editorial Changes + + Header: changed document from an individual submission to an ldapbis + working group submission. Discussion referred to the ietf- + ldapbis@openldap.org mailing list. + + Header and "Authors' Addresses" sections: added "editor" next to Mark + Smith's name. + + "Abstract" section: fixed typo (replaced the nonsense phrase "to + perform to retrieve" with "used to retrieve"). Added a note to let + the reader know that not all of the parameters of the LDAP search + operation described in [RFC2251] can be expressed using this format. + + "URL Definition" section: added text that refers to the ABNF from RFC + 2234. + + "Defaults for Fields of the LDAP URL" section: added a note to + clarify that other specifications MAY specify different defaulting + rules. + + Copyright: changed the year to 2001. + + References: changed from [1] style to [RFC2251] style throughout the + document. Added a reference to RFC 2234. Updated RFC 1738 + references to the appropriate sections within RFC 2396. + + "Acknowledgements" section: added statement about this being an + update to RFC 2255. Added Jim Sermersheim. + + "Loose Ends" section: removed item about referencing RFC 2396 instead + + + +Smith & Howes Intended Category: Standards Track [Page 12] + +INTERNET-DRAFT The LDAP URL Format 21 February 2001 + + + of 1738 (done). Removed "Search URLs vs. Referral URLs" item (the + editor believe this has been resolved)." Added item about potentially + supporting userinfo in LDAP URLs. Added item about not supporting + all parameters of the LDAPv3 search operation. + + +15. Appendix C: Loose Ends + + Other Extensions: Suggestions for TLS and SASL URL extensions have + been made, but more discussion is needed about whether they are + needed, how they will be specified, and whether they should be added + to this document. + + We need to consider whether it makes sense to support constructs like + @: within the hostport field. We do not want + to preclude this in the future, but we may keep the details out of + this document. Note this specification uses the "hostport" construct + from RFC 2396, but not the "server" construct (which is the one that + contains "userinfo"): + + server = [ [ userinfo "@" ] hostport ] + hostport = host [ ":" port ] + + Therefore, it may be necessary to replace "hostport" with "server" in + this specification. + + Some parameters of the LDAPv3 search operation defined in section + 4.5.1 of RFC 2251 are not supported by the LDAP URL format, e.g., + derefAliases, sizeLimit, timeLimit, typesOnly, controls. Some + ldapbis working group participants would like to see them supported, + while others see this as "out of scope" for ldapbis. Support for + these options could be added using the extension mechanism. + + +This Internet Draft expires on 21 August 2001. + + + + + + + + + + + + + + + + +Smith & Howes Intended Category: Standards Track [Page 13] + + + +1. Status of this Memo............................................1 +2. Abstract.......................................................1 +3. URL Definition.................................................2 +4. Defaults for Fields of the LDAP URL............................4 +5. The Bindname Extension.........................................4 +6. URL Processing.................................................5 +7. Examples.......................................................6 +8. Security Considerations........................................7 +9. Acknowledgements...............................................8 +10. References.....................................................8 +11. Authors' Address...............................................9 +12. Full Copyright Statement.......................................9 +13. Appendix A: Changes Since RFC 2255.............................10 +13.1. Technical Changes...........................................10 +13.2. Editorial Changes...........................................10 +14. Appendix B: Changes Since Previous Document Revision...........12 +14.1. Technical Changes...........................................12 +14.2. Editorial Changes...........................................12 +15. Appendix C: Loose Ends.........................................13 diff --git a/doc/devel/I-D/draft-ietf-ldapbis-url-00.txt b/doc/devel/I-D/draft-ietf-ldapbis-url-00.txt new file mode 100644 index 00000000..515d2467 --- /dev/null +++ b/doc/devel/I-D/draft-ietf-ldapbis-url-00.txt @@ -0,0 +1,752 @@ + + + + + + +Network Working Group Mark Smith, Editor +Request for Comments: DRAFT Netscape Communications Corp. +Obsoletes: RFC 2255 Tim Howes + Loudcloud, Inc. + + 21 February 2001 + + + The LDAP URL Format + + + + +1. Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. Internet-Drafts are working + documents of the Internet Engineering Task Force (IETF), its areas, + and its working groups. Note that other groups may also distribute + working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet- Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + Discussion of this document should take place on the LDAP (v3) + Revison (ldapbis) Working Group mailing list . After appropriate review and discussion, this + document will be submitted as a Standards Track replacement for RFC + 2255. + +Copyright Notice + + Copyright (C) The Internet Society (2001). All Rights Reserved. + +2. Abstract + + LDAP is the Lightweight Directory Access Protocol, defined in + [RFC2251], [RFC2253], and [RFC2252]. This document describes a + format for an LDAP Uniform Resource Locator. The format describes an + LDAP search operation used to retrieve information from an LDAP + + + +Smith & Howes Intended Category: Standards Track [Page 1] + +INTERNET-DRAFT The LDAP URL Format 21 February 2001 + + + directory, or, in the context of an LDAPv3 referral or reference, the + format describes a service where an LDAP operation may be progressed. + Note: not all of the parameters of the LDAP search operation + described in [RFC2251] can be expressed using the format defined in + this document. + + This document specifies the LDAP URL format for version 3 of LDAP and + clarifies how LDAP URLs are resolved. This document also defines an + extension mechanism for LDAP URLs, so that future documents can + extend their functionality, for example, to provide access to new + LDAPv3 extensions as they are defined. + + This document replaces RFC 2255. See Appendix A for a list of changes + relative to RFC 2255. + + The key words "MUST", "MAY", and "SHOULD" used in this document are + to be interpreted as described in [RFC2119]. + +3. URL Definition + + An LDAP URL begins with the protocol prefix "ldap" and is defined by + the following grammar, following the ABNF notation defined in + [RFC2234]. + + ldapurl = scheme "://" [hostport] ["/" + [dn ["?" [attributes] ["?" [scope] + ["?" [filter] ["?" extensions]]]]]] + scheme = "ldap" + hostport = + dn = + attributes = attrdesc *("," attrdesc) + attrdesc = / "*" + scope = "base" / "one" / "sub" + filter = + extensions = extension *("," extension) + extension = ["!"] extype ["=" exvalue] + extype = token / xtoken + exvalue = + token = + xtoken = "x-" token + + The "ldap" prefix indicates an entry or entries residing in the LDAP + server running on the given hostname at the given portnumber. + + The dn is an LDAP Distinguished Name using the string format + described in [RFC2253]. It identifies the base object of the LDAP + search or the target of a non-search operation. + + + + +Smith & Howes Intended Category: Standards Track [Page 2] + +INTERNET-DRAFT The LDAP URL Format 21 February 2001 + + + The attributes construct is used to indicate which attributes should + be returned from the entry or entries. Individual attrdesc names are + as defined for AttributeDescription in [RFC2251]. + + The scope construct is used to specify the scope of the search to + perform in the given LDAP server. The allowable scopes are "base" + for a base object search, "one" for a one-level search, or "sub" for + a subtree search. + + The filter is used to specify the search filter to apply to entries + within the specified scope during the search. It has the format + specified in [RFC2254]. + + The extensions construct provides the LDAP URL with an extensibility + mechanism, allowing the capabilities of the URL to be extended in the + future. Extensions are a simple comma-separated list of type=value + pairs, where the =value portion MAY be omitted for options not + requiring it. Each type=value pair is a separate extension. These + LDAP URL extensions are not necessarily related to any of the LDAPv3 + extension mechanisms. Extensions may be supported or unsupported by + the client resolving the URL. An extension prefixed with a '!' + character (ASCII 33) is critical. An extension not prefixed with a + '!' character is non-critical. + + If an extension is supported by the client, the client MUST obey the + extension if the extension is critical. The client SHOULD obey + supported extensions that are non-critical. + + If an extension is unsupported by the client, the client MUST NOT + process the URL if the extension is critical. If an unsupported + extension is non-critical, the client MUST ignore the extension. + + If a critical extension cannot be processed successfully by the + client, the client MUST NOT process the URL. If a non-critical + extension cannot be processed successfully by the client, the client + SHOULD ignore the extension. + + Extension types prefixed by "X-" or "x-" are reserved for use in + bilateral agreements between communicating parties. Other extension + types MUST be defined in this document, or in other standards-track + documents. + + One LDAP URL extension is defined in this document (see the section + "The Bindname Extension" below). Other documents or a future version + of this document MAY define other extensions. + + Note that characters that are not safe (e.g., spaces) (as defined in + section 2.1 of RFC 2396 [RFC2396]), and the single Reserved character + + + +Smith & Howes Intended Category: Standards Track [Page 3] + +INTERNET-DRAFT The LDAP URL Format 21 February 2001 + + + '?' occurring inside a dn, filter, or other element of an LDAP URL + MUST be escaped using the % method described in section 2.4 of RFC + 2396 [RFC2396]. If a comma character ',' occurs inside an extension + value, the character MUST also be escaped using the % method. + + +4. Defaults for Fields of the LDAP URL + + Some fields of the LDAP URL are optional, as described above. In the + absence of any other specification, the following general defaults + SHOULD be used when a field is absent. Note: other documents MAY + specify different defaulting rules; for example, section 4.1.11 of + [RFC 2251] specifies a different rule for determining the correct DN + to use when it is absent in an LDAP URL that is returned as a + referral. + + hostport + The default LDAP port is TCP port 389. If no hostport is given, + the client must have some apriori knowledge of an appropriate LDAP + server to contact. + + dn + If no dn is given, the default is the zero-length DN, "". + + attributes + If the attributes part is omitted, all user attributes of the + entry or entries should be requested (e.g., by setting the + attributes field AttributeDescriptionList in the LDAP search + request to a NULL list, or (in LDAPv3) by requesting the special + attribute name "*"). + + scope + If scope is omitted, a scope of "base" is assumed. + + filter + If filter is omitted, a filter of "(objectClass=*)" is assumed. + + extensions + If extensions is omitted, no extensions are assumed. + + +5. The Bindname Extension + + This section defines an LDAP URL extension for representing the + distinguished name for a client to use when authenticating to an LDAP + directory during resolution of an LDAP URL. Clients MAY implement + this extension. + + + + +Smith & Howes Intended Category: Standards Track [Page 4] + +INTERNET-DRAFT The LDAP URL Format 21 February 2001 + + + The extension type is "bindname". The extension value is the + distinguished name of the directory entry to authenticate as, in the + same form as described for dn in the grammar above. The dn may be the + NULL string to specify unauthenticated access. The extension may be + either critical (prefixed with a '!' character) or non-critical (not + prefixed with a '!' character). + + If the bindname extension is critical, the client resolving the URL + MUST authenticate to the directory using the given distinguished name + and an appropriate authentication method. Note that for a NULL + distinguished name, no bind MAY be required to obtain anonymous + access to the directory. If the extension is non-critical, the client + MAY bind to the directory using the given distinguished name. + +6. URL Processing + + This section describes how an LDAP URL SHOULD be resolved by a + client. + + First, the client obtains a connection to the LDAP server referenced + in the URL, or an LDAP server of the client's choice if no LDAP + server is explicitly referenced. This connection MAY be opened + specifically for the purpose of resolving the URL or the client MAY + reuse an already open connection if the open connection is compatible + with the URL. The connection MAY provide confidentiality, integrity, + or other services, e.g., using TLS. Use of security services is at + the client's discretion if not specified in the URL but is encouraged + if the request or any potential responses contains sensitive + information. If the URL represents a referral for an update + operation, security services SHOULD be used. + + + Next, the client authenticates itself to the LDAP server. This step + is optional, unless the URL contains a critical bindname extension + with a non-NULL value. If a bindname extension is given, the client + proceeds according to the section above. + + If a bindname extension is not specified, the client MAY bind to the + directory using an appropriate authentication method of its own + choosing (including NULL authentication). The client may interrogate + the server to determine the most appropriate method. + + Next, the client performs the LDAP search operation specified in the + URL. Additional fields in the LDAP protocol search request, such as + sizelimit, timelimit, deref, and anything else not specified or + defaulted in the URL specification, MAY be set at the client's + discretion. + + + + +Smith & Howes Intended Category: Standards Track [Page 5] + +INTERNET-DRAFT The LDAP URL Format 21 February 2001 + + + Once the search has completed, the client MAY close the connection to + the LDAP server, or the client MAY keep the connection open for + future use. + +7. Examples + + The following are some example LDAP URLs using the format defined + above. The first example is an LDAP URL referring to the University + of Michigan entry, available from an LDAP server of the client's + choosing: + + ldap:///o=University%20of%20Michigan,c=US + + The next example is an LDAP URL referring to the University of + Michigan entry in a particular ldap server: + + ldap://ldap1.example.net/o=University%20of%20Michigan,c=US + + Both of these URLs correspond to a base object search of the + "o=University of Michigan,c=US" entry using a filter of + "(objectclass=*)", requesting all attributes. + + The next example is an LDAP URL referring to only the postalAddress + attribute of the University of Michigan entry: + + ldap://ldap1.example.net/o=University%20of%20Michigan, + c=US?postalAddress + + The corresponding LDAP search operation is the same as in the + previous example, except that only the postalAddress attribute is + requested. + + The next example is an LDAP URL referring to the set of entries found + by querying the given LDAP server on port 6666 and doing a subtree + search of the University of Michigan for any entry with a common name + of "Babs Jensen", retrieving all attributes: + + ldap://ldap1.example.net:6666/o=University%20of%20Michigan, + c=US??sub?(cn=Babs%20Jensen) + + The next example is an LDAP URL referring to all children of the c=GB + entry: + + ldap://ldap1.example.com/c=GB?objectClass?one + + The objectClass attribute is requested to be returned along with the + entries, and the default filter of "(objectclass=*)" is used. + + + + +Smith & Howes Intended Category: Standards Track [Page 6] + +INTERNET-DRAFT The LDAP URL Format 21 February 2001 + + + The next example is an LDAP URL to retrieve the mail attribute for + the LDAP entry named "o=Question?,c=US" is given below, illustrating + the use of the escaping mechanism on the reserved character '?'. + + ldap://ldap2.example.com/o=Question%3f,c=US?mail + + The next example illustrates the interaction between LDAP and URL + quoting mechanisms. + + ldap://ldap3.example.com/o=Babsco,c=US???(int=%5c00%5c00%5c00%5c04) + + The filter in this example uses the LDAP escaping mechanism of \ to + encode three zero or null bytes in the value. In LDAP, the filter + would be written as (int=\00\00\00\04). Because the \ character must + be escaped in a URL, the \'s are escaped as %5c in the URL encoding. + + The final example shows the use of the bindname extension to specify + the dn a client should use for authentication when resolving the URL. + + ldap:///??sub??bindname=cn=Manager%2co=Foo + ldap:///??sub??!bindname=cn=Manager%2co=Foo + + The two URLs are the same, except that the second one marks the + bindname extension as critical. Notice the use of the % encoding + method to encode the comma in the distinguished name value in the + bindname extension. + +8. Security Considerations + + General URL security considerations discussed in RFC 2396 [RFC2396] + are relevant for LDAP URLs. + + The use of security mechanisms when processing LDAP URLs requires + particular care, since clients may encounter many different servers + via URLs, and since URLs are likely to be processed automatically, + without user intervention. A client SHOULD have a user-configurable + policy about which servers to connect to using which security + mechanisms, and SHOULD NOT make connections that are inconsistent + with this policy. If a client chooses to reuse an existing + connection when resolving one or more LDAP URL, it MUST ensure that + the connection is compatible with the URL and that no security + policies are violated. + + Sending authentication information, no matter the mechanism, may + violate a user's privacy requirements. In the absence of specific + policy permitting authentication information to be sent to a server, + a client should use an anonymous connection. (Note that clients + conforming to previous LDAP URL specifications, where all connections + + + +Smith & Howes Intended Category: Standards Track [Page 7] + +INTERNET-DRAFT The LDAP URL Format 21 February 2001 + + + are anonymous and unprotected, are consistent with this + specification; they simply have the default security policy.) Simply + opening a connection to another server may violate some users' + privacy requirements, so clients should provide the user with a way + to control URL processing. + + Some authentication methods, in particular reusable passwords sent to + the server, may reveal easily-abused information to the remote server + or to eavesdroppers in transit, and should not be used in URL + processing unless explicitly permitted by policy. Confirmation by + the human user of the use of authentication information is + appropriate in many circumstances. Use of strong authentication + methods that do not reveal sensitive information is much preferred. + If the URL represents a referral for an update operation, strong + authentication methods SHOULD be used. Please refer to the Security + Considerations section of [RFC2829] for more information. + + The LDAP URL format allows the specification of an arbitrary LDAP + search operation to be performed when evaluating the LDAP URL. + Following an LDAP URL may cause unexpected results, for example, the + retrieval of large amounts of data, the initiation of a long-lived + search, etc. The security implications of resolving an LDAP URL are + the same as those of resolving an LDAP search query. + +9. Acknowledgements + + The LDAP URL format was originally defined at the University of + Michigan. This material is based upon work supported by the National + Science Foundation under Grant No. NCR-9416667. The support of both + the University of Michigan and the National Science Foundation is + gratefully acknowledged. + + This document is an update to RFC 2255 by Tim Howes and Mark Smith. + Changes included in this revised specification are based upon + discussions among the authors, discussions within the LDAP (v3) + Revision Working Group (ldapbis), and discussions within other IETF + Working Groups. The contributions of individuals in these working + groups is gratefully acknowledged. Several people in particular have + made valuable comments on this document; RL "Bob" Morgan, Mark Wahl, + Kurt Zeilenga, and Jim Sermersheim deserve special thanks for their + contributions. + +10. References + + [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate + Requirement Levels," RFC 2119, March 1997. + + [RFC2234] Crocker, D., Overell, P., "Augmented BNF for Syntax + + + +Smith & Howes Intended Category: Standards Track [Page 8] + +INTERNET-DRAFT The LDAP URL Format 21 February 2001 + + + Specifications: ABNF", RFC 2234, November 1997. + + [RFC2251] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory + Access Protocol (v3)", RFC 2251, December 1997. + + [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, + "Lightweight Directory Access Protocol (v3): Attribute Syntax + Definitions", RFC 2252, December 1997. + + [RFC2253] Wahl, M., Kille, S., and T. Howes, "Lightweight Directory + Access Protocol (v3): UTF-8 String Representation of Distinguished + Names", RFC 2253, December 1997. + + [RFC2254] Howes, T., "A String Representation of LDAP Search + Filters", RFC 2254, December 1997. + + [RFC2396] Berners-Lee, T., Fielding, R., and Masinter, L., "Uniform + Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. + + [RFC2829] Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan, + "Authentication Methods for LDAP", RFC 2829, May 2000. + + +11. Authors' Address + + Mark Smith, Editor + Netscape Communications Corp. + Mailstop USCA17-201 + 4170 Network Circle + Santa Clara, CA 95054 + USA + +1 650 937-3477 + mcs@netscape.com + + Tim Howes + Loudcloud, Inc. + 599 N. Mathilda Ave. + Sunnyvale, CA 94086 + USA + +1 408 744-7509 + howes@loudcloud.com + +12. Full Copyright Statement + + Copyright (C) The Internet Society (2001). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + + + +Smith & Howes Intended Category: Standards Track [Page 9] + +INTERNET-DRAFT The LDAP URL Format 21 February 2001 + + + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +13. Appendix A: Changes Since RFC 2255 + +13.1. Technical Changes + + "URL Definition" section: added missing "*" as an alternative for the + attrdesc part of the URL. It is believed that existing + implementations of RFC 2255 already support this. Added angle + brackets around free-form prose in the "dn", "hostport", "attrdesc", + "filter", "exvalue", and "token" rules. Simplified the "xtoken" rule + by removing the "X-" option (case insensitivity is taken care of by + the ABNF). Reordered rules to more closely follow the order the + elements appear in the URL. + + +13.2. Editorial Changes + + "Abstract" section: changed the text indicate that RFC 2255 is + replaced by this document (instead of RFC 1959). Added text to + indicate that LDAP URLs are used for references and referrals. Fixed + typo (replaced the nonsense phrase "to perform to retrieve" with + "used to retrieve"). Added a note to let the reader know that not + all of the parameters of the LDAP search operation described in + [RFC2251] can be expressed using this format. + + IESG Note: removed note about lack of satisfactory mandatory + + + +Smith & Howes Intended Category: Standards Track [Page 10] + +INTERNET-DRAFT The LDAP URL Format 21 February 2001 + + + authentication mechanisms. + + "URL Definition" section: removed second copy of ldapurl grammar and + following two paragraphs (editorial error in RFC 2255). Fixed line + break within '!' sequence. Reworded last paragraph to clarify which + characters must be URL escaped. Added text to indicate that LDAP + URLs are used for references and referrals. Added text that refers + to the ABNF from RFC 2234. + + "Defaults for Fields of the LDAP URL" section: added; formed by + moving text about defaults out of the "URL Definition" section. + + "URL Processing" section: clarified that connections MAY be reused + only if the open connection is compatible with the URL. Added text + to indicate that use of security services is encouraged and that they + SHOULD be used when updates are involved. Removed "dn" from + discussion of authentication methods. Added note that the client MAY + interrogate the server to determine the most appropriate method. + + "Examples" section: Modified examples to use example.com and + example.net hostnames. Added missing '?' to the LDAP URL example + whose filter contains three null bytes. Removed space after one + comma within a DN. + + "Security Considerations" section: Added a note about connection + reuse. Added a note about using strong authentication methods for + updates. Added a reference to RFC 2829. Added note that simply + opening a connection may violate some users' privacy requirements. + + "Acknowledgements" section: added statement about this being an + update to RFC 2255. Added added Kurt Zeilenga and Jim Sermersheim. + + "References" section: changed from [1] style to [RFC2251] style + throughout the document. Added references to RFCs 2234 and 2829. + Updated RFC 1738 references to the appropriate sections within RFC + 2396. + + Header and "Authors' Addresses" sections: added "editor" next to Mark + Smith's name. Updated affiliation and contact information. + + Copyright: updated the year. + + "Appendix C: Loose Ends" section: added. + + "Table of Contents" section: added. + + + + + + +Smith & Howes Intended Category: Standards Track [Page 11] + +INTERNET-DRAFT The LDAP URL Format 21 February 2001 + + +14. Appendix B: Changes Since Previous Document Revision + + This appendix lists all changes relative to the last published + revision, draft-smith-ldapv3-url-update-01.txt. Note that these + changes are also included in Appendix A, but are included here for + those who have already reviewed draft-smith-ldapv3-url-update-01.txt. + + +14.1. Technical Changes + + "URL Definition" section: added angle brackets around free-form prose + in the "dn", "hostport", "attrdesc", "filter", "exvalue", and "token" + rules. Simplified the "xtoken" rule by removing the "X-" option + (case insensitivity is taken care of by the ABNF). Reordered rules + to more closely follow the order the elements appear in the URL. + + +14.2. Editorial Changes + + Header: changed document from an individual submission to an ldapbis + working group submission. Discussion referred to the ietf- + ldapbis@openldap.org mailing list. + + Header and "Authors' Addresses" sections: added "editor" next to Mark + Smith's name. + + "Abstract" section: fixed typo (replaced the nonsense phrase "to + perform to retrieve" with "used to retrieve"). Added a note to let + the reader know that not all of the parameters of the LDAP search + operation described in [RFC2251] can be expressed using this format. + + "URL Definition" section: added text that refers to the ABNF from RFC + 2234. + + "Defaults for Fields of the LDAP URL" section: added a note to + clarify that other specifications MAY specify different defaulting + rules. + + Copyright: changed the year to 2001. + + References: changed from [1] style to [RFC2251] style throughout the + document. Added a reference to RFC 2234. Updated RFC 1738 + references to the appropriate sections within RFC 2396. + + "Acknowledgements" section: added statement about this being an + update to RFC 2255. Added Jim Sermersheim. + + "Loose Ends" section: removed item about referencing RFC 2396 instead + + + +Smith & Howes Intended Category: Standards Track [Page 12] + +INTERNET-DRAFT The LDAP URL Format 21 February 2001 + + + of 1738 (done). Removed "Search URLs vs. Referral URLs" item (the + editor believe this has been resolved)." Added item about potentially + supporting userinfo in LDAP URLs. Added item about not supporting + all parameters of the LDAPv3 search operation. + + +15. Appendix C: Loose Ends + + Other Extensions: Suggestions for TLS and SASL URL extensions have + been made, but more discussion is needed about whether they are + needed, how they will be specified, and whether they should be added + to this document. + + We need to consider whether it makes sense to support constructs like + @: within the hostport field. We do not want + to preclude this in the future, but we may keep the details out of + this document. Note this specification uses the "hostport" construct + from RFC 2396, but not the "server" construct (which is the one that + contains "userinfo"): + + server = [ [ userinfo "@" ] hostport ] + hostport = host [ ":" port ] + + Therefore, it may be necessary to replace "hostport" with "server" in + this specification. + + Some parameters of the LDAPv3 search operation defined in section + 4.5.1 of RFC 2251 are not supported by the LDAP URL format, e.g., + derefAliases, sizeLimit, timeLimit, typesOnly, controls. Some + ldapbis working group participants would like to see them supported, + while others see this as "out of scope" for ldapbis. Support for + these options could be added using the extension mechanism. + + +This Internet Draft expires on 21 August 2001. + + + + + + + + + + + + + + + + +Smith & Howes Intended Category: Standards Track [Page 13] + + + +1. Status of this Memo............................................1 +2. Abstract.......................................................1 +3. URL Definition.................................................2 +4. Defaults for Fields of the LDAP URL............................4 +5. The Bindname Extension.........................................4 +6. URL Processing.................................................5 +7. Examples.......................................................6 +8. Security Considerations........................................7 +9. Acknowledgements...............................................8 +10. References.....................................................8 +11. Authors' Address...............................................9 +12. Full Copyright Statement.......................................9 +13. Appendix A: Changes Since RFC 2255.............................10 +13.1. Technical Changes...........................................10 +13.2. Editorial Changes...........................................10 +14. Appendix B: Changes Since Previous Document Revision...........12 +14.1. Technical Changes...........................................12 +14.2. Editorial Changes...........................................12 +15. Appendix C: Loose Ends.........................................13 diff --git a/doc/devel/rfc/rfc1123.txt b/doc/devel/rfc/rfc1123.txt new file mode 100644 index 00000000..51cdf83c --- /dev/null +++ b/doc/devel/rfc/rfc1123.txt @@ -0,0 +1,5782 @@ + + + + + + +Network Working Group Internet Engineering Task Force +Request for Comments: 1123 R. Braden, Editor + October 1989 + + + Requirements for Internet Hosts -- Application and Support + +Status of This Memo + + This RFC is an official specification for the Internet community. It + incorporates by reference, amends, corrects, and supplements the + primary protocol standards documents relating to hosts. Distribution + of this document is unlimited. + +Summary + + This RFC is one of a pair that defines and discusses the requirements + for Internet host software. This RFC covers the application and + support protocols; its companion RFC-1122 covers the communication + protocol layers: link layer, IP layer, and transport layer. + + + + Table of Contents + + + + + 1. INTRODUCTION ............................................... 5 + 1.1 The Internet Architecture .............................. 6 + 1.2 General Considerations ................................. 6 + 1.2.1 Continuing Internet Evolution ..................... 6 + 1.2.2 Robustness Principle .............................. 7 + 1.2.3 Error Logging ..................................... 8 + 1.2.4 Configuration ..................................... 8 + 1.3 Reading this Document .................................. 10 + 1.3.1 Organization ...................................... 10 + 1.3.2 Requirements ...................................... 10 + 1.3.3 Terminology ....................................... 11 + 1.4 Acknowledgments ........................................ 12 + + 2. GENERAL ISSUES ............................................. 13 + 2.1 Host Names and Numbers ................................. 13 + 2.2 Using Domain Name Service .............................. 13 + 2.3 Applications on Multihomed hosts ....................... 14 + 2.4 Type-of-Service ........................................ 14 + 2.5 GENERAL APPLICATION REQUIREMENTS SUMMARY ............... 15 + + + + +Internet Engineering Task Force [Page 1] + + + + +RFC1123 INTRODUCTION October 1989 + + + 3. REMOTE LOGIN -- TELNET PROTOCOL ............................ 16 + 3.1 INTRODUCTION ........................................... 16 + 3.2 PROTOCOL WALK-THROUGH .................................. 16 + 3.2.1 Option Negotiation ................................ 16 + 3.2.2 Telnet Go-Ahead Function .......................... 16 + 3.2.3 Control Functions ................................. 17 + 3.2.4 Telnet "Synch" Signal ............................. 18 + 3.2.5 NVT Printer and Keyboard .......................... 19 + 3.2.6 Telnet Command Structure .......................... 20 + 3.2.7 Telnet Binary Option .............................. 20 + 3.2.8 Telnet Terminal-Type Option ....................... 20 + 3.3 SPECIFIC ISSUES ........................................ 21 + 3.3.1 Telnet End-of-Line Convention ..................... 21 + 3.3.2 Data Entry Terminals .............................. 23 + 3.3.3 Option Requirements ............................... 24 + 3.3.4 Option Initiation ................................. 24 + 3.3.5 Telnet Linemode Option ............................ 25 + 3.4 TELNET/USER INTERFACE .................................. 25 + 3.4.1 Character Set Transparency ........................ 25 + 3.4.2 Telnet Commands ................................... 26 + 3.4.3 TCP Connection Errors ............................. 26 + 3.4.4 Non-Default Telnet Contact Port ................... 26 + 3.4.5 Flushing Output ................................... 26 + 3.5. TELNET REQUIREMENTS SUMMARY ........................... 27 + + 4. FILE TRANSFER .............................................. 29 + 4.1 FILE TRANSFER PROTOCOL -- FTP .......................... 29 + 4.1.1 INTRODUCTION ...................................... 29 + 4.1.2. PROTOCOL WALK-THROUGH ............................ 29 + 4.1.2.1 LOCAL Type ................................... 29 + 4.1.2.2 Telnet Format Control ........................ 30 + 4.1.2.3 Page Structure ............................... 30 + 4.1.2.4 Data Structure Transformations ............... 30 + 4.1.2.5 Data Connection Management ................... 31 + 4.1.2.6 PASV Command ................................. 31 + 4.1.2.7 LIST and NLST Commands ....................... 31 + 4.1.2.8 SITE Command ................................. 32 + 4.1.2.9 STOU Command ................................. 32 + 4.1.2.10 Telnet End-of-line Code ..................... 32 + 4.1.2.11 FTP Replies ................................. 33 + 4.1.2.12 Connections ................................. 34 + 4.1.2.13 Minimum Implementation; RFC-959 Section ..... 34 + 4.1.3 SPECIFIC ISSUES ................................... 35 + 4.1.3.1 Non-standard Command Verbs ................... 35 + 4.1.3.2 Idle Timeout ................................. 36 + 4.1.3.3 Concurrency of Data and Control .............. 36 + 4.1.3.4 FTP Restart Mechanism ........................ 36 + 4.1.4 FTP/USER INTERFACE ................................ 39 + + + +Internet Engineering Task Force [Page 2] + + + + +RFC1123 INTRODUCTION October 1989 + + + 4.1.4.1 Pathname Specification ....................... 39 + 4.1.4.2 "QUOTE" Command .............................. 40 + 4.1.4.3 Displaying Replies to User ................... 40 + 4.1.4.4 Maintaining Synchronization .................. 40 + 4.1.5 FTP REQUIREMENTS SUMMARY ......................... 41 + 4.2 TRIVIAL FILE TRANSFER PROTOCOL -- TFTP ................. 44 + 4.2.1 INTRODUCTION ...................................... 44 + 4.2.2 PROTOCOL WALK-THROUGH ............................. 44 + 4.2.2.1 Transfer Modes ............................... 44 + 4.2.2.2 UDP Header ................................... 44 + 4.2.3 SPECIFIC ISSUES ................................... 44 + 4.2.3.1 Sorcerer's Apprentice Syndrome ............... 44 + 4.2.3.2 Timeout Algorithms ........................... 46 + 4.2.3.3 Extensions ................................... 46 + 4.2.3.4 Access Control ............................... 46 + 4.2.3.5 Broadcast Request ............................ 46 + 4.2.4 TFTP REQUIREMENTS SUMMARY ......................... 47 + + 5. ELECTRONIC MAIL -- SMTP and RFC-822 ........................ 48 + 5.1 INTRODUCTION ........................................... 48 + 5.2 PROTOCOL WALK-THROUGH .................................. 48 + 5.2.1 The SMTP Model .................................... 48 + 5.2.2 Canonicalization .................................. 49 + 5.2.3 VRFY and EXPN Commands ............................ 50 + 5.2.4 SEND, SOML, and SAML Commands ..................... 50 + 5.2.5 HELO Command ...................................... 50 + 5.2.6 Mail Relay ........................................ 51 + 5.2.7 RCPT Command ...................................... 52 + 5.2.8 DATA Command ...................................... 53 + 5.2.9 Command Syntax .................................... 54 + 5.2.10 SMTP Replies ..................................... 54 + 5.2.11 Transparency ..................................... 55 + 5.2.12 WKS Use in MX Processing ......................... 55 + 5.2.13 RFC-822 Message Specification .................... 55 + 5.2.14 RFC-822 Date and Time Specification .............. 55 + 5.2.15 RFC-822 Syntax Change ............................ 56 + 5.2.16 RFC-822 Local-part .............................. 56 + 5.2.17 Domain Literals .................................. 57 + 5.2.18 Common Address Formatting Errors ................. 58 + 5.2.19 Explicit Source Routes ........................... 58 + 5.3 SPECIFIC ISSUES ........................................ 59 + 5.3.1 SMTP Queueing Strategies .......................... 59 + 5.3.1.1 Sending Strategy .............................. 59 + 5.3.1.2 Receiving strategy ........................... 61 + 5.3.2 Timeouts in SMTP .................................. 61 + 5.3.3 Reliable Mail Receipt ............................. 63 + 5.3.4 Reliable Mail Transmission ........................ 63 + 5.3.5 Domain Name Support ............................... 65 + + + +Internet Engineering Task Force [Page 3] + + + + +RFC1123 INTRODUCTION October 1989 + + + 5.3.6 Mailing Lists and Aliases ......................... 65 + 5.3.7 Mail Gatewaying ................................... 66 + 5.3.8 Maximum Message Size .............................. 68 + 5.4 SMTP REQUIREMENTS SUMMARY .............................. 69 + + 6. SUPPORT SERVICES ............................................ 72 + 6.1 DOMAIN NAME TRANSLATION ................................. 72 + 6.1.1 INTRODUCTION ....................................... 72 + 6.1.2 PROTOCOL WALK-THROUGH ............................. 72 + 6.1.2.1 Resource Records with Zero TTL ............... 73 + 6.1.2.2 QCLASS Values ................................ 73 + 6.1.2.3 Unused Fields ................................ 73 + 6.1.2.4 Compression .................................. 73 + 6.1.2.5 Misusing Configuration Info .................. 73 + 6.1.3 SPECIFIC ISSUES ................................... 74 + 6.1.3.1 Resolver Implementation ...................... 74 + 6.1.3.2 Transport Protocols .......................... 75 + 6.1.3.3 Efficient Resource Usage ..................... 77 + 6.1.3.4 Multihomed Hosts ............................. 78 + 6.1.3.5 Extensibility ................................ 79 + 6.1.3.6 Status of RR Types ........................... 79 + 6.1.3.7 Robustness ................................... 80 + 6.1.3.8 Local Host Table ............................. 80 + 6.1.4 DNS USER INTERFACE ................................ 81 + 6.1.4.1 DNS Administration ........................... 81 + 6.1.4.2 DNS User Interface ........................... 81 + 6.1.4.3 Interface Abbreviation Facilities ............. 82 + 6.1.5 DOMAIN NAME SYSTEM REQUIREMENTS SUMMARY ........... 84 + 6.2 HOST INITIALIZATION .................................... 87 + 6.2.1 INTRODUCTION ...................................... 87 + 6.2.2 REQUIREMENTS ...................................... 87 + 6.2.2.1 Dynamic Configuration ........................ 87 + 6.2.2.2 Loading Phase ................................ 89 + 6.3 REMOTE MANAGEMENT ...................................... 90 + 6.3.1 INTRODUCTION ...................................... 90 + 6.3.2 PROTOCOL WALK-THROUGH ............................. 90 + 6.3.3 MANAGEMENT REQUIREMENTS SUMMARY ................... 92 + + 7. REFERENCES ................................................. 93 + + + + + + + + + + + + +Internet Engineering Task Force [Page 4] + + + + +RFC1123 INTRODUCTION October 1989 + + +1. INTRODUCTION + + This document is one of a pair that defines and discusses the + requirements for host system implementations of the Internet protocol + suite. This RFC covers the applications layer and support protocols. + Its companion RFC, "Requirements for Internet Hosts -- Communications + Layers" [INTRO:1] covers the lower layer protocols: transport layer, + IP layer, and link layer. + + These documents are intended to provide guidance for vendors, + implementors, and users of Internet communication software. They + represent the consensus of a large body of technical experience and + wisdom, contributed by members of the Internet research and vendor + communities. + + This RFC enumerates standard protocols that a host connected to the + Internet must use, and it incorporates by reference the RFCs and + other documents describing the current specifications for these + protocols. It corrects errors in the referenced documents and adds + additional discussion and guidance for an implementor. + + For each protocol, this document also contains an explicit set of + requirements, recommendations, and options. The reader must + understand that the list of requirements in this document is + incomplete by itself; the complete set of requirements for an + Internet host is primarily defined in the standard protocol + specification documents, with the corrections, amendments, and + supplements contained in this RFC. + + A good-faith implementation of the protocols that was produced after + careful reading of the RFC's and with some interaction with the + Internet technical community, and that followed good communications + software engineering practices, should differ from the requirements + of this document in only minor ways. Thus, in many cases, the + "requirements" in this RFC are already stated or implied in the + standard protocol documents, so that their inclusion here is, in a + sense, redundant. However, they were included because some past + implementation has made the wrong choice, causing problems of + interoperability, performance, and/or robustness. + + This document includes discussion and explanation of many of the + requirements and recommendations. A simple list of requirements + would be dangerous, because: + + o Some required features are more important than others, and some + features are optional. + + o There may be valid reasons why particular vendor products that + + + +Internet Engineering Task Force [Page 5] + + + + +RFC1123 INTRODUCTION October 1989 + + + are designed for restricted contexts might choose to use + different specifications. + + However, the specifications of this document must be followed to meet + the general goal of arbitrary host interoperation across the + diversity and complexity of the Internet system. Although most + current implementations fail to meet these requirements in various + ways, some minor and some major, this specification is the ideal + towards which we need to move. + + These requirements are based on the current level of Internet + architecture. This document will be updated as required to provide + additional clarifications or to include additional information in + those areas in which specifications are still evolving. + + This introductory section begins with general advice to host software + vendors, and then gives some guidance on reading the rest of the + document. Section 2 contains general requirements that may be + applicable to all application and support protocols. Sections 3, 4, + and 5 contain the requirements on protocols for the three major + applications: Telnet, file transfer, and electronic mail, + respectively. Section 6 covers the support applications: the domain + name system, system initialization, and management. Finally, all + references will be found in Section 7. + + 1.1 The Internet Architecture + + For a brief introduction to the Internet architecture from a host + viewpoint, see Section 1.1 of [INTRO:1]. That section also + contains recommended references for general background on the + Internet architecture. + + 1.2 General Considerations + + There are two important lessons that vendors of Internet host + software have learned and which a new vendor should consider + seriously. + + 1.2.1 Continuing Internet Evolution + + The enormous growth of the Internet has revealed problems of + management and scaling in a large datagram-based packet + communication system. These problems are being addressed, and + as a result there will be continuing evolution of the + specifications described in this document. These changes will + be carefully planned and controlled, since there is extensive + participation in this planning by the vendors and by the + organizations responsible for operations of the networks. + + + +Internet Engineering Task Force [Page 6] + + + + +RFC1123 INTRODUCTION October 1989 + + + Development, evolution, and revision are characteristic of + computer network protocols today, and this situation will + persist for some years. A vendor who develops computer + communication software for the Internet protocol suite (or any + other protocol suite!) and then fails to maintain and update + that software for changing specifications is going to leave a + trail of unhappy customers. The Internet is a large + communication network, and the users are in constant contact + through it. Experience has shown that knowledge of + deficiencies in vendor software propagates quickly through the + Internet technical community. + + 1.2.2 Robustness Principle + + At every layer of the protocols, there is a general rule whose + application can lead to enormous benefits in robustness and + interoperability: + + "Be liberal in what you accept, and + conservative in what you send" + + Software should be written to deal with every conceivable + error, no matter how unlikely; sooner or later a packet will + come in with that particular combination of errors and + attributes, and unless the software is prepared, chaos can + ensue. In general, it is best to assume that the network is + filled with malevolent entities that will send in packets + designed to have the worst possible effect. This assumption + will lead to suitable protective design, although the most + serious problems in the Internet have been caused by + unenvisaged mechanisms triggered by low-probability events; + mere human malice would never have taken so devious a course! + + Adaptability to change must be designed into all levels of + Internet host software. As a simple example, consider a + protocol specification that contains an enumeration of values + for a particular header field -- e.g., a type field, a port + number, or an error code; this enumeration must be assumed to + be incomplete. Thus, if a protocol specification defines four + possible error codes, the software must not break when a fifth + code shows up. An undefined code might be logged (see below), + but it must not cause a failure. + + The second part of the principle is almost as important: + software on other hosts may contain deficiencies that make it + unwise to exploit legal but obscure protocol features. It is + unwise to stray far from the obvious and simple, lest untoward + effects result elsewhere. A corollary of this is "watch out + + + +Internet Engineering Task Force [Page 7] + + + + +RFC1123 INTRODUCTION October 1989 + + + for misbehaving hosts"; host software should be prepared, not + just to survive other misbehaving hosts, but also to cooperate + to limit the amount of disruption such hosts can cause to the + shared communication facility. + + 1.2.3 Error Logging + + The Internet includes a great variety of host and gateway + systems, each implementing many protocols and protocol layers, + and some of these contain bugs and mis-features in their + Internet protocol software. As a result of complexity, + diversity, and distribution of function, the diagnosis of user + problems is often very difficult. + + Problem diagnosis will be aided if host implementations include + a carefully designed facility for logging erroneous or + "strange" protocol events. It is important to include as much + diagnostic information as possible when an error is logged. In + particular, it is often useful to record the header(s) of a + packet that caused an error. However, care must be taken to + ensure that error logging does not consume prohibitive amounts + of resources or otherwise interfere with the operation of the + host. + + There is a tendency for abnormal but harmless protocol events + to overflow error logging files; this can be avoided by using a + "circular" log, or by enabling logging only while diagnosing a + known failure. It may be useful to filter and count duplicate + successive messages. One strategy that seems to work well is: + (1) always count abnormalities and make such counts accessible + through the management protocol (see Section 6.3); and (2) + allow the logging of a great variety of events to be + selectively enabled. For example, it might useful to be able + to "log everything" or to "log everything for host X". + + Note that different managements may have differing policies + about the amount of error logging that they want normally + enabled in a host. Some will say, "if it doesn't hurt me, I + don't want to know about it", while others will want to take a + more watchful and aggressive attitude about detecting and + removing protocol abnormalities. + + 1.2.4 Configuration + + It would be ideal if a host implementation of the Internet + protocol suite could be entirely self-configuring. This would + allow the whole suite to be implemented in ROM or cast into + silicon, it would simplify diskless workstations, and it would + + + +Internet Engineering Task Force [Page 8] + + + + +RFC1123 INTRODUCTION October 1989 + + + be an immense boon to harried LAN administrators as well as + system vendors. We have not reached this ideal; in fact, we + are not even close. + + At many points in this document, you will find a requirement + that a parameter be a configurable option. There are several + different reasons behind such requirements. In a few cases, + there is current uncertainty or disagreement about the best + value, and it may be necessary to update the recommended value + in the future. In other cases, the value really depends on + external factors -- e.g., the size of the host and the + distribution of its communication load, or the speeds and + topology of nearby networks -- and self-tuning algorithms are + unavailable and may be insufficient. In some cases, + configurability is needed because of administrative + requirements. + + Finally, some configuration options are required to communicate + with obsolete or incorrect implementations of the protocols, + distributed without sources, that unfortunately persist in many + parts of the Internet. To make correct systems coexist with + these faulty systems, administrators often have to "mis- + configure" the correct systems. This problem will correct + itself gradually as the faulty systems are retired, but it + cannot be ignored by vendors. + + When we say that a parameter must be configurable, we do not + intend to require that its value be explicitly read from a + configuration file at every boot time. We recommend that + implementors set up a default for each parameter, so a + configuration file is only necessary to override those defaults + that are inappropriate in a particular installation. Thus, the + configurability requirement is an assurance that it will be + POSSIBLE to override the default when necessary, even in a + binary-only or ROM-based product. + + This document requires a particular value for such defaults in + some cases. The choice of default is a sensitive issue when + the configuration item controls the accommodation to existing + faulty systems. If the Internet is to converge successfully to + complete interoperability, the default values built into + implementations must implement the official protocol, not + "mis-configurations" to accommodate faulty implementations. + Although marketing considerations have led some vendors to + choose mis-configuration defaults, we urge vendors to choose + defaults that will conform to the standard. + + Finally, we note that a vendor needs to provide adequate + + + +Internet Engineering Task Force [Page 9] + + + + +RFC1123 INTRODUCTION October 1989 + + + documentation on all configuration parameters, their limits and + effects. + + + 1.3 Reading this Document + + 1.3.1 Organization + + In general, each major section is organized into the following + subsections: + + (1) Introduction + + (2) Protocol Walk-Through -- considers the protocol + specification documents section-by-section, correcting + errors, stating requirements that may be ambiguous or + ill-defined, and providing further clarification or + explanation. + + (3) Specific Issues -- discusses protocol design and + implementation issues that were not included in the walk- + through. + + (4) Interfaces -- discusses the service interface to the next + higher layer. + + (5) Summary -- contains a summary of the requirements of the + section. + + Under many of the individual topics in this document, there is + parenthetical material labeled "DISCUSSION" or + "IMPLEMENTATION". This material is intended to give + clarification and explanation of the preceding requirements + text. It also includes some suggestions on possible future + directions or developments. The implementation material + contains suggested approaches that an implementor may want to + consider. + + The summary sections are intended to be guides and indexes to + the text, but are necessarily cryptic and incomplete. The + summaries should never be used or referenced separately from + the complete RFC. + + 1.3.2 Requirements + + In this document, the words that are used to define the + significance of each particular requirement are capitalized. + These words are: + + + +Internet Engineering Task Force [Page 10] + + + + +RFC1123 INTRODUCTION October 1989 + + + * "MUST" + + This word or the adjective "REQUIRED" means that the item + is an absolute requirement of the specification. + + * "SHOULD" + + This word or the adjective "RECOMMENDED" means that there + may exist valid reasons in particular circumstances to + ignore this item, but the full implications should be + understood and the case carefully weighed before choosing + a different course. + + * "MAY" + + This word or the adjective "OPTIONAL" means that this item + is truly optional. One vendor may choose to include the + item because a particular marketplace requires it or + because it enhances the product, for example; another + vendor may omit the same item. + + + An implementation is not compliant if it fails to satisfy one + or more of the MUST requirements for the protocols it + implements. An implementation that satisfies all the MUST and + all the SHOULD requirements for its protocols is said to be + "unconditionally compliant"; one that satisfies all the MUST + requirements but not all the SHOULD requirements for its + protocols is said to be "conditionally compliant". + + 1.3.3 Terminology + + This document uses the following technical terms: + + Segment + A segment is the unit of end-to-end transmission in the + TCP protocol. A segment consists of a TCP header followed + by application data. A segment is transmitted by + encapsulation in an IP datagram. + + Message + This term is used by some application layer protocols + (particularly SMTP) for an application data unit. + + Datagram + A [UDP] datagram is the unit of end-to-end transmission in + the UDP protocol. + + + + +Internet Engineering Task Force [Page 11] + + + + +RFC1123 INTRODUCTION October 1989 + + + Multihomed + A host is said to be multihomed if it has multiple IP + addresses to connected networks. + + + + 1.4 Acknowledgments + + This document incorporates contributions and comments from a large + group of Internet protocol experts, including representatives of + university and research labs, vendors, and government agencies. + It was assembled primarily by the Host Requirements Working Group + of the Internet Engineering Task Force (IETF). + + The Editor would especially like to acknowledge the tireless + dedication of the following people, who attended many long + meetings and generated 3 million bytes of electronic mail over the + past 18 months in pursuit of this document: Philip Almquist, Dave + Borman (Cray Research), Noel Chiappa, Dave Crocker (DEC), Steve + Deering (Stanford), Mike Karels (Berkeley), Phil Karn (Bellcore), + John Lekashman (NASA), Charles Lynn (BBN), Keith McCloghrie (TWG), + Paul Mockapetris (ISI), Thomas Narten (Purdue), Craig Partridge + (BBN), Drew Perkins (CMU), and James Van Bokkelen (FTP Software). + + In addition, the following people made major contributions to the + effort: Bill Barns (Mitre), Steve Bellovin (AT&T), Mike Brescia + (BBN), Ed Cain (DCA), Annette DeSchon (ISI), Martin Gross (DCA), + Phill Gross (NRI), Charles Hedrick (Rutgers), Van Jacobson (LBL), + John Klensin (MIT), Mark Lottor (SRI), Milo Medin (NASA), Bill + Melohn (Sun Microsystems), Greg Minshall (Kinetics), Jeff Mogul + (DEC), John Mullen (CMC), Jon Postel (ISI), John Romkey (Epilogue + Technology), and Mike StJohns (DCA). The following also made + significant contributions to particular areas: Eric Allman + (Berkeley), Rob Austein (MIT), Art Berggreen (ACC), Keith Bostic + (Berkeley), Vint Cerf (NRI), Wayne Hathaway (NASA), Matt Korn + (IBM), Erik Naggum (Naggum Software, Norway), Robert Ullmann + (Prime Computer), David Waitzman (BBN), Frank Wancho (USA), Arun + Welch (Ohio State), Bill Westfield (Cisco), and Rayan Zachariassen + (Toronto). + + We are grateful to all, including any contributors who may have + been inadvertently omitted from this list. + + + + + + + + + +Internet Engineering Task Force [Page 12] + + + + +RFC1123 APPLICATIONS LAYER -- GENERAL October 1989 + + +2. GENERAL ISSUES + + This section contains general requirements that may be applicable to + all application-layer protocols. + + 2.1 Host Names and Numbers + + The syntax of a legal Internet host name was specified in RFC-952 + [DNS:4]. One aspect of host name syntax is hereby changed: the + restriction on the first character is relaxed to allow either a + letter or a digit. Host software MUST support this more liberal + syntax. + + Host software MUST handle host names of up to 63 characters and + SHOULD handle host names of up to 255 characters. + + Whenever a user inputs the identity of an Internet host, it SHOULD + be possible to enter either (1) a host domain name or (2) an IP + address in dotted-decimal ("#.#.#.#") form. The host SHOULD check + the string syntactically for a dotted-decimal number before + looking it up in the Domain Name System. + + DISCUSSION: + This last requirement is not intended to specify the complete + syntactic form for entering a dotted-decimal host number; + that is considered to be a user-interface issue. For + example, a dotted-decimal number must be enclosed within + "[ ]" brackets for SMTP mail (see Section 5.2.17). This + notation could be made universal within a host system, + simplifying the syntactic checking for a dotted-decimal + number. + + If a dotted-decimal number can be entered without such + identifying delimiters, then a full syntactic check must be + made, because a segment of a host domain name is now allowed + to begin with a digit and could legally be entirely numeric + (see Section 6.1.2.4). However, a valid host name can never + have the dotted-decimal form #.#.#.#, since at least the + highest-level component label will be alphabetic. + + 2.2 Using Domain Name Service + + Host domain names MUST be translated to IP addresses as described + in Section 6.1. + + Applications using domain name services MUST be able to cope with + soft error conditions. Applications MUST wait a reasonable + interval between successive retries due to a soft error, and MUST + + + +Internet Engineering Task Force [Page 13] + + + + +RFC1123 APPLICATIONS LAYER -- GENERAL October 1989 + + + allow for the possibility that network problems may deny service + for hours or even days. + + An application SHOULD NOT rely on the ability to locate a WKS + record containing an accurate listing of all services at a + particular host address, since the WKS RR type is not often used + by Internet sites. To confirm that a service is present, simply + attempt to use it. + + 2.3 Applications on Multihomed hosts + + When the remote host is multihomed, the name-to-address + translation will return a list of alternative IP addresses. As + specified in Section 6.1.3.4, this list should be in order of + decreasing preference. Application protocol implementations + SHOULD be prepared to try multiple addresses from the list until + success is obtained. More specific requirements for SMTP are + given in Section 5.3.4. + + When the local host is multihomed, a UDP-based request/response + application SHOULD send the response with an IP source address + that is the same as the specific destination address of the UDP + request datagram. The "specific destination address" is defined + in the "IP Addressing" section of the companion RFC [INTRO:1]. + + Similarly, a server application that opens multiple TCP + connections to the same client SHOULD use the same local IP + address for all. + + 2.4 Type-of-Service + + Applications MUST select appropriate TOS values when they invoke + transport layer services, and these values MUST be configurable. + Note that a TOS value contains 5 bits, of which only the most- + significant 3 bits are currently defined; the other two bits MUST + be zero. + + DISCUSSION: + As gateway algorithms are developed to implement Type-of- + Service, the recommended values for various application + protocols may change. In addition, it is likely that + particular combinations of users and Internet paths will want + non-standard TOS values. For these reasons, the TOS values + must be configurable. + + See the latest version of the "Assigned Numbers" RFC + [INTRO:5] for the recommended TOS values for the major + application protocols. + + + +Internet Engineering Task Force [Page 14] + + + + +RFC1123 APPLICATIONS LAYER -- GENERAL October 1989 + + + 2.5 GENERAL APPLICATION REQUIREMENTS SUMMARY + + | | | | |S| | + | | | | |H| |F + | | | | |O|M|o + | | |S| |U|U|o + | | |H| |L|S|t + | |M|O| |D|T|n + | |U|U|M| | |o + | |S|L|A|N|N|t + | |T|D|Y|O|O|t +FEATURE |SECTION | | | |T|T|e +-----------------------------------------------|----------|-|-|-|-|-|-- + | | | | | | | +User interfaces: | | | | | | | + Allow host name to begin with digit |2.1 |x| | | | | + Host names of up to 635 characters |2.1 |x| | | | | + Host names of up to 255 characters |2.1 | |x| | | | + Support dotted-decimal host numbers |2.1 | |x| | | | + Check syntactically for dotted-dec first |2.1 | |x| | | | + | | | | | | | +Map domain names per Section 6.1 |2.2 |x| | | | | +Cope with soft DNS errors |2.2 |x| | | | | + Reasonable interval between retries |2.2 |x| | | | | + Allow for long outages |2.2 |x| | | | | +Expect WKS records to be available |2.2 | | | |x| | + | | | | | | | +Try multiple addr's for remote multihomed host |2.3 | |x| | | | +UDP reply src addr is specific dest of request |2.3 | |x| | | | +Use same IP addr for related TCP connections |2.3 | |x| | | | +Specify appropriate TOS values |2.4 |x| | | | | + TOS values configurable |2.4 |x| | | | | + Unused TOS bits zero |2.4 |x| | | | | + | | | | | | | + | | | | | | | + + + + + + + + + + + + + + + + +Internet Engineering Task Force [Page 15] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + +3. REMOTE LOGIN -- TELNET PROTOCOL + + 3.1 INTRODUCTION + + Telnet is the standard Internet application protocol for remote + login. It provides the encoding rules to link a user's + keyboard/display on a client ("user") system with a command + interpreter on a remote server system. A subset of the Telnet + protocol is also incorporated within other application protocols, + e.g., FTP and SMTP. + + Telnet uses a single TCP connection, and its normal data stream + ("Network Virtual Terminal" or "NVT" mode) is 7-bit ASCII with + escape sequences to embed control functions. Telnet also allows + the negotiation of many optional modes and functions. + + The primary Telnet specification is to be found in RFC-854 + [TELNET:1], while the options are defined in many other RFCs; see + Section 7 for references. + + 3.2 PROTOCOL WALK-THROUGH + + 3.2.1 Option Negotiation: RFC-854, pp. 2-3 + + Every Telnet implementation MUST include option negotiation and + subnegotiation machinery [TELNET:2]. + + A host MUST carefully follow the rules of RFC-854 to avoid + option-negotiation loops. A host MUST refuse (i.e, reply + WONT/DONT to a DO/WILL) an unsupported option. Option + negotiation SHOULD continue to function (even if all requests + are refused) throughout the lifetime of a Telnet connection. + + If all option negotiations fail, a Telnet implementation MUST + default to, and support, an NVT. + + DISCUSSION: + Even though more sophisticated "terminals" and supporting + option negotiations are becoming the norm, all + implementations must be prepared to support an NVT for any + user-server communication. + + 3.2.2 Telnet Go-Ahead Function: RFC-854, p. 5, and RFC-858 + + On a host that never sends the Telnet command Go Ahead (GA), + the Telnet Server MUST attempt to negotiate the Suppress Go + Ahead option (i.e., send "WILL Suppress Go Ahead"). A User or + Server Telnet MUST always accept negotiation of the Suppress Go + + + +Internet Engineering Task Force [Page 16] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + + Ahead option. + + When it is driving a full-duplex terminal for which GA has no + meaning, a User Telnet implementation MAY ignore GA commands. + + DISCUSSION: + Half-duplex ("locked-keyboard") line-at-a-time terminals + for which the Go-Ahead mechanism was designed have largely + disappeared from the scene. It turned out to be difficult + to implement sending the Go-Ahead signal in many operating + systems, even some systems that support native half-duplex + terminals. The difficulty is typically that the Telnet + server code does not have access to information about + whether the user process is blocked awaiting input from + the Telnet connection, i.e., it cannot reliably determine + when to send a GA command. Therefore, most Telnet Server + hosts do not send GA commands. + + The effect of the rules in this section is to allow either + end of a Telnet connection to veto the use of GA commands. + + There is a class of half-duplex terminals that is still + commercially important: "data entry terminals," which + interact in a full-screen manner. However, supporting + data entry terminals using the Telnet protocol does not + require the Go Ahead signal; see Section 3.3.2. + + 3.2.3 Control Functions: RFC-854, pp. 7-8 + + The list of Telnet commands has been extended to include EOR + (End-of-Record), with code 239 [TELNET:9]. + + Both User and Server Telnets MAY support the control functions + EOR, EC, EL, and Break, and MUST support AO, AYT, DM, IP, NOP, + SB, and SE. + + A host MUST be able to receive and ignore any Telnet control + functions that it does not support. + + DISCUSSION: + Note that a Server Telnet is required to support the + Telnet IP (Interrupt Process) function, even if the server + host has an equivalent in-stream function (e.g., Control-C + in many systems). The Telnet IP function may be stronger + than an in-stream interrupt command, because of the out- + of-band effect of TCP urgent data. + + The EOR control function may be used to delimit the + + + +Internet Engineering Task Force [Page 17] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + + stream. An important application is data entry terminal + support (see Section 3.3.2). There was concern that since + EOR had not been defined in RFC-854, a host that was not + prepared to correctly ignore unknown Telnet commands might + crash if it received an EOR. To protect such hosts, the + End-of-Record option [TELNET:9] was introduced; however, a + properly implemented Telnet program will not require this + protection. + + 3.2.4 Telnet "Synch" Signal: RFC-854, pp. 8-10 + + When it receives "urgent" TCP data, a User or Server Telnet + MUST discard all data except Telnet commands until the DM (and + end of urgent) is reached. + + When it sends Telnet IP (Interrupt Process), a User Telnet + SHOULD follow it by the Telnet "Synch" sequence, i.e., send as + TCP urgent data the sequence "IAC IP IAC DM". The TCP urgent + pointer points to the DM octet. + + When it receives a Telnet IP command, a Server Telnet MAY send + a Telnet "Synch" sequence back to the user, to flush the output + stream. The choice ought to be consistent with the way the + server operating system behaves when a local user interrupts a + process. + + When it receives a Telnet AO command, a Server Telnet MUST send + a Telnet "Synch" sequence back to the user, to flush the output + stream. + + A User Telnet SHOULD have the capability of flushing output + when it sends a Telnet IP; see also Section 3.4.5. + + DISCUSSION: + There are three possible ways for a User Telnet to flush + the stream of server output data: + + (1) Send AO after IP. + + This will cause the server host to send a "flush- + buffered-output" signal to its operating system. + However, the AO may not take effect locally, i.e., + stop terminal output at the User Telnet end, until + the Server Telnet has received and processed the AO + and has sent back a "Synch". + + (2) Send DO TIMING-MARK [TELNET:7] after IP, and discard + all output locally until a WILL/WONT TIMING-MARK is + + + +Internet Engineering Task Force [Page 18] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + + received from the Server Telnet. + + Since the DO TIMING-MARK will be processed after the + IP at the server, the reply to it should be in the + right place in the output data stream. However, the + TIMING-MARK will not send a "flush buffered output" + signal to the server operating system. Whether or + not this is needed is dependent upon the server + system. + + (3) Do both. + + The best method is not entirely clear, since it must + accommodate a number of existing server hosts that do not + follow the Telnet standards in various ways. The safest + approach is probably to provide a user-controllable option + to select (1), (2), or (3). + + 3.2.5 NVT Printer and Keyboard: RFC-854, p. 11 + + In NVT mode, a Telnet SHOULD NOT send characters with the + high-order bit 1, and MUST NOT send it as a parity bit. + Implementations that pass the high-order bit to applications + SHOULD negotiate binary mode (see Section 3.2.6). + + + DISCUSSION: + Implementors should be aware that a strict reading of + RFC-854 allows a client or server expecting NVT ASCII to + ignore characters with the high-order bit set. In + general, binary mode is expected to be used for + transmission of an extended (beyond 7-bit) character set + with Telnet. + + However, there exist applications that really need an 8- + bit NVT mode, which is currently not defined, and these + existing applications do set the high-order bit during + part or all of the life of a Telnet connection. Note that + binary mode is not the same as 8-bit NVT mode, since + binary mode turns off end-of-line processing. For this + reason, the requirements on the high-order bit are stated + as SHOULD, not MUST. + + RFC-854 defines a minimal set of properties of a "network + virtual terminal" or NVT; this is not meant to preclude + additional features in a real terminal. A Telnet + connection is fully transparent to all 7-bit ASCII + characters, including arbitrary ASCII control characters. + + + +Internet Engineering Task Force [Page 19] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + + For example, a terminal might support full-screen commands + coded as ASCII escape sequences; a Telnet implementation + would pass these sequences as uninterpreted data. Thus, + an NVT should not be conceived as a terminal type of a + highly-restricted device. + + 3.2.6 Telnet Command Structure: RFC-854, p. 13 + + Since options may appear at any point in the data stream, a + Telnet escape character (known as IAC, with the value 255) to + be sent as data MUST be doubled. + + 3.2.7 Telnet Binary Option: RFC-856 + + When the Binary option has been successfully negotiated, + arbitrary 8-bit characters are allowed. However, the data + stream MUST still be scanned for IAC characters, any embedded + Telnet commands MUST be obeyed, and data bytes equal to IAC + MUST be doubled. Other character processing (e.g., replacing + CR by CR NUL or by CR LF) MUST NOT be done. In particular, + there is no end-of-line convention (see Section 3.3.1) in + binary mode. + + DISCUSSION: + The Binary option is normally negotiated in both + directions, to change the Telnet connection from NVT mode + to "binary mode". + + The sequence IAC EOR can be used to delimit blocks of data + within a binary-mode Telnet stream. + + 3.2.8 Telnet Terminal-Type Option: RFC-1091 + + The Terminal-Type option MUST use the terminal type names + officially defined in the Assigned Numbers RFC [INTRO:5], when + they are available for the particular terminal. However, the + receiver of a Terminal-Type option MUST accept any name. + + DISCUSSION: + RFC-1091 [TELNET:10] updates an earlier version of the + Terminal-Type option defined in RFC-930. The earlier + version allowed a server host capable of supporting + multiple terminal types to learn the type of a particular + client's terminal, assuming that each physical terminal + had an intrinsic type. However, today a "terminal" is + often really a terminal emulator program running in a PC, + perhaps capable of emulating a range of terminal types. + Therefore, RFC-1091 extends the specification to allow a + + + +Internet Engineering Task Force [Page 20] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + + more general terminal-type negotiation between User and + Server Telnets. + + 3.3 SPECIFIC ISSUES + + 3.3.1 Telnet End-of-Line Convention + + The Telnet protocol defines the sequence CR LF to mean "end- + of-line". For terminal input, this corresponds to a command- + completion or "end-of-line" key being pressed on a user + terminal; on an ASCII terminal, this is the CR key, but it may + also be labelled "Return" or "Enter". + + When a Server Telnet receives the Telnet end-of-line sequence + CR LF as input from a remote terminal, the effect MUST be the + same as if the user had pressed the "end-of-line" key on a + local terminal. On server hosts that use ASCII, in particular, + receipt of the Telnet sequence CR LF must cause the same effect + as a local user pressing the CR key on a local terminal. Thus, + CR LF and CR NUL MUST have the same effect on an ASCII server + host when received as input over a Telnet connection. + + A User Telnet MUST be able to send any of the forms: CR LF, CR + NUL, and LF. A User Telnet on an ASCII host SHOULD have a + user-controllable mode to send either CR LF or CR NUL when the + user presses the "end-of-line" key, and CR LF SHOULD be the + default. + + The Telnet end-of-line sequence CR LF MUST be used to send + Telnet data that is not terminal-to-computer (e.g., for Server + Telnet sending output, or the Telnet protocol incorporated + another application protocol). + + DISCUSSION: + To allow interoperability between arbitrary Telnet clients + and servers, the Telnet protocol defined a standard + representation for a line terminator. Since the ASCII + character set includes no explicit end-of-line character, + systems have chosen various representations, e.g., CR, LF, + and the sequence CR LF. The Telnet protocol chose the CR + LF sequence as the standard for network transmission. + + Unfortunately, the Telnet protocol specification in RFC- + 854 [TELNET:1] has turned out to be somewhat ambiguous on + what character(s) should be sent from client to server for + the "end-of-line" key. The result has been a massive and + continuing interoperability headache, made worse by + various faulty implementations of both User and Server + + + +Internet Engineering Task Force [Page 21] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + + Telnets. + + Although the Telnet protocol is based on a perfectly + symmetric model, in a remote login session the role of the + user at a terminal differs from the role of the server + host. For example, RFC-854 defines the meaning of CR, LF, + and CR LF as output from the server, but does not specify + what the User Telnet should send when the user presses the + "end-of-line" key on the terminal; this turns out to be + the point at issue. + + When a user presses the "end-of-line" key, some User + Telnet implementations send CR LF, while others send CR + NUL (based on a different interpretation of the same + sentence in RFC-854). These will be equivalent for a + correctly-implemented ASCII server host, as discussed + above. For other servers, a mode in the User Telnet is + needed. + + The existence of User Telnets that send only CR NUL when + CR is pressed creates a dilemma for non-ASCII hosts: they + can either treat CR NUL as equivalent to CR LF in input, + thus precluding the possibility of entering a "bare" CR, + or else lose complete interworking. + + Suppose a user on host A uses Telnet to log into a server + host B, and then execute B's User Telnet program to log + into server host C. It is desirable for the Server/User + Telnet combination on B to be as transparent as possible, + i.e., to appear as if A were connected directly to C. In + particular, correct implementation will make B transparent + to Telnet end-of-line sequences, except that CR LF may be + translated to CR NUL or vice versa. + + IMPLEMENTATION: + To understand Telnet end-of-line issues, one must have at + least a general model of the relationship of Telnet to the + local operating system. The Server Telnet process is + typically coupled into the terminal driver software of the + operating system as a pseudo-terminal. A Telnet end-of- + line sequence received by the Server Telnet must have the + same effect as pressing the end-of-line key on a real + locally-connected terminal. + + Operating systems that support interactive character-at- + a-time applications (e.g., editors) typically have two + internal modes for their terminal I/O: a formatted mode, + in which local conventions for end-of-line and other + + + +Internet Engineering Task Force [Page 22] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + + formatting rules have been applied to the data stream, and + a "raw" mode, in which the application has direct access + to every character as it was entered. A Server Telnet + must be implemented in such a way that these modes have + the same effect for remote as for local terminals. For + example, suppose a CR LF or CR NUL is received by the + Server Telnet on an ASCII host. In raw mode, a CR + character is passed to the application; in formatted mode, + the local system's end-of-line convention is used. + + 3.3.2 Data Entry Terminals + + DISCUSSION: + In addition to the line-oriented and character-oriented + ASCII terminals for which Telnet was designed, there are + several families of video display terminals that are + sometimes known as "data entry terminals" or DETs. The + IBM 3270 family is a well-known example. + + Two Internet protocols have been designed to support + generic DETs: SUPDUP [TELNET:16, TELNET:17], and the DET + option [TELNET:18, TELNET:19]. The DET option drives a + data entry terminal over a Telnet connection using (sub-) + negotiation. SUPDUP is a completely separate terminal + protocol, which can be entered from Telnet by negotiation. + Although both SUPDUP and the DET option have been used + successfully in particular environments, neither has + gained general acceptance or wide implementation. + + A different approach to DET interaction has been developed + for supporting the IBM 3270 family through Telnet, + although the same approach would be applicable to any DET. + The idea is to enter a "native DET" mode, in which the + native DET input/output stream is sent as binary data. + The Telnet EOR command is used to delimit logical records + (e.g., "screens") within this binary stream. + + IMPLEMENTATION: + The rules for entering and leaving native DET mode are as + follows: + + o The Server uses the Terminal-Type option [TELNET:10] + to learn that the client is a DET. + + o It is conventional, but not required, that both ends + negotiate the EOR option [TELNET:9]. + + o Both ends negotiate the Binary option [TELNET:3] to + + + +Internet Engineering Task Force [Page 23] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + + enter native DET mode. + + o When either end negotiates out of binary mode, the + other end does too, and the mode then reverts to + normal NVT. + + + 3.3.3 Option Requirements + + Every Telnet implementation MUST support the Binary option + [TELNET:3] and the Suppress Go Ahead option [TELNET:5], and + SHOULD support the Echo [TELNET:4], Status [TELNET:6], End-of- + Record [TELNET:9], and Extended Options List [TELNET:8] + options. + + A User or Server Telnet SHOULD support the Window Size Option + [TELNET:12] if the local operating system provides the + corresponding capability. + + DISCUSSION: + Note that the End-of-Record option only signifies that a + Telnet can receive a Telnet EOR without crashing; + therefore, every Telnet ought to be willing to accept + negotiation of the End-of-Record option. See also the + discussion in Section 3.2.3. + + 3.3.4 Option Initiation + + When the Telnet protocol is used in a client/server situation, + the server SHOULD initiate negotiation of the terminal + interaction mode it expects. + + DISCUSSION: + The Telnet protocol was defined to be perfectly + symmetrical, but its application is generally asymmetric. + Remote login has been known to fail because NEITHER side + initiated negotiation of the required non-default terminal + modes. It is generally the server that determines the + preferred mode, so the server needs to initiate the + negotiation; since the negotiation is symmetric, the user + can also initiate it. + + A client (User Telnet) SHOULD provide a means for users to + enable and disable the initiation of option negotiation. + + DISCUSSION: + A user sometimes needs to connect to an application + service (e.g., FTP or SMTP) that uses Telnet for its + + + +Internet Engineering Task Force [Page 24] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + + control stream but does not support Telnet options. User + Telnet may be used for this purpose if initiation of + option negotiation is disabled. + + 3.3.5 Telnet Linemode Option + + DISCUSSION: + An important new Telnet option, LINEMODE [TELNET:12], has + been proposed. The LINEMODE option provides a standard + way for a User Telnet and a Server Telnet to agree that + the client rather than the server will perform terminal + character processing. When the client has prepared a + complete line of text, it will send it to the server in + (usually) one TCP packet. This option will greatly + decrease the packet cost of Telnet sessions and will also + give much better user response over congested or long- + delay networks. + + The LINEMODE option allows dynamic switching between local + and remote character processing. For example, the Telnet + connection will automatically negotiate into single- + character mode while a full screen editor is running, and + then return to linemode when the editor is finished. + + We expect that when this RFC is released, hosts should + implement the client side of this option, and may + implement the server side of this option. To properly + implement the server side, the server needs to be able to + tell the local system not to do any input character + processing, but to remember its current terminal state and + notify the Server Telnet process whenever the state + changes. This will allow password echoing and full screen + editors to be handled properly, for example. + + 3.4 TELNET/USER INTERFACE + + 3.4.1 Character Set Transparency + + User Telnet implementations SHOULD be able to send or receive + any 7-bit ASCII character. Where possible, any special + character interpretations by the user host's operating system + SHOULD be bypassed so that these characters can conveniently be + sent and received on the connection. + + Some character value MUST be reserved as "escape to command + mode"; conventionally, doubling this character allows it to be + entered as data. The specific character used SHOULD be user + selectable. + + + +Internet Engineering Task Force [Page 25] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + + On binary-mode connections, a User Telnet program MAY provide + an escape mechanism for entering arbitrary 8-bit values, if the + host operating system doesn't allow them to be entered directly + from the keyboard. + + IMPLEMENTATION: + The transparency issues are less pressing on servers, but + implementors should take care in dealing with issues like: + masking off parity bits (sent by an older, non-conforming + client) before they reach programs that expect only NVT + ASCII, and properly handling programs that request 8-bit + data streams. + + 3.4.2 Telnet Commands + + A User Telnet program MUST provide a user the capability of + entering any of the Telnet control functions IP, AO, or AYT, + and SHOULD provide the capability of entering EC, EL, and + Break. + + 3.4.3 TCP Connection Errors + + A User Telnet program SHOULD report to the user any TCP errors + that are reported by the transport layer (see "TCP/Application + Layer Interface" section in [INTRO:1]). + + 3.4.4 Non-Default Telnet Contact Port + + A User Telnet program SHOULD allow the user to optionally + specify a non-standard contact port number at the Server Telnet + host. + + 3.4.5 Flushing Output + + A User Telnet program SHOULD provide the user the ability to + specify whether or not output should be flushed when an IP is + sent; see Section 3.2.4. + + For any output flushing scheme that causes the User Telnet to + flush output locally until a Telnet signal is received from the + Server, there SHOULD be a way for the user to manually restore + normal output, in case the Server fails to send the expected + signal. + + + + + + + + +Internet Engineering Task Force [Page 26] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + + 3.5. TELNET REQUIREMENTS SUMMARY + + + | | | | |S| | + | | | | |H| |F + | | | | |O|M|o + | | |S| |U|U|o + | | |H| |L|S|t + | |M|O| |D|T|n + | |U|U|M| | |o + | |S|L|A|N|N|t + | |T|D|Y|O|O|t +FEATURE |SECTION | | | |T|T|e +-------------------------------------------------|--------|-|-|-|-|-|-- + | | | | | | | +Option Negotiation |3.2.1 |x| | | | | + Avoid negotiation loops |3.2.1 |x| | | | | + Refuse unsupported options |3.2.1 |x| | | | | + Negotiation OK anytime on connection |3.2.1 | |x| | | | + Default to NVT |3.2.1 |x| | | | | + Send official name in Term-Type option |3.2.8 |x| | | | | + Accept any name in Term-Type option |3.2.8 |x| | | | | + Implement Binary, Suppress-GA options |3.3.3 |x| | | | | + Echo, Status, EOL, Ext-Opt-List options |3.3.3 | |x| | | | + Implement Window-Size option if appropriate |3.3.3 | |x| | | | + Server initiate mode negotiations |3.3.4 | |x| | | | + User can enable/disable init negotiations |3.3.4 | |x| | | | + | | | | | | | +Go-Aheads | | | | | | | + Non-GA server negotiate SUPPRESS-GA option |3.2.2 |x| | | | | + User or Server accept SUPPRESS-GA option |3.2.2 |x| | | | | + User Telnet ignore GA's |3.2.2 | | |x| | | + | | | | | | | +Control Functions | | | | | | | + Support SE NOP DM IP AO AYT SB |3.2.3 |x| | | | | + Support EOR EC EL Break |3.2.3 | | |x| | | + Ignore unsupported control functions |3.2.3 |x| | | | | + User, Server discard urgent data up to DM |3.2.4 |x| | | | | + User Telnet send "Synch" after IP, AO, AYT |3.2.4 | |x| | | | + Server Telnet reply Synch to IP |3.2.4 | | |x| | | + Server Telnet reply Synch to AO |3.2.4 |x| | | | | + User Telnet can flush output when send IP |3.2.4 | |x| | | | + | | | | | | | +Encoding | | | | | | | + Send high-order bit in NVT mode |3.2.5 | | | |x| | + Send high-order bit as parity bit |3.2.5 | | | | |x| + Negot. BINARY if pass high-ord. bit to applic |3.2.5 | |x| | | | + Always double IAC data byte |3.2.6 |x| | | | | + + + +Internet Engineering Task Force [Page 27] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + + Double IAC data byte in binary mode |3.2.7 |x| | | | | + Obey Telnet cmds in binary mode |3.2.7 |x| | | | | + End-of-line, CR NUL in binary mode |3.2.7 | | | | |x| + | | | | | | | +End-of-Line | | | | | | | + EOL at Server same as local end-of-line |3.3.1 |x| | | | | + ASCII Server accept CR LF or CR NUL for EOL |3.3.1 |x| | | | | + User Telnet able to send CR LF, CR NUL, or LF |3.3.1 |x| | | | | + ASCII user able to select CR LF/CR NUL |3.3.1 | |x| | | | + User Telnet default mode is CR LF |3.3.1 | |x| | | | + Non-interactive uses CR LF for EOL |3.3.1 |x| | | | | + | | | | | | | +User Telnet interface | | | | | | | + Input & output all 7-bit characters |3.4.1 | |x| | | | + Bypass local op sys interpretation |3.4.1 | |x| | | | + Escape character |3.4.1 |x| | | | | + User-settable escape character |3.4.1 | |x| | | | + Escape to enter 8-bit values |3.4.1 | | |x| | | + Can input IP, AO, AYT |3.4.2 |x| | | | | + Can input EC, EL, Break |3.4.2 | |x| | | | + Report TCP connection errors to user |3.4.3 | |x| | | | + Optional non-default contact port |3.4.4 | |x| | | | + Can spec: output flushed when IP sent |3.4.5 | |x| | | | + Can manually restore output mode |3.4.5 | |x| | | | + | | | | | | | + + + + + + + + + + + + + + + + + + + + + + + + + + +Internet Engineering Task Force [Page 28] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + +4. FILE TRANSFER + + 4.1 FILE TRANSFER PROTOCOL -- FTP + + 4.1.1 INTRODUCTION + + The File Transfer Protocol FTP is the primary Internet standard + for file transfer. The current specification is contained in + RFC-959 [FTP:1]. + + FTP uses separate simultaneous TCP connections for control and + for data transfer. The FTP protocol includes many features, + some of which are not commonly implemented. However, for every + feature in FTP, there exists at least one implementation. The + minimum implementation defined in RFC-959 was too small, so a + somewhat larger minimum implementation is defined here. + + Internet users have been unnecessarily burdened for years by + deficient FTP implementations. Protocol implementors have + suffered from the erroneous opinion that implementing FTP ought + to be a small and trivial task. This is wrong, because FTP has + a user interface, because it has to deal (correctly) with the + whole variety of communication and operating system errors that + may occur, and because it has to handle the great diversity of + real file systems in the world. + + 4.1.2. PROTOCOL WALK-THROUGH + + 4.1.2.1 LOCAL Type: RFC-959 Section 3.1.1.4 + + An FTP program MUST support TYPE I ("IMAGE" or binary type) + as well as TYPE L 8 ("LOCAL" type with logical byte size 8). + A machine whose memory is organized into m-bit words, where + m is not a multiple of 8, MAY also support TYPE L m. + + DISCUSSION: + The command "TYPE L 8" is often required to transfer + binary data between a machine whose memory is organized + into (e.g.) 36-bit words and a machine with an 8-bit + byte organization. For an 8-bit byte machine, TYPE L 8 + is equivalent to IMAGE. + + "TYPE L m" is sometimes specified to the FTP programs + on two m-bit word machines to ensure the correct + transfer of a native-mode binary file from one machine + to the other. However, this command should have the + same effect on these machines as "TYPE I". + + + + +Internet Engineering Task Force [Page 29] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + 4.1.2.2 Telnet Format Control: RFC-959 Section 3.1.1.5.2 + + A host that makes no distinction between TYPE N and TYPE T + SHOULD implement TYPE T to be identical to TYPE N. + + DISCUSSION: + This provision should ease interoperation with hosts + that do make this distinction. + + Many hosts represent text files internally as strings + of ASCII characters, using the embedded ASCII format + effector characters (LF, BS, FF, ...) to control the + format when a file is printed. For such hosts, there + is no distinction between "print" files and other + files. However, systems that use record structured + files typically need a special format for printable + files (e.g., ASA carriage control). For the latter + hosts, FTP allows a choice of TYPE N or TYPE T. + + 4.1.2.3 Page Structure: RFC-959 Section 3.1.2.3 and Appendix I + + Implementation of page structure is NOT RECOMMENDED in + general. However, if a host system does need to implement + FTP for "random access" or "holey" files, it MUST use the + defined page structure format rather than define a new + private FTP format. + + 4.1.2.4 Data Structure Transformations: RFC-959 Section 3.1.2 + + An FTP transformation between record-structure and file- + structure SHOULD be invertible, to the extent possible while + making the result useful on the target host. + + DISCUSSION: + RFC-959 required strict invertibility between record- + structure and file-structure, but in practice, + efficiency and convenience often preclude it. + Therefore, the requirement is being relaxed. There are + two different objectives for transferring a file: + processing it on the target host, or just storage. For + storage, strict invertibility is important. For + processing, the file created on the target host needs + to be in the format expected by application programs on + that host. + + As an example of the conflict, imagine a record- + oriented operating system that requires some data files + to have exactly 80 bytes in each record. While STORing + + + +Internet Engineering Task Force [Page 30] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + a file on such a host, an FTP Server must be able to + pad each line or record to 80 bytes; a later retrieval + of such a file cannot be strictly invertible. + + 4.1.2.5 Data Connection Management: RFC-959 Section 3.3 + + A User-FTP that uses STREAM mode SHOULD send a PORT command + to assign a non-default data port before each transfer + command is issued. + + DISCUSSION: + This is required because of the long delay after a TCP + connection is closed until its socket pair can be + reused, to allow multiple transfers during a single FTP + session. Sending a port command can avoided if a + transfer mode other than stream is used, by leaving the + data transfer connection open between transfers. + + 4.1.2.6 PASV Command: RFC-959 Section 4.1.2 + + A server-FTP MUST implement the PASV command. + + If multiple third-party transfers are to be executed during + the same session, a new PASV command MUST be issued before + each transfer command, to obtain a unique port pair. + + IMPLEMENTATION: + The format of the 227 reply to a PASV command is not + well standardized. In particular, an FTP client cannot + assume that the parentheses shown on page 40 of RFC-959 + will be present (and in fact, Figure 3 on page 43 omits + them). Therefore, a User-FTP program that interprets + the PASV reply must scan the reply for the first digit + of the host and port numbers. + + Note that the host number h1,h2,h3,h4 is the IP address + of the server host that is sending the reply, and that + p1,p2 is a non-default data transfer port that PASV has + assigned. + + 4.1.2.7 LIST and NLST Commands: RFC-959 Section 4.1.3 + + The data returned by an NLST command MUST contain only a + simple list of legal pathnames, such that the server can use + them directly as the arguments of subsequent data transfer + commands for the individual files. + + The data returned by a LIST or NLST command SHOULD use an + + + +Internet Engineering Task Force [Page 31] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + implied TYPE AN, unless the current type is EBCDIC, in which + case an implied TYPE EN SHOULD be used. + + DISCUSSION: + Many FTP clients support macro-commands that will get + or put files matching a wildcard specification, using + NLST to obtain a list of pathnames. The expansion of + "multiple-put" is local to the client, but "multiple- + get" requires cooperation by the server. + + The implied type for LIST and NLST is designed to + provide compatibility with existing User-FTPs, and in + particular with multiple-get commands. + + 4.1.2.8 SITE Command: RFC-959 Section 4.1.3 + + A Server-FTP SHOULD use the SITE command for non-standard + features, rather than invent new private commands or + unstandardized extensions to existing commands. + + 4.1.2.9 STOU Command: RFC-959 Section 4.1.3 + + The STOU command stores into a uniquely named file. When it + receives an STOU command, a Server-FTP MUST return the + actual file name in the "125 Transfer Starting" or the "150 + Opening Data Connection" message that precedes the transfer + (the 250 reply code mentioned in RFC-959 is incorrect). The + exact format of these messages is hereby defined to be as + follows: + + 125 FILE: pppp + 150 FILE: pppp + + where pppp represents the unique pathname of the file that + will be written. + + 4.1.2.10 Telnet End-of-line Code: RFC-959, Page 34 + + Implementors MUST NOT assume any correspondence between READ + boundaries on the control connection and the Telnet EOL + sequences (CR LF). + + DISCUSSION: + Thus, a server-FTP (or User-FTP) must continue reading + characters from the control connection until a complete + Telnet EOL sequence is encountered, before processing + the command (or response, respectively). Conversely, a + single READ from the control connection may include + + + +Internet Engineering Task Force [Page 32] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + more than one FTP command. + + 4.1.2.11 FTP Replies: RFC-959 Section 4.2, Page 35 + + A Server-FTP MUST send only correctly formatted replies on + the control connection. Note that RFC-959 (unlike earlier + versions of the FTP spec) contains no provision for a + "spontaneous" reply message. + + A Server-FTP SHOULD use the reply codes defined in RFC-959 + whenever they apply. However, a server-FTP MAY use a + different reply code when needed, as long as the general + rules of Section 4.2 are followed. When the implementor has + a choice between a 4xx and 5xx reply code, a Server-FTP + SHOULD send a 4xx (temporary failure) code when there is any + reasonable possibility that a failed FTP will succeed a few + hours later. + + A User-FTP SHOULD generally use only the highest-order digit + of a 3-digit reply code for making a procedural decision, to + prevent difficulties when a Server-FTP uses non-standard + reply codes. + + A User-FTP MUST be able to handle multi-line replies. If + the implementation imposes a limit on the number of lines + and if this limit is exceeded, the User-FTP MUST recover, + e.g., by ignoring the excess lines until the end of the + multi-line reply is reached. + + A User-FTP SHOULD NOT interpret a 421 reply code ("Service + not available, closing control connection") specially, but + SHOULD detect closing of the control connection by the + server. + + DISCUSSION: + Server implementations that fail to strictly follow the + reply rules often cause FTP user programs to hang. + Note that RFC-959 resolved ambiguities in the reply + rules found in earlier FTP specifications and must be + followed. + + It is important to choose FTP reply codes that properly + distinguish between temporary and permanent failures, + to allow the successful use of file transfer client + daemons. These programs depend on the reply codes to + decide whether or not to retry a failed transfer; using + a permanent failure code (5xx) for a temporary error + will cause these programs to give up unnecessarily. + + + +Internet Engineering Task Force [Page 33] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + When the meaning of a reply matches exactly the text + shown in RFC-959, uniformity will be enhanced by using + the RFC-959 text verbatim. However, a Server-FTP + implementor is encouraged to choose reply text that + conveys specific system-dependent information, when + appropriate. + + 4.1.2.12 Connections: RFC-959 Section 5.2 + + The words "and the port used" in the second paragraph of + this section of RFC-959 are erroneous (historical), and they + should be ignored. + + On a multihomed server host, the default data transfer port + (L-1) MUST be associated with the same local IP address as + the corresponding control connection to port L. + + A user-FTP MUST NOT send any Telnet controls other than + SYNCH and IP on an FTP control connection. In particular, it + MUST NOT attempt to negotiate Telnet options on the control + connection. However, a server-FTP MUST be capable of + accepting and refusing Telnet negotiations (i.e., sending + DONT/WONT). + + DISCUSSION: + Although the RFC says: "Server- and User- processes + should follow the conventions for the Telnet + protocol...[on the control connection]", it is not the + intent that Telnet option negotiation is to be + employed. + + 4.1.2.13 Minimum Implementation; RFC-959 Section 5.1 + + The following commands and options MUST be supported by + every server-FTP and user-FTP, except in cases where the + underlying file system or operating system does not allow or + support a particular command. + + Type: ASCII Non-print, IMAGE, LOCAL 8 + Mode: Stream + Structure: File, Record* + Commands: + USER, PASS, ACCT, + PORT, PASV, + TYPE, MODE, STRU, + RETR, STOR, APPE, + RNFR, RNTO, DELE, + CWD, CDUP, RMD, MKD, PWD, + + + +Internet Engineering Task Force [Page 34] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + LIST, NLST, + SYST, STAT, + HELP, NOOP, QUIT. + + *Record structure is REQUIRED only for hosts whose file + systems support record structure. + + DISCUSSION: + Vendors are encouraged to implement a larger subset of + the protocol. For example, there are important + robustness features in the protocol (e.g., Restart, + ABOR, block mode) that would be an aid to some Internet + users but are not widely implemented. + + A host that does not have record structures in its file + system may still accept files with STRU R, recording + the byte stream literally. + + 4.1.3 SPECIFIC ISSUES + + 4.1.3.1 Non-standard Command Verbs + + FTP allows "experimental" commands, whose names begin with + "X". If these commands are subsequently adopted as + standards, there may still be existing implementations using + the "X" form. At present, this is true for the directory + commands: + + RFC-959 "Experimental" + + MKD XMKD + RMD XRMD + PWD XPWD + CDUP XCUP + CWD XCWD + + All FTP implementations SHOULD recognize both forms of these + commands, by simply equating them with extra entries in the + command lookup table. + + IMPLEMENTATION: + A User-FTP can access a server that supports only the + "X" forms by implementing a mode switch, or + automatically using the following procedure: if the + RFC-959 form of one of the above commands is rejected + with a 500 or 502 response code, then try the + experimental form; any other response would be passed + to the user. + + + +Internet Engineering Task Force [Page 35] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + 4.1.3.2 Idle Timeout + + A Server-FTP process SHOULD have an idle timeout, which will + terminate the process and close the control connection if + the server is inactive (i.e., no command or data transfer in + progress) for a long period of time. The idle timeout time + SHOULD be configurable, and the default should be at least 5 + minutes. + + A client FTP process ("User-PI" in RFC-959) will need + timeouts on responses only if it is invoked from a program. + + DISCUSSION: + Without a timeout, a Server-FTP process may be left + pending indefinitely if the corresponding client + crashes without closing the control connection. + + 4.1.3.3 Concurrency of Data and Control + + DISCUSSION: + The intent of the designers of FTP was that a user + should be able to send a STAT command at any time while + data transfer was in progress and that the server-FTP + would reply immediately with status -- e.g., the number + of bytes transferred so far. Similarly, an ABOR + command should be possible at any time during a data + transfer. + + Unfortunately, some small-machine operating systems + make such concurrent programming difficult, and some + other implementers seek minimal solutions, so some FTP + implementations do not allow concurrent use of the data + and control connections. Even such a minimal server + must be prepared to accept and defer a STAT or ABOR + command that arrives during data transfer. + + 4.1.3.4 FTP Restart Mechanism + + The description of the 110 reply on pp. 40-41 of RFC-959 is + incorrect; the correct description is as follows. A restart + reply message, sent over the control connection from the + receiving FTP to the User-FTP, has the format: + + 110 MARK ssss = rrrr + + Here: + + * ssss is a text string that appeared in a Restart Marker + + + +Internet Engineering Task Force [Page 36] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + in the data stream and encodes a position in the + sender's file system; + + * rrrr encodes the corresponding position in the + receiver's file system. + + The encoding, which is specific to a particular file system + and network implementation, is always generated and + interpreted by the same system, either sender or receiver. + + When an FTP that implements restart receives a Restart + Marker in the data stream, it SHOULD force the data to that + point to be written to stable storage before encoding the + corresponding position rrrr. An FTP sending Restart Markers + MUST NOT assume that 110 replies will be returned + synchronously with the data, i.e., it must not await a 110 + reply before sending more data. + + Two new reply codes are hereby defined for errors + encountered in restarting a transfer: + + 554 Requested action not taken: invalid REST parameter. + + A 554 reply may result from a FTP service command that + follows a REST command. The reply indicates that the + existing file at the Server-FTP cannot be repositioned + as specified in the REST. + + 555 Requested action not taken: type or stru mismatch. + + A 555 reply may result from an APPE command or from any + FTP service command following a REST command. The + reply indicates that there is some mismatch between the + current transfer parameters (type and stru) and the + attributes of the existing file. + + DISCUSSION: + Note that the FTP Restart mechanism requires that Block + or Compressed mode be used for data transfer, to allow + the Restart Markers to be included within the data + stream. The frequency of Restart Markers can be low. + + Restart Markers mark a place in the data stream, but + the receiver may be performing some transformation on + the data as it is stored into stable storage. In + general, the receiver's encoding must include any state + information necessary to restart this transformation at + any point of the FTP data stream. For example, in TYPE + + + +Internet Engineering Task Force [Page 37] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + A transfers, some receiver hosts transform CR LF + sequences into a single LF character on disk. If a + Restart Marker happens to fall between CR and LF, the + receiver must encode in rrrr that the transfer must be + restarted in a "CR has been seen and discarded" state. + + Note that the Restart Marker is required to be encoded + as a string of printable ASCII characters, regardless + of the type of the data. + + RFC-959 says that restart information is to be returned + "to the user". This should not be taken literally. In + general, the User-FTP should save the restart + information (ssss,rrrr) in stable storage, e.g., append + it to a restart control file. An empty restart control + file should be created when the transfer first starts + and deleted automatically when the transfer completes + successfully. It is suggested that this file have a + name derived in an easily-identifiable manner from the + name of the file being transferred and the remote host + name; this is analogous to the means used by many text + editors for naming "backup" files. + + There are three cases for FTP restart. + + (1) User-to-Server Transfer + + The User-FTP puts Restart Markers at + convenient places in the data stream. When the + Server-FTP receives a Marker, it writes all prior + data to disk, encodes its file system position and + transformation state as rrrr, and returns a "110 + MARK ssss = rrrr" reply over the control + connection. The User-FTP appends the pair + (ssss,rrrr) to its restart control file. + + To restart the transfer, the User-FTP fetches the + last (ssss,rrrr) pair from the restart control + file, repositions its local file system and + transformation state using ssss, and sends the + command "REST rrrr" to the Server-FTP. + + (2) Server-to-User Transfer + + The Server-FTP puts Restart Markers at + convenient places in the data stream. When the + User-FTP receives a Marker, it writes all prior + data to disk, encodes its file system position and + + + +Internet Engineering Task Force [Page 38] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + transformation state as rrrr, and appends the pair + (rrrr,ssss) to its restart control file. + + To restart the transfer, the User-FTP fetches the + last (rrrr,ssss) pair from the restart control + file, repositions its local file system and + transformation state using rrrr, and sends the + command "REST ssss" to the Server-FTP. + + (3) Server-to-Server ("Third-Party") Transfer + + The sending Server-FTP puts Restart Markers + at convenient places in the data stream. When it + receives a Marker, the receiving Server-FTP writes + all prior data to disk, encodes its file system + position and transformation state as rrrr, and + sends a "110 MARK ssss = rrrr" reply over the + control connection to the User. The User-FTP + appends the pair (ssss,rrrr) to its restart + control file. + + To restart the transfer, the User-FTP fetches the + last (ssss,rrrr) pair from the restart control + file, sends "REST ssss" to the sending Server-FTP, + and sends "REST rrrr" to the receiving Server-FTP. + + + 4.1.4 FTP/USER INTERFACE + + This section discusses the user interface for a User-FTP + program. + + 4.1.4.1 Pathname Specification + + Since FTP is intended for use in a heterogeneous + environment, User-FTP implementations MUST support remote + pathnames as arbitrary character strings, so that their form + and content are not limited by the conventions of the local + operating system. + + DISCUSSION: + In particular, remote pathnames can be of arbitrary + length, and all the printing ASCII characters as well + as space (0x20) must be allowed. RFC-959 allows a + pathname to contain any 7-bit ASCII character except CR + or LF. + + + + + +Internet Engineering Task Force [Page 39] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + 4.1.4.2 "QUOTE" Command + + A User-FTP program MUST implement a "QUOTE" command that + will pass an arbitrary character string to the server and + display all resulting response messages to the user. + + To make the "QUOTE" command useful, a User-FTP SHOULD send + transfer control commands to the server as the user enters + them, rather than saving all the commands and sending them + to the server only when a data transfer is started. + + DISCUSSION: + The "QUOTE" command is essential to allow the user to + access servers that require system-specific commands + (e.g., SITE or ALLO), or to invoke new or optional + features that are not implemented by the User-FTP. For + example, "QUOTE" may be used to specify "TYPE A T" to + send a print file to hosts that require the + distinction, even if the User-FTP does not recognize + that TYPE. + + 4.1.4.3 Displaying Replies to User + + A User-FTP SHOULD display to the user the full text of all + error reply messages it receives. It SHOULD have a + "verbose" mode in which all commands it sends and the full + text and reply codes it receives are displayed, for + diagnosis of problems. + + 4.1.4.4 Maintaining Synchronization + + The state machine in a User-FTP SHOULD be forgiving of + missing and unexpected reply messages, in order to maintain + command synchronization with the server. + + + + + + + + + + + + + + + + + +Internet Engineering Task Force [Page 40] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + 4.1.5 FTP REQUIREMENTS SUMMARY + + | | | | |S| | + | | | | |H| |F + | | | | |O|M|o + | | |S| |U|U|o + | | |H| |L|S|t + | |M|O| |D|T|n + | |U|U|M| | |o + | |S|L|A|N|N|t + | |T|D|Y|O|O|t +FEATURE |SECTION | | | |T|T|e +-------------------------------------------|---------------|-|-|-|-|-|-- +Implement TYPE T if same as TYPE N |4.1.2.2 | |x| | | | +File/Record transform invertible if poss. |4.1.2.4 | |x| | | | +User-FTP send PORT cmd for stream mode |4.1.2.5 | |x| | | | +Server-FTP implement PASV |4.1.2.6 |x| | | | | + PASV is per-transfer |4.1.2.6 |x| | | | | +NLST reply usable in RETR cmds |4.1.2.7 |x| | | | | +Implied type for LIST and NLST |4.1.2.7 | |x| | | | +SITE cmd for non-standard features |4.1.2.8 | |x| | | | +STOU cmd return pathname as specified |4.1.2.9 |x| | | | | +Use TCP READ boundaries on control conn. |4.1.2.10 | | | | |x| + | | | | | | | +Server-FTP send only correct reply format |4.1.2.11 |x| | | | | +Server-FTP use defined reply code if poss. |4.1.2.11 | |x| | | | + New reply code following Section 4.2 |4.1.2.11 | | |x| | | +User-FTP use only high digit of reply |4.1.2.11 | |x| | | | +User-FTP handle multi-line reply lines |4.1.2.11 |x| | | | | +User-FTP handle 421 reply specially |4.1.2.11 | | | |x| | + | | | | | | | +Default data port same IP addr as ctl conn |4.1.2.12 |x| | | | | +User-FTP send Telnet cmds exc. SYNCH, IP |4.1.2.12 | | | | |x| +User-FTP negotiate Telnet options |4.1.2.12 | | | | |x| +Server-FTP handle Telnet options |4.1.2.12 |x| | | | | +Handle "Experimental" directory cmds |4.1.3.1 | |x| | | | +Idle timeout in server-FTP |4.1.3.2 | |x| | | | + Configurable idle timeout |4.1.3.2 | |x| | | | +Receiver checkpoint data at Restart Marker |4.1.3.4 | |x| | | | +Sender assume 110 replies are synchronous |4.1.3.4 | | | | |x| + | | | | | | | +Support TYPE: | | | | | | | + ASCII - Non-Print (AN) |4.1.2.13 |x| | | | | + ASCII - Telnet (AT) -- if same as AN |4.1.2.2 | |x| | | | + ASCII - Carriage Control (AC) |959 3.1.1.5.2 | | |x| | | + EBCDIC - (any form) |959 3.1.1.2 | | |x| | | + IMAGE |4.1.2.1 |x| | | | | + LOCAL 8 |4.1.2.1 |x| | | | | + + + +Internet Engineering Task Force [Page 41] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + LOCAL m |4.1.2.1 | | |x| | |2 + | | | | | | | +Support MODE: | | | | | | | + Stream |4.1.2.13 |x| | | | | + Block |959 3.4.2 | | |x| | | + | | | | | | | +Support STRUCTURE: | | | | | | | + File |4.1.2.13 |x| | | | | + Record |4.1.2.13 |x| | | | |3 + Page |4.1.2.3 | | | |x| | + | | | | | | | +Support commands: | | | | | | | + USER |4.1.2.13 |x| | | | | + PASS |4.1.2.13 |x| | | | | + ACCT |4.1.2.13 |x| | | | | + CWD |4.1.2.13 |x| | | | | + CDUP |4.1.2.13 |x| | | | | + SMNT |959 5.3.1 | | |x| | | + REIN |959 5.3.1 | | |x| | | + QUIT |4.1.2.13 |x| | | | | + | | | | | | | + PORT |4.1.2.13 |x| | | | | + PASV |4.1.2.6 |x| | | | | + TYPE |4.1.2.13 |x| | | | |1 + STRU |4.1.2.13 |x| | | | |1 + MODE |4.1.2.13 |x| | | | |1 + | | | | | | | + RETR |4.1.2.13 |x| | | | | + STOR |4.1.2.13 |x| | | | | + STOU |959 5.3.1 | | |x| | | + APPE |4.1.2.13 |x| | | | | + ALLO |959 5.3.1 | | |x| | | + REST |959 5.3.1 | | |x| | | + RNFR |4.1.2.13 |x| | | | | + RNTO |4.1.2.13 |x| | | | | + ABOR |959 5.3.1 | | |x| | | + DELE |4.1.2.13 |x| | | | | + RMD |4.1.2.13 |x| | | | | + MKD |4.1.2.13 |x| | | | | + PWD |4.1.2.13 |x| | | | | + LIST |4.1.2.13 |x| | | | | + NLST |4.1.2.13 |x| | | | | + SITE |4.1.2.8 | | |x| | | + STAT |4.1.2.13 |x| | | | | + SYST |4.1.2.13 |x| | | | | + HELP |4.1.2.13 |x| | | | | + NOOP |4.1.2.13 |x| | | | | + | | | | | | | + + + +Internet Engineering Task Force [Page 42] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + +User Interface: | | | | | | | + Arbitrary pathnames |4.1.4.1 |x| | | | | + Implement "QUOTE" command |4.1.4.2 |x| | | | | + Transfer control commands immediately |4.1.4.2 | |x| | | | + Display error messages to user |4.1.4.3 | |x| | | | + Verbose mode |4.1.4.3 | |x| | | | + Maintain synchronization with server |4.1.4.4 | |x| | | | + +Footnotes: + +(1) For the values shown earlier. + +(2) Here m is number of bits in a memory word. + +(3) Required for host with record-structured file system, optional + otherwise. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Internet Engineering Task Force [Page 43] + + + + +RFC1123 FILE TRANSFER -- TFTP October 1989 + + + 4.2 TRIVIAL FILE TRANSFER PROTOCOL -- TFTP + + 4.2.1 INTRODUCTION + + The Trivial File Transfer Protocol TFTP is defined in RFC-783 + [TFTP:1]. + + TFTP provides its own reliable delivery with UDP as its + transport protocol, using a simple stop-and-wait acknowledgment + system. Since TFTP has an effective window of only one 512 + octet segment, it can provide good performance only over paths + that have a small delay*bandwidth product. The TFTP file + interface is very simple, providing no access control or + security. + + TFTP's most important application is bootstrapping a host over + a local network, since it is simple and small enough to be + easily implemented in EPROM [BOOT:1, BOOT:2]. Vendors are + urged to support TFTP for booting. + + 4.2.2 PROTOCOL WALK-THROUGH + + The TFTP specification [TFTP:1] is written in an open style, + and does not fully specify many parts of the protocol. + + 4.2.2.1 Transfer Modes: RFC-783, Page 3 + + The transfer mode "mail" SHOULD NOT be supported. + + 4.2.2.2 UDP Header: RFC-783, Page 17 + + The Length field of a UDP header is incorrectly defined; it + includes the UDP header length (8). + + 4.2.3 SPECIFIC ISSUES + + 4.2.3.1 Sorcerer's Apprentice Syndrome + + There is a serious bug, known as the "Sorcerer's Apprentice + Syndrome," in the protocol specification. While it does not + cause incorrect operation of the transfer (the file will + always be transferred correctly if the transfer completes), + this bug may cause excessive retransmission, which may cause + the transfer to time out. + + Implementations MUST contain the fix for this problem: the + sender (i.e., the side originating the DATA packets) must + never resend the current DATA packet on receipt of a + + + +Internet Engineering Task Force [Page 44] + + + + +RFC1123 FILE TRANSFER -- TFTP October 1989 + + + duplicate ACK. + + DISCUSSION: + The bug is caused by the protocol rule that either + side, on receiving an old duplicate datagram, may + resend the current datagram. If a packet is delayed in + the network but later successfully delivered after + either side has timed out and retransmitted a packet, a + duplicate copy of the response may be generated. If + the other side responds to this duplicate with a + duplicate of its own, then every datagram will be sent + in duplicate for the remainder of the transfer (unless + a datagram is lost, breaking the repetition). Worse + yet, since the delay is often caused by congestion, + this duplicate transmission will usually causes more + congestion, leading to more delayed packets, etc. + + The following example may help to clarify this problem. + + TFTP A TFTP B + + (1) Receive ACK X-1 + Send DATA X + (2) Receive DATA X + Send ACK X + (ACK X is delayed in network, + and A times out): + (3) Retransmit DATA X + + (4) Receive DATA X again + Send ACK X again + (5) Receive (delayed) ACK X + Send DATA X+1 + (6) Receive DATA X+1 + Send ACK X+1 + (7) Receive ACK X again + Send DATA X+1 again + (8) Receive DATA X+1 again + Send ACK X+1 again + (9) Receive ACK X+1 + Send DATA X+2 + (10) Receive DATA X+2 + Send ACK X+3 + (11) Receive ACK X+1 again + Send DATA X+2 again + (12) Receive DATA X+2 again + Send ACK X+3 again + + + + +Internet Engineering Task Force [Page 45] + + + + +RFC1123 FILE TRANSFER -- TFTP October 1989 + + + Notice that once the delayed ACK arrives, the protocol + settles down to duplicate all further packets + (sequences 5-8 and 9-12). The problem is caused not by + either side timing out, but by both sides + retransmitting the current packet when they receive a + duplicate. + + The fix is to break the retransmission loop, as + indicated above. This is analogous to the behavior of + TCP. It is then possible to remove the retransmission + timer on the receiver, since the resent ACK will never + cause any action; this is a useful simplification where + TFTP is used in a bootstrap program. It is OK to allow + the timer to remain, and it may be helpful if the + retransmitted ACK replaces one that was genuinely lost + in the network. The sender still requires a retransmit + timer, of course. + + 4.2.3.2 Timeout Algorithms + + A TFTP implementation MUST use an adaptive timeout. + + IMPLEMENTATION: + TCP retransmission algorithms provide a useful base to + work from. At least an exponential backoff of + retransmission timeout is necessary. + + 4.2.3.3 Extensions + + A variety of non-standard extensions have been made to TFTP, + including additional transfer modes and a secure operation + mode (with passwords). None of these have been + standardized. + + 4.2.3.4 Access Control + + A server TFTP implementation SHOULD include some + configurable access control over what pathnames are allowed + in TFTP operations. + + 4.2.3.5 Broadcast Request + + A TFTP request directed to a broadcast address SHOULD be + silently ignored. + + DISCUSSION: + Due to the weak access control capability of TFTP, + directed broadcasts of TFTP requests to random networks + + + +Internet Engineering Task Force [Page 46] + + + + +RFC1123 FILE TRANSFER -- TFTP October 1989 + + + could create a significant security hole. + + 4.2.4 TFTP REQUIREMENTS SUMMARY + + | | | | |S| | + | | | | |H| |F + | | | | |O|M|o + | | |S| |U|U|o + | | |H| |L|S|t + | |M|O| |D|T|n + | |U|U|M| | |o + | |S|L|A|N|N|t + | |T|D|Y|O|O|t +FEATURE |SECTION | | | |T|T|e +-------------------------------------------------|--------|-|-|-|-|-|-- +Fix Sorcerer's Apprentice Syndrome |4.2.3.1 |x| | | | | +Transfer modes: | | | | | | | + netascii |RFC-783 |x| | | | | + octet |RFC-783 |x| | | | | + mail |4.2.2.1 | | | |x| | + extensions |4.2.3.3 | | |x| | | +Use adaptive timeout |4.2.3.2 |x| | | | | +Configurable access control |4.2.3.4 | |x| | | | +Silently ignore broadcast request |4.2.3.5 | |x| | | | +-------------------------------------------------|--------|-|-|-|-|-|-- +-------------------------------------------------|--------|-|-|-|-|-|-- + + + + + + + + + + + + + + + + + + + + + + + + + +Internet Engineering Task Force [Page 47] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + +5. ELECTRONIC MAIL -- SMTP and RFC-822 + + 5.1 INTRODUCTION + + In the TCP/IP protocol suite, electronic mail in a format + specified in RFC-822 [SMTP:2] is transmitted using the Simple Mail + Transfer Protocol (SMTP) defined in RFC-821 [SMTP:1]. + + While SMTP has remained unchanged over the years, the Internet + community has made several changes in the way SMTP is used. In + particular, the conversion to the Domain Name System (DNS) has + caused changes in address formats and in mail routing. In this + section, we assume familiarity with the concepts and terminology + of the DNS, whose requirements are given in Section 6.1. + + RFC-822 specifies the Internet standard format for electronic mail + messages. RFC-822 supercedes an older standard, RFC-733, that may + still be in use in a few places, although it is obsolete. The two + formats are sometimes referred to simply by number ("822" and + "733"). + + RFC-822 is used in some non-Internet mail environments with + different mail transfer protocols than SMTP, and SMTP has also + been adapted for use in some non-Internet environments. Note that + this document presents the rules for the use of SMTP and RFC-822 + for the Internet environment only; other mail environments that + use these protocols may be expected to have their own rules. + + 5.2 PROTOCOL WALK-THROUGH + + This section covers both RFC-821 and RFC-822. + + The SMTP specification in RFC-821 is clear and contains numerous + examples, so implementors should not find it difficult to + understand. This section simply updates or annotates portions of + RFC-821 to conform with current usage. + + RFC-822 is a long and dense document, defining a rich syntax. + Unfortunately, incomplete or defective implementations of RFC-822 + are common. In fact, nearly all of the many formats of RFC-822 + are actually used, so an implementation generally needs to + recognize and correctly interpret all of the RFC-822 syntax. + + 5.2.1 The SMTP Model: RFC-821 Section 2 + + DISCUSSION: + Mail is sent by a series of request/response transactions + between a client, the "sender-SMTP," and a server, the + + + +Internet Engineering Task Force [Page 48] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + "receiver-SMTP". These transactions pass (1) the message + proper, which is composed of header and body, and (2) SMTP + source and destination addresses, referred to as the + "envelope". + + The SMTP programs are analogous to Message Transfer Agents + (MTAs) of X.400. There will be another level of protocol + software, closer to the end user, that is responsible for + composing and analyzing RFC-822 message headers; this + component is known as the "User Agent" in X.400, and we + use that term in this document. There is a clear logical + distinction between the User Agent and the SMTP + implementation, since they operate on different levels of + protocol. Note, however, that this distinction is may not + be exactly reflected the structure of typical + implementations of Internet mail. Often there is a + program known as the "mailer" that implements SMTP and + also some of the User Agent functions; the rest of the + User Agent functions are included in a user interface used + for entering and reading mail. + + The SMTP envelope is constructed at the originating site, + typically by the User Agent when the message is first + queued for the Sender-SMTP program. The envelope + addresses may be derived from information in the message + header, supplied by the user interface (e.g., to implement + a bcc: request), or derived from local configuration + information (e.g., expansion of a mailing list). The SMTP + envelope cannot in general be re-derived from the header + at a later stage in message delivery, so the envelope is + transmitted separately from the message itself using the + MAIL and RCPT commands of SMTP. + + The text of RFC-821 suggests that mail is to be delivered + to an individual user at a host. With the advent of the + domain system and of mail routing using mail-exchange (MX) + resource records, implementors should now think of + delivering mail to a user at a domain, which may or may + not be a particular host. This DOES NOT change the fact + that SMTP is a host-to-host mail exchange protocol. + + 5.2.2 Canonicalization: RFC-821 Section 3.1 + + The domain names that a Sender-SMTP sends in MAIL and RCPT + commands MUST have been "canonicalized," i.e., they must be + fully-qualified principal names or domain literals, not + nicknames or domain abbreviations. A canonicalized name either + identifies a host directly or is an MX name; it cannot be a + + + +Internet Engineering Task Force [Page 49] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + CNAME. + + 5.2.3 VRFY and EXPN Commands: RFC-821 Section 3.3 + + A receiver-SMTP MUST implement VRFY and SHOULD implement EXPN + (this requirement overrides RFC-821). However, there MAY be + configuration information to disable VRFY and EXPN in a + particular installation; this might even allow EXPN to be + disabled for selected lists. + + A new reply code is defined for the VRFY command: + + 252 Cannot VRFY user (e.g., info is not local), but will + take message for this user and attempt delivery. + + DISCUSSION: + SMTP users and administrators make regular use of these + commands for diagnosing mail delivery problems. With the + increasing use of multi-level mailing list expansion + (sometimes more than two levels), EXPN has been + increasingly important for diagnosing inadvertent mail + loops. On the other hand, some feel that EXPN represents + a significant privacy, and perhaps even a security, + exposure. + + 5.2.4 SEND, SOML, and SAML Commands: RFC-821 Section 3.4 + + An SMTP MAY implement the commands to send a message to a + user's terminal: SEND, SOML, and SAML. + + DISCUSSION: + It has been suggested that the use of mail relaying + through an MX record is inconsistent with the intent of + SEND to deliver a message immediately and directly to a + user's terminal. However, an SMTP receiver that is unable + to write directly to the user terminal can return a "251 + User Not Local" reply to the RCPT following a SEND, to + inform the originator of possibly deferred delivery. + + 5.2.5 HELO Command: RFC-821 Section 3.5 + + The sender-SMTP MUST ensure that the parameter in a + HELO command is a valid principal host domain name for the + client host. As a result, the receiver-SMTP will not have to + perform MX resolution on this name in order to validate the + HELO parameter. + + The HELO receiver MAY verify that the HELO parameter really + + + +Internet Engineering Task Force [Page 50] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + corresponds to the IP address of the sender. However, the + receiver MUST NOT refuse to accept a message, even if the + sender's HELO command fails verification. + + DISCUSSION: + Verifying the HELO parameter requires a domain name lookup + and may therefore take considerable time. An alternative + tool for tracking bogus mail sources is suggested below + (see "DATA Command"). + + Note also that the HELO argument is still required to have + valid syntax, since it will appear in a Received: + line; otherwise, a 501 error is to be sent. + + IMPLEMENTATION: + When HELO parameter validation fails, a suggested + procedure is to insert a note about the unknown + authenticity of the sender into the message header (e.g., + in the "Received:" line). + + 5.2.6 Mail Relay: RFC-821 Section 3.6 + + We distinguish three types of mail (store-and-) forwarding: + + (1) A simple forwarder or "mail exchanger" forwards a message + using private knowledge about the recipient; see section + 3.2 of RFC-821. + + (2) An SMTP mail "relay" forwards a message within an SMTP + mail environment as the result of an explicit source route + (as defined in section 3.6 of RFC-821). The SMTP relay + function uses the "@...:" form of source route from RFC- + 822 (see Section 5.2.19 below). + + (3) A mail "gateway" passes a message between different + environments. The rules for mail gateways are discussed + below in Section 5.3.7. + + An Internet host that is forwarding a message but is not a + gateway to a different mail environment (i.e., it falls under + (1) or (2)) SHOULD NOT alter any existing header fields, + although the host will add an appropriate Received: line as + required in Section 5.2.8. + + A Sender-SMTP SHOULD NOT send a RCPT TO: command containing an + explicit source route using the "@...:" address form. Thus, + the relay function defined in section 3.6 of RFC-821 should + not be used. + + + +Internet Engineering Task Force [Page 51] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + DISCUSSION: + The intent is to discourage all source routing and to + abolish explicit source routing for mail delivery within + the Internet environment. Source-routing is unnecessary; + the simple target address "user@domain" should always + suffice. This is the result of an explicit architectural + decision to use universal naming rather than source + routing for mail. Thus, SMTP provides end-to-end + connectivity, and the DNS provides globally-unique, + location-independent names. MX records handle the major + case where source routing might otherwise be needed. + + A receiver-SMTP MUST accept the explicit source route syntax in + the envelope, but it MAY implement the relay function as + defined in section 3.6 of RFC-821. If it does not implement + the relay function, it SHOULD attempt to deliver the message + directly to the host to the right of the right-most "@" sign. + + DISCUSSION: + For example, suppose a host that does not implement the + relay function receives a message with the SMTP command: + "RCPT TO:<@ALPHA,@BETA:joe@GAMMA>", where ALPHA, BETA, and + GAMMA represent domain names. Rather than immediately + refusing the message with a 550 error reply as suggested + on page 20 of RFC-821, the host should try to forward the + message to GAMMA directly, using: "RCPT TO:". + Since this host does not support relaying, it is not + required to update the reverse path. + + Some have suggested that source routing may be needed + occasionally for manually routing mail around failures; + however, the reality and importance of this need is + controversial. The use of explicit SMTP mail relaying for + this purpose is discouraged, and in fact it may not be + successful, as many host systems do not support it. Some + have used the "%-hack" (see Section 5.2.16) for this + purpose. + + 5.2.7 RCPT Command: RFC-821 Section 4.1.1 + + A host that supports a receiver-SMTP MUST support the reserved + mailbox "Postmaster". + + The receiver-SMTP MAY verify RCPT parameters as they arrive; + however, RCPT responses MUST NOT be delayed beyond a reasonable + time (see Section 5.3.2). + + Therefore, a "250 OK" response to a RCPT does not necessarily + + + +Internet Engineering Task Force [Page 52] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + imply that the delivery address(es) are valid. Errors found + after message acceptance will be reported by mailing a + notification message to an appropriate address (see Section + 5.3.3). + + DISCUSSION: + The set of conditions under which a RCPT parameter can be + validated immediately is an engineering design choice. + Reporting destination mailbox errors to the Sender-SMTP + before mail is transferred is generally desirable to save + time and network bandwidth, but this advantage is lost if + RCPT verification is lengthy. + + For example, the receiver can verify immediately any + simple local reference, such as a single locally- + registered mailbox. On the other hand, the "reasonable + time" limitation generally implies deferring verification + of a mailing list until after the message has been + transferred and accepted, since verifying a large mailing + list can take a very long time. An implementation might + or might not choose to defer validation of addresses that + are non-local and therefore require a DNS lookup. If a + DNS lookup is performed but a soft domain system error + (e.g., timeout) occurs, validity must be assumed. + + 5.2.8 DATA Command: RFC-821 Section 4.1.1 + + Every receiver-SMTP (not just one that "accepts a message for + relaying or for final delivery" [SMTP:1]) MUST insert a + "Received:" line at the beginning of a message. In this line, + called a "time stamp line" in RFC-821: + + * The FROM field SHOULD contain both (1) the name of the + source host as presented in the HELO command and (2) a + domain literal containing the IP address of the source, + determined from the TCP connection. + + * The ID field MAY contain an "@" as suggested in RFC-822, + but this is not required. + + * The FOR field MAY contain a list of entries when + multiple RCPT commands have been given. + + + An Internet mail program MUST NOT change a Received: line that + was previously added to the message header. + + + + + +Internet Engineering Task Force [Page 53] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + DISCUSSION: + Including both the source host and the IP source address + in the Received: line may provide enough information for + tracking illicit mail sources and eliminate a need to + explicitly verify the HELO parameter. + + Received: lines are primarily intended for humans tracing + mail routes, primarily of diagnosis of faults. See also + the discussion under 5.3.7. + + When the receiver-SMTP makes "final delivery" of a message, + then it MUST pass the MAIL FROM: address from the SMTP envelope + with the message, for use if an error notification message must + be sent later (see Section 5.3.3). There is an analogous + requirement when gatewaying from the Internet into a different + mail environment; see Section 5.3.7. + + DISCUSSION: + Note that the final reply to the DATA command depends only + upon the successful transfer and storage of the message. + Any problem with the destination address(es) must either + (1) have been reported in an SMTP error reply to the RCPT + command(s), or (2) be reported in a later error message + mailed to the originator. + + IMPLEMENTATION: + The MAIL FROM: information may be passed as a parameter or + in a Return-Path: line inserted at the beginning of the + message. + + 5.2.9 Command Syntax: RFC-821 Section 4.1.2 + + The syntax shown in RFC-821 for the MAIL FROM: command omits + the case of an empty path: "MAIL FROM: <>" (see RFC-821 Page + 15). An empty reverse path MUST be supported. + + 5.2.10 SMTP Replies: RFC-821 Section 4.2 + + A receiver-SMTP SHOULD send only the reply codes listed in + section 4.2.2 of RFC-821 or in this document. A receiver-SMTP + SHOULD use the text shown in examples in RFC-821 whenever + appropriate. + + A sender-SMTP MUST determine its actions only by the reply + code, not by the text (except for 251 and 551 replies); any + text, including no text at all, must be acceptable. The space + (blank) following the reply code is considered part of the + text. Whenever possible, a sender-SMTP SHOULD test only the + + + +Internet Engineering Task Force [Page 54] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + first digit of the reply code, as specified in Appendix E of + RFC-821. + + DISCUSSION: + Interoperability problems have arisen with SMTP systems + using reply codes that are not listed explicitly in RFC- + 821 Section 4.3 but are legal according to the theory of + reply codes explained in Appendix E. + + 5.2.11 Transparency: RFC-821 Section 4.5.2 + + Implementors MUST be sure that their mail systems always add + and delete periods to ensure message transparency. + + 5.2.12 WKS Use in MX Processing: RFC-974, p. 5 + + RFC-974 [SMTP:3] recommended that the domain system be queried + for WKS ("Well-Known Service") records, to verify that each + proposed mail target does support SMTP. Later experience has + shown that WKS is not widely supported, so the WKS step in MX + processing SHOULD NOT be used. + + The following are notes on RFC-822, organized by section of that + document. + + 5.2.13 RFC-822 Message Specification: RFC-822 Section 4 + + The syntax shown for the Return-path line omits the possibility + of a null return path, which is used to prevent looping of + error notifications (see Section 5.3.3). The complete syntax + is: + + return = "Return-path" ":" route-addr + / "Return-path" ":" "<" ">" + + The set of optional header fields is hereby expanded to include + the Content-Type field defined in RFC-1049 [SMTP:7]. This + field "allows mail reading systems to automatically identify + the type of a structured message body and to process it for + display accordingly". [SMTP:7] A User Agent MAY support this + field. + + 5.2.14 RFC-822 Date and Time Specification: RFC-822 Section 5 + + The syntax for the date is hereby changed to: + + date = 1*2DIGIT month 2*4DIGIT + + + + +Internet Engineering Task Force [Page 55] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + All mail software SHOULD use 4-digit years in dates, to ease + the transition to the next century. + + There is a strong trend towards the use of numeric timezone + indicators, and implementations SHOULD use numeric timezones + instead of timezone names. However, all implementations MUST + accept either notation. If timezone names are used, they MUST + be exactly as defined in RFC-822. + + The military time zones are specified incorrectly in RFC-822: + they count the wrong way from UT (the signs are reversed). As + a result, military time zones in RFC-822 headers carry no + information. + + Finally, note that there is a typo in the definition of "zone" + in the syntax summary of appendix D; the correct definition + occurs in Section 3 of RFC-822. + + 5.2.15 RFC-822 Syntax Change: RFC-822 Section 6.1 + + The syntactic definition of "mailbox" in RFC-822 is hereby + changed to: + + mailbox = addr-spec ; simple address + / [phrase] route-addr ; name & addr-spec + + That is, the phrase preceding a route address is now OPTIONAL. + This change makes the following header field legal, for + example: + + From: + + 5.2.16 RFC-822 Local-part: RFC-822 Section 6.2 + + The basic mailbox address specification has the form: "local- + part@domain". Here "local-part", sometimes called the "left- + hand side" of the address, is domain-dependent. + + A host that is forwarding the message but is not the + destination host implied by the right-hand side "domain" MUST + NOT interpret or modify the "local-part" of the address. + + When mail is to be gatewayed from the Internet mail environment + into a foreign mail environment (see Section 5.3.7), routing + information for that foreign environment MAY be embedded within + the "local-part" of the address. The gateway will then + interpret this local part appropriately for the foreign mail + environment. + + + +Internet Engineering Task Force [Page 56] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + DISCUSSION: + Although source routes are discouraged within the Internet + (see Section 5.2.6), there are non-Internet mail + environments whose delivery mechanisms do depend upon + source routes. Source routes for extra-Internet + environments can generally be buried in the "local-part" + of the address (see Section 5.2.16) while mail traverses + the Internet. When the mail reaches the appropriate + Internet mail gateway, the gateway will interpret the + local-part and build the necessary address or route for + the target mail environment. + + For example, an Internet host might send mail to: + "a!b!c!user@gateway-domain". The complex local part + "a!b!c!user" would be uninterpreted within the Internet + domain, but could be parsed and understood by the + specified mail gateway. + + An embedded source route is sometimes encoded in the + "local-part" using "%" as a right-binding routing + operator. For example, in: + + user%domain%relay3%relay2@relay1 + + the "%" convention implies that the mail is to be routed + from "relay1" through "relay2", "relay3", and finally to + "user" at "domain". This is commonly known as the "%- + hack". It is suggested that "%" have lower precedence + than any other routing operator (e.g., "!") hidden in the + local-part; for example, "a!b%c" would be interpreted as + "(a!b)%c". + + Only the target host (in this case, "relay1") is permitted + to analyze the local-part "user%domain%relay3%relay2". + + 5.2.17 Domain Literals: RFC-822 Section 6.2.3 + + A mailer MUST be able to accept and parse an Internet domain + literal whose content ("dtext"; see RFC-822) is a dotted- + decimal host address. This satisfies the requirement of + Section 2.1 for the case of mail. + + An SMTP MUST accept and recognize a domain literal for any of + its own IP addresses. + + + + + + + +Internet Engineering Task Force [Page 57] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + 5.2.18 Common Address Formatting Errors: RFC-822 Section 6.1 + + Errors in formatting or parsing 822 addresses are unfortunately + common. This section mentions only the most common errors. A + User Agent MUST accept all valid RFC-822 address formats, and + MUST NOT generate illegal address syntax. + + o A common error is to leave out the semicolon after a group + identifier. + + o Some systems fail to fully-qualify domain names in + messages they generate. The right-hand side of an "@" + sign in a header address field MUST be a fully-qualified + domain name. + + For example, some systems fail to fully-qualify the From: + address; this prevents a "reply" command in the user + interface from automatically constructing a return + address. + + DISCUSSION: + Although RFC-822 allows the local use of abbreviated + domain names within a domain, the application of + RFC-822 in Internet mail does not allow this. The + intent is that an Internet host must not send an SMTP + message header containing an abbreviated domain name + in an address field. This allows the address fields + of the header to be passed without alteration across + the Internet, as required in Section 5.2.6. + + o Some systems mis-parse multiple-hop explicit source routes + such as: + + @relay1,@relay2,@relay3:user@domain. + + + o Some systems over-qualify domain names by adding a + trailing dot to some or all domain names in addresses or + message-ids. This violates RFC-822 syntax. + + + 5.2.19 Explicit Source Routes: RFC-822 Section 6.2.7 + + Internet host software SHOULD NOT create an RFC-822 header + containing an address with an explicit source route, but MUST + accept such headers for compatibility with earlier systems. + + DISCUSSION: + + + +Internet Engineering Task Force [Page 58] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + In an understatement, RFC-822 says "The use of explicit + source routing is discouraged". Many hosts implemented + RFC-822 source routes incorrectly, so the syntax cannot be + used unambiguously in practice. Many users feel the + syntax is ugly. Explicit source routes are not needed in + the mail envelope for delivery; see Section 5.2.6. For + all these reasons, explicit source routes using the RFC- + 822 notations are not to be used in Internet mail headers. + + As stated in Section 5.2.16, it is necessary to allow an + explicit source route to be buried in the local-part of an + address, e.g., using the "%-hack", in order to allow mail + to be gatewayed into another environment in which explicit + source routing is necessary. The vigilant will observe + that there is no way for a User Agent to detect and + prevent the use of such implicit source routing when the + destination is within the Internet. We can only + discourage source routing of any kind within the Internet, + as unnecessary and undesirable. + + 5.3 SPECIFIC ISSUES + + 5.3.1 SMTP Queueing Strategies + + The common structure of a host SMTP implementation includes + user mailboxes, one or more areas for queueing messages in + transit, and one or more daemon processes for sending and + receiving mail. The exact structure will vary depending on the + needs of the users on the host and the number and size of + mailing lists supported by the host. We describe several + optimizations that have proved helpful, particularly for + mailers supporting high traffic levels. + + Any queueing strategy MUST include: + + o Timeouts on all activities. See Section 5.3.2. + + o Never sending error messages in response to error + messages. + + + 5.3.1.1 Sending Strategy + + The general model of a sender-SMTP is one or more processes + that periodically attempt to transmit outgoing mail. In a + typical system, the program that composes a message has some + method for requesting immediate attention for a new piece of + outgoing mail, while mail that cannot be transmitted + + + +Internet Engineering Task Force [Page 59] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + immediately MUST be queued and periodically retried by the + sender. A mail queue entry will include not only the + message itself but also the envelope information. + + The sender MUST delay retrying a particular destination + after one attempt has failed. In general, the retry + interval SHOULD be at least 30 minutes; however, more + sophisticated and variable strategies will be beneficial + when the sender-SMTP can determine the reason for non- + delivery. + + Retries continue until the message is transmitted or the + sender gives up; the give-up time generally needs to be at + least 4-5 days. The parameters to the retry algorithm MUST + be configurable. + + A sender SHOULD keep a list of hosts it cannot reach and + corresponding timeouts, rather than just retrying queued + mail items. + + DISCUSSION: + Experience suggests that failures are typically + transient (the target system has crashed), favoring a + policy of two connection attempts in the first hour the + message is in the queue, and then backing off to once + every two or three hours. + + The sender-SMTP can shorten the queueing delay by + cooperation with the receiver-SMTP. In particular, if + mail is received from a particular address, it is good + evidence that any mail queued for that host can now be + sent. + + The strategy may be further modified as a result of + multiple addresses per host (see Section 5.3.4), to + optimize delivery time vs. resource usage. + + A sender-SMTP may have a large queue of messages for + each unavailable destination host, and if it retried + all these messages in every retry cycle, there would be + excessive Internet overhead and the daemon would be + blocked for a long period. Note that an SMTP can + generally determine that a delivery attempt has failed + only after a timeout of a minute or more; a one minute + timeout per connection will result in a very large + delay if it is repeated for dozens or even hundreds of + queued messages. + + + + +Internet Engineering Task Force [Page 60] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + When the same message is to be delivered to several users on + the same host, only one copy of the message SHOULD be + transmitted. That is, the sender-SMTP should use the + command sequence: RCPT, RCPT,... RCPT, DATA instead of the + sequence: RCPT, DATA, RCPT, DATA,... RCPT, DATA. + Implementation of this efficiency feature is strongly urged. + + Similarly, the sender-SMTP MAY support multiple concurrent + outgoing mail transactions to achieve timely delivery. + However, some limit SHOULD be imposed to protect the host + from devoting all its resources to mail. + + The use of the different addresses of a multihomed host is + discussed below. + + 5.3.1.2 Receiving strategy + + The receiver-SMTP SHOULD attempt to keep a pending listen on + the SMTP port at all times. This will require the support + of multiple incoming TCP connections for SMTP. Some limit + MAY be imposed. + + IMPLEMENTATION: + When the receiver-SMTP receives mail from a particular + host address, it could notify the sender-SMTP to retry + any mail pending for that host address. + + 5.3.2 Timeouts in SMTP + + There are two approaches to timeouts in the sender-SMTP: (a) + limit the time for each SMTP command separately, or (b) limit + the time for the entire SMTP dialogue for a single mail + message. A sender-SMTP SHOULD use option (a), per-command + timeouts. Timeouts SHOULD be easily reconfigurable, preferably + without recompiling the SMTP code. + + DISCUSSION: + Timeouts are an essential feature of an SMTP + implementation. If the timeouts are too long (or worse, + there are no timeouts), Internet communication failures or + software bugs in receiver-SMTP programs can tie up SMTP + processes indefinitely. If the timeouts are too short, + resources will be wasted with attempts that time out part + way through message delivery. + + If option (b) is used, the timeout has to be very large, + e.g., an hour, to allow time to expand very large mailing + lists. The timeout may also need to increase linearly + + + +Internet Engineering Task Force [Page 61] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + with the size of the message, to account for the time to + transmit a very large message. A large fixed timeout + leads to two problems: a failure can still tie up the + sender for a very long time, and very large messages may + still spuriously time out (which is a wasteful failure!). + + Using the recommended option (a), a timer is set for each + SMTP command and for each buffer of the data transfer. + The latter means that the overall timeout is inherently + proportional to the size of the message. + + Based on extensive experience with busy mail-relay hosts, the + minimum per-command timeout values SHOULD be as follows: + + o Initial 220 Message: 5 minutes + + A Sender-SMTP process needs to distinguish between a + failed TCP connection and a delay in receiving the initial + 220 greeting message. Many receiver-SMTPs will accept a + TCP connection but delay delivery of the 220 message until + their system load will permit more mail to be processed. + + o MAIL Command: 5 minutes + + + o RCPT Command: 5 minutes + + A longer timeout would be required if processing of + mailing lists and aliases were not deferred until after + the message was accepted. + + o DATA Initiation: 2 minutes + + This is while awaiting the "354 Start Input" reply to a + DATA command. + + o Data Block: 3 minutes + + This is while awaiting the completion of each TCP SEND + call transmitting a chunk of data. + + o DATA Termination: 10 minutes. + + This is while awaiting the "250 OK" reply. When the + receiver gets the final period terminating the message + data, it typically performs processing to deliver the + message to a user mailbox. A spurious timeout at this + point would be very wasteful, since the message has been + + + +Internet Engineering Task Force [Page 62] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + successfully sent. + + A receiver-SMTP SHOULD have a timeout of at least 5 minutes + while it is awaiting the next command from the sender. + + 5.3.3 Reliable Mail Receipt + + When the receiver-SMTP accepts a piece of mail (by sending a + "250 OK" message in response to DATA), it is accepting + responsibility for delivering or relaying the message. It must + take this responsibility seriously, i.e., it MUST NOT lose the + message for frivolous reasons, e.g., because the host later + crashes or because of a predictable resource shortage. + + If there is a delivery failure after acceptance of a message, + the receiver-SMTP MUST formulate and mail a notification + message. This notification MUST be sent using a null ("<>") + reverse path in the envelope; see Section 3.6 of RFC-821. The + recipient of this notification SHOULD be the address from the + envelope return path (or the Return-Path: line). However, if + this address is null ("<>"), the receiver-SMTP MUST NOT send a + notification. If the address is an explicit source route, it + SHOULD be stripped down to its final hop. + + DISCUSSION: + For example, suppose that an error notification must be + sent for a message that arrived with: + "MAIL FROM:<@a,@b:user@d>". The notification message + should be sent to: "RCPT TO:". + + Some delivery failures after the message is accepted by + SMTP will be unavoidable. For example, it may be + impossible for the receiver-SMTP to validate all the + delivery addresses in RCPT command(s) due to a "soft" + domain system error or because the target is a mailing + list (see earlier discussion of RCPT). + + To avoid receiving duplicate messages as the result of + timeouts, a receiver-SMTP MUST seek to minimize the time + required to respond to the final "." that ends a message + transfer. See RFC-1047 [SMTP:4] for a discussion of this + problem. + + 5.3.4 Reliable Mail Transmission + + To transmit a message, a sender-SMTP determines the IP address + of the target host from the destination address in the + envelope. Specifically, it maps the string to the right of the + + + +Internet Engineering Task Force [Page 63] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + "@" sign into an IP address. This mapping or the transfer + itself may fail with a soft error, in which case the sender- + SMTP will requeue the outgoing mail for a later retry, as + required in Section 5.3.1.1. + + When it succeeds, the mapping can result in a list of + alternative delivery addresses rather than a single address, + because of (a) multiple MX records, (b) multihoming, or both. + To provide reliable mail transmission, the sender-SMTP MUST be + able to try (and retry) each of the addresses in this list in + order, until a delivery attempt succeeds. However, there MAY + also be a configurable limit on the number of alternate + addresses that can be tried. In any case, a host SHOULD try at + least two addresses. + + The following information is to be used to rank the host + addresses: + + (1) Multiple MX Records -- these contain a preference + indication that should be used in sorting. If there are + multiple destinations with the same preference and there + is no clear reason to favor one (e.g., by address + preference), then the sender-SMTP SHOULD pick one at + random to spread the load across multiple mail exchanges + for a specific organization; note that this is a + refinement of the procedure in [DNS:3]. + + (2) Multihomed host -- The destination host (perhaps taken + from the preferred MX record) may be multihomed, in which + case the domain name resolver will return a list of + alternative IP addresses. It is the responsibility of the + domain name resolver interface (see Section 6.1.3.4 below) + to have ordered this list by decreasing preference, and + SMTP MUST try them in the order presented. + + DISCUSSION: + Although the capability to try multiple alternative + addresses is required, there may be circumstances where + specific installations want to limit or disable the use of + alternative addresses. The question of whether a sender + should attempt retries using the different addresses of a + multihomed host has been controversial. The main argument + for using the multiple addresses is that it maximizes the + probability of timely delivery, and indeed sometimes the + probability of any delivery; the counter argument is that + it may result in unnecessary resource use. + + Note that resource use is also strongly determined by the + + + +Internet Engineering Task Force [Page 64] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + sending strategy discussed in Section 5.3.1. + + 5.3.5 Domain Name Support + + SMTP implementations MUST use the mechanism defined in Section + 6.1 for mapping between domain names and IP addresses. This + means that every Internet SMTP MUST include support for the + Internet DNS. + + In particular, a sender-SMTP MUST support the MX record scheme + [SMTP:3]. See also Section 7.4 of [DNS:2] for information on + domain name support for SMTP. + + 5.3.6 Mailing Lists and Aliases + + An SMTP-capable host SHOULD support both the alias and the list + form of address expansion for multiple delivery. When a + message is delivered or forwarded to each address of an + expanded list form, the return address in the envelope + ("MAIL FROM:") MUST be changed to be the address of a person + who administers the list, but the message header MUST be left + unchanged; in particular, the "From" field of the message is + unaffected. + + DISCUSSION: + An important mail facility is a mechanism for multi- + destination delivery of a single message, by transforming + or "expanding" a pseudo-mailbox address into a list of + destination mailbox addresses. When a message is sent to + such a pseudo-mailbox (sometimes called an "exploder"), + copies are forwarded or redistributed to each mailbox in + the expanded list. We classify such a pseudo-mailbox as + an "alias" or a "list", depending upon the expansion + rules: + + (a) Alias + + To expand an alias, the recipient mailer simply + replaces the pseudo-mailbox address in the envelope + with each of the expanded addresses in turn; the rest + of the envelope and the message body are left + unchanged. The message is then delivered or + forwarded to each expanded address. + + (b) List + + A mailing list may be said to operate by + "redistribution" rather than by "forwarding". To + + + +Internet Engineering Task Force [Page 65] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + expand a list, the recipient mailer replaces the + pseudo-mailbox address in the envelope with each of + the expanded addresses in turn. The return address in + the envelope is changed so that all error messages + generated by the final deliveries will be returned to + a list administrator, not to the message originator, + who generally has no control over the contents of the + list and will typically find error messages annoying. + + + 5.3.7 Mail Gatewaying + + Gatewaying mail between different mail environments, i.e., + different mail formats and protocols, is complex and does not + easily yield to standardization. See for example [SMTP:5a], + [SMTP:5b]. However, some general requirements may be given for + a gateway between the Internet and another mail environment. + + (A) Header fields MAY be rewritten when necessary as messages + are gatewayed across mail environment boundaries. + + DISCUSSION: + This may involve interpreting the local-part of the + destination address, as suggested in Section 5.2.16. + + The other mail systems gatewayed to the Internet + generally use a subset of RFC-822 headers, but some + of them do not have an equivalent to the SMTP + envelope. Therefore, when a message leaves the + Internet environment, it may be necessary to fold the + SMTP envelope information into the message header. A + possible solution would be to create new header + fields to carry the envelope information (e.g., "X- + SMTP-MAIL:" and "X-SMTP-RCPT:"); however, this would + require changes in mail programs in the foreign + environment. + + (B) When forwarding a message into or out of the Internet + environment, a gateway MUST prepend a Received: line, but + it MUST NOT alter in any way a Received: line that is + already in the header. + + DISCUSSION: + This requirement is a subset of the general + "Received:" line requirement of Section 5.2.8; it is + restated here for emphasis. + + Received: fields of messages originating from other + + + +Internet Engineering Task Force [Page 66] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + environments may not conform exactly to RFC822. + However, the most important use of Received: lines is + for debugging mail faults, and this debugging can be + severely hampered by well-meaning gateways that try + to "fix" a Received: line. + + The gateway is strongly encouraged to indicate the + environment and protocol in the "via" clauses of + Received field(s) that it supplies. + + (C) From the Internet side, the gateway SHOULD accept all + valid address formats in SMTP commands and in RFC-822 + headers, and all valid RFC-822 messages. Although a + gateway must accept an RFC-822 explicit source route + ("@...:" format) in either the RFC-822 header or in the + envelope, it MAY or may not act on the source route; see + Sections 5.2.6 and 5.2.19. + + DISCUSSION: + It is often tempting to restrict the range of + addresses accepted at the mail gateway to simplify + the translation into addresses for the remote + environment. This practice is based on the + assumption that mail users have control over the + addresses their mailers send to the mail gateway. In + practice, however, users have little control over the + addresses that are finally sent; their mailers are + free to change addresses into any legal RFC-822 + format. + + (D) The gateway MUST ensure that all header fields of a + message that it forwards into the Internet meet the + requirements for Internet mail. In particular, all + addresses in "From:", "To:", "Cc:", etc., fields must be + transformed (if necessary) to satisfy RFC-822 syntax, and + they must be effective and useful for sending replies. + + + (E) The translation algorithm used to convert mail from the + Internet protocols to another environment's protocol + SHOULD try to ensure that error messages from the foreign + mail environment are delivered to the return path from the + SMTP envelope, not to the sender listed in the "From:" + field of the RFC-822 message. + + DISCUSSION: + Internet mail lists usually place the address of the + mail list maintainer in the envelope but leave the + + + +Internet Engineering Task Force [Page 67] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + original message header intact (with the "From:" + field containing the original sender). This yields + the behavior the average recipient expects: a reply + to the header gets sent to the original sender, not + to a mail list maintainer; however, errors get sent + to the maintainer (who can fix the problem) and not + the sender (who probably cannot). + + (F) Similarly, when forwarding a message from another + environment into the Internet, the gateway SHOULD set the + envelope return path in accordance with an error message + return address, if any, supplied by the foreign + environment. + + + 5.3.8 Maximum Message Size + + Mailer software MUST be able to send and receive messages of at + least 64K bytes in length (including header), and a much larger + maximum size is highly desirable. + + DISCUSSION: + Although SMTP does not define the maximum size of a + message, many systems impose implementation limits. + + The current de facto minimum limit in the Internet is 64K + bytes. However, electronic mail is used for a variety of + purposes that create much larger messages. For example, + mail is often used instead of FTP for transmitting ASCII + files, and in particular to transmit entire documents. As + a result, messages can be 1 megabyte or even larger. We + note that the present document together with its lower- + layer companion contains 0.5 megabytes. + + + + + + + + + + + + + + + + + + +Internet Engineering Task Force [Page 68] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + 5.4 SMTP REQUIREMENTS SUMMARY + + | | | | |S| | + | | | | |H| |F + | | | | |O|M|o + | | |S| |U|U|o + | | |H| |L|S|t + | |M|O| |D|T|n + | |U|U|M| | |o + | |S|L|A|N|N|t + | |T|D|Y|O|O|t +FEATURE |SECTION | | | |T|T|e +-----------------------------------------------|----------|-|-|-|-|-|-- + | | | | | | | +RECEIVER-SMTP: | | | | | | | + Implement VRFY |5.2.3 |x| | | | | + Implement EXPN |5.2.3 | |x| | | | + EXPN, VRFY configurable |5.2.3 | | |x| | | + Implement SEND, SOML, SAML |5.2.4 | | |x| | | + Verify HELO parameter |5.2.5 | | |x| | | + Refuse message with bad HELO |5.2.5 | | | | |x| + Accept explicit src-route syntax in env. |5.2.6 |x| | | | | + Support "postmaster" |5.2.7 |x| | | | | + Process RCPT when received (except lists) |5.2.7 | | |x| | | + Long delay of RCPT responses |5.2.7 | | | | |x| + | | | | | | | + Add Received: line |5.2.8 |x| | | | | + Received: line include domain literal |5.2.8 | |x| | | | + Change previous Received: line |5.2.8 | | | | |x| + Pass Return-Path info (final deliv/gwy) |5.2.8 |x| | | | | + Support empty reverse path |5.2.9 |x| | | | | + Send only official reply codes |5.2.10 | |x| | | | + Send text from RFC-821 when appropriate |5.2.10 | |x| | | | + Delete "." for transparency |5.2.11 |x| | | | | + Accept and recognize self domain literal(s) |5.2.17 |x| | | | | + | | | | | | | + Error message about error message |5.3.1 | | | | |x| + Keep pending listen on SMTP port |5.3.1.2 | |x| | | | + Provide limit on recv concurrency |5.3.1.2 | | |x| | | + Wait at least 5 mins for next sender cmd |5.3.2 | |x| | | | + Avoidable delivery failure after "250 OK" |5.3.3 | | | | |x| + Send error notification msg after accept |5.3.3 |x| | | | | + Send using null return path |5.3.3 |x| | | | | + Send to envelope return path |5.3.3 | |x| | | | + Send to null address |5.3.3 | | | | |x| + Strip off explicit src route |5.3.3 | |x| | | | + Minimize acceptance delay (RFC-1047) |5.3.3 |x| | | | | +-----------------------------------------------|----------|-|-|-|-|-|-- + + + +Internet Engineering Task Force [Page 69] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + | | | | | | | +SENDER-SMTP: | | | | | | | + Canonicalized domain names in MAIL, RCPT |5.2.2 |x| | | | | + Implement SEND, SOML, SAML |5.2.4 | | |x| | | + Send valid principal host name in HELO |5.2.5 |x| | | | | + Send explicit source route in RCPT TO: |5.2.6 | | | |x| | + Use only reply code to determine action |5.2.10 |x| | | | | + Use only high digit of reply code when poss. |5.2.10 | |x| | | | + Add "." for transparency |5.2.11 |x| | | | | + | | | | | | | + Retry messages after soft failure |5.3.1.1 |x| | | | | + Delay before retry |5.3.1.1 |x| | | | | + Configurable retry parameters |5.3.1.1 |x| | | | | + Retry once per each queued dest host |5.3.1.1 | |x| | | | + Multiple RCPT's for same DATA |5.3.1.1 | |x| | | | + Support multiple concurrent transactions |5.3.1.1 | | |x| | | + Provide limit on concurrency |5.3.1.1 | |x| | | | + | | | | | | | + Timeouts on all activities |5.3.1 |x| | | | | + Per-command timeouts |5.3.2 | |x| | | | + Timeouts easily reconfigurable |5.3.2 | |x| | | | + Recommended times |5.3.2 | |x| | | | + Try alternate addr's in order |5.3.4 |x| | | | | + Configurable limit on alternate tries |5.3.4 | | |x| | | + Try at least two alternates |5.3.4 | |x| | | | + Load-split across equal MX alternates |5.3.4 | |x| | | | + Use the Domain Name System |5.3.5 |x| | | | | + Support MX records |5.3.5 |x| | | | | + Use WKS records in MX processing |5.2.12 | | | |x| | +-----------------------------------------------|----------|-|-|-|-|-|-- + | | | | | | | +MAIL FORWARDING: | | | | | | | + Alter existing header field(s) |5.2.6 | | | |x| | + Implement relay function: 821/section 3.6 |5.2.6 | | |x| | | + If not, deliver to RHS domain |5.2.6 | |x| | | | + Interpret 'local-part' of addr |5.2.16 | | | | |x| + | | | | | | | +MAILING LISTS AND ALIASES | | | | | | | + Support both |5.3.6 | |x| | | | + Report mail list error to local admin. |5.3.6 |x| | | | | + | | | | | | | +MAIL GATEWAYS: | | | | | | | + Embed foreign mail route in local-part |5.2.16 | | |x| | | + Rewrite header fields when necessary |5.3.7 | | |x| | | + Prepend Received: line |5.3.7 |x| | | | | + Change existing Received: line |5.3.7 | | | | |x| + Accept full RFC-822 on Internet side |5.3.7 | |x| | | | + Act on RFC-822 explicit source route |5.3.7 | | |x| | | + + + +Internet Engineering Task Force [Page 70] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + Send only valid RFC-822 on Internet side |5.3.7 |x| | | | | + Deliver error msgs to envelope addr |5.3.7 | |x| | | | + Set env return path from err return addr |5.3.7 | |x| | | | + | | | | | | | +USER AGENT -- RFC-822 | | | | | | | + Allow user to enter address |5.2.6 | | | |x| | + Support RFC-1049 Content Type field |5.2.13 | | |x| | | + Use 4-digit years |5.2.14 | |x| | | | + Generate numeric timezones |5.2.14 | |x| | | | + Accept all timezones |5.2.14 |x| | | | | + Use non-num timezones from RFC-822 |5.2.14 |x| | | | | + Omit phrase before route-addr |5.2.15 | | |x| | | + Accept and parse dot.dec. domain literals |5.2.17 |x| | | | | + Accept all RFC-822 address formats |5.2.18 |x| | | | | + Generate invalid RFC-822 address format |5.2.18 | | | | |x| + Fully-qualified domain names in header |5.2.18 |x| | | | | + Create explicit src route in header |5.2.19 | | | |x| | + Accept explicit src route in header |5.2.19 |x| | | | | + | | | | | | | +Send/recv at least 64KB messages |5.3.8 |x| | | | | + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Internet Engineering Task Force [Page 71] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + +6. SUPPORT SERVICES + + 6.1 DOMAIN NAME TRANSLATION + + 6.1.1 INTRODUCTION + + Every host MUST implement a resolver for the Domain Name System + (DNS), and it MUST implement a mechanism using this DNS + resolver to convert host names to IP addresses and vice-versa + [DNS:1, DNS:2]. + + In addition to the DNS, a host MAY also implement a host name + translation mechanism that searches a local Internet host + table. See Section 6.1.3.8 for more information on this + option. + + DISCUSSION: + Internet host name translation was originally performed by + searching local copies of a table of all hosts. This + table became too large to update and distribute in a + timely manner and too large to fit into many hosts, so the + DNS was invented. + + The DNS creates a distributed database used primarily for + the translation between host names and host addresses. + Implementation of DNS software is required. The DNS + consists of two logically distinct parts: name servers and + resolvers (although implementations often combine these + two logical parts in the interest of efficiency) [DNS:2]. + + Domain name servers store authoritative data about certain + sections of the database and answer queries about the + data. Domain resolvers query domain name servers for data + on behalf of user processes. Every host therefore needs a + DNS resolver; some host machines will also need to run + domain name servers. Since no name server has complete + information, in general it is necessary to obtain + information from more than one name server to resolve a + query. + + 6.1.2 PROTOCOL WALK-THROUGH + + An implementor must study references [DNS:1] and [DNS:2] + carefully. They provide a thorough description of the theory, + protocol, and implementation of the domain name system, and + reflect several years of experience. + + + + + +Internet Engineering Task Force [Page 72] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + 6.1.2.1 Resource Records with Zero TTL: RFC-1035 Section 3.2.1 + + All DNS name servers and resolvers MUST properly handle RRs + with a zero TTL: return the RR to the client but do not + cache it. + + DISCUSSION: + Zero TTL values are interpreted to mean that the RR can + only be used for the transaction in progress, and + should not be cached; they are useful for extremely + volatile data. + + 6.1.2.2 QCLASS Values: RFC-1035 Section 3.2.5 + + A query with "QCLASS=*" SHOULD NOT be used unless the + requestor is seeking data from more than one class. In + particular, if the requestor is only interested in Internet + data types, QCLASS=IN MUST be used. + + 6.1.2.3 Unused Fields: RFC-1035 Section 4.1.1 + + Unused fields in a query or response message MUST be zero. + + 6.1.2.4 Compression: RFC-1035 Section 4.1.4 + + Name servers MUST use compression in responses. + + DISCUSSION: + Compression is essential to avoid overflowing UDP + datagrams; see Section 6.1.3.2. + + 6.1.2.5 Misusing Configuration Info: RFC-1035 Section 6.1.2 + + Recursive name servers and full-service resolvers generally + have some configuration information containing hints about + the location of root or local name servers. An + implementation MUST NOT include any of these hints in a + response. + + DISCUSSION: + Many implementors have found it convenient to store + these hints as if they were cached data, but some + neglected to ensure that this "cached data" was not + included in responses. This has caused serious + problems in the Internet when the hints were obsolete + or incorrect. + + + + + +Internet Engineering Task Force [Page 73] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + 6.1.3 SPECIFIC ISSUES + + 6.1.3.1 Resolver Implementation + + A name resolver SHOULD be able to multiplex concurrent + requests if the host supports concurrent processes. + + In implementing a DNS resolver, one of two different models + MAY optionally be chosen: a full-service resolver, or a stub + resolver. + + + (A) Full-Service Resolver + + A full-service resolver is a complete implementation of + the resolver service, and is capable of dealing with + communication failures, failure of individual name + servers, location of the proper name server for a given + name, etc. It must satisfy the following requirements: + + o The resolver MUST implement a local caching + function to avoid repeated remote access for + identical requests, and MUST time out information + in the cache. + + o The resolver SHOULD be configurable with start-up + information pointing to multiple root name servers + and multiple name servers for the local domain. + This insures that the resolver will be able to + access the whole name space in normal cases, and + will be able to access local domain information + should the local network become disconnected from + the rest of the Internet. + + + (B) Stub Resolver + + A "stub resolver" relies on the services of a recursive + name server on the connected network or a "nearby" + network. This scheme allows the host to pass on the + burden of the resolver function to a name server on + another host. This model is often essential for less + capable hosts, such as PCs, and is also recommended + when the host is one of several workstations on a local + network, because it allows all of the workstations to + share the cache of the recursive name server and hence + reduce the number of domain requests exported by the + local network. + + + +Internet Engineering Task Force [Page 74] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + At a minimum, the stub resolver MUST be capable of + directing its requests to redundant recursive name + servers. Note that recursive name servers are allowed + to restrict the sources of requests that they will + honor, so the host administrator must verify that the + service will be provided. Stub resolvers MAY implement + caching if they choose, but if so, MUST timeout cached + information. + + + 6.1.3.2 Transport Protocols + + DNS resolvers and recursive servers MUST support UDP, and + SHOULD support TCP, for sending (non-zone-transfer) queries. + Specifically, a DNS resolver or server that is sending a + non-zone-transfer query MUST send a UDP query first. If the + Answer section of the response is truncated and if the + requester supports TCP, it SHOULD try the query again using + TCP. + + DNS servers MUST be able to service UDP queries and SHOULD + be able to service TCP queries. A name server MAY limit the + resources it devotes to TCP queries, but it SHOULD NOT + refuse to service a TCP query just because it would have + succeeded with UDP. + + Truncated responses MUST NOT be saved (cached) and later + used in such a way that the fact that they are truncated is + lost. + + DISCUSSION: + UDP is preferred over TCP for queries because UDP + queries have much lower overhead, both in packet count + and in connection state. The use of UDP is essential + for heavily-loaded servers, especially the root + servers. UDP also offers additional robustness, since + a resolver can attempt several UDP queries to different + servers for the cost of a single TCP query. + + It is possible for a DNS response to be truncated, + although this is a very rare occurrence in the present + Internet DNS. Practically speaking, truncation cannot + be predicted, since it is data-dependent. The + dependencies include the number of RRs in the answer, + the size of each RR, and the savings in space realized + by the name compression algorithm. As a rule of thumb, + truncation in NS and MX lists should not occur for + answers containing 15 or fewer RRs. + + + +Internet Engineering Task Force [Page 75] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + Whether it is possible to use a truncated answer + depends on the application. A mailer must not use a + truncated MX response, since this could lead to mail + loops. + + Responsible practices can make UDP suffice in the vast + majority of cases. Name servers must use compression + in responses. Resolvers must differentiate truncation + of the Additional section of a response (which only + loses extra information) from truncation of the Answer + section (which for MX records renders the response + unusable by mailers). Database administrators should + list only a reasonable number of primary names in lists + of name servers, MX alternatives, etc. + + However, it is also clear that some new DNS record + types defined in the future will contain information + exceeding the 512 byte limit that applies to UDP, and + hence will require TCP. Thus, resolvers and name + servers should implement TCP services as a backup to + UDP today, with the knowledge that they will require + the TCP service in the future. + + By private agreement, name servers and resolvers MAY arrange + to use TCP for all traffic between themselves. TCP MUST be + used for zone transfers. + + A DNS server MUST have sufficient internal concurrency that + it can continue to process UDP queries while awaiting a + response or performing a zone transfer on an open TCP + connection [DNS:2]. + + A server MAY support a UDP query that is delivered using an + IP broadcast or multicast address. However, the Recursion + Desired bit MUST NOT be set in a query that is multicast, + and MUST be ignored by name servers receiving queries via a + broadcast or multicast address. A host that sends broadcast + or multicast DNS queries SHOULD send them only as occasional + probes, caching the IP address(es) it obtains from the + response(s) so it can normally send unicast queries. + + DISCUSSION: + Broadcast or (especially) IP multicast can provide a + way to locate nearby name servers without knowing their + IP addresses in advance. However, general broadcasting + of recursive queries can result in excessive and + unnecessary load on both network and servers. + + + + +Internet Engineering Task Force [Page 76] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + 6.1.3.3 Efficient Resource Usage + + The following requirements on servers and resolvers are very + important to the health of the Internet as a whole, + particularly when DNS services are invoked repeatedly by + higher level automatic servers, such as mailers. + + (1) The resolver MUST implement retransmission controls to + insure that it does not waste communication bandwidth, + and MUST impose finite bounds on the resources consumed + to respond to a single request. See [DNS:2] pages 43- + 44 for specific recommendations. + + (2) After a query has been retransmitted several times + without a response, an implementation MUST give up and + return a soft error to the application. + + (3) All DNS name servers and resolvers SHOULD cache + temporary failures, with a timeout period of the order + of minutes. + + DISCUSSION: + This will prevent applications that immediately + retry soft failures (in violation of Section 2.2 + of this document) from generating excessive DNS + traffic. + + (4) All DNS name servers and resolvers SHOULD cache + negative responses that indicate the specified name, or + data of the specified type, does not exist, as + described in [DNS:2]. + + (5) When a DNS server or resolver retries a UDP query, the + retry interval SHOULD be constrained by an exponential + backoff algorithm, and SHOULD also have upper and lower + bounds. + + IMPLEMENTATION: + A measured RTT and variance (if available) should + be used to calculate an initial retransmission + interval. If this information is not available, a + default of no less than 5 seconds should be used. + Implementations may limit the retransmission + interval, but this limit must exceed twice the + Internet maximum segment lifetime plus service + delay at the name server. + + (6) When a resolver or server receives a Source Quench for + + + +Internet Engineering Task Force [Page 77] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + a query it has issued, it SHOULD take steps to reduce + the rate of querying that server in the near future. A + server MAY ignore a Source Quench that it receives as + the result of sending a response datagram. + + IMPLEMENTATION: + One recommended action to reduce the rate is to + send the next query attempt to an alternate + server, if there is one available. Another is to + backoff the retry interval for the same server. + + + 6.1.3.4 Multihomed Hosts + + When the host name-to-address function encounters a host + with multiple addresses, it SHOULD rank or sort the + addresses using knowledge of the immediately connected + network number(s) and any other applicable performance or + history information. + + DISCUSSION: + The different addresses of a multihomed host generally + imply different Internet paths, and some paths may be + preferable to others in performance, reliability, or + administrative restrictions. There is no general way + for the domain system to determine the best path. A + recommended approach is to base this decision on local + configuration information set by the system + administrator. + + IMPLEMENTATION: + The following scheme has been used successfully: + + (a) Incorporate into the host configuration data a + Network-Preference List, that is simply a list of + networks in preferred order. This list may be + empty if there is no preference. + + (b) When a host name is mapped into a list of IP + addresses, these addresses should be sorted by + network number, into the same order as the + corresponding networks in the Network-Preference + List. IP addresses whose networks do not appear + in the Network-Preference List should be placed at + the end of the list. + + + + + + +Internet Engineering Task Force [Page 78] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + 6.1.3.5 Extensibility + + DNS software MUST support all well-known, class-independent + formats [DNS:2], and SHOULD be written to minimize the + trauma associated with the introduction of new well-known + types and local experimentation with non-standard types. + + DISCUSSION: + The data types and classes used by the DNS are + extensible, and thus new types will be added and old + types deleted or redefined. Introduction of new data + types ought to be dependent only upon the rules for + compression of domain names inside DNS messages, and + the translation between printable (i.e., master file) + and internal formats for Resource Records (RRs). + + Compression relies on knowledge of the format of data + inside a particular RR. Hence compression must only be + used for the contents of well-known, class-independent + RRs, and must never be used for class-specific RRs or + RR types that are not well-known. The owner name of an + RR is always eligible for compression. + + A name server may acquire, via zone transfer, RRs that + the server doesn't know how to convert to printable + format. A resolver can receive similar information as + the result of queries. For proper operation, this data + must be preserved, and hence the implication is that + DNS software cannot use textual formats for internal + storage. + + The DNS defines domain name syntax very generally -- a + string of labels each containing up to 63 8-bit octets, + separated by dots, and with a maximum total of 255 + octets. Particular applications of the DNS are + permitted to further constrain the syntax of the domain + names they use, although the DNS deployment has led to + some applications allowing more general names. In + particular, Section 2.1 of this document liberalizes + slightly the syntax of a legal Internet host name that + was defined in RFC-952 [DNS:4]. + + 6.1.3.6 Status of RR Types + + Name servers MUST be able to load all RR types except MD and + MF from configuration files. The MD and MF types are + obsolete and MUST NOT be implemented; in particular, name + servers MUST NOT load these types from configuration files. + + + +Internet Engineering Task Force [Page 79] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + DISCUSSION: + The RR types MB, MG, MR, NULL, MINFO and RP are + considered experimental, and applications that use the + DNS cannot expect these RR types to be supported by + most domains. Furthermore these types are subject to + redefinition. + + The TXT and WKS RR types have not been widely used by + Internet sites; as a result, an application cannot rely + on the the existence of a TXT or WKS RR in most + domains. + + 6.1.3.7 Robustness + + DNS software may need to operate in environments where the + root servers or other servers are unavailable due to network + connectivity or other problems. In this situation, DNS name + servers and resolvers MUST continue to provide service for + the reachable part of the name space, while giving temporary + failures for the rest. + + DISCUSSION: + Although the DNS is meant to be used primarily in the + connected Internet, it should be possible to use the + system in networks which are unconnected to the + Internet. Hence implementations must not depend on + access to root servers before providing service for + local names. + + 6.1.3.8 Local Host Table + + DISCUSSION: + A host may use a local host table as a backup or + supplement to the DNS. This raises the question of + which takes precedence, the DNS or the host table; the + most flexible approach would make this a configuration + option. + + Typically, the contents of such a supplementary host + table will be determined locally by the site. However, + a publically-available table of Internet hosts is + maintained by the DDN Network Information Center (DDN + NIC), with a format documented in [DNS:4]. This table + can be retrieved from the DDN NIC using a protocol + described in [DNS:5]. It must be noted that this table + contains only a small fraction of all Internet hosts. + Hosts using this protocol to retrieve the DDN NIC host + table should use the VERSION command to check if the + + + +Internet Engineering Task Force [Page 80] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + table has changed before requesting the entire table + with the ALL command. The VERSION identifier should be + treated as an arbitrary string and tested only for + equality; no numerical sequence may be assumed. + + The DDN NIC host table includes administrative + information that is not needed for host operation and + is therefore not currently included in the DNS + database; examples include network and gateway entries. + However, much of this additional information will be + added to the DNS in the future. Conversely, the DNS + provides essential services (in particular, MX records) + that are not available from the DDN NIC host table. + + 6.1.4 DNS USER INTERFACE + + 6.1.4.1 DNS Administration + + This document is concerned with design and implementation + issues in host software, not with administrative or + operational issues. However, administrative issues are of + particular importance in the DNS, since errors in particular + segments of this large distributed database can cause poor + or erroneous performance for many sites. These issues are + discussed in [DNS:6] and [DNS:7]. + + 6.1.4.2 DNS User Interface + + Hosts MUST provide an interface to the DNS for all + application programs running on the host. This interface + will typically direct requests to a system process to + perform the resolver function [DNS:1, 6.1:2]. + + At a minimum, the basic interface MUST support a request for + all information of a specific type and class associated with + a specific name, and it MUST return either all of the + requested information, a hard error code, or a soft error + indication. When there is no error, the basic interface + returns the complete response information without + modification, deletion, or ordering, so that the basic + interface will not need to be changed to accommodate new + data types. + + DISCUSSION: + The soft error indication is an essential part of the + interface, since it may not always be possible to + access particular information from the DNS; see Section + 6.1.3.3. + + + +Internet Engineering Task Force [Page 81] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + A host MAY provide other DNS interfaces tailored to + particular functions, transforming the raw domain data into + formats more suited to these functions. In particular, a + host MUST provide a DNS interface to facilitate translation + between host addresses and host names. + + 6.1.4.3 Interface Abbreviation Facilities + + User interfaces MAY provide a method for users to enter + abbreviations for commonly-used names. Although the + definition of such methods is outside of the scope of the + DNS specification, certain rules are necessary to insure + that these methods allow access to the entire DNS name space + and to prevent excessive use of Internet resources. + + If an abbreviation method is provided, then: + + (a) There MUST be some convention for denoting that a name + is already complete, so that the abbreviation method(s) + are suppressed. A trailing dot is the usual method. + + (b) Abbreviation expansion MUST be done exactly once, and + MUST be done in the context in which the name was + entered. + + + DISCUSSION: + For example, if an abbreviation is used in a mail + program for a destination, the abbreviation should be + expanded into a full domain name and stored in the + queued message with an indication that it is already + complete. Otherwise, the abbreviation might be + expanded with a mail system search list, not the + user's, or a name could grow due to repeated + canonicalizations attempts interacting with wildcards. + + The two most common abbreviation methods are: + + (1) Interface-level aliases + + Interface-level aliases are conceptually implemented as + a list of alias/domain name pairs. The list can be + per-user or per-host, and separate lists can be + associated with different functions, e.g. one list for + host name-to-address translation, and a different list + for mail domains. When the user enters a name, the + interface attempts to match the name to the alias + component of a list entry, and if a matching entry can + + + +Internet Engineering Task Force [Page 82] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + be found, the name is replaced by the domain name found + in the pair. + + Note that interface-level aliases and CNAMEs are + completely separate mechanisms; interface-level aliases + are a local matter while CNAMEs are an Internet-wide + aliasing mechanism which is a required part of any DNS + implementation. + + (2) Search Lists + + A search list is conceptually implemented as an ordered + list of domain names. When the user enters a name, the + domain names in the search list are used as suffixes to + the user-supplied name, one by one, until a domain name + with the desired associated data is found, or the + search list is exhausted. Search lists often contain + the name of the local host's parent domain or other + ancestor domains. Search lists are often per-user or + per-process. + + It SHOULD be possible for an administrator to disable a + DNS search-list facility. Administrative denial may be + warranted in some cases, to prevent abuse of the DNS. + + There is danger that a search-list mechanism will + generate excessive queries to the root servers while + testing whether user input is a complete domain name, + lacking a final period to mark it as complete. A + search-list mechanism MUST have one of, and SHOULD have + both of, the following two provisions to prevent this: + + (a) The local resolver/name server can implement + caching of negative responses (see Section + 6.1.3.3). + + (b) The search list expander can require two or more + interior dots in a generated domain name before it + tries using the name in a query to non-local + domain servers, such as the root. + + DISCUSSION: + The intent of this requirement is to avoid + excessive delay for the user as the search list is + tested, and more importantly to prevent excessive + traffic to the root and other high-level servers. + For example, if the user supplied a name "X" and + the search list contained the root as a component, + + + +Internet Engineering Task Force [Page 83] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + a query would have to consult a root server before + the next search list alternative could be tried. + The resulting load seen by the root servers and + gateways near the root would be multiplied by the + number of hosts in the Internet. + + The negative caching alternative limits the effect + to the first time a name is used. The interior + dot rule is simpler to implement but can prevent + easy use of some top-level names. + + + 6.1.5 DOMAIN NAME SYSTEM REQUIREMENTS SUMMARY + + | | | | |S| | + | | | | |H| |F + | | | | |O|M|o + | | |S| |U|U|o + | | |H| |L|S|t + | |M|O| |D|T|n + | |U|U|M| | |o + | |S|L|A|N|N|t + | |T|D|Y|O|O|t +FEATURE |SECTION | | | |T|T|e +-----------------------------------------------|-----------|-|-|-|-|-|-- +GENERAL ISSUES | | | | | | | + | | | | | | | +Implement DNS name-to-address conversion |6.1.1 |x| | | | | +Implement DNS address-to-name conversion |6.1.1 |x| | | | | +Support conversions using host table |6.1.1 | | |x| | | +Properly handle RR with zero TTL |6.1.2.1 |x| | | | | +Use QCLASS=* unnecessarily |6.1.2.2 | |x| | | | + Use QCLASS=IN for Internet class |6.1.2.2 |x| | | | | +Unused fields zero |6.1.2.3 |x| | | | | +Use compression in responses |6.1.2.4 |x| | | | | + | | | | | | | +Include config info in responses |6.1.2.5 | | | | |x| +Support all well-known, class-indep. types |6.1.3.5 |x| | | | | +Easily expand type list |6.1.3.5 | |x| | | | +Load all RR types (except MD and MF) |6.1.3.6 |x| | | | | +Load MD or MF type |6.1.3.6 | | | | |x| +Operate when root servers, etc. unavailable |6.1.3.7 |x| | | | | +-----------------------------------------------|-----------|-|-|-|-|-|-- +RESOLVER ISSUES: | | | | | | | + | | | | | | | +Resolver support multiple concurrent requests |6.1.3.1 | |x| | | | +Full-service resolver: |6.1.3.1 | | |x| | | + Local caching |6.1.3.1 |x| | | | | + + + +Internet Engineering Task Force [Page 84] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + Information in local cache times out |6.1.3.1 |x| | | | | + Configurable with starting info |6.1.3.1 | |x| | | | +Stub resolver: |6.1.3.1 | | |x| | | + Use redundant recursive name servers |6.1.3.1 |x| | | | | + Local caching |6.1.3.1 | | |x| | | + Information in local cache times out |6.1.3.1 |x| | | | | +Support for remote multi-homed hosts: | | | | | | | + Sort multiple addresses by preference list |6.1.3.4 | |x| | | | + | | | | | | | +-----------------------------------------------|-----------|-|-|-|-|-|-- +TRANSPORT PROTOCOLS: | | | | | | | + | | | | | | | +Support UDP queries |6.1.3.2 |x| | | | | +Support TCP queries |6.1.3.2 | |x| | | | + Send query using UDP first |6.1.3.2 |x| | | | |1 + Try TCP if UDP answers are truncated |6.1.3.2 | |x| | | | +Name server limit TCP query resources |6.1.3.2 | | |x| | | + Punish unnecessary TCP query |6.1.3.2 | | | |x| | +Use truncated data as if it were not |6.1.3.2 | | | | |x| +Private agreement to use only TCP |6.1.3.2 | | |x| | | +Use TCP for zone transfers |6.1.3.2 |x| | | | | +TCP usage not block UDP queries |6.1.3.2 |x| | | | | +Support broadcast or multicast queries |6.1.3.2 | | |x| | | + RD bit set in query |6.1.3.2 | | | | |x| + RD bit ignored by server is b'cast/m'cast |6.1.3.2 |x| | | | | + Send only as occasional probe for addr's |6.1.3.2 | |x| | | | +-----------------------------------------------|-----------|-|-|-|-|-|-- +RESOURCE USAGE: | | | | | | | + | | | | | | | +Transmission controls, per [DNS:2] |6.1.3.3 |x| | | | | + Finite bounds per request |6.1.3.3 |x| | | | | +Failure after retries => soft error |6.1.3.3 |x| | | | | +Cache temporary failures |6.1.3.3 | |x| | | | +Cache negative responses |6.1.3.3 | |x| | | | +Retries use exponential backoff |6.1.3.3 | |x| | | | + Upper, lower bounds |6.1.3.3 | |x| | | | +Client handle Source Quench |6.1.3.3 | |x| | | | +Server ignore Source Quench |6.1.3.3 | | |x| | | +-----------------------------------------------|-----------|-|-|-|-|-|-- +USER INTERFACE: | | | | | | | + | | | | | | | +All programs have access to DNS interface |6.1.4.2 |x| | | | | +Able to request all info for given name |6.1.4.2 |x| | | | | +Returns complete info or error |6.1.4.2 |x| | | | | +Special interfaces |6.1.4.2 | | |x| | | + Name<->Address translation |6.1.4.2 |x| | | | | + | | | | | | | +Abbreviation Facilities: |6.1.4.3 | | |x| | | + + + +Internet Engineering Task Force [Page 85] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + Convention for complete names |6.1.4.3 |x| | | | | + Conversion exactly once |6.1.4.3 |x| | | | | + Conversion in proper context |6.1.4.3 |x| | | | | + Search list: |6.1.4.3 | | |x| | | + Administrator can disable |6.1.4.3 | |x| | | | + Prevention of excessive root queries |6.1.4.3 |x| | | | | + Both methods |6.1.4.3 | |x| | | | +-----------------------------------------------|-----------|-|-|-|-|-|-- +-----------------------------------------------|-----------|-|-|-|-|-|-- + +1. Unless there is private agreement between particular resolver and + particular server. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Internet Engineering Task Force [Page 86] + + + + +RFC1123 SUPPORT SERVICES -- INITIALIZATION October 1989 + + + 6.2 HOST INITIALIZATION + + 6.2.1 INTRODUCTION + + This section discusses the initialization of host software + across a connected network, or more generally across an + Internet path. This is necessary for a diskless host, and may + optionally be used for a host with disk drives. For a diskless + host, the initialization process is called "network booting" + and is controlled by a bootstrap program located in a boot ROM. + + To initialize a diskless host across the network, there are two + distinct phases: + + (1) Configure the IP layer. + + Diskless machines often have no permanent storage in which + to store network configuration information, so that + sufficient configuration information must be obtained + dynamically to support the loading phase that follows. + This information must include at least the IP addresses of + the host and of the boot server. To support booting + across a gateway, the address mask and a list of default + gateways are also required. + + (2) Load the host system code. + + During the loading phase, an appropriate file transfer + protocol is used to copy the system code across the + network from the boot server. + + A host with a disk may perform the first step, dynamic + configuration. This is important for microcomputers, whose + floppy disks allow network configuration information to be + mistakenly duplicated on more than one host. Also, + installation of new hosts is much simpler if they automatically + obtain their configuration information from a central server, + saving administrator time and decreasing the probability of + mistakes. + + 6.2.2 REQUIREMENTS + + 6.2.2.1 Dynamic Configuration + + A number of protocol provisions have been made for dynamic + configuration. + + o ICMP Information Request/Reply messages + + + +Internet Engineering Task Force [Page 87] + + + + +RFC1123 SUPPORT SERVICES -- INITIALIZATION October 1989 + + + This obsolete message pair was designed to allow a host + to find the number of the network it is on. + Unfortunately, it was useful only if the host already + knew the host number part of its IP address, + information that hosts requiring dynamic configuration + seldom had. + + o Reverse Address Resolution Protocol (RARP) [BOOT:4] + + RARP is a link-layer protocol for a broadcast medium + that allows a host to find its IP address given its + link layer address. Unfortunately, RARP does not work + across IP gateways and therefore requires a RARP server + on every network. In addition, RARP does not provide + any other configuration information. + + o ICMP Address Mask Request/Reply messages + + These ICMP messages allow a host to learn the address + mask for a particular network interface. + + o BOOTP Protocol [BOOT:2] + + This protocol allows a host to determine the IP + addresses of the local host and the boot server, the + name of an appropriate boot file, and optionally the + address mask and list of default gateways. To locate a + BOOTP server, the host broadcasts a BOOTP request using + UDP. Ad hoc gateway extensions have been used to + transmit the BOOTP broadcast through gateways, and in + the future the IP Multicasting facility will provide a + standard mechanism for this purpose. + + + The suggested approach to dynamic configuration is to use + the BOOTP protocol with the extensions defined in "BOOTP + Vendor Information Extensions" RFC-1084 [BOOT:3]. RFC-1084 + defines some important general (not vendor-specific) + extensions. In particular, these extensions allow the + address mask to be supplied in BOOTP; we RECOMMEND that the + address mask be supplied in this manner. + + DISCUSSION: + Historically, subnetting was defined long after IP, and + so a separate mechanism (ICMP Address Mask messages) + was designed to supply the address mask to a host. + However, the IP address mask and the corresponding IP + address conceptually form a pair, and for operational + + + +Internet Engineering Task Force [Page 88] + + + + +RFC1123 SUPPORT SERVICES -- INITIALIZATION October 1989 + + + simplicity they ought to be defined at the same time + and by the same mechanism, whether a configuration file + or a dynamic mechanism like BOOTP. + + Note that BOOTP is not sufficiently general to specify + the configurations of all interfaces of a multihomed + host. A multihomed host must either use BOOTP + separately for each interface, or configure one + interface using BOOTP to perform the loading, and + perform the complete initialization from a file later. + + Application layer configuration information is expected + to be obtained from files after loading of the system + code. + + 6.2.2.2 Loading Phase + + A suggested approach for the loading phase is to use TFTP + [BOOT:1] between the IP addresses established by BOOTP. + + TFTP to a broadcast address SHOULD NOT be used, for reasons + explained in Section 4.2.3.4. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Internet Engineering Task Force [Page 89] + + + + +RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 + + + 6.3 REMOTE MANAGEMENT + + 6.3.1 INTRODUCTION + + The Internet community has recently put considerable effort + into the development of network management protocols. The + result has been a two-pronged approach [MGT:1, MGT:6]: the + Simple Network Management Protocol (SNMP) [MGT:4] and the + Common Management Information Protocol over TCP (CMOT) [MGT:5]. + + In order to be managed using SNMP or CMOT, a host will need to + implement an appropriate management agent. An Internet host + SHOULD include an agent for either SNMP or CMOT. + + Both SNMP and CMOT operate on a Management Information Base + (MIB) that defines a collection of management values. By + reading and setting these values, a remote application may + query and change the state of the managed system. + + A standard MIB [MGT:3] has been defined for use by both + management protocols, using data types defined by the Structure + of Management Information (SMI) defined in [MGT:2]. Additional + MIB variables can be introduced under the "enterprises" and + "experimental" subtrees of the MIB naming space [MGT:2]. + + Every protocol module in the host SHOULD implement the relevant + MIB variables. A host SHOULD implement the MIB variables as + defined in the most recent standard MIB, and MAY implement + other MIB variables when appropriate and useful. + + 6.3.2 PROTOCOL WALK-THROUGH + + The MIB is intended to cover both hosts and gateways, although + there may be detailed differences in MIB application to the two + cases. This section contains the appropriate interpretation of + the MIB for hosts. It is likely that later versions of the MIB + will include more entries for host management. + + A managed host must implement the following groups of MIB + object definitions: System, Interfaces, Address Translation, + IP, ICMP, TCP, and UDP. + + The following specific interpretations apply to hosts: + + o ipInHdrErrors + + Note that the error "time-to-live exceeded" can occur in a + host only when it is forwarding a source-routed datagram. + + + +Internet Engineering Task Force [Page 90] + + + + +RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 + + + o ipOutNoRoutes + + This object counts datagrams discarded because no route + can be found. This may happen in a host if all the + default gateways in the host's configuration are down. + + o ipFragOKs, ipFragFails, ipFragCreates + + A host that does not implement intentional fragmentation + (see "Fragmentation" section of [INTRO:1]) MUST return the + value zero for these three objects. + + o icmpOutRedirects + + For a host, this object MUST always be zero, since hosts + do not send Redirects. + + o icmpOutAddrMaskReps + + For a host, this object MUST always be zero, unless the + host is an authoritative source of address mask + information. + + o ipAddrTable + + For a host, the "IP Address Table" object is effectively a + table of logical interfaces. + + o ipRoutingTable + + For a host, the "IP Routing Table" object is effectively a + combination of the host's Routing Cache and the static + route table described in "Routing Outbound Datagrams" + section of [INTRO:1]. + + Within each ipRouteEntry, ipRouteMetric1...4 normally will + have no meaning for a host and SHOULD always be -1, while + ipRouteType will normally have the value "remote". + + If destinations on the connected network do not appear in + the Route Cache (see "Routing Outbound Datagrams section + of [INTRO:1]), there will be no entries with ipRouteType + of "direct". + + + DISCUSSION: + The current MIB does not include Type-of-Service in an + ipRouteEntry, but a future revision is expected to make + + + +Internet Engineering Task Force [Page 91] + + + + +RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 + + + this addition. + + We also expect the MIB to be expanded to allow the remote + management of applications (e.g., the ability to partially + reconfigure mail systems). Network service applications + such as mail systems should therefore be written with the + "hooks" for remote management. + + 6.3.3 MANAGEMENT REQUIREMENTS SUMMARY + + | | | | |S| | + | | | | |H| |F + | | | | |O|M|o + | | |S| |U|U|o + | | |H| |L|S|t + | |M|O| |D|T|n + | |U|U|M| | |o + | |S|L|A|N|N|t + | |T|D|Y|O|O|t +FEATURE |SECTION | | | |T|T|e +-----------------------------------------------|-----------|-|-|-|-|-|-- +Support SNMP or CMOT agent |6.3.1 | |x| | | | +Implement specified objects in standard MIB |6.3.1 | |x| | | | + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Internet Engineering Task Force [Page 92] + + + + +RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 + + +7. REFERENCES + + This section lists the primary references with which every + implementer must be thoroughly familiar. It also lists some + secondary references that are suggested additional reading. + + INTRODUCTORY REFERENCES: + + + [INTRO:1] "Requirements for Internet Hosts -- Communication Layers," + IETF Host Requirements Working Group, R. Braden, Ed., RFC-1122, + October 1989. + + [INTRO:2] "DDN Protocol Handbook," NIC-50004, NIC-50005, NIC-50006, + (three volumes), SRI International, December 1985. + + [INTRO:3] "Official Internet Protocols," J. Reynolds and J. Postel, + RFC-1011, May 1987. + + This document is republished periodically with new RFC numbers; + the latest version must be used. + + [INTRO:4] "Protocol Document Order Information," O. Jacobsen and J. + Postel, RFC-980, March 1986. + + [INTRO:5] "Assigned Numbers," J. Reynolds and J. Postel, RFC-1010, + May 1987. + + This document is republished periodically with new RFC numbers; + the latest version must be used. + + + TELNET REFERENCES: + + + [TELNET:1] "Telnet Protocol Specification," J. Postel and J. + Reynolds, RFC-854, May 1983. + + [TELNET:2] "Telnet Option Specification," J. Postel and J. Reynolds, + RFC-855, May 1983. + + [TELNET:3] "Telnet Binary Transmission," J. Postel and J. Reynolds, + RFC-856, May 1983. + + [TELNET:4] "Telnet Echo Option," J. Postel and J. Reynolds, RFC-857, + May 1983. + + [TELNET:5] "Telnet Suppress Go Ahead Option," J. Postel and J. + + + +Internet Engineering Task Force [Page 93] + + + + +RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 + + + Reynolds, RFC-858, May 1983. + + [TELNET:6] "Telnet Status Option," J. Postel and J. Reynolds, RFC- + 859, May 1983. + + [TELNET:7] "Telnet Timing Mark Option," J. Postel and J. Reynolds, + RFC-860, May 1983. + + [TELNET:8] "Telnet Extended Options List," J. Postel and J. + Reynolds, RFC-861, May 1983. + + [TELNET:9] "Telnet End-Of-Record Option," J. Postel, RFC-855, + December 1983. + + [TELNET:10] "Telnet Terminal-Type Option," J. VanBokkelen, RFC-1091, + February 1989. + + This document supercedes RFC-930. + + [TELNET:11] "Telnet Window Size Option," D. Waitzman, RFC-1073, + October 1988. + + [TELNET:12] "Telnet Linemode Option," D. Borman, RFC-1116, August + 1989. + + [TELNET:13] "Telnet Terminal Speed Option," C. Hedrick, RFC-1079, + December 1988. + + [TELNET:14] "Telnet Remote Flow Control Option," C. Hedrick, RFC- + 1080, November 1988. + + + SECONDARY TELNET REFERENCES: + + + [TELNET:15] "Telnet Protocol," MIL-STD-1782, U.S. Department of + Defense, May 1984. + + This document is intended to describe the same protocol as RFC- + 854. In case of conflict, RFC-854 takes precedence, and the + present document takes precedence over both. + + [TELNET:16] "SUPDUP Protocol," M. Crispin, RFC-734, October 1977. + + [TELNET:17] "Telnet SUPDUP Option," M. Crispin, RFC-736, October + 1977. + + [TELNET:18] "Data Entry Terminal Option," J. Day, RFC-732, June 1977. + + + +Internet Engineering Task Force [Page 94] + + + + +RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 + + + [TELNET:19] "TELNET Data Entry Terminal option -- DODIIS + Implementation," A. Yasuda and T. Thompson, RFC-1043, February + 1988. + + + FTP REFERENCES: + + + [FTP:1] "File Transfer Protocol," J. Postel and J. Reynolds, RFC- + 959, October 1985. + + [FTP:2] "Document File Format Standards," J. Postel, RFC-678, + December 1974. + + [FTP:3] "File Transfer Protocol," MIL-STD-1780, U.S. Department of + Defense, May 1984. + + This document is based on an earlier version of the FTP + specification (RFC-765) and is obsolete. + + + TFTP REFERENCES: + + + [TFTP:1] "The TFTP Protocol Revision 2," K. Sollins, RFC-783, June + 1981. + + + MAIL REFERENCES: + + + [SMTP:1] "Simple Mail Transfer Protocol," J. Postel, RFC-821, August + 1982. + + [SMTP:2] "Standard For The Format of ARPA Internet Text Messages," + D. Crocker, RFC-822, August 1982. + + This document obsoleted an earlier specification, RFC-733. + + [SMTP:3] "Mail Routing and the Domain System," C. Partridge, RFC- + 974, January 1986. + + This RFC describes the use of MX records, a mandatory extension + to the mail delivery process. + + [SMTP:4] "Duplicate Messages and SMTP," C. Partridge, RFC-1047, + February 1988. + + + + +Internet Engineering Task Force [Page 95] + + + + +RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 + + + [SMTP:5a] "Mapping between X.400 and RFC 822," S. Kille, RFC-987, + June 1986. + + [SMTP:5b] "Addendum to RFC-987," S. Kille, RFC-???, September 1987. + + The two preceding RFC's define a proposed standard for + gatewaying mail between the Internet and the X.400 environments. + + [SMTP:6] "Simple Mail Transfer Protocol," MIL-STD-1781, U.S. + Department of Defense, May 1984. + + This specification is intended to describe the same protocol as + does RFC-821. However, MIL-STD-1781 is incomplete; in + particular, it does not include MX records [SMTP:3]. + + [SMTP:7] "A Content-Type Field for Internet Messages," M. Sirbu, + RFC-1049, March 1988. + + + DOMAIN NAME SYSTEM REFERENCES: + + + [DNS:1] "Domain Names - Concepts and Facilities," P. Mockapetris, + RFC-1034, November 1987. + + This document and the following one obsolete RFC-882, RFC-883, + and RFC-973. + + [DNS:2] "Domain Names - Implementation and Specification," RFC-1035, + P. Mockapetris, November 1987. + + + [DNS:3] "Mail Routing and the Domain System," C. Partridge, RFC-974, + January 1986. + + + [DNS:4] "DoD Internet Host Table Specification," K. Harrenstein, + RFC-952, M. Stahl, E. Feinler, October 1985. + + SECONDARY DNS REFERENCES: + + + [DNS:5] "Hostname Server," K. Harrenstein, M. Stahl, E. Feinler, + RFC-953, October 1985. + + [DNS:6] "Domain Administrators Guide," M. Stahl, RFC-1032, November + 1987. + + + + +Internet Engineering Task Force [Page 96] + + + + +RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 + + + [DNS:7] "Domain Administrators Operations Guide," M. Lottor, RFC- + 1033, November 1987. + + [DNS:8] "The Domain Name System Handbook," Vol. 4 of Internet + Protocol Handbook, NIC 50007, SRI Network Information Center, + August 1989. + + + SYSTEM INITIALIZATION REFERENCES: + + + [BOOT:1] "Bootstrap Loading Using TFTP," R. Finlayson, RFC-906, June + 1984. + + [BOOT:2] "Bootstrap Protocol (BOOTP)," W. Croft and J. Gilmore, RFC- + 951, September 1985. + + [BOOT:3] "BOOTP Vendor Information Extensions," J. Reynolds, RFC- + 1084, December 1988. + + Note: this RFC revised and obsoleted RFC-1048. + + [BOOT:4] "A Reverse Address Resolution Protocol," R. Finlayson, T. + Mann, J. Mogul, and M. Theimer, RFC-903, June 1984. + + + MANAGEMENT REFERENCES: + + + [MGT:1] "IAB Recommendations for the Development of Internet Network + Management Standards," V. Cerf, RFC-1052, April 1988. + + [MGT:2] "Structure and Identification of Management Information for + TCP/IP-based internets," M. Rose and K. McCloghrie, RFC-1065, + August 1988. + + [MGT:3] "Management Information Base for Network Management of + TCP/IP-based internets," M. Rose and K. McCloghrie, RFC-1066, + August 1988. + + [MGT:4] "A Simple Network Management Protocol," J. Case, M. Fedor, + M. Schoffstall, and C. Davin, RFC-1098, April 1989. + + [MGT:5] "The Common Management Information Services and Protocol + over TCP/IP," U. Warrier and L. Besaw, RFC-1095, April 1989. + + [MGT:6] "Report of the Second Ad Hoc Network Management Review + Group," V. Cerf, RFC-1109, August 1989. + + + +Internet Engineering Task Force [Page 97] + + + + +RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 + + +Security Considerations + + There are many security issues in the application and support + programs of host software, but a full discussion is beyond the scope + of this RFC. Security-related issues are mentioned in sections + concerning TFTP (Sections 4.2.1, 4.2.3.4, 4.2.3.5), the SMTP VRFY and + EXPN commands (Section 5.2.3), the SMTP HELO command (5.2.5), and the + SMTP DATA command (Section 5.2.8). + +Author's Address + + Robert Braden + USC/Information Sciences Institute + 4676 Admiralty Way + Marina del Rey, CA 90292-6695 + + Phone: (213) 822 1511 + + EMail: Braden@ISI.EDU + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Internet Engineering Task Force [Page 98] + diff --git a/doc/devel/rfc/rfc1413.txt b/doc/devel/rfc/rfc1413.txt new file mode 100644 index 00000000..17ede58a --- /dev/null +++ b/doc/devel/rfc/rfc1413.txt @@ -0,0 +1,451 @@ + + + + + + +Network Working Group M. St. Johns +Request for Comments: 1413 US Department of Defense +Obsoletes: 931 February 1993 + + + Identification Protocol + +Status of this Memo + + This RFC specifies an IAB standards track protocol for the Internet + community, and requests discussion and suggestions for improvements. + Please refer to the current edition of the "IAB Official Protocol + Standards" for the standardization state and status of this protocol. + Distribution of this memo is unlimited. + +1. INTRODUCTION + + The Identification Protocol (a.k.a., "ident", a.k.a., "the Ident + Protocol") provides a means to determine the identity of a user of a + particular TCP connection. Given a TCP port number pair, it returns + a character string which identifies the owner of that connection on + the server's system. + + The Identification Protocol was formerly called the Authentication + Server Protocol. It has been renamed to better reflect its function. + This document is a product of the TCP Client Identity Protocol + Working Group of the Internet Engineering Task Force (IETF). + +2. OVERVIEW + + This is a connection based application on TCP. A server listens for + TCP connections on TCP port 113 (decimal). Once a connection is + established, the server reads a line of data which specifies the + connection of interest. If it exists, the system dependent user + identifier of the connection of interest is sent as the reply. The + server may then either shut the connection down or it may continue to + read/respond to multiple queries. + + The server should close the connection down after a configurable + amount of time with no queries - a 60-180 second idle timeout is + recommended. The client may close the connection down at any time; + however to allow for network delays the client should wait at least + 30 seconds (or longer) after a query before abandoning the query and + closing the connection. + + + + + + + +St. Johns [Page 1] + +RFC 1413 Identification Protocol February 1993 + + +3. RESTRICTIONS + + Queries are permitted only for fully specified connections. The + query contains the local/foreign port pair -- the local/foreign + address pair used to fully specify the connection is taken from the + local and foreign address of query connection. This means a user on + address A may only query the server on address B about connections + between A and B. + +4. QUERY/RESPONSE FORMAT + + The server accepts simple text query requests of the form: + + , + + where is the TCP port (decimal) on the target (where + the "ident" server is running) system, and is the + TCP port (decimal) on the source (client) system. + + N.B - If a client on host A wants to ask a server on host B about a + connection specified locally (on the client's machine) as 23, 6191 + (an inbound TELNET connection), the client must actually ask about + 6191, 23 - which is how the connection would be specified on host B. + + For example: + + 6191, 23 + + The response is of the form + + , : : + + where , are the same pair as the + query, is a keyword identifying the type of response, and + is context dependent. + + The information returned is that associated with the fully specified + TCP connection identified by , , + , , where and + are the local and foreign IP addresses of the + querying connection -- i.e., the TCP connection to the Identification + Protocol Server. ( and are taken + from the query.) + + For example: + + 6193, 23 : USERID : UNIX : stjohns + 6195, 23 : ERROR : NO-USER + + + +St. Johns [Page 2] + +RFC 1413 Identification Protocol February 1993 + + +5. RESPONSE TYPES + +A response can be one of two types: + +USERID + + In this case, is a string consisting of an + operating system name (with an optional character set + identifier), followed by ":", followed by an + identification string. + + The character set (if present) is separated from the + operating system name by ",". The character set + identifier is used to indicate the character set of the + identification string. The character set identifier, + if omitted, defaults to "US-ASCII" (see below). + + Permitted operating system names and character set + names are specified in RFC 1340, "Assigned Numbers" or + its successors. + + In addition to those operating system and character set + names specified in "Assigned Numbers" there is one + special case operating system identifier - "OTHER". + + Unless "OTHER" is specified as the operating system + type, the server is expected to return the "normal" + user identification of the owner of this connection. + "Normal" in this context may be taken to mean a string + of characters which uniquely identifies the connection + owner such as a user identifier assigned by the system + administrator and used by such user as a mail + identifier, or as the "user" part of a user/password + pair used to gain access to system resources. When an + operating system is specified (e.g., anything but + "OTHER"), the user identifier is expected to be in a + more or less immediately useful form - e.g., something + that could be used as an argument to "finger" or as a + mail address. + + "OTHER" indicates the identifier is an unformatted + character string consisting of printable characters in + the specified character set. "OTHER" should be + specified if the user identifier does not meet the + constraints of the previous paragraph. Sending an + encrypted audit token, or returning other non-userid + information about a user (such as the real name and + phone number of a user from a UNIX passwd file) are + + + +St. Johns [Page 3] + +RFC 1413 Identification Protocol February 1993 + + + both examples of when "OTHER" should be used. + + Returned user identifiers are expected to be printable + in the character set indicated. + + The identifier is an unformatted octet string - - all + octets are permissible EXCEPT octal 000 (NUL), 012 (LF) + and 015 (CR). N.B. - space characters (040) following the + colon separator ARE part of the identifier string and + may not be ignored. A response string is still + terminated normally by a CR/LF. N.B. A string may be + printable, but is not *necessarily* printable. + +ERROR + + For some reason the port owner could not be determined, + tells why. The following are the permitted values of and + their meanings: + + INVALID-PORT + + Either the local or foreign port was improperly + specified. This should be returned if either or + both of the port ids were out of range (TCP port + numbers are from 1-65535), negative integers, reals or + in any fashion not recognized as a non-negative + integer. + + NO-USER + + The connection specified by the port pair is not + currently in use or currently not owned by an + identifiable entity. + + HIDDEN-USER + + The server was able to identify the user of this + port, but the information was not returned at the + request of the user. + + UNKNOWN-ERROR + + Can't determine connection owner; reason unknown. + Any error not covered above should return this + error code value. Optionally, this code MAY be + returned in lieu of any other specific error code + if, for example, the server desires to hide + information implied by the return of that error + + + +St. Johns [Page 4] + +RFC 1413 Identification Protocol February 1993 + + + code, or for any other reason. If a server + implements such a feature, it MUST be configurable + and it MUST default to returning the proper error + message. + + Other values may eventually be specified and defined in future + revisions to this document. If an implementer has a need to specify + a non-standard error code, that code must begin with "X". + + In addition, the server is allowed to drop the query connection + without responding. Any premature close (i.e., one where the client + does not receive the EOL, whether graceful or an abort should be + considered to have the same meaning as "ERROR : UNKNOWN-ERROR". + +FORMAL SYNTAX + + ::= + + ::= "," + + ::= + + ::= "015 012" ; CR-LF End of Line Indicator + + ::= | + + ::= ":" "ERROR" ":" + + ::= ":" "USERID" ":" + ":" + + ::= "INVALID-PORT" | "NO-USER" | "UNKNOWN-ERROR" + | "HIDDEN-USER" | + + ::= [ "," ] + + ::= "OTHER" | "UNIX" | ...etc. + ; (See "Assigned Numbers") + + ::= "US-ASCII" | ...etc. + ; (See "Assigned Numbers") + + ::= + + ::= 1*64 ; 1-64 characters + + ::= "X"1*63 + ; 2-64 chars beginning w/X + + + +St. Johns [Page 5] + +RFC 1413 Identification Protocol February 1993 + + + ::= 1*5 ; 1-5 digits. + + ::= "0" | "1" ... "8" | "9" ; 0-9 + + ::= + /?"'~`{}[]; > + ; upper and lowercase a-z plus + ; printables minus the colon ":" + ; character. + + ::= 1*512 + + ::= + + +Notes on Syntax: + + 1) To promote interoperability among variant + implementations, with respect to white space the above + syntax is understood to embody the "be conservative in + what you send and be liberal in what you accept" + philosophy. Clients and servers should not generate + unnecessary white space (space and tab characters) but + should accept white space anywhere except within a + token. In parsing responses, white space may occur + anywhere, except within a token. Specifically, any + amount of white space is permitted at the beginning or + end of a line both for queries and responses. This + does not apply for responses that contain a user ID + because everything after the colon after the operating + system type until the terminating CR/LF is taken as + part of the user ID. The terminating CR/LF is NOT + considered part of the user ID. + + 2) The above notwithstanding, servers should restrict the + amount of inter-token white space they send to the + smallest amount reasonable or useful. Clients should + feel free to abort a connection if they receive 1000 + characters without receiving an . + + 3) The 512 character limit on user IDs and the 64 + character limit on tokens should be understood to mean + as follows: a) No new token (i.e., OPSYS or ERROR-TYPE) + token will be defined that has a length greater than 64 + and b) a server SHOULD NOT send more than 512 octets of + user ID and a client MUST accept at least 512 octets of + + + +St. Johns [Page 6] + +RFC 1413 Identification Protocol February 1993 + + + user ID. Because of this limitation, a server MUST + return the most significant portion of the user ID in + the first 512 octets. + + 4) The character sets and character set identifiers should + map directly to those defined in or referenced by RFC 1340, + "Assigned Numbers" or its successors. Character set + identifiers only apply to the user identification field + - all other fields will be defined in and must be sent + as US-ASCII. + + 5) Although is defined as an + above, it must follow the format and character set + constraints implied by the ; see the + discussion above. + + 6) The character set provides context for the client to + print or store the returned user identification string. + If the client does not recognize or implement the + returned character set, it should handle the returned + identification string as OCTET, but should in addition + store or report the character set. An OCTET string + should be printed, stored or handled in hex notation + (0-9a-f) in addition to any other representation the + client implements - this provides a standard + representation among differing implementations. + +6. Security Considerations + + The information returned by this protocol is at most as trustworthy + as the host providing it OR the organization operating the host. For + example, a PC in an open lab has few if any controls on it to prevent + a user from having this protocol return any identifier the user + wants. Likewise, if the host has been compromised the information + returned may be completely erroneous and misleading. + + The Identification Protocol is not intended as an authorization or + access control protocol. At best, it provides some additional + auditing information with respect to TCP connections. At worst, it + can provide misleading, incorrect, or maliciously incorrect + information. + + The use of the information returned by this protocol for other than + auditing is strongly discouraged. Specifically, using Identification + Protocol information to make access control decisions - either as the + primary method (i.e., no other checks) or as an adjunct to other + methods may result in a weakening of normal host security. + + + + +St. Johns [Page 7] + +RFC 1413 Identification Protocol February 1993 + + + An Identification server may reveal information about users, + entities, objects or processes which might normally be considered + private. An Identification server provides service which is a rough + analog of the CallerID services provided by some phone companies and + many of the same privacy considerations and arguments that apply to + the CallerID service apply to Identification. If you wouldn't run a + "finger" server due to privacy considerations you may not want to run + this protocol. + +7. ACKNOWLEDGEMENTS + + Acknowledgement is given to Dan Bernstein who is primarily + responsible for renewing interest in this protocol and for pointing + out some annoying errors in RFC 931. + +References + + [1] St. Johns, M., "Authentication Server", RFC 931, TPSC, January + 1985. + + [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340, + USC/Information Sciences Institute, July 1992. + +Author's Address + + Michael C. St. Johns + DARPA/CSTO + 3701 N. Fairfax Dr + Arlington, VA 22203 + + Phone: (703) 696-2271 + EMail: stjohns@DARPA.MIL + + + + + + + + + + + + + + + + + + + +St. Johns [Page 8] + \ No newline at end of file diff --git a/doc/devel/rfc/rfc1428.txt b/doc/devel/rfc/rfc1428.txt new file mode 100644 index 00000000..9053b4fe --- /dev/null +++ b/doc/devel/rfc/rfc1428.txt @@ -0,0 +1,339 @@ + + + + + + +Network Working Group G. Vaudreuil +Request for Comments: 1428 CNRI + February 1993 + + + Transition of Internet Mail from + Just-Send-8 + to 8bit-SMTP/MIME + +Status of this Memo + + This RFC provides information for the Internet community. It does + not specify an Internet standard. Distribution of this memo is + unlimited. + +Abstract + + Protocols for extending SMTP to pass 8bit characters have been + defined [3] [4]. These protocols require that messages transported by + the extended SMTP are to be encoded in MIME [1] [2]. Before work + began on these protocols, several SMTP implementations adopted ad-hoc + mechanisms for sending 8bit data. It is desirable for the extended + SMTP environment and these ad hoc mechanisms interoperate. This + document outlines the problems in this environment and an approach to + minimizing the cost of transition from current usage of non-MIME 8bit + messages to MIME. + +1. Terminology + + RFC 821 defines a 7bit transport. A transport agent which does not + clear the high order bit upon receipt of octets with this bit set in + SMTP messages is called 8 bit transparent in this document. An + implementation of the general SMTP Extensions document [3] and the + 8bit extensions protocol [4] which passes MIME messages using all 8 + bits of an octet is called 8bit ESMTP. An implementation of extended + SMTP which does not accept 8bit characters is called 7bit ESMTP. A + gateway is defined to be a transport agent with User Agent authority + to alter or convert the content of a message. + +2. The Problem + + SMTP as defined in RFC 821 limits the sending of Internet Mail to + US-ASCII [5] characters. As the Internet has grown to include non- + English correspondents, the need to communicate with character sets + other than US-ASCII has prompted many vendors and users to extend + SMTP or RFC 822 to use non-ASCII character sets. Common approaches + are to send 7 bit national variant ISO 646 character sets over + current RFC822/SMTP, to extend SMTP and RFC822 to use 8bit ISO 8859 + + + +Vaudreuil [Page 1] + +RFC 1428 Transition to 8bit-SMTP/MIME February 1993 + + + character sets, and to use proprietary PC character sets. + + A third approach is used for Japanese mail. Japanese characters are + represented by pairs of octets with the high order bit cleared. + Switching between 14 bit character sets and 7 bit character sets is + indicated within the message by ISO 2022 escape sequences. + + So long as these implementations can communicate without intermediate + transformations and have a loose private agreement on the use of a + specific character set without tagging, basic mail service can be + provided. + + In the transition to the negotiated 8bit ESMTP/MIME environment, it + is important that mail sent by a currently non-conforming user can be + read by another non-conforming user. This existing functionality is + reduced by conversion from 8bit text to text encoded in unreadable + Base-64 or "garbled" text encoded in quoted printable. + + There are several interesting non-interoperable cases that currently + exist in non US-ASCII mail and several new ones likely to emerge in a + transition to 8bit/MIME. Below is a listing of the transition-to- + mime cases. Only solutions to (4) in the context of a translating + gateway are discussed in this memo. + + \ Receiver + \ 7bit 8bit MIME/ + Sender \| only | transparent | ESMTP + ---------------------------------------- + 7bit only | (1) | (1) | (1) + ---------------------------------------- + 8bit transparent | (2) | (3) | (4) + ---------------------------------------- + MIME/ESMTP | (5) | (5) | (6) + + + (1) 7Bit non-MIME sender to 7bit, MIME, or 8bit transparent receiver + + This will continue to work unchanged with nationally varient ISO + 646 or ISO 2022 character set shifting if an external "out of + band" agreement exists between the sender and the receiver. A + 7bit to 8bit/ESMTP gateway need not alter the content of this + message. + + (2) 8bit sender to 7bit non-MIME receiver + + The receiver will receive bit-stripped mail which results in the + mis-interpretation of the data and the wrong character being + displayed or printed. Mail sent using languages where most + + + +Vaudreuil [Page 2] + +RFC 1428 Transition to 8bit-SMTP/MIME February 1993 + + + characters are in the US-ASCII subset of ISO 8859 may be somewhat + readable. + + (3) 8bit transparent sender to 8bit transparent receiver + + Will work if an external agreement "out of band" to use a + particular character set without tagging exists between the sender + and the receiver. + + (4) 8bit transparent sender to MIME/ESMTP conformant receiver + + Will work if a reasonable upgrade path is provided via gateways, + the indicated character set tag inserted by the gateway is correct + and the receiver supports the character set chosen by the sender. + This case is the focus of this memo. + + (5) MIME/ESMTP sender to non-MIME 7bit receiver + + Because the ESMTP/MIME sender cannot know if the receiver will + understand 8bits, the sender will encode the text into base-64 or + quoted-printable which may be considered "garbled" by the + receiver. To provide a useful downgrade path the gateway must + have some knowledge about the capabilities of the receiver. When + the character set can be clearly identified, techniques like the + menmonic MNEM encoding described in RFC 1345 may be helpful in + this case. + + (6) MIME/ESMTP sender to MIME/ESMTP receiver + + Interoperability will be attained provided the receiver supports + the character set chosen by the sender. + +3. Upgrade Path from 8bit Transparent to ESMTP/MIME + + A gateway which has been upgraded to support Extended SMTP may + upgrade an 8bit message received to MIME. This is consistent with + the requirement that all 8bit mail sent by ESMTP be encoded in MIME. + The upgrade should be done using the best available information. + + A site may "upgrade" to MIME en-masse by implementing MIME conversion + for all messages leaving the site. For text messages, the body can + be converted by adding a MIME-version header and a Content-Type: + Text/Plain with the character set in use in the site, provided the + site uses a single character set. + + An appropriate Content-Transfer-Encoding header line must be added to + indicate any encoding that may be necessary. + + + + +Vaudreuil [Page 3] + +RFC 1428 Transition to 8bit-SMTP/MIME February 1993 + + + Example: + + MIME-Version: 1.0 + Content-Type: Text/Plain; Charset = ISO-8859-1 + Content-Transfer-Encoding: 8bit + + If no information about the character set in use is available, the + gateway should upgrade the content by using the character set + "unknown-8bit". The unknown-8bit value of the charset parameter + indicates only that no reliable information about the character + set(s) used in the message was available. + + If a message body has been upgraded to MIME, the RFC 822 headers + containing non US-ASCII characters must be upgraded to conform with + the header encoding rules of RFC1342. A gateway should recode all + unstructered header fields as well as RFC 822 "comment"s and + "phrase"s according to the rules of RFC 1342. There is no equivalent + in RFC 1342 to the "8bit" Content-Transfer-Encoding value for message + bodies so all 8bit header text must be transformed according to + either the "B" or the "Q" encoding method. For ISO 8859 character + sets, the "Q" encoding will generally result in somewhat readable + headers. + + Trace information should be added to the document with a convert + clause: "rfc822-to-8bit", "rfc822-to-base-64" or "rfc822-to-quoted- + printable" e.g., + + Received: from dbc.mtview.ca.us by dbc.mtview.ca.us + convert rfc822-to-8bit; Tue, 01 Sep 1992 01:18:00 -0700 + +Appendix - The "unknown-8bit" Character Set + + This section defines a "charset" parameter, for use in a MIME + Content-Type field. + + A special purpose character set called "unknown-8bit" is defined to + be an unknown 8bit character set, encoded into a sequence of octets. + It can be used as a label for any character set from any language, + using any encoding. It must not be further defined. + + The use of this token in a "charset=" field of a message indicates + that nothing is known about the character set used. This marker is + intended for use by non-MIME to MIME gateways; specifically in those + which translate from SMTP to 8bit ESMTP/MIME. + + This character set is not intended to be used by mail composers. It + is assumed that the mail composer knows the character set in use and + will mark it with a character set value as specified in [1], as + + + +Vaudreuil [Page 4] + +RFC 1428 Transition to 8bit-SMTP/MIME February 1993 + + + amended by current Assigned Numbers documents [6]. + + The use of the "unknown-8bit" label is intended only by mail gateway + agents which cannot determine via out-of-band information the + intended character set. + + The interpretation of the "unknown-8bit" is up to the mail reader. + It is assumed that in many cases the human user will be able to + interpret the information and choose an appropriate character set or + pre-processor. + +Acknowledgements + + This document originated as a hallway conversation between Ned Freed, + Neil Katin, and the author. Substantive input was received from + Jonathan Laventhol, Craig Everhart, Olle Jarnefors, and Olafur + Gudmundsson. The document was refined with the input of many + participants in the IETF SMTP Extensions Working Group. + +References + + [1] Borenstein, N., and N. Freed, "Multipurpose Internet Mail + Extensions", RFC 1341, Bellcore, Innosoft, June 1992. + + [2] Moore, K., "Representation of Non-ASCII Text in Internet Message + Headers", RFC 1342, University of Tennessee, June 1992. + + [3] Klensin, J., WG Chair, Freed, N., Editor, Rose, M., Stefferud, + E., and D. Crocker, "SMTP Service Extensions" RFC 1425, United + Nations University, Innosoft International, Inc., Dover Beach + Consulting, Inc., Network Management Associates, Inc., The Branch + Office, February 1993. + + [4] Klensin, J., WG Chair, Freed, N., Editor, Rose, M., Stefferud, + E., and D. Crocker, "SMTP Service Extensions for 8bit + MIMEtransport", RFC 1426, United Nations University, Innosoft + International, Inc., Dover Beach Consulting, Inc., Network + Management Associates, Inc., The Branch Office, February 1993. + + [5] Coded Character Set--7-Bit American Standard Code for Information + Interchange, ANSI X3.4-1986. + + [6] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340, + USC/Information Sciences Institute, July 1992. + +Security Considerations + + Security issues are not discussed in this memo. + + + +Vaudreuil [Page 5] + +RFC 1428 Transition to 8bit-SMTP/MIME February 1993 + + +Author's Address + + Greg Vaudreuil + Corporation for National Research Initiatives + 1895 Preston White Drive, Suite 100 + Reston, VA 22091 USA + + Phone: (703) 620-8990 + EMail: GVaudre@CNRI.Reston.VA.US + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Vaudreuil [Page 6] + \ No newline at end of file diff --git a/doc/devel/rfc/rfc1521.txt b/doc/devel/rfc/rfc1521.txt new file mode 100644 index 00000000..074ba415 --- /dev/null +++ b/doc/devel/rfc/rfc1521.txt @@ -0,0 +1,4539 @@ + + + + + + +Network Working Group N. Borenstein +Request for Comments: 1521 Bellcore +Obsoletes: 1341 N. Freed +Category: Standards Track Innosoft + September 1993 + + + MIME (Multipurpose Internet Mail Extensions) Part One: + Mechanisms for Specifying and Describing + the Format of Internet Message Bodies + +Status of this Memo + + This RFC specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" for the standardization state and status + of this protocol. Distribution of this memo is unlimited. + +Abstract + + STD 11, RFC 822 defines a message representation protocol which + specifies considerable detail about message headers, but which leaves + the message content, or message body, as flat ASCII text. This + document redefines the format of message bodies to allow multi-part + textual and non-textual message bodies to be represented and + exchanged without loss of information. This is based on earlier work + documented in RFC 934 and STD 11, RFC 1049, but extends and revises + that work. Because RFC 822 said so little about message bodies, this + document is largely orthogonal to (rather than a revision of) RFC + 822. + + In particular, this document is designed to provide facilities to + include multiple objects in a single message, to represent body text + in character sets other than US-ASCII, to represent formatted multi- + font text messages, to represent non-textual material such as images + and audio fragments, and generally to facilitate later extensions + defining new types of Internet mail for use by cooperating mail + agents. + + This document does NOT extend Internet mail header fields to permit + anything other than US-ASCII text data. Such extensions are the + subject of a companion document [RFC-1522]. + + This document is a revision of RFC 1341. Significant differences + from RFC 1341 are summarized in Appendix H. + + + + + +Borenstein & Freed [Page 1] + +RFC 1521 MIME September 1993 + + +Table of Contents + + 1. Introduction....................................... 3 + 2. Notations, Conventions, and Generic BNF Grammar.... 6 + 3. The MIME-Version Header Field...................... 7 + 4. The Content-Type Header Field...................... 9 + 5. The Content-Transfer-Encoding Header Field......... 13 + 5.1. Quoted-Printable Content-Transfer-Encoding......... 18 + 5.2. Base64 Content-Transfer-Encoding................... 21 + 6. Additional Content-Header Fields................... 23 + 6.1. Optional Content-ID Header Field................... 23 + 6.2. Optional Content-Description Header Field.......... 24 + 7. The Predefined Content-Type Values................. 24 + 7.1. The Text Content-Type.............................. 24 + 7.1.1. The charset parameter.............................. 25 + 7.1.2. The Text/plain subtype............................. 28 + 7.2. The Multipart Content-Type......................... 28 + 7.2.1. Multipart: The common syntax...................... 29 + 7.2.2. The Multipart/mixed (primary) subtype.............. 34 + 7.2.3. The Multipart/alternative subtype.................. 34 + 7.2.4. The Multipart/digest subtype....................... 36 + 7.2.5. The Multipart/parallel subtype..................... 37 + 7.2.6. Other Multipart subtypes........................... 37 + 7.3. The Message Content-Type........................... 38 + 7.3.1. The Message/rfc822 (primary) subtype............... 38 + 7.3.2. The Message/Partial subtype........................ 39 + 7.3.3. The Message/External-Body subtype.................. 42 + 7.3.3.1. The "ftp" and "tftp" access-types............... 44 + 7.3.3.2. The "anon-ftp" access-type...................... 45 + 7.3.3.3. The "local-file" and "afs" access-types......... 45 + 7.3.3.4. The "mail-server" access-type................... 45 + 7.3.3.5. Examples and Further Explanations............... 46 + 7.4. The Application Content-Type....................... 49 + 7.4.1. The Application/Octet-Stream (primary) subtype..... 50 + 7.4.2. The Application/PostScript subtype................. 50 + 7.4.3. Other Application subtypes......................... 53 + 7.5. The Image Content-Type............................. 53 + 7.6. The Audio Content-Type............................. 54 + 7.7. The Video Content-Type............................. 54 + 7.8. Experimental Content-Type Values................... 54 + 8. Summary............................................ 56 + 9. Security Considerations............................ 56 + 10. Authors' Addresses................................. 57 + 11. Acknowledgements................................... 58 + Appendix A -- Minimal MIME-Conformance.................... 60 + Appendix B -- General Guidelines For Sending Email Data... 63 + Appendix C -- A Complex Multipart Example................. 66 + Appendix D -- Collected Grammar........................... 68 + + + +Borenstein & Freed [Page 2] + +RFC 1521 MIME September 1993 + + + Appendix E -- IANA Registration Procedures................ 72 + E.1 Registration of New Content-type/subtype Values...... 72 + E.2 Registration of New Access-type Values + for Message/external-body............................ 73 + Appendix F -- Summary of the Seven Content-types.......... 74 + Appendix G -- Canonical Encoding Model.................... 76 + Appendix H -- Changes from RFC 1341....................... 78 + References................................................ 80 + +1. Introduction + + Since its publication in 1982, STD 11, RFC 822 [RFC-822] has defined + the standard format of textual mail messages on the Internet. Its + success has been such that the RFC 822 format has been adopted, + wholly or partially, well beyond the confines of the Internet and the + Internet SMTP transport defined by STD 10, RFC 821 [RFC-821]. As the + format has seen wider use, a number of limitations have proven + increasingly restrictive for the user community. + + RFC 822 was intended to specify a format for text messages. As such, + non-text messages, such as multimedia messages that might include + audio or images, are simply not mentioned. Even in the case of text, + however, RFC 822 is inadequate for the needs of mail users whose + languages require the use of character sets richer than US ASCII + [US-ASCII]. Since RFC 822 does not specify mechanisms for mail + containing audio, video, Asian language text, or even text in most + European languages, additional specifications are needed. + + One of the notable limitations of RFC 821/822 based mail systems is + the fact that they limit the contents of electronic mail messages to + relatively short lines of seven-bit ASCII. This forces users to + convert any non-textual data that they may wish to send into seven- + bit bytes representable as printable ASCII characters before invoking + a local mail UA (User Agent, a program with which human users send + and receive mail). Examples of such encodings currently used in the + Internet include pure hexadecimal, uuencode, the 3-in-4 base 64 + scheme specified in RFC 1421, the Andrew Toolkit Representation + [ATK], and many others. + + The limitations of RFC 822 mail become even more apparent as gateways + are designed to allow for the exchange of mail messages between RFC + 822 hosts and X.400 hosts. X.400 [X400] specifies mechanisms for the + inclusion of non-textual body parts within electronic mail messages. + The current standards for the mapping of X.400 messages to RFC 822 + messages specify either that X.400 non-textual body parts must be + converted to (not encoded in) an ASCII format, or that they must be + discarded, notifying the RFC 822 user that discarding has occurred. + This is clearly undesirable, as information that a user may wish to + + + +Borenstein & Freed [Page 3] + +RFC 1521 MIME September 1993 + + + receive is lost. Even though a user's UA may not have the capability + of dealing with the non-textual body part, the user might have some + mechanism external to the UA that can extract useful information from + the body part. Moreover, it does not allow for the fact that the + message may eventually be gatewayed back into an X.400 message + handling system (i.e., the X.400 message is "tunneled" through + Internet mail), where the non-textual information would definitely + become useful again. + + This document describes several mechanisms that combine to solve most + of these problems without introducing any serious incompatibilities + with the existing world of RFC 822 mail. In particular, it + describes: + + 1. A MIME-Version header field, which uses a version number to + declare a message to be conformant with this specification and + allows mail processing agents to distinguish between such + messages and those generated by older or non-conformant software, + which is presumed to lack such a field. + + 2. A Content-Type header field, generalized from RFC 1049 [RFC-1049], + which can be used to specify the type and subtype of data in the + body of a message and to fully specify the native representation + (encoding) of such data. + + 2.a. A "text" Content-Type value, which can be used to represent + textual information in a number of character sets and + formatted text description languages in a standardized + manner. + + 2.b. A "multipart" Content-Type value, which can be used to + combine several body parts, possibly of differing types of + data, into a single message. + + 2.c. An "application" Content-Type value, which can be used to + transmit application data or binary data, and hence, among + other uses, to implement an electronic mail file transfer + service. + + 2.d. A "message" Content-Type value, for encapsulating another + mail message. + + 2.e An "image" Content-Type value, for transmitting still image + (picture) data. + + 2.f. An "audio" Content-Type value, for transmitting audio or + voice data. + + + + +Borenstein & Freed [Page 4] + +RFC 1521 MIME September 1993 + + + 2.g. A "video" Content-Type value, for transmitting video or + moving image data, possibly with audio as part of the + composite video data format. + + 3. A Content-Transfer-Encoding header field, which can be used to + specify an auxiliary encoding that was applied to the data in + order to allow it to pass through mail transport mechanisms which + may have data or character set limitations. + + 4. Two additional header fields that can be used to further describe + the data in a message body, the Content-ID and Content- + Description header fields. + + MIME has been carefully designed as an extensible mechanism, and it + is expected that the set of content-type/subtype pairs and their + associated parameters will grow significantly with time. Several + other MIME fields, notably including character set names, are likely + to have new values defined over time. In order to ensure that the + set of such values is developed in an orderly, well-specified, and + public manner, MIME defines a registration process which uses the + Internet Assigned Numbers Authority (IANA) as a central registry for + such values. Appendix E provides details about how IANA registration + is accomplished. + + Finally, to specify and promote interoperability, Appendix A of this + document provides a basic applicability statement for a subset of the + above mechanisms that defines a minimal level of "conformance" with + this document. + + HISTORICAL NOTE: Several of the mechanisms described in this + document may seem somewhat strange or even baroque at first + reading. It is important to note that compatibility with existing + standards AND robustness across existing practice were two of the + highest priorities of the working group that developed this + document. In particular, compatibility was always favored over + elegance. + + MIME was first defined and published as RFCs 1341 and 1342 [RFC-1341] + [RFC-1342]. This document is a relatively minor updating of RFC + 1341, and is intended to supersede it. The differences between this + document and RFC 1341 are summarized in Appendix H. Please refer to + the current edition of the "IAB Official Protocol Standards" for the + standardization state and status of this protocol. Several other RFC + documents will be of interest to the MIME implementor, in particular + [RFC 1343], [RFC-1344], and [RFC-1345]. + + + + + + +Borenstein & Freed [Page 5] + +RFC 1521 MIME September 1993 + + +2. Notations, Conventions, and Generic BNF Grammar + + This document is being published in two versions, one as plain ASCII + text and one as PostScript (PostScript is a trademark of Adobe + Systems Incorporated.). While the text version is the official + specification, some will find the PostScript version easier to read. + The textual contents are identical. An Andrew-format copy of this + document is also available from the first author (Borenstein). + + Although the mechanisms specified in this document are all described + in prose, most are also described formally in the modified BNF + notation of RFC 822. Implementors will need to be familiar with this + notation in order to understand this specification, and are referred + to RFC 822 for a complete explanation of the modified BNF notation. + + Some of the modified BNF in this document makes reference to + syntactic entities that are defined in RFC 822 and not in this + document. A complete formal grammar, then, is obtained by combining + the collected grammar appendix of this document with that of RFC 822 + plus the modifications to RFC 822 defined in RFC 1123, which + specifically changes the syntax for `return', `date' and `mailbox'. + + The term CRLF, in this document, refers to the sequence of the two + ASCII characters CR (13) and LF (10) which, taken together, in this + order, denote a line break in RFC 822 mail. + + The term "character set" is used in this document to refer to a + method used with one or more tables to convert encoded text to a + series of octets. This definition is intended to allow various kinds + of text encodings, from simple single-table mappings such as ASCII to + complex table switching methods such as those that use ISO 2022's + techniques. However, a MIME character set name must fully specify + the mapping to be performed. + + The term "message", when not further qualified, means either the + (complete or "top-level") message being transferred on a network, or + a message encapsulated in a body of type "message". + + The term "body part", in this document, means one of the parts of the + body of a multipart entity. A body part has a header and a body, so + it makes sense to speak about the body of a body part. + + The term "entity", in this document, means either a message or a body + part. All kinds of entities share the property that they have a + header and a body. + + The term "body", when not further qualified, means the body of an + entity, that is the body of either a message or of a body part. + + + +Borenstein & Freed [Page 6] + +RFC 1521 MIME September 1993 + + + NOTE: The previous four definitions are clearly circular. This is + unavoidable, since the overall structure of a MIME message is + indeed recursive. + + In this document, all numeric and octet values are given in decimal + notation. + + It must be noted that Content-Type values, subtypes, and parameter + names as defined in this document are case-insensitive. However, + parameter values are case-sensitive unless otherwise specified for + the specific parameter. + + FORMATTING NOTE: This document has been carefully formatted for + ease of reading. The PostScript version of this document, in + particular, places notes like this one, which may be skipped by + the reader, in a smaller, italicized, font, and indents it as + well. In the text version, only the indentation is preserved, so + if you are reading the text version of this you might consider + using the PostScript version instead. However, all such notes will + be indented and preceded by "NOTE:" or some similar introduction, + even in the text version. + + The primary purpose of these non-essential notes is to convey + information about the rationale of this document, or to place this + document in the proper historical or evolutionary context. Such + information may be skipped by those who are focused entirely on + building a conformant implementation, but may be of use to those + who wish to understand why this document is written as it is. + + For ease of recognition, all BNF definitions have been placed in a + fixed-width font in the PostScript version of this document. + +3. The MIME-Version Header Field + + Since RFC 822 was published in 1982, there has really been only one + format standard for Internet messages, and there has been little + perceived need to declare the format standard in use. This document + is an independent document that complements RFC 822. Although the + extensions in this document have been defined in such a way as to be + compatible with RFC 822, there are still circumstances in which it + might be desirable for a mail-processing agent to know whether a + message was composed with the new standard in mind. + + Therefore, this document defines a new header field, "MIME-Version", + which is to be used to declare the version of the Internet message + body format standard in use. + + Messages composed in accordance with this document MUST include such + + + +Borenstein & Freed [Page 7] + +RFC 1521 MIME September 1993 + + + a header field, with the following verbatim text: + + MIME-Version: 1.0 + + The presence of this header field is an assertion that the message + has been composed in compliance with this document. + + Since it is possible that a future document might extend the message + format standard again, a formal BNF is given for the content of the + MIME-Version field: + + version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT + + Thus, future format specifiers, which might replace or extend "1.0", + are constrained to be two integer fields, separated by a period. If + a message is received with a MIME-version value other than "1.0", it + cannot be assumed to conform with this specification. + + Note that the MIME-Version header field is required at the top level + of a message. It is not required for each body part of a multipart + entity. It is required for the embedded headers of a body of type + "message" if and only if the embedded message is itself claimed to be + MIME-conformant. + + It is not possible to fully specify how a mail reader that conforms + with MIME as defined in this document should treat a message that + might arrive in the future with some value of MIME-Version other than + "1.0". However, conformant software is encouraged to check the + version number and at least warn the user if an unrecognized MIME- + version is encountered. + + It is also worth noting that version control for specific content- + types is not accomplished using the MIME-Version mechanism. In + particular, some formats (such as application/postscript) have + version numbering conventions that are internal to the document + format. Where such conventions exist, MIME does nothing to supersede + them. Where no such conventions exist, a MIME type might use a + "version" parameter in the content-type field if necessary. + + NOTE TO IMPLEMENTORS: All header fields defined in this document, + including MIME-Version, Content-type, etc., are subject to the + general syntactic rules for header fields specified in RFC 822. In + particular, all can include comments, which means that the following + two MIME-Version fields are equivalent: + + MIME-Version: 1.0 + MIME-Version: 1.0 (Generated by GBD-killer 3.7) + + + + +Borenstein & Freed [Page 8] + +RFC 1521 MIME September 1993 + + +4. The Content-Type Header Field + + The purpose of the Content-Type field is to describe the data + contained in the body fully enough that the receiving user agent can + pick an appropriate agent or mechanism to present the data to the + user, or otherwise deal with the data in an appropriate manner. + + HISTORICAL NOTE: The Content-Type header field was first defined in + RFC 1049. RFC 1049 Content-types used a simpler and less powerful + syntax, but one that is largely compatible with the mechanism given + here. + + The Content-Type header field is used to specify the nature of the + data in the body of an entity, by giving type and subtype + identifiers, and by providing auxiliary information that may be + required for certain types. After the type and subtype names, the + remainder of the header field is simply a set of parameters, + specified in an attribute/value notation. The set of meaningful + parameters differs for the different types. In particular, there are + NO globally-meaningful parameters that apply to all content-types. + Global mechanisms are best addressed, in the MIME model, by the + definition of additional Content-* header fields. The ordering of + parameters is not significant. Among the defined parameters is a + "charset" parameter by which the character set used in the body may + be declared. Comments are allowed in accordance with RFC 822 rules + for structured header fields. + + In general, the top-level Content-Type is used to declare the general + type of data, while the subtype specifies a specific format for that + type of data. Thus, a Content-Type of "image/xyz" is enough to tell + a user agent that the data is an image, even if the user agent has no + knowledge of the specific image format "xyz". Such information can + be used, for example, to decide whether or not to show a user the raw + data from an unrecognized subtype -- such an action might be + reasonable for unrecognized subtypes of text, but not for + unrecognized subtypes of image or audio. For this reason, registered + subtypes of audio, image, text, and video, should not contain + embedded information that is really of a different type. Such + compound types should be represented using the "multipart" or + "application" types. + + Parameters are modifiers of the content-subtype, and do not + fundamentally affect the requirements of the host system. Although + most parameters make sense only with certain content-types, others + are "global" in the sense that they might apply to any subtype. For + example, the "boundary" parameter makes sense only for the + "multipart" content-type, but the "charset" parameter might make + sense with several content-types. + + + +Borenstein & Freed [Page 9] + +RFC 1521 MIME September 1993 + + + An initial set of seven Content-Types is defined by this document. + This set of top-level names is intended to be substantially complete. + It is expected that additions to the larger set of supported types + can generally be accomplished by the creation of new subtypes of + these initial types. In the future, more top-level types may be + defined only by an extension to this standard. If another primary + type is to be used for any reason, it must be given a name starting + with "X-" to indicate its non-standard status and to avoid a + potential conflict with a future official name. + + In the Augmented BNF notation of RFC 822, a Content-Type header field + value is defined as follows: + + content := "Content-Type" ":" type "/" subtype *(";" + parameter) + ; case-insensitive matching of type and subtype + + type := "application" / "audio" + / "image" / "message" + / "multipart" / "text" + / "video" / extension-token + ; All values case-insensitive + + extension-token := x-token / iana-token + + iana-token := + + x-token := + + subtype := token ; case-insensitive + + parameter := attribute "=" value + + attribute := token ; case-insensitive + + value := token / quoted-string + + token := 1* + + tspecials := "(" / ")" / "<" / ">" / "@" + / "," / ";" / ":" / "\" / <"> + / "/" / "[" / "]" / "?" / "=" + ; Must be in quoted-string, + ; to use within parameter values + + + +Borenstein & Freed [Page 10] + +RFC 1521 MIME September 1993 + + + Note that the definition of "tspecials" is the same as the RFC 822 + definition of "specials" with the addition of the three characters + "/", "?", and "=", and the removal of ".". + + Note also that a subtype specification is MANDATORY. There are no + default subtypes. + + The type, subtype, and parameter names are not case sensitive. For + example, TEXT, Text, and TeXt are all equivalent. Parameter values + are normally case sensitive, but certain parameters are interpreted + to be case-insensitive, depending on the intended use. (For example, + multipart boundaries are case-sensitive, but the "access-type" for + message/External-body is not case-sensitive.) + + Beyond this syntax, the only constraint on the definition of subtype + names is the desire that their uses must not conflict. That is, it + would be undesirable to have two different communities using + "Content-Type: application/foobar" to mean two different things. The + process of defining new content-subtypes, then, is not intended to be + a mechanism for imposing restrictions, but simply a mechanism for + publicizing the usages. There are, therefore, two acceptable + mechanisms for defining new Content-Type subtypes: + + 1. Private values (starting with "X-") may be + defined bilaterally between two cooperating + agents without outside registration or + standardization. + + 2. New standard values must be documented, + registered with, and approved by IANA, as + described in Appendix E. Where intended for + public use, the formats they refer to must + also be defined by a published specification, + and possibly offered for standardization. + + The seven standard initial predefined Content-Types are detailed in + the bulk of this document. They are: + + text -- textual information. The primary subtype, + "plain", indicates plain (unformatted) text. No + special software is required to get the full + meaning of the text, aside from support for the + indicated character set. Subtypes are to be used + for enriched text in forms where application + software may enhance the appearance of the text, + but such software must not be required in order to + get the general idea of the content. Possible + subtypes thus include any readable word processor + + + +Borenstein & Freed [Page 11] + +RFC 1521 MIME September 1993 + + + format. A very simple and portable subtype, + richtext, was defined in RFC 1341, with a future + revision expected. + + multipart -- data consisting of multiple parts of + independent data types. Four initial subtypes + are defined, including the primary "mixed" + subtype, "alternative" for representing the same + data in multiple formats, "parallel" for parts + intended to be viewed simultaneously, and "digest" + for multipart entities in which each part is of + type "message". + + message -- an encapsulated message. A body of + Content-Type "message" is itself all or part of a + fully formatted RFC 822 conformant message which + may contain its own different Content-Type header + field. The primary subtype is "rfc822". The + "partial" subtype is defined for partial messages, + to permit the fragmented transmission of bodies + that are thought to be too large to be passed + through mail transport facilities. Another + subtype, "External-body", is defined for + specifying large bodies by reference to an + external data source. + + image -- image data. Image requires a display device + (such as a graphical display, a printer, or a FAX + machine) to view the information. Initial + subtypes are defined for two widely-used image + formats, jpeg and gif. + + audio -- audio data, with initial subtype "basic". + Audio requires an audio output device (such as a + speaker or a telephone) to "display" the contents. + + video -- video data. Video requires the capability to + display moving images, typically including + specialized hardware and software. The initial + subtype is "mpeg". + + application -- some other kind of data, typically + either uninterpreted binary data or information to + be processed by a mail-based application. The + primary subtype, "octet-stream", is to be used in + the case of uninterpreted binary data, in which + case the simplest recommended action is to offer + to write the information into a file for the user. + + + +Borenstein & Freed [Page 12] + +RFC 1521 MIME September 1993 + + + An additional subtype, "PostScript", is defined + for transporting PostScript documents in bodies. + Other expected uses for "application" include + spreadsheets, data for mail-based scheduling + systems, and languages for "active" + (computational) email. (Note that active email + and other application data may entail several + security considerations, which are discussed later + in this memo, particularly in the context of + application/PostScript.) + + Default RFC 822 messages are typed by this protocol as plain text in + the US-ASCII character set, which can be explicitly specified as + "Content-type: text/plain; charset=us-ascii". If no Content-Type is + specified, this default is assumed. In the presence of a MIME- + Version header field, a receiving User Agent can also assume that + plain US-ASCII text was the sender's intent. In the absence of a + MIME-Version specification, plain US-ASCII text must still be + assumed, but the sender's intent might have been otherwise. + + RATIONALE: In the absence of any Content-Type header field or + MIME-Version header field, it is impossible to be certain that a + message is actually text in the US-ASCII character set, since it + might well be a message that, using the conventions that predate + this document, includes text in another character set or non- + textual data in a manner that cannot be automatically recognized + (e.g., a uuencoded compressed UNIX tar file). Although there is + no fully acceptable alternative to treating such untyped messages + as "text/plain; charset=us-ascii", implementors should remain + aware that if a message lacks both the MIME-Version and the + Content-Type header fields, it may in practice contain almost + anything. + + It should be noted that the list of Content-Type values given here + may be augmented in time, via the mechanisms described above, and + that the set of subtypes is expected to grow substantially. + + When a mail reader encounters mail with an unknown Content-type + value, it should generally treat it as equivalent to + "application/octet-stream", as described later in this document. + +5. The Content-Transfer-Encoding Header Field + + Many Content-Types which could usefully be transported via email are + represented, in their "natural" format, as 8-bit character or binary + data. Such data cannot be transmitted over some transport protocols. + For example, RFC 821 restricts mail messages to 7-bit US-ASCII data + with lines no longer than 1000 characters. + + + +Borenstein & Freed [Page 13] + +RFC 1521 MIME September 1993 + + + It is necessary, therefore, to define a standard mechanism for re- + encoding such data into a 7-bit short-line format. This document + specifies that such encodings will be indicated by a new "Content- + Transfer-Encoding" header field. The Content-Transfer-Encoding field + is used to indicate the type of transformation that has been used in + order to represent the body in an acceptable manner for transport. + + Unlike Content-Types, a proliferation of Content-Transfer-Encoding + values is undesirable and unnecessary. However, establishing only a + single Content-Transfer-Encoding mechanism does not seem possible. + There is a tradeoff between the desire for a compact and efficient + encoding of largely-binary data and the desire for a readable + encoding of data that is mostly, but not entirely, 7-bit data. For + this reason, at least two encoding mechanisms are necessary: a + "readable" encoding and a "dense" encoding. + + The Content-Transfer-Encoding field is designed to specify an + invertible mapping between the "native" representation of a type of + data and a representation that can be readily exchanged using 7 bit + mail transport protocols, such as those defined by RFC 821 (SMTP). + This field has not been defined by any previous standard. The field's + value is a single token specifying the type of encoding, as + enumerated below. Formally: + + encoding := "Content-Transfer-Encoding" ":" mechanism + + mechanism := "7bit" ; case-insensitive + / "quoted-printable" + / "base64" + / "8bit" + / "binary" + / x-token + + These values are not case sensitive. That is, Base64 and BASE64 and + bAsE64 are all equivalent. An encoding type of 7BIT requires that + the body is already in a seven-bit mail-ready representation. This + is the default value -- that is, "Content-Transfer-Encoding: 7BIT" is + assumed if the Content-Transfer-Encoding header field is not present. + + The values "8bit", "7bit", and "binary" all mean that NO encoding has + been performed. However, they are potentially useful as indications + of the kind of data contained in the object, and therefore of the + kind of encoding that might need to be performed for transmission in + a given transport system. In particular: + + "7bit" means that the data is all represented as short + lines of US-ASCII data. + + + + +Borenstein & Freed [Page 14] + +RFC 1521 MIME September 1993 + + + "8bit" means that the lines are short, but there may be + non-ASCII characters (octets with the high-order + bit set). + + "Binary" means that not only may non-ASCII characters + be present, but also that the lines are not + necessarily short enough for SMTP transport. + + The difference between "8bit" (or any other conceivable bit-width + token) and the "binary" token is that "binary" does not require + adherence to any limits on line length or to the SMTP CRLF semantics, + while the bit-width tokens do require such adherence. If the body + contains data in any bit-width other than 7-bit, the appropriate + bit-width Content-Transfer-Encoding token must be used (e.g., "8bit" + for unencoded 8 bit wide data). If the body contains binary data, + the "binary" Content-Transfer-Encoding token must be used. + + NOTE: The distinction between the Content-Transfer-Encoding values + of "binary", "8bit", etc. may seem unimportant, in that all of + them really mean "none" -- that is, there has been no encoding of + the data for transport. However, clear labeling will be of + enormous value to gateways between future mail transport systems + with differing capabilities in transporting data that do not meet + the restrictions of RFC 821 transport. + + Mail transport for unencoded 8-bit data is defined in RFC-1426 + [RFC-1426]. As of the publication of this document, there are no + standardized Internet mail transports for which it is legitimate + to include unencoded binary data in mail bodies. Thus there are + no circumstances in which the "binary" Content-Transfer-Encoding + is actually legal on the Internet. However, in the event that + binary mail transport becomes a reality in Internet mail, or when + this document is used in conjunction with any other binary-capable + transport mechanism, binary bodies should be labeled as such using + this mechanism. + + NOTE: The five values defined for the Content-Transfer-Encoding + field imply nothing about the Content-Type other than the + algorithm by which it was encoded or the transport system + requirements if unencoded. + + Implementors may, if necessary, define new Content-Transfer-Encoding + values, but must use an x-token, which is a name prefixed by "X-" to + indicate its non-standard status, e.g., "Content-Transfer-Encoding: + x-my-new-encoding". However, unlike Content-Types and subtypes, the + creation of new Content-Transfer-Encoding values is explicitly and + strongly discouraged, as it seems likely to hinder interoperability + with little potential benefit. Their use is allowed only as the + + + +Borenstein & Freed [Page 15] + +RFC 1521 MIME September 1993 + + + result of an agreement between cooperating user agents. + + If a Content-Transfer-Encoding header field appears as part of a + message header, it applies to the entire body of that message. If a + Content-Transfer-Encoding header field appears as part of a body + part's headers, it applies only to the body of that body part. If an + entity is of type "multipart" or "message", the Content-Transfer- + Encoding is not permitted to have any value other than a bit width + (e.g., "7bit", "8bit", etc.) or "binary". + + It should be noted that email is character-oriented, so that the + mechanisms described here are mechanisms for encoding arbitrary octet + streams, not bit streams. If a bit stream is to be encoded via one + of these mechanisms, it must first be converted to an 8-bit byte + stream using the network standard bit order ("big-endian"), in which + the earlier bits in a stream become the higher-order bits in a byte. + A bit stream not ending at an 8-bit boundary must be padded with + zeroes. This document provides a mechanism for noting the addition + of such padding in the case of the application Content-Type, which + has a "padding" parameter. + + The encoding mechanisms defined here explicitly encode all data in + ASCII. Thus, for example, suppose an entity has header fields such + as: + + Content-Type: text/plain; charset=ISO-8859-1 + Content-transfer-encoding: base64 + + This must be interpreted to mean that the body is a base64 ASCII + encoding of data that was originally in ISO-8859-1, and will be in + that character set again after decoding. + + The following sections will define the two standard encoding + mechanisms. The definition of new content-transfer-encodings is + explicitly discouraged and should only occur when absolutely + necessary. All content-transfer-encoding namespace except that + beginning with "X-" is explicitly reserved to the IANA for future + use. Private agreements about content-transfer-encodings are also + explicitly discouraged. + + Certain Content-Transfer-Encoding values may only be used on certain + Content-Types. In particular, it is expressly forbidden to use any + encodings other than "7bit", "8bit", or "binary" with any Content- + Type that recursively includes other Content-Type fields, notably the + "multipart" and "message" Content-Types. All encodings that are + desired for bodies of type multipart or message must be done at the + innermost level, by encoding the actual body that needs to be + encoded. + + + +Borenstein & Freed [Page 16] + +RFC 1521 MIME September 1993 + + + NOTE ON ENCODING RESTRICTIONS: Though the prohibition against + using content-transfer-encodings on data of type multipart or + message may seem overly restrictive, it is necessary to prevent + nested encodings, in which data are passed through an encoding + algorithm multiple times, and must be decoded multiple times in + order to be properly viewed. Nested encodings add considerable + complexity to user agents: aside from the obvious efficiency + problems with such multiple encodings, they can obscure the basic + structure of a message. In particular, they can imply that + several decoding operations are necessary simply to find out what + types of objects a message contains. Banning nested encodings may + complicate the job of certain mail gateways, but this seems less + of a problem than the effect of nested encodings on user agents. + + NOTE ON THE RELATIONSHIP BETWEEN CONTENT-TYPE AND CONTENT- + TRANSFER-ENCODING: It may seem that the Content-Transfer-Encoding + could be inferred from the characteristics of the Content-Type + that is to be encoded, or, at the very least, that certain + Content-Transfer-Encodings could be mandated for use with specific + Content-Types. There are several reasons why this is not the case. + First, given the varying types of transports used for mail, some + encodings may be appropriate for some Content-Type/transport + combinations and not for others. (For example, in an 8-bit + transport, no encoding would be required for text in certain + character sets, while such encodings are clearly required for 7- + bit SMTP.) Second, certain Content-Types may require different + types of transfer encoding under different circumstances. For + example, many PostScript bodies might consist entirely of short + lines of 7-bit data and hence require little or no encoding. + Other PostScript bodies (especially those using Level 2 + PostScript's binary encoding mechanism) may only be reasonably + represented using a binary transport encoding. Finally, since + Content-Type is intended to be an open-ended specification + mechanism, strict specification of an association between + Content-Types and encodings effectively couples the specification + of an application protocol with a specific lower-level transport. + This is not desirable since the developers of a Content-Type + should not have to be aware of all the transports in use and what + their limitations are. + + NOTE ON TRANSLATING ENCODINGS: The quoted-printable and base64 + encodings are designed so that conversion between them is + possible. The only issue that arises in such a conversion is the + handling of line breaks. When converting from quoted-printable to + base64 a line break must be converted into a CRLF sequence. + Similarly, a CRLF sequence in base64 data must be converted to a + quoted-printable line break, but ONLY when converting text data. + + + + +Borenstein & Freed [Page 17] + +RFC 1521 MIME September 1993 + + + NOTE ON CANONICAL ENCODING MODEL: There was some confusion, in + earlier drafts of this memo, regarding the model for when email + data was to be converted to canonical form and encoded, and in + particular how this process would affect the treatment of CRLFs, + given that the representation of newlines varies greatly from + system to system, and the relationship between content-transfer- + encodings and character sets. For this reason, a canonical model + for encoding is presented as Appendix G. + +5.1. Quoted-Printable Content-Transfer-Encoding + + The Quoted-Printable encoding is intended to represent data that + largely consists of octets that correspond to printable characters in + the ASCII character set. It encodes the data in such a way that the + resulting octets are unlikely to be modified by mail transport. If + the data being encoded are mostly ASCII text, the encoded form of the + data remains largely recognizable by humans. A body which is + entirely ASCII may also be encoded in Quoted-Printable to ensure the + integrity of the data should the message pass through a character- + translating, and/or line-wrapping gateway. + + In this encoding, octets are to be represented as determined by the + following rules: + + Rule #1: (General 8-bit representation) Any octet, except those + indicating a line break according to the newline convention of the + canonical (standard) form of the data being encoded, may be + represented by an "=" followed by a two digit hexadecimal + representation of the octet's value. The digits of the + hexadecimal alphabet, for this purpose, are "0123456789ABCDEF". + Uppercase letters must be used when sending hexadecimal data, + though a robust implementation may choose to recognize lowercase + letters on receipt. Thus, for example, the value 12 (ASCII form + feed) can be represented by "=0C", and the value 61 (ASCII EQUAL + SIGN) can be represented by "=3D". Except when the following + rules allow an alternative encoding, this rule is mandatory. + + Rule #2: (Literal representation) Octets with decimal values of 33 + through 60 inclusive, and 62 through 126, inclusive, MAY be + represented as the ASCII characters which correspond to those + octets (EXCLAMATION POINT through LESS THAN, and GREATER THAN + through TILDE, respectively). + + Rule #3: (White Space): Octets with values of 9 and 32 MAY be + represented as ASCII TAB (HT) and SPACE characters, respectively, + but MUST NOT be so represented at the end of an encoded line. Any + TAB (HT) or SPACE characters on an encoded line MUST thus be + followed on that line by a printable character. In particular, an + + + +Borenstein & Freed [Page 18] + +RFC 1521 MIME September 1993 + + + "=" at the end of an encoded line, indicating a soft line break + (see rule #5) may follow one or more TAB (HT) or SPACE characters. + It follows that an octet with value 9 or 32 appearing at the end + of an encoded line must be represented according to Rule #1. This + rule is necessary because some MTAs (Message Transport Agents, + programs which transport messages from one user to another, or + perform a part of such transfers) are known to pad lines of text + with SPACEs, and others are known to remove "white space" + characters from the end of a line. Therefore, when decoding a + Quoted-Printable body, any trailing white space on a line must be + deleted, as it will necessarily have been added by intermediate + transport agents. + + Rule #4 (Line Breaks): A line break in a text body, independent of + what its representation is following the canonical representation + of the data being encoded, must be represented by a (RFC 822) line + break, which is a CRLF sequence, in the Quoted-Printable encoding. + Since the canonical representation of types other than text do not + generally include the representation of line breaks, no hard line + breaks (i.e. line breaks that are intended to be meaningful and + to be displayed to the user) should occur in the quoted-printable + encoding of such types. Of course, occurrences of "=0D", "=0A", + "0A=0D" and "=0D=0A" will eventually be encountered. In general, + however, base64 is preferred over quoted-printable for binary + data. + + Note that many implementations may elect to encode the local + representation of various content types directly, as described in + Appendix G. In particular, this may apply to plain text material + on systems that use newline conventions other than CRLF + delimiters. Such an implementation is permissible, but the + generation of line breaks must be generalized to account for the + case where alternate representations of newline sequences are + used. + + Rule #5 (Soft Line Breaks): The Quoted-Printable encoding REQUIRES + that encoded lines be no more than 76 characters long. If longer + lines are to be encoded with the Quoted-Printable encoding, 'soft' + line breaks must be used. An equal sign as the last character on a + encoded line indicates such a non-significant ('soft') line break + in the encoded text. Thus if the "raw" form of the line is a + single unencoded line that says: + + Now's the time for all folk to come to the aid of + their country. + + This can be represented, in the Quoted-Printable encoding, as + + + + +Borenstein & Freed [Page 19] + +RFC 1521 MIME September 1993 + + + Now's the time = + for all folk to come= + to the aid of their country. + + This provides a mechanism with which long lines are encoded in + such a way as to be restored by the user agent. The 76 character + limit does not count the trailing CRLF, but counts all other + characters, including any equal signs. + + Since the hyphen character ("-") is represented as itself in the + Quoted-Printable encoding, care must be taken, when encapsulating a + quoted-printable encoded body in a multipart entity, to ensure that + the encapsulation boundary does not appear anywhere in the encoded + body. (A good strategy is to choose a boundary that includes a + character sequence such as "=_" which can never appear in a quoted- + printable body. See the definition of multipart messages later in + this document.) + + NOTE: The quoted-printable encoding represents something of a + compromise between readability and reliability in transport. + Bodies encoded with the quoted-printable encoding will work + reliably over most mail gateways, but may not work perfectly over + a few gateways, notably those involving translation into EBCDIC. + (In theory, an EBCDIC gateway could decode a quoted-printable body + and re-encode it using base64, but such gateways do not yet + exist.) A higher level of confidence is offered by the base64 + Content-Transfer-Encoding. A way to get reasonably reliable + transport through EBCDIC gateways is to also quote the ASCII + characters + + !"#$@[\]^`{|}~ + + according to rule #1. See Appendix B for more information. + + Because quoted-printable data is generally assumed to be line- + oriented, it is to be expected that the representation of the breaks + between the lines of quoted printable data may be altered in + transport, in the same manner that plain text mail has always been + altered in Internet mail when passing between systems with differing + newline conventions. If such alterations are likely to constitute a + corruption of the data, it is probably more sensible to use the + base64 encoding rather than the quoted-printable encoding. + + WARNING TO IMPLEMENTORS: If binary data are encoded in quoted- + printable, care must be taken to encode CR and LF characters as "=0D" + and "=0A", respectively. In particular, a CRLF sequence in binary + data should be encoded as "=0D=0A". Otherwise, if CRLF were + represented as a hard line break, it might be incorrectly decoded on + + + +Borenstein & Freed [Page 20] + +RFC 1521 MIME September 1993 + + + platforms with different line break conventions. + + For formalists, the syntax of quoted-printable data is described by + the following grammar: + + quoted-printable := ([*(ptext / SPACE / TAB) ptext] ["="] CRLF) + ; Maximum line length of 76 characters excluding CRLF + + ptext := octet / 127, =, SPACE, or TAB, + ; and is recommended for any characters not listed in + ; Appendix B as "mail-safe". + +5.2. Base64 Content-Transfer-Encoding + + The Base64 Content-Transfer-Encoding is designed to represent + arbitrary sequences of octets in a form that need not be humanly + readable. The encoding and decoding algorithms are simple, but the + encoded data are consistently only about 33 percent larger than the + unencoded data. This encoding is virtually identical to the one used + in Privacy Enhanced Mail (PEM) applications, as defined in RFC 1421. + The base64 encoding is adapted from RFC 1421, with one change: base64 + eliminates the "*" mechanism for embedded clear text. + + A 65-character subset of US-ASCII is used, enabling 6 bits to be + represented per printable character. (The extra 65th character, "=", + is used to signify a special processing function.) + + NOTE: This subset has the important property that it is + represented identically in all versions of ISO 646, including US + ASCII, and all characters in the subset are also represented + identically in all versions of EBCDIC. Other popular encodings, + such as the encoding used by the uuencode utility and the base85 + encoding specified as part of Level 2 PostScript, do not share + these properties, and thus do not fulfill the portability + requirements a binary transport encoding for mail must meet. + + The encoding process represents 24-bit groups of input bits as output + strings of 4 encoded characters. Proceeding from left to right, a + 24-bit input group is formed by concatenating 3 8-bit input groups. + These 24 bits are then treated as 4 concatenated 6-bit groups, each + of which is translated into a single digit in the base64 alphabet. + When encoding a bit stream via the base64 encoding, the bit stream + must be presumed to be ordered with the most-significant-bit first. + + + +Borenstein & Freed [Page 21] + +RFC 1521 MIME September 1993 + + + That is, the first bit in the stream will be the high-order bit in + the first byte, and the eighth bit will be the low-order bit in the + first byte, and so on. + + Each 6-bit group is used as an index into an array of 64 printable + characters. The character referenced by the index is placed in the + output string. These characters, identified in Table 1, below, are + selected so as to be universally representable, and the set excludes + characters with particular significance to SMTP (e.g., ".", CR, LF) + and to the encapsulation boundaries defined in this document (e.g., + "-"). + + Table 1: The Base64 Alphabet + + Value Encoding Value Encoding Value Encoding Value Encoding + 0 A 17 R 34 i 51 z + 1 B 18 S 35 j 52 0 + 2 C 19 T 36 k 53 1 + 3 D 20 U 37 l 54 2 + 4 E 21 V 38 m 55 3 + 5 F 22 W 39 n 56 4 + 6 G 23 X 40 o 57 5 + 7 H 24 Y 41 p 58 6 + 8 I 25 Z 42 q 59 7 + 9 J 26 a 43 r 60 8 + 10 K 27 b 44 s 61 9 + 11 L 28 c 45 t 62 + + 12 M 29 d 46 u 63 / + 13 N 30 e 47 v + 14 O 31 f 48 w (pad) = + 15 P 32 g 49 x + 16 Q 33 h 50 y + + The output stream (encoded bytes) must be represented in lines of no + more than 76 characters each. All line breaks or other characters + not found in Table 1 must be ignored by decoding software. In base64 + data, characters other than those in Table 1, line breaks, and other + white space probably indicate a transmission error, about which a + warning message or even a message rejection might be appropriate + under some circumstances. + + Special processing is performed if fewer than 24 bits are available + at the end of the data being encoded. A full encoding quantum is + always completed at the end of a body. When fewer than 24 input bits + are available in an input group, zero bits are added (on the right) + to form an integral number of 6-bit groups. Padding at the end of + the data is performed using the '=' character. Since all base64 + input is an integral number of octets, only the following cases can + + + +Borenstein & Freed [Page 22] + +RFC 1521 MIME September 1993 + + + arise: (1) the final quantum of encoding input is an integral + multiple of 24 bits; here, the final unit of encoded output will be + an integral multiple of 4 characters with no "=" padding, (2) the + final quantum of encoding input is exactly 8 bits; here, the final + unit of encoded output will be two characters followed by two "=" + padding characters, or (3) the final quantum of encoding input is + exactly 16 bits; here, the final unit of encoded output will be three + characters followed by one "=" padding character. + + Because it is used only for padding at the end of the data, the + occurrence of any '=' characters may be taken as evidence that the + end of the data has been reached (without truncation in transit). No + such assurance is possible, however, when the number of octets + transmitted was a multiple of three. + + Any characters outside of the base64 alphabet are to be ignored in + base64-encoded data. The same applies to any illegal sequence of + characters in the base64 encoding, such as "=====" + + Care must be taken to use the proper octets for line breaks if base64 + encoding is applied directly to text material that has not been + converted to canonical form. In particular, text line breaks must be + converted into CRLF sequences prior to base64 encoding. The important + thing to note is that this may be done directly by the encoder rather + than in a prior canonicalization step in some implementations. + + NOTE: There is no need to worry about quoting apparent + encapsulation boundaries within base64-encoded parts of multipart + entities because no hyphen characters are used in the base64 + encoding. + +6. Additional Content-Header Fields + +6.1. Optional Content-ID Header Field + + In constructing a high-level user agent, it may be desirable to allow + one body to make reference to another. Accordingly, bodies may be + labeled using the "Content-ID" header field, which is syntactically + identical to the "Message-ID" header field: + + id := "Content-ID" ":" msg-id + Like the Message-ID values, Content-ID values must be generated to be + world-unique. + + The Content-ID value may be used for uniquely identifying MIME + entities in several contexts, particularly for cacheing data + referenced by the message/external-body mechanism. Although the + Content-ID header is generally optional, its use is mandatory in + + + +Borenstein & Freed [Page 23] + +RFC 1521 MIME September 1993 + + + implementations which generate data of the optional MIME Content-type + "message/external-body". That is, each message/external-body entity + must have a Content-ID field to permit cacheing of such data. + + It is also worth noting that the Content-ID value has special + semantics in the case of the multipart/alternative content-type. + This is explained in the section of this document dealing with + multipart/alternative. + +6.2. Optional Content-Description Header Field + + The ability to associate some descriptive information with a given + body is often desirable. For example, it may be useful to mark an + "image" body as "a picture of the Space Shuttle Endeavor." Such text + may be placed in the Content-Description header field. + + description := "Content-Description" ":" *text + + The description is presumed to be given in the US-ASCII character + set, although the mechanism specified in [RFC-1522] may be used for + non-US-ASCII Content-Description values. + +7. The Predefined Content-Type Values + + This document defines seven initial Content-Type values and an + extension mechanism for private or experimental types. Further + standard types must be defined by new published specifications. It + is expected that most innovation in new types of mail will take place + as subtypes of the seven types defined here. The most essential + characteristics of the seven content-types are summarized in Appendix + F. + +7.1 The Text Content-Type + + The text Content-Type is intended for sending material which is + principally textual in form. It is the default Content-Type. A + "charset" parameter may be used to indicate the character set of the + body text for some text subtypes, notably including the primary + subtype, "text/plain", which indicates plain (unformatted) text. The + default Content-Type for Internet mail is "text/plain; charset=us- + ascii". + + Beyond plain text, there are many formats for representing what might + be known as "extended text" -- text with embedded formatting and + presentation information. An interesting characteristic of many such + representations is that they are to some extent readable even without + the software that interprets them. It is useful, then, to + distinguish them, at the highest level, from such unreadable data as + + + +Borenstein & Freed [Page 24] + +RFC 1521 MIME September 1993 + + + images, audio, or text represented in an unreadable form. In the + absence of appropriate interpretation software, it is reasonable to + show subtypes of text to the user, while it is not reasonable to do + so with most nontextual data. + + Such formatted textual data should be represented using subtypes of + text. Plausible subtypes of text are typically given by the common + name of the representation format, e.g., "text/richtext" [RFC-1341]. + +7.1.1. The charset parameter + + A critical parameter that may be specified in the Content-Type field + for text/plain data is the character set. This is specified with a + "charset" parameter, as in: + + Content-type: text/plain; charset=us-ascii + + Unlike some other parameter values, the values of the charset + parameter are NOT case sensitive. The default character set, which + must be assumed in the absence of a charset parameter, is US-ASCII. + + The specification for any future subtypes of "text" must specify + whether or not they will also utilize a "charset" parameter, and may + possibly restrict its values as well. When used with a particular + body, the semantics of the "charset" parameter should be identical to + those specified here for "text/plain", i.e., the body consists + entirely of characters in the given charset. In particular, definers + of future text subtypes should pay close attention the the + implications of multibyte character sets for their subtype + definitions. + + This RFC specifies the definition of the charset parameter for the + purposes of MIME to be a unique mapping of a byte stream to glyphs, a + mapping which does not require external profiling information. + + An initial list of predefined character set names can be found at the + end of this section. Additional character sets may be registered + with IANA, although the standardization of their use requires the + usual IESG [RFC-1340] review and approval. Note that if the + specified character set includes 8-bit data, a Content-Transfer- + Encoding header field and a corresponding encoding on the data are + required in order to transmit the body via some mail transfer + protocols, such as SMTP. + + The default character set, US-ASCII, has been the subject of some + confusion and ambiguity in the past. Not only were there some + ambiguities in the definition, there have been wide variations in + practice. In order to eliminate such ambiguity and variations in the + + + +Borenstein & Freed [Page 25] + +RFC 1521 MIME September 1993 + + + future, it is strongly recommended that new user agents explicitly + specify a character set via the Content-Type header field. "US- + ASCII" does not indicate an arbitrary seven-bit character code, but + specifies that the body uses character coding that uses the exact + correspondence of codes to characters specified in ASCII. National + use variations of ISO 646 [ISO-646] are NOT ASCII and their use in + Internet mail is explicitly discouraged. The omission of the ISO 646 + character set is deliberate in this regard. The character set name + of "US-ASCII" explicitly refers to ANSI X3.4-1986 [US-ASCII] only. + The character set name "ASCII" is reserved and must not be used for + any purpose. + + NOTE: RFC 821 explicitly specifies "ASCII", and references an + earlier version of the American Standard. Insofar as one of the + purposes of specifying a Content-Type and character set is to + permit the receiver to unambiguously determine how the sender + intended the coded message to be interpreted, assuming anything + other than "strict ASCII" as the default would risk unintentional + and incompatible changes to the semantics of messages now being + transmitted. This also implies that messages containing + characters coded according to national variations on ISO 646, or + using code-switching procedures (e.g., those of ISO 2022), as well + as 8-bit or multiple octet character encodings MUST use an + appropriate character set specification to be consistent with this + specification. + + The complete US-ASCII character set is listed in [US-ASCII]. Note + that the control characters including DEL (0-31, 127) have no defined + meaning apart from the combination CRLF (ASCII values 13 and 10) + indicating a new line. Two of the characters have de facto meanings + in wide use: FF (12) often means "start subsequent text on the + beginning of a new page"; and TAB or HT (9) often (though not always) + means "move the cursor to the next available column after the current + position where the column number is a multiple of 8 (counting the + first column as column 0)." Apart from this, any use of the control + characters or DEL in a body must be part of a private agreement + between the sender and recipient. Such private agreements are + discouraged and should be replaced by the other capabilities of this + document. + + NOTE: Beyond US-ASCII, an enormous proliferation of character sets + is possible. It is the opinion of the IETF working group that a + large number of character sets is NOT a good thing. We would + prefer to specify a single character set that can be used + universally for representing all of the world's languages in + electronic mail. Unfortunately, existing practice in several + communities seems to point to the continued use of multiple + character sets in the near future. For this reason, we define + + + +Borenstein & Freed [Page 26] + +RFC 1521 MIME September 1993 + + + names for a small number of character sets for which a strong + constituent base exists. + + The defined charset values are: + + US-ASCII -- as defined in [US-ASCII]. + + ISO-8859-X -- where "X" is to be replaced, as necessary, for the + parts of ISO-8859 [ISO-8859]. Note that the ISO 646 + character sets have deliberately been omitted in favor of + their 8859 replacements, which are the designated character + sets for Internet mail. As of the publication of this + document, the legitimate values for "X" are the digits 1 + through 9. + + The character sets specified above are the ones that were relatively + uncontroversial during the drafting of MIME. This document does not + endorse the use of any particular character set other than US-ASCII, + and recognizes that the future evolution of world character sets + remains unclear. It is expected that in the future, additional + character sets will be registered for use in MIME. + + Note that the character set used, if anything other than US-ASCII, + must always be explicitly specified in the Content-Type field. + + No other character set name may be used in Internet mail without the + publication of a formal specification and its registration with IANA, + or by private agreement, in which case the character set name must + begin with "X-". + + Implementors are discouraged from defining new character sets for + mail use unless absolutely necessary. + + The "charset" parameter has been defined primarily for the purpose of + textual data, and is described in this section for that reason. + However, it is conceivable that non-textual data might also wish to + specify a charset value for some purpose, in which case the same + syntax and values should be used. + + In general, mail-sending software must always use the "lowest common + denominator" character set possible. For example, if a body contains + only US-ASCII characters, it must be marked as being in the US-ASCII + character set, not ISO-8859-1, which, like all the ISO-8859 family of + character sets, is a superset of US-ASCII. More generally, if a + widely-used character set is a subset of another character set, and a + body contains only characters in the widely-used subset, it must be + labeled as being in that subset. This will increase the chances that + the recipient will be able to view the mail correctly. + + + +Borenstein & Freed [Page 27] + +RFC 1521 MIME September 1993 + + +7.1.2. The Text/plain subtype + + The primary subtype of text is "plain". This indicates plain + (unformatted) text. The default Content-Type for Internet mail, + "text/plain; charset=us-ascii", describes existing Internet practice. + That is, it is the type of body defined by RFC 822. + + No other text subtype is defined by this document. + + The formal grammar for the content-type header field for text is as + follows: + + text-type := "text" "/" text-subtype [";" "charset" "=" charset] + + text-subtype := "plain" / extension-token + + charset := "us-ascii"/ "iso-8859-1"/ "iso-8859-2"/ "iso-8859-3" + / "iso-8859-4"/ "iso-8859-5"/ "iso-8859-6"/ "iso-8859-7" + / "iso-8859-8" / "iso-8859-9" / extension-token + ; case insensitive + +7.2. The Multipart Content-Type + + In the case of multiple part entities, in which one or more different + sets of data are combined in a single body, a "multipart" Content- + Type field must appear in the entity's header. The body must then + contain one or more "body parts," each preceded by an encapsulation + boundary, and the last one followed by a closing boundary. Each part + starts with an encapsulation boundary, and then contains a body part + consisting of header area, a blank line, and a body area. Thus a + body part is similar to an RFC 822 message in syntax, but different + in meaning. + + A body part is NOT to be interpreted as actually being an RFC 822 + message. To begin with, NO header fields are actually required in + body parts. A body part that starts with a blank line, therefore, is + allowed and is a body part for which all default values are to be + assumed. In such a case, the absence of a Content-Type header field + implies that the corresponding body is plain US-ASCII text. The only + header fields that have defined meaning for body parts are those the + names of which begin with "Content-". All other header fields are + generally to be ignored in body parts. Although they should + generally be retained in mail processing, they may be discarded by + gateways if necessary. Such other fields are permitted to appear in + body parts but must not be depended on. "X-" fields may be created + for experimental or private purposes, with the recognition that the + information they contain may be lost at some gateways. + + + + +Borenstein & Freed [Page 28] + +RFC 1521 MIME September 1993 + + + NOTE: The distinction between an RFC 822 message and a body part + is subtle, but important. A gateway between Internet and X.400 + mail, for example, must be able to tell the difference between a + body part that contains an image and a body part that contains an + encapsulated message, the body of which is an image. In order to + represent the latter, the body part must have "Content-Type: + message", and its body (after the blank line) must be the + encapsulated message, with its own "Content-Type: image" header + field. The use of similar syntax facilitates the conversion of + messages to body parts, and vice versa, but the distinction + between the two must be understood by implementors. (For the + special case in which all parts actually are messages, a "digest" + subtype is also defined.) + + As stated previously, each body part is preceded by an encapsulation + boundary. The encapsulation boundary MUST NOT appear inside any of + the encapsulated parts. Thus, it is crucial that the composing agent + be able to choose and specify the unique boundary that will separate + the parts. + + All present and future subtypes of the "multipart" type must use an + identical syntax. Subtypes may differ in their semantics, and may + impose additional restrictions on syntax, but must conform to the + required syntax for the multipart type. This requirement ensures + that all conformant user agents will at least be able to recognize + and separate the parts of any multipart entity, even of an + unrecognized subtype. + + As stated in the definition of the Content-Transfer-Encoding field, + no encoding other than "7bit", "8bit", or "binary" is permitted for + entities of type "multipart". The multipart delimiters and header + fields are always represented as 7-bit ASCII in any case (though the + header fields may encode non-ASCII header text as per [RFC-1522]), + and data within the body parts can be encoded on a part-by-part + basis, with Content-Transfer-Encoding fields for each appropriate + body part. + + Mail gateways, relays, and other mail handling agents are commonly + known to alter the top-level header of an RFC 822 message. In + particular, they frequently add, remove, or reorder header fields. + Such alterations are explicitly forbidden for the body part headers + embedded in the bodies of messages of type "multipart." + +7.2.1. Multipart: The common syntax + + All subtypes of "multipart" share a common syntax, defined in this + section. A simple example of a multipart message also appears in + this section. An example of a more complex multipart message is + + + +Borenstein & Freed [Page 29] + +RFC 1521 MIME September 1993 + + + given in Appendix C. + + The Content-Type field for multipart entities requires one parameter, + "boundary", which is used to specify the encapsulation boundary. The + encapsulation boundary is defined as a line consisting entirely of + two hyphen characters ("-", decimal code 45) followed by the boundary + parameter value from the Content-Type header field. + + NOTE: The hyphens are for rough compatibility with the earlier RFC + 934 method of message encapsulation, and for ease of searching for + the boundaries in some implementations. However, it should be + noted that multipart messages are NOT completely compatible with + RFC 934 encapsulations; in particular, they do not obey RFC 934 + quoting conventions for embedded lines that begin with hyphens. + This mechanism was chosen over the RFC 934 mechanism because the + latter causes lines to grow with each level of quoting. The + combination of this growth with the fact that SMTP implementations + sometimes wrap long lines made the RFC 934 mechanism unsuitable + for use in the event that deeply-nested multipart structuring is + ever desired. + + WARNING TO IMPLEMENTORS: The grammar for parameters on the Content- + type field is such that it is often necessary to enclose the + boundaries in quotes on the Content-type line. This is not always + necessary, but never hurts. Implementors should be sure to study the + grammar carefully in order to avoid producing illegal Content-type + fields. Thus, a typical multipart Content-Type header field might + look like this: + + Content-Type: multipart/mixed; + boundary=gc0p4Jq0M2Yt08jU534c0p + + But the following is illegal: + + Content-Type: multipart/mixed; + boundary=gc0p4Jq0M:2Yt08jU534c0p + + (because of the colon) and must instead be represented as + + Content-Type: multipart/mixed; + boundary="gc0p4Jq0M:2Yt08jU534c0p" + + This indicates that the entity consists of several parts, each itself + with a structure that is syntactically identical to an RFC 822 + message, except that the header area might be completely empty, and + that the parts are each preceded by the line + + --gc0p4Jq0M:2Yt08jU534c0p + + + +Borenstein & Freed [Page 30] + +RFC 1521 MIME September 1993 + + + Note that the encapsulation boundary must occur at the beginning of a + line, i.e., following a CRLF, and that the initial CRLF is considered + to be attached to the encapsulation boundary rather than part of the + preceding part. The boundary must be followed immediately either by + another CRLF and the header fields for the next part, or by two + CRLFs, in which case there are no header fields for the next part + (and it is therefore assumed to be of Content-Type text/plain). + + NOTE: The CRLF preceding the encapsulation line is conceptually + attached to the boundary so that it is possible to have a part + that does not end with a CRLF (line break). Body parts that must + be considered to end with line breaks, therefore, must have two + CRLFs preceding the encapsulation line, the first of which is part + of the preceding body part, and the second of which is part of the + encapsulation boundary. + + Encapsulation boundaries must not appear within the encapsulations, + and must be no longer than 70 characters, not counting the two + leading hyphens. + + The encapsulation boundary following the last body part is a + distinguished delimiter that indicates that no further body parts + will follow. Such a delimiter is identical to the previous + delimiters, with the addition of two more hyphens at the end of the + line: + + --gc0p4Jq0M2Yt08jU534c0p-- + + There appears to be room for additional information prior to the + first encapsulation boundary and following the final boundary. These + areas should generally be left blank, and implementations must ignore + anything that appears before the first boundary or after the last + one. + + NOTE: These "preamble" and "epilogue" areas are generally not used + because of the lack of proper typing of these parts and the lack + of clear semantics for handling these areas at gateways, + particularly X.400 gateways. However, rather than leaving the + preamble area blank, many MIME implementations have found this to + be a convenient place to insert an explanatory note for recipients + who read the message with pre-MIME software, since such notes will + be ignored by MIME-compliant software. + + NOTE: Because encapsulation boundaries must not appear in the body + parts being encapsulated, a user agent must exercise care to + choose a unique boundary. The boundary in the example above could + have been the result of an algorithm designed to produce + boundaries with a very low probability of already existing in the + + + +Borenstein & Freed [Page 31] + +RFC 1521 MIME September 1993 + + + data to be encapsulated without having to prescan the data. + Alternate algorithms might result in more 'readable' boundaries + for a recipient with an old user agent, but would require more + attention to the possibility that the boundary might appear in the + encapsulated part. The simplest boundary possible is something + like "---", with a closing boundary of "-----". + + As a very simple example, the following multipart message has two + parts, both of them plain text, one of them explicitly typed and one + of them implicitly typed: + + From: Nathaniel Borenstein + To: Ned Freed + Subject: Sample message + MIME-Version: 1.0 + Content-type: multipart/mixed; boundary="simple + boundary" + + This is the preamble. It is to be ignored, though it + is a handy place for mail composers to include an + explanatory note to non-MIME conformant readers. + --simple boundary + + This is implicitly typed plain ASCII text. + It does NOT end with a linebreak. + --simple boundary + Content-type: text/plain; charset=us-ascii + + This is explicitly typed plain ASCII text. + It DOES end with a linebreak. + + --simple boundary-- + This is the epilogue. It is also to be ignored. + + The use of a Content-Type of multipart in a body part within another + multipart entity is explicitly allowed. In such cases, for obvious + reasons, care must be taken to ensure that each nested multipart + entity must use a different boundary delimiter. See Appendix C for an + example of nested multipart entities. + + The use of the multipart Content-Type with only a single body part + may be useful in certain contexts, and is explicitly permitted. + + The only mandatory parameter for the multipart Content-Type is the + boundary parameter, which consists of 1 to 70 characters from a set + of characters known to be very robust through email gateways, and NOT + ending with white space. (If a boundary appears to end with white + space, the white space must be presumed to have been added by a + + + +Borenstein & Freed [Page 32] + +RFC 1521 MIME September 1993 + + + gateway, and must be deleted.) It is formally specified by the + following BNF: + + boundary := 0*69 bcharsnospace + + bchars := bcharsnospace / " " + + bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" / "+" /"_" + / "," / "-" / "." / "/" / ":" / "=" / "?" + + Overall, the body of a multipart entity may be specified as + follows: + + multipart-body := preamble 1*encapsulation + close-delimiter epilogue + + encapsulation := delimiter body-part CRLF + + delimiter := "--" boundary CRLF ; taken from Content-Type field. + ; There must be no space + ; between "--" and boundary. + + close-delimiter := "--" boundary "--" CRLF ; Again, no space + by "--", + + preamble := discard-text ; to be ignored upon receipt. + + epilogue := discard-text ; to be ignored upon receipt. + + discard-text := *(*text CRLF) + + body-part := <"message" as defined in RFC 822, + with all header fields optional, and with the + specified delimiter not occurring anywhere in + the message body, either on a line by itself + or as a substring anywhere. Note that the + semantics of a part differ from the semantics + of a message, as described in the text.> + + NOTE: In certain transport enclaves, RFC 822 restrictions such as + the one that limits bodies to printable ASCII characters may not + be in force. (That is, the transport domains may resemble + standard Internet mail transport as specified in RFC821 and + assumed by RFC822, but without certain restrictions.) The + relaxation of these restrictions should be construed as locally + extending the definition of bodies, for example to include octets + outside of the ASCII range, as long as these extensions are + supported by the transport and adequately documented in the + + + +Borenstein & Freed [Page 33] + +RFC 1521 MIME September 1993 + + + Content-Transfer-Encoding header field. However, in no event are + headers (either message headers or body-part headers) allowed to + contain anything other than ASCII characters. + + NOTE: Conspicuously missing from the multipart type is a notion of + structured, related body parts. In general, it seems premature to + try to standardize interpart structure yet. It is recommended + that those wishing to provide a more structured or integrated + multipart messaging facility should define a subtype of multipart + that is syntactically identical, but that always expects the + inclusion of a distinguished part that can be used to specify the + structure and integration of the other parts, probably referring + to them by their Content-ID field. If this approach is used, + other implementations will not recognize the new subtype, but will + treat it as the primary subtype (multipart/mixed) and will thus be + able to show the user the parts that are recognized. + +7.2.2. The Multipart/mixed (primary) subtype + + The primary subtype for multipart, "mixed", is intended for use when + the body parts are independent and need to be bundled in a particular + order. Any multipart subtypes that an implementation does not + recognize must be treated as being of subtype "mixed". + +7.2.3. The Multipart/alternative subtype + + The multipart/alternative type is syntactically identical to + multipart/mixed, but the semantics are different. In particular, + each of the parts is an "alternative" version of the same + information. + + Systems should recognize that the content of the various parts are + interchangeable. Systems should choose the "best" type based on the + local environment and preferences, in some cases even through user + interaction. As with multipart/mixed, the order of body parts is + significant. In this case, the alternatives appear in an order of + increasing faithfulness to the original content. In general, the best + choice is the LAST part of a type supported by the recipient system's + local environment. + + Multipart/alternative may be used, for example, to send mail in a + fancy text format in such a way that it can easily be displayed + anywhere: + + + + + + + + +Borenstein & Freed [Page 34] + +RFC 1521 MIME September 1993 + + + From: Nathaniel Borenstein + To: Ned Freed + Subject: Formatted text mail + MIME-Version: 1.0 + Content-Type: multipart/alternative; boundary=boundary42 + + --boundary42 + + Content-Type: text/plain; charset=us-ascii + + ...plain text version of message goes here.... + --boundary42 + Content-Type: text/richtext + + .... RFC 1341 richtext version of same message goes here ... + --boundary42 + Content-Type: text/x-whatever + + .... fanciest formatted version of same message goes here + ... + --boundary42-- + + In this example, users whose mail system understood the "text/x- + whatever" format would see only the fancy version, while other users + would see only the richtext or plain text version, depending on the + capabilities of their system. + + In general, user agents that compose multipart/alternative entities + must place the body parts in increasing order of preference, that is, + with the preferred format last. For fancy text, the sending user + agent should put the plainest format first and the richest format + last. Receiving user agents should pick and display the last format + they are capable of displaying. In the case where one of the + alternatives is itself of type "multipart" and contains unrecognized + sub-parts, the user agent may choose either to show that alternative, + an earlier alternative, or both. + + NOTE: From an implementor's perspective, it might seem more + sensible to reverse this ordering, and have the plainest + alternative last. However, placing the plainest alternative first + is the friendliest possible option when multipart/alternative + entities are viewed using a non-MIME-conformant mail reader. + While this approach does impose some burden on conformant mail + readers, interoperability with older mail readers was deemed to be + more important in this case. + + It may be the case that some user agents, if they can recognize more + than one of the formats, will prefer to offer the user the choice of + + + +Borenstein & Freed [Page 35] + +RFC 1521 MIME September 1993 + + + which format to view. This makes sense, for example, if mail + includes both a nicely-formatted image version and an easily-edited + text version. What is most critical, however, is that the user not + automatically be shown multiple versions of the same data. Either + the user should be shown the last recognized version or should be + given the choice. + + NOTE ON THE SEMANTICS OF CONTENT-ID IN MULTIPART/ALTERNATIVE: Each + part of a multipart/alternative entity represents the same data, but + the mappings between the two are not necessarily without information + loss. For example, information is lost when translating ODA to + PostScript or plain text. It is recommended that each part should + have a different Content-ID value in the case where the information + content of the two parts is not identical. However, where the + information content is identical -- for example, where several parts + of type "application/external- body" specify alternate ways to access + the identical data -- the same Content-ID field value should be used, + to optimize any cacheing mechanisms that might be present on the + recipient's end. However, it is recommended that the Content-ID + values used by the parts should not be the same Content-ID value that + describes the multipart/alternative as a whole, if there is any such + Content-ID field. That is, one Content-ID value will refer to the + multipart/alternative entity, while one or more other Content-ID + values will refer to the parts inside it. + +7.2.4. The Multipart/digest subtype + + This document defines a "digest" subtype of the multipart Content- + Type. This type is syntactically identical to multipart/mixed, but + the semantics are different. In particular, in a digest, the default + Content-Type value for a body part is changed from "text/plain" to + "message/rfc822". This is done to allow a more readable digest + format that is largely compatible (except for the quoting convention) + with RFC 934. + + + + + + + + + + + + + + + + + +Borenstein & Freed [Page 36] + +RFC 1521 MIME September 1993 + + + A digest in this format might, then, look something like this: + + From: Moderator-Address + To: Recipient-List + MIME-Version: 1.0 + Subject: Internet Digest, volume 42 + Content-Type: multipart/digest; + boundary="---- next message ----" + + ------ next message ---- + + From: someone-else + Subject: my opinion + + ...body goes here ... + + ------ next message ---- + + From: someone-else-again + Subject: my different opinion + + ... another body goes here... + + ------ next message ------ + +7.2.5. The Multipart/parallel subtype + + This document defines a "parallel" subtype of the multipart Content- + Type. This type is syntactically identical to multipart/mixed, but + the semantics are different. In particular, in a parallel entity, + the order of body parts is not significant. + + A common presentation of this type is to display all of the parts + simultaneously on hardware and software that are capable of doing so. + However, composing agents should be aware that many mail readers will + lack this capability and will show the parts serially in any event. + +7.2.6. Other Multipart subtypes + + Other multipart subtypes are expected in the future. MIME + implementations must in general treat unrecognized subtypes of + multipart as being equivalent to "multipart/mixed". + + The formal grammar for content-type header fields for multipart data + is given by: + + multipart-type := "multipart" "/" multipart-subtype + ";" "boundary" "=" boundary + + + +Borenstein & Freed [Page 37] + +RFC 1521 MIME September 1993 + + + multipart-subtype := "mixed" / "parallel" / "digest" + / "alternative" / extension-token + +7.3. The Message Content-Type + + It is frequently desirable, in sending mail, to encapsulate another + mail message. For this common operation, a special Content-Type, + "message", is defined. The primary subtype, message/rfc822, has no + required parameters in the Content-Type field. Additional subtypes, + "partial" and "External-body", do have required parameters. These + subtypes are explained below. + + NOTE: It has been suggested that subtypes of message might be + defined for forwarded or rejected messages. However, forwarded + and rejected messages can be handled as multipart messages in + which the first part contains any control or descriptive + information, and a second part, of type message/rfc822, is the + forwarded or rejected message. Composing rejection and forwarding + messages in this manner will preserve the type information on the + original message and allow it to be correctly presented to the + recipient, and hence is strongly encouraged. + + As stated in the definition of the Content-Transfer-Encoding field, + no encoding other than "7bit", "8bit", or "binary" is permitted for + messages or parts of type "message". Even stronger restrictions + apply to the subtypes "message/partial" and "message/external-body", + as specified below. The message header fields are always US-ASCII in + any case, and data within the body can still be encoded, in which + case the Content-Transfer-Encoding header field in the encapsulated + message will reflect this. Non-ASCII text in the headers of an + encapsulated message can be specified using the mechanisms described + in [RFC-1522]. + + Mail gateways, relays, and other mail handling agents are commonly + known to alter the top-level header of an RFC 822 message. In + particular, they frequently add, remove, or reorder header fields. + Such alterations are explicitly forbidden for the encapsulated + headers embedded in the bodies of messages of type "message." + +7.3.1. The Message/rfc822 (primary) subtype + + A Content-Type of "message/rfc822" indicates that the body contains + an encapsulated message, with the syntax of an RFC 822 message. + However, unlike top-level RFC 822 messages, it is not required that + each message/rfc822 body must include a "From", "Subject", and at + least one destination header. + + It should be noted that, despite the use of the numbers "822", a + + + +Borenstein & Freed [Page 38] + +RFC 1521 MIME September 1993 + + + message/rfc822 entity can include enhanced information as defined in + this document. In other words, a message/rfc822 message may be a + MIME message. + +7.3.2. The Message/Partial subtype + + A subtype of message, "partial", is defined in order to allow large + objects to be delivered as several separate pieces of mail and + automatically reassembled by the receiving user agent. (The concept + is similar to IP fragmentation/reassembly in the basic Internet + Protocols.) This mechanism can be used when intermediate transport + agents limit the size of individual messages that can be sent. + Content-Type "message/partial" thus indicates that the body contains + a fragment of a larger message. + + Three parameters must be specified in the Content-Type field of type + message/partial: The first, "id", is a unique identifier, as close to + a world-unique identifier as possible, to be used to match the parts + together. (In general, the identifier is essentially a message-id; + if placed in double quotes, it can be any message-id, in accordance + with the BNF for "parameter" given earlier in this specification.) + The second, "number", an integer, is the part number, which indicates + where this part fits into the sequence of fragments. The third, + "total", another integer, is the total number of parts. This third + subfield is required on the final part, and is optional (though + encouraged) on the earlier parts. Note also that these parameters + may be given in any order. + + Thus, part 2 of a 3-part message may have either of the following + header fields: + + Content-Type: Message/Partial; + number=2; total=3; + id="oc=jpbe0M2Yt4s@thumper.bellcore.com" + + Content-Type: Message/Partial; + id="oc=jpbe0M2Yt4s@thumper.bellcore.com"; + number=2 + + But part 3 MUST specify the total number of parts: + + Content-Type: Message/Partial; + number=3; total=3; + id="oc=jpbe0M2Yt4s@thumper.bellcore.com" + + Note that part numbering begins with 1, not 0. + + When the parts of a message broken up in this manner are put + + + +Borenstein & Freed [Page 39] + +RFC 1521 MIME September 1993 + + + together, the result is a complete MIME entity, which may have its + own Content-Type header field, and thus may contain any other data + type. + + Message fragmentation and reassembly: The semantics of a reassembled + partial message must be those of the "inner" message, rather than of + a message containing the inner message. This makes it possible, for + example, to send a large audio message as several partial messages, + and still have it appear to the recipient as a simple audio message + rather than as an encapsulated message containing an audio message. + That is, the encapsulation of the message is considered to be + "transparent". + + When generating and reassembling the parts of a message/partial + message, the headers of the encapsulated message must be merged with + the headers of the enclosing entities. In this process the following + rules must be observed: + + (1) All of the header fields from the initial enclosing entity + (part one), except those that start with "Content-" and the + specific header fields "Message-ID", "Encrypted", and "MIME- + Version", must be copied, in order, to the new message. + + (2) Only those header fields in the enclosed message which start + with "Content-" and "Message-ID", "Encrypted", and "MIME-Version" + must be appended, in order, to the header fields of the new + message. Any header fields in the enclosed message which do not + start with "Content-" (except for "Message-ID", "Encrypted", and + "MIME-Version") will be ignored. + + (3) All of the header fields from the second and any subsequent + messages will be ignored. + + For example, if an audio message is broken into two parts, the first + part might look something like this: + + X-Weird-Header-1: Foo + From: Bill@host.com + To: joe@otherhost.com + Subject: Audio mail + Message-ID: + MIME-Version: 1.0 + Content-type: message/partial; + id="ABC@host.com"; + number=1; total=2 + + X-Weird-Header-1: Bar + X-Weird-Header-2: Hello + + + +Borenstein & Freed [Page 40] + +RFC 1521 MIME September 1993 + + + Message-ID: + MIME-Version: 1.0 + Content-type: audio/basic + Content-transfer-encoding: base64 + + ... first half of encoded audio data goes here... + + and the second half might look something like this: + + From: Bill@host.com + To: joe@otherhost.com + Subject: Audio mail + MIME-Version: 1.0 + Message-ID: + Content-type: message/partial; + id="ABC@host.com"; number=2; total=2 + + ... second half of encoded audio data goes here... + + Then, when the fragmented message is reassembled, the resulting + message to be displayed to the user should look something like this: + + X-Weird-Header-1: Foo + From: Bill@host.com + To: joe@otherhost.com + Subject: Audio mail + Message-ID: + MIME-Version: 1.0 + Content-type: audio/basic + Content-transfer-encoding: base64 + + ... first half of encoded audio data goes here... + ... second half of encoded audio data goes here... + + Note on encoding of MIME entities encapsulated inside message/partial + entities: Because data of type "message" may never be encoded in + base64 or quoted-printable, a problem might arise if message/partial + entities are constructed in an environment that supports binary or + 8-bit transport. The problem is that the binary data would be split + into multiple message/partial objects, each of them requiring binary + transport. If such objects were encountered at a gateway into a 7- + bit transport environment, there would be no way to properly encode + them for the 7-bit world, aside from waiting for all of the parts, + reassembling the message, and then encoding the reassembled data in + base64 or quoted-printable. Since it is possible that different + parts might go through different gateways, even this is not an + acceptable solution. For this reason, it is specified that MIME + entities of type message/partial must always have a content- + + + +Borenstein & Freed [Page 41] + +RFC 1521 MIME September 1993 + + + transfer-encoding of 7-bit (the default). In particular, even in + environments that support binary or 8-bit transport, the use of a + content-transfer-encoding of "8bit" or "binary" is explicitly + prohibited for entities of type message/partial. + + It should be noted that, because some message transfer agents may + choose to automatically fragment large messages, and because such + agents may use different fragmentation thresholds, it is possible + that the pieces of a partial message, upon reassembly, may prove + themselves to comprise a partial message. This is explicitly + permitted. + + It should also be noted that the inclusion of a "References" field in + the headers of the second and subsequent pieces of a fragmented + message that references the Message-Id on the previous piece may be + of benefit to mail readers that understand and track references. + However, the generation of such "References" fields is entirely + optional. + + Finally, it should be noted that the "Encrypted" header field has + been made obsolete by Privacy Enhanced Messaging (PEM), but the rules + above are believed to describe the correct way to treat it if it is + encountered in the context of conversion to and from message/partial + fragments. + +7.3.3. The Message/External-Body subtype + + The external-body subtype indicates that the actual body data are not + included, but merely referenced. In this case, the parameters + describe a mechanism for accessing the external data. + + When an entity is of type "message/external-body", it consists of a + header, two consecutive CRLFs, and the message header for the + encapsulated message. If another pair of consecutive CRLFs appears, + this of course ends the message header for the encapsulated message. + However, since the encapsulated message's body is itself external, it + does NOT appear in the area that follows. For example, consider the + following message: + + Content-type: message/external-body; access- + type=local-file; + + name="/u/nsb/Me.gif" + + Content-type: image/gif + Content-ID: + Content-Transfer-Encoding: binary + + + + +Borenstein & Freed [Page 42] + +RFC 1521 MIME September 1993 + + + THIS IS NOT REALLY THE BODY! + + The area at the end, which might be called the "phantom body", is + ignored for most external-body messages. However, it may be used to + contain auxiliary information for some such messages, as indeed it is + when the access-type is "mail-server". Of the access-types defined + by this document, the phantom body is used only when the access-type + is "mail-server". In all other cases, the phantom body is ignored. + + The only always-mandatory parameter for message/external-body is + "access-type"; all of the other parameters may be mandatory or + optional depending on the value of access-type. + + ACCESS-TYPE -- A case-insensitive word, indicating the supported + access mechanism by which the file or data may be obtained. + Values include, but are not limited to, "FTP", "ANON-FTP", "TFTP", + "AFS", "LOCAL-FILE", and "MAIL-SERVER". Future values, except for + experimental values beginning with "X-" must be registered with + IANA, as described in Appendix E . + + In addition, the following three parameters are optional for ALL + access-types: + + EXPIRATION -- The date (in the RFC 822 "date-time" syntax, as + extended by RFC 1123 to permit 4 digits in the year field) after + which the existence of the external data is not guaranteed. + + SIZE -- The size (in octets) of the data. The intent of this + parameter is to help the recipient decide whether or not to expend + the necessary resources to retrieve the external data. Note that + this describes the size of the data in its canonical form, that + is, before any Content- Transfer-Encoding has been applied or + after the data have been decoded. + + PERMISSION -- A case-insensitive field that indicates whether or + not it is expected that clients might also attempt to overwrite + the data. By default, or if permission is "read", the assumption + is that they are not, and that if the data is retrieved once, it + is never needed again. If PERMISSION is "read-write", this + assumption is invalid, and any local copy must be considered no + more than a cache. "Read" and "Read-write" are the only defined + values of permission. + + The precise semantics of the access-types defined here are described + in the sections that follow. + + The encapsulated headers in ALL message/external-body entities MUST + include a Content-ID header field to give a unique identifier by + + + +Borenstein & Freed [Page 43] + +RFC 1521 MIME September 1993 + + + which to reference the data. This identifier may be used for + cacheing mechanisms, and for recognizing the receipt of the data when + the access-type is "mail-server". + + Note that, as specified here, the tokens that describe external-body + data, such as file names and mail server commands, are required to be + in the US-ASCII character set. If this proves problematic in + practice, a new mechanism may be required as a future extension to + MIME, either as newly defined access-types for message/external-body + or by some other mechanism. + + As with message/partial, it is specified that MIME entities of type + message/external-body must always have a content-transfer-encoding of + 7-bit (the default). In particular, even in environments that + support binary or 8-bit transport, the use of a content-transfer- + encoding of "8bit" or "binary" is explicitly prohibited for entities + of type message/external-body. + +7.3.3.1. The "ftp" and "tftp" access-types + + An access-type of FTP or TFTP indicates that the message body is + accessible as a file using the FTP [RFC-959] or TFTP [RFC-783] + protocols, respectively. For these access-types, the following + additional parameters are mandatory: + + NAME -- The name of the file that contains the actual body data. + + SITE -- A machine from which the file may be obtained, using the + given protocol. This must be a fully qualified domain name, not a + nickname. + + Before any data are retrieved, using FTP, the user will generally + need to be asked to provide a login id and a password for the machine + named by the site parameter. For security reasons, such an id and + password are not specified as content-type parameters, but must be + obtained from the user. + + In addition, the following parameters are optional: + + DIRECTORY -- A directory from which the data named by NAME should + be retrieved. + + MODE -- A case-insensitive string indicating the mode to be used + when retrieving the information. The legal values for access-type + "TFTP" are "NETASCII", "OCTET", and "MAIL", as specified by the + TFTP protocol [RFC-783]. The legal values for access-type "FTP" + are "ASCII", "EBCDIC", "IMAGE", and "LOCALn" where "n" is a + decimal integer, typically 8. These correspond to the + + + +Borenstein & Freed [Page 44] + +RFC 1521 MIME September 1993 + + + representation types "A" "E" "I" and "L n" as specified by the FTP + protocol [RFC-959]. Note that "BINARY" and "TENEX" are not valid + values for MODE, but that "OCTET" or "IMAGE" or "LOCAL8" should be + used instead. IF MODE is not specified, the default value is + "NETASCII" for TFTP and "ASCII" otherwise. + +7.3.3.2. The "anon-ftp" access-type + + The "anon-ftp" access-type is identical to the "ftp" access type, + except that the user need not be asked to provide a name and password + for the specified site. Instead, the ftp protocol will be used with + login "anonymous" and a password that corresponds to the user's email + address. + +7.3.3.3. The "local-file" and "afs" access-types + + An access-type of "local-file" indicates that the actual body is + accessible as a file on the local machine. An access-type of "afs" + indicates that the file is accessible via the global AFS file system. + In both cases, only a single parameter is required: + + NAME -- The name of the file that contains the actual body data. + + The following optional parameter may be used to describe the locality + of reference for the data, that is, the site or sites at which the + file is expected to be visible: + + SITE -- A domain specifier for a machine or set of machines that + are known to have access to the data file. Asterisks may be used + for wildcard matching to a part of a domain name, such as + "*.bellcore.com", to indicate a set of machines on which the data + should be directly visible, while a single asterisk may be used to + indicate a file that is expected to be universally available, + e.g., via a global file system. + +7.3.3.4. The "mail-server" access-type + + The "mail-server" access-type indicates that the actual body is + available from a mail server. The mandatory parameter for this + access-type is: + + SERVER -- The email address of the mail server from which the + actual body data can be obtained. + + Because mail servers accept a variety of syntaxes, some of which is + multiline, the full command to be sent to a mail server is not + included as a parameter on the content-type line. Instead, it is + provided as the "phantom body" when the content-type is + + + +Borenstein & Freed [Page 45] + +RFC 1521 MIME September 1993 + + + message/external-body and the access- type is mail-server. + + An optional parameter for this access-type is: + + SUBJECT -- The subject that is to be used in the mail that is sent + to obtain the data. Note that keying mail servers on Subject lines + is NOT recommended, but such mail servers are known to exist. + + Note that MIME does not define a mail server syntax. Rather, it + allows the inclusion of arbitrary mail server commands in the phantom + body. Implementations must include the phantom body in the body of + the message it sends to the mail server address to retrieve the + relevant data. + + It is worth noting that, unlike other access-types, mail-server + access is asynchronous and will happen at an unpredictable time in + the future. For this reason, it is important that there be a + mechanism by which the returned data can be matched up with the + original message/external-body entity. MIME mailservers must use the + same Content-ID field on the returned message that was used in the + original message/external-body entity, to facilitate such matching. + +7.3.3.5. Examples and Further Explanations + + With the emerging possibility of very wide-area file systems, it + becomes very hard to know in advance the set of machines where a file + will and will not be accessible directly from the file system. + Therefore it may make sense to provide both a file name, to be tried + directly, and the name of one or more sites from which the file is + known to be accessible. An implementation can try to retrieve remote + files using FTP or any other protocol, using anonymous file retrieval + or prompting the user for the necessary name and password. If an + external body is accessible via multiple mechanisms, the sender may + include multiple parts of type message/external-body within an entity + of type multipart/alternative. + + However, the external-body mechanism is not intended to be limited to + file retrieval, as shown by the mail-server access-type. Beyond + this, one can imagine, for example, using a video server for external + references to video clips. + + If an entity is of type "message/external-body", then the body of the + entity will contain the header fields of the encapsulated message. + The body itself is to be found in the external location. This means + that if the body of the "message/external-body" message contains two + consecutive CRLFs, everything after those pairs is NOT part of the + message itself. For most message/external-body messages, this + trailing area must simply be ignored. However, it is a convenient + + + +Borenstein & Freed [Page 46] + +RFC 1521 MIME September 1993 + + + place for additional data that cannot be included in the content-type + header field. In particular, if the "access-type" value is "mail- + server", then the trailing area must contain commands to be sent to + the mail server at the address given by the value of the SERVER + parameter. + + The embedded message header fields which appear in the body of the + message/external-body data must be used to declare the Content-type + of the external body if it is anything other than plain ASCII text, + since the external body does not have a header section to declare its + type. Similarly, any Content-transfer-encoding other than "7bit" + must also be declared here. Thus a complete message/external-body + message, referring to a document in PostScript format, might look + like this: + + From: Whomever + To: Someone + Subject: whatever + MIME-Version: 1.0 + Message-ID: + Content-Type: multipart/alternative; boundary=42 + Content-ID: + + --42 + Content-Type: message/external-body; + name="BodyFormats.ps"; + site="thumper.bellcore.com"; + access-type=ANON-FTP; + directory="pub"; + mode="image"; + expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)" + + Content-type: application/postscript + Content-ID: + + --42 + Content-Type: message/external-body; + name="/u/nsb/writing/rfcs/RFC-MIME.ps"; + site="thumper.bellcore.com"; + access-type=AFS + expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)" + + Content-type: application/postscript + Content-ID: + + --42 + Content-Type: message/external-body; + access-type=mail-server + + + +Borenstein & Freed [Page 47] + +RFC 1521 MIME September 1993 + + + server="listserv@bogus.bitnet"; + expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)" + + Content-type: application/postscript + Content-ID: + + get RFC-MIME.DOC + + --42-- + + Note that in the above examples, the default Content-transfer- + encoding of "7bit" is assumed for the external postscript data. + + Like the message/partial type, the message/external-body type is + intended to be transparent, that is, to convey the data type in the + external body rather than to convey a message with a body of that + type. Thus the headers on the outer and inner parts must be merged + using the same rules as for message/partial. In particular, this + means that the Content-type header is overridden, but the From and + Subject headers are preserved. + + Note that since the external bodies are not transported as mail, they + need not conform to the 7-bit and line length requirements, but might + in fact be binary files. Thus a Content-Transfer-Encoding is not + generally necessary, though it is permitted. + + Note that the body of a message of type "message/external-body" is + governed by the basic syntax for an RFC 822 message. In particular, + anything before the first consecutive pair of CRLFs is header + information, while anything after it is body information, which is + ignored for most access-types. + + The formal grammar for content-type header fields for data of type + message is given by: + + message-type := "message" "/" message-subtype + + message-subtype := "rfc822" + / "partial" 2#3partial-param + / "external-body" 1*external-param + / extension-token + + partial-param := (";" "id" "=" value) + / (";" "number" "=" 1*DIGIT) + / (";" "total" "=" 1*DIGIT) + ; id & number required; total required for last part + + external-param := (";" "access-type" "=" atype) + + + +Borenstein & Freed [Page 48] + +RFC 1521 MIME September 1993 + + + / (";" "expiration" "=" date-time) + ; Note that date-time is quoted + / (";" "size" "=" 1*DIGIT) + / (";" "permission" "=" ("read" / "read-write")) + ; Permission is case-insensitive + / (";" "name" "=" value) + / (";" "site" "=" value) + / (";" "dir" "=" value) + / (";" "mode" "=" value) + / (";" "server" "=" value) + / (";" "subject" "=" value) + ; access-type required;others required based on access-type + + atype := "ftp" / "anon-ftp" / "tftp" / "local-file" + / "afs" / "mail-server" / extension-token + ; Case-insensitive + +7.4. The Application Content-Type + + The "application" Content-Type is to be used for data which do not + fit in any of the other categories, and particularly for data to be + processed by mail-based uses of application programs. This is + information which must be processed by an application before it is + viewable or usable to a user. Expected uses for Content-Type + application include mail-based file transfer, spreadsheets, data for + mail-based scheduling systems, and languages for "active" + (computational) email. (The latter, in particular, can pose security + problems which must be understood by implementors, and are considered + in detail in the discussion of the application/PostScript content- + type.) + + For example, a meeting scheduler might define a standard + representation for information about proposed meeting dates. An + intelligent user agent would use this information to conduct a dialog + with the user, and might then send further mail based on that dialog. + More generally, there have been several "active" messaging languages + developed in which programs in a suitably specialized language are + sent through the mail and automatically run in the recipient's + environment. + + Such applications may be defined as subtypes of the "application" + Content-Type. This document defines two subtypes: octet-stream, and + PostScript. + + In general, the subtype of application will often be the name of the + application for which the data are intended. This does not mean, + however, that any application program name may be used freely as a + subtype of application. Such usages (other than subtypes beginning + + + +Borenstein & Freed [Page 49] + +RFC 1521 MIME September 1993 + + + with "x-") must be registered with IANA, as described in Appendix E. + +7.4.1. The Application/Octet-Stream (primary) subtype + + The primary subtype of application, "octet-stream", may be used to + indicate that a body contains binary data. The set of possible + parameters includes, but is not limited to: + + TYPE -- the general type or category of binary data. This is + intended as information for the human recipient rather than for + any automatic processing. + + PADDING -- the number of bits of padding that were appended to the + bit-stream comprising the actual contents to produce the enclosed + byte-oriented data. This is useful for enclosing a bit-stream in + a body when the total number of bits is not a multiple of the byte + size. + + An additional parameter, "conversions", was defined in [RFC-1341] but + has been removed. + + RFC 1341 also defined the use of a "NAME" parameter which gave a + suggested file name to be used if the data were to be written to a + file. This has been deprecated in anticipation of a separate + Content-Disposition header field, to be defined in a subsequent RFC. + + The recommended action for an implementation that receives + application/octet-stream mail is to simply offer to put the data in a + file, with any Content-Transfer-Encoding undone, or perhaps to use it + as input to a user-specified process. + + To reduce the danger of transmitting rogue programs through the mail, + it is strongly recommended that implementations NOT implement a + path-search mechanism whereby an arbitrary program named in the + Content-Type parameter (e.g., an "interpreter=" parameter) is found + and executed using the mail body as input. + +7.4.2. The Application/PostScript subtype + + A Content-Type of "application/postscript" indicates a PostScript + program. Currently two variants of the PostScript language are + allowed; the original level 1 variant is described in [POSTSCRIPT] + and the more recent level 2 variant is described in [POSTSCRIPT2]. + + PostScript is a registered trademark of Adobe Systems, Inc. Use of + the MIME content-type "application/postscript" implies recognition of + that trademark and all the rights it entails. + + + + +Borenstein & Freed [Page 50] + +RFC 1521 MIME September 1993 + + + The PostScript language definition provides facilities for internal + labeling of the specific language features a given program uses. This + labeling, called the PostScript document structuring conventions, is + very general and provides substantially more information than just + the language level. + + The use of document structuring conventions, while not required, is + strongly recommended as an aid to interoperability. Documents which + lack proper structuring conventions cannot be tested to see whether + or not they will work in a given environment. As such, some systems + may assume the worst and refuse to process unstructured documents. + + The execution of general-purpose PostScript interpreters entails + serious security risks, and implementors are discouraged from simply + sending PostScript email bodies to "off-the-shelf" interpreters. + While it is usually safe to send PostScript to a printer, where the + potential for harm is greatly constrained, implementors should + consider all of the following before they add interactive display of + PostScript bodies to their mail readers. + + The remainder of this section outlines some, though probably not all, + of the possible problems with sending PostScript through the mail. + + Dangerous operations in the PostScript language include, but may not + be limited to, the PostScript operators deletefile, renamefile, + filenameforall, and file. File is only dangerous when applied to + something other than standard input or output. Implementations may + also define additional nonstandard file operators; these may also + pose a threat to security. Filenameforall, the wildcard file search + operator, may appear at first glance to be harmless. Note, however, + that this operator has the potential to reveal information about what + files the recipient has access to, and this information may itself be + sensitive. Message senders should avoid the use of potentially + dangerous file operators, since these operators are quite likely to + be unavailable in secure PostScript implementations. Message- + receiving and -displaying software should either completely disable + all potentially dangerous file operators or take special care not to + delegate any special authority to their operation. These operators + should be viewed as being done by an outside agency when interpreting + PostScript documents. Such disabling and/or checking should be done + completely outside of the reach of the PostScript language itself; + care should be taken to insure that no method exists for re-enabling + full-function versions of these operators. + + The PostScript language provides facilities for exiting the normal + interpreter, or server, loop. Changes made in this "outer" + environment are customarily retained across documents, and may in + some cases be retained semipermanently in nonvolatile memory. The + + + +Borenstein & Freed [Page 51] + +RFC 1521 MIME September 1993 + + + operators associated with exiting the interpreter loop have the + potential to interfere with subsequent document processing. As such, + their unrestrained use constitutes a threat of service denial. + PostScript operators that exit the interpreter loop include, but may + not be limited to, the exitserver and startjob operators. Message- + sending software should not generate PostScript that depends on + exiting the interpreter loop to operate. The ability to exit will + probably be unavailable in secure PostScript implementations. + Message-receiving and -displaying software should, if possible, + disable the ability to make retained changes to the PostScript + environment, and eliminate the startjob and exitserver commands. If + these commands cannot be eliminated, the password associated with + them should at least be set to a hard-to-guess value. + + PostScript provides operators for setting system-wide and device- + specific parameters. These parameter settings may be retained across + jobs and may potentially pose a threat to the correct operation of + the interpreter. The PostScript operators that set system and device + parameters include, but may not be limited to, the setsystemparams + and setdevparams operators. Message-sending software should not + generate PostScript that depends on the setting of system or device + parameters to operate correctly. The ability to set these parameters + will probably be unavailable in secure PostScript implementations. + Message-receiving and -displaying software should, if possible, + disable the ability to change system and device parameters. If these + operators cannot be disabled, the password associated with them + should at least be set to a hard-to-guess value. + + Some PostScript implementations provide nonstandard facilities for + the direct loading and execution of machine code. Such facilities + are quite obviously open to substantial abuse. Message-sending + software should not make use of such features. Besides being totally + hardware- specific, they are also likely to be unavailable in secure + implementations of PostScript. Message-receiving and -displaying + software should not allow such operators to be used if they exist. + + PostScript is an extensible language, and many, if not most, + implementations of it provide a number of their own extensions. This + document does not deal with such extensions explicitly since they + constitute an unknown factor. Message-sending software should not + make use of nonstandard extensions; they are likely to be missing + from some implementations. Message-receiving and -displaying software + should make sure that any nonstandard PostScript operators are secure + and don't present any kind of threat. + + It is possible to write PostScript that consumes huge amounts of + various system resources. It is also possible to write PostScript + programs that loop infinitely. Both types of programs have the + + + +Borenstein & Freed [Page 52] + +RFC 1521 MIME September 1993 + + + potential to cause damage if sent to unsuspecting recipients. + Message-sending software should avoid the construction and + dissemination of such programs, which is antisocial. Message- + receiving and -displaying software should provide appropriate + mechanisms to abort processing of a document after a reasonable + amount of time has elapsed. In addition, PostScript interpreters + should be limited to the consumption of only a reasonable amount of + any given system resource. + + Finally, bugs may exist in some PostScript interpreters which could + possibly be exploited to gain unauthorized access to a recipient's + system. Apart from noting this possibility, there is no specific + action to take to prevent this, apart from the timely correction of + such bugs if any are found. + +7.4.3. Other Application subtypes + + It is expected that many other subtypes of application will be + defined in the future. MIME implementations must generally treat any + unrecognized subtypes as being equivalent to application/octet- + stream. + + The formal grammar for content-type header fields for application + data is given by: + + application-type := "application" "/" application-subtype + + application-subtype := ("octet-stream" *stream-param) + / "postscript" / extension-token + + stream-param := (";" "type" "=" value) + / (";" "padding" "=" padding) + + padding := "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" + +7.5. The Image Content-Type + + A Content-Type of "image" indicates that the body contains an image. + The subtype names the specific image format. These names are case + insensitive. Two initial subtypes are "jpeg" for the JPEG format, + JFIF encoding, and "gif" for GIF format [GIF]. + + The list of image subtypes given here is neither exclusive nor + exhaustive, and is expected to grow as more types are registered with + IANA, as described in Appendix E. + + The formal grammar for the content-type header field for data of type + image is given by: + + + +Borenstein & Freed [Page 53] + +RFC 1521 MIME September 1993 + + + image-type := "image" "/" ("gif" / "jpeg" / extension-token) + +7.6. The Audio Content-Type + + A Content-Type of "audio" indicates that the body contains audio + data. Although there is not yet a consensus on an "ideal" audio + format for use with computers, there is a pressing need for a format + capable of providing interoperable behavior. + + The initial subtype of "basic" is specified to meet this requirement + by providing an absolutely minimal lowest common denominator audio + format. It is expected that richer formats for higher quality and/or + lower bandwidth audio will be defined by a later document. + + The content of the "audio/basic" subtype is audio encoded using 8-bit + ISDN mu-law [PCM]. When this subtype is present, a sample rate of + 8000 Hz and a single channel is assumed. + + The formal grammar for the content-type header field for data of type + audio is given by: + + audio-type := "audio" "/" ("basic" / extension-token) + +7.7. The Video Content-Type + + A Content-Type of "video" indicates that the body contains a time- + varying-picture image, possibly with color and coordinated sound. + The term "video" is used extremely generically, rather than with + reference to any particular technology or format, and is not meant to + preclude subtypes such as animated drawings encoded compactly. The + subtype "mpeg" refers to video coded according to the MPEG standard + [MPEG]. + + Note that although in general this document strongly discourages the + mixing of multiple media in a single body, it is recognized that many + so-called "video" formats include a representation for synchronized + audio, and this is explicitly permitted for subtypes of "video". + + The formal grammar for the content-type header field for data of type + video is given by: + + video-type := "video" "/" ("mpeg" / extension-token) + +7.8. Experimental Content-Type Values + + A Content-Type value beginning with the characters "X-" is a private + value, to be used by consenting mail systems by mutual agreement. + Any format without a rigorous and public definition must be named + + + +Borenstein & Freed [Page 54] + +RFC 1521 MIME September 1993 + + + with an "X-" prefix, and publicly specified values shall never begin + with "X-". (Older versions of the widely-used Andrew system use the + "X-BE2" name, so new systems should probably choose a different + name.) + + In general, the use of "X-" top-level types is strongly discouraged. + Implementors should invent subtypes of the existing types whenever + possible. The invention of new types is intended to be restricted + primarily to the development of new media types for email, such as + digital odors or holography, and not for new data formats in general. + In many cases, a subtype of application will be more appropriate than + a new top-level type. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Borenstein & Freed [Page 55] + +RFC 1521 MIME September 1993 + + +8. Summary + + Using the MIME-Version, Content-Type, and Content-Transfer-Encoding + header fields, it is possible to include, in a standardized way, + arbitrary types of data objects with RFC 822 conformant mail + messages. No restrictions imposed by either RFC 821 or RFC 822 are + violated, and care has been taken to avoid problems caused by + additional restrictions imposed by the characteristics of some + Internet mail transport mechanisms (see Appendix B). The "multipart" + and "message" Content-Types allow mixing and hierarchical structuring + of objects of different types in a single message. Further Content- + Types provide a standardized mechanism for tagging messages or body + parts as audio, image, or several other kinds of data. A + distinguished parameter syntax allows further specification of data + format details, particularly the specification of alternate character + sets. Additional optional header fields provide mechanisms for + certain extensions deemed desirable by many implementors. Finally, a + number of useful Content-Types are defined for general use by + consenting user agents, notably message/partial, and + message/external-body. + +9. Security Considerations + + Security issues are discussed in Section 7.4.2 and in Appendix F. + Implementors should pay special attention to the security + implications of any mail content-types that can cause the remote + execution of any actions in the recipient's environment. In such + cases, the discussion of the application/postscript content-type in + Section 7.4.2 may serve as a model for considering other content- + types with remote execution capabilities. + + + + + + + + + + + + + + + + + + + + + +Borenstein & Freed [Page 56] + +RFC 1521 MIME September 1993 + + +10. Authors' Addresses + + For more information, the authors of this document may be contacted + via Internet mail: + + Nathaniel S. Borenstein + MRE 2D-296, Bellcore + 445 South St. + Morristown, NJ 07962-1910 + + Phone: +1 201 829 4270 + Fax: +1 201 829 7019 + Email: nsb@bellcore.com + + + Ned Freed + Innosoft International, Inc. + 250 West First Street + Suite 240 + Claremont, CA 91711 + + Phone: +1 909 624 7907 + Fax: +1 909 621 5319 + Email: ned@innosoft.com + + MIME is a result of the work of the Internet Engineering Task Force + Working Group on Email Extensions. The chairman of that group, Greg + Vaudreuil, may be reached at: + + Gregory M. Vaudreuil + Tigon Corporation + 17060 Dallas Parkway + Dallas Texas, 75248 + + Phone: +1 214-733-2722 + EMail: gvaudre@cnri.reston.va.us + + + + + + + + + + + + + + + +Borenstein & Freed [Page 57] + +RFC 1521 MIME September 1993 + + +11. Acknowledgements + + This document is the result of the collective effort of a large + number of people, at several IETF meetings, on the IETF-SMTP and + IETF-822 mailing lists, and elsewhere. Although any enumeration + seems doomed to suffer from egregious omissions, the following are + among the many contributors to this effort: + + Harald Tveit Alvestrand Timo Lehtinen + Randall Atkinson John R. MacMillan + Philippe Brandon Rick McGowan + Kevin Carosso Leo Mclaughlin + Uhhyung Choi Goli Montaser-Kohsari + Cristian Constantinof Keith Moore + Mark Crispin Tom Moore + Dave Crocker Erik Naggum + Terry Crowley Mark Needleman + Walt Daniels John Noerenberg + Frank Dawson Mats Ohrman + Hitoshi Doi Julian Onions + Kevin Donnelly Michael Patton + Keith Edwards David J. Pepper + Chris Eich Blake C. Ramsdell + Johnny Eriksson Luc Rooijakkers + Craig Everhart Marshall T. Rose + Patrik Faeltstroem Jonathan Rosenberg + Erik E. Fair Jan Rynning + Roger Fajman Harri Salminen + Alain Fontaine Michael Sanderson + James M. Galvin Masahiro Sekiguchi + Philip Gladstone Mark Sherman + Thomas Gordon Keld Simonsen + Phill Gross Bob Smart + James Hamilton Peter Speck + Steve Hardcastle-Kille Henry Spencer + David Herron Einar Stefferud + Bruce Howard Michael Stein + Bill Janssen Klaus Steinberger + Olle Jaernefors Peter Svanberg + Risto Kankkunen James Thompson + Phil Karn Steve Uhler + Alan Katz Stuart Vance + Tim Kehres Erik van der Poel + Neil Katin Guido van Rossum + Kyuho Kim Peter Vanderbilt + Anders Klemets Greg Vaudreuil + John Klensin Ed Vielmetti + Valdis Kletniek Ryan Waldron + + + +Borenstein & Freed [Page 58] + +RFC 1521 MIME September 1993 + + + Jim Knowles Wally Wedel + Stev Knowles Sven-Ove Westberg + Bob Kummerfeld Brian Wideen + Pekka Kytolaakso John Wobus + Stellan Lagerstrom Glenn Wright + Vincent Lau Rayan Zachariassen + Donald Lindsay David Zimmerman + Marc Andreessen Bob Braden + Brian Capouch Peter Clitherow + Dave Collier-Brown John Coonrod + Stephen Crocker Jim Davis + Axel Deininger Dana S Emery + Martin Forssen Stephen Gildea + Terry Gray Mark Horton + Warner Losh Carlyn Lowery + Laurence Lundblade Charles Lynn + Larry Masinter Michael J. McInerny + Jon Postel Christer Romson + Yutaka Sato Markku Savela + Richard Alan Schafer Larry W. Virden + Rhys Weatherly Jay Weber + Dave Wecker + +The authors apologize for any omissions from this list, which are +certainly unintentional. + + + + + + + + + + + + + + + + + + + + + + + + + + +Borenstein & Freed [Page 59] + +RFC 1521 MIME September 1993 + + +Appendix A -- Minimal MIME-Conformance + + The mechanisms described in this document are open-ended. It is + definitely not expected that all implementations will support all of + the Content-Types described, nor that they will all share the same + extensions. In order to promote interoperability, however, it is + useful to define the concept of "MIME-conformance" to define a + certain level of implementation that allows the useful interworking + of messages with content that differs from US ASCII text. In this + section, we specify the requirements for such conformance. + + A mail user agent that is MIME-conformant MUST: + + 1. Always generate a "MIME-Version: 1.0" header field. + + 2. Recognize the Content-Transfer-Encoding header field, and + decode all received data encoded with either the quoted-printable + or base64 implementations. Encode any data sent that is not in + seven-bit mail-ready representation using one of these + transformations and include the appropriate Content-Transfer- + Encoding header field, unless the underlying transport mechanism + supports non-seven-bit data, as SMTP does not. + + 3. Recognize and interpret the Content-Type header field, and + avoid showing users raw data with a Content-Type field other than + text. Be able to send at least text/plain messages, with the + character set specified as a parameter if it is not US-ASCII. + + 4. Explicitly handle the following Content-Type values, to at + least the following extents: + + Text: + + -- Recognize and display "text" mail + with the character set "US-ASCII." + + -- Recognize other character sets at + least to the extent of being able + to inform the user about what + character set the message uses. + + -- Recognize the "ISO-8859-*" character + sets to the extent of being able to + display those characters that are + common to ISO-8859-* and US-ASCII, + namely all characters represented + by octet values 0-127. + + + + +Borenstein & Freed [Page 60] + +RFC 1521 MIME September 1993 + + + -- For unrecognized subtypes, show or + offer to show the user the "raw" + version of the data after + conversion of the content from + canonical form to local form. + + Message: + + -- Recognize and display at least the + primary (822) encapsulation. + + Multipart: + + -- Recognize the primary (mixed) + subtype. Display all relevant + information on the message level + and the body part header level and + then display or offer to display + each of the body parts individually. + + -- Recognize the "alternative" subtype, + and avoid showing the user + redundant parts of + multipart/alternative mail. + + -- Treat any unrecognized subtypes as if + they were "mixed". + + Application: + + -- Offer the ability to remove either of + the two types of Content-Transfer- + Encoding defined in this document + and put the resulting information + in a user file. + + 5. Upon encountering any unrecognized Content- Type, an + implementation must treat it as if it had a Content-Type of + "application/octet-stream" with no parameter sub-arguments. How + such data are handled is up to an implementation, but likely + options for handling such unrecognized data include offering the + user to write it into a file (decoded from its mail transport + format) or offering the user to name a program to which the + decoded data should be passed as input. Unrecognized predefined + types, which in a MIME-conformant mailer might still include + audio, image, or video, should also be treated in this way. + + A user agent that meets the above conditions is said to be MIME- + + + +Borenstein & Freed [Page 61] + +RFC 1521 MIME September 1993 + + + conformant. The meaning of this phrase is that it is assumed to be + "safe" to send virtually any kind of properly-marked data to users of + such mail systems, because such systems will at least be able to + treat the data as undifferentiated binary, and will not simply splash + it onto the screen of unsuspecting users. There is another sense in + which it is always "safe" to send data in a format that is MIME- + conformant, which is that such data will not break or be broken by + any known systems that are conformant with RFC 821 and RFC 822. User + agents that are MIME-conformant have the additional guarantee that + the user will not be shown data that were never intended to be viewed + as text. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Borenstein & Freed [Page 62] + +RFC 1521 MIME September 1993 + + +Appendix B -- General Guidelines For Sending Email Data + + Internet email is not a perfect, homogeneous system. Mail may become + corrupted at several stages in its travel to a final destination. + Specifically, email sent throughout the Internet may travel across + many networking technologies. Many networking and mail technologies + do not support the full functionality possible in the SMTP transport + environment. Mail traversing these systems is likely to be modified + in such a way that it can be transported. + + There exist many widely-deployed non-conformant MTAs in the Internet. + These MTAs, speaking the SMTP protocol, alter messages on the fly to + take advantage of the internal data structure of the hosts they are + implemented on, or are just plain broken. + + The following guidelines may be useful to anyone devising a data + format (Content-Type) that will survive the widest range of + networking technologies and known broken MTAs unscathed. Note that + anything encoded in the base64 encoding will satisfy these rules, but + that some well-known mechanisms, notably the UNIX uuencode facility, + will not. Note also that anything encoded in the Quoted-Printable + encoding will survive most gateways intact, but possibly not some + gateways to systems that use the EBCDIC character set. + + (1) Under some circumstances the encoding used for data may change + as part of normal gateway or user agent operation. In particular, + conversion from base64 to quoted-printable and vice versa may be + necessary. This may result in the confusion of CRLF sequences with + line breaks in text bodies. As such, the persistence of CRLF as + something other than a line break must not be relied on. + + (2) Many systems may elect to represent and store text data using + local newline conventions. Local newline conventions may not match + the RFC822 CRLF convention -- systems are known that use plain CR, + plain LF, CRLF, or counted records. The result is that isolated + CR and LF characters are not well tolerated in general; they may + be lost or converted to delimiters on some systems, and hence must + not be relied on. + + (3) TAB (HT) characters may be misinterpreted or may be + automatically converted to variable numbers of spaces. This is + unavoidable in some environments, notably those not based on the + ASCII character set. Such conversion is STRONGLY DISCOURAGED, but + it may occur, and mail formats must not rely on the persistence of + TAB (HT) characters. + + (4) Lines longer than 76 characters may be wrapped or truncated in + some environments. Line wrapping and line truncation are STRONGLY + + + +Borenstein & Freed [Page 63] + +RFC 1521 MIME September 1993 + + + DISCOURAGED, but unavoidable in some cases. Applications which + require long lines must somehow differentiate between soft and + hard line breaks. (A simple way to do this is to use the quoted- + printable encoding.) + + (5) Trailing "white space" characters (SPACE, TAB (HT)) on a line + may be discarded by some transport agents, while other transport + agents may pad lines with these characters so that all lines in a + mail file are of equal length. The persistence of trailing white + space, therefore, must not be relied on. + + (6) Many mail domains use variations on the ASCII character set, + or use character sets such as EBCDIC which contain most but not + all of the US-ASCII characters. The correct translation of + characters not in the "invariant" set cannot be depended on across + character converting gateways. For example, this situation is a + problem when sending uuencoded information across BITNET, an + EBCDIC system. Similar problems can occur without crossing a + gateway, since many Internet hosts use character sets other than + ASCII internally. The definition of Printable Strings in X.400 + adds further restrictions in certain special cases. In + particular, the only characters that are known to be consistent + across all gateways are the 73 characters that correspond to the + upper and lower case letters A-Z and a-z, the 10 digits 0-9, and + the following eleven special characters: + + "'" (ASCII code 39) + "(" (ASCII code 40) + ")" (ASCII code 41) + "+" (ASCII code 43) + "," (ASCII code 44) + "-" (ASCII code 45) + "." (ASCII code 46) + "/" (ASCII code 47) + ":" (ASCII code 58) + "=" (ASCII code 61) + "?" (ASCII code 63) + + A maximally portable mail representation, such as the base64 + encoding, will confine itself to relatively short lines of text in + which the only meaningful characters are taken from this set of 73 + characters. + + (7) Some mail transport agents will corrupt data that includes + certain literal strings. In particular, a period (".") alone on a + line is known to be corrupted by some (incorrect) SMTP + implementations, and a line that starts with the five characters + "From " (the fifth character is a SPACE) are commonly corrupted as + + + +Borenstein & Freed [Page 64] + +RFC 1521 MIME September 1993 + + + well. A careful composition agent can prevent these corruptions + by encoding the data (e.g., in the quoted-printable encoding, + "=46rom " in place of "From " at the start of a line, and "=2E" in + place of "." alone on a line. + + Please note that the above list is NOT a list of recommended + practices for MTAs. RFC 821 MTAs are prohibited from altering the + character of white space or wrapping long lines. These BAD and + illegal practices are known to occur on established networks, and + implementations should be robust in dealing with the bad effects they + can cause. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Borenstein & Freed [Page 65] + +RFC 1521 MIME September 1993 + + +Appendix C -- A Complex Multipart Example + + What follows is the outline of a complex multipart message. This + message has five parts to be displayed serially: two introductory + plain text parts, an embedded multipart message, a richtext part, and + a closing encapsulated text message in a non-ASCII character set. + The embedded multipart message has two parts to be displayed in + parallel, a picture and an audio fragment. + + MIME-Version: 1.0 + From: Nathaniel Borenstein + To: Ned Freed + Subject: A multipart example + Content-Type: multipart/mixed; + boundary=unique-boundary-1 + + This is the preamble area of a multipart message. + Mail readers that understand multipart format + should ignore this preamble. + If you are reading this text, you might want to + consider changing to a mail reader that understands + how to properly display multipart messages. + --unique-boundary-1 + + ...Some text appears here... + [Note that the preceding blank line means + no header fields were given and this is text, + with charset US ASCII. It could have been + done with explicit typing as in the next part.] + + --unique-boundary-1 + Content-type: text/plain; charset=US-ASCII + + This could have been part of the previous part, + but illustrates explicit versus implicit + typing of body parts. + + --unique-boundary-1 + Content-Type: multipart/parallel; + boundary=unique-boundary-2 + + + --unique-boundary-2 + Content-Type: audio/basic + Content-Transfer-Encoding: base64 + + ... base64-encoded 8000 Hz single-channel + mu-law-format audio data goes here.... + + + +Borenstein & Freed [Page 66] + +RFC 1521 MIME September 1993 + + + --unique-boundary-2 + Content-Type: image/gif + Content-Transfer-Encoding: base64 + + ... base64-encoded image data goes here.... + + --unique-boundary-2-- + + --unique-boundary-1 + Content-type: text/richtext + + This is richtext. + as defined in RFC 1341 + Isn't it + cool? + + --unique-boundary-1 + Content-Type: message/rfc822 + + From: (mailbox in US-ASCII) + To: (address in US-ASCII) + Subject: (subject in US-ASCII) + Content-Type: Text/plain; charset=ISO-8859-1 + Content-Transfer-Encoding: Quoted-printable + + ... Additional text in ISO-8859-1 goes here ... + + --unique-boundary-1-- + + + + + + + + + + + + + + + + + + + + + + + +Borenstein & Freed [Page 67] + +RFC 1521 MIME September 1993 + + +Appendix D -- Collected Grammar + + This appendix contains the complete BNF grammar for all the syntax + specified by this document. + + By itself, however, this grammar is incomplete. It refers to several + entities that are defined by RFC 822. Rather than reproduce those + definitions here, and risk unintentional differences between the two, + this document simply refers the reader to RFC 822 for the remaining + definitions. Wherever a term is undefined, it refers to the RFC 822 + definition. + + application-subtype := ("octet-stream" *stream-param) + / "postscript" / extension-token + + application-type := "application" "/" application-subtype + + attribute := token ; case-insensitive + + atype := "ftp" / "anon-ftp" / "tftp" / "local-file" + / "afs" / "mail-server" / extension-token + ; Case-insensitive + + audio-type := "audio" "/" ("basic" / extension-token) + + body-part := <"message" as defined in RFC 822, + with all header fields optional, and with the + specified delimiter not occurring anywhere in + the message body, either on a line by itself + or as a substring anywhere.> + + NOTE: In certain transport enclaves, RFC 822 restrictions such as + the one that limits bodies to printable ASCII characters may not + be in force. (That is, the transport domains may resemble + standard Internet mail transport as specified in RFC821 and + assumed by RFC822, but without certain restrictions.) The + relaxation of these restrictions should be construed as locally + extending the definition of bodies, for example to include octets + outside of the ASCII range, as long as these extensions are + supported by the transport and adequately documented in the + Content-Transfer-Encoding header field. However, in no event are + headers (either message headers or body-part headers) allowed to + contain anything other than ASCII characters. + + + + + + + + +Borenstein & Freed [Page 68] + +RFC 1521 MIME September 1993 + + + boundary := 0*69 bcharsnospace + + bchars := bcharsnospace / " " + + bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" / "+" / "_" + / "," / "-" / "." / "/" / ":" / "=" / "?" + + charset := "us-ascii" / "iso-8859-1" / "iso-8859-2"/ "iso-8859-3" + / "iso-8859-4" / "iso-8859-5" / "iso-8859-6" / "iso-8859-7" + / "iso-8859-8" / "iso-8859-9" / extension-token + ; case insensitive + + close-delimiter := "--" boundary "--" CRLF;Again,no space by "--", + + content := "Content-Type" ":" type "/" subtype *(";" parameter) + ; case-insensitive matching of type and subtype + + delimiter := "--" boundary CRLF ;taken from Content-Type field. + ; There must be no space + ; between "--" and boundary. + + description := "Content-Description" ":" *text + + discard-text := *(*text CRLF) + + encapsulation := delimiter body-part CRLF + + encoding := "Content-Transfer-Encoding" ":" mechanism + + epilogue := discard-text ; to be ignored upon receipt. + + extension-token := x-token / iana-token + + external-param := (";" "access-type" "=" atype) + / (";" "expiration" "=" date-time) + + ; Note that date-time is quoted + / (";" "size" "=" 1*DIGIT) + / (";" "permission" "=" ("read" / "read-write")) + ; Permission is case-insensitive + / (";" "name" "=" value) + / (";" "site" "=" value) + / (";" "dir" "=" value) + / (";" "mode" "=" value) + / (";" "server" "=" value) + / (";" "subject" "=" value) + ;access-type required; others required based on access-type + + + + +Borenstein & Freed [Page 69] + +RFC 1521 MIME September 1993 + + + iana-token := + + id := "Content-ID" ":" msg-id + + image-type := "image" "/" ("gif" / "jpeg" / extension-token) + + mechanism := "7bit" ; case-insensitive + / "quoted-printable" + / "base64" + / "8bit" + / "binary" + / x-token + + message-subtype := "rfc822" + / "partial" 2#3partial-param + / "external-body" 1*external-param + / extension-token + + message-type := "message" "/" message-subtype + + multipart-body :=preamble 1*encapsulation close-delimiter epilogue + + multipart-subtype := "mixed" / "parallel" / "digest" + / "alternative" / extension-token + + multipart-type := "multipart" "/" multipart-subtype + ";" "boundary" "=" boundary + + octet := "=" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F") + ; octet must be used for characters > 127, =, SPACE, or + TAB, + ; and is recommended for any characters not listed in + ; Appendix B as "mail-safe". + + padding := "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" + + parameter := attribute "=" value + + partial-param := (";" "id" "=" value) + / (";" "number" "=" 1*DIGIT) + / (";" "total" "=" 1*DIGIT) + ; id & number required;total required for last part + + preamble := discard-text ; to be ignored upon receipt. + + ptext := octet / " / "@" + / "," / ";" / ":" / "\" / <"> + / "/" / "[" / "]" / "?" / "=" + ; Must be in quoted-string, + ; to use within parameter values + + + type := "application" / "audio" ; case-insensitive + / "image" / "message" + / "multipart" / "text" + / "video" / extension-token + ; All values case-insensitive + + value := token / quoted-string + + version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT + + video-type := "video" "/" ("mpeg" / extension-token) + + x-token := + + + + + + + + + + + + + +Borenstein & Freed [Page 71] + +RFC 1521 MIME September 1993 + + +Appendix E -- IANA Registration Procedures + + MIME has been carefully designed to have extensible mechanisms, and + it is expected that the set of content-type/subtype pairs and their + associated parameters will grow significantly with time. Several + other MIME fields, notably character set names, access-type + parameters for the message/external-body type, and possibly even + Content-Transfer-Encoding values, are likely to have new values + defined over time. In order to ensure that the set of such values is + developed in an orderly, well-specified, and public manner, MIME + defines a registration process which uses the Internet Assigned + Numbers Authority (IANA) as a central registry for such values. + + In general, parameters in the content-type header field are used to + convey supplemental information for various content types, and their + use is defined when the content-type and subtype are defined. New + parameters should not be defined as a way to introduce new + functionality. + + In order to simplify and standardize the registration process, this + appendix gives templates for the registration of new values with + IANA. Each of these is given in the form of an email message + template, to be filled in by the registering party. + + E.1 Registration of New Content-type/subtype Values + + Note that MIME is generally expected to be extended by subtypes. If + a new fundamental top-level type is needed, its specification must be + published as an RFC or submitted in a form suitable to become an RFC, + and be subject to the Internet standards process. + + To: IANA@isi.edu + Subject: Registration of new MIME + content-type/subtype + + MIME type name: + + (If the above is not an existing top-level MIME type, + please explain why an existing type cannot be used.) + + MIME subtype name: + + Required parameters: + + Optional parameters: + + Encoding considerations: + + + + +Borenstein & Freed [Page 72] + +RFC 1521 MIME September 1993 + + + Security considerations: + + Published specification: + + (The published specification must be an Internet RFC or + RFC-to-be if a new top-level type is being defined, and + must be a publicly available specification in any + case.) + + Person & email address to contact for further information: + + E.2 Registration of New Access-type Values + for Message/external-body + + To: IANA@isi.edu + Subject: Registration of new MIME Access-type for + Message/external-body content-type + + MIME access-type name: + + Required parameters: + + Optional parameters: + + Published specification: + + (The published specification must be an Internet RFC or + RFC-to-be.) + + Person & email address to contact for further information: + + + + + + + + + + + + + + + + + + + + + +Borenstein & Freed [Page 73] + +RFC 1521 MIME September 1993 + + +Appendix F -- Summary of the Seven Content-types + + Content-type: text + + Subtypes defined by this document: plain + + Important Parameters: charset + + Encoding notes: quoted-printable generally preferred if an encoding + is needed and the character set is mostly an ASCII superset. + + Security considerations: Rich text formats such as TeX and Troff + often contain mechanisms for executing arbitrary commands or file + system operations, and should not be used automatically unless + these security problems have been addressed. Even plain text may + contain control characters that can be used to exploit the + capabilities of "intelligent" terminals and cause security + violations. User interfaces designed to run on such terminals + should be aware of and try to prevent such problems. + + ________________________________________________________ + Content-type: multipart + + Subtypes defined by this document: mixed, alternative, + digest, parallel. + + Important Parameters: boundary + + Encoding notes: No content-transfer-encoding is permitted. + + ________________________________________________________ + Content-type: message + + Subtypes defined by this document: rfc822, partial, external-body + + Important Parameters: id, number, total, access-type, expiration, + size, permission, name, site, directory, mode, server, subject + + Encoding notes: No content-transfer-encoding is permitted. + Specifically, only "7bit" is permitted for "message/partial" or + "message/external-body", and only "7bit", "8bit", or "binary" are + permitted for other subtypes of "message". + ______________________________________________________________ + Content-type: application + + Subtypes defined by this document: octet-stream, postscript + + Important Parameters: type, padding + + + +Borenstein & Freed [Page 74] + +RFC 1521 MIME September 1993 + + + Deprecated Parameters: name and conversions were + defined in RFC 1341. + + Encoding notes: base64 preferred for unreadable subtypes. + + Security considerations: This type is intended for the + transmission of data to be interpreted by locally-installed + programs. If used, for example, to transmit executable + binary programs or programs in general-purpose interpreted + languages, such as LISP programs or shell scripts, severe + security problems could result. Authors of mail-reading + agents are cautioned against giving their systems the power + to execute mail-based application data without carefully + considering the security implications. While it is + certainly possible to define safe application formats and + even safe interpreters for unsafe formats, each interpreter + should be evaluated separately for possible security + problems. + ________________________________________________________________ + Content-type: image + + Subtypes defined by this document: jpeg, gif + + Important Parameters: none + + Encoding notes: base64 generally preferred + ________________________________________________________________ + Content-type: audio + + Subtypes defined by this document: basic + + Important Parameters: none + + Encoding notes: base64 generally preferred + ________________________________________________________________ + Content-type: video + + Subtypes defined by this document: mpeg + + Important Parameters: none + + Encoding notes: base64 generally preferred + + + + + + + + + +Borenstein & Freed [Page 75] + +RFC 1521 MIME September 1993 + + +Appendix G -- Canonical Encoding Model + + There was some confusion, in earlier drafts of this memo, regarding + the model for when email data was to be converted to canonical form + and encoded, and in particular how this process would affect the + treatment of CRLFs, given that the representation of newlines varies + greatly from system to system. For this reason, a canonical model + for encoding is presented below. + + The process of composing a MIME entity can be modeled as being done + in a number of steps. Note that these steps are roughly similar to + those steps used in RFC 1421 and are performed for each 'innermost + level' body: + + Step 1. Creation of local form. + + The body to be transmitted is created in the system's native format. + The native character set is used, and where appropriate local end of + line conventions are used as well. The body may be a UNIX-style text + file, or a Sun raster image, or a VMS indexed file, or audio data in + a system-dependent format stored only in memory, or anything else + that corresponds to the local model for the representation of some + form of information. Fundamentally, the data is created in the + "native" form specified by the type/subtype information. + + Step 2. Conversion to canonical form. + + The entire body, including "out-of-band" information such as record + lengths and possibly file attribute information, is converted to a + universal canonical form. The specific content type of the body as + well as its associated attributes dictate the nature of the canonical + form that is used. Conversion to the proper canonical form may + involve character set conversion, transformation of audio data, + compression, or various other operations specific to the various + content types. If character set conversion is involved, however, + care must be taken to understand the semantics of the content-type, + which may have strong implications for any character set conversion, + e.g. with regard to syntactically meaningful characters in a text + subtype other than "plain". + + For example, in the case of text/plain data, the text must be + converted to a supported character set and lines must be delimited + with CRLF delimiters in accordance with RFC822. Note that the + restriction on line lengths implied by RFC822 is eliminated if the + next step employs either quoted-printable or base64 encoding. + + + + + + +Borenstein & Freed [Page 76] + +RFC 1521 MIME September 1993 + + + Step 3. Apply transfer encoding. + + A Content-Transfer-Encoding appropriate for this body is applied. + Note that there is no fixed relationship between the content type and + the transfer encoding. In particular, it may be appropriate to base + the choice of base64 or quoted-printable on character frequency + counts which are specific to a given instance of a body. + + Step 4. Insertion into entity. + + The encoded object is inserted into a MIME entity with appropriate + headers. The entity is then inserted into the body of a higher-level + entity (message or multipart) if needed. + + It is vital to note that these steps are only a model; they are + specifically NOT a blueprint for how an actual system would be built. + In particular, the model fails to account for two common designs: + + 1. In many cases the conversion to a canonical form prior to + encoding will be subsumed into the encoder itself, which + understands local formats directly. For example, the local + newline convention for text bodies might be carried through to the + encoder itself along with knowledge of what that format is. + + 2. The output of the encoders may have to pass through one or + more additional steps prior to being transmitted as a message. As + such, the output of the encoder may not be conformant with the + formats specified by RFC822. In particular, once again it may be + appropriate for the converter's output to be expressed using local + newline conventions rather than using the standard RFC822 CRLF + delimiters. + + Other implementation variations are conceivable as well. The vital + aspect of this discussion is that, in spite of any optimizations, + collapsings of required steps, or insertion of additional processing, + the resulting messages must be consistent with those produced by the + model described here. For example, a message with the following + header fields: + + Content-type: text/foo; charset=bar + Content-Transfer-Encoding: base64 + + must be first represented in the text/foo form, then (if necessary) + represented in the "bar" character set, and finally transformed via + the base64 algorithm into a mail-safe form. + + + + + + +Borenstein & Freed [Page 77] + +RFC 1521 MIME September 1993 + + +Appendix H -- Changes from RFC 1341 + + This document is a relatively minor revision of RFC 1341. For + the convenience of those familiar with RFC 1341, the technical + changes from that document are summarized in this appendix. + + 1. The definition of "tspecials" has been changed to no longer + include ".". + + 2. The Content-ID field is now mandatory for message/external-body + parts. + + 3. The text/richtext type (including the old Section 7.1.3 and + Appendix D) has been moved to a separate document. + + 4. The rules on header merging for message/partial data have been + changed to treat the Encrypted and MIME-Version headers as special + cases. + + 5. The definition of the external-body access-type parameter has + been changed so that it can only indicate a single access method + (which was all that made sense). + + 6. There is a new "Subject" parameter for message/external-body, + access-type mail-server, to permit MIME-based use of mail servers + that rely on Subject field information. + + 7. The "conversions" parameter for application/octet-stream has been + removed. + + 8. Section 7.4.1 now deprecates the use of the "name" parameter for + application/octet-stream, as this will be superseded in the future by + a Content-Disposition header. + + 9. The formal grammar for multipart bodies has been changed so that + a CRLF is no longer required before the first boundary line. + + 10. MIME entities of type "message/partial" and "message/external- + body" are now required to use only the "7bit" transfer-encoding. + (Specifically, "binary" and "8bit" are not permitted.) + + 11. The "application/oda" content-type has been removed. + + 12. A note has been added to the end of section 7.2.3, explaining + the semantics of Content-ID in a multipart/alternative MIME entity. + + 13. The formal syntax for the "MIME-Version" field has been + tightened, but in a way that is completely compatible with the only + + + +Borenstein & Freed [Page 78] + +RFC 1521 MIME September 1993 + + + version number defined in RFC 1341. + + 14. In Section 7.3.1, the definition of message/rfc822 has been + relaxed regarding mandatory fields. + + All other changes from RFC 1341 were editorial changes and do not + affect the technical content of MIME. Considerable formal grammar + has been added, but this reflects the prose specification that was + already in place. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Borenstein & Freed [Page 79] + +RFC 1521 MIME September 1993 + + +References + + [US-ASCII] Coded Character Set--7-Bit American Standard Code for + Information Interchange, ANSI X3.4-1986. + + [ATK] Borenstein, Nathaniel S., Multimedia Applications Development + with the Andrew Toolkit, Prentice-Hall, 1990. + + [GIF] Graphics Interchange Format (Version 89a), Compuserve, Inc., + Columbus, Ohio, 1990. + + [ISO-2022] International Standard--Information Processing--ISO 7-bit + and 8-bit coded character sets--Code extension techniques, ISO + 2022:1986. + + [ISO-8859] Information Processing -- 8-bit Single-Byte Coded Graphic + Character Sets -- Part 1: Latin Alphabet No. 1, ISO 8859-1:1987. Part + 2: Latin alphabet No. 2, ISO 8859-2, 1987. Part 3: Latin alphabet + No. 3, ISO 8859-3, 1988. Part 4: Latin alphabet No. 4, ISO 8859-4, + 1988. Part 5: Latin/Cyrillic alphabet, ISO 8859-5, 1988. Part 6: + Latin/Arabic alphabet, ISO 8859-6, 1987. Part 7: Latin/Greek + alphabet, ISO 8859-7, 1987. Part 8: Latin/Hebrew alphabet, ISO + 8859-8, 1988. Part 9: Latin alphabet No. 5, ISO 8859-9, 1990. + + [ISO-646] International Standard--Information Processing--ISO 7-bit + coded character set for information interchange, ISO 646:1983. + + [MPEG] Video Coding Draft Standard ISO 11172 CD, ISO IEC/TJC1/SC2/WG11 + (Motion Picture Experts Group), May, 1991. + + [PCM] CCITT, Fascicle III.4 - Recommendation G.711, Geneva, 1972, + "Pulse Code Modulation (PCM) of Voice Frequencies". + + [POSTSCRIPT] Adobe Systems, Inc., PostScript Language Reference + Manual, Addison-Wesley, 1985. + + [POSTSCRIPT2] Adobe Systems, Inc., PostScript Language Reference + Manual, Addison-Wesley, Second Edition, 1990. + + [X400] Schicker, Pietro, "Message Handling Systems, X.400", Message + Handling Systems and Distributed Applications, E. Stefferud, O-j. + Jacobsen, and P. Schicker, eds., North-Holland, 1989, pp. 3-41. + + [RFC-783] Sollins, K., "TFTP Protocol (revision 2)", RFC 783, MIT, + June 1981. + + [RFC-821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC + 821, USC/Information Sciences Institute, August 1982. + + + +Borenstein & Freed [Page 80] + +RFC 1521 MIME September 1993 + + + [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text + Messages", STD 11, RFC 822, UDEL, August 1982. + + [RFC-934] Rose, M., and E. Stefferud, "Proposed Standard for Message + Encapsulation", RFC 934, Delaware and NMA, January 1985. + + [RFC-959] Postel, J. and J. Reynolds, "File Transfer Protocol", + STD 9, RFC 959, USC/Information Sciences Institute, October 1985. + + [RFC-1049] Sirbu, M., "Content-Type Header Field for Internet + Messages", STD 11, RFC 1049, CMU, March 1988. + + [RFC-1421] Linn, J., "Privacy Enhancement for Internet Electronic Mail: + Part I - Message Encryption and Authentication Procedures", RFC + 1421, IAB IRTF PSRG, IETF PEM WG, February 1993. + + [RFC-1154] Robinson, D. and R. Ullmann, "Encoding Header Field for + Internet Messages", RFC 1154, Prime Computer, Inc., April 1990. + + [RFC-1341] Borenstein, N., and N. Freed, "MIME (Multipurpose Internet + Mail Extensions): Mechanisms for Specifying and Describing the Format + of Internet Message Bodies", RFC 1341, Bellcore, Innosoft, June 1992. + + [RFC-1342] Moore, K., "Representation of Non-Ascii Text in Internet + Message Headers", RFC 1342, University of Tennessee, June 1992. + + [RFC-1343] Borenstein, N., "A User Agent Configuration Mechanism + for Multimedia Mail Format Information", RFC 1343, Bellcore, June + 1992. + + [RFC-1344] Borenstein, N., "Implications of MIME for Internet + Mail Gateways", RFC 1344, Bellcore, June 1992. + + [RFC-1345] Simonsen, K., "Character Mnemonics & Character Sets", + RFC 1345, Rationel Almen Planlaegning, June 1992. + + [RFC-1426] Klensin, J., (WG Chair), Freed, N., (Editor), Rose, M., + Stefferud, E., and D. Crocker, "SMTP Service Extension for 8bit-MIME + transport", RFC 1426, United Nations Universit, Innosoft, Dover Beach + Consulting, Inc., Network Management Associates, Inc., The Branch + Office, February 1993. + + [RFC-1522] Moore, K., "Representation of Non-Ascii Text in Internet + Message Headers" RFC 1522, University of Tennessee, September 1993. + + [RFC-1340] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC + 1340, USC/Information Sciences Institute, July 1992. + + + + +Borenstein & Freed [Page 81] + \ No newline at end of file diff --git a/doc/devel/rfc/rfc1651.txt b/doc/devel/rfc/rfc1651.txt new file mode 100644 index 00000000..6398eab0 --- /dev/null +++ b/doc/devel/rfc/rfc1651.txt @@ -0,0 +1,619 @@ + + + + + + +Network Working Group J. Klensin, WG Chair +Request for Comments: 1651 MCI +Obsoletes: 1425 N. Freed, Editor +Category: Standards Track Innosoft + M. Rose + Dover Beach Consulting, Inc. + E. Stefferud + Network Management Associates, Inc. + D. Crocker + Silicon Graphics, Inc. + July 1994 + + + SMTP Service Extensions + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +1. Abstract + + This memo defines a framework for extending the SMTP service by + defining a means whereby a server SMTP can inform a client SMTP as to + the service extensions it supports. Standard extensions to the SMTP + service are registered with the IANA. This framework does not + require modification of existing SMTP clients or servers unless the + features of the service extensions are to be requested or provided. + +2. Introduction + + The Simple Mail Transfer Protocol (SMTP) [1] has provided a stable, + effective basis for the relay function of message transfer agents. + Although a decade old, SMTP has proven remarkably resilient. + Nevertheless, the need for a number of protocol extensions has become + evident. Rather than describing these extensions as separate and + haphazard entities, this document enhances SMTP in a straightforward + fashion that provides a framework in which all future extensions can + be built in a single consistent way. + +3. Framework for SMTP Extensions + + For the purpose of service extensions to SMTP, SMTP relays a mail + object containing an envelope and a content. + + + + +Klensin, Freed, Rose, Stefferud & Crocker [Page 1] + +RFC 1651 SMTP Service Extensions July 1994 + + + (1) The SMTP envelope is straightforward, and is sent as a + series of SMTP protocol units: it consists of an + originator address (to which error reports should be + directed); a delivery mode (e.g., deliver to recipient + mailboxes); and, one or more recipient addresses. + + (2) The SMTP content is sent in the SMTP DATA protocol unit + and has two parts: the headers and the body. The headers + form a collection of field/value pairs structured + according to STD 11, RFC 822 [2], whilst the body, if + structured, is defined according to MIME [3]. The content is + textual in nature, expressed using the US-ASCII repertoire (ANSI + X3.4-1986). Although extensions (such as MIME) may relax + this restriction for the content body, the content + headers are always encoded using the US-ASCII repertoire. + The algorithm defined in [4] is used to represent header + values outside the US-ASCII repertoire, whilst still + encoding them using the US-ASCII repertoire. + + Although SMTP is widely and robustly deployed, some parts of the + Internet community might wish to extend the SMTP service. This memo + defines a means whereby both an extended SMTP client and server may + recognize each other as such and the server can inform the client as + to the service extensions that it supports. + + It must be emphasized that any extension to the SMTP service should + not be considered lightly. SMTP's strength comes primarily from its + simplicity. Experience with many protocols has shown that: + + protocols with few options tend towards ubiquity, whilst + protocols with many options tend towards obscurity. + + This means that each and every extension, regardless of its benefits, + must be carefully scrutinized with respect to its implementation, + deployment, and interoperability costs. In many cases, the cost of + extending the SMTP service will likely outweigh the benefit. + + Given this environment, the framework for the extensions described in + this memo consists of: + + (1) a new SMTP command (section 4) + + (2) a registry of SMTP service extensions (section 5) + + (3) additional parameters to the SMTP MAIL FROM and RCPT TO + commands (section 6). + + + + + +Klensin, Freed, Rose, Stefferud & Crocker [Page 2] + +RFC 1651 SMTP Service Extensions July 1994 + + +4. The EHLO command + + A client SMTP supporting SMTP service extensions should start an SMTP + session by issuing the EHLO command instead of the HELO command. If + the SMTP server supports the SMTP service extensions it will give a + successful response (see section 4.3), a failure response (see 4.4), + or an error response (4.5). If the SMTP server does not support any + SMTP service extensions it will generate an error response (see + section 4.5). + +4.1. Changes to STD 10, RFC 821 + + STD 10, RFC 821 states that the first command in an SMTP session must + be the HELO command. This requirement is hereby amended to allow a + session to start with either EHLO or HELO. + +4.2. Command syntax + + The syntax for this command, using the ABNF notation of [2], is: + + ehlo-cmd ::= "EHLO" SP domain CR LF + + If successful, the server SMTP responds with code 250. On failure, + the server SMTP responds with code 550. On error, the server SMTP + responds with one of codes 500, 501, 502, 504, or 421. + + This command is issued instead of the HELO command, and may be issued + at any time that a HELO command would be appropriate. That is, if + the EHLO command is issued, and a successful response is returned, + then a subsequent HELO or EHLO command will result in the server SMTP + replying with code 503. A client SMTP must not cache any information + returned if the EHLO command succeeds. That is, a client SMTP must + issue the EHLO command at the start of each SMTP session if + information about extended facilities is needed. + +4.3. Successful response + + If the server SMTP implements and is able to perform the EHLO + command, it will return code 250. This indicates that both the + server and client SMTP are in the initial state, that is, there is no + transaction in progress and all state tables and buffers are cleared. + + Normally, this response will be a multiline reply. Each line of the + response contains a keyword and, optionally, one or more parameters. + The syntax for a positive response, using the ABNF notation of [2], + is: + + + + + +Klensin, Freed, Rose, Stefferud & Crocker [Page 3] + +RFC 1651 SMTP Service Extensions July 1994 + + + ehlo-ok-rsp ::= "250" domain [ SP greeting ] CR LF + / ( "250-" domain [ SP greeting ] CR LF + *( "250-" ehlo-line CR LF ) + "250" SP ehlo-line CR LF ) + + ; the usual HELO chit-chat + greeting ::= 1* + + ehlo-line ::= ehlo-keyword *( SP ehlo-param ) + + ehlo-keyword ::= (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") + + ; syntax and values depend on ehlo-keyword + ehlo-param ::= 1* + + ALPHA ::= + DIGIT ::= + + CR ::= + LF ::= + SP ::= + + Although EHLO keywords may be specified in upper, lower, or mixed + case, they must always be recognized and processed in a case- + insensitive manner. This is simply an extension of practices begun in + RFC 821. + + The IANA maintains a registry of standard SMTP service extensions. + Associated with each such extension is a corresponding EHLO keyword + value. Each service extension registered with the IANA is defined by + a standards-track RFC, and such a definition includes: + + (1) the textual name of the SMTP service extension; + + (2) the EHLO keyword value associated with the extension; + + (3) the syntax and possible values of parameters associated + with the EHLO keyword value; + + + + + +Klensin, Freed, Rose, Stefferud & Crocker [Page 4] + +RFC 1651 SMTP Service Extensions July 1994 + + + (4) any additional SMTP verbs associated with the extension + (additional verbs will usually be, but are not required + to be, the same as the EHLO keyword value); + + (5) any new parameters the extension associates with the MAIL + FROM or RCPT TO verbs; and, + + (6) how support for the extension affects the behavior of a + server and client SMTP. + + In addition, any EHLO keyword value that starts with an upper or + lower case "X" refers to a local SMTP service extension, which is + used through bilateral, rather than standardized, agreement. Keywords + beginning with "X" may not be used in a registered service extension. + + Any keyword values presented in the EHLO response that do not begin + with "X" must correspond to a standard or standards-track SMTP + service extension registered with IANA. A conforming server must not + offer non "X" prefixed keyword values that are not described in a + registered and standardized extension. + + Additional verbs are bound by the same rules as EHLO keywords; + specifically, verbs begining with "X" are local extensions that may + not be standardized and verbs not beginning with "X" must always be + registered. + +4.4. Failure response + + If for some reason the server SMTP is unable to list the service + extensions it supports, it will return code 554. + + In the case of a failure response, the client SMTP should issue + either the HELO or QUIT command. + +4.5. Error responses from extended servers + + If the server SMTP recognizes the EHLO command, but the command + argument is unacceptable, it will return code 501. + + If the server SMTP recognizes, but does not implement, the EHLO + command, it will return code 502. + + If the server SMTP determines that the SMTP service is no longer + available (e.g., due to imminent system shutdown), it will return + code 421. + + In the case of any error response, the client SMTP should issue + either the HELO or QUIT command. + + + +Klensin, Freed, Rose, Stefferud & Crocker [Page 5] + +RFC 1651 SMTP Service Extensions July 1994 + + +4.6. Responses from servers without extensions + + A server SMTP that conforms to RFC 821 but does not support the + extensions specified here will not recognize the EHLO command and + will consequently return code 500, as specified in RFC 821. The + server SMTP should stay in the same state after returning this code + (see section 4.1.1 of RFC 821). The client SMTP may then issue + either a HELO or a QUIT command. + +4.7. Responses from improperly implemented servers + + Some SMTP servers are known to disconnect the SMTP transmission + channel upon receipt of the EHLO command. The disconnect can occur + immediately or after sending a response. Such behavior violates + section 4.1.1 of RFC 821, which explicitly states that disconnection + should only occur after a QUIT command is issued. + + Nevertheless, in order to achieve maxmimum interoperablity it is + suggested that extended SMTP clients using EHLO be coded to check for + server connection closure after EHLO is sent, either before or after + returning a reply. If this happens the client must decide if the + operation can be successfully completed without using any SMTP + extensions. If it can a new connection can be opened and the HELO + command can be used. + + Other improperly-implemented servers will not accept a HELO command + after EHLO has been sent and rejected. In some cases, this problem + can be worked around by sending a RSET after the failure response to + EHLO, then sending the HELO. Clients that do this should be aware + that many implementations will return a failure code (e.g., 503 Bad + sequence of commands) in response to the RSET. This code can be + safely ignored. + +5. Initial IANA Registry + + The IANA's initial registry of SMTP service extensions consists of + these entries: + + Service Ext EHLO Keyword Parameters Verb Added Behavior + ------------- ------------ ---------- ---------- ------------------ + Send SEND none SEND defined in RFC 821 + Send or Mail SOML none SOML defined in RFC 821 + Send and Mail SAML none SAML defined in RFC 821 + Expand EXPN none EXPN defined in RFC 821 + Help HELP none HELP defined in RFC 821 + Turn TURN none TURN defined in RFC 821 + + + + + +Klensin, Freed, Rose, Stefferud & Crocker [Page 6] + +RFC 1651 SMTP Service Extensions July 1994 + + + which correspond to those SMTP commands which are defined as optional + in [5]. (The mandatory SMTP commands, according to [5], are HELO, + MAIL, RCPT, DATA, RSET, VRFY, NOOP, and QUIT.) + +6. MAIL FROM and RCPT TO Parameters + + It is recognized that several of the extensions planned for SMTP will + make use of additional parameters associated with the MAIL FROM and + RCPT TO command. The syntax for these commands, again using the ABNF + notation of [2] as well as underlying definitions from [1], is: + + esmtp-cmd ::= inner-esmtp-cmd [SP esmtp-parameters] CR LF + esmtp-parameters ::= esmtp-parameter *(SP esmtp-parameter) + esmtp-parameter ::= esmtp-keyword ["=" esmtp-value] + esmtp-keyword ::= (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") + + ; syntax and values depend on esmtp-keyword + esmtp-value ::= 1*") / + ("RCPT TO:<" forward-path ">") + + All esmtp-keyword values must be registered as part of the IANA + registration process described above. This definition only provides + the framework for future extension; no extended MAIL FROM or RCPT TO + parameters are defined by this RFC. + +6.1. Error responses + + If the server SMTP does not recognize or cannot implement one or more + of the parameters associated with a particular MAIL FROM or RCPT TO + command, it will return code 555. + + If for some reason the server is temporarily unable to accomodate one + or more of the parameters associated with a MAIL FROM or RCPT TO + command, and if the definition of the specific parameter does not + mandate the use of another code, it should return code 455. + + Errors specific to particular parameters and their values will be + specified in the parameter's defining RFC. + + + + + + + +Klensin, Freed, Rose, Stefferud & Crocker [Page 7] + +RFC 1651 SMTP Service Extensions July 1994 + + +7. Received: Header Field Annotation + + SMTP servers are required to add an appropriate Received: field to + the headers of all messages they receive. A "with ESMTP" clause + should be added to this field when any SMTP service extensions are + used. "ESMTP" is hereby added to the list of standard protocol names + registered with IANA. + +8. Usage Examples + + (1) An interaction of the form: + + S: + C: + S: 220 dbc.mtview.ca.us SMTP service ready + C: EHLO ymir.claremont.edu + S: 250 dbc.mtview.ca.us says hello + ... + + indicates that the server SMTP implements only those SMTP + commands which are defined as mandatory in [5]. + + + (2) In contrast, an interaction of the form: + + S: + C: + S: 220 dbc.mtview.ca.us SMTP service ready + C: EHLO ymir.claremont.edu + S: 250-dbc.mtview.ca.us says hello + S: 250-EXPN + S: 250-HELP + S: 250-8BITMIME + S: 250-XONE + S: 250 XVRB + ... + + indicates that the server SMTP also implements the SMTP + EXPN and HELP commands, one standard service extension + (8BITMIME), and two non-standard service extensions (XONE + and XVRB). + + + (3) Finally, a server that does not support SMTP service + extensions would act as follows: + + S: + C: + + + +Klensin, Freed, Rose, Stefferud & Crocker [Page 8] + +RFC 1651 SMTP Service Extensions July 1994 + + + S: 220 dbc.mtview.ca.us SMTP service ready + C: EHLO ymir.claremont.edu + S: 500 Command not recognized: EHLO + ... + + The 500 response indicates that the server SMTP does not + implement the extensions specified here. The client + would normally send a HELO command and proceed as + specified in RFC 821. See section 4.7 for additional + discussion. + +9. Security Considerations + + This RFC does not discuss security issues and is not believed to + raise any security issues not already endemic in electronic mail and + present in fully conforming implementations of RFC-821. It does + provide an announcement of server mail capabilities via the response + to the EHLO verb. However, all information provided by announcement + of any of the initial set of service extensions defined by this RFC + can be readily deduced by selective probing of the verbs required to + transport and deliver mail. The security implications of service + extensions described in other RFCs should be dealt with in those + RFCs. + +10. Acknowledgements + + This document represents a synthesis of the ideas of many people and + reactions to the ideas and proposals of others. Randall Atkinson, + Craig Everhart, Risto Kankkunen, and Greg Vaudreuil contributed ideas + and text sufficient to be considered co-authors. Other important + suggestions, text, or encouragement came from Harald Alvestrand, Jim + Conklin, Mark Crispin, Frank da Cruz, 'Olafur Gudmundsson, Per + Hedeland, Christian Huitma, Neil Katin, Eliot Lear, Harold A. + Miller, Dan Oscarsson, Julian Onions, Rayan Zachariassen, and the + contributions of the entire IETF SMTP Working Group. Of course, none + of the individuals are necessarily responsible for the combination of + ideas represented here. Indeed, in some cases, the response to a + particular criticism was to accept the problem identification but to + include an entirely different solution from the one originally + proposed. + +11. References + + [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, + USC/Information Sciences Institute, August 1982. + + [2] Crocker, D., "Standard for the Format of ARPA Internet Text + Messages", STD 11, RFC 822, UDEL, August 1982. + + + +Klensin, Freed, Rose, Stefferud & Crocker [Page 9] + +RFC 1651 SMTP Service Extensions July 1994 + + + [3] Borenstein, N., and N. Freed, "Multipurpose Internet Mail + Extensions", RFC 1521, Bellcore, Innosoft, September 1993. + + [4] Moore, K., "Representation of Non-ASCII Text in Internet Message + Headers", RFC 1522, University of Tennessee, September 1993. + + [5] Braden, R., "Requirements for Internet Hosts - Application and + Support", STD 3, RFC 1123, USC/Information Sciences Institute, + October 1989. + +12. Chair, Editor, and Authors' Addresses + + John Klensin, WG Chair + MCI Data Services Division + 2100 Reston Parkway, 6th floor + Reston, VA 22091 + USA + + Phone:: 1 703 715 7361 + Fax: +1 703 715 7435 + EMail: klensin@mci.net + + + Ned Freed, Editor + Innosoft International, Inc. + 1050 East Garvey Avenue South + West Covina, CA 91790 + USA + + Phone:: +1 818 919 3600 + Fax: +1 818 919 3614 + EMail: ned@innosoft.com + + + Marshall T. Rose + Dover Beach Consulting, Inc. + 420 Whisman Court + Moutain View, CA 94043-2186 + USA + + Phone: +1 415 968 1052 + Fax: +1 415 968 2510 + EMail: mrose@dbc.mtview.ca.us + + + + + + + + +Klensin, Freed, Rose, Stefferud & Crocker [Page 10] + +RFC 1651 SMTP Service Extensions July 1994 + + + Einar A. Stefferud + Network Management Associates, Inc. + 17301 Drey Lane + Huntington Beach, CA, 92647-5615 + USA + + Phone: +1 714 842 3711 + Fax: +1 714 848 2091 + EMail: stef@nma.com + + + Dave Crocker + Silicon Graphics, Inc. + 2011 N. Shoreline Blvd. + P.O. Box 7311 + Mountain View, CA 94039 + USA + + Phone: +1 415 390 1804 + Fax: +1 415 962 8404 + EMail: dcrocker@sgi.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Klensin, Freed, Rose, Stefferud & Crocker [Page 11] + diff --git a/doc/devel/rfc/rfc1869.txt b/doc/devel/rfc/rfc1869.txt new file mode 100644 index 00000000..cd3506ec --- /dev/null +++ b/doc/devel/rfc/rfc1869.txt @@ -0,0 +1,619 @@ + + + + + + +Network Working Group J. Klensin, WG Chair +Request For Comments: 1869 MCI +STD: 10 N. Freed, Editor +Obsoletes: 1651 Innosoft International, Inc. +Category: Standards Track M. Rose + Dover Beach Consulting, Inc. + E. Stefferud + Network Management Associates, Inc. + D. Crocker + Brandenburg Consulting + November 1995 + + + SMTP Service Extensions + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +1. Abstract + + This memo defines a framework for extending the SMTP service by + defining a means whereby a server SMTP can inform a client SMTP as to + the service extensions it supports. Extensions to the SMTP service + are registered with the IANA. This framework does not require + modification of existing SMTP clients or servers unless the features + of the service extensions are to be requested or provided. + +2. Introduction + + The Simple Mail Transfer Protocol (SMTP) [1] has provided a stable, + effective basis for the relay function of message transfer agents. + Although a decade old, SMTP has proven remarkably resilient. + Nevertheless, the need for a number of protocol extensions has become + evident. Rather than describing these extensions as separate and + haphazard entities, this document enhances SMTP in a straightforward + fashion that provides a framework in which all future extensions can + be built in a single consistent way. + +3. Framework for SMTP Extensions + + For the purpose of service extensions to SMTP, SMTP relays a mail + object containing an envelope and a content. + + + + +Klensin, et al Standards Track [Page 1] + +RFC 1869 SMTP Service Extensions November 1995 + + + (1) The SMTP envelope is straightforward, and is sent as a + series of SMTP protocol units: it consists of an + originator address (to which error reports should be + directed); a delivery mode (e.g., deliver to recipient + mailboxes); and, one or more recipient addresses. + + (2) The SMTP content is sent in the SMTP DATA protocol unit + and has two parts: the headers and the body. The + headers form a collection of field/value pairs + structured according to RFC 822 [2], whilst the body, + if structured, is defined according to MIME [3]. The + content is textual in nature, expressed using the US + ASCII repertoire (ANSI X3.4-1986). Although extensions + (such as MIME) may relax this restriction for the + content body, the content headers are always encoded + using the US ASCII repertoire. The algorithm defined in + [4] is used to represent header values outside the US + ASCII repertoire, whilst still encoding them using the + US ASCII repertoire. + + Although SMTP is widely and robustly deployed, some parts of the + Internet community might wish to extend the SMTP service. This memo + defines a means whereby both an extended SMTP client and server may + recognize each other as such and the server can inform the client as + to the service extensions that it supports. + + It must be emphasized that any extension to the SMTP service should + not be considered lightly. SMTP's strength comes primarily from its + simplicity. Experience with many protocols has shown that: + + protocols with few options tend towards ubiquity, whilst + protocols with many options tend towards obscurity. + + This means that each and every extension, regardless of its benefits, + must be carefully scrutinized with respect to its implementation, + deployment, and interoperability costs. In many cases, the cost of + extending the SMTP service will likely outweigh the benefit. + + Given this environment, the framework for the extensions described in + this memo consists of: + + (1) a new SMTP command (section 4) + + (2) a registry of SMTP service extensions (section 5) + + (3) additional parameters to the SMTP MAIL FROM and RCPT TO + commands (section 6). + + + + +Klensin, et al Standards Track [Page 2] + +RFC 1869 SMTP Service Extensions November 1995 + + +4. The EHLO command + + A client SMTP supporting SMTP service extensions should start an SMTP + session by issuing the EHLO command instead of the HELO command. If + the SMTP server supports the SMTP service extensions it will give a + successful response (see section 4.3), a failure response (see 4.4), + or an error response (4.5). If the SMTP server does not support any + SMTP service extensions it will generate an error response (see + section 4.5). + +4.1. Changes to STD 10, RFC 821 + + This specification is intended to extend STD 10, RFC 821 without + impacting existing services in any way. The minor changes needed are + enumerated below. + +4.1.1. First command + + RFC 821 states that the first command in an SMTP session must be the + HELO command. This requirement is hereby amended to allow a session + to start with either EHLO or HELO. + +4.1.2. Maximum command line length + + This specification extends the SMTP MAIL FROM and RCPT TO to allow + additional parameters and parameter values. It is possible that the + MAIL FROM and RCPT TO lines that result will exceed the 512 character + limit on command line length imposed by RFC 821. This limit is + hereby amended to only apply to command lines without any parameters. + Each specification that defines new MAIL FROM or RCPT TO parameters + must also specify maximum parameter value lengths for each parameter + so that implementors of some set of extensions know how much buffer + space must be allocated. The maximum command length that must be + supported by an SMTP implementation with extensions is 512 plus the + sum of all the maximum parameter lengths for all the extensions + supported. + +4.2. Command syntax + + The syntax for this command, using the ABNF notation of [2], is: + + ehlo-cmd ::= "EHLO" SP domain CR LF + + If successful, the server SMTP responds with code 250. On failure, + the server SMTP responds with code 550. On error, the server SMTP + responds with one of codes 500, 501, 502, 504, or 421. + + + + + +Klensin, et al Standards Track [Page 3] + +RFC 1869 SMTP Service Extensions November 1995 + + + This command is issued instead of the HELO command, and may be issued + at any time that a HELO command would be appropriate. That is, if + the EHLO command is issued, and a successful response is returned, + then a subsequent HELO or EHLO command will result in the server SMTP + replying with code 503. A client SMTP must not cache any information + returned if the EHLO command succeeds. That is, a client SMTP must + issue the EHLO command at the start of each SMTP session if + information about extended facilities is needed. + +4.3. Successful response + + If the server SMTP implements and is able to perform the EHLO + command, it will return code 250. This indicates that both the + server and client SMTP are in the initial state, that is, there is no + transaction in progress and all state tables and buffers are cleared. + + Normally, this response will be a multiline reply. Each line of the + response contains a keyword and, optionally, one or more parameters. + The syntax for a positive response, using the ABNF notation of [2], + is: + + ehlo-ok-rsp ::= "250" domain [ SP greeting ] CR LF + / ( "250-" domain [ SP greeting ] CR LF + *( "250-" ehlo-line CR LF ) + "250" SP ehlo-line CR LF ) + + ; the usual HELO chit-chat + greeting ::= 1* + + ehlo-line ::= ehlo-keyword *( SP ehlo-param ) + + ehlo-keyword ::= (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") + + ; syntax and values depend on ehlo-keyword + ehlo-param ::= 1* + + ALPHA ::= + DIGIT ::= + + CR ::= + LF ::= + + + +Klensin, et al Standards Track [Page 4] + +RFC 1869 SMTP Service Extensions November 1995 + + + SP ::= + + Although EHLO keywords may be specified in upper, lower, or mixed + case, they must always be recognized and processed in a case- + insensitive manner. This is simply an extension of practices begun in + RFC 821. + + The IANA maintains a registry of SMTP service extensions. Associated + with each such extension is a corresponding EHLO keyword value. Each + service extension registered with the IANA must be defined in an RFC. + Such RFCs must either be on the standards-track or must define an + IESG-approved experimental protocol. The definition must include: + + (1) the textual name of the SMTP service extension; + + (2) the EHLO keyword value associated with the extension; + + (3) the syntax and possible values of parameters associated + with the EHLO keyword value; + + (4) any additional SMTP verbs associated with the extension + (additional verbs will usually be, but are not required + to be, the same as the EHLO keyword value); + + (5) any new parameters the extension associates with the + MAIL FROM or RCPT TO verbs; + + (6) how support for the extension affects the behavior of a + server and client SMTP; and, + + (7) the increment by which the extension is increasing the + maximum length of the commands MAIL FROM, RCPT TO, or + both, over that specified in RFC 821. + + In addition, any EHLO keyword value that starts with an upper or + lower case "X" refers to a local SMTP service extension, which is + used through bilateral, rather than standardized, agreement. Keywords + beginning with "X" may not be used in a registered service extension. + + Any keyword values presented in the EHLO response that do not begin + with "X" must correspond to a standard, standards-track, or IESG- + approved experimental SMTP service extension registered with IANA. A + conforming server must not offer non "X" prefixed keyword values that + are not described in a registered extension. + + + + + + +Klensin, et al Standards Track [Page 5] + +RFC 1869 SMTP Service Extensions November 1995 + + + Additional verbs are bound by the same rules as EHLO keywords; + specifically, verbs begining with "X" are local extensions that may + not be registered or standardized and verbs not beginning with "X" + must always be registered. + +4.4. Failure response + + If for some reason the server SMTP is unable to list the service + extensions it supports, it will return code 554. + + In the case of a failure response, the client SMTP should issue + either the HELO or QUIT command. + +4.5. Error responses from extended servers + + If the server SMTP recognizes the EHLO command, but the command + argument is unacceptable, it will return code 501. + + If the server SMTP recognizes, but does not implement, the EHLO + command, it will return code 502. + + If the server SMTP determines that the SMTP service is no longer + available (e.g., due to imminent system shutdown), it will return + code 421. + + In the case of any error response, the client SMTP should issue + either the HELO or QUIT command. + +4.6. Responses from servers without extensions + + A server SMTP that conforms to RFC 821 but does not support the + extensions specified here will not recognize the EHLO command and + will consequently return code 500, as specified in RFC 821. The + server SMTP should stay in the same state after returning this code + (see section 4.1.1 of RFC 821). The client SMTP may then issue + either a HELO or a QUIT command. + +4.7. Responses from improperly implemented servers + + Some SMTP servers are known to disconnect the SMTP transmission + channel upon receipt of the EHLO command. The disconnect can occur + immediately or after sending a response. Such behavior violates + section 4.1.1 of RFC 821, which explicitly states that disconnection + should only occur after a QUIT command is issued. + + Nevertheless, in order to achieve maxmimum interoperablity it is + suggested that extended SMTP clients using EHLO be coded to check for + server connection closure after EHLO is sent, either before or after + + + +Klensin, et al Standards Track [Page 6] + +RFC 1869 SMTP Service Extensions November 1995 + + + returning a reply. If this happens the client must decide if the + operation can be successfully completed without using any SMTP + extensions. If it can a new connection can be opened and the HELO + command can be used. + + Other improperly-implemented servers will not accept a HELO command + after EHLO has been sent and rejected. In some cases, this problem + can be worked around by sending a RSET after the failure response to + EHLO, then sending the HELO. Clients that do this should be aware + that many implementations will return a failure code (e.g., 503 Bad + sequence of commands) in response to the RSET. This code can be + safely ignored. + +5. Initial IANA Registry + + The IANA's initial registry of SMTP service extensions consists of + these entries: + + Service Ext EHLO Keyword Parameters Verb Added Behavior + ------------- ------------ ---------- ---------- ------------------ + Send SEND none SEND defined in RFC 821 + Send or Mail SOML none SOML defined in RFC 821 + Send and Mail SAML none SAML defined in RFC 821 + Expand EXPN none EXPN defined in RFC 821 + Help HELP none HELP defined in RFC 821 + Turn TURN none TURN defined in RFC 821 + + which correspond to those SMTP commands which are defined as optional + in [5]. (The mandatory SMTP commands, according to [5], are HELO, + MAIL, RCPT, DATA, RSET, VRFY, NOOP, and QUIT.) + +6. MAIL FROM and RCPT TO Parameters + + It is recognized that several of the extensions planned for SMTP will + make use of additional parameters associated with the MAIL FROM and + RCPT TO command. The syntax for these commands, again using the ABNF + notation of [2] as well as underlying definitions from [1], is: + + esmtp-cmd ::= inner-esmtp-cmd [SP esmtp-parameters] CR LF + esmtp-parameters ::= esmtp-parameter *(SP esmtp-parameter) + esmtp-parameter ::= esmtp-keyword ["=" esmtp-value] + esmtp-keyword ::= (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") + + ; syntax and values depend on esmtp-keyword + esmtp-value ::= 1* + C: + S: 220 dbc.mtview.ca.us SMTP service ready + C: EHLO ymir.claremont.edu + S: 250 dbc.mtview.ca.us says hello + ... + + indicates that the server SMTP implements only those + SMTP commands which are defined as mandatory in [5]. + + + + + + +Klensin, et al Standards Track [Page 8] + +RFC 1869 SMTP Service Extensions November 1995 + + + (2) In contrast, an interaction of the form: + + S: + C: + S: 220 dbc.mtview.ca.us SMTP service ready + C: EHLO ymir.claremont.edu + S: 250-dbc.mtview.ca.us says hello + S: 250-EXPN + S: 250-HELP + S: 250-8BITMIME + S: 250-XONE + S: 250 XVRB + ... + + indicates that the server SMTP also implements the SMTP + EXPN and HELP commands, one standard service extension + (8BITMIME), and two nonstandard and unregistered + service extensions (XONE and XVRB). + + (3) Finally, a server that does not support SMTP service + extensions would act as follows: + + S: + C: + S: 220 dbc.mtview.ca.us SMTP service ready + C: EHLO ymir.claremont.edu + S: 500 Command not recognized: EHLO + ... + + The 500 response indicates that the server SMTP does + not implement the extensions specified here. The + client would normally send a HELO command and proceed + as specified in RFC 821. See section 4.7 for + additional discussion. + +9. Security Considerations + + This RFC does not discuss security issues and is not believed to + raise any security issues not already endemic in electronic mail and + present in fully conforming implementations of RFC-821. It does + provide an announcement of server mail capabilities via the response + to the EHLO verb. However, all information provided by announcement + of any of the initial set of service extensions defined by this RFC + can be readily deduced by selective probing of the verbs required to + transport and deliver mail. The security implications of service + extensions described in other RFCs should be dealt with in those + RFCs. + + + + +Klensin, et al Standards Track [Page 9] + +RFC 1869 SMTP Service Extensions November 1995 + + +10. Acknowledgements + + This document represents a synthesis of the ideas of many people and + reactions to the ideas and proposals of others. Randall Atkinson, + Craig Everhart, Risto Kankkunen, and Greg Vaudreuil contributed ideas + and text sufficient to be considered co-authors. Other important + suggestions, text, or encouragement came from Harald Alvestrand, Jim + Conklin, Mark Crispin, Frank da Cruz, 'Olafur Gudmundsson, Per + Hedeland, Christian Huitma, Neil Katin, Eliot Lear, Harold A. + Miller, Keith Moore, John Myers, Dan Oscarsson, Julian Onions, Rayan + Zachariassen, and the contributions of the entire IETF SMTP Working + Group. Of course, none of the individuals are necessarily responsible + for the combination of ideas represented here. Indeed, in some cases, + the response to a particular criticism was to accept the problem + identification but to include an entirely different solution from the + one originally proposed. + +11. References + + [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, + USC/Information Sciences Institute, August 1982. + + [2] Crocker, D., "Standard for the Format of ARPA Internet Text + Messages", STD 11, RFC 822, UDEL, August 1982. + + [3] Borenstein, N., and N. Freed, "Multipurpose Internet Mail + Extensions", RFC 1521, Bellcore, Innosoft, September 1993. + + [4] Moore, K., "Representation of Non-ASCII Text in Internet Message + Headers", RFC 1522, University of Tennessee, September 1993. + + [5] Braden, R., "Requirements for Internet Hosts - Application and + Support", STD 3, RFC 1123, USC/Information Sciences Institute, + October 1989. + +12. Chair, Editor, and Author Addresses + + John Klensin, WG Chair + MCI + 2100 Reston Parkway + Reston, VA 22091 + + Phone: +1 703 715-7361 + Fax: +1 703 715-7436 + EMail: klensin@mci.net + + + + + + +Klensin, et al Standards Track [Page 10] + +RFC 1869 SMTP Service Extensions November 1995 + + + Ned Freed, Editor + Innosoft International, Inc. + 1050 East Garvey Avenue South + West Covina, CA 91790 + USA + + Phone: +1 818 919 3600 + Fax: +1 818 919 3614 + EMail: ned@innosoft.com + + + Marshall T. Rose + Dover Beach Consulting, Inc. + 420 Whisman Court + Moutain View, CA 94043-2186 + USA + + Phone: +1 415 968 1052 + Fax: +1 415 968 2510 + EMail: mrose@dbc.mtview.ca.us + + + Einar A. Stefferud + Network Management Associates, Inc. + 17301 Drey Lane + Huntington Beach, CA, 92647-5615 + USA + + Phone: +1 714 842 3711 + Fax: +1 714 848 2091 + EMail: stef@nma.com + + + Dave Crocker + Brandenburg Consulting + 675 Spruce Dr. + Sunnyvale, CA 94086 USA + USA + + Phone: +1 408 246 8253 + Fax: +1 408 249 6205 + EMail: dcrocker@mordor.stanford.edu + + + + + + + + + +Klensin, et al Standards Track [Page 11] + diff --git a/doc/devel/rfc/rfc1891.txt b/doc/devel/rfc/rfc1891.txt new file mode 100644 index 00000000..23b58ba9 --- /dev/null +++ b/doc/devel/rfc/rfc1891.txt @@ -0,0 +1,1739 @@ + + + + + + +Network Working Group K. Moore +Request for Comments: 1891 University of Tennessee +Category: Standards Track January 1996 + + + SMTP Service Extension + for Delivery Status Notifications + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +1. Abstract + + This memo defines an extension to the SMTP service, which allows an + SMTP client to specify (a) that delivery status notifications (DSNs) + should be generated under certain conditions, (b) whether such + notifications should return the contents of the message, and (c) + additional information, to be returned with a DSN, that allows the + sender to identify both the recipient(s) for which the DSN was + issued, and the transaction in which the original message was sent. + + Any questions, comments, and reports of defects or ambiguities in + this specification may be sent to the mailing list for the NOTARY + working group of the IETF, using the address + . Requests to subscribe to the mailing + list should be addressed to . + Implementors of this specification are encouraged to subscribe to the + mailing list, so that they will quickly be informed of any problems + which might hinder interoperability. + + NOTE: This document is a Proposed Standard. If and when this + protocol is submitted for Draft Standard status, any normative text + (phrases containing SHOULD, SHOULD NOT, MUST, MUST NOT, or MAY) in + this document will be re-evaluated in light of implementation + experience, and are thus subject to change. + +2. Introduction + + The SMTP protocol [1] requires that an SMTP server provide + notification of delivery failure, if it determines that a message + cannot be delivered to one or more recipients. Traditionally, such + notification consists of an ordinary Internet mail message (format + defined by [2]), sent to the envelope sender address (the argument of + + + +Moore Standards Track [Page 1] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + + the SMTP MAIL command), containing an explanation of the error and at + least the headers of the failed message. + + Experience with large mail distribution lists [3] indicates that such + messages are often insufficient to diagnose problems, or even to + determine at which host or for which recipients a problem occurred. + In addition, the lack of a standardized format for delivery + notifications in Internet mail makes it difficult to exchange such + notifications with other message handling systems. + + Such experience has demonstrated a need for a delivery status + notification service for Internet electronic mail, which: + +(a) is reliable, in the sense that any DSN request will either be + honored at the time of final delivery, or result in a response + that indicates that the request cannot be honored, + +(b) when both success and failure notifications are requested, + provides an unambiguous and nonconflicting indication of whether + delivery of a message to a recipient succeeded or failed, + +(c) is stable, in that a failed attempt to deliver a DSN should never + result in the transmission of another DSN over the network, + +(d) preserves sufficient information to allow the sender to identify + both the mail transaction and the recipient address which caused + the notification, even when mail is forwarded or gatewayed to + foreign environments, and + +(e) interfaces acceptably with non-SMTP and non-822-based mail + systems, both so that notifications returned from foreign mail + systems may be useful to Internet users, and so that the + notification requests from foreign environments may be honored. + Among the requirements implied by this goal are the ability to + request non-return-of-content, and the ability to specify whether + positive delivery notifications, negative delivery notifications, + both, or neither, should be issued. + + In an attempt to provide such a service, this memo uses the mechanism + defined in [4] to define an extension to the SMTP protocol. Using + this mechanism, an SMTP client may request that an SMTP server issue + or not issue a delivery status notification (DSN) under certain + conditions. The format of a DSN is defined in [5]. + + + + + + + + +Moore Standards Track [Page 2] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +3. Framework for the Delivery Status Notification Extension + + The following service extension is therefore defined: + +(1) The name of the SMTP service extension is "Delivery Status + Notification"; + +(2) the EHLO keyword value associated with this extension is "DSN", + the meaning of which is defined in section 4 of this memo; + +(3) no parameters are allowed with this EHLO keyword value; + +(4) two optional parameters are added to the RCPT command, and two + optional parameters are added to the MAIL command: + + An optional parameter for the RCPT command, using the + esmtp-keyword "NOTIFY", (to specify the conditions under which a + delivery status notification should be generated), is defined in + section 5.1, + + An optional parameter for the RCPT command, using the + esmtp-keyword "ORCPT", (used to convey the "original" + (sender-specified) recipient address), is defined in section 5.2, + and + + An optional parameter for the MAIL command, using the + esmtp-keyword "RET", (to request that DSNs containing an + indication of delivery failure either return the entire contents + of a message or only the message headers), is defined in section + 5.3, + + An optional parameter for the MAIL command, using the + esmtp-keyword "ENVID", (used to propagate an identifier for this + message transmission envelope, which is also known to the sender + and will, if present, be returned in any DSNs issued for this + transmission), is defined in section 5.4; + +(5) no additional SMTP verbs are defined by this extension. + + The remainder of this memo specifies how support for the extension + effects the behavior of a message transfer agent. + +4. The Delivery Status Notification service extension + + An SMTP client wishing to request a DSN for a message may issue the + EHLO command to start an SMTP session, to determine if the server + supports any of several service extensions. If the server responds + with code 250 to the EHLO command, and the response includes the EHLO + + + +Moore Standards Track [Page 3] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + + keyword DSN, then the Delivery Status Notification extension (as + described in this memo) is supported. + + Ordinarily, when an SMTP server returns a positive (2xx) reply code + in response to a RCPT command, it agrees to accept responsibility for + either delivering the message to the named recipient, or sending a + notification to the sender of the message indicating that delivery + has failed. However, an extended SMTP ("ESMTP") server which + implements this service extension will accept an optional NOTIFY + parameter with the RCPT command. If present, the NOTIFY parameter + alters the conditions for generation of delivery status notifications + from the default (issue notifications only on failure) specified in + [1]. The ESMTP client may also request (via the RET parameter) + whether the entire contents of the original message should be + returned (as opposed to just the headers of that message), along with + the DSN. + + In general, an ESMTP server which implements this service extension + will propagate delivery status notification requests when relaying + mail to other SMTP-based MTAs which also support this extension, and + make a "best effort" to ensure that such requests are honored when + messages are passed into other environments. + + In order that any delivery status notifications thus generated will + be meaningful to the sender, any ESMTP server which supports this + extension will attempt to propagate the following information to any + other MTAs that are used to relay the message, for use in generating + DSNs: + +(a) for each recipient, a copy of the original recipient address, as + used by the sender of the message. + + This address need not be the same as the mailbox specified in the + RCPT command. For example, if a message was originally addressed + to A@B.C and later forwarded to A@D.E, after such forwarding has + taken place, the RCPT command will specify a mailbox of A@D.E. + However, the original recipient address remains A@B.C. + + Also, if the message originated from an environment which does not + use Internet-style user@domain addresses, and was gatewayed into + SMTP, the original recipient address will preserve the original + form of the recipient address. + +(b) for the entire SMTP transaction, an envelope identification + string, which may be used by the sender to associate any delivery + status notifications with the transaction used to send the + original message. + + + + +Moore Standards Track [Page 4] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +5. Additional parameters for RCPT and MAIL commands + + The extended RCPT and MAIL commands are issued by a client when it + wishes to request a DSN from the server, under certain conditions, + for a particular recipient. The extended RCPT and MAIL commands are + identical to the RCPT and MAIL commands defined in [1], except that + one or more of the following parameters appear after the sender or + recipient address, respectively. The general syntax for extended + SMTP commands is defined in [4]. + + NOTE: Although RFC 822 ABNF is used to describe the syntax of these + parameters, they are not, in the language of that document, + "structured field bodies". Therefore, while parentheses MAY appear + within an emstp-value, they are not recognized as comment delimiters. + + The syntax for "esmtp-value" in [4] does not allow SP, "=", control + characters, or characters outside the traditional ASCII range of 1- + 127 decimal to be transmitted in an esmtp-value. Because the ENVID + and ORCPT parameters may need to convey values outside this range, + the esmtp-values for these parameters are encoded as "xtext". + "xtext" is formally defined as follows: + + xtext = *( xchar / hexchar ) + + xchar = any ASCII CHAR between "!" (33) and "~" (126) inclusive, + except for "+" and "=". + +; "hexchar"s are intended to encode octets that cannot appear +; as ASCII characters within an esmtp-value. + + hexchar = ASCII "+" immediately followed by two upper case + hexadecimal digits + +When encoding an octet sequence as xtext: + ++ Any ASCII CHAR between "!" and "~" inclusive, except for "+" and "=", + MAY be encoded as itself. (A CHAR in this range MAY instead be + encoded as a "hexchar", at the implementor's discretion.) + ++ ASCII CHARs that fall outside the range above must be encoded as + "hexchar". + +5.1 The NOTIFY parameter of the ESMTP RCPT command + + A RCPT command issued by a client may contain the optional esmtp- + keyword "NOTIFY", to specify the conditions under which the SMTP + server should generate DSNs for that recipient. If the NOTIFY + esmtp-keyword is used, it MUST have an associated esmtp-value, + + + +Moore Standards Track [Page 5] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + + formatted according to the following rules, using the ABNF of RFC + 822: + + notify-esmtp-value = "NEVER" / 1#notify-list-element + + notify-list-element = "SUCCESS" / "FAILURE" / "DELAY" + +Notes: + +a. Multiple notify-list-elements, separated by commas, MAY appear in a + NOTIFY parameter; however, the NEVER keyword MUST appear by itself. + +b. Any of the keywords NEVER, SUCCESS, FAILURE, or DELAY may be spelled + in any combination of upper and lower case letters. + +The meaning of the NOTIFY parameter values is generally as follows: + ++ A NOTIFY parameter value of "NEVER" requests that a DSN not be + returned to the sender under any conditions. + ++ A NOTIFY parameter value containing the "SUCCESS" or "FAILURE" + keywords requests that a DSN be issued on successful delivery or + delivery failure, respectively. + ++ A NOTIFY parameter value containing the keyword "DELAY" indicates the + sender's willingness to receive "delayed" DSNs. Delayed DSNs may be + issued if delivery of a message has been delayed for an unusual amount + of time (as determined by the MTA at which the message is delayed), + but the final delivery status (whether successful or failure) cannot + be determined. The absence of the DELAY keyword in a NOTIFY parameter + requests that a "delayed" DSN NOT be issued under any conditions. + + The actual rules governing interpretation of the NOTIFY parameter are + given in section 6. + + For compatibility with SMTP clients that do not use the NOTIFY + facility, the absence of a NOTIFY parameter in a RCPT command may be + interpreted as either NOTIFY=FAILURE or NOTIFY=FAILURE,DELAY. + +5.2 The ORCPT parameter to the ESMTP RCPT command + + The ORCPT esmtp-keyword of the RCPT command is used to specify an + "original" recipient address that corresponds to the actual recipient + to which the message is to be delivered. If the ORCPT esmtp-keyword + is used, it MUST have an associated esmtp-value, which consists of + the original recipient address, encoded according to the rules below. + The ABNF for the ORCPT parameter is: + + + + +Moore Standards Track [Page 6] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + + orcpt-parameter = "ORCPT=" original-recipient-address + + original-recipient-address = addr-type ";" xtext + + addr-type = atom + + The "addr-type" portion MUST be an IANA-registered electronic mail + address-type (as defined in [5]), while the "xtext" portion contains + an encoded representation of the original recipient address using the + rules in section 5 of this document. The entire ORCPT parameter MAY + be up to 500 characters in length. + + When initially submitting a message via SMTP, if the ORCPT parameter + is used, it MUST contain the same address as the RCPT TO address + (unlike the RCPT TO address, the ORCPT parameter will be encoded as + xtext). Likewise, when a mailing list submits a message via SMTP to + be distributed to the list subscribers, if ORCPT is used, the ORCPT + parameter MUST match the new RCPT TO address of each recipient, not + the address specified by the original sender of the message.) + + The "addr-type" portion of the original-recipient-address is used to + indicate the "type" of the address which appears in the ORCPT + parameter value. However, the address associated with the ORCPT + keyword is NOT constrained to conform to the syntax rules for that + "addr-type". + + Ideally, the "xtext" portion of the original-recipient-address should + contain, in encoded form, the same sequence of characters that the + sender used to specify the recipient. However, for a message + gatewayed from an environment (such as X.400) in which a recipient + address is not a simple string of printable characters, the + representation of recipient address must be defined by a + specification for gatewaying between DSNs and that environment. + +5.3 The RET parameter of the ESMTP MAIL command + + The RET esmtp-keyword on the extended MAIL command specifies whether + or not the message should be included in any failed DSN issued for + this message transmission. If the RET esmtp-keyword is used, it MUST + have an associated esmtp-value, which is one of the following + keywords: + + FULL requests that the entire message be returned in any "failed" + delivery status notification issued for this recipient. + + HDRS requests that only the headers of the message be returned. + + + + + +Moore Standards Track [Page 7] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + + The FULL and HDRS keywords may be spelled in any combination of upper + and lower case letters. + + If no RET parameter is supplied, the MTA MAY return either the + headers of the message or the entire message for any DSN containing + indication of failed deliveries. + + Note that the RET parameter only applies to DSNs that indicate + delivery failure for at least one recipient. If a DSN contains no + indications of delivery failure, only the headers of the message + should be returned. + +5.4 The ENVID parameter to the ESMTP MAIL command + + The ENVID esmtp-keyword of the SMTP MAIL command is used to specify + an "envelope identifier" to be transmitted along with the message and + included in any DSNs issued for any of the recipients named in this + SMTP transaction. The purpose of the envelope identifier is to allow + the sender of a message to identify the transaction for which the DSN + was issued. + + The ABNF for the ENVID parameter is: + + envid-parameter = "ENVID=" xtext + + The ENVID esmtp-keyword MUST have an associated esmtp-value. No + meaning is assigned by the mail system to the presence or absence of + this parameter or to any esmtp-value associated with this parameter; + the information is used only by the sender or his user agent. The + ENVID parameter MAY be up to 100 characters in length. + +5.5 Restrictions on the use of Delivery Status Notification parameters + + The RET and ENVID parameters MUST NOT appear more than once each in + any single MAIL command. If more than one of either of these + parameters appears in a MAIL command, the ESMTP server SHOULD respond + with "501 syntax error in parameters or arguments". + + The NOTIFY and ORCPT parameters MUST NOT appear more than once in any + RCPT command. If more than one of either of these parameters appears + in a RCPT command, the ESMTP server SHOULD respond with "501 syntax + error in parameters or arguments". + +6. Conformance requirements + + The Simple Mail Transfer Protocol (SMTP) is used by Message Transfer + Agents (MTAs) when accepting, relaying, or gatewaying mail, as well + as User Agents (UAs) when submitting mail to the mail transport + + + +Moore Standards Track [Page 8] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + + system. The DSN extension to SMTP may be used to allow UAs to convey + the sender's requests as to when DSNs should be issued. A UA which + claims to conform to this specification must meet certain + requirements as described below. + + Typically, a message transfer agent (MTA) which supports SMTP will + assume, at different times, both the role of a SMTP client and an + SMTP server, and may also provide local delivery, gatewaying to + foreign environments, forwarding, and mailing list expansion. An MTA + which, when acting as an SMTP server, issues the DSN keyword in + response to the EHLO command, MUST obey the rules below for a + "conforming SMTP client" when acting as a client, and a "conforming + SMTP server" when acting as a server. The term "conforming MTA" + refers to an MTA which conforms to this specification, independent of + its role of client or server. + +6.1 SMTP protocol interactions + + The following rules apply to SMTP transactions in which any of the + ENVID, NOTIFY, RET, or ORCPT keywords are used: + +(a) If an SMTP client issues a MAIL command containing a valid ENVID + parameter and associated esmtp-value and/or a valid RET parameter + and associated esmtp-value, a conforming SMTP server MUST return + the same reply-code as it would to the same MAIL command without + the ENVID and/or RET parameters. A conforming SMTP server MUST + NOT refuse a MAIL command based on the absence or presence of + valid ENVID or RET parameters, or on their associated + esmtp-values. + + However, if the associated esmtp-value is not valid (i.e. contains + illegal characters), or if there is more than one ENVID or RET + parameter in a particular MAIL command, the server MUST issue the + reply-code 501 with an appropriate message (e.g. "syntax error in + parameter"). + +(b) If an SMTP client issues a RCPT command containing any valid + NOTIFY and/or ORCPT parameters, a conforming SMTP server MUST + return the same response as it would to the same RCPT command + without those NOTIFY and/or ORCPT parameters. A conforming SMTP + server MUST NOT refuse a RCPT command based on the presence or + absence of any of these parameters. + + However, if any of the associated esmtp-values are not valid, or + if there is more than one of any of these parameters in a + particular RCPT command, the server SHOULD issue the response "501 + syntax error in parameter". + + + + +Moore Standards Track [Page 9] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +6.2 Handling of messages received via SMTP + + This section describes how a conforming MTA should handle any + messages received via SMTP. + + NOTE: A DSN MUST NOT be returned to the sender for any message for + which the return address from the SMTP MAIL command was NULL ("<>"), + even if the sender's address is available from other sources (e.g. + the message header). However, the MTA which would otherwise issue a + DSN SHOULD inform the local postmaster of delivery failures through + some appropriate mechanism that will not itself result in the + generation of DSNs. + + DISCUSSION: RFC 1123, section 2.3.3 requires error notifications to + be sent with a NULL return address ("reverse-path"). This creates an + interesting situation when a message arrives with one or more + nonfunctional recipient addresses in addition to a nonfunctional + return address. When delivery to one of the recipient addresses + fails, the MTA will attempt to send a nondelivery notification to the + return address, setting the return address on the notification to + NULL. When the delivery of this notification fails, the MTA + attempting delivery of that notification sees a NULL return address. + If that MTA were not to inform anyone of the situation, the original + message would be silently lost. Furthermore, a nonfunctional return + address is often indicative of a configuration problem in the + sender's MTA. Reporting the condition to the local postmaster may + help to speed correction of such errors. + +6.2.1 Relay of messages to other conforming SMTP servers + + The following rules govern the behavior of a conforming MTA, when + relaying a message which was received via the SMTP protocol, to an + SMTP server that supports the Delivery Status Notification service + extension: + +(a) Any ENVID parameter included in the MAIL command when a message was + received, MUST also appear on the MAIL command with which the + message is relayed, with the same associated esmtp-value. If no + ENVID parameter was included in the MAIL command when the message + was received, the ENVID parameter MUST NOT be supplied when the + message is relayed. + +(b) Any RET parameter included in the MAIL command when a message was + received, MUST also appear on the MAIL command with which the + message is relayed, with the same associated esmtp-value. If no RET + parameter was included in the MAIL command when the message was + received, the RET parameter MUST NOT supplied when the message is + relayed. + + + +Moore Standards Track [Page 10] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +(c) If the NOTIFY parameter was supplied for a recipient when the + message was received, the RCPT command issued when the message is + relayed MUST also contain the NOTIFY parameter along with its + associated esmtp-value. If the NOTIFY parameter was not supplied + for a recipient when the message was received, the NOTIFY parameter + MUST NOT be supplied for that recipient when the message is relayed. + +(d) If any ORCPT parameter was present in the RCPT command for a + recipient when the message was received, an ORCPT parameter with the + identical original-recipient-address MUST appear in the RCPT command + issued for that recipient when relaying the message. (For example, + the MTA therefore MUST NOT change the case of any alphabetic + characters in an ORCPT parameter.) + + If no ORCPT parameter was present in the RCPT command when the + message was received, an ORCPT parameter MAY be added to the RCPT + command when the message is relayed. If an ORCPT parameter is added + by the relaying MTA, it MUST contain the recipient address from the + RCPT command used when the message was received by that MTA. + +6.2.2 Relay of messages to non-conforming SMTP servers + + The following rules govern the behavior of a conforming MTA (in the + role of client), when relaying a message which was received via the + SMTP protocol, to an SMTP server that does not support the Delivery + Status Notification service extension: + +(a) ENVID, NOTIFY, RET, or ORCPT parameters MUST NOT be issued when + relaying the message. + +(b) If the NOTIFY parameter was supplied for a recipient, with an esmtp- + value containing the keyword SUCCESS, and the SMTP server returns a + success (2xx) reply-code in response to the RCPT command, the client + MUST issue a "relayed" DSN for that recipient. + +(c) If the NOTIFY parameter was supplied for a recipient with an esmtp- + value containing the keyword FAILURE, and the SMTP server returns a + permanent failure (5xx) reply-code in response to the RCPT command, + the client MUST issue a "failed" DSN for that recipient. + +(d) If the NOTIFY parameter was supplied for a recipient with an esmtp- + value of NEVER, the client MUST NOT issue a DSN for that recipient, + regardless of the reply-code returned by the SMTP server. However, + if the server returned a failure (5xx) reply-code, the client MAY + inform the local postmaster of the delivery failure via an + appropriate mechanism that will not itself result in the generation + of DSNs. + + + + +Moore Standards Track [Page 11] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + + When attempting to relay a message to an SMTP server that does not + support this extension, and if NOTIFY=NEVER was specified for some + recipients of that message, a conforming SMTP client MAY relay the + message for those recipients in a separate SMTP transaction, using + an empty reverse-path in the MAIL command. This will prevent DSNs + from being issued for those recipients by MTAs that conform to [1]. + +(e) If a NOTIFY parameter was not supplied for a recipient, and the SMTP + server returns a success (2xx) reply-code in response to a RCPT + command, the client MUST NOT issue any DSN for that recipient. + +(f) If a NOTIFY parameter was not supplied for a recipient, and the SMTP + server returns a permanent failure (5xx) reply-code in response to a + RCPT command, the client MUST issue a "failed" DSN for that + recipient. + +6.2.3 Local delivery of messages + + The following rules govern the behavior of a conforming MTA upon + successful delivery of a message that was received via the SMTP + protocol, to a local recipient's mailbox: + + "Delivery" means that the message has been placed in the recipient's + mailbox. For messages which are transmitted to a mailbox for later + retrieval via IMAP [6], POP [7] or a similar message access protocol, + "delivery" occurs when the message is made available to the IMAP + (POP, etc.) service, rather than when the message is retrieved by the + recipient's user agent. + + Similarly, for a recipient address which corresponds to a mailing + list exploder, "delivery" occurs when the message is made available + to that list exploder, even though the list exploder might refuse to + deliver that message to the list recipients. + +(a) If the NOTIFY parameter was supplied for that recipient, with an + esmtp-value containing the SUCCESS keyword, the MTA MUST issue a + "delivered" DSN for that recipient. + +(b) If the NOTIFY parameter was supplied for that recipient which did + not contain the SUCCESS keyword, the MTA MUST NOT issue a DSN for + that recipient. + +(c) If the NOTIFY parameter was not supplied for that recipient, the MTA + MUST NOT issue a DSN. + + + + + + + +Moore Standards Track [Page 12] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +6.2.4 Gatewaying a message into a foreign environment + + The following rules govern the behavior of a conforming MTA, when + gatewaying a message that was received via the SMTP protocol, into a + foreign (non-SMTP) environment: + +(a) If the the foreign environment is capable of issuing appropriate + notifications under the conditions requested by the NOTIFY + parameter, and the conforming MTA can ensure that any notification + thus issued will be translated into a DSN and delivered to the + original sender, then the MTA SHOULD gateway the message into the + foreign environment, requesting notification under the desired + conditions, without itself issuing a DSN. + +(b) If a NOTIFY parameter was supplied with the SUCCESS keyword, but the + destination environment cannot return an appropriate notification on + successful delivery, the MTA SHOULD issue a "relayed" DSN for that + recipient. + +(c) If a NOTIFY parameter was supplied with an esmtp-keyword of NEVER, a + DSN MUST NOT be issued. If possible, the MTA SHOULD direct the + destination environment to not issue delivery notifications for that + recipient. + +(d) If the NOTIFY parameter was not supplied for a particular recipient, + a DSN SHOULD NOT be issued by the gateway. The gateway SHOULD + attempt to ensure that appropriate notification will be provided by + the foreign mail environment if eventual delivery failure occurs, + and that no notification will be issued on successful delivery. + +(e) When gatewaying a message into a foreign environment, the return-of- + content conditions specified by any RET parameter are nonbinding; + however, the MTA SHOULD attempt to honor the request using whatever + mechanisms exist in the foreign environment. + +6.2.5 Delays in delivery + + If a conforming MTA receives a message via the SMTP protocol, and is + unable to deliver or relay the message to one or more recipients for + an extended length of time (to be determined by the MTA), it MAY + issue a "delayed" DSN for those recipients, subject to the following + conditions: + +(a) If the NOTIFY parameter was supplied for a recipient and its value + included the DELAY keyword, a "delayed" DSN MAY be issued. + +(b) If the NOTIFY parameter was not supplied for a recipient, a + "delayed" DSN MAY be issued. + + + +Moore Standards Track [Page 13] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +(c) If the NOTIFY parameter was supplied which did not contain the DELAY + keyword, a "delayed" DSN MUST NOT be issued. + + NOTE: Although delay notifications are common in present-day + electronic mail, a conforming MTA is never required to issue + "delayed" DSNs. The DELAY keyword of the NOTIFY parameter is + provided to allow the SMTP client to specifically request (by + omitting the DELAY parameter) that "delayed" DSNs NOT be issued. + +6.2.6 Failure of a conforming MTA to deliver a message + + The following rules govern the behavior of a conforming MTA which + received a message via the SMTP protocol, and is unable to deliver a + message to a recipient specified in the SMTP transaction: + +(a) If a NOTIFY parameter was supplied for the recipient with an esmtp- + keyword containing the value FAILURE, a "failed" DSN MUST be issued + by the MTA. + +(b) If a NOTIFY parameter was supplied for the recipient which did not + contain the value FAILURE, a DSN MUST NOT be issued for that + recipient. However, the MTA MAY inform the local postmaster of the + delivery failure via some appropriate mechanism which does not + itself result in the generation of DSNs. + +(c) If no NOTIFY parameter was supplied for the recipient, a "failed" + DSN MUST be issued. + + NOTE: Some MTAs are known to forward undeliverable messages to the + local postmaster or "dead letter" mailbox. This is still considered + delivery failure, and does not diminish the requirement to issue a + "failed" DSN under the conditions defined elsewhere in this memo. If + a DSN is issued for such a recipient, the Action value MUST be + "failed". + +6.2.7 Forwarding, aliases, and mailing lists + + Delivery of a message to a local email address usually causes the + message to be stored in the recipient's mailbox. However, MTAs + commonly provide a facility where a local email address can be + designated as an "alias" or "mailing list"; delivery to that address + then causes the message to be forwarded to each of the (local or + remote) recipient addresses associated with the alias or list. It is + also common to allow a user to optionally "forward" her mail to one + or more alternate addresses. If this feature is enabled, her mail is + redistributed to those addresses instead of being deposited in her + mailbox. + + + + +Moore Standards Track [Page 14] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + + Following the example of [9] (section 5.3.6), this document defines + the difference between an "alias" and "mailing list" as follows: When + forwarding a message to the addresses associated with an "alias", the + envelope return address (e.g. SMTP MAIL FROM) remains intact. + However, when forwarding a message to the addresses associated with a + "mailing list", the envelope return address is changed to that of the + administrator of the mailing list. This causes DSNs and other + nondelivery reports resulting from delivery to the list members to be + sent to the list administrator rather than the sender of the original + message. + + The DSN processing for aliases and mailing lists is as follows: + +6.2.7.1 mailing lists + + When a message is delivered to a list submission address (i.e. placed + in the list's mailbox for incoming mail, or accepted by the process + that redistributes the message to the list subscribers), this is + considered final delivery for the original message. If the NOTIFY + parameter for the list submission address contained the SUCCESS + keyword, a "delivered" DSN MUST be returned to the sender of the + original message. + + NOTE: Some mailing lists are able to reject message submissions, + based on the content of the message, the sender's address, or some + other criteria. While the interface between such a mailing list and + its MTA is not well-defined, it is important that DSNs NOT be issued + by both the MTA (to report successful delivery to the list), and the + list (to report message rejection using a "failure" DSN.) + + However, even if a "delivered" DSN was issued by the MTA, a mailing + list which rejects a message submission MAY notify the sender that + the message was rejected using an ordinary message instead of a DSN. + + Whenever a message is redistributed to an mailing list, + +(a) The envelope return address is rewritten to point to the list + maintainer. This address MAY be that of a process that recognizes + DSNs and processes them automatically, but it MUST forward + unrecognized messages to the human responsible for the list. + +(b) The ENVID, NOTIFY, RET, and ORCPT parameters which accompany the + redistributed message MUST NOT be derived from those of the original + message. + +(c) The NOTIFY and RET parameters MAY be specified by the local + postmaster or the list administrator. If ORCPT parameters are + supplied during redistribution to the list subscribers, they SHOULD + + + +Moore Standards Track [Page 15] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + + contain the addresses of the list subscribers in the format used by + the mailing list. + +6.2.7.2 single-recipient aliases + + Under normal circumstances, when a message arrives for an "alias" + which has a single forwarding address, a DSN SHOULD NOT be issued. + Any ENVID, NOTIFY, RET, or ORCPT parameters SHOULD be propagated with + the message as it is redistributed to the forwarding address. + +6.2.7.3 multiple-recipient aliases + + An "alias" with multiple recipient addresses may be handled in any of + the following ways: + +(a) Any ENVID, NOTIFY, RET, or ORCPT parameters are NOT propagated when + relaying the message to any of the forwarding addresses. If the + NOTIFY parameter for the alias contained the SUCCESS keyword, the + MTA issues a "relayed" DSN. (In effect, the MTA treats the message + as if it were being relayed into an environment that does not + support DSNs.) + +(b) Any ENVID, NOTIFY, RET, or ORCPT parameters (or the equivalent + requests if the message is gatewayed) are propagated to EXACTLY one + of the forwarding addresses. No DSN is issued. (This is + appropriate when aliasing is used to forward a message to a + "vacation" auto-responder program in addition to the local mailbox.) + +(c) Any ENVID, RET, or ORCPT parameters are propagated to all forwarding + addresses associated with that alias. The NOTIFY parameter is + propagated to the forwarding addresses, except that it any SUCCESS + keyword is removed. If the original NOTIFY parameter for the alias + contained the SUCCESS keyword, an "expanded" DSN is issued for the + alias. If the NOTIFY parameter for the alias did not contain the + SUCCESS keyword, no DSN is issued for the alias. + +6.2.7.4 confidential forwarding addresses + + If it is desired to maintain the confidentiality of a recipient's + forwarding address, the forwarding may be treated as if it were a + mailing list. A DSN will be issued, if appropriate, upon "delivery" + to the recipient address specified by the sender. When the message + is forwarded it will have a new envelope return address. Any DSNs + which result from delivery failure of the forwarded message will not + be returned to the original sender of the message and thus not expose + the recipient's forwarding address. + + + + + +Moore Standards Track [Page 16] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +6.2.8 DSNs describing delivery to multiple recipients + + A single DSN may describe attempts to deliver a message to multiple + recipients of that message. If a DSN is issued for some recipients + in an SMTP transaction and not for others according to the rules + above, the DSN SHOULD NOT contain information for recipients for whom + DSNs would not otherwise have been issued. + +6.3 Handling of messages from other sources + + For messages which originated from "local" users (whatever that + means), the specifications under which DSNs should be generated can + be communicated to the MTA via any protocol agreed on between the + sender's mail composer (user agent) and the MTA. The local MTA can + then either relay the message, or issue appropriate delivery status + notifications. However, if such requests are transmitted within the + message itself (for example in the message headers), the requests + MUST be removed from the message before it is transmitted via SMTP. + + For messages gatewayed from non-SMTP sources and further relayed by + SMTP, the gateway SHOULD, using the SMTP extensions described here, + attempt to provide the delivery reporting conditions expected by the + source mail environment. If appropriate, any DSNs returned to the + source environment SHOULD be translated into the format expected in + that environment. + +6.4 Implementation limits + + A conforming MTA MUST accept ESMTP parameters of at least the + following sizes: + + (a) ENVID parameter: 100 characters. + + (b) NOTIFY parameter: 28 characters. + + (c) ORCPT parameter: 500 characters. + + (d) RET parameter: 8 characters. + + The maximum sizes for the ENVID and ORCPT parameters are intended to + be adequate for the transmission of "foreign" envelope identifier and + original recipient addresses. However, user agents which use SMTP as + a message submission protocol SHOULD NOT generate ENVID parameters + which are longer than 38 characters in length. + + A conforming MTA MUST be able to accept SMTP command-lines which are + at least 1036 characters long (530 characters for the ORCPT and + NOTIFY parameters of the RCPT command, in addition to the 512 + + + +Moore Standards Track [Page 17] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + + characters required by [1]). If other SMTP extensions are supported + by the MTA, the MTA MUST be able to accept a command-line large + enough for each SMTP command and any combination of ESMTP parameters + which may be used with that command. + +7. Format of delivery notifications + + The format of delivery status notifications is defined in [5], which + uses the framework defined in [8]. Delivery status notifications are + to be returned to the sender of the original message as outlined + below. + +7.1 SMTP Envelope to be used with delivery status notifications + + The DSN sender address (in the SMTP MAIL command) MUST be a null + reverse-path ("<>"), as required by section 5.3.3 of [9]. The DSN + recipient address (in the RCPT command) is copied from the MAIL + command which accompanied the message for which the DSN is being + issued. When transmitting a DSN via SMTP, the RET parameter MUST NOT + be used. The NOTIFY parameter MAY be used, but its value MUST be + NEVER. The ENVID parameter (with a newly generated envelope-id) + and/or ORCPT parameter MAY be used. + +7.2 Contents of the DSN + + A DSN is transmitted as a MIME message with a top-level content-type + of multipart/report (as defined in [5]). + + The multipart/report content-type may be used for any of several + kinds of reports generated by the mail system. When multipart/report + is used to convey a DSN, the report-type parameter of the + multipart/report content-type is "delivery-status". + + As described in [8], the first component of a multipart/report + content-type is a human readable explanation of the report. For a + DSN, the second component of the multipart/report is of content-type + message/delivery-status (defined in [5]). The third component of the + multipart/report consists of the original message or some portion + thereof. When the value of the RET parameter is FULL, the full + message SHOULD be returned for any DSN which conveys notification of + delivery failure. (However, if the length of the message is greater + than some implementation-specified length, the MTA MAY return only + the headers even if the RET parameter specified FULL.) If a DSN + contains no notifications of delivery failure, the MTA SHOULD return + only the headers. + + The third component must have an appropriate content-type label. + Issues concerning selection of the content-type are discussed in [8]. + + + +Moore Standards Track [Page 18] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +7.3 Message/delivery-status fields + + The message/delivery-status content-type defines a number of fields, + with general specifications for their contents. The following + requirements for any DSNs generated in response to a message received + by the SMTP protocol by a conforming SMTP server, are in addition to + the requirements defined in [5] for the message/delivery-status type. + + When generating a DSN for a message which was received via the SMTP + protocol, a conforming MTA will generate the following fields of the + message/delivery-status body part: + +(a) if an ENVID parameter was present on the MAIL command, an Original- + Envelope-ID field MUST be supplied, and the value associated with + the ENVID parameter must appear in that field. If the message was + received via SMTP with no ENVID parameter, the Original-Envelope-ID + field MUST NOT be supplied. + + Since the ENVID parameter is encoded as xtext, but the Original- + Envelope-ID header is NOT encoded as xtext, the MTA must decode the + xtext encoding when copying the ENVID value to the Original- + Envelope-ID field. + +(b) The Reporting-MTA field MUST be supplied. If Reporting MTA can + determine its fully-qualified Internet domain name, the MTA-name- + type subfield MUST be "dns", and the field MUST contain the fully- + qualified domain name of the Reporting MTA. If the fully-qualified + Internet domain name of the Reporting MTA is not known (for example, + for an SMTP server which is not directly connected to the Internet), + the Reporting-MTA field may contain any string identifying the MTA, + however, in this case the MTA-name-type subfield MUST NOT be "dns". + A MTA-name-type subfield value of "x-local-hostname" is suggested. + +(c) Other per-message fields as defined in [5] MAY be supplied as + appropriate. + +(d) If the ORCPT parameter was provided for this recipient, the + Original-Recipient field MUST be supplied, with its value taken from + the ORCPT parameter. If no ORCPT parameter was provided for this + recipient, the Original-Recipient field MUST NOT appear. + +(e) The Final-Recipient field MUST be supplied. It MUST contain the + recipient address from the message envelope. If the message was + received via SMTP, the address-type will be "rfc822". + +(f) The Action field MUST be supplied. + + + + + +Moore Standards Track [Page 19] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +(g) The Status field MUST be supplied, using a status-code from [10]. + If there is no specific code which suitably describes a delivery + failure, either 4.0.0 (temporary failure), or 5.0.0 (permanent + failure) MUST be used. + +(h) For DSNs resulting from attempts to relay a message to one or more + recipients via SMTP, the Remote-MTA field MUST be supplied for each + of those recipients. The mta-name-type subfields of those Remote- + MTA fields will be "dns". + +(i) For DSNs resulting from attempts to relay a message to one or more + recipients via SMTP, the Diagnostic-Code MUST be supplied for each + of those recipients. The diagnostic-type subfield will be "smtp". + See section 9.2(a) of this document for a description of the "smtp" + diagnostic-code. + +(j) For DSNs resulting from attempts to relay a message to one or more + recipients via SMTP, an SMTP-Remote-Recipient extension field MAY be + supplied for each recipient, which contains the address of that + recpient which was presented to the remote SMTP server. + +(k) Other per-recipient fields defined in [5] MAY appear, as + appropriate. + +8. Acknowledgments + + The author wishes to thank Eric Allman, Harald Alvestrand, Jim + Conklin, Bryan Costales, Peter Cowen, Dave Crocker, Roger Fajman, Ned + Freed, Marko Kaittola, Steve Kille, John Klensin, Anastasios + Kotsikonas, John Gardiner Myers, Julian Onions, Jacob Palme, Marshall + Rose, Greg Vaudreuil, and Klaus Weide for their suggestions for + improvement of this document. + + + + + + + + + + + + + + + + + + + +Moore Standards Track [Page 20] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +9. Appendix - Type-Name Definitions + + The following type names are defined for use in DSN fields generated + by conforming SMTP-based MTAs: + +9.1 "rfc822" address-type + + The "rfc822" address-type is to be used when reporting Internet + electronic mail address in the Original-Recipient and Final-Recipient + DSN fields. + +(a) address-type name: rfc822 + +(b) syntax for mailbox addresses + + RFC822 mailbox addresses are generally expected to be of the form + + [route] addr-spec + + where "route" and "addr-spec" are defined in [2], and the "domain" + portions of both "route" and "addr-spec" are fully-qualified domain + names that are registered in the DNS. However, an MTA MUST NOT + modify an address obtained from the message envelope to force it to + conform to syntax rules. + +(c) If addresses of this type are not composed entirely of graphic +characters from the US-ASCII repertoire, a specification for how they +are to be encoded as graphic US-ASCII characters in a DSN Original- +Recipient or Final-Recipient DSN field. + + RFC822 addresses consist entirely of graphic characters from the US- + ASCII repertoire, so no translation is necessary. + +9.2 "smtp" diagnostic-type + + The "smtp" diagnostic-type is to be used when reporting SMTP reply- + codes in Diagnostic-Code DSN fields. + +(a) diagnostic-type name: SMTP + +(b) A description of the syntax to be used for expressing diagnostic +codes of this type as graphic characters from the US-ASCII repertoire. + + An SMTP diagnostic-code is of the form + + *( 3*DIGIT "-" *text ) 3*DIGIT SPACE *text + + + + + +Moore Standards Track [Page 21] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + + For a single-line SMTP reply to an SMTP command, the diagnostic-code + SHOULD be an exact transcription of the reply. For multi-line SMTP + replies, it is necessary to insert a SPACE before each line after + the first. For example, an SMTP reply of: + + 550-mailbox unavailable + 550 user has moved with no forwarding address + + could appear as follows in a Diagnostic-Code DSN field: + + Diagnostic-Code: smtp ; 550-mailbox unavailable + 550 user has moved with no forwarding address + +(c) A list of valid diagnostic codes of this type and the meaning of +each code. + + SMTP reply-codes are currently defined in [1], [4], and [9]. + Additional codes may be defined by other RFCs. + +9.3 "dns" MTA-name-type + + The "dns" MTA-name-type should be used in the Reporting-MTA field. + An MTA-name of type "dns" is a fully-qualified domain name. The name + must be registered in the DNS, and the address Postmaster@{mta-name} + must be valid. + +(a) MTA-name-type name: dns + +(b) A description of the syntax of MTA names of this type, using BNF, +regular expressions, ASN.1, or other non-ambiguous language. + + MTA names of type "dns" SHOULD be valid Internet domain names. If + such domain names are not available, a domain-literal containing the + internet protocol address is acceptable. Such domain names + generally conform to the following syntax: + + domain = real-domain / domain-literal + + real-domain = sub-domain *("." sub-domain) + + sub-domain = atom + + domain-literal = "[" 1*3DIGIT 3("." 1*3DIGIT) "]" + + where "atom" and "DIGIT" are defined in [2]. + + + + + + +Moore Standards Track [Page 22] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +(c) If MTA names of this type do not consist entirely of graphic +characters from the US-ASCII repertoire, a specification for how an MTA +name of this type should be expressed as a sequence of graphic US-ASCII +characters. + + MTA names of type "dns" consist entirely of graphic US-ASCII + characters, so no translation is needed. + +10. Appendix - Example + + This example traces the flow of a single message addressed to + multiple recipients. The message is sent by Alice@Pure-Heart.ORG to + Bob@Big-Bucks.COM, Carol@Ivory.EDU, Dana@Ivory.EDU, + Eric@Bombs.AF.MIL, Fred@Bombs.AF.MIL, and George@Tax-ME.GOV, with a + variety of per-recipient options. The message is successfully + delivered to Bob, Dana (via a gateway), Eric, and Fred. Delivery + fails for Carol and George. + + NOTE: Formatting rules for RFCs require that no line be longer than + 72 characters. Therefore, in the following examples, some SMTP + commands longer than 72 characters are printed on two lines, with the + first line ending in "\". In an actual SMTP transaction, such a + command would be sent as a single line (i.e. with no embedded CRLFs), + and without the "\" character that appears in these examples. + +10.1 Submission + + Alice's user agent sends the message to the SMTP server at Pure- + Heart.ORG. Note that while this example uses SMTP as a mail + submission protocol, other protocols could also be used. + +<<< 220 Pure-Heart.ORG SMTP server here +>>> EHLO Pure-Heart.ORG +<<< 250-Pure-Heart.ORG +<<< 250-DSN +<<< 250-EXPN +<<< 250 SIZE +>>> MAIL FROM: RET=HDRS ENVID=QQ314159 +<<< 250 sender ok +>>> RCPT TO: NOTIFY=SUCCESS \ + ORCPT=rfc822;Bob@Big-Bucks.COM +<<< 250 recipient ok +>>> RCPT TO: NOTIFY=FAILURE \ + ORCPT=rfc822;Carol@Ivory.EDU +<<< 250 recipient ok +>>> RCPT TO: NOTIFY=SUCCESS,FAILURE \ + ORCPT=rfc822;Dana@Ivory.EDU +<<< 250 recipient ok + + + +Moore Standards Track [Page 23] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +>>> RCPT TO: NOTIFY=FAILURE \ + ORCPT=rfc822;Eric@Bombs.AF.MIL +<<< 250 recipient ok +>>> RCPT TO: NOTIFY=NEVER +<<< 250 recipient ok +>>> RCPT TO: NOTIFY=FAILURE \ + ORCPT=rfc822;George@Tax-ME.GOV +<<< 250 recipient ok +>>> DATA +<<< 354 okay, send message +>>> (message goes here) +>>> . +<<< 250 message accepted +>>> QUIT +<<< 221 goodbye + +10.2 Relay to Big-Bucks.COM + + The SMTP at Pure-Heart.ORG then relays the message to Big-Bucks.COM. + (For the purpose of this example, mail.Big-Bucks.COM is the primary + mail exchanger for Big-Bucks.COM). + +<<< 220 mail.Big-Bucks.COM says hello +>>> EHLO Pure-Heart.ORG +<<< 250-mail.Big-Bucks.COM +<<< 250 DSN +>>> MAIL FROM: RET=HDRS ENVID=QQ314159 +<<< 250 sender okay +>>> RCPT TO: NOTIFY=SUCCESS \ + ORCPT=rfc822;Bob@Big-Bucks.COM +<<< 250 recipient okay +>>> DATA +<<< 354 send message +>>> (message goes here) +>>> . +<<< 250 message received +>>> QUIT +<<< 221 bcnu + +10.3 Relay to Ivory.EDU + + The SMTP at Pure-Heart.ORG relays the message to Ivory.EDU, which (as + it happens) is a gateway to a LAN-based mail system that accepts SMTP + mail and supports the DSN extension. + +<<< 220 Ivory.EDU gateway to FooMail(tm) here +>>> EHLO Pure-Heart.ORG +<<< 250-Ivory.EDU + + + +Moore Standards Track [Page 24] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +<<< 250 DSN +>>> MAIL FROM: RET=HDRS ENVID=QQ314159 +<<< 250 ok +>>> RCPT TO: NOTIFY=FAILURE \ + ORCPT=rfc822;Carol@Ivory.EDU +<<< 550 error - no such recipient +>>> RCPT TO: NOTIFY=SUCCESS,FAILURE \ + ORCPT=rfc822;Dana@Ivory.EDU +<<< 250 recipient ok +>>> DATA +<<< 354 send message, end with '.' +>>> (message goes here) +>>> . +<<< 250 message received +>>> QUIT +<<< 221 bye + + Note that since the Ivory.EDU refused to accept mail for + Carol@Ivory.EDU, and the sender specified NOTIFY=FAILURE, the + sender-SMTP (in this case Pure-Heart.ORG) must generate a DSN. + +10.4 Relay to Bombs.AF.MIL + + The SMTP at Pure-Heart.ORG relays the message to Bombs.AF.MIL, which + does not support the SMTP extension. Because the sender specified + NOTIFY=NEVER for recipient Fred@Bombs.AF.MIL, the SMTP at Pure- + Heart.ORG chooses to send the message for that recipient in a + separate transaction with a reverse-path of <>. + +<<< 220-Bombs.AF.MIL reporting for duty. +<<< 220 Electronic mail is to be used for official business only. +>>> EHLO Pure-Heart.ORG +<<< 502 command not implemented +>>> RSET +<<< 250 reset +>>> HELO Pure-Heart.ORG +<<< 250 Bombs.AF.MIL +>>> MAIL FROM: +<<< 250 ok +>>> RCPT TO: +<<< 250 ok +>>> DATA +<<< 354 send message +>>> (message goes here) +>>> . +<<< 250 message accepted +>>> MAIL FROM:<> +<<< 250 ok + + + +Moore Standards Track [Page 25] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +>>> RCPT TO: +<<< 250 ok +>>> DATA +<<< 354 send message +>>> (message goes here) +>>> . +<<< 250 message accepted +>>> QUIT +<<< 221 Bombs.AF.MIL closing connection + +10.5 Forward from George@Tax-ME.GOV to Sam@Boondoggle.GOV + + The SMTP at Pure-Heart.ORG relays the message to Tax-ME.GOV. (this + step is not shown). MTA Tax-ME.GOV then forwards the message to + Sam@Boondoggle.GOV (shown below). Both Tax-ME.GOV and Pure-Heart.ORG + support the SMTP DSN extension. Note that RET, ENVID, and ORCPT all + retain their original values. + +<<< 220 BoonDoggle.GOV says hello +>>> EHLO Pure-Heart.ORG +<<< 250-mail.Big-Bucks.COM +<<< 250 DSN +>>> MAIL FROM: RET=HDRS ENVID=QQ314159 +<<< 250 sender okay +>>> RCPT TO: NOTIFY=SUCCESS \ + ORCPT=rfc822;George@Tax-ME.GOV +<<< 250 recipient okay +>>> DATA +<<< 354 send message +>>> (message goes here) +>>> . +<<< 250 message received +>>> QUIT +<<< 221 bcnu + + + + + + + + + + + + + + + + + +Moore Standards Track [Page 26] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +10.6 "Delivered" DSN for Bob@Big-Bucks.COM + + MTA mail.Big-Bucks.COM successfully delivers the message to Bob@Big- + Bucks.COM. Because the sender specified NOTIFY=SUCCESS, mail.Big- + Bucks.COM issues the following DSN, and sends it to Alice@Pure- + Heart.ORG. + +To: Alice@Pure-Heart.ORG +From: postmaster@mail.Big-Bucks.COM +Subject: Delivery Notification (success) for Bob@Big-Bucks.COM +Content-Type: multipart/report; report-type=delivery-status; + boundary=abcde +MIME-Version: 1.0 + +--abcde +Content-type: text/plain; charset=us-ascii + +Your message (id QQ314159) was successfully delivered to +Bob@Big-Bucks.COM. + +--abcde +Content-type: message/delivery-status + +Reporting-MTA: dns; mail.Big-Bucks.COM +Original-Envelope-ID: QQ314159 + +Original-Recipient: rfc822;Bob@Big-Bucks.COM +Final-Recipient: rfc822;Bob@Big-Bucks.COM +Action: delivered +Status: 2.0.0 + +--abcde +Content-type: message/rfc822 + +(headers of returned message go here) + +--abcde-- + + + + + + + + + + + + + + +Moore Standards Track [Page 27] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +10.7 Failed DSN for Carol@Ivory.EDU + + Because delivery to Carol failed and the sender specified + NOTIFY=FAILURE for Carol@Ivory.EDU, MTA Pure-Heart.ORG (the SMTP + client to which the failure was reported via SMTP) issues the + following DSN. + +To: Alice@Pure-Heart.ORG +From: postmaster@Pure-Heart.ORG +Subject: Delivery Notification (failure) for Carol@Ivory.EDU +Content-Type: multipart/report; report-type=delivery-status; + boundary=bcdef +MIME-Version: 1.0 + +--bcdef +Content-type: text/plain; charset=us-ascii + +Your message (id QQ314159) could not be delivered to +Carol@Ivory.EDU. + +A transcript of the session follows: + +(while talking to Ivory.EDU) +>>> RCPT TO: NOTIFY=FAILURE +<<< 550 error - no such recipient + +--bcdef +Content-type: message/delivery-status + +Reporting-MTA: dns; Pure-Heart.ORG +Original-Envelope-ID: QQ314159 + +Original-Recipient: rfc822;Carol@Ivory.EDU +Final-Recipient: rfc822;Carol@Ivory.EDU +SMTP-Remote-Recipient: Carol@Ivory.EDU +Diagnostic-Code: smtp; 550 error - no such recipient +Action: failed +Status: 5.0.0 + +--bcdef +Content-type: message/rfc822 + +(headers of returned message go here) + +--bcdef-- + + + + + + +Moore Standards Track [Page 28] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +10.8 Relayed DSN For Dana@Ivory.EDU + + Although the mail gateway Ivory.EDU supports the DSN SMTP extension, + the LAN mail system attached to its other side does not generate + positive delivery confirmations. So Ivory.EDU issues a "relayed" + DSN: + +To: Alice@Pure-Heart.ORG +From: postmaster@Ivory.EDU +Subject: mail relayed for Dana@Ivory.EDU +Content-Type: multipart/report; report-type=delivery-status; + boundary=cdefg +MIME-Version: 1.0 + +--cdefg +Content-type: text/plain; charset=us-ascii + +Your message (addressed to Dana@Ivory.EDU) was successfully +relayed to: + +ymail!Dana + +by the FooMail gateway at Ivory.EDU. + +Unfortunately, the remote mail system does not support +confirmation of actual delivery. Unless delivery to ymail!Dana +fails, this will be the only delivery status notification sent. + +--cdefg +Content-type: message/delivery-status + +Reporting-MTA: dns; Ivory.EDU +Original-Envelope-ID: QQ314159 + +Original-Recipient: rfc822;Dana@Ivory.EDU +Final-Recipient: rfc822;Dana@Ivory.EDU +Action: relayed +Status: 2.0.0 + +--cdefg +Content-type: message/rfc822 + +(headers of returned message go here) + +--cdefg-- + + + + + + +Moore Standards Track [Page 29] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +10.9 Failure notification for Sam@Boondoggle.GOV + + The message originally addressed to George@Tax-ME.GOV was forwarded + to Sam@Boondoggle.GOV, but the MTA for Boondoggle.GOV was unable to + deliver the message due to a lack of disk space in Sam's mailbox. + After trying for several days, Boondoggle.GOV returned the following + DSN: + +To: Alice@BigHeart.ORG +From: Postmaster@Boondoggle.GOV +Subject: Delivery failure for Sam@Boondoggle.GOV +Content-Type: multipart/report; report-type=delivery-status; + boundary=defgh +MIME-Version: 1.0 + +--defgh +Your message, originally addressed to George@Tax-ME.GOV, and forwarded +from there to Sam@Boondoggle.GOV could not be delivered, for the +following reason: + +write error to mailbox, disk quota exceeded + +--defgh +Content-type: message/delivery-status + +Reporting-MTA: Boondoggle.GOV +Original-Envelope-ID: QQ314159 + +Original-Recipient: rfc822;George@Tax-ME.GOV +Final-Recipient: rfc822;Sam@Boondoggle.GOV +Action: failed +Status: 4.2.2 (disk quota exceeded) + +--defgh +Content-type: message/rfc822 + +(headers of returned message go here) + +--defgh-- + + + + + + + + + + + + +Moore Standards Track [Page 30] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +11. References + + [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, + USC/Information Sciences Institute, August 1982. + + [2] Crocker, D., "Standard for the Format of ARPA Internet Text + Messages", STD 11, RFC 822, UDEL, August 1982. + + [3] Westine, A., and J. Postel, "Problems with the Maintenance of + Large Mailing Lists.", RFC 1211, USC/Information Sciences + Institute, March 1991. + + [4] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, + "SMTP Service Extensions", RFC 1651, MCI, Innosoft, Dover Beach + Consulting, Inc., Network Management Associates, Inc., Silicon + Graphics, Inc., July 1994. + + [5] Moore, K., and G. Vaudreuil, "An Extensible Message Format for + Delivery Status Notifications", RFC 1894, University of Tennessee, + Octel Network Services, January 1996. + + [6] Crispin, M., "Internet Message Access Protocol - Version 4", RFC + 1730, University of Washington, 20 December 1994. + + [7] Myers, J., and M. Rose, "Post Office Protocol - Version 3", RFC + 1725, Carnegie Mellon, Dover Beach Consulting, November 1994. + + [8] Vaudreuil, G., "The Multipart/Report Content Type for the + Reporting of Mail System Administrative Messages", RFC 1892, Octel + Network Services, January 1996. + + [9] Braden, R., Editor, "Requirements for Internet Hosts - Application + and Support", STD 3, RFC 1123, IETF, October 1989. + + [10] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893, + Octel Network Services, January 1996. + +12. Author's Address + + Keith Moore + University of Tennessee + 107 Ayres Hall + Knoxville, TN 37996-1301 + USA + + EMail: moore@cs.utk.edu + + + + + +Moore Standards Track [Page 31] + diff --git a/doc/devel/rfc/rfc1893.txt b/doc/devel/rfc/rfc1893.txt new file mode 100644 index 00000000..9ca4efb5 --- /dev/null +++ b/doc/devel/rfc/rfc1893.txt @@ -0,0 +1,843 @@ + + + + + + +Network Working Group G. Vaudreuil +Request for Comments: 1893 Octel Network Services +Category: Standards Track January 1996 + + + Enhanced Mail System Status Codes + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +1. Overview + + There currently is not a standard mechanism for the reporting of mail + system errors except for the limited set offered by SMTP and the + system specific text descriptions sent in mail messages. There is a + pressing need for a rich machine readable status code for use in + delivery status notifications [DSN]. This document proposes a new + set of status codes for this purpose. + + SMTP [SMTP] error codes have historically been used for reporting + mail system errors. Because of limitations in the SMTP code design, + these are not suitable for use in delivery status notifications. + SMTP provides about 12 useful codes for delivery reports. The + majority of the codes are protocol specific response codes such as + the 354 response to the SMTP data command. Each of the 12 useful + codes are each overloaded to indicate several error conditions each. + SMTP suffers some scars from history, most notably the unfortunate + damage to the reply code extension mechanism by uncontrolled use. + This proposal facilitates future extensibility by requiring the + client to interpret unknown error codes according to the theory of + codes while requiring servers to register new response codes. + + The SMTP theory of reply codes partitioned in the number space such a + manner that the remaining available codes will not provide the space + needed. The most critical example is the existence of only 5 + remaining codes for mail system errors. The mail system + classification includes both host and mailbox error conditions. The + remaining third digit space would be completely consumed as needed to + indicate MIME and media conversion errors and security system errors. + + A revision to the SMTP theory of reply codes to better distribute the + error conditions in the number space will necessarily be incompatible + with SMTP. Further, consumption of the remaining reply-code number + + + +Vaudreuil Standards Track [Page 1] + +RFC 1893 Mail System Status Codes January 1996 + + + space for delivery notification reporting will reduce the available + codes for new ESMTP extensions. + + The following proposal is based on the SMTP theory of reply codes. + It adopts the success, permanent error, and transient error semantics + of the first value, with a further description and classification in + the second. This proposal re-distributes the classifications to + better distribute the error conditions, such as separating mailbox + from host errors. + +2. Status Codes + + This document defines a new set of status codes to report mail system + conditions. These status codes are intended to be used for media and + language independent status reporting. They are not intended for + system specific diagnostics. + + The syntax of the new status codes is defined as: + + status-code = class "." subject "." detail + class = "2"/"4"/"5" + subject = 1*3digit + detail = 1*3digit + + White-space characters and comments are NOT allowed within a status- + code. Each numeric sub-code within the status-code MUST be expressed + without leading zero digits. + + Status codes consist of three numerical fields separated by ".". The + first sub-code indicates whether the delivery attempt was successful. + The second sub-code indicates the probable source of any delivery + anomalies, and the third sub-code indicates a precise error + condition. + + The codes space defined is intended to be extensible only by + standards track documents. Mail system specific status codes should + be mapped as close as possible to the standard status codes. Servers + should send only defined, registered status codes. System specific + errors and diagnostics should be carried by means other than status + codes. + + New subject and detail codes will be added over time. Because the + number space is large, it is not intended that published status codes + will ever be redefined or eliminated. Clients should preserve the + extensibility of the code space by reporting the general error + described in the subject sub-code when the specific detail is + unrecognized. + + + + +Vaudreuil Standards Track [Page 2] + +RFC 1893 Mail System Status Codes January 1996 + + + The class sub-code provides a broad classification of the status. + The enumerated values the class are defined as: + + 2.X.X Success + + Success specifies that the DSN is reporting a positive delivery + action. Detail sub-codes may provide notification of + transformations required for delivery. + + 4.X.X Persistent Transient Failure + + A persistent transient failure is one in which the message as + sent is valid, but some temporary event prevents the successful + sending of the message. Sending in the future may be successful. + + 5.X.X Permanent Failure + + A permanent failure is one which is not likely to be resolved by + resending the message in the current form. Some change to the + message or the destination must be made for successful delivery. + + A client must recognize and report class sub-code even where + subsequent subject sub-codes are unrecognized. + + The subject sub-code classifies the status. This value applies to + each of the three classifications. The subject sub-code, if + recognized, must be reported even if the additional detail provided + by the detail sub-code is not recognized. The enumerated values for + the subject sub-code are: + + X.0.X Other or Undefined Status + + There is no additional subject information available. + + X.1.X Addressing Status + + The address status reports on the originator or destination + address. It may include address syntax or validity. These + errors can generally be corrected by the sender and retried. + + X.2.X Mailbox Status + + Mailbox status indicates that something having to do with the + mailbox has cause this DSN. Mailbox issues are assumed to be + under the general control of the recipient. + + + + + + +Vaudreuil Standards Track [Page 3] + +RFC 1893 Mail System Status Codes January 1996 + + + X.3.X Mail System Status + + Mail system status indicates that something having to do + with the destination system has caused this DSN. System + issues are assumed to be under the general control of the + destination system administrator. + + X.4.X Network and Routing Status + + The networking or routing codes report status about the + delivery system itself. These system components include any + necessary infrastructure such as directory and routing + services. Network issues are assumed to be under the + control of the destination or intermediate system + administrator. + + X.5.X Mail Delivery Protocol Status + + The mail delivery protocol status codes report failures + involving the message delivery protocol. These failures + include the full range of problems resulting from + implementation errors or an unreliable connection. Mail + delivery protocol issues may be controlled by many parties + including the originating system, destination system, or + intermediate system administrators. + + X.6.X Message Content or Media Status + + The message content or media status codes report failures + involving the content of the message. These codes report + failures due to translation, transcoding, or otherwise + unsupported message media. Message content or media issues + are under the control of both the sender and the receiver, + both of whom must support a common set of supported + content-types. + + X.7.X Security or Policy Status + + The security or policy status codes report failures + involving policies such as per-recipient or per-host + filtering and cryptographic operations. Security and policy + status issues are assumed to be under the control of either + or both the sender and recipient. Both the sender and + recipient must permit the exchange of messages and arrange + the exchange of necessary keys and certificates for + cryptographic operations. + + + + + +Vaudreuil Standards Track [Page 4] + +RFC 1893 Mail System Status Codes January 1996 + + +3. Enumerated Status Codes + + The following section defines and describes the detail sub-code. The + detail value provides more information about the status and is + defined relative to the subject of the status. + + 3.1 Other or Undefined Status + + X.0.0 Other undefined Status + + Other undefined status is the only undefined error code. It + should be used for all errors for which only the class of the + error is known. + + 3.2 Address Status + + X.1.0 Other address status + + Something about the address specified in the message caused + this DSN. + + X.1.1 Bad destination mailbox address + + The mailbox specified in the address does not exist. For + Internet mail names, this means the address portion to the + left of the "@" sign is invalid. This code is only useful + for permanent failures. + + X.1.2 Bad destination system address + + The destination system specified in the address does not + exist or is incapable of accepting mail. For Internet mail + names, this means the address portion to the right of the + "@" is invalid for mail. This codes is only useful for + permanent failures. + + X.1.3 Bad destination mailbox address syntax + + The destination address was syntactically invalid. This can + apply to any field in the address. This code is only useful + for permanent failures. + + X.1.4 Destination mailbox address ambiguous + + The mailbox address as specified matches one or more + recipients on the destination system. This may result if a + heuristic address mapping algorithm is used to map the + specified address to a local mailbox name. + + + +Vaudreuil Standards Track [Page 5] + +RFC 1893 Mail System Status Codes January 1996 + + + X.1.5 Destination address valid + + This mailbox address as specified was valid. This status + code should be used for positive delivery reports. + + X.1.6 Destination mailbox has moved, No forwarding address + + The mailbox address provided was at one time valid, but mail + is no longer being accepted for that address. This code is + only useful for permanent failures. + + X.1.7 Bad sender's mailbox address syntax + + The sender's address was syntactically invalid. This can + apply to any field in the address. + + X.1.8 Bad sender's system address + + The sender's system specified in the address does not exist + or is incapable of accepting return mail. For domain names, + this means the address portion to the right of the "@" is + invalid for mail. + + 3.3 Mailbox Status + + X.2.0 Other or undefined mailbox status + + The mailbox exists, but something about the destination + mailbox has caused the sending of this DSN. + + X.2.1 Mailbox disabled, not accepting messages + + The mailbox exists, but is not accepting messages. This may + be a permanent error if the mailbox will never be re-enabled + or a transient error if the mailbox is only temporarily + disabled. + + X.2.2 Mailbox full + + The mailbox is full because the user has exceeded a + per-mailbox administrative quota or physical capacity. The + general semantics implies that the recipient can delete + messages to make more space available. This code should be + used as a persistent transient failure. + + + + + + + +Vaudreuil Standards Track [Page 6] + +RFC 1893 Mail System Status Codes January 1996 + + + X.2.3 Message length exceeds administrative limit + + A per-mailbox administrative message length limit has been + exceeded. This status code should be used when the + per-mailbox message length limit is less than the general + system limit. This code should be used as a permanent + failure. + + X.2.4 Mailing list expansion problem + + The mailbox is a mailing list address and the mailing list + was unable to be expanded. This code may represent a + permanent failure or a persistent transient failure. + + 3.4 Mail system status + + X.3.0 Other or undefined mail system status + + The destination system exists and normally accepts mail, but + something about the system has caused the generation of this + DSN. + + X.3.1 Mail system full + + Mail system storage has been exceeded. The general + semantics imply that the individual recipient may not be + able to delete material to make room for additional + messages. This is useful only as a persistent transient + error. + + X.3.2 System not accepting network messages + + The host on which the mailbox is resident is not accepting + messages. Examples of such conditions include an immanent + shutdown, excessive load, or system maintenance. This is + useful for both permanent and permanent transient errors. + + X.3.3 System not capable of selected features + + Selected features specified for the message are not + supported by the destination system. This can occur in + gateways when features from one domain cannot be mapped onto + the supported feature in another. + + + + + + + + +Vaudreuil Standards Track [Page 7] + +RFC 1893 Mail System Status Codes January 1996 + + + X.3.4 Message too big for system + + The message is larger than per-message size limit. This + limit may either be for physical or administrative reasons. + This is useful only as a permanent error. + + X.3.5 System incorrectly configured + + The system is not configured in a manner which will permit + it to accept this message. + + 3.5 Network and Routing Status + + X.4.0 Other or undefined network or routing status + + Something went wrong with the networking, but it is not + clear what the problem is, or the problem cannot be well + expressed with any of the other provided detail codes. + + X.4.1 No answer from host + + The outbound connection attempt was not answered, either + because the remote system was busy, or otherwise unable to + take a call. This is useful only as a persistent transient + error. + + X.4.2 Bad connection + + The outbound connection was established, but was otherwise + unable to complete the message transaction, either because + of time-out, or inadequate connection quality. This is + useful only as a persistent transient error. + + X.4.3 Directory server failure + + The network system was unable to forward the message, + because a directory server was unavailable. This is useful + only as a persistent transient error. + + The inability to connect to an Internet DNS server is one + example of the directory server failure error. + + X.4.4 Unable to route + + The mail system was unable to determine the next hop for the + message because the necessary routing information was + unavailable from the directory server. This is useful for + both permanent and persistent transient errors. + + + +Vaudreuil Standards Track [Page 8] + +RFC 1893 Mail System Status Codes January 1996 + + + A DNS lookup returning only an SOA (Start of Administration) + record for a domain name is one example of the unable to + route error. + + X.4.5 Mail system congestion + + The mail system was unable to deliver the message because + the mail system was congested. This is useful only as a + persistent transient error. + + X.4.6 Routing loop detected + + A routing loop caused the message to be forwarded too many + times, either because of incorrect routing tables or a user + forwarding loop. This is useful only as a persistent + transient error. + + X.4.7 Delivery time expired + + The message was considered too old by the rejecting system, + either because it remained on that host too long or because + the time-to-live value specified by the sender of the + message was exceeded. If possible, the code for the actual + problem found when delivery was attempted should be returned + rather than this code. This is useful only as a persistent + transient error. + + 3.6 Mail Delivery Protocol Status + + X.5.0 Other or undefined protocol status + + Something was wrong with the protocol necessary to deliver + the message to the next hop and the problem cannot be well + expressed with any of the other provided detail codes. + + X.5.1 Invalid command + + A mail transaction protocol command was issued which was + either out of sequence or unsupported. This is useful only + as a permanent error. + + X.5.2 Syntax error + + A mail transaction protocol command was issued which could + not be interpreted, either because the syntax was wrong or + the command is unrecognized. This is useful only as a + permanent error. + + + + +Vaudreuil Standards Track [Page 9] + +RFC 1893 Mail System Status Codes January 1996 + + + X.5.3 Too many recipients + + More recipients were specified for the message than could + have been delivered by the protocol. This error should + normally result in the segmentation of the message into two, + the remainder of the recipients to be delivered on a + subsequent delivery attempt. It is included in this list in + the event that such segmentation is not possible. + + X.5.4 Invalid command arguments + + A valid mail transaction protocol command was issued with + invalid arguments, either because the arguments were out of + range or represented unrecognized features. This is useful + only as a permanent error. + + X.5.5 Wrong protocol version + + A protocol version mis-match existed which could not be + automatically resolved by the communicating parties. + + 3.7 Message Content or Message Media Status + + X.6.0 Other or undefined media error + + Something about the content of a message caused it to be + considered undeliverable and the problem cannot be well + expressed with any of the other provided detail codes. + + X.6.1 Media not supported + + The media of the message is not supported by either the + delivery protocol or the next system in the forwarding path. + This is useful only as a permanent error. + + X.6.2 Conversion required and prohibited + + The content of the message must be converted before it can + be delivered and such conversion is not permitted. Such + prohibitions may be the expression of the sender in the + message itself or the policy of the sending host. + + X.6.3 Conversion required but not supported + + The message content must be converted to be forwarded but + such conversion is not possible or is not practical by a + host in the forwarding path. This condition may result when + an ESMTP gateway supports 8bit transport but is not able to + + + +Vaudreuil Standards Track [Page 10] + +RFC 1893 Mail System Status Codes January 1996 + + + downgrade the message to 7 bit as required for the next hop. + + X.6.4 Conversion with loss performed + + This is a warning sent to the sender when message delivery + was successfully but when the delivery required a conversion + in which some data was lost. This may also be a permanant + error if the sender has indicated that conversion with loss + is prohibited for the message. + + X.6.5 Conversion Failed + + A conversion was required but was unsuccessful. This may be + useful as a permanent or persistent temporary notification. + + 3.8 Security or Policy Status + + X.7.0 Other or undefined security status + + Something related to security caused the message to be + returned, and the problem cannot be well expressed with any + of the other provided detail codes. This status code may + also be used when the condition cannot be further described + because of security policies in force. + + X.7.1 Delivery not authorized, message refused + + The sender is not authorized to send to the destination. + This can be the result of per-host or per-recipient + filtering. This memo does not discuss the merits of any + such filtering, but provides a mechanism to report such. + This is useful only as a permanent error. + + X.7.2 Mailing list expansion prohibited + + The sender is not authorized to send a message to the + intended mailing list. This is useful only as a permanent + error. + + X.7.3 Security conversion required but not possible + + A conversion from one secure messaging protocol to another + was required for delivery and such conversion was not + possible. This is useful only as a permanent error. + + + + + + + +Vaudreuil Standards Track [Page 11] + +RFC 1893 Mail System Status Codes January 1996 + + + X.7.4 Security features not supported + + A message contained security features such as secure + authentication which could not be supported on the delivery + protocol. This is useful only as a permanent error. + + X.7.5 Cryptographic failure + + A transport system otherwise authorized to validate or + decrypt a message in transport was unable to do so because + necessary information such as key was not available or such + information was invalid. + + X.7.6 Cryptographic algorithm not supported + + A transport system otherwise authorized to validate or + decrypt a message was unable to do so because the necessary + algorithm was not supported. + + X.7.7 Message integrity failure + + A transport system otherwise authorized to validate a + message was unable to do so because the message was + corrupted or altered. This may be useful as a permanent, + transient persistent, or successful delivery code. + +4. References + + [SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, + USC/Information Sciences Institute, August 1982. + + [DSN] Moore, K., and G. Vaudreuil, "An Extensible Message Format for + Delivery Status Notifications", RFC 1894, University of + Tennessee, Octel Network Services, January 1996. + +5. Security Considerations + + This document describes a status code system with increased + precision. Use of these status codes may disclose additional + information about how an internal mail system is implemented beyond + that currently available. + +6. Acknowledgments + + The author wishes to offer special thanks to Harald Alvestrand, Marko + Kaittola, and Keith Moore for their extensive review and constructive + suggestions. + + + + +Vaudreuil Standards Track [Page 12] + +RFC 1893 Mail System Status Codes January 1996 + + +7. Author's Address + + Gregory M. Vaudreuil + Octel Network Services + 17060 Dallas Parkway + Suite 214 + Dallas, TX 75248-1905 + + Voice/Fax: +1-214-733-2722 + EMail: Greg.Vaudreuil@Octel.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Vaudreuil Standards Track [Page 13] + +RFC 1893 Mail System Status Codes January 1996 + + +8. Appendix - Collected Status Codes + + X.1.0 Other address status + X.1.1 Bad destination mailbox address + X.1.2 Bad destination system address + X.1.3 Bad destination mailbox address syntax + X.1.4 Destination mailbox address ambiguous + X.1.5 Destination mailbox address valid + X.1.6 Mailbox has moved + X.1.7 Bad sender's mailbox address syntax + X.1.8 Bad sender's system address + + X.2.0 Other or undefined mailbox status + X.2.1 Mailbox disabled, not accepting messages + X.2.2 Mailbox full + X.2.3 Message length exceeds administrative limit. + X.2.4 Mailing list expansion problem + + X.3.0 Other or undefined mail system status + X.3.1 Mail system full + X.3.2 System not accepting network messages + X.3.3 System not capable of selected features + X.3.4 Message too big for system + + X.4.0 Other or undefined network or routing status + X.4.1 No answer from host + X.4.2 Bad connection + X.4.3 Routing server failure + X.4.4 Unable to route + X.4.5 Network congestion + X.4.6 Routing loop detected + X.4.7 Delivery time expired + + X.5.0 Other or undefined protocol status + X.5.1 Invalid command + X.5.2 Syntax error + X.5.3 Too many recipients + X.5.4 Invalid command arguments + X.5.5 Wrong protocol version + + X.6.0 Other or undefined media error + X.6.1 Media not supported + X.6.2 Conversion required and prohibited + X.6.3 Conversion required but not supported + X.6.4 Conversion with loss performed + X.6.5 Conversion failed + + + + + +Vaudreuil Standards Track [Page 14] + +RFC 1893 Mail System Status Codes January 1996 + + + X.7.0 Other or undefined security status + X.7.1 Delivery not authorized, message refused + X.7.2 Mailing list expansion prohibited + X.7.3 Security conversion required but not possible + X.7.4 Security features not supported + X.7.5 Cryptographic failure + X.7.6 Cryptographic algorithm not supported + X.7.7 Message integrity failure + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Vaudreuil Standards Track [Page 15] + diff --git a/doc/devel/rfc/rfc1985.txt b/doc/devel/rfc/rfc1985.txt new file mode 100644 index 00000000..f49afd75 --- /dev/null +++ b/doc/devel/rfc/rfc1985.txt @@ -0,0 +1,395 @@ + + + + + + +Network Working Group J. De Winter +Request for Comments: 1985 Wildbear Consulting, Inc. +Category: Standards Track August 1996 + + + SMTP Service Extension + for Remote Message Queue Starting + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + This memo defines an extension to the SMTP service whereby an SMTP + client and server may interact to give the server an opportunity to + start the processing of its queues for messages to go to a given + host. This extension is meant to be used in startup conditions as + well as for mail nodes that have transient connections to their + service providers. + +1. Introduction + + The TURN command was a valid attempt to address the problem of having + to start the processing for the mail queue on a remote machine. + However, the TURN command presents a large security loophole. As + there is no verification of the remote host name, the TURN command + could be used by a rogue system to download the mail for a site other + than itself. + + Therefore, this memo introduces the ETRN command. This command uses + the mechanism defined in [4] to define extensions to the SMTP service + whereby a client ("sender-SMTP") may request that the server + ("receiver-SMTP") start the processing of its mail queues for + messages that are waiting at the server for the client machine. If + any messages are at the server for the client, then the server should + create a new SMTP session and send the messages at that time. + + + + + + + + + + +De Winter Standards Track [Page 1] + +RFC 1985 SMTP Service Extension - ETRN August 1996 + + +2. Framework for the ETRN Extension + + The following service extension is therefore defined: + + (1) the name of the SMTP service extension is "Remote Queue + Processing Declaration"; + + (2) the EHLO keyword value associated with this extension is "ETRN", + with no associated parameters; + + (3) one additional verb, ETRN, with a single parameter that + specifies the name of the client(s) to start processing for; + + (4) no additional SMTP verbs are defined by this extension. + + The remainder of this memo specifies how support for the extension + affects the behavior of an SMTP client and server. + +3. The Remote Queue Processing Declaration service extension + + To save money, many small companies want to only maintain transient + connections to their service providers. In addition, there are some + situations where the client sites depend on their mail arriving + quickly, so forcing the queues on the server belonging to their + service provider may be more desirable than waiting for the retry + timeout to occur. + + Both of these situations could currently be fixed using the TURN + command defined in [1], if it were not for a large security loophole + in the TURN command. As it stands, the TURN command will reverse the + direction of the SMTP connection and assume that the remote host is + being honest about what its name is. The security loophole is that + there is no documented stipulation for checking the authenticity of + the remote host name, as given in the HELO or EHLO command. As such, + most SMTP and ESMTP implementations do not implement the TURN command + to avoid this security loophole. + + This has been addressed in the design of the ETRN command. This + extended turn command was written with the points in the first + paragraph in mind, yet paying attention to the problems that + currently exist with the TURN command. The security loophole is + avoided by asking the server to start a new connection aimed at the + specified client. + + In this manner, the server has a lot more certainty that it is + talking to the correct SMTP client. This mechanism can just be seen + as a more immediate version of the retry queues that appear in most + SMTP implementations. In addition, as this command will take a + + + +De Winter Standards Track [Page 2] + +RFC 1985 SMTP Service Extension - ETRN August 1996 + + + single parameter, the name of the remote host(s) to start the queues + for, the server can decide whether it wishes to respect the request + or deny it for any local administrative reasons. + +4. Definitions + + Remote queue processing means that using an SMTP or ESMTP connection, + the client may request that the server start to process parts of its + messaging queue. This processing is performed using the existing + SMTP infrastructure and will occur at some point after the processing + is initiated. + + The server host is the node that is responding to the ETRN + command. + + The client host is the node that is initiating the ETRN command. + + The remote host name is defined to be a plain-text field that + specifies a name for the remote host(s). This remote host name may + also include an alias for the specified remote host or special + commands to identify other types of queues. + +5. The extended ETRN command + + The extended ETRN command is issued by the client host when it wishes + to start the SMTP queue processing of a given server host. The + syntax of this command is as follows: + + ETRN [ + + ::= | + + ::= | + + ::= | | "-" + + ::= | "." + + ::= | + + ::= """ """ + + ::= "\" | "\" | | + + ::= | "\" + + ::= "." "." "." + + ::= | + + ::= + + + + +[Page 30] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + ::= the carriage return character (ASCII code 13) + + ::= the line feed character (ASCII code 10) + + ::= the space character (ASCII code 32) + + ::= one, two, or three digits representing a decimal + integer value in the range 0 through 255 + + ::= any one of the 52 alphabetic characters A through Z + in upper case and a through z in lower case + + ::= any one of the 128 ASCII characters, but not any + or + + ::= any one of the ten digits 0 through 9 + + ::= any one of the 128 ASCII characters except , + , quote ("), or backslash (\) + + ::= any one of the 128 ASCII characters (no exceptions) + + ::= "<" | ">" | "(" | ")" | "[" | "]" | "\" | "." + | "," | ";" | ":" | "@" """ | the control + characters (ASCII codes 0 through 31 inclusive and + 127) + + Note that the backslash, "\", is a quote character, which is + used to indicate that the next character is to be used + literally (instead of its normal interpretation). For example, + "Joe\,Smith" could be used to indicate a single nine character + user field with comma being the fourth character of the field. + + Hosts are generally known by names which are translated to + addresses in each host. Note that the name elements of domains + are the official names -- no use of nicknames or aliases is + allowed. + + Sometimes a host is not known to the translation function and + communication is blocked. To bypass this barrier two numeric + forms are also allowed for host "names". One form is a decimal + integer prefixed by a pound sign, "#", which indicates the + number is the address of the host. Another form is four small + decimal integers separated by dots and enclosed by brackets, + e.g., "[123.255.37.2]", which indicates a 32-bit ARPA Internet + Address in four 8-bit fields. + + + +Postel [Page 31] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + The time stamp line and the return path line are formally + defined as follows: + + ::= "Return-Path:" + + ::= "Received:" + + ::= ";" + + + ::= "FROM" + + ::= "BY" + + ::= [] [] [] [] + + ::= "VIA" + + ::= "WITH" + + ::= "ID" + + ::= "FOR" + + ::= The standard names for links are registered with + the Network Information Center. + + ::= The standard names for protocols are + registered with the Network Information Center. + + ::=