Initial revision

18 files changed, 26131 insertions, 0 deletions

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
+                    <draft-ietf-ldapbis-url-00.txt>
+
+
+
+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 <ietf-
+   ldapbis@openldap.org>.  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   = <hostport from Section 3.2.2 of RFC 2396 [RFC2396]>
+       dn         = <distinguishedName from Section 3 of [RFC2253]>
+       attributes = attrdesc *("," attrdesc)
+       attrdesc   = <AttributeDescription from Section 4.1.5 of [RFC2251]> / "*"
+       scope      = "base" / "one" / "sub"
+       filter     = <filter from Section 4 of [RFC2254]>
+       extensions = extension *("," extension)
+       extension  = ["!"] extype ["=" exvalue]
+       extype     = token / xtoken
+       exvalue    = <LDAPString from section 4.1.2 of [RFC2251]>
+       token      = <oid from section 4.1 of [RFC2252]>
+       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
+   <userinfo>@<host>:<port> 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 <ssss> 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 <ssss> 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 <ssss>
+                      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 <domain> 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 <domain> 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:<joe@GAMMA>".
+              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 <path> 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: <craig@nnsc.nsf.net>
+
+      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:<user@d>".
+
+              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 <route> 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:
+
+            <port-on-server> , <port-on-client>
+
+   where <port-on-server> is the TCP port (decimal) on the target (where
+   the "ident" server is running) system, and <port-on-client> 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
+
+   <port-on-server> , <port-on-client> : <resp-type> : <add-info>
+
+   where <port-on-server>,<port-on-client> are the same pair as the
+   query, <resp-type> is a keyword identifying the type of response, and
+   <add-info> is context dependent.
+
+   The information returned is that associated with the fully specified
+   TCP connection identified by <server-address>, <client-address>,
+   <port-on-server>, <port-on-client>, where <server-address> and
+   <client-address> are the local and foreign IP addresses of the
+   querying connection -- i.e., the TCP connection to the Identification
+   Protocol Server.  (<port-on-server> and <port-on-client> 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, <add-info> 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, <add-info>
+   tells why.  The following are the permitted values of <add-info> 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
+
+   <request> ::= <port-pair> <EOL>
+
+   <port-pair> ::= <integer> "," <integer>
+
+   <reply> ::= <reply-text> <EOL>
+
+   <EOL> ::= "015 012"  ; CR-LF End of Line Indicator
+
+   <reply-text> ::= <error-reply> | <ident-reply>
+
+   <error-reply> ::= <port-pair> ":" "ERROR" ":" <error-type>
+
+   <ident-reply> ::= <port-pair> ":" "USERID" ":" <opsys-field>
+                     ":" <user-id>
+
+   <error-type> ::= "INVALID-PORT" | "NO-USER" | "UNKNOWN-ERROR"
+                    | "HIDDEN-USER" |  <error-token>
+
+   <opsys-field> ::= <opsys> [ "," <charset>]
+
+   <opsys> ::= "OTHER" | "UNIX" | <token> ...etc.
+               ;  (See "Assigned Numbers")
+
+   <charset> ::= "US-ASCII" | ...etc.
+                 ;  (See "Assigned Numbers")
+
+   <user-id> ::= <octet-string>
+
+   <token> ::= 1*64<token-characters> ; 1-64 characters
+
+   <error-token> ::= "X"1*63<token-characters>
+                     ; 2-64 chars beginning w/X
+
+
+
+St. Johns                                                       [Page 5]
+
+RFC 1413                Identification Protocol            February 1993
+
+
+   <integer> ::= 1*5<digit> ; 1-5 digits.
+
+   <digit> ::= "0" | "1" ... "8" | "9" ; 0-9
+
+   <token-characters> ::=
+                  <Any of these ASCII characters: a-z, A-Z,
+                   - (dash), .!@#$%^&*()_=+.,<>/?"'~`{}[]; >
+                               ; upper and lowercase a-z plus
+                               ; printables minus the colon ":"
+                               ; character.
+
+   <octet-string> ::= 1*512<octet-characters>
+
+   <octet-characters> ::=
+                  <any octet from  00 to 377 (octal) except for
+                   ASCII NUL (000), CR (015) and LF (012)>
+
+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 <EOL>.
+
+   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 <user-id> is defined as an <octet-string>
+        above, it must follow the format and character set
+        constraints implied by the <opsys-field>; 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 := <a publicly-defined extension token,
+               registered with IANA, as specified in
+               appendix E>
+
+     x-token := <The two characters "X-" or "x-" followed, with
+                 no intervening white space, by any token>
+
+     subtype := token ; case-insensitive
+
+     parameter := attribute "=" value
+
+     attribute := token   ; case-insensitive
+
+     value := token / quoted-string
+
+     token  :=  1*<any (ASCII) CHAR except SPACE, CTLs,
+                   or tspecials>
+
+     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 /<any ASCII character except "=", SPACE, or TAB>
+        ; characters not listed as "mail-safe" in Appendix B
+        ; are also not recommended.
+
+   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".
+
+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 <nsb@bellcore.com>
+      To:  Ned Freed <ned@innosoft.com>
+      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<bchars> 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 <nsb@bellcore.com>
+   To: Ned Freed <ned@innosoft.com>
+   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: <id1@host.com>
+      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: <anotherid@foo.com>
+      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: <id2@host.com>
+      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: <anotherid@foo.com>
+      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: <id42@guppylake.bellcore.com>
+      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: <id1@host.com>
+      Content-Type: multipart/alternative; boundary=42
+      Content-ID: <id001@guppylake.bellcore.com>
+
+      --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: <id42@guppylake.bellcore.com>
+
+      --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: <id42@guppylake.bellcore.com>
+
+      --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: <id42@guppylake.bellcore.com>
+
+      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 <nsb@bellcore.com>
+      To: Ned Freed <ned@innosoft.com>
+      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 <bold><italic>richtext.</italic></bold>
+      <smaller>as defined in RFC 1341</smaller>
+      <nl><nl>Isn't it
+      <bigger><bigger>cool?</bigger></bigger>
+
+      --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<bchars> 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 := <a publicly-defined extension token,
+             registered with IANA, as specified in
+             appendix E>
+
+   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 / <any ASCII character except "=", SPACE,  or TAB>
+
+
+
+Borenstein & Freed                                             [Page 70]
+
+RFC 1521                          MIME                    September 1993
+
+
+        ; characters not listed as "mail-safe" in Appendix B
+        ; are also not recommended.
+
+   quoted-printable := ([*(ptext / SPACE /  TAB)  ptext]  ["="] CRLF)
+        ; Maximum line length of 76 characters excluding CRLF
+
+   stream-param :=  (";" "type" "=" value)
+                / (";" "padding" "=" padding)
+
+   subtype := token  ; case-insensitive
+
+   text-subtype := "plain" / extension-token
+
+   text-type := "text" "/" text-subtype [";" "charset" "=" charset]
+
+   token  :=  1*<any  (ASCII) CHAR except SPACE, CTLs, or tspecials>
+
+   tspecials :=  "(" / ")" / "<" / ">" / "@"
+              /  "," / ";" / ":" / "\" / <">
+              /  "/" / "[" / "]" / "?" / "="
+             ; 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 := <The two characters "X-" or "x-" followed, with no
+              intervening white space, by any 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*<any character other than CR or LF>
+
+     ehlo-line    ::= ehlo-keyword *( SP ehlo-param )
+
+     ehlo-keyword ::= (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
+
+                  ; syntax and values depend on ehlo-keyword
+     ehlo-param   ::= 1*<any CHAR excluding SP and all
+                         control characters (US-ASCII 0-31
+                         inclusive)>
+
+     ALPHA        ::= <any one of the 52 alphabetic characters
+                       (A through Z in upper case, and,
+                        a through z in lower case)>
+     DIGIT        ::= <any one of the 10 numeric characters
+                       (0 through 9)>
+
+     CR           ::= <the carriage-return character
+                       (ASCII decimal code 13)>
+     LF           ::= <the line-feed character
+                       (ASCII decimal code 10)>
+     SP           ::= <the space character
+                       (ASCII decimal code 32)>
+
+   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*<any CHAR excluding "=", SP, and all
+                          control characters (US-ASCII 0-31
+                          inclusive)>
+
+                       ; The following commands are extended to
+                       ; accept extended parameters.
+  inner-esmtp-cmd  ::= ("MAIL FROM:<" reverse-path ">")   /
+                       ("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: <wait for connection on TCP port 25>
+        C: <open connection to server>
+        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: <wait for connection on TCP port 25>
+        C: <open connection to server>
+        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: <wait for connection on TCP port 25>
+        C: <open connection to server>
+
+
+
+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*<any character other than CR or LF>
+
+     ehlo-line    ::= ehlo-keyword *( SP ehlo-param )
+
+     ehlo-keyword ::= (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
+
+                  ; syntax and values depend on ehlo-keyword
+     ehlo-param   ::= 1*<any CHAR excluding SP and all
+                         control characters (US ASCII 0-31
+                         inclusive)>
+
+     ALPHA        ::= <any one of the 52 alphabetic characters
+                       (A through Z in upper case, and,
+                        a through z in lower case)>
+     DIGIT        ::= <any one of the 10 numeric characters
+                       (0 through 9)>
+
+     CR           ::= <the carriage-return character
+                       (ASCII decimal code 13)>
+     LF           ::= <the line-feed character
+                       (ASCII decimal code 10)>
+
+
+
+Klensin, et al              Standards Track                     [Page 4]
+
+RFC 1869                SMTP Service Extensions            November 1995
+
+
+     SP           ::= <the space character
+                       (ASCII decimal code 32)>
+
+   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*<any CHAR excluding "=", SP, and all
+                             control characters (US ASCII 0-31
+                             inclusive)>
+
+
+
+
+Klensin, et al              Standards Track                     [Page 7]
+
+RFC 1869                SMTP Service Extensions            November 1995
+
+
+                          ; The following commands are extended to
+                          ; accept extended parameters.
+     inner-esmtp-cmd  ::= ("MAIL FROM:" reverse-path)   /
+                          ("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.
+
+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: <wait for connection on TCP port 25>
+       C: <open connection to server>
+       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: <wait for connection on TCP port 25>
+       C: <open connection to server>
+       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: <wait for connection on TCP port 25>
+       C: <open connection to server>
+       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
+   <notifications@cs.utk.edu>.  Requests to subscribe to the mailing
+   list should be addressed to <notifications-request@cs.utk.edu>.
+   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:<Alice@Pure-Heart.ORG> RET=HDRS ENVID=QQ314159
+<<< 250 <Alice@Pure-Heart.ORG> sender ok
+>>> RCPT TO:<Bob@Big-Bucks.COM> NOTIFY=SUCCESS \
+    ORCPT=rfc822;Bob@Big-Bucks.COM
+<<< 250 <Bob@Big-Bucks.COM> recipient ok
+>>> RCPT TO:<Carol@Ivory.EDU> NOTIFY=FAILURE \
+    ORCPT=rfc822;Carol@Ivory.EDU
+<<< 250 <Carol@Ivory.EDU> recipient ok
+>>> RCPT TO:<Dana@Ivory.EDU> NOTIFY=SUCCESS,FAILURE \
+    ORCPT=rfc822;Dana@Ivory.EDU
+<<< 250 <Dana@Ivory.EDU> recipient ok
+
+
+
+Moore                       Standards Track                    [Page 23]
+
+RFC 1891           SMTP Delivery Status Notifications       January 1996
+
+
+>>> RCPT TO:<Eric@Bombs.AF.MIL> NOTIFY=FAILURE \
+    ORCPT=rfc822;Eric@Bombs.AF.MIL
+<<< 250 <Eric@Bombs.AF.MIL> recipient ok
+>>> RCPT TO:<Fred@Bombs.AF.MIL> NOTIFY=NEVER
+<<< 250 <Fred@Bombs.AF.MIL> recipient ok
+>>> RCPT TO:<George@Tax-ME.GOV> NOTIFY=FAILURE \
+    ORCPT=rfc822;George@Tax-ME.GOV
+<<< 250 <George@Tax-ME.GOV> 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:<Alice@Pure-Heart.ORG> RET=HDRS ENVID=QQ314159
+<<< 250 sender okay
+>>> RCPT TO:<Bob@Big-Bucks.COM> 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:<Alice@Pure-Heart.ORG> RET=HDRS ENVID=QQ314159
+<<< 250 ok
+>>> RCPT TO:<Carol@Ivory.EDU> NOTIFY=FAILURE \
+    ORCPT=rfc822;Carol@Ivory.EDU
+<<< 550 error - no such recipient
+>>> RCPT TO:<Dana@Ivory.EDU> 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:<Alice@Pure-Heart.ORG>
+<<< 250 ok
+>>> RCPT TO:<Eric@Bombs.AF.MIL>
+<<< 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:<Fred@Bombs.AF.MIL>
+<<< 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:<Alice@Pure-Heart.ORG> RET=HDRS ENVID=QQ314159
+<<< 250 sender okay
+>>> RCPT TO:<Sam@Boondoggle.GOV> 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:<Carol@Ivory.EDU> 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 [<option character>]<node name><CR><LF>
+
+   This command may be issued at any time once a session is established,
+   as long as there is not a transaction occuring.  Thus, this command
+   is illegal between a MAIL FROM: command and the end of the DATA
+   commands and responses.
+
+   The specified node name must be a fully qualified domain name for the
+   node, which may refer to a CNAME or MX pointer in the DNS.  If an
+   alias is used for the node, multiple ETRN commands may be needed to
+   start the processing for the node as it may be listed at the remote
+   site under multiple names.  This can also be addressed using the
+   options discussed in section 5.3.
+
+   The option character under normal circumstances is not used.
+
+
+
+
+
+
+
+
+De Winter                   Standards Track                     [Page 3]
+
+RFC 1985             SMTP Service Extension - ETRN           August 1996
+
+
+5.1  Server action on receipt of the extended ETRN command
+
+   When the server host receives the ETRN command, it should have a look
+   at the node name that is specified in the command and make a local
+   decision if it should honour the request.  If not, the appropriate
+   error codes should be returned to the client.
+
+   Otherwise, the server host should force its retry queues to start
+   sending messages to that remote site, using another SMTP connection.
+   At the moment, there is no requirement that a connection must occur,
+   or that the connection must occur within a given time frame.  This
+   should be noted in the case where there are no messages for the
+   client host at the server host and only the 250 response is used.
+
+   Since the processing of the queues may take an indeterminate amount
+   of time, this command should return immediately with a response to
+   the client host.  The valid return codes for this command are:
+
+   250 OK, queuing for node <x> started
+   251 OK, no messages waiting for node <x>
+   252 OK, pending messages for node <x> started
+   253 OK, <n> pending messages for node <x> started
+   458 Unable to queue messages for node <x>
+   459 Node <x> not allowed: <reason>
+   500 Syntax Error
+   501 Syntax Error in Parameters
+
+   The 250 response code does not indicate that messages will be sent to
+   the system in question, just that the queue has been started and some
+   action will occur.  If the server is capable of supporting it, the
+   251, 252 or 253 response codes should be used to give more
+   information to the client side.  In this case, if there are messages
+   waiting for the client side node, a check can be performed using
+   these responses codes as an indication of when there are no more
+   pending messages in the queue for that node.
+
+   The 458 and 459 result codes should be used to give more information
+   back to the client host as to why the action was not performed.  If
+   the syntax of the request is not correct, then the 500 and 501 result
+   codes should be used.
+
+5.2  Client action on receiving response to extended ETRN command
+
+   If one of the 500 level error codes (550 or 551) are sent, the client
+   should assume that the protocol is not supported in the remote host
+   or that the protocol has not been implemented correctly on either the
+   client or server host.  In this case, multiple ETRN commands (dealing
+   with the aliases for the system) should not be sent.
+
+
+
+De Winter                   Standards Track                     [Page 4]
+
+RFC 1985             SMTP Service Extension - ETRN           August 1996
+
+
+   If the 250 response is received, then the client host can assume that
+   the server host found its request to be satisfactory and it will send
+   any queued messages.  This process may involve going through a very
+   large retry queue, and may take some time.
+
+   If the 400 level response is received, then the client can assume
+   that the server supports the command, but for some local reason does
+   not want to accept the ETRN command as is.  In most cases, it will
+   mean that there is a list of nodes that it will accept the command
+   from and the current client is not on that list.  The 459 response
+   code is presented to allow for a more in-depth reason as to why the
+   remote queuing cannot be started.
+
+5.3  Use Of ETRN to release mail for a subdomain or queue
+
+   If the requesting server wishes to release all of the mail for a
+   given subdomain, a variation on the ETRN command can be used.  To
+   perform this request, the option character '@' should be used in
+   front of the node name.  In this manner, any domain names that are
+   formed with a suffix of the specified node name are released.
+
+   For example, if the command ETRN @foo.com was issued, then any
+   accumulated mail for fred.foo.com, a.b.c.d.e.f.g.foo.com or foo.com
+   may be released.  It should be noted that the receiving side of the
+   ETRN command should make a decision based on the client in question
+   and only allow certain combinations for each of the nodes.  This is
+   more of a security issue than anything else.
+
+   In a similar vein, it might be necessary under some circumstances to
+   release a certain queue, where that queue does not correspond to a
+   given domain name.  To this end, the option character '#' can be used
+   to force the processing of a given queue.  In this case, the node
+   name would be used as a queue name instead, and its syntactical
+   structure would be dependant on the receiving server.  An example of
+   this would be using the command ETRN #uucp to force the flush of a
+   UUCP queue.  Note that the use of this option is entirely a local
+   matter and there is no way for a client to find a list of any such
+   queues that exist.
+
+6.  Minimal usage
+
+   A "minimal" client may use this extension with its host name to start
+   the queues on the server host.  This minimal usage will not handle
+   cases where mail for 'x.y' is sent to 's.x.y'.
+
+   A minimal server may use this extensions to start the processing of
+   the queues for all remote sites.  In this case, the 458 error
+   response will not be seen, and it should always return the 250
+
+
+
+De Winter                   Standards Track                     [Page 5]
+
+RFC 1985             SMTP Service Extension - ETRN           August 1996
+
+
+   response as it will always try and start the processing for any
+   request.
+
+7. Example
+
+   The following example illustrates the use of remote queue processing
+   with some permanent and temporary failures.
+
+   S: <wait for connection on TCP port 25>
+   C: <open connection to server>
+   S: 220 sigurd.innosoft.com -- Server SMTP (PMDF V4.2-6 #1992)
+   C: EHLO ymir.claremont.edu
+   S: 250-sigurd.innosoft.com
+   S: 250-EXPN
+   S: 250-HELP
+   S: 250 ETRN
+   C: ETRN
+   S: 500 Syntax Error
+   C: ETRN localname
+   S: 501 Syntax Error in Parameters
+   C: ETRN uu.net
+   S: 458 Unable to queue messages for node uu.net
+   ...
+
+   C: ETRN sigurd.innosoft.com
+   S: 250 OK, queuing for node sigurd.innosoft.com started
+   C: ETRN innosoft.com
+   S: 250 OK, queuing for node innosoft.com started
+
+   OR
+
+   C: ETRN sigurd.innosoft.com
+   S: 251 OK, no messages waiting for node sigurd.innosoft.com
+   C: ETRN innosoft.com
+   S: 252 OK, pending messages for node innosoft.com started
+   C: ETRN mysoft.com
+   S: 253 OK, 14 pending messages for node mysoft.com started
+
+   ...
+   C: ETRN foo.bar
+   S: 459 Node foo.bar not allowed: Unable to resolve name.
+   ...
+   C: QUIT
+   S: 250 Goodbye
+
+
+
+
+
+
+
+De Winter                   Standards Track                     [Page 6]
+
+RFC 1985             SMTP Service Extension - ETRN           August 1996
+
+
+8. Security Considerations
+
+   This command does not compromise any security considerations of any
+   existing SMTP or ESMTP protocols as it merely shortens the time that
+   a client needs to wait before their messages are retried.
+
+   Precautions should be taken to make sure that any client server can
+   only use the @ and # option characters for systems that make sense.
+   Failure to implement some kind of sanity checking on the parameters
+   could lead to congestion.  This would be evident if a person asking
+   to release @com, which would release mail for any address that ended
+   with com.
+
+9.  Acknowledgements
+
+   This document was created with lots of support from the users of our
+   products, who have given some input to the functionality that they
+   would like to see in the software that they bought.
+
+10.  References
+
+   [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
+       821, August 1982.
+
+   [2] 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.
+
+11.  Author's Address
+
+   Jack De Winter
+   Wildbear Consulting, Inc.
+   17 Brock Street
+   Kitchener, Ontario, Canada
+   N2M 1X2
+
+   Phone: +1 519 576 3873
+   EMail: jack@wildbear.on.ca
+
+
+
+
+
+
+
+
+
+
+
+De Winter                   Standards Track                     [Page 7]
+
diff --git a/doc/devel/rfc/rfc2034.txt b/doc/devel/rfc/rfc2034.txt
new file mode 100644
index 00000000..14f0ab3e
--- /dev/null
+++ b/doc/devel/rfc/rfc2034.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group                                       N. Freed
+Request for Comments: RFC 2034                              Innosoft
+Category: Standards Track                               October 1996
+
+
+                       SMTP Service Extension for
+                     Returning Enhanced Error 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.  Abstract
+
+   This memo defines an extension to the SMTP service [RFC-821, RFC-
+   1869] whereby an SMTP server augments its responses with the enhanced
+   mail system status codes defined in RFC 1893.  These codes can then
+   be used to provide more informative explanations of error conditions,
+   especially in the context of the delivery status notifications format
+   defined in RFC 1894.
+
+2.  Introduction
+
+   Although SMTP is widely and robustly deployed, various extensions
+   have been requested by parts of the Internet community. In
+   particular, in the modern, international, and multilingual Internet a
+   need exists to assign codes to specific error conditions that can be
+   translated into different languages. RFC 1893 defines such a set of
+   status codes and RFC 1894 defines a mechanism to send such coded
+   material to users. However, in many cases the agent creating the RFC
+   1894 delivery status notification is doing so in response to errors
+   it received from a remote SMTP server.
+
+   As such, remote servers need a mechanism for embedding enhanced
+   status codes in their responses as well as a way to indicate to a
+   client when they are in fact doing this. This memo uses the SMTP
+   extension mechanism described in RFC 1869 to define such a mechanism.
+
+
+
+
+
+
+
+
+
+
+Freed                       Standards Track                     [Page 1]
+
+RFC 2034               SMTP Enhanced Error Codes            October 1996
+
+
+3.  Framework for the Enhanced Error Statuses Extension
+
+   The enhanced error statuses transport extension is laid out as
+   follows:
+
+   (1)   the name of the SMTP service extension defined here is
+         Enhanced-Status-Codes;
+
+   (2)   the EHLO keyword value associated with the extension is
+         ENHANCEDSTATUSCODES;
+
+   (3)   no parameter is used with the ENHANCEDSTATUSCODES EHLO
+         keyword;
+
+   (4)   the text part of all 2xx, 4xx, and 5xx SMTP responses
+         other than the initial greeting and any response to
+         HELO or EHLO are prefaced with a status code as defined
+         in RFC 1893. This status code is always followed by one
+         or more spaces.
+
+   (5)   no additional SMTP verbs are defined by this extension;
+         and,
+
+   (6)   the next section specifies how support for the
+         extension affects the behavior of a server and client
+         SMTP.
+
+4.  The Enhanced-Status-Codes service extension
+
+   Servers supporting the Enhanced-Status-Codes extension must preface
+   the text part of almost all response lines with a status code. As in
+   RFC 1893, the syntax of these status codes is given by the ABNF:
+
+        status-code ::= class "." subject "." detail
+        class       ::= "2" / "4" / "5"
+        subject     ::= 1*3digit
+        detail      ::= 1*3digit
+
+   These codes must appear in all 2xx, 4xx, and 5xx response lines other
+   than initial greeting and any response to HELO or EHLO. Note that 3xx
+   responses are NOT included in this list.
+
+   All status codes returned by the server must agree with the primary
+   response code, that is, a 2xx response must incorporate a 2.X.X code,
+   a 4xx response must incorporate a 4.X.X code, and a 5xx response must
+   incorporate a 5.X.X code.
+
+
+
+
+
+Freed                       Standards Track                     [Page 2]
+
+RFC 2034               SMTP Enhanced Error Codes            October 1996
+
+
+   When responses are continued across multiple lines the same status
+   code must appear at the beginning of the text in each line of the
+   response.
+
+   Servers supporting this extension must attach enhanced status codes
+   to their responses regardless of whether or not EHLO is employed by
+   the client.
+
+5.  Status Codes and Negotiation
+
+   This specification does not provide a means for clients to request
+   that status codes be returned or that they not be returned; a
+   compliant server includes these codes in the responses it sends
+   regardless of whether or not the client expects them.  This is
+   somewhat different from most other SMTP extensions, where generally
+   speaking a client must specifically make a request before the
+   extended server behaves any differently than an unextended server.
+   The omission of client negotiation in this case is entirely
+   intentional: Given the generally poor state of SMTP server error code
+   implementation it is felt that any step taken towards more
+   comprehensible error codes is something that all clients, extended or
+   not, should benefit from.
+
+   IMPORTANT NOTE:  The use of this approach in this extension should be
+   seen as a very special case.  It MUST NOT be taken as a license for
+   future SMTP extensions to dramatically change the nature of SMTP
+   client-server interaction without proper announcement from the server
+   and a corresponding enabling command from the client.
+
+6.  Usage Example
+
+   The following dialogue illustrates the use of enhanced status codes
+   by a server:
+
+   S: <wait for connection on TCP port 25>
+   C: <open connection to server>
+   S: 220 dbc.mtview.ca.us SMTP service ready
+   C: EHLO ymir.claremont.edu
+   S: 250-dbc.mtview.ca.us says hello
+   S: 250 ENHANCEDSTATUSCODES
+   C: MAIL FROM:<ned@ymir.claremont.edu>
+   S: 250 2.1.0 Originator <ned@ymir.claremont.edu> ok
+   C: RCPT TO:<mrose@dbc.mtview.ca.us>
+   S: 250 2.1.5 Recipient <mrose@dbc.mtview.ca.us> ok
+   C: RCPT TO:<nosuchuser@dbc.mtview.ca.us>
+   S: 550 5.1.1 Mailbox "nosuchuser" does not exist
+   C: RCPT TO:<remoteuser@isi.edu>
+   S: 551-5.7.1 Forwarding to remote hosts disabled
+
+
+
+Freed                       Standards Track                     [Page 3]
+
+RFC 2034               SMTP Enhanced Error Codes            October 1996
+
+
+   S: 551 5.7.1 Select another host to act as your forwarder
+   C: DATA
+   S: 354 Send message, ending in CRLF.CRLF.
+    ...
+   C: .
+   S: 250 2.6.0 Message accepted
+   C: QUIT
+   S: 221 2.0.0 Goodbye
+
+   The client that receives these responses might then send a
+   nondelivery notification of the general form:
+
+      Date: Mon, 11 Mar 1996 09:21:47 -0400
+      From: Mail Delivery Subsystem <mailer-daemon@ymir.claremont.edu>
+      Subject: Returned mail
+      To: <ned@ymir.claremont.edu>
+      MIME-Version: 1.0
+      Content-Type: multipart/report; report-type=delivery-status;
+            boundary="JAA13167.773673707/YMIR.CLAREMONT.EDU"
+
+      --JAA13167.773673707/YMIR.CLAREMONT.EDU
+      content-type: text/plain; charset=us-ascii
+
+         ----- Mail was successfully relayed to
+               the following addresses -----
+
+      <mrose@dbc.mtview.ca.us>
+
+         ----- The following addresses had delivery problems -----
+      <nosuchuser@dbc.mtview.ca.us>
+        (Mailbox "nosuchuser" does not exist)
+      <remoteuser@isi.edu>
+        (Forwarding to remote hosts disabled)
+
+      --JAA13167.773673707/YMIR.CLAREMONT.EDU
+      content-type: message/delivery-status
+
+      Reporting-MTA: dns; ymir.claremont.edu
+
+      Original-Recipient: rfc822;mrose@dbc.mtview.ca.us
+      Final-Recipient: rfc822;mrose@dbc.mtview.ca.us
+      Action: relayed
+      Status: 2.1.5 (Destination address valid)
+      Diagnostic-Code: smtp;
+       250 Recipient <mrose@dbc.mtview.ca.us> ok
+      Remote-MTA: dns; dbc.mtview.ca.us
+
+
+
+
+
+Freed                       Standards Track                     [Page 4]
+
+RFC 2034               SMTP Enhanced Error Codes            October 1996
+
+
+      Original-Recipient: rfc822;nosuchuser@dbc.mtview.ca.us
+      Final-Recipient: rfc822;nosuchuser@dbc.mtview.ca.us
+      Action: failed
+      Status: 5.1.1 (Bad destination mailbox address)
+      Diagnostic-Code: smtp;
+       550 Mailbox "nosuchuser" does not exist
+      Remote-MTA: dns; dbc.mtview.ca.us
+
+      Original-Recipient: rfc822;remoteuser@isi.edu
+      Final-Recipient: rfc822;remoteuser@isi.edu
+      Action: failed
+      Status: 5.7.1 (Delivery not authorized, message refused)
+      Diagnostic-Code: smtp;
+        551 Forwarding to remote hosts disabled
+        Select another host to act as your forwarder
+      Remote-MTA: dns; dbc.mtview.ca.us
+
+      --JAA13167.773673707/YMIR.CLAREMONT.EDU
+      content-type: message/rfc822
+
+      [original message goes here]
+      --JAA13167.773673707/YMIR.CLAREMONT.EDU--
+
+   Note that in order to reduce clutter the reporting MTA has omitted
+   enhanced status code information from the diagnostic-code fields it
+   has generated.
+
+7.  Security Considerations
+
+   Additional detail in server responses axiomatically provides
+   additional information about the server.  It is conceivable that
+   additional information of this sort may be of assistance in
+   circumventing server security.  The advantages of provides additional
+   information must always be weighed against the security implications
+   of doing so.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Freed                       Standards Track                     [Page 5]
+
+RFC 2034               SMTP Enhanced Error Codes            October 1996
+
+
+8.  References
+
+   [RFC-821]
+        Postel, J., "Simple Mail Transfer Protocol", RFC 821,
+        August, 1982.  (August, 1982).
+
+   [RFC-1869]
+        Rose, M., Stefferud, E., Crocker, C., Klensin, J., Freed,
+        N., "SMTP Service Extensions", RFC 1869, November, 1995.
+
+   [RFC-1893]
+        Vaudreuil, G., "Enhanced Mail System Status Codes", RFC
+        1893, January, 1996.
+
+   [RFC-1894]
+        Moore, K., Vaudreuil, G., "An Extensible Message Format
+        for Delivery Status Notifications", RFC 1894, January,
+        1996.
+
+9.  Author Address
+
+   Ned Freed
+   Innosoft International, Inc.
+   1050 East Garvey Avenue South
+   West Covina, CA 91790
+   USA
+    tel: +1 818 919 3600           fax: +1 818 919 3614
+    email: ned@innosoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Freed                       Standards Track                     [Page 6]
+
diff --git a/doc/devel/rfc/rfc2254.txt b/doc/devel/rfc/rfc2254.txt
new file mode 100644
index 00000000..323fdb00
--- /dev/null
+++ b/doc/devel/rfc/rfc2254.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                          T. Howes
+Request for Comments: 2254                Netscape Communications Corp.
+Category: Standards Track                                 December 1997
+
+
+            The String Representation of LDAP Search Filters
+
+1. 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.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1997).  All Rights Reserved.
+
+IESG Note
+
+   This document describes a directory access protocol that provides
+   both read and update access.  Update access requires secure
+   authentication, but this document does not mandate implementation of
+   any satisfactory authentication mechanisms.
+
+   In accordance with RFC 2026, section 4.4.1, this specification is
+   being approved by IESG as a Proposed Standard despite this
+   limitation, for the following reasons:
+
+   a. to encourage implementation and interoperability testing of
+      these protocols (with or without update access) before they
+      are deployed, and
+
+   b. to encourage deployment and use of these protocols in read-only
+      applications.  (e.g. applications where LDAPv3 is used as
+      a query language for directories which are updated by some
+      secure mechanism other than LDAP), and
+
+   c. to avoid delaying the advancement and deployment of other Internet
+      standards-track protocols which require the ability to query, but
+      not update, LDAPv3 directory servers.
+
+
+
+
+
+
+
+
+
+Howes                       Standards Track                     [Page 1]
+
+RFC 2254             String Representation of LDAP         December 1997
+
+
+   Readers are hereby warned that until mandatory authentication
+   mechanisms are standardized, clients and servers written according to
+   this specification which make use of update functionality are
+   UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION
+   IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL.
+
+   Implementors are hereby discouraged from deploying LDAPv3 clients or
+   servers which implement the update functionality, until a Proposed
+   Standard for mandatory authentication in LDAPv3 has been approved and
+   published as an RFC.
+
+2. Abstract
+
+   The Lightweight Directory Access Protocol (LDAP) [1] defines a
+   network representation of a search filter transmitted to an LDAP
+   server.  Some applications may find it useful to have a common way of
+   representing these search filters in a human-readable form.  This
+   document defines a human-readable string format for representing LDAP
+   search filters.
+
+   This document replaces RFC 1960, extending the string LDAP filter
+   definition to include support for LDAP version 3 extended match
+   filters, and including support for representing the full range of
+   possible LDAP search filters.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Howes                       Standards Track                     [Page 2]
+
+RFC 2254             String Representation of LDAP         December 1997
+
+
+3. LDAP Search Filter Definition
+
+   An LDAPv3 search filter is defined in Section 4.5.1 of [1] as
+   follows:
+
+        Filter ::= CHOICE {
+                and                [0] SET OF Filter,
+                or                 [1] SET OF Filter,
+                not                [2] Filter,
+                equalityMatch      [3] AttributeValueAssertion,
+                substrings         [4] SubstringFilter,
+                greaterOrEqual     [5] AttributeValueAssertion,
+                lessOrEqual        [6] AttributeValueAssertion,
+                present            [7] AttributeDescription,
+                approxMatch        [8] AttributeValueAssertion,
+                extensibleMatch    [9] MatchingRuleAssertion
+        }
+
+        SubstringFilter ::= SEQUENCE {
+                type    AttributeDescription,
+                SEQUENCE OF CHOICE {
+                        initial        [0] LDAPString,
+                        any            [1] LDAPString,
+                        final          [2] LDAPString
+                }
+        }
+
+        AttributeValueAssertion ::= SEQUENCE {
+                attributeDesc   AttributeDescription,
+                attributeValue  AttributeValue
+        }
+
+        MatchingRuleAssertion ::= SEQUENCE {
+                matchingRule    [1] MatchingRuleID OPTIONAL,
+                type            [2] AttributeDescription OPTIONAL,
+                matchValue      [3] AssertionValue,
+                dnAttributes    [4] BOOLEAN DEFAULT FALSE
+        }
+
+        AttributeDescription ::= LDAPString
+
+        AttributeValue ::= OCTET STRING
+
+        MatchingRuleID ::= LDAPString
+
+        AssertionValue ::= OCTET STRING
+
+        LDAPString ::= OCTET STRING
+
+
+
+Howes                       Standards Track                     [Page 3]
+
+RFC 2254             String Representation of LDAP         December 1997
+
+
+   where the LDAPString above is limited to the UTF-8 encoding of the
+   ISO 10646 character set [4].  The AttributeDescription is a string
+   representation of the attribute description and is defined in [1].
+   The AttributeValue and AssertionValue OCTET STRING have the form
+   defined in [2].  The Filter is encoded for transmission over a
+   network using the Basic Encoding Rules defined in [3], with
+   simplifications described in [1].
+
+4. String Search Filter Definition
+
+   The string representation of an LDAP search filter is defined by the
+   following grammar, following the ABNF notation defined in [5].  The
+   filter format uses a prefix notation.
+
+        filter     = "(" filtercomp ")"
+        filtercomp = and / or / not / item
+        and        = "&" filterlist
+        or         = "|" filterlist
+        not        = "!" filter
+        filterlist = 1*filter
+        item       = simple / present / substring / extensible
+        simple     = attr filtertype value
+        filtertype = equal / approx / greater / less
+        equal      = "="
+        approx     = "~="
+        greater    = ">="
+        less       = "<="
+        extensible = attr [":dn"] [":" matchingrule] ":=" value
+                     / [":dn"] ":" matchingrule ":=" value
+        present    = attr "=*"
+        substring  = attr "=" [initial] any [final]
+        initial    = value
+        any        = "*" *(value "*")
+        final      = value
+        attr       = AttributeDescription from Section 4.1.5 of [1]
+        matchingrule = MatchingRuleId from Section 4.1.9 of [1]
+        value      = AttributeValue from Section 4.1.6 of [1]
+
+   The attr, matchingrule, and value constructs are as described in the
+   corresponding section of [1] given above.
+
+
+
+
+
+
+
+
+
+
+
+Howes                       Standards Track                     [Page 4]
+
+RFC 2254             String Representation of LDAP         December 1997
+
+
+   If a value should contain any of the following characters
+
+           Character       ASCII value
+           ---------------------------
+           *               0x2a
+           (               0x28
+           )               0x29
+           \               0x5c
+           NUL             0x00
+
+   the character must be encoded as the backslash '\' character (ASCII
+   0x5c) followed by the two hexadecimal digits representing the ASCII
+   value of the encoded character. The case of the two hexadecimal
+   digits is not significant.
+
+   This simple escaping mechanism eliminates filter-parsing ambiguities
+   and allows any filter that can be represented in LDAP to be
+   represented as a NUL-terminated string. Other characters besides the
+   ones listed above may be escaped using this mechanism, for example,
+   non-printing characters.
+
+   For example, the filter checking whether the "cn" attribute contained
+   a value with the character "*" anywhere in it would be represented as
+   "(cn=*\2a*)".
+
+   Note that although both the substring and present productions in the
+   grammar above can produce the "attr=*" construct, this construct is
+   used only to denote a presence filter.
+
+5. Examples
+
+   This section gives a few examples of search filters written using
+   this notation.
+
+        (cn=Babs Jensen)
+        (!(cn=Tim Howes))
+        (&(objectClass=Person)(|(sn=Jensen)(cn=Babs J*)))
+        (o=univ*of*mich*)
+
+   The following examples illustrate the use of extensible matching.
+
+        (cn:1.2.3.4.5:=Fred Flintstone)
+        (sn:dn:2.4.6.8.10:=Barney Rubble)
+        (o:dn:=Ace Industry)
+        (:dn:2.4.6.8.10:=Dino)
+
+
+
+
+
+
+Howes                       Standards Track                     [Page 5]
+
+RFC 2254             String Representation of LDAP         December 1997
+
+
+   The second example illustrates the use of the ":dn" notation to
+   indicate that matching rule "2.4.6.8.10" should be used when making
+   comparisons, and that the attributes of an entry's distinguished name
+   should be considered part of the entry when evaluating the match.
+
+   The third example denotes an equality match, except that DN
+   components should be considered part of the entry when doing the
+   match.
+
+   The fourth example is a filter that should be applied to any
+   attribute supporting the matching rule given (since the attr has been
+   left off). Attributes supporting the matching rule contained in the
+   DN should also be considered.
+
+   The following examples illustrate the use of the escaping mechanism.
+
+        (o=Parens R Us \28for all your parenthetical needs\29)
+        (cn=*\2A*)
+        (filename=C:\5cMyFile)
+        (bin=\00\00\00\04)
+        (sn=Lu\c4\8di\c4\87)
+
+   The first example shows the use of the escaping mechanism to
+   represent parenthesis characters. The second shows how to represent a
+   "*" in a value, preventing it from being interpreted as a substring
+   indicator. The third illustrates the escaping of the backslash
+   character.
+
+   The fourth example shows a filter searching for the four-byte value
+   0x00000004, illustrating the use of the escaping mechanism to
+   represent arbitrary data, including NUL characters.
+
+   The final example illustrates the use of the escaping mechanism to
+   represent various non-ASCII UTF-8 characters.
+
+6. Security Considerations
+
+   This memo describes a string representation of LDAP search filters.
+   While the representation itself has no known security implications,
+   LDAP search filters do. They are interpreted by LDAP servers to
+   select entries from which data is retrieved.  LDAP servers should
+   take care to protect the data they maintain from unauthorized access.
+
+
+
+
+
+
+
+
+
+Howes                       Standards Track                     [Page 6]
+
+RFC 2254             String Representation of LDAP         December 1997
+
+
+7. References
+
+   [1] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access
+   Protocol (v3)", RFC 2251, December 1997.
+
+   [2] Wahl, M., Coulbeck, A., Howes, T., and S. Kille, "Lightweight
+   Directory Access Protocol (v3): Attribute Syntax Definitions", RFC
+   2252, December 1997.
+
+   [3] Specification of ASN.1 encoding rules: Basic, Canonical, and
+   Distinguished Encoding Rules, ITU-T Recommendation X.690, 1994.
+
+   [4] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO
+   10646", RFC 2044, October 1996.
+
+   [5] Crocker, D., "Standard for the Format of ARPA Internet Text
+   Messages", STD 11, RFC 822, August 1982.
+
+8. Author's Address
+
+   Tim Howes
+   Netscape Communications Corp.
+   501 E. Middlefield Road
+   Mountain View, CA 94043
+   USA
+
+   Phone: +1 415 937-3419
+   EMail: howes@netscape.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Howes                       Standards Track                     [Page 7]
+
+RFC 2254             String Representation of LDAP         December 1997
+
+
+9. Full Copyright Statement
+
+   Copyright (C) The Internet Society (1997).  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
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Howes                       Standards Track                     [Page 8]
+
diff --git a/doc/devel/rfc/rfc2476.txt b/doc/devel/rfc/rfc2476.txt
new file mode 100644
index 00000000..0c5c17dc
--- /dev/null
+++ b/doc/devel/rfc/rfc2476.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Network Working Group                                        R. Gellens
+Request for Comments: 2476                                     QUALCOMM
+Category: Standards Track                                    J. Klensin
+                                                                    MCI
+                                                          December 1998
+
+
+                           Message Submission
+
+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.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+Table of Contents
+
+    1.  Abstract . . . . . . . . . . . . . . . . . . . . . . . . . .  2
+    2.  Document Information  . . . . . . . . . . . . . . . . . . .   3
+      2.1.  Definitions of Terms Used in this Memo . . . . . . . . .  3
+      2.2.  Conventions Used in this Document . . . . . . . . . . .   4
+    3.  Message Submission . . . . . . . . . . . . . . . . . . . . .  4
+      3.1.  Submission Identification . . . . . . . . . . . . . . .   4
+      3.2.  Message Rejection and Bouncing . . . . . . . . . . . . .  4
+      3.3.  Authorized Submission . . . . . . . . . . . . . . . . .   5
+      3.4.  Enhanced Status Codes  . . . . . . . . . . . . . . . . .  6
+    4.  Mandatory Actions . . . . . . . . . . . . . . . . . . . . .   6
+      4.1.  General Submission Rejection Code  . . . . . . . . . . .  6
+      4.2.  Ensure All Domains are Fully-Qualified  . . . . . . . .   6
+    5.  Recommended Actions  . . . . . . . . . . . . . . . . . . . .  7
+      5.1.  Enforce Address Syntax  . . . . . . . . . . . . . . . .   7
+      5.2.  Log Errors . . . . . . . . . . . . . . . . . . . . . . .  7
+    6.  Optional Actions  . . . . . . . . . . . . . . . . . . . . .   7
+      6.1.  Enforce Submission Rights  . . . . . . . . . . . . . . .  7
+      6.2.  Require Authentication  . . . . . . . . . . . . . . . .   8
+      6.3.  Enforce Permissions  . . . . . . . . . . . . . . . . . .  8
+      6.4.  Check Message Data  . . . . . . . . . . . . . . . . . .   8
+    7.  Interaction with SMTP Extensions . . . . . . . . . . . . . .  8
+    8.  Message Modifications . . . . . . . . . . . . . . . . . . .   9
+      8.1.  Add 'Sender' . . . . . . . . . . . . . . . . . . . . . .  9
+      8.2.  Add 'Date'  . . . . . . . . . . . . . . . . . . . . . .  10
+      8.3.  Add 'Message-ID' . . . . . . . . . . . . . . . . . . . . 10
+
+
+
+Gellens & Klensin           Standards Track                     [Page 1]
+
+RFC 2476                   Message Submission              December 1998
+
+
+      8.4.  Transfer Encode . . . . . . . . . . . . . . . . . . . .  10
+      8.5.  Sign the Message . . . . . . . . . . . . . . . . . . . . 10
+      8.6.  Encrypt the Message . . . . . . . . . . . . . . . . . .  10
+      8.7.  Resolve Aliases  . . . . . . . . . . . . . . . . . . . . 10
+      8.8.  Header Rewriting  . . . . . . . . . . . . . . . . . . .  10
+    9.  Security Considerations  . . . . . . . . . . . . . . . . . . 11
+   10.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . .  11
+   11.  References . . . . . . . . . . . . . . . . . . . . . . . . . 12
+   12.  Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14
+   13.  Full Copyright Statement  . . . . . . . . . . . . . . . . .  15
+
+1.  Abstract
+
+   SMTP was defined as a message *transfer* protocol, that is, a means
+   to route (if needed) and deliver finished (complete) messages.
+   Message Transfer Agents (MTAs) are not supposed to alter the message
+   text, except to add 'Received', 'Return-Path', and other header
+   fields as required by [SMTP-MTA].
+
+   However, SMTP is now also widely used as a message *submission*
+   protocol, that is, a means for message user agents (MUAs) to
+   introduce new messages into the MTA routing network.  The process
+   which accepts message submissions from MUAs is termed a Message
+   Submission Agent (MSA).
+
+   Messages being submitted are in some cases finished (complete)
+   messages, and in other cases are unfinished (incomplete) in some
+   aspect or other.  Unfinished messages need to be completed to ensure
+   they conform to [MESSAGE-FORMAT], and later requirements.  For
+   example, the message may lack a proper 'Date' header field, and
+   domains might not be fully qualified.  In some cases, the MUA may be
+   unable to generate finished messages (for example, it might not know
+   its time zone).  Even when submitted messages are complete, local
+   site policy may dictate that the message text be examined or modified
+   in some way.  Such completions or modifications have been shown to
+   cause harm when performed by downstream MTAs -- that is, MTAs after
+   the first-hop submission MTA -- and are in general considered to be
+   outside the province of standardized MTA functionality.
+
+   Separating messages into submissions and transfers allows developers
+   and network administrators to more easily:
+
+   *   Implement security policies and guard against unauthorized mail
+       relaying or injection of unsolicited bulk mail
+
+   *   Implement authenticated submission, including off-site submission
+       by authorized users such as travelers
+
+
+
+
+Gellens & Klensin           Standards Track                     [Page 2]
+
+RFC 2476                   Message Submission              December 1998
+
+
+   *   Separate the relevant software code differences, thereby making
+       each code base more straightforward and allowing for different
+       programs for relay and submission
+
+   *   Detect configuration problems with a site's mail clients
+
+   *   Provide a basis for adding enhanced submission services in the
+       future
+
+   This memo describes a low cost, deterministic means for messages to
+   be identified as submissions, and specifies what actions are to be
+   taken by a submission server.
+
+   Public comments should be sent to the IETF Submit mailing list,
+   <ietf-submit@imc.org>.  To subscribe, send a message containing
+   SUBSCRIBE to <ietf-submit-request@imc.org>.  Private comments may be
+   sent to the authors.
+
+2.  Document Information
+
+2.1.  Definitions of Terms Used in this Memo
+
+   Fully-Qualified
+
+   Containing or consisting of a domain which can be globally resolved
+   using the global Domain Name Service; that is, not a local alias or
+   partial specification.
+
+   Message Submission Agent (MSA)
+
+   A process which conforms to this specification, which acts as a
+   submission server to accept messages from MUAs, and either delivers
+   them or acts as an SMTP client to relay them to an MTA.
+
+   Message Transfer Agent (MTA)
+
+   A process which conforms to [SMTP-MTA], which acts as an SMTP server
+   to accept messages from an MSA or another MTA, and either delivers
+   them or acts as an SMTP client to relay them to another MTA.
+
+   Message User Agent (MUA)
+
+   A process which acts (usually on behalf of a user) to compose and
+   submit new messages, and process delivered messages.  In the split-
+   MUA model, POP or IMAP is used to access delivered messages.
+
+
+
+
+
+
+Gellens & Klensin           Standards Track                     [Page 3]
+
+RFC 2476                   Message Submission              December 1998
+
+
+2.2.  Conventions Used in this Document
+
+   In examples, "C:" is used to indicate lines sent by the client, and
+   "S:" indicates those sent by the server.  Line breaks within a
+   command example are for editorial purposes only.
+
+   Examples use the 'example.net' domain.
+
+   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
+   in this document are to be interpreted as defined in [KEYWORDS].
+
+3.  Message Submission
+
+3.1.  Submission Identification
+
+   Port 587 is reserved for email message submission as specified in
+   this document.  Messages received on this port are defined to be
+   submissions.  The protocol used is ESMTP [SMTP-MTA, ESMTP], with
+   additional restrictions as specified here.
+
+   While most email clients and servers can be configured to use port
+   587 instead of 25, there are cases where this is not possible or
+   convenient.  A site MAY choose to use port 25 for message submission,
+   by designating some hosts to be MSAs and others to be MTAs.
+
+3.2.  Message Rejection and Bouncing
+
+   MTAs and MSAs MAY implement message rejection rules that rely in part
+   on whether the message is a submission or a relay.
+
+   For example, some sites might configure their MTA to reject all RCPT
+   TOs for messages that do not reference local users, and configure
+   their MSA to reject all message submissions that do not come from
+   authorized users, based on IP address, or authenticated identity.
+
+   NOTE:  It is better to reject a message than to risk sending one that
+   is damaged.  This is especially true for problems that are
+   correctable by the MUA, for example, an invalid 'From' field.
+
+   If an MSA is not able to determine a return path to the submitting
+   user, from a valid MAIL FROM, a valid source IP address, or based on
+   authenticated identity, then the MSA SHOULD immediately reject the
+   message.  A message can be immediately rejected by returning a 550
+   code to the MAIL FROM command.
+
+
+
+
+
+
+
+Gellens & Klensin           Standards Track                     [Page 4]
+
+RFC 2476                   Message Submission              December 1998
+
+
+   Note that a null return path, that is, MAIL FROM:<>, is permitted
+   and MUST be accepted. (MUAs need to generate null return-path
+   messages for a variety of reasons, including disposition
+   notifications.)
+
+   Except in the case where the MSA is unable to determine a valid
+   return path for the message being submitted, text in this
+   specification which instructs an MSA to issue a rejection code MAY be
+   complied with by accepting the message and subsequently generating a
+   bounce message. (That is, if the MSA is going to reject a message for
+   any reason except being unable to determine a return path, it can
+   optionally do an immediate rejection or accept the message and then
+   mail a bounce.)
+
+   NOTE:  In the normal case of message submission, immediately
+   rejecting the message is preferred, as it gives the user and MUA
+   direct feedback.  To properly handle delayed bounces the client MUA
+   must maintain a queue of messages it has submitted, and match bounces
+   to them.
+
+3.3.  Authorized Submission
+
+   Numerous methods have been used to ensure that only authorized users
+   are able to submit messages.  These methods include authenticated
+   SMTP, IP address restrictions, secure IP, and prior POP
+   authentication.
+
+   Authenticated SMTP [SMTP-AUTH] has been proposed.  It allows the MSA
+   to determine an authorization identity for the message submission,
+   which is not tied to other protocols.
+
+   IP address restrictions are very widely implemented, but do not allow
+   for travellers and similar situations, and can be spoofed.
+
+   Secure IP [IPSEC] can also be used, and provides additional benefits
+   of protection against eavesdropping and traffic analysis.
+
+   Requiring a POP [POP3] authentication (from the same IP address)
+   within some amount of time (for example, 20 minutes) prior to the
+   start of a message submission session has also been used, but this
+   does impose restrictions on clients as well as servers which may
+   cause difficulties.  Specifically, the client must do a POP
+   authentication before an SMTP submission session, and not all clients
+   are capable and configured for this.  Also, the MSA must coordinate
+   with the POP server, which may be difficult.  There is also a window
+   during which an unauthorized user can submit messages and appear to
+   be a prior authorized user.
+
+
+
+
+Gellens & Klensin           Standards Track                     [Page 5]
+
+RFC 2476                   Message Submission              December 1998
+
+
+3.4.  Enhanced Status Codes
+
+   This memo suggests several enhanced status codes [SMTP-CODES] for
+   submission-specific rejections.  The specific codes used are:
+
+    5.6.0  Bad content.  The content of the header or text is
+           improper.
+
+    5.6.2  Bad domain or address.  Invalid or improper domain or address
+           in MAIL FROM, RCPT TO, or DATA.
+
+    5.7.1  Not allowed.  The address in MAIL FROM appears to have
+           insufficient submission rights, or is invalid, or is not
+           authorized with the authentication used; the address in a
+           RCPT TO command is inconsistent with the permissions given to
+           the user; the message data is rejected based on the
+           submitting user.
+
+    5.7.0  Site policy.  The message appears to violate site policy in
+           some way.
+
+4.  Mandatory Actions
+
+   An MSA MUST do all of the following:
+
+4.1.  General Submission Rejection Code
+
+   Unless covered by a more precise response code, response code 554 is
+   to be used to reject a MAIL FROM, RCPT TO, or DATA command that
+   contains something improper.  Enhanced status code 5.6.0 is to be
+   used if no other code is more specific.
+
+4.2.  Ensure All Domains are Fully-Qualified
+
+   The MSA MUST ensure that all domains in the envelope are fully-
+   qualified.
+
+   If the MSA examines or alters the message text in way, except to add
+   trace header fields [SMTP-MTA], it MUST ensure that all domains in
+   address header fields are fully-qualified.
+
+   Reply code 554 is to be used to reject a MAIL FROM, RCPT TO, or DATA
+   command which contains improper domain references.
+
+   NOTE:  A frequent local convention is to accept single-level domains
+   (for example, 'sales') and then to expand the reference by adding the
+   remaining portion of the domain name (for example, to
+
+
+
+
+Gellens & Klensin           Standards Track                     [Page 6]
+
+RFC 2476                   Message Submission              December 1998
+
+
+   'sales.example.net').  Local conventions that permit single-level
+   domains SHOULD reject, rather than expand, incomplete multi-level
+   domains, since such expansion is particularly risky.
+
+5.  Recommended Actions
+
+   The MSA SHOULD do all of the following:
+
+5.1.  Enforce Address Syntax
+
+   An MSA SHOULD reject messages with illegal syntax in a sender or
+   recipient envelope address.
+
+   If the MSA examines or alters the message text in way, except to add
+   trace header fields, it SHOULD reject messages with illegal address
+   syntax in address header fields.
+
+   Reply code 501 is to be used to reject a MAIL FROM or RCPT TO command
+   that contains a detectably improper address.
+
+   When addresses are resolved after submission of the message body,
+   reply code 554 with enhanced status code 5.6.2 is to be used after
+   end-of-data, if the message contains invalid addresses in the header.
+
+5.2.  Log Errors
+
+   The MSA SHOULD log message errors, especially apparent
+   misconfigurations of client software.
+
+   Note:  It can be very helpful to notify the administrator when
+   problems are detected with local mail clients.  This is another
+   advantage of distinguishing submission from relay: system
+   administrators might be interested in local configuration problems,
+   but not in client problems at other sites.
+
+6.  Optional Actions
+
+   The MSA MAY do any of the following:
+
+6.1.  Enforce Submission Rights
+
+   The MSA MAY issue an error response to the MAIL FROM command if the
+   address in MAIL FROM appears to have insufficient submission rights,
+   or is not authorized with the authentication used (if the session has
+   been authenticated).
+
+   Reply code 550 with enhanced status code 5.7.1 is used for this
+   purpose.
+
+
+
+Gellens & Klensin           Standards Track                     [Page 7]
+
+RFC 2476                   Message Submission              December 1998
+
+
+6.2.  Require Authentication
+
+   The MSA MAY issue an error response to the MAIL FROM command if the
+   session has not been authenticated.
+
+   Section 3.3 discusses authentication mechanisms.
+
+   Reply code 530 [SMTP-AUTH] is used for this purpose.
+
+6.3.  Enforce Permissions
+
+   The MSA MAY issue an error response to the RCPT TO command if
+   inconsistent with the permissions given to the user (if the session
+   has been authenticated).
+
+   Reply code 550 with enhanced status code 5.7.1 is used for this
+   purpose.
+
+6.4.  Check Message Data
+
+   The MSA MAY issue an error response to the DATA command or send a
+   failure result after end-of-data if the submitted message is
+   syntactically invalid, or seems inconsistent with permissions given
+   to the user (if known), or violates site policy in some way.
+
+   Reply code 554 is used for syntactic problems in the data.  Reply
+   code 501 is used if the command itself is not syntactically valid.
+   Reply code 550 with enhanced status code 5.7.1 is used to reject
+   based on the submitting user.  Reply code 550 with enhanced status
+   code 5.7.0 is used if the message violates site policy.
+
+7.  Interaction with SMTP Extensions
+
+   The following table lists the current standards-track and
+   Experimental SMTP extensions.  Listed are the RFC, name, an
+   indication as to the use of the extension on the submit port, and a
+   reference:
+
+   RFC   Name             Submission  Reference
+   ----  ---------------  ----------  ------------------
+   2197  Pipelining         SHOULD    [PIPELINING]
+   2034  Error Codes        SHOULD    [CODES-EXTENSION]
+   1985  ETRN              MUST NOT   [ETRN]
+   1893  Extended Codes     SHOULD    [SMTP-CODES]
+   1891  DSN                SHOULD    [DSN]
+   1870  Size                MAY      [SIZE]
+   1846  521               MUST NOT   [521REPLY]
+   1845  Checkpoint          MAY      [Checkpoint]
+
+
+
+Gellens & Klensin           Standards Track                     [Page 8]
+
+RFC 2476                   Message Submission              December 1998
+
+
+   1830  Binary              MAY      [CHUNKING]
+   1652  8-bit MIME         SHOULD    [8BITMIME]
+   ----  Authentication     ------    [SMTP-AUTH]
+
+   Future SMTP extensions should explicitly specify if they are valid on
+   the Submission port.
+
+   Some SMTP extensions are especially useful for message submission:
+
+   Extended Status Codes [SMTP-CODES], SHOULD be supported and used
+   according to [CODES-EXTENSION].  This permits the MSA to notify the
+   client of specific configuration or other problems in more detail
+   than the response codes listed in this memo.  Because some rejections
+   are related to a site's security policy, care should be used not to
+   expose more detail than is needed to correct the problem.
+
+   [PIPELINING] SHOULD be supported by the MSA.
+
+   [SMTP-AUTH] allows the MSA to validate the authority and determine
+   the identity of the submitting user.
+
+   Any references to the DATA command in this memo also refer to any
+   substitutes for DATA, such as the BDAT command used with [CHUNKING].
+
+8.  Message Modifications
+
+   Sites MAY modify submissions to ensure compliance with standards and
+   site policy.  This section describes a number of such modifications
+   that are often considered useful.
+
+   NOTE:  As a matter of guidance for local decisions to implement
+   message modification, a paramount rule is to limit such actions to
+   remedies for specific problems that have clear solutions.  This is
+   especially true with address elements.  For example, indiscriminately
+   appending a domain to an address or element which lacks one typically
+   results in more broken addresses.  An unqualified address must be
+   verified to be a valid local part in the domain before the domain can
+   be safely added.
+
+8.1.  Add 'Sender'
+
+   The MSA MAY add or replace the 'Sender' field, if the identity of the
+   sender is known and this is not given in the 'From' field.
+
+   The MSA MUST ensure that any address it places in a 'Sender' field is
+   in fact a valid mail address.
+
+
+
+
+
+Gellens & Klensin           Standards Track                     [Page 9]
+
+RFC 2476                   Message Submission              December 1998
+
+
+8.2.  Add 'Date'
+
+   The MSA MAY add a 'Date' field to the submitted message, if it lacks
+   it, or correct the 'Date' field if it does not conform to [MESSAGE-
+   FORMAT] syntax.
+
+8.3.  Add 'Message-ID'
+
+   The MSA MAY add or replace the 'Message-ID' field, if it lacks it, or
+   it is not valid syntax (as defined by [MESSAGE-FORMAT]).
+
+8.4.  Transfer Encode
+
+   The MSA MAY apply transfer encoding to the message according to MIME
+   conventions, if needed and not harmful to the MIME type.
+
+8.5.  Sign the Message
+
+   The MSA MAY (digitally) sign or otherwise add authentication
+   information to the message.
+
+8.6.  Encrypt the Message
+
+   The MSA MAY encrypt the message for transport to reflect
+   organizational policies.
+
+   NOTE:  To be useful, the addition of a signature and/or encryption by
+   the MSA generally implies that the connection between the MUA and MSA
+   must itself be secured in some other way, e.g., by operating inside
+   of a secure environment, by securing the submission connection at the
+   transport layer, or by using an [SMTP-AUTH] mechanism that provides
+   for session integrity.
+
+8.7.  Resolve Aliases
+
+   The MSA MAY resolve aliases (CNAME records) for domain names, in the
+   envelope and optionally in address fields of the header, subject to
+   local policy.
+
+   NOTE:  Unconditionally resolving aliases could be harmful.  For
+   example, if www.example.net and ftp.example.net are both aliases for
+   mail.example.net, rewriting them could lose useful information.
+
+8.8.  Header Rewriting
+
+   The MSA MAY rewrite local parts and/or domains, in the envelope and
+   optionally in address fields of the header, according to local
+   policy.  For example, a site may prefer to rewrite 'JRU' as '
+
+
+
+Gellens & Klensin           Standards Track                    [Page 10]
+
+RFC 2476                   Message Submission              December 1998
+
+
+   J.Random.User' in order to hide logon names, and/or to rewrite '
+   squeeky.sales.example.net' as 'zyx.example.net' to hide machine names
+   and make it easier to move users.
+
+   However, only addresses, local-parts, or domains which match specific
+   local MSA configuration settings should be altered.  It would be very
+   dangerous for the MSA to apply data-independent rewriting rules, such
+   as always deleting the first element of a domain name.  So, for
+   example, a rule which strips the left-most element of the domain if
+   the complete domain matches '*.foo.example.net' would be acceptable.
+
+9.  Security Considerations
+
+   Separation of submission and relay of messages can allow a site to
+   implement different policies for the two types of services, including
+   requiring use of additional security mechanisms for one or both.  It
+   can do this in a way which is simpler, both technically and
+   administratively.  This increases the likelihood that policies will
+   be applied correctly.
+
+   Separation also can aid in tracking and preventing unsolicited bulk
+   email.
+
+   For example, a site could configure its MSA to require authentication
+   before accepting a message, and could configure its MTA to reject all
+   RCPT TOs for non-local users.  This can be an important element in a
+   site's total email security policy.
+
+   If a site fails to require any form of authorization for message
+   submissions (see section 3.3 for discussion), it is allowing open use
+   of its resources and name; unsolicited bulk email can be injected
+   using its facilities.
+
+10.  Acknowledgments
+
+   This updated memo has been revised in part based on comments and
+   discussions which took place on and off the IETF-Submit mailing list.
+   The help of those who took the time to review the draft and make
+   suggestions is appreciated, especially that of Dave Crocker, Ned
+   Freed, Keith Moore, John Myers, and Chris Newman.
+
+   Special thanks to Harald Alvestrand, who got this effort started.
+
+
+
+
+
+
+
+
+
+Gellens & Klensin           Standards Track                    [Page 11]
+
+RFC 2476                   Message Submission              December 1998
+
+
+11.  References
+
+   [521REPLY]        Durand, A. and F. Dupont, "SMTP 521 Reply Code",
+                     RFC 1846, September 1995.
+
+   [8BITMIME]        Klensin, J., Freed, N., Rose, M., Stefferud, E. and
+                     D.  Crocker, "SMTP Service Extension for 8bit-
+                     MIMEtransport", RFC 1652, July 1994.
+
+   [ABNF]            Crocker, D., Ed. and P. Overell, "Augmented BNF for
+                     Syntax Specifications: ABNF", RFC 2234, November
+                     1997.
+
+   [CHECKPOINT]      Crocker, D., Freed, N. and A. Cargille, "SMTP
+                     Service Extension for Checkpoint/Restart", RFC
+                     1845, September 1995.
+
+   [CHUNKING]        Vaudreuil, G., "SMTP Service Extensions for
+                     Transmission of Large and Binary MIME Messages",
+                     RFC 1830, August 1995.
+
+   [CODES-EXTENSION] Freed, N., "SMTP Service Extension for Returning
+                     Enhanced Error Codes", RFC 2034, October 1996.
+
+   [DSN]             Moore, K., "SMTP Service Extension for Delivery
+                     Status Notifications", RFC 1891, January 1996.
+
+   [ESMTP]           Klensin, J., Freed, N., Rose, M., Stefferud, E. and
+                     D. Crocker, "SMTP Service Extensions", STD 10, RFC
+                     1869, November 1995.
+
+   [ETRN]            De Winter, J., "SMTP Service Extension for Remote
+                     Message Queue Starting", RFC 1985, August 1996.
+
+   [HEADERS]         Palme, J., "Common Internet Message Headers", RFC
+                     2076, February 1997.
+
+   [IPSEC]           Atkinson, R., "Security Architecture for the
+                     Internet Protocol", RFC 1825, August 1995.
+
+   [KEYWORDS]        Bradner, S., "Key words for use in RFCs to Indicate
+                     Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+
+
+
+
+
+Gellens & Klensin           Standards Track                    [Page 12]
+
+RFC 2476                   Message Submission              December 1998
+
+
+   [MESSAGE-FORMAT]  Crocker, D., "Standard for the format of ARPA
+                     Internet text messages", STD 11, RFC 822, August
+                     1982;
+
+                     Braden, R., Editor, "Requirements for Internet
+                     Hosts -- Application and Support", STD 3, RFC 1123,
+                     October 1989.
+
+   [PIPELINING]      Freed, N., "SMTP Service Extension for Command
+                     Pipelining", RFC 2197, September 1997.
+
+   [POP3]            Myers, J. and M. Rose, "Post Office Protocol --
+                     Version 3", STD 53, RFC 1939, May 1996.
+
+   [SIZE]            Klensin, J., Freed, N. and K. Moore, "SMTP Service
+                     Extension for Message Size Declaration", STD 10,
+                     RFC 1870, November 1995.
+
+   [SMTP-AUTH]       Myers, J., "SMTP Service Extension for
+                     Authentication", Work in Progress.
+
+   [SMTP-CODES]      Vaudreuil, G., "Enhanced Mail System Status Codes",
+                     RFC 1893, January 1996.
+
+   [SMTP-MTA]        Postel, J., "Simple Mail Transfer Protocol", STD
+                     10, RFC 821, August 1982.
+
+                     Partridge, C., "Mail Routing and the Domain
+                     System", STD 14, RFC 974, January 1986.
+
+                     Braden, R., Editor, "Requirements for Internet
+                     Hosts -- Application and Support", STD 3, RFC 1123,
+                     October 1989.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gellens & Klensin           Standards Track                    [Page 13]
+
+RFC 2476                   Message Submission              December 1998
+
+
+12.  Authors' Addresses
+
+   Randall Gellens
+   QUALCOMM Incorporated
+   6455 Lusk Blvd.
+   San Diego, CA  92121-2779
+   U.S.A.
+
+   Phone: +1 619 651 5115
+   Fax:   +1 619 651 5334
+   EMail: Randy@Qualcomm.Com
+
+
+   John C. Klensin
+   MCI Telecommunications
+   800 Boylston St, 7th floor
+   Boston, MA 02199
+   USA
+
+   Phone: +1 617 960 1011
+   EMail: klensin@mci.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gellens & Klensin           Standards Track                    [Page 14]
+
+RFC 2476                   Message Submission              December 1998
+
+
+13.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1998).  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
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gellens & Klensin           Standards Track                    [Page 15]
+
diff --git a/doc/devel/rfc/rfc2487.txt b/doc/devel/rfc/rfc2487.txt
new file mode 100644
index 00000000..fb1305f0
--- /dev/null
+++ b/doc/devel/rfc/rfc2487.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                     P. Hoffman
+Request for Comments: 2487                  Internet Mail Consortium
+Category: Standards Track                               January 1999
+
+
+            SMTP Service Extension for Secure SMTP over TLS
+
+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.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+1. Abstract
+
+   This document describes an extension to the SMTP service that allows
+   an SMTP server and client to use transport-layer security to provide
+   private, authenticated communication over the Internet. This gives
+   SMTP agents the ability to protect some or all of their
+   communications from eavesdroppers and attackers.
+
+2. Introduction
+
+   SMTP [RFC-821] servers and clients normally communicate in the clear
+   over the Internet. In many cases, this communication goes through one
+   or more router that is not controlled or trusted by either entity.
+   Such an untrusted router might allow a third party to monitor or
+   alter the communications between the server and client.
+
+   Further, there is often a desire for two SMTP agents to be able to
+   authenticate each others' identities. For example, a secure SMTP
+   server might only allow communications from other SMTP agents it
+   knows, or it might act differently for messages received from an
+   agent it knows than from one it doesn't know.
+
+   TLS [TLS], more commonly known as SSL, is a popular mechanism for
+   enhancing TCP communications with privacy and authentication. TLS is
+   in wide use with the HTTP protocol, and is also being used for adding
+   security to many other common protocols that run over TCP.
+
+
+
+
+
+
+Hoffman                     Standards Track                     [Page 1]
+
+RFC 2487                 SMTP Service Extension             January 1999
+
+
+2.1 Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC-2119].
+
+3. STARTTLS Extension
+
+   The STARTTLS extension to SMTP is laid out as follows:
+
+   (1) the name of the SMTP service defined here is STARTTLS;
+
+   (2) the EHLO keyword value associated with the extension is STARTTLS;
+
+   (3) the STARTTLS keyword has no parameters;
+
+   (4) a new SMTP verb, "STARTTLS", is defined;
+
+   (5) no additional parameters are added to any SMTP command.
+
+4. The STARTTLS Keyword
+
+   The STARTTLS keyword is used to tell the SMTP client that the SMTP
+   server allows use of TLS. It takes no parameters.
+
+5. The STARTTLS Command
+
+   The format for the STARTTLS command is:
+
+   STARTTLS
+
+   with no parameters.
+
+   After the client gives the STARTTLS command, the server responds with
+   one of the following reply codes:
+
+   220 Ready to start TLS
+   501 Syntax error (no parameters allowed)
+   454 TLS not available due to temporary reason
+
+   A publicly-referenced SMTP server MUST NOT require use of the
+   STARTTLS extension in order to deliver mail locally. This rule
+   prevents the STARTTLS extension from damaging the interoperability of
+   the Internet's SMTP infrastructure. A publicly-referenced SMTP server
+   is an SMTP server which runs on port 25 of an Internet host listed in
+   the MX record (or A record if an MX record is not present) for the
+   domain name on the right hand side of an Internet mail address.
+
+
+
+
+Hoffman                     Standards Track                     [Page 2]
+
+RFC 2487                 SMTP Service Extension             January 1999
+
+
+   Any SMTP server may refuse to accept messages for relay based on
+   authentication supplied during the TLS negotiation. An SMTP server
+   that is not publicly referenced may refuse to accept any messages for
+   relay or local delivery based on authentication supplied during the
+   TLS negotiation.
+
+   A SMTP server that is not publicly referenced may choose to require
+   that the client perform a TLS negotiation before accepting any
+   commands. In this case, the server SHOULD return the reply code:
+
+   530 Must issue a STARTTLS command first
+
+   to every command other than NOOP, EHLO, STARTTLS, or QUIT. If the
+   client and server are using the ENHANCEDSTATUSCODES ESMTP extension
+   [RFC-2034], the status code to be returned SHOULD be 5.7.0.
+
+   After receiving a 220 response to a STARTTLS command, the client
+   SHOULD start the TLS negotiation before giving any other SMTP
+   commands.
+
+   If the SMTP client is using pipelining as defined in RFC 1854, the
+   STARTTLS command must be the last command in a group.
+
+5.1 Processing After the STARTTLS Command
+
+   After the TLS handshake has been completed, both parties MUST
+   immediately decide whether or not to continue based on the
+   authentication and privacy achieved. The SMTP client and server may
+   decide to move ahead even if the TLS negotiation ended with no
+   authentication and/or no privacy because most SMTP services are
+   performed with no authentication and no privacy, but some SMTP
+   clients or servers may want to continue only if a particular level of
+   authentication and/or privacy was achieved.
+
+   If the SMTP client decides that the level of authentication or
+   privacy is not high enough for it to continue, it SHOULD issue an
+   SMTP QUIT command immediately after the TLS negotiation is complete.
+   If the SMTP server decides that the level of authentication or
+   privacy is not high enough for it to continue, it SHOULD reply to
+   every SMTP command from the client (other than a QUIT command) with
+   the 554 reply code (with a possible text string such as "Command
+   refused due to lack of security").
+
+   The decision of whether or not to believe the authenticity of the
+   other party in a TLS negotiation is a local matter. However, some
+   general rules for the decisions are:
+
+
+
+
+
+Hoffman                     Standards Track                     [Page 3]
+
+RFC 2487                 SMTP Service Extension             January 1999
+
+
+    - A SMTP client would probably only want to authenticate an SMTP
+      server whose server certificate has a domain name that is the
+      domain name that the client thought it was connecting to.
+    - A publicly-referenced  SMTP server would probably want to accept
+      any certificate from an SMTP client, and would possibly want to
+      put distinguishing information about the certificate in the
+      Received header of messages that were relayed or submitted from
+      the client.
+
+5.2 Result of the STARTTLS Command
+
+   Upon completion of the TLS handshake, the SMTP protocol is reset to
+   the initial state (the state in SMTP after a server issues a 220
+   service ready greeting). The server MUST discard any knowledge
+   obtained from the client, such as the argument to the EHLO command,
+   which was not obtained from the TLS negotiation itself. The client
+   MUST discard any knowledge obtained from the server, such as the list
+   of SMTP service extensions, which was not obtained from the TLS
+   negotiation itself. The client SHOULD send an EHLO command as the
+   first command after a successful TLS negotiation.
+
+   The list of SMTP service extensions returned in response to an EHLO
+   command received after the TLS handshake MAY be different than the
+   list returned before the TLS handshake. For example, an SMTP server
+   might not want to advertise support for a particular SASL mechanism
+   [SASL] unless a client has sent an appropriate client certificate
+   during a TLS handshake.
+
+   Both the client and the server MUST know if there is a TLS session
+   active.  A client MUST NOT attempt to start a TLS session if a TLS
+   session is already active. A server MUST NOT return the TLS extension
+   in response to an EHLO command received after a TLS handshake has
+   completed.
+
+6. Usage Example
+
+   The following dialog illustrates how a client and server can start a
+   TLS session:
+
+   S: <waits for connection on TCP port 25>
+   C: <opens connection>
+   S: 220 mail.imc.org SMTP service ready
+   C: EHLO mail.ietf.org
+   S: 250-mail.imc.org offers a warm hug of welcome
+   S: 250 STARTTLS
+   C: STARTTLS
+   S: 220 Go ahead
+   C: <starts TLS negotiation>
+
+
+
+Hoffman                     Standards Track                     [Page 4]
+
+RFC 2487                 SMTP Service Extension             January 1999
+
+
+   C & S: <negotiate a TLS session>
+   C & S: <check result of negotiation>
+   C: <continues by sending an SMTP command>
+   . . .
+
+7. Security Considerations
+
+   It should be noted that SMTP is not an end-to-end mechanism. Thus, if
+   an SMTP client/server pair decide to add TLS privacy, they are not
+   securing the transport from the originating mail user agent to the
+   recipient.  Further, because delivery of a single piece of mail may
+   go between more than two SMTP servers, adding TLS privacy to one pair
+   of servers does not mean that the entire SMTP chain has been made
+   private. Further, just because an SMTP server can authenticate an
+   SMTP client, it does not mean that the mail from the SMTP client was
+   authenticated by the SMTP client when the client received it.
+
+   Both the STMP client and server must check the result of the TLS
+   negotiation to see whether acceptable authentication or privacy was
+   achieved. Ignoring this step completely invalidates using TLS for
+   security.  The decision about whether acceptable authentication or
+   privacy was achieved is made locally, is implementation-dependant,
+   and is beyond the scope of this document.
+
+   The SMTP client and server should note carefully the result of the
+   TLS negotiation. If the negotiation results in no privacy, or if it
+   results in privacy using algorithms or key lengths that are deemed
+   not strong enough, or if the authentication is not good enough for
+   either party, the client may choose to end the SMTP session with an
+   immediate QUIT command, or the server may choose to not accept any
+   more SMTP commands.
+
+   A server announcing in an EHLO response that it uses a particular TLS
+   protocol should not pose any security issues, since any use of TLS
+   will be at least as secure as no use of TLS.
+
+   A man-in-the-middle attack can be launched by deleting the "250
+   STARTTLS" response from the server. This would cause the client not
+   to try to start a TLS session. An SMTP client can protect against
+   this attack by recording the fact that a particular SMTP server
+   offers TLS during one session and generating an alarm if it does not
+   appear in the EHLO response for a later session. The lack of TLS
+   during a session SHOULD NOT result in the bouncing of email, although
+   it could result in delayed processing.
+
+
+
+
+
+
+
+Hoffman                     Standards Track                     [Page 5]
+
+RFC 2487                 SMTP Service Extension             January 1999
+
+
+   Before the TLS handshake has begun, any protocol interactions are
+   performed in the clear and may be modified by an active attacker. For
+   this reason, clients and servers MUST discard any knowledge obtained
+   prior to the start of the TLS handshake upon completion of the TLS
+   handshake.
+
+   The STARTTLS extension is not suitable for authenticating the author
+   of an email message unless every hop in the delivery chain, including
+   the submission to the first SMTP server, is authenticated. Another
+   proposal [SMTP-AUTH] can be used to authenticate delivery and MIME
+   security multiparts [MIME-SEC] can be used to authenticate the author
+   of an email message. In addition, the [SMTP-AUTH] proposal offers
+   simpler and more flexible options to authenticate an SMTP client and
+   the SASL EXTERNAL mechanism [SASL] MAY be used in conjunction with
+   the STARTTLS command to provide an authorization identity.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman                     Standards Track                     [Page 6]
+
+RFC 2487                 SMTP Service Extension             January 1999
+
+
+A. References
+
+   [RFC-821]   Postel, J., "Simple Mail Transfer Protocol", RFC 821,
+               August 1982.
+
+   [RFC-1869]  Klensin, J., Freed, N, Rose, M, Stefferud, E. and D.
+               Crocker, "SMTP Service Extensions", STD 10, RFC 1869,
+               November 1995.
+
+   [RFC-2034]  Freed, N., "SMTP Service Extension for Returning Enhanced
+               Error Codes", RFC 2034, October 1996.
+
+   [RFC-2119]  Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [SASL]      Myers, J., "Simple Authentication and Security Layer
+               (SASL)", RFC 2222, October 1997.
+
+   [SMTP-AUTH] "SMTP Service Extension for Authentication", Work in
+               Progress.
+
+   [TLS]       Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
+               RFC 2246, January 1999.
+
+B. Author's Address
+
+   Paul Hoffman
+   Internet Mail Consortium
+   127 Segre Place
+   Santa Cruz, CA  95060
+
+   Phone: (831) 426-9827
+   EMail: phoffman@imc.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman                     Standards Track                     [Page 7]
+
+RFC 2487                 SMTP Service Extension             January 1999
+
+
+C.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  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
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman                     Standards Track                     [Page 8]
+
diff --git a/doc/devel/rfc/rfc2554.txt b/doc/devel/rfc/rfc2554.txt
new file mode 100644
index 00000000..2922deae
--- /dev/null
+++ b/doc/devel/rfc/rfc2554.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group                                           J. Myers
+Request for Comments: 2554                       Netscape Communications
+Category: Standards Track                                     March 1999
+
+
+                         SMTP Service Extension
+                           for Authentication
+
+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.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+
+1. Introduction
+
+   This document defines an SMTP service extension [ESMTP] whereby an
+   SMTP client may indicate an authentication mechanism to the server,
+   perform an authentication protocol exchange, and optionally negotiate
+   a security layer for subsequent protocol interactions.  This
+   extension is a profile of the Simple Authentication and Security
+   Layer [SASL].
+
+
+2. Conventions Used in this Document
+
+   In examples, "C:" and "S:" indicate lines sent by the client and
+   server respectively.
+
+   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
+   in this document are to be interpreted as defined in "Key words for
+   use in RFCs to Indicate Requirement Levels" [KEYWORDS].
+
+
+3. The Authentication service extension
+
+
+   (1) the name of the SMTP service extension is "Authentication"
+
+   (2) the EHLO keyword value associated with this extension is "AUTH"
+
+
+
+
+Myers                       Standards Track                     [Page 1]
+
+RFC 2554                  SMTP Authentication                 March 1999
+
+
+   (3) The AUTH EHLO keyword contains as a parameter a space separated
+       list of the names of supported SASL mechanisms.
+
+   (4) a new SMTP verb "AUTH" is defined
+
+   (5) an optional parameter using the keyword "AUTH" is added to the
+       MAIL FROM command, and extends the maximum line length of the
+       MAIL FROM command by 500 characters.
+
+   (6) this extension is appropriate for the submission protocol
+       [SUBMIT].
+
+
+4. The AUTH command
+
+   AUTH mechanism [initial-response]
+
+     Arguments:
+         a string identifying a SASL authentication mechanism.
+         an optional base64-encoded response
+
+     Restrictions:
+         After an AUTH command has successfully completed, no more AUTH
+         commands may be issued in the same session.  After a successful
+         AUTH command completes, a server MUST reject any further AUTH
+         commands with a 503 reply.
+
+         The AUTH command is not permitted during a mail transaction.
+
+     Discussion:
+         The AUTH command indicates an authentication mechanism to the
+         server.  If the server supports the requested authentication
+         mechanism, it performs an authentication protocol exchange to
+         authenticate and identify the user.  Optionally, it also
+         negotiates a security layer for subsequent protocol
+         interactions.  If the requested authentication mechanism is not
+         supported, the server rejects the AUTH command with a 504
+         reply.
+
+         The authentication protocol exchange consists of a series of
+         server challenges and client answers that are specific to the
+         authentication mechanism.  A server challenge, otherwise known
+         as a ready response, is a 334 reply with the text part
+         containing a BASE64 encoded string.  The client answer consists
+         of a line containing a BASE64 encoded string.  If the client
+         wishes to cancel an authentication exchange, it issues a line
+         with a single "*".  If the server receives such an answer, it
+         MUST reject the AUTH command by sending a 501 reply.
+
+
+
+Myers                       Standards Track                     [Page 2]
+
+RFC 2554                  SMTP Authentication                 March 1999
+
+
+         The optional initial-response argument to the AUTH command is
+         used to save a round trip when using authentication mechanisms
+         that are defined to send no data in the initial challenge.
+         When the initial-response argument is used with such a
+         mechanism, the initial empty challenge is not sent to the
+         client and the server uses the data in the initial-response
+         argument as if it were sent in response to the empty challenge.
+         Unlike a zero-length client answer to a 334 reply, a zero-
+         length initial response is sent as a single equals sign ("=").
+         If the client uses an initial-response argument to the AUTH
+         command with a mechanism that sends data in the initial
+         challenge, the server rejects the AUTH command with a 535
+         reply.
+
+         If the server cannot BASE64 decode the argument, it rejects the
+         AUTH command with a 501 reply.  If the server rejects the
+         authentication data, it SHOULD reject the AUTH command with a
+         535 reply unless a more specific error code, such as one listed
+         in section 6, is appropriate.  Should the client successfully
+         complete the authentication exchange, the SMTP server issues a
+         235 reply.
+
+         The service name specified by this protocol's profile of SASL
+         is "smtp".
+
+         If a security layer is negotiated through the SASL
+         authentication exchange, it takes effect immediately following
+         the CRLF that concludes the authentication exchange for the
+         client, and the CRLF of the success reply for the server.  Upon
+         a security layer's taking effect, the SMTP protocol is reset to
+         the initial state (the state in SMTP after a server issues a
+         220 service ready greeting).  The server MUST discard any
+         knowledge obtained from the client, such as the argument to the
+         EHLO command, which was not obtained from the SASL negotiation
+         itself.  The client MUST discard any knowledge obtained from
+         the server, such as the list of SMTP service extensions, which
+         was not obtained from the SASL negotiation itself (with the
+         exception that a client MAY compare the list of advertised SASL
+         mechanisms before and after authentication in order to detect
+         an active down-negotiation attack).  The client SHOULD send an
+         EHLO command as the first command after a successful SASL
+         negotiation which results in the enabling of a security layer.
+
+         The server is not required to support any particular
+         authentication mechanism, nor are authentication mechanisms
+         required to support any security layers.  If an AUTH command
+         fails, the client may try another authentication mechanism by
+         issuing another AUTH command.
+
+
+
+Myers                       Standards Track                     [Page 3]
+
+RFC 2554                  SMTP Authentication                 March 1999
+
+
+         If an AUTH command fails, the server MUST behave the same as if
+         the client had not issued the AUTH command.
+
+         The BASE64 string may in general be arbitrarily long.  Clients
+         and servers MUST be able to support challenges and responses
+         that are as long as are generated by the authentication
+         mechanisms they support, independent of any line length
+         limitations the client or server may have in other parts of its
+         protocol implementation.
+
+     Examples:
+         S: 220 smtp.example.com ESMTP server ready
+         C: EHLO jgm.example.com
+         S: 250-smtp.example.com
+         S: 250 AUTH CRAM-MD5 DIGEST-MD5
+         C: AUTH FOOBAR
+         S: 504 Unrecognized authentication type.
+         C: AUTH CRAM-MD5
+         S: 334
+         PENCeUxFREJoU0NnbmhNWitOMjNGNndAZWx3b29kLmlubm9zb2Z0LmNvbT4=
+         C: ZnJlZCA5ZTk1YWVlMDljNDBhZjJiODRhMGMyYjNiYmFlNzg2ZQ==
+         S: 235 Authentication successful.
+
+
+
+5. The AUTH parameter to the MAIL FROM command
+
+   AUTH=addr-spec
+
+   Arguments:
+       An addr-spec containing the identity which submitted the message
+       to the delivery system, or the two character sequence "<>"
+       indicating such an identity is unknown or insufficiently
+       authenticated.  To comply with the restrictions imposed on ESMTP
+       parameters, the addr-spec is encoded inside an xtext.  The syntax
+       of an xtext is described in section 5 of [ESMTP-DSN].
+
+   Discussion:
+       The optional AUTH parameter to the MAIL FROM command allows
+       cooperating agents in a trusted environment to communicate the
+       authentication of individual messages.
+
+       If the server trusts the authenticated identity of the client to
+       assert that the message was originally submitted by the supplied
+       addr-spec, then the server SHOULD supply the same addr-spec in an
+       AUTH parameter when relaying the message to any server which
+       supports the AUTH extension.
+
+
+
+
+Myers                       Standards Track                     [Page 4]
+
+RFC 2554                  SMTP Authentication                 March 1999
+
+
+       A MAIL FROM parameter of AUTH=<> indicates that the original
+       submitter of the message is not known.  The server MUST NOT treat
+       the message as having been originally submitted by the client.
+
+       If the AUTH parameter to the MAIL FROM is not supplied, the
+       client has authenticated, and the server believes the message is
+       an original submission by the client, the server MAY supply the
+       client's identity in the addr-spec in an AUTH parameter when
+       relaying the message to any server which supports the AUTH
+       extension.
+
+       If the server does not sufficiently trust the authenticated
+       identity of the client, or if the client is not authenticated,
+       then the server MUST behave as if the AUTH=<> parameter was
+       supplied.  The server MAY, however, write the value of the AUTH
+       parameter to a log file.
+
+       If an AUTH=<> parameter was supplied, either explicitly or due to
+       the requirement in the previous paragraph, then the server MUST
+       supply the AUTH=<> parameter when relaying the message to any
+       server which it has authenticated to using the AUTH extension.
+
+       A server MAY treat expansion of a mailing list as a new
+       submission, setting the AUTH parameter to the mailing list
+       address or mailing list administration address when relaying the
+       message to list subscribers.
+
+       It is conforming for an implementation to be hard-coded to treat
+       all clients as being insufficiently trusted.  In that case, the
+       implementation does nothing more than parse and discard
+       syntactically valid AUTH parameters to the MAIL FROM command and
+       supply AUTH=<> parameters to any servers to which it
+       authenticates using the AUTH extension.
+
+   Examples:
+       C: MAIL FROM:<e=mc2@example.com> AUTH=e+3Dmc2@example.com
+       S: 250 OK
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Myers                       Standards Track                     [Page 5]
+
+RFC 2554                  SMTP Authentication                 March 1999
+
+
+6. Error Codes
+
+   The following error codes may be used to indicate various conditions
+   as described.
+
+   432 A password transition is needed
+
+   This response to the AUTH command indicates that the user needs to
+   transition to the selected authentication mechanism.  This typically
+   done by authenticating once using the PLAIN authentication mechanism.
+
+   534 Authentication mechanism is too weak
+
+   This response to the AUTH command indicates that the selected
+   authentication mechanism is weaker than server policy permits for
+   that user.
+
+   538 Encryption required for requested authentication mechanism
+
+   This response to the AUTH command indicates that the selected
+   authentication mechanism may only be used when the underlying SMTP
+   connection is encrypted.
+
+   454 Temporary authentication failure
+
+   This response to the AUTH command indicates that the authentication
+   failed due to a temporary server failure.
+
+   530 Authentication required
+
+   This response may be returned by any command other than AUTH, EHLO,
+   HELO, NOOP, RSET, or QUIT.  It indicates that server policy requires
+   authentication in order to perform the requested action.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Myers                       Standards Track                     [Page 6]
+
+RFC 2554                  SMTP Authentication                 March 1999
+
+
+7. Formal Syntax
+
+   The following syntax specification uses the augmented Backus-Naur
+   Form (BNF) notation as specified in [ABNF].
+
+   Except as noted otherwise, all alphabetic characters are case-
+   insensitive.  The use of upper or lower case characters to define
+   token strings is for editorial clarity only.  Implementations MUST
+   accept these strings in a case-insensitive fashion.
+
+   UPALPHA         = %x41-5A            ;; Uppercase: A-Z
+
+   LOALPHA         = %x61-7A            ;; Lowercase: a-z
+
+   ALPHA           = UPALPHA / LOALPHA  ;; case insensitive
+
+   DIGIT           = %x30-39            ;; Digits 0-9
+
+   HEXDIGIT        = %x41-46 / DIGIT    ;; hexidecimal digit (uppercase)
+
+   hexchar         = "+" HEXDIGIT HEXDIGIT
+
+   xchar           = %x21-2A / %x2C-3C / %x3E-7E
+                     ;; US-ASCII except for "+", "=", SPACE and CTL
+
+   xtext           = *(xchar / hexchar)
+
+   AUTH_CHAR       = ALPHA / DIGIT / "-" / "_"
+
+   auth_type       = 1*20AUTH_CHAR
+
+   auth_command    = "AUTH" SPACE auth_type [SPACE (base64 / "=")]
+                     *(CRLF [base64]) CRLF
+
+   auth_param      = "AUTH=" xtext
+                       ;; The decoded form of the xtext MUST be either
+                       ;; an addr-spec or the two characters "<>"
+
+   base64          = base64_terminal /
+                     ( 1*(4base64_CHAR) [base64_terminal] )
+
+   base64_char     = UPALPHA / LOALPHA / DIGIT / "+" / "/"
+                     ;; Case-sensitive
+
+   base64_terminal = (2base64_char "==") / (3base64_char "=")
+
+   continue_req    = "334" SPACE [base64] CRLF
+
+
+
+
+Myers                       Standards Track                     [Page 7]
+
+RFC 2554                  SMTP Authentication                 March 1999
+
+
+   CR              = %x0C           ;; ASCII CR, carriage return
+
+   CRLF            = CR LF
+
+   CTL             = %x00-1F / %x7F ;; any ASCII control character and DEL
+
+   LF              = %x0A           ;; ASCII LF, line feed
+
+   SPACE           = %x20           ;; ASCII SP, space
+
+
+
+
+8. References
+
+   [ABNF]      Crocker, D. and P. Overell, "Augmented BNF for Syntax
+               Specifications: ABNF", RFC 2234, November 1997.
+
+   [CRAM-MD5]  Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP
+               AUTHorize Extension for Simple Challenge/Response", RFC
+               2195, September 1997.
+
+   [ESMTP]     Klensin, J., Freed, N., Rose, M., Stefferud, E. and D.
+               Crocker, "SMTP Service Extensions", RFC 1869, November
+               1995.
+
+   [ESMTP-DSN] Moore, K, "SMTP Service Extension for Delivery Status
+               Notifications", RFC 1891, January 1996.
+
+   [KEYWORDS]  Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [SASL]      Myers, J., "Simple Authentication and Security Layer
+               (SASL)", RFC 2222, October 1997.
+
+   [SUBMIT]    Gellens, R. and J. Klensin, "Message Submission", RFC
+               2476, December 1998.
+
+   [RFC821]    Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
+               821, August 1982.
+
+   [RFC822]    Crocker, D., "Standard for the Format of ARPA Internet
+               Text Messages", STD 11, RFC 822, August 1982.
+
+
+
+
+
+
+
+
+Myers                       Standards Track                     [Page 8]
+
+RFC 2554                  SMTP Authentication                 March 1999
+
+
+9. Security Considerations
+
+   Security issues are discussed throughout this memo.
+
+   If a client uses this extension to get an encrypted tunnel through an
+   insecure network to a cooperating server, it needs to be configured
+   to never send mail to that server when the connection is not mutually
+   authenticated and encrypted.  Otherwise, an attacker could steal the
+   client's mail by hijacking the SMTP connection and either pretending
+   the server does not support the Authentication extension or causing
+   all AUTH commands to fail.
+
+   Before the SASL negotiation has begun, any protocol interactions are
+   performed in the clear and may be modified by an active attacker.
+   For this reason, clients and servers MUST discard any knowledge
+   obtained prior to the start of the SASL negotiation upon completion
+   of a SASL negotiation which results in a security layer.
+
+   This mechanism does not protect the TCP port, so an active attacker
+   may redirect a relay connection attempt to the submission port
+   [SUBMIT].  The AUTH=<> parameter prevents such an attack from causing
+   an relayed message without an envelope authentication to pick up the
+   authentication of the relay client.
+
+   A message submission client may require the user to authenticate
+   whenever a suitable SASL mechanism is advertised.  Therefore, it may
+   not be desirable for a submission server [SUBMIT] to advertise a SASL
+   mechanism when use of that mechanism grants the client no benefits
+   over anonymous submission.
+
+   This extension is not intended to replace or be used instead of end-
+   to-end message signature and encryption systems such as S/MIME or
+   PGP.  This extension addresses a different problem than end-to-end
+   systems; it has the following key differences:
+
+      (1) it is generally useful only within a trusted enclave
+
+      (2) it protects the entire envelope of a message, not just the
+          message's body.
+
+      (3) it authenticates the message submission, not authorship of the
+          message content
+
+      (4) it can give the sender some assurance the message was
+          delivered to the next hop in the case where the sender
+          mutually authenticates with the next hop and negotiates an
+          appropriate security layer.
+
+
+
+
+Myers                       Standards Track                     [Page 9]
+
+RFC 2554                  SMTP Authentication                 March 1999
+
+
+   Additional security considerations are mentioned in the SASL
+   specification [SASL].
+
+
+
+10. Author's Address
+
+   John Gardiner Myers
+   Netscape Communications
+   501 East Middlefield Road
+   Mail Stop MV-029
+   Mountain View, CA 94043
+
+   EMail: jgmyers@netscape.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Myers                       Standards Track                    [Page 10]
+
+RFC 2554                  SMTP Authentication                 March 1999
+
+
+11.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  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
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Myers                       Standards Track                    [Page 11]
+
diff --git a/doc/devel/rfc/rfc821.txt b/doc/devel/rfc/rfc821.txt
new file mode 100644
index 00000000..d877b72c
--- /dev/null
+++ b/doc/devel/rfc/rfc821.txt
@@ -0,0 +1,4050 @@
+
+                                                                        
+
+   RFC 821
+                                    
+                                    
+                                    
+                                    
+                                    
+                     SIMPLE MAIL TRANSFER PROTOCOL
+                                    
+                                    
+                                    
+                           Jonathan B. Postel
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                              August 1982
+                                    
+                                    
+                                    
+                     Information Sciences Institute
+                   University of Southern California
+                           4676 Admiralty Way
+                   Marina del Rey, California  90291
+
+                             (213) 822-1511
+
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+                           TABLE OF CONTENTS
+
+   1.  INTRODUCTION .................................................. 1
+
+   2.  THE SMTP MODEL ................................................ 2
+
+   3.  THE SMTP PROCEDURE ............................................ 4
+
+      3.1.  Mail ..................................................... 4
+      3.2.  Forwarding ............................................... 7
+      3.3.  Verifying and Expanding .................................. 8
+      3.4.  Sending and Mailing ..................................... 11
+      3.5.  Opening and Closing ..................................... 13
+      3.6.  Relaying ................................................ 14
+      3.7.  Domains ................................................. 17
+      3.8.  Changing Roles .......................................... 18
+
+   4.  THE SMTP SPECIFICATIONS ...................................... 19
+
+      4.1.  SMTP Commands ........................................... 19
+      4.1.1.  Command Semantics ..................................... 19
+      4.1.2.  Command Syntax ........................................ 27
+      4.2.  SMTP Replies ............................................ 34
+      4.2.1.  Reply Codes by Function Group ......................... 35
+      4.2.2.  Reply Codes in Numeric Order .......................... 36
+      4.3.  Sequencing of Commands and Replies ...................... 37
+      4.4.  State Diagrams .......................................... 39
+      4.5.  Details ................................................. 41
+      4.5.1.  Minimum Implementation ................................ 41
+      4.5.2.  Transparency .......................................... 41
+      4.5.3.  Sizes ................................................. 42
+
+   APPENDIX A:  TCP ................................................. 44
+   APPENDIX B:  NCP ................................................. 45
+   APPENDIX C:  NITS ................................................ 46
+   APPENDIX D:  X.25 ................................................ 47
+   APPENDIX E:  Theory of Reply Codes ............................... 48
+   APPENDIX F:  Scenarios ........................................... 51
+
+   GLOSSARY ......................................................... 64
+
+   REFERENCES ....................................................... 67
+
+
+
+
+Network Working Group                                          J. Postel
+Request for Comments: DRAFT                                          ISI
+Replaces: RFC 788, 780, 772                                  August 1982
+
+                     SIMPLE MAIL TRANSFER PROTOCOL
+
+
+1.  INTRODUCTION
+
+   The objective of Simple Mail Transfer Protocol (SMTP) is to transfer
+   mail reliably and efficiently.
+
+   SMTP is independent of the particular transmission subsystem and
+   requires only a reliable ordered data stream channel.  Appendices A,
+   B, C, and D describe the use of SMTP with various transport services.
+   A Glossary provides the definitions of terms as used in this
+   document.
+
+   An important feature of SMTP is its capability to relay mail across
+   transport service environments.  A transport service provides an
+   interprocess communication environment (IPCE).  An IPCE may cover one
+   network, several networks, or a subset of a network.  It is important
+   to realize that transport systems (or IPCEs) are not one-to-one with
+   networks.  A process can communicate directly with another process
+   through any mutually known IPCE.  Mail is an application or use of
+   interprocess communication.  Mail can be communicated between
+   processes in different IPCEs by relaying through a process connected
+   to two (or more) IPCEs.  More specifically, mail can be relayed
+   between hosts on different transport systems by a host on both
+   transport systems.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel                                                          [Page 1]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+2.  THE SMTP MODEL
+
+   The SMTP design is based on the following model of communication:  as
+   the result of a user mail request, the sender-SMTP establishes a
+   two-way transmission channel to a receiver-SMTP.  The receiver-SMTP
+   may be either the ultimate destination or an intermediate.  SMTP
+   commands are generated by the sender-SMTP and sent to the
+   receiver-SMTP.  SMTP replies are sent from the receiver-SMTP to the
+   sender-SMTP in response to the commands.
+
+   Once the transmission channel is established, the SMTP-sender sends a
+   MAIL command indicating the sender of the mail.  If the SMTP-receiver
+   can accept mail it responds with an OK reply.  The SMTP-sender then
+   sends a RCPT command identifying a recipient of the mail.  If the
+   SMTP-receiver can accept mail for that recipient it responds with an
+   OK reply; if not, it responds with a reply rejecting that recipient
+   (but not the whole mail transaction).  The SMTP-sender and
+   SMTP-receiver may negotiate several recipients.  When the recipients
+   have been negotiated the SMTP-sender sends the mail data, terminating
+   with a special sequence.  If the SMTP-receiver successfully processes
+   the mail data it responds with an OK reply.  The dialog is purposely
+   lock-step, one-at-a-time.
+
+     -------------------------------------------------------------
+
+   
+               +----------+                +----------+
+   +------+    |          |                |          |
+   | User |<-->|          |      SMTP      |          |
+   +------+    |  Sender- |Commands/Replies| Receiver-|
+   +------+    |   SMTP   |<-------------->|    SMTP  |    +------+
+   | File |<-->|          |    and Mail    |          |<-->| File |
+   |System|    |          |                |          |    |System|
+   +------+    +----------+                +----------+    +------+
+   
+
+                Sender-SMTP                Receiver-SMTP
+
+                           Model for SMTP Use
+
+                                Figure 1
+
+     -------------------------------------------------------------
+
+   The SMTP provides mechanisms for the transmission of mail; directly
+   from the sending user's host to the receiving user's host when the
+
+
+
+[Page 2]                                                          Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+   two host are connected to the same transport service, or via one or
+   more relay SMTP-servers when the source and destination hosts are not
+   connected to the same transport service.
+
+   To be able to provide the relay capability the SMTP-server must be
+   supplied with the name of the ultimate destination host as well as
+   the destination mailbox name.
+
+   The argument to the MAIL command is a reverse-path, which specifies
+   who the mail is from.  The argument to the RCPT command is a
+   forward-path, which specifies who the mail is to.  The forward-path
+   is a source route, while the reverse-path is a return route (which
+   may be used to return a message to the sender when an error occurs
+   with a relayed message).
+
+   When the same message is sent to multiple recipients the SMTP
+   encourages the transmission of only one copy of the data for all the
+   recipients at the same destination host.
+
+   The mail commands and replies have a rigid syntax.  Replies also have
+   a numeric code.  In the following, examples appear which use actual
+   commands and replies.  The complete lists of commands and replies
+   appears in Section 4 on specifications.
+
+   Commands and replies are not case sensitive.  That is, a command or
+   reply word may be upper case, lower case, or any mixture of upper and
+   lower case.  Note that this is not true of mailbox user names.  For
+   some hosts the user name is case sensitive, and SMTP implementations
+   must take case to preserve the case of user names as they appear in
+   mailbox arguments.  Host names are not case sensitive.
+
+   Commands and replies are composed of characters from the ASCII
+   character set [1].  When the transport service provides an 8-bit byte
+   (octet) transmission channel, each 7-bit character is transmitted
+   right justified in an octet with the high order bit cleared to zero.
+
+   When specifying the general form of a command or reply, an argument
+   (or special symbol) will be denoted by a meta-linguistic variable (or
+   constant), for example, "<string>" or "<reverse-path>".  Here the
+   angle brackets indicate these are meta-linguistic variables.
+   However, some arguments use the angle brackets literally.  For
+   example, an actual reverse-path is enclosed in angle brackets, i.e.,
+   "<John.Smith@USC-ISI.ARPA>" is an instance of <reverse-path> (the
+   angle brackets are actually transmitted in the command or reply).
+
+
+
+
+
+Postel                                                          [Page 3]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+3.  THE SMTP PROCEDURES
+
+   This section presents the procedures used in SMTP in several parts.
+   First comes the basic mail procedure defined as a mail transaction.
+   Following this are descriptions of forwarding mail, verifying mailbox
+   names and expanding mailing lists, sending to terminals instead of or
+   in combination with mailboxes, and the opening and closing exchanges.
+   At the end of this section are comments on relaying, a note on mail
+   domains, and a discussion of changing roles.  Throughout this section
+   are examples of partial command and reply sequences, several complete
+   scenarios are presented in Appendix F.
+
+   3.1.  MAIL
+
+      There are three steps to SMTP mail transactions.  The transaction
+      is started with a MAIL command which gives the sender
+      identification.  A series of one or more RCPT commands follows
+      giving the receiver information.  Then a DATA command gives the
+      mail data.  And finally, the end of mail data indicator confirms
+      the transaction.
+
+         The first step in the procedure is the MAIL command.  The
+         <reverse-path> contains the source mailbox.
+
+            MAIL <SP> FROM:<reverse-path> <CRLF>
+
+         This command tells the SMTP-receiver that a new mail
+         transaction is starting and to reset all its state tables and
+         buffers, including any recipients or mail data.  It gives the
+         reverse-path which can be used to report errors.  If accepted,
+         the receiver-SMTP returns a 250 OK reply.
+
+         The <reverse-path> can contain more than just a mailbox.  The
+         <reverse-path> is a reverse source routing list of hosts and
+         source mailbox.  The first host in the <reverse-path> should be
+         the host sending this command.
+
+         The second step in the procedure is the RCPT command.
+
+            RCPT <SP> TO:<forward-path> <CRLF>
+
+         This command gives a forward-path identifying one recipient.
+         If accepted, the receiver-SMTP returns a 250 OK reply, and
+         stores the forward-path.  If the recipient is unknown the
+         receiver-SMTP returns a 550 Failure reply.  This second step of
+         the procedure can be repeated any number of times.
+
+
+
+[Page 4]                                                          Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+         The <forward-path> can contain more than just a mailbox.  The
+         <forward-path> is a source routing list of hosts and the
+         destination mailbox.  The first host in the <forward-path>
+         should be the host receiving this command.
+
+         The third step in the procedure is the DATA command.
+
+            DATA <CRLF>
+
+         If accepted, the receiver-SMTP returns a 354 Intermediate reply
+         and considers all succeeding lines to be the message text.
+         When the end of text is received and stored the SMTP-receiver
+         sends a 250 OK reply.
+
+         Since the mail data is sent on the transmission channel the end
+         of the mail data must be indicated so that the command and
+         reply dialog can be resumed.  SMTP indicates the end of the
+         mail data by sending a line containing only a period.  A
+         transparency procedure is used to prevent this from interfering
+         with the user's text (see Section 4.5.2).
+
+            Please note that the mail data includes the memo header
+            items such as Date, Subject, To, Cc, From [2].
+
+         The end of mail data indicator also confirms the mail
+         transaction and tells the receiver-SMTP to now process the
+         stored recipients and mail data.  If accepted, the
+         receiver-SMTP returns a 250 OK reply.  The DATA command should
+         fail only if the mail transaction was incomplete (for example,
+         no recipients), or if resources are not available.
+
+      The above procedure is an example of a mail transaction.  These
+      commands must be used only in the order discussed above.
+      Example 1 (below) illustrates the use of these commands in a mail
+      transaction.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel                                                          [Page 5]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+      -------------------------------------------------------------
+
+                     Example of the SMTP Procedure
+
+         This SMTP example shows mail sent by Smith at host Alpha.ARPA,
+         to Jones, Green, and Brown at host Beta.ARPA.  Here we assume
+         that host Alpha contacts host Beta directly.
+
+            S: MAIL FROM:<Smith@Alpha.ARPA>
+            R: 250 OK
+
+            S: RCPT TO:<Jones@Beta.ARPA>
+            R: 250 OK
+
+            S: RCPT TO:<Green@Beta.ARPA>
+            R: 550 No such user here
+
+            S: RCPT TO:<Brown@Beta.ARPA>
+            R: 250 OK
+
+            S: DATA
+            R: 354 Start mail input; end with <CRLF>.<CRLF>
+            S: Blah blah blah...
+            S: ...etc. etc. etc.
+            S: <CRLF>.<CRLF>
+            R: 250 OK
+
+         The mail has now been accepted for Jones and Brown.  Green did
+         not have a mailbox at host Beta.
+
+                               Example 1
+
+      -------------------------------------------------------------
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 6]                                                          Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+   3.2.  FORWARDING
+
+      There are some cases where the destination information in the
+      <forward-path> is incorrect, but the receiver-SMTP knows the
+      correct destination.  In such cases, one of the following replies
+      should be used to allow the sender to contact the correct
+      destination.
+
+         251 User not local; will forward to <forward-path>
+
+            This reply indicates that the receiver-SMTP knows the user's
+            mailbox is on another host and indicates the correct
+            forward-path to use in the future.  Note that either the
+            host or user or both may be different.  The receiver takes
+            responsibility for delivering the message.
+
+         551 User not local; please try <forward-path>
+
+            This reply indicates that the receiver-SMTP knows the user's
+            mailbox is on another host and indicates the correct
+            forward-path to use.  Note that either the host or user or
+            both may be different.  The receiver refuses to accept mail
+            for this user, and the sender must either redirect the mail
+            according to the information provided or return an error
+            response to the originating user.
+
+      Example 2 illustrates the use of these responses.
+
+      -------------------------------------------------------------
+
+                         Example of Forwarding
+
+      Either
+
+      S: RCPT TO:<Postel@USC-ISI.ARPA>
+      R: 251 User not local; will forward to <Postel@USC-ISIF.ARPA>
+
+      Or
+
+      S: RCPT TO:<Paul@USC-ISIB.ARPA>
+      R: 551 User not local; please try <Mockapetris@USC-ISIF.ARPA>
+
+                               Example 2
+
+      -------------------------------------------------------------
+
+
+
+
+Postel                                                          [Page 7]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+   3.3.  VERIFYING AND EXPANDING
+
+      SMTP provides as additional features, commands to verify a user
+      name or expand a mailing list.  This is done with the VRFY and
+      EXPN commands, which have character string arguments.  For the
+      VRFY command, the string is a user name, and the response may
+      include the full name of the user and must include the mailbox of
+      the user.  For the EXPN command, the string identifies a mailing
+      list, and the multiline response may include the full name of the
+      users and must give the mailboxes on the mailing list.
+
+      "User name" is a fuzzy term and used purposely.  If a host
+      implements the VRFY or EXPN commands then at least local mailboxes
+      must be recognized as "user names".  If a host chooses to
+      recognize other strings as "user names" that is allowed.
+
+      In some hosts the distinction between a mailing list and an alias
+      for a single mailbox is a bit fuzzy, since a common data structure
+      may hold both types of entries, and it is possible to have mailing
+      lists of one mailbox.  If a request is made to verify a mailing
+      list a positive response can be given if on receipt of a message
+      so addressed it will be delivered to everyone on the list,
+      otherwise an error should be reported (e.g., "550 That is a
+      mailing list, not a user").  If a request is made to expand a user
+      name a positive response can be formed by returning a list
+      containing one name, or an error can be reported (e.g., "550 That
+      is a user name, not a mailing list").
+
+      In the case of a multiline reply (normal for EXPN) exactly one
+      mailbox is to be specified on each line of the reply.  In the case
+      of an ambiguous request, for example, "VRFY Smith", where there
+      are two Smith's the response must be "553 User ambiguous".
+
+      The case of verifying a user name is straightforward as shown in
+      example 3.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 8]                                                          Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+      -------------------------------------------------------------
+
+                    Example of Verifying a User Name
+
+         Either
+
+            S: VRFY Smith
+            R: 250 Fred Smith <Smith@USC-ISIF.ARPA>
+
+         Or
+
+            S: VRFY Smith
+            R: 251 User not local; will forward to <Smith@USC-ISIQ.ARPA>
+
+         Or
+
+            S: VRFY Jones
+            R: 550 String does not match anything.
+
+         Or
+
+            S: VRFY Jones
+            R: 551 User not local; please try <Jones@USC-ISIQ.ARPA>
+
+         Or
+
+            S: VRFY Gourzenkyinplatz
+            R: 553 User ambiguous.
+
+                               Example 3
+
+      -------------------------------------------------------------
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel                                                          [Page 9]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+      The case of expanding a mailbox list requires a multiline reply as
+      shown in example 4.
+
+      -------------------------------------------------------------
+
+                  Example of Expanding a Mailing List
+
+         Either
+
+            S: EXPN Example-People
+            R: 250-Jon Postel <Postel@USC-ISIF.ARPA>
+            R: 250-Fred Fonebone <Fonebone@USC-ISIQ.ARPA>
+            R: 250-Sam Q. Smith <SQSmith@USC-ISIQ.ARPA>
+            R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA>
+            R: 250-<joe@foo-unix.ARPA>
+            R: 250 <xyz@bar-unix.ARPA>
+
+         Or
+
+            S: EXPN Executive-Washroom-List
+            R: 550 Access Denied to You.
+
+                               Example 4
+
+      -------------------------------------------------------------
+
+      The character string arguments of the VRFY and EXPN commands
+      cannot be further restricted due to the variety of implementations
+      of the user name and mailbox list concepts.  On some systems it
+      may be appropriate for the argument of the EXPN command to be a
+      file name for a file containing a mailing list, but again there is
+      a variety of file naming conventions in the Internet.
+
+      The VRFY and EXPN commands are not included in the minimum
+      implementation (Section 4.5.1), and are not required to work
+      across relays when they are implemented.
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 10]                                                         Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+   3.4.  SENDING AND MAILING
+
+      The main purpose of SMTP is to deliver messages to user's
+      mailboxes.  A very similar service provided by some hosts is to
+      deliver messages to user's terminals (provided the user is active
+      on the host).  The delivery to the user's mailbox is called
+      "mailing", the delivery to the user's terminal is called
+      "sending".  Because in many hosts the implementation of sending is
+      nearly identical to the implementation of mailing these two
+      functions are combined in SMTP.  However the sending commands are
+      not included in the required minimum implementation
+      (Section 4.5.1).  Users should have the ability to control the
+      writing of messages on their terminals.  Most hosts permit the
+      users to accept or refuse such messages.
+
+      The following three command are defined to support the sending
+      options.  These are used in the mail transaction instead of the
+      MAIL command and inform the receiver-SMTP of the special semantics
+      of this transaction:
+
+         SEND <SP> FROM:<reverse-path> <CRLF>
+
+            The SEND command requires that the mail data be delivered to
+            the user's terminal.  If the user is not active (or not
+            accepting terminal messages) on the host a 450 reply may
+            returned to a RCPT command.  The mail transaction is
+            successful if the message is delivered the terminal.
+
+         SOML <SP> FROM:<reverse-path> <CRLF>
+
+            The Send Or MaiL command requires that the mail data be
+            delivered to the user's terminal if the user is active (and
+            accepting terminal messages) on the host.  If the user is
+            not active (or not accepting terminal messages) then the
+            mail data is entered into the user's mailbox.  The mail
+            transaction is successful if the message is delivered either
+            to the terminal or the mailbox.
+
+         SAML <SP> FROM:<reverse-path> <CRLF>
+
+            The Send And MaiL command requires that the mail data be
+            delivered to the user's terminal if the user is active (and
+            accepting terminal messages) on the host.  In any case the
+            mail data is entered into the user's mailbox.  The mail
+            transaction is successful if the message is delivered the
+            mailbox.
+
+
+
+Postel                                                         [Page 11]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+      The same reply codes that are used for the MAIL commands are used
+      for these commands.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 12]                                                         Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+   3.5.  OPENING AND CLOSING
+
+      At the time the transmission channel is opened there is an
+      exchange to ensure that the hosts are communicating with the hosts
+      they think they are.
+
+      The following two commands are used in transmission channel
+      opening and closing:
+
+         HELO <SP> <domain> <CRLF>
+
+         QUIT <CRLF>
+
+      In the HELO command the host sending the command identifies
+      itself; the command may be interpreted as saying "Hello, I am
+      <domain>".
+
+      -------------------------------------------------------------
+
+                     Example of Connection Opening
+
+         R: 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready
+         S: HELO USC-ISIF.ARPA
+         R: 250 BBN-UNIX.ARPA
+
+                               Example 5
+
+      -------------------------------------------------------------
+
+      -------------------------------------------------------------
+
+                     Example of Connection Closing
+
+         S: QUIT
+         R: 221 BBN-UNIX.ARPA Service closing transmission channel
+
+                               Example 6
+
+      -------------------------------------------------------------
+
+
+
+
+
+
+
+
+
+
+Postel                                                         [Page 13]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+   3.6.  RELAYING
+
+      The forward-path may be a source route of the form
+      "@ONE,@TWO:JOE@THREE", where ONE, TWO, and THREE are hosts.  This
+      form is used to emphasize the distinction between an address and a
+      route.  The mailbox is an absolute address, and the route is
+      information about how to get there.  The two concepts should not
+      be confused.
+
+      Conceptually the elements of the forward-path are moved to the
+      reverse-path as the message is relayed from one server-SMTP to
+      another.  The reverse-path is a reverse source route, (i.e., a
+      source route from the current location of the message to the
+      originator of the message).  When a server-SMTP deletes its
+      identifier from the forward-path and inserts it into the
+      reverse-path, it must use the name it is known by in the
+      environment it is sending into, not the environment the mail came
+      from, in case the server-SMTP is known by different names in
+      different environments.
+
+      If when the message arrives at an SMTP the first element of the
+      forward-path is not the identifier of that SMTP the element is not
+      deleted from the forward-path and is used to determine the next
+      SMTP to send the message to.  In any case, the SMTP adds its own
+      identifier to the reverse-path.
+
+      Using source routing the receiver-SMTP receives mail to be relayed
+      to another server-SMTP  The receiver-SMTP may accept or reject the
+      task of relaying the mail in the same way it accepts or rejects
+      mail for a local user.  The receiver-SMTP transforms the command
+      arguments by moving its own identifier from the forward-path to
+      the beginning of the reverse-path.  The receiver-SMTP then becomes
+      a sender-SMTP, establishes a transmission channel to the next SMTP
+      in the forward-path, and sends it the mail.
+
+      The first host in the reverse-path should be the host sending the
+      SMTP commands, and the first host in the forward-path should be
+      the host receiving the SMTP commands.
+
+      Notice that the forward-path and reverse-path appear in the SMTP
+      commands and replies, but not necessarily in the message.  That
+      is, there is no need for these paths and especially this syntax to
+      appear in the "To:" , "From:", "CC:", etc. fields of the message
+      header.
+
+      If a server-SMTP has accepted the task of relaying the mail and
+
+
+
+[Page 14]                                                         Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+      later finds that the forward-path is incorrect or that the mail
+      cannot be delivered for whatever reason, then it must construct an
+      "undeliverable mail" notification message and send it to the
+      originator of the undeliverable mail (as indicated by the
+      reverse-path).
+
+      This notification message must be from the server-SMTP at this
+      host.  Of course, server-SMTPs should not send notification
+      messages about problems with notification messages.  One way to
+      prevent loops in error reporting is to specify a null reverse-path
+      in the MAIL command of a notification message.  When such a
+      message is relayed it is permissible to leave the reverse-path
+      null.  A MAIL command with a null reverse-path appears as follows:
+
+         MAIL FROM:<>
+
+      An undeliverable mail notification message is shown in example 7.
+      This notification is in response to a message originated by JOE at
+      HOSTW and sent via HOSTX to HOSTY with instructions to relay it on
+      to HOSTZ.  What we see in the example is the transaction between
+      HOSTY and HOSTX, which is the first step in the return of the
+      notification message.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel                                                         [Page 15]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+      -------------------------------------------------------------
+
+            Example Undeliverable Mail Notification Message
+
+         S: MAIL FROM:<>
+         R: 250 ok
+         S: RCPT TO:<@HOSTX.ARPA:JOE@HOSTW.ARPA>
+         R: 250 ok
+         S: DATA
+         R: 354 send the mail data, end with .
+         S: Date: 23 Oct 81 11:22:33
+         S: From: SMTP@HOSTY.ARPA
+         S: To: JOE@HOSTW.ARPA
+         S: Subject: Mail System Problem
+         S:
+         S:   Sorry JOE, your message to SAM@HOSTZ.ARPA lost.
+         S:   HOSTZ.ARPA said this:
+         S:    "550 No Such User"
+         S: .
+         R: 250 ok
+
+                               Example 7
+
+      -------------------------------------------------------------
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 16]                                                         Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+   3.7.  DOMAINS
+
+      Domains are a recently introduced concept in the ARPA Internet
+      mail system.  The use of domains changes the address space from a
+      flat global space of simple character string host names to a
+      hierarchically structured rooted tree of global addresses.  The
+      host name is replaced by a domain and host designator which is a
+      sequence of domain element strings separated by periods with the
+      understanding that the domain elements are ordered from the most
+      specific to the most general.
+
+      For example, "USC-ISIF.ARPA", "Fred.Cambridge.UK", and
+      "PC7.LCS.MIT.ARPA" might be host-and-domain identifiers.
+
+      Whenever domain names are used in SMTP only the official names are
+      used, the use of nicknames or aliases is not allowed.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel                                                         [Page 17]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+   3.8.  CHANGING ROLES
+
+      The TURN command may be used to reverse the roles of the two
+      programs communicating over the transmission channel.
+
+      If program-A is currently the sender-SMTP and it sends the TURN
+      command and receives an ok reply (250) then program-A becomes the
+      receiver-SMTP.
+
+      If program-B is currently the receiver-SMTP and it receives the
+      TURN command and sends an ok reply (250) then program-B becomes
+      the sender-SMTP.
+
+      To refuse to change roles the receiver sends the 502 reply.
+
+      Please note that this command is optional.  It would not normally
+      be used in situations where the transmission channel is TCP.
+      However, when the cost of establishing the transmission channel is
+      high, this command may be quite useful.  For example, this command
+      may be useful in supporting be mail exchange using the public
+      switched telephone system as a transmission channel, especially if
+      some hosts poll other hosts for mail exchanges.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 18]                                                         Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+4.  THE SMTP SPECIFICATIONS
+
+   4.1.  SMTP COMMANDS
+
+      4.1.1.  COMMAND SEMANTICS
+
+         The SMTP commands define the mail transfer or the mail system
+         function requested by the user.  SMTP commands are character
+         strings terminated by <CRLF>.  The command codes themselves are
+         alphabetic characters terminated by <SP> if parameters follow
+         and <CRLF> otherwise.  The syntax of mailboxes must conform to
+         receiver site conventions.  The SMTP commands are discussed
+         below.  The SMTP replies are discussed in the Section 4.2.
+
+         A mail transaction involves several data objects which are
+         communicated as arguments to different commands.  The
+         reverse-path is the argument of the MAIL command, the
+         forward-path is the argument of the RCPT command, and the mail
+         data is the argument of the DATA command.  These arguments or
+         data objects must be transmitted and held pending the
+         confirmation communicated by the end of mail data indication
+         which finalizes the transaction.  The model for this is that
+         distinct buffers are provided to hold the types of data
+         objects, that is, there is a reverse-path buffer, a
+         forward-path buffer, and a mail data buffer.  Specific commands
+         cause information to be appended to a specific buffer, or cause
+         one or more buffers to be cleared.
+
+         HELLO (HELO)
+
+            This command is used to identify the sender-SMTP to the
+            receiver-SMTP.  The argument field contains the host name of
+            the sender-SMTP.
+
+            The receiver-SMTP identifies itself to the sender-SMTP in
+            the connection greeting reply, and in the response to this
+            command.
+
+            This command and an OK reply to it confirm that both the
+            sender-SMTP and the receiver-SMTP are in the initial state,
+            that is, there is no transaction in progress and all state
+            tables and buffers are cleared.
+
+
+
+
+
+
+
+Postel                                                         [Page 19]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+         MAIL (MAIL)
+
+            This command is used to initiate a mail transaction in which
+            the mail data is delivered to one or more mailboxes.  The
+            argument field contains a reverse-path.
+
+            The reverse-path consists of an optional list of hosts and
+            the sender mailbox.  When the list of hosts is present, it
+            is a "reverse" source route and indicates that the mail was
+            relayed through each host on the list (the first host in the
+            list was the most recent relay).  This list is used as a
+            source route to return non-delivery notices to the sender.
+            As each relay host adds itself to the beginning of the list,
+            it must use its name as known in the IPCE to which it is
+            relaying the mail rather than the IPCE from which the mail
+            came (if they are different).  In some types of error
+            reporting messages (for example, undeliverable mail
+            notifications) the reverse-path may be null (see Example 7).
+
+            This command clears the reverse-path buffer, the
+            forward-path buffer, and the mail data buffer; and inserts
+            the reverse-path information from this command into the
+            reverse-path buffer.
+
+         RECIPIENT (RCPT)
+
+            This command is used to identify an individual recipient of
+            the mail data; multiple recipients are specified by multiple
+            use of this command.
+
+            The forward-path consists of an optional list of hosts and a
+            required destination mailbox.  When the list of hosts is
+            present, it is a source route and indicates that the mail
+            must be relayed to the next host on the list.  If the
+            receiver-SMTP does not implement the relay function it may
+            user the same reply it would for an unknown local user
+            (550).
+
+            When mail is relayed, the relay host must remove itself from
+            the beginning forward-path and put itself at the beginning
+            of the reverse-path.  When mail reaches its ultimate
+            destination (the forward-path contains only a destination
+            mailbox), the receiver-SMTP inserts it into the destination
+            mailbox in accordance with its host mail conventions.
+
+
+
+
+
+[Page 20]                                                         Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+               For example, mail received at relay host A with arguments
+
+                  FROM:<USERX@HOSTY.ARPA>
+                  TO:<@HOSTA.ARPA,@HOSTB.ARPA:USERC@HOSTD.ARPA>
+
+               will be relayed on to host B with arguments
+
+                  FROM:<@HOSTA.ARPA:USERX@HOSTY.ARPA>
+                  TO:<@HOSTB.ARPA:USERC@HOSTD.ARPA>.
+
+            This command causes its forward-path argument to be appended
+            to the forward-path buffer.
+
+         DATA (DATA)
+
+            The receiver treats the lines following the command as mail
+            data from the sender.  This command causes the mail data
+            from this command to be appended to the mail data buffer.
+            The mail data may contain any of the 128 ASCII character
+            codes.
+
+            The mail data is terminated by a line containing only a
+            period, that is the character sequence "<CRLF>.<CRLF>" (see
+            Section 4.5.2 on Transparency).  This is the end of mail
+            data indication.
+
+            The end of mail data indication requires that the receiver
+            must now process the stored mail transaction information.
+            This processing consumes the information in the reverse-path
+            buffer, the forward-path buffer, and the mail data buffer,
+            and on the completion of this command these buffers are
+            cleared.  If the processing is successful the receiver must
+            send an OK reply.  If the processing fails completely the
+            receiver must send a failure reply.
+
+            When the receiver-SMTP accepts a message either for relaying
+            or for final delivery it inserts at the beginning of the
+            mail data a time stamp line.  The time stamp line indicates
+            the identity of the host that sent the message, and the
+            identity of the host that received the message (and is
+            inserting this time stamp), and the date and time the
+            message was received.  Relayed messages will have multiple
+            time stamp lines.
+
+            When the receiver-SMTP makes the "final delivery" of a
+            message it inserts at the beginning of the mail data a
+
+
+
+Postel                                                         [Page 21]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+            return path line.  The return path line preserves the
+            information in the <reverse-path> from the MAIL command.
+            Here, final delivery means the message leaves the SMTP
+            world.  Normally, this would mean it has been delivered to
+            the destination user, but in some cases it may be further
+            processed and transmitted by another mail system.
+
+               It is possible for the mailbox in the return path be
+               different from the actual sender's mailbox, for example,
+               if error responses are to be delivered a special error
+               handling mailbox rather than the message senders.
+
+            The preceding two paragraphs imply that the final mail data
+            will begin with a  return path line, followed by one or more
+            time stamp lines.  These lines will be followed by the mail
+            data header and body [2].  See Example 8.
+
+            Special mention is needed of the response and further action
+            required when the processing following the end of mail data
+            indication is partially successful.  This could arise if
+            after accepting several recipients and the mail data, the
+            receiver-SMTP finds that the mail data can be successfully
+            delivered to some of the recipients, but it cannot be to
+            others (for example, due to mailbox space allocation
+            problems).  In such a situation, the response to the DATA
+            command must be an OK reply.  But, the receiver-SMTP must
+            compose and send an "undeliverable mail" notification
+            message to the originator of the message.  Either a single
+            notification which lists all of the recipients that failed
+            to get the message, or separate notification messages must
+            be sent for each failed recipient (see Example 7).  All
+            undeliverable mail notification messages are sent using the
+            MAIL command (even if they result from processing a SEND,
+            SOML, or SAML command).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 22]                                                         Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+     -------------------------------------------------------------
+
+            Example of Return Path and Received Time Stamps
+
+      Return-Path: <@GHI.ARPA,@DEF.ARPA,@ABC.ARPA:JOE@ABC.ARPA>   
+      Received: from GHI.ARPA by JKL.ARPA ; 27 Oct 81 15:27:39 PST
+      Received: from DEF.ARPA by GHI.ARPA ; 27 Oct 81 15:15:13 PST
+      Received: from ABC.ARPA by DEF.ARPA ; 27 Oct 81 15:01:59 PST
+      Date: 27 Oct 81 15:01:01 PST                                
+      From: JOE@ABC.ARPA                                          
+      Subject: Improved Mailing System Installed                  
+      To: SAM@JKL.ARPA                                            
+                                    
+      This is to inform you that ...                              
+
+                               Example 8
+
+     -------------------------------------------------------------
+
+         SEND (SEND)
+
+            This command is used to initiate a mail transaction in which
+            the mail data is delivered to one or more terminals.  The
+            argument field contains a reverse-path.  This command is
+            successful if the message is delivered to a terminal.
+
+            The reverse-path consists of an optional list of hosts and
+            the sender mailbox.  When the list of hosts is present, it
+            is a "reverse" source route and indicates that the mail was
+            relayed through each host on the list (the first host in the
+            list was the most recent relay).  This list is used as a
+            source route to return non-delivery notices to the sender.
+            As each relay host adds itself to the beginning of the list,
+            it must use its name as known in the IPCE to which it is
+            relaying the mail rather than the IPCE from which the mail
+            came (if they are different).
+
+            This command clears the reverse-path buffer, the
+            forward-path buffer, and the mail data buffer; and inserts
+            the reverse-path information from this command into the
+            reverse-path buffer.
+
+         SEND OR MAIL (SOML)
+
+            This command is used to initiate a mail transaction in which
+            the mail data is delivered to one or more terminals or
+
+
+
+Postel                                                         [Page 23]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+            mailboxes. For each recipient the mail data is delivered to
+            the recipient's terminal if the recipient is active on the
+            host (and accepting terminal messages), otherwise to the
+            recipient's mailbox.  The argument field contains a
+            reverse-path.  This command is successful if the message is
+            delivered to a terminal or the mailbox.
+
+            The reverse-path consists of an optional list of hosts and
+            the sender mailbox.  When the list of hosts is present, it
+            is a "reverse" source route and indicates that the mail was
+            relayed through each host on the list (the first host in the
+            list was the most recent relay).  This list is used as a
+            source route to return non-delivery notices to the sender.
+            As each relay host adds itself to the beginning of the list,
+            it must use its name as known in the IPCE to which it is
+            relaying the mail rather than the IPCE from which the mail
+            came (if they are different).
+
+            This command clears the reverse-path buffer, the
+            forward-path buffer, and the mail data buffer; and inserts
+            the reverse-path information from this command into the
+            reverse-path buffer.
+
+         SEND AND MAIL (SAML)
+
+            This command is used to initiate a mail transaction in which
+            the mail data is delivered to one or more terminals and
+            mailboxes. For each recipient the mail data is delivered to
+            the recipient's terminal if the recipient is active on the
+            host (and accepting terminal messages), and for all
+            recipients to the recipient's mailbox.  The argument field
+            contains a reverse-path.  This command is successful if the
+            message is delivered to the mailbox.
+
+            The reverse-path consists of an optional list of hosts and
+            the sender mailbox.  When the list of hosts is present, it
+            is a "reverse" source route and indicates that the mail was
+            relayed through each host on the list (the first host in the
+            list was the most recent relay).  This list is used as a
+            source route to return non-delivery notices to the sender.
+            As each relay host adds itself to the beginning of the list,
+            it must use its name as known in the IPCE to which it is
+            relaying the mail rather than the IPCE from which the mail
+            came (if they are different).
+
+            This command clears the reverse-path buffer, the
+
+
+
+[Page 24]                                                         Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+            forward-path buffer, and the mail data buffer; and inserts
+            the reverse-path information from this command into the
+            reverse-path buffer.
+
+         RESET (RSET)
+
+            This command specifies that the current mail transaction is
+            to be aborted.  Any stored sender, recipients, and mail data
+            must be discarded, and all buffers and state tables cleared.
+            The receiver must send an OK reply.
+
+         VERIFY (VRFY)
+
+            This command asks the receiver to confirm that the argument
+            identifies a user.  If it is a user name, the full name of
+            the user (if known) and the fully specified mailbox are
+            returned.
+
+            This command has no effect on any of the reverse-path
+            buffer, the forward-path buffer, or the mail data buffer.
+
+         EXPAND (EXPN)
+
+            This command asks the receiver to confirm that the argument
+            identifies a mailing list, and if so, to return the
+            membership of that list.  The full name of the users (if
+            known) and the fully specified mailboxes are returned in a
+            multiline reply.
+
+            This command has no effect on any of the reverse-path
+            buffer, the forward-path buffer, or the mail data buffer.
+
+         HELP (HELP)
+
+            This command causes the receiver to send helpful information
+            to the sender of the HELP command.  The command may take an
+            argument (e.g., any command name) and return more specific
+            information as a response.
+
+            This command has no effect on any of the reverse-path
+            buffer, the forward-path buffer, or the mail data buffer.
+
+
+
+
+
+
+
+
+Postel                                                         [Page 25]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+         NOOP (NOOP)
+
+            This command does not affect any parameters or previously
+            entered commands.  It specifies no action other than that
+            the receiver send an OK reply.
+
+            This command has no effect on any of the reverse-path
+            buffer, the forward-path buffer, or the mail data buffer.
+
+         QUIT (QUIT)
+
+            This command specifies that the receiver must send an OK
+            reply, and then close the transmission channel.
+
+            The receiver should not close the transmission channel until
+            it receives and replies to a QUIT command (even if there was
+            an error).  The sender should not close the transmission
+            channel until it send a QUIT command and receives the reply
+            (even if there was an error response to a previous command).
+            If the connection is closed prematurely the receiver should
+            act as if a RSET command had been received (canceling any
+            pending transaction, but not undoing any previously
+            completed transaction), the sender should act as if the
+            command or transaction in progress had received a temporary
+            error (4xx).
+
+         TURN (TURN)
+
+            This command specifies that the receiver must either (1)
+            send an OK reply and then take on the role of the
+            sender-SMTP, or (2) send a refusal reply and retain the role
+            of the receiver-SMTP.
+
+            If program-A is currently the sender-SMTP and it sends the
+            TURN command and receives an OK reply (250) then program-A
+            becomes the receiver-SMTP.  Program-A is then in the initial
+            state as if the transmission channel just opened, and it
+            then sends the 220 service ready greeting.
+
+            If program-B is currently the receiver-SMTP and it receives
+            the TURN command and sends an OK reply (250) then program-B
+            becomes the sender-SMTP.  Program-B is then in the initial
+            state as if the transmission channel just opened, and it
+            then expects to receive the 220 service ready greeting.
+
+            To refuse to change roles the receiver sends the 502 reply.
+
+
+
+[Page 26]                                                         Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+         There are restrictions on the order in which these command may
+         be used.
+
+            The first command in a session must be the HELO command.
+            The HELO command may be used later in a session as well.  If
+            the HELO command argument is not acceptable a 501 failure
+            reply must be returned and the receiver-SMTP must stay in
+            the same state.
+
+            The NOOP, HELP, EXPN, and VRFY commands can be used at any
+            time during a session.
+
+            The MAIL, SEND, SOML, or SAML commands begin a mail
+            transaction.  Once started a mail transaction consists of
+            one of the transaction beginning commands, one or more RCPT
+            commands, and a DATA command, in that order.  A mail
+            transaction may be aborted by the RSET command.  There may
+            be zero or more transactions in a session.
+
+            If the transaction beginning command argument is not
+            acceptable a 501 failure reply must be returned and the
+            receiver-SMTP must stay in the same state.  If the commands
+            in a transaction are out of order a 503 failure reply must
+            be returned and the receiver-SMTP must stay in the same
+            state.
+
+            The last command in a session must be the QUIT command.  The
+            QUIT command can not be used at any other time in a session.
+
+      4.1.2.  COMMAND SYNTAX
+
+         The commands consist of a command code followed by an argument
+         field.  Command codes are four alphabetic characters.  Upper
+         and lower case alphabetic characters are to be treated
+         identically.  Thus, any of the following may represent the mail
+         command:
+
+            MAIL    Mail    mail    MaIl    mAIl
+
+         This also applies to any symbols representing parameter values,
+         such as "TO" or "to" for the forward-path.  Command codes and
+         the argument fields are separated by one or more spaces.
+         However, within the reverse-path and forward-path arguments
+         case is important.  In particular, in some hosts the user
+         "smith" is different from the user "Smith".
+
+
+
+
+Postel                                                         [Page 27]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+         The argument field consists of a variable length character
+         string ending with the character sequence <CRLF>.  The receiver
+         is to take no action until this sequence is received.
+
+         Square brackets denote an optional argument field.  If the
+         option is not taken, the appropriate default is implied.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 28]                                                         Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+         The following are the SMTP commands:
+
+            HELO <SP> <domain> <CRLF>
+
+            MAIL <SP> FROM:<reverse-path> <CRLF>
+
+            RCPT <SP> TO:<forward-path> <CRLF>
+
+            DATA <CRLF>
+
+            RSET <CRLF>
+
+            SEND <SP> FROM:<reverse-path> <CRLF>
+
+            SOML <SP> FROM:<reverse-path> <CRLF>
+
+            SAML <SP> FROM:<reverse-path> <CRLF>
+
+            VRFY <SP> <string> <CRLF>
+
+            EXPN <SP> <string> <CRLF>
+
+            HELP [<SP> <string>] <CRLF>
+
+            NOOP <CRLF>
+
+            QUIT <CRLF>
+
+            TURN <CRLF>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel                                                         [Page 29]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+         The syntax of the above argument fields (using BNF notation
+         where applicable) is given below.  The "..." notation indicates
+         that a field may be repeated one or more times.
+
+            <reverse-path> ::= <path>
+
+            <forward-path> ::= <path>
+
+            <path> ::= "<" [ <a-d-l> ":" ] <mailbox> ">"
+
+            <a-d-l> ::= <at-domain> | <at-domain> "," <a-d-l>
+
+            <at-domain> ::= "@" <domain>
+
+            <domain> ::=  <element> | <element> "." <domain>
+
+            <element> ::= <name> | "#" <number> | "[" <dotnum> "]"
+
+            <mailbox> ::= <local-part> "@" <domain>
+
+            <local-part> ::= <dot-string> | <quoted-string>
+
+            <name> ::= <a> <ldh-str> <let-dig>
+
+            <ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
+
+            <let-dig> ::= <a> | <d>
+
+            <let-dig-hyp> ::= <a> | <d> | "-"
+
+            <dot-string> ::= <string> | <string> "." <dot-string>
+
+            <string> ::= <char> | <char> <string>
+
+            <quoted-string> ::=  """ <qtext> """
+
+            <qtext> ::=  "\" <x> | "\" <x> <qtext> | <q> | <q> <qtext>
+
+            <char> ::= <c> | "\" <x>
+
+            <dotnum> ::= <snum> "." <snum> "." <snum> "." <snum>
+
+            <number> ::= <d> | <d> <number>
+
+            <CRLF> ::= <CR> <LF>
+
+
+
+
+[Page 30]                                                         Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+            <CR> ::= the carriage return character (ASCII code 13)
+
+            <LF> ::= the line feed character (ASCII code 10)
+
+            <SP> ::= the space character (ASCII code 32)
+
+            <snum> ::= one, two, or three digits representing a decimal
+                      integer value in the range 0 through 255
+
+            <a> ::= any one of the 52 alphabetic characters A through Z
+                      in upper case and a through z in lower case
+
+            <c> ::= any one of the 128 ASCII characters, but not any
+                      <special> or <SP>
+
+            <d> ::= any one of the ten digits 0 through 9
+
+            <q> ::= any one of the 128 ASCII characters except <CR>,
+                      <LF>, quote ("), or backslash (\)
+
+            <x> ::= any one of the 128 ASCII characters (no exceptions)
+
+            <special> ::= "<" | ">" | "(" | ")" | "[" | "]" | "\" | "."
+                      | "," | ";" | ":" | "@"  """ | 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-line> ::= "Return-Path:" <SP><reverse-path><CRLF>
+
+         <time-stamp-line> ::= "Received:" <SP> <stamp> <CRLF>
+
+            <stamp> ::= <from-domain> <by-domain> <opt-info> ";"
+                      <daytime>
+
+            <from-domain> ::= "FROM" <SP> <domain> <SP>
+
+            <by-domain> ::= "BY" <SP> <domain> <SP>
+
+            <opt-info> ::= [<via>] [<with>] [<id>] [<for>]
+
+            <via> ::= "VIA" <SP> <link> <SP>
+
+            <with> ::= "WITH" <SP> <protocol> <SP>
+
+            <id> ::= "ID" <SP> <string> <SP>
+
+            <for> ::= "FOR" <SP> <path> <SP>
+
+            <link> ::= The standard names for links are registered with
+                      the Network Information Center.
+
+            <protocol> ::= The standard names for protocols are
+                      registered with the Network Information Center.
+
+            <daytime> ::= <SP> <date> <SP> <time>
+
+            <date> ::= <dd> <SP> <mon> <SP> <yy>
+
+            <time> ::= <hh> ":" <mm> ":" <ss> <SP> <zone>
+
+            <dd> ::= the one or two decimal integer day of the month in
+                      the range 1 to 31.
+
+            <mon> ::= "JAN" | "FEB" | "MAR" | "APR" | "MAY" | "JUN" |
+                      "JUL" | "AUG" | "SEP" | "OCT" | "NOV" | "DEC"
+
+            <yy> ::= the two decimal integer year of the century in the
+                      range 00 to 99.
+
+
+
+
+
+[Page 32]                                                         Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+            <hh> ::= the two decimal integer hour of the day in the
+                      range 00 to 24.
+
+            <mm> ::= the two decimal integer minute of the hour in the
+                      range 00 to 59.
+
+            <ss> ::= the two decimal integer second of the minute in the
+                      range 00 to 59.
+
+            <zone> ::= "UT" for Universal Time (the default) or other
+                      time zone designator (as in [2]).
+
+            
+
+     -------------------------------------------------------------
+
+                          Return Path Example
+
+         Return-Path: <@CHARLIE.ARPA,@BAKER.ARPA:JOE@ABLE.ARPA>
+
+                               Example 9
+
+     -------------------------------------------------------------
+
+     -------------------------------------------------------------
+
+                        Time Stamp Line Example
+
+      Received: FROM ABC.ARPA BY XYZ.ARPA ; 22 OCT 81 09:23:59 PDT
+
+         Received: from ABC.ARPA by XYZ.ARPA via TELENET with X25
+                   id M12345 for Smith@PDQ.ARPA ; 22 OCT 81 09:23:59 PDT
+
+                               Example 10
+
+      -------------------------------------------------------------
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel                                                         [Page 33]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+   4.2.  SMTP REPLIES
+
+      Replies to SMTP commands are devised to ensure the synchronization
+      of requests and actions in the process of mail transfer, and to
+      guarantee that the sender-SMTP always knows the state of the
+      receiver-SMTP.  Every command must generate exactly one reply.
+
+         The details of the command-reply sequence are made explicit in
+         Section 5.3 on Sequencing and Section 5.4 State Diagrams.
+
+      An SMTP reply consists of a three digit number (transmitted as
+      three alphanumeric characters) followed by some text.  The number
+      is intended for use by automata to determine what state to enter
+      next; the text is meant for the human user.  It is intended that
+      the three digits contain enough encoded information that the
+      sender-SMTP need not examine the text and may either discard it or
+      pass it on to the user, as appropriate.  In particular, the text
+      may be receiver-dependent and context dependent, so there are
+      likely to be varying texts for each reply code.  A discussion of
+      the theory of reply codes is given in Appendix E.  Formally, a
+      reply is defined to be the sequence:  a three-digit code, <SP>,
+      one line of text, and <CRLF>, or a multiline reply (as defined in
+      Appendix E).  Only the EXPN and HELP commands are expected to
+      result in multiline replies in normal circumstances, however
+      multiline replies are allowed for any command.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 34]                                                         Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+      4.2.1.  REPLY CODES BY FUNCTION GROUPS
+
+         500 Syntax error, command unrecognized
+            [This may include errors such as command line too long]
+         501 Syntax error in parameters or arguments
+         502 Command not implemented
+         503 Bad sequence of commands
+         504 Command parameter not implemented
+          
+         211 System status, or system help reply
+         214 Help message
+            [Information on how to use the receiver or the meaning of a
+            particular non-standard command; this reply is useful only
+            to the human user]
+          
+         220 <domain> Service ready
+         221 <domain> Service closing transmission channel
+         421 <domain> Service not available,
+             closing transmission channel
+            [This may be a reply to any command if the service knows it
+            must shut down]
+          
+         250 Requested mail action okay, completed
+         251 User not local; will forward to <forward-path>
+         450 Requested mail action not taken: mailbox unavailable
+            [E.g., mailbox busy]
+         550 Requested action not taken: mailbox unavailable
+            [E.g., mailbox not found, no access]
+         451 Requested action aborted: error in processing
+         551 User not local; please try <forward-path>
+         452 Requested action not taken: insufficient system storage
+         552 Requested mail action aborted: exceeded storage allocation
+         553 Requested action not taken: mailbox name not allowed
+            [E.g., mailbox syntax incorrect]
+         354 Start mail input; end with <CRLF>.<CRLF>
+         554 Transaction failed
+         
+
+
+
+
+
+
+
+
+
+
+
+
+Postel                                                         [Page 35]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+      4.2.2.  NUMERIC ORDER LIST OF REPLY CODES
+
+         211 System status, or system help reply
+         214 Help message
+            [Information on how to use the receiver or the meaning of a
+            particular non-standard command; this reply is useful only
+            to the human user]
+         220 <domain> Service ready
+         221 <domain> Service closing transmission channel
+         250 Requested mail action okay, completed
+         251 User not local; will forward to <forward-path>
+          
+         354 Start mail input; end with <CRLF>.<CRLF>
+          
+         421 <domain> Service not available,
+             closing transmission channel
+            [This may be a reply to any command if the service knows it
+            must shut down]
+         450 Requested mail action not taken: mailbox unavailable
+            [E.g., mailbox busy]
+         451 Requested action aborted: local error in processing
+         452 Requested action not taken: insufficient system storage
+          
+         500 Syntax error, command unrecognized
+            [This may include errors such as command line too long]
+         501 Syntax error in parameters or arguments
+         502 Command not implemented
+         503 Bad sequence of commands
+         504 Command parameter not implemented
+         550 Requested action not taken: mailbox unavailable
+            [E.g., mailbox not found, no access]
+         551 User not local; please try <forward-path>
+         552 Requested mail action aborted: exceeded storage allocation
+         553 Requested action not taken: mailbox name not allowed
+            [E.g., mailbox syntax incorrect]
+         554 Transaction failed
+         
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 36]                                                         Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+   4.3.  SEQUENCING OF COMMANDS AND REPLIES
+
+      The communication between the sender and receiver is intended to
+      be an alternating dialogue, controlled by the sender.  As such,
+      the sender issues a command and the receiver responds with a
+      reply.  The sender must wait for this response before sending
+      further commands.
+
+      One important reply is the connection greeting.  Normally, a
+      receiver will send a 220 "Service ready" reply when the connection
+      is completed.  The sender should wait for this greeting message
+      before sending any commands.
+
+         Note: all the greeting type replies have the official name of
+         the server host as the first word following the reply code.
+
+            For example,
+
+               220 <SP> USC-ISIF.ARPA <SP> Service ready <CRLF>
+
+      The table below lists alternative success and failure replies for
+      each command.  These must be strictly adhered to; a receiver may
+      substitute text in the replies, but the meaning and action implied
+      by the code numbers and by the specific command reply sequence
+      cannot be altered.
+
+      COMMAND-REPLY SEQUENCES
+
+         Each command is listed with its possible replies.  The prefixes
+         used before the possible replies are "P" for preliminary (not
+         used in SMTP), "I" for intermediate, "S" for success, "F" for
+         failure, and "E" for error.  The 421 reply (service not
+         available, closing transmission channel) may be given to any
+         command if the SMTP-receiver knows it must shut down.  This
+         listing forms the basis for the State Diagrams in Section 4.4.
+
+            CONNECTION ESTABLISHMENT
+               S: 220
+               F: 421
+            HELO
+               S: 250
+               E: 500, 501, 504, 421
+            MAIL
+               S: 250
+               F: 552, 451, 452
+               E: 500, 501, 421
+
+
+
+Postel                                                         [Page 37]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+            RCPT
+               S: 250, 251
+               F: 550, 551, 552, 553, 450, 451, 452
+               E: 500, 501, 503, 421
+            DATA
+               I: 354 -> data -> S: 250
+                                 F: 552, 554, 451, 452
+               F: 451, 554
+               E: 500, 501, 503, 421
+            RSET
+               S: 250
+               E: 500, 501, 504, 421
+            SEND
+               S: 250
+               F: 552, 451, 452
+               E: 500, 501, 502, 421
+            SOML
+               S: 250
+               F: 552, 451, 452
+               E: 500, 501, 502, 421
+            SAML
+               S: 250
+               F: 552, 451, 452
+               E: 500, 501, 502, 421
+            VRFY
+               S: 250, 251
+               F: 550, 551, 553
+               E: 500, 501, 502, 504, 421
+            EXPN
+               S: 250
+               F: 550
+               E: 500, 501, 502, 504, 421
+            HELP
+               S: 211, 214
+               E: 500, 501, 502, 504, 421
+            NOOP
+               S: 250
+               E: 500, 421
+            QUIT
+               S: 221
+               E: 500
+            TURN
+               S: 250
+               F: 502
+               E: 500, 503
+
+
+
+
+[Page 38]                                                         Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+   4.4.  STATE DIAGRAMS
+
+      Following are state diagrams for a simple-minded SMTP
+      implementation.  Only the first digit of the reply codes is used.
+      There is one state diagram for each group of SMTP commands.  The
+      command groupings were determined by constructing a model for each
+      command and then collecting together the commands with
+      structurally identical models.
+
+      For each command there are three possible outcomes:  "success"
+      (S), "failure" (F), and "error" (E). In the state diagrams below
+      we use the symbol B for "begin", and the symbol W for "wait for
+      reply".
+
+      First, the diagram that represents most of the SMTP commands:
+
+         
+                                  1,3    +---+
+                             ----------->| E |
+                            |            +---+
+                            |
+         +---+    cmd    +---+    2      +---+
+         | B |---------->| W |---------->| S |
+         +---+           +---+           +---+
+                            |
+                            |     4,5    +---+
+                             ----------->| F |
+                                         +---+
+         
+
+         This diagram models the commands:
+
+            HELO, MAIL, RCPT, RSET, SEND, SOML, SAML, VRFY, EXPN, HELP,
+            NOOP, QUIT, TURN.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel                                                         [Page 39]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+      A more complex diagram models the DATA command:
+
+         
+         +---+   DATA    +---+ 1,2                 +---+
+         | B |---------->| W |-------------------->| E |
+         +---+           +---+        ------------>+---+
+                         3| |4,5     |
+                          | |        |
+            --------------   -----   |
+           |                      |  |             +---+
+           |               ----------     -------->| S |
+           |              |       |      |         +---+
+           |              |  ------------
+           |              | |     |
+           V           1,3| |2    |
+         +---+   data    +---+     --------------->+---+
+         |   |---------->| W |                     | F |
+         +---+           +---+-------------------->+---+
+                              4,5
+
+
+         Note that the "data" here is a series of lines sent from the
+         sender to the receiver with no response expected until the last
+         line is sent.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 40]                                                         Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+   4.5.  DETAILS
+
+      4.5.1.  MINIMUM IMPLEMENTATION
+
+         In order to make SMTP workable, the following minimum
+         implementation is required for all receivers:
+
+            COMMANDS -- HELO
+                        MAIL
+                        RCPT
+                        DATA
+                        RSET
+                        NOOP
+                        QUIT
+
+      4.5.2.  TRANSPARENCY
+
+         Without some provision for data transparency the character
+         sequence "<CRLF>.<CRLF>" ends the mail text and cannot be sent
+         by the user.  In general, users are not aware of such
+         "forbidden" sequences.  To allow all user composed text to be
+         transmitted transparently the following procedures are used.
+
+            1. Before sending a line of mail text the sender-SMTP checks
+            the first character of the line.  If it is a period, one
+            additional period is inserted at the beginning of the line.
+
+            2. When a line of mail text is received by the receiver-SMTP
+            it checks the line.  If the line is composed of a single
+            period it is the end of mail.  If the first character is a
+            period and there are other characters on the line, the first
+            character is deleted.
+
+         The mail data may contain any of the 128 ASCII characters.  All
+         characters are to be delivered to the recipient's mailbox
+         including format effectors and other control characters.  If
+         the transmission channel provides an 8-bit byte (octets) data
+         stream, the 7-bit ASCII codes are transmitted right justified
+         in the octets with the high order bits cleared to zero.
+
+            In some systems it may be necessary to transform the data as
+            it is received and stored.  This may be necessary for hosts
+            that use a different character set than ASCII as their local
+            character set, or that store data in records rather than
+
+
+
+
+
+Postel                                                         [Page 41]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+            strings.  If such transforms are necessary, they must be
+            reversible -- especially if such transforms are applied to
+            mail being relayed.
+
+      4.5.3.  SIZES
+
+         There are several objects that have required minimum maximum
+         sizes.  That is, every implementation must be able to receive
+         objects of at least these sizes, but must not send objects
+         larger than these sizes.
+
+                                    
+          ****************************************************
+          *                                                  *
+          *  TO THE MAXIMUM EXTENT POSSIBLE, IMPLEMENTATION  *
+          *  TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH *
+          *  OF THESE OBJECTS SHOULD BE USED.                *
+          *                                                  *
+          ****************************************************
+
+            user
+
+               The maximum total length of a user name is 64 characters.
+
+            domain
+
+               The maximum total length of a domain name or number is 64
+               characters.
+
+            path
+
+               The maximum total length of a reverse-path or
+               forward-path is 256 characters (including the punctuation
+               and element separators).
+
+            command line
+
+               The maximum total length of a command line including the
+               command word and the <CRLF> is 512 characters.
+
+            reply line
+
+               The maximum total length of a reply line including the
+               reply code and the <CRLF> is 512 characters.
+
+
+
+
+
+[Page 42]                                                         Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+            text line
+
+               The maximum total length of a text line including the
+               <CRLF> is 1000 characters (but not counting the leading
+               dot duplicated for transparency).
+
+            recipients buffer
+
+               The maximum total number of recipients that must be
+               buffered is 100 recipients.
+
+                                    
+          ****************************************************
+          *                                                  *
+          *  TO THE MAXIMUM EXTENT POSSIBLE, IMPLEMENTATION  *
+          *  TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH *
+          *  OF THESE OBJECTS SHOULD BE USED.                *
+          *                                                  *
+          ****************************************************
+
+         Errors due to exceeding these limits may be reported by using
+         the reply codes, for example:
+
+            500 Line too long.
+
+            501 Path too long
+
+            552 Too many recipients.
+
+            552 Too much mail data.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel                                                         [Page 43]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+APPENDIX A
+
+   TCP Transport service
+
+      The Transmission Control Protocol [3] is used in the ARPA
+      Internet, and in any network following the US DoD standards for
+      internetwork protocols.
+
+      Connection Establishment
+
+         The SMTP transmission channel is a TCP connection established
+         between the sender process port U and the receiver process port
+         L.  This single full duplex connection is used as the
+         transmission channel.  This protocol is assigned the service
+         port 25 (31 octal), that is L=25.
+
+      Data Transfer
+
+         The TCP connection supports the transmission of 8-bit bytes.
+         The SMTP data is 7-bit ASCII characters.  Each character is
+         transmitted as an 8-bit byte with the high-order bit cleared to
+         zero.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 44]                                                         Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+APPENDIX B
+
+   NCP Transport service
+
+      The ARPANET Host-to-Host Protocol [4] (implemented by the Network
+      Control Program) may be used in the ARPANET.
+
+      Connection Establishment
+
+         The SMTP transmission channel is established via NCP between
+         the sender process socket U and receiver process socket L.  The
+         Initial Connection Protocol [5] is followed resulting in a pair
+         of simplex connections.  This pair of connections is used as
+         the transmission channel.  This protocol is assigned the
+         contact socket 25 (31 octal), that is L=25.
+
+      Data Transfer
+
+         The NCP data connections are established in 8-bit byte mode.
+         The SMTP data is 7-bit ASCII characters.  Each character is
+         transmitted as an 8-bit byte with the high-order bit cleared to
+         zero.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel                                                         [Page 45]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+APPENDIX C
+
+   NITS
+
+      The Network Independent Transport Service [6] may be used.
+
+      Connection Establishment
+
+         The SMTP transmission channel is established via NITS between
+         the sender process and receiver process.  The sender process
+         executes the CONNECT primitive, and the waiting receiver
+         process executes the ACCEPT primitive.
+
+      Data Transfer
+
+         The NITS connection supports the transmission of 8-bit bytes.
+         The SMTP data is 7-bit ASCII characters.  Each character is
+         transmitted as an 8-bit byte with the high-order bit cleared to
+         zero.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 46]                                                         Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+APPENDIX D
+
+   X.25 Transport service
+
+      It may be possible to use the X.25 service [7] as provided by the
+      Public Data Networks directly, however, it is suggested that a
+      reliable end-to-end protocol such as TCP be used on top of X.25
+      connections.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel                                                         [Page 47]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+APPENDIX E
+
+   Theory of Reply Codes
+
+      The three digits of the reply each have a special significance.
+      The first digit denotes whether the response is good, bad or
+      incomplete.  An unsophisticated sender-SMTP will be able to
+      determine its next action (proceed as planned, redo, retrench,
+      etc.) by simply examining this first digit.  A sender-SMTP that
+      wants to know approximately what kind of error occurred (e.g.,
+      mail system error, command syntax error) may examine the second
+      digit, reserving the third digit for the finest gradation of
+      information.
+
+         There are five values for the first digit of the reply code:
+
+            1yz   Positive Preliminary reply
+
+               The command has been accepted, but the requested action
+               is being held in abeyance, pending confirmation of the
+               information in this reply.  The sender-SMTP should send
+               another command specifying whether to continue or abort
+               the action.
+
+                  [Note: SMTP does not have any commands that allow this
+                  type of reply, and so does not have the continue or
+                  abort commands.]
+
+            2yz   Positive Completion reply
+
+               The requested action has been successfully completed.  A
+               new request may be initiated.
+
+            3yz   Positive Intermediate reply
+
+               The command has been accepted, but the requested action
+               is being held in abeyance, pending receipt of further
+               information.  The sender-SMTP should send another command
+               specifying this information.  This reply is used in
+               command sequence groups.
+
+            4yz   Transient Negative Completion reply
+
+               The command was not accepted and the requested action did
+               not occur.  However, the error condition is temporary and
+               the action may be requested again.  The sender should
+
+
+
+[Page 48]                                                         Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+               return to the beginning of the command sequence (if any).
+               It is difficult to assign a meaning to "transient" when
+               two different sites (receiver- and sender- SMTPs) must
+               agree on the interpretation.  Each reply in this category
+               might have a different time value, but the sender-SMTP is
+               encouraged to try again.  A rule of thumb to determine if
+               a reply fits into the 4yz or the 5yz category (see below)
+               is that replies are 4yz if they can be repeated without
+               any change in command form or in properties of the sender
+               or receiver.  (E.g., the command is repeated identically
+               and the receiver does not put up a new implementation.)
+
+            5yz   Permanent Negative Completion reply
+
+               The command was not accepted and the requested action did
+               not occur.  The sender-SMTP is discouraged from repeating
+               the exact request (in the same sequence).  Even some
+               "permanent" error conditions can be corrected, so the
+               human user may want to direct the sender-SMTP to
+               reinitiate the command sequence by direct action at some
+               point in the future (e.g., after the spelling has been
+               changed, or the user has altered the account status).
+
+         The second digit encodes responses in specific categories:
+
+            x0z   Syntax -- These replies refer to syntax errors,
+                  syntactically correct commands that don't fit any
+                  functional category, and unimplemented or superfluous
+                  commands.
+
+            x1z   Information --  These are replies to requests for
+                  information, such as status or help.
+
+            x2z   Connections -- These are replies referring to the
+                  transmission channel.
+
+            x3z   Unspecified as yet.
+
+            x4z   Unspecified as yet.
+
+            x5z   Mail system -- These replies indicate the status of
+                  the receiver mail system vis-a-vis the requested
+                  transfer or other mail system action.
+
+         The third digit gives a finer gradation of meaning in each
+         category specified by the second digit.  The list of replies
+
+
+
+Postel                                                         [Page 49]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+         illustrates this.  Each reply text is recommended rather than
+         mandatory, and may even change according to the command with
+         which it is associated.  On the other hand, the reply codes
+         must strictly follow the specifications in this section.
+         Receiver implementations should not invent new codes for
+         slightly different situations from the ones described here, but
+         rather adapt codes already defined.
+
+         For example, a command such as NOOP whose successful execution
+         does not offer the sender-SMTP any new information will return
+         a 250 reply.  The response is 502 when the command requests an
+         unimplemented non-site-specific action.  A refinement of that
+         is the 504 reply for a command that is implemented, but that
+         requests an unimplemented parameter.
+
+      The reply text may be longer than a single line; in these cases
+      the complete text must be marked so the sender-SMTP knows when it
+      can stop reading the reply.  This requires a special format to
+      indicate a multiple line reply.
+
+         The format for multiline replies requires that every line,
+         except the last, begin with the reply code, followed
+         immediately by a hyphen, "-" (also known as minus), followed by
+         text.  The last line will begin with the reply code, followed
+         immediately by <SP>, optionally some text, and <CRLF>.
+
+            For example:
+                                123-First line
+                                123-Second line
+                                123-234 text beginning with numbers
+                                123 The last line
+
+         In many cases the sender-SMTP then simply needs to search for
+         the reply code followed by <SP> at the beginning of a line, and
+         ignore all preceding lines.  In a few cases, there is important
+         data for the sender in the reply "text".  The sender will know
+         these cases from the current context.
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 50]                                                         Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+APPENDIX F
+
+   Scenarios
+
+      This section presents complete scenarios of several types of SMTP
+      sessions.
+
+   A Typical SMTP Transaction Scenario
+
+      This SMTP example shows mail sent by Smith at host USC-ISIF, to
+      Jones, Green, and Brown at host BBN-UNIX.  Here we assume that
+      host USC-ISIF contacts host BBN-UNIX directly.  The mail is
+      accepted for Jones and Brown.  Green does not have a mailbox at
+      host BBN-UNIX.
+
+      -------------------------------------------------------------
+
+         R: 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready
+         S: HELO USC-ISIF.ARPA
+         R: 250 BBN-UNIX.ARPA
+
+         S: MAIL FROM:<Smith@USC-ISIF.ARPA>
+         R: 250 OK
+
+         S: RCPT TO:<Jones@BBN-UNIX.ARPA>
+         R: 250 OK
+
+         S: RCPT TO:<Green@BBN-UNIX.ARPA>
+         R: 550 No such user here
+
+         S: RCPT TO:<Brown@BBN-UNIX.ARPA>
+         R: 250 OK
+
+         S: DATA
+         R: 354 Start mail input; end with <CRLF>.<CRLF>
+         S: Blah blah blah...
+         S: ...etc. etc. etc.
+         S: .
+         R: 250 OK
+
+         S: QUIT
+         R: 221 BBN-UNIX.ARPA Service closing transmission channel
+
+                               Scenario 1
+
+      -------------------------------------------------------------
+
+
+
+Postel                                                         [Page 51]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+   Aborted SMTP Transaction Scenario
+
+      -------------------------------------------------------------
+
+         R: 220 MIT-Multics.ARPA Simple Mail Transfer Service Ready
+         S: HELO ISI-VAXA.ARPA
+         R: 250 MIT-Multics.ARPA
+
+         S: MAIL FROM:<Smith@ISI-VAXA.ARPA>
+         R: 250 OK
+
+         S: RCPT TO:<Jones@MIT-Multics.ARPA>
+         R: 250 OK
+
+         S: RCPT TO:<Green@MIT-Multics.ARPA>
+         R: 550 No such user here
+
+         S: RSET
+         R: 250 OK
+
+         S: QUIT
+         R: 221 MIT-Multics.ARPA Service closing transmission channel
+
+                               Scenario 2
+
+      -------------------------------------------------------------
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 52]                                                         Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+   Relayed Mail Scenario
+
+      -------------------------------------------------------------
+
+         Step 1  --  Source Host to Relay Host
+
+            R: 220 USC-ISIE.ARPA Simple Mail Transfer Service Ready
+            S: HELO MIT-AI.ARPA
+            R: 250 USC-ISIE.ARPA
+
+            S: MAIL FROM:<JQP@MIT-AI.ARPA>
+            R: 250 OK
+
+            S: RCPT TO:<@USC-ISIE.ARPA:Jones@BBN-VAX.ARPA>
+            R: 250 OK
+
+            S: DATA
+            R: 354 Start mail input; end with <CRLF>.<CRLF>
+            S: Date: 2 Nov 81 22:33:44
+            S: From: John Q. Public <JQP@MIT-AI.ARPA>
+            S: Subject:  The Next Meeting of the Board
+            S: To: Jones@BBN-Vax.ARPA
+            S:
+            S: Bill:
+            S: The next meeting of the board of directors will be
+            S: on Tuesday.
+            S:                                              John.
+            S: .
+            R: 250 OK
+
+            S: QUIT
+            R: 221 USC-ISIE.ARPA Service closing transmission channel
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel                                                         [Page 53]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+         Step 2  --  Relay Host to Destination Host
+
+            R: 220 BBN-VAX.ARPA Simple Mail Transfer Service Ready
+            S: HELO USC-ISIE.ARPA
+            R: 250 BBN-VAX.ARPA
+
+            S: MAIL FROM:<@USC-ISIE.ARPA:JQP@MIT-AI.ARPA>
+            R: 250 OK
+
+            S: RCPT TO:<Jones@BBN-VAX.ARPA>
+            R: 250 OK
+
+            S: DATA
+            R: 354 Start mail input; end with <CRLF>.<CRLF>
+            S: Received: from MIT-AI.ARPA by USC-ISIE.ARPA ;
+               2 Nov 81 22:40:10 UT
+            S: Date: 2 Nov 81 22:33:44
+            S: From: John Q. Public <JQP@MIT-AI.ARPA>
+            S: Subject:  The Next Meeting of the Board
+            S: To: Jones@BBN-Vax.ARPA
+            S:
+            S: Bill:
+            S: The next meeting of the board of directors will be
+            S: on Tuesday.
+            S:                                              John.
+            S: .
+            R: 250 OK
+
+            S: QUIT
+            R: 221 USC-ISIE.ARPA Service closing transmission channel
+
+                               Scenario 3
+
+      -------------------------------------------------------------
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 54]                                                         Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+   Verifying and Sending Scenario
+
+      -------------------------------------------------------------
+
+         R: 220 SU-SCORE.ARPA Simple Mail Transfer Service Ready
+         S: HELO MIT-MC.ARPA
+         R: 250 SU-SCORE.ARPA
+
+         S: VRFY Crispin
+         R: 250 Mark Crispin <Admin.MRC@SU-SCORE.ARPA>
+
+         S: SEND FROM:<EAK@MIT-MC.ARPA>
+         R: 250 OK
+
+         S: RCPT TO:<Admin.MRC@SU-SCORE.ARPA>
+         R: 250 OK
+
+         S: DATA
+         R: 354 Start mail input; end with <CRLF>.<CRLF>
+         S: Blah blah blah...
+         S: ...etc. etc. etc.
+         S: .
+         R: 250 OK
+
+         S: QUIT
+         R: 221 SU-SCORE.ARPA Service closing transmission channel
+
+                               Scenario 4
+
+      -------------------------------------------------------------
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel                                                         [Page 55]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+   Sending and Mailing Scenarios
+
+      First the user's name is verified, then  an attempt is made to
+      send to the user's terminal.  When that fails, the messages is
+      mailed to the user's mailbox.
+
+      -------------------------------------------------------------
+
+         R: 220 SU-SCORE.ARPA Simple Mail Transfer Service Ready
+         S: HELO MIT-MC.ARPA
+         R: 250 SU-SCORE.ARPA
+
+         S: VRFY Crispin
+         R: 250 Mark Crispin <Admin.MRC@SU-SCORE.ARPA>
+
+         S: SEND FROM:<EAK@MIT-MC.ARPA>
+         R: 250 OK
+
+         S: RCPT TO:<Admin.MRC@SU-SCORE.ARPA>
+         R: 450 User not active now
+
+         S: RSET
+         R: 250 OK
+
+         S: MAIL FROM:<EAK@MIT-MC.ARPA>
+         R: 250 OK
+
+         S: RCPT TO:<Admin.MRC@SU-SCORE.ARPA>
+         R: 250 OK
+
+         S: DATA
+         R: 354 Start mail input; end with <CRLF>.<CRLF>
+         S: Blah blah blah...
+         S: ...etc. etc. etc.
+         S: .
+         R: 250 OK
+
+         S: QUIT
+         R: 221 SU-SCORE.ARPA Service closing transmission channel
+
+                               Scenario 5
+
+      -------------------------------------------------------------
+
+
+
+
+
+
+[Page 56]                                                         Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+      Doing the preceding scenario more efficiently.
+
+      -------------------------------------------------------------
+
+         R: 220 SU-SCORE.ARPA Simple Mail Transfer Service Ready
+         S: HELO MIT-MC.ARPA
+         R: 250 SU-SCORE.ARPA
+
+         S: VRFY Crispin
+         R: 250 Mark Crispin <Admin.MRC@SU-SCORE.ARPA>
+
+         S: SOML FROM:<EAK@MIT-MC.ARPA>
+         R: 250 OK
+
+         S: RCPT TO:<Admin.MRC@SU-SCORE.ARPA>
+         R: 250 User not active now, so will do mail.
+
+         S: DATA
+         R: 354 Start mail input; end with <CRLF>.<CRLF>
+         S: Blah blah blah...
+         S: ...etc. etc. etc.
+         S: .
+         R: 250 OK
+
+         S: QUIT
+         R: 221 SU-SCORE.ARPA Service closing transmission channel
+
+                               Scenario 6
+
+      -------------------------------------------------------------
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel                                                         [Page 57]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+   Mailing List Scenario
+
+      First each of two mailing lists are expanded in separate sessions
+      with different hosts.  Then the message is sent to everyone that
+      appeared on either list (but no duplicates) via a relay host.
+
+      -------------------------------------------------------------
+
+         Step 1  --  Expanding the First List
+
+            R: 220 MIT-AI.ARPA Simple Mail Transfer Service Ready
+            S: HELO SU-SCORE.ARPA
+            R: 250 MIT-AI.ARPA
+
+            S: EXPN Example-People
+            R: 250-<ABC@MIT-MC.ARPA>
+            R: 250-Fred Fonebone <Fonebone@USC-ISIQ.ARPA>
+            R: 250-Xenon Y. Zither <XYZ@MIT-AI.ARPA>
+            R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA>
+            R: 250-<joe@foo-unix.ARPA>
+            R: 250 <xyz@bar-unix.ARPA>
+
+            S: QUIT
+            R: 221 MIT-AI.ARPA Service closing transmission channel
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 58]                                                         Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+         Step 2  --  Expanding the Second List
+
+            R: 220 MIT-MC.ARPA Simple Mail Transfer Service Ready
+            S: HELO SU-SCORE.ARPA
+            R: 250 MIT-MC.ARPA
+
+            S: EXPN Interested-Parties
+            R: 250-Al Calico <ABC@MIT-MC.ARPA>
+            R: 250-<XYZ@MIT-AI.ARPA>
+            R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA>
+            R: 250-<fred@BBN-UNIX.ARPA>
+            R: 250 <xyz@bar-unix.ARPA>
+
+            S: QUIT
+            R: 221 MIT-MC.ARPA Service closing transmission channel
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel                                                         [Page 59]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+         Step 3  --  Mailing to All via a Relay Host
+
+            R: 220 USC-ISIE.ARPA Simple Mail Transfer Service Ready
+            S: HELO SU-SCORE.ARPA
+            R: 250 USC-ISIE.ARPA
+
+            S: MAIL FROM:<Account.Person@SU-SCORE.ARPA>
+            R: 250 OK
+            S: RCPT TO:<@USC-ISIE.ARPA:ABC@MIT-MC.ARPA>
+            R: 250 OK
+            S: RCPT TO:<@USC-ISIE.ARPA:Fonebone@USC-ISIQA.ARPA>
+            R: 250 OK
+            S: RCPT TO:<@USC-ISIE.ARPA:XYZ@MIT-AI.ARPA>
+            R: 250 OK
+            S: RCPT
+                TO:<@USC-ISIE.ARPA,@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA>
+            R: 250 OK
+            S: RCPT TO:<@USC-ISIE.ARPA:joe@FOO-UNIX.ARPA>
+            R: 250 OK
+            S: RCPT TO:<@USC-ISIE.ARPA:xyz@BAR-UNIX.ARPA>
+            R: 250 OK
+            S: RCPT TO:<@USC-ISIE.ARPA:fred@BBN-UNIX.ARPA>
+            R: 250 OK
+
+            S: DATA
+            R: 354 Start mail input; end with <CRLF>.<CRLF>
+            S: Blah blah blah...
+            S: ...etc. etc. etc.
+            S: .
+            R: 250 OK
+
+            S: QUIT
+            R: 221 USC-ISIE.ARPA Service closing transmission channel
+
+                               Scenario 7
+
+      -------------------------------------------------------------
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 60]                                                         Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+   Forwarding Scenarios
+
+      -------------------------------------------------------------
+
+         R: 220 USC-ISIF.ARPA Simple Mail Transfer Service Ready
+         S: HELO LBL-UNIX.ARPA
+         R: 250 USC-ISIF.ARPA
+
+         S: MAIL FROM:<mo@LBL-UNIX.ARPA>
+         R: 250 OK
+
+         S: RCPT TO:<fred@USC-ISIF.ARPA>
+         R: 251 User not local; will forward to <Jones@USC-ISI.ARPA>
+
+         S: DATA
+         R: 354 Start mail input; end with <CRLF>.<CRLF>
+         S: Blah blah blah...
+         S: ...etc. etc. etc.
+         S: .
+         R: 250 OK
+
+         S: QUIT
+         R: 221 USC-ISIF.ARPA Service closing transmission channel
+
+                               Scenario 8
+
+      -------------------------------------------------------------
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel                                                         [Page 61]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+      -------------------------------------------------------------
+
+         Step 1  --  Trying the Mailbox at the First Host
+
+            R: 220 USC-ISIF.ARPA Simple Mail Transfer Service Ready
+            S: HELO LBL-UNIX.ARPA
+            R: 250 USC-ISIF.ARPA
+
+            S: MAIL FROM:<mo@LBL-UNIX.ARPA>
+            R: 250 OK
+
+            S: RCPT TO:<fred@USC-ISIF.ARPA>
+            R: 251 User not local; will forward to <Jones@USC-ISI.ARPA>
+
+            S: RSET
+            R: 250 OK
+
+            S: QUIT
+            R: 221 USC-ISIF.ARPA Service closing transmission channel
+
+         Step 2  --  Delivering the Mail at the Second Host
+
+            R: 220 USC-ISI.ARPA Simple Mail Transfer Service Ready
+            S: HELO LBL-UNIX.ARPA
+            R: 250 USC-ISI.ARPA
+
+            S: MAIL FROM:<mo@LBL-UNIX.ARPA>
+            R: 250 OK
+
+            S: RCPT TO:<Jones@USC-ISI.ARPA>
+            R: OK
+
+            S: DATA
+            R: 354 Start mail input; end with <CRLF>.<CRLF>
+            S: Blah blah blah...
+            S: ...etc. etc. etc.
+            S: .
+            R: 250 OK
+
+            S: QUIT
+            R: 221 USC-ISI.ARPA Service closing transmission channel
+
+                               Scenario 9
+
+      -------------------------------------------------------------
+
+
+
+
+[Page 62]                                                         Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+   Too Many Recipients Scenario
+
+      -------------------------------------------------------------
+
+         R: 220 BERKELEY.ARPA Simple Mail Transfer Service Ready
+         S: HELO USC-ISIF.ARPA
+         R: 250 BERKELEY.ARPA
+
+         S: MAIL FROM:<Postel@USC-ISIF.ARPA>
+         R: 250 OK
+
+         S: RCPT TO:<fabry@BERKELEY.ARPA>
+         R: 250 OK
+
+         S: RCPT TO:<eric@BERKELEY.ARPA>
+         R: 552 Recipient storage full, try again in another transaction
+
+         S: DATA
+         R: 354 Start mail input; end with <CRLF>.<CRLF>
+         S: Blah blah blah...
+         S: ...etc. etc. etc.
+         S: .
+         R: 250 OK
+
+         S: MAIL FROM:<Postel@USC-ISIF.ARPA>
+         R: 250 OK
+
+         S: RCPT TO:<eric@BERKELEY.ARPA>
+         R: 250 OK
+
+         S: DATA
+         R: 354 Start mail input; end with <CRLF>.<CRLF>
+         S: Blah blah blah...
+         S: ...etc. etc. etc.
+         S: .
+         R: 250 OK
+
+         S: QUIT
+         R: 221 BERKELEY.ARPA Service closing transmission channel
+
+                              Scenario 10
+
+      -------------------------------------------------------------
+
+      Note that a real implementation must handle many recipients as
+      specified in Section 4.5.3.
+
+
+
+Postel                                                         [Page 63]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+GLOSSARY
+
+   ASCII
+
+      American Standard Code for Information Interchange [1].
+
+   command
+
+      A request for a mail service action sent by the sender-SMTP to the
+      receiver-SMTP.
+
+   domain
+
+      The hierarchially structured global character string address of a
+      host computer in the mail system.
+
+   end of mail data indication
+
+      A special sequence of characters that indicates the end of the
+      mail data.  In particular, the five characters carriage return,
+      line feed, period, carriage return, line feed, in that order.
+
+   host
+
+      A computer in the internetwork environment on which mailboxes or
+      SMTP processes reside.
+
+   line
+
+      A a sequence of ASCII characters ending with a <CRLF>.
+
+   mail data
+
+      A sequence of ASCII characters of arbitrary length, which conforms
+      to the standard set in the Standard for the Format of ARPA
+      Internet Text Messages (RFC 822 [2]).
+
+   mailbox
+
+      A character string (address) which identifies a user to whom mail
+      is to be sent.  Mailbox normally consists of the host and user
+      specifications.  The standard mailbox naming convention is defined
+      to be "user@domain".  Additionally, the "container" in which mail
+      is stored.
+
+
+
+
+
+[Page 64]                                                         Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+   receiver-SMTP process
+
+      A process which transfers mail in cooperation with a sender-SMTP
+      process.  It waits for a connection to be established via the
+      transport service.  It receives SMTP commands from the
+      sender-SMTP, sends replies, and performs the specified operations.
+
+   reply
+
+      A reply is an acknowledgment (positive or negative) sent from
+      receiver to sender via the transmission channel in response to a
+      command.  The general form of a reply is a completion code
+      (including error codes) followed by a text string.  The codes are
+      for use by programs and the text is usually intended for human
+      users.
+
+   sender-SMTP process
+
+      A process which transfers mail in cooperation with a receiver-SMTP
+      process.  A local language may be used in the user interface
+      command/reply dialogue.  The sender-SMTP initiates the transport
+      service connection.  It initiates SMTP commands, receives replies,
+      and governs the transfer of mail.
+
+   session
+
+      The set of exchanges that occur while the transmission channel is
+      open.
+
+   transaction
+
+      The set of exchanges required for one message to be transmitted
+      for one or more recipients.
+
+   transmission channel
+
+      A full-duplex communication path between a sender-SMTP and a
+      receiver-SMTP for the exchange of commands, replies, and mail
+      text.
+
+   transport service
+
+      Any reliable stream-oriented data communication services.  For
+      example, NCP, TCP, NITS.
+
+
+
+
+
+Postel                                                         [Page 65]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+   user
+
+      A human being (or a process on behalf of a human being) wishing to
+      obtain mail transfer service.  In addition, a recipient of
+      computer mail.
+
+   word
+
+      A sequence of printing characters.
+
+   <CRLF>
+
+      The characters carriage return and line feed (in that order).
+
+   <SP>
+
+      The space character.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 66]                                                         Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+REFERENCES
+
+   [1]  ASCII
+
+      ASCII, "USA Code for Information Interchange", United States of
+      America Standards Institute, X3.4, 1968.  Also in:  Feinler, E.
+      and J. Postel, eds., "ARPANET Protocol Handbook", NIC 7104, for
+      the Defense Communications Agency by SRI International, Menlo
+      Park, California, Revised January 1978.
+
+   [2]  RFC 822
+
+      Crocker, D., "Standard for the Format of ARPA Internet Text
+      Messages," RFC 822, Department of Electrical Engineering,
+      University of Delaware, August 1982.
+
+   [3]  TCP
+
+      Postel, J., ed., "Transmission Control Protocol - DARPA Internet
+      Program Protocol Specification", RFC 793, USC/Information Sciences
+      Institute, NTIS AD Number A111091, September 1981.  Also in:
+      Feinler, E. and J. Postel, eds., "Internet Protocol Transition
+      Workbook", SRI International, Menlo Park, California, March 1982.
+
+   [4]  NCP
+
+      McKenzie,A., "Host/Host Protocol for the ARPA Network", NIC 8246,
+      January 1972.  Also in:  Feinler, E. and J. Postel, eds., "ARPANET
+      Protocol Handbook", NIC 7104, for the Defense Communications
+      Agency by SRI International, Menlo Park, California, Revised
+      January 1978.
+
+   [5]  Initial Connection Protocol
+
+      Postel, J., "Official Initial Connection Protocol", NIC 7101,
+      11 June 1971.  Also in:  Feinler, E. and J. Postel, eds., "ARPANET
+      Protocol Handbook", NIC 7104, for the Defense Communications
+      Agency by SRI International, Menlo Park, California, Revised
+      January 1978.
+
+   [6]  NITS
+
+      PSS/SG3, "A Network Independent Transport Service", Study Group 3,
+      The Post Office PSS Users Group, February 1980.  Available from
+      the DCPU, National Physical Laboratory, Teddington, UK.
+
+
+
+
+Postel                                                         [Page 67]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+   [7]  X.25
+
+      CCITT, "Recommendation X.25 - Interface Between Data Terminal
+      Equipment (DTE) and Data Circuit-terminating Equipment (DCE) for
+      Terminals Operating in the Packet Mode on Public Data Networks,"
+      CCITT Orange Book, Vol. VIII.2, International Telephone and
+      Telegraph Consultative Committee, Geneva, 1976.
+
+         
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 68]                                                         Postel
+
diff --git a/doc/devel/rfc/rfc822.txt b/doc/devel/rfc/rfc822.txt
new file mode 100644
index 00000000..35b09a3c
--- /dev/null
+++ b/doc/devel/rfc/rfc822.txt
@@ -0,0 +1,2901 @@
+
+ 
+
+
+
+
+     RFC #  822
+
+     Obsoletes:  RFC #733  (NIC #41952)
+
+
+
+
+
+
+
+
+
+
+
+
+                        STANDARD FOR THE FORMAT OF
+
+                        ARPA INTERNET TEXT MESSAGES
+
+
+
+
+
+
+                              August 13, 1982
+
+
+
+
+
+
+                                Revised by
+
+                             David H. Crocker
+
+
+                      Dept. of Electrical Engineering
+                 University of Delaware, Newark, DE  19711
+                      Network:  DCrocker @ UDel-Relay
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+                             TABLE OF CONTENTS
+
+
+     PREFACE ....................................................   ii
+
+     1.  INTRODUCTION ...........................................    1
+
+         1.1.  Scope ............................................    1
+         1.2.  Communication Framework ..........................    2
+
+     2.  NOTATIONAL CONVENTIONS .................................    3
+
+     3.  LEXICAL ANALYSIS OF MESSAGES ...........................    5
+
+         3.1.  General Description ..............................    5
+         3.2.  Header Field Definitions .........................    9
+         3.3.  Lexical Tokens ...................................   10
+         3.4.  Clarifications ...................................   11
+
+     4.  MESSAGE SPECIFICATION ..................................   17
+
+         4.1.  Syntax ...........................................   17
+         4.2.  Forwarding .......................................   19
+         4.3.  Trace Fields .....................................   20
+         4.4.  Originator Fields ................................   21
+         4.5.  Receiver Fields ..................................   23
+         4.6.  Reference Fields .................................   23
+         4.7.  Other Fields .....................................   24
+
+     5.  DATE AND TIME SPECIFICATION ............................   26
+
+         5.1.  Syntax ...........................................   26
+         5.2.  Semantics ........................................   26
+
+     6.  ADDRESS SPECIFICATION ..................................   27
+
+         6.1.  Syntax ...........................................   27
+         6.2.  Semantics ........................................   27
+         6.3.  Reserved Address .................................   33
+
+     7.  BIBLIOGRAPHY ...........................................   34
+
+
+                             APPENDIX
+
+     A.  EXAMPLES ...............................................   36
+     B.  SIMPLE FIELD PARSING ...................................   40
+     C.  DIFFERENCES FROM RFC #733 ..............................   41
+     D.  ALPHABETICAL LISTING OF SYNTAX RULES ...................   44
+
+
+     August 13, 1982               - i -                      RFC #822
+
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+                                  PREFACE
+
+
+          By 1977, the Arpanet employed several informal standards for
+     the  text  messages (mail) sent among its host computers.  It was
+     felt necessary to codify these practices and  provide  for  those
+     features  that  seemed  imminent.   The result of that effort was
+     Request for Comments (RFC) #733, "Standard for the Format of ARPA
+     Network Text Message", by Crocker, Vittal, Pogran, and Henderson.
+     The specification attempted to avoid major  changes  in  existing
+     software, while permitting several new features.
+
+          This document revises the specifications  in  RFC  #733,  in
+     order  to  serve  the  needs  of the larger and more complex ARPA
+     Internet.  Some of RFC #733's features failed  to  gain  adequate
+     acceptance.   In  order to simplify the standard and the software
+     that follows it, these features have been removed.   A  different
+     addressing  scheme  is  used, to handle the case of inter-network
+     mail; and the concept of re-transmission has been introduced.
+
+          This specification is intended for use in the ARPA Internet.
+     However, an attempt has been made to free it of any dependence on
+     that environment, so that it can be applied to other network text
+     message systems.
+
+          The specification of RFC #733 took place over the course  of
+     one  year, using the ARPANET mail environment, itself, to provide
+     an on-going forum for discussing the capabilities to be included.
+     More  than  twenty individuals, from across the country, partici-
+     pated in  the  original  discussion.   The  development  of  this
+     revised specification has, similarly, utilized network mail-based
+     group discussion.  Both specification efforts  greatly  benefited
+     from the comments and ideas of the participants.
+
+          The syntax of the standard,  in  RFC  #733,  was  originally
+     specified  in  the  Backus-Naur Form (BNF) meta-language.  Ken L.
+     Harrenstien, of SRI International, was responsible for  re-coding
+     the  BNF  into  an  augmented  BNF  that makes the representation
+     smaller and easier to understand.
+
+
+
+
+
+
+
+
+
+
+
+
+     August 13, 1982              - ii -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+     1.  INTRODUCTION
+
+     1.1.  SCOPE
+
+          This standard specifies a syntax for text messages that  are
+     sent  among  computer  users, within the framework of "electronic
+     mail".  The standard supersedes  the  one  specified  in  ARPANET
+     Request  for Comments #733, "Standard for the Format of ARPA Net-
+     work Text Messages".
+
+          In this context, messages are viewed as having  an  envelope
+     and  contents.   The  envelope  contains  whatever information is
+     needed to accomplish transmission  and  delivery.   The  contents
+     compose  the object to be delivered to the recipient.  This stan-
+     dard applies only to the format and some of the semantics of mes-
+     sage  contents.   It contains no specification of the information
+     in the envelope.
+
+          However, some message systems may use information  from  the
+     contents  to create the envelope.  It is intended that this stan-
+     dard facilitate the acquisition of such information by programs.
+
+          Some message systems may  store  messages  in  formats  that
+     differ  from the one specified in this standard.  This specifica-
+     tion is intended strictly as a definition of what message content
+     format is to be passed BETWEEN hosts.
+
+     Note:  This standard is NOT intended to dictate the internal for-
+            mats  used  by sites, the specific message system features
+            that they are expected to support, or any of  the  charac-
+            teristics  of  user interface programs that create or read
+            messages.
+
+          A distinction should be made between what the  specification
+     REQUIRES  and  what  it ALLOWS.  Messages can be made complex and
+     rich with formally-structured components of information or can be
+     kept small and simple, with a minimum of such information.  Also,
+     the standard simplifies the interpretation  of  differing  visual
+     formats  in  messages;  only  the  visual  aspect of a message is
+     affected and not the interpretation  of  information  within  it.
+     Implementors may choose to retain such visual distinctions.
+
+          The formal definition is divided into four levels.  The bot-
+     tom level describes the meta-notation used in this document.  The
+     second level describes basic lexical analyzers that  feed  tokens
+     to  higher-level  parsers.   Next is an overall specification for
+     messages; it permits distinguishing individual fields.   Finally,
+     there is definition of the contents of several structured fields.
+
+
+
+     August 13, 1982               - 1 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+     1.2.  COMMUNICATION FRAMEWORK
+
+          Messages consist of lines of text.   No  special  provisions
+     are  made for encoding drawings, facsimile, speech, or structured
+     text.  No significant consideration has been given  to  questions
+     of  data  compression  or to transmission and storage efficiency,
+     and the standard tends to be free with the number  of  bits  con-
+     sumed.   For  example,  field  names  are specified as free text,
+     rather than special terse codes.
+
+          A general "memo" framework is used.  That is, a message con-
+     sists of some information in a rigid format, followed by the main
+     part of the message, with a format that is not specified in  this
+     document.   The  syntax of several fields of the rigidly-formated
+     ("headers") section is defined in  this  specification;  some  of
+     these fields must be included in all messages.
+
+          The syntax  that  distinguishes  between  header  fields  is
+     specified  separately  from  the  internal  syntax for particular
+     fields.  This separation is intended to allow simple  parsers  to
+     operate on the general structure of messages, without concern for
+     the detailed structure of individual header fields.   Appendix  B
+     is provided to facilitate construction of these parsers.
+
+          In addition to the fields specified in this document, it  is
+     expected  that  other fields will gain common use.  As necessary,
+     the specifications for these "extension-fields" will be published
+     through  the same mechanism used to publish this document.  Users
+     may also  wish  to  extend  the  set  of  fields  that  they  use
+     privately.  Such "user-defined fields" are permitted.
+
+          The framework severely constrains document tone and  appear-
+     ance and is primarily useful for most intra-organization communi-
+     cations and  well-structured   inter-organization  communication.
+     It  also  can  be used for some types of inter-process communica-
+     tion, such as simple file transfer and remote job entry.  A  more
+     robust  framework might allow for multi-font, multi-color, multi-
+     dimension encoding of information.  A  less  robust  one,  as  is
+     present  in  most  single-machine  message  systems,  would  more
+     severely constrain the ability to add fields and the decision  to
+     include specific fields.  In contrast with paper-based communica-
+     tion, it is interesting to note that the RECEIVER  of  a  message
+     can   exercise  an  extraordinary  amount  of  control  over  the
+     message's appearance.  The amount of actual control available  to
+     message  receivers  is  contingent upon the capabilities of their
+     individual message systems.
+
+
+
+
+
+     August 13, 1982               - 2 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+     2.  NOTATIONAL CONVENTIONS
+
+          This specification uses an augmented Backus-Naur Form  (BNF)
+     notation.  The differences from standard BNF involve naming rules
+     and indicating repetition and "local" alternatives.
+
+     2.1.  RULE NAMING
+
+          Angle brackets ("<", ">") are not  used,  in  general.   The
+     name  of  a rule is simply the name itself, rather than "<name>".
+     Quotation-marks enclose literal text (which may be  upper  and/or
+     lower  case).   Certain  basic  rules  are  in uppercase, such as
+     SPACE, TAB, CRLF, DIGIT, ALPHA, etc.  Angle brackets are used  in
+     rule  definitions,  and  in  the rest of this  document, whenever
+     their presence will facilitate discerning the use of rule names.
+
+     2.2.  RULE1 / RULE2:  ALTERNATIVES
+
+          Elements separated by slash ("/") are alternatives.   There-
+     fore "foo / bar" will accept foo or bar.
+
+     2.3.  (RULE1 RULE2):  LOCAL ALTERNATIVES
+
+          Elements enclosed in parentheses are  treated  as  a  single
+     element.   Thus,  "(elem  (foo  /  bar)  elem)"  allows the token
+     sequences "elem foo elem" and "elem bar elem".
+
+     2.4.  *RULE:  REPETITION
+
+          The character "*" preceding an element indicates repetition.
+     The full form is:
+
+                              <l>*<m>element
+
+     indicating at least <l> and at most <m> occurrences  of  element.
+     Default values are 0 and infinity so that "*(element)" allows any
+     number, including zero; "1*element" requires at  least  one;  and
+     "1*2element" allows one or two.
+
+     2.5.  [RULE]:  OPTIONAL
+
+          Square brackets enclose optional elements; "[foo  bar]"   is
+     equivalent to "*1(foo bar)".
+
+     2.6.  NRULE:  SPECIFIC REPETITION
+
+          "<n>(element)" is equivalent to "<n>*<n>(element)"; that is,
+     exactly  <n>  occurrences  of (element). Thus 2DIGIT is a 2-digit
+     number, and 3ALPHA is a string of three alphabetic characters.
+
+
+     August 13, 1982               - 3 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+     2.7.  #RULE:  LISTS
+
+          A construct "#" is defined, similar to "*", as follows:
+
+                              <l>#<m>element
+
+     indicating at least <l> and at most <m> elements, each  separated
+     by  one  or more commas (","). This makes the usual form of lists
+     very easy; a rule such as '(element *("," element))' can be shown
+     as  "1#element".   Wherever this construct is used, null elements
+     are allowed, but do not  contribute  to  the  count  of  elements
+     present.   That  is,  "(element),,(element)"  is  permitted,  but
+     counts as only two elements.  Therefore, where at least one  ele-
+     ment  is required, at least one non-null element must be present.
+     Default values are 0 and infinity so that "#(element)" allows any
+     number,  including  zero;  "1#element" requires at least one; and
+     "1#2element" allows one or two.
+
+     2.8.  ; COMMENTS
+
+          A semi-colon, set off some distance to  the  right  of  rule
+     text,  starts  a comment that continues to the end of line.  This
+     is a simple way of including useful notes in  parallel  with  the
+     specifications.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+     August 13, 1982               - 4 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+     3.  LEXICAL ANALYSIS OF MESSAGES
+
+     3.1.  GENERAL DESCRIPTION
+
+          A message consists of header fields and, optionally, a body.
+     The  body  is simply a sequence of lines containing ASCII charac-
+     ters.  It is separated from the headers by a null line  (i.e.,  a
+     line with nothing preceding the CRLF).
+
+     3.1.1.  LONG HEADER FIELDS
+
+        Each header field can be viewed as a single, logical  line  of
+        ASCII  characters,  comprising  a field-name and a field-body.
+        For convenience, the field-body  portion  of  this  conceptual
+        entity  can be split into a multiple-line representation; this
+        is called "folding".  The general rule is that wherever  there
+        may  be  linear-white-space  (NOT  simply  LWSP-chars), a CRLF
+        immediately followed by AT LEAST one LWSP-char may instead  be
+        inserted.  Thus, the single line
+
+            To:  "Joe & J. Harvey" <ddd @Org>, JJV @ BBN
+
+        can be represented as:
+
+            To:  "Joe & J. Harvey" <ddd @ Org>,
+                    JJV@BBN
+
+        and
+
+            To:  "Joe & J. Harvey"
+                            <ddd@ Org>, JJV
+             @BBN
+
+        and
+
+            To:  "Joe &
+             J. Harvey" <ddd @ Org>, JJV @ BBN
+
+             The process of moving  from  this  folded   multiple-line
+        representation  of a header field to its single line represen-
+        tation is called "unfolding".  Unfolding  is  accomplished  by
+        regarding   CRLF   immediately  followed  by  a  LWSP-char  as
+        equivalent to the LWSP-char.
+
+        Note:  While the standard  permits  folding  wherever  linear-
+               white-space is permitted, it is recommended that struc-
+               tured fields, such as those containing addresses, limit
+               folding  to higher-level syntactic breaks.  For address
+               fields, it  is  recommended  that  such  folding  occur
+
+
+     August 13, 1982               - 5 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+               between addresses, after the separating comma.
+
+     3.1.2.  STRUCTURE OF HEADER FIELDS
+
+        Once a field has been unfolded, it may be viewed as being com-
+        posed of a field-name followed by a colon (":"), followed by a
+        field-body, and  terminated  by  a  carriage-return/line-feed.
+        The  field-name must be composed of printable ASCII characters
+        (i.e., characters that  have  values  between  33.  and  126.,
+        decimal, except colon).  The field-body may be composed of any
+        ASCII characters, except CR or LF.  (While CR and/or LF may be
+        present  in the actual text, they are removed by the action of
+        unfolding the field.)
+
+        Certain field-bodies of headers may be  interpreted  according
+        to  an  internal  syntax  that some systems may wish to parse.
+        These  fields  are  called  "structured   fields".    Examples
+        include  fields containing dates and addresses.  Other fields,
+        such as "Subject"  and  "Comments",  are  regarded  simply  as
+        strings of text.
+
+        Note:  Any field which has a field-body  that  is  defined  as
+               other  than  simply <text> is to be treated as a struc-
+               tured field.
+
+               Field-names, unstructured field bodies  and  structured
+               field bodies each are scanned by their own, independent
+               "lexical" analyzers.
+
+     3.1.3.  UNSTRUCTURED FIELD BODIES
+
+        For some fields, such as "Subject" and "Comments",  no  struc-
+        turing  is assumed, and they are treated simply as <text>s, as
+        in the message body.  Rules of folding apply to these  fields,
+        so  that  such  field  bodies  which occupy several lines must
+        therefore have the second and successive lines indented by  at
+        least one LWSP-char.
+
+     3.1.4.  STRUCTURED FIELD BODIES
+
+        To aid in the creation and reading of structured  fields,  the
+        free  insertion   of linear-white-space (which permits folding
+        by inclusion of CRLFs)  is  allowed  between  lexical  tokens.
+        Rather  than  obscuring  the  syntax  specifications for these
+        structured fields with explicit syntax for this  linear-white-
+        space, the existence of another "lexical" analyzer is assumed.
+        This analyzer does not apply  for  unstructured  field  bodies
+        that  are  simply  strings  of  text, as described above.  The
+        analyzer provides  an  interpretation  of  the  unfolded  text
+
+
+     August 13, 1982               - 6 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+        composing  the body of the field as a sequence of lexical sym-
+        bols.
+
+        These symbols are:
+
+                     -  individual special characters
+                     -  quoted-strings
+                     -  domain-literals
+                     -  comments
+                     -  atoms
+
+        The first four of these symbols  are  self-delimiting.   Atoms
+        are not; they are delimited by the self-delimiting symbols and
+        by  linear-white-space.   For  the  purposes  of  regenerating
+        sequences  of  atoms  and quoted-strings, exactly one SPACE is
+        assumed to exist, and should be used, between them.  (Also, in
+        the "Clarifications" section on "White Space", below, note the
+        rules about treatment of multiple contiguous LWSP-chars.)
+
+        So, for example, the folded body of an address field
+
+            ":sysmail"@  Some-Group. Some-Org,
+            Muhammed.(I am  the greatest) Ali @(the)Vegas.WBA
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+     August 13, 1982               - 7 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+        is analyzed into the following lexical symbols and types:
+
+                    :sysmail              quoted string
+                    @                     special
+                    Some-Group            atom
+                    .                     special
+                    Some-Org              atom
+                    ,                     special
+                    Muhammed              atom
+                    .                     special
+                    (I am  the greatest)  comment
+                    Ali                   atom
+                    @                     atom
+                    (the)                 comment
+                    Vegas                 atom
+                    .                     special
+                    WBA                   atom
+
+        The canonical representations for the data in these  addresses
+        are the following strings:
+
+                        ":sysmail"@Some-Group.Some-Org
+
+        and
+
+                            Muhammed.Ali@Vegas.WBA
+
+        Note:  For purposes of display, and when passing  such  struc-
+               tured information to other systems, such as mail proto-
+               col  services,  there  must  be  NO  linear-white-space
+               between  <word>s  that are separated by period (".") or
+               at-sign ("@") and exactly one SPACE between  all  other
+               <word>s.  Also, headers should be in a folded form.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+     August 13, 1982               - 8 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+     3.2.  HEADER FIELD DEFINITIONS
+
+          These rules show a field meta-syntax, without regard for the
+     particular  type  or internal syntax.  Their purpose is to permit
+     detection of fields; also, they present to  higher-level  parsers
+     an image of each field as fitting on one line.
+
+     field       =  field-name ":" [ field-body ] CRLF
+
+     field-name  =  1*<any CHAR, excluding CTLs, SPACE, and ":">
+
+     field-body  =  field-body-contents
+                    [CRLF LWSP-char field-body]
+
+     field-body-contents =
+                   <the ASCII characters making up the field-body, as
+                    defined in the following sections, and consisting
+                    of combinations of atom, quoted-string, and
+                    specials tokens, or else consisting of texts>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+     August 13, 1982               - 9 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+     3.3.  LEXICAL TOKENS
+
+          The following rules are used to define an underlying lexical
+     analyzer,  which  feeds  tokens to higher level parsers.  See the
+     ANSI references, in the Bibliography.
+
+                                                 ; (  Octal, Decimal.)
+     CHAR        =  <any ASCII character>        ; (  0-177,  0.-127.)
+     ALPHA       =  <any ASCII alphabetic character>
+                                                 ; (101-132, 65.- 90.)
+                                                 ; (141-172, 97.-122.)
+     DIGIT       =  <any ASCII decimal digit>    ; ( 60- 71, 48.- 57.)
+     CTL         =  <any ASCII control           ; (  0- 37,  0.- 31.)
+                     character and DEL>          ; (    177,     127.)
+     CR          =  <ASCII CR, carriage return>  ; (     15,      13.)
+     LF          =  <ASCII LF, linefeed>         ; (     12,      10.)
+     SPACE       =  <ASCII SP, space>            ; (     40,      32.)
+     HTAB        =  <ASCII HT, horizontal-tab>   ; (     11,       9.)
+     <">         =  <ASCII quote mark>           ; (     42,      34.)
+     CRLF        =  CR LF
+
+     LWSP-char   =  SPACE / HTAB                 ; semantics = SPACE
+
+     linear-white-space =  1*([CRLF] LWSP-char)  ; semantics = SPACE
+                                                 ; CRLF => folding
+
+     specials    =  "(" / ")" / "<" / ">" / "@"  ; Must be in quoted-
+                 /  "," / ";" / ":" / "\" / <">  ;  string, to use
+                 /  "." / "[" / "]"              ;  within a word.
+
+     delimiters  =  specials / linear-white-space / comment
+
+     text        =  <any CHAR, including bare    ; => atoms, specials,
+                     CR & bare LF, but NOT       ;  comments and
+                     including CRLF>             ;  quoted-strings are
+                                                 ;  NOT recognized.
+
+     atom        =  1*<any CHAR except specials, SPACE and CTLs>
+
+     quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or
+                                                 ;   quoted chars.
+
+     qtext       =  <any CHAR excepting <">,     ; => may be folded
+                     "\" & CR, and including
+                     linear-white-space>
+
+     domain-literal =  "[" *(dtext / quoted-pair) "]"
+
+
+
+
+     August 13, 1982              - 10 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+     dtext       =  <any CHAR excluding "[",     ; => may be folded
+                     "]", "\" & CR, & including
+                     linear-white-space>
+
+     comment     =  "(" *(ctext / quoted-pair / comment) ")"
+
+     ctext       =  <any CHAR excluding "(",     ; => may be folded
+                     ")", "\" & CR, & including
+                     linear-white-space>
+
+     quoted-pair =  "\" CHAR                     ; may quote any char
+
+     phrase      =  1*word                       ; Sequence of words
+
+     word        =  atom / quoted-string
+
+
+     3.4.  CLARIFICATIONS
+
+     3.4.1.  QUOTING
+
+        Some characters are reserved for special interpretation,  such
+        as  delimiting lexical tokens.  To permit use of these charac-
+        ters as uninterpreted data, a quoting mechanism  is  provided.
+        To quote a character, precede it with a backslash ("\").
+
+        This mechanism is not fully general.  Characters may be quoted
+        only  within  a subset of the lexical constructs.  In particu-
+        lar, quoting is limited to use within:
+
+                             -  quoted-string
+                             -  domain-literal
+                             -  comment
+
+        Within these constructs, quoting is REQUIRED for  CR  and  "\"
+        and for the character(s) that delimit the token (e.g., "(" and
+        ")" for a comment).  However, quoting  is  PERMITTED  for  any
+        character.
+
+        Note:  In particular, quoting is NOT permitted  within  atoms.
+               For  example  when  the local-part of an addr-spec must
+               contain a special character, a quoted  string  must  be
+               used.  Therefore, a specification such as:
+
+                            Full\ Name@Domain
+
+               is not legal and must be specified as:
+
+                            "Full Name"@Domain
+
+
+     August 13, 1982              - 11 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+     3.4.2.  WHITE SPACE
+
+        Note:  In structured field bodies, multiple linear space ASCII
+               characters  (namely  HTABs  and  SPACEs) are treated as
+               single spaces and may freely surround any  symbol.   In
+               all header fields, the only place in which at least one
+               LWSP-char is REQUIRED is at the beginning of  continua-
+               tion lines in a folded field.
+
+        When passing text to processes  that  do  not  interpret  text
+        according to this standard (e.g., mail protocol servers), then
+        NO linear-white-space characters should occur between a period
+        (".") or at-sign ("@") and a <word>.  Exactly ONE SPACE should
+        be used in place of arbitrary linear-white-space  and  comment
+        sequences.
+
+        Note:  Within systems conforming to this standard, wherever  a
+               member of the list of delimiters is allowed, LWSP-chars
+               may also occur before and/or after it.
+
+        Writers of  mail-sending  (i.e.,  header-generating)  programs
+        should realize that there is no network-wide definition of the
+        effect of ASCII HT (horizontal-tab) characters on the  appear-
+        ance  of  text  at another network host; therefore, the use of
+        tabs in message headers, though permitted, is discouraged.
+
+     3.4.3.  COMMENTS
+
+        A comment is a set of ASCII characters, which is  enclosed  in
+        matching  parentheses  and which is not within a quoted-string
+        The comment construct permits message originators to add  text
+        which  will  be  useful  for  human readers, but which will be
+        ignored by the formal semantics.  Comments should be  retained
+        while  the  message  is subject to interpretation according to
+        this standard.  However, comments  must  NOT  be  included  in
+        other  cases,  such  as  during  protocol  exchanges with mail
+        servers.
+
+        Comments nest, so that if an unquoted left parenthesis  occurs
+        in  a  comment  string,  there  must  also be a matching right
+        parenthesis.  When a comment acts as the delimiter  between  a
+        sequence of two lexical symbols, such as two atoms, it is lex-
+        ically equivalent with a single SPACE,  for  the  purposes  of
+        regenerating  the  sequence, such as when passing the sequence
+        onto a mail protocol server.  Comments are  detected  as  such
+        only within field-bodies of structured fields.
+
+        If a comment is to be "folded" onto multiple lines,  then  the
+        syntax  for  folding  must  be  adhered to.  (See the "Lexical
+
+
+     August 13, 1982              - 12 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+        Analysis of Messages" section on "Folding Long Header  Fields"
+        above,  and  the  section on "Case Independence" below.)  Note
+        that  the  official  semantics  therefore  do  not  "see"  any
+        unquoted CRLFs that are in comments, although particular pars-
+        ing programs may wish to note their presence.  For these  pro-
+        grams,  it would be reasonable to interpret a "CRLF LWSP-char"
+        as being a CRLF that is part of the comment; i.e., the CRLF is
+        kept  and  the  LWSP-char is discarded.  Quoted CRLFs (i.e., a
+        backslash followed by a CR followed by a  LF)  still  must  be
+        followed by at least one LWSP-char.
+
+     3.4.4.  DELIMITING AND QUOTING CHARACTERS
+
+        The quote character (backslash) and  characters  that  delimit
+        syntactic  units  are not, generally, to be taken as data that
+        are part of the delimited or quoted unit(s).   In  particular,
+        the   quotation-marks   that   define   a  quoted-string,  the
+        parentheses that define  a  comment  and  the  backslash  that
+        quotes  a  following  character  are  NOT  part of the quoted-
+        string, comment or quoted character.  A quotation-mark that is
+        to  be  part  of  a quoted-string, a parenthesis that is to be
+        part of a comment and a backslash that is to be part of either
+        must  each be preceded by the quote-character backslash ("\").
+        Note that the syntax allows any character to be quoted  within
+        a  quoted-string  or  comment; however only certain characters
+        MUST be quoted to be included as data.  These  characters  are
+        the  ones that are not part of the alternate text group (i.e.,
+        ctext or qtext).
+
+        The one exception to this rule  is  that  a  single  SPACE  is
+        assumed  to  exist  between  contiguous words in a phrase, and
+        this interpretation is independent of  the  actual  number  of
+        LWSP-chars  that  the  creator  places  between the words.  To
+        include more than one SPACE, the creator must make  the  LWSP-
+        chars be part of a quoted-string.
+
+        Quotation marks that delimit a quoted string  and  backslashes
+        that  quote  the  following character should NOT accompany the
+        quoted-string when the string is passed to processes  that  do
+        not interpret data according to this specification (e.g., mail
+        protocol servers).
+
+     3.4.5.  QUOTED-STRINGS
+
+        Where permitted (i.e., in words in structured fields)  quoted-
+        strings  are  treated  as a single symbol.  That is, a quoted-
+        string is equivalent to an atom, syntactically.  If a  quoted-
+        string  is to be "folded" onto multiple lines, then the syntax
+        for folding must be adhered to.  (See the "Lexical Analysis of
+
+
+     August 13, 1982              - 13 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+        Messages"  section  on "Folding Long Header Fields" above, and
+        the section on "Case  Independence"  below.)   Therefore,  the
+        official  semantics  do  not  "see" any bare CRLFs that are in
+        quoted-strings; however particular parsing programs  may  wish
+        to  note  their presence.  For such programs, it would be rea-
+        sonable to interpret a "CRLF LWSP-char" as being a CRLF  which
+        is  part  of the quoted-string; i.e., the CRLF is kept and the
+        LWSP-char is discarded.  Quoted CRLFs (i.e., a backslash  fol-
+        lowed  by  a CR followed by a LF) are also subject to rules of
+        folding, but the presence of the quoting character (backslash)
+        explicitly  indicates  that  the  CRLF  is  data to the quoted
+        string.  Stripping off the first following LWSP-char  is  also
+        appropriate when parsing quoted CRLFs.
+
+     3.4.6.  BRACKETING CHARACTERS
+
+        There is one type of bracket which must occur in matched pairs
+        and may have pairs nested within each other:
+
+            o   Parentheses ("(" and ")") are used  to  indicate  com-
+                ments.
+
+        There are three types of brackets which must occur in  matched
+        pairs, and which may NOT be nested:
+
+            o   Colon/semi-colon (":" and ";") are   used  in  address
+                specifications  to  indicate that the included list of
+                addresses are to be treated as a group.
+
+            o   Angle brackets ("<" and ">")  are  generally  used  to
+                indicate  the  presence of a one machine-usable refer-
+                ence (e.g., delimiting mailboxes), possibly  including
+                source-routing to the machine.
+
+            o   Square brackets ("[" and "]") are used to indicate the
+                presence  of  a  domain-literal, which the appropriate
+                name-domain  is  to  use  directly,  bypassing  normal
+                name-resolution mechanisms.
+
+     3.4.7.  CASE INDEPENDENCE
+
+        Except as noted, alphabetic strings may be represented in  any
+        combination of upper and lower case.  The only syntactic units
+
+
+
+
+
+
+
+
+     August 13, 1982              - 14 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+        which requires preservation of case information are:
+
+                    -  text
+                    -  qtext
+                    -  dtext
+                    -  ctext
+                    -  quoted-pair
+                    -  local-part, except "Postmaster"
+
+        When matching any other syntactic unit, case is to be ignored.
+        For  example, the field-names "From", "FROM", "from", and even
+        "FroM" are semantically equal and should all be treated ident-
+        ically.
+
+        When generating these units, any mix of upper and  lower  case
+        alphabetic  characters  may  be  used.  The case shown in this
+        specification is suggested for message-creating processes.
+
+        Note:  The reserved local-part address unit, "Postmaster",  is
+               an  exception.   When  the  value "Postmaster" is being
+               interpreted, it must be  accepted  in  any  mixture  of
+               case, including "POSTMASTER", and "postmaster".
+
+     3.4.8.  FOLDING LONG HEADER FIELDS
+
+        Each header field may be represented on exactly one line  con-
+        sisting  of the name of the field and its body, and terminated
+        by a CRLF; this is what the parser sees.  For readability, the
+        field-body  portion of long header fields may be "folded" onto
+        multiple lines of the actual field.  "Long" is commonly inter-
+        preted  to  mean greater than 65 or 72 characters.  The former
+        length serves as a limit, when the message is to be viewed  on
+        most  simple terminals which use simple display software; how-
+        ever, the limit is not imposed by this standard.
+
+        Note:  Some display software often can selectively fold lines,
+               to  suit  the display terminal.  In such cases, sender-
+               provided  folding  can  interfere  with   the   display
+               software.
+
+     3.4.9.  BACKSPACE CHARACTERS
+
+        ASCII BS characters (Backspace, decimal 8) may be included  in
+        texts and quoted-strings to effect overstriking.  However, any
+        use of backspaces which effects an overstrike to the  left  of
+        the beginning of the text or quoted-string is prohibited.
+
+
+
+
+
+     August 13, 1982              - 15 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+     3.4.10.  NETWORK-SPECIFIC TRANSFORMATIONS
+
+        During transmission through heterogeneous networks, it may  be
+        necessary  to  force data to conform to a network's local con-
+        ventions.  For example, it may be required that a CR  be  fol-
+        lowed  either by LF, making a CRLF, or by <null>, if the CR is
+        to stand alone).  Such transformations are reversed, when  the
+        message exits that network.
+
+        When  crossing  network  boundaries,  the  message  should  be
+        treated  as  passing  through  two modules.  It will enter the
+        first module containing whatever network-specific  transforma-
+        tions  that  were  necessary  to  permit migration through the
+        "current" network.  It then passes through the modules:
+
+            o   Transformation Reversal
+
+                The "current" network's idiosyncracies are removed and
+                the  message  is returned to the canonical form speci-
+                fied in this standard.
+
+            o   Transformation
+
+                The "next" network's local idiosyncracies are  imposed
+                on the message.
+
+                                ------------------
+                    From   ==>  | Remove Net-A   |
+                    Net-A       | idiosyncracies |
+                                ------------------
+                                       ||
+                                       \/
+                                  Conformance
+                                  with standard
+                                       ||
+                                       \/
+                                ------------------
+                                | Impose Net-B   |  ==>  To
+                                | idiosyncracies |       Net-B
+                                ------------------
+
+
+
+
+
+
+
+
+
+
+
+     August 13, 1982              - 16 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+     4.  MESSAGE SPECIFICATION
+
+     4.1.  SYNTAX
+
+     Note:  Due to an artifact of the notational conventions, the syn-
+            tax  indicates that, when present, some fields, must be in
+            a particular order.  Header fields  are  NOT  required  to
+            occur  in  any  particular  order, except that the message
+            body must occur AFTER  the  headers.   It  is  recommended
+            that,  if  present,  headers be sent in the order "Return-
+            Path", "Received", "Date",  "From",  "Subject",  "Sender",
+            "To", "cc", etc.
+
+            This specification permits multiple  occurrences  of  most
+            fields.   Except  as  noted,  their  interpretation is not
+            specified here, and their use is discouraged.
+
+          The following syntax for the bodies of various fields should
+     be  thought  of  as  describing  each field body as a single long
+     string (or line).  The "Lexical Analysis of Message"  section  on
+     "Long  Header Fields", above, indicates how such long strings can
+     be represented on more than one line in  the  actual  transmitted
+     message.
+
+     message     =  fields *( CRLF *text )       ; Everything after
+                                                 ;  first null line
+                                                 ;  is message body
+
+     fields      =    dates                      ; Creation time,
+                      source                     ;  author id & one
+                    1*destination                ;  address required
+                     *optional-field             ;  others optional
+
+     source      = [  trace ]                    ; net traversals
+                      originator                 ; original mail
+                   [  resent ]                   ; forwarded
+
+     trace       =    return                     ; path to sender
+                    1*received                   ; receipt tags
+
+     return      =  "Return-path" ":" route-addr ; return address
+
+     received    =  "Received"    ":"            ; one per relay
+                       ["from" domain]           ; sending host
+                       ["by"   domain]           ; receiving host
+                       ["via"  atom]             ; physical path
+                      *("with" atom)             ; link/mail protocol
+                       ["id"   msg-id]           ; receiver msg id
+                       ["for"  addr-spec]        ; initial form
+
+
+     August 13, 1982              - 17 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+                        ";"    date-time         ; time received
+
+     originator  =   authentic                   ; authenticated addr
+                   [ "Reply-To"   ":" 1#address] )
+
+     authentic   =   "From"       ":"   mailbox  ; Single author
+                 / ( "Sender"     ":"   mailbox  ; Actual submittor
+                     "From"       ":" 1#mailbox) ; Multiple authors
+                                                 ;  or not sender
+
+     resent      =   resent-authentic
+                   [ "Resent-Reply-To"  ":" 1#address] )
+
+     resent-authentic =
+                 =   "Resent-From"      ":"   mailbox
+                 / ( "Resent-Sender"    ":"   mailbox
+                     "Resent-From"      ":" 1#mailbox  )
+
+     dates       =   orig-date                   ; Original
+                   [ resent-date ]               ; Forwarded
+
+     orig-date   =  "Date"        ":"   date-time
+
+     resent-date =  "Resent-Date" ":"   date-time
+
+     destination =  "To"          ":" 1#address  ; Primary
+                 /  "Resent-To"   ":" 1#address
+                 /  "cc"          ":" 1#address  ; Secondary
+                 /  "Resent-cc"   ":" 1#address
+                 /  "bcc"         ":"  #address  ; Blind carbon
+                 /  "Resent-bcc"  ":"  #address
+
+     optional-field =
+                 /  "Message-ID"        ":"   msg-id
+                 /  "Resent-Message-ID" ":"   msg-id
+                 /  "In-Reply-To"       ":"  *(phrase / msg-id)
+                 /  "References"        ":"  *(phrase / msg-id)
+                 /  "Keywords"          ":"  #phrase
+                 /  "Subject"           ":"  *text
+                 /  "Comments"          ":"  *text
+                 /  "Encrypted"         ":" 1#2word
+                 /  extension-field              ; To be defined
+                 /  user-defined-field           ; May be pre-empted
+
+     msg-id      =  "<" addr-spec ">"            ; Unique message id
+
+
+
+
+
+
+     August 13, 1982              - 18 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+     extension-field =
+                   <Any field which is defined in a document
+                    published as a formal extension to this
+                    specification; none will have names beginning
+                    with the string "X-">
+
+     user-defined-field =
+                   <Any field which has not been defined
+                    in this specification or published as an
+                    extension to this specification; names for
+                    such fields must be unique and may be
+                    pre-empted by published extensions>
+
+     4.2.  FORWARDING
+
+          Some systems permit mail recipients to  forward  a  message,
+     retaining  the original headers, by adding some new fields.  This
+     standard supports such a service, through the "Resent-" prefix to
+     field names.
+
+          Whenever the string "Resent-" begins a field name, the field
+     has  the  same  semantics as a field whose name does not have the
+     prefix.  However, the message is assumed to have  been  forwarded
+     by  an original recipient who attached the "Resent-" field.  This
+     new field is treated as being more recent  than  the  equivalent,
+     original  field.   For  example, the "Resent-From", indicates the
+     person that forwarded the message, whereas the "From" field indi-
+     cates the original author.
+
+          Use of such precedence  information  depends  upon  partici-
+     pants'  communication needs.  For example, this standard does not
+     dictate when a "Resent-From:" address should receive replies,  in
+     lieu of sending them to the "From:" address.
+
+     Note:  In general, the "Resent-" fields should be treated as con-
+            taining  a  set  of information that is independent of the
+            set of original fields.  Information for  one  set  should
+            not  automatically be taken from the other.  The interpre-
+            tation of multiple "Resent-" fields, of the same type,  is
+            undefined.
+
+          In the remainder of this specification, occurrence of  legal
+     "Resent-"  fields  are treated identically with the occurrence of
+
+
+
+
+
+
+
+
+     August 13, 1982              - 19 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+     fields whose names do not contain this prefix.
+
+     4.3.  TRACE FIELDS
+
+          Trace information is used to provide an audit trail of  mes-
+     sage  handling.   In  addition,  it indicates a route back to the
+     sender of the message.
+
+          The list of known "via" and  "with"  values  are  registered
+     with  the  Network  Information  Center, SRI International, Menlo
+     Park, California.
+
+     4.3.1.  RETURN-PATH
+
+        This field  is  added  by  the  final  transport  system  that
+        delivers  the message to its recipient.  The field is intended
+        to contain definitive information about the address and  route
+        back to the message's originator.
+
+        Note:  The "Reply-To" field is added  by  the  originator  and
+               serves  to  direct  replies,  whereas the "Return-Path"
+               field is used to identify a path back to  the  origina-
+               tor.
+
+        While the syntax  indicates  that  a  route  specification  is
+        optional,  every attempt should be made to provide that infor-
+        mation in this field.
+
+     4.3.2.  RECEIVED
+
+        A copy of this field is added by each transport  service  that
+        relays the message.  The information in the field can be quite
+        useful for tracing transport problems.
+
+        The names of the sending  and  receiving  hosts  and  time-of-
+        receipt may be specified.  The "via" parameter may be used, to
+        indicate what physical mechanism the message  was  sent  over,
+        such  as  Arpanet or Phonenet, and the "with" parameter may be
+        used to indicate the mail-,  or  connection-,  level  protocol
+        that  was  used, such as the SMTP mail protocol, or X.25 tran-
+        sport protocol.
+
+        Note:  Several "with" parameters may  be  included,  to  fully
+               specify the set of protocols that were used.
+
+        Some transport services queue mail; the internal message iden-
+        tifier that is assigned to the message may be noted, using the
+        "id" parameter.  When the  sending  host  uses  a  destination
+        address specification that the receiving host reinterprets, by
+
+
+     August 13, 1982              - 20 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+        expansion or transformation, the receiving host  may  wish  to
+        record  the original specification, using the "for" parameter.
+        For example, when a copy of mail is sent to the  member  of  a
+        distribution  list,  this  parameter may be used to record the
+        original address that was used to specify the list.
+
+     4.4.  ORIGINATOR FIELDS
+
+          The standard allows only a subset of the combinations possi-
+     ble  with the From, Sender, Reply-To, Resent-From, Resent-Sender,
+     and Resent-Reply-To fields.  The limitation is intentional.
+
+     4.4.1.  FROM / RESENT-FROM
+
+        This field contains the identity of the person(s)  who  wished
+        this  message to be sent.  The message-creation process should
+        default this field  to  be  a  single,  authenticated  machine
+        address,  indicating  the  AGENT  (person,  system or process)
+        entering the message.  If this is not done, the "Sender" field
+        MUST  be  present.  If the "From" field IS defaulted this way,
+        the "Sender" field is  optional  and  is  redundant  with  the
+        "From"  field.   In  all  cases, addresses in the "From" field
+        must be machine-usable (addr-specs) and may not contain  named
+        lists (groups).
+
+     4.4.2.  SENDER / RESENT-SENDER
+
+        This field contains the authenticated identity  of  the  AGENT
+        (person,  system  or  process)  that sends the message.  It is
+        intended for use when the sender is not the author of the mes-
+        sage,  or  to  indicate  who among a group of authors actually
+        sent the message.  If the contents of the "Sender" field would
+        be  completely  redundant  with  the  "From"  field,  then the
+        "Sender" field need not be present and its use is  discouraged
+        (though  still legal).  In particular, the "Sender" field MUST
+        be present if it is NOT the same as the "From" Field.
+
+        The Sender mailbox  specification  includes  a  word  sequence
+        which  must correspond to a specific agent (i.e., a human user
+        or a computer program) rather than a standard  address.   This
+        indicates  the  expectation  that  the field will identify the
+        single AGENT (person,  system,  or  process)  responsible  for
+        sending  the mail and not simply include the name of a mailbox
+        from which the mail was sent.  For example in the  case  of  a
+        shared login name, the name, by itself, would not be adequate.
+        The local-part address unit, which refers to  this  agent,  is
+        expected to be a computer system term, and not (for example) a
+        generalized person reference which can  be  used  outside  the
+        network text message context.
+
+
+     August 13, 1982              - 21 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+        Since the critical function served by the  "Sender"  field  is
+        identification  of  the agent responsible for sending mail and
+        since computer programs cannot be held accountable  for  their
+        behavior, it is strongly recommended that when a computer pro-
+        gram generates a message, the HUMAN  who  is  responsible  for
+        that program be referenced as part of the "Sender" field mail-
+        box specification.
+
+     4.4.3.  REPLY-TO / RESENT-REPLY-TO
+
+        This field provides a general  mechanism  for  indicating  any
+        mailbox(es)  to which responses are to be sent.  Three typical
+        uses for this feature can  be  distinguished.   In  the  first
+        case,  the  author(s) may not have regular machine-based mail-
+        boxes and therefore wish(es) to indicate an alternate  machine
+        address.   In  the  second case, an author may wish additional
+        persons to be made aware of, or responsible for,  replies.   A
+        somewhat  different  use  may be of some help to "text message
+        teleconferencing" groups equipped with automatic  distribution
+        services:   include the address of that service in the "Reply-
+        To" field of all messages  submitted  to  the  teleconference;
+        then  participants  can  "reply"  to conference submissions to
+        guarantee the correct distribution of any submission of  their
+        own.
+
+        Note:  The "Return-Path" field is added by the mail  transport
+               service,  at the time of final deliver.  It is intended
+               to identify a path back to the orginator  of  the  mes-
+               sage.   The  "Reply-To"  field  is added by the message
+               originator and is intended to direct replies.
+
+     4.4.4.  AUTOMATIC USE OF FROM / SENDER / REPLY-TO
+
+        For systems which automatically  generate  address  lists  for
+        replies to messages, the following recommendations are made:
+
+            o   The "Sender" field mailbox should be sent  notices  of
+                any  problems in transport or delivery of the original
+                messages.  If there is no  "Sender"  field,  then  the
+                "From" field mailbox should be used.
+
+            o   The  "Sender"  field  mailbox  should  NEVER  be  used
+                automatically, in a recipient's reply message.
+
+            o   If the "Reply-To" field exists, then the reply  should
+                go to the addresses indicated in that field and not to
+                the address(es) indicated in the "From" field.
+
+
+
+
+     August 13, 1982              - 22 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+            o   If there is a "From" field, but no  "Reply-To"  field,
+                the  reply should be sent to the address(es) indicated
+                in the "From" field.
+
+        Sometimes, a recipient may actually wish to  communicate  with
+        the  person  that  initiated  the  message  transfer.  In such
+        cases, it is reasonable to use the "Sender" address.
+
+        This recommendation is intended  only  for  automated  use  of
+        originator-fields  and is not intended to suggest that replies
+        may not also be sent to other recipients of messages.   It  is
+        up  to  the  respective  mail-handling programs to decide what
+        additional facilities will be provided.
+
+        Examples are provided in Appendix A.
+
+     4.5.  RECEIVER FIELDS
+
+     4.5.1.  TO / RESENT-TO
+
+        This field contains the identity of the primary recipients  of
+        the message.
+
+     4.5.2.  CC / RESENT-CC
+
+        This field contains the identity of  the  secondary  (informa-
+        tional) recipients of the message.
+
+     4.5.3.  BCC / RESENT-BCC
+
+        This field contains the identity of additional  recipients  of
+        the  message.   The contents of this field are not included in
+        copies of the message sent to the primary and secondary  reci-
+        pients.   Some  systems  may choose to include the text of the
+        "Bcc" field only in the author(s)'s  copy,  while  others  may
+        also include it in the text sent to all those indicated in the
+        "Bcc" list.
+
+     4.6.  REFERENCE FIELDS
+
+     4.6.1.  MESSAGE-ID / RESENT-MESSAGE-ID
+
+             This field contains a unique identifier  (the  local-part
+        address  unit)  which  refers to THIS version of THIS message.
+        The uniqueness of the message identifier is guaranteed by  the
+        host  which  generates  it.  This identifier is intended to be
+        machine readable and not necessarily meaningful to humans.   A
+        message  identifier pertains to exactly one instantiation of a
+        particular message; subsequent revisions to the message should
+
+
+     August 13, 1982              - 23 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+        each receive new message identifiers.
+
+     4.6.2.  IN-REPLY-TO
+
+             The contents of this field identify  previous  correspon-
+        dence  which this message answers.  Note that if message iden-
+        tifiers are used in this  field,  they  must  use  the  msg-id
+        specification format.
+
+     4.6.3.  REFERENCES
+
+             The contents of this field identify other  correspondence
+        which  this message references.  Note that if message identif-
+        iers are used, they must use the msg-id specification format.
+
+     4.6.4.  KEYWORDS
+
+             This field contains keywords  or  phrases,  separated  by
+        commas.
+
+     4.7.  OTHER FIELDS
+
+     4.7.1.  SUBJECT
+
+             This is intended to provide a summary,  or  indicate  the
+        nature, of the message.
+
+     4.7.2.  COMMENTS
+
+             Permits adding text comments  onto  the  message  without
+        disturbing the contents of the message's body.
+
+     4.7.3.  ENCRYPTED
+
+             Sometimes,  data  encryption  is  used  to  increase  the
+        privacy  of  message  contents.   If the body of a message has
+        been encrypted, to keep its contents private, the  "Encrypted"
+        field  can be used to note the fact and to indicate the nature
+        of the encryption.  The first <word> parameter  indicates  the
+        software  used  to  encrypt the body, and the second, optional
+        <word> is intended to  aid  the  recipient  in  selecting  the
+        proper  decryption  key.   This  code word may be viewed as an
+        index to a table of keys held by the recipient.
+
+        Note:  Unfortunately, headers must contain envelope,  as  well
+               as  contents,  information.  Consequently, it is neces-
+               sary that they remain unencrypted, so that  mail  tran-
+               sport   services   may   access   them.   Since  names,
+               addresses, and "Subject"  field  contents  may  contain
+
+
+     August 13, 1982              - 24 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+               sensitive  information,  this  requirement limits total
+               message privacy.
+
+             Names of encryption software are registered with the Net-
+        work  Information Center, SRI International, Menlo Park, Cali-
+        fornia.
+
+     4.7.4.  EXTENSION-FIELD
+
+             A limited number of common fields have  been  defined  in
+        this  document.   As  network mail requirements dictate, addi-
+        tional fields may be standardized.   To  provide  user-defined
+        fields  with  a  measure  of  safety,  in name selection, such
+        extension-fields will never have names  that  begin  with  the
+        string "X-".
+
+             Names of Extension-fields are registered with the Network
+        Information Center, SRI International, Menlo Park, California.
+
+     4.7.5.  USER-DEFINED-FIELD
+
+             Individual users of network mail are free to  define  and
+        use  additional  header  fields.   Such fields must have names
+        which are not already used in the current specification or  in
+        any definitions of extension-fields, and the overall syntax of
+        these user-defined-fields must conform to this specification's
+        rules   for   delimiting  and  folding  fields.   Due  to  the
+        extension-field  publishing  process,  the  name  of  a  user-
+        defined-field may be pre-empted
+
+        Note:  The prefatory string "X-" will never  be  used  in  the
+               names  of Extension-fields.  This provides user-defined
+               fields with a protected set of names.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+     August 13, 1982              - 25 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+     5.  DATE AND TIME SPECIFICATION
+
+     5.1.  SYNTAX
+
+     date-time   =  [ day "," ] date time        ; dd mm yy
+                                                 ;  hh:mm:ss zzz
+
+     day         =  "Mon"  / "Tue" /  "Wed"  / "Thu"
+                 /  "Fri"  / "Sat" /  "Sun"
+
+     date        =  1*2DIGIT month 2DIGIT        ; day month year
+                                                 ;  e.g. 20 Jun 82
+
+     month       =  "Jan"  /  "Feb" /  "Mar"  /  "Apr"
+                 /  "May"  /  "Jun" /  "Jul"  /  "Aug"
+                 /  "Sep"  /  "Oct" /  "Nov"  /  "Dec"
+
+     time        =  hour zone                    ; ANSI and Military
+
+     hour        =  2DIGIT ":" 2DIGIT [":" 2DIGIT]
+                                                 ; 00:00:00 - 23:59:59
+
+     zone        =  "UT"  / "GMT"                ; Universal Time
+                                                 ; North American : UT
+                 /  "EST" / "EDT"                ;  Eastern:  - 5/ - 4
+                 /  "CST" / "CDT"                ;  Central:  - 6/ - 5
+                 /  "MST" / "MDT"                ;  Mountain: - 7/ - 6
+                 /  "PST" / "PDT"                ;  Pacific:  - 8/ - 7
+                 /  1ALPHA                       ; Military: Z = UT;
+                                                 ;  A:-1; (J not used)
+                                                 ;  M:-12; N:+1; Y:+12
+                 / ( ("+" / "-") 4DIGIT )        ; Local differential
+                                                 ;  hours+min. (HHMM)
+
+     5.2.  SEMANTICS
+
+          If included, day-of-week must be the day implied by the date
+     specification.
+
+          Time zone may be indicated in several ways.  "UT" is Univer-
+     sal  Time  (formerly called "Greenwich Mean Time"); "GMT" is per-
+     mitted as a reference to Universal Time.  The  military  standard
+     uses  a  single  character for each zone.  "Z" is Universal Time.
+     "A" indicates one hour earlier, and "M" indicates 12  hours  ear-
+     lier;  "N"  is  one  hour  later, and "Y" is 12 hours later.  The
+     letter "J" is not used.  The other remaining two forms are  taken
+     from ANSI standard X3.51-1975.  One allows explicit indication of
+     the amount of offset from UT; the other uses  common  3-character
+     strings for indicating time zones in North America.
+
+
+     August 13, 1982              - 26 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+     6.  ADDRESS SPECIFICATION
+
+     6.1.  SYNTAX
+
+     address     =  mailbox                      ; one addressee
+                 /  group                        ; named list
+
+     group       =  phrase ":" [#mailbox] ";"
+
+     mailbox     =  addr-spec                    ; simple address
+                 /  phrase route-addr            ; name & addr-spec
+
+     route-addr  =  "<" [route] addr-spec ">"
+
+     route       =  1#("@" domain) ":"           ; path-relative
+
+     addr-spec   =  local-part "@" domain        ; global address
+
+     local-part  =  word *("." word)             ; uninterpreted
+                                                 ; case-preserved
+
+     domain      =  sub-domain *("." sub-domain)
+
+     sub-domain  =  domain-ref / domain-literal
+
+     domain-ref  =  atom                         ; symbolic reference
+
+     6.2.  SEMANTICS
+
+          A mailbox receives mail.  It is a  conceptual  entity  which
+     does  not necessarily pertain to file storage.  For example, some
+     sites may choose to print mail on their line printer and  deliver
+     the output to the addressee's desk.
+
+          A mailbox specification comprises a person, system  or  pro-
+     cess name reference, a domain-dependent string, and a name-domain
+     reference.  The name reference is optional and is usually used to
+     indicate  the  human name of a recipient.  The name-domain refer-
+     ence specifies a sequence of sub-domains.   The  domain-dependent
+     string is uninterpreted, except by the final sub-domain; the rest
+     of the mail service merely transmits it as a literal string.
+
+     6.2.1.  DOMAINS
+
+        A name-domain is a set of registered (mail)  names.   A  name-
+        domain  specification  resolves  to  a subordinate name-domain
+        specification  or  to  a  terminal  domain-dependent   string.
+        Hence,  domain  specification  is  extensible,  permitting any
+        number of registration levels.
+
+
+     August 13, 1982              - 27 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+        Name-domains model a global, logical, hierarchical  addressing
+        scheme.   The  model is logical, in that an address specifica-
+        tion is related to name registration and  is  not  necessarily
+        tied  to  transmission  path.   The  model's  hierarchy  is  a
+        directed graph, called an in-tree, such that there is a single
+        path  from  the root of the tree to any node in the hierarchy.
+        If more than one path actually exists, they are considered  to
+        be different addresses.
+
+        The root node is common to all addresses; consequently, it  is
+        not  referenced.   Its  children  constitute "top-level" name-
+        domains.  Usually, a service has access to its own full domain
+        specification and to the names of all top-level name-domains.
+
+        The "top" of the domain addressing hierarchy -- a child of the
+        root  --  is  indicated  by  the right-most field, in a domain
+        specification.  Its child is specified to the left, its  child
+        to the left, and so on.
+
+        Some groups provide formal registration services;  these  con-
+        stitute   name-domains   that  are  independent  logically  of
+        specific machines.  In addition, networks and machines  impli-
+        citly  compose name-domains, since their membership usually is
+        registered in name tables.
+
+        In the case of formal registration, an organization implements
+        a  (distributed)  data base which provides an address-to-route
+        mapping service for addresses of the form:
+
+                         person@registry.organization
+
+        Note that "organization" is a logical  entity,  separate  from
+        any particular communication network.
+
+        A mechanism for accessing "organization" is universally avail-
+        able.   That mechanism, in turn, seeks an instantiation of the
+        registry; its location is not indicated in the address specif-
+        ication.   It  is assumed that the system which operates under
+        the name "organization" knows how to find a subordinate regis-
+        try.  The registry will then use the "person" string to deter-
+        mine where to send the mail specification.
+
+        The latter,  network-oriented  case  permits  simple,  direct,
+        attachment-related address specification, such as:
+
+                              user@host.network
+
+        Once the network is accessed, it is expected  that  a  message
+        will  go  directly  to the host and that the host will resolve
+
+
+     August 13, 1982              - 28 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+        the user name, placing the message in the user's mailbox.
+
+     6.2.2.  ABBREVIATED DOMAIN SPECIFICATION
+
+        Since any number of  levels  is  possible  within  the  domain
+        hierarchy,  specification  of  a  fully  qualified address can
+        become inconvenient.  This standard permits abbreviated domain
+        specification, in a special case:
+
+            For the address of  the  sender,  call  the  left-most
+            sub-domain  Level  N.   In a header address, if all of
+            the sub-domains above (i.e., to the right of) Level  N
+            are  the same as those of the sender, then they do not
+            have to appear in the specification.   Otherwise,  the
+            address must be fully qualified.
+
+            This feature is subject  to  approval  by  local  sub-
+            domains.   Individual  sub-domains  may  require their
+            member systems, which originate mail, to provide  full
+            domain  specification only.  When permitted, abbrevia-
+            tions may be present  only  while  the  message  stays
+            within the sub-domain of the sender.
+
+            Use of this mechanism requires the sender's sub-domain
+            to reserve the names of all top-level domains, so that
+            full specifications can be distinguished from abbrevi-
+            ated specifications.
+
+        For example, if a sender's address is:
+
+                 sender@registry-A.registry-1.organization-X
+
+        and one recipient's address is:
+
+                recipient@registry-B.registry-1.organization-X
+
+        and another's is:
+
+                recipient@registry-C.registry-2.organization-X
+
+        then ".registry-1.organization-X" need not be specified in the
+        the  message,  but  "registry-C.registry-2"  DOES  have  to be
+        specified.  That is, the first two addresses may  be  abbrevi-
+        ated, but the third address must be fully specified.
+
+        When a message crosses a domain boundary, all  addresses  must
+        be  specified  in  the  full format, ending with the top-level
+        name-domain in the right-most field.  It is the responsibility
+        of  mail  forwarding services to ensure that addresses conform
+
+
+     August 13, 1982              - 29 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+        with this requirement.  In the case of abbreviated  addresses,
+        the  relaying  service must make the necessary expansions.  It
+        should be noted that it often is difficult for such a  service
+        to locate all occurrences of address abbreviations.  For exam-
+        ple, it will not be possible to find such abbreviations within
+        the  body  of  the  message.   The "Return-Path" field can aid
+        recipients in recovering from these errors.
+
+        Note:  When passing any portion of an addr-spec onto a process
+               which  does  not interpret data according to this stan-
+               dard (e.g., mail protocol servers).  There must  be  NO
+               LWSP-chars  preceding  or  following the at-sign or any
+               delimiting period ("."), such as  shown  in  the  above
+               examples,   and   only  ONE  SPACE  between  contiguous
+               <word>s.
+
+     6.2.3.  DOMAIN TERMS
+
+        A domain-ref must be THE official name of a registry, network,
+        or  host.   It  is  a  symbolic  reference, within a name sub-
+        domain.  At times, it is necessary to bypass standard  mechan-
+        isms  for  resolving  such  references,  using  more primitive
+        information, such as a network host address  rather  than  its
+        associated host name.
+
+        To permit such references, this standard provides the  domain-
+        literal  construct.   Its contents must conform with the needs
+        of the sub-domain in which it is interpreted.
+
+        Domain-literals which refer to domains within the ARPA  Inter-
+        net  specify  32-bit  Internet addresses, in four 8-bit fields
+        noted in decimal, as described in Request for  Comments  #820,
+        "Assigned Numbers."  For example:
+
+                                 [10.0.3.19]
+
+        Note:  THE USE OF DOMAIN-LITERALS IS STRONGLY DISCOURAGED.  It
+               is  permitted  only  as  a means of bypassing temporary
+               system limitations, such as name tables which  are  not
+               complete.
+
+        The names of "top-level" domains, and  the  names  of  domains
+        under  in  the  ARPA Internet, are registered with the Network
+        Information Center, SRI International, Menlo Park, California.
+
+     6.2.4.  DOMAIN-DEPENDENT LOCAL STRING
+
+        The local-part of an  addr-spec  in  a  mailbox  specification
+        (i.e.,  the  host's  name for the mailbox) is understood to be
+
+
+     August 13, 1982              - 30 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+        whatever the receiving mail protocol server allows.  For exam-
+        ple,  some systems do not understand mailbox references of the
+        form "P. D. Q. Bach", but others do.
+
+        This specification treats periods (".") as lexical separators.
+        Hence,  their  presence  in  local-parts which are not quoted-
+        strings, is detected.   However,  such  occurrences  carry  NO
+        semantics.  That is, if a local-part has periods within it, an
+        address parser will divide the local-part into several tokens,
+        but  the  sequence  of  tokens will be treated as one uninter-
+        preted unit.  The sequence  will  be  re-assembled,  when  the
+        address is passed outside of the system such as to a mail pro-
+        tocol service.
+
+        For example, the address:
+
+                           First.Last@Registry.Org
+
+        is legal and does not require the local-part to be  surrounded
+        with  quotation-marks.   (However,  "First  Last" DOES require
+        quoting.)  The local-part of the address, when passed  outside
+        of  the  mail  system,  within  the  Registry.Org  domain,  is
+        "First.Last", again without quotation marks.
+
+     6.2.5.  BALANCING LOCAL-PART AND DOMAIN
+
+        In some cases, the boundary between local-part and domain  can
+        be  flexible.  The local-part may be a simple string, which is
+        used for the final determination of the  recipient's  mailbox.
+        All  other  levels  of  reference  are, therefore, part of the
+        domain.
+
+        For some systems, in the case of abbreviated reference to  the
+        local  and  subordinate  sub-domains,  it  may  be possible to
+        specify only one reference within the domain  part  and  place
+        the  other,  subordinate  name-domain  references  within  the
+        local-part.  This would appear as:
+
+                        mailbox.sub1.sub2@this-domain
+
+        Such a specification would be acceptable  to  address  parsers
+        which  conform  to  RFC  #733,  but  do not support this newer
+        Internet standard.  While contrary to the intent of this stan-
+        dard, the form is legal.
+
+        Also, some sub-domains have a specification syntax which  does
+        not conform to this standard.  For example:
+
+                      sub-net.mailbox@sub-domain.domain
+
+
+     August 13, 1982              - 31 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+        uses a different parsing  sequence  for  local-part  than  for
+        domain.
+
+        Note:  As a rule,  the  domain  specification  should  contain
+               fields  which  are  encoded  according to the syntax of
+               this standard and which contain  generally-standardized
+               information.   The local-part specification should con-
+               tain only that portion of the  address  which  deviates
+               from the form or intention of the domain field.
+
+     6.2.6.  MULTIPLE MAILBOXES
+
+        An individual may have several mailboxes and wish  to  receive
+        mail  at  whatever  mailbox  is  convenient  for the sender to
+        access.  This standard does not provide a means of  specifying
+        "any member of" a list of mailboxes.
+
+        A set of individuals may wish to receive mail as a single unit
+        (i.e.,  a  distribution  list).  The <group> construct permits
+        specification of such a list.  Recipient mailboxes are  speci-
+        fied  within  the  bracketed  part (":" - ";").  A copy of the
+        transmitted message is to be  sent  to  each  mailbox  listed.
+        This  standard  does  not  permit  recursive  specification of
+        groups within groups.
+
+        While a list must be named, it is not required that  the  con-
+        tents  of  the  list be included.  In this case, the <address>
+        serves only as an indication of group distribution  and  would
+        appear in the form:
+
+                                    name:;
+
+        Some mail  services  may  provide  a  group-list  distribution
+        facility,  accepting  a single mailbox reference, expanding it
+        to the full distribution list, and relaying the  mail  to  the
+        list's  members.   This standard provides no additional syntax
+        for indicating such a  service.   Using  the  <group>  address
+        alternative,  while listing one mailbox in it, can mean either
+        that the mailbox reference will be expanded to a list or  that
+        there is a group with one member.
+
+     6.2.7.  EXPLICIT PATH SPECIFICATION
+
+        At times, a  message  originator  may  wish  to  indicate  the
+        transmission  path  that  a  message  should  follow.  This is
+        called source routing.  The normal addressing scheme, used  in
+        an  addr-spec,  is  carefully separated from such information;
+        the <route> portion of a route-addr is provided for such occa-
+        sions.  It specifies the sequence of hosts and/or transmission
+
+
+     August 13, 1982              - 32 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+        services that are  to  be  traversed.   Both  domain-refs  and
+        domain-literals may be used.
+
+        Note:  The use of source routing is discouraged.   Unless  the
+               sender has special need of path restriction, the choice
+               of transmission route should be left to the mail  tran-
+               sport service.
+
+     6.3.  RESERVED ADDRESS
+
+          It often is necessary to send mail to a site, without  know-
+     ing  any  of its valid addresses.  For example, there may be mail
+     system dysfunctions, or a user may wish to find  out  a  person's
+     correct address, at that site.
+
+          This standard specifies a single, reserved  mailbox  address
+     (local-part)  which  is  to  be valid at each site.  Mail sent to
+     that address is to be routed to  a  person  responsible  for  the
+     site's mail system or to a person with responsibility for general
+     site operation.  The name of the reserved local-part address is:
+
+                                Postmaster
+
+     so that "Postmaster@domain" is required to be valid.
+
+     Note:  This reserved local-part must be  matched  without  sensi-
+            tivity to alphabetic case, so that "POSTMASTER", "postmas-
+            ter", and even "poStmASteR" is to be accepted.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+     August 13, 1982              - 33 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+     7.  BIBLIOGRAPHY
+
+
+     ANSI.  "USA Standard Code  for  Information  Interchange,"  X3.4.
+        American  National Standards Institute: New York (1968).  Also
+        in:  Feinler, E.  and J. Postel, eds., "ARPANET Protocol Hand-
+        book", NIC 7104.
+
+     ANSI.  "Representations of Universal Time, Local  Time  Differen-
+        tials,  and United States Time Zone References for Information
+        Interchange," X3.51-1975.  American National Standards  Insti-
+        tute:  New York (1975).
+
+     Bemer, R.W., "Time and the Computer."  In:  Interface  Age  (Feb.
+        1979).
+
+     Bennett, C.J.  "JNT Mail Protocol".  Joint Network Team,  Ruther-
+        ford and Appleton Laboratory:  Didcot, England.
+
+     Bhushan, A.K., Pogran, K.T., Tomlinson,  R.S.,  and  White,  J.E.
+        "Standardizing  Network  Mail  Headers,"   ARPANET Request for
+        Comments No. 561, Network Information Center  No.  18516;  SRI
+        International:  Menlo Park (September 1973).
+
+     Birrell, A.D., Levin, R.,  Needham,  R.M.,  and  Schroeder,  M.D.
+        "Grapevine:  An Exercise in Distributed Computing," Communica-
+        tions of the ACM 25, 4 (April 1982), 260-274.
+
+     Crocker,  D.H.,  Vittal,  J.J.,  Pogran,  K.T.,  Henderson,  D.A.
+        "Standard  for  the  Format  of  ARPA  Network  Text Message,"
+        ARPANET Request for  Comments  No.  733,  Network  Information
+        Center  No.  41952.   SRI International:  Menlo Park (November
+        1977).
+
+     Feinler, E.J. and Postel, J.B.  ARPANET Protocol  Handbook,  Net-
+        work  Information  Center  No.  7104   (NTIS AD A003890).  SRI
+        International:  Menlo Park (April 1976).
+
+     Harary, F.   "Graph  Theory".   Addison-Wesley:   Reading,  Mass.
+        (1969).
+
+     Levin, R. and Schroeder, M.  "Transport  of  Electronic  Messages
+        through  a  Network,"   TeleInformatics  79, pp. 29-33.  North
+        Holland (1979).  Also  as  Xerox  Palo  Alto  Research  Center
+        Technical Report CSL-79-4.
+
+     Myer, T.H. and Henderson, D.A.  "Message Transmission  Protocol,"
+        ARPANET  Request  for  Comments,  No. 680, Network Information
+        Center No. 32116.  SRI International:  Menlo Park (1975).
+
+
+     August 13, 1982              - 34 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+     NBS.  "Specification of Message Format for Computer Based Message
+        Systems, Recommended Federal Information Processing Standard."
+        National  Bureau   of   Standards:    Gaithersburg,   Maryland
+        (October 1981).
+
+     NIC.  Internet Protocol Transition Workbook.  Network Information
+        Center,   SRI-International,  Menlo  Park,  California  (March
+        1982).
+
+     Oppen, D.C. and Dalal, Y.K.  "The Clearinghouse:  A Decentralized
+        Agent  for  Locating  Named  Objects in a Distributed Environ-
+        ment," OPD-T8103.  Xerox Office Products Division:  Palo Alto,
+        CA. (October 1981).
+
+     Postel, J.B.  "Assigned Numbers,"  ARPANET Request for  Comments,
+        No. 820.  SRI International:  Menlo Park (August 1982).
+
+     Postel, J.B.  "Simple Mail Transfer  Protocol,"  ARPANET  Request
+        for Comments, No. 821.  SRI International:  Menlo Park (August
+        1982).
+
+     Shoch, J.F.  "Internetwork naming, addressing  and  routing,"  in
+        Proc. 17th IEEE Computer Society International Conference, pp.
+        72-79, Sept. 1978, IEEE Cat. No. 78 CH 1388-8C.
+
+     Su, Z. and Postel, J.  "The Domain Naming Convention for Internet
+        User  Applications,"  ARPANET  Request  for Comments, No. 819.
+        SRI International:  Menlo Park (August 1982).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+     August 13, 1982              - 35 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+                                 APPENDIX
+
+
+     A.  EXAMPLES
+
+     A.1.  ADDRESSES
+
+     A.1.1.  Alfred Neuman <Neuman@BBN-TENEXA>
+
+     A.1.2.  Neuman@BBN-TENEXA
+
+             These two "Alfred Neuman" examples have identical  seman-
+        tics, as far as the operation of the local host's mail sending
+        (distribution) program (also sometimes  called  its  "mailer")
+        and  the remote host's mail protocol server are concerned.  In
+        the first example, the  "Alfred  Neuman"  is  ignored  by  the
+        mailer,  as "Neuman@BBN-TENEXA" completely specifies the reci-
+        pient.  The second example contains  no  superfluous  informa-
+        tion,  and,  again,  "Neuman@BBN-TENEXA" is the intended reci-
+        pient.
+
+        Note:  When the message crosses name-domain  boundaries,  then
+               these specifications must be changed, so as to indicate
+               the remainder of the hierarchy, starting with  the  top
+               level.
+
+     A.1.3.  "George, Ted" <Shared@Group.Arpanet>
+
+             This form might be used to indicate that a single mailbox
+        is  shared  by several users.  The quoted string is ignored by
+        the originating host's mailer, because  "Shared@Group.Arpanet"
+        completely specifies the destination mailbox.
+
+     A.1.4.  Wilt . (the  Stilt) Chamberlain@NBA.US
+
+             The "(the  Stilt)" is a comment, which is NOT included in
+        the  destination  mailbox  address  handed  to the originating
+        system's mailer.  The local-part of the address is the  string
+        "Wilt.Chamberlain", with NO space between the first and second
+        words.
+
+     A.1.5.  Address Lists
+
+     Gourmets:  Pompous Person <WhoZiWhatZit@Cordon-Bleu>,
+                Childs@WGBH.Boston, Galloping Gourmet@
+                ANT.Down-Under (Australian National Television),
+                Cheapie@Discount-Liquors;,
+       Cruisers:  Port@Portugal, Jones@SEA;,
+         Another@Somewhere.SomeOrg
+
+
+     August 13, 1982              - 36 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+        This group list example points out the use of comments and the
+        mixing of addresses and groups.
+
+     A.2.  ORIGINATOR ITEMS
+
+     A.2.1.  Author-sent
+
+             George Jones logs into his host  as  "Jones".   He  sends
+        mail himself.
+
+            From:  Jones@Group.Org
+
+        or
+
+            From:  George Jones <Jones@Group.Org>
+
+     A.2.2.  Secretary-sent
+
+             George Jones logs in as Jones on his  host.   His  secre-
+        tary,  who logs in as Secy sends mail for him.  Replies to the
+        mail should go to George.
+
+            From:    George Jones <Jones@Group>
+            Sender:  Secy@Other-Group
+
+     A.2.3.  Secretary-sent, for user of shared directory
+
+             George Jones' secretary sends mail  for  George.  Replies
+        should go to George.
+
+            From:     George Jones<Shared@Group.Org>
+            Sender:   Secy@Other-Group
+
+        Note that there need not be a space between  "Jones"  and  the
+        "<",  but  adding a space enhances readability (as is the case
+        in other examples.
+
+     A.2.4.  Committee activity, with one author
+
+             George is a member of a committee.  He wishes to have any
+        replies to his message go to all committee members.
+
+            From:     George Jones <Jones@Host.Net>
+            Sender:   Jones@Host
+            Reply-To: The Committee: Jones@Host.Net,
+                                     Smith@Other.Org,
+                                     Doe@Somewhere-Else;
+
+        Note  that  if  George  had  not  included  himself   in   the
+
+
+     August 13, 1982              - 37 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+        enumeration  of  The  Committee,  he  would not have gotten an
+        implicit reply; the presence of the  "Reply-to"  field  SUPER-
+        SEDES the sending of a reply to the person named in the "From"
+        field.
+
+     A.2.5.  Secretary acting as full agent of author
+
+             George Jones asks his secretary  (Secy@Host)  to  send  a
+        message for him in his capacity as Group.  He wants his secre-
+        tary to handle all replies.
+
+            From:     George Jones <Group@Host>
+            Sender:   Secy@Host
+            Reply-To: Secy@Host
+
+     A.2.6.  Agent for user without online mailbox
+
+             A friend  of  George's,  Sarah,  is  visiting.   George's
+        secretary  sends  some  mail to a friend of Sarah in computer-
+        land.  Replies should go to George, whose mailbox is Jones  at
+        Registry.
+
+            From:     Sarah Friendly <Secy@Registry>
+            Sender:   Secy-Name <Secy@Registry>
+            Reply-To: Jones@Registry.
+
+     A.2.7.  Agent for member of a committee
+
+             George's secretary sends out a message which was authored
+        jointly by all the members of a committee.  Note that the name
+        of the committee cannot be specified, since <group> names  are
+        not permitted in the From field.
+
+            From:   Jones@Host,
+                    Smith@Other-Host,
+                    Doe@Somewhere-Else
+            Sender: Secy@SHost
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+     August 13, 1982              - 38 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+     A.3.  COMPLETE HEADERS
+
+     A.3.1.  Minimum required
+
+     Date:     26 Aug 76 1429 EDT        Date:     26 Aug 76 1429 EDT
+     From:     Jones@Registry.Org   or   From:     Jones@Registry.Org
+     Bcc:                                To:       Smith@Registry.Org
+
+        Note that the "Bcc" field may be empty, while the  "To"  field
+        is required to have at least one address.
+
+     A.3.2.  Using some of the additional fields
+
+     Date:     26 Aug 76 1430 EDT
+     From:     George Jones<Group@Host>
+     Sender:   Secy@SHOST
+     To:       "Al Neuman"@Mad-Host,
+               Sam.Irving@Other-Host
+     Message-ID:  <some.string@SHOST>
+
+     A.3.3.  About as complex as you're going to get
+
+     Date     :  27 Aug 76 0932 PDT
+     From     :  Ken Davis <KDavis@This-Host.This-net>
+     Subject  :  Re: The Syntax in the RFC
+     Sender   :  KSecy@Other-Host
+     Reply-To :  Sam.Irving@Reg.Organization
+     To       :  George Jones <Group@Some-Reg.An-Org>,
+                 Al.Neuman@MAD.Publisher
+     cc       :  Important folk:
+                   Tom Softwood <Balsa@Tree.Root>,
+                   "Sam Irving"@Other-Host;,
+                 Standard Distribution:
+                   /main/davis/people/standard@Other-Host,
+                   "<Jones>standard.dist.3"@Tops-20-Host>;
+     Comment  :  Sam is away on business. He asked me to handle
+                 his mail for him.  He'll be able to provide  a
+                 more  accurate  explanation  when  he  returns
+                 next week.
+     In-Reply-To: <some.string@DBM.Group>, George's message
+     X-Special-action:  This is a sample of user-defined field-
+                 names.  There could also be a field-name
+                 "Special-action", but its name might later be
+                 preempted
+     Message-ID: <4231.629.XYzi-What@Other-Host>
+
+
+
+
+
+
+     August 13, 1982              - 39 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+     B.  SIMPLE FIELD PARSING
+
+          Some mail-reading software systems may wish to perform  only
+     minimal  processing,  ignoring  the internal syntax of structured
+     field-bodies and treating them the  same  as  unstructured-field-
+     bodies.  Such software will need only to distinguish:
+
+         o   Header fields from the message body,
+
+         o   Beginnings of fields from lines which continue fields,
+
+         o   Field-names from field-contents.
+
+          The abbreviated set of syntactic rules  which  follows  will
+     suffice  for  this  purpose.  It describes a limited view of mes-
+     sages and is a subset of the syntactic rules provided in the main
+     part of this specification.  One small exception is that the con-
+     tents of field-bodies consist only of text:
+
+     B.1.  SYNTAX
+
+
+     message         =   *field *(CRLF *text)
+
+     field           =    field-name ":" [field-body] CRLF
+
+     field-name      =  1*<any CHAR, excluding CTLs, SPACE, and ":">
+
+     field-body      =   *text [CRLF LWSP-char field-body]
+
+
+     B.2.  SEMANTICS
+
+          Headers occur before the message body and are terminated  by
+     a null line (i.e., two contiguous CRLFs).
+
+          A line which continues a header field begins with a SPACE or
+     HTAB  character,  while  a  line  beginning a field starts with a
+     printable character which is not a colon.
+
+          A field-name consists of one or  more  printable  characters
+     (excluding  colon,  space, and control-characters).  A field-name
+     MUST be contained on one line.  Upper and lower case are not dis-
+     tinguished when comparing field-names.
+
+
+
+
+
+
+
+     August 13, 1982              - 40 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+     C.  DIFFERENCES FROM RFC #733
+
+          The following summarizes the differences between this  stan-
+     dard  and the one specified in Arpanet Request for Comments #733,
+     "Standard for the Format of ARPA  Network  Text  Messages".   The
+     differences  are  listed  in the order of their occurrence in the
+     current specification.
+
+     C.1.  FIELD DEFINITIONS
+
+     C.1.1.  FIELD NAMES
+
+        These now must be a sequence of  printable  characters.   They
+        may not contain any LWSP-chars.
+
+     C.2.  LEXICAL TOKENS
+
+     C.2.1.  SPECIALS
+
+        The characters period ("."), left-square  bracket  ("["),  and
+        right-square  bracket ("]") have been added.  For presentation
+        purposes, and when passing a specification to  a  system  that
+        does  not conform to this standard, periods are to be contigu-
+        ous with their surrounding lexical tokens.   No  linear-white-
+        space  is  permitted  between them.  The presence of one LWSP-
+        char between other tokens is still directed.
+
+     C.2.2.  ATOM
+
+        Atoms may not contain SPACE.
+
+     C.2.3.  SPECIAL TEXT
+
+        ctext and qtext have had backslash ("\") added to the list  of
+        prohibited characters.
+
+     C.2.4.  DOMAINS
+
+        The lexical tokens  <domain-literal>  and  <dtext>  have  been
+        added.
+
+     C.3.  MESSAGE SPECIFICATION
+
+     C.3.1.  TRACE
+
+        The "Return-path:" and "Received:" fields have been specified.
+
+
+
+
+
+     August 13, 1982              - 41 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+     C.3.2.  FROM
+
+        The "From" field must contain machine-usable addresses  (addr-
+        spec).   Multiple  addresses may be specified, but named-lists
+        (groups) may not.
+
+     C.3.3.  RESENT
+
+        The meta-construct of prefacing field names  with  the  string
+        "Resent-"  has been added, to indicate that a message has been
+        forwarded by an intermediate recipient.
+
+     C.3.4.  DESTINATION
+
+        A message must contain at least one destination address field.
+        "To" and "CC" are required to contain at least one address.
+
+     C.3.5.  IN-REPLY-TO
+
+        The field-body is no longer a comma-separated list, although a
+        sequence is still permitted.
+
+     C.3.6.  REFERENCE
+
+        The field-body is no longer a comma-separated list, although a
+        sequence is still permitted.
+
+     C.3.7.  ENCRYPTED
+
+        A field has been specified that permits  senders  to  indicate
+        that the body of a message has been encrypted.
+
+     C.3.8.  EXTENSION-FIELD
+
+        Extension fields are prohibited from beginning with the  char-
+        acters "X-".
+
+     C.4.  DATE AND TIME SPECIFICATION
+
+     C.4.1.  SIMPLIFICATION
+
+        Fewer optional forms are permitted  and  the  list  of  three-
+        letter time zones has been shortened.
+
+     C.5.  ADDRESS SPECIFICATION
+
+
+
+
+
+
+     August 13, 1982              - 42 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+     C.5.1.  ADDRESS
+
+        The use of quoted-string, and the ":"-atom-":" construct, have
+        been  removed.   An  address  now  is  either a single mailbox
+        reference or is a named list of addresses.  The  latter  indi-
+        cates a group distribution.
+
+     C.5.2.  GROUPS
+
+        Group lists are now required to to have a name.   Group  lists
+        may not be nested.
+
+     C.5.3.  MAILBOX
+
+        A mailbox specification  may  indicate  a  person's  name,  as
+        before.   Such  a  named  list  no longer may specify multiple
+        mailboxes and may not be nested.
+
+     C.5.4.  ROUTE ADDRESSING
+
+        Addresses now are taken to be absolute, global specifications,
+        independent  of transmission paths.  The <route> construct has
+        been provided, to permit explicit specification  of  transmis-
+        sion  path.   RFC  #733's  use  of multiple at-signs ("@") was
+        intended as a general syntax  for  indicating  routing  and/or
+        hierarchical addressing.  The current standard separates these
+        specifications and only one at-sign is permitted.
+
+     C.5.5.  AT-SIGN
+
+        The string " at " no longer is used as an  address  delimiter.
+        Only at-sign ("@") serves the function.
+
+     C.5.6.  DOMAINS
+
+        Hierarchical, logical name-domains have been added.
+
+     C.6.  RESERVED ADDRESS
+
+     The local-part "Postmaster" has been reserved, so that users  can
+     be guaranteed at least one valid address at a site.
+
+
+
+
+
+
+
+
+
+
+     August 13, 1982              - 43 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+     D.  ALPHABETICAL LISTING OF SYNTAX RULES
+
+     address     =  mailbox                      ; one addressee
+                 /  group                        ; named list
+     addr-spec   =  local-part "@" domain        ; global address
+     ALPHA       =  <any ASCII alphabetic character>
+                                                 ; (101-132, 65.- 90.)
+                                                 ; (141-172, 97.-122.)
+     atom        =  1*<any CHAR except specials, SPACE and CTLs>
+     authentic   =   "From"       ":"   mailbox  ; Single author
+                 / ( "Sender"     ":"   mailbox  ; Actual submittor
+                     "From"       ":" 1#mailbox) ; Multiple authors
+                                                 ;  or not sender
+     CHAR        =  <any ASCII character>        ; (  0-177,  0.-127.)
+     comment     =  "(" *(ctext / quoted-pair / comment) ")"
+     CR          =  <ASCII CR, carriage return>  ; (     15,      13.)
+     CRLF        =  CR LF
+     ctext       =  <any CHAR excluding "(",     ; => may be folded
+                     ")", "\" & CR, & including
+                     linear-white-space>
+     CTL         =  <any ASCII control           ; (  0- 37,  0.- 31.)
+                     character and DEL>          ; (    177,     127.)
+     date        =  1*2DIGIT month 2DIGIT        ; day month year
+                                                 ;  e.g. 20 Jun 82
+     dates       =   orig-date                   ; Original
+                   [ resent-date ]               ; Forwarded
+     date-time   =  [ day "," ] date time        ; dd mm yy
+                                                 ;  hh:mm:ss zzz
+     day         =  "Mon"  / "Tue" /  "Wed"  / "Thu"
+                 /  "Fri"  / "Sat" /  "Sun"
+     delimiters  =  specials / linear-white-space / comment
+     destination =  "To"          ":" 1#address  ; Primary
+                 /  "Resent-To"   ":" 1#address
+                 /  "cc"          ":" 1#address  ; Secondary
+                 /  "Resent-cc"   ":" 1#address
+                 /  "bcc"         ":"  #address  ; Blind carbon
+                 /  "Resent-bcc"  ":"  #address
+     DIGIT       =  <any ASCII decimal digit>    ; ( 60- 71, 48.- 57.)
+     domain      =  sub-domain *("." sub-domain)
+     domain-literal =  "[" *(dtext / quoted-pair) "]"
+     domain-ref  =  atom                         ; symbolic reference
+     dtext       =  <any CHAR excluding "[",     ; => may be folded
+                     "]", "\" & CR, & including
+                     linear-white-space>
+     extension-field =
+                   <Any field which is defined in a document
+                    published as a formal extension to this
+                    specification; none will have names beginning
+                    with the string "X-">
+
+
+     August 13, 1982              - 44 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+     field       =  field-name ":" [ field-body ] CRLF
+     fields      =    dates                      ; Creation time,
+                      source                     ;  author id & one
+                    1*destination                ;  address required
+                     *optional-field             ;  others optional
+     field-body  =  field-body-contents
+                    [CRLF LWSP-char field-body]
+     field-body-contents =
+                   <the ASCII characters making up the field-body, as
+                    defined in the following sections, and consisting
+                    of combinations of atom, quoted-string, and
+                    specials tokens, or else consisting of texts>
+     field-name  =  1*<any CHAR, excluding CTLs, SPACE, and ":">
+     group       =  phrase ":" [#mailbox] ";"
+     hour        =  2DIGIT ":" 2DIGIT [":" 2DIGIT]
+                                                 ; 00:00:00 - 23:59:59
+     HTAB        =  <ASCII HT, horizontal-tab>   ; (     11,       9.)
+     LF          =  <ASCII LF, linefeed>         ; (     12,      10.)
+     linear-white-space =  1*([CRLF] LWSP-char)  ; semantics = SPACE
+                                                 ; CRLF => folding
+     local-part  =  word *("." word)             ; uninterpreted
+                                                 ; case-preserved
+     LWSP-char   =  SPACE / HTAB                 ; semantics = SPACE
+     mailbox     =  addr-spec                    ; simple address
+                 /  phrase route-addr            ; name & addr-spec
+     message     =  fields *( CRLF *text )       ; Everything after
+                                                 ;  first null line
+                                                 ;  is message body
+     month       =  "Jan"  /  "Feb" /  "Mar"  /  "Apr"
+                 /  "May"  /  "Jun" /  "Jul"  /  "Aug"
+                 /  "Sep"  /  "Oct" /  "Nov"  /  "Dec"
+     msg-id      =  "<" addr-spec ">"            ; Unique message id
+     optional-field =
+                 /  "Message-ID"        ":"   msg-id
+                 /  "Resent-Message-ID" ":"   msg-id
+                 /  "In-Reply-To"       ":"  *(phrase / msg-id)
+                 /  "References"        ":"  *(phrase / msg-id)
+                 /  "Keywords"          ":"  #phrase
+                 /  "Subject"           ":"  *text
+                 /  "Comments"          ":"  *text
+                 /  "Encrypted"         ":" 1#2word
+                 /  extension-field              ; To be defined
+                 /  user-defined-field           ; May be pre-empted
+     orig-date   =  "Date"        ":"   date-time
+     originator  =   authentic                   ; authenticated addr
+                   [ "Reply-To"   ":" 1#address] )
+     phrase      =  1*word                       ; Sequence of words
+
+
+
+
+     August 13, 1982              - 45 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+     qtext       =  <any CHAR excepting <">,     ; => may be folded
+                     "\" & CR, and including
+                     linear-white-space>
+     quoted-pair =  "\" CHAR                     ; may quote any char
+     quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or
+                                                 ;   quoted chars.
+     received    =  "Received"    ":"            ; one per relay
+                       ["from" domain]           ; sending host
+                       ["by"   domain]           ; receiving host
+                       ["via"  atom]             ; physical path
+                      *("with" atom)             ; link/mail protocol
+                       ["id"   msg-id]           ; receiver msg id
+                       ["for"  addr-spec]        ; initial form
+                        ";"    date-time         ; time received
+
+     resent      =   resent-authentic
+                   [ "Resent-Reply-To"  ":" 1#address] )
+     resent-authentic =
+                 =   "Resent-From"      ":"   mailbox
+                 / ( "Resent-Sender"    ":"   mailbox
+                     "Resent-From"      ":" 1#mailbox  )
+     resent-date =  "Resent-Date" ":"   date-time
+     return      =  "Return-path" ":" route-addr ; return address
+     route       =  1#("@" domain) ":"           ; path-relative
+     route-addr  =  "<" [route] addr-spec ">"
+     source      = [  trace ]                    ; net traversals
+                      originator                 ; original mail
+                   [  resent ]                   ; forwarded
+     SPACE       =  <ASCII SP, space>            ; (     40,      32.)
+     specials    =  "(" / ")" / "<" / ">" / "@"  ; Must be in quoted-
+                 /  "," / ";" / ":" / "\" / <">  ;  string, to use
+                 /  "." / "[" / "]"              ;  within a word.
+     sub-domain  =  domain-ref / domain-literal
+     text        =  <any CHAR, including bare    ; => atoms, specials,
+                     CR & bare LF, but NOT       ;  comments and
+                     including CRLF>             ;  quoted-strings are
+                                                 ;  NOT recognized.
+     time        =  hour zone                    ; ANSI and Military
+     trace       =    return                     ; path to sender
+                    1*received                   ; receipt tags
+     user-defined-field =
+                   <Any field which has not been defined
+                    in this specification or published as an
+                    extension to this specification; names for
+                    such fields must be unique and may be
+                    pre-empted by published extensions>
+     word        =  atom / quoted-string
+
+
+
+
+     August 13, 1982              - 46 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+     zone        =  "UT"  / "GMT"                ; Universal Time
+                                                 ; North American : UT
+                 /  "EST" / "EDT"                ;  Eastern:  - 5/ - 4
+                 /  "CST" / "CDT"                ;  Central:  - 6/ - 5
+                 /  "MST" / "MDT"                ;  Mountain: - 7/ - 6
+                 /  "PST" / "PDT"                ;  Pacific:  - 8/ - 7
+                 /  1ALPHA                       ; Military: Z = UT;
+     <">         =  <ASCII quote mark>           ; (     42,      34.)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+     August 13, 1982              - 47 -                      RFC #822
+
diff --git a/doc/devel/rfc/rfc974.txt b/doc/devel/rfc/rfc974.txt
new file mode 100644
index 00000000..97d79a4f
--- /dev/null
+++ b/doc/devel/rfc/rfc974.txt
@@ -0,0 +1,399 @@
+
+
+Network Working Group                                    Craig Partridge
+Request for Comments: 974                 CSNET CIC BBN Laboratories Inc
+                                                            January 1986
+
+                   MAIL ROUTING AND THE DOMAIN SYSTEM
+
+
+Status of this Memo
+
+   This RFC presents a description of how mail systems on the Internet
+   are expected to route messages based on information from the domain
+   system described in RFCs 882, 883 and 973.  Distribution of this memo
+   is unlimited.
+
+Introduction
+
+   The purpose of this memo is to explain how mailers are to decide how
+   to route a message addressed to a given Internet domain name.  This
+   involves a discussion of how mailers interpret MX RRs, which are used
+   for message routing.  Note that this memo makes no statement about
+   how mailers are to deal with MB and MG RRs, which are used for
+   interpreting mailbox names.
+
+   Under RFC-882 and RFC-883 certain assumptions about mail addresses
+   have been changed.  Up to now, one could usually assume that if a
+   message was addressed to a mailbox, for example, at LOKI.BBN.COM,
+   that one could just open an SMTP connection to LOKI.BBN.COM and pass
+   the message along.  This system broke down in certain situations,
+   such as for certain UUCP and CSNET hosts which were not directly
+   attached to the Internet, but these hosts could be handled as special
+   cases in configuration files (for example, most mailers were set up
+   to automatically forward mail addressed to a CSNET host to
+   CSNET-RELAY.ARPA).
+
+   Under domains, one cannot simply open a connection to LOKI.BBN.COM,
+   but must instead ask the domain system where messages to LOKI.BBN.COM
+   are to be delivered. And the domain system may direct a mailer to
+   deliver messages to an entirely different host, such as SH.CS.NET.
+   Or, in a more complicated case, the mailer may learn that it has a
+   choice of routes to LOKI.BBN.COM.  This memo is essentially a set of
+   guidelines on how mailers should behave in this more complex world.
+
+   Readers are expected to be familiar with RFCs 882, 883, and the
+   updates to them (e.g., RFC-973).
+
+
+
+
+
+
+
+
+
+Partridge                                                       [Page 1]
+
+
+
+RFC 974                                                     January 1986
+Mail Routing and the Domain System
+
+
+What the Domain Servers Know
+
+   The domain servers store information as a series of resource records
+   (RRs), each of which contains a particular piece of information about
+   a given domain name (which is usually, but not always, a host).  The
+   simplest way to think of a RR is as a typed pair of datum, a domain
+   name matched with relevant data, and stored with some additional type
+   information to help systems determine when the RR is relevant.  For
+   the purposes of message routing, the system stores RRs known as MX
+   RRs. Each MX matches a domain name with two pieces of data, a
+   preference value (an unsigned 16-bit integer), and the name of a
+   host.  The preference number is used to indicate in what order the
+   mailer should attempt deliver to the MX hosts, with the lowest
+   numbered MX being the one to try first.  Multiple MXs with the same
+   preference are permitted and have the same priority.
+
+   In addition to mail information, the servers store certain other
+   types of RR's which mailers may encounter or choose to use.  These
+   are: the canonical name (CNAME) RR, which simply states that the
+   domain name queried for is actually an alias for another domain name,
+   which is the proper, or canonical, name; and the Well Known Service
+   (WKS) RR, which stores information about network services (such as
+   SMTP) a given domain name supports.
+
+General Routing Guidelines
+
+   Before delving into a detailed discussion of how mailers are expected
+   to do mail routing, it would seem to make sense to give a brief
+   overview of how this memo is approaching the problems that routing
+   poses.
+
+   The first major principle is derived from the definition of the
+   preference field in MX records, and is intended to prevent mail
+   looping.  If the mailer is on a host which is listed as an MX for the
+   destination host, the mailer may only deliver to an MX which has a
+   lower preference count than its own host.
+
+   It is also possible to cause mail looping because routing information
+   is out of date or incomplete.  Out of date information is only a
+   problem when domain tables are changed.  The changes will not be
+   known to all affected hosts until their resolver caches time out.
+   There is no way to ensure that this will not happen short of
+   requiring mailers and their resolvers to always send their queries to
+   an authoritative server, and never use data stored in a cache.  This
+   is an impractical solution, since eliminating resolver caching would
+   make mailing inordinately expensive.  What is more, the out-of-date
+   RR problem should not happen if, when a domain table is changed,
+
+
+Partridge                                                       [Page 2]
+
+
+
+RFC 974                                                     January 1986
+Mail Routing and the Domain System
+
+
+   affected hosts (those in the list of MXs) have their resolver caches
+   flushed. In other words, given proper precautions, mail looping as a
+   result of domain information should be avoidable, without requiring
+   mailers to query authoritative servers.  (The appropriate precaution
+   is to check with a host's administrator before adding that host to a
+   list of MXs).
+
+   The incomplete data problem also requires some care when handling
+   domain queries.  If the answer section of a query is incomplete
+   critical MX RRs may be left out.  This may result in mail looping, or
+   in a message being mistakenly labelled undeliverable.  As a result,
+   mailers may only accept responses from the domain system which have
+   complete answer sections.  Note that this entire problem can be
+   avoided by only using virtual circuits for queries, but since this
+   situation is likely to be very rare and datagrams are the preferred
+   way to interact with the domain system, implementors should probably
+   just ensure that their mailer will repeat a query with virtual
+   circuits should the truncation bit ever be set.
+
+Determining Where to Send a Message
+
+   The explanation of how mailers should decide how to route a message
+   is discussed in terms of the problem of a mailer on a host with
+   domain name LOCAL trying to deliver a message addressed to the domain
+   name REMOTE. Both LOCAL and REMOTE are assumed to be syntactically
+   correct domain names.  Furthermore, LOCAL is assumed to be the
+   official name for the host on which the mailer resides (i.e., it is
+   not a alias).
+
+Issuing a Query
+
+   The first step for the mailer at LOCAL is to issue a query for MX RRs
+   for REMOTE.  It is strongly urged that this step be taken every time
+   a mailer attempts to send the message.  The hope is that changes in
+   the domain database will rapidly be used by mailers, and thus domain
+   administrators will be able to re-route in-transit messages for
+   defective hosts by simply changing their domain databases.
+
+   Certain responses to the query are considered errors:
+
+      Getting no response to the query.  The domain server the mailer
+      queried never sends anything back.  (This is distinct from an
+      answer which contains no answers to the query, which is not an
+      error).
+
+      Getting a response in which the truncation field of the header is
+
+
+
+Partridge                                                       [Page 3]
+
+
+
+RFC 974                                                     January 1986
+Mail Routing and the Domain System
+
+
+      set.  (Recall discussion of incomplete queries above).  Mailers
+      may not use responses of this type, and should repeat the query
+      using virtual circuits instead of datagrams.
+
+      Getting a response in which the response code is non-zero.
+
+   Mailers are expected to do something reasonable in the face of an
+   error.  The behaviour for each type of error is not specified here,
+   but implementors should note that different types of errors should
+   probably be treated differently.  For example, a response code of
+   "non-existent domain" should probably cause the message to be
+   returned to the sender as invalid, while a response code of "server
+   failure" should probably cause the message to be retried later.
+
+   There is one other special case.  If the response contains an answer
+   which is a CNAME RR, it indicates that REMOTE is actually an alias
+   for some other domain name. The query should be repeated with the
+   canonical domain name.
+
+   If the response does not contain an error response, and does not
+   contain aliases, its answer section should be a (possibly zero
+   length) list of MX RRs for domain name REMOTE (or REMOTE's true
+   domain name if REMOTE was a alias).  The next section describes how
+   this list is interpreted.
+
+Interpreting the List of MX RRs
+
+   NOTE: This section only discusses how mailers choose which names to
+   try to deliver a message to, working from a list of RR's.  It does
+   not discuss how the mailers actually make delivery.  Where ever
+   delivering a message is mentioned, all that is meant is that the
+   mailer should do whatever it needs to do to transfer a message to a
+   remote site, given a domain name for that site.  (For example, an
+   SMTP mailer will try to get an address for the domain name, which
+   involves another query to the domain system, and then, if it gets an
+   address, connect to the SMTP TCP port).  The mechanics of actually
+   transferring the message over the network to the address associated
+   with a given domain name is not within the scope of this memo.
+
+   It is possible that the list of MXs in the response to the query will
+   be empty.  This is a special case.  If the list is empty, mailers
+   should treat it as if it contained one RR, an MX RR with a preference
+   value of 0, and a host name of REMOTE.  (I.e., REMOTE is its only
+   MX).  In addition, the mailer should do no further processing on the
+   list, but should attempt to deliver the message to REMOTE.  The idea
+
+
+
+
+Partridge                                                       [Page 4]
+
+
+
+RFC 974                                                     January 1986
+Mail Routing and the Domain System
+
+
+   here is that if a domain fails to advertise any information about a
+   particular name we will give it the benefit of the doubt and attempt
+   delivery.
+
+   If the list is not empty, the mailer should remove irrelevant RR's
+   from the list according to the following steps.  Note that the order
+   is significant.
+
+      For each MX, a WKS query should be issued to see if the domain
+      name listed actually supports the mail service desired.  MX RRs
+      which list domain names which do not support the service should be
+      discarded.  This step is optional, but strongly encouraged.
+
+      If the domain name LOCAL is listed as an MX RR, all MX RRs with a
+      preference value greater than or equal to that of LOCAL's must be
+      discarded.
+
+   After removing irrelevant RRs, the list can again be empty.  This is
+   now an error condition and can occur in several ways.  The simplest
+   case is that the WKS queries have discovered that none of the hosts
+   listed supports the mail service desired.  The message is thus deemed
+   undeliverable, though extremely persistent mail systems might want to
+   try a delivery to REMOTE's address (if it exists) before returning
+   the message. Another, more dangerous, possibility is that the domain
+   system believes that LOCAL is handling message for REMOTE, but the
+   mailer on LOCAL is not set up to handle mail for REMOTE.  For
+   example, if the domain system lists LOCAL as the only MX for REMOTE,
+   LOCAL will delete all the entries in the list.  But LOCAL is
+   presumably querying the domain system because it didn't know what to
+   do with a message addressed to REMOTE. Clearly something is wrong.
+   How a mailer chooses to handle these situations is to some extent
+   implementation dependent, and is thus left to the implementor's
+   discretion.
+
+   If the list of MX RRs is not empty, the mailer should try to deliver
+   the message to the MXs in order (lowest preference value tried
+   first).  The mailer is required to attempt delivery to the lowest
+   valued MX.  Implementors are encouraged to write mailers so that they
+   try the MXs in order until one of the MXs accepts the message, or all
+   the MXs have been tried.  A somewhat less demanding system, in which
+   a fixed number of MXs is tried, is also reasonable.  Note that
+   multiple MXs may have the same preference value.  In this case, all
+   MXs at with a given value must be tried before any of a higher value
+   are tried.  In addition, in the special case in which there are
+   several MXs with the lowest preference value,  all of them should be
+   tried before a message is deemed undeliverable.
+
+
+
+Partridge                                                       [Page 5]
+
+
+
+RFC 974                                                     January 1986
+Mail Routing and the Domain System
+
+
+Minor Special Issues
+
+   There are a couple of special issues left out of the preceding
+   section because they complicated the discussion.  They are treated
+   here in no particular order.
+
+   Wildcard names, those containing the character '*' in them, may be
+   used for mail routing.  There are likely to be servers on the network
+   which simply state that any mail to a domain is to be routed through
+   a relay. For example, at the time that this RFC is being written, all
+   mail to hosts in the domain IL is routed through RELAY.CS.NET.  This
+   is done by creating a wildcard RR, which states that *.IL has an MX
+   of RELAY.CS.NET.  This should be transparent to the mailer since the
+   domain servers will hide this wildcard match. (If it matches *.IL
+   with HUJI.IL for example, a domain server will return an RR
+   containing HUJI.IL, not *.IL). If by some accident a mailer receives
+   an RR with a wildcard domain name in its name or data section it
+   should discard the RR.
+
+   Note that the algorithm to delete irrelevant RRs breaks if LOCAL has
+   a alias and the alias is listed in the MX records for REMOTE.  (E.g.
+   REMOTE has an MX of ALIAS, where ALIAS has a CNAME of LOCAL).  This
+   can be avoided if aliases are never used in the data section of MX
+   RRs.
+
+   Implementors should understand that the query and interpretation of
+   the query is only performed for REMOTE.  It is not repeated for the
+   MX RRs listed for REMOTE.  You cannot try to support more extravagant
+   mail routing by building a chain of MXs.  (E.g. UNIX.BBN.COM is an MX
+   for RELAY.CS.NET and RELAY.CS.NET is an MX for all the hosts in .IL,
+   but this does not mean that UNIX.BBN.COM accepts any responsibility
+   for mail for .IL).
+
+   Finally, it should be noted that this is a standard for routing on
+   the Internet.  Mailers serving hosts which lie on multiple networks
+   will presumably have to make some decisions about which network to
+   route through. This decision making is outside the scope of this
+   memo, although mailers may well use the domain system to help them
+   decide.  However, once a mailer decides to deliver a message via the
+   Internet it must apply these rules to route the message.
+
+
+
+
+
+
+
+
+
+Partridge                                                       [Page 6]
+
+
+
+RFC 974                                                     January 1986
+Mail Routing and the Domain System
+
+
+Examples
+
+   To illustrate the discussion above, here are three examples of how
+   mailers should route messages.  All examples work with the following
+   database:
+
+      A.EXAMPLE.ORG    IN    MX    10    A.EXAMPLE.ORG
+      A.EXAMPLE.ORG    IN    MX    15    B.EXAMPLE.ORG
+      A.EXAMPLE.ORG    IN    MX    20    C.EXAMPLE.ORG
+      A.EXAMPLE.ORG    IN    WKS   10.0.0.1    TCP    SMTP
+
+      B.EXAMPLE.ORG    IN    MX    0      B.EXAMPLE.ORG
+      B.EXAMPLE.ORG    IN    MX    10     C.EXAMPLE.ORG
+      B.EXAMPLE.ORG    IN    WKS   10.0.0.2    TCP    SMTP
+
+      C.EXAMPLE.ORG    IN    MX    0     C.EXAMPLE.ORG
+      C.EXAMPLE.ORG    IN    WKS   10.0.0.3    TCP    SMTP
+
+      D.EXAMPLE.ORG    IN    MX    0     D.EXAMPLE.ORG
+      D.EXAMPLE.ORG    IN    MX    0     C.EXAMPLE.ORG
+      D.EXAMPLE.ORG    IN    WKS   10.0.0.4    TCP    SMTP
+
+   In the first example, an SMTP mailer on D.EXAMPLE.ORG is trying to
+   deliver a message addressed to A.EXAMPLE.ORG. From the answer to its
+   query, it learns that A.EXAMPLE.ORG has three MX RRs.  D.EXAMPLE.ORG
+   is not one of the MX RRs and all three MXs support SMTP mail
+   (determined from the WKS entries), so none of the MXs are eliminated.
+   The mailer is obliged to try to deliver to A.EXAMPLE.ORG as the
+   lowest valued MX.  If it cannot reach A.EXAMPLE.ORG it can (but is
+   not required to) try B.EXAMPLE.ORG. and if B.EXAMPLE.ORG is not
+   responding, it can try C.EXAMPLE.ORG.
+
+   In the second example, the mailer is on B.EXAMPLE.ORG, and is again
+   trying to deliver a message addressed to A.EXAMPLE.ORG.  There are
+   once again three MX RRs for A.EXAMPLE.ORG, but in this case the
+   mailer must discard the RRs for itself and C.EXAMPLE.ORG (because the
+   MX RR for C.EXAMPLE.ORG has a higher preference value than the RR for
+   B.EXAMPLE.ORG).  It is left only with the RR for A.EXAMPLE.ORG, and
+   can only try delivery to A.EXAMPLE.ORG.
+
+   In the third example, consider a mailer on A.EXAMPLE.ORG trying to
+   deliver a message to D.EXAMPLE.ORG.  In this case there are only two
+   MX RRs, both with the same preference value.  Either MX will accept
+   messages for D.EXAMPLE.ORG. The mailer should try one MX first (which
+   one is up to the mailer, though D.EXAMPLE.ORG seems most reasonable),
+   and if that delivery fails should try the other MX (e.g.
+   C.EXAMPLE.ORG).
+
+
+Partridge                                                       [Page 7]
+