38 files changed, 10 insertions, 53635 deletions
diff --git a/RFC/draft-klensin-cram-03.txt b/RFC/draft-klensin-cram-03.txt
deleted file mode 100644
index bfac1d5b..00000000
--- a/RFC/draft-klensin-cram-03.txt
+++ /dev/null
@@ -1,261 +0,0 @@
-
-Network Working Group                                        J Klensin
-Internet Draft                                                 R Catoe
-Document: draft-klensin-cram-03.txt                        P Krumviede  
-                                                                   MCI
-							September 1996
-
-
-
-
-       IMAP/POP AUTHorize Extension for Simple Challenge/Response
-
-Status of this Memo
-
-   This document is an Internet Draft.  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.  Internet Drafts may be updated, replaced, or obsoleted by
-   other documents at any time.  It is not appropriate to use Internet
-   Drafts as reference material or to cite them other than as a
-   ``working draft'' or ``work in progress``.
-
-   To learn the current status of any Internet-Draft, please check the
-   1id-abstracts.txt listing contained in the Internet-Drafts Shadow
-   Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or
-   munnari.oz.au.
-
-   A revised version of this draft document will be submitted to the
-   IESG for processing as a Proposed Standard for the Internet
-   Community, updating RFC 1731.  Discussion and suggestions for
-   improvement are requested. This document reflects editorial
-   comments received during the last call period; the protocol is
-   unchanged from the previous version.  This draft will expire
-   before February 22, 1997.  Distribution of this draft is
-   unlimited. 
-
-
-Abstract
-
-  While IMAP4 supports a number of strong authentication mechanisms
-  as described in RFC 1731, it lacks any mechanism that neither passes
-  cleartext, reusable passwords across the network nor requires either a
-  significant security infrastructure or that the mail server update a
-  mail-system-wide user authentication file on each mail access.  This
-  specification provides a simple challenge-response authentication
-  protocol that is suitable for use with IMAP4.  Since it utilizes
-  Keyed-MD5 digests and does not require that the secret be stored in the
-  clear on the server, it may also constitute an improvement on APOP for
-  POP3 use as specified in RFC 1734.
-
-1. Introduction
-
-   Existing Proposed Standards specify an AUTHENTICATE mechanism for
-   the IMAP4 protocol [IMAP, IMAP-AUTH] and a parallel AUTH mechanism for 
-   the POP3 protocol [POP3-AUTH].  The AUTHENTICATE mechanism is intended
-   to be extensible; the four methods specified in [IMAP-AUTH] are all
-   fairly powerful and require some security infrastructure to support.
-   The base POP3 specification [POP3] also contains a lightweight
-   challenge-response mechanism called APOP.  APOP is associated with
-   most of the risks associated with such protocols: in particular, it
-   requires that both the client and server machines have access to the
-   shared secret in cleartext form. CRAM offers a method for avoiding
-   such cleartext storage while retaining the algorithmic simplicity
-   of APOP in using only MD5, though in a "keyed" method.
-
-   At present, IMAP [IMAP] lacks any facility corresponding to APOP.
-   The only alternative to the strong mechanisms identified in
-   [IMAP-AUTH] is a presumably cleartext username and password,
-   supported through the LOGIN command in [IMAP].  This document
-   describes a simple challenge-response mechanism, similar to APOP and
-   PPP CHAP [PPP], that can be used with IMAP (and, in principle, with
-   POP3).
-
-   This mechanism also has the advantage over some possible
-   alternatives of not requiring that the server maintain information
-   about email "logins" on a per-login basis.  While mechanisms that
-   do require such per-login history records may offer enhanced
-   security, protocols such as IMAP, which may have several
-   connections between a given client and server open more or less
-   simultaneous, may make their implementation particularly
-   challenging. 
-
-
-2. Challenge-Response Authentication Mechanism (CRAM)
-
-   The authentication type associated with CRAM is "CRAM-MD5".
-
-   The data encoded in the first ready response contains an
-   presumptively arbitrary string of random digits, a timestamp,
-   and the fully-qualified primary host name of the server.  The
-   syntax of the unencoded form must correspond to that of an
-   RFC 822 'msg-id' [RFC822] as described in [POP3].
-
-   The client makes note of the data and then responds with a string
-   consisting of the user name, a space, and a 'digest'.  The latter is
-   computed by applying the keyed MD5 algorithm from [KEYED-MD5]
-   where the key is a shared secret and the digested text is
-   the timestamp (including angle-brackets). 
-
-   This shared secret is a string known only to the client and server.
-   The `digest' parameter itself is a 16-octet value which is
-   sent in hexadecimal format, using lower-case ASCII characters. 
-
-   When the server receives this client response, it verifies the digest
-   provided.  If the digest is correct, the server should consider the
-   client authenticated and respond appropriately.
-
-   Keyed MD5 is chosen for this application because of the greater
-   security imparted to authentication of short messages. In addition,
-   the use of the techniques described in [KEYED-MD5] for
-   precomputation of intermediate results make it possible to avoid 
-   explicit cleartext storage of the shared secret on the server system
-   by instead storing the intermediate results which are known as
-   "contexts". 
- 
-   CRAM does not support a protection mechanism.
-
-
-   Example:
-
-   The examples in this document show the use of the CRAM mechanism with
-   the IMAP4 AUTHENTICATE command [IMAP-AUTH].  The base64 encoding of
-   the challenges and responses is part of the IMAP4 AUTHENTICATE
-   command, not part of the CRAM specification itself.
-
-     S: * OK IMAP4 Server
-     C: A0001 AUTHENTICATE CRAM-MD5
-     S: + PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+
-     C: dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw
-     S: A0001 OK CRAM authentication successful
-
-     In this example, the shared secret is the string 'tanstaaftanstaaf'.
-     Hence, the Keyed MD5 digest is produced by calculating
-
-        MD5((tanstaaftanstaaf XOR opad),
-            MD5((tanstaaftanstaaf XOR ipad),
-            <1896.697170952@postoffice.reston.mci.net>))
-
-     where ipad and opad are as defined in the keyed-MD5 draft
-     [KEYED-MD5] and the string shown in the challenge is the base64
-     encoding of <1896.697170952@postoffice.reston.mci.net>. The
-     shared secret is null-padded to a length of 64 bytes. If the
-     shared secret is longer than 64 bytes, the MD5 digest of the
-     shared secret is used as a 16 byte input to the keyed MD5
-     calculation.
-
-     This produces a digest value (in hexadecimal) of
-
-
-	   b913a602c7eda7a495b4e6e7334d3890
-
-     The user name is then prepended to it, forming
-
-           tim b913a602c7eda7a495b4e6e7334d3890
-
-     Which is then base64 encoded to meet the requirements of the IMAP4
-     AUTHENTICATE command (or the similar POP3 AUTH command), yielding
-
-           dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw
-
-
-
-3. References
-
-   [CHAP]  Lloyd, B. and W. Simpson, "PPP Authentication Protocols",
-       RFC 1334, October 1992.
-
-   [IMAP] Crispin, M. "Internet Message Access Protocol - Version 4",
-       RFC 1730, University of Washington, December, 1994.
-
-   [IMAP-AUTH] Myers, J. "IMAP4 Authentication Mechanisms", 
-       RFC 1731, Carnegie Mellon, December, 1994
-
-   [KEYED-MD5] Krawczyk, H "HMAC-MD5: Keyed-MD5 for Message
-       Authentication" work in progess (draft-ietf-ipsec-hmac-md5-00.txt),
-       IBM, March 1996. 
-
-   [MD5]  Rivest, R. "The MD5 Message Digest Algorithm",
-       RFC 1321, MIT Laboratory for Computer Science, April, 1992.  
-   
-   [POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3 ",
-       RFC 1939 (STD 53), Carnegie Mellon, May 1996.
-
-   [POP3-AUTH] Myers, J. "POP3 AUTHentication command", RFC 1734, Carnegie
-       Mellon, December, 1994.
-
-
-4. Security Considerations
-
-   It is conjectured that use of the CRAM authentication mechanism
-   provides origin identification and replay protection for a session.
-   Accordingly, a server that implements both a cleartext password
-   command and this authentication type should not allow both methods of
-   access for a given user.
-
-   While the saving, on the server, of "contexts" (see section 2) is
-   marginally better than saving the shared secrets in cleartext as is
-   required by CHAP [CHAP] and APOP [POP3], it is not sufficient to
-   protect the secrets if the server itself is compromised.
-   Consequently, servers that store the secrets or contexts must both
-   be protected to a level appropriate to the potential information
-   value in user mailboxes and identities.
-
-   As the length of the shared secret increases, so does the difficulty
-   of deriving it.
-
-   While there are now suggestions in the literature that the use of
-   MD5 and keyed MD5 in authentication procedures probably has a
-   limited effective lifetime, the technique is now widely deployed and
-   widely understood.  It is believed that this general understanding
-   may assist with the rapid replacement, by CRAM-MD5, of the current
-   uses of permanent cleartext passwords in IMAP.   This document has
-   been deliberately written to permit easy upgrading to use SHA (or
-   whatever alternatives emerge) when they are considered to be widely
-   available and adequately safe.
-
-   Even with the use of CRAM, users are still vulnerable to active
-   attacks.  An example of an increasingly common active attack is 'TCP
-   Session Hijacking' as described in CERT Advisory CA-95:01 [CERT95].
-
-   See section 1 above for additional discussion.
-
-
-5. Acknowledgements
-
-   This memo borrows ideas and some text liberally from [POP3] and
-   [RFC-1731] and thanks are due the authors of those documents.  Ran
-   Atkinson made a number of valuable technical and editorial
-   contributions to the current draft.
-
-
-6. Authors' Addresses
-
- John C. Klensin
- MCI Telecommunications
- 800 Boylston St, 7th floor
- Boston, MA 02199
- USA
-    Email: klensin@mci.net
-    Tel: +1 617 960 1011
-
- Randy Catoe
- MCI Telecommunications
- 2100 Reston Parkway
- Reston, VA 22091
- USA
-    Email: randy@mci.net
-    Tel: +1 703 715 7366
-
- Paul Krumviede
- MCI Telecommunications
- 2100 Reston Parkway
- Reston, VA 22091
- USA
-    Email: paul@mci.net
-    Tel: +1 703 715 7251
-
-
diff --git a/RFC/draft-newman-tls-imappop-05.txt b/RFC/draft-newman-tls-imappop-05.txt
deleted file mode 100644
index 680556e8..00000000
--- a/RFC/draft-newman-tls-imappop-05.txt
+++ /dev/null
@@ -1,618 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          C. Newman
-Internet Draft: Using TLS with IMAP4, POP3 and ACAP             Innosoft
-Document: draft-newman-tls-imappop-05.txt                  November 1998
-
-
-                  Using TLS with IMAP4, POP3 and ACAP
-
-
-Status of this memo
-
-     This document is an Internet-Draft.  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."
-
-     To view the entire list of current Internet-Drafts, please check
-     the "1id-abstracts.txt" listing contained in the Internet-Drafts
-     Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
-     (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
-     (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US
-     West Coast).
-
-Abstract
-
-     This specification defines extensions to IMAP [IMAP4], POP [POP3]
-     and ACAP [ACAP] which activate TLS [TLS].  This also defines a
-     simple PLAIN SASL [SASL] mechanism for use underneath strong TLS
-     encryption with ACAP or other protocols lacking a clear-text login
-     command.
-
-1. Motivation
-
-     The TLS protocol [TLS] (formerly known as SSL) provides a way to
-     secure a TCP connection from tampering and eavesdropping.
-     Obviously, the option of using such security is desirable for IMAP
-     [IMAP4], POP [POP3] and ACAP [ACAP].  Although advanced SASL [SASL]
-     authentication mechanisms can provide a lightweight version of this
-     service, TLS is a full service security layer and is complimentary
-     to simple authentication-only SASL mechanisms or clear-text
-     password login commands. Furthermore, many sites have a high
-     investment in authentication infrastructure (e.g., a large database
-     of a one-way-function applied to user passwords), so a privacy
-
-
-
-Newman                                                          [Page 1]
-
-Internet Draft    Using TLS with IMAP4, POP3 and ACAP      November 1998
-
-
-     layer which is not tightly bound to user authentication can protect
-     against network eavesdropping attacks without requiring a new
-     authentication infrastructure and/or forcing all users to change
-     their password.
-
-1.1. Conventions Used in this Document
-
-     The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD
-     NOT", "MAY", and "OPTIONAL" in this document are to be interpreted
-     as described in "Key words for use in RFCs to Indicate Requirement
-     Levels" [KEYWORDS].
-
-     Formal syntax is defined using ABNF [ABNF].
-
-     In examples, "C:" and "S:" indicate lines sent by the client and
-     server respectively.
-
-2. Basic Interoperability and Security Requirements
-
-     The following requirements apply to all implementations of the
-     STARTTLS extension for IMAP4, POP3 and ACAP.
-
-2.1. Cipher Suite Requirements
-
-     Implementation of the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher
-     suite is REQUIRED.  This is important as it assures that any two
-     compliant implementations can be configured to interoperate.
-
-     All other cipher suites are OPTIONAL.
-
-2.2. TLS Operational Mode Security Requirements
-
-     Both clients and servers SHOULD have an operational mode where use
-     of TLS encryption is required to login.  Clients MAY have an
-     operational mode where TLS is used only when advertised by the
-     server, but login occurs regardless.  For backwards compatibility,
-     servers SHOULD have an operational mode which permits clients to
-     login when TLS is not used.
-
-2.3. Clear-Text Password Requirement
-
-     A server which implements both STARTTLS and a clear-text password
-     authentication mechanism (including but not limited to the IMAP4
-     LOGIN command, POP3 PASS command and the PLAIN mechanism in section
-     6) MUST have an operational mode where all clear-text login
-     commands and mechanisms are disabled unless TLS encryption is
-     active.
-
-
-
-
-Newman                                                          [Page 2]
-
-Internet Draft    Using TLS with IMAP4, POP3 and ACAP      November 1998
-
-
-2.4. Server Identity Check
-
-     During the TLS negotiation, the client MUST check its understanding
-     of the server hostname against the server's identity as presented
-     in the server Certificate message, in order to prevent
-     man-in-the-middle attacks.  Matching is performed according to
-     these rules:
-
-     o   The client MUST use the server hostname it used to open the
-         connection as the value to compare against the server name as
-         expressed in the server certificate.  The client MUST NOT use
-         any form of the server hostname derived from an insecure remote
-         source (e.g., insecure DNS reverse lookup).
-
-     o   If a subjectAltName extension of type dNSName is present in the
-         certificate, it SHOULD be used as the source of the server's
-         identity.
-
-     o   Matching is case-insensitive.
-
-     o   A "*" wildcard character MAY be used as the left-most name
-         component in the certificate.  For example, *.example.com would
-         match a.example.com, foo.example.com, etc. but would not match
-         example.com.
-
-     o   If the certificate contains multiple names (e.g. more than one
-         dNSName field), then a match with any one of the fields is
-         considered acceptable.
-
-     If the match fails, the client SHOULD either ask for explicit user
-     confirmation, or terminate the connection and indicate the server's
-     identity is suspect.
-
-3. IMAP4 STARTTLS extension
-
-     When the TLS extension is present in IMAP4, "STARTTLS" is listed as
-     a capability in response to the CAPABILITY command.  This extension
-     adds a single command, "STARTTLS" to the IMAP4 protocol which is
-     used to begin a TLS negotiation.
-
-3.1. STARTTLS Command
-
-   Arguments:  none
-
-   Responses:  no specific responses for this command
-
-   Result:     OK - begin TLS negotiation
-               NO - security layer already active
-
-
-
-Newman                                                          [Page 3]
-
-Internet Draft    Using TLS with IMAP4, POP3 and ACAP      November 1998
-
-
-               BAD - command unknown or arguments invalid
-
-      A TLS negotiation begins immediately after the CRLF at the end of
-      the tagged OK response from the server.  Once a client issues a
-      STARTTLS command, it MUST NOT issue further commands until a
-      server response is seen and the TLS negotiation is complete.
-
-      The STARTTLS command is only valid in non-authenticated state.
-      The server remains in non-authenticated state, even if client
-      credentials are supplied during the TLS negotiation.  The SASL
-      [SASL] EXTERNAL mechanism MAY be used to authenticate once TLS
-      client credentials are successfully exchanged, but servers
-      supporting the STARTTLS command are not required to support the
-      EXTERNAL mechanism.
-
-      Once TLS has been started, the client SHOULD discard cached
-      information about server capabilities and re-issue the CAPABILITY
-      command.  This is necessary to protect against man-in-the-middle
-      attacks which alter the capabilities list prior to STARTTLS.  The
-      server MAY advertise different capabilities after STARTTLS.
-
-      The formal syntax for IMAP4 is amended as follows:
-
-        command_any   =/  "STARTTLS"
-
-   Example:    C: a001 CAPABILITY
-               S: * CAPABILITY IMAP4rev1 STARTTLS
-               S: a001 OK CAPABILITY completed
-               C: a002 STARTTLS
-               S: a002 OK Begin TLS negotiation now
-               <TLS negotiation, further commands are under TLS layer>
-               C: a003 CAPABILITY
-               S: * CAPABILITY IMAP4rev1 AUTH=EXTERNAL
-               S: a003 OK CAPABILITY completed
-               C: a004 LOGIN joe password
-               S: a004 OK LOGIN completed
-
-4. POP3 STARTTLS extension
-
-   The POP3 STARTTLS extension adds the STLS command to POP3 servers.
-   If this is implemented, the POP3 extension mechanism [POP3EXT] MUST
-   also be implemented to avoid the need for client probing of multiple
-   commands.  The capability name "STLS" indicates this command is
-   present.
-
-      STLS
-
-         Arguments: none
-
-
-
-Newman                                                          [Page 4]
-
-Internet Draft    Using TLS with IMAP4, POP3 and ACAP      November 1998
-
-
-         Restrictions:
-             Only permitted in AUTHORIZATION state.
-
-         Discussion:
-             A TLS negotiation begins immediately after the CRLF at the
-             end of the +OK response from the server.  A -ERR response
-             MAY result if a security layer is already active.  Once a
-             client issues a STLS command, it MUST NOT issue further
-             commands until a server response is seen and the TLS
-             negotiation is complete.
-
-             The STLS command is only permitted in AUTHORIZATION state
-             and the server remains in AUTHORIZATION state, even if
-             client credentials are supplied during the TLS negotiation.
-             The AUTH command [POP-AUTH] with the EXTERNAL mechanism
-             [SASL] MAY be used to authenticate once TLS client
-             credentials are successfully exchanged, but servers
-             supporting the STLS command are not required to support the
-             EXTERNAL mechanism.
-
-             Once TLS has been started, the client SHOULD discard cached
-             information about server capabilities and re-issue the CAPA
-             command.  This is necessary to protect against
-             man-in-the-middle attacks which alter the capabilities list
-             prior to STLS.  The server MAY advertise different
-             capabilities after STLS.
-
-         Possible Responses:
-             +OK -ERR
-
-         Examples:
-             C: STLS
-             S: +OK Begin TLS negotiation
-             <TLS negotiation, further commands are under TLS layer>
-               ...
-             C: STLS
-             S: -ERR Security Layer already active
-
-5. ACAP STARTTLS extension
-
-     When the TLS extension is present in ACAP, "STARTTLS" is listed as
-     a capability in the ACAP greeting.  No arguments to this capability
-     are defined at this time.  This extension adds a single command,
-     "STARTTLS" to the ACAP protocol which is used to begin a TLS
-     negotiation.
-
-
-
-
-
-
-Newman                                                          [Page 5]
-
-Internet Draft    Using TLS with IMAP4, POP3 and ACAP      November 1998
-
-
-5.1. STARTTLS Command
-
-   Arguments:  none
-
-   Responses:  no specific responses for this command
-
-   Result:     OK - begin TLS negotiation
-               NO - security layer already active
-               BAD - command unknown or arguments invalid
-
-      A TLS negotiation begins immediately after the CRLF at the end of
-      the tagged OK response from the server.  Once a client issues a
-      STARTTLS command, it MUST NOT issue further commands until a
-      server response is seen and the TLS negotiation is complete.
-
-      The STARTTLS command is only valid in non-authenticated state.
-      The server remains in non-authenticated state, even if client
-      credentials are supplied during the TLS negotiation.  The SASL
-      [SASL] EXTERNAL mechanism MAY be used to authenticate once TLS
-      client credentials are successfully exchanged, but servers
-      supporting the STARTTLS command are not required to support the
-      EXTERNAL mechanism.
-
-      After the TLS layer is established, the server MUST re-issue an
-      untagged ACAP greeting.  This is necessary to protect against
-      man-in-the-middle attacks which alter the capabilities list prior
-      to STARTTLS.  The client SHOULD discard cached capability
-      information and replace it with the information from the new ACAP
-      greeting.  The server MAY advertise different capabilities after
-      STARTTLS.
-
-      The formal syntax for ACAP is amended as follows:
-
-        command_any   =/  "STARTTLS"
-
-   Example:    S: * ACAP (SASL "CRAM-MD5") (STARTTLS)
-               C: a002 STARTTLS
-               S: a002 OK "Begin TLS negotiation now"
-               <TLS negotiation, further commands are under TLS layer>
-               S: * ACAP (SASL "CRAM-MD5" "PLAIN" "EXTERNAL")
-
-6. PLAIN SASL mechanism
-
-     Clear-text passwords are simple, interoperate with almost all
-     existing operating system authentication databases, and are useful
-     for a smooth transition to a more secure password-based
-     authentication mechanism.  The drawback is that they are
-     unacceptable for use over an unencrypted network connection.
-
-
-
-Newman                                                          [Page 6]
-
-Internet Draft    Using TLS with IMAP4, POP3 and ACAP      November 1998
-
-
-     This defines the "PLAIN" SASL mechanism for use with ACAP and other
-     protocols with no clear-text login command.  This MUST NOT be
-     implemented unless strong TLS encryption or an equivalent strong
-     encryption layer is also implemented.
-
-     The mechanism consists of a single message from the client to the
-     server.  The client sends the authorization identity (identity to
-     login as), followed by a US-ASCII NUL character, followed by the
-     authentication identity (identity whose password will be used),
-     followed by a US-ASCII NUL character, followed by the clear-text
-     password.  The client may leave the authorization identity empty to
-     indicate that it is the same as the authentication identity.
-
-     The server will verify the authentication identity and password
-     with the system authentication database and verify that the
-     authentication credentials permit the client to login as the
-     authorization identity.  If both steps succeed, the user is logged
-     in.
-
-     The server MAY also use the password to initialize any new
-     authentication database, such as one suitable for CRAM-MD5
-     [CRAM-MD5].
-
-     Non-US-ASCII characters are permitted as long as they are
-     represented in UTF-8 [UTF-8].  Use of non-visible characters or
-     characters which a user may be unable to enter on some keyboards is
-     discouraged.
-
-     Clients are encouraged to support pure-binary passwords as they may
-     be safe from dictionary attacks.  However, if the client offers a
-     character-based interface for password entry it MUST use UTF-8
-     encoding for the characters.
-
-     The formal grammar for the client message using Augmented BNF
-     [ABNF] follows.
-
-     message         = [authorize-id] NUL authenticate-id NUL password
-     authenticate-id = 1*UTF8-SAFE      ; MUST accept up to 255 octets
-     authorize-id    = 1*UTF8-SAFE      ; MUST accept up to 255 octets
-     password        = *NZ-OCTET        ; MUST accept up to 255 octets
-     NUL             = %x00
-     NZ-OCTET        = %x01-FF          ; all non-NUL octet values
-     UTF8-SAFE       = %x01-09 / %x0B-0C / %x0E-7F / UTF8-2 /
-                       UTF8-3 / UTF8-4 / UTF8-5 / UTF8-6
-     UTF8-1          = %x80-BF
-     UTF8-2          = %xC0-DF UTF8-1
-     UTF8-3          = %xE0-EF 2UTF8-1
-     UTF8-4          = %xF0-F7 3UTF8-1
-
-
-
-Newman                                                          [Page 7]
-
-Internet Draft    Using TLS with IMAP4, POP3 and ACAP      November 1998
-
-
-     UTF8-5          = %xF8-FB 4UTF8-1
-     UTF8-6          = %xFC-FD 5UTF8-1
-
-     Here is an example of how this might be used to initialize a
-     CRAM-MD5 authentication database for ACAP:
-
-     Example:    S: * ACAP (SASL "CRAM-MD5") (STARTTLS)
-                 C: a001 AUTHENTICATE "CRAM-MD5"
-                 S: + "<1896.697170952@postoffice.reston.mci.net>"
-                 C: "tim b913a602c7eda7a495b4e6e7334d3890"
-                 S: a001 NO (TRANSITION-NEEDED)
-                    "Please change your password, or use TLS to login"
-                 C: a002 STARTTLS
-                 S: a002 OK "Begin TLS negotiation now"
-                 <TLS negotiation, further commands are under TLS layer>
-                 S: * ACAP (SASL "CRAM-MD5" "PLAIN" "EXTERNAL")
-                 C: a003 AUTHENTICATE "PLAIN" {21+}
-                 C: <NUL>tim<NUL>tanstaaftanstaaf
-                 S: a003 OK CRAM-MD5 password initialized
-
-     Note: In this example, <NUL> represents a single ASCII NUL octet.
-
-     Here is an example session where a client erroneously attempts to
-     use PLAIN prior to starting TLS:
-
-     Example:    S: * ACAP (SASL "CRAM-MD5" "PLAIN") (STARTTLS)
-                 C: a001 AUTHENTICATE "PLAIN" {21}
-                 S: a001 NO (ENCRYPT-NEEDED)
-                    "Can't use PLAIN without encryption"
-
-7. imaps and pop3s ports
-
-     The common practice of using a separate port for a "secure" version
-     of each protocol has a number of disadvantages in the IMAP [IMAP4],
-     ACAP [ACAP] and POP [POP3] environment.  Rather than using the best
-     security available, it means that clients have to be explicitly
-     configured to use the separate secure port or suffer the
-     performance loss of probing for active ports.  Furthermore this is
-     even more serious as it would require a new URL scheme which could
-     only be resolved by TLS-enabled clients.
-
-     Separate "imaps" and "pop3s" ports were registered for use with
-     TLS.  Use of these ports is discouraged in favor of the STARTTLS or
-     STLS command.
-
-     One of the arguments used in favor of the separate port technique
-     is that it simplifies configuration of firewalls which filter by IP
-     port.  However, a quality server implementation running on the
-
-
-
-Newman                                                          [Page 8]
-
-Internet Draft    Using TLS with IMAP4, POP3 and ACAP      November 1998
-
-
-     standard port can be configured to require use of the STARTTLS
-     command or a suitably strong SASL mechanism for non-local
-     connections.  This provides superior functionality as the client
-     need not be re-configured for use outside the firewall and faster
-     non-clear-text SASL mechanisms may be acceptable to many sites for
-     non-local connections.
-
-8. IANA Considerations
-
-     This document constitutes registration of the "STARTTLS" IMAP4
-     capability as required by section 7.2.1 of RFC 2060.
-
-     This document defines the "STLS" POP3 capability as follows:
-
-     CAPA tag:                   STLS
-     Arguments:                  none
-     Added commands:             STLS
-     Standard commands affected: May enable USER/PASS as a side-effect.
-       CAPA command should be re-issued after successful completion.
-     Announced states/Valid states: AUTHORIZATION state only.
-     Specification reference:    this memo
-
-     This document defines the "STARTTLS" ACAP capability as follows:
-
-     Capability name:            STARTTLS
-     Capability keyword:         STARTTLS
-     Capability arguments:       none
-     Published Specification(s): this memo
-     Person and email address for further information:
-         see author's address section below
-
-     This document defines the "PLAIN" SASL mechanism as follows:
-
-     SASL mechanism name:        PLAIN
-     Security Considerations:    See section 9 of this memo
-     Published specification:    this memo
-     Person & email address to contact for further information:
-         see author's address section below
-     Intended usage:             COMMON
-     Author/Change controller:   see author's address section below
-
-9. Security Considerations
-
-     TLS only provides protection for data sent over a network
-     connection.  Messages transferred over IMAP or POP3 are still
-     available to server administrators and usually subject to
-     eavesdropping, tampering and forgery when transmitted through SMTP
-     or NNTP.  TLS is no substitute for an end-to-end message security
-
-
-
-Newman                                                          [Page 9]
-
-Internet Draft    Using TLS with IMAP4, POP3 and ACAP      November 1998
-
-
-     mechanism using MIME security multiparts [MIME-SEC].
-
-     An active attacker can remove STARTTLS from the capability list.
-     In order to detect such an attack, clients SHOULD either warn the
-     user when session privacy is not active, or be configurable to
-     refuse to proceed without an acceptable level of security.
-
-     Both client and server MUST verify the level of protection
-     negotiated by TLS is adequate for local security policy, and
-     terminate the TCP connection if it is not.  An active attacker can
-     always cause a down-negotiation to the weakest authentication
-     mechanism or cipher suite available.  For this reason,
-     implementations need to be configurable to refuse weak mechanisms
-     or cipher suites.
-
-     Any protocol interactions prior to the TLS handshake are performed
-     in the clear and can be modified by an active attacker.  For this
-     reason, clients SHOULD discard cached information about server
-     capabilities advertised prior to the start of the TLS handshake.
-
-     Clients are encouraged to clearly distinguish between a level of
-     encryption known to be vulnerable to a reasonable attack using
-     modern hardware (such as encryption with a 40-bit key) and one
-     which is believed to be safe from such an attack.
-
-     When the PLAIN mechanism (or the IMAP4 LOGIN or POP3 PASS command)
-     is used, the server gains the ability to impersonate the user to
-     all services with the same password regardless of any encryption
-     provided by TLS or other network privacy mechanisms.  Stronger SASL
-     authentication mechanisms such as Kerberos address this issue.
-
-     Use of clear-text login mechanisms (e.g., the IMAP4 LOGIN command,
-     POP3 PASS command or the PLAIN mechanism) without a suitable
-     encryption layer such as that provided by TLS expose the user's
-     password to a common network eavesdropping attack.  Therefore, the
-     PLAIN mechanism MUST NOT be implemented unless a suitable
-     encryption layer, such as that provided by TLS is also implemented.
-
-     Additional security requirements are discussed in section 2.
-
-10. References
-
-     [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications:
-     ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd,
-     November 1997.
-
-     [ACAP] Newman, Myers, "ACAP -- Application Configuration Access
-     Protocol", RFC 2244, Innosoft, Netscape, November 1997.
-
-
-
-Newman                                                         [Page 10]
-
-Internet Draft    Using TLS with IMAP4, POP3 and ACAP      November 1998
-
-
-     [CRAM-MD5] Klensin, Catoe, Krumviede, "IMAP/POP AUTHorize Extension
-     for Simple Challenge/Response", RFC 2195, MCI, September 1997.
-
-     [IMAP4] Crispin, M., "Internet Message Access Protocol - Version
-     4rev1", RFC 2060, University of Washington, December 1996.
-
-     [IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanism", RFC 1731,
-     Carnegie-Mellon University, December 1994.
-
-     [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
-     Requirement Levels", RFC 2119, Harvard University, March 1997.
-
-     [MIME-SEC] Galvin, Murphy, Crocker, Freed, "Security Multiparts for
-     MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, Trusted
-     Information Systems, CyberCash, Innosoft International, October
-     1995.
-
-     [POP3] Myers, J., Rose, M., "Post Office Protocol - Version 3", RFC
-     1939, Carnegie Mellon, Dover Beach Consulting, Inc., May 1996.
-
-     [POP3EXT] Gellens, Newman, Lundblade "POP3 Extension Mechanism",
-     Work in progress.
-
-     [POP-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734,
-     Carnegie Mellon, December 1994.
-
-     [SASL] Myers, J., "Simple Authentication and Security Layer
-     (SASL)", RFC 2222, Netscape Communications, October 1997.
-
-     [TLS] Dierks, Allen, "The TLS Protocol Version 1.0", Work in
-     progress.
-
-     [UTF-8] Yergeau, F. "UTF-8, a transformation format of ISO 10646",
-     RFC 2279, Alis Technologies, January 1998.
-
-11. Author's Address
-
-     Chris Newman
-     Innosoft International, Inc.
-     1050 Lakes Drive
-     West Covina, CA 91790 USA
-
-     Email: chris.newman@innosoft.com
-
-
-
-
-
-
-
-
-Newman                                                         [Page 11]
diff --git a/RFC/lan-mail-protocols b/RFC/lan-mail-protocols
deleted file mode 100644
index 13e984ee..00000000
--- a/RFC/lan-mail-protocols
+++ /dev/null
@@ -1,1330 +0,0 @@
-
-     SERVING DESKTOP COMPUTERS USING A CENTRAL MAIL SERVER ON AN INTERNET
-                                       
-   
-     _________________________________________________________________
-   
-   Author
-          John Wobus, jmwobus@syr.edu (corrections welcome)
-          
-   Date
-          2/4/1997
-          
-   This file
-          http://web.syr.edu/~jmwobus/comfaqs/lan-mail-protocols.html
-          
-   Other LAN Info
-          http://web.syr.edu/~jmwobus/lans/
-          
-   
-     _________________________________________________________________
-   
-Contents
-
-     * Introduction
-     * List of Protocols and RFCs
-     * Other Sources of Information
-     * Capabilities of Well-known mail clients
-     * List of Implementations
-     * Some other packages for desktop systems
-     * Key and Other Issues
-       
-   
-     _________________________________________________________________
-   
-Introduction
-
-   
-   
-   There are advantages to having a central server receive the mail
-   destined to desktop computers and having the desktop computer collect
-   the mail from the server on demand:
-     * Your desktop computer may be down quite a bit and less network
-       bandwidth and less of the processing resources of the sending
-       computer are used if the computer receiving your mail is ready to
-       receive.
-     * Some people use more than one desktop computer to read mail.
-     * A desktop computer may not have the resources to store all the
-       mail you receive.
-     * It can make your e-mail address more like other users'.
-       
-   
-   
-   The easiest way to "implement" this is to run the central mail server
-   like any multi-user system: let people sign on to it and use some mail
-   utility. Then desktop computer users can use "terminal sessions" to
-   sign on to the central mail server and read their mail (e.g. with Unix
-   "pine"). This has the disadvantage of making the desktop computer
-   users learn and use the central mail server's procedures.
-   
-   SMTP, the "internet" mail protocol used to deliver mail between
-   multi-user systems only supports mail transfer initiated by the sender
-   to actually, it has a method to initiate reception, but the method
-   didn't catch on and is not used). Other protocols have been devised to
-   allow a desktop computer to request transfer of mail, thus able to
-   make use of a central server. These include the published variants of
-   POP, IMAP, and DMSP.
-   
-  POP, POP2, POP3
-  
-   
-   
-   These are rather minimal and are designed to be so. The three are
-   similar but not enough alike to be interoperable. They are basically
-   designed to identify the user by username and password, to transfer
-   the mail from server to desktop computer and to delete the mail
-   transferred. It is assumed that SMTP will be used to send mail.
-   Messages can be retrieved individually, but the only information you
-   can get about a message without transferring it is its length in
-   bytes-- useful for desktop computers with limited storage.
-   
-   POP3 has a number of optional extensions including Xtnd Xmit which
-   allows clients to send mail through the POP3 session rather than using
-   SMTP. Another extension is APOP which allows RSA MD5 encryption of
-   passwords passed over the network.
-   
-   POP3 is now by far the most-used variant of POP, but POP2 may still be
-   used at a few sites. POP3 has a couple of optional extensions: one to
-   avoid sending passwords, and one to aid in reading bulletin boards.
-   
-  IMAP2, IMAP2BIS, IMAP3, IMAP4, IMAP4REV1
-  
-   
-   
-   The IMAP family is similar to the POP family, but also gives clients a
-   way to do string searches through mail that still resides on the
-   server. This is designed to allow the desktop computer to be more
-   selective as to which mail will be transferred. The POP protocols, on
-   the other hand, are designed for simpler server software.
-   
-   IMAP2 is used quite a bit. IMAP3 is an incompatible offshoot that has
-   not been implemented much. IMAP4 is a relatively recent extension of
-   IMAP2 which makes the servers cognizant of the MIME-structure of a
-   message. IMAP2bis was the original name of IMAP4, which has since been
-   refined, but there are/were some implementations of IMAP2bis that are
-   not IMAP4 compliant. IMAP4 also extends IMAP to have many other
-   features including some of DMSP's. IMAP4rev1 includes a few
-   enhancements to IMAP4.
-   
-  ACAP
-  
-   
-   
-   ACAP (Application Configuration Access Protocol), formerly IMSP
-   (Interactive Mail Support Protocol), is a protocol which is being
-   developed to compliment IMAP4 by offering related e-mail services
-   beyond the scope of IMAP4. It includes the ability to subscribe find &
-   subscribe to bulletin boards, mailboxes, and to find and search
-   address books.
-   
-  IMAP VS POP
-  
-   
-   
-   As of this writing (10/96), there are a many more POP than IMAP client
-   implementations and an Internet Service Provider is much more likely
-   to provide POP3 service than IMAP4. But interest in IMAP4 is growing
-   with big-time software houses announcing support. IMAP4 has more
-   features, basically designed to support a model where users store
-   their received mail on a server rather than on their own computer. The
-   big advantage cited for IMAP is that people who "do e-mail" from
-   different computers at different times have the same access to their
-   message store from any of the client-computers they use. The cost of
-   this model (aside from issues such as the complexity and the
-   availability of implementations) is in running a server with
-   sufficient space for the clients' message stores. With personal
-   computer disks now often above a gigabyte (presumeably growing to 10s
-   of gigabytes over the next few years) and multimedia messaging in our
-   future, people storing e-mail on their own hard disk will have a lot
-   of space and ways to use it. A central store serving 10-20 users will
-   not be overly difficult, but one for 1,000 or 10,000 users will be
-   very large (terabytes?) if it is to offer comparable space. The
-   question comes down to the tradeoff between the advantage to users who
-   computer-hop against the costs of managing the large amount of central
-   store. See also online document imap.vs.pop.html (reference below) and
-   section below "Issue of Remote Access".
-   
-  DMSP
-  
-   
-   
-   Also know as PCMAIL. Desktop computers can use this protocol to both
-   send and receive mail. The system is designed around the idea that
-   each user can own more than one workstation; however, the system
-   doesn't seem to handle the idea of a "public workstation" very well.
-   The desktop computers are assumed to hold state information about the
-   mail, a directory so to speak, and when the desktop computer is
-   connected to the server, this directory is updated to "reality". Note:
-   DMSP never gained the following of IMAP or POP and I've heard the
-   software is no longer available.
-   
-  WHO USES THESE PROTOCOLS?
-  
-   
-   
-   These protocols were designed and implemented mostly by
-   Internet-connected universities with some participation by other
-   Internet-connected research institutions. They were certainly devised
-   to handle the type of electronic mail that universities must do. A
-   typical site has probably 10 to 10,000 desktop computers and has an
-   Internet connection and also runs Unix, giving them the Unix sysadmin
-   expertise that makes running a Unix-based server attractive. Most of
-   the servers listed here run under Unix though some run under other
-   large systems and as time goes on, we are seeing more servers that run
-   on PCs and Macintoshes.
-   
-   A more recent use of these protocols has been by Internet Service
-   Providers and their customers. Internet Service Providers require a
-   way to offer e-mail services to however many customers they provide,
-   to customers who are connected to the network only part of the time.
-   Like a campus application, they may have 10 or 10,000 customers to
-   serve. These protocols offer a distinct advantage over SMTP for such
-   purposes and form an attractive complementary e-mail service for WWW
-   users.
-   
-  DISADVANTAGES
-  
-   
-   
-   There are a number of disadvantages associated with the use of these
-   protocols:
-     * since these have long been no more than a small part of the e-mail
-       market, software using these methods is often incompatible with
-       other useful and/or well-known software. A couple of examples are:
-          + Use of mail-enabled applications on desktop computers (there
-            is no fundamental reason that mail software using these
-            protocols can't provide the API used by mail-enabled
-            applications, but in general this hasn't come about yet)
-          + Use of the usual Unix mail readers & the Unix .forward files.
-     * since the server is holding mail for the person, the person can
-       use the server for storage. This leaves the potential for all the
-       disk-space problems inherent in shared disks: people hogging
-       disk-space or forgetting to clean up, etc.
-     * sizing the server: a perennial question people ask is "How big a
-       machine do I need to serve my campus (or department, or
-       whatever)". Naturally no one can give a straight answer because it
-       depends upon so many factors.
-       
-  ISSUE OF REMOTE ACCESS
-  
-   
-   
-   Modern commercial e-mail packages typically have features designed to
-   assist in remote access of ones e-mail. Features include:
-     * ability to download mail through a modem
-     * ability to synchronize two different systems which you are using
-       to read your e-mail by plugging them together.
-       
-   
-   
-   Any method of reading e-mail using PCs or Macintoshes can be used
-   remotely via remote control (the "PCanywhere(tm)" method, e.g. by
-   dialing up your own office PC/Macintosh and using one of the several
-   kinds of software that allow you to control your PC/Macintosh over the
-   phone). Also, any LAN-based method can be used by using one of the
-   several methods of providing the same protocol support over dialup
-   lines as are on LANs (SLIP or PPP for the above-mentioned,
-   TCP/IP-based protocols, ARA for Appletalk-based protocols, etc, and
-   sometimes using two different protocols, one incapsulated in the
-   other) under the constraint that any operations that use the network
-   will be much slower. Also, POP3 is sometime used directly over modems
-   (for example, Eudora can be used in this manner).
-   
-   The ideal protocol for remote access would not penalize the user for
-   the much slower communications speed (usually slower by a factor of
-   100: note that a lot of LAN-based software was written without regard
-   to minimizing the necessary communication, thus is really hurt by such
-   slow speeds), yet would allow the same software to run both remotely
-   and locally, with a wonderful user interface. It would also not be
-   overly expensive in communications equipment or services. This is a
-   difficult set of objectives and the above-three protocols can achieve
-   some of them for some users, but what they actually achieve depends a
-   lot on the user's pattern of e-mail usage. If a user reads just a
-   small amount of mail, then we would not worry about the length of time
-   necessary to download it remotely with POP3, but if the person
-   receives a lot of mail, but just wants to read a small amount of it at
-   home, then with IMAP2, they could pick and choose what to read,
-   eliminating some download time. If someone is paying for the telephone
-   line time (possibly the user if it is a long distance call; in any
-   case, the institution pays a monthly fee for each line it offers,
-   which is dependent upon how many users it is serving, how often they
-   call, and how long their calls are) then IMAP2's natural method of
-   usage which requires the phone call to remain while a user is reading,
-   poking around, sending, and rearranging mail can be much more costly
-   than using POP3 if one call is used to quickly download all the mail
-   and another later call is used to send any replies. Thus with POP3 a
-   user might have two 1 minute calls before and after a 30 minute e-mail
-   session instead of keeping the call for 30 minutes with IMAP2, and
-   each phone line the institution offers could be serving 15 times as
-   many such users who would each pay a lot less in long-distance phone
-   bills. Note that with the advent of multimedia mail (see MIME below)
-   whose messages can be very large, it is possible that downloading even
-   one message that you end up not reading remotely could ruin such a
-   nice-sounding scenario.
-   
-   Note that with the growth of Internet Service Providers, remote access
-   is becoming the normal way for many people to do their e-mail, and
-   offering such services is one of the major growth areas for POP and
-   IMAP.
-   
-  MIME
-  
-   
-   
-   MIME (Multipurpose Internet Mail Extensions) is a relatively new
-   Internet standard for the format for messages with multiple parts, and
-   with non-ASCII data. Any client that can import or export files can
-   use MIME in a clumsy way if you have a program to create and/or decode
-   a MIME message. Some clients have built-in features to do this.
-   Client-server mail protocols generally only deal with entire messages,
-   and can retrieve MIME messages as well as any other messages since
-   MIME was carefully designed to be transparent to existing mail
-   systems. However, IMAP4 has features to allow retrieval of individual
-   parts of MIME-encoded messages. The chart below lists whether a
-   package has MIME support. Servers for protocols that don't offer any
-   special MIME features are marked na for Not Applicable since they need
-   do nothing for users to use MIME. All IMAP4 servers can also do this,
-   but the chart lists whether they include explicit MIME support.
-   
-  APPROACHES NOT COVERED BY THIS MEMO
-     * Proprietary protocols
-     * file sharing
-     * APIs
-     * X.400.
-       
-   
-   
-   Vendors can invent their own protocols similar to those listed above,
-   and some have.
-   
-   LAN e-mail can also be implemented using file sharing, e.g. using NFS
-   to allow separate Unix workstations to share the same mail spool area
-   just as if it were mail being stored on one system, or using Novell's
-   SMF (Simple Message Format) in a Novell file server. If the
-   applications are written so that they are careful to lock files
-   correctly, then this works. An advantage is that any network file
-   protocol can be used and the e-mail application can be somewhat
-   independent of the file protocol. For example, Unix systems could use
-   either AFS or NFS. Pegasus is a PC & Mac application that uses Novell
-   file service to do something similar. Specifications for client-server
-   interaction consist of the file service protocol along with the server
-   directory structures & conventions used for storing e-mail.
-   
-   A very popular approach with commercial vendors is the use of APIs.
-   The client talks to the server using an API (Applications Programming
-   Interface), i.e., a set of subroutine/procedure library call
-   definitions for a library providing subroutines/procedures to send,
-   receive, and manipulate e-mail. With the use of any remote procedure
-   call mechanism, the client can be located on a different computer from
-   the server. This allows some mixing and matching of RPC mechanisms,
-   underlying protocol stacks and APIs: e.g., a vendor defines an API,
-   and it can be run over IPX or TCP/IP, in each case over the protocol
-   stack's RPC mechanism. There are a number of APIs now being pushed by
-   vendors: MAPI (Microsoft); VIM (Lotus); AOCE (Apple). These API's have
-   been the basis for numerous mail-enabled applications: e.g. a word
-   processor that allows you to send or receive documents through e-mail
-   simply uses one of these APIs allowing it to communicate with any
-   server supporting the same API. Specifications for client-server
-   interaction consist of the protocol stack up to the RPC protocol, then
-   the API itself.
-   
-   Note that though the API approach in combination with remote procedure
-   calls allows one to implement client-server e-mail without the use of
-   the protocols covered by this document (IMAP, POP, etc), that there is
-   no theoretical reason why such APIs can't be used in an IMAP or POP
-   environment. The necessary software would be a "driver" or piece of
-   "middleware" that provides the APIs calls to mail-enabled applications
-   and uses POP, IMAP, or whatever over a LAN to reach a server. The
-   advantages/disadvantages of such an approach as compared to the use of
-   RPCs is open to debate. UniPalm's Mail-IT is an example of client
-   software that provides MAPI within the client and uses POP3 to access
-   the server.
-   
-   X.400 is the message transport defined for use between
-   telecommunications vendors and customers by the international
-   consortium of national standards bodies known as ISO. It roughly
-   corresponds to TCP/IP's SMTP and RFC822 header format. A consortium of
-   X.400 vendors (XAPIA) have developed an API for X.400 applications
-   called CMC.
-   
-  LDAP
-  
-   
-   
-   LDAP is a protocol (the Lightweight Directory Access Protocol) being
-   incorporated in some clients as an Internet way for the client to get
-   information about e-mail addresses from a server, i.e. to give you the
-   capability to type in someone's name and have the mail client software
-   retrieve the address from a server-based directory. LDAP also has
-   other uses. There are plans to incorporate LDAP clients into some IMAP
-   and POP clients. LDAP is essentially an Internet-based, simplified
-   X.500-like protocol and one of the original intentions of its creators
-   was to be gatewayed to X.500, thus giving relatively simple Internet
-   clients access to X.500 servers. Both LDAP and X.500 provide a method
-   for naming, retrieving, and searching fields in a directory, but do
-   not define the field-names or what is supposed to go in the fields.
-   Thus server/client interoperability requires further conventions.
-   
-  JAVA
-  
-   
-   
-   Java is a programming language currently (1996) touted as a tool for
-   web-based applications. It can affect the use of LAN protocols in a
-   number of ways: first of all, POP or IMAP clients can be written in
-   Java, using its cross-platform development capabilities to create
-   version for a number of platforms. Second, clients could be written as
-   "Applets", i.e. applications designed to be downloaded into web
-   browsers such as Netscape from a server. With such a design, a user
-   would only need access to a web browser to see their e-mail, e.g. drop
-   into a library and see your e-mail from one of its Internet-browser
-   kyosks. Applets are not normally allowed to access the
-   client-machine's disk files (which would result in too much risk when
-   browsing the Internet from the kind of people who develop computer
-   viruses), so such an application fits a little better into the IMAP
-   model (server storage of e-mail folders) than the POP model (client
-   storage of e-mail folders). Thirdly, Applets enable more practical use
-   of e-mail clients that use non-standard protocols rather than POP or
-   IMAP; interoperability is achieved because the server itself
-   distributes a compatible client applet right when the user accesses
-   the server.
-     _________________________________________________________________
-   
-List of Protocols and RFCs
-
-   
-   
-   Note: for up-to-date information on the RFCs, get an index from an RFC
-   repository. For up-to-date information on the state of each RFC as to
-   the Internet Standards, see the most recent RFC called "Internet
-   Official Protocol Standards".
-
-Name:      Simple Mail Transfer Protocol
-Nickname:  SMTP
-Document:  RFC 821 (Postel, August 1982)
-TCP-port:  25
-Status:    Internet standard (STD 10)
-
-Name:      Post Office Protocol, Version 2
-Nickname:  POP2
-Document:  RFC 937 (Butler et al, February 1985)
-TCP-port:  109
-Status:    Functionally replaced by incompatible POP3 but still used some
-
-Name:      Post Office Protocol, Version 3
-Nickname:  POP3
-Document:  RFC 1939 (Myers & Rose, May 1996)
-TCP-port:  110 (109 also often used)
-Status:    In use, standards track
-Sites:     UC Irvine, MIT
-
-Name       Post Office Protocol, Version 3 Authentication command
-Nickname:  POP3 AUTH
-Document:  RFC1734 (Myers, December 1994)
-
-Name:      Post Office Protocol, Version 3 Extended Service Offerings
-Nickname:  POP3 XTND
-Document:  RFC 1082 (Rose, November 1988)
-
-Name:      Distributed Mail Service Protocol
-Nickname:  DMSP, Pcmail
-Document:  RFC 1056 (Lambert, June 1988)
-TCP-port:  158
-Status:    Used very little
-Sites:     MIT
-
-Name:      Interactive Mail Access Protocol, Version 2
-Nickname:  IMAP2
-Document:  RFC 1176 (Crispin, August 1990)
-TCP-port:  143
-Status:    In use, being replaced by upward-compatible IMAP4
-Sites:     Stanford, U Washington
-
-Name:      Interactive Mail Access Protocol, Version 2bis
-Nickname:  IMAP2bis
-TCP-port:  143
-Status:    Experimental, but in use, being replaced by upward-compatible IMAP4
-
-Name:      Interactive Mail Access Protocol, Version 3
-Nickname:  IMAP3
-Document:  RFC 1203 (Rice, February 1991)
-TCP-port:  220
-Status:    Historical, not used
-Sites:     Stanford
-
-Name:      Internet Message Access Protocol, Version 4
-Nickname:  IMAP4
-Document:  RFC 1730 (Crispin, December 1994)
-TCP-port:  143
-Status:    Implementations exist, being replaced by revised version IMAP4rev1
-Sites:     U Washington
-Related:   RFC 1731 (Myers, December 1994),
-           RFC 1732 (Crispin, December 1994),
-           RFC 1733 (Crispin, December 1994)
-
-Name:      Internet Message Access Protocol, Version 4rev1
-Nickname:  IMAP4rev1
-Document:  RFC 2060 (Crispin, December 1996)
-TCP-port:  143
-Status:    Being implemented, Standards track
-Sites:     U Washington
-Related:   RFC 2061 (Crispin, December 1996),
-           RFC 2062 (Crispin, December 1996)
-
-Name:      Interactive Mail Support Protocol
-Nickname:  IMSP
-Document:  Draft RFC: ? (Myers, June 1995)
-TCP Port:  406
-Status:    Experimental, renamed ACAP
-Sites:     Carnegie Mellon
-
-Name:      Application Configuratino Access Protocol
-Nickname:  ACAP
-Document:  Draft RFC: ? (Myers, June 1996)
-Status:    ?
-Sites:     Carnegie Mellon
-
-   
-   
-   Note: The "I" in IMAP used to stand for "Interactive". Now it stands
-   for "Internet" and the "M" stands for "Message" rather than "Mail".
-   Also, Internet drafts are available at ds.internic.net, munnari.oz.au,
-   and nic.nordu.net in directory internet-drafts. IMAP2bis is
-   essentially an early version of IMAP4.
-     _________________________________________________________________
-   
-Other Sources of Information
-
-   My own info
-          http://web.syr.edu/~jmwobus/lans/#imappop
-          http://web.syr.edu/~jmwobus/internet/
-          
-   The IMAP Connection web site
-          
-        http://www.imap.org
-                Main page
-                
-        http://www.imap.org/products.html
-                List of IMAP implementations
-                
-        http://www.imap.org/imap.vs.pop.brief.html
-                Outlines differences between IMAP and POP.
-                
-        http://www.imap.org/imap.vs.pop.html
-                Same, with more detail.
-                
-        http://www.imap.org/biblio.html
-                Bibliography of IMAP Documents.
-                
-   Information from University of Washington
-          http://www.washington.edu/imap/
-          
-   By anonymous ftp from ftp.cac.washington.edu
-          mail/* (miscellaneous information)
-          
-   Information from andrew2.andrew.cmu.edu
-          
-        http://andrew2.andrew.cmu.edu/cyrus/email/clients-IMAP.html
-                List of IMAP clients
-                
-        http://andrew2.andrew.cmu.edu/cyrus/acap/acap.html
-                The ACAP Home Page
-                
-   Mailing lists:
-          pop@jhunix.hcf.jhu.edu
-          imap@cac.washington.edu
-          CW-EMAIL@EARNCC.EARN.NET
-          
-   By anonymous ftp from rtfm.mit.edu
-          This memo
-          comp.os.msdos.mail-news FAQ Memo
-          Mini FAQ on client-server mail protocols (similar to this memo
-          but shorter and more practical:
-          ftp://rtfm.mit.edu/pub/usenet/news.answers/mail/mailclient-fa
-          q)
-          
-   Consortium
-          "The IMAP Consortium" (Getting under way as of March 1995).
-          
-   Page on MAPI API
-          http://www.wp.com/davidb/emapi.html
-          
-   
-     _________________________________________________________________
-   
-Capabilities of Well-known mail clients
-
-   
-   
-   This section covers what I've been able to find out so far about the
-   well-known mail clients' ability to retrieve mail from a POP or IMAP
-   server.
-
-Client                       POP3           IMAP          MIME
-------                       ----           ----          ----
-Apple PowerMail client          ?              ?             ?
-BeyondMail                    yes        planned-          yes
-CE QuickMail client       planned=       planned=          yes
-Claris Emailer                yes              ?           yes
-DaVinci eMAIL client          yes*             ?           yes*
-Lotus cc:Mail Client           no             no            no
-Lotus Notes mail client        no             no             ?
-Microsoft Mail client          no             no            no
-Microsoft Exchange client     yes+            no           yes&
-Netscape                      yes        planned%          yes
-
-Notes:
-(-) Announced early 1996: target delivery: 4th quarter 1996.
-(=) CE plans to rename the successor to their current client
-    QuickMail LAN, while introducing both a free and a commercial
-    POP3 client, then upgrade the commercial POP3 client to also
-    support IMAP.
-(*) DaVinci SMTP eMAIL: I'm not sure if this is different from
-    the normal DaVinci client.
-(+) Requires Internet Mail Client for Exhange, downloadable from
-    http://www.windows.microsoft.com or included in "Microsoft Plus".
-(&) qp/base64
-(%) Planned for Netscape 4.0
-
-
-
-   
-     _________________________________________________________________
-   
-List of Implementations
-
-
-
-Prot   Computer   Implementation      End  MIME Source
------- ---------- ------------------- ---- ---- -------------------------------
-DMSP   PC         pc-epsilon (3.1)    clnt ?    allspice.lcs.mit.edu
-DMSP   PC         pc-netmail (3.1)    clnt ?    allspice.lcs.mit.edu
-DMSP   PC         pc-reader           clnt ?    allspice.lcs.mit.edu
-DMSP   Unix       Pcmail 3.1 reposit. srvr na   allspice.lcs.mit.edu
-DMSP   Unix/EMACS Pcmail 4.2          clnt ?    allspice.lcs.mit.edu
-DMSP   PC         PC/TCP 2.3          clnt ?    FTP Software 8/4/94
-DMSP   OS/2       PC/TCP              clnt ?    FTP Software
-DMSP   OS/2       TCP/2               clnt ?    Essex Systems
-DMSP   OS/2       TCP/2 SERVER PACK   srvr na   Essex Systems
-DMSP   OS/2       TCP/2 ADV CLIENT    clnt ?    Essex Systems
-IMAP1  MacOS      MacMS 2.2.1 (obs)   clnt no   sumex-aim.stanford.edu* 7/13/95
-IMAP24 MacOS      Mailstrom 1.04      clnt no   sumex-aim.stanford.edu* 11/7/93
-IMAP24 MacOS      Mailstrom 1.05      clnt no   ftp-camis.stanford.edu 5/21/96
-IMAP24 MacOS      Mailstrom 2(beta)   clnt yes  Tree Star Inc. 12/18/96
-IMAP?  MacOS      Mailstrom           clnt ?    lindy.stanford.edu 9/22/95
-IMAP?  MacOS      Mulberry (beta)     clnt no   mulberry@dial.pipex.com 7/30/96
-IMAP?  MacOS      Mulberry 1.1        clnt ?    CyDaSoft 12/19/96
-IMAPb4 Mac/OT     SIMEON 4.1          clnt yes  ESYS Corp www.esys.ca 8/5/96
-IMAPb4 MacOS      SIMEON 4.1          clnt yes  ESYS Corp www.esys.ca 8/5/96
-IMAPb4 MS-WIN     SIMEON 4.1          clnt yes  ESYS Corp www.esys.ca 8/5/96
-IMAPb4 WIN32      SIMEON 4.1          clnt yes  ESYS Corp www.esys.ca 8/5/96
-IMAPb4 Unix/Motif SIMEON 4.1          clnt yes  ESYS Corp www.esys.ca 8/5/96
-IMAP4  ?          SIMEON SERVER       srvr ?    ESYS Corp www.esys.ca 8/1/96
-IMAP2  MacOS      PathWay             clnt no   The Wollongong Group 2/25/94
-IMAP2  Unix/X     PathWay             clnt no   The Wollongong Group 2/25/94
-POP3   MacOS      PathWay             clnt no   The Wollongong Group 2/25/94
-POP3   Unix/X     PathWay             clnt no   The Wollongong Group 2/25/94
-POP3   OS/2       ? (in testing)      srvr no   kf5mg@computek.net 11/28/95
-POP2   MacOS      MacPOP 1.5          clnt ?    ? 10/24/94
-POP2   MS-DOS     PC POP 2.1          clnt ?    ? 10/24/94
-POP3   MacOS      TCP/Connect II      clnt ?    InterCon Systems Corp
-POP3   MS-WIN     TCP/Connect II f W  clnt yes  InterCon Systems Corp 7/8/94
-POP3   NeXT       EasyMail            clnt yes  ftp.cac.washington.edu 11/7/93
-IMAP2  NeXT       MailManager         srvr yes  ftp.cac.washington.edu 11/7/93
-IMAP2  TOPS20     MAPSER              srvr na   ? 11/7/93
-IMAP2  Unix       imap kit            srvr na   ftp.cac.washington.edu 2/1/94
-POP23  Unix       imap kit            srvr na   ftp.cac.washington.edu 2/1/94
-POP23  Unix       IPOP                srvr na   ftp.cac.washington.edu 2/23/96
-IMAP4  Unix       imap4 kit (alpha)   srvr na   ftp.cac.washington.edu 5/31/95
-IMAP24 Unix       Pine 3.90           clnt yes  ftp.cac.washington.edu 9/23/94
-IMAP24 Unix       Pine 3.91           clnt yes  ftp.cac.washington.edu 10/14/94
-IMAP2b Unix       Pine 3.95           clnt yes  ftp.cac.washington.edu 7/30/96
-IMAP24 Unix       Pine 4.0 (future)   clnt yes  ftp.cac.washington.edu 7/30/96
-IMAP24 MS-DOSl+   PC-Pine 3.90        clnt yes  ftp.cac.washington.edu 9/23/94
-IMAP24 MS-DOSl+   PC-Pine 3.91        clnt yes  ftp.cac.washington.edu 10/14/94
-POP23r Unix       popclient x.x (rep) clnt no   Renamed 'fetchmail' 10/7/96
-IMAPb4 Unix       popclient x.x (rep) clnt no   Renamed 'fetchmail' 10/7/96
-POP23r Unix       fetchmail 2.0       clnt no   www.ccil.org/~esr 11/19/96
-IMAPb4 Unix       fetchmail 2.0       clnt no   www.ccil.org/~esr 11/19/96
-POP23r Unix       fetchmail 2.2       clnt no   www.ccil.org/~esr 12/10/96
-IMAPb4 Unix       fetchmail 2.2       clnt no   www.ccil.org/~esr 12/10/96
-POP23r Unix       fetchmail 2.3       clnt no   www.ccil.org/~esr 12/18/96
-POP3k  Unix       fetchmail 2.3       clnt no   www.ccil.org/~esr 12/18/96
-IMAPb4 Unix       fetchmail 2.3       clnt no   www.ccil.org/~esr 12/18/96
-POP23r Unix       fetchmail 2.6       clnt no   www.ccil.org/~esr 12/18/96
-POP3k  Unix       fetchmail 2.6       clnt no   www.ccil.org/~esr 12/18/96
-IMAPb4 Unix       fetchmail 2.6       clnt no   www.ccil.org/~esr 12/18/96
-POP23r Unix       fetchmail 3.3       clnt no   www.ccil.org/~esr 2/4/97
-POP3k  Unix       fetchmail 3.3       clnt no   www.ccil.org/~esr 2/4/97
-IMAPb4 Unix       fetchmail 3.3       clnt no   www.ccil.org/~esr 2/4/97
-POP?   Unix       gwpop               clnt ?    ftp.pasteur.fr 2/9/96
-POP?   Unix       popc                clnt ?    ftp.imag.fr 2/9/96
-POP?   Unix       popmail             clnt ?    ftp.cic.net 2/9/96
-POP?   Unix       movemail            clnt ?    GNU 2/9/96
-IMAP2  VMS        Pine 3.88 port      clnt yes  vms.huji.ac.il 4/12/94
-IMAP?  VMS        Pine in PMDF 4.3    clnt ?    Innosoft 4/1/94
-IMAP2  VMS        ImapD port          srvr yes  vms.huji.ac.il 4/12/94
-POP3u  Win3/95/NT Navigator 2.x       clnt yes  Netscape 7/29/96
-IMAP?  Windows?   pcMail (future)     clnt ?    OzMail 3/19/96
-POP?   Solaris    Navigator 3.0b4(fut)clnt ?    Netscape 6/25/96
-IMAP4  ?          Navigator 4.0 (fut) clnt yes  Netscape 7/30/96
-IMAP4  MacOS      Navigator 4.0 (fut) clnt yes  Netscape 12/18/96
-POP3   Macintosh6 Eudora 1.3.1        clnt no   ftp.qualcomm.com 7/14/94
-POP3   Mac7/PM7   Eudora 1.5.3        clnt yes  ftp.qualcomm.com 8/4/95
-POP3mr Macintosh7 Eudora 2.0.2        clnt yes  Qualcomm 5/10/94
-POP3mr Mac7/PM7   Eudora 2.0.3        clnt yes  Qualcomm 9/13/94
-POP3mrkMac7/PM7   Eudora 2.1          clnt yes  Qualcomm 9/13/94
-POP3mrkMac7/PM7   Eudora 2.1.1        clnt yes  Qualcomm 8/4/95
-POP3mrkMac7/PM7   Eudora 2.1.2        clnt yes  Qualcomm 8/4/95
-POP3mrkMac7/PM7   Eudora 2.1.3        clnt yes  Qualcomm 8/4/95
-POP3   MS-WINw    Eudora 1.4.4        clnt yes  ftp.qualcomm.com 6/23/95
-POP3   MS-WINw    Eudora 1.5.2b1      clnt yes  ftp.qualcomm.com 8/4/95
-POP3   MS-WINw    Eudora 2.0.3        clnt yes  Qualcomm 9/13/94
-POP3   MS-WINw    Eudora 2.1.1        clnt yes  Qualcomm 8/4/95
-POP3   WIN32      Eudora Pro 2.2b8    clnt yes  Qualcomm 12/5/95
-POP3   WIN3/95/NT Eudora Pro ?        clnt yes  Qualcomm 7/29/96
-POP3   Mac        Eudora Pro 3.0      clnt yes  Qualcomm 8/14/96
-POP3   OS/2       PMMail 11           clnt yes  hobbes.nmsu.edu 6/2/95
-POP3   OS/2       POP3D 12            srvr yes  hobbes.nmsu.edu 6/2/95
-POP3   OS/2       POP3D 14A           srvr yes  hobbes.nmsu.edu 9/12/95
-POP3   OS/2       POP3D 14B           srvr yes  hobbes.nmsu.edu 4/5/96
-POP?   OS/2       popsrv99.zip        srvr ?    hobbes.nmsu.edu 2/15/96
-POP3r  OS/2       popsrv10.zip        srvr na   ftp-os2.mnsu.edu 3/15/96
-POP3   MS-WIN     Mi'Mail             clnt yes  http://www.irisoft.be 6/30/95
-
-IMAP2b Unix/XM    ML 1.3.1            clnt yes  ftp-camis.stanford.edu 7/13/95
-IMAP24 Unix/XM    ML 2.0 (future)     clnt yes  Stanford 7/13/95
-IMAP1  Unix       imapd 3.2 (obs)     srvr na   ftp-camis.stanford.edu 7/13/95
-IMAP2b Unix       imapd 3.4/UW        srvr ?    ftp.cac.washington.edu 12/13/94
-IMAP2b Unix       imapd 3.5/UW        srvr ?    ftp.cac.washington.edu 4/25/95
-IMAP2b Unix       imapd 3.6.BETA      srvr ?    ftp.cac.washington.edu 4/25/95
-IMAP2b Unix       imapd 4.0/UW (fut)  srvr ?    U Wash 4/25/95
-IMAP?  Unix       imapd 8.0(124)      srvr ?    U Wash 1/31/97
-IMAP?  Unix       imapd 9.0(161)      srvr ?    U Wash 1/31/97
-IMAP4  ?          imap-4              srvr yes  ftp.cac.washington.edu 10/25/96
-POP3u  ?          imap-4              srvr na   ftp.cac.washington.edu 10/25/96
-IMAP4  ?          imap-4.1 ALPHA      srvr yes  ftp.cac.washington.edu 10/25/96
-POP3u  ?          imap-4.1 ALPHA      srvr na   ftp.cac.washington.edu 10/25/96
-IMAP?  Unix/X     Palm (in dev)       clnt ?    UMiami 11/7/93
-IMAP?  Unix/X     Cyrus (dev on hold) clnt yes  CMU 10/4/94
-IMAP   Unix       Cyrus 1.4           srvr yes  ftp.andrew.cmu.edu 12/1/95
-POP3   Unix       Cyrus 1.4           srvr na   ftp.andrew.cmu.edu 12/1/95
-KPOP   Unix       Cyrus 1.4           srvr na   ftp.andrew.cmu.edu 12/1/95
-POP3u  Unix       Cyrus ?             srvr na   3/12/96
-IMAP41 Unix       Cyrus 1.5           srvr yes  ftp.andrew.cmu.edu 1/3/97
-POP3k  Unix       Cyrus 1.5           srvr na   ftp.andrew.cmu.edu 1/3/97
-KPOP   Unix       Cyrus 1.5           srvr na   ftp.andrew.cmu.edu 1/3/97
-IMAP4  ?          Futr Andrew Msg Sys ?    ?    Carnegie-Mellon 9/20/94
-IMAP?  Xrx Lsp Mc Yes-Way             clnt yes  Stanford U 11/7/93
-IMAP2b MacOS      ECSMail             clnt yes  ESYS Corp www.esys.ca 12/16/96
-IMAP2b MS-WINw    ECSMail             clnt yes  ESYS Corp www.esys.ca 12/16/96
-IMAP2  Unix/XM    ECSMail Motif       clnt yes  ESYS Corp www.esys.ca 12/16/96
-IMAP2b Solaris    ECSMail             clnt yes  ESYS Corp www.esys.ca 12/16/96
-IMAP2  MS-DOS     ECSMail DOS         clnt yes  ESYS Corp www.esys.ca 12/16/96
-IMAP?  NT         ECSMail             clnt yes  ESYS Corp www.esys.ca 12/16/96
-IMAP?  OS/2       ECSMail OS/2        clnt yes  ESYS Corp www.esys.ca 12/16/96
-IMAP?  Unix       UMAIL               clnt no   umail@umail.umd.edu 11/7/93
-IMAP?  Unix       MS                  clnt no   ftp.cac.washington.edu 11/7/93
-IMAP2  MS-WIN     PathWay             clnt no   The Wollongong Group 2/25/94
-POP3   MS-WIN     PathWay             clnt no   The Wollongong Group 2/25/94
-POP?   MS-WIN     PathWay Access 3.0  clnt ?    The Wollongong Group 8/4/94
-POP3   NT         sendmail/POP3 (bet) srvr na   www.metainfo.com 9/15/95
-POP3   NT         sendmail/POP3       srvr na   emwac.ed.ac.uk 12/5/95 (www.emw
-ac.ed.ac.uk)
-IMAP4  NT         sendmail/POP3 (fut) srvr ?    emwac.ed.ac.uk 5/21/96 (www.emw
-ac.ed.ac.uk)
-IMAP2  Amiga      Pine 3.8x (in dev)  clnt yes  UWashington 11/7/93
-POP    MacOS      POPmail 1.7         clnt ?    boombox.micro.umn.edu 9/1/95
-POP23  MacOS      POPmail 2.09b       clnt ?    boombox.micro.umn.edu 9/1/95
-IMAP2  MacOS      POPmail 2.09b       clnt ?    boombox.micro.umn.edu 9/1/95
-POP23  MacOS      POPmail 2.2         clnt ?    boombox.micro.umn.edu 9/1/95
-IMAP2  MacOS      POPmail 2.2         clnt ?    boombox.micro.umn.edu 9/1/95
-POP3   MacOS      POPmail/Lab         clnt ?    boombox.micro.umn.edu 9/1/95
-POP    NeXT OS    BlitzMail           srvr na   ftp.dartmouth.edu 10/23/95
-POP    DEC OSF/1  BlitzMail           srvr na   ftp.dartmouth.edu 10/23/95
-POP    AIX        BlitzMail (in dev)  srvr na   ftp.dartmouth.edu 10/23/95
-POP3   MS-WINw5   POPmail/Lab         clnt ?    boombox.micro.umn.edu 9/1/95
-POP3   MacOS      Emailer 1.1         clnt yes  Claris 7/29/96
-POP3   MacOS      OfficeMail          srvr na   Claris 6/6/96
-IMAP2b Unix       imapperl-0.6        clnt ?    dnpap.et.tudelft.nl 2/6/96
-POP2   MacOS      MailStop 1.1.3      srvr na   boombox.micro.umn.edu 1/18/94
-POP3r  MacOS      MailShare 1.0(beta) srvr na   glenn.anderson@stonebow.otago.a
-c.nz 8/16/94
-POP3r  MacOS      MailShare 1.0fc6    srvr na   ftp.qualcomm.com 8/4/95
-POP3r  MacOS      AIMS 1.0            srvr na   Apple 10/27/95
-POP3r  MacOS      AIMS 1.1            srvr na   Apple 5/21/96 (www.cybertech.ap
-ple.com)
-POP3r  MacOS      AIMS 1.1.1          srvr na   Apple 10/17/96
-POP3r  MacOS      AIMS 2.0 (fut: '97) srvr ?    Apple 10/17/96
-POP3r  MacOS      AIMS 2.1 (fut)      srvr ?    Apple 10/17/96
-IMAP   MacOS      AIMS 2.1 (fut)      srvr ?    Apple 10/17/96
-POP3   MacOS      POPGate 1.1         gway ?    Stalker 3/25/96 (www.stalker.co
-m)
-IMAP?  MacOS      MailDrop 1.1        clnt ?    ackmo.baylor.edu 3/22/96
-IMAP2? MacOS      MailDrop 1.2d6a     clnt ?    ackmo.baylor.edu 3/22/96
-IMAP?  MacOS      MailDrop 2 (dev)    clnt ?    Baylor 1/19/96
-POP2   MS-DOS     LifeLine Mail 2.0   clnt ?    SunSelect 12/7/93
-POP23  MS-DOS     SelectMail 2.1      clnt ?    SunSelect 1/25/94
-POP2   MS-DOSk    ?                   srvr na   ucsd.edu
-POP2   MS-DOSk    net091b             srvr na   boombox.micro.umn.edu 12/3/93
-POP3   MS-DOSk    pop3nos v1.86       srvr na   boombox.micro.umn.edu 12/3/93
-POP2   MS-DOSp    POPMail 3.2.2       clnt ?    boombox.micro.umn.edu 9/1/95
-IMAP?  MS-DOSp    POPMail/PC 3.2.2    clnt ?    boombox.micro.umn.edu 1/11/94
-POP2   MS-DOSp    POPMail 3.2.3 beta2 clnt ?    boombox.micro.umn.edu 9/1/95
-IMAP?  MS-DOSp    POPMail 3.2.3 beta2 clnt ?    boombox.micro.umn.edu 9/1/95
-POP3   MS-DOSk    pop3serv            srvr na   biochemistry.crwu.edu
-POP3   MS-DOSk    nos11c-a.exe        srvr na   biochemistry.bioc.cwru.edu 9/16
-/94
-POP2   MS-DOS     MD/DOS-IP           clnt ?    U Maryland
-POP2   MS-DOS     PC/TCP              clnt ?    FTP Software
-POP2   OS/2       PC/TCP for OS/2     clnt ?    FTP Software 11/2/93
-POP23  MS-WIN     BW-Connect          clnt no   Beame & Whiteside 8/4/94
-POP3   MS-WIN     Air Series 2.06     clnt no   Spry 7/7/94
-IMAP?  MS-WIN     Air Mail            ?    ?    AIR Co. Ltd 9/20/94
-IMAP?  MS-WIN     EMBLA               ?    ?    ICL ProSystems 9/20/94
-IMAP4  ?          Intrnt Msging Srvr  srvr ?    ICL TeamWare 9/8/1
-POP3   ?          Intrnt Msging Srvr  srvr ?    ICL TeamWare 9/8/1
-POP23  MS-DOSp    Minuet 1.0b18a(beta)clnt no   minuet.micro.umn.edu 9/1/95
-POP?   MS-WINls   TCPMail             clnt ?    Pinesoft (pinesoft@net.com)
-POP2   Unix       U Minn popd 1.5c    srvr na   boombox.micro.umn.edu 11/19/93
-POP2   Unix/AIX   aix_new_popd        srvr na   boombox.micro.umn.edu 9/1/95
-POP2   Unix/HP9k  hp9000_popd         srvr na   boombox.micro.umn.edu 9/1/95
-POP23  MS-WINw    POPmail             clnt ?    boombox.micro.umn.edu 9/1/95
-IMAP2  MS-WINw    POPmail             clnt ?    boombox.micro.umn.edu 9/1/95
-POP2   Unix       USC-ISI popd        srvr na   ? 10/24/94
-POP2   Unix       imapd/ipop2d 3.4    srvr na   ftp.cac.washington.edu 12/13/94
-POP3   Unix/curs  Z-Mail Lite 3.2     clnt yes  NetManage 8/23/96 www.netmanage
-.com
-POP3   Unix/line  Z-Mail Lite 3.2     clnt yes  NetManage 8/23/96 www.netmanage
-.com
-POP3   Unix/XM    Z-Mail Motif 3.2.1  clnt yes  NetManage 8/23/96 www.netmanage
-.com
-POP3   WIN3/95/NT Z-Mail 4.0.1        clnt yes  NetManage 8/23/96 www.netmanage
-.com
-POP3   MacOS      Z-Mail 3.3.1        clnt yes  NetManage 8/23/96 www.netmanage
-.com
-IMAP4  WIN3/95/NT Z-Mail Pro          clnt yes  NetManage 8/23/96 www.netmanage
-.com
-IMAP4  WIN3/95/NT Z-Mail Pro 6.0      clnt yes  NetManage 1/31/97 www.netmanage
-.com
-IMAP?  MacOS      Z-Mail ?            clnt yes  NetManage 5/21/96
-POP?   Unix       zync ?              clnt ?    NCD 9/23/94 (www.ncd.com)
-POP23k UnixX      xmh                 clnt ?    ftp.x.org 2/15/94
-POP23k UnixX      exmh                clnt yes  ? 8/8/95
-POP23k UnixX      dxmail/mh           clnt ?    DEC
-POP?   Unix       ucbmail clone       clnt ?    rtfm.mit.edu 12/16/94
-POP?   Unix       pop-perl-1.0        clnt ?    sunsite.unc.edu 9/13/94
-POP?   Unix/XO    SXMail 0.9.74a (b)  clnt ?    ftp.uni-stuttgart.de 10/12/95
-POP2   VM         FAL                 srvr na   IBM
-POP2   MS-WIN     IBM TCP/IP for DOS  clnt no   IBM 7/7/94
-POP2   VM         ?                   srvr na   Texas Tech University
-POP?   VM         ?POPD               srvr na   vmd.cso.uiuc.edu 2/4/94
-POP3   VM         vmpop3.200          srvr na   uriacc.uri.edu 1/10/95
-POP3   MUSIC/SP   POPD 1.0            srvr na   McGill Univ. Sys. Inc. 01/11/95
-POP2   OS/2       TCP/2 SERVER PACK   srvr na   Essex Systems
-POP2   VMS        MultiNet            srvr na   TGV, Inc. 07/26/95
-POP2   HP3000/MPE NetMail/3000        srvr na   3K Associates
-POP3   ?          NetMail/3000        srvr na   3K Associates
-POP3k  MacOS      Eudora 1.3a8k       clnt ?    ftp.brown.edu 8/19/94
-POP3   MacOS      MacPOP (Berkeley)   clnt ?    ftp.cc.berkeley.edu
-POP3k  MacOS      TechMail 2.0        clnt ?    net-dist.mit.edu
-POP3   MacOS      MacMH               clnt ?    jessica.stanford.edu/info
-POP3   MacOS      VersaTerm Link      clnt ?    Synergy Software 10/8/93
-POP3   MacOS      LeeMail 2.0.2 (shw) clnt ?    chs.cusd.claremont.edu 10/12/93
-POP3   Mac7pro    Mail*Link Internet  clnt yes  StarNine Technologies 2/18/94
-POP3t  Unix       popper-1.7          srvr na   ftp.cc.berkeley.edu 10/15/93
-POP3k  Unix       popper-1.7k         srvr na   ftp.brown.edu 10/19/94
-POP3k  Unix       hacked ucbmail      clnt no   UCSC 6/29/95
-POP3k  Unix       hacked pine         clnt yes  UCSC 6/29/95
-POP3   Unix       popper-1.831        srvr na   ftp.cc.berkeley.edu 11/3/93
-POP3   Solaris2.X popper-1.831/uore   srvr na   ftp.uoregon.edu 10/19/93
-POP3   Solaris2.X popper-1.9          srvr na   ftp.chalmers.se 7/26/94
-POP3   Unix       popperQC3           srvr na   ftp.qualcomm.com 8/4/95
-POP3   Unix       qpopper 2.1.3-r5    srvr na   ftp.qualcomm.com 8/4/95
-POP3   Unix       qpopper 2.1.4-r1    srvr na   ftp.qualcomm.com 8/4/95
-POP3u  Unix       qpopper 2.1.4-r3    srvr na   ftp.qualcomm.com 2/26/96
-POP3u  Unix       qpopper 2.1.4-r4    srvr na   QualComm 5/16/95
-POP3r  Unix       Vers of qpopper     srvr na   QualComm 1/26/96
-POP3u  Unix       qpopper 2.2 beta    srvr na   Qualcomm 2/26/96
-POP?   Unix       zpop                srvr na   NCD 9/1/95
-POP3   Unix       popper.rs2          srvr na   ftp.qualcomm.com 8/4/95
-POP3   Unix       perl popper         srvr na   ftp.xensei.com/users/ccrlphr 9/
-1/95
-POP23k Unix       mh-6.8 (UCI RandMH) both yes  ftp.ics.uci.edu 8/30/94
-POP23krUnix       mh-6.8.3 (UCI RndMH)both yes  ftp.ics.uci.edu 9/27/94
-POP23  Unix/EMACS RMAIL               clnt no   ? 8/2/95
-POP23  Unix/EMACS vm                  clnt no   ftp.uu.net 8/2/95
-POP3   Linux      miniclient          clnt ?    sunsite.unc.edu 8/30/94
-POP3   Unix       imapd/ipop3d 3.4    srvr na   ftp.cac.washington.edu 12/13/94
-POP3   Unix       pop3d 1.004         srvr na   ftp.ucdavis.edu 12/3/93
-POP2   Unix       pop2d 1.001         srvr na   ftp.ucdavis.edu 12/3/93
-POP3   Unix       mush 7.2.5          clnt ?    ? 12/16/94
-POP23k Unix       popmaild            srvr na   ftp.wu-wien.ac.at 4/5/95
-IMAP   AIX        imap server         srvr ?    ftp.wu-wien.ac.at 4/5/95
-POP3   MacOS/AOCE MailConnect         clnt yes  ? 7/5/95
-POP3t  MS-DOSnpo  PC/TCP              clnt ?    FTP Software
-POP3   OS/2       PC/TCP for OS/2     clnt ?    FTP Software 11/2/93
-POP3   MS-DOS     TechMail(future)    clnt ?    ?
-POP3   MS-WINl    TechMail for Wind.  clnt ?    net-dist.mit.edu 2/25/94
-POP3   OS/2l      TechMail for Wind.  clnt ?    net-dist.mit.edu 2/25/94
-POP3   MS-DOSp    NUPop 1.03          clnt no   ftp.acns.nwu.edu 11/5/93
-POP3   MS-DOSp    NUPop 2.02          clnt no   ftp.acns.nwu.edu 1/18/94
-POP3   MS-DOSp    NUPop 2.10 (alpha)  clnt yes  ftp.acns.nwu.edu 6/10/94
-POP23  MS-WINw    Trumpet             clnt no   ftp.psychol.utas.edu.au 7/7/94
-POP3   MS-WIN     Pceudora            clnt ?    ftp.qualcomm.com 9/24/93
-POP3   MS-WINw    WinPmail 2.0b4      clnt ?    risc.ua.edu 6/6/95
-POP3   MS-DOSp    POPgate (Pmail gw)  clnt ?    risc.ua.edu 4/1/94
-POP3   MS-DOSl    PMPOP (Pmail gw)    clnt ?    risc.ua.edu 4/1/94
-POP3x  MS-WIN     WinQVT (2.1)        clnt ?    QPC Software (shareware) 7/12/9
-4
-POP3   MS-WINp    wnqvtnet 3.0        clnt ?    ftp.cica.indiana.edu
-POP3   MS-WINp    wnqvtnet 3.9        clnt ?    ftp.cica.indiana.edu 2/1/94
-POP3   MS-WIN     Open Systems Mail   clnt ?    Pine Software
-POP3   MS-WIN?    IMAIL               both ?    Ipswitch 7/12/94
-POP3   NT         Ipswitch            srvr ?    Ipswitch 5/24/96
-POP3   VMS        IUPOP3 v1.7         srvr na   ftp.indiana.edu 7/25/94
-POP3   VMS        IUPOP3 v1.7-CMU-TEK srvr na   ftp.indiana.edu 7/25/94
-POP3   VMS        IUPOP3 v1.8-1       srvr na   ftp.indiana.edu 7/25/94
-POP3   MS-DOS     POP3 0.9            clnt na   ftp.indiana.edu 7/25/94
-POP3   VMS        MultiNet            both ?    TGV, Inc. 07/26/95
-POP3   VMS        PMDF 5.1            srvr na   Innosoft 9/24/96 www.innosoft.c
-om
-POP3   Solaris    PMDF 5.1            srvr na   Innosoft 9/24/96 www.innosoft.c
-om
-POP3   DigUNIX    PMDF 5.1            srvr na   Innosoft 9/24/96 www.innosoft.c
-om
-POP3   OpenVMS    PMDF 5.1            srvr na   Innosoft 9/24/96 www.innosoft.c
-om
-IMAP?  VMS        PMDF 5.1            srvr ?    Innosoft 9/24/96 www.innosoft.c
-om
-IMAP?  Solaris    PMDF 5.1            srvr ?    Innosoft 9/24/96 www.innosoft.c
-om
-IMAP?  DigUNIX    PMDF 5.1            srvr ?    Innosoft 9/24/96 www.innosoft.c
-om
-IMAP?  OpenVMS    PMDF 5.1            srvr ?    Innosoft 9/24/96 www.innosoft.c
-om
-IMAP?  MS-DOS     PMDF E-mail Interc  clnt ?    Innosoft 3/2/94 www.innosoft.co
-m
-IMAP?  MacOS      PMDF E-mail Interc  clnt ?    Innosoft 3/2/94 www.innosoft.co
-m
-POP?   VMS        PMDF E-mail Interc  ?    ?    Innosoft 6/24/96 www.innosoft.c
-om
-IMAP?  VMS        PMDF E-mail Interc  ?    ?    Innosoft 6/24/96 www.innosoft.c
-om
-POP3r  VMS        PMDF popstore       clnt ?    Innosoft 9/24/96 www.innosoft.c
-om
-IMAP4  SolarisX   Roam (Future)       clnt ?    Sun 9/26/95
-IMAP?  Windows?   Roam (Future)       clnt ?    Sun 3/19/96
-IMAP4  SolarisX   imapd (Future)      clnt ?    Sun 9/26/95
-IMAP4  Solaris    Solstice IMS1.0     srvr yes  SunSoft 10/17/96 http://www.sun
-.com
-POP3   Solaris    Solstice IMS1.0     srvr yes  SunSoft 10/17/96 http://www.sun
-.com
-
-IMAP4  Solaris    Solstice IMS2.0 (f) srvr yes  SunSoft 10/17/96 http://www.sun
-.com
-POP3   Solaris    Solstice IMS2.0 (f) srvr yes  SunSoft 10/17/96 http://www.sun
-.com
-IMAP4  Solaris    Solstice IMC0.9     clnt yes  SunSoft 4/5/96 http://www.sun.c
-om
-IMAP4  Solaris    Solstice IMC? (fut) clnt yes  SunSoft 4/5/96 http://www.sun.c
-om
-IMAP4  MS-WIN3.11 Solstice IMC0.9     clnt yes  SunSoft 4/5/96 http://www.sun.c
-om
-IMAP4  MS-WIN3.11 Solstice IMC? (fut) clnt yes  SunSoft 4/5/96 http://www.sun.c
-om
-IMAP4  MS-WIN95   Solstice IMC0.9     clnt yes  SunSoft 4/5/96 http://www.sun.c
-om
-IMAP4  MS-WIN95   Solstice IMC? (fut) clnt yes  SunSoft 4/5/96 http://www.sun.c
-om
-IMAP4  NT         Solstice IMC0.9     clnt yes  SunSoft 4/5/96 http://www.sun.c
-om
-IMAP4  NT         Solstice IMC? (fut) clnt yes  SunSoft 4/5/96 http://www.sun.c
-om
-IMAP4  Win95      SOlstice 2.0        clnt ?    SunSoft 1/31/97
-POP3   OS/2       TCP/2 SERVER PACK   srvr na   Essex Systems
-POP3   OS/2       TCP/2 ADV CLIENT    clnt ?    Essex Systems
-POP?   MS-DOS     UCDmail             clnt ?    ftp.ucdavis.edu 10/24/94
-POP?   MS-DOS     PC POP              clnt ?    ?Bill Schweickert/Sterling Fed
-POP23  MS-WINnpo  Super-TCP for W e.0 clnt yes  Frontier Technologies 6/10/94
-POP?   MS-WINnpo  Super-TCP for W e.0 srvr yes  Frontier Technologies 7/12/94
-POP3   WIN3/95/NT SuperHghwy Access 2 clnt yes  Frontier Technologies 7/29/96
-POP?   MS-WINw    Windows ELM         clnt ?    lister.cc.ic.ac.uk 7/12/94
-IMAP?  ?          ELM patches         clnt ?    www.math.fu-berlin.de/~guckes/e
-lm/patches 7/16/96
-POP23  MS-DOSni   ChameleonNFS        both ?    NetManage 8/4/94
-POP23  MS-DOSni   Chameleon beta      clnt yes  NetManage
-POP23  MS-WINw    Internet Chameleon  clnt yes  NetManage 7/12/94
-POP23  NT         Chameleon V5.0 f NT both ?    NetManage 11/28/95
-IMAP?  Windows?   Chameleon (future)  clnt ?    NetManage 3/19/96
-POP?   MacOS      MEWS                clnt ?    ?
-POP?   MacOS      byupopmail          clnt ?    ?
-POP?   VM         ?                   srvr na   TTUVM1
-POP3   MacOS      HyperMail           ?    ?    ?
-?      OS/2       lamailpop           ?    ?    ftp-so2.cdrom.com
-POP?   OS/2       Popclient           clnt yes  ? 1/19/96
-POP?   OS/2       Emacs 19.xx         clnt yes  ? 1/19/96
-POP3   MS-DOSs    pcelm               clnt ?    lister.cc.ic.ac.uk 1/25/94
-POP3   MS-WINs    winelm              clnt ?    lister.cc.ic.ac.uk 1/25/94
-POP3   NetWare    Mercury 1.11        srvr na   risc.ua.edu 2/4/94
-POP3   NetWare34  Mercury 1.2.1       srvr na   risc.ua.edu 3/29/96
-POP3   NetWare34  Mercury 1.3         srvr na   risc.ua.edu 8/2/96
-POP3   MS-WINw    IMail               srvr na   Ipswitch 7/15/94
-POP3   MS-Windows Pegasus/Win 2.3     clnt ?    risc.ua.edu 6/6/96
-POP3   MS-Windows Pegasus/Win 2.2(r3) clnt ?    risc.ua.edu 6/6/96
-POP3   MS-Windows Pegasus/Win 2.0(r1) clnt ?    risc.ua.edu 6/6/96
-POP3   MS-DOS     Pegasus/DOS 3.2(r2) clnt ?    risc.ua.edu 6/6/96
-POP3   MacOS      Pegasus/MAC 2.1.2   clnt ?    risc.ua.edu 6/6/96
-POP23  MS-WINw    Mail-IT 2           clnt yes  mail-it@unipalm.co.uk 7/12/94
-POP23  Unix       Mail-IT 2           clnt yes  mail-it@unipalm.co.uk 9/9/94
-POP23  Unix       servers w Mail-IT   srvr na   mail-it@unipalm.co.uk 12/16/94
-POP?   MS-WIN     RFD Mail 1.22       clnt ?    ftp.std.com 7/19/94
-POP?   MS-WIN     RFD Mail 1.23       clnt ?    ftp.std.com 9/16/94
-POP3   MS-WINw    ws_gmail            srvr na   buckshot.usma.edu 9/16/94
-POP3   MS-WINw    IMAIL               srvr na   Ipswitch 9/16/94
-POP3   MS-WINw    Pronto Mail 2.01    clnt yes  Commtouch 4/24/96 (www.commtouc
-h.com)
-IMAP   MS-WINw    Pronto              clnt yes  Commtouch 9/5/95
-IMAP4  ?          Pronto97            clnt yes  CommTouch 1/7/97 (www.commtouch
-.com)
-POP3   ?          Pronto97            clnt yes  CommTouch 1/7/97 (www.commtouch
-.com)
-POP23  MS-WINw    Turnpike            clnt yes  Turnpike Ltd, http:www.turnpike
-.com 8/11/95
-POP3   MS-WIN     WinSmtp             srvr na   Seattle Labs, http://wildside.k
-wnet.on.ca/winsmtp.html 11/3/95
-POP3r  WIN95      SLmail95            srvr na   http://www.seattlelab.com/ 5/14
-/96
-POP3r  NT         SLmailNT            srvr na   http://www.seattlelab.com/ 3/29
-/96
-POP3   ?          VA Professional     clnt yes  Ashmount 4/30/96 http://www.asn
-mount.com
-POP3   ?          VA Workgroup        clnt yes  Ashmount 4/30/96 http://www.asn
-mount.com
-POP3   NT         post.office         srvr na   Software.com, Inc. 12/11/95 (ww
-w.software.com)
-POP3   Solaris    post.office         srvr na   Software.com, Inc. 12/11/95 (ww
-w.software.com)
-POP?   MS-?       Exchange            clnt ?    Microsoft 10/24/95
-POP3   MS-?       Exchange Server (f) srvr yes  Microsoft 9/11/96
-IMAP4  MS-?       Exch Server (maybe) srvr ?    Microsoft 6/21/96
-POP3   MS-?       Exchange Server 5.0 srvr ?    Microsoft 1/14/97
-POP3   MS-?       Inter. Mail & News  clnt yes  Microsoft 6/4/96 (www.microsoft
-.com)
-POP3   MS-?       Inter. Mail Service gway ?    Microsoft 6/4/96 (www.microsoft
-.com)
-POP3u  NT         Exchpop(?) 1.0      gway yes  http://www.sts.co.il/pop3.htm 6
-/14/96
-POP3   MacOS      Powertalk           ?    ?    ? 11/7/95
-IMAP2  MS-WIN     Siren Mail          clnt yes  Siren Software 12/28/95
-IMAP?  Windows?   Siren Mail 3.0      clnt yes  Siren Software 3/19/96
-POP3   MS-WIN     Siren Mail          clnt yes  Siren Software 12/28/95
-IMAP2  WIN95      Siren Mail          clnt yes  Siren Software 12/28/95
-POP3   WIN95      Siren Mail          clnt yes  Siren Software 12/28/95
-IMAP2  NTclient   Siren Mail          clnt yes  Siren Software 12/28/95
-POP3   NTclient   Siren Mail          clnt yes  Siren Software 12/28/95
-?      Unix       Siren Mail          srvr ?    Siren Software 12/28/95
-IMAP2  ?          Siren Mail Server   srvr ?    Siren Software 8/1/96
-POP3   ?          Siren Mail Server   srvr ?    Siren Software 8/1/96
-IMAP4  ?          Siren Mail (future) clnt yes  Siren Software 12/28/95
-IMAP?  MacOS      Siren Mail (future) clnt yes  Siren Software 1/21/96
-IMAP?  WIN95      Siren Mail (beta)   clnt yes  Siren Software 7/30/96
-POP3   MacOS      NetAlly             srvr na   Delphic (www.delphic.com) 11/17
-/95
-POP3   DOSWIN     BeyondMail          clnt yes  Banyan (beyondmail.banyan.com)
-2/6/96
-IMAP4  ?          BeyondMail (future) clnt yes  Banyan (beyondmail.banyan.com)
-9/6/96
-POP?   NT         MailSrv from Res K. srvr na   Microsoft?
-IMAP   WIN?       ?                   clnt ?    Email connection 12/8/95
-POP3   NetWare34  SoftNet WEBserv     srvr na   Puzzle Systems 12/15/95 (info@p
-uzzle.com)
-POP3   NT         Netscape Mail Srvr  srvr na   Netscape 12/18/95 (info@netscap
-e.com)
-POP3   SunOS      Netscape Mail Srvr  srvr na   Netscape 12/18/95 (info@netscap
-e.com)
-POP3   Solaris    Netscape Mail Srvr  srvr na   Netscape 12/18/95 (info@netscap
-e.com)
-IMAP4  NT         Netscape M S 2.0(f) srvr ?    Netscape 6/21/96
-IMAP4  NT         Netscape M S 2.02   srvr ?    Netscape 1/31/97
-POP3   OpenVMS    TCPware Internet Sr srvr na   Process Software 12/20/95 (info
-@process.com)
-POP3   Unix       UMT (beta)          clnt ?    ftp.topaz.kiev.ua 12/29/95 (www
-.topaz.kiev.ua)
-POP3   NetWare 4  LAN WorkGroup 5     ???? na   Novell 1/1/96
-IMAP2  Solaris    MMail               clnt yes  Atelier de Software Ltd. 5/21/9
-6
-IMAP2  MacOS      MMail (planned)     clnt yes  Atelier de Software Ltd. 5/21/9
-6
-POP?   OS/2       Yarn/Souper(?)      clnt ?    ? 1/16/96
-POP3   NT         Sendmail w POP3 1.0 srvr na   MetaInfo 1/19/96 http://www.met
-ainfo.com
-POP3   NT         Sendmail w POP3 1.1 srvr na   MetaInfo 12/4/96 http://www.met
-ainfo.com
-POP3   ?          PopGate             gway na   ftp.esi sys.com 1/19/96
-POP3   OS/2       ? (future)          srvr na   Secant 1/23/96
-?POP3  NT         NT MAIL             ?    ?    http://bhs.com 1/26/96
-POP3   NT         MAILbus Internet    srvr na   Digital 2/20/96 (www.digital.co
-m)
-POP3   DEC UNIX   MAILbus Internet    srvr na   Digital 2/20/96 (www.digital.co
-m)
-POP3r  NT         MAILbus Internet(b) srvr na   Digital 2/20/96 (www.digital.co
-m)
-POP3r  DEC UNIX   MAILbus Internet(b) srvr na   Digital 2/20/96 (www.digital.co
-m)
-POP?   OS/2       lampop(?)           clnt ?    ? 1/26/96
-POP?   NT         NTMail              clnt ?    www.mortimer.com 2/9/96
-POP3   DOSWINMac  OpenMail (future)   clnt ?    HP 3/29/96 http://www.openmail.
-external.hp.com
-IMAP   DOSWINMac  OpenMail (future)   clnt ?    HP 3/29/96 http://www.openmail.
-external.hp.com
-POP3   NetWare4   Connect2SMTP        srvr ?    Infinite Technologies 3/29/96
-POP3   OS/2       PowerWeb Server++   srvr na   CompuSource 4/16/96 http://www.
-compusource.co.za
-POP3   OS/2       SIDIS/2             srvr na   stargate.rz.fh-offenburg.de 6/4
-/96
-POP3   ?          WIG v2.0            gway ?    http://www.demon.co.uk/ 4/19/96
-POP3   WIN95      Windis32            srvr na   Demon Internet 6/6/96 (www.demo
-n.co.uk)
-POP3   DOSWINMac  DaVinci SMTP eMAIL  clnt yes  On Technology 4/24/96
-POP?   WIN32      Mail OnNet (OnNet32)clnt yes  FTP Software 5/3/96 (www.ftp.co
-m)
-POP?   Unix       xfmail              clnt ?    burka.netvision.net.il 5/110/96
-POP3rutOS/2       POP3s v1.01         srvr ?    www.secant.com 5/14/96
-POP3   Java Aplt  Yamp                clnt ?    www.mcs.net/~faisal/Yamp/yampix
-.html 5/24/96
-POP3   NT         NT Mail             gway ?    www.net-shopper.co.uk 5/31/96
-POP3   WIN?       Mailcall            chkr na   ? 6/11/96
-POP3   WIN?       Mailcheck           chkr na   ? 6/11/96
-POP3   DOS        C2SMTP              srvr na   Infinite Technologies 6/11/96
-POP    MacOS      Quarterdeck v4(fut) clnt yes  Starnine 6/11/96 (www.starnine.
-com)
-POP    MacOS      List Star           ?    ?    Starnine 6/24/96 (www.starnine.
-com)
-POP3   MacOS      Marionet 1.0        srvr na   Allegiant 6/12/96 (www.allegian
-t.com)
-POP3   ?          Mailcoach V1.0      srvr na   http://www.multi.se/ymex/mailco
-ach.htm 6/14/96
-IMAP4  WIN3/NT/95 JetMail             clnt yes  NetManage 7/29/96
-POP3   WIN3/NT/95 JetMail             clnt yes  NetManage 7/29/96
-POP3   NT         Post.Office         srvr na   NetManage 8/22/96 www.netmanage
-.com
-POP3   SunOS      Post.Office         srvr na   NetManage 8/22/96 www.netmanage
-.com
-POP3   Solaris    Post.Office         srvr na   NetManage 8/22/96 www.netmanage
-.com
-POP3   Unix       Z-Pop 1.0           srvr na   NetManage 8/22/96 www.netmanage
-.com
-POP3   AppleShare FutureShare (fut)   srvr na   Apple 6/14/96
-POP?   ?          Applixware          ?    ?    Applix 6/24/96
-POP3   Unix       Mail*Hub            srvr ?    CDC 10/23/96 www.cdc.com
-IMAP4  Unix       Mail*Hub            srvr ?    CDC 10/23/96 www.cdc.com
-POP?   Unix       TkRat               clnt ?    www.dtek.chalmers.se/~maf/ratat
-osk 6/24/96
-IMAP?  Unix       TkRat               clnt ?    www.dtek.chalmers.se/~maf/ratat
-osk 6/24/96
-IMAP?  Unix       Elm                 clnt ?    ? 7/1/96
-POP3   WIN16/32   Virtual Access      clnt yes  www.ashmount.com 8/9/96
-POP3   ?          pop-perl5           clnt ?    ? 7/23/96
-POP3   WIN95      Agent               clnt ?    ? 7/23/96
-POP3   ?          Mail eXtension 1.60 clnt ?    Terckland 7/26/96 (ourworld.com
-puserve.com/homepages/mailx)
-POP3   WIN3/95/NT Emissary Office 1.1 clnt yes  Attachmate 7/29/96
-POP3   WIN3/95    Pronto Mail 2.0     clnt yes  CommTouch 7/29/96
-POP3   ?          gcMail 081b (beta)  clnt ?    www.greencedars.com 8/9/96
-POP3r  Java       shareware Java cls  clnt ?    Koehn Consulting 8/2/96
-POP3   ?          cucipop (future)    srvr na   cuci.nl 8/6/96
-POP3   MacOS      QuickMail Pro       clnt ?    CE Software www.cesoft.com 12/1
-9/96
-POP3   ?          QuickMail Pro (fut) clnt ?    CE Software www.cesoft.com 8/9/
-96
-IMAP?  ?          QuickMail Pro (fut) clnt ?    CE Software www.cesoft.com 8/9/
-96
-POP3   ?          QuickMail POP (fut) clnt ?    CE Software www.cesoft.com 8/9/
-96
-POP3   ?          QM-Internet Gateway ?    ?    CE Software 6/24/96
-POP3   ?          Lotus Notes 4.5 srv srvr ?    Lotus 10/17/97
-POP3   Be         BeMail              clnt ?    www.be.com 11/25/96
-POP3   NT         Metainfo/Intergate  srvr na   ? 11/26/96
-POP3   Java       Novita Mail         clnt ?    Novita Comm 12/10/96
-IMAP?  Java       Novita Mail         clnt ?    Novita Comm 12/10/96
-IMAP?  Windows    Winbox 3.1 Beta 1   clnt ?    ftp.uv.es 12/13/96
-POP?   Windows    Winbox 3.1 Beta 1   clnt ?    ftp.uv.es 12/13/96
-POP3   MacOS      Bluto (future)      clnt yes  Bare Bones www.barebones.com 12
-/18/96
-POP3   WIN95/NT   ExpressIT! 2000     clnt ?    Infinite Technologies www.ihub.
-com 1/14/97
-IMAP   WIN95/NT   ExpressIT! 2000     clnt ?    Infinite Technologies www.ihub.
-com 1/14/97
------- ---------- ------------------- ---- ---- -------------------------------
-
-   
-     _________________________________________________________________
-   
-Some other packages for desktop systems
-
-
------- ---------- ------------------- ---- ---- -------------------------------
-?      MS-DOSs    CMM                 peer ?    Cinetic Systems 1/25/94
-?      MS-DOSs    WinMail 1.1a        peer ?    Obsolete
-SMTP   MacOS      LeeMail 1.2.4       peer ?    Shareware, laf@mitre.org
-SMTP   MacOS      LeeMail 2.0.2 (shw) peer ?    chs.cusd.claremont.edu 10/12/93
-SMTP   MS-DOSni   ChameleonNFS        peer ?    NetManage 2/25/94
-SMTP   MS-WINw    ws_gmail            peer ?    buckshot.usma.edu 5/26/94
-uucp   MacOS      FernMail            peer ?    Shareware, dplatt@snulbug.mtvie
-w.ca.us
-prop   MacOS      MacPost             both ?    ftp.lu.se 10/19/93
-uucp   MacOS      Eudora >1.3.1       peer yes  ftp.qualcomm.com 5/10/94
-MAPI   WIN3/95/NT Eudora Pro ?        clnt yes  Qualcomm 7/29/96
-uucp   MacOS      UUPC                peer ?    dplatt@snulbug.mtview.ca.us
-uucp   MacOS      gnuucp              peer ?    jim@fpr.com
-uucp   MS-DOS     waffle              peer ?    ? dell@vox.darkside.com 10/24/9
-4
-uucp   MS-DOS     UUPC                peer ?    ? help@kew.com 10/24/94
-fshare MS-Windows Pegasus/Win 2.3     clnt ?    risc.ua.edu 6/6/96
-fshare MS-Windows Pegasus/Win 2.2(r3) clnt ?    risc.ua.edu 6/6/96
-fshare MS-Windows Pegasus/Win 2.0(r1) clnt ?    risc.ua.edu 6/6/96
-fshare MS-DOS     Pegasus/DOS 3.2(r2) clnt ?    risc.ua.edu 6/6/96
-fshare MacOS      Pegasus/MAC 2.1.2   clnt ?    risc.ua.edu 6/6/96
-fshare MS-Windows Pegasus/Win 2.4.2   clnt ?    risc.ua.edu 8/2/96
-fshare MS-DOS     Pegasus/DOS 3.3.1   clnt ?    risc.ua.edu 8/2/96
-SMTP   MS-DOS     Charon              gway ?    risc.ua.edu 10/15/93
-Waffle MS-WIN     Boxer               clnt ?    ftp.halcyon.com 12/3/93
-?      MS-?       pcelm               clnt ?    simtel 12/3/93
-?      MS-?       elm-pc              clnt ?    lister.cc.ic.ac.uk 12/3/93
-SMTP   MS-WINw    Internt Ex for cc:m gway yes  IMA 1/31/94
-SMTP   Netware    Mercury 1.11        gway ?    risc.ua.edu 2/4/94
-?      MacOS      PowerMail           clnt ?    Apple 2/18/94
-SMTP   OS/2       PC/TCP v1.3         peer ?    FTP Software 2/18/94
-MAPI   MS-DOS?    Microsoft Mail      clnt ?    Microsoft 3/2/94
-?      MacOS      Microsoft Mail      clnt ?    Microsoft 3/15/94
-VIM    DOSWINMac  cc:mail             clnt ?    Lotus 3/15/94
-MHS/G  DOSWINMac  DaVinci eMAIL       clnt ?    On Technology 4/24/96
-P7uucp DOSWINMac  OpenMail            clnt ?    HP 3/2/94
-?      DOSWINMac  WordPerfect Office  clnt ?    WordPerfect Corp. 3/15/94
-?      DOSMac     MailWorks           clnt ?    DEC 3/2/94
-MHS/G  DOSWIN     BeyondMail          clnt yes  Banyan (beyondmail.banyan.com)
-2/6/96
-?      DOSOS/2    Higgins Mail        clnt ?    Enable Software 1/26/95
-?      MacOS      QuickMail 3.6       clnt ?    CE Software 6/6/96
-?      DOS        QuickMail 3.0       clnt ?    CE Software 6/6/96
-?      MS-WIN     QuickMail 3.5       clnt ?    CE Software 6/6/96
-?      MacOS      QuickMail 4.0 (fut) clnt ?    CE Software 6/6/96
-?      ?          QuickMail ?         clnt yes  CE Software 7/15/96
-?      MS-WIN     Team                clnt ?    Futurus 1/26/95
-?      DOSWIN     ExpressIT!          clnt ?    Infinite Technologies 1/26/95
-MAPI   WIN95/NT   ExpressIT! 2000     clnt ?    Infinite Technologies www.ihub.
-com 1/14/97
-MHS    WIN95/NT   ExpressIT! 2000     clnt ?    Infinite Technologies www.ihub.
-com 1/14/97
-VIM    WIN95/NT   ExpressIT! 2000     clnt ?    Infinite Technologies www.ihub.
-com 1/14/97
-?      ?          GroupWise           cnlt ?    Novell 1/26/95
-?      DOSWINMac  Lotus Notes         clnt ?    Lotus 3/15/94
-FCP    MacOS      FirstClass 2.5      clnt no   SoftArc 7/12/94
-FCP    MS-WIN     FirstClass 2.5      clnt no   SoftArc 7/12/94
-FCP    MacOS      FirstClass 2.5      srvr no   SoftArc 7/12/94
-MHS    MacOS      FirstClass/MHS      gway no   SoftArc 7/12/94
-UUCP   MacOS      FirstClass/UUCP     gway no   SoftArc 7/12/94
-MAPI   MS-WINw    Mail-IT 2           clnt yes  mail-it@unipalm.co.uk 7/12/94
-MAPI   ?          ECSmail             clnt ?    ESYS Corp www.esys.ca 12/16/96
-VIM    ?          ECSmail             clnt ?    ESYS Corp www.esys.ca 12/16/96
-MAPI   MS-WIN     SIMEON 4.1          clnt ?    ESYS Corp 222.esys.ca 12/16/96
-MAPI   WIN3/95/NT Z-Mail 4.0.1        clnt yes  NetManage 8/22/96 www.netmanage
-.com
-MAPI   MS-WIN     Air Mail            ?    ?    AIR Co. Ltd 10/7/94
-MAPIs  MS-WIN     Siren Mail          ?    ?    Siren Software 12/28/95
-MAPIs  WIN95      Siren Mail          ?    ?    Siren Software 12/28/95
-MAPIs  NTclient   Siren Mail          ?    ?    Siren Software 12/28/95
-SMTP   MS-WINw    Mail-IT 2           peer yes  mail-it@unipalm.co.uk 7/12/94
-?      MS-WINw    Panda               ?    ?    ftp.cica.indiana.edu 7/12/94
-PSS    MS-Win     pMail 3.0           clnt no   CommTouch 9/27/94
-PSS    MS-DOS     pMail 3.0           clnt no   CommTouch 9/27/94
-PROP   MacOS      BlitzMail           clnt no   ftp.dartmouth.edu 10/23/95
-PROP   NeXT OS    BlitzMail           srvr no   ftp.dartmouth.edu 10/23/95
-PROP   DEC OSF/1  BlitzMail           srvr no   ftp.dartmouth.edu 10/23/95
-PROP   AIX        BlitzMail (in dev)  srvr no   ftp.dartmouth.edu 10/23/95
-PROP   ?          FreeMail            ?    ?    whttp://www.montana.com/freemai
-l 95/12/8
-PROP   MacOS      CommuniGate         both ?    Stalker 5/21/96 (www.stalker.co
-m)
-SMPT   MacOS      SMTPGate            gway ?    Stalker 3/25/96 (www.stalker.co
-m)
-UUCP   MacOS      UUCPGate            gway ?    Stalker 3/25/96 (www.stalker.co
-m)
-?      MacOS      Quarterdeck Mail    both yes  Starnine 6/11/96 (www.starnine.
-com)
-MAPI   WIN3/NT/95 JetMail             clnt yes  NetManage 7/29/96
------- ---------- ------------------- ---- ---- -------------------------------
-
-   
-     _________________________________________________________________
-   
-Key and Other Issues
-
-
-(a) What are the common extensions to POP3 and which clients/servers
- support them?
-POP3k - Kerberos
-POP3a - AFS Kerberos
-POP3x - ?
-POP3t - xtnd xmit facility--allows client to send mail through additional
- POP commands, thus allowing server to verify/log source of mail.
-POP3r - APOP
-POP3m - ?
-POP3u - with UIDL command.
-(b) What DOS protocol stacks are supported?
-MS-DOSm - Lan Manager
-MS-DOSn - NDIS Drivers
-MS-DOSl - Lan Workplace for Dos
-MS-DOSs - Sun PCNFS
-MS-DOSp - Packet Drivers
-MS-DOSo - ODI Drivers
-MS-DOSi - IPXLink
-MS-DOSf - FTP Software PC/TCP
-MS-DOSk - KA9Q I think
-MS-WIN? - similar
-MS-WINw - WinSock compliant
-MS-WIN5 - Windows 95
-WIN3 - Windows 3.x winsock
-WIN3/95/NT - Windows 3.x Winsock, Windows 95 and Windows NT
-WIN3/95 - Windows 3.x Winsock and WIndows 95
-NetWare3 - NetWare 3.x
-NetWare4 - NetWare 4.x
-NetWare34 - NetWare 3.x and 4.x
-(c) Other notes
-IMAP1 - Original IMAP: I've heard that MacMS actually uses a unique
-        dialect of it.  Definitely obselete, unsupported, discouraged.
-IMAP2b - IMAP2bis: name applied to various improved versions of IMAP2.
- This development effort culminated in IMAP4.
-IMAP24 - IMAP2 or IMAP4
-fshare - uses file sharing.
-IMAPb4 - IMAP2, IMAP2bis, or IMAP4.
-IMAP41 - IMAP4rev1
-MAPI - Microsoft's Messaging API
-MAPIs - Simple MAPI.
-VIM - Lotus's Vendor Independent Messaging API
-CMC - XAPIA's Common Message Calls API
-AOCE - Apple Open Collaborative Environment
-PROP - System-specific proprietary protocol
-FCP - Softarc's proprietary client-server protocol.
-Unix/X - X Windows based
-Unix/XM - Motif based
-Unix/XO - OpenWindows based
-PSS - PROFS Screen Scraper
-sumex-aim.stanford.edu* - almost dead as of 7/13/95, to be replaced by
- info-mac.org.
-Metamail - a package with which MIME messages can be processed from
- basically any Unix-based mail client.
-POPGate (Stalker Software) - gateway to/from Stalker's CommuniGate
- system:  enables both use of POP3 to get software from a POP3 server
- for use within a CommuniGate community, and to allow POP3 clients to
- retrieve mail from a CommuniGate server.
-DigUNIX - Digital Unix
-Solaris - Solaris 2.x
-(d) IMAP/MAPI adaptors:
-Wollongong's Pathway Access 7/12/94
-mail-it@unipalm.co.uk's Mail-IT 7/12/94
-(e) IMAP/POP3 adaptors:
-Included with NCD Z-mail 4.0 for Windows 9/14/95
------- ----------- ------------------- ------- -------------------------------
diff --git a/RFC/rfc1081.txt b/RFC/rfc1081.txt
deleted file mode 100644
index c21d6e48..00000000
--- a/RFC/rfc1081.txt
+++ /dev/null
@@ -1,899 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                            M. Rose
-Request for Comments: 1081                                           TWG
-                                                           November 1988
-
-                    Post Office Protocol - Version 3
-
-
-Status of this Memo
-
-   This memo suggests a simple method for workstations to dynamically
-   access mail from a mailbox server.  This RFC specifies a proposed
-   protocol for the Internet community, and requests discussion and
-   suggestions for improvements.  Distribution of this memo is
-   unlimited.
-
-   This memo is based on RFC 918 (since revised as RFC 937).  Although
-   similar in form to the original Post Office Protocol (POP) proposed
-   for the Internet community, the protocol discussed in this memo is
-   similar in spirit to the ideas investigated by the MZnet project at
-   the University of California, Irvine.
-
-   Further, substantial work was done on examining POP in a PC-based
-   environment.  This work, which resulted in additional functionality
-   in this protocol, was performed by the ACIS Networking Systems Group
-   at Stanford University.  The author gratefully acknowledges their
-   interest.
-
-Introduction
-
-   On certain types of smaller nodes in the Internet it is often
-   impractical to maintain a message transport system (MTS).  For
-   example, a workstation may not have sufficient resources (cycles,
-   disk space) in order to permit a SMTP server and associated local
-   mail delivery system to be kept resident and continuously running.
-   Similarly, it may be expensive (or impossible) to keep a personal
-   computer interconnected to an IP-style network for long amounts of
-   time (the node is lacking the resource known as "connectivity").
-
-   Despite this, it is often very useful to be able to manage mail on
-   these smaller nodes, and they often support a user agent (UA) to aid
-   the tasks of mail handling.  To solve this problem, a node which can
-   support an MTS entity offers a maildrop service to these less endowed
-   nodes.  The Post Office Protocol - Version 3 (POP3) is intended to
-   permit a workstation to dynamically access a maildrop on a server
-   host in a useful fashion.  Usually, this means that the POP3 is used
-   to allow a workstation to retrieve mail that the server is holding
-   for it.
-
-
-
-
-Rose                                                            [Page 1]
-
-RFC 1081                          POP3                     November 1988
-
-
-   For the remainder of this memo, the term "client host" refers to a
-   host making use of the POP3 service, while the term "server host"
-   refers to a host which offers the POP3 service.
-
-A Short Digression
-
-   This memo does not specify how a client host enters mail into the
-   transport system, although a method consistent with the philosophy of
-   this memo is presented here:
-
-      When the user agent on a client host wishes to enter a message
-      into the transport system, it establishes an SMTP connection to
-      its relay host (this relay host could be, but need not be, the
-      POP3 server host for the client host).
-
-   If this method is followed, then the client host appears to the MTS
-   as a user agent, and should NOT be regarded as a "trusted" MTS entity
-   in any sense whatsoever.  This concept, along with the role of the
-   POP3 as a part of a split-UA model is discussed later in this memo.
-
-   Initially, the server host starts the POP3 service by listening on
-   TCP port 110.  When a client host wishes to make use of the service,
-   it establishes a TCP connection with the server host.  When the
-   connection is established, the POP3 server sends a greeting.  The
-   client and POP3 server then exchange commands and responses
-   (respectively) until the connection is closed or aborted.
-
-   Commands in the POP3 consist of a keyword possibly followed by an
-   argument.  All commands are terminated by a CRLF pair.
-
-   Responses in the POP3 consist of a success indicator and a keyword
-   possibly followed by additional information.  All responses are
-   terminated by a CRLF pair.  There are currently two success
-   indicators: positive ("+OK") and negative ("-ERR").
-
-   Responses to certain commands are multi-line.  In these cases, which
-   are clearly indicated below, after sending the first line of the
-   response and a CRLF, any additional lines are sent, each terminated
-   by a CRLF pair.  When all lines of the response have been sent, a
-   final line is sent, consisting of a termination octet (decimal code
-   046, ".") and a CRLF pair.  If any line of the multi-line response
-   begins with the termination octet, the line is "byte-stuffed" by
-   pre-pending the termination octet to that line of the response.
-   Hence a multi-line response is terminated with the five octets
-   "CRLF.CRLF".  When examining a multi-line response, the client checks
-   to see if the line begins with the termination octet.  If so and if
-   octets other than CRLF follow, the the first octet of the line (the
-   termination octet) is stripped away.  If so and if CRLF immediately
-
-
-
-Rose                                                            [Page 2]
-
-RFC 1081                          POP3                     November 1988
-
-
-   follows the termination character, then the response from the POP
-   server is ended and the line containing ".CRLF" is not considered
-   part of the multi-line response.
-
-   A POP3 session progresses through a number of states during its
-   lifetime.  Once the TCP connection has been opened and the POP3
-   server has sent the greeting, the session enters the AUTHORIZATION
-   state.  In this state, the client must identify itself to the POP3
-   server.  Once the client has successfully done this, the server
-   acquires resources associated with the client's maildrop, and the
-   session enters the TRANSACTION state.  In this state, the client
-   requests actions on the part of the POP3 server.  When the client has
-   finished its transactions, the session enters the UPDATE state.  In
-   this state, the POP3 server releases any resources acquired during
-   the TRANSACTION state and says goodbye.  The TCP connection is then
-   closed.
-
-The AUTHORIZATION State
-
-   Once the TCP connection has been opened by a POP3 client, the POP3
-   server issues a one line greeting.  This can be any string terminated
-   by CRLF.  An example might be:
-
-      S.  +OK dewey POP3 server ready (Comments to: PostMaster@UDEL.EDU)
-
-   Note that this greeting is a POP3 reply.  The POP3 server should
-   always give a positive response as the greeting.
-
-   The POP3 session is now in the AUTHORIZATION state.  The client must
-   now issue the USER command.  If the POP3 server responds with a
-   positive success indicator ("+OK"), then the client may issue either
-   the PASS command to complete the authorization, or the QUIT command
-   to terminate the POP3 session.  If the POP3 server responds with a
-   negative success indicator ("-ERR") to the USER command, then the
-   client may either issue a new USER command or may issue the QUIT
-   command.
-
-   When the client issues the PASS command, the POP3 server uses the
-   argument pair from the USER and PASS commands to determine if the
-   client should be given access to the appropriate maildrop.  If so,
-   the POP3 server then acquires an exclusive-access lock on the
-   maildrop.  If the lock is successfully acquired, the POP3 server
-   parses the maildrop into individual messages (read note below),
-   determines the last message (if any) present in the maildrop that was
-   referenced by the RETR command, and responds with a positive success
-   indicator.  The POP3 session now enters the TRANSACTION state.  If
-   the lock can not be acquired or the client should is denied access to
-   the appropriate maildrop or the maildrop can't be parsed for some
-
-
-
-Rose                                                            [Page 3]
-
-RFC 1081                          POP3                     November 1988
-
-
-   reason, the POP3 server responds with a negative success indicator.
-   (If a lock was acquired but the POP3 server intends to respond with a
-   negative success indicator, the POP3 server must release the lock
-   prior to rejecting the command.)  At this point, the client may
-   either issue a new USER command and start again, or the client may
-   issue the QUIT command.
-
-                 NOTE: Minimal implementations of the POP3 need only be
-                 able to break a maildrop into its component messages;
-                 they need NOT be able to parse individual messages.
-                 More advanced implementations may wish to have this
-                 capability, for reasons discussed later.
-
-   After the POP3 server has parsed the maildrop into individual
-   messages, it assigns a message-id to each message, and notes the size
-   of the message in octets.  The first message in the maildrop is
-   assigned a message-id of "1", the second is assigned "2", and so on,
-   so that the n'th message in a maildrop is assigned a message-id of
-   "n".  In POP3 commands and responses, all message-id's and message
-   sizes are expressed in base-10 (i.e., decimal).
-
-   It sets the "highest number accessed" to be that of the last message
-   referenced by the RETR command.
-
-   Here are summaries for the three POP3 commands discussed thus far:
-
-           USER name
-               Arguments: a server specific user-id (required)
-               Restrictions: may only be given in the AUTHORIZATION
-                   state after the POP3 greeting or after an
-                   unsuccessful USER or PASS command
-               Possible Responses:
-                   +OK name is welcome here
-                   -ERR never heard of name
-               Examples:
-                   C:    USER mrose
-                   S:    +OK mrose is a real hoopy frood
-                     ...
-                   C:    USER frated
-                   S:    -ERR sorry, frated doesn't get his mail here
-
-           PASS string
-               Arguments: a server/user-id specific password (required)
-               Restrictions: may only be given in the AUTHORIZATION
-                   state after a successful USER command
-               Possible Responses:
-                   +OK maildrop locked and ready
-                   -ERR invalid password
-
-
-
-Rose                                                            [Page 4]
-
-RFC 1081                          POP3                     November 1988
-
-
-                   -ERR unable to lock maildrop
-               Examples:
-                   C:    USER mrose
-                   S:    +OK mrose is a real hoopy frood
-                   C:    PASS secret
-                   S:    +OK mrose's maildrop has 2 messages
-                         (320 octets)
-                     ...
-                   C:    USER mrose
-                   S:    +OK mrose is a real hoopy frood
-                   C:    PASS secret
-                   S:    -ERR unable to lock mrose's maildrop, file
-                         already locked
-
-           QUIT
-               Arguments: none
-               Restrictions: none
-               Possible Responses:
-                   +OK
-               Examples:
-                   C:    QUIT
-                   S:    +OK dewey POP3 server signing off
-
-
-The TRANSACTION State
-
-   Once the client has successfully identified itself to the POP3 server
-   and the POP3 server has locked and burst the appropriate maildrop,
-   the POP3 session is now in the TRANSACTION state.  The client may now
-   issue any of the following POP3 commands repeatedly.  After each
-   command, the POP3 server issues a response.  Eventually, the client
-   issues the QUIT command and the POP3 session enters the UPDATE state.
-
-   Here are the POP3 commands valid in the TRANSACTION state:
-
-           STAT
-               Arguments: none
-               Restrictions: may only be given in the TRANSACTION state.
-               Discussion:
-
-                 The POP3 server issues a positive response with a line
-                 containing information for the maildrop.  This line is
-                 called a "drop listing" for that maildrop.
-
-                 In order to simplify parsing, all POP3 servers are
-                 required to use a certain format for drop listings.
-                 The first octets present must indicate the number of
-                 messages in the maildrop.  Following this is the size
-
-
-
-Rose                                                            [Page 5]
-
-RFC 1081                          POP3                     November 1988
-
-
-                 of the maildrop in octets.  This memo makes no
-                 requirement on what follows the maildrop size.
-                 Minimal implementations should just end that line of
-                 the response with a CRLF pair.  More advanced
-                 implementations may include other information.
-
-                      NOTE: This memo STRONGLY discourages
-                      implementations from supplying additional
-                      information in the drop listing.  Other,
-                      optional, facilities are discussed later on
-                      which permit the client to parse the messages
-                      in the maildrop.
-
-                 Note that messages marked as deleted are not counted in
-                 either total.
-
-               Possible Responses:
-                   +OK nn mm
-               Examples:
-                   C:    STAT
-                   S:    +OK 2 320
-
-           LIST [msg]
-               Arguments: a message-id (optionally)  If a message-id is
-                   given, it may NOT refer to a message marked as
-                   deleted.
-               Restrictions: may only be given in the TRANSACTION state.
-               Discussion:
-
-                 If an argument was given and the POP3 server issues a
-                 positive response with a line containing information
-                 for that message.  This line is called a "scan listing"
-                 for that message.
-
-                 If no argument was given and the POP3 server issues a
-                 positive response, then the response given is
-                 multi-line.  After the initial +OK, for each message
-                 in the maildrop, the POP3 server responds with a line
-                 containing information for that message.  This line
-                 is called a "scan listing" for that message.
-
-                 In order to simplify parsing, all POP3 servers are
-                 required to use a certain format for scan listings.
-                 The first octets present must be the message-id of
-                 the message.  Following the message-id is the size of
-                 the message in octets.  This memo makes no requirement
-                 on what follows the message size in the scan listing.
-                 Minimal implementations should just end that line of
-
-
-
-Rose                                                            [Page 6]
-
-RFC 1081                          POP3                     November 1988
-
-
-                 the response with a CRLF pair.  More advanced
-                 implementations may include other information, as
-                 parsed from the message.
-
-                      NOTE: This memo STRONGLY discourages
-                      implementations from supplying additional
-                      information in the scan listing.  Other, optional,
-                      facilities are discussed later on which permit
-                      the client to parse the messages in the maildrop.
-
-                 Note that messages marked as deleted are not listed.
-
-               Possible Responses:
-                   +OK scan listing follows
-                   -ERR no such message
-               Examples:
-                   C:    LIST
-                   S:    +OK 2 messages (320 octets)
-                   S:    1 120
-                   S:    2 200
-                   S:    .
-                     ...
-                   C:    LIST 2
-                   S:    +OK 2 200
-                     ...
-                   C:    LIST 3
-                   S:    -ERR no such message, only 2 messages in
-                         maildrop
-
-           RETR msg
-               Arguments: a message-id (required)  This message-id may
-                   NOT refer to a message marked as deleted.
-               Restrictions: may only be given in the TRANSACTION state.
-               Discussion:
-
-                 If the POP3 server issues a positive response, then the
-                 response given is multi-line.  After the initial +OK,
-                 the POP3 server sends the message corresponding to the
-                 given message-id, being careful to byte-stuff the
-                 termination character (as with all multi-line
-                 responses).
-
-                 If the number associated with this message is higher
-                 than the "highest number accessed" in the maildrop, the
-                 POP3 server updates the "highest number accessed" to
-                 the number associated with this message.
-
-
-
-
-
-Rose                                                            [Page 7]
-
-RFC 1081                          POP3                     November 1988
-
-
-               Possible Responses:
-                   +OK message follows
-                   -ERR no such message
-               Examples:
-                   C:    RETR 1
-                   S:    +OK 120 octets
-                   S:    <the POP3 server sends the entire message here>
-                   S:    .
-
-           DELE msg
-               Arguments: a message-id (required)  This message-id
-                   may NOT refer to a message marked as deleted.
-               Restrictions: may only be given in the TRANSACTION state.
-               Discussion:
-
-                 The POP3 server marks the message as deleted.  Any
-                 future reference to the message-id associated with the
-                 message in a POP3 command generates an error.  The POP3
-                 server does not actually delete the message until the
-                 POP3 session enters the UPDATE state.
-
-                 If the number associated with this message is higher
-                 than the "highest number accessed" in the maildrop,
-                 the POP3 server updates the "highest number accessed"
-                 to the number associated with this message.
-
-               Possible Responses:
-                   +OK message deleted
-                   -ERR no such message
-               Examples:
-                   C:    DELE 1
-                   S:    +OK message 1 deleted
-                     ...
-                   C:    DELE 2
-                   S:    -ERR message 2 already deleted
-
-           NOOP
-               Arguments: none
-               Restrictions: may only be given in the TRANSACTION state.
-               Discussion:
-
-                 The POP3 server does nothing, it merely replies with a
-                 positive response.
-
-               Possible Responses:
-                   +OK
-
-
-
-
-
-Rose                                                            [Page 8]
-
-RFC 1081                          POP3                     November 1988
-
-
-               Examples:
-                   C:    NOOP
-                   S:    +OK
-
-           LAST
-               Arguments: none
-               Restrictions: may only be issued in the TRANSACTION state.
-               Discussion:
-
-                 The POP3 server issues a positive response with a line
-                 containing the highest message number which accessed.
-                 Zero is returned in case no message in the maildrop has
-                 been accessed during previous transactions.  A client
-                 may thereafter infer that messages, if any, numbered
-                 greater than the response to the LAST command are
-                 messages not yet accessed by the client.
-
-             Possible Response:
-                   +OK nn
-
-             Examples:
-                   C:      STAT
-                   S:      +OK 4 320
-                   C:      LAST
-                   S:      +OK 1
-                   C:      RETR 3
-                   S:      +OK 120 octets
-                   S:      <the POP3 server sends the entire message
-                           here>
-                   S:      .
-                   C:      LAST
-                   S:      +OK 3
-                   C:      DELE 2
-                   S:      +OK message 2 deleted
-                   C:      LAST
-                   S:      +OK 3
-                   C:      RSET
-                   S:      +OK
-                   C:      LAST
-                   S:      +OK 1
-
-           RSET
-               Arguments: none
-               Restrictions: may only be given in the TRANSACTION
-                   state.
-               Discussion:
-
-                 If any messages have been marked as deleted by the POP3
-
-
-
-Rose                                                            [Page 9]
-
-RFC 1081                          POP3                     November 1988
-
-
-                 server, they are unmarked.  The POP3 server then
-                 replies with a positive response.  In addition, the
-                 "highest number accessed" is also reset to the value
-                 determined at the beginning of the POP3 session.
-
-               Possible Responses:
-                   +OK
-               Examples:
-                   C:    RSET
-                   S:    +OK maildrop has 2 messages (320 octets)
-
-
-
-The UPDATE State
-
-   When the client issues the QUIT command from the TRANSACTION state,
-   the POP3 session enters the UPDATE state.  (Note that if the client
-   issues the QUIT command from the AUTHORIZATION state, the POP3
-   session terminates but does NOT enter the UPDATE state.)
-
-           QUIT
-               Arguments: none
-               Restrictions: none
-               Discussion:
-
-                 The POP3 server removes all messages marked as deleted
-                 from the maildrop.  It then releases the
-                 exclusive-access lock on the maildrop and replies as
-                 to the success of
-                 these operations.  The TCP connection is then closed.
-
-               Possible Responses:
-                   +OK
-               Examples:
-                   C:    QUIT
-                   S:    +OK dewey POP3 server signing off (maildrop
-                         empty)
-                     ...
-                   C:    QUIT
-                   S:    +OK dewey POP3 server signing off (2 messages
-                         left)
-                     ...
-
-
-Optional POP3 Commands
-
-   The POP3 commands discussed above must be supported by all minimal
-   implementations of POP3 servers.
-
-
-
-Rose                                                           [Page 10]
-
-RFC 1081                          POP3                     November 1988
-
-
-   The optional POP3 commands described below permit a POP3 client
-   greater freedom in message handling, while preserving a simple POP3
-   server implementation.
-
-                 NOTE: This memo STRONGLY encourages implementations to
-                 support these commands in lieu of developing augmented
-                 drop and scan listings.  In short, the philosophy of
-                 this memo is to put intelligence in the part of the
-                 POP3 client and not the POP3 server.
-
-           TOP msg n
-               Arguments: a message-id (required) and a number.  This
-                   message-id may NOT refer to a message marked as
-                   deleted.
-               Restrictions: may only be given in the TRANSACTION state.
-               Discussion:
-
-                 If the POP3 server issues a positive response, then
-                 the response given is multi-line.  After the initial
-                 +OK, the POP3 server sends the headers of the message,
-                 the blank line separating the headers from the body,
-                 and then the number of lines indicated message's body,
-                 being careful to byte-stuff the termination character
-                 (as with all multi-line responses).
-
-                 Note that if the number of lines requested by the POP3
-                 client is greater than than the number of lines in the
-                 body, then the POP3 server sends the entire message.
-
-               Possible Responses:
-                   +OK top of message follows
-                   -ERR no such message
-               Examples:
-                   C:    TOP 10
-                   S:    +OK
-                   S:    <the POP3 server sends the headers of the
-                          message, a blank line, and the first 10 lines
-                          of the body of the message>
-                   S:    .
-                     ...
-                   C:    TOP 100
-                   S:    -ERR no such message
-
-           RPOP user
-               Arguments: a client specific user-id (required)
-               Restrictions: may only be given in the AUTHORIZATION
-                   state after a successful USER command; in addition,
-                   may only be given if the client used a reserved
-
-
-
-Rose                                                           [Page 11]
-
-RFC 1081                          POP3                     November 1988
-
-
-                   (privileged) TCP port to connect to the server.
-               Discussion:
-
-                 The RPOP command may be used instead of the PASS
-                 command to authenticate access to the maildrop.  In
-                 order for this command to be successful, the POP3
-                 client must use a reserved TCP port (port < 1024) to
-                 connect tothe server.  The POP3 server uses the
-                 argument pair from the USER and RPOP commands to
-                 determine if the client should be given access to
-                 the appropriate maildrop.  Unlike the PASS command
-                 however, the POP3 server considers if the remote user
-                 specified by the RPOP command who resides on the POP3
-                 client host is allowed to access the maildrop for the
-                 user specified by the USER command (e.g., on Berkeley
-                 UNIX, the .rhosts mechanism is used).  With the
-                 exception of this differing in authentication, this
-                 command is identical to the PASS command.
-
-                 Note that the use of this feature has allowed much wider
-                 penetration into numerous hosts on local networks (and
-                 sometimes remote networks) by those who gain illegal
-                 access to computers by guessing passwords or otherwise
-                 breaking into the system.
-
-               Possible Responses:
-                   +OK maildrop locked and ready
-                   -ERR permission denied
-               Examples:
-                   C:    USER mrose
-                   S:    +OK mrose is a real hoopy frood
-                   C:    RPOP mrose
-                   S:    +OK mrose's maildrop has 2 messages (320
-                         octets)
-
-       Minimal POP3 Commands:
-           USER name               valid in the AUTHORIZATION state
-           PASS string
-           QUIT
-
-           STAT                    valid in the TRANSACTION state
-           LIST [msg]
-           RETR msg
-           DELE msg
-           NOOP
-           LAST
-           RSET
-
-
-
-
-Rose                                                           [Page 12]
-
-RFC 1081                          POP3                     November 1988
-
-
-           QUIT                    valid in the UPDATE state
-
-       Optional POP3 Commands:
-           RPOP user               valid in the AUTHORIZATION state
-
-           TOP msg n               valid in the TRANSACTION state
-
-       POP3 Replies:
-           +OK
-           -ERR
-
-       Note that with the exception of the STAT command, the reply given
-       by the POP3 server to any command is significant only to "+OK"
-       and "-ERR".  Any text occurring after this reply may be ignored
-       by the client.
-
-Example POP3 Session
-
-    S: <wait for connection on TCP port 110>
-        ...
-    C: <open connection>
-    S:    +OK dewey POP3 server ready (Comments to: PostMaster@UDEL.EDU)
-    C:    USER mrose
-    S:    +OK mrose is a real hoopy frood
-    C:    PASS secret
-    S:    +OK mrose's maildrop has 2 messages (320 octets)
-    C:    STAT
-    S:    +OK 2 320
-    C:    LIST
-    S:    +OK 2 messages (320 octets)
-    S:    1 120
-    S:    2 200
-    S:    .
-    C:    RETR 1
-    S:    +OK 120 octets
-    S:    <the POP3 server sends message 1>
-    S:    .
-    C:    DELE 1
-    S:    +OK message 1 deleted
-    C:    RETR 2
-    S:    +OK 200 octets
-    S:    <the POP3 server sends message 2>
-    S:    .
-    C:    DELE 2
-    S:    +OK message 2 deleted
-    C:    QUIT
-
-
-
-
-
-Rose                                                           [Page 13]
-
-RFC 1081                          POP3                     November 1988
-
-
-    S:    +OK dewey POP3 server signing off (maildrop empty)
-    C:  <close connection>
-    S:  <wait for next connection>
-
-Message Format
-
-   All messages transmitted during a POP3 session are assumed to conform
-   to the standard for the format of Internet text messages [RFC822].
-
-   It is important to note that the byte count for a message on the
-   server host may differ from the octet count assigned to that message
-   due to local conventions for designating end-of-line.  Usually,
-   during the AUTHORIZATION state of the POP3 session, the POP3 client
-   can calculate the size of each message in octets when it parses the
-   maildrop into messages.  For example, if the POP3 server host
-   internally represents end-of-line as a single character, then the
-   POP3 server simply counts each occurrence of this character in a
-   message as two octets.  Note that lines in the message which start
-   with the termination octet need not be counted twice, since the POP3
-   client will remove all byte-stuffed termination characters when it
-   receives a multi-line response.
-
-The POP and the Split-UA model
-
-   The underlying paradigm in which the POP3 functions is that of a
-   split-UA model.  The POP3 client host, being a remote PC based
-   workstation, acts solely as a client to the message transport system.
-   It does not provide delivery/authentication services to others.
-   Hence, it is acting as a UA, on behalf of the person using the
-   workstation.  Furthermore, the workstation uses SMTP to enter mail
-   into the MTS.
-
-   In this sense, we have two UA functions which interface to the
-   message transport system: Posting (SMTP) and Retrieval (POP3).  The
-   entity which supports this type of environment is called a split-UA
-   (since the user agent is split between two hosts which must
-   interoperate to provide these functions).
-
-                 ASIDE:  Others might term this a remote-UA instead.
-                 There are arguments supporting the use of both terms.
-
-   This memo has explicitly referenced TCP as the underlying transport
-   agent for the POP3.  This need not be the case.  In the MZnet split-
-   UA, for example, personal micro-computer systems are used which do
-   not have IP-style networking capability.  To connect to the POP3
-   server host, a PC establishes a terminal connection using some simple
-   protocol (PhoneNet).  A program on the PC drives the connection,
-   first establishing a login session as a normal user.  The login shell
-
-
-
-Rose                                                           [Page 14]
-
-RFC 1081                          POP3                     November 1988
-
-
-   for this pseudo-user is a program which drives the other half of the
-   terminal protocol and communicates with one of two servers.  Although
-   MZnet can support several PCs, a single pseudo-user login is present
-   on the server host.  The user-id and password for this pseudo-user
-   login is known to all members of MZnet.  Hence, the first action of
-   the login shell, after starting the terminal protocol, is to demand a
-   USER/PASS authorization pair from the PC.  This second level of
-   authorization is used to ascertain who is interacting with the MTS.
-   Although the server host is deemed to support a "trusted" MTS entity,
-   PCs in MZnet are not.  Naturally, the USER/PASS authorization pair
-   for a PC is known only to the owner of the PC (in theory, at least).
-
-   After successfully verifying the identity of the client, a modified
-   SMTP server is started, and the PC posts mail with the server host.
-   After the QUIT command is given to the SMTP server and it terminates,
-   a modified POP3 server is started, and the PC retrieves mail from the
-   server host.  After the QUIT command is given to the POP3 server and
-   it terminates, the login shell for the pseudo-user terminates the
-   terminal protocol and logs the job out.  The PC then closes the
-   terminal connection to the server host.
-
-   The SMTP server used by MZnet is modified in the sense that it knows
-   that it's talking to a user agent and not a "trusted" entity in the
-   message transport system.  Hence, it does performs the validation
-   activities normally performed by an entity in the MTS when it accepts
-   a message from a UA.
-
-   The POP3 server used by MZnet is modified in the sense that it does
-   not require a USER/PASS combination before entering the TRANSACTION
-   state.  The reason for this (of course) is that the PC has already
-   identified itself during the second-level authorization step
-   described above.
-
-                 NOTE: Truth in advertising laws require that the author
-                 of this memo state that MZnet has not actually been
-                 fully implemented.  The concepts presented and proven
-                 by the project led to the notion of the MZnet
-                 split-slot model.  This notion has inspired the
-                 split-UA concept described in this memo, led to the
-                 author's interest in the POP, and heavily influenced
-                 the the description of the POP3 herein.
-
-   In fact, some UAs present in the Internet already support the notion
-   of posting directly to an SMTP server and retrieving mail directly
-   from a POP server, even if the POP server and client resided on the
-   same host!
-
-                 ASIDE: this discussion raises an issue which this memo
-
-
-
-Rose                                                           [Page 15]
-
-RFC 1081                          POP3                     November 1988
-
-
-                 purposedly avoids: how does SMTP know that it's talking
-                 to a "trusted" MTS entity?
-
-References
-
-     [MZnet]   Stefferud, E., J. Sweet, and T. Domae, "MZnet: Mail
-               Service for Personal Micro-Computer Systems",
-               Proceedings, IFIP 6.5 International Conference on
-               Computer Message Systems, Nottingham, U.K., May 1984.
-
-     [RFC821]  Postel, J., "Simple Mail Transfer Protocol",
-               USC/Information Sciences Institute, August 1982.
-
-     [RFC822]  Crocker, D., "Standard for the Format of ARPA-Internet
-               Text Messages", University of Delaware, August 1982.
-
-     [RFC937]  Butler, M., J. Postel, D. Chase, J. Goldberger, and J.
-               Reynolds, "Post Office Protocol - Version 2", RFC 937,
-               USC/Information Sciences Institute, February 1985.
-
-     [RFC1010] Reynolds, J., and J. Postel, "Assigned Numbers", RFC
-               1010, USC/Information Sciences Institute, May 1987.
-
-Author's Address:
-
-
-   Marshall Rose
-   The Wollongong Group
-   1129 San Antonio Rd.
-   Palo Alto, California 94303
-
-   Phone: (415) 962-7100
-
-   Email: MRose@TWG.COM
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rose                                                           [Page 16]
-
-\ No newline at end of file
diff --git a/RFC/rfc1123.txt b/RFC/rfc1123.txt
deleted file mode 100644
index 51cdf83c..00000000
--- a/RFC/rfc1123.txt
+++ /dev/null
@@ -1,5782 +0,0 @@
-
-
-
-
-
-
-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/RFC/rfc1176.txt b/RFC/rfc1176.txt
deleted file mode 100644
index 1ea72a11..00000000
--- a/RFC/rfc1176.txt
+++ /dev/null
@@ -1,1683 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         M. Crispin
-Request for Comments: 1176                                    Washington
-Obsoletes: RFC 1064                                          August 1990
-
-
-              INTERACTIVE MAIL ACCESS PROTOCOL - VERSION 2
-
-
-Status of this Memo
-
-   This RFC suggests a method for personal computers and workstations to
-   dynamically access mail from a mailbox server ("repository").  It
-   obosoletes RFC 1064.  This RFC specifies an Experimental Protocol for
-   the Internet community.  Discussion and suggestions for improvement
-   are requested.  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.
-
-Introduction
-
-   The intent of the Interactive Mail Access Protocol, Version 2 (IMAP2)
-   is to allow a workstation, personal computer, or similar small
-   machine to access electronic mail from a mailbox server.  Since the
-   distinction between personal computers and workstations is blurring
-   over time, it is desirable to have a single solution that addresses
-   the need in a general fashion.  IMAP2 is the "glue" of a distributed
-   electronic mail system consisting of a family of client and server
-   implementations on a wide variety of platforms, from small single-
-   tasking personal computing engines to complex multi-user timesharing
-   systems.
-
-   Although different in many ways from the Post Office Protocols (POP2
-   and POP3, hereafter referred to collectively as "POP") described in
-   RFC 937 and RFC 1081, IMAP2 may be thought of as a functional
-   superset of these.  RFC 937 was used as a model for this RFC.  There
-   was a cognizant reason for this; POP deals with a similar problem,
-   albeit with a less comprehensive solution, and it was desirable to
-   offer a basis for comparison.
-
-   Like POP, IMAP2 specifies a means of accessing stored mail and not of
-   posting mail; this function is handled by a mail transfer protocol
-   such as SMTP (RFC 821).
-
-   This protocol assumes a reliable data stream such as provided by TCP
-   or any similar protocol.  When TCP is used, the IMAP2 server listens
-   on port 143.
-
-
-
-
-
-Crispin                                                         [Page 1]
-
-RFC 1176                         IMAP2                       August 1990
-
-
-System Model and Philosophy
-
-   Electronic mail is a primary means of communication for the widely
-   spread Internet community.  The advent of distributed personal
-   computers and workstations has forced a significant rethinking of the
-   mechanisms employed to manage electronic mail.  With mainframes, each
-   user tends to receive and process mail at the computer he uses most
-   of the time, his "primary host".  The first inclination of many users
-   when an independent workstation is placed in front of them is to
-   begin receiving mail at the workstation, and many vendors have
-   implemented facilities to do this.  However, this approach has
-   several disadvantages:
-
-      (1) Personal computers and many workstations have a software
-      design that gives full control of all aspects of the system to the
-      user at the console.  As a result, background tasks such as
-      receiving mail may not run for long periods of time; either
-      because the user is asking to use all the machine's resources, or
-      because the user has (perhaps accidentally) manipulated the
-      environment in such a way that it prevents mail reception.  In
-      many personal computers, the operating system is single-tasking
-      and this is the only mode of operation.  Any of these conditions
-      could lead to repeated failed delivery attempts by outside agents.
-
-      (2) The hardware failure of a single machine can keep its user
-      "off the air" for a considerable time, since repair of individual
-      units may be delayed.  Given the growing number of personal
-      computers and workstations spread throughout office environments,
-      quick repair of such systems is not assured.  On the other hand, a
-      central mainframe is generally repaired soon after failure.
-
-      (3) Personal computers and workstations are often not backed up
-      with as much diligence as a central mainframe, if at all.
-
-      (4) It is more difficult to keep track of mailing addresses when
-      each person is associated with a distinct machine.  Consider the
-      difficulty in keeping track of many postal addresses or phone
-      numbers, particularly if there was no single address or phone
-      number for an organization through which you could reach any
-      person in that organization.  Traditionally, electronic mail on
-      the ARPANET involved remembering a name and one of several "hosts"
-      (machines) whose name reflected the organization in which the
-      individual worked.  This was suitable at a time when most
-      organizations had only one central host.  It is less satisfactory
-      today unless the concept of a host is changed to refer to an
-      organizational entity and not a particular machine.
-
-      (5) It is difficult to keep a multitude of heterogeneous machines
-
-
-
-Crispin                                                         [Page 2]
-
-RFC 1176                         IMAP2                       August 1990
-
-
-      working properly with complex mailing protocols, making it
-      difficult to move forward as progress is made in electronic
-      communication and as new standards emerge.  Each system has to
-      worry about receiving incoming mail, routing and delivering
-      outgoing mail, formatting, storing, and providing for the
-      stability of mailboxes over a variety of possible filing and
-      mailing protocols.
-
-   Consequently, while a personal computer or workstation may be viewed
-   as an Internet host in the sense that it implements TCP/IP, it should
-   not be viewed as the entity that contains the user's mailbox.
-   Instead, a mail server machine ("server", sometimes called a
-   "repository") should hold the mailbox, and the personal computer or
-   workstation (hereafter referred to as a "client") should access the
-   mailbox via mail transactions.
-
-   Because the mail server machine is isolated from direct user
-   manipulation, it should achieve high software reliability easily,
-   and, as a shared resource, it should also achieve high hardware
-   reliability, perhaps through redundancy.  The mail server may be
-   accessed from arbitrary locations, allowing users to read mail across
-   campus, town, or country using commonly available clients.
-   Furthermore, the same user may access his mailbox from different
-   clients at different times, and multiple users may access the same
-   mailbox simultaneously.
-
-   The mail server acts an an interface among users, data storage, and
-   other mailers.  A mail access protocol retrieves messages, accesss
-   and changes properties of messages, and otherwise manages mailboxes.
-   This differs from some approaches (e.g., Unix mail via NFS) in that
-   the mail access protocol is used for all message manipulations,
-   isolating the user and the client from all knowledge of how the data
-   storage is used.  This means that the mail server can use the data
-   storage in whatever way is most efficient to organize the mail in
-   that particular environment, without having to worry about storage
-   representation compatibility across different machines.
-
-   A mail access protocol further differs in that it transmits
-   information only on demand.  A well-designed mail access protocol
-   requires considerably less network traffic than Unix mail via NFS,
-   particularly when the mail file is large.  The result is that a mail
-   access protocol can scale well to situations of large mailboxes or
-   networks with high latency or low speed.
-
-   In defining a mail access protocol, it is important to keep in mind
-   that the client and server form a macrosystem, in which it should be
-   possible to exploit the strong points of both while compensating for
-   each other's weaknesses.  Furthermore, it is desirable to allow for a
-
-
-
-Crispin                                                         [Page 3]
-
-RFC 1176                         IMAP2                       August 1990
-
-
-   growth path beyond the hoary text-only RFC 822 protocol, specifically
-   in the area of attachments and multi-media mail, to ease the eventual
-   transition to ISO solutions.
-
-   Unlike POP, IMAP2 has extensive features for remote searching and
-   parsing of messages on the server.  A free text search (optionally
-   with other searching) can be made in the entire mailbox by the server
-   and the results made available to the client without the client
-   having to transfer the entire mailbox and searching itself.  Since
-   remote parsing of a message into a structured (and standard format)
-   "envelope" is available, a client can display envelope information
-   and implement commands such as REPLY without having any understanding
-   of how to parse RFC 822, etc. headers.  The effect of this is
-   twofold: it further improves the ability to scale well in instances
-   where network traffic must be reduced, and it reduces the complexity
-   of the client program.
-
-   Additionally, IMAP2 offers several facilities for managing individual
-   message state and the mailbox as a whole beyond the simple "delete
-   message" functionality of POP.  Another benefit of IMAP2 is the use
-   of tagged responses to reduce the possibility of synchronization
-   errors and the concept of state on the client (a "local cache") that
-   the server may update without explicit request by the client.  These
-   concepts and how they are used are explained under "Implementation
-   Discussion" below.
-
-   In spite of this functional richness, IMAP2 is a small protocol.
-   Although servers should implement the full set of IMAP2 functions, a
-   simple client can be written that uses IMAP2 in much the way as a POP
-   client.
-
-   A related protocol to POP and IMAP2 is the DMSP protocol of PCMAIL
-   (RFC 1056).  IMAP2 differs from DMSP more fundamentally, reflecting a
-   differing architecture from PCMAIL.  PCMAIL is either an online
-   ("interactive mode"), or offline ("batch mode") system with long-term
-   shared state.  Some POP based systems are also offline; in such
-   systems, since there is no long-term shared state POP is little more
-   than a download mechanism of the "mail file" to the client.  IMAP2-
-   based software is primarily an online system in which real-time and
-   simultaneous mail access were considered important.
-
-   In PCMAIL, there is a long-term client/server relationship in which
-   some mailbox state is preserved on the client.  There is a
-   registration of clients used by a particular user, and the client
-   keeps a set of "descriptors" for each message that summarize the
-   message.  The server and client synchronize their states when the
-   DMSP connection starts up, and, if a client has not accessed the
-   server for a while, the client does a complete reset (reload) of its
-
-
-
-Crispin                                                         [Page 4]
-
-RFC 1176                         IMAP2                       August 1990
-
-
-   state from the server.
-
-   In IMAP2-based software, the client/server relationship lasts only
-   for the duration of the TCP connection.  All mailbox state is
-   maintained on the server.  There is no registration of clients.  The
-   function of a descriptor is handled by a structured representation of
-   the message "envelope" as noted above.  There is no client/server
-   synchronization since the client does not remember state between
-   IMAP2 connections.  This is not a problem since in general the client
-   never needs the entire state of the mailbox in a single session,
-   therefore there isn't much overhead in fetching the state information
-   that is needed as it is needed.
-
-   There are also some functional differences between IMAP2 and DMSP.
-   DMSP has functions for sending messages, printing messages, listing
-   mailboxes, and changing passwords; these are done outside IMAP2.
-   DMSP has 16 binary flags of which 8 are defined by the system.  IMAP2
-   has flag names; there are currently 5 defined system flag names and a
-   facility for some number (30 in the current implementations) of user
-   flag names.  IMAP2 has a sophisticated message search facility in the
-   server to identify interesting messages based on dates, addresses,
-   flag status, or textual contents without compelling the client to
-   fetch this data for every message.
-
-   It was felt that maintaining state on the client is advantageous only
-   in those cases where the client is only used by a single user, or if
-   there is some means on the client to restrict access to another
-   user's data.  It can be a serious disadvantage in an environment in
-   which multiple users routinely use the same client, the same user
-   routinely uses different clients, and where there are no access
-   restrictions on the client.  It was also observed that most user mail
-   access is to a small set of "interesting" messages, which were either
-   new mail or mail based on some user-selected criteria.  Consequently,
-   IMAP2 was designed to easily identify those "interesting" messages so
-   that the client could fetch the state of those messages and not those
-   that were not "interesting".
-
-The Protocol
-
-   The IMAP2 protocol consists of a sequence of client commands and
-   server responses, with server data interspersed between the
-   responses.  Unlike most Internet protocols, commands and responses
-   are tagged.  That is, a command begins with a unique identifier
-   (typically a short alphanumeric sequence such as a Lisp "gensym"
-   function would generate e.g., A0001, A0002, etc.), called a tag.  The
-   response to this command is given the same tag from the server.
-   Additionally, the server may send an arbitrary amount of "unsolicited
-   data", which is identified by the special reserved tag of "*".  There
-
-
-
-Crispin                                                         [Page 5]
-
-RFC 1176                         IMAP2                       August 1990
-
-
-   is another special reserved tag, "+", discussed below.
-
-   The server must be listening for a connection.  When a connection is
-   opened the server sends an unsolicited OK response as a greeting
-   message and then waits for commands.
-
-   The client opens a connection and waits for the greeting.  The client
-   must not send any commands until it has received the greeting from
-   the server.
-
-   Once the greeting has been received, the client may begin sending
-   commands and is not under any obligation to wait for a server
-   response to this command before sending another command, within the
-   constraints of TCP flow control.  When commands are received the
-   server acts on them and responds with command responses, often
-   interspersed with data.  The effect of a command can not be
-   considered complete until a command response with a tag matching the
-   command is received from the server.
-
-   Although all known IMAP2 servers at the time of this writing process
-   commands to completion before processing the next command, it is not
-   required that a server do so.  However, many commands can affect the
-   results of other commands, creating processing-order dependencies
-   (or, for SEARCH and FIND, ambiguities about which data is associated
-   with which command).  All implementations that operate in a non-
-   lockstep fashion must recognize such dependencies and defer or
-   synchronize execution as necessary.  In general, such multi-
-   processing is limited to consecutive FETCH commands.
-
-   Generally, the first command from the client is a LOGIN command with
-   user name and password arguments to establish identity and access
-   authorization, unless this has already been accomplished through
-   other means, e.g. Kerberos.  Until identity and access authorization
-   have been established, no operations other than LOGIN or LOGOUT are
-   permitted.
-
-   Once identity and authorization have been established, the client
-   must send a SELECT command to access the desired mailbox; no mailbox
-   is selected by default.  SELECT's argument is implementation-
-   dependent; however the word "INBOX" must be implemented to mean the
-   primary or default mailbox for this user, independent of any other
-   server semantics.  On a successful SELECT, the server will send a
-   list of valid flags, number of messages, and number of messages
-   arrived since last access for this mailbox as unsolicited data,
-   followed by an OK response.  The client may terminate access to this
-   mailbox and access a different one with another SELECT command.
-
-   The client reads mailbox information with FETCH commands.  The actual
-
-
-
-Crispin                                                         [Page 6]
-
-RFC 1176                         IMAP2                       August 1990
-
-
-   data is transmitted via the unsolicited data mechanism (that is,
-   FETCH should be viewed as instructing the server to include the
-   desired data along with any other data it wishes to transmit to the
-   client).  There are three major categories of data that may be
-   fetched.
-
-   The first category is data that is associated with a message as an
-   entity in the mailbox.  There are now three such items of data: the
-   "internal date", the "RFC 822 size", and the "flags".  The internal
-   date is the date and time that the message was placed in the mailbox.
-   The RFC 822 size is subject to deletion in the future; it is the size
-   in bytes of the message, expressed as an RFC 822 text string.
-   Current clients only use it as part of a status display line.  The
-   flags are a list of status flags associated with the message (see
-   below).  All the first category data can be fetched by using the
-   macro-fetch word "FAST"; that is, "FAST" expands to "(FLAGS
-   INTERNALDATE RFC822.SIZE)".
-
-   The second category is that data that describes the composition and
-   delivery information of a message; that is, information such as the
-   message sender, recipient lists, message-ID, subject, etc.  This is
-   the information that is stored in the message header in RFC 822
-   format message and is traditionally called the "envelope".  [Note:
-   this should not be confused with the SMTP (RFC 821) envelope, which
-   is strictly limited to delivery information.]  IMAP2 defines a
-   structured and unambiguous representation for the envelope that is
-   particularly suited for Lisp-based parsers.  A client can use the
-   envelope for operations such as replying and not worry about RFC 822
-   at all.  Envelopes are discussed in more detail below.  The first two
-   categories of data can be fetched together by using the macro-fetch
-   word "ALL"; that is, "ALL" expands to "(FLAGS INTERNALDATE
-   RFC822.SIZE ENVELOPE)".
-
-   The third category is that data that is intended for direct human
-   viewing.  The present RFC 822 based IMAP2 defines three such items:
-   RFC822.HEADER, RFC822.TEXT, and RFC822 (the latter being the two
-   former appended together in a single text string).  RFC822.HEADER is
-   the "raw", unprocessed RFC 822 format header of the message.
-   Fetching "RFC822" is equivalent to fetching the RFC 822
-   representation of the message as stored on the mailbox without any
-   filtering or processing.
-
-   An intelligent client will "FETCH ALL" for some (or all) of the
-   messages in the mailbox for use as a presentation menu, and when the
-   user wishes to read a particular message will "FETCH RFC822.TEXT" to
-   get the message body.  A more primitive client could, of course,
-   simply "FETCH RFC822" a`la POP-type functionality.
-
-
-
-
-Crispin                                                         [Page 7]
-
-RFC 1176                         IMAP2                       August 1990
-
-
-   The client can alter certain data (currently only the flags) by a
-   STORE command.  As an example, a message is deleted from a mailbox by
-   a STORE command that includes the \DELETED flag as a flag being set.
-
-   Other client operations include copying a message to another mailbox
-   (COPY command), permanently removing deleted messages (EXPUNGE
-   command), checking for new messages (CHECK command), and searching
-   for messages that match certain criteria (SEARCH command).
-
-   The client terminates the session with the LOGOUT command.  The
-   server returns a "BYE" followed by an "OK".
-
-   A Typical Scenario
-
-           Client                          Server
-           ------                          ------
-                                       {Wait for Connection}
-       {Open Connection}        -->
-                                   <-- * OK IMAP2 Server Ready
-                                       {Wait for command}
-       A001 LOGIN Fred Secret   -->
-                                   <-- A001 OK User Fred logged in
-                                       {Wait for command}
-       A002 SELECT INBOX        -->
-                                   <-- * FLAGS (Meeting Notice \Answered
-                                                \Flagged \Deleted \Seen)
-                                   <-- * 19 EXISTS
-                                   <-- * 2 RECENT
-                                   <-- A0002 OK Select complete
-                                       {Wait for command}
-       A003 FETCH 1:19 ALL      -->
-                                   <-- * 1 Fetch (......)
-                                           ...
-                                   <-- * 18 Fetch (......)
-                                   <-- * 19 Fetch (......)
-                                   <-- A003 OK Fetch complete
-                                       {Wait for command}
-       A004 FETCH 8 RFC822.TEXT -->
-                                   <-- * 8 Fetch (RFC822.TEXT {893}
-                                           ...893 characters of text...
-                                   <-- )
-                                   <-- A004 OK Fetch complete
-                                       {Wait for command}
-
-
-
-
-
-
-
-
-Crispin                                                         [Page 8]
-
-RFC 1176                         IMAP2                       August 1990
-
-
-       A005 STORE 8 +Flags \Deleted -->
-                                   <-- * 8 Store (Flags (\Deleted
-                                                  \Seen))
-                                   <-- A005 OK Store complete
-                                       {Wait for command}
-       A006 EXPUNGE             -->
-                                   <-- * 19 EXISTS
-                                   <-- * 8 EXPUNGE
-                                   <-- * 18 EXISTS
-                                   <-- A006 Expunge complete
-                                       {Wait for command}
-       A007 LOGOUT              -->
-                                   <-- * BYE IMAP2 server quitting
-                                   <-- A007 OK Logout complete
-       {Close Connection}       --><-- {Close connection}
-                                       {Go back to start}
-Conventions
-
-   The following terms are used in a meta-sense in the syntax
-   specification below:
-
-      An ASCII-STRING is a sequence of arbitrary ASCII characters.
-
-      An ATOM is a sequence of ASCII characters delimited by SP or CRLF.
-
-      A CHARACTER is any ASCII character except """", "{", CR, LF, "%",
-      or "\".
-
-      A CRLF is an ASCII carriage-return character followed immediately
-      by an ASCII linefeed character.
-
-      A NUMBER is a sequence of the ASCII characters that represent
-      decimal numerals ("0" through "9"), delimited by SP, CRLF, ",", or
-      ":".
-
-      A SP is the ASCII space character.
-
-      A TEXT_LINE is a human-readable sequence of ASCII characters up to
-      but not including a terminating CRLF.
-
-   A common field in the IMAP2 protocol is a STRING, which may be an
-   ATOM, QUOTED-STRING (a sequence of CHARACTERs inside double-quotes),
-   or a LITERAL.  A literal consists of an open brace ("{"), a number, a
-   close brace ("}"), a CRLF, and then an ASCII-STRING of n characters,
-   where n is the value of the number inside the brace.  In general, a
-   string should be represented as an ATOM or QUOTED-STRING if at all
-   possible.  The semantics for QUOTED-STRING or LITERAL are checked
-   before those for ATOM; therefore an ATOM used in a STRING may only
-
-
-
-Crispin                                                         [Page 9]
-
-RFC 1176                         IMAP2                       August 1990
-
-
-   contain CHARACTERs.  Literals are most often sent from the server to
-   the client; in the rare case of a client to server literal there is a
-   special consideration (see the "+ text" response below).
-
-   Another important field is the SEQUENCE, which identifies a set of
-   messages by consecutive numbers from 1 to n where n is the number of
-   messages in the mailbox.  A sequence may consist of a single number,
-   a pair of numbers delimited by colon (equivalent to all numbers
-   between those two numbers), or a list of single numbers or number
-   pairs.  For example, the sequence 2,4:7,9,12:15 is equivalent to
-   2,4,5,6,7,9,12,13,14,15 and identifies all those messages.
-
-Definitions of Commands and Responses
-
-     Summary of Commands and Responses
-
-       Commands                            ||      Responses
-       --------                            ||      -------
-       tag NOOP                            ||      tag OK text
-       tag LOGIN user password             ||      tag NO text
-       tag LOGOUT                          ||      tag BAD text
-       tag SELECT mailbox                  ||      * number message_data
-       tag BBOARD bulletin_board           ||      * FLAGS flag_list
-       tag FIND MAILBOXES pattern          ||      * SEARCH sequence
-       tag FIND BBOARDS pattern            ||      * BBOARD string
-       tag CHECK                           ||      * MAILBOX string
-       tag EXPUNGE                         ||      * BYE text
-       tag COPY sequence mailbox           ||      * OK text
-       tag FETCH sequence data             ||      * NO text
-       tag STORE sequence data value       ||      * BAD text
-       tag SEARCH search_program           ||      + text
-
-Commands
-
-   tag NOOP
-
-      The NOOP command returns an OK to the client.  By itself, it does
-      nothing, but certain things may happen as side effects.  For
-      example, server implementations that implicitly check the mailbox
-      for new mail may do so as a result of this command.  The primary
-      use of this command is to for the client to see if the server is
-      still alive (and notify the server that the client is still alive,
-      for those servers that have inactivity autologout timers).
-
-   tag LOGIN user password
-
-      The LOGIN command identifies the user to the server and carries
-      the password authenticating this user.  This information is used
-
-
-
-Crispin                                                        [Page 10]
-
-RFC 1176                         IMAP2                       August 1990
-
-
-      by the server to control access to the mailboxes.
-
-      EXAMPLE:  A001 LOGIN SMITH SESAME
-      logs in as user SMITH with password SESAME.
-
-   tag LOGOUT
-
-      The LOGOUT command informs the server that the client is done with
-      the session.  The server should send an unsolicited BYE response
-      before the (tagged) OK response, and then close the network
-      connection.
-
-   tag SELECT mailbox
-
-      The SELECT command selects a particular mailbox.  The server must
-      check that the user is permitted read access to this mailbox.
-      Before returning an OK to the client, the server must send the
-      following unsolicited data to the client:
-         FLAGS        mailbox's defined flags
-         <n> EXISTS   the number of messages in the mailbox
-         <n> RECENT   the number of new messages in the mailbox
-      in order to define the initial state of the mailbox at the client.
-
-      Multiple SELECT commands are permitted in a session, in which case
-      the previous mailbox is automatically deselected when a new SELECT
-      is made.
-
-      The default mailbox for the SELECT command is INBOX, which is a
-      special name reserved to mean "the primary mailbox for this user
-      on this server".  The format of other mailbox names is operating
-      system dependent (as of this writing, it reflects the filename
-      path of the mailbox file on the current servers).
-
-      It is customary, although not required, for the text of an OK
-      response to the SELECT command to begin with either "[READ-ONLY]"
-      or "[READ-WRITE]" to show the mailbox's access status.
-
-      EXAMPLE: A002 SELECT INBOX
-      selects the default mailbox.
-
-   tag BBOARD bulletin_board
-
-      The BBOARD command is equivalent to SELECT, and returns the same
-      output.  However, it differs from SELECT in that its argument is a
-      shared mailbox (bulletin board) name instead of an ordinary
-      mailbox.  The format of a bulletin name is implementation
-      specific, although it is strongly encouraged to use something that
-      resembles a name in a generic sense and not a file or mailbox name
-
-
-
-Crispin                                                        [Page 11]
-
-RFC 1176                         IMAP2                       August 1990
-
-
-      on the particular system.  There is no requirement that a bulletin
-      board name be a mailbox name or a file name (in particular, Unix
-      netnews has a completely different namespace from mailbox or file
-      names).
-
-      Support for BBOARD is optional.
-
-   tag FIND MAILBOXES pattern
-
-      The FIND MAILBOXES command accepts as an argument a pattern
-      (including wildcards) that specifies some set of mailbox names
-      that are usable by the SELECT command.  The format of mailboxes is
-      implementation dependent.  The special mailbox name INBOX is not
-      included in the output.
-
-      Two wildcard characters are defined; "*" specifies any number
-      (including zero) characters may match at this position and "%"
-      specifies a single character may match at this position.  For
-      example, FOO*BAR will match FOOBAR, FOOD.ON.THE.BAR and FOO.BAR,
-      whereas FOO%BAR will match only FOO.BAR.  "*" will match all
-      mailboxes.
-
-      The FIND MAILBOXES command will return some set of unsolicited
-      MAILBOX replies that have as their value a single mailbox name.
-
-      EXAMPLE:  A002 FIND MAILBOXES *
-                * MAILBOX FOOBAR
-                * MAILBOX GENERAL
-                A002 FIND completed
-
-      Although the use of explicit file or path names for mailboxes is
-      discouraged by this standard, it may be unavoidable.  It is
-      important that the value returned in the MAILBOX unsolicited reply
-      be usable in the SELECT command without remembering any path
-      specification that may have been used in the FIND MAILBOXES
-      pattern.
-
-      Support for FIND MAILBOXES is optional.  If a client's attempt
-      returns BAD as a response then the client can make no assumptions
-      about what mailboxes exist on the server other than INBOX.
-
-   tag FIND BBOARDS pattern
-
-      The FIND BBOARDS command accepts as an argument a pattern that
-      specifies some set of bulletin board names that are usable by the
-      BBOARD command.  Wildcards are permitted as in FIND MAILBOXES.
-
-      The FIND BBOARDS command will return some set of unsolicited
-
-
-
-Crispin                                                        [Page 12]
-
-RFC 1176                         IMAP2                       August 1990
-
-
-      BBOARD replies that have as their value a single bulletin board
-      name.
-
-      EXAMPLE:  A002 FIND BBOARDS *
-                * BBOARD FOOBAR
-                * BBOARD GENERAL
-                A002 FIND completed
-
-      Support for FIND BBOARDS is optional.  If a client's attempt
-      returns BAD as a response then the client can make no assumptions
-      about what bulletin boards exist on the server, or that they exist
-      at all.
-
-   tag CHECK
-
-      The CHECK command forces a check for new messages and a rescan of
-      the mailbox for internal change for those implementations that
-      allow multiple simultaneous read/write access to the same mailbox.
-      It is recommend that periodic implicit checks for new mail be done
-      by servers as well.  The server should send unsolicited EXISTS and
-      RECENT responses with the current status before returning an OK to
-      the client.
-
-   tag EXPUNGE
-
-      The EXPUNGE command permanently removes all messages with the
-      \DELETED flag set in its flags from the mailbox.  Before returning
-      an OK to the client, for each message that is removed, an
-      unsolicited EXPUNGE response is sent.  The message number for each
-      successive message in the mailbox is immediately decremented by 1;
-      this means that if the last 5 messages in a 9-message mail file
-      are expunged you will receive 5 unsolicited EXPUNGE responses for
-      message 5.  To ensure mailbox integrity and server/client
-      synchronization, it is recommended that the server do an implicit
-      check before commencing the expunge and again when the expunge is
-      completed.  Furthermore, if the server allows multiple
-      simultaneous access to the same mail file the server must lock the
-      mail file for exclusive access while an expunge is taking place.
-
-      EXPUNGE is not allowed if the user does not have write access to
-      this mailbox.
-
-   tag COPY sequence mailbox
-
-      The COPY command copies the specified message(s) to the specified
-      destination mailbox.  If the destination mailbox does not exist,
-      the server should create it.  Before returning an OK to the
-      client, the server should return an unsolicited <n> COPY response
-
-
-
-Crispin                                                        [Page 13]
-
-RFC 1176                         IMAP2                       August 1990
-
-
-      for each message copied.  A copy should set the \SEEN flag for all
-      messages that were successfully copied (provided, of course, that
-      the user has write access to this mailbox).
-
-      EXAMPLE:  A003 COPY 2:4 MEETING
-      copies messages 2, 3, and 4 to mailbox "MEETING".
-
-      COPY is not allowed if the user does not have write access to the
-      destination mailbox.
-
-   tag FETCH sequence data
-
-      The FETCH command retrieves data associated with a message in the
-      mailbox.  The data items to be fetched may be either a single atom
-      or an S-expression list.  The currently defined data items that
-      can be fetched are:
-
-      ALL             Macro equivalent to:
-                      (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE)
-
-      ENVELOPE        The envelope of the message.  The envelope is
-                      computed by the server by parsing the RFC 822
-                      header into the component parts, defaulting
-                      various fields as necessary.
-
-      FAST            Macro equivalent to:
-                      (FLAGS INTERNALDATE RFC822.SIZE)
-
-      FLAGS           The flags that are set for this message.
-                      This may include the following system flags:
-
-                              \RECENT    Message arrived since the
-                                          previous time this mailbox
-                                          was read
-                              \SEEN      Message has been read
-                              \ANSWERED  Message has been answered
-                              \FLAGGED   Message is "flagged" for
-                                          urgent/special attention
-                              \DELETED   Message is "deleted" for
-                                          removal by later EXPUNGE
-
-      INTERNALDATE    The date and time the message was written to
-                      the mailbox.
-
-
-
-
-
-
-
-
-Crispin                                                        [Page 14]
-
-RFC 1176                         IMAP2                       August 1990
-
-
-      RFC822          The message in RFC 822 format.  The \SEEN
-                      flag is implicitly set; if this causes the
-                      flags to change they should be included as
-                      part of the fetch results.  This is the
-                      concatenation of RFC822.HEADER and RFC822.TEXT.
-
-      RFC822.HEADER   The "raw" RFC 822 format header of the message
-                      as stored on the server.
-
-      RFC822.SIZE     The number of characters in the message as
-                      expressed in RFC 822 format.
-
-      RFC822.TEXT     The text body of the message, omitting the
-                      RFC 822 header.  The \SEEN flag is implicitly
-                      set as with RFC822 above.
-
-      EXAMPLES:
-
-      A003 FETCH 2:4 ALL
-         fetches the flags, internal date, RFC 822 size, and envelope
-         for messages 2, 3, and 4.
-
-      A004 FETCH 3 RFC822
-         fetches the RFC 822 representation for message 3.
-
-      A005 FETCH 4 (FLAGS RFC822.HEADER)
-         fetches the flags and RFC 822 format header for message 4.
-
-      Note: An attempt to FETCH already-transmitted data may have no
-      result.  See the Implementation Discussion below.
-
-   tag STORE sequence data value
-
-      The STORE command alters data associated with a message in the
-      mailbox.  The currently defined data items that can be stored are:
-
-         FLAGS           Replace the flags for the message with the
-                         argument (in flag list format).
-
-         +FLAGS          Add the flags in the argument to the
-                         message's flag list.
-
-         -FLAGS          Remove the flags in the argument from the
-                         message's flag list.
-
-      STORE is not allowed if the user does not have write access to
-      this mailbox.
-
-
-
-
-Crispin                                                        [Page 15]
-
-RFC 1176                         IMAP2                       August 1990
-
-
-      EXAMPLE:  A003 STORE 2:4 +FLAGS (\DELETED)
-      marks messages 2, 3, and 4 for deletion.
-
-   tag SEARCH search_criteria
-
-      The SEARCH command searches the mailbox for messages that match
-      the given set of criteria.  The unsolicited SEARCH <1#number>
-      response from the server is a list of messages that express the
-      intersection (AND function) of all the messages which match that
-      criteria.  For example,
-              A003 SEARCH DELETED FROM "SMITH" SINCE 1-OCT-87
-      returns the message numbers for all deleted messages from Smith
-      that were placed in the mail file since October 1, 1987.
-
-      In all search criteria which use strings, a message matches the
-      criteria if the string is a case-independent substring of that
-      field.  The currently defined criteria are:
-
-      ALL             All messages in the mailbox; the default
-                      initial criterion for ANDing.
-
-      ANSWERED        Messages with the \ANSWERED flag set.
-
-      BCC string      Messages which contain the specified string
-                      in the envelope's BCC field.
-
-      BEFORE date     Messages whose internal date is earlier than
-                      the specified date.
-
-      BODY string     Messages which contain the specified string
-                      in the body of the message.
-
-      CC string       Messages which contain the specified string
-                      in the envelope's CC field.
-
-      DELETED         Messages with the \DELETED flag set.
-
-      FLAGGED         Messages with the \FLAGGED flag set.
-
-      FROM string     Messages which contain the specified string
-                      in the envelope's FROM field.
-
-      KEYWORD flag    Messages with the specified flag set.
-
-      NEW             Messages which have the \RECENT flag set but
-                      not the \SEEN flag.  This is functionally
-                      equivalent to "RECENT UNSEEN".
-
-
-
-
-Crispin                                                        [Page 16]
-
-RFC 1176                         IMAP2                       August 1990
-
-
-      OLD             Messages which do not have the \RECENT flag
-                      set.
-
-      ON date         Messages whose internal date is the same as
-                      the specified date.
-
-      RECENT          Messages which have the \RECENT flag set.
-
-      SEEN            Messages which have the \SEEN flag set.
-
-      SINCE date      Messages whose internal date is later than
-                      the specified date.
-
-      SUBJECT string  Messages which contain the specified string
-                      in the envelope's SUBJECT field.
-
-      TEXT string     Messages which contain the specified string.
-
-      TO string       Messages which contain the specified string in
-                      the envelope's TO field.
-
-      UNANSWERED      Messages which do not have the \ANSWERED flag
-                      set.
-
-      UNDELETED       Messages which do not have the \DELETED flag
-                      set.
-
-      UNFLAGGED       Messages which do not have the \FLAGGED flag
-                      set.
-
-      UNKEYWORD flag  Messages which do not have the specified flag
-                      set.
-
-      UNSEEN          Messages which do not have the \SEEN flag set.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin                                                        [Page 17]
-
-RFC 1176                         IMAP2                       August 1990
-
-
-Responses
-
-   tag OK text
-
-      This response identifies successful completion of the command with
-      that tag.  The text is a line of human-readable text that may be
-      useful in a protocol telemetry log for debugging purposes.
-
-   tag NO text
-
-      This response identifies unsuccessful completion of the command
-      with that tag.  The text is a line of human-readable text that
-      probably should be displayed to the user in an error report by the
-      client.
-
-   tag BAD text
-
-      This response identifies faulty protocol received from the client;
-      The text is a line of human-readable text that should be recorded
-      in any telemetry as part of a bug report to the maintainer of the
-      client.
-
-   * number message_data
-
-      This response occurs as a result of several different commands.
-      The message_data is one of the following:
-
-      EXISTS  The specified number of messages exists in the mailbox.
-
-      RECENT  The specified number of messages have arrived since the
-              previous time this mailbox was read.
-
-      EXPUNGE The specified message number has been permanently
-              removed from the mailbox, and the next message in the
-              mailbox (if any) becomes that message number.
-
-      STORE data
-              Obsolete and functionally equivalent to FETCH.
-
-      FETCH data
-              This is the principle means by which data about a
-              message is returned to the client.  The data is in a
-              Lisp-like S-expression property list form.  The current
-              properties are:
-
-         ENVELOPE     An S-expression format list that describes the
-                      envelope of a message.  The envelope is computed
-                      by the server by parsing the RFC 822 header into
-
-
-
-Crispin                                                        [Page 18]
-
-RFC 1176                         IMAP2                       August 1990
-
-
-                      the component parts, defaulting various fields
-                      as necessary.
-
-                      The fields of the envelope are in the following
-                      order: date, subject, from, sender, reply-to, to,
-                      cc, bcc, in-reply-to, and message-id.  The date,
-                      subject, in-reply-to, and message-id fields are
-                      strings.  The from, sender, reply-to, to, cc,
-                      and bcc fields are lists of addresses.
-
-                      An address is an S-expression format list that
-                      describes an electronic mail address.  The fields
-                      of an address are in the following order:
-                      personal name, source-route (a.k.a. the
-                      at-domain-list in SMTP), mailbox name, and
-                      host name.
-
-                      Any field of an envelope or address that is
-                      not applicable is presented as the atom NIL.
-                      Note that the server must default the reply-to
-                      and sender fields from the from field; a client is
-                      not expected to know to do this.
-
-         FLAGS        An S-expression format list of flags that are set
-                      for this message.  This may include the following
-                      system flags:
-
-                      \RECENT       Message arrived since the
-                                     previous time this mailbox
-                                     was read
-                      \SEEN         Message has been read
-                      \ANSWERED     Message has been answered
-                      \FLAGGED      Message is "flagged" for
-                                     urgent/special attention
-                      \DELETED      Message is "deleted" for
-                                     removal by later EXPUNGE
-
-         INTERNALDATE  A string containing the date and time the
-                       message was written to the mailbox.
-
-         RFC822        A string expressing the message in RFC 822
-                       format.
-
-         RFC822.HEADER A string expressing the RFC 822 format
-                       header of the message
-
-         RFC822.SIZE   A number indicating the number of
-                       characters in the message as expressed
-
-
-
-Crispin                                                        [Page 19]
-
-RFC 1176                         IMAP2                       August 1990
-
-
-                       in RFC 822 format.
-
-         RFC822.TEXT   A string expressing the text body of the
-                       message, omitting the RFC 822 header.
-
-   * FLAGS flag_list
-
-      This response occurs as a result of a SELECT command.  The flag
-      list are the list of flags (at a minimum, the system-defined
-      flags) that are applicable for this mailbox.  Flags other than the
-      system flags are a function of the server implementation.
-
-   * SEARCH number(s)
-
-      This response occurs as a result of a SEARCH command.  The
-      number(s) refer to those messages that match the search criteria.
-      Each number is delimited by a space, e.g., "SEARCH 2 3 6".
-
-   * BBOARD string
-
-      This response occurs as a result of a FIND BBOARDS command.  The
-      string is a bulletin board name that matches the pattern in the
-      command.
-
-   * MAILBOX string
-
-      This response occurs as a result of a FIND MAILBOXES command.  The
-      string is a mailbox name that matches the pattern in the command.
-
-   * BYE text
-
-      This response identifies that the server is about to close the
-      connection.  The text is a line of human-readable text that should
-      be displayed to the user in a status report by the client.  This
-      may be sent as part of a normal logout sequence, or as a panic
-      shutdown announcement by the server.  It is also used by some
-      servers as an announcement of an inactivity autologout.
-
-   * OK text
-
-      This response identifies normal operation on the server.  No
-      special action by the client is called for, however, the text
-      should be displayed to the user in some fashion.  This is
-      currently only used by servers at startup as a greeting message to
-      show they are ready to accept the first command.
-
-
-
-
-
-
-Crispin                                                        [Page 20]
-
-RFC 1176                         IMAP2                       August 1990
-
-
-   * NO text
-
-      This response identifies a warning from the server that does not
-      affect the overall results of any particular request.  The text is
-      a line of human-readable text that should be presented to the user
-      as a warning of improper operation.
-
-   * BAD text
-
-      This response identifies a serious error at the server; it may
-      also indicate faulty protocol from the client in which a tag could
-      not be parsed.  The text is a line of human-readable text that
-      should be presented to the user as a serious or possibly fatal
-      error.  It should also be recorded in any telemetry as part of a
-      bug report to the maintainer of the client and server.
-
-   + text
-
-      This response identifies that the server is ready to accept the
-      text of a literal from the client.  Normally, a command from the
-      client is a single text line.  If the server detects an error in
-      the command, it can simply discard the remainder of the line.  It
-      cannot do this for commands that contain literals, since a literal
-      can be an arbitrarily long amount of text, and the server may not
-      even be expecting a literal.  This mechanism is provided so the
-      client knows not to send a literal until the server expects it,
-      preserving client/server synchronization.
-
-      In practice, this condition is rarely encountered.  In the current
-      protocol, the only client command likely to contain a literal is
-      the LOGIN command.  Consider a server that validates the user
-      before checking the password.  If the password contains "funny"
-      characters and hence is sent as a literal, then if the user is
-      invalid an error would occur before the password is parsed.
-
-      No such synchronization protection is provided for literals sent
-      from the server to the client, for performance reasons.  Any
-      synchronization problems in this direction would be caused by a
-      bug in the client or server.
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin                                                        [Page 21]
-
-RFC 1176                         IMAP2                       August 1990
-
-
-Sample IMAP2 session
-
-   The following is a transcript of an IMAP2 session.  Server output is
-   identified by "S:" and client output by "U:".  In cases where lines
-   are too long to fit within the boundaries of this document, the line
-   is continued on the next line.
-
-   S:   * OK SUMEX-AIM.Stanford.EDU Interim Mail Access Protocol II Service
-         6.1(349) at Thu, 9 Jun 88 14:58:30 PDT
-   U:   a001 login crispin secret
-   S:   a002 OK User CRISPIN logged in at Thu, 9 Jun 88 14:58:42 PDT, job 76
-   U:   a002 select inbox
-   S:   * FLAGS (Bugs SF Party Skating Meeting Flames Request AI Question
-         Note \XXXX \YYYY \Answered \Flagged \Deleted \Seen)
-   S:   * 16 EXISTS
-   S:   * 0 RECENT
-   S:   a002 OK Select complete
-   U:   a003 fetch 16 all
-   S:   * 16 Fetch (Flags (\Seen) InternalDate " 9-Jun-88 12:55:44 PDT"
-         RFC822.Size 637 Envelope ("Sat, 4 Jun 88 13:27:11 PDT"
-         "INFO-MAC Mail Message" (("Larry Fagan" NIL "FAGAN"
-         "SUMEX-AIM.Stanford.EDU")) (("Larry Fagan" NIL "FAGAN"
-         "SUMEX-AIM.Stanford.EDU")) (("Larry Fagan" NIL "FAGAN"
-         "SUMEX-AIM.Stanford.EDU")) ((NIL NIL "rindflEISCH"
-         "SUMEX-AIM.Stanford.EDU")) NIL NIL NIL
-         "<12403828905.13.FAGAN@SUMEX-AIM.Stanford.EDU>"))
-   S:   a003 OK Fetch completed
-   U:   a004 fetch 16 rfc822
-   S:   * 16 Fetch (RFC822 {637}
-   S:   Mail-From: RINDFLEISCH created at  9-Jun-88 12:55:43
-   S:   Mail-From: FAGAN created at  4-Jun-88 13:27:12
-   S:   Date: Sat, 4 Jun 88 13:27:11 PDT
-   S:   From: Larry Fagan  <FAGAN@SUMEX-AIM.Stanford.EDU>
-   S:   To: rindflEISCH@SUMEX-AIM.Stanford.EDU
-   S:   Subject: INFO-MAC Mail Message
-   S:   Message-ID: <12403828905.13.FAGAN@SUMEX-AIM.Stanford.EDU>
-   S:   ReSent-Date: Thu, 9 Jun 88 12:55:43 PDT
-   S:   ReSent-From: TC Rindfleisch <Rindfleisch@SUMEX-AIM.Stanford.EDU>
-   S:   ReSent-To: Yeager@SUMEX-AIM.Stanford.EDU,
-         Crispin@SUMEX-AIM.Stanford.EDU
-   S:   ReSent-Message-ID:
-         <12405133897.80.RINDFLEISCH@SUMEX-AIM.Stanford.EDU>
-   S:
-   S:   The file is <info-mac>usenetv4-55.arc  ...
-   S:   Larry
-   S:   -------
-   S:   )
-   S:   a004 OK Fetch completed
-
-
-
-Crispin                                                        [Page 22]
-
-RFC 1176                         IMAP2                       August 1990
-
-
-   U:   a005 logout
-   S:   * BYE DEC-20 IMAP II server terminating connection
-   S:   a005 OK SUMEX-AIM.Stanford.EDU Interim Mail Access Protocol
-         Service logout
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin                                                        [Page 23]
-
-RFC 1176                         IMAP2                       August 1990
-
-
-Implementation Discussion
-
-   There are several advantages to the scheme of tags and unsolicited
-   responses.  First, the infamous synchronization problems of SMTP and
-   similar protocols do not happen with tagged commands; a command is
-   not considered satisfied until a response with the same tag is seen.
-   Tagging allows an arbitrary amount of other responses ("unsolicited"
-   data) to be sent by the server with no possibility of the client
-   losing synchronization.  Compare this with the problems that FTP or
-   SMTP clients have with continuation, partial completion, and
-   commentary reply codes.
-
-   Another advantage is that a non-lockstep client implementation is
-   possible.  The client could send a command, and entrust the handling
-   of the server responses to a different process that would signal the
-   client when the tagged response comes in.  Under certain
-   circumstances, the client may have more than one command outstanding.
-
-   It was observed that synchronization problems can occur with literals
-   if the literal is not recognized as such.  Fortunately, the cases in
-   which this can happen are rare; a mechanism (the special "+" tag
-   response) was introduced to handle those few cases.  The proper way
-   to address this problem is probably to move towards a record-oriented
-   architecture instead of the text stream model provided by TCP.
-
-   An IMAP2 client must maintain a local cache of data from the mailbox.
-   This cache is an incomplete model of the mailbox, and at startup is
-   empty.  A listener processes all unsolicited data, and updates the
-   cache based on this data.  If a tagged response arrives, the listener
-   unblocks the process that sent the tagged request.
-
-   Unsolicited data needs some discussion.  Unlike most protocols, in
-   which the server merely does the client's bidding, an IMAP2 server
-   has a semi-autonomous role.  By sending "unsolicited data", the
-   server is in effect sending a command to the client -- to update or
-   extend the client's cache with new information from the server.  In
-   other words, a "fetch" command is merely a request to the server to
-   ensure that the client's cache has the most up-to-date version of the
-   requested information.  A server acknowledgement to the "fetch" is a
-   statement that all the requested data has been sent.
-
-   Although no current server does this, a server is not obliged by the
-   protocol to send data that it has already sent and is unchanged.  An
-   exception to this is the actual message text fetching operations
-   (RFC822, RFC822.HEADER, and RFC822.TEXT), owing to the possibly
-   excessive resource consumption of maintaining this data in a cache.
-   It can not be assumed that a FETCH will transmit any data; only that
-   an OK to the FETCH means that the client's cache has the most up-to-
-
-
-
-Crispin                                                        [Page 24]
-
-RFC 1176                         IMAP2                       August 1990
-
-
-   date information.
-
-   When a mailbox is selected, the initial unsolicited data from the
-   server arrives.  The first piece of data is the number of messages.
-   By sending a new EXISTS unsolicited data message the server causes
-   the client to resize its cache (this is how newly arrived mail is
-   handled).  If the client attempts to access information from the
-   cache, it will encounter empty spots that will trigger "fetch"
-   requests.  The request would be sent, some unsolicited data including
-   the answer to the fetch will flow back, and then the "fetch" response
-   will unblock the client.
-
-   People familiar with demand-paged virtual memory operating system
-   design will recognize this model as being similar to page-fault
-   handling on a demand-paged system.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin                                                        [Page 25]
-
-RFC 1176                         IMAP2                       August 1990
-
-
-Formal Syntax
-
-   The following syntax specification uses the augmented Backus-Naur
-   Form (BNF) notation as specified in RFC 822 with one exception; the
-   delimiter used with the "#" construct is a single space (SP) and not
-   a comma.
-
-   address         ::= "(" addr_name SP addr_adl SP addr_mailbox SP
-                       addr_host ")"
-
-   addr_adl        ::= nil / string
-
-   addr_host       ::= nil / string
-
-   addr_mailbox    ::= nil / string
-
-   addr_name       ::= nil / string
-
-   bboard          ::= "BBOARD" SP string
-
-   check           ::= "CHECK"
-
-   copy            ::= "COPY" SP sequence SP mailbox
-
-   data            ::= ("FLAGS" SP flag_list / "SEARCH" SP 1#number /
-                       "BYE" SP text_line / "OK" SP text_line /
-                       "NO" SP text_line / "BAD" SP text_line)
-
-   date            ::= string in form "dd-mmm-yy hh:mm:ss-zzz"
-
-   envelope        ::= "(" env_date SP env_subject SP env_from SP
-                       env_sender SP env_reply-to SP env_to SP
-                       env_cc SP env_bcc SP env_in-reply-to SP
-                       env_message-id ")"
-
-   env_bcc         ::= nil / "(" 1*address ")"
-
-   env_cc          ::= nil / "(" 1*address ")"
-
-   env_date        ::= string
-
-   env_from        ::= nil / "(" 1*address ")"
-
-   env_in-reply-to ::= nil / string
-
-   env_message-id  ::= nil / string
-
-   env_reply-to    ::= nil / "(" 1*address ")"
-
-
-
-Crispin                                                        [Page 26]
-
-RFC 1176                         IMAP2                       August 1990
-
-
-   env_sender      ::= nil / "(" 1*address ")"
-
-   env_subject     ::= nil / string
-
-   env_to          ::= nil / "(" 1*address ")"
-
-   expunge         ::= "EXPUNGE"
-
-   fetch           ::= "FETCH" SP sequence SP ("ALL" / "FAST" /
-                       fetch_att / "(" 1#fetch_att ")")
-
-   fetch_att       ::= "ENVELOPE" / "FLAGS" / "INTERNALDATE" /
-                       "RFC822" / "RFC822.HEADER" / "RFC822.SIZE" /
-                       "RFC822.TEXT"
-
-   find            ::= "FIND" SP find_option SP string
-
-   find_option     ::= "MAILBOXES" / "BBOARDS"
-
-   flag_list       ::= ATOM / "(" 1#ATOM ")"
-
-   literal         ::= "{" NUMBER "}" CRLF ASCII-STRING
-
-   login           ::= "LOGIN" SP userid SP password
-
-   logout          ::= "LOGOUT"
-
-   mailbox         ::= "INBOX" / string
-
-   msg_copy        ::= "COPY"
-
-   msg_data        ::= (msg_exists / msg_recent / msg_expunge /
-                       msg_fetch / msg_copy)
-
-   msg_exists      ::= "EXISTS"
-
-   msg_expunge     ::= "EXPUNGE"
-
-   msg_fetch       ::= ("FETCH" / "STORE") SP "(" 1#("ENVELOPE" SP
-                        envelope / "FLAGS" SP "(" 1#(recent_flag
-                        flag_list) ")" / "INTERNALDATE" SP date /
-                        "RFC822" SP string / "RFC822.HEADER" SP string /
-                        "RFC822.SIZE" SP NUMBER / "RFC822.TEXT" SP
-                        string) ")"
-
-   msg_recent      ::= "RECENT"
-
-   msg_num         ::= NUMBER
-
-
-
-Crispin                                                        [Page 27]
-
-RFC 1176                         IMAP2                       August 1990
-
-
-   nil             ::= "NIL"
-
-   noop            ::= "NOOP"
-
-   password        ::= string
-
-   recent_flag     ::= "\RECENT"
-
-   ready           ::= "+" SP text_line
-
-   request         ::= tag SP (noop / login / logout / select / check /
-                       expunge / copy / fetch / store / search / find /
-                       bboard) CRLF
-
-   response        ::= tag SP ("OK" / "NO" / "BAD") SP text_line CRLF
-
-   search          ::= "SEARCH" SP 1#("ALL" / "ANSWERED" /
-                       "BCC" SP string / "BEFORE" SP string /
-                       "BODY" SP string / "CC" SP string / "DELETED" /
-                       "FLAGGED" / "KEYWORD" SP atom / "NEW" / "OLD" /
-                       "ON" SP string / "RECENT" / "SEEN" /
-                       "SINCE" SP string / "TEXT" SP string /
-                       "TO" SP string / "UNANSWERED" / "UNDELETED" /
-                       "UNFLAGGED" / "UNKEYWORD" / "UNSEEN")
-
-   select          ::= "SELECT" SP mailbox
-
-   sequence        ::= NUMBER / (NUMBER "," sequence) / (NUMBER ":"
-                       sequence)
-
-   store           ::= "STORE" SP sequence SP store_att
-
-   store_att       ::= ("+FLAGS" SP flag_list / "-FLAGS" SP flag_list /
-                       "FLAGS" SP flag_list)
-
-   string          ::= atom / """" 1*character """" / literal
-
-   system_flags    ::= "\ANSWERED" SP "\FLAGGED" SP "\DELETED" SP
-                       "\SEEN"
-
-   tag             ::= atom
-
-   unsolicited     ::= "*" SP (msg_num SP msg_data / data) CRLF
-
-   userid          ::= string
-
-
-
-
-
-
-Crispin                                                        [Page 28]
-
-RFC 1176                         IMAP2                       August 1990
-
-
-Implementation Status
-
-   This information is current as of this writing.
-
-   The University of Washington has developed an electronic mail client
-   library called the "C-Client". It provides complete IMAP2, SMTP, and
-   local mailbox (both /usr/spool/mail and mail.txt formats) services in
-   a well-defined way to a user interface main program.  Using the C-
-   Client, the University of Washington has created an operational
-   client for BSD Unix and two operational clients (one basic, one
-   advanced) for the NeXT.
-
-   Stanford University/SUMEX has developed operational IMAP2 clients for
-   Xerox Lisp machines, Texas Instruments Explorers, and the Apple
-   Macintosh.  The core of the Macintosh client is an early version of
-   the C-Client.  SUMEX has also developed IMAP2 servers for TOPS-20 and
-   BSD Unix.
-
-   All of the above software is in production use, with enthusiastic
-   local user communities.  Active development continues on the
-   Macintosh and C-Client based clients and the BSD Unix server.  This
-   software is freely available from the University of Washington and
-   SUMEX.
-
-   IMAP2 software exists for other platforms; for example Nippon
-   Telephone and Telegraph (NTT) has developed an operational IMAP2
-   client for the NTT ELIS.  Several organizations are working on a PC
-   client.
-
-   IMAP2 can be used to access mailboxes at very remote sites, where
-   echo delays and frequent outages make TELNET and running a local mail
-   reader intolerable.  For example, from a desktop workstation on the
-   University of Washington local network the author routinely uses
-   IMAP2 to read and manage mailboxes on various University of
-   Washington local servers, at two systems at Stanford University, at a
-   Milnet site, and at a site in Tokyo, Japan.
-
-   This specification does not make any formal definition of size
-   restrictions, but the DEC-20 server has the following limitations:
-
-    . length of a mailbox: 7,077,888 characters
-    . maximum number of messages: 18,432 messages
-    . length of a command line: 10,000 characters
-    . length of the local host name: 64 characters
-    . length of a "short" argument: 39 characters
-    . length of a "long" argument: 491,520 characters
-    . maximum amount of data output in a single fetch:
-      655,360 characters
-
-
-
-Crispin                                                        [Page 29]
-
-RFC 1176                         IMAP2                       August 1990
-
-
-   To date, nobody has run up against any of these limitations, many of
-   which are substantially larger than most current user mail reading
-   programs.
-
-Acknowledgements
-
-   Bill Yeager and Rich Acuff both contributed invaluable suggestions in
-   the evolution of IMAP2 from the original IMAP.  James Rice pointed
-   out several ambiguities in the previous IMAP2 specification and
-   otherwise would not allow me to leave bad enough along.  Laurence
-   Lundblade reviewed a draft of this version and made several helpful
-   suggestions.
-
-   Many dedicated individuals have worked on IMAP2 software, including:
-   Mark Crispin, Frank Gilmurray, Christopher Lane, Hiroshi Okuno,
-   Christopher Schmidt, and Bill Yeager.
-
-   Any mistakes, flaws, or sins of omission in this IMAP2 protocol
-   specification are, however, strictly my own; and the mention of any
-   name above does not imply an endorsement.
-
-Security Considerations
-
-   Security issues are not discussed in this memo.
-
-Author's Address
-
-   Mark R. Crispin
-   Panda Programming
-   6158 Lariat Loop NE
-   Bainbridge Island, WA 98110-2020
-
-   Phone: (206) 842-2385
-
-   EMail: mrc@Tomobiki-Cho.CAC.Washington.EDU
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin                                                        [Page 30]
-
-\ No newline at end of file
diff --git a/RFC/rfc1203.txt b/RFC/rfc1203.txt
deleted file mode 100644
index a362ca88..00000000
--- a/RFC/rfc1203.txt
+++ /dev/null
@@ -1,2747 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                           J. Rice
-Request for Comments: 1203                                     Stanford
-Obsoletes: RFC 1064                                       February 1991
-
-
-              INTERACTIVE MAIL ACCESS PROTOCOL - VERSION 3
-
-Status of this Memo
-
-   This RFC suggests a method for workstations to access mail
-   dynamically from a mailbox server ("repository").  This RFC specifies
-   a standard for the SUMEX-AIM community and an Experimental Protocol
-   for the Internet community.  Discussion and suggestions for
-   improvement are requested.  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.
-
-Scope
-
-   The following document is a modified version of RFC 1064, the
-   definition of the IMAP2 protocol.  This RFC has been written
-   specifically as a counter proposal to RFC 1176, which itself proposes
-   modifications to IMAP2.  Sadly, RFC 1176 was made without internal
-   consultation with the IMAP community, so we are in a position of
-   feeling we have to present a counter proposal to what, if we do not
-   act, will become a de facto standard.  The reasons for this counter
-   proposal are numerous but fall mostly into the following categories:
-
-      - IMAP2 is insufficiently powerful for a number of server/client
-        interactions which we believe to be important.  RFC 1176
-        negligibly enhances the functionality of IMAP2.
-
-      - IMAP2 makes what we believe to be an erroneous definition for
-        unsolicited vs. solicited data.  IMAP3 as specified herein
-        attempts to correct this.  RFC 1176 makes no effort to remedy
-        these problems.
-
-      - RFC 1176 has explicitly modified the intent of RFC 1064 by
-        allowing the server to make assumptions about the client's
-        caching architecture.  We believe this to be a grave error
-        and do not support it in this proposal.
-
-      - RFC 1176 specifies a number of "optional" features in the
-        protocol without specifying a suitable metaprotocol by which
-        servers and clients can adequately negotiate over the set of
-        implemented features.  This proposal specifies a mechanism
-        by which servers and clients can come to an unambiguous
-        understanding about which features are usable by each party.
-
-
-
-Rice                                                            [Page 1]
-
-RFC 1203                         IMAP3                     February 1991
-
-
-
-      - RFC 1176 pays only lip-service to being network protocol
-        independent and, in fact assumes the use of TCP/IP.  Neither
-        RFC 1064 nor this proposal make any such assumption.
-
-   Although there are numerous other detailed objections to RFC 1176, we
-   believe that the above will serve to show that we believe strongly in
-   the importance of mailbox abstraction level mail protocols and, after
-   a couple of years of use of IMAP2 under RFC 1064 we believe that we
-   have a good enough understanding of the issues involved to be able to
-   take the next step.
-
-   It is important to take this next step because of the rapid pace of
-   both mail system and user interface development.  We believe that,
-   for IMAP not to die in its infancy, IMAP must be ready to respond to
-   emerging ISO and RFC standards in mail, such as for multi-media mail.
-   We believe that RFC 1176 not only provides a very small increment in
-   functionality over RFC 1064 but also adds a number of bugs, which
-   would be detrimental to the IMAP cause.  Thus we propose the
-   following definition for IMAP3.
-
-Compatibility notes:
-
-   In revising the IMAP2 protocol it has been our intent, wherever
-   possible to make upwards compatible changes to produce IMAP3.  There
-   were, however, some places that had to be changed incompatibly in
-   order to compensate for either ambiguities in the IMAP2 protocol as
-   defined by RFC 1064 or behavior that proved undesirable in the light
-   of experience.
-
-   It is our goal, however, that existing IMAP2 clients should still be
-   supported and that, at least for the foreseeable future, all IMAP3
-   servers will support IMAP2 behavior as their default mode.
-
-   The following are the major differences between this proposal, RFC
-   1176 and RFC 1064:
-
-      - In this proposal we specify a difference between "solicited" and
-        "unsolicited" data sent from the server.  It is generally the
-        case that data sent by the server can be sent either in response
-        to an explicit request by the client or by the server of its own
-        volition.  Any data that the server is required to sent to the
-        client as the result of a request is said to be solicited and
-        carries the same tag as the request that provoked it.  Any data
-        sent by the server to the client that is not required by the
-        protocol is said to be unsolicited and carries the special "*"
-        tag.  RFC 1176 preserves the original RFC 1064 terminology that
-        calls all such data sent by the server "unsolicited" even when
-
-
-
-Rice                                                            [Page 2]
-
-RFC 1203                         IMAP3                     February 1991
-
-
-        it is, in fact, solicited.
-
-      - This proposal introduces the experimental concept of
-        distinguishing between Generic, Canonical and Concrete keys,
-        allowing the mailbox to be viewed as a relational database
-        indexed by these keys.  This should allow the IMAP protocol
-        to evolve away from its current reliance on RFC 822.  RFC 1176
-        does not have such a unifying model.
-
-      - The SEARCH command has been changed so as to allow multiple
-        simultaneous searches to be made and to allow unsolicited
-        search messages to be sent by the server.  Such a change is
-        essential to allow more sophisticated servers that can process
-        commands asynchronously, possibly substantially delaying
-        searches over slow backing storage media, for example.  It is
-        also important to allow servers to be able to send unsolicited
-        search messages that might inform the client of interesting
-        patterns of messages, such as new and unseen mail.
-
-      - This proposal introduces a specific protocol for the negotiation
-        of protocol versions and server features.  This is important
-        because it allows client/server pairs to come to an agreement on
-        what behavior is really available to it.  RFC 1176 introduces a
-        number of "optional" commands, which are in some way analogous
-        to "feature-introduced" commands in this proposal.  The principle
-        distinction between these is that in RFC 1176 there is no way
-        for a client to discover the set of optional commands, nor is
-        there a way for it to determine whether a specific command
-        really is supported, since RFC 1176 requires the use of the
-        "BAD" response if a feature is not supported.  There is,
-        therefore, no way for the client to determine why the attempted
-        command did not work.  This also means that, for example, a
-        client cannot disable certain user commands or make them
-        invisible on menus if they are not supported, since there
-        is no way for the client to discover whether the commands are
-        indeed supported without trying to execute such a command.
-
-      - This proposal introduces a mechanism for clients to create and
-        delete user flags (keywords).  This is nor supported in either
-        RFC 1176 or RFC 1064, requiring the user to add keys manually
-        on the server, generally by editing some form of "init" file.
-
-      - RFC 1064 has no mechanism for determining whether a mailbox is
-        readonly or not.  RFC 1176 introduces a non-enforced convention
-        of encoding data about the readonly status of a mailbox in the
-        SELECT message's OK respose comment field.  This is not regular
-        with respect to the rest of the protocol, in which the comment
-        field is used for no purpose other than documentation.  This
-
-
-
-Rice                                                            [Page 3]
-
-RFC 1203                         IMAP3                     February 1991
-
-
-        proposal introduces specific protocol additions for the dynamic
-        determination and modification of the readonly/readwrite status
-        of mailboxes.
-
-Introduction
-
-   The intent of the Interactive Mail Access Protocol, Version 3 (IMAP3)
-   is to allow a (possibly unreliable) workstation or similar machine to
-   access electronic mail from a reliable mailbox server in an efficient
-   manner.
-
-   Although different in many ways from POP2 (RFC 937), IMAP3 may be
-   thought of as a functional superset of POP2, and the POP2 RFC was
-   used as a model for this RFC.  There was a cognizant reason for this;
-   RFC 937 deals with an identical problem and it was desirable to offer
-   a basis for comparison.
-
-   Like POP2, IMAP3 specifies a means of accessing stored mail and not
-   of posting mail; this function is handled by a mail transfer protocol
-   such as SMTP (RFC 821).  A comparison with the DMSP protocol of
-   PCMAIL can be found at the end of "System Model and Philosophy"
-   section.
-
-   This protocol assumes a reliable data stream such as provided by TCP
-   or any similar protocol.  When TCP is used, the IMAP server listens
-   on port 220.  When CHAOS is used the IMAP server listens for the
-   logical contact name "IMAP3".
-
-   Communication in IMAP is defined to be using the ASCII character
-   interpretation of data.  Communication using other conventions may be
-   possible by the selection of features on some servers.
-
-System Model and Philosophy
-
-   Electronic mail is a primary means of communication for the widely
-   spread SUMEX-AIM community.  The advent of distributed workstations
-   is forcing a significant rethinking of the mechanisms employed to
-   manage such mail.  With mainframes, each user tends to receive and
-   process mail at the computer he used most of the time, his "primary
-   host".  The first inclination of many users when an independent
-   workstation is placed in front of them is to begin receiving mail at
-   the workstation, and, in fact, many vendors have implemented
-   facilities to do this.  However, this approach has several
-   disadvantages:
-
-      (1)  Workstations (especially Lisp workstations) have a software
-           design that gives full control of all aspects of the system
-           to the user at the console.  As a result, background tasks,
-
-
-
-Rice                                                            [Page 4]
-
-RFC 1203                         IMAP3                     February 1991
-
-
-           like receiving mail, could well be kept from running for
-           long periods of time either because the user is asking to
-           use all of the machine's resources, or because, in the course
-           of working, the user has (perhaps accidentally) manipulated
-           the environment in such a way as to prevent mail reception.
-           This could lead to repeated failed delivery attempts by
-           outside agents.
-
-      (2)  The hardware failure of a single workstation could keep its
-           user "off the air" for a considerable time, since repair of
-           individual workstation units might be delayed.  Given the
-           growing number of workstations spread throughout office
-           environments, quick repair would not be assured, whereas a
-           centralized mainframe is generally repaired very soon after
-           failure.
-
-      (3)  It is more difficult to keep track of mailing addresses when
-           each person is associated with a distinct machine.  Consider
-           the difficulty in keeping track of a large number of postal
-           addresses or phone numbers, particularly if there was no
-           single address or phone number for an organization through
-           which you could reach any person in that organization.
-           Traditionally, electronic mail on the ARPANET involved
-           remembering a name and one of several "hosts" (machines)
-           whose name reflected the organization in which the
-           individual worked.  This was suitable at a time when most
-           organizations had only one central host.  It is less
-           satisfactory today unless the concept of a host is changed
-           to refer to an organizational entity and not a particular
-           machine.
-
-      (4)  It is very difficult to keep a multitude of heterogeneous
-           workstations working properly with complex mailing protocols,
-           making it difficult to move forward as progress is made in
-           electronic communication and as new standards emerge.  Each
-           system has to worry about receiving incoming mail, routing
-           and delivering outgoing mail, formatting, storing, and
-           providing for the stability of mailboxes over a variety of
-           possible filing and mailing protocols.
-
-   Consequently, while the workstation may be viewed as an Internet host
-   in the sense that it implements IP, it should not be viewed as the
-   entity which contains the user's mailbox.  Rather, a mail server
-   machine (sometimes called a "repository") should hold the mailbox,
-   and the workstation (hereafter referred to as a "client") should
-   access the mailbox via mail transactions.  Because the mail server
-   machine would be isolated from direct user manipulation, it could
-   achieve high software reliability easily, and, as a shared resource,
-
-
-
-Rice                                                            [Page 5]
-
-RFC 1203                         IMAP3                     February 1991
-
-
-   it could achieve high hardware reliability, perhaps through
-   redundancy.  The mail server could be used from arbitrary locations,
-   allowing users to read mail across campus, town, or country using
-   more and more commonly available clients.  Furthermore, the same user
-   may access his mailbox from different clients at different times, and
-   multiple users may access the same mailbox simultaneously.
-
-   The mail server acts an an interface among users, data storage, and
-   other mailers.  The mail access protocol is used to retrieve
-   messages, access and change properties of messages, and manage
-   mailboxes.  This differs from some approaches (e.g., Unix mail via
-   NFS) in that the mail access protocol is used for all message
-   manipulations, isolating the user and the client from all knowledge
-   of how the data storage is used.  This means that the mail server can
-   utilize the data storage in whatever way is most efficient to
-   organize the mail in that particular environment, without having to
-   worry about storage representation compatibility across different
-   machines.
-
-   In defining a mail access protocol, it is important to keep in mind
-   that the client and server form a macrosystem, in which it should be
-   possible to exploit the strong points of both while compensating for
-   each other's weaknesses.  Furthermore, it's desirable to allow for a
-   growth path beyond the hoary text-only RFC 822 protocol.  Unlike
-   POP2, IMAP3 has extensive features for remote searching and parsing
-   of messages on the server.  For example, a free text search
-   (optionally in conjunction with other searching) can be made
-   throughout the entire mailbox by the server and the results made
-   available to the client without the client having to transfer the
-   entire mailbox and searching itself.  Since remote parsing of a
-   message into a structured (and standard format) "envelope" is
-   available, a client can display envelope information and implement
-   commands such as REPLY without having any understanding of how to
-   parse RFC 822, etc., headers.
-
-   Additionally, IMAP3 offers several facilities for managing a mailbox
-   beyond the simple "delete message" functionality of POP2.
-
-   In spite of this, IMAP3 is a relatively simple protocol.  Although
-   servers should implement the full set of IMAP3 functions, a simple
-   client can be written which uses IMAP3 in much the way as a POP2
-   client.
-
-   IMAP3 differs from the DMSP protocol of PCMAIL (RFC 1056) in a more
-   fundamental manner, reflecting the differing architectures of IMAP
-   and PCMAIL.  PCMAIL is either an online ("interactive mode"), or
-   offline ("batch mode") system.  IMAP is primarily an online system in
-   which real-time and simultaneous mail access were considered
-
-
-
-Rice                                                            [Page 6]
-
-RFC 1203                         IMAP3                     February 1991
-
-
-   important.
-
-   In PCMAIL, there is a long-term client/server relationship in which
-   some mailbox state is preserved on the client.  There is a
-   registration of clients used by a particular user, and the client
-   keeps a set of "descriptors" for each message which summarize the
-   message.  The server and client synchronize their states when the
-   DMSP connection starts up, and, if a client has not accessed the
-   server for a while, the client does a complete reset (reload) of its
-   state from the server.
-
-   In IMAP, the client/server relationship lasts only for the duration
-   of the IMAP3 connection.  All mailbox state is maintained on the
-   server.  There is no registration of clients.  The function of a
-   descriptor is handled by a structured representation of the message
-   "envelope".  This structure makes it unnecessary for a client to know
-   anything about RFC 822 parsing.  There is no synchronization since
-   the client does not remember state between IMAP3 connections.  This
-   is not a problem since in general the client never needs the entire
-   state of the mailbox in a single session, therefore there isn't much
-   overhead in fetching the state information that is needed as it is
-   needed.
-
-   There are also some functional differences between IMAP3 and DMSP.
-   DMSP has functions for sending messages, printing messages, and
-   changing passwords, all of which are done outside of IMAP3.  DMSP has
-   16 binary flags of which 8 are defined by the system.  IMAP has flag
-   names; there are currently 5 defined system flag names and a facility
-   for some number (29 in the current implementations) of user flag
-   names.  IMAP3 has a sophisticated message search facility in the
-   server to identify interesting messages based on dates, addresses,
-   flag status, or textual contents without compelling the client to
-   fetch this data for every message.
-
-   It was felt that maintaining state on the client is advantageous only
-   in those cases where the client is only used by a single user, or if
-   there is some means on the client to restrict access to another
-   user's data.  It can be a serious disadvantage in an environment in
-   which multiple users routinely use the same client, the same user
-   routinely uses different clients, and where there are no access
-   restrictions on the client.  It was also observed that most user mail
-   access is to a relatively small set of "interesting" messages, which
-   were either "new" mail or mail based upon some user-selected
-   criteria. Consequently, IMAP3 was designed to easily identify those
-   "interesting" messages so that the client could fetch the state of
-   those messages and not those that were not "interesting".
-
-   One crucial philosophical difference between IMAP and other common
-
-
-
-Rice                                                            [Page 7]
-
-RFC 1203                         IMAP3                     February 1991
-
-
-   mail protocols is that IMAP is a mailbox access protocol, not a
-   protocol for manipulating mail files.  In the IMAP model, unlike
-   other mail system models in which mail is stored in a linear mail
-   file, no specification is made for the implementation architecture
-   for mail storage.  Servers may choose to implement mailboxes as files
-   but this is a detail of which the client can be totally unaware.
-
-   What is more, in the IMAP model, mailboxes are viewed as mappings
-   from keys into values.  There are broadly three types of keys,
-   generic, canonical and concrete.  Generic keys are generic, mail
-   protocol independent keys defined by IMAP which are meaningful across
-   multiple mail encoding formats.  An example of such a generic key
-   might be "TO", which would be associated with the "To:" field of an
-   RFC 822 format message.
-
-   Canonical keys represent the way in which the server can associate
-   values that are generally "about" a certain key concept, possibly
-   integrating several mail format specific fields, without having to
-   worry the client with the particular details of any particular
-   message format.  Thus, the canonical TO key (called $TO) could denote
-   anything that could reasonably be construed as being directed towards
-   someone.  Hence, in an RFC 822 message the server could find the
-   union of the "To:", "Resent-To", "Apparently-To:" and "CC:" fields to
-   be the appropriate value associated with the canonical $TO key.
-
-   Concrete keys allow the client to gain access to certain mail format
-   specific concepts, that are not pre-specified by the IMAP protocol,
-   in a well defined manner.  For example, If the client asks for the
-   value associated with the "APPARENTLY-TO" key then, if the message
-   were to be in RFC 822 format, the server would look for a header
-   field called "Apparently-To:".  If no such field is found or the
-   field is not implemented or meaningful for the particular message
-   format then the server will respond with the null value, called NIL,
-   indicating the non-existence of the field.
-
-   Thus, IMAP servers are at liberty to implement mailboxes as a
-   relational databases if it seems convenient.  Indeed, we anticipate
-   that future mail systems will tend to use database technology for the
-   storage and indexing of mailboxes as a result of the pressure caused
-   by the increasing size of mailboxes.
-
-   Although for historical reasons IMAP is currently somewhat closely
-   associated with RFC 822, we anticipate that future developments in
-   IMAP will remove these mail format specific components and will move
-   towards the generic model mentioned above.  This will allow IMAP more
-   easily to incorporate such things as multi-media mail.
-
-
-
-
-
-Rice                                                            [Page 8]
-
-RFC 1203                         IMAP3                     February 1991
-
-
-The Protocol
-
-   The IMAP3 protocol consists of a sequence of client commands and
-   server responses to those commands, with extra information from the
-   server data being sent asynchronously to and independent to the
-   responses to client commands.  Unlike most Internet protocols,
-   commands and responses are tagged.  That is, a command begins with a
-   unique identifier (typically a short alphanumeric sequence such as a
-   Lisp "gensym" function would generate e.g., A0001, A0002, etc.),
-   called a tag.  The response to this command is given the same tag
-   from the server.
-
-   We distinguish between data sent by the server as the result of a
-   client request, which we term "SOLICITED" and data sent by the server
-   not as the result of a client request, which we term "UNSOLICITED".
-   The server may send unsolicited data at any time that would not
-   fragment another piece of data on the same stream rendering it
-   unintelligible.  The server is contractually required, however, to
-   return all data that is solicited by the client before the return of
-   the completion signal for that command, i.e., all solicited data must
-   be returned within the temporal extent of the request/completion
-   acknowledgement wrapper.  This does not, however, preclude the
-   simultaneous processing of multiple requests by the client, it simply
-   requires that the client be confident that it has all the requested
-   data when a request finishes.  This allows the implementation of both
-   synchronous and asynchronous clients.
-
-   Solicited data is identified by the tag of the initial request by the
-   client.  Unsolicited data is identified by the special reserved tag
-   of "*".  There is another special reserved tag, "+", discussed below.
-
-   Note: the tagging of SOLICITED data is only permitted for a selected
-   server version other than 2.0.
-
-   No assumptions concerning serial or monolithic processing by the
-   server can be made by a correct client.  The server is at liberty to
-   process multiple requests by the same client in any order.  This
-   allows servers to process costly searches over mailboxes on slow
-   backing storage media in the background, while still preserving
-   interactive performance.  Clients can, however, assume the
-   serialization of the request/data/completion behavior mentioned
-   above.
-
-   When a connection is opened the server sends an unsolicited OK
-   response as a greeting message and then waits for commands.  When
-   commands are received the server acts on them and responds with
-   responses, often interspersed with data.
-
-
-
-
-Rice                                                            [Page 9]
-
-RFC 1203                         IMAP3                     February 1991
-
-
-   The client opens a connection, waits for the greeting, then sends a
-   LOGIN command with user name and password arguments to establish
-   authorization.  Following an OK response from the server, the client
-   then sends a SELECT command to access the desired mailbox.  The
-   user's default mailbox has a special reserved name of "INBOX" which
-   is independent of the operating system that the server is implemented
-   on.  The server will generally send a list of valid flags, number of
-   messages, and number of messages arrived since last access for this
-   mailbox as solicited data, followed by an OK response.  The client
-   may terminate access to this mailbox and access a different one with
-   another SELECT command.
-
-   Because the SELECT command affects the state of the server in a
-   fundamental way, the server is required to process all outstanding
-   commands for any given mailbox before sending the OK tag for the
-   SELECT command.  Thus, the client will always know that all responses
-   before an OK SELECT response will refer to the old mailbox and all
-   responses following it will apply to the new mailbox.
-
-   Because, in the real world, local needs or experimental work will
-   dictate that servers will support both supersets of the defined
-   behavior and incompatible changes, servers will support a
-   SELECT.VERSION command and a SELECT.FEATURES command, the purpose of
-   which is to allow clients to select the overall behavior and specific
-   features that they want from a server.  The default behavior of any
-   server is to process commands and to have interaction syntax the same
-   as is specified by IMAP2 in RFC 1064.  A server may not behave in any
-   other manner unless the SELECT.VERSION or SELECT.FEATURES commands
-   are used to select different behavior.
-
-   Over time, when groups of generally useful changes to the current,
-   default behavior of the server are found, these will be collected
-   together and incorporated in such a way that all of the features can
-   be selected simply by selecting a particular major version number of
-   the protocol.  It should be noted that the version numbers (both
-   major and minor) selected by the SELECT.VERSION command denote
-   versions of the IMAP protocol, not versions of the server per se.
-   Thus, although in general changes to the protocol specification will
-   be made in such a way that they are upwards compatible, this cannot
-   be guaranteed.  No client should rely on tests of the form "if
-   major_version > 2 then..." being valid for all protocol versions,
-   since incompatible changes might be made in the future.
-
-   The client reads mailbox information by means of FETCH commands.  The
-   actual data is transmitted via the solicited data mechanism (that is,
-   FETCH should be viewed as poking the server to include the desired
-   data along with any other data it wishes to transmit to the client).
-   There are three major categories of data which may be fetched.
-
-
-
-Rice                                                           [Page 10]
-
-RFC 1203                         IMAP3                     February 1991
-
-
-   The first category is that data which is associated with a message as
-   an entity in the mailbox.  There are presently three such items of
-   data: the "internal date", the "RFC 822 size", and the "flags".  The
-   internal date is the date and time that the message was placed in the
-   mailbox.  The RFC 822 size is subject to deletion in the future; it
-   is the size in bytes of the message, expressed as an RFC 822 text
-   string.  Current clients only use it as part of a status display
-   line.  The flags are a list of status flags associated with the
-   message (see below).  All of the first category data can be fetched
-   by using the macro-fetch word "FAST"; that is, "FAST" expands to
-   "(FLAGS INTERNALDATE RFC822.SIZE)".
-
-   The second category is that data which describes the composition and
-   delivery information of a message; that is, information such as the
-   message sender, recipient lists, message-ID, subject, etc.  This is
-   the information which is stored in the message header in RFC 822
-   format message and is traditionally called the "envelope".  [Note:
-   this should not be confused with the SMTP (RFC 821) envelope, which
-   is strictly limited to delivery information.]  IMAP3 defines a
-   structured and unambiguous representation for the envelope which is
-   particularly nice for Lisp-based parsers.  A client can use the
-   envelope for operations such as replying and not worry about RFC 822
-   at all.  Envelopes are discussed in more detail below.  The first and
-   second category data can be fetched together by using the macro-fetch
-   word "ALL"; that is, "ALL" expands to "(FLAGS INTERNALDATE
-   RFC822.SIZE ENVELOPE)".
-
-   The third category is that data which is intended for direct human
-   viewing.  The present RFC 822 based IMAP3 defines three such items:
-   RFC822.HEADER, RFC822.TEXT, and RFC822 (the latter being the two
-   former appended together in a single text string).  Fetching "RFC822"
-   is equivalent to typing the RFC 822 representation of the message as
-   stored on the mailbox without any filtering or processing.
-
-   Typically, a client will "FETCH ALL" for some or all of the messages
-   in the mailbox for use as a presentation menu, and when the user
-    wishes to read a particular message will "FETCH RFC822.TEXT" to get
-   the message body.  A more primitive client could, of course, simply
-   "FETCH RFC822" a la POP2-type functionality.
-
-   The client can alter certain data by means of a STORE command.  As an
-   example, a message is deleted from a mailbox by a STORE command which
-   includes the \DELETED flag as one of the flags being set.
-
-   Other client operations include copying a message to another mailbox
-   (COPY command), permanently removing deleted messages (EXPUNGE
-   command), checking for new messages (CHECK command), and searching
-   for messages which match certain criteria (SEARCH command).
-
-
-
-Rice                                                           [Page 11]
-
-RFC 1203                         IMAP3                     February 1991
-
-
-   The client terminates the session with the LOGOUT command.  The
-   server returns a "BYE" followed by an "OK".
-
-A Typical Scenario
-
-        Client                          Server
-        ------                          ------
-                                    {Wait for Connection}
-    {Open Connection}        -->
-                                <-- * OK IMAP3 Server Ready
-                                    {Wait for command}
-    A001 SUPPORTED.VERSIONS   -->
-                                <-- * SUPPORTED.VERSIONS ((2 0 )
-                                        (3 0 EIGHT.BIT.TRANSPARENT
-                                             AUTO.SET.SEEN
-                                             TAGGED.SOLICITED))
-                                    A001 OK Supported Versions returned.
-                                    {Wait for command}
-    A002 SELECT.VERSION (3 0) -->
-                                <-- A002 OK Version 3.0 Selected.
-                                    {Wait for command}
-    A002 SELECT.FEATURES TAGGED.SOLICITED -->
-                                <-- A002 OK Features selected.
-                                    {Wait for command}
-    A003 LOGIN Fred Secret   -->
-                                <-- A003 OK User Fred logged in
-                                    {Wait for command}
-    A004 SELECT INBOX        -->
-                                <-- A004 FLAGS (Meeting Notice \Answered
-                                             \Flagged \Deleted \Seen)
-                                <-- A004 19 EXISTS
-                                <-- A004 2 RECENT
-                                <-- A004 OK Select complete
-                                    {Wait for command}
-    A005 FETCH 1:19 ALL      -->
-                                <-- A005 1 Fetch (......)
-                                        ...
-                                <-- A005 18 Fetch (......)
-                                <-- A005 19 Fetch (......)
-                                <-- A005 OK Fetch complete
-                                    {Wait for command}
-    A006 FETCH 8 RFC822.TEXT -->
-                                <-- A006 8 Fetch (RFC822.TEXT {893}
-                                       ...893 characters of text...
-                                <-- )
-                                <-- A006 OK Fetch complete
-                                    {Wait for command}
-
-
-
-
-Rice                                                           [Page 12]
-
-RFC 1203                         IMAP3                     February 1991
-
-
-    A007 STORE 8 +Flags \Deleted -->
-                                <-- A007 8 Store (Flags (\Deleted
-                                               \Seen))
-                                <-- A007 OK Store complete
-                                    {Wait for command}
-    A008 EXPUNGE             -->
-                                <-- A008 19 EXISTS
-                                <-- A008 8 EXPUNGE
-                                <-- A008 18 EXISTS
-                                <-- A008 Expunge complete
-                                    {Wait for command}
-    A009 LOGOUT              -->
-                                <-- A009 BYE IMAP3 server quitting
-                                <-- A009 OK Logout complete
-    {Close Connection}       --><-- {Close connection}
-                                    {Go back to start}
-
-   A more complex scenario produced by a pipelining multiprocess client.
-
-        Client                          Server
-        ------                          ------
-                                    {Wait for Connection}
-    {Open session as above}
-                                <-- A004 19 EXISTS
-                                <-- A004 2 RECENT
-                                <-- A004 OK Select complete
-                                    {Wait for command}
-    A005 SEARCH RECENT       -->
-                                <-- A005 SEARCH (18 19) (RECENT)
-                                <---A005 OK Search complete
-    A006 FETCH 18:19 ALL RFC822.TEXT
-    A007 STORE 18:19 +FLAGS (\SEEN)
-    A008 FETCH 1:17 ALL      -->
-                                <-- A006 18 Fetch (... RFC822.TEXT ...)
-    A009 STORE 18 +FLAGS (\DELETED)
-                                <-- A006 19 Fetch (... RFC822.TEXT ...)
-                                <-- A006 OK Fetch complete
-                                <-- A007 18 STORE (Flags (\Seen))
-    A010 STORE 19 +FLAGS (\DELETED)
-                                <-- A007 19 STORE (Flags (\Seen))
-                                <-- A007 OK Store complete
-                                <-- A008 1 Fetch (......)
-                                       ...
-                                <-- A008 16 Fetch (......)
-                                <-- A008 17 Fetch (......)
-                                <-- A008 OK Fetch complete
-                                <-- A009 18 STORE (Flags (\Seen
-                                                          \Deleted))
-
-
-
-Rice                                                           [Page 13]
-
-RFC 1203                         IMAP3                     February 1991
-
-
-                                <-- A009 OK Store complete
-                                <-- A010 19 STORE (Flags (\Seen
-                                                          \Deleted))
-                                <-- A010 OK Store complete
-                                    {Wait for command}
-                                <-- * EXISTS 23
-                                <-- * RECENT 4
-                                <-- * SEARCH (20 21 22 23) (RECENT)
-   A011 FETCH 20:23 ALL RFC822.TEXT
-
-Conventions
-
-   The following terms are used in a meta-sense in the syntax
-   specification below:
-
-      An ASCII-STRING is a sequence of arbitrary ASCII characters.
-
-      An ATOM is a sequence of ASCII characters delimited by SP or CRLF.
-
-      A CHARACTER is any ASCII character except """", "{", CR, LF, "%",
-      or "\".
-
-      A CRLF is an ASCII carriage-return character followed immediately
-      by an ASCII linefeed character.
-
-      A NUMBER is a sequence of the ASCII characters which represent
-      decimal numerals ("0" through "9"), delimited by SP, CRLF, ",", or
-      ":".
-
-      A SP is the ASCII space character.
-
-      A TEXT_LINE is a human-readable sequence of ASCII characters up to
-      but not including a terminating CRLF.
-
-   One of the most common fields in the IMAP3 protocol is a STRING,
-   which may be an ATOM, QUOTED-STRING (a sequence of CHARACTERs inside
-   double-quotes), or a LITERAL.  A literal consists of an open brace
-   ("{"), a number, a close brace ("}"), a CRLF, and then an ASCII-
-   STRING of n characters, where n is the value of the number inside the
-   brace. In general, a string should be represented as an ATOM or
-   QUOTED-STRING if at all possible.  The semantics for QUOTED-STRING or
-   LITERAL are checked before those for ATOM; therefore an ATOM used in
-   a STRING may only contain CHARACTERs.  Literals are most often sent
-   from the server to the client; in the rare case of a client to server
-   literal there is a special consideration (see the "+ text" response
-   below).
-
-   Another important field is the SEQUENCE, which identifies a set of
-
-
-
-Rice                                                           [Page 14]
-
-RFC 1203                         IMAP3                     February 1991
-
-
-   messages by consecutive numbers from 1 to n where n is the number of
-   messages in the mailbox.  A sequence may consist of a single number,
-   a pair of numbers delimited by colon indicating all numbers between
-   those two numbers, or a list of single numbers and/or number pairs.
-   For example, the sequence 2,4:7,9,12:15 is equivalent to
-   2,4,5,6,7,9,12,13,14,15 and identifies all of those messages.
-
-Definitions of Commands and Responses
-
-   Summary of Commands and Responses
-
-Commands:
-       tag NOOP
-       tag LOGIN user password
-       tag LOGOUT
-       tag SELECT mailbox
-       tag CHECK
-       tag EXPUNGE
-       tag COPY sequence mailbox
-       tag FETCH sequence data
-       tag STORE sequence data value
-       tag SEARCH criteria
-       tag BBOARD bboard
-       tag FIND (BBOARDS / MAILBOXES) pattern
-       tag READONLY
-       tag READWRITE
-       tag SELECT.VERSION (major_version minor_version)
-       tag SELECT.FEATURES features
-       tag SUPPORTED.VERSIONS
-       tag FLAGS
-       tag SET.FLAGS
-
-Responses (can be either solicited or unsolicited):
-       */tag FLAGS flag_list
-       */tag SEARCH (numbers) (criteria)
-       */tag EXISTS
-       */tag RECENT
-       */tag EXPUNGE
-       */tag STORE data
-       */tag FETCH data
-       */tag BBOARD bboard_name
-       */tag MAILBOX non_inbox_mailbox_name
-       */tag SUPPORTED.VERSIONS version_data
-       */tag READONLY
-       */tag READWRITE
-       */tag OK text
-       */tag NO text
-       */tag BAD text
-
-
-
-Rice                                                           [Page 15]
-
-RFC 1203                         IMAP3                     February 1991
-
-
-       */tag BYE text
-
-Responses (can only be solicited):
-       tag COPY message_number
-
-Responses (can only be unsolicited):
-       + text
-
-Commands
-
-   tag NOOP
-
-      The NOOP command returns an OK to the client.  By itself, it does
-      nothing, but certain things may happen as side effects.  For
-      example, server implementations which implicitly check the mailbox
-      for new mail may do so as a result of this command.  The primary
-      use of this command is to for the client to see if the server is
-      still alive (and notify the server that the client is still alive,
-      for those servers which have inactivity autologout timers).
-
-   tag LOGIN user password
-
-      The LOGIN command identifies the user to the server and carries
-      the password authenticating this user.  This information is used
-      by the server to control access to the mailboxes.
-
-      EXAMPLE: A001 LOGIN SMITH SESAME logs in as user SMITH with
-      password SESAME.
-
-   tag LOGOUT
-
-      The LOGOUT command indicates the client is done with the session.
-      The server sends a solicited BYE response before the (tagged) OK
-      response, and then closes the connection.
-
-   tag SELECT mailbox
-
-      The SELECT command selects a particular mailbox.  The server must
-      check that the user is permitted read access to this mailbox.
-      Prior to returning an OK to the client, the server must send an
-      solicited FLAGS and <n> EXISTS response to the client giving the
-      flags list for this mailbox (simply the system flags if this
-      mailbox doesn't have any special flags) and the number of messages
-      in the mailbox.  It is also recommended that the server send a <n>
-      RECENT unsolicited response to the client for the benefit of
-      clients which make use of the number of new messages in a mailbox.
-      It is further recommended that servers should send an unsolicited
-      READONLY message if the mailbox that has been selected is not
-
-
-
-Rice                                                           [Page 16]
-
-RFC 1203                         IMAP3                     February 1991
-
-
-      writable by the user.
-
-      Multiple SELECT commands are permitted in a session, in which case
-      the prior mailbox is deselected first.
-
-      The default mailbox for the SELECT command is INBOX, which is a
-      special name reserved to mean "the primary mailbox for this user
-      on this server".  The format of other mailbox names is operating
-      system dependent (as of this writing, it reflects the path of the
-      mailbox on the current servers), though it could reflect any
-      server-specific naming convention for the namespace of mailboxes.
-      Such a namespace need not and should not be viewed as being
-      equivalent or linked to the server machine's file system.
-
-      EXAMPLES: A002 SELECT INBOX  ;; selects the default mailbox.
-                A002 197 EXISTS    ;; server says 197 messages in INBOX
-                A002 5 RECENT      ;; server says 5 are recent.
-                A002 OK Select complete.
-      or
-                A003 SELECT /usr/fred/my-mail.txt
-                 ;; select a different user specified mailbox.
-                ...
-
-   tag CHECK
-
-      The CHECK command forces a check for new messages and a rescan of
-      the mailbox for internal change for those implementations which
-      allow multiple simultaneous read/write access to the same mailbox
-      (e.g., TOPS-20).  It is recommend that periodic implicit checks
-      for new mail be done by servers as well.  The server must send a
-      solicited <n> EXISTS response prior to returning an OK to the
-      client.
-
-   tag EXPUNGE
-
-      The EXPUNGE command permanently removes all messages with the
-      \DELETED flag set in its flags from the mailbox.  Prior to
-      returning an OK to the client, for each message which is removed,
-      a solicited <n> EXPUNGE response is sent indicating which message
-      was removed.  The message number of each subsequent message in the
-      mailbox is immediately decremented by 1; this means that if the
-      last 5 messages in a 9-message mailbox are expunged you will
-      receive 5 "5 EXPUNGE" responses for message 5.  To ensure mailbox
-      integrity and server/client synchronization, it is recommended
-      that the server do an implicit check prior to commencing the
-      expunge and again when the expunge is completed.  Furthermore, if
-      the server allows multiple simultaneous access to the same mailbox
-      the server must guarantee both the integrity of the mailbox and
-
-
-
-Rice                                                           [Page 17]
-
-RFC 1203                         IMAP3                     February 1991
-
-
-      the views of it held by the clients.
-
-      EXPUNGE is not allowed if the user does not have write access to
-      this mailbox.  If a user does not have write access to the mailbox
-      then the server is required to signal this fact by replying with a
-      NO response with a suitable text string that can be presented to
-      the user explaining that the mailbox is read-only.  It is further
-      recommended that servers send an unsolicited READONLY message to
-      clients that attempt an expunge operation on a read only mailbox.
-
-   tag COPY sequence mailbox
-
-      The COPY command copies the specified message(s) to the specified
-      destination mailbox.  If the destination mailbox does not exist,
-      the server should create it.  Prior to returning an OK to the
-      client, the server must return a solicited <n> COPY response for
-      each message copied.
-
-      EXAMPLE: A003 COPY 2:4 MEETING copies messages 2, 3, and 4 to
-      mailbox "MEETING".
-
-      COPY is not allowed if the user does not have write access to the
-      destination mailbox.  If a user does not have write access to the
-      destination mailbox then the server is required to signal this
-      fact by replying with a NO response with a suitable text string
-      that can be presented to the user explaining that the mailbox is
-      read-only.  It is further recommended that servers send an
-      unsolicited READONLY message to clients that attempt to copy to a
-      read only mailbox.  IMAP3 does not specify "where" the message
-      will be put in the mailbox to which it has been copied.
-
-   tag FETCH sequence fetch_att
-
-      The FETCH command retrieves data associated with a message in the
-      mailbox.  The data items to be fetched may be either a single atom
-      or an S-expression list.  The attributes that can be fetched are
-      any of those mentioned specifically below along with any generic,
-      canonical or concrete key.  The set of predefined generic keys is:
-      {BCC, BODY, CC, FROM, HEADER, SIZE, SUBJECT, TEXT, TO}.  The set
-      of predefined canonical keys is {$CC, $FROM, $SUBJECT, $TO}.  The
-      value returned by the server for a non-existent or non-meaningful
-      key is defined to be the null value, NIL.
-
-      ALL             Equivalent to:
-                      (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE)
-
-      ENVELOPE        The envelope of the message.  The envelope is
-                      computed by the server by parsing the header,
-
-
-
-Rice                                                           [Page 18]
-
-RFC 1203                         IMAP3                     February 1991
-
-
-                      i.e., the RFC 822 header for an RFC822 format
-                      message, into the component parts, defaulting
-                      various fields as necessary.
-
-      FAST            Macro equivalent to:
-                      (FLAGS INTERNALDATE RFC822.SIZE)
-
-      FLAGS           The flags which are set for this message.
-                      This may include the following system flags:
-
-                              \RECENT    Message arrived since
-                                          last read of this mailbox
-                              \SEEN      Message has been read
-                              \ANSWERED  Message has been answered
-                              \FLAGGED   Message is "flagged" for
-                                          urgent/special attention
-                              \DELETED   Message is "deleted" for
-                                          removal by later EXPUNGE
-
-      INTERNALDATE    The date and time the message was written to
-                      the mailbox.
-
-      RFC822          The message in RFC 822 format.
-
-      RFC822.HEADER   The RFC 822 format header of the message.
-
-      RFC822.SIZE     The number of characters in the message as
-                      expressed in RFC 822 format.
-
-      RFC822.TEXT     The text body of the message, omitting the
-                      RFC 822 header.
-
-      EXAMPLES:
-
-      A003 FETCH 2:4 ALL
-         fetches the flags, internal date, RFC 822 size, and envelope
-         for messages 2, 3, and 4.
-
-      A004 FETCH 3 RFC822
-         fetches the RFC 822 representation for message 3.
-
-      A005 FETCH 4 (FLAGS RFC822.HEADER)
-         fetches the flags and RFC 822 format header for message 4.
-
-      A006 FETCH 42 $SUBJECT
-      A006 FETCH $SUBJECT "Some subject text..."
-      A006 OK FETCH completed ok.
-         fetches the canonical subject field.
-
-
-
-Rice                                                           [Page 19]
-
-RFC 1203                         IMAP3                     February 1991
-
-
-      A007 FETCH 42 APPARENTLY-TO
-      A007 FETCH APPARENTLY-TO NIL
-      A007 OK FETCH found no value.
-         fetches the concrete apparently-to field.
-
-   tag STORE sequence data value
-
-      The STORE command alters the values associated with particular
-      keys for a message in the mailbox.  As is the case for the FETCH
-      command, any generic, canonical or concrete key may be used to
-      index the value provided.  In addition to these, the following
-      pre-defined keys are provided.
-
-   FLAGS           Replace the flags for the message with the
-                   argument (in flag list format).
-                  The server must respond with a solicited STORE FLAGS
-                  message, showing the new state of the flags after
-                  the store.
-
-   +FLAGS          Add the flags in the argument to the
-                   message's flag list.
-                 The server must respond with a solicited STORE FLAGS
-                 message, showing the new state of the flags after
-                 the store.
-
-  -FLAGS          Remove the flags in the argument from the
-                  message's flag list.
-                 The server must respond with a solicited STORE FLAGS
-                 message, showing the new state of the flags after
-                 the store.
-
-  RFC822.HEADER   Replace the header of the message(s) with that
-                  specified.  This allows users to use their mailboxes
-                  as databases with header fields as keys.
-                  The server must respond with solicited
-                  STORE RFC822.HEADER, STORE RFC822.SIZE and
-                  STORE ENVELOPE messages,  showing the new state
-                  of the reparsed header after the store.
-
-  RFC822.TEXT     Replace the body of the messages with that specified.
-                  The server must respond with solicited
-                  STORE RFC822.TEXT and STORE RFC822.SIZE messages,
-                  showing the new state of the message after the store.
-
-         STORE is not allowed if the user does not have write access to
-         this mailbox.
-
-         The server is required to send a solicited STORE response for
-
-
-
-Rice                                                           [Page 20]
-
-RFC 1203                         IMAP3                     February 1991
-
-
-         each store operation that results in a format transformation by
-         the server.  For example, the server is required to send a
-         STORE FLAGS response when the client performs a STORE +FLAGS or
-         a STORE -FLAGS, since the client may not easily be able to know
-         what the result of this command will be.  Similarly, if the
-         client emits a STORE FROM command then the server should
-         respond with a suitable STORE FROM response because the client
-         would be sending a string value to be stored and the server
-         should transform this into a set of addresses.  In general,
-         however, although it is legal for the server to send a
-         solicited STORE response for each STORE operation, this is
-         discouraged, since it might result in the retransmission of
-         very large and unnecessary amounts of data that have been
-         stored.
-
-         EXAMPLE: A003 STORE 2:4 +FLAGS (\DELETED) marks messages 2, 3,
-         and 4 for deletion.
-
-   tag SEARCH search_criteria
-
-      The SEARCH command searches the mailbox for messages which match
-      the given set of criteria.  The server response SEARCH (criteria)
-      (numbers) gives the set of messages which match the conjunction of
-      the criteria specified.  In addition to each of the search
-      criteria there is its logical inverse.  The logical inverse
-      criterion is denoted by the ~ (tilda) sign.
-
-      Thus, no message that matches the criterion:
-         FROM crispin
-
-      will match the criterion:
-         ~FROM crispin
-
-      The criteria for the search can be any generic, canonical or
-      concrete key.  In addition to these, the following pre-defined
-      keys are also provided:
-
-      ALL             All messages in the mailbox; the default
-                      initial criterion for ANDing.
-
-      ANSWERED        Messages with the \ANSWERED flag set.
-
-      BCC string      Messages which contain the specified string
-                      in the envelope's BCC field.
-
-      BEFORE date     Messages whose internal date is earlier than
-                      the specified date.
-
-
-
-
-Rice                                                           [Page 21]
-
-RFC 1203                         IMAP3                     February 1991
-
-
-      BODY string     Messages which contain the specified string
-                      in the body of the message.
-
-      CC string       Messages which contain the specified string
-                      in the envelope's CC field.
-
-      DELETED         Messages with the \DELETED flag set.
-
-      FLAGGED         Messages with the \FLAGGED flag set.
-
-      FROM string     Messages which contain the specified string
-                      in the envelope's FROM field.
-
-      HEADER string   Messages which contain the specified string
-                      in the message header.
-
-      KEYWORD flag    Messages with the specified flag set.
-
-      NEW             Messages which have the \RECENT flag set but
-                      not the \SEEN flag.  This is functionally
-                      equivalent to "RECENT UNSEEN".
-
-      OLD             Messages which do not have the \RECENT flag
-                      set.
-
-      ON date         Messages whose internal date is the same as
-                      the specified date.
-
-      RECENT          Messages which have the \RECENT flag set.
-
-      SEEN            Messages which have the \SEEN flag set.
-
-      SINCE date      Messages whose internal date is later than
-                      the specified date.
-
-      SUBJECT string  Messages which contain the specified string
-                      in the envelope's SUBJECT field.
-
-      TEXT string     Messages which contain the specified string.
-
-      TO string       Messages which contain the specified string in
-                      the envelope's TO field.
-
-         EXAMPLE:  A003 SEARCH DELETED FROM "SMITH" SINCE 1-OCT-87
-         returns the message numbers for all deleted messages from Smith
-         that were placed in the mailbox since October 1, 1987.
-
-      Implementation note:  The UNANSWERED, UNDELETED, UNFLAGGED,
-
-
-
-Rice                                                           [Page 22]
-
-RFC 1203                         IMAP3                     February 1991
-
-
-      UNKEYWORD and UNSEEN criteria, described below, are preserved in
-      IMAP3 for IMAP2 compatibility.  They are, however, considered
-      obsolete and new Client programs are encouraged to use the ~
-      notation for the logical inverses of search criteria with a view
-      to the dropping of this outmoded syntax in later versions.
-
-      UNANSWERED      Messages which do not have the \ANSWERED flag
-                      set.
-
-      UNDELETED       Messages which do not have the \DELETED flag
-                      set.
-
-      UNFLAGGED       Messages which do not have the \FLAGGED flag
-                      set.
-
-      UNKEYWORD flag  Messages which do not have the specified flag
-                      set.
-
-      UNSEEN          Messages which do not have the \SEEN flag set.
-
-   tag READONLY
-
-      The READONLY command indicates that the client wishes to make the
-      mailbox read-only.  The server is required to reply with a
-      solicited READONLY or READWRITE response.
-
-   tag READWRITE
-
-      The READWRITE command indicates that the client wishes to make the
-      mailbox read-write.  The server is required to reply with a
-      solicited READONLY or READWRITE response.
-
-   tag SUPPORTED.VERSIONS
-
-      The SUPPORTED.VERSIONS solicits from the server a
-      SUPPORTED.VERSIONS message, which encapsulates information about
-      which versions and features the server supports.
-
-   tag SELECT.VERSION (major_version minor_version)
-
-      The SELECT.VERSION command indicates that the client wishes to
-      select certain behavior on the part of the server.  The major and
-      minor versions indicate the specific version of the protocol being
-      selected.
-
-      EXAMPLE: A002 SELECT.VERSION (3 0)
-
-      A client may not request a server version that is not supported by
-
-
-
-Rice                                                           [Page 23]
-
-RFC 1203                         IMAP3                     February 1991
-
-
-      the server, i.e., which is specifically mentioned in the response
-      to a SUPPORTED.VERSIONS command.  An attempt to do so by a client
-      will result in a NO response from the server.  It is an error for
-      the SELECT.VERSION command to be used after a mailbox has been
-      selected.  The rationale for this is that for some server
-      implementations it might be necessary to spawn separate programs
-      to implement widely divergent protocol versions.  Thus, the client
-      cannot be allowed to expect any server state to be preserved after
-      the use of the SELECT.VERSION command.  The default version of all
-      servers is 2.0, i.e., IMAP2 as defined by RFC 1064.
-
-   tag SELECT.FEATURES 1#features
-
-      The SELECT.FEATURES command indicates that the client wishes to
-      select certain specific features on the part of the server. A
-      client may not request a feature that is not supported by the
-      server, i.e., one that is explicitly mentioned in the set of
-      features for the selected version returned by the
-      SUPPORTED.VERSIONS command.  An attempt to do so by a client will
-      result in a NO response from the server.
-
-      EXAMPLE: A002 SELECT.FEATURES AUTO.SET.SEEN ~TAGGED.SOLICITED
-              EIGHT.BIT.TRANSPARENT
-
-      i.e., select the set of features called AUTO.SET.SEEN and
-      EIGHT.BIT.TRANSPARENT and deselect the feature called
-      TAGGED.SOLICITED.  The use of the SELECT.FEATURES command
-      completely resets the set of selected features.  Note:  These are
-      only example feature names and are not necessarily supported by
-      any server.  See the appendix on features for more information on
-      features.  Note:  Some features, when present in the server, will
-      cause the upwards compatible extension of the grammar, i.e., by
-      adding extra commands.  The server is at liberty not to remove
-      these upwards compatible extensions to the command tables when a
-      feature is disabled.  Thus, it is an error for a client to rely on
-      getting a NO or BAD response in any way, for instance to determine
-      the selectedness or presence of a feature.
-
-   tag BBOARD bboard
-
-      The BBOARD command is equivalent to SELECT, except that its
-      argument is a bulletin board (BBoard) name.  The format of a
-      BBoard name is implementation specific, although it is strongly
-      encouraged to use something that resembles a name in a generic
-      sense and not a file or mailbox name on the particular system.
-      There is no requirement that a BBoard name be a mailbox name or a
-      file name (in particular, Unix netnews has a completely different
-      namespace from mailbox or file names).
-
-
-
-Rice                                                           [Page 24]
-
-RFC 1203                         IMAP3                     February 1991
-
-
-      The result from the BBOARD command is identical from that of the
-      SELECT command.  For example, in the TOPS-20 server
-      implementation, the command
-         A0002 BBOARD FOO
-      is exactly equivalent to the command
-         A0002 SELECT POBOX:<BBOARD>FOO.TXT
-         Note: the equivalence in this example is *not* required by the
-         protocol, and merely reflects the fuzzy distinction between
-         mailboxes and BBoards on TOPS-20.
-
-   tag FIND (BBOARDS / MAILBOXES) pattern
-
-      The FIND command accepts as arguments the keywords BBOARDS or
-      MAILBOXES and a pattern which specifies some set of BBoard/mailbox
-      names which are usable by the BBOARD/SELECT command.  Two wildcard
-      characters are defined; "*" specifies that any number (including
-      zero) characters may match at this position and "%" specifies that
-      a single character may match at this position.  For example,
-      FOO*BAR will match FOOBAR, FOOD.ON.THE.BAR and FOO.BAR, whereas
-      FOO%BAR will match only FOO.BAR; furthermore, "*" will match all
-      BBoards/mailboxes.  The following quoting convention applies to
-      wildcards: "\*" is the literal "*" character, "\%" is the literal
-      "%" character and "\\" is the literal "\" character.  Notes: The
-      format of mailboxes is server implementation dependent.  The
-      special mailbox name INBOX is not included in the output to the
-      FIND MAILBOXES command.
-
-      The FIND command solicits any number of BBOARD or MAILBOX
-      responses from the server as appropriate.
-
-      Examples:
-          A0002 FIND BBOARDS *
-          A0002 BBOARD FOOBAR
-          A0002 BBOARD GENERAL
-          A0002 OK FIND completed
-      or
-          A0002 FIND MAILBOXES FOO%BA*
-          A0002 MAILBOX FOO.BAR
-          A0002 MAILBOX FOO.BAZZAR
-          A0002 OK FIND completed
-
-      Note: Although the use of explicit file or path names for
-      mailboxes is discouraged by this standard, it may be unavoidable.
-      It is important that the value returned in the MAILBOX solicited
-      reply be usable in the SELECT command without remembering any path
-      specification which may have been used in the FIND MAILBOXES
-      pattern.
-
-
-
-
-Rice                                                           [Page 25]
-
-RFC 1203                         IMAP3                     February 1991
-
-
-   tag FLAGS
-
-      The FLAGS command solicits a FLAGS response from the server.
-
-   tag SET.FLAGS flag_list
-
-      The SET.FLAGS command defines the user specifiable flags for this
-      mailbox, i.e., the keywords.  If this set does not include flags
-      formerly sent to the client by the server in a FLAGS message then
-      this constitutes a request to delete the flag.  Any new flags
-      should be created.  This command does not affect the system
-      defined flags and any system flags that are included in the
-      flag_list will be ignored.  The server must respond to this
-      command with a solicited FLAGS message.  If the deletion of a flag
-      results in the invalidation of the flag sets of any messages then
-      the server is required to send solicited STORE FLAGS messages to
-      the client for each modified message.
-
-Responses:
-
-   */tag OK text
-
-      In its solicited form this response identifies successful
-      completion of the command with the indicated tag.  The text is a
-      line of human-readable text which may be useful in a protocol
-      telemetry log for debugging purposes.
-
-      In its unsolicited form, this response indicates simply that the
-      server is alive.  No special action on the part of the client is
-      called for.  This is presently only used by servers at startup as
-      a greeting message indicating that they are ready to accept the
-      first command.  This usage, although legal, is by no means
-      required.  The text is a line of human-readable text which may be
-      logged in protocol telemetry.
-
-   */tag NO text
-
-      In its solicited form this response identifies unsuccessful
-      completion of the command with the indicated tag.  The text is a
-      line of human-readable text which probably should be displayed to
-      the user in an error report by the client.
-
-      In its unsolicited form this response indicates some operational
-      error at the server which cannot be traced to any protocol
-      command.  The text is a line of human-readable text which should
-      be logged in protocol telemetry for the maintainer of the server
-      and/or the client.
-
-
-
-
-Rice                                                           [Page 26]
-
-RFC 1203                         IMAP3                     February 1991
-
-
-   */tag BAD text
-
-      In its solicited form response indicates faulty protocol received
-      from the client and indicates a bug.  The text is a line of
-      human-readable text which should be recorded in any telemetry as
-      part of a bug report to the maintainer of the client.
-
-      In its unsolicited form response indicates some protocol error at
-      the server which cannot be traced to any protocol command.  The
-      text is a line of human-readable text which should be logged in
-      protocol telemetry for the maintainer of the server and/or the
-      client.  This generally indicates a protocol synchronization
-      problem, and examination of the protocol telemetry is advised to
-      determine the cause of the problem.
-
-   */tag BYE text
-
-      This indicates that the server is about to close the connection.
-      The text is a line of human-readable text which should be
-      displayed to the user in a status report by the client.  IMAP2
-      requires that the server emit a solicited BYE response as part of
-      a normal logout sequence.  This solicited form is not required
-      under IMAP3, though is still legal for compatibility.  In its
-      unsolicited form the BYE response is used as a panic shutdown
-      announcement by the server.  It is required to be used by any
-      server which performs autologouts due to inactivity.
-
-   */tag number message_data
-
-      The solicited (tag number message_data) response is generated as
-      the result of a number of client requests.  The server may also
-      emit any the following at any time as unsolicited data (i.e., *
-      number message_data).  The message_data is one of the following:
-
-      EXISTS  The specified number of messages exists in the mailbox.
-
-      RECENT  The specified number of messages have arrived since the
-              last time this mailbox was selected with the SELECT
-              command or equivalent.
-
-      EXPUNGE The specified message number has been permanently
-              removed from the mailbox, and the next message in the
-              mailbox (if any) becomes that message number.
-             The server must send a solicited EXPUNGE response
-             for each message that it expunges as the result
-             of an EXPUNGE command.  Note: future versions of the
-             protocol may allow the use of a message sequence
-             as a value returned by the EXPUNGE response to allow the
-
-
-
-Rice                                                           [Page 27]
-
-RFC 1203                         IMAP3                     February 1991
-
-
-             more efficient compaction of client representations of
-             mailboxes.
-
-      STORE data
-             Functionally equivalent to FETCH, only it is sent by the
-             server when the state of a mailbox changes.  The server
-             must send solicited STORE responses as the result of
-             any change caused by a STORE command.
-
-      FETCH data
-              This is the principle means by which data about a
-              message is sent to the client.  The data is in a
-              Lisp-like S-expression property list form.  Just as the
-              FETCH request from the client can fetch any generic,
-              canonical or concrete key, so also the FETCH response
-              can return values for any of these keys as well as for
-              the pre-defined attributes mentioned below.  Note that
-              the server is permitted to send any unsolicited FETCH
-              or STORE messages that it should choose, be they the
-              values associated with generic, canonical or concrete
-              keys.  Clients are required to ignore any such
-              FETCH responses that it cannot interpret.  For example,
-              clients are not required to be able to understand, i.e.,
-              use fruitfully, the canonical $TO key, but they are
-              required to be able to ignore an unsolicited $TO message
-              correctly.
-
-         ENVELOPE     An S-expression format list which describes the
-                      envelope of a message.  The envelope is computed
-                      by the server by parsing the RFC 822 header into
-                      the component parts, defaulting various fields
-                      as necessary.
-
-                      The fields of the envelope are in the following
-                      order: date, subject, from, sender, reply-to, to,
-                      cc, bcc, in-reply-to, and message-id.  The date,
-                      subject, in-reply-to, and message-id fields are
-                      strings.  The from, sender, reply-to, to, cc,
-                      and bcc fields are lists of addresses.
-
-                      An address is an S-expression format list which
-                      describes an electronic mail address.  The fields
-                      of an address are in the following order:
-                      personal name, source-route (i.e., the
-                      at-domain-list in SMTP), mailbox name, host name
-                      and comments.  Implementation note:  The addition
-                      of the comment field is an incompatible extension
-                      from IMAP2.  The server is required not to provide
-
-
-
-Rice                                                           [Page 28]
-
-RFC 1203                         IMAP3                     February 1991
-
-
-                      this field when running in IMAP2 mode.
-
-                      Any field of an envelope or address which is
-                      not applicable is presented as the atom NIL.
-                      Note that the server must default the reply-to
-                      and sender fields from the from field; a client is
-                      not expected to know to do this.
-
-         FLAGS        An S-expression format list of flags which are set
-                      for this message.  This may include the following
-                      system flags:
-
-                      \RECENT       Message arrived since last
-                                     read of this mailbox
-                      \SEEN         Message has been read
-                      \ANSWERED     Message has been answered
-                      \FLAGGED      Message is "flagged" for
-                                     urgent/special attention
-                      \DELETED      Message is "deleted" for
-                                     removal by later EXPUNGE
-
-         INTERNALDATE  A string containing the date and time the
-                       message was written to the mailbox.
-
-         RFC822        A string expressing the message in RFC 822
-                       format.
-                      Note: Some implementations of IMAP2 servers
-                      had the (undocumented) behavior of setting
-                      the \SEEN flag as a side effect of fetching
-                      the body of a message.  This resulted in
-                      erroneous behavior for clients that prefetch
-                      messages that the user might not get
-                      around to reading.  Thus, this behavior is
-                      explicitly disallowed in IMAP3.
-                      Note: this is not a significant performance
-                      restriction because it is always possible for
-                      IMAP3 clients to use an interaction with the
-                      server of the following type:
-                      A001 FETCH 42 RFC822
-                      A002 STORE 42 +FLAGS (\SEEN)
-                      A001 42 FETCH RFC822 {637} ......
-                      A001 OK Fetch completed
-                      A002 42 STORE FLAGS (\SEEN \FLAGGED...)
-                      A002 OK Store Completed.
-
-         RFC822.HEADER A string expressing the RFC 822 format
-                       header of the message
-
-
-
-
-Rice                                                           [Page 29]
-
-RFC 1203                         IMAP3                     February 1991
-
-
-         RFC822.SIZE   A number indicating the number of
-                       characters in the message as expressed
-                       in RFC 822 format.
-
-         RFC822.TEXT   A string expressing the text body of the
-                       message, omitting the RFC 822 header.
-                      See also note for RFC822.
-
-   */tag FLAGS flag_list
-
-      A solicited FLAGS response must occur as a result of a SELECT
-      command.  The flag list is the list of flags (at a minimum, the
-      IMAP defined flags) which are applicable for this mailbox.  Flags
-      other than the system flags are a function of the server
-      implementation.
-
-   */tag SEARCH (numbers) (search_criteria)
-
-      This response occurs as a result of a SEARCH command.  The
-      number(s) refer to those messages which match the search criteria.
-      In its solicited form this message allows clients to find
-      interesting groups of messages, e.g., unseen messages from
-      Crispin.  In its unsolicited form it allows the server to inform
-      the client of interesting patterns, e.g., when new mail arrives,
-      recent and from Crispin.  Compatibility note:  The search_criteria
-      are sent by the server along with the matching numbers so
-      unsolicited SEARCH messages may be interpreted.  This syntax is
-      not upwards compatible with IMAP2 and so the new syntax is
-      intended to make it simple for clients that are not able to take
-      advantage of unsolicited SEARCH messages still to interpret
-      solicited SEARCH messages simply by ignoring everything that
-      follows the list of numbers with minimal parsing.  Such clients
-      may not, however, simply discard the rest of the line because
-      there might be LITERALs in the search pattern.
-
-      Examples:
-         A00042 SEARCH (2 3 6) (FROM Crispin ~SEEN)
-      and
-         * SEARCH (42) (FROM Crispin RECENT)
-
-   */tag READONLY
-
-      This indicates that the mailbox is read-only.  The server is
-      required to respond to a READONLY or READWRITE command with either
-      a solicited READONLY or a solicited READWRITE response.  Note:  If
-      the client attempts a mutation operation, such as STORE, on a
-      mailbox to which it does not have write access then the server is
-      required to reply with a solicited READONLY response on the first
-
-
-
-Rice                                                           [Page 30]
-
-RFC 1203                         IMAP3                     February 1991
-
-
-      such attempted mutation.  The server may also choose to send
-      solicited READONLY responses for each subsequent attempted
-      mutation.
-
-   */tag READWRITE
-
-      This indicates that the mailbox is read-write.  The server is
-      required to respond to a READONLY or READWRITE command with either
-      a solicited READONLY or a solicited READWRITE response.
-
-   */tag BBOARD bboard_name
-
-      This message is produced in its solicited form as a response to a
-      FIND BBOARDS command.  In its unsolicited form it represents a
-      notification by the server that a new BBoard has been added.
-      Bboard_name must be a name that can be supplied to the BBOARD
-      command so as to select the appropriate bboard.
-
-   */tag MAILBOX non_inbox_mailbox_name
-
-      This message is produced in its solicited form as a response to a
-      FIND MAILBOXES command.  In its unsolicited form it represents a
-      notification by the server that a new mailbox has been added,
-      perhaps as the result of a COPY command creating a new mailbox.
-      Non_inbox_mailbox_name must be a name that can be supplied to the
-      SELECT command so as to select the appropriate mailbox.  Note:
-      non_inbox_mailbox_name is never the string "INBOX".
-
-   */tag SUPPORTED.VERSIONS (version_specs)
-
-      This message is used either as a response to the
-      SUPPORTED.VERSIONS or, in its unsolicited form, to indicate the
-      dynamic addition or removal of support for features or protocol
-      versions.  Each version_spec is of the form (4 2
-      EIGHT.BIT.TRANSPARENT AUTO.SET.SEEN ...), i.e., a major version
-      number and a minor version number for the protocol and the set of
-      features supported under the server's implementation of that
-      protocol version.  A server may not dynamically remove support for
-      any version or feature that has been selected by any currently
-      logged in client by the use of the VERSION command.
-
-      Example:
-        A00005 SUPPORTED.VERSIONS ((2 0 )
-              (2 2 TAGGED.SOLICITED)
-              (3 0 EIGHT.BIT.TRANSPARENT TAGGED.SOLICITED))
-
-      Indicates that two major versions are supported and one minor
-      version is supported and that tagged solicited messages are
-
-
-
-Rice                                                           [Page 31]
-
-RFC 1203                         IMAP3                     February 1991
-
-
-      supported in versions 2.2 and 3.0 with eight bit characters being
-      supported under version 3.  For each feature mentioned in the list
-      of features there is also always the negation of that feature.
-      For example, if the server supports the TAGGED.SOLICITED feature
-      then it also supports the ~TAGGED.SOLICITED feature, which
-      disables this feature.  Note:  These are only example feature
-      names and are not necessarily supported by any server.  See the
-      appendix on features for more information on features.
-
-   + text
-
-      This response indicates that the server is ready to accept the
-      text of a literal from the client.  Normally, a command from the
-      client is a single text line.  If the server detects an error in
-      the command, it can simply discard the remainder of the line.  It
-      cannot do this in the case of commands which contain literals,
-      since a literal can be an arbitrarily long amount of text, and the
-      server may not even be expecting a literal.  This mechanism is
-      provided so the client knows not to send a literal until the
-      server definitely expects it, preserving client/server
-      synchronization.
-
-      In actual practice, this situation is rarely encountered.  In the
-      current protocol, the only client commands likely to contain
-      literals are the LOGIN command and the STORE RFC822.HEADER or
-      STORE RFC822.TEXT commands.  Consider a situation in which a
-      server validates the user before checking the password.  If the
-      password contains "funny" characters and hence is sent as a
-      literal, then if the user is invalid an error would occur before
-      the password is parsed.
-
-      No such synchronization protection is provided for literals sent
-      from the server to the client, for performance reasons.  Any
-      synchronization problems in this direction would be due to a bug
-      in the client or server and not for some operational problem.
-
-Sample IMAP3 session
-
-   The following is a transcript of an actual IMAP3 session.  Server
-   output is identified by "S:" and client output by "U:".  In cases
-   where lines were too long to fit within the boundaries of this
-   document, the line was continued on the next line preceded by a tab.
-
-   S:     * OK SUMEX-AIM.Stanford.EDU Interactive Mail Access Protocol
-                  III Service 6.1(349) at Mon, 14 May 90 14:58:30 PDT
-   U:     a001 SUPPORTED.VERSIONS
-   S:     * SUPPORTED.VERSIONS ((2 0 ) (3 0 EIGHT.BIT.TRANSPARENT
-                     AUTO.SET.SEEN TAGGED.SOLICITED))
-
-
-
-Rice                                                           [Page 32]
-
-RFC 1203                         IMAP3                     February 1991
-
-
-   S:     A001 Supported Versions returned.
-   U:     a002 SELECT.VERSION (3 0)
-   S:     a002 OK Version 3.0 Selected.
-   U:     a003 SELECT.FEATURES TAGGED.SOLICITED
-   S:     a003 OK Features selected.
-   U:     a004 login crispin secret
-   S:     a004 OK User CRISPIN logged in at Thu, 9 Jun 90 14:58:42 PDT,
-                  job 76
-   U:     a005 select inbox
-   S:     a005 FLAGS (Bugs SF Party Skating Meeting Flames Request AI
-                  Question Note \XXXX \YYYY \Answered \Flagged \Deleted
-                  \Seen)
-   S:     a005 16 EXISTS
-   S:     a005 0 RECENT
-   S:     a006 OK Select complete
-   U:     a006 fetch 16 all
-   S:     a006 16 Fetch (Flags (\Seen) InternalDate " 9-Jun-88 12:55:
-              RFC822.Size 637 Envelope ("Sat, 4 Jun 88 13:27:11 PDT"
-              "INFO-MAC Mail Message" (("Larry Fagan" NIL "FAGAN"
-              "SUMEX-AIM.Stanford.EDU" NIL)) (("Larry Fagan" NIL "FAGAN"
-              "SUMEX-AIM.Stanford.EDU" NIL)) (("Larry Fagan" NIL "FAGAN"
-              "SUMEX-AIM.Stanford.EDU" NIL)) ((NIL NIL "rindflEISCH"
-              "SUMEX-AIM.Stanford.EDU" NIL)) NIL NIL NIL
-              "<12403828905.13.FAGAN@SUMEX-AIM.Stanford.EDU>"))
-   S:  a006 OK Fetch completed
-   U:  a007 fetch 16 rfc822
-   S:  a007 16 Fetch (RFC822 {637}
-   S:  Mail-From: RINDFLEISCH created at  9-Jun-88 12:55:43
-   S:  Mail-From: FAGAN created at  4-Jun-88 13:27:12
-   S:  Date: Sat, 4 Jun 88 13:27:11 PDT
-   S:  From: Larry Fagan  <FAGAN@SUMEX-AIM.Stanford.EDU>
-   S:  To: rindflEISCH@SUMEX-AIM.Stanford.EDU
-   S:  Subject: INFO-MAC Mail Message
-   S:  Message-ID: <12403828905.13.FAGAN@SUMEX-AIM.Stanford.EDU>
-   S:  ReSent-Date: Thu, 9 Jun 88 12:55:43 PDT
-   S:  ReSent-From: TC Rindfleisch <Rindfleisch@SUMEX-AIM.Stanford.EDU>
-   S:  ReSent-To: Yeager@SUMEX-AIM.Stanford.EDU,
-                  Crispin@SUMEX-AIM.Stanford.EDU
-   S:  ReSent-Message-ID:
-          <12405133897.80.RINDFLEISCH@SUMEX-AIM.Stanford.EDU>
-   S:
-   S:  The file is <info-mac>usenetv4-55.arc  ...
-   S:  Larry
-   S:  -------
-   S:  )
-   S:  a007 OK Fetch completed
-   U:  a008 logout
-   S:  a008 BYE UNIX IMAP III server terminating connection
-
-
-
-Rice                                                           [Page 33]
-
-RFC 1203                         IMAP3                     February 1991
-
-
-   S:  a008 OK SUMEX-AIM.Stanford.EDU Interim Mail Access Protocol
-                  Service logout
-
-Implementation Discussion
-
-   As of this writing, SUMEX has completed an IMAP2 client for Xerox
-   Lisp machines written in hybrid Interlisp/CommonLisp and is beginning
-   distribution of a client for TI Explorer Lisp machines.  SUMEX has
-   also completed a portable IMAP2 client protocol library module
-   written in C.  This library, with the addition of a small main
-   program (primarily user interface) and a TCP/IP driver, became a
-   rudimentary remote system mail-reading program under Unix.  The first
-   production use of this library is as a part of a MacII client which
-   has now been under daily use (by real users) at Stanford for quite
-   some time.
-
-   As of this writing, SUMEX has completed IMAP2 servers for TOPS-20
-   written in DEC-20 assembly language and 4.2/3 BSD Unix written in C.
-   The TOPS-20 server is fully compatible with MM-20, the standard
-   TOPS-20 mailsystem, and requires no special action or setup on the
-   part of the user.  The INBOX under TOPS-20 is the user's MAIL.TXT.
-   The TOPS-20 server also supports multiple simultaneous access to the
-   same mailbox, including simultaneous access between the IMAP3 server
-   and MM-20.  The 4.2/3 BSD Unix server requires that the user use
-   either Unix Mail format or mail.txt format which is compatible with
-   SRI MM-32 or Columbia MM-C.  The 4.2/3 BSD Unix server allows
-   simultaneous read access; write access must be exclusive.  There is
-   also an experimental IMAP3 server running on the TI Explorer class of
-   machine, which uses MM mailbox format and which can communicate over
-   both TCP and Chaos.
-
-   The Xerox Lisp client and DEC-20 server have been in production use
-   for over two years; the Unix server was been in production use for
-   over a year.  IMAP3 has been used to access mailboxes at remote sites
-   from a local workstation via the Internet.  For example, from the
-   Stanford local network one of the authors has read his mailbox at a
-   Milnet site.
-
-   A number of IMAP clients have now been developed or are being
-   developed.  Amongst these are versions that run on the following
-   machines:
-
-    . Xerox Lisp machines
-    . Apple Macintosh
-    . NeXT
-    . IBM PC
-    . TI Explorer Lisp machines
-    . "Glass teletype" version that runs under Unix
-
-
-
-Rice                                                           [Page 34]
-
-RFC 1203                         IMAP3                     February 1991
-
-
-    . GNU Emacs
-    . X Windows
-    . NTT ELIS
-
-   Each of these client programs is carefully tuned to optimize the
-   performance and user interface in a manner that is consistent with
-   the the user interface model of the native machine.  For example, the
-   Macintosh client features a "messy-desk" interface that allows the
-   cutting and pasting of text with the use of the clipboard with a menu
-   driven interface with keyboard accelerators.
-
-   This specification does not make any formal definition of size
-   restrictions, but some of the existing servers have the following
-   limitations:
-
-   DEC-20
-    . length of a mailbox: 7,077,888 characters
-    . maximum number of messages: 18,432 messages
-    . length of a command line: 10,000 characters
-    . length of the local host name: 64 characters
-    . length of a "short" argument: 39 characters
-    . length of a "long" argument: 491,520 characters
-    . maximum amount of data output in a single fetch:
-      655,360 characters
-
-   TI-Explorer
-    . length of a mailbox: limited by the Minimum of the size of the
-      virtual address space and the size of the file system
-    . maximum number of messages: limited by the the size of the
-      virtual address space
-    . length of a command line: limited by the the size of the
-      virtual address space
-    . length of the local host name: limited by the the size of the
-      virtual address space
-    . length of a "short" argument: limited by the the size of the
-      virtual address space
-    . length of a "long" argument: limited by the the size of the
-      virtual address space
-    . maximum amount of data output in a single fetch: not limited
-
-   Typical values for these limits are 30Mb for file systems and 128Mb
-   for virtual address space.
-
-   To date, nobody has run up against any of these limitations, many of
-   which are substantially larger than most current user mail reading
-   programs.
-
-   There are several advantages to the scheme of tags and solicited
-
-
-
-Rice                                                           [Page 35]
-
-RFC 1203                         IMAP3                     February 1991
-
-
-   responses and unsolicited data.  First, the infamous synchronization
-   problems of SMTP and similar protocols do not happen with tagged
-   commands; a command is not considered satisfied until a completion
-   acknowledgement with the same tag is seen.  Tagging allows an
-   arbitrary amount of other responses ("solicited" data) to be sent by
-   the server with no possibility of the client losing synchronization.
-   Compare this with the problems that FTP or SMTP clients have with
-   continuation, partial completion, and commentary reply codes.
-
-   Another advantage is that a non-lockstep client implementation is
-   possible.  The client could send a command, and entrust the handling
-   of the server responses to a different process which would signal the
-   client when the tagged response comes in.  Some clients might be
-   implemented in a thoroughly asynchronous manner, having, perhaps,
-   multiple outstanding commands at any given time.  Note:  this does
-   not require that the server process these commands in anything other
-   than a lock-step manner.  It simply allows clients to take advantage
-   of servers that are able to do such asynchronous operations.
-
-   It was observed that synchronization problems can occur with literals
-   if the literal is not recognized as such.  Fortunately, the cases in
-   which this can happen are relatively rare; a mechanism (the special
-   "+" tag response) was introduced to handle those few cases which
-   could happen.  The proper way to address this problem in all cases is
-   probably to move towards a record-oriented architecture instead of
-   the text stream model provided by TCP.
-
-   Unsolicited data needs some discussion.  Unlike most protocols, in
-   which the server merely does the client's bidding, an IMAP3 server
-   has a semi-autonomous role.  By means of sending "unsolicited data",
-   the server is in effect sending a command to the client -- to update
-   and/or extend its (incomplete) model of the mailbox with new
-   information from the server.  In this viewpoint, although a "fetch"
-   command is a request for specific information from the client, the
-   server is always at liberty to include more than the desired data as
-   "unsolicited".  A server acknowledgement to the "fetch" is a
-   statement that at least all the requested data has been sent.
-
-   In terms of implementation, a simple lock-step client may have a
-   local cache of data from the mailbox.  This cache is incomplete in
-   general, and at select time is empty.  A listener on the IMAP
-   connection in the client processes all solicited and unsolicited data
-   symmetrically, and updates the cache based on this data, i.e., the
-   client faults on a cache miss and asks the server to fill that cache
-   slot synchronously.  If a tagged completion response arrives, the
-   listener unblocks the process which sent the tagged request.
-
-   Clearly, given this model it is not strictly necessary to distinguish
-
-
-
-Rice                                                           [Page 36]
-
-RFC 1203                         IMAP3                     February 1991
-
-
-   most solicited from unsolicited data.  Doing so, however, apart from
-   being clearer, also allows such simplistic, lock-step client
-   implementations that extract the specific value of the response to
-   command by trapping the tagged response.  This allows the client not
-   to have to block on some complex predicate that involves watching to
-   see an update in a cache cell.
-
-   For example, perhaps as a result of opening a mailbox, solicited data
-   from the server arrives.  The first piece of data is the number of
-   messages.  This is used to size the cache; note that, if new mail
-   arrives, by sending a new "number of messages" unsolicited data
-   message server will cause the cache to be re-sized.  If the client
-   attempts to access information from the cache, it will encounter
-   empty spots which will trigger "fetch" requests.  The request would
-   be sent, some solicited data including the answer to the fetch will
-   flow back, and then the "fetch" response will unblock the client.
-
-   People familiar with demand-paged virtual memory design will
-   recognize this model as being very similar to page-fault handling on
-   a demand-paged system.
-
-Formal Syntax
-
-   The following syntax specification uses the augmented Backus-Naur
-   Form (BNF) notation as specified in RFC 822 with one exception; the
-   delimiter used with the "#" construct is a single space (SP) and not
-   a comma.
-
-address         ::= "(" addr_name SP addr_adl SP addr_mailbox SP
-                    addr_host addr_comment ")"
-
-addr_adl        ::= nil / string
-
-addr_comment    ::= nil / string
-
-addr_host       ::= nil / string
-
-addr_mailbox    ::= nil / string
-
-addr_name       ::= nil / string
-
-bboard          ::= "BBOARD" SP bboard_name
-
-bboard_name     ::= string
-
-bboard_notify   ::= "BBOARD" sp bboard_name
-
-canonical_key   ::= "$CC" /  "$FROM" / "$SUBJECT" / "$TO"
-
-
-
-Rice                                                           [Page 37]
-
-RFC 1203                         IMAP3                     February 1991
-
-
-check           ::= "CHECK"
-
-concrete_key    ::= string
-
-copy            ::= "COPY" SP sequence SP mailbox
-
-criterion       ::= "ALL" / "ANSWERED" /
-                    "BCC" SP string / "BEFORE" SP string /
-                    "BODY" SP string / "CC" SP string / "DELETED" /
-                    "FLAGGED" / "KEYWORD" SP atom / "NEW" / "OLD" /
-                    "ON" SP string / "RECENT" / "SEEN" /
-                    "SINCE" SP string / "TEXT" SP string /
-                    "TO" SP string / "UNANSWERED" / "UNDELETED" /
-                    "UNFLAGGED" / "UNKEYWORD" / "UNSEEN" / key SP string
-
-criteria        ::= 1#criterion
-
-data            ::= ("FLAGS" SP flag_list /
-                  search_notify / bboard_notify / mailbox_notify /
-                  supported_versions_notify / "READONLY" / "READWRITE" /
-                    "BYE" SP text_line / "OK" SP text_line /
-                    "NO" SP text_line / "BAD" SP text_line)
-
-date            ::= string in form "dd-mmm-yy hh:mm:ss-zzz"
-
-envelope        ::= "(" env_date SP env_subject SP env_from SP
-                    env_sender SP env_reply-to SP env_to SP
-                    env_cc SP env_bcc SP env_in-reply-to SP
-                    env_message-id ")"
-
-env_bcc         ::= nil / "(" 1*address ")"
-
-env_cc          ::= nil / "(" 1*address ")"
-
-env_date        ::= string
-
-env_from        ::= nil / "(" 1*address ")"
-
-env_in-reply-to ::= nil / string
-
-env_length      ::= NUMBER
-
-env_message-id  ::= nil / string
-
-env_reply-to    ::= nil / "(" 1*address ")"
-
-env_sender      ::= nil / "(" 1*address ")"
-
-
-
-
-Rice                                                           [Page 38]
-
-RFC 1203                         IMAP3                     February 1991
-
-
-env_subject     ::= nil / string
-
-env_to          ::= nil / "(" 1*address ")"
-
-expunge         ::= "EXPUNGE"
-
-feature         ::= ATOM
-
-fetch           ::= "FETCH" SP sequence SP ("ALL" / "FAST" /
-                    fetch_att / "(" 1#fetch_att ")")
-
-fetch_att       ::= "ENVELOPE" / "FLAGS" / "INTERNALDATE" /
-                    "RFC822" / "RFC822.HEADER" / "RFC822.SIZE" /
-                    "RFC822.TEXT" / key
-
-find            ::= "FIND" ("BBOARDS" / "MAILBOXES") pattern
-
-flag_list       ::= ATOM / "(" 1#ATOM ")"
-
-flags           ::= "FLAGS"
-
-generic_key     ::= "BCC" / "BODY" / "CC" / "FROM" / "HEADER" / "SIZE" /
-                    "SUBJECT" / "TEXT" / "TO"
-
-key             ::= generic_key / canonical_key / concrete_key
-
-literal         ::= "{" NUMBER "}" CRLF ASCII-STRING
-
-login           ::= "LOGIN" SP userid SP password
-
-logout          ::= "LOGOUT"
-
-mailbox         ::= "INBOX" / string
-
-mailbox_notify ::= MAILBOX non_inbox_mailbox_name
-
-msg_copy        ::= "COPY"
-
-msg_data        ::= (msg_exists / msg_recent / msg_expunge /
-                    msg_fetch / msg_copy)
-
-msg_exists      ::= "EXISTS"
-
-msg_expunge     ::= "EXPUNGE"
-
-msg_fetch       ::= ("FETCH" / "STORE") SP "(" 1#("ENVELOPE" SP
-                     env_length envelope / "FLAGS" SP "(" 1#(recent_flag
-                     flag_list) ")" / "INTERNALDATE" SP date /
-
-
-
-Rice                                                           [Page 39]
-
-RFC 1203                         IMAP3                     February 1991
-
-
-                     "RFC822" SP string / "RFC822.HEADER" SP string /
-                     "RFC822.SIZE" SP NUMBER / "RFC822.TEXT" SP
-                     string / key SP string_list) ")"
-
-msg_recent      ::= "RECENT"
-
-msg_num         ::= NUMBER
-
-nil             ::= "NIL"
-
-non_inbox_mailbox_name ::= string
-
-noop            ::= "NOOP"
-
-numbers         ::= 1#NUMBER
-
-password        ::= string
-
-pattern         ::= string
-
-recent_flag     ::= "\RECENT"
-
-read_only       ::= "READONLY"
-
-read_write      ::= "READWRITE"
-
-ready           ::= "+" SP text_line
-
-request         ::= tag SP (noop / login / logout / select / check /
-                    expunge / copy / fetch / store / search /
-                    select_version / select_features /
-                    supported_versions / bboard / find /
-                    read_only / read_write / flags / set_flags ) CRLF
-
-response        ::= tag SP ("OK" / "NO" / "BAD") SP text_line CRLF
-
-search          ::= "SEARCH" SP criteria
-
-search_notify   ::= "SEARCH" SP (numbers) SP (criteria)
-
-select          ::= "SELECT" SP mailbox
-
-select_features ::= "SELECT.FEATURES" 1#feature
-
-select_version  ::= "SELECT.VERSION" SP "(" NUMBER SP NUMBER ")"
-
-sequence        ::= NUMBER / (NUMBER "," sequence) / (NUMBER ":"
-                    sequence)
-
-
-
-Rice                                                           [Page 40]
-
-RFC 1203                         IMAP3                     February 1991
-
-
-set_flags       ::= "SET.FLAGS" SP flag_list
-
-solicited       ::= tag SP (msg_num SP msg_data / data /
-                            solicited_only) CRLF
-
-solicited_only  ::=                {None currently defined}
-
-store           ::= "STORE" SP sequence SP store_att
-
-store_att       ::= ("+FLAGS" SP flag_list / "-FLAGS" SP flag_list /
-                    "FLAGS" SP flag_list / RFC822.TEXT SP string
-                    / RFC822.HEADER SP string / key SP string)
-
-string          ::= atom / """" 1*character """" / literal
-
-string_list     ::= string / ("(" 1#string ")")
-
-supported_versions ::= "SUPPORTED.VERSIONS"
-
-supported_versions_notify ::= "SUPPORTED.VERSIONS" "(" 1#version_spec
-                              ")"
-
-system_flags    ::= "\ANSWERED" SP "\FLAGGED" SP "\DELETED" SP
-                    "\SEEN"
-
-tag             ::= atom
-
-unsolicited     ::= "*" SP (msg_num SP msg_data / data) CRLF
-
-userid          ::= string
-
-version_spec    ::= "(" NUMBER SP NUMBER SP 1#feature ")"
-
-Appendix: Features.
-
-   In this section we outline the standard features that are supported
-   by all IMAP3 servers and identify those features which are
-   recommended or experimental.  For each of these features the default
-   setting is specified.  This means that it is required of any server
-   that supports a given feature to make the default enabledness of that
-   feature as is specified below.  It is required that for each feature
-   supported by a server the inverse feature should also be supported.
-   The inverse feature name shall always be defined as the feature name
-   preceded by the "~" character.  Thus, the AUTO.SET.SEEN feature is
-   disabled by the ~AUTO.SET.SEEN feature.
-
-
-
-
-
-
-Rice                                                           [Page 41]
-
-RFC 1203                         IMAP3                     February 1991
-
-
-   Required Features:
-
-   AUTO.SET.SEEN - When this features is enabled (default is disabled),
-        the \\SEEN flag is set for all appropriate messages as a side
-        effect of any of the following:
-            FETCH of RFC822
-            FETCH of RFC822.TEXT
-            COPY
-        Justification:  This feature is provided for the use of clients
-        that are unable to pipeline their commands effectively and
-        communicate over high latency connections.  When disabled,
-        the server will not perform any such side effects.  This feature
-        is also provided so as to smooth the transition from IMAP2 to
-        IMAP3.
-
-
-   TAGGED.SOLICITED - When this feature is enabled (default is enabled
-        for IMAP3, disabled for IMAP2 mode), solicited responses from
-        the server will have the tag specified by the client.
-        When this feature is disabled, solicited responses from the
-        server will have the IMAP2 compatible tag "*", not the
-        tag specified by the client.
-        Justification:  This feature is provided so as to smooth the
-        transition from IMAP2 to IMAP3.
-
-   Recommended Features.
-
-   EIGHT.BIT.TRANSPARENT - When this feature is enabled
-        (default is disabled), the server allows the transparent
-        transmission of eight bit characters.  When this feature is
-        disabled, the value of any bit other than the least significant
-        7 bits transmitted by the server is unspecified.  If this
-        feature is enabled, the characters that compose all command
-        keywords specified in the IMAP3 grammar and all feature names
-        use only their 7 least significant bits.
-        Justification:  This feature is provided for the purpose of
-        supporting national character sets within messages, encoded
-        languages such as Japanese Kanji characters and also of binary
-        data, such as programs, graphics and sound.
-
-
-   NEW.MAIL.NOTIFY - When this feature is enabled (default is
-        disabled for compatibility with the majority of existing
-        IMAP2 servers), the server will notify the client of the
-        arrival of new mail in the currently selected mailbox
-        using the appropriate RECENT and EXISTS unsolicited messages
-        without the client needing to send periodic CHECK commands.
-        Justification:  This feature is provided to allow clients to
-
-
-
-Rice                                                           [Page 42]
-
-RFC 1203                         IMAP3                     February 1991
-
-
-        switch off any periodic polling strategy that they may use
-        to look for new mail.  Such polling unnecessarily uses bandwidth
-        and can cause the interactive performance to degrade because
-        the user can be kept waiting while some background process
-        is doing a CHECK.
-
-
-   SEND - When this feature is enabled (default is disabled) a new
-        "SEND" command becomes available to the client.  The SEND
-        command instructs the server to send a message, rather
-        than requiring the client to use its own, local message
-        sending capability, for example.  An example of of the
-        send command might be as follows:
-            tag42 SEND RFC822 {2083}
-            From: James Rice <Rice@Sumex-Aim.Stanford.Edu>
-            To:.....
-        If the server is unable to parse the message being sent then
-        it is required to issue a suitable NO notification to the client.
-        If the message cannot be delivered for some reason then the
-        server should send a suitable message to the FROM: address
-        of the message detailing the delivery failure.
-        When the SEND feature is enabled, the "send" production in
-        the grammar is added and as defined below.  The "send"
-        request is added to the list of requests in the request
-        production also as shown below:
-
-   message_format  ::= RFC822
-
-   request         ::= tag SP (noop / login / logout / select / check /
-                       expunge / copy / fetch / store / search /
-                       select_version / select_features /
-                       supported_versions / bboard / find /
-                       read_only / read_write / flags /
-                       set_flags / send) CRLF
-
-   send            ::= SEND SP message_format SP string
-
-        Justification:  This feature is provided so that mail can be
-        sent by the same reliable server that is used for the storage
-        of mail.  This has, amongst others, the following benefits:
-        - Single process clients need not be delayed by mail
-          transmission.
-        - Mail sent by the client will have the server named as the
-          message's sender.  This can be important because there are
-          a lot of mailers that erroneously cause reply mail to be
-          sent to the Sender, not the From or Reply-To address.  Since
-          the client in general is not listening for mail being sent
-          to it directly this can cause mail to be lost.
-
-
-
-Rice                                                           [Page 43]
-
-RFC 1203                         IMAP3                     February 1991
-
-
-        - Clients can be written that do not have any native message
-          sending capability.
-
-
-   ADD.MESSAGE - When this feature is enabled (default is disabled)
-        a new "ADD.MESSAGE" command becomes available to the client.
-        The ADD.MESSAGE command instructs the server to add the
-        specified message to the designated mailbox.  This command
-        can be thought of as being like a COPY command except in
-        this case the message that is put in the designated mailbox
-        is specified as a string, rather than as a message number to
-        be copied from the currently selected mailbox.  An example
-        use of this command might be as follows:
-            tag42 ADD.MESSAGE OUTGOING-MAIL RFC822 {2083}
-            From: James Rice <Rice@Sumex-Aim.Stanford.Edu>
-            To:.....
-        This will have the effect of adding the message to the mailbox
-        called OUTGOING-MAIL.
-        If the server is unable to parse the message being added then
-        it is required to issue a suitable NO notification to the client.
-        When the ADD.MESSAGE feature is enabled, the "add_message"
-        production in the grammar is added and as defined below.
-        The "add_message" request is added to the list of requests
-        in the request production also as shown below:
-
-   add_message            ::= ADD.MESSAGE SP mailbox SP format SP string
-
-   message_format  ::= RFC822
-
-   request         ::= tag SP (noop / login / logout / select / check /
-                       expunge / copy / fetch / store / search /
-                       select_version / select_features /
-                       supported_versions / bboard / find /
-                       read_only / read_write / flags / set_flags /
-                       add_message) CRLF
-
-        Justification:  This feature is provided so that clients can
-        easily add mail to specific mailboxes.  This allows clients
-        to implement such behavior as outgoing mail storage (BCC)
-        without the need to resort to mailing to special BCC mailboxes.
-
-
-   RENUMBER - When this feature is enabled (default is disabled)
-        the RENUMBER command becomes available to the client.
-        The RENUMBER command will reorder the assignment of message
-        numbers to the messages in the mailbox.  If this results in a
-        change to the association of any message number with any
-        message then the server is required to send solicited RESET
-
-
-
-Rice                                                           [Page 44]
-
-RFC 1203                         IMAP3                     February 1991
-
-
-        responses to the client.  The intent of this command is
-        to allow users to view mailboxes in user-meaningful order
-        efficiently.  While the client could do the ordering,
-        it would be less efficient in general.  Note that the
-        server may or may not change the actual storage of the
-        messages and the ordering may or may not remain in effect
-        after another mailbox is selected or the IMAP session is
-        terminated.  Informally, the syntax for the RENUMBER
-        command is:
-
-            tag RENUMBER field_name ordering_type
-
-        this has the effect of changing the IMAP grammar to be
-        as follows:
-
-   ordering_type   ::= DATE / NUMERIC / ALPHA
-
-   renumber        ::= RENUMBER SP field_name SP ordering_type
-
-   request         ::= tag SP (noop / login / logout / select / check /
-                       expunge / copy / fetch / store / search /
-                       select_version / select_features /
-                       supported_versions / bboard / find /
-                       read_only / read_write / flags / set_flags /
-                       renumber) CRLF
-
-        For example:
-         tag42 RENUMBER FROM ALPHA
-                         ;;;RENUMBER alphabetically by the from field
-         tag42 RESET 10:20,49
-                         ;;;Messages 10 to 20 and 49 have changed
-         tag42 OK RENUMBER finished.  Sequence has changed
-         tag43 FETCH ALL 10:20,49
-                         ;;;Client chooses to fetch the changed msgs.
-
-        To support this the RESET message is defined as follows:
-
-   */tag RESET message_sequence
-       This solicited of unsolicited message from the server informs the
-       client that it should flush any information that it has
-       retained for the specified messages.
-
-        Justification:  This feature is provided so that clients can
-        view mailboxes in an order that is convenient to the user.
-        This is particularly important in the context of mailboxes
-        that the user copies messages to from other mailboxes.  This
-        user-controlled filing process often does not happen in any
-        well-defined order.  Because messages in a mailbox are
-
-
-
-Rice                                                           [Page 45]
-
-RFC 1203                         IMAP3                     February 1991
-
-
-        implicitly ordered (usually by arrival date, though this is
-        not a required ordering predicate), the user can be confused
-        by the apparent order of messages in the mailbox.  The
-        addition of the RENUMBER command makes it unnecessary
-        for the user to leave IMAP and use some other mail system to
-        sort mailboxes.
-
-
-   ENCODING - When this feature is enabled (default is disabled) a new
-        generic key named ENCODING is defined.  The value associated
-        with the generic ENCODING key is a list of (tag encoding-type
-        options...) lists that represent the ordered, possibly encoded
-        body of the message.  Each such list represents a segment of
-        the body of the message and the way in which it is encoded.
-        Any options that follow the encoding_type are further
-        qualifiers that describe the format of the segment.  Each tag
-        is created by the server and is unique with respect to the
-        other tags allocated for the other elements in the ENCODING
-        list.  The client may use the tags returned by the server as
-        concrete keys to access a field which is encoded using the
-        encoding type and options mentioned in the appropriate list.
-        Thus:
-
- tag41 FETCH 196 ENCODING ; Client asks for encoding field of msg 196.
- tag41 FETCH ENCODING NIL ; Server replies. This message is not encoded.
- tag41 OK Fetch completed.
- tag42 FETCH 197 ENCODING ; Client asks for encoding field of msg 197.
- tag42 FETCH ENCODING ((G001 UUENCODE) (G002 HEX)) ; Server replies.
- tag42 OK Fetch completed.
- tag43 FETCH 197 G002     ; Client asks for field named G002
- tag43 FETCH G002 "A0 00 FF 13 42......." ; Server sends value of field.
- tag43 OK Fetch completed.
-
-     or
-
- tag44 STORE 197 G002 "0A 00 FF 31 24......."
-    ; Store back the segment with nibbles swapped
-
-      Note:  As a side-effect of enabling this feature, the generic key
-      TEXT will be redefined so as to return only those body parts of a
-      message that are of type TEXT.  The concrete key RFC822.TEXT, on
-      the other hand, would still return everything in the body of the
-      message, even if it was full of strange, binary character
-      sequences.
-
-      When the client STOREs to a field denoted by one of the above tags
-      the server will interpret the value being passed as being in the
-      same format as is currently specified in the ENCODING field.  The
-
-
-
-Rice                                                           [Page 46]
-
-RFC 1203                         IMAP3                     February 1991
-
-
-      server is not required to be able to reformat the data associated
-      with the ENCODING tags if the client STOREs a new value for the
-      ENCODING field.  The interpretability of a message in the context
-      of its ENCODING field is undefined if the client side-effects that
-      ENCODING field, unless the client also STOREs new, reformatted
-      values for the fields that have had their encoding changed.
-
-      If the client stores a new value for the ENCODING field then the
-      tags in the new value will be used to index the parts of the body.
-      All tags in a client-STOREd ENCODING that are the same as those
-      originally generated by the server in response to a FETCH ENCODING
-      command are said still to denote the fields that they originally
-      denoted, though possibly reordered.  Any tags not originally
-      defined by the server will denote new message parts, in the
-      appropriate format, in the relative position specified.  The
-      exclusion of any tags that the server originally defined in a
-      FETCH of the ENCODING field will indicate the deletion of that
-      part of the message.  Newly created message parts are undefined by
-      default, so if the client fails to follow the STOREing of the
-      ENCODING field with suitable STORE commands for the values
-      associated with any newly created tags, these fields will contain
-      the null value NIL.
-
-      Justification:  This feature is supplied so as to allow support
-      for emergent multi-part and multi-media mail standards.
-
-   INDEXABLE.FIELDS - When this feature is enabled (default is
-        disabled) the grammar of fetch commands is changed to allow the
-        client to select a specific subsequence from the field in
-        question.  For example:
-
-          tag42 FETCH 197 BODY 2000:3999
-
-        would fetch the second two thousand bytes of the body of message
-        197.  This feature allows resource limited clients to access
-        small parts of large messages.  The formal syntax for this is:
-
-   fetch_att       ::= "ENVELOPE" / "FLAGS" / "INTERNALDATE" /
-                       fetch_key / (fetch_key SP NUMBER ":" NUMBER)
-
-   fetch_key       ::= "RFC822" / "RFC822.HEADER" / "RFC822.SIZE" /
-                       "RFC822.TEXT" / key
-
-      If the lower bound number (the number to the left of the colon)
-      exceeds the maximum size of the field then the empty string is
-      returned.  If the upper bound exceeds the maximum size of the
-      field but the lower bound does not then the server will return the
-      remaining substring of the field after the lower bound.  The
-
-
-
-Rice                                                           [Page 47]
-
-RFC 1203                         IMAP3                     February 1991
-
-
-      bounds specified are zero indexed into the fields and the bounds
-      index fields by 8-bit bytes.
-
-      Justification:  This feature is provided so as to allow resource-
-      limited clients to read very large messages and also to allow
-      clients to improve interactive response for the reading of large
-      messages by fetching the first "screen full" of data to display
-      immediately and fetching the rest of the message in the
-      background.
-
-   SET.EOL - When enabled (default is disabled), this feature
-        allows the new command SET.EOL to be available, changing the
-        grammar as follows:
-
-   character       ::= "CR" / "LF" / number
-
-   request         ::= tag SP (noop / login / logout / select / check /
-                       expunge / copy / fetch / store / search /
-                       select_version / select_features /
-                       supported_versions / bboard / find /
-                       read_only / read_write / flags / set_flags /
-                       set_eol) CRLF
-
-   set_eol         ::= "SET.EOL" 1#character
-
-      This has the effect of changing the end of line character sequence
-      generated by the server for newlines within strings to the
-      sequence of characters specified.  The characters in the sequence
-      can be either the specified symbolically named characters or a
-      numerical value, specifying the decimal value of the character to
-      use.  Thus, if the client would like newlines in strings to be
-      indicated by a carriage return followed by a control-d, the client
-      would issue the following command:
-
-           tag42 SET.EOL CR 4
-
-      If the server is unable to support the combination of characters
-      requested by the client as its end-of-line pattern it will reply
-      with a NO response.  This might be the case, for example, if a
-      server is only able to generate its own native line feed pattern
-      and the CRLF required by IMAP by default.
-
-      The server is required to change any length denoting values, such
-      as envelope byte counts for all future transactions to reflect the
-      new eol setting.  This change in reported sizes should apply to
-      all generic size fetching keys, but not to concrete ones such as
-      RFC822.SIZE, which by their very nature require a size measurement
-      in RFC822 format, i.e., with CRLF as the end-of-line convention.
-
-
-
-Rice                                                           [Page 48]
-
-RFC 1203                         IMAP3                     February 1991
-
-
-      Justification: This feature is provided because frequently clients
-      and servers might have end-of-line conventions other than the CRLF
-      specified by RFC822.  It is undesirable that the IMAP be linked
-      too closely to RFC822 and selecting a different convention might
-      allow substantial performance improvements in both clients and
-      servers by saving either client, server or both from having to
-      shuffle text around so as to add or remove non-local end-of-line
-      sequences.
-
-Acknowledgements:
-
-   This text is based on RFC 1064 by Mark Crispin.
-
-   The following have made major contributions to this proposed update
-   to the IMAP2 protocol:
-
-      James Rice               <Rice@sumex-aim.stanford.edu>
-      Richard Acuff            <acuff@sumex-aim.stanford.edu>
-      Bill Yeager              <yeager@sumex-aim.stanford.edu>
-      Christopher Lane         <lane@sumex-aim.stanford.edu>
-      Bjorn Victor             <Bjorn.Victor@docs.uu.se>
-
-   Additional input was also received from:
-
-      Andrew Sweer             <sweer@sumex-aim.stanford.edu>
-      Tom Gruber               <Gruber@sumex-aim.stanford.edu>
-      Kevin Brock              <Brock@Sumex-Aim.Stanford.Edu>
-      Mark Crispin             <MRC@cac.washington.edu>
-
-Security Considerations
-
-   Security issues are not discussed in this memo.
-
-Author's Address
-
-   James Rice
-   Stanford University
-   Knowledge Systems Laboratory
-   701 Welch Road
-   Building C
-   Palo Alto, CA 94304
-
-   Phone: (415) 723-8405
-   EMail: RICE@SUMEX-AIM.STANFORD.EDU
-
-
-
-
-
-
-
-Rice                                                           [Page 49]
-
-\ No newline at end of file
diff --git a/RFC/rfc1225.txt b/RFC/rfc1225.txt
deleted file mode 100644
index 8d7e0029..00000000
--- a/RFC/rfc1225.txt
+++ /dev/null
@@ -1,899 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                            M. Rose
-Request for Comments: 1225             Performance Systems International
-Obsoletes: RFC 1081                                             May 1991
-
-
-                    Post Office Protocol - Version 3
-
-Status of this Memo
-
-   This memo suggests a simple method for workstations to dynamically
-   access mail from a mailbox server.  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.
-
-Overview
-
-   This memo is a republication of RFC 1081 which was based on RFC 918
-   (since revised as RFC 937).  Although similar in form to the original
-   Post Office Protocol (POP) proposed for the Internet community, the
-   protocol discussed in this memo is similar in spirit to the ideas
-   investigated by the MZnet project at the University of California,
-   Irvine.
-
-   Further, substantial work was done on examining POP in a PC-based
-   environment.  This work, which resulted in additional functionality
-   in this protocol, was performed by the ACIS Networking Systems Group
-   at Stanford University.  The author gratefully acknowledges their
-   interest.
-
-Introduction
-
-   On certain types of smaller nodes in the Internet it is often
-   impractical to maintain a message transport system (MTS).  For
-   example, a workstation may not have sufficient resources (cycles,
-   disk space) in order to permit a SMTP server and associated local
-   mail delivery system to be kept resident and continuously running.
-   Similarly, it may be expensive (or impossible) to keep a personal
-   computer interconnected to an IP-style network for long amounts of
-   time (the node is lacking the resource known as "connectivity").
-
-   Despite this, it is often very useful to be able to manage mail on
-   these smaller nodes, and they often support a user agent (UA) to aid
-   the tasks of mail handling.  To solve this problem, a node which can
-   support an MTS entity offers a maildrop service to these less endowed
-   nodes.  The Post Office Protocol - Version 3 (POP3) is intended to
-
-
-
-Rose                                                            [Page 1]
-
-RFC 1225                          POP3                          May 1991
-
-
-   permit a workstation to dynamically access a maildrop on a server
-   host in a useful fashion.  Usually, this means that the POP3 is used
-   to allow a workstation to retrieve mail that the server is holding
-   for it.
-
-   For the remainder of this memo, the term "client host" refers to a
-   host making use of the POP3 service, while the term "server host"
-   refers to a host which offers the POP3 service.
-
-A Short Digression
-
-   This memo does not specify how a client host enters mail into the
-   transport system, although a method consistent with the philosophy of
-   this memo is presented here:
-
-      When the user agent on a client host wishes to enter a message
-      into the transport system, it establishes an SMTP connection to
-      its relay host (this relay host could be, but need not be, the
-      POP3 server host for the client host).
-
-   If this method is followed, then the client host appears to the MTS
-   as a user agent, and should NOT be regarded as a "trusted" MTS entity
-   in any sense whatsoever.  This concept, along with the role of the
-   POP3 as a part of a split-UA model is discussed later in this memo.
-
-   Initially, the server host starts the POP3 service by listening on
-   TCP port 110.  When a client host wishes to make use of the service,
-   it establishes a TCP connection with the server host.  When the
-   connection is established, the POP3 server sends a greeting.  The
-   client and POP3 server then exchange commands and responses
-   (respectively) until the connection is closed or aborted.
-
-   Commands in the POP3 consist of a keyword possibly followed by an
-   argument.  All commands are terminated by a CRLF pair.
-
-   Responses in the POP3 consist of a success indicator and a keyword
-   possibly followed by additional information.  All responses are
-   terminated by a CRLF pair.  There are currently two success
-   indicators: positive ("+OK") and negative ("-ERR").
-
-   Responses to certain commands are multi-line.  In these cases, which
-   are clearly indicated below, after sending the first line of the
-   response and a CRLF, any additional lines are sent, each terminated
-   by a CRLF pair.  When all lines of the response have been sent, a
-   final line is sent, consisting of a termination octet (decimal code
-   046, ".") and a CRLF pair.  If any line of the multi-line response
-   begins with the termination octet, the line is "byte-stuffed" by
-   pre-pending the termination octet to that line of the response.
-
-
-
-Rose                                                            [Page 2]
-
-RFC 1225                          POP3                          May 1991
-
-
-   Hence a multi-line response is terminated with the five octets
-   "CRLF.CRLF".  When examining a multi-line response, the client checks
-   to see if the line begins with the termination octet.  If so and if
-   octets other than CRLF follow, the the first octet of the line (the
-   termination octet) is stripped away.  If so and if CRLF immediately
-   follows the termination character, then the response from the POP
-   server is ended and the line containing ".CRLF" is not considered
-   part of the multi-line response.
-
-   A POP3 session progresses through a number of states during its
-   lifetime.  Once the TCP connection has been opened and the POP3
-   server has sent the greeting, the session enters the AUTHORIZATION
-   state.  In this state, the client must identify itself to the POP3
-   server.  Once the client has successfully done this, the server
-   acquires resources associated with the client's maildrop, and the
-   session enters the TRANSACTION state.  In this state, the client
-   requests actions on the part of the POP3 server.  When the client has
-   finished its transactions, the session enters the UPDATE state.  In
-   this state, the POP3 server releases any resources acquired during
-   the TRANSACTION state and says goodbye.  The TCP connection is then
-   closed.
-
-The AUTHORIZATION State
-
-   Once the TCP connection has been opened by a POP3 client, the POP3
-   server issues a one line greeting.  This can be any string terminated
-   by CRLF.  An example might be:
-
-      S.  +OK dewey POP3 server ready (Comments to: PostMaster@UDEL.EDU)
-
-   Note that this greeting is a POP3 reply.  The POP3 server should
-   always give a positive response as the greeting.
-
-   The POP3 session is now in the AUTHORIZATION state.  The client must
-   now issue the USER command.  If the POP3 server responds with a
-   positive success indicator ("+OK"), then the client may issue either
-   the PASS command to complete the authorization, or the QUIT command
-   to terminate the POP3 session.  If the POP3 server responds with a
-   negative success indicator ("-ERR") to the USER command, then the
-   client may either issue a new USER command or may issue the QUIT
-   command.
-
-   When the client issues the PASS command, the POP3 server uses the
-   argument pair from the USER and PASS commands to determine if the
-   client should be given access to the appropriate maildrop.  If so,
-   the POP3 server then acquires an exclusive-access lock on the
-   maildrop.  If the lock is successfully acquired, the POP3 server
-   parses the maildrop into individual messages (read note below),
-
-
-
-Rose                                                            [Page 3]
-
-RFC 1225                          POP3                          May 1991
-
-
-   determines the last message (if any) present in the maildrop that was
-   referenced by the RETR command, and responds with a positive success
-   indicator.  The POP3 session now enters the TRANSACTION state.  If
-   the lock can not be acquired or the client should is denied access to
-   the appropriate maildrop or the maildrop can't be parsed for some
-   reason, the POP3 server responds with a negative success indicator.
-   (If a lock was acquired but the POP3 server intends to respond with a
-   negative success indicator, the POP3 server must release the lock
-   prior to rejecting the command.)  At this point, the client may
-   either issue a new USER command and start again, or the client may
-   issue the QUIT command.
-
-                 NOTE: Minimal implementations of the POP3 need only be
-                 able to break a maildrop into its component messages;
-                 they need NOT be able to parse individual messages.
-                 More advanced implementations may wish to have this
-                 capability, for reasons discussed later.
-
-   After the POP3 server has parsed the maildrop into individual
-   messages, it assigns a message-id to each message, and notes the size
-   of the message in octets.  The first message in the maildrop is
-   assigned a message-id of "1", the second is assigned "2", and so on,
-   so that the n'th message in a maildrop is assigned a message-id of
-   "n".  In POP3 commands and responses, all message-id's and message
-   sizes are expressed in base-10 (i.e., decimal).
-
-   It sets the "highest number accessed" to be that of the last message
-   referenced by the RETR command.
-
-   Here are summaries for the three POP3 commands discussed thus far:
-
-           USER name
-               Arguments: a server specific user-id (required)
-               Restrictions: may only be given in the AUTHORIZATION
-                   state after the POP3 greeting or after an
-                   unsuccessful USER or PASS command
-               Possible Responses:
-                   +OK name is welcome here
-                   -ERR never heard of name
-               Examples:
-                   C:    USER mrose
-                   S:    +OK mrose is a real hoopy frood
-                     ...
-                   C:    USER frated
-                   S:    -ERR sorry, frated doesn't get his mail here
-
-           PASS string
-               Arguments: a server/user-id specific password (required)
-
-
-
-Rose                                                            [Page 4]
-
-RFC 1225                          POP3                          May 1991
-
-
-               Restrictions: may only be given in the AUTHORIZATION
-                   state after a successful USER command
-               Possible Responses:
-                   +OK maildrop locked and ready
-                   -ERR invalid password
-                   -ERR unable to lock maildrop
-               Examples:
-                   C:    USER mrose
-                   S:    +OK mrose is a real hoopy frood
-                   C:    PASS secret
-                   S:    +OK mrose's maildrop has 2 messages
-                         (320 octets)
-                     ...
-                   C:    USER mrose
-                   S:    +OK mrose is a real hoopy frood
-                   C:    PASS secret
-                   S:    -ERR unable to lock mrose's maildrop, file
-                         already locked
-
-           QUIT
-               Arguments: none
-               Restrictions: none
-               Possible Responses:
-                   +OK
-               Examples:
-                   C:    QUIT
-                   S:    +OK dewey POP3 server signing off
-
-
-The TRANSACTION State
-
-   Once the client has successfully identified itself to the POP3 server
-   and the POP3 server has locked and burst the appropriate maildrop,
-   the POP3 session is now in the TRANSACTION state.  The client may now
-   issue any of the following POP3 commands repeatedly.  After each
-   command, the POP3 server issues a response.  Eventually, the client
-   issues the QUIT command and the POP3 session enters the UPDATE state.
-
-   Here are the POP3 commands valid in the TRANSACTION state:
-
-           STAT
-               Arguments: none
-               Restrictions: may only be given in the TRANSACTION state.
-               Discussion:
-
-                 The POP3 server issues a positive response with a line
-                 containing information for the maildrop.  This line is
-                 called a "drop listing" for that maildrop.
-
-
-
-Rose                                                            [Page 5]
-
-RFC 1225                          POP3                          May 1991
-
-
-                 In order to simplify parsing, all POP3 servers are
-                 required to use a certain format for drop listings.
-                 The first octets present must indicate the number of
-                 messages in the maildrop.  Following this is the size
-                 of the maildrop in octets.  This memo makes no
-                 requirement on what follows the maildrop size.
-                 Minimal implementations should just end that line of
-                 the response with a CRLF pair.  More advanced
-                 implementations may include other information.
-
-                      NOTE: This memo STRONGLY discourages
-                      implementations from supplying additional
-                      information in the drop listing.  Other,
-                      optional, facilities are discussed later on
-                      which permit the client to parse the messages
-                      in the maildrop.
-
-                 Note that messages marked as deleted are not counted in
-                 either total.
-
-               Possible Responses:
-                   +OK nn mm
-               Examples:
-                   C:    STAT
-                   S:    +OK 2 320
-
-           LIST [msg]
-               Arguments: a message-id (optionally)  If a message-id is
-                   given, it may NOT refer to a message marked as
-                   deleted.
-               Restrictions: may only be given in the TRANSACTION state.
-               Discussion:
-
-                 If an argument was given and the POP3 server issues a
-                 positive response with a line containing information
-                 for that message.  This line is called a "scan listing"
-                 for that message.
-
-                 If no argument was given and the POP3 server issues a
-                 positive response, then the response given is
-                 multi-line.  After the initial +OK, for each message
-                 in the maildrop, the POP3 server responds with a line
-                 containing information for that message.  This line
-                 is called a "scan listing" for that message.
-
-                 In order to simplify parsing, all POP3 servers are
-                 required to use a certain format for scan listings.
-                 The first octets present must be the message-id of
-
-
-
-Rose                                                            [Page 6]
-
-RFC 1225                          POP3                          May 1991
-
-
-                 the message.  Following the message-id is the size of
-                 the message in octets.  This memo makes no requirement
-                 on what follows the message size in the scan listing.
-                 Minimal implementations should just end that line of
-                 the response with a CRLF pair.  More advanced
-                 implementations may include other information, as
-                 parsed from the message.
-
-                      NOTE: This memo STRONGLY discourages
-                      implementations from supplying additional
-                      information in the scan listing.  Other, optional,
-                      facilities are discussed later on which permit
-                      the client to parse the messages in the maildrop.
-
-                 Note that messages marked as deleted are not listed.
-
-               Possible Responses:
-                   +OK scan listing follows
-                   -ERR no such message
-               Examples:
-                   C:    LIST
-                   S:    +OK 2 messages (320 octets)
-                   S:    1 120
-                   S:    2 200
-                   S:    .
-                     ...
-                   C:    LIST 2
-                   S:    +OK 2 200
-                     ...
-                   C:    LIST 3
-                   S:    -ERR no such message, only 2 messages in
-                         maildrop
-
-           RETR msg
-               Arguments: a message-id (required)  This message-id may
-                   NOT refer to a message marked as deleted.
-               Restrictions: may only be given in the TRANSACTION state.
-               Discussion:
-
-                 If the POP3 server issues a positive response, then the
-                 response given is multi-line.  After the initial +OK,
-                 the POP3 server sends the message corresponding to the
-                 given message-id, being careful to byte-stuff the
-                 termination character (as with all multi-line
-                 responses).
-
-                 If the number associated with this message is higher
-                 than the "highest number accessed" in the maildrop, the
-
-
-
-Rose                                                            [Page 7]
-
-RFC 1225                          POP3                          May 1991
-
-
-                 POP3 server updates the "highest number accessed" to
-                 the number associated with this message.
-
-               Possible Responses:
-                   +OK message follows
-                   -ERR no such message
-               Examples:
-                   C:    RETR 1
-                   S:    +OK 120 octets
-                   S:    <the POP3 server sends the entire message here>
-                   S:    .
-
-           DELE msg
-               Arguments: a message-id (required)  This message-id
-                   may NOT refer to a message marked as deleted.
-               Restrictions: may only be given in the TRANSACTION state.
-               Discussion:
-
-                 The POP3 server marks the message as deleted.  Any
-                 future reference to the message-id associated with the
-                 message in a POP3 command generates an error.  The POP3
-                 server does not actually delete the message until the
-                 POP3 session enters the UPDATE state.
-
-                 If the number associated with this message is higher
-                 than the "highest number accessed" in the maildrop,
-                 the POP3 server updates the "highest number accessed"
-                 to the number associated with this message.
-
-               Possible Responses:
-                   +OK message deleted
-                   -ERR no such message
-               Examples:
-                   C:    DELE 1
-                   S:    +OK message 1 deleted
-                     ...
-                   C:    DELE 2
-                   S:    -ERR message 2 already deleted
-
-           NOOP
-               Arguments: none
-               Restrictions: may only be given in the TRANSACTION state.
-               Discussion:
-
-                 The POP3 server does nothing, it merely replies with a
-                 positive response.
-
-               Possible Responses:
-
-
-
-Rose                                                            [Page 8]
-
-RFC 1225                          POP3                          May 1991
-
-
-                   +OK
-               Examples:
-                   C:    NOOP
-                   S:    +OK
-
-           LAST
-               Arguments: none
-               Restrictions: may only be issued in the TRANSACTION state.
-               Discussion:
-
-                 The POP3 server issues a positive response with a line
-                 containing the highest message number which accessed.
-                 Zero is returned in case no message in the maildrop has
-                 been accessed during previous transactions.  A client
-                 may thereafter infer that messages, if any, numbered
-                 greater than the response to the LAST command are
-                 messages not yet accessed by the client.
-
-             Possible Response:
-                   +OK nn
-
-             Examples:
-                   C:      STAT
-                   S:      +OK 4 320
-                   C:      LAST
-                   S:      +OK 1
-                   C:      RETR 3
-                   S:      +OK 120 octets
-                   S:      <the POP3 server sends the entire message
-                           here>
-                   S:      .
-                   C:      LAST
-                   S:      +OK 3
-                   C:      DELE 2
-                   S:      +OK message 2 deleted
-                   C:      LAST
-                   S:      +OK 3
-                   C:      RSET
-                   S:      +OK
-                   C:      LAST
-                   S:      +OK 1
-
-           RSET
-               Arguments: none
-               Restrictions: may only be given in the TRANSACTION
-                   state.
-               Discussion:
-
-
-
-
-Rose                                                            [Page 9]
-
-RFC 1225                          POP3                          May 1991
-
-
-                 If any messages have been marked as deleted by the POP3
-                 server, they are unmarked.  The POP3 server then
-                 replies with a positive response.  In addition, the
-                 "highest number accessed" is also reset to the value
-                 determined at the beginning of the POP3 session.
-
-               Possible Responses:
-                   +OK
-               Examples:
-                   C:    RSET
-                   S:    +OK maildrop has 2 messages (320 octets)
-
-
-
-The UPDATE State
-
-   When the client issues the QUIT command from the TRANSACTION state,
-   the POP3 session enters the UPDATE state.  (Note that if the client
-   issues the QUIT command from the AUTHORIZATION state, the POP3
-   session terminates but does NOT enter the UPDATE state.)
-
-           QUIT
-               Arguments: none
-               Restrictions: none
-               Discussion:
-
-                 The POP3 server removes all messages marked as deleted
-                 from the maildrop.  It then releases the
-                 exclusive-access lock on the maildrop and replies as
-                 to the success of
-                 these operations.  The TCP connection is then closed.
-
-               Possible Responses:
-                   +OK
-               Examples:
-                   C:    QUIT
-                   S:    +OK dewey POP3 server signing off (maildrop
-                         empty)
-                     ...
-                   C:    QUIT
-                   S:    +OK dewey POP3 server signing off (2 messages
-                         left)
-                     ...
-
-
-Optional POP3 Commands
-
-   The POP3 commands discussed above must be supported by all minimal
-
-
-
-Rose                                                           [Page 10]
-
-RFC 1225                          POP3                          May 1991
-
-
-   implementations of POP3 servers.
-
-   The optional POP3 commands described below permit a POP3 client
-   greater freedom in message handling, while preserving a simple POP3
-   server implementation.
-
-                 NOTE: This memo STRONGLY encourages implementations to
-                 support these commands in lieu of developing augmented
-                 drop and scan listings.  In short, the philosophy of
-                 this memo is to put intelligence in the part of the
-                 POP3 client and not the POP3 server.
-
-           TOP msg n
-               Arguments: a message-id (required) and a number.  This
-                   message-id may NOT refer to a message marked as
-                   deleted.
-               Restrictions: may only be given in the TRANSACTION state.
-               Discussion:
-
-                 If the POP3 server issues a positive response, then
-                 the response given is multi-line.  After the initial
-                 +OK, the POP3 server sends the headers of the message,
-                 the blank line separating the headers from the body,
-                 and then the number of lines indicated message's body,
-                 being careful to byte-stuff the termination character
-                 (as with all multi-line responses).
-
-                 Note that if the number of lines requested by the POP3
-                 client is greater than than the number of lines in the
-                 body, then the POP3 server sends the entire message.
-
-               Possible Responses:
-                   +OK top of message follows
-                   -ERR no such message
-               Examples:
-                   C:    TOP 10
-                   S:    +OK
-                   S:    <the POP3 server sends the headers of the
-                          message, a blank line, and the first 10 lines
-                          of the body of the message>
-                   S:    .
-                     ...
-                   C:    TOP 100
-                   S:    -ERR no such message
-
-           RPOP user
-               Arguments: a client specific user-id (required)
-               Restrictions: may only be given in the AUTHORIZATION
-
-
-
-Rose                                                           [Page 11]
-
-RFC 1225                          POP3                          May 1991
-
-
-                   state after a successful USER command; in addition,
-                   may only be given if the client used a reserved
-                   (privileged) TCP port to connect to the server.
-               Discussion:
-
-                 The RPOP command may be used instead of the PASS
-                 command to authenticate access to the maildrop.  In
-                 order for this command to be successful, the POP3
-                 client must use a reserved TCP port (port < 1024) to
-                 connect tothe server.  The POP3 server uses the
-                 argument pair from the USER and RPOP commands to
-                 determine if the client should be given access to
-                 the appropriate maildrop.  Unlike the PASS command
-                 however, the POP3 server considers if the remote user
-                 specified by the RPOP command who resides on the POP3
-                 client host is allowed to access the maildrop for the
-                 user specified by the USER command (e.g., on Berkeley
-                 UNIX, the .rhosts mechanism is used).  With the
-                 exception of this differing in authentication, this
-                 command is identical to the PASS command.
-
-                 Note that the use of this feature has allowed much wider
-                 penetration into numerous hosts on local networks (and
-                 sometimes remote networks) by those who gain illegal
-                 access to computers by guessing passwords or otherwise
-                 breaking into the system.
-
-               Possible Responses:
-                   +OK maildrop locked and ready
-                   -ERR permission denied
-               Examples:
-                   C:    USER mrose
-                   S:    +OK mrose is a real hoopy frood
-                   C:    RPOP mrose
-                   S:    +OK mrose's maildrop has 2 messages (320
-                         octets)
-
-       Minimal POP3 Commands:
-           USER name               valid in the AUTHORIZATION state
-           PASS string
-           QUIT
-
-           STAT                    valid in the TRANSACTION state
-           LIST [msg]
-           RETR msg
-           DELE msg
-           NOOP
-           LAST
-
-
-
-Rose                                                           [Page 12]
-
-RFC 1225                          POP3                          May 1991
-
-
-           RSET
-
-           QUIT                    valid in the UPDATE state
-
-       Optional POP3 Commands:
-           RPOP user               valid in the AUTHORIZATION state
-
-           TOP msg n               valid in the TRANSACTION state
-
-       POP3 Replies:
-           +OK
-           -ERR
-
-       Note that with the exception of the STAT command, the reply given
-       by the POP3 server to any command is significant only to "+OK"
-       and "-ERR".  Any text occurring after this reply may be ignored
-       by the client.
-
-Example POP3 Session
-
-    S: <wait for connection on TCP port 110>
-        ...
-    C: <open connection>
-    S:    +OK dewey POP3 server ready (Comments to: PostMaster@UDEL.EDU)
-    C:    USER mrose
-    S:    +OK mrose is a real hoopy frood
-    C:    PASS secret
-    S:    +OK mrose's maildrop has 2 messages (320 octets)
-    C:    STAT
-    S:    +OK 2 320
-    C:    LIST
-    S:    +OK 2 messages (320 octets)
-    S:    1 120
-    S:    2 200
-    S:    .
-    C:    RETR 1
-    S:    +OK 120 octets
-    S:    <the POP3 server sends message 1>
-    S:    .
-    C:    DELE 1
-    S:    +OK message 1 deleted
-    C:    RETR 2
-    S:    +OK 200 octets
-    S:    <the POP3 server sends message 2>
-    S:    .
-    C:    DELE 2
-    S:    +OK message 2 deleted
-    C:    QUIT
-
-
-
-Rose                                                           [Page 13]
-
-RFC 1225                          POP3                          May 1991
-
-
-    S:    +OK dewey POP3 server signing off (maildrop empty)
-    C:  <close connection>
-    S:  <wait for next connection>
-
-Message Format
-
-   All messages transmitted during a POP3 session are assumed to conform
-   to the standard for the format of Internet text messages [RFC822].
-
-   It is important to note that the byte count for a message on the
-   server host may differ from the octet count assigned to that message
-   due to local conventions for designating end-of-line.  Usually,
-   during the AUTHORIZATION state of the POP3 session, the POP3 client
-   can calculate the size of each message in octets when it parses the
-   maildrop into messages.  For example, if the POP3 server host
-   internally represents end-of-line as a single character, then the
-   POP3 server simply counts each occurrence of this character in a
-   message as two octets.  Note that lines in the message which start
-   with the termination octet need not be counted twice, since the POP3
-   client will remove all byte-stuffed termination characters when it
-   receives a multi-line response.
-
-The POP and the Split-UA model
-
-   The underlying paradigm in which the POP3 functions is that of a
-   split-UA model.  The POP3 client host, being a remote PC based
-   workstation, acts solely as a client to the message transport system.
-   It does not provide delivery/authentication services to others.
-   Hence, it is acting as a UA, on behalf of the person using the
-   workstation.  Furthermore, the workstation uses SMTP to enter mail
-   into the MTS.
-
-   In this sense, we have two UA functions which interface to the
-   message transport system: Posting (SMTP) and Retrieval (POP3).  The
-   entity which supports this type of environment is called a split-UA
-   (since the user agent is split between two hosts which must
-   interoperate to provide these functions).
-
-                 ASIDE:  Others might term this a remote-UA instead.
-                 There are arguments supporting the use of both terms.
-
-   This memo has explicitly referenced TCP as the underlying transport
-   agent for the POP3.  This need not be the case.  In the MZnet split-
-   UA, for example, personal micro-computer systems are used which do
-   not have IP-style networking capability.  To connect to the POP3
-   server host, a PC establishes a terminal connection using some simple
-   protocol (PhoneNet).  A program on the PC drives the connection,
-   first establishing a login session as a normal user.  The login shell
-
-
-
-Rose                                                           [Page 14]
-
-RFC 1225                          POP3                          May 1991
-
-
-   for this pseudo-user is a program which drives the other half of the
-   terminal protocol and communicates with one of two servers.  Although
-   MZnet can support several PCs, a single pseudo-user login is present
-   on the server host.  The user-id and password for this pseudo-user
-   login is known to all members of MZnet.  Hence, the first action of
-   the login shell, after starting the terminal protocol, is to demand a
-   USER/PASS authorization pair from the PC.  This second level of
-   authorization is used to ascertain who is interacting with the MTS.
-   Although the server host is deemed to support a "trusted" MTS entity,
-   PCs in MZnet are not.  Naturally, the USER/PASS authorization pair
-   for a PC is known only to the owner of the PC (in theory, at least).
-
-   After successfully verifying the identity of the client, a modified
-   SMTP server is started, and the PC posts mail with the server host.
-   After the QUIT command is given to the SMTP server and it terminates,
-   a modified POP3 server is started, and the PC retrieves mail from the
-   server host.  After the QUIT command is given to the POP3 server and
-   it terminates, the login shell for the pseudo-user terminates the
-   terminal protocol and logs the job out.  The PC then closes the
-   terminal connection to the server host.
-
-   The SMTP server used by MZnet is modified in the sense that it knows
-   that it's talking to a user agent and not a "trusted" entity in the
-   message transport system.  Hence, it does performs the validation
-   activities normally performed by an entity in the MTS when it accepts
-   a message from a UA.
-
-   The POP3 server used by MZnet is modified in the sense that it does
-   not require a USER/PASS combination before entering the TRANSACTION
-   state.  The reason for this (of course) is that the PC has already
-   identified itself during the second-level authorization step
-   described above.
-
-                 NOTE: Truth in advertising laws require that the author
-                 of this memo state that MZnet has not actually been
-                 fully implemented.  The concepts presented and proven
-                 by the project led to the notion of the MZnet
-                 split-slot model.  This notion has inspired the
-                 split-UA concept described in this memo, led to the
-                 author's interest in the POP, and heavily influenced
-                 the the description of the POP3 herein.
-
-   In fact, some UAs present in the Internet already support the notion
-   of posting directly to an SMTP server and retrieving mail directly
-   from a POP server, even if the POP server and client resided on the
-   same host!
-
-                 ASIDE: this discussion raises an issue which this memo
-
-
-
-Rose                                                           [Page 15]
-
-RFC 1225                          POP3                          May 1991
-
-
-                 purposedly avoids: how does SMTP know that it's talking
-                 to a "trusted" MTS entity?
-
-References
-
-     [MZnet]   Stefferud, E., J. Sweet, and T. Domae, "MZnet: Mail
-               Service for Personal Micro-Computer Systems",
-               Proceedings, IFIP 6.5 International Conference on
-               Computer Message Systems, Nottingham, U.K., May 1984.
-
-     [RFC821]  Postel, J., "Simple Mail Transfer Protocol",
-               USC/Information Sciences Institute, August 1982.
-
-     [RFC822]  Crocker, D., "Standard for the Format of ARPA-Internet
-               Text Messages", University of Delaware, August 1982.
-
-     [RFC937]  Butler, M., J. Postel, D. Chase, J. Goldberger, and J.
-               Reynolds, "Post Office Protocol - Version 2", RFC 937,
-               USC/Information Sciences Institute, February 1985.
-
-     [RFC1060] Reynolds, J., and J. Postel, "Assigned Numbers", RFC
-               1060, USC/Information Sciences Institute, March 1990.
-
-Security Considerations
-
-   Security issues are not discussed in this memo.
-
-Author's Address:
-
-   Marshall T. Rose
-   Performance Systems International
-   5201 Great America Parkway
-   Suite 3106
-   Santa Clara, CA  95054
-
-   Phone: +1 408 562 6222
-
-   EMail: mrose@psi.com
-   X.500:  rose, psi, us
-
-
-
-
-
-
-
-
-
-
-
-
-Rose                                                           [Page 16]
-
-\ No newline at end of file
diff --git a/RFC/rfc1460.txt b/RFC/rfc1460.txt
deleted file mode 100644
index d6177599..00000000
--- a/RFC/rfc1460.txt
+++ /dev/null
@@ -1,955 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                            M. Rose
-Request for Comments: 1460                  Dover Beach Consulting, Inc.
-Obsoletes: 1225                                                June 1993
-
-
-                    Post Office Protocol - Version 3
-
-
-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.
-
-Overview
-
-   This memo is a revision to RFC 1225, a Draft Standard.  It makes the
-   following changes from that document:
-
-        - the RPOP facility is removed;
-
-        - the optional APOP facility is added (which is in interoperable,
-          operational use in at least three implementations);
-
-        - a typo was corrected with respect to the interaction of LAST
-          and RSET;
-
-        - section numbers were added; and,
-
-        - an acknowledgements section was added.
-
-1. Introduction
-
-   On certain types of smaller nodes in the Internet it is often
-   impractical to maintain a message transport system (MTS).  For
-   example, a workstation may not have sufficient resources (cycles,
-   disk space) in order to permit a SMTP server [RFC821] and associated
-   local mail delivery system to be kept resident and continuously
-   running.
-
-   Similarly, it may be expensive (or impossible) to keep a personal
-   computer interconnected to an IP-style network for long amounts of
-   time (the node is lacking the resource known as "connectivity").
-
-   Despite this, it is often very useful to be able to manage mail on
-   these smaller nodes, and they often support a user agent (UA) to aid
-
-
-
-Rose                                                            [Page 1]
-
-RFC 1460                          POP3                         June 1993
-
-
-   the tasks of mail handling.  To solve this problem, a node which can
-   support an MTS entity offers a maildrop service to these less endowed
-   nodes.  The Post Office Protocol - Version 3 (POP3) is intended to
-   permit a workstation to dynamically access a maildrop on a server
-   host in a useful fashion.  Usually, this means that the POP3 is used
-   to allow a workstation to retrieve mail that the server is holding
-   for it.
-
-   For the remainder of this memo, the term "client host" refers to a
-   host making use of the POP3 service, while the term "server host"
-   refers to a host which offers the POP3 service.
-
-2. A Short Digression
-
-   This memo does not specify how a client host enters mail into the
-   transport system, although a method consistent with the philosophy of
-   this memo is presented here:
-
-      When the user agent on a client host wishes to enter a message
-      into the transport system, it establishes an SMTP connection to
-      its relay host (this relay host could be, but need not be, the
-      POP3 server host for the client host).
-
-   If this method is followed, then the client host appears to the MTS
-   as a user agent, and should NOT be regarded as a "trusted" MTS entity
-   in any sense whatsoever.  This concept, along with the role of the
-   POP3 as a part of a split-UA model is discussed later in this memo.
-
-3. Basic Operation
-
-   Initially, the server host starts the POP3 service by listening on
-   TCP port 110.  When a client host wishes to make use of the service,
-   it establishes a TCP connection with the server host.  When the
-   connection is established, the POP3 server sends a greeting.  The
-   client and POP3 server then exchange commands and responses
-   (respectively) until the connection is closed or aborted.
-
-   Commands in the POP3 consist of a keyword possibly followed by an
-   argument.  All commands are terminated by a CRLF pair.
-
-   Responses in the POP3 consist of a success indicator and a keyword
-   possibly followed by additional information.  All responses are
-   terminated by a CRLF pair.  There are currently two success
-   indicators: positive ("+OK") and negative ("-ERR").
-
-   Responses to certain commands are multi-line.  In these cases, which
-   are clearly indicated below, after sending the first line of the
-   response and a CRLF, any additional lines are sent, each terminated
-
-
-
-Rose                                                            [Page 2]
-
-RFC 1460                          POP3                         June 1993
-
-
-   by a CRLF pair.  When all lines of the response have been sent, a
-   final line is sent, consisting of a termination octet (decimal code
-   046, ".") and a CRLF pair.  If any line of the multi-line response
-   begins with the termination octet, the line is "byte-stuffed" by
-   pre-pending the termination octet to that line of the response.
-
-   Hence a multi-line response is terminated with the five octets
-   "CRLF.CRLF".  When examining a multi-line response, the client checks
-   to see if the line begins with the termination octet.  If so and if
-   octets other than CRLF follow, the the first octet of the line (the
-   termination octet) is stripped away.  If so and if CRLF immediately
-   follows the termination character, then the response from the POP
-   server is ended and the line containing ".CRLF" is not considered
-   part of the multi-line response.
-
-   A POP3 session progresses through a number of states during its
-   lifetime.  Once the TCP connection has been opened and the POP3
-   server has sent the greeting, the session enters the AUTHORIZATION
-   state.  In this state, the client must identify itself to the POP3
-   server.  Once the client has successfully done this, the server
-   acquires resources associated with the client's maildrop, and the
-   session enters the TRANSACTION state.  In this state, the client
-   requests actions on the part of the POP3 server.  When the client has
-   finished its transactions, the session enters the UPDATE state.  In
-   this state, the POP3 server releases any resources acquired during
-   the TRANSACTION state and says goodbye.  The TCP connection is then
-   closed.
-
-4. The AUTHORIZATION State
-
-   Once the TCP connection has been opened by a POP3 client, the POP3
-   server issues a one line greeting.  This can be any string terminated
-   by CRLF.  An example might be:
-
-      S.  +OK POP3 server ready
-
-   Note that this greeting is a POP3 reply.  The POP3 server should
-   always give a positive response as the greeting.
-
-   The POP3 session is now in the AUTHORIZATION state.  The client must
-   now issue the USER command.  If the POP3 server responds with a
-   positive success indicator ("+OK"), then the client may issue either
-   the PASS command to complete the authorization, or the QUIT command
-   to terminate the POP3 session.  If the POP3 server responds with a
-   negative success indicator ("-ERR") to the USER command, then the
-   client may either issue a new USER command or may issue the QUIT
-   command.
-
-
-
-
-Rose                                                            [Page 3]
-
-RFC 1460                          POP3                         June 1993
-
-
-   When the client issues the PASS command, the POP3 server uses the
-   argument pair from the USER and PASS commands to determine if the
-   client should be given access to the appropriate maildrop.  If so,
-   the POP3 server then acquires an exclusive-access lock on the
-   maildrop.  If the lock is successfully acquired, the POP3 server
-   parses the maildrop into individual messages (read note below),
-   determines the last message (if any) present in the maildrop that was
-   referenced by the RETR command, and responds with a positive success
-   indicator.  The POP3 session now enters the TRANSACTION state.  If
-   the lock can not be acquired or the client should is denied access to
-   the appropriate maildrop or the maildrop can't be parsed for some
-   reason, the POP3 server responds with a negative success indicator.
-   (If a lock was acquired but the POP3 server intends to respond with a
-   negative success indicator, the POP3 server must release the lock
-   prior to rejecting the command.)  At this point, the client may
-   either issue a new USER command and start again, or the client may
-   issue the QUIT command.
-
-                 NOTE: Minimal implementations of the POP3 need only be
-                 able to break a maildrop into its component messages;
-                 they need NOT be able to parse individual messages.
-                 More advanced implementations may wish to have this
-                 capability, for reasons discussed later.
-
-   After the POP3 server has parsed the maildrop into individual
-   messages, it assigns a message-id to each message, and notes the size
-   of the message in octets.  The first message in the maildrop is
-   assigned a message-id of "1", the second is assigned "2", and so on,
-   so that the n'th message in a maildrop is assigned a message-id of
-   "n".  In POP3 commands and responses, all message-id's and message
-   sizes are expressed in base-10 (i.e., decimal).
-
-   It sets the "highest number accessed" to be that of the last message
-   referenced by the RETR command.
-
-   Here are summaries for the three POP3 commands discussed thus far:
-
-           USER name
-               Arguments: a server specific user-id (required)
-               Restrictions: may only be given in the AUTHORIZATION
-                   state after the POP3 greeting or after an
-                   unsuccessful USER or PASS command
-               Possible Responses:
-                   +OK name is welcome here
-                   -ERR never heard of name
-               Examples:
-                   C:    USER mrose
-                   S:    +OK mrose is a real hoopy frood
-
-
-
-Rose                                                            [Page 4]
-
-RFC 1460                          POP3                         June 1993
-
-
-                     ...
-                   C:    USER frated
-                   S:    -ERR sorry, frated doesn't get his mail here
-
-           PASS string
-               Arguments: a server/user-id specific password (required)
-               Restrictions: may only be given in the AUTHORIZATION
-                   state after a successful USER command
-               Possible Responses:
-                   +OK maildrop locked and ready
-                   -ERR invalid password
-                   -ERR unable to lock maildrop
-               Examples:
-                   C:    USER mrose
-                   S:    +OK mrose is a real hoopy frood
-                   C:    PASS secret
-                   S:    +OK mrose's maildrop has 2 messages
-                         (320 octets)
-                     ...
-                   C:    USER mrose
-                   S:    +OK mrose is a real hoopy frood
-                   C:    PASS secret
-                   S:    -ERR unable to lock mrose's maildrop, file
-                         already locked
-
-           QUIT
-               Arguments: none
-               Restrictions: none
-               Possible Responses:
-                   +OK
-               Examples:
-                   C:    QUIT
-                   S:    +OK dewey POP3 server signing off
-
-5. The TRANSACTION State
-
-   Once the client has successfully identified itself to the POP3 server
-   and the POP3 server has locked and burst the appropriate maildrop,
-   the POP3 session is now in the TRANSACTION state.  The client may now
-   issue any of the following POP3 commands repeatedly.  After each
-   command, the POP3 server issues a response.  Eventually, the client
-   issues the QUIT command and the POP3 session enters the UPDATE state.
-
-   Here are the POP3 commands valid in the TRANSACTION state:
-
-           STAT
-               Arguments: none
-               Restrictions: may only be given in the TRANSACTION state.
-
-
-
-Rose                                                            [Page 5]
-
-RFC 1460                          POP3                         June 1993
-
-
-               Discussion:
-
-                 The POP3 server issues a positive response with a line
-                 containing information for the maildrop.  This line is
-                 called a "drop listing" for that maildrop.
-
-                 In order to simplify parsing, all POP3 servers are
-                 required to use a certain format for drop listings.
-                 The first octets present must indicate the number of
-                 messages in the maildrop.  Following this is the size
-                 of the maildrop in octets.  This memo makes no
-                 requirement on what follows the maildrop size.
-                 Minimal implementations should just end that line of
-                 the response with a CRLF pair.  More advanced
-                 implementations may include other information.
-
-                      NOTE: This memo STRONGLY discourages
-                      implementations from supplying additional
-                      information in the drop listing.  Other,
-                      optional, facilities are discussed later on
-                      which permit the client to parse the messages
-                      in the maildrop.
-
-                 Note that messages marked as deleted are not counted in
-                 either total.
-
-               Possible Responses:
-                   +OK nn mm
-               Examples:
-                   C:    STAT
-                   S:    +OK 2 320
-
-           LIST [msg]
-               Arguments: a message-id (optionally)  If a message-id is
-                   given, it may NOT refer to a message marked as
-                   deleted.
-               Restrictions: may only be given in the TRANSACTION state.
-               Discussion:
-
-                 If an argument was given and the POP3 server issues a
-                 positive response with a line containing information
-                 for that message.  This line is called a "scan listing"
-                 for that message.
-
-                 If no argument was given and the POP3 server issues a
-                 positive response, then the response given is
-                 multi-line.  After the initial +OK, for each message
-                 in the maildrop, the POP3 server responds with a line
-
-
-
-Rose                                                            [Page 6]
-
-RFC 1460                          POP3                         June 1993
-
-
-                 containing information for that message.  This line
-                 is called a "scan listing" for that message.
-
-                 In order to simplify parsing, all POP3 servers are
-                 required to use a certain format for scan listings.
-                 The first octets present must be the message-id of
-                 the message.  Following the message-id is the size of
-                 the message in octets.  This memo makes no requirement
-                 on what follows the message size in the scan listing.
-                 Minimal implementations should just end that line of
-                 the response with a CRLF pair.  More advanced
-                 implementations may include other information, as
-                 parsed from the message.
-
-                      NOTE: This memo STRONGLY discourages
-                      implementations from supplying additional
-                      information in the scan listing.  Other, optional,
-                      facilities are discussed later on which permit
-                      the client to parse the messages in the maildrop.
-
-                 Note that messages marked as deleted are not listed.
-
-               Possible Responses:
-                   +OK scan listing follows
-                   -ERR no such message
-               Examples:
-                   C:    LIST
-                   S:    +OK 2 messages (320 octets)
-                   S:    1 120
-                   S:    2 200
-                   S:    .
-                     ...
-                   C:    LIST 2
-                   S:    +OK 2 200
-                     ...
-                   C:    LIST 3
-                   S:    -ERR no such message, only 2 messages in
-                         maildrop
-
-           RETR msg
-               Arguments: a message-id (required)  This message-id may
-                   NOT refer to a message marked as deleted.
-               Restrictions: may only be given in the TRANSACTION state.
-               Discussion:
-
-                 If the POP3 server issues a positive response, then the
-                 response given is multi-line.  After the initial +OK,
-                 the POP3 server sends the message corresponding to the
-
-
-
-Rose                                                            [Page 7]
-
-RFC 1460                          POP3                         June 1993
-
-
-                 given message-id, being careful to byte-stuff the
-                 termination character (as with all multi-line
-                 responses).
-
-                 If the number associated with this message is higher
-                 than the "highest number accessed" in the maildrop, the
-                 POP3 server updates the "highest number accessed" to
-                 the number associated with this message.
-
-               Possible Responses:
-                   +OK message follows
-                   -ERR no such message
-               Examples:
-                   C:    RETR 1
-                   S:    +OK 120 octets
-                   S:    <the POP3 server sends the entire message here>
-                   S:    .
-
-           DELE msg
-               Arguments: a message-id (required)  This message-id
-                   may NOT refer to a message marked as deleted.
-               Restrictions: may only be given in the TRANSACTION state.
-               Discussion:
-
-                 The POP3 server marks the message as deleted.  Any
-                 future reference to the message-id associated with the
-                 message in a POP3 command generates an error.  The POP3
-                 server does not actually delete the message until the
-                 POP3 session enters the UPDATE state.
-
-                 If the number associated with this message is higher
-                 than the "highest number accessed" in the maildrop,
-                 the POP3 server updates the "highest number accessed"
-                 to the number associated with this message.
-
-               Possible Responses:
-                   +OK message deleted
-                   -ERR no such message
-               Examples:
-                   C:    DELE 1
-                   S:    +OK message 1 deleted
-                     ...
-                   C:    DELE 2
-                   S:    -ERR message 2 already deleted
-
-           NOOP
-               Arguments: none
-               Restrictions: may only be given in the TRANSACTION state.
-
-
-
-Rose                                                            [Page 8]
-
-RFC 1460                          POP3                         June 1993
-
-
-               Discussion:
-
-                 The POP3 server does nothing, it merely replies with a
-                 positive response.
-
-               Possible Responses:
-                   +OK
-               Examples:
-                   C:    NOOP
-                   S:    +OK
-
-           LAST
-               Arguments: none
-               Restrictions: may only be issued in the TRANSACTION state.
-               Discussion:
-
-                 The POP3 server issues a positive response with a line
-                 containing the highest message number which accessed.
-                 Zero is returned in case no message in the maildrop has
-                 been accessed during previous transactions.  A client
-                 may thereafter infer that messages, if any, numbered
-                 greater than the response to the LAST command are
-                 messages not yet accessed by the client.
-
-             Possible Response:
-                   +OK nn
-
-             Examples:
-                   C:      STAT
-                   S:      +OK 4 320
-                   C:      LAST
-                   S:      +OK 1
-                   C:      RETR 3
-                   S:      +OK 120 octets
-                   S:      <the POP3 server sends the entire message
-                           here>
-                   S:      .
-                   C:      LAST
-                   S:      +OK 3
-                   C:      DELE 2
-                   S:      +OK message 2 deleted
-                   C:      LAST
-                   S:      +OK 3
-                   C:      RSET
-                   S:      +OK
-                   C:      LAST
-                   S:      +OK 0
-
-
-
-
-Rose                                                            [Page 9]
-
-RFC 1460                          POP3                         June 1993
-
-
-           RSET
-               Arguments: none
-               Restrictions: may only be given in the TRANSACTION
-                   state.
-               Discussion:
-
-                 If any messages have been marked as deleted by the POP3
-                 server, they are unmarked.  The POP3 server then
-                 replies with a positive response.  In addition, the
-                 "highest number accessed" is also reset to zero.
-
-               Possible Responses:
-                   +OK
-               Examples:
-                   C:    RSET
-                   S:    +OK maildrop has 2 messages (320 octets)
-
-6. The UPDATE State
-
-   When the client issues the QUIT command from the TRANSACTION state,
-   the POP3 session enters the UPDATE state.  (Note that if the client
-   issues the QUIT command from the AUTHORIZATION state, the POP3
-   session terminates but does NOT enter the UPDATE state.)
-
-           QUIT
-               Arguments: none
-               Restrictions: none
-               Discussion:
-
-                 The POP3 server removes all messages marked as deleted
-                 from the maildrop.  It then releases the
-                 exclusive-access lock on the maildrop and replies as
-                 to the success of these operations.  The TCP
-                 connection is then closed.
-
-               Possible Responses:
-                   +OK
-               Examples:
-                   C:    QUIT
-                   S:    +OK dewey POP3 server signing off (maildrop
-                         empty)
-                     ...
-                   C:    QUIT
-                   S:    +OK dewey POP3 server signing off (2 messages
-                         left)
-                     ...
-
-
-
-
-
-Rose                                                           [Page 10]
-
-RFC 1460                          POP3                         June 1993
-
-
-7. Optional POP3 Commands
-
-   The POP3 commands discussed above must be supported by all minimal
-   implementations of POP3 servers.
-
-   The optional POP3 commands described below permit a POP3 client
-   greater freedom in message handling, while preserving a simple POP3
-   server implementation.
-
-                 NOTE: This memo STRONGLY encourages implementations to
-                 support these commands in lieu of developing augmented
-                 drop and scan listings.  In short, the philosophy of
-                 this memo is to put intelligence in the part of the
-                 POP3 client and not the POP3 server.
-
-           TOP msg n
-               Arguments: a message-id (required) and a number.  This
-                   message-id may NOT refer to a message marked as
-                   deleted.
-               Restrictions: may only be given in the TRANSACTION state.
-               Discussion:
-
-                 If the POP3 server issues a positive response, then
-                 the response given is multi-line.  After the initial
-                 +OK, the POP3 server sends the headers of the message,
-                 the blank line separating the headers from the body,
-                 and then the number of lines indicated message's body,
-                 being careful to byte-stuff the termination character
-                 (as with all multi-line responses).
-
-                 Note that if the number of lines requested by the POP3
-                 client is greater than than the number of lines in the
-                 body, then the POP3 server sends the entire message.
-
-               Possible Responses:
-                   +OK top of message follows
-                   -ERR no such message
-               Examples:
-                   C:    TOP 10
-                   S:    +OK
-                   S:    <the POP3 server sends the headers of the
-                          message, a blank line, and the first 10 lines
-                          of the body of the message>
-                   S:    .
-                     ...
-                   C:    TOP 100
-                   S:    -ERR no such message
-
-
-
-
-Rose                                                           [Page 11]
-
-RFC 1460                          POP3                         June 1993
-
-
-           APOP name digest
-               Arguments: a server specific user-id and a digest string
-                    (both required).
-               Restrictions: may only be given in the AUTHORIZATION
-                   state after the POP3 greeting
-               Discussion:
-
-                 Normally, each POP3 session starts with a USER/PASS
-                 exchange.  This results in a server/user-id specific
-                 password being sent in the clear on the network.  For
-                 intermittent use of POP3, this may not introduce a
-                 sizable risk.  However, many POP3 client
-                 implementations connect to the POP3 server on a
-                 regular basis -- to check for new mail.  Further the
-                 interval of session initiation may be on the order of
-                 five minutes.  Hence, the risk of password capture is
-                 greatly enhanced.
-
-                 An alternate method of authentication is required
-                 which provides for both origin authentication and
-                 replay protection, but which does not involve sending
-                 a password in the clear over the network.  The APOP
-                 command provides this functionality.
-
-                 A POP3 server which implements the APOP command will
-                 include a timestamp in its banner greeting.  The
-                 syntax of the timestamp corresponds to the "msg-id"
-                 in [RFC822], and MUST be different each time the POP3
-                 server issues a banner greeting.  For example, on a
-                 UNIX implementation in which a separate UNIX process
-                 is used for each instance of a POP3 server, the
-                 syntax of the timestamp might be:
-
-                    <process-ID.clock@hostname>
-
-                 where "process-ID" is the decimal value of the
-                 process's PID, clock is the decimal value of the
-                 system clock, and hostname is the fully-qualified
-                 domain-name corresponding to the host where the POP3
-                 server is running.
-
-                 The POP3 client makes note of this timestamp, and
-                 then issues the APOP command.  The "name" parameter
-                 has identical semantics to the "name" parameter of
-                 the USER command. The "digest" parameter is
-                 calculated by applying the MD5 algorithm [RFC1321] to
-                 a string consisting of the timestamp (including
-                 angle-brackets) followed by a shared secret.  This
-
-
-
-Rose                                                           [Page 12]
-
-RFC 1460                          POP3                         June 1993
-
-
-                 shared secret is a string known only to the POP3
-                 client and server. Great care should be taken to
-                 prevent unauthorized disclosure of the secret, as
-                 knowledge of the secret will allow any entity to
-                 successfully masquerade as the named user.  The
-                 "digest" parameter itself is a 16-octet value which
-                 is sent in hexadecimal format, using lower-case ASCII
-                 characters.
-
-                 When the POP3 server receives the APOP command, it
-                 verifies the digest provided.  If the digest is
-                 correct, the POP3 server issues a positive response,
-                 and the POP3 session enters the TRANSACTION state.
-                 Otherwise, a negative response is issued and the POP3
-                 session remains in the AUTHORIZATION state.
-
-               Possible Responses:
-                   +OK maildrop locked and ready
-                   -ERR permission denied
-               Examples:
-                   S: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us>
-                   C: APOP mrose c4c9334bac560ecc979e58001b3e22fb
-                   S: +OK maildrop has 1 message (369 octets)
-
-                 In this example, the shared secret is the string "tanstaaf".
-                 Hence, the MD5 algorithm is applied to the string
-
-                    <1896.697170952@dbc.mtview.ca.us>tanstaaf
-
-                 which produces a digest value of
-
-                    c4c9334bac560ecc979e58001b3e22fb
-
-8. POP3 Command Summary
-
-       Minimal POP3 Commands:
-           USER name               valid in the AUTHORIZATION state
-           PASS string
-           QUIT
-
-           STAT                    valid in the TRANSACTION state
-           LIST [msg]
-           RETR msg
-           DELE msg
-           NOOP
-           LAST
-           RSET
-
-
-
-
-Rose                                                           [Page 13]
-
-RFC 1460                          POP3                         June 1993
-
-
-           QUIT                    valid in the UPDATE state
-
-       Optional POP3 Commands:
-           APOP name digest        valid in the AUTHORIZATION state
-
-           TOP msg n               valid in the TRANSACTION state
-
-       POP3 Replies:
-           +OK
-           -ERR
-
-       Note that with the exception of the STAT command, the reply given
-       by the POP3 server to any command is significant only to "+OK"
-       and "-ERR".  Any text occurring after this reply may be ignored
-       by the client.
-
-9. Example POP3 Session
-
-    S: <wait for connection on TCP port 110>
-        ...
-    C: <open connection>
-    S:    +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us>
-    C:    APOP mrose c4c9334bac560ecc979e58001b3e22fb
-    S:    +OK mrose's maildrop has 2 messages (320 octets)
-    C:    STAT
-    S:    +OK 2 320
-    C:    LIST
-    S:    +OK 2 messages (320 octets)
-    S:    1 120
-    S:    2 200
-    S:    .
-    C:    RETR 1
-    S:    +OK 120 octets
-    S:    <the POP3 server sends message 1>
-    S:    .
-    C:    DELE 1
-    S:    +OK message 1 deleted
-    C:    RETR 2
-    S:    +OK 200 octets
-    S:    <the POP3 server sends message 2>
-    S:    .
-    C:    DELE 2
-    S:    +OK message 2 deleted
-    C:    QUIT
-    S:    +OK dewey POP3 server signing off (maildrop empty)
-    C:  <close connection>
-    S:  <wait for next connection>
-
-
-
-
-Rose                                                           [Page 14]
-
-RFC 1460                          POP3                         June 1993
-
-
-10. Message Format
-
-   All messages transmitted during a POP3 session are assumed to conform
-   to the standard for the format of Internet text messages [RFC822].
-
-   It is important to note that the byte count for a message on the
-   server host may differ from the octet count assigned to that message
-   due to local conventions for designating end-of-line.  Usually,
-   during the AUTHORIZATION state of the POP3 session, the POP3 client
-   can calculate the size of each message in octets when it parses the
-   maildrop into messages.  For example, if the POP3 server host
-   internally represents end-of-line as a single character, then the
-   POP3 server simply counts each occurrence of this character in a
-   message as two octets.  Note that lines in the message which start
-   with the termination octet need not be counted twice, since the POP3
-   client will remove all byte-stuffed termination characters when it
-   receives a multi-line response.
-
-11. The POP and the Split-UA model
-
-   The underlying paradigm in which the POP3 functions is that of a
-   split-UA model.  The POP3 client host, being a remote PC based
-   workstation, acts solely as a client to the message transport system.
-   It does not provide delivery/authentication services to others.
-   Hence, it is acting as a UA, on behalf of the person using the
-   workstation.  Furthermore, the workstation uses SMTP to enter mail
-   into the MTS.
-
-   In this sense, we have two UA functions which interface to the
-   message transport system: Posting (SMTP) and Retrieval (POP3).  The
-   entity which supports this type of environment is called a split-UA
-   (since the user agent is split between two hosts which must
-   interoperate to provide these functions).
-
-                 ASIDE:  Others might term this a remote-UA instead.
-                 There are arguments supporting the use of both terms.
-
-   This memo has explicitly referenced TCP as the underlying transport
-   agent for the POP3.  This need not be the case.  In the MZnet split-
-   UA, for example, personal micro-computer systems are used which do
-   not have IP-style networking capability [MZnet].  To connect to the
-   POP3 server host, a PC establishes a terminal connection using some
-   simple protocol (PhoneNet).  A program on the PC drives the
-   connection, first establishing a login session as a normal user.  The
-   login shell for this pseudo-user is a program which drives the other
-   half of the terminal protocol and communicates with one of two
-   servers.  Although MZnet can support several PCs, a single pseudo-
-   user login is present on the server host.  The user-id and password
-
-
-
-Rose                                                           [Page 15]
-
-RFC 1460                          POP3                         June 1993
-
-
-   for this pseudo-user login is known to all members of MZnet.  Hence,
-   the first action of the login shell, after starting the terminal
-   protocol, is to demand a USER/PASS authorization pair from the PC.
-   This second level of authorization is used to ascertain who is
-   interacting with the MTS.  Although the server host is deemed to
-   support a "trusted" MTS entity, PCs in MZnet are not.  Naturally, the
-   USER/PASS authorization pair for a PC is known only to the owner of
-   the PC (in theory, at least).
-
-   After successfully verifying the identity of the client, a modified
-   SMTP server is started, and the PC posts mail with the server host.
-   After the QUIT command is given to the SMTP server and it terminates,
-   a modified POP3 server is started, and the PC retrieves mail from the
-   server host.  After the QUIT command is given to the POP3 server and
-   it terminates, the login shell for the pseudo-user terminates the
-   terminal protocol and logs the job out.  The PC then closes the
-   terminal connection to the server host.
-
-   The SMTP server used by MZnet is modified in the sense that it knows
-   that it's talking to a user agent and not a "trusted" entity in the
-   message transport system.  Hence, it does performs the validation
-   activities normally performed by an entity in the MTS when it accepts
-   a message from a UA.
-
-   The POP3 server used by MZnet is modified in the sense that it does
-   not require a USER/PASS combination before entering the TRANSACTION
-   state.  The reason for this (of course) is that the PC has already
-   identified itself during the second-level authorization step
-   described above.
-
-                 NOTE: Truth in advertising laws require that the author
-                 of this memo state that MZnet has not actually been
-                 fully implemented.  The concepts presented and proven
-                 by the project led to the notion of the MZnet
-                 split-slot model.  This notion has inspired the
-                 split-UA concept described in this memo, led to the
-                 author's interest in the POP, and heavily influenced
-                 the the description of the POP3 herein.
-
-   In fact, some UAs present in the Internet already support the notion
-   of posting directly to an SMTP server and retrieving mail directly
-   from a POP3 server, even if the POP3 server and client resided on the
-   same host!
-
-                 ASIDE: this discussion raises an issue which this memo
-                 purposedly avoids: how does SMTP know that it's talking
-                 to a "trusted" MTS entity?
-
-
-
-
-Rose                                                           [Page 16]
-
-RFC 1460                          POP3                         June 1993
-
-
-12. References
-
-   [MZnet]   Stefferud, E., Sweet, J., and T. Domae, "MZnet: Mail
-             Service for Personal Micro-Computer Systems,:
-             Proceedings, IFIP 6.5 International Conference on
-             Computer Message Systems, Nottingham, U.K., May 1984.
-
-   [RFC821]  Postel, J., "Simple Mail Transfer Protocol", STD 10,
-             RFC 821, USC/Information Sciences Institute, August 1982.
-
-   [RFC822]  Crocker, D., "Standard for the Format of ARPA-Internet
-             Text Messages", STD 11, RFC 822, University of Delaware,
-             August 1982.
-
-   [RFC1321] Rivest, R. "The MD5 Message-Digest Algorithm", MIT
-             Laboratory for Computer Science, April 1992.
-
-13. Security Considerations
-
-   It is conjectured that use of the APOP command provides origin
-   identification and replay protection for a POP3 session.
-   Accordingly, a POP3 server which implements both the PASS and APOP
-   commands must not allow both methods of access for a given user; that
-   is, for a given "USER name" either the PASS or APOP command is
-   allowed, but not both.
-
-   Otherwise, security issues are not discussed in this memo.
-
-14. Acknowledgements
-
-   The POP family has a long and checkered history.  Although primarily
-   a minor revision to [RFC1225], POP3 is based on the ideas presented
-   in RFCs 918, 937, and 1081.
-
-   In addition, Alfred Grimstad, Keith McCloghrie, and Neil Ostroff
-   provided significant comments on the APOP command.
-
-15. Author's Address
-
-   Marshall T. Rose
-   Dover Beach Consulting, Inc.
-   Mountain View, CA  94043-2186
-
-   Phone: +1 415 968 1052
-   Fax:   +1 415 968 2510
-
-   EMail: mrose@dbc.mtview.ca.us
-   X.500: rose, dbc, us
-
-
-
-Rose                                                           [Page 17]
-
-\ No newline at end of file
diff --git a/RFC/rfc1521.txt b/RFC/rfc1521.txt
deleted file mode 100644
index cb4ee75a..00000000
--- a/RFC/rfc1521.txt
+++ /dev/null
@@ -1,4539 +0,0 @@
-
-
-
-
-
-
-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/RFC/rfc1725.txt b/RFC/rfc1725.txt
deleted file mode 100644
index 43fcc518..00000000
--- a/RFC/rfc1725.txt
+++ /dev/null
@@ -1,1011 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                           J. Myers
-Request for Comments: 1725                               Carnegie Mellon
-Obsoletes: 1460                                                  M. Rose
-Category: Standards Track                   Dover Beach Consulting, Inc.
-                                                           November 1994
-
-
-                    Post Office Protocol - Version 3
-
-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.
-
-Overview
-
-   This memo is a revision to RFC 1460, a Draft Standard.  It makes the
-   following changes from that document:
-
-      - removed text regarding "split-UA model", which didn't add
-        anything to the understanding of POP
-
-      - clarified syntax of commands, keywords, and arguments
-
-      - clarified behavior on broken connection
-
-      - explicitly permitted an inactivity autologout timer
-
-      - clarified the requirements of the "exclusive-access lock"
-
-      - removed implementation-specific wording regarding the parsing of
-        the maildrop
-
-      - allowed servers to close the connection after a failed
-        authentication command
-
-      - removed the LAST command
-
-      - fixed typo in example of TOP command
-
-      - clarified that the second argument to the TOP command is non-
-        negative
-
-      - added the optional UIDL command
-
-
-
-
-Myers & Rose                                                    [Page 1]
-
-RFC 1725                          POP3                     November 1994
-
-
-      - added warning regarding length of shared secrets with APOP
-
-      - added additional warnings to the security considerations section
-
-1. Introduction
-
-   On certain types of smaller nodes in the Internet it is often
-   impractical to maintain a message transport system (MTS).  For
-   example, a workstation may not have sufficient resources (cycles,
-   disk space) in order to permit a SMTP server [RFC821] and associated
-   local mail delivery system to be kept resident and continuously
-   running.  Similarly, it may be expensive (or impossible) to keep a
-   personal computer interconnected to an IP-style network for long
-   amounts of time (the node is lacking the resource known as
-   "connectivity").
-
-   Despite this, it is often very useful to be able to manage mail on
-   these smaller nodes, and they often support a user agent (UA) to aid
-   the tasks of mail handling.  To solve this problem, a node which can
-   support an MTS entity offers a maildrop service to these less endowed
-   nodes.  The Post Office Protocol - Version 3 (POP3) is intended to
-   permit a workstation to dynamically access a maildrop on a server
-   host in a useful fashion.  Usually, this means that the POP3 is used
-   to allow a workstation to retrieve mail that the server is holding
-   for it.
-
-   For the remainder of this memo, the term "client host" refers to a
-   host making use of the POP3 service, while the term "server host"
-   refers to a host which offers the POP3 service.
-
-2. A Short Digression
-
-   This memo does not specify how a client host enters mail into the
-   transport system, although a method consistent with the philosophy of
-   this memo is presented here:
-
-      When the user agent on a client host wishes to enter a message
-      into the transport system, it establishes an SMTP connection to
-      its relay host (this relay host could be, but need not be, the
-      POP3 server host for the client host).
-
-3. Basic Operation
-
-   Initially, the server host starts the POP3 service by listening on
-   TCP port 110.  When a client host wishes to make use of the service,
-   it establishes a TCP connection with the server host.  When the
-   connection is established, the POP3 server sends a greeting.  The
-   client and POP3 server then exchange commands and responses
-
-
-
-Myers & Rose                                                    [Page 2]
-
-RFC 1725                          POP3                     November 1994
-
-
-   (respectively) until the connection is closed or aborted.
-
-   Commands in the POP3 consist of a keyword, possibly followed by one
-   or more arguments.  All commands are terminated by a CRLF pair.
-   Keywords and arguments consist of printable ASCII characters.
-   Keywords and arguments are each separated by a single SPACE
-   character.  Keywords are three or four characters long. Each argument
-   may be up to 40 characters long.
-
-   Responses in the POP3 consist of a status indicator and a keyword
-   possibly followed by additional information.  All responses are
-   terminated by a CRLF pair.  There are currently two status
-   indicators: positive ("+OK") and negative ("-ERR").
-
-   Responses to certain commands are multi-line.  In these cases, which
-   are clearly indicated below, after sending the first line of the
-   response and a CRLF, any additional lines are sent, each terminated
-   by a CRLF pair.  When all lines of the response have been sent, a
-   final line is sent, consisting of a termination octet (decimal code
-   046, ".") and a CRLF pair.  If any line of the multi-line response
-   begins with the termination octet, the line is "byte-stuffed" by
-   pre-pending the termination octet to that line of the response.
-   Hence a multi-line response is terminated with the five octets
-   "CRLF.CRLF".  When examining a multi-line response, the client checks
-   to see if the line begins with the termination octet.  If so and if
-   octets other than CRLF follow, the the first octet of the line (the
-   termination octet) is stripped away.  If so and if CRLF immediately
-   follows the termination character, then the response from the POP
-   server is ended and the line containing ".CRLF" is not considered
-   part of the multi-line response.
-
-   A POP3 session progresses through a number of states during its
-   lifetime.  Once the TCP connection has been opened and the POP3
-   server has sent the greeting, the session enters the AUTHORIZATION
-   state.  In this state, the client must identify itself to the POP3
-   server.  Once the client has successfully done this, the server
-   acquires resources associated with the client's maildrop, and the
-   session enters the TRANSACTION state.  In this state, the client
-   requests actions on the part of the POP3 server.  When the client has
-   issued the QUIT command, the session enters the UPDATE state.  In
-   this state, the POP3 server releases any resources acquired during
-   the TRANSACTION state and says goodbye.  The TCP connection is then
-   closed.
-
-   A POP3 server MAY have an inactivity autologout timer.  Such a timer
-   MUST be of at least 10 minutes' duration.  The receipt of any command
-   from the client during that interval should suffice to reset the
-   autologout timer.  When the timer expires, the session does NOT enter
-
-
-
-Myers & Rose                                                    [Page 3]
-
-RFC 1725                          POP3                     November 1994
-
-
-   the UPDATE state--the server should close the TCP connection without
-   removing any messages or sending any response to the client.
-
-4. The AUTHORIZATION State
-
-   Once the TCP connection has been opened by a POP3 client, the POP3
-   server issues a one line greeting.  This can be any string terminated
-   by CRLF.  An example might be:
-
-      S:  +OK POP3 server ready
-
-   Note that this greeting is a POP3 reply.  The POP3 server should
-   always give a positive response as the greeting.
-
-   The POP3 session is now in the AUTHORIZATION state.  The client must
-   now identify and authenticate itself to the POP3 server.  Two
-   possible mechanisms for doing this are described in this document,
-   the USER and PASS command combination and the APOP command.  The APOP
-   command is described later in this document.
-
-   To authenticate using the USER and PASS command combination, the
-   client must first issue the USER command.  If the POP3 server
-   responds with a positive status indicator ("+OK"), then the client
-   may issue either the PASS command to complete the authentication, or
-   the QUIT command to terminate the POP3 session.  If the POP3 server
-   responds with a negative status indicator ("-ERR") to the USER
-   command, then the client may either issue a new authentication
-   command or may issue the QUIT command.
-
-   When the client issues the PASS command, the POP3 server uses the
-   argument pair from the USER and PASS commands to determine if the
-   client should be given access to the appropriate maildrop.
-
-   Once the POP3 server has determined through the use of any
-   authentication command that the client should be given access to the
-   appropriate maildrop, the POP3 server then acquires an exclusive-
-   access lock on the maildrop, as necessary to prevent messages from
-   being modified or removed before the session enters the UPDATE state.
-   If the lock is successfully acquired, the POP3 server responds with a
-   positive status indicator.  The POP3 session now enters the
-   TRANSACTION state, with no messages marked as deleted.  If the the
-   maildrop cannot be opened for some reason (for example, a lock can
-   not be acquired, the client is denied access to the appropriate
-   maildrop, or the maildrop cannot be parsed), the POP3 server responds
-   with a negative status indicator.  (If a lock was acquired but the
-   POP3 server intends to respond with a negative status indicator, the
-   POP3 server must release the lock prior to rejecting the command.)
-   After returning a negative status indicator, the server may close the
-
-
-
-Myers & Rose                                                    [Page 4]
-
-RFC 1725                          POP3                     November 1994
-
-
-   connection.  If the server does not close the connection, the client
-   may either issue a new authentication command and start again, or the
-   client may issue the QUIT command.
-
-   After the POP3 server has opened the maildrop, it assigns a message-
-   number to each message, and notes the size of each message in octets.
-   The first message in the maildrop is assigned a message-number of
-   "1", the second is assigned "2", and so on, so that the n'th message
-   in a maildrop is assigned a message-number of "n".  In POP3 commands
-   and responses, all message-number's and message sizes are expressed
-   in base-10 (i.e., decimal).
-
-   Here are summaries for the three POP3 commands discussed thus far:
-
-      USER name
-
-         Arguments:
-             a string identifying a mailbox (required), which is of
-             significance ONLY to the server
-
-         Restrictions:
-             may only be given in the AUTHORIZATION state after the POP3
-             greeting or after an unsuccessful USER or PASS command
-
-         Possible Responses:
-             +OK name is a valid mailbox
-             -ERR never heard of mailbox name
-
-         Examples:
-             C: USER mrose
-             S: +OK mrose is a real hoopy frood
-                ...
-             C: USER frated
-             S: -ERR sorry, no mailbox for frated here
-
-      PASS string
-
-         Arguments:
-             a server/mailbox-specific password (required)
-
-         Restrictions:
-             may only be given in the AUTHORIZATION state after a
-             successful USER command
-
-         Discussion:
-             Since the PASS command has exactly one argument, a POP3
-             server may treat spaces in the argument as part of the
-             password, instead of as argument separators.
-
-
-
-Myers & Rose                                                    [Page 5]
-
-RFC 1725                          POP3                     November 1994
-
-
-         Possible Responses:
-             +OK maildrop locked and ready
-             -ERR invalid password
-             -ERR unable to lock maildrop
-
-         Examples:
-             C: USER mrose
-             S: +OK mrose is a real hoopy frood
-             C: PASS secret
-             S: +OK mrose's maildrop has 2 messages (320 octets)
-               ...
-             C: USER mrose
-             S: +OK mrose is a real hoopy frood
-             C: PASS secret
-             S: -ERR maildrop already locked
-
-      QUIT
-
-         Arguments: none
-
-         Restrictions: none
-
-         Possible Responses:
-             +OK
-
-         Examples:
-             C: QUIT
-             S: +OK dewey POP3 server signing off
-
-5. The TRANSACTION State
-
-   Once the client has successfully identified itself to the POP3 server
-   and the POP3 server has locked and opened the appropriate maildrop,
-   the POP3 session is now in the TRANSACTION state.  The client may now
-   issue any of the following POP3 commands repeatedly.  After each
-   command, the POP3 server issues a response.  Eventually, the client
-   issues the QUIT command and the POP3 session enters the UPDATE state.
-
-   Here are the POP3 commands valid in the TRANSACTION state:
-
-      STAT
-
-         Arguments: none
-
-         Restrictions:
-             may only be given in the TRANSACTION state
-
-
-
-
-
-Myers & Rose                                                    [Page 6]
-
-RFC 1725                          POP3                     November 1994
-
-
-         Discussion:
-             The POP3 server issues a positive response with a line
-             containing information for the maildrop.  This line is
-             called a "drop listing" for that maildrop.
-
-             In order to simplify parsing, all POP3 servers required to
-             use a certain format for drop listings.  The positive
-             response consists of "+OK" followed by a single space, the
-             number of messages in the maildrop, a single space, and the
-             size of the maildrop in octets.  This memo makes no
-             requirement on what follows the maildrop size.  Minimal
-             implementations should just end that line of the response
-             with a CRLF pair.  More advanced implementations may
-             include other information.
-
-                NOTE: This memo STRONGLY discourages implementations
-                from supplying additional information in the drop
-                listing.  Other, optional, facilities are discussed
-                later on which permit the client to parse the messages
-                in the maildrop.
-
-             Note that messages marked as deleted are not counted in
-             either total.
-
-         Possible Responses:
-             +OK nn mm
-
-         Examples:
-             C: STAT
-             S: +OK 2 320
-
-      LIST [msg]
-
-         Arguments:
-             a message-number (optional), which, if present, may NOT
-             refer to a message marked as deleted
-
-         Restrictions:
-             may only be given in the TRANSACTION state
-
-         Discussion:
-             If an argument was given and the POP3 server issues a
-             positive response with a line containing information for
-             that message.  This line is called a "scan listing" for
-             that message.
-
-             If no argument was given and the POP3 server issues a
-             positive response, then the response given is multi-line.
-
-
-
-Myers & Rose                                                    [Page 7]
-
-RFC 1725                          POP3                     November 1994
-
-
-             After the initial +OK, for each message in the maildrop,
-             the POP3 server responds with a line containing information
-             for that message.  This line is also called a "scan
-             listing" for that message.
-
-             In order to simplify parsing, all POP3 servers are required
-             to use a certain format for scan listings.  A scan listing
-             consists of the message-number of the message, followed by
-             a single space and the exact size of the message in octets.
-             This memo makes no requirement on what follows the message
-             size in the scan listing.  Minimal implementations should
-             just end that line of the response with a CRLF pair.  More
-             advanced implementations may include other information, as
-             parsed from the message.
-
-                NOTE: This memo STRONGLY discourages implementations
-                from supplying additional information in the scan
-                listing.  Other, optional, facilities are discussed
-                later on which permit the client to parse the messages
-                in the maildrop.
-
-             Note that messages marked as deleted are not listed.
-
-         Possible Responses:
-             +OK scan listing follows
-             -ERR no such message
-
-         Examples:
-             C: LIST
-             S: +OK 2 messages (320 octets)
-             S: 1 120
-             S: 2 200
-             S: .
-               ...
-             C: LIST 2
-             S: +OK 2 200
-               ...
-             C: LIST 3
-             S: -ERR no such message, only 2 messages in maildrop
-
-      RETR msg
-
-         Arguments:
-             a message-number (required) which may not refer to a
-             message marked as deleted
-
-         Restrictions:
-             may only be given in the TRANSACTION state
-
-
-
-Myers & Rose                                                    [Page 8]
-
-RFC 1725                          POP3                     November 1994
-
-
-         Discussion:
-             If the POP3 server issues a positive response, then the
-             response given is multi-line.  After the initial +OK, the
-             POP3 server sends the message corresponding to the given
-             message-number, being careful to byte-stuff the termination
-             character (as with all multi-line responses).
-
-         Possible Responses:
-             +OK message follows
-             -ERR no such message
-
-         Examples:
-             C: RETR 1
-             S: +OK 120 octets
-             S: <the POP3 server sends the entire message here>
-             S: .
-
-      DELE msg
-
-         Arguments:
-             a message-number (required) which may not refer to a
-             message marked as deleted
-
-         Restrictions:
-             may only be given in the TRANSACTION state
-
-         Discussion:
-             The POP3 server marks the message as deleted.  Any future
-             reference to the message-number associated with the message
-             in a POP3 command generates an error.  The POP3 server does
-             not actually delete the message until the POP3 session
-             enters the UPDATE state.
-
-         Possible Responses:
-             +OK message deleted
-             -ERR no such message
-
-         Examples:
-             C: DELE 1
-             S: +OK message 1 deleted
-                ...
-             C: DELE 2
-             S: -ERR message 2 already deleted
-
-      NOOP
-
-         Arguments: none
-
-
-
-
-Myers & Rose                                                    [Page 9]
-
-RFC 1725                          POP3                     November 1994
-
-
-         Restrictions:
-             may only be given in the TRANSACTION state
-
-         Discussion:
-             The POP3 server does nothing, it merely replies with a
-             positive response.
-
-         Possible Responses:
-             +OK
-
-         Examples:
-             C: NOOP
-             S: +OK
-
-      RSET
-
-         Arguments: none
-
-         Restrictions:
-             may only be given in the TRANSACTION state
-
-         Discussion:
-             If any messages have been marked as deleted by the POP3
-             server, they are unmarked.  The POP3 server then replies
-             with a positive response.
-
-         Possible Responses:
-             +OK
-
-         Examples:
-             C: RSET
-             S: +OK maildrop has 2 messages (320 octets)
-
-6. The UPDATE State
-
-   When the client issues the QUIT command from the TRANSACTION state,
-   the POP3 session enters the UPDATE state.  (Note that if the client
-   issues the QUIT command from the AUTHORIZATION state, the POP3
-   session terminates but does NOT enter the UPDATE state.)
-
-   If a session terminates for some reason other than a client-issued
-   QUIT command, the POP3 session does NOT enter the UPDATE state and
-   MUST not remove any messages from the maildrop.
-
-      QUIT
-
-         Arguments: none
-
-
-
-
-Myers & Rose                                                   [Page 10]
-
-RFC 1725                          POP3                     November 1994
-
-
-         Restrictions: none
-
-         Discussion:
-             The POP3 server removes all messages marked as deleted from
-             the maildrop.  It then releases any exclusive-access lock
-             on the maildrop and replies as to the status of these
-             operations.  The TCP connection is then closed.
-
-         Possible Responses:
-             +OK
-
-         Examples:
-             C: QUIT
-             S: +OK dewey POP3 server signing off (maildrop empty)
-                ...
-             C: QUIT
-             S: +OK dewey POP3 server signing off (2 messages left)
-                ...
-
-7. Optional POP3 Commands
-
-   The POP3 commands discussed above must be supported by all minimal
-   implementations of POP3 servers.
-
-   The optional POP3 commands described below permit a POP3 client
-   greater freedom in message handling, while preserving a simple POP3
-   server implementation.
-
-      NOTE: This memo STRONGLY encourages implementations to support
-      these commands in lieu of developing augmented drop and scan
-      listings.  In short, the philosophy of this memo is to put
-      intelligence in the part of the POP3 client and not the POP3
-      server.
-
-      TOP msg n
-
-         Arguments:
-             a message-number (required) which may NOT refer to to a
-             message marked as deleted, and a non-negative number
-             (required)
-
-         Restrictions:
-             may only be given in the TRANSACTION state
-
-         Discussion:
-             If the POP3 server issues a positive response, then the
-             response given is multi-line.  After the initial +OK, the
-             POP3 server sends the headers of the message, the blank
-
-
-
-Myers & Rose                                                   [Page 11]
-
-RFC 1725                          POP3                     November 1994
-
-
-             line separating the headers from the body, and then the
-             number of lines indicated message's body, being careful to
-             byte-stuff the termination character (as with all multi-
-             line responses).
-
-             Note that if the number of lines requested by the POP3
-             client is greater than than the number of lines in the
-             body, then the POP3 server sends the entire message.
-
-         Possible Responses:
-             +OK top of message follows
-             -ERR no such message
-
-         Examples:
-             C: TOP 1 10
-             S: +OK
-             S: <the POP3 server sends the headers of the
-                message, a blank line, and the first 10 lines
-                of the body of the message>
-             S: .
-                ...
-             C: TOP 100 3
-             S: -ERR no such message
-
-      UIDL [msg]
-
-      Arguments:
-          a message-number (optionally)  If a message-number is given,
-          it may NOT refer to a message marked as deleted.
-
-      Restrictions:
-          may only be given in the TRANSACTION state.
-
-      Discussion:
-          If an argument was given and the POP3 server issues a positive
-          response with a line containing information for that message.
-          This line is called a "unique-id listing" for that message.
-
-          If no argument was given and the POP3 server issues a positive
-          response, then the response given is multi-line.  After the
-          initial +OK, for each message in the maildrop, the POP3 server
-          responds with a line containing information for that message.
-          This line is called a "unique-id listing" for that message.
-
-          In order to simplify parsing, all POP3 servers are required to
-          use a certain format for unique-id listings.  A unique-id
-          listing consists of the message-number of the message,
-          followed by a single space and the unique-id of the message.
-
-
-
-Myers & Rose                                                   [Page 12]
-
-RFC 1725                          POP3                     November 1994
-
-
-          No information follows the unique-id in the unique-id listing.
-
-          The unique-id of a message is an arbitrary server-determined
-          string, consisting of characters in the range 0x21 to 0x7E,
-          which uniquely identifies a message within a maildrop and
-          which persists across sessions. The server should never reuse
-          an unique-id in a given maildrop, for as long as the entity
-          using the unique-id exists.
-
-          Note that messages marked as deleted are not listed.
-
-      Possible Responses:
-          +OK unique-id listing follows
-          -ERR no such message
-
-      Examples:
-          C: UIDL
-          S: +OK
-          S: 1 whqtswO00WBw418f9t5JxYwZ
-          S: 2 QhdPYR:00WBw1Ph7x7
-          S: .
-             ...
-          C: UIDL 2
-          S: +OK 2 QhdPYR:00WBw1Ph7x7
-             ...
-          C: UIDL 3
-          S: -ERR no such message, only 2 messages in maildrop
-
-      APOP name digest
-
-         Arguments:
-             a string identifying a mailbox and a MD5 digest string
-             (both required)
-
-         Restrictions:
-             may only be given in the AUTHORIZATION state after the POP3
-             greeting
-
-         Discussion:
-             Normally, each POP3 session starts with a USER/PASS
-             exchange.  This results in a server/user-id specific
-             password being sent in the clear on the network.  For
-             intermittent use of POP3, this may not introduce a sizable
-             risk.  However, many POP3 client implementations connect to
-             the POP3 server on a regular basis -- to check for new
-             mail.  Further the interval of session initiation may be on
-             the order of five minutes.  Hence, the risk of password
-             capture is greatly enhanced.
-
-
-
-Myers & Rose                                                   [Page 13]
-
-RFC 1725                          POP3                     November 1994
-
-
-             An alternate method of authentication is required which
-             provides for both origin authentication and replay
-             protection, but which does not involve sending a password
-             in the clear over the network.  The APOP command provides
-             this functionality.
-
-             A POP3 server which implements the APOP command will
-             include a timestamp in its banner greeting.  The syntax of
-             the timestamp corresponds to the `msg-id' in [RFC822], and
-             MUST be different each time the POP3 server issues a banner
-             greeting.  For example, on a UNIX implementation in which a
-             separate UNIX process is used for each instance of a POP3
-             server, the syntax of the timestamp might be:
-
-                <process-ID.clock@hostname>
-
-             where `process-ID' is the decimal value of the process's
-             PID, clock is the decimal value of the system clock, and
-             hostname is the fully-qualified domain-name corresponding
-             to the host where the POP3 server is running.
-
-             The POP3 client makes note of this timestamp, and then
-             issues the APOP command.  The `name' parameter has
-             identical semantics to the `name' parameter of the USER
-             command. The `digest' parameter is calculated by applying
-             the MD5 algorithm [RFC1321] to a string consisting of the
-             timestamp (including angle-brackets) followed by a shared
-             secret.  This shared secret is a string known only to the
-             POP3 client and server.  Great care should be taken to
-             prevent unauthorized disclosure of the secret, as knowledge
-             of the secret will allow any entity to successfully
-             masquerade as the named user.  The `digest' parameter
-             itself is a 16-octet value which is sent in hexadecimal
-             format, using lower-case ASCII characters.
-
-             When the POP3 server receives the APOP command, it verifies
-             the digest provided.  If the digest is correct, the POP3
-             server issues a positive response, and the POP3 session
-             enters the TRANSACTION state.  Otherwise, a negative
-             response is issued and the POP3 session remains in the
-             AUTHORIZATION state.
-
-             Note that as the length of the shared secret increases, so
-             does the difficulty of deriving it.  As such, shared
-             secrets should be long strings (considerably longer than
-             the 8-character example shown below).
-
-
-
-
-
-Myers & Rose                                                   [Page 14]
-
-RFC 1725                          POP3                     November 1994
-
-
-         Possible Responses:
-             +OK maildrop locked and ready
-             -ERR permission denied
-
-         Examples:
-             S: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us>
-             C: APOP mrose c4c9334bac560ecc979e58001b3e22fb
-             S: +OK maildrop has 1 message (369 octets)
-
-             In this example, the shared  secret  is  the  string  `tan-
-             staaf'.  Hence, the MD5 algorithm is applied to the string
-
-                <1896.697170952@dbc.mtview.ca.us>tanstaaf
-
-             which produces a digest value of
-
-                c4c9334bac560ecc979e58001b3e22fb
-
-8. POP3 Command Summary
-
-   Minimal POP3 Commands:
-
-      USER name               valid in the AUTHORIZATION state
-      PASS string
-      QUIT
-
-      STAT                    valid in the TRANSACTION state
-      LIST [msg]
-      RETR msg
-      DELE msg
-      NOOP
-      RSET
-
-      QUIT                    valid in the UPDATE state
-
-   Optional POP3 Commands:
-
-      APOP name digest        valid in the AUTHORIZATION state
-
-      TOP msg n               valid in the TRANSACTION state
-      UIDL [msg]
-
-   POP3 Replies:
-
-      +OK
-      -ERR
-
-
-
-
-
-Myers & Rose                                                   [Page 15]
-
-RFC 1725                          POP3                     November 1994
-
-
-   Note that with the exception of the STAT, LIST, and UIDL commands,
-   the reply given by the POP3 server to any command is significant only
-   to "+OK" and "-ERR".  Any text occurring after this reply may be
-   ignored by the client.
-
-9. Example POP3 Session
-
-   S: <wait for connection on TCP port 110>
-   C: <open connection>
-   S:    +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us>
-   C:    APOP mrose c4c9334bac560ecc979e58001b3e22fb
-   S:    +OK mrose's maildrop has 2 messages (320 octets)
-   C:    STAT
-   S:    +OK 2 320
-   C:    LIST
-   S:    +OK 2 messages (320 octets)
-   S:    1 120
-   S:    2 200
-   S:    .
-   C:    RETR 1
-   S:    +OK 120 octets
-   S:    <the POP3 server sends message 1>
-   S:    .
-   C:    DELE 1
-   S:    +OK message 1 deleted
-   C:    RETR 2
-   S:    +OK 200 octets
-   S:    <the POP3 server sends message 2>
-   S:    .
-   C:    DELE 2
-   S:    +OK message 2 deleted
-   C:    QUIT
-   S:    +OK dewey POP3 server signing off (maildrop empty)
-   C:  <close connection>
-   S:  <wait for next connection>
-
-10. Message Format
-
-   All messages transmitted during a POP3 session are assumed to conform
-   to the standard for the format of Internet text messages [RFC822].
-
-   It is important to note that the octet count for a message on the
-   server host may differ from the octet count assigned to that message
-   due to local conventions for designating end-of-line.  Usually,
-   during the AUTHORIZATION state of the POP3 session, the POP3 server
-   can calculate the size of each message in octets when it opens the
-   maildrop.  For example, if the POP3 server host internally represents
-   end-of-line as a single character, then the POP3 server simply counts
-
-
-
-Myers & Rose                                                   [Page 16]
-
-RFC 1725                          POP3                     November 1994
-
-
-   each occurrence of this character in a message as two octets.  Note
-   that lines in the message which start with the termination octet need
-   not be counted twice, since the POP3 client will remove all byte-
-   stuffed termination characters when it receives a multi-line
-   response.
-
-11. References
-
-   [RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
-       821, USC/Information Sciences Institute, August 1982.
-
-   [RFC822] Crocker, D., "Standard for the Format of ARPA-Internet Text
-       Messages", STD 11, RFC 822, University of Delaware, August 1982.
-
-   [RFC1321] Rivest, R. "The MD5 Message-Digest Algorithm", RFC 1321,
-       MIT Laboratory for Computer Science, April, 1992.
-
-12. Security Considerations
-
-   It is conjectured that use of the APOP command provides origin
-   identification and replay protection for a POP3 session.
-   Accordingly, a POP3 server which implements both the PASS and APOP
-   commands must not allow both methods of access for a given user; that
-   is, for a given "USER name" either the PASS or APOP command is
-   allowed, but not both.
-
-   Further, note that as the length of the shared secret increases, so
-   does the difficulty of deriving it.
-
-   Servers that answer -ERR to the USER command are giving potential
-   attackers clues about which names are valid
-
-   Use of the PASS command sends passwords in the clear over the
-   network.
-
-   Use of the RETR and TOP commands sends mail in the clear over the
-   network.
-
-   Otherwise, security issues are not discussed in this memo.
-
-13. Acknowledgements
-
-   The POP family has a long and checkered history.  Although primarily
-   a minor revision to RFC 1460, POP3 is based on the ideas presented in
-   RFCs 918, 937, and 1081.
-
-   In addition, Alfred Grimstad, Keith McCloghrie, and Neil Ostroff
-   provided significant comments on the APOP command.
-
-
-
-Myers & Rose                                                   [Page 17]
-
-RFC 1725                          POP3                     November 1994
-
-
-14. Authors' Addresses
-
-   John G. Myers
-   Carnegie-Mellon University
-   5000 Forbes Ave
-   Pittsburgh, PA 15213
-
-   EMail: jgm+@cmu.edu
-
-
-   Marshall T. Rose
-   Dover Beach Consulting, Inc.
-   420 Whisman Court
-   Mountain View, CA  94043-2186
-
-   EMail: mrose@dbc.mtview.ca.us
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Myers & Rose                                                   [Page 18]
-
diff --git a/RFC/rfc1730.txt b/RFC/rfc1730.txt
deleted file mode 100644
index fcf72ad7..00000000
--- a/RFC/rfc1730.txt
+++ /dev/null
@@ -1,4318 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         M. Crispin
-Request for Comments: 1730                      University of Washington
-Category: Standards Track                                  December 1994
-
-
-              INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4
-
-
-
-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
-
-   The Internet Message Access Protocol, Version 4 (IMAP4) allows a
-   client to access and manipulate electronic mail messages on a server.
-   IMAP4 permits manipulation of remote message folders, called
-   "mailboxes", in a way that is functionally equivalent to local
-   mailboxes.  IMAP4 also provides the capability for an offline client
-   to resynchronize with the server (see also [IMAP-DISC]).
-
-   IMAP4 includes operations for creating, deleting, and renaming
-   mailboxes; checking for new messages; permanently removing messages;
-   setting and clearing flags; RFC 822 and MIME parsing; searching; and
-   selective fetching of message attributes, texts, and portions
-   thereof.  Messages in IMAP4 are accessed by the use of numbers.
-   These numbers are either message sequence numbers (relative position
-   from 1 to the number of messages in the mailbox) or unique
-   identifiers (immutable, strictly ascending values assigned to each
-   message, but which are not necessarily contiguous).
-
-   IMAP4 supports a single server.  A mechanism for supporting multiple
-   IMAP4 servers is discussed in [IMSP].
-
-   IMAP4 does not specify a means of posting mail; this function is
-   handled by a mail transfer protocol such as [SMTP].
-
-   IMAP4 is designed to be upwards compatible from the [IMAP2] protocol.
-   Compatibility issues are discussed in [IMAP-COMPAT].
-
-
-
-
-
-
-Crispin                                                         [Page i]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-
-
-
-Table of Contents
-
-
-
-IMAP4 Protocol Specification ......................................    1
-1.      Organization of this Document .............................    1
-1.1.    How to Read This Document .................................    1
-1.2.    Conventions Used in this Document .........................    1
-2.      Protocol Overview .........................................    1
-2.1.    Link Level ................................................    1
-2.2.    Commands and Responses ....................................    1
-2.2.1.  Client Protocol Sender and Server Protocol Receiver .......    2
-2.2.2.  Server Protocol Sender and Client Protocol Receiver .......    2
-3.      State and Flow Diagram ....................................    4
-3.1.    Non-Authenticated State ...................................    4
-3.2.    Authenticated State .......................................    4
-3.3.    Selected State ............................................    4
-3.4.    Logout State ..............................................    4
-4.      Data Formats ..............................................    6
-4.1.    Atom ......................................................    6
-4.2.    Number ....................................................    6
-4.3.    String ....................................................    6
-4.3.1.  8-bit and Binary Strings ..................................    7
-4.4.    Parenthesized List ........................................    7
-4.5.    NIL .......................................................    7
-5.      Operational Considerations ................................    8
-5.1.    Mailbox Naming ............................................    8
-5.2.    Mailbox Size and Message Status Updates ...................    8
-5.3.    Response when no Command in Progress ......................    8
-5.4.    Autologout Timer ..........................................    9
-5.5.    Multiple Commands in Progress .............................    9
-6.      Client Commands ...........................................   10
-6.1.    Client Commands - Any State ...............................   10
-6.1.1.  CAPABILITY Command ........................................   10
-6.1.2.  NOOP Command ..............................................   11
-6.1.3.  LOGOUT Command ............................................   11
-6.2.    Client Commands - Non-Authenticated State .................   12
-6.2.1.  AUTHENTICATE Command ......................................   12
-6.2.2.  LOGIN Command .............................................   14
-6.3.    Client Commands - Authenticated State .....................   14
-6.3.1.  SELECT Command ............................................   15
-6.3.2.  EXAMINE Command ...........................................   16
-6.3.3.  CREATE Command ............................................   17
-6.3.4.  DELETE Command ............................................   18
-6.3.5.  RENAME Command ............................................   18
-
-
-
-Crispin                                                        [Page ii]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-6.3.6.  SUBSCRIBE Command .........................................   19
-6.3.7.  UNSUBSCRIBE Command .......................................   19
-6.3.8.  LIST Command ..............................................   20
-6.3.9.  LSUB Command ..............................................   22
-6.3.10. APPEND Command ............................................   22
-6.4.    Client Commands - Selected State ..........................   23
-6.4.1.  CHECK Command .............................................   23
-6.4.2.  CLOSE Command .............................................   24
-6.4.3.  EXPUNGE Command ...........................................   25
-6.4.4.  SEARCH Command ............................................   25
-6.4.5.  FETCH Command .............................................   29
-6.4.6.  PARTIAL Command ...........................................   32
-6.4.7.  STORE Command .............................................   33
-6.4.8.  COPY Command ..............................................   34
-6.4.9.  UID Command ...............................................   35
-6.5.    Client Commands - Experimental/Expansion ..................   37
-6.5.1.  X<atom> Command ...........................................   37
-7.      Server Responses ..........................................   38
-7.1.    Server Responses - Status Responses .......................   39
-7.1.1.  OK Response ...............................................   40
-7.1.2.  NO Response ...............................................   40
-7.1.3.  BAD Response ..............................................   41
-7.1.4.  PREAUTH Response ..........................................   41
-7.1.5.  BYE Response ..............................................   41
-7.2.    Server Responses - Server and Mailbox Status ..............   42
-7.2.1.  CAPABILITY Response .......................................   42
-7.2.2.  LIST Response .............................................   43
-7.2.3.  LSUB Response .............................................   44
-7.2.4.  SEARCH Response ...........................................   44
-7.2.5.  FLAGS Response ............................................   44
-7.3.    Server Responses - Message Status .........................   45
-7.3.1.  EXISTS Response ...........................................   45
-7.3.2.  RECENT Response ...........................................   45
-7.3.3.  EXPUNGE Response ..........................................   45
-7.3.4.  FETCH Response ............................................   46
-7.3.5.  Obsolete Responses ........................................   51
-7.4.    Server Responses - Command Continuation Request ...........   51
-8.      Sample IMAP4 session ......................................   52
-9.      Formal Syntax .............................................   53
-10.     Author's Note .............................................   64
-11.     Security Considerations ...................................   64
-12.     Author's Address ..........................................   64
-Appendices ........................................................   65
-A.      Obsolete Commands .........................................   65
-A.6.3.OBS.1.    FIND ALL.MAILBOXES Command ........................   65
-A.6.3.OBS.2.    FIND MAILBOXES Command ............................   65
-A.6.3.OBS.3.    SUBSCRIBE MAILBOX Command .........................   66
-A.6.3.OBS.4.    UNSUBSCRIBE MAILBOX Command .......................   66
-
-
-
-Crispin                                                       [Page iii]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-B.      Obsolete Responses ........................................   68
-B.7.2.OBS.1.    MAILBOX Response ..................................   68
-B.7.3.OBS.1.    COPY Response .....................................   68
-B.7.3.OBS.2.    STORE Response ....................................   69
-C.      References ................................................   70
-E.      IMAP4 Keyword Index .......................................   71
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin                                                        [Page iv]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-IMAP4 Protocol Specification
-
-1.      Organization of this Document
-
-1.1.    How to Read This Document
-
-   This document is written from the point of view of the implementor of
-   an IMAP4 client or server.  Beyond the protocol overview in section
-   2, it is not optimized for someone trying to understand the operation
-   of the protocol.  The material in sections 3 through 5 provides the
-   general context and definitions with which IMAP4 operates.
-
-   Sections 6, 7, and 9 describe the IMAP commands, responses, and
-   syntax, respectively.  The relationships among these are such that it
-   is almost impossible to understand any of them separately.  In
-   particular, one should not attempt to deduce command syntax from the
-   command section alone; one should instead refer to the formal syntax
-   section.
-
-
-1.2.    Conventions Used in this Document
-
-   In examples, "C:" and "S:" indicate lines sent by the client and
-   server respectively.
-
-
-2.      Protocol Overview
-
-2.1.    Link Level
-
-   The IMAP4 protocol assumes a reliable data stream such as provided by
-   TCP.  When TCP is used, an IMAP4 server listens on port 143.
-
-
-2.2.    Commands and Responses
-
-   An IMAP4 session consists of the establishment of a client/server
-   connection, an initial greeting from the server, and client/server
-   interactions.  These client/server interactions consist of a client
-   command, server data, and a server completion result response.
-
-   All interactions transmitted by client and server are in the form of
-   lines; that is, strings that end with a CRLF.  The protocol receiver
-   of an IMAP4 client or server is either reading a line, or is reading
-   a sequence of octets with a known count followed by a line.
-
-
-
-
-
-
-Crispin                                                         [Page 1]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-2.2.1.  Client Protocol Sender and Server Protocol Receiver
-
-   The client command begins an operation.  Each client command is
-   prefixed with a identifier (typically a short alphanumeric string,
-   e.g. A0001, A0002, etc.) called a "tag".  A different tag is
-   generated by the client for each command.
-
-   There are two cases in which a line from the client does not
-   represent a complete command.  In one case, a command argument is
-   quoted with an octet count (see the description of literal in String
-   under Data Formats); in the other case, the command arguments require
-   server feedback (see the AUTHENTICATE command).  In either case, the
-   server sends a command continuation request response if it is ready
-   for the octets (if appropriate) and the remainder of the command.
-   This response is prefixed with the token "+".
-
-        Note: If, instead, the server detected an error in the
-        command, it sends a BAD completion response with tag
-        matching the command (as described below) to reject the
-        command and prevent the client from sending any more of the
-        command.
-
-        It is also possible for the server to send a completion
-        response for some other command (if multiple commands are
-        in progress), or untagged data.  In either case, the
-        command continuation request is still pending; the client
-        takes the appropriate action for the response, and reads
-        another response from the server.
-
-   The protocol receiver of an IMAP4 server reads a command line from
-   the client, parses the command and its arguments, and transmits
-   server data and a server command completion result response.
-
-
-2.2.2.  Server Protocol Sender and Client Protocol Receiver
-
-   Data transmitted by the server to the client and status responses
-   that do not indicate command completion are prefixed with the token
-   "*", and are called untagged responses.
-
-   Server data may be sent as a result of a client command, or may be
-   sent unilaterally by the server.  There is no syntactic difference
-   between server data that resulted from a specific command and server
-   data that were sent unilaterally.
-
-   The server completion result response indicates the success or
-   failure of the operation.  It is tagged with the same tag as the
-   client command which began the operation.  Thus, if more than one
-
-
-
-Crispin                                                         [Page 2]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-   command is in progress, the tag in a server completion response
-   identifies the command to which the response applies.  There are
-   three possible server completion responses: OK (indicating success),
-   NO (indicating failure), or BAD (indicating protocol error such as
-   unrecognized command or command syntax error).
-
-   The protocol receiver of an IMAP4 client reads a response line from
-   the server.  It then takes action on the response based upon the
-   first token of the response, which may be a tag, a "*", or a "+".  As
-   described above.
-
-   A client MUST be prepared to accept any server response at all times.
-   This includes server data that it may not have requested.  Server
-   data SHOULD be recorded, so that the client can reference its
-   recorded copy rather than sending a command to the server to request
-   the data.  In the case of certain server data, recording the data is
-   mandatory.
-
-   This topic is discussed in greater detail in the Server Responses
-   section.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin                                                         [Page 3]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-3.      State and Flow Diagram
-
-   An IMAP4 server is in one of four states.  Most commands are valid in
-   only certain states.  It is a protocol error for the client to
-   attempt a command while the command is in an inappropriate state.  In
-   this case, a server will respond with a BAD or NO (depending upon
-   server implementation) command completion result.
-
-
-3.1.    Non-Authenticated State
-
-   In non-authenticated state, the user must supply authentication
-   credentials before most commands will be permitted.  This state is
-   entered when a connection starts unless the connection has been
-   pre-authenticated.
-
-
-3.2.    Authenticated State
-
-   In authenticated state, the user is authenticated and must select a
-   mailbox to access before commands that affect messages will be
-   permitted.  This state is entered when a pre-authenticated connection
-   starts, when acceptable authentication credentials have been
-   provided, or after an error in selecting a mailbox.
-
-
-3.3.    Selected State
-
-   In selected state, a mailbox has been selected to access.  This state
-   is entered when a mailbox has been successfully selected.
-
-
-3.4.    Logout State
-
-   In logout state, the session is being terminated, and the server will
-   close the connection.  This state can be entered as a result of a
-   client request or by unilateral server decision.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin                                                         [Page 4]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-            +--------------------------------------+
-            |initial connection and server greeting|
-            +--------------------------------------+
-                      || (1)       || (2)        || (3)
-                      VV           ||            ||
-            +-----------------+    ||            ||
-            |non-authenticated|    ||            ||
-            +-----------------+    ||            ||
-             || (7)   || (4)       ||            ||
-             ||       VV           VV            ||
-             ||     +----------------+           ||
-             ||     | authenticated  |<=++       ||
-             ||     +----------------+  ||       ||
-             ||       || (7)   || (5)   || (6)   ||
-             ||       ||       VV       ||       ||
-             ||       ||    +--------+  ||       ||
-             ||       ||    |selected|==++       ||
-             ||       ||    +--------+           ||
-             ||       ||       || (7)            ||
-             VV       VV       VV                VV
-            +--------------------------------------+
-            |     logout and close connection      |
-            +--------------------------------------+
-
-         (1) connection without pre-authentication (OK greeting)
-         (2) pre-authenticated connection (PREAUTH greeting)
-         (3) rejected connection (BYE greeting)
-         (4) successful LOGIN or AUTHENTICATE command
-         (5) successful SELECT or EXAMINE command
-         (6) CLOSE command, or failed SELECT or EXAMINE command
-         (7) LOGOUT command, server shutdown, or connection closed
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin                                                         [Page 5]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-4.      Data Formats
-
-   IMAP4 uses textual commands and responses.  Data in IMAP4 can be in
-   one of several forms: atom, number, string, parenthesized list, or
-   NIL.
-
-
-4.1.    Atom
-
-   An atom consists of one or more non-special characters.
-
-
-4.2.    Number
-
-   A number consists of one or more digit characters, and represents a
-   numeric value.
-
-
-4.3.    String
-
-   A string is in one of two forms: literal and quoted string.  The
-   literal form is the general form of string.  The quoted string form
-   is an alternative that avoids the overhead of processing a literal at
-   the cost of restrictions of what may be in a quoted string.
-
-   A literal is a sequence of zero or more octets (including CR and LF),
-   prefix-quoted with an octet count in the form of an open brace ("{"),
-   the number of octets, close brace ("}"), and CRLF.  In the case of
-   literals transmitted from server to client, the CRLF is immediately
-   followed by the octet data.  In the case of literals transmitted from
-   client to server, the client must wait to receive a command
-   continuation request (described later in this document) before
-   sending the octet data (and the remainder of the command).
-
-   A quoted string is a sequence of zero or more 7-bit characters,
-   excluding CR and LF, with double quote (<">) characters at each end.
-
-   The empty string is respresented as either "" (a quoted string with
-   zero characters between double quotes) or as {0} followed by CRLF (a
-   literal with an octet count of 0).
-
-        Note: Even if the octet count is 0, a client transmitting a
-        literal must wait to receive a command continuation
-        request.
-
-
-
-
-
-
-
-Crispin                                                         [Page 6]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-4.3.1.  8-bit and Binary Strings
-
-   8-bit textual and binary mail is supported through the use of
-   [MIME-1] encoding.  IMAP4 implementations MAY transmit 8-bit or
-   multi-octet characters in literals, but should do so only when the
-   character set is identified.
-
-   Although a BINARY body encoding is defined, unencoded binary strings
-   are not permitted.  A "binary string" is any string with NUL
-   characters.  Implementations MUST encode binary data into a textual
-   form such as BASE64 before transmitting the data.  A string with an
-   excessive amount of CTL characters may also be considered to be
-   binary, although this is not required.
-
-
-4.4.    Parenthesized List
-
-   Data structures are represented as a "parenthesized list"; a sequence
-   of data items, delimited by space, and bounded at each end by
-   parentheses.  A parenthesized list may itself contain other
-   parenthesized lists, using multiple levels of parentheses to indicate
-   nesting.
-
-   The empty list is represented as () -- a parenthesized list with no
-   members.
-
-
-4.5.    NIL
-
-   The special atom "NIL" represents the non-existence of a particular
-   data item that is represented as a string or parenthesized list, as
-   distinct from the empty string "" or the empty parenthesized list ().
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin                                                         [Page 7]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-5.      Operational Considerations
-
-5.1.    Mailbox Naming
-
-   The interpretation of mailbox names is implementation-dependent.
-   However, the mailbox name INBOX is a special name reserved to mean
-   "the primary mailbox for this user on this server".  If it is desired
-   to export hierarchical mailbox names, mailbox names must be
-   left-to-right hierarchical using a single character to separate
-   levels of hierarchy.  The same hierarchy separator character is used
-   for all levels of hierarchy within a single name.
-
-5.2.    Mailbox Size and Message Status Updates
-
-   At any time, a server can send data that the client did not request.
-   Sometimes, such behavior is required.  For example, agents other than
-   the server may add messages to the mailbox (e.g. new mail delivery),
-   change the flags of message in the mailbox (e.g. simultaneous access
-   to the same mailbox by multiple agents), or even remove messages from
-   the mailbox.  A server MUST send mailbox size updates automatically
-   if a mailbox size change is observed during the processing of a
-   command.  A server SHOULD send message flag updates automatically,
-   without requiring the client to request such updates explicitly.
-   Special rules exist for server notification of a client about the
-   removal of messages to prevent synchronization errors; see the
-   description of the EXPUNGE response for more details.
-
-   Regardless of what implementation decisions a client may take on
-   remembering data from the server, a client implementation MUST record
-   mailbox size updates.  It MUST NOT assume that any command after
-   initial mailbox selection will return the size of the mailbox.
-
-
-5.3.    Response when no Command in Progress
-
-   Server implementations are permitted to send an untagged response
-   (except for EXPUNGE) while there is no command in progress.  Server
-   implementations that send such responses MUST deal with flow control
-   considerations.  Specifically, they must either (1) verify that the
-   size of the data does not exceed the underlying transport's available
-   window size, or (2) use non-blocking writes.
-
-
-
-
-
-
-
-
-
-
-Crispin                                                         [Page 8]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-5.4.    Autologout Timer
-
-   If a server has an inactivity autologout timer, that timer MUST be of
-   at least 30 minutes' duration.  The receipt of ANY command from the
-   client during that interval should suffice to reset the autologout
-   timer.
-
-
-5.5.    Multiple Commands in Progress
-
-   The client is not required to wait for the completion result response
-   of a command before sending another command, subject to flow control
-   constraints on the underlying data stream.  Similarly, a server is
-   not required to process a command to completion before beginning
-   processing of the next command, unless an ambiguity would result
-   because of a command that would affect the results of other commands.
-   If there is such an ambiguity, the server executes commands to
-   completion in the order given by the client.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin                                                         [Page 9]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-6.      Client Commands
-
-   IMAP4 commands are described in this section.  Commands are organized
-   by the state in which the command is permitted.  Commands which are
-   permitted in multiple states are listed in the minimum permitted
-   state (for example, commands valid in authenticated and selected
-   state are listed in the authenticated state commands).
-
-   Command arguments, identified by "Arguments:" in the command
-   descriptions below, are described by function, not by syntax.  The
-   precise syntax of command arguments is described in the Formal Syntax
-   section.
-
-   Some commands cause specific server data to be returned; these are
-   identified by "Data:" in the command descriptions below.  See the
-   response descriptions in the Responses section for information on
-   these responses, and the Formal Syntax section for the precise syntax
-   of these responses.  It is possible for server data to be transmitted
-   as a result of any command; thus, commands that do not specifically
-   require server data specify "no specific data for this command"
-   instead of "none".
-
-   The "Result:" in the command description refers to the possible
-   tagged status responses to a command, and any special interpretation
-   of these status responses.
-
-
-6.1.    Client Commands - Any State
-
-   The following commands are valid in any state: CAPABILITY, NOOP, and
-   LOGOUT.
-
-6.1.1.  CAPABILITY Command
-
-   Arguments:  none
-
-   Data:       mandatory untagged response: CAPABILITY
-
-   Result:     OK - capability completed
-               BAD - command unknown or arguments invalid
-
-      The CAPABILITY command requests a listing of capabilities that the
-      server supports.  The server MUST send a single untagged
-      CAPABILITY response with "IMAP4" as the first listed capability
-      before the (tagged) OK response.  This listing of capabilities is
-      not dependent upon connection state or user.  It is therefore not
-      necessary to issue a CAPABILITY command more than once in a
-      session.
-
-
-
-Crispin                                                        [Page 10]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-      Capability names other than "IMAP4" refer to extensions,
-      revisions, or amendments to this specification.  See the
-      documentation of the CAPABILITY response for additional
-      information.  No capabilities are enabled without explicit client
-      action to invoke the capability.  See the section entitled "Client
-      Commands - Experimental/Expansion" for information about the form
-      of site or implementation-specific capabilities.
-
-   Example:    C: abcd CAPABILITY
-               S: * CAPABILITY IMAP4
-               S: abcd OK CAPABILITY completed
-
-
-6.1.2.  NOOP Command
-
-   Arguments:  none
-
-   Data:       no specific data for this command (but see below)
-
-   Result:     OK - noop completed
-               BAD - command unknown or arguments invalid
-
-      The NOOP command always succeeds.  It does nothing.
-
-      Since any command can return a status update as untagged data, the
-      NOOP command can be used as a periodic poll for new messages or
-      message status updates during a period of inactivity.  The NOOP
-      command can also be used to reset any inactivity autologout timer
-      on the server.
-
-   Example:    C: a002 NOOP
-               S: a002 OK NOOP completed
-                  . . .
-               C: a047 NOOP
-               S: * 22 EXPUNGE
-               S: * 23 EXISTS
-               S: * 3 RECENT
-               S: * 14 FETCH (FLAGS (\Seen \Deleted))
-               S: a047 OK NOOP completed
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin                                                        [Page 11]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-6.1.3.  LOGOUT Command
-
-   Arguments:  none
-
-   Data:       mandatory untagged response: BYE
-
-   Result:     OK - logout completed
-               BAD - command unknown or arguments invalid
-
-      The LOGOUT command informs the server that the client is done with
-      the session.  The server must send a BYE untagged response before
-      the (tagged) OK response, and then close the network connection.
-
-   Example:    C: A023 LOGOUT
-               S: * BYE IMAP4 Server logging out
-               S: A023 OK LOGOUT completed
-               (Server and client then close the connection)
-
-
-
-6.2.    Client Commands - Non-Authenticated State
-
-   In non-authenticated state, the AUTHENTICATE or LOGIN command
-   establishes authentication and enter authenticated state.  The
-   AUTHENTICATE command provides a general mechanism for a variety of
-   authentication techniques, whereas the LOGIN command uses the
-   traditional user name and plaintext password pair.
-
-   Server implementations may allow non-authenticated access to certain
-   mailboxes.  The convention is to use a LOGIN command with the userid
-   "anonymous".  A password is required.  It is implementation-dependent
-   what requirements, if any, are placed on the password and what access
-   restrictions are placed on anonymous users.
-
-   Once authenticated (including as anonymous), it is not possible to
-   re-enter non-authenticated state.
-
-   In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
-   the following commands are valid in non-authenticated state:
-   AUTHENTICATE and LOGIN.
-
-
-
-
-
-
-
-
-
-
-
-Crispin                                                        [Page 12]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-6.2.1.  AUTHENTICATE Command
-
-   Arguments:  authentication mechanism name
-
-   Data:       continuation data may be requested
-
-   Result:     OK - authenticate completed, now in authenticated state
-               NO - authenticate failure: unsupported authentication
-                    mechanism, credentials rejected
-               BAD - command unknown or arguments invalid,
-                    authentication exchange cancelled
-
-      The AUTHENTICATE command indicates an authentication mechanism,
-      such as described in [IMAP-AUTH], 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 protection mechanism for
-      subsequent protocol interactions.  If the requested authentication
-      mechanism is not supported, the server should reject the
-      AUTHENTICATE command by sending a tagged NO response.
-
-      The authentication protocol exchange consists of a series of
-      server challenges and client answers that are specific to the
-      authentication mechanism.  A server challenge consists of a
-      command continuation request response with the "+" token followed
-      by a BASE64 encoded string.  The client answer consists of a line
-      consisting of a BASE64 encoded string.  If the client wishes to
-      cancel an authentication exchange, it should issue a line with a
-      single "*".  If the server receives such an answer, it must reject
-      the AUTHENTICATE command by sending a tagged BAD response.
-
-      A protection mechanism provides integrity and privacy protection
-      to the protocol session.  If a protection mechanism is negotiated,
-      it is applied to all subsequent data sent over the connection.
-      The protection mechanism takes effect immediately following the
-      CRLF that concludes the authentication exchange for the client,
-      and the CRLF of the tagged OK response for the server.  Once the
-      protection mechanism is in effect, the stream of command and
-      response octets is processed into buffers of ciphertext.  Each
-      buffer is transferred over the connection as a stream of octets
-      prepended with a four octet field in network byte order that
-      represents the length of the following data.  The maximum
-      ciphertext buffer length is defined by the protection mechanism.
-
-      The server is not required to support any particular
-      authentication mechanism, nor are authentication mechanisms
-      required to support any protection mechanisms.  If an AUTHENTICATE
-      command fails with a NO response, the client may try another
-
-
-
-Crispin                                                        [Page 13]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-      authentication mechanism by issuing another AUTHENTICATE command,
-      or may attempt to authenticate by using the LOGIN command.  In
-      other words, the client may request authentication types in
-      decreasing order of preference, with the LOGIN command as a last
-      resort.
-
-   Example:    S: * OK KerberosV4 IMAP4 Server
-               C: A001 AUTHENTICATE KERBEROS_V4
-               S: + AmFYig==
-               C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
-                  +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd
-                  WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
-               S: + or//EoAADZI=
-               C: DiAF5A4gA+oOIALuBkAAmw==
-               S: A001 OK Kerberos V4 authentication successful
-
-        Note: the line breaks in the first client answer are for
-        editorial clarity and are not in real authenticators.
-
-
-6.2.2.  LOGIN Command
-
-   Arguments:  user name
-               password
-
-   Data:       no specific data for this command
-
-   Result:     OK - login completed, now in authenticated state
-               NO - login failure: user name or password rejected
-               BAD - command unknown or arguments invalid
-
-      The LOGIN command identifies the user to the server and carries
-      the plaintext password authenticating this user.
-
-   Example:    C: a001 LOGIN SMITH SESAME
-               S: a001 OK LOGIN completed
-
-
-
-6.3.    Client Commands - Authenticated State
-
-   In authenticated state, commands that manipulate mailboxes as atomic
-   entities are permitted.  Of these commands, the SELECT and EXAMINE
-   commands will select a mailbox for access and enter selected state.
-
-
-
-
-
-
-
-Crispin                                                        [Page 14]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-   In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
-   the following commands are valid in authenticated state: SELECT,
-   EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB,
-   and APPEND.
-
-6.3.1.  SELECT Command
-
-   Arguments:  mailbox name
-
-   Data:       mandatory untagged responses: FLAGS, EXISTS, RECENT
-               optional OK untagged responses: UNSEEN, PERMANENTFLAGS
-
-   Result:     OK - select completed, now in selected state
-               NO - select failure, now in authenticated state: no
-                    such mailbox, can't access mailbox
-               BAD - command unknown or arguments invalid
-
-      The SELECT command selects a  mailbox  so  that  messages  in  the
-      mailbox  can  be  accessed.  Before returning an OK to the client,
-      the server MUST send the following untagged data to the client:
-
-         FLAGS       Defined flags in the mailbox
-
-         <n> EXISTS  The number of messages in the mailbox
-
-         <n> RECENT  The number of messages added to the  mailbox  since
-                     the previous time this mailbox was read
-
-         OK [UIDVALIDITY <n>]
-                     The unique  identifier  validity  value.   See  the
-                     description of the UID command for more detail.
-
-      to define the initial state of the mailbox at the client.  If it
-      is not possible to determine the messages that were added since
-      the previous time a mailbox was read, then all messages SHOULD be
-      considered recent.
-
-      The server SHOULD also send an UNSEEN response code in an OK
-      untagged response, indicating the message sequence number of the
-      first unseen message in the mailbox.
-
-      If the client can not change the permanent state of one or more of
-      the flags listed in the FLAGS untagged response, the server SHOULD
-      send a PERMANENTFLAGS response code in an OK untagged response,
-      listing the flags that the client may change permanently.
-
-      Only one mailbox may be selected at a time in a session;
-      simultaneous access to multiple mailboxes requires multiple
-
-
-
-Crispin                                                        [Page 15]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-      sessions.  The SELECT command automatically deselects any
-      currently selected mailbox before attempting the new selection.
-      Consequently, if a mailbox is selected and a SELECT command that
-      fails is attempted, no mailbox is selected.
-
-      If the user is permitted to modify the mailbox, the server SHOULD
-      prefix the text of the tagged OK response with the "[READ-WRITE]"
-      response code.
-
-      If the user is not permitted to modify the mailbox but is
-      permitted read access, the mailbox is selected as read-only, and
-      the server MUST prefix the text of the tagged OK response to
-      SELECT with the "[READ-ONLY]" response code.  Read-only access
-      through SELECT differs from the EXAMINE command in that certain
-      read-only mailboxes may permit the change of permanent state on a
-      per-user (as opposed to global) basis.  Netnews messages marked in
-      a user's .newsrc file are an example of such per-user permanent
-      state that can be modified with read-only mailboxes.
-
-   Example:    C: A142 SELECT INBOX
-               S: * 172 EXISTS
-               S: * 1 RECENT
-               S: * OK [UNSEEN 12] Message 12 is first unseen
-               S: * OK [UIDVALIDITY 3857529045] UIDs valid
-               S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
-               S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
-               S: A142 OK [READ-WRITE] SELECT completed
-
-
-6.3.2.  EXAMINE Command
-
-   Arguments:  mailbox name
-
-   Data:       mandatory untagged responses: FLAGS, EXISTS, RECENT
-               optional OK untagged responses: UNSEEN, PERMANENTFLAGS
-
-   Result:     OK - examine completed, now in selected state
-               NO - examine failure, now in authenticated state: no
-                    such mailbox, can't access mailbox
-               BAD - command unknown or arguments invalid
-
-      The EXAMINE command is identical to SELECT and returns the same
-      output; however, the selected mailbox is identified as read-only.
-      No changes to the permanent state of the mailbox, including
-      per-user state, are permitted.
-
-
-
-
-
-
-Crispin                                                        [Page 16]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-      The text of the tagged OK response to the EXAMINE command MUST
-      begin with the "[READ-ONLY]" response code.
-
-   Example:    C: A932 EXAMINE blurdybloop
-               S: * 17 EXISTS
-               S: * 2 RECENT
-               S: * OK [UNSEEN 8] Message 8 is first unseen
-               S: * OK [UIDVALIDITY 3857529045] UIDs valid
-               S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
-               S: * OK [PERMANENTFLAGS ()] No permanent flags permitted
-               S: A932 OK [READ-ONLY] EXAMINE completed
-
-
-6.3.3.  CREATE Command
-
-   Arguments:  mailbox name
-
-   Data:       no specific data for this command
-
-   Result:     OK - create completed
-               NO - create failure: can't create mailbox with that name
-               BAD - command unknown or arguments invalid
-
-      The CREATE command creates a mailbox with the given name.  An OK
-      response is returned only if a new mailbox with that name has been
-      created.  It is an error to attempt to create INBOX or a mailbox
-      with a name that refers to an extant mailbox.  Any error in
-      creation will return a tagged NO response.
-
-      If the mailbox name is suffixed with the server's hierarchy
-      separator character (as returned from the server by a LIST
-      command), this is a declaration that the client may, in the
-      future, create mailbox names under this name in the hierarchy.
-      Server implementations that do not require this declaration MUST
-      ignore it.
-
-      If a new mailbox is created with the same name as a mailbox which
-      was deleted, its unique identifiers MUST be greater than any
-      unique identifiers used in the previous incarnation of the mailbox
-      UNLESS the new incarnation has a different unique identifier
-      validity value.  See the description of the UID command for more
-      detail.
-
-   Example:    C: A003 CREATE owatagusiam/
-               S: A003 OK CREATE completed
-               C: A004 CREATE owatagusiam/blurdybloop
-               S: A004 OK CREATE completed
-
-
-
-
-Crispin                                                        [Page 17]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-        Note: the interpretation of this example depends on whether
-        "/" was returned as the hierarchy separator from LIST.  If
-        "/" is the hierarchy separator, a new level of hierarchy
-        named "owatagusiam" with a member called "blurdybloop" is
-        created.  Otherwise, two mailboxes at the same hierarchy
-        level are created.
-
-
-6.3.4.  DELETE Command
-
-   Arguments:  mailbox name
-
-   Data:       no specific data for this command
-
-   Result:     OK - delete completed
-               NO - delete failure: can't delete mailbox with that name
-               BAD - command unknown or arguments invalid
-
-      The DELETE command permanently removes the mailbox with the given
-      name.  A tagged OK response is returned only if the mailbox has
-      been deleted.  It is an error to attempt to delete INBOX or a
-      mailbox name that does not exist.  Any error in deletion will
-      return a tagged NO response.
-
-      The value of the highest-used unique indentifier of the deleted
-      mailbox MUST be preserved so that a new mailbox created with the
-      same name will not reuse the identifiers of the former
-      incarnation, UNLESS the new incarnation has a different unique
-      identifier validity value.  See the description of the UID command
-      for more detail.
-
-   Example:    C: A683 DELETE blurdybloop
-               S: A683 OK DELETE completed
-
-
-6.3.5.  RENAME Command
-
-   Arguments:  existing mailbox name
-               new mailbox name
-
-   Data:       no specific data for this command
-
-   Result:     OK - rename completed
-               NO - rename failure: can't rename mailbox with that name,
-                    can't rename to mailbox with that name
-               BAD - command unknown or arguments invalid
-
-
-
-
-
-Crispin                                                        [Page 18]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-      The RENAME command changes the name of a mailbox.  A tagged OK
-      response is returned only if the mailbox has been renamed.  It is
-      an error to attempt to rename from a mailbox name that does not
-      exist or to a mailbox name that already exists.  Any error in
-      renaming will return a tagged NO response.
-
-      Renaming INBOX is permitted; a new, empty INBOX is created in its
-      place.
-
-   Example:    C: Z4S9 RENAME blurdybloop owatagusiam
-               S: Z4S9 OK RENAME completed
-
-
-6.3.6.  SUBSCRIBE Command
-
-   Arguments:  mailbox
-
-   Data:       no specific data for this command
-
-   Result:     OK - subscribe completed
-               NO - subscribe failure: can't subscribe to that name
-               BAD - command unknown or arguments invalid
-
-      The SUBSCRIBE command adds the specified mailbox name to the
-      server's set of "active" or "subscribed" mailboxes as returned by
-      the LSUB command.  This command returns a tagged OK response only
-      if the subscription is successful.
-
-   Example:    C: A002 SUBSCRIBE #news.comp.mail.mime
-               S: A002 OK SUBSCRIBE completed
-
-
-6.3.7.  UNSUBSCRIBE Command
-
-   Arguments:  mailbox name
-
-   Data:       no specific data for this command
-
-   Result:     OK - unsubscribe completed
-               NO - unsubscribe failure: can't unsubscribe that name
-               BAD - command unknown or arguments invalid
-
-      The UNSUBSCRIBE command removes the specified mailbox name from
-      the server's set of "active" or "subscribed" mailboxes as returned
-      by the LSUB command.  This command returns a tagged OK response
-      only if the unsubscription is successful.
-
-
-
-
-
-Crispin                                                        [Page 19]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-   Example:    C: A002 UNSUBSCRIBE #news.comp.mail.mime
-               S: A002 OK UNSUBSCRIBE completed
-
-
-6.3.8.  LIST Command
-
-   Arguments:  reference name
-               mailbox name with possible wildcards
-
-   Data:       untagged responses: LIST
-
-   Result:     OK - list completed
-               NO - list failure: can't list that reference or name
-               BAD - command unknown or arguments invalid
-
-      The LIST command returns a subset of names from the complete set
-      of all names available to the user.  Zero or more untagged LIST
-      replies are returned, containing the name attributes, hierarchy
-      delimiter, and name; see the description of the LIST reply for
-      more detail.
-
-      An empty ("" string) reference name argument indicates that the
-      mailbox name is interpreted as by SELECT. The returned mailbox
-      names MUST match the supplied mailbox name pattern.  A non-empty
-      reference name argument is the name of a mailbox or a level of
-      mailbox hierarchy, and indicates a context in which the mailbox
-      name is interpreted in an implementation-defined manner.
-
-      The reference and mailbox name arguments are interpreted, in an
-      implementation-dependent fashion, into a canonical form that
-      represents an unambiguous left-to-right hierarchy.  The returned
-      mailbox names will be in the interpreted form.
-
-      Any part of the reference argument that is included in the
-      interpreted form SHOULD prefix the interpreted form.  It should
-      also be in the same form as the reference name argument.  This
-      rule permits the client to determine if the returned mailbox name
-      is in the context of the reference argument, or if something about
-      the mailbox argument overrode the reference argument.  Without
-      this rule, the client would have to have knowledge of the server's
-      naming semantics including what characters are "breakouts" that
-      override a naming context.
-
-
-
-
-
-
-
-
-
-Crispin                                                        [Page 20]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-           For example, here are some examples of how references
-           and mailbox names might be interpreted on a UNIX-based
-           server:
-
-               Reference     Mailbox Name  Interpretation
-               ------------  ------------  --------------
-               ~smith/Mail/  foo.*         ~smith/Mail/foo.*
-               archive/      %             archive/%
-               #news.        comp.mail.*   #news.comp.mail.*
-               ~smith/Mail/  /usr/doc/foo  /usr/doc/foo
-               archive/      ~fred/Mail/*  ~fred/Mail/*
-
-           The first three examples demonstrate interpretations in
-           the context of the reference argument.  Note that
-           "~smith/Mail" should not be transformed into something
-           like "/u2/users/smith/Mail", or it would be impossible
-           for the client to determine that the interpretation was
-           in the context of the reference.
-
-      The character "*" is a wildcard, and matches zero or more
-      characters at this position.  The character "%" is similar to "*",
-      but it does not match a hierarchy delimiter.  If the "%" wildcard
-      is the last character of a mailbox name argument, matching levels
-      of hierarchy are also returned.  If these levels of hierarchy are
-      not also selectable mailboxes, they are returned with the
-      \Noselect mailbox name attribute (see the description of the LIST
-      response for more detail).
-
-      Server implementations are permitted to "hide" otherwise
-      accessible mailboxes from the wildcard characters, by preventing
-      certain characters or names from matching a wildcard in certain
-      situations.  For example, a UNIX-based server might restrict the
-      interpretation of "*" so that an initial "/" character does not
-      match.
-
-      The special name INBOX is included in the output from LIST if it
-      matches the input arguments and INBOX is supported by this server
-      for this user.  The criteria for omitting INBOX is whether SELECT
-      INBOX will return failure; it is not relevant whether the user's
-      real INBOX resides on this or some other server.
-
-   Example:    C: A002 LIST "~/Mail/" "%"
-               S: * LIST (\Noselect) "/" ~/Mail/foo
-               S: * LIST () "/" ~/Mail/meetings
-               S: A002 OK LIST completed
-
-
-
-
-
-
-Crispin                                                        [Page 21]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-6.3.9.  LSUB Command
-
-   Arguments:  reference name
-               mailbox name with possible wildcards
-
-   Data:       untagged responses: LSUB
-
-   Result:     OK - lsub completed
-               NO - lsub failure: can't list that reference or name
-               BAD - command unknown or arguments invalid
-
-      The LSUB command returns a subset of names from the set of names
-      that the user has declared as being "active" or "subscribed".
-      Zero or more untagged LSUB replies are returned.  The arguments to
-      LSUB are in the same form as those for LIST.
-
-   Example:    C: A002 LSUB "#news." "comp.mail.*"
-               S: * LSUB () "." #news.comp.mail.mime
-               S: * LSUB () "." #news.comp.mail.misc
-               S: A002 OK LSUB completed
-
-
-6.3.10. APPEND Command
-
-   Arguments:  mailbox name
-               optional flag parenthesized list
-               optional date/time string
-               message literal
-
-   Data:       no specific data for this command
-
-   Result:     OK - append completed
-               NO - append error: can't append to that mailbox, error
-                    in flags or date/time or message text
-               BAD - command unknown or arguments invalid
-
-      The APPEND command appends the literal argument as a new message
-      in the specified destination mailbox.  This argument is in the
-      format of an [RFC-822] message.  8-bit characters are permitted in
-      the message.  A server implementation that is unable to preserve
-      8-bit data properly MUST be able to reversibly convert 8-bit
-      APPEND data to 7-bit using [MIME-1] encoding.
-
-      If a flag parenthesized list or date_time are specified, that data
-      SHOULD be set in the resulting message; otherwise, the defaults of
-      empty flags and the current date/time are used.
-
-
-
-
-
-Crispin                                                        [Page 22]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-      If the append is unsuccessful for any reason, the mailbox MUST be
-      restored to its state before the APPEND attempt; no partial
-      appending is permitted.  If the mailbox is currently selected, the
-      normal new mail actions should occur.
-
-      If the destination mailbox does not exist, a server MUST return an
-      error, and MUST NOT automatically create the mailbox.  Unless it
-      is certain that the destination mailbox can not be created, the
-      server MUST send the response code "[TRYCREATE]" as the prefix of
-      the text of the tagged NO response.  This gives a hint to the
-      client that it can attempt a CREATE command and retry the APPEND
-      if the CREATE is successful.
-
-   Example:    C: A003 APPEND saved-messages (\Seen) {310}
-               C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
-               C: From: Fred Foobar <foobar@Blurdybloop.COM>
-               C: Subject: afternoon meeting
-               C: To: mooch@owatagu.siam.edu
-               C: Message-Id: <B27397-0100000@Blurdybloop.COM>
-               C: MIME-Version: 1.0
-               C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
-               C:
-               C: Hello Joe, do you think we can meet at 3:30 tomorrow?
-               C:
-               S: A003 OK APPEND completed
-
-        Note: the APPEND command is not used for message delivery,
-        because it does not provide a mechanism to transfer [SMTP]
-        envelope information.
-
-
-
-6.4.    Client Commands - Selected State
-
-   In selected state, commands that manipulate messages in a mailbox are
-   permitted.
-
-   In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
-   and the authenticated state commands (SELECT, EXAMINE, CREATE,
-   DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, FIND
-   ALL.MAILBOXES, FIND MAILBOXES, and APPEND), the following commands
-   are valid in the selected state: CHECK, CLOSE, EXPUNGE, SEARCH,
-   FETCH, PARTIAL, STORE, COPY, and UID.
-
-
-
-
-
-
-
-
-Crispin                                                        [Page 23]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-6.4.1.  CHECK Command
-
-   Arguments:  none
-
-   Data:       no specific data for this command
-
-   Result:     OK - check completed
-               BAD - command unknown or arguments invalid
-
-      The CHECK command requests a checkpoint of the currently selected
-      mailbox.  A checkpoint refers to any implementation-dependent
-      housekeeping associated with the mailbox (e.g. resolving the
-      server's in-memory state of the mailbox with the state on its
-      disk) that is not normally executed as part of each command.  A
-      checkpoint may take a non-instantaneous amount of real time to
-      complete.  If a server implementation has no such housekeeping
-      considerations, CHECK is equivalent to NOOP.
-
-      There is no guarantee that an EXISTS untagged response will happen
-      as a result of CHECK.  NOOP, not CHECK, should be used for new
-      mail polling.
-
-   Example:    C: FXXZ CHECK
-               S: FXXZ OK CHECK Completed
-
-
-6.4.2.  CLOSE Command
-
-   Arguments:  none
-
-   Data:       no specific data for this command
-
-   Result:     OK - close completed, now in authenticated state
-               NO - close failure: no mailbox selected
-               BAD - command unknown or arguments invalid
-
-      The CLOSE command permanently removes from the currently selected
-      mailbox all messages that have the \Deleted flag set, and returns
-      to authenticated state from selected state.  No untagged EXPUNGE
-      responses are sent.
-
-      No messages are removed, and no error is given, if the mailbox is
-      selected by an EXAMINE command or is otherwise selected read-only.
-
-      Even when a mailbox is selected, it is not required to send a
-      CLOSE command before a SELECT, EXAMINE, or LOGOUT command.  The
-      SELECT, EXAMINE, and LOGOUT commands implicitly close the
-      currently selected mailbox without doing an expunge.  However,
-
-
-
-Crispin                                                        [Page 24]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-      when many messages are deleted, a CLOSE-LOGOUT or CLOSE-SELECT
-      sequence is considerably faster than an EXPUNGE-LOGOUT or
-      EXPUNGE-SELECT because no untagged EXPUNGE responses (which the
-      client would probably ignore) are sent.
-
-   Example:    C: A341 CLOSE
-               S: A341 OK CLOSE completed
-
-
-6.4.3.  EXPUNGE Command
-
-   Arguments:  none
-
-   Data:       untagged responses: EXPUNGE
-
-   Result:     OK - expunge completed
-               NO - expunge failure: can't expunge (e.g. permission
-                    denied)
-               BAD - command unknown or arguments invalid
-
-      The EXPUNGE command permanently removes from the currently
-      selected mailbox all messages that have the \Deleted flag set.
-      Before returning an OK to the client, an untagged EXPUNGE response
-      is sent for each message that is removed.
-
-   Example:    C: A202 EXPUNGE
-               S: * 3 EXPUNGE
-               S: * 3 EXPUNGE
-               S: * 5 EXPUNGE
-               S: * 8 EXPUNGE
-               S: A202 OK EXPUNGE completed
-
-        Note: in this example, messages 3, 4, 7, and 11 had the
-        \Deleted flag set.  See the description of the EXPUNGE
-        response for further explanation.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin                                                        [Page 25]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-6.4.4.  SEARCH Command
-
-   Arguments:  optional character set specification
-               searching criteria (one or more)
-
-   Data:       mandatory untagged response: SEARCH
-
-   Result:     OK - search completed
-               NO - search error: can't search that character set or
-                    criteria
-               BAD - command unknown or arguments invalid
-
-      The SEARCH command searches the mailbox for messages that match
-      the given searching criteria.  Searching criteria consist of one
-      or more search keys.  The untagged SEARCH response from the server
-      contains a listing of message sequence numbers corresponding to
-      those messages that match the searching criteria.
-
-      When multiple keys are specified, the result is the intersection
-      (AND function) of all the messages that match those keys.  For
-      example, the criteria DELETED FROM "SMITH" SINCE 1-Feb-1994 refers
-      to all deleted messages from Smith that were placed in the mailbox
-      since February 1, 1994.  A search key may also be a parenthesized
-      list of one or more search keys (e.g. for use with the OR and NOT
-      keys).
-
-      Server implementations MAY exclude [MIME-1] body parts with
-      terminal content types other than TEXT and MESSAGE from
-      consideration in SEARCH matching.
-
-      The optional character set specification consists of the word
-      "CHARSET" followed by a registered MIME character set.  It
-      indicates the character set of the strings that appear in the
-      search criteria.  [MIME-2] strings that appear in RFC 822/MIME
-      message headers, and [MIME-1] content transfer encodings, MUST be
-      decoded before matching.  Except for US-ASCII, it is not required
-      that any particular character set be supported.  If the server
-      does not support the specified character set, it MUST return a
-      tagged NO response (not a BAD).
-
-      In all search keys that use strings, a message matches the key if
-      the string is a substring of the field.  The matching is
-      case-insensitive.
-
-
-
-
-
-
-
-
-Crispin                                                        [Page 26]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-      The defined search keys are as follows.  Refer to the Formal
-      Syntax section for the precise syntactic definitions of the
-      arguments.
-
-      <message set>  Messages with message sequence numbers
-                     corresponding to the specified message sequence
-                     number set
-
-      ALL            All messages in the mailbox; the default initial
-                     key for ANDing.
-
-      ANSWERED       Messages with the \Answered flag set.
-
-      BCC <string>   Messages that contain the specified string in the
-                     envelope structure's BCC field.
-
-      BEFORE <date>  Messages whose internal date is earlier than the
-                     specified date.
-
-      BODY <string>  Messages that contain the specified string in the
-                     body of the message.
-
-      CC <string>    Messages that contain the specified string in the
-                     envelope structure's CC field.
-
-      DELETED        Messages with the \Deleted flag set.
-
-      DRAFT          Messages with the \Draft flag set.
-
-      FLAGGED        Messages with the \Flagged flag set.
-
-      FROM <string>  Messages that contain the specified string in the
-                     envelope structure's FROM field.
-
-      HEADER <field-name> <string>
-                     Messages that have a header with the specified
-                     field-name (as defined in [RFC-822]) and that
-                     contains the specified string in the [RFC-822]
-                     field-body.
-
-      KEYWORD <flag> Messages with the specified keyword set.
-
-      LARGER <n>     Messages with an RFC822.SIZE larger than the
-                     specified number of octets.
-
-      NEW            Messages that have the \Recent flag set but not the
-                     \Seen flag.  This is functionally equivalent to
-                     "(RECENT UNSEEN)".
-
-
-
-Crispin                                                        [Page 27]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-      NOT <search-key>
-                     Messages that do not match the specified search
-                     key.
-
-      OLD            Messages that do not have the \Recent flag set.
-                     This is functionally equivalent to "NOT RECENT" (as
-                     opposed to "NOT NEW").
-
-      ON <date>      Messages whose internal date is within the
-                     specified date.
-
-      OR <search-key1> <search-key2>
-                     Messages that match either search key.
-
-      RECENT         Messages that have the \Recent flag set.
-
-      SEEN           Messages that have the \Seen flag set.
-
-      SENTBEFORE <date>
-                     Messages whose [RFC-822] Date: header is earlier
-                     than the specified date.
-
-      SENTON <date>  Messages whose [RFC-822] Date: header is within the
-                     specified date.
-
-      SENTSINCE <date>
-                     Messages whose [RFC-822] Date: header is within or
-                     later than the specified date.
-
-      SINCE <date>   Messages whose internal date is within or later
-                     than the specified date.
-
-      SMALLER <n>    Messages with an RFC822.SIZE smaller than the
-                     specified number of octets.
-
-      SUBJECT <string>
-                     Messages that contain the specified string in the
-                     envelope structure's SUBJECT field.
-
-      TEXT <string>  Messages that contain the specified string in the
-                     header or body of the message.
-
-      TO <string>    Messages that contain the specified string in the
-                     envelope structure's TO field.
-
-      UID <message set>
-                     Messages with unique identifiers corresponding to
-                     the specified unique identifier set.
-
-
-
-Crispin                                                        [Page 28]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-      UNANSWERED     Messages that do not have the \Answered flag set.
-
-      UNDELETED      Messages that do not have the \Deleted flag set.
-
-      UNDRAFT        Messages that do not have the \Draft flag set.
-
-      UNFLAGGED      Messages that do not have the \Flagged flag set.
-
-      UNKEYWORD <flag>
-                     Messages that do not have the specified keyword
-                     set.
-
-      UNSEEN         Messages that do not have the \Seen flag set.
-
-
-   Example:    C: A282 SEARCH FLAGGED SINCE 1-Feb-1994 NOT FROM "Smith"
-               S: * SEARCH 2 84 882
-               S: A282 OK SEARCH completed
-
-
-6.4.5.  FETCH Command
-
-   Arguments:  message set
-               message data item names
-
-   Data:       untagged responses: FETCH
-
-   Result:     OK - fetch completed
-               NO - fetch error: can't fetch that data
-               BAD - command unknown or arguments invalid
-
-      The FETCH command retrieves data associated with a message in the
-      mailbox.  The data items to be fetched may be either a single atom
-      or a parenthesized list.  The currently defined data items that
-      can be fetched are:
-
-      ALL            Macro equivalent to: (FLAGS INTERNALDATE
-                     RFC822.SIZE ENVELOPE)
-
-      BODY           Non-extensible form of BODYSTRUCTURE.
-
-      BODY[<section>]
-                     The text of a particular body section.  The section
-                     specification is a set of one or more part numbers
-                     delimited by periods.
-
-                     Single-part messages only have a part 1.
-
-
-
-
-Crispin                                                        [Page 29]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-                     Multipart messages are assigned consecutive part
-                     numbers, as they occur in the message.  If a
-                     particular part is of type message or multipart,
-                     its parts must be indicated by a period followed by
-                     the part number within that nested multipart part.
-                     It is not permitted to fetch a multipart part
-                     itself, only its individual members.
-
-                     A part of type MESSAGE and subtype RFC822 also has
-                     nested parts.  These are the parts of the MESSAGE
-                     part's body.  Nested part 0 of a part of type
-                     MESSAGE and subtype RFC822 is the [RFC-822] header
-                     of the message.
-
-                     Every message has at least one part.
-
-                          Here is an example of a complex message
-                          with its associated section
-                          specifications:
-
-                           0   ([RFC-822] header of the message)
-                               MULTIPART/MIXED
-                           1   TEXT/PLAIN
-                           2   APPLICATION/OCTET-STREAM
-                           3   MESSAGE/RFC822
-                           3.0   ([RFC-822] header of the message)
-                           3.1   TEXT/PLAIN
-                           3.2   APPLICATION/OCTET-STREAM
-                                 MULTIPART/MIXED
-                           4.1   IMAGE/GIF
-                           4.2   MESSAGE/RFC822
-                           4.2.0   ([RFC-822] header of the message)
-                           4.2.1   TEXT/PLAIN
-                                   MULTIPART/ALTERNATIVE
-                           4.2.2.1  TEXT/PLAIN
-                           4.2.2.2  TEXT/RICHTEXT
-
-                          Note that there is no section
-                          specification for the Multi-part parts
-                          (no section 4 or 4.2.2).
-
-                     The \Seen flag is implicitly set; if this causes
-                     the flags to change they should be included as part
-                     of the fetch responses.
-
-      BODY.PEEK[<section>]
-                     An alternate form of BODY[section] that does not
-                     implicitly set the \Seen flag.
-
-
-
-Crispin                                                        [Page 30]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-      BODYSTRUCTURE  The [MIME-1] body structure of the message.  This
-                     is computed by the server by parsing the [MIME-1]
-                     header lines.
-
-      ENVELOPE       The envelope structure of the message.  This is
-                     computed by the server by parsing the [RFC-822]
-                     header into the component parts, defaulting various
-                     fields as necessary.
-
-      FAST           Macro equivalent to: (FLAGS INTERNALDATE
-                     RFC822.SIZE)
-
-      FLAGS          The flags that are set for this message.
-
-      FULL           Macro equivalent to: (FLAGS INTERNALDATE
-                     RFC822.SIZE ENVELOPE BODY)
-
-      INTERNALDATE   The date and time of final delivery of the message
-                     as defined by RFC 821.
-
-      RFC822         The message in [RFC-822] format.  The \Seen flag is
-                     implicitly set; if this causes the flags to change
-                     they should be included as part of the fetch
-                     responses.  This is the concatenation of
-                     RFC822.HEADER and RFC822.TEXT.
-
-      RFC822.PEEK    An alternate form of RFC822 that does not
-                     implicitly set the \Seen flag.
-
-      RFC822.HEADER  The [RFC-822] format header of the message as
-                     stored on the server including the delimiting blank
-                     line between the header and the body.
-
-      RFC822.HEADER.LINES <header_list>
-                     All header lines (including continuation lines) of
-                     the [RFC-822] format header of the message with a
-                     field-name (as defined in [RFC-822]) that matches
-                     any of the strings in header_list.  The matching is
-                     case-insensitive but otherwise exact.  The
-                     delimiting blank line between the header and the
-                     body is always included.
-
-
-
-
-
-
-
-
-
-
-Crispin                                                        [Page 31]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-      RFC822.HEADER.LINES.NOT <header_list>
-                     All header lines (including continuation lines) of
-                     the [RFC-822] format header of the message with a
-                     field-name (as defined in [RFC-822]) that does not
-                     match any of the strings in header_list.  The
-                     matching is case-insensitive but otherwise exact.
-                     The delimiting blank line between the header and
-                     the body is always included.
-
-      RFC822.SIZE    The number of octets in the message, as expressed
-                     in [RFC-822] format.
-
-      RFC822.TEXT    The text body of the message, omitting the
-                     [RFC-822] header.  The \Seen flag is implicitly
-                     set; if this causes the flags to change they should
-                     be included as part of the fetch responses.
-
-      RFC822.TEXT.PEEK
-                     An alternate form of RFC822.TEXT that does not
-                     implicitly set the \Seen flag.
-
-      UID            The unique identifier for the message.
-
-
-   Example:    C: A654 FETCH 2:4 (FLAGS RFC822.HEADER.LINES (DATE FROM))
-               S: * 2 FETCH ....
-               S: * 3 FETCH ....
-               S: * 4 FETCH ....
-               S: A003 OK FETCH completed
-
-
-6.4.6.  PARTIAL Command
-
-   Arguments:  message sequence number
-               message data item name
-               position of first octet
-               number of octets
-
-   Data:       untagged responses: FETCH
-
-   Result:     OK - partial completed
-               NO - partial error: can't fetch that data
-               BAD - command unknown or arguments invalid
-
-      The PARTIAL command is equivalent to the associated FETCH command,
-      with the added functionality that only the specified number of
-      octets, beginning at the specified starting octet, are returned.
-      Only a single message can be fetched at a time.  The first octet
-
-
-
-Crispin                                                        [Page 32]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-      of a message, and hence the minimum for the starting octet, is
-      octet 1.
-
-      The following FETCH items are valid data for PARTIAL: RFC822,
-      RFC822.HEADER, RFC822.TEXT, BODY[section], as well as any .PEEK
-      forms of these.
-
-      Any partial fetch that attempts to read beyond the end of the text
-      is truncated as appropriate.  If the starting octet is beyond the
-      end of the text, an empty string is returned.
-
-      The data are returned with the FETCH response.  There is no
-      indication of the range of the partial data in this response.  It
-      is not possible to stream multiple PARTIAL commands of the same
-      data item without processing and synchronizing at each step, since
-      streamed commands may be executed out of order.
-
-      There is no requirement that partial fetches follow any sequence.
-      For example, if a partial fetch of octets 1 through 10000 breaks
-      in an awkward place for BASE64 decoding, it is permitted to
-      continue with a partial fetch of 9987 through 19987, etc.
-
-      The handling of the \Seen flag is the same as in the associated
-      FETCH command.
-
-   Example:    C: A005 PARTIAL 4 RFC822 1 1024
-               S: * 1 FETCH (RFC822 {1024}
-               S: Return-Path: <gray@cac.washington.edu>
-               S: ...
-               S: .........  FLAGS (\Seen))
-               S: A005 OK PARTIAL completed
-
-
-6.4.7.  STORE Command
-
-   Arguments:  message set
-               message data item name
-               value for message data item
-
-   Data:       untagged responses: FETCH
-
-   Result:     OK - store completed
-               NO - store error: can't store that data
-               BAD - command unknown or arguments invalid
-
-      The STORE command alters data associated with a message in the
-      mailbox.  Normally, STORE will return the updated value of the
-      data with an untagged FETCH response.  A suffix of ".SILENT" in
-
-
-
-Crispin                                                        [Page 33]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-      the data item name prevents the untagged FETCH, and the server
-      should assume that the client has determined the updated value
-      itself or does not care about the updated value.
-
-      The currently defined data items that can be stored are:
-
-      FLAGS <flag list>
-                     Replace the flags for the message with the
-                     argument.  The new value of the flags are returned
-                     as if a FETCH of those flags was done.
-
-      FLAGS.SILENT <flag list>
-                     Equivalent to FLAGS, but without returning a new
-                     value.
-
-      +FLAGS <flag list>
-                     Add the argument to the flags for the message.  The
-                     new value of the flags are returned as if a FETCH
-                     of those flags was done.
-
-      +FLAGS.SILENT <flag list>
-                     Equivalent to +FLAGS, but without returning a new
-                     value.
-
-      -FLAGS <flag list>
-                     Remove the argument from the flags for the message.
-                     The new value of the flags are returned as if a
-                     FETCH of those flags was done.
-
-      -FLAGS.SILENT <flag list>
-                     Equivalent to -FLAGS, but without returning a new
-                     value.
-
-
-   Example:    C: A003 STORE 2:4 +FLAGS (\Deleted)
-               S: * 2 FETCH FLAGS (\Deleted \Seen)
-               S: * 3 FETCH FLAGS (\Deleted)
-               S: * 4 FETCH FLAGS (\Deleted \Flagged \Seen)
-               S: A003 OK STORE completed
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin                                                        [Page 34]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-6.4.8.  COPY Command
-
-   Arguments:  message set
-               mailbox name
-
-   Data:       no specific data for this command
-
-   Result:     OK - copy completed
-               NO - copy error: can't copy those messages or to that
-                    name
-               BAD - command unknown or arguments invalid
-
-      The COPY command copies the specified message(s) to the specified
-      destination mailbox.  The flags and internal date of the
-      message(s) SHOULD be preserved in the copy.
-
-      If the destination mailbox does not exist, a server SHOULD return
-      an error.  It SHOULD NOT automatically create the mailbox.  Unless
-      it is certain that the destination mailbox can not be created, the
-      server MUST send the response code "[TRYCREATE]" as the prefix of
-      the text of the tagged NO response.  This gives a hint to the
-      client that it can attempt a CREATE command and retry the COPY if
-      the CREATE is successful.
-
-      If the COPY command is unsuccessful for any reason, server
-      implementations MUST restore the destination mailbox to its state
-      before the COPY attempt.
-
-   Example:    C: A003 COPY 2:4 MEETING
-               S: A003 OK COPY completed
-
-
-6.4.9.  UID Command
-
-   Arguments:  command name
-               command arguments
-
-   Data:       untagged responses: FETCH, SEARCH
-
-   Result:     OK - UID command completed
-               NO - UID command error
-               BAD - command unknown or arguments invalid
-
-      The UID command has two forms.  In the first form, it takes as its
-      arguments a COPY, FETCH, or STORE command with arguments
-      appropriate for the associated command.  However, the numbers in
-      the message set argument are unique identifiers instead of message
-      sequence numbers.
-
-
-
-Crispin                                                        [Page 35]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-      In the second form, the UID command takes a SEARCH command with
-      SEARCH command arguments.  The interpretation of the arguments is
-      the same as with SEARCH; however, the numbers returned in a SEARCH
-      response for a UID SEARCH command are unique identifiers instead
-      of message sequence numbers.  For example, the command UID SEARCH
-      1:100 UID 443:557 returns the unique identifiers corresponding to
-      the intersection of the message sequence number set 1:100 and the
-      UID set 443:557.
-
-      A unique identifier of a message is a number, and is guaranteed
-      not to refer to any other message in the mailbox.  Unique
-      identifiers are assigned in a strictly ascending fashion for each
-      message added to the mailbox.  Unlike message sequence numbers,
-      unique identifiers persist across sessions.  This permits a client
-      to resynchronize its state from a previous session with the server
-      (e.g.  disconnected or offline access clients); this is discussed
-      further in [IMAP-DISC].
-
-      Associated with every mailbox is a unique identifier validity
-      value, which is sent in an UIDVALIDITY response code in an OK
-      untagged response at message selection time.  If unique
-      identifiers from an earlier session fail to persist to this
-      session, the unique identifier validity value MUST be greater than
-      in the earlier session.
-
-           Note: An example of a good value to use for the unique
-           identifier validity value would be a 32-bit
-           representation of the creation date/time of the mailbox.
-           It is alright to use a constant such as 1, but only if
-           it guaranteed that unique identifers will never be
-           reused, even in the case of a mailbox being deleted and
-           a new mailbox by the same name created at some future
-           time.
-
-
-      Message set ranges are permitted; however, there is no guarantee
-      that unique identifiers be contiguous.  A non-existent unique
-      identifier within a message set range is ignored without any error
-      message generated.
-
-      The number after the "*" in an untagged FETCH response is always a
-      message sequence number, not a unique identifier, even for a UID
-      command response.  However, server implementations MUST implicitly
-      include the UID message data item as part of any FETCH response
-      caused by a UID command, regardless of whether UID was specified
-      as a message data item to the FETCH.
-
-
-
-
-
-Crispin                                                        [Page 36]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-   Example:    C: A003 UID FETCH 4827313:4828442 FLAGS
-               S: * 23 FETCH (FLAGS (\Seen) UID 4827313)
-               S: * 24 FETCH (FLAGS (\Seen) UID 4827943)
-               S: * 25 FETCH (FLAGS (\Seen) UID 4828442)
-               S: A999 UID FETCH completed
-
-
-
-6.5.    Client Commands - Experimental/Expansion
-
-
-6.5.1.  X<atom> Command
-
-   Arguments:  implementation defined
-
-   Data:       implementation defined
-
-   Result:     OK - command completed
-               NO - failure
-               BAD - command unknown or arguments invalid
-
-      Any command prefixed with an X is an experimental command.
-      Commands which are not part of this specification, or a standard
-      or standards-track revision of this specification, MUST use the X
-      prefix.
-
-      Any added untagged responses issued by an experimental command
-      MUST also be prefixed with an X.  Server implementations MUST NOT
-      send any such untagged responses, unless the client requested it
-      by issuing the associated experimental command.
-
-   Example:    C: a441 CAPABILITY
-               S: * CAPABILITY IMAP4 XPIG-LATIN
-               S: a441 OK CAPABILITY completed
-               C: A442 XPIG-LATIN
-               S: * XPIG-LATIN ow-nay eaking-spay ig-pay atin-lay
-               S: A442 OK XPIG-LATIN ompleted-cay
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin                                                        [Page 37]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-7.      Server Responses
-
-   Server responses are in three forms: status responses, server data,
-   and command continuation request.
-
-   Server response data, identified by "Data:" in the response
-   descriptions below, are described by function, not by syntax.  The
-   precise syntax of server response data is described in the Formal
-   Syntax section.
-
-   The client MUST be prepared to accept any response at all times.
-
-   Status responses that are tagged indicate the completion result of a
-   client command, and have a tag matching the command.
-
-   Some status responses, and all server data, are untagged.  An
-   untagged response is indicated by the token "*" instead of a tag.
-   Untagged status responses indicate server greeting, or server status
-   that does not indicate the completion of a command.  For historical
-   reasons, untagged server data responses are also called "unsolicited
-   data", although strictly speaking only unilateral server data is
-   truly "unsolicited".
-
-   Certain server data MUST be recorded by the client when it is
-   received; this is noted in the description of that data.  Such data
-   conveys critical information which affects the interpretation of all
-   subsequent commands and responses (e.g. updates reflecting the
-   creation or destruction of messags).
-
-   Other server data SHOULD be recorded for later reference; if the
-   client does not need to record the data, or if recording the data has
-   no obvious purpose (e.g. a SEARCH response when no SEARCH command is
-   in progress), the data SHOULD be ignored.
-
-   An example of unilateral untagged responses occurs when the IMAP
-   connection is in selected state.  In selected state, the server
-   checks the mailbox for new messages as part of the execution of each
-   command.  If new messages are found, the server sends untagged EXISTS
-   and RECENT responses reflecting the new size of the mailbox.  Server
-   implementations that offer multiple simultaneous access to the same
-   mailbox should also send appropriate unilateral untagged FETCH and
-   EXPUNGE responses if another agent changes the state of any message
-   flags or expunges any messages.
-
-   Command continuation request responses use the token "+" instead of a
-   tag.  These responses are sent by the server to indicate acceptance
-   of an incomplete client command and readiness for the remainder of
-   the command.
-
-
-
-Crispin                                                        [Page 38]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-7.1.    Server Responses - Status Responses
-
-   Status responses may include an optional response code.  A response
-   code consists of data inside square brackets in the form of an atom,
-   possibly followed by a space and arguments.  The response code
-   contains additional information or status codes for client software
-   beyond the OK/NO/BAD condition, and are defined when there is a
-   specific action that a client can take based upon the additional
-   information.
-
-   The currently defined response codes are:
-
-      ALERT          The human-readable text contains a special alert
-                     that MUST be presented to the user in a fashion
-                     that calls the user's attention to the message.
-
-      PARSE          The human-readable text represents an error in
-                     parsing the [RFC-822] or [MIME-1] headers of a
-                     message in the mailbox.
-
-      PERMANENTFLAGS Followed by a parenthesized list of flags,
-                     indicates which of the known flags that the client
-                     may change permanently.  Any flags that are in the
-                     FLAGS untagged response, but not the PERMANENTFLAGS
-                     list, can not be set permanently.  If the client
-                     attempts to STORE a flag that is not in the
-                     PERMANENTFLAGS list, the server will either reject
-                     it with a NO reply or store the state for the
-                     remainder of the current session only.  The
-                     PERMANENTFLAGS list may also include the special
-                     flag \*, which indicates that it is possible to
-                     create new keywords by attempting to store those
-                     flags in the mailbox.
-
-      READ-ONLY      The mailbox is selected read-only, or its access
-                     while selected has changed from read-write to
-                     read-only.
-
-      READ-WRITE     The mailbox is selected read-write, or its access
-                     while selected has changed from read-only to
-                     read-write.
-
-      TRYCREATE      An APPEND or COPY attempt is failing because the
-                     target mailbox does not exist (as opposed to some
-                     other reason).  This is a hint to the client that
-                     the operation may succeed if the mailbox is first
-                     created by the CREATE command.
-
-
-
-
-Crispin                                                        [Page 39]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-      UIDVALIDITY    Followed by a decimal number, indicates the unique
-                     identifier validity value.  See the description of
-                     the UID command for more detail.
-
-      UNSEEN         Followed by a decimal number, indicates the number
-                     of the first message without the \Seen flag set.
-
-      Additional response codes defined by particular client or server
-      implementations should be prefixed with an "X" until they are
-      added to a revision of this protocol.  Client implementations
-      should ignore response codes that they do not recognize.
-
-
-7.1.1.  OK Response
-
-   Data:       optional response code
-               human-readable text
-
-      The OK response indicates an information message from the server.
-      When tagged, it indicates successful completion of the associated
-      command.  The human-readable text may be presented to the user as
-      an information message.  The untagged form indicates an
-      information-only message; the nature of the information may be
-      indicated by a response code.
-
-      The untagged form is also used as one of three possible greetings
-      at session startup.  It indicates that the session is not yet
-      authenticated and that a LOGIN command is needed.
-
-   Example:    S: * OK IMAP4 server ready
-               C: A001 LOGIN fred blurdybloop
-               S: * OK [ALERT] System shutdown in 10 minutes
-               S: A001 OK LOGIN Completed
-
-
-7.1.2.  NO Response
-
-   Data:       optional response code
-               human-readable text
-
-      The NO response indicates an operational error message from the
-      server.  When tagged, it indicates unsuccessful completion of the
-      associated command.  The untagged form indicates a warning; the
-      command may still complete successfully.  The human-readable text
-      describes the condition.
-
-
-
-
-
-
-Crispin                                                        [Page 40]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-   Example:    C: A222 COPY 1:2 owatagusiam
-               S: * NO Disk is 98% full, please delete unnecessary data
-               S: A222 OK COPY completed
-               C: A222 COPY 3:200 blurdybloop
-               S: * NO Disk is 98% full, please delete unnecessary data
-               S: * NO Disk is 99% full, please delete unnecessary data
-               S: A222 NO COPY failed: disk is full
-
-
-7.1.3.  BAD Response
-
-   Data:       optional response code
-               human-readable text
-
-      The BAD response indicates an error message from the server.  When
-      tagged, it reports a protocol-level error in the client's command;
-      the tag indicates the command that caused the error.  The untagged
-      form indicates a protocol-level error for which the associated
-      command can not be determined; it may also indicate an internal
-      server failure.  The human-readable text describes the condition.
-
-   Example:    C: ...very long command line...
-               S: * BAD Command line too long
-               C: ...empty line...
-               S: * BAD Empty command line
-               C: A443 EXPUNGE
-               S: * BAD Disk crash, attempting salvage to a new disk!
-               S: * OK Salvage successful, no data lost
-               S: A443 OK Expunge completed
-
-
-7.1.4.  PREAUTH Response
-
-   Data:       optional response code
-               human-readable text
-
-      The PREAUTH response is always untagged, and is one of three
-      possible greetings at session startup.  It indicates that the
-      session has already been authenticated by external means and thus
-      no LOGIN command is needed.
-
-   Example:    S: * PREAUTH IMAP4 server ready and logged in as Smith
-
-
-
-
-
-
-
-
-
-Crispin                                                        [Page 41]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-7.1.5.  BYE Response
-
-   Data:       optional response code
-               human-readable text
-
-      The BYE response is always untagged, and indicates that the server
-      is about to close the connection.  The human-readable text may be
-      displayed to the user in a status report by the client.  The BYE
-      response may be sent as part of a normal logout sequence, or as a
-      panic shutdown announcement by the server.  It is also used by
-      some server implementations as an announcement of an inactivity
-      autologout.
-
-      This response is also used as one of three possible greetings at
-      session startup.  It indicates that the server is not willing to
-      accept a session from this client.
-
-   Example:    S: * BYE Autologout; idle for too long
-
-
-
-7.2.    Server Responses - Server and Mailbox Status
-
-   These responses are always untagged.  This is how server data are
-   transmitted from the server to the client, often as a result of a
-   command with the same name.
-
-7.2.1.  CAPABILITY Response
-
-   Data:       capability listing
-
-      The CAPABILITY response occurs as a result of a CAPABILITY
-      command.  The capability listing contains a space-separated
-      listing of capability names that the server supports.  The first
-      name in the capability listing MUST be the atom "IMAP4".
-
-      A capability name other than IMAP4 indicates that the server
-      supports an extension, revision, or amendment to the IMAP4
-      protocol.  Server responses MUST conform to this document until
-      the client issues a command that uses the associated capability.
-
-      Capability names MUST either begin with "X" or be standard or
-      standards-track IMAP4 extensions, revisions, or amendments
-      registered with IANA.  A server MUST NOT offer unregistered or
-      non-standard capability names, unless such names are prefixed with
-      an "X".
-
-
-
-
-
-Crispin                                                        [Page 42]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-      Client implementations SHOULD NOT require any capability name
-      other than "IMAP4", and MUST ignore any unknown capability names.
-
-   Example:    S: * CAPABILITY IMAP4 XPIG-LATIN
-
-
-7.2.2.  LIST Response
-
-   Data:       name attributes
-               hierarchy delimiter
-               name
-
-      The LIST response occurs as a result of a LIST command.  It
-      returns a single name that matches the LIST specification.  There
-      may be multiple LIST responses for a single LIST command.
-
-      Four name attributes are defined:
-
-      \Noinferiors   It is not possible for any child levels of
-                     hierarchy to exist under this name; no child levels
-                     exist now and none can be created in the future.
-
-      \Noselect      It is not possible to use this name as a selectable
-                     mailbox.
-
-      \Marked        The mailbox has been marked "interesting" by the
-                     server; the mailbox probably contains messages that
-                     have been added since the last time the mailbox was
-                     selected.
-
-      \Unmarked      The mailbox does not contain any additional
-                     messages since the last time the mailbox was
-                     selected.
-
-      If it is not feasible for the server to determine whether the
-      mailbox is "interesting" or not, or if the name is a \Noselect
-      name, the server should not send either \Marked or \Unmarked.
-
-      The hierarchy delimiter is a character used to delimit levels of
-      hierarchy in a mailbox name.  A client may use it to create child
-      mailboxes, and to search higher or lower levels of naming
-      hierarchy.  All children of a top-level hierarchy node must use
-      the same separator character.  A NIL hierarchy delimiter means
-      that no hierarchy exists; the name is a "flat" name.
-
-
-
-
-
-
-
-Crispin                                                        [Page 43]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-      The name represents an unambiguous left-to-right hierarchy, and
-      MUST be valid for use as a reference in LIST and LSUB commands.
-      Unless \Noselect is indicated, the name must also be valid as an
-      argument for commands, such as SELECT, that accept mailbox names.
-
-   Example:    S: * LIST (\Noselect) "/" ~/Mail/foo
-
-
-7.2.3.  LSUB Response
-
-   Data:       name attributes
-               hierarchy delimiter
-               name
-
-      The LSUB response occurs as a result of an LSUB command.  It
-      returns a single name that matches the LSUB specification.  There
-      may be multiple LSUB responses for a single LSUB command.  The
-      data is identical in format to the LIST response.
-
-   Example:    S: * LSUB () "." #news.comp.mail.misc
-
-
-7.2.4.  SEARCH Response
-
-   Data:       zero or more numbers
-
-      The SEARCH response occurs as a result of a SEARCH or UID SEARCH
-      command.  The number(s) refer to those messages that match the
-      search criteria.  For SEARCH, these are message sequence numbers;
-      for UID SEARCH, these are unique identifiers.  Each number is
-      delimited by a space.
-
-   Example:    S: * SEARCH 2 3 6
-
-
-7.2.5.  FLAGS Response
-
-   Data:       flag parenthesized list
-
-      The FLAGS response occurs as a result of a SELECT or EXAMINE
-      command.  The flag parenthesized list identifies the flags (at a
-      minimum, the system-defined flags) that are applicable for this
-      mailbox.  Flags other than the system flags may also exist,
-      depending on server implementation.
-
-      The update from the FLAGS response MUST be recorded by the client.
-
-   Example:    S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
-
-
-
-Crispin                                                        [Page 44]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-7.3.    Server Responses - Message Status
-
-   These responses are always untagged.  This is how message data are
-   transmitted from the server to the client, often as a result of a
-   command with the same name.  Immediately following the "*" token is a
-   number that represents either a message sequence number or a message
-   count.
-
-7.3.1.  EXISTS Response
-
-   Data:       none
-
-      The EXISTS response reports the number of messages in the mailbox.
-      This response occurs as a result of a SELECT or EXAMINE command,
-      and if the size of the mailbox changes (e.g. new mail).
-
-      The update from the EXISTS response MUST be recorded by the
-      client.
-
-   Example:    S: * 23 EXISTS
-
-
-7.3.2.  RECENT Response
-
-   Data:       none
-
-      The RECENT response reports the number of messages that have
-      arrived since the previous time a SELECT command was done on this
-      mailbox.  This response occurs as a result of a SELECT or EXAMINE
-      command, and if the size of the mailbox changes (e.g. new mail).
-
-      The update from the RECENT response MUST be recorded by the
-      client.
-
-   Example:    S: * 5 RECENT
-
-
-7.3.3.  EXPUNGE Response
-
-   Data:       none
-
-      The EXPUNGE response reports that the specified message sequence
-      number has been permanently removed from the mailbox.  The message
-      sequence number for each successive message in the mailbox is
-      immediately decremented by 1, and this decrement is reflected in
-      message sequence numbers in subsequent responses (including other
-      untagged EXPUNGE responses).
-
-
-
-
-Crispin                                                        [Page 45]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-      As a result of the immediate decrement rule, message sequence
-      numbers that appear in a set of successive EXPUNGE responses
-      depend upon whether the messages are removed starting from lower
-      numbers to higher numbers, or from higher numbers to lower
-      numbers.  For example, if the last 5 messages in a 9-message
-      mailbox are expunged; a "lower to higher" server will send five
-      untagged EXPUNGE responses for message sequence number 5, whereas
-      a "higher to lower server" will send successive untagged EXPUNGE
-      responses for message sequence numbers 9, 8, 7, 6, and 5.
-
-      An EXPUNGE response MUST NOT be sent when no command is in
-      progress; nor while responding to a FETCH, STORE, or SEARCH
-      command.  This rule is necessary to prevent a loss of
-      synchronization of message sequence numbers between client and
-      server.
-
-      The update from the EXPUNGE response MUST be recorded by the
-      client.
-
-   Example:    S: * 44 EXPUNGE
-
-
-7.3.4.  FETCH Response
-
-   Data:       message data
-
-      The FETCH response returns data about a message to the client.
-      The data are pairs of data item names and their values in
-      parentheses.  This response occurs as the result of a FETCH or
-      STORE command, as well as by unilateral server decision (e.g. flag
-      updates).
-
-      The current data items are:
-
-      BODY           A form of BODYSTRUCTURE without extension data.
-
-      BODY[section]  A string expressing the body contents of the
-                     specified section.  The string should be
-                     interpreted by the client according to the content
-                     transfer encoding, body type, and subtype.
-
-                     8-bit textual data is permitted if a character set
-                     identifier is part of the body parameter
-                     parenthesized list for this section.
-
-                     Non-textual data such as binary data must be
-                     transfer encoded into a textual form such as BASE64
-                     prior to being sent to the client.  To derive the
-
-
-
-Crispin                                                        [Page 46]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-                     original binary data, the client must decode the
-                     transfer encoded string.
-
-      BODYSTRUCTURE  A parenthesized list that describes the body
-                     structure of a message.  This is computed by the
-                     server by parsing the [RFC-822] header and body
-                     into the component parts, defaulting various fields
-                     as necessary.
-
-                     Multiple parts are indicated by parenthesis
-                     nesting.  Instead of a body type as the first
-                     element of the parenthesized list there is a nested
-                     body.  The second element of the parenthesized list
-                     is the multipart subtype (mixed, digest, parallel,
-                     alternative, etc.).
-
-                     Extension data follows the multipart subtype.
-                     Extension data is never returned with the BODY
-                     fetch, but may be returned with a BODYSTRUCTURE
-                     fetch.  Extension data, if present, must be in the
-                     defined order.
-
-                     The extension data of a multipart body part are in
-                     the following order:
-
-                     body parameter parenthesized list
-                        A parenthesized list of attribute/value pairs
-                        [e.g. (foo bar baz rag) where "bar" is the value
-                        of "foo" and "rag" is the value of "baz"] as
-                        defined in [MIME-1].
-
-                     Any following extension data are not yet defined in
-                     this version of the protocol.  Such extension data
-                     may consist of zero or more NILs, strings, numbers,
-                     or potentially nested parenthesized lists of such
-                     data.  Client implementations that do a
-                     BODYSTRUCTURE fetch MUST be prepared to accept such
-                     extension data.  Server implementations MUST NOT
-                     send such extension data until it has been defined
-                     by a revision of this protocol.
-
-                     The basic fields of a non-multipart body part are
-                     in the following order:
-
-                     body type
-                        A string giving the content type name as defined
-                        in [MIME-1].
-
-
-
-
-Crispin                                                        [Page 47]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-                     body subtype
-                        A string giving the content subtype name as
-                        defined in [MIME-1].
-
-                     body parameter parenthesized list
-                        A parenthesized list of attribute/value pairs
-                        [e.g. (foo bar baz rag) where "bar" is the value
-                        of "foo" and "rag" is the value of "baz"] as
-                        defined in [MIME-1].
-
-                     body id
-                        A string giving the content id as defined in
-                        [MIME-1].
-
-                     body description
-                        A string giving the content description as
-                        defined in [MIME-1].
-
-                     body encoding
-                        A string giving the content transfer encoding as
-                        defined in [MIME-1].
-
-                     body size
-                        A number giving the size of the body in octets.
-                        Note that this size is the size in its transfer
-                        encoding and not the resulting size after any
-                        decoding.
-
-                     A body type of type MESSAGE and subtype RFC822
-                     contains, immediately after the basic fields, the
-                     envelope structure, body structure, and size in
-                     text lines of the encapsulated message.
-
-                     A body type of type TEXT contains, immediately
-                     after the basic fields, the size of the body in
-                     text lines.  Note that this size is the size in its
-                     transfer encoding and not the resulting size after
-                     any decoding.
-
-                     Extension data follows the basic fields and the
-                     type-specific fields listed above.  Extension data
-                     is never returned with the BODY fetch, but may be
-                     returned with a BODYSTRUCTURE fetch.  Extension
-                     data, if present, must be in the defined order.
-
-                     The extension data of a non-multipart body part are
-                     in the following order:
-
-
-
-
-Crispin                                                        [Page 48]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-                     body MD5
-                        A string giving the content MD5 value as defined
-                        in [MIME-1].
-
-                     Any following extension data are not yet defined in
-                     this version of the protocol, and would be as
-                     described above under multipart extension data.
-
-      ENVELOPE       A parenthesized list that describes the envelope
-                     structure of a message.  This is computed by the
-                     server by parsing the [RFC-822] header into the
-                     component parts, defaulting various fields as
-                     necessary.
-
-                     The fields of the envelope structure are in the
-                     following order: date, subject, from, sender,
-                     reply-to, to, cc, bcc, in-reply-to, and message-id.
-                     The date, subject, in-reply-to, and message-id
-                     fields are strings.  The from, sender, reply-to,
-                     to, cc, and bcc fields are parenthesized lists of
-                     address structures.
-
-                     An address structure is a parenthesized list that
-                     describes an electronic mail address.  The fields
-                     of an address structure are in the following order:
-                     personal name, [SMTP] at-domain-list (source
-                     route), mailbox name, and host name.
-
-                     [RFC-822] group syntax is indicated by a special
-                     form of address structure in which the host name
-                     field is NIL.  If the mailbox name field is also
-                     NIL, this is an end of group marker (semi-colon in
-                     RFC 822 syntax).  If the mailbox name field is
-                     non-NIL, this is a start of group marker, and the
-                     mailbox name field holds the group name phrase.
-
-                     Any field of an envelope or address structure that
-                     is not applicable is presented as NIL.  Note that
-                     the server must default the reply-to and sender
-                     fields from the from field; a client is not
-                     expected to know to do this.
-
-
-
-
-
-
-
-
-
-
-Crispin                                                        [Page 49]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-      FLAGS          A parenthesized list of flags that are set for this
-                     message.  This may include keywords as well as the
-                     following system flags:
-
-                     \Seen       Message has been read
-
-                     \Answered   Message has been answered
-
-                     \Flagged    Message is "flagged" for urgent/special
-                                 attention
-
-                     \Deleted    Message is "deleted" for removal by
-                                 later EXPUNGE
-
-                     \Draft      Message has not completed composition
-                                 (marked as a draft).
-
-                     as well as the following special flag, which may be
-                     fetched but not stored:
-
-                     \Recent     Message has arrived since the previous
-                                 time this mailbox was selected.
-
-      INTERNALDATE   A string containing the date and time of final
-                     delivery of the message as defined by [SMTP].
-
-      RFC822         A string expressing the message in [RFC-822]
-                     format.  The header portion of the message must be
-                     7-bit.  8-bit characters are permitted only in the
-                     non-header portion of the message only if there are
-                     [MIME-1] data in the message that identify the
-                     character set of the message.
-
-      RFC822.HEADER  A string expressing the [RFC-822] format header of
-                     the message, including the delimiting blank line
-                     between the header and the body.  The entire string
-                     must be 7-bit; 8-bit characters are not permitted
-                     in headers.  RFC822.HEADER is used to return data
-                     for the RFC822.HEADER, RFC822.HEADER.LINES, and
-                     RFC822.HEADER.LINES.NOT FETCH data items.  Note
-                     that a blank line is always included regardless of
-                     header line restrictions.
-
-      RFC822.SIZE    A number expressing the number of octets in the
-                     message in [RFC-822] format.
-
-
-
-
-
-
-Crispin                                                        [Page 50]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-      RFC822.TEXT    A string expressing the text body of the message,
-                     omitting the [RFC-822] header.  8-bit characters
-                     are permitted only if there are [MIME-1] data in
-                     the message that identify the character set of the
-                     message.
-
-      UID            A number expressing the unique identifier of the
-                     message.
-
-
-   Example:    S: * 23 FETCH (FLAGS (\Seen) RFC822.SIZE 44827)
-
-
-7.3.5.  Obsolete Responses
-
-   In addition to the responses listed in here, client implementations
-   MUST accept and implement the obsolete responses described in
-   Appendix B.
-
-
-
-7.4.    Server Responses - Command Continuation Request
-
-   The command completion request response is indicated by a "+" token
-   instead of a tag.  This form of response indicates that the server is
-   ready to accept the continuation of a command from the client.  The
-   remainder of this response is a line of text.
-
-   This response is used in the AUTHORIZATION command to transmit server
-   data to the client, and request additional client data.  This
-   response is also used if an argument to any command is a literal.
-
-   The client is not permitted to send the octets of the literal unless
-   the server indicates that it expects it.  This permits the server to
-   process commands and reject errors on a line-by-line basis.  The
-   remainder of the command, including the CRLF that terminates a
-   command, follows the octets of the literal.  If there are any
-   additional command arguments the literal octets are followed by a
-   space and those arguments.
-
-   Example:    C: A001 LOGIN {11}
-               S: + Ready for additional command text
-               C: FRED FOOBAR {7}
-               S: + Ready for additional command text
-               C: fat man
-               S: A001 OK LOGIN completed
-               C: A044 BLURDYBLOOP {102856}
-               S: A044 BAD No such command as "BLURDYBLOOP"
-
-
-
-Crispin                                                        [Page 51]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-8.      Sample IMAP4 session
-
-   The following is a transcript of an IMAP4 session.  A long line in
-   this sample is broken for editorial clarity.
-
-   S:   * OK IMAP4 Service Ready
-   C:   a001 login mrc secret
-   S:   a001 OK LOGIN completed
-   C:   a002 select inbox
-   S:   * 18 EXISTS
-   S:   * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
-   S:   * 2 RECENT
-   S:   * OK [UNSEEN 17] Message 17 is the first unseen message
-   S:   * OK [UIDVALIDITY 3857529045] UIDs valid
-   S:   a002 OK [READ-WRITE] SELECT completed
-   C:   a003 fetch 12 full
-   S:   * 12 FETCH (FLAGS (\Seen) INTERNALDATE "14-Jul-1993 02:44:25 -0700"
-         RFC822.SIZE 4282 ENVELOPE ("Wed, 14 Jul 1993 02:23:25 -0700 (PDT)"
-         "IMAP4 WG mtg summary and minutes"
-         (("Terry Gray" NIL "gray" "cac.washington.edu"))
-         (("Terry Gray" NIL "gray" "cac.washington.edu"))
-         (("Terry Gray" NIL "gray" "cac.washington.edu"))
-         ((NIL NIL "imap" "cac.washington.edu"))
-         ((NIL NIL "minutes" "CNRI.Reston.VA.US")
-         ("John Klensin" NIL "KLENSIN" "INFOODS.MIT.EDU")) NIL NIL
-         "<B27397-0100000@cac.washington.edu>")
-          BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 3028 92))
-   S:    a003 OK FETCH completed
-   C:    a004 fetch 12 rfc822.header
-   S:    * 12 FETCH (RFC822.HEADER {346}
-   S:    Date: Wed, 14 Jul 1993 02:23:25 -0700 (PDT)
-   S:    From: Terry Gray <gray@cac.washington.edu>
-   S:    Subject: IMAP4 WG mtg summary and minutes
-   S:    To: imap@cac.washington.edu
-   S:    cc: minutes@CNRI.Reston.VA.US, John Klensin <KLENSIN@INFOODS.MIT.EDU>
-   S:    Message-Id: <B27397-0100000@cac.washington.edu>
-   S:    MIME-Version: 1.0
-   S:    Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
-   S:
-   S:    )
-   S:    a004 OK FETCH completed
-   C:    a005 store 12 +flags \deleted
-   S:    * 12 FETCH (FLAGS (\Seen \Deleted))
-   S:    a005 OK +FLAGS completed
-   C:    a006 logout
-   S:    * BYE IMAP4 server terminating connection
-   S:    a006 OK LOGOUT completed
-
-
-
-
-Crispin                                                        [Page 52]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-9.      Formal Syntax
-
-   The following syntax specification uses the augmented Backus-Naur
-   Form (BNF) notation as specified in [RFC-822] with one exception; the
-   delimiter used with the "#" construct is a single space (SPACE) and
-   not a comma.
-
-   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.
-
-   Syntax marked as obsolete may be encountered with implementations
-   written for an earlier version of this protocol (e.g. IMAP2).  New
-   implementations SHOULD accept obsolete syntax as input, but MUST NOT
-   otherwise use such syntax.
-
-   address         ::= "(" addr_name SPACE addr_adl SPACE addr_mailbox
-                       SPACE addr_host ")"
-
-   addr_adl        ::= nstring
-
-   addr_host       ::= nstring
-                       ;; NIL indicates [RFC-822] group syntax
-
-   addr_mailbox    ::= nstring
-                       ;; NIL indicates end of [RFC-822] group; if
-                       ;; non-NIL and addr_host is NIL, holds
-                       ;; [RFC-822] group name
-
-   addr_name       ::= nstring
-
-   alpha           ::= "A" / "B" / "C" / "D" / "E" / "F" / "G" / "H" /
-                       "I" / "J" / "K" / "L" / "M" / "N" / "O" / "P" /
-                       "Q" / "R" / "S" / "T" / "U" / "V" / "W" / "X" /
-                       "Y" / "Z" /
-                       "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" /
-                       "i" / "j" / "k" / "l" / "m" / "n" / "o" / "p" /
-                       "q" / "r" / "s" / "t" / "u" / "v" / "w" / "x" /
-                       "y" / "z" /
-                       ;; Case-sensitive
-
-   append          ::= "APPEND" SPACE mailbox [SPACE flag_list]
-                       [SPACE date_time] SPACE literal
-
-   astring         ::= atom / string
-
-
-
-
-
-Crispin                                                        [Page 53]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-   atom            ::= 1*ATOM_CHAR
-
-   ATOM_CHAR       ::= <any CHAR except atom_specials>
-
-   atom_specials   ::= "(" / ")" / "{" / SPACE / CTLs / list_wildcards /
-                       quoted_specials
-
-   authenticate    ::= "AUTHENTICATE" SPACE auth_type *(CRLF base64)
-
-   auth_type       ::= atom
-
-   base64          ::= *(4base64_char) [base64_terminal]
-
-   base64_char     ::= alpha / digit / "+" / "/"
-
-   base64_terminal ::= (2base64_char "==") / (3base64_char "=")
-
-   body            ::= "(" body_type_1part / body_type_mpart ")"
-
-   body_extension  ::= nstring / number / "(" 1#body_extension ")"
-                       ;; Future expansion.  Client implementations
-                       ;; MUST accept body_extension fields.  Server
-                       ;; implementations MUST NOT generate
-                       ;; body_extension fields except as defined by
-                       ;; future standard or standards-track
-                       ;; revisions of this specification.
-
-   body_ext_1part  ::= body_fld_md5 [SPACE 1#body_extension]
-                       ;; MUST NOT be returned on non-extensible
-                       ;; "BODY" fetch
-
-   body_ext_mpart  ::= body_fld_param [SPACE 1#body_extension]]
-                       ;; MUST NOT be returned on non-extensible
-                       ;; "BODY" fetch
-
-   body_fields     ::= body_fld_param SPACE body_fld_id SPACE
-                       body_fld_desc SPACE body_fld_enc SPACE
-                       body_fld_octets
-
-   body_fld_desc   ::= nstring
-
-   body_fld_enc    ::= (<"> ("7BIT" / "8BIT" / "BINARY" / "BASE64"/
-                       "QUOTED-PRINTABLE") <">) / string
-
-   body_fld_id     ::= nstring
-
-   body_fld_lines  ::= number
-
-
-
-
-Crispin                                                        [Page 54]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-   body_fld_md5    ::= nstring
-
-   body_fld_octets ::= number
-
-   body_fld_param  ::= "(" 1#(string string) ")" / nil
-
-   body_fld_subtyp ::= string
-
-   body_type_1part ::= (body_type_basic / body_type_msg / body_type_text)
-                       [SPACE body_ext_1part]
-
-   body_type_basic ::= (<"> ("APPLICATION" / "AUDIO" / "IMAGE" /
-                       "MESSAGE" / "VIDEO") <">) / string) SPACE
-                       body_fld_subtyp SPACE body_fields
-                       ;; MESSAGE subtype MUST NOT be "RFC822"
-
-   body_type_mpart ::= 1*body SPACE body_fld_subtyp
-                       [SPACE body_ext_mpart]
-
-   body_type_msg   ::= <"> "MESSAGE" <"> SPACE <"> "RFC822" <"> SPACE
-                       body_fields SPACE envelope SPACE body SPACE
-                       body_fld_lines
-
-   body_type_text  ::= <"> "TEXT" <"> SPACE body_fld_subtyp SPACE
-                        body_fields SPACE body_fld_lines
-
-   capability      ::= atom
-                       ;; Must begin with "X" or be registered with
-                       ;; IANA as standard or standards-track
-
-   capability_data ::= "CAPABILITY" SPACE "IMAP4" [SPACE 1#capability]
-
-   CHAR            ::= <any 7-bit US-ASCII character except NUL,
-                        0x01 - 0x7f>
-
-   CHAR8           ::= <any 8-bit octet except NUL, 0x01 - 0xff>
-
-   command         ::= tag SPACE (command_any / command_auth /
-                       command_nonauth / command_select) CRLF
-                       ;; Modal based on state
-
-   command_any     ::= "CAPABILITY" / "LOGOUT" / "NOOP" / x_command
-                       ;; Valid in all states
-
-   command_auth    ::= append / create / delete / examine / find / list /
-                       lsub / rename / select / subscribe / unsubscribe /
-                       ;; Valid only in Authenticated or Selected state
-
-
-
-
-Crispin                                                        [Page 55]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-   command_nonauth ::= login / authenticate
-                       ;; Valid only when in Non-Authenticated state
-
-   command_select  ::= "CHECK" / "CLOSE" / "EXPUNGE" /
-                        copy / fetch / partial / store / uid / search
-                       ;; Valid only when in Selected state
-
-   continue_req    ::= "+" SPACE (resp_text / base64)
-
-   copy            ::= "COPY" SPACE set SPACE mailbox
-
-   CR              ::= <ASCII CR, carriage return, 0x0C>
-
-   create          ::= "CREATE" SPACE mailbox
-                       ;; Use of INBOX gives a NO error
-
-   CRLF            ::= CR LF
-
-   CTL             ::= <any ASCII control character and DEL,
-                        0x00 - 0x1f, 0x7f>
-
-   date            ::= date_text / <"> date_text <">
-
-   date_day        ::= 1*2digit
-                       ;; Day of month
-
-   date_day_fixed  ::= (SPACE digit) / 2digit
-                       ;; Fixed-format version of date_day
-
-   date_month      ::= "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" /
-                       "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec"
-
-   date_text       ::= date_day "-" date_month "-" (date_year /
-                       date_year_old)
-
-   date_year       ::= 4digit
-
-   date_year_old   ::= 2digit
-                       ;; OBSOLETE, (year - 1900)
-
-   date_time       ::= <"> (date_time_new / date_time_old) <">
-
-   date_time_new   ::= date_day_fixed "-" date_month "-" date_year
-                       SPACE time SPACE zone
-
-   date_time_old   ::= date_day_fixed "-" date_month "-" date_year_old
-                       SPACE time "-" zone_old
-                       ;; OBSOLETE
-
-
-
-Crispin                                                        [Page 56]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-   delete          ::= "DELETE" SPACE mailbox
-                       ;; Use of INBOX gives a NO error
-
-   digit           ::= "0" / digit_nz
-
-   digit_nz        ::= "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" /
-                       "9"
-
-   envelope        ::= "(" env_date SPACE env_subject SPACE env_from
-                       SPACE env_sender SPACE env_reply-to SPACE env_to
-                       SPACE env_cc SPACE env_bcc SPACE env_in-reply-to
-                       SPACE env_message-id ")"
-
-   env_bcc         ::= "(" 1*address ")" / nil
-
-   env_cc          ::= "(" 1*address ")" / nil
-
-   env_date        ::= nstring
-
-   env_from        ::= "(" 1*address ")" / nil
-
-   env_in-reply-to ::= nstring
-
-   env_message-id  ::= nstring
-
-   env_reply-to    ::= "(" 1*address ")" / nil
-
-   env_sender      ::= "(" 1*address ")" / nil
-
-   env_subject     ::= nstring
-
-   env_to          ::= "(" 1*address ")" / nil
-
-   examine         ::= "EXAMINE" SPACE mailbox
-
-   fetch           ::= "FETCH" SPACE set SPACE ("ALL" / "FULL" /
-                       "FAST" / fetch_att / "(" 1#fetch_att ")")
-
-   fetch_att       ::= "BODY" / "BODYSTRUCTURE" /
-                       "BODY" [".PEEK"] "[" section "]" / "ENVELOPE" /
-                       "FLAGS" / "INTERNALDATE" / "UID" /
-                       "RFC822" (([".TEXT"] [".PEEK"]) / ".SIZE" /
-                       (".HEADER" [".LINES" [".NOT"] SPACE header_list])
-
-   find            ::= "FIND" SPACE ["ALL."] "MAILBOXES" SPACE
-                       list_mailbox
-                       ;; OBSOLETE
-
-
-
-
-Crispin                                                        [Page 57]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-   flag            ::= "\Answered" / "\Flagged" / "\Deleted" /
-                       "\Seen" / "\Draft" / flag_keyword  /
-                       flag_extension
-
-   flag_extension  ::= "\" atom
-                       ;; Future expansion.  Client implementations
-                       ;; MUST accept flag_extension flags.  Server
-                       ;; implementations MUST NOT generate
-                       ;; flag_extension flags except as defined by
-                       ;; future standard or standards-track
-                       ;; revisions of this specification.
-
-   flag_keyword    ::= atom
-
-   flag_list       ::= "(" #flag ")"
-
-   greeting        ::= "*" SPACE (resp_cond_auth / resp_cond_bye) CRLF
-
-   header_line     ::= astring
-
-   header_list     ::= "(" 1#header_line ")"
-
-   LF              ::= <ASCII LF, line feed, 0x0A>
-
-   list            ::= "LIST" SPACE mailbox SPACE list_mailbox
-
-   list_mailbox    ::= 1*(ATOM_CHAR / list_wildcards) / string
-
-   list_wildcards  ::= "%" / "*"
-
-   literal         ::= "{" number "}" CRLF *CHAR8
-                       ;; Number represents the number of CHAR8 octets
-
-   login           ::= "LOGIN" SPACE userid SPACE password
-
-   lsub            ::= "LSUB" SPACE mailbox SPACE list_mailbox
-
-   mailbox         ::= "INBOX" / astring
-                       ;; INBOX is case-insensitive; other names may be
-                       ;; case-sensitive depending on implementation.
-
-   mailbox_data    ::=  "FLAGS" SPACE flag_list /
-                        "LIST" SPACE mailbox_list /
-                        "LSUB" SPACE mailbox_list /
-                        "MAILBOX" SPACE text /
-                        "SEARCH" [SPACE 1#nz_number] /
-                        number SPACE "EXISTS" / number SPACE "RECENT"
-
-
-
-
-Crispin                                                        [Page 58]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-   mailbox_list    ::= "(" #("\Marked" / "\Noinferiors" /
-                       "\Noselect" / "\Unmarked" / flag_extension) ")"
-                       SPACE (<"> QUOTED_CHAR <"> / nil) SPACE mailbox
-
-   message_data    ::= nz_number SPACE ("EXPUNGE" /
-                       ("FETCH" SPACE msg_fetch) / msg_obsolete)
-
-   msg_fetch       ::= "(" 1#("BODY" SPACE body /
-                       "BODYSTRUCTURE" SPACE body /
-                       "BODY[" section "]" SPACE nstring /
-                       "ENVELOPE" SPACE envelope /
-                       "FLAGS" SPACE "(" #(flag / "\Recent") ")" /
-                       "INTERNALDATE" SPACE date_time /
-                       "RFC822" [".HEADER" / ".TEXT"] SPACE nstring /
-                       "RFC822.SIZE" SPACE number /
-                       "UID" SPACE uniqueid) ")"
-
-   msg_obsolete    ::= "COPY" / ("STORE" SPACE msg_fetch)
-                       ;; OBSOLETE untagged data responses
-
-   nil             ::= "NIL"
-
-   nstring         ::= string / nil
-
-   number          ::= 1*digit
-                       ;; Unsigned 32-bit integer
-                       ;; (0 <= n < 4,294,967,296)
-
-   nz_number       ::= digit_nz *digit
-                       ;; Non-zero unsigned 32-bit integer
-                       ;; (0 < n < 4,294,967,296)
-
-   partial         ::= "PARTIAL" SPACE nz_number SPACE
-                       ("BODY" [".PEEK"] "[" section "]" /
-                       "RFC822" (([".TEXT"] [".PEEK"]) / ".HEADER")
-                       SPACE number SPACE number
-
-   password        ::= astring
-
-   quoted          ::= <"> *QUOTED_CHAR <">
-
-   QUOTED_CHAR     ::= <any TEXT_CHAR except quoted_specials> /
-                       "\" quoted_specials
-
-   quoted_specials ::= <"> / "\"
-
-   rename          ::= "RENAME" SPACE mailbox SPACE mailbox
-                       ;; Use of INBOX as a destination gives a NO error
-
-
-
-Crispin                                                        [Page 59]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-   response        ::= *response_data response_done
-
-   response_data   ::= "*" SPACE (resp_cond_state / resp_cond_bye /
-                       mailbox_data / message_data / capability_data)
-                       CRLF
-
-   response_done   ::= response_tagged / response_fatal
-
-   response_fatal  ::= "*" SPACE resp_cond_bye CRLF
-
-   response_tagged ::= tag SPACE resp_cond_state CRLF
-
-   resp_cond_auth  ::= ("OK" / "PREAUTH") SPACE resp_text
-                       ;; Authentication condition
-
-   resp_cond_bye   ::= "BYE" SPACE resp_text
-                       ;; Server will disconnect condition
-
-   resp_cond_state ::= ("OK" / "NO" / "BAD") SPACE resp_text
-                       ;; Status condition
-
-   resp_text       ::= ["[" resp_text_code "]" SPACE] (text_mime2 / text)
-
-   resp_text_code  ::= "ALERT" / "PARSE" /
-                       "PERMANENTFLAGS" SPACE "(" #(flag / "\*") ")" /
-                       "READ-ONLY" / "READ-WRITE" / "TRYCREATE" /
-                       "UIDVALIDITY" SPACE nz_number /
-                       "UNSEEN" SPACE nz_number /
-                       atom [SPACE 1*<any TEXT_CHAR except "]">]
-
-   search          ::= "SEARCH" SPACE ["CHARSET" SPACE astring SPACE]
-                       search_criteria
-                       ;; Character set must be registered with IANA
-                       ;; as a MIME character set
-
-   search_criteria ::= 1#search_key
-
-   search_key      ::= search_new / search_old
-
-   search_new      ::= "DRAFT" /
-                       "HEADER" SPACE header_line SPACE astring /
-                       "LARGER" SPACE number / "NOT" SPACE search_key /
-                       "OR" SPACE search_key SPACE search_key /
-                       "SENTBEFORE" SPACE date / "SENTON" SPACE date /
-                       "SENTSINCE" SPACE date / "SMALLER" SPACE number /
-                       "UID" SPACE set / "UNDRAFT" / set /
-                       "(" search_criteria ")"
-                       ;; New in IMAP4
-
-
-
-Crispin                                                        [Page 60]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-   search_old      ::= "ALL" / "ANSWERED" / "BCC" SPACE astring /
-                       "BEFORE" SPACE date / "BODY" SPACE astring /
-                       "CC" SPACE astring / "DELETED" / "FLAGGED" /
-                       "FROM" SPACE astring /
-                       "KEYWORD" SPACE flag_keyword / "NEW" / "OLD" /
-                       "ON" SPACE date / "RECENT" / "SEEN" /
-                       "SINCE" SPACE date / "SUBJECT" SPACE astring /
-                       "TEXT" SPACE astring / "TO" SPACE astring /
-                       "UNANSWERED" / "UNDELETED" / "UNFLAGGED" /
-                       "UNKEYWORD" SPACE flag_keyword / "UNSEEN"
-                       ;; Defined in [IMAP2]
-
-   section         ::= "0" / nz_number ["." section]
-
-   select          ::= "SELECT" SPACE mailbox
-
-   sequence_num    ::= nz_number / "*"
-                       ;; * is the largest number in use.  For message
-                       ;; sequence numbers, it is the number of messages
-                       ;; in the mailbox.  For unique identifiers, it is
-                       ;; the unique identifier of the last message in
-                       ;; the mailbox.
-
-   set             ::= sequence_num / (sequence_num ":" sequence_num) /
-                       (set "," set)
-                       ;; Identifies a set of messages.  For message
-                       ;; sequence numbers, these are consecutive
-                       ;; numbers from 1 to the number of messages in
-                       ;; the mailbox
-                       ;; Comma delimits individual numbers, colon
-                       ;; delimits between two numbers inclusive.
-                       ;; Example: 2,4:7,9,12:* is 2,4,5,6,7,9,12,13,
-                       ;; 14,15 for a mailbox with 15 messages.
-
-   SPACE           ::= <ASCII SP, space, 0x20>
-
-   store           ::= "STORE" SPACE set SPACE store_att_flags
-
-   store_att_flags ::= (["+" / "-"] "FLAGS" [".SILENT"]) SPACE
-                       (flag_list / #flag)
-
-   string          ::= quoted / literal
-
-   subscribe       ::= ("SUBSCRIBE" SPACE mailbox) / subscribe_obs
-
-   subscribe_obs   ::= "SUBSCRIBE" SPACE "MAILBOX" SPACE mailbox
-                       ;;OBSOLETE
-
-
-
-
-Crispin                                                        [Page 61]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-   tag             ::= 1*<any ATOM_CHAR except "+">
-
-   text            ::= 1*TEXT_CHAR
-
-   text_mime2       ::= "=?" <charset> "?" <encoding> "?"
-                        <encoded-text> "?="
-                        ;; Syntax defined in [MIME-2]
-
-   TEXT_CHAR       ::= <any CHAR except CR and LF>
-
-   time            ::= 2digit ":" 2digit ":" 2digit
-                       ;; Hours minutes seconds
-
-   uid             ::= "UID" SPACE (copy / fetch / search / store)
-                       ;; Unique identifiers used instead of message
-                       ;; sequence numbers
-
-   uniqueid        ::= nz_number
-                       ;; Strictly ascending
-
-   unsubscribe     ::= ("UNSUBSCRIBE" SPACE mailbox) / unsubscribe_obs
-
-   unsubscribe_obs ::= "UNSUBSCRIBE" SPACE "MAILBOX" SPACE mailbox
-                       ;;OBSOLETE
-
-   userid          ::= astring
-
-   x_command       ::= "X" atom <experimental command arguments>
-
-   zone            ::= ("+" / "-") 4digit
-                       ;; Signed four-digit value of hhmm representing
-                       ;; hours and minutes west of Greenwich (that is,
-                       ;; (the amount that the given time differs from
-                       ;; Universal Time).  Subtracting the timezone
-                       ;; from the given time will give the UT form.
-                       ;; The Universal Time zone is "+0000".
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin                                                        [Page 62]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-   zone_old        ::= "UT" / "GMT" / "Z" /                ;; +0000
-                       "AST" / "EDT" /                     ;; -0400
-                       "EST" / "CDT" /                     ;; -0500
-                       "CST" / "MDT" /                     ;; -0600
-                       "MST" / "PDT" /                     ;; -0700
-                       "PST" / "YDT" /                     ;; -0800
-                       "YST" / "HDT" /                     ;; -0900
-                       "HST" / "BDT" /                     ;; -1000
-                       "BST" /                             ;; -1100
-                       "A" / "B" / "C" / "D" / "E" / "F" / ;; +1 to +6
-                       "G" / "H" / "I" / "K" / "L" / "M" / ;; +7 to +12
-                       "N" / "O" / "P" / "Q" / "R" / "S" / ;; -1 to -6
-                       "T" / "U" / "V" / "W" / "X" / "Y"   ;; -7 to -12
-                       ;; OBSOLETE
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin                                                        [Page 63]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-10.     Author's Note
-
-   This document is a revision or rewrite of earlier documents, and
-   supercedes the protocol specification in those documents: IMAP4
-   Internet drafts, the IMAP2bis Internet drafts, unpublished
-   IMAP2bis.TXT document, RFC 1176, and RFC 1064.
-
-
-11.     Security Considerations
-
-   IMAP4 protocol transactions, including electronic mail data, are sent
-   in the clear over the network unless the optional privacy protection
-   is negotiated in the AUTHENTICATE command.
-
-   A server error message for an AUTHENTICATE command which fails due to
-   invalid credentials should not detail why the credentials are
-   invalid.
-
-   Use of the LOGIN command sends passwords in the clear.  This can be
-   avoided by using the AUTHENTICATE command instead.
-
-   A server error message for a failing LOGIN command should not specify
-   that the user name, as opposed to the password, is invalid.
-
-   Additional security considerations are discussed in the section
-   discussing the AUTHENTICATE and LOGIN commands.
-
-
-12.     Author's Address
-
-   Mark R. Crispin
-   Networks and Distributed Computing, JE-30
-   University of Washington
-   Seattle, WA  98195
-
-   Phone: (206) 543-5762
-
-   EMail: MRC@CAC.Washington.EDU
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin                                                        [Page 64]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-Appendices
-
-A.      Obsolete Commands
-
-   The following commands are OBSOLETE.  It is NOT required to support
-   any of these commands in new server implementations.  These commands
-   are documented here for the benefit of implementors who may wish to
-   support them for compatibility with old client implementations.
-
-   The section headings of these commands are intended to correspond
-   with where they would be located in the main document if they were
-   not obsoleted.
-
-
-A.6.3.OBS.1.    FIND ALL.MAILBOXES Command
-
-   Arguments:  mailbox name with possible wildcards
-
-   Data:       untagged responses: MAILBOX
-
-   Result:     OK - find completed
-               NO - find failure: can't list that name
-               BAD - command unknown or arguments invalid
-
-      The FIND ALL.MAILBOXES command returns a subset of names from the
-      complete set of all names available to the user.  It returns zero
-      or more untagged MAILBOX replies.  The mailbox argument to FIND
-      ALL.MAILBOXES is similar to that for LIST with an empty reference,
-      except that the characters "%" and "?" match a single character.
-
-   Example:    C: A002 FIND ALL.MAILBOXES *
-               S: * MAILBOX blurdybloop
-               S: * MAILBOX INBOX
-               S: A002 OK FIND ALL.MAILBOXES completed
-
-
-A.6.3.OBS.2.    FIND MAILBOXES Command
-
-   Arguments:  mailbox name with possible wildcards
-
-   Data:       untagged responses: MAILBOX
-
-   Result:     OK - find completed
-               NO - find failure: can't list that name
-               BAD - command unknown or arguments invalid
-
-      The FIND MAILBOXES command returns a subset of names from the set
-      of names that the user has declared as being "active" or
-
-
-
-Crispin                                                        [Page 65]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-      "subscribed".  It returns zero or more untagged MAILBOX replies.
-      The mailbox argument to FIND MAILBOXES is similar to that for LSUB
-      with an empty reference, except that the characters "%" and "?"
-      match a single character.
-
-   Example:    C: A002 FIND MAILBOXES *
-               S: * MAILBOX blurdybloop
-               S: * MAILBOX INBOX
-               S: A002 OK FIND MAILBOXES completed
-
-
-A.6.3.OBS.3.    SUBSCRIBE MAILBOX Command
-
-   Arguments:  mailbox name
-
-   Data:       no specific data for this command
-
-   Result:     OK - subscribe completed
-               NO - subscribe failure: can't subscribe to that name
-               BAD - command unknown or arguments invalid
-
-      The SUBSCRIBE MAILBOX command is identical in effect to the
-      SUBSCRIBE command.  A server which implements this command must be
-      able to distinguish between a SUBSCRIBE MAILBOX command and a
-      SUBSCRIBE command with a mailbox name argument of "MAILBOX".
-
-   Example:    C: A002 SUBSCRIBE MAILBOX #news.comp.mail.mime
-               S: A002 OK SUBSCRIBE MAILBOX to #news.comp.mail.mime
-               completed
-               C: A003 SUBSCRIBE MAILBOX
-               S: A003 OK SUBSCRIBE to MAILBOX completed
-
-
-A.6.3.OBS.4.    UNSUBSCRIBE MAILBOX Command
-
-   Arguments:  mailbox name
-
-   Data:       no specific data for this command
-
-   Result:     OK - unsubscribe completed
-               NO - unsubscribe failure: can't unsubscribe that name
-               BAD - command unknown or arguments invalid
-
-      The UNSUBSCRIBE MAILBOX command is identical in effect to the
-      UNSUBSCRIBE command.  A server which implements this command must
-      be able to distinguish between a UNSUBSCRIBE MAILBOX command and
-      an UNSUBSCRIBE command with a mailbox name argument of "MAILBOX".
-
-
-
-
-Crispin                                                        [Page 66]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-   Example:    C: A002 UNSUBSCRIBE MAILBOX #news.comp.mail.mime
-               S: A002 OK UNSUBSCRIBE MAILBOX from #news.comp.mail.mime
-               completed
-               C: A003 UNSUBSCRIBE MAILBOX
-               S: A003 OK UNSUBSCRIBE from MAILBOX completed
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin                                                        [Page 67]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-B.      Obsolete Responses
-
-   The following responses are OBSOLETE.  Except as noted below, these
-   responses MUST NOT be transmitted by new server implementations.
-
-   The section headings of these responses are intended to correspond
-   with where they would be located in the main document if they were
-   not obsoleted.
-
-
-B.7.2.OBS.1.    MAILBOX Response
-
-   Data:       name
-
-      The MAILBOX response MUST NOT be transmitted by server
-      implementations except in response to the obsolete FIND MAILBOXES
-      and FIND ALL.MAILBOXES commands.  Client implementations that do
-      not use these commands MAY ignore this response.  It is documented
-      here for the benefit of implementors who may wish to support it
-      for compatibility with old client implementations.
-
-      This response occurs as a result of the FIND MAILBOXES and FIND
-      ALL.MAILBOXES commands.  It returns a single name that matches the
-      FIND specification.  There are no attributes or hierarchy
-      delimiter.
-
-   Example:    S: * MAILBOX blurdybloop
-
-
-B.7.3.OBS.1.    COPY Response
-
-   Data:       none
-
-      The COPY response MUST NOT be transmitted by new server
-      implementations.  Client implementations MUST ignore the COPY
-      response.  It is documented here for the benefit of client
-      implementors who may encounter this response from old server
-      implementations.
-
-      In some experimental versions of this protocol, this response was
-      returned in response to a COPY command to indicate on a
-      per-message basis that the message was copied successfully.
-
-   Example:    S: * 44 COPY
-
-
-
-
-
-
-
-Crispin                                                        [Page 68]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-B.7.3.OBS.2.    STORE Response
-
-   Data:       message data
-
-      The STORE response MUST NOT be transmitted by new server
-      implementations.  Client implementations MUST treat the STORE
-      response as equivalent to the FETCH response.  It is documented
-      here for the benefit of client implementors who may encounter this
-      response from old server implementations.
-
-      In some experimental versions of this protocol, this response was
-      returned instead of FETCH in response to a STORE command to report
-      the new value of the flags.
-
-   Example:    S: * 69 STORE (FLAGS (\Deleted))
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin                                                        [Page 69]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-C.      References
-
-
-   [IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanism", RFC 1731.
-   Carnegie-Mellon University, December 1994.
-
-   [IMAP-COMPAT] Crispin, M. "IMAP4 Compatibility with IMAP2 and
-   IMAP2bis", RFC 1732, University of Washington, December 1994.
-
-   [IMAP-DISC] Austein, R. "Synchronization Operations for Disconnected
-   IMAP4 Clients", Work in Progress.
-
-   [IMAP-MODEL] Crispin, M. "Distributed Electronic Mail Models in
-   IMAP4", RFC 1733, University of Washington, December 1994.
-
-   [IMAP-NAMING] Crispin, M. "Mailbox Naming Convention in IMAP4", Work
-   in Progress.
-
-   [IMAP2] Crispin, M., "Interactive Mail Access Protocol - Version 2",
-   RFC 1176, University of Washington, August 1990.
-
-   [IMSP] Myers, J. "IMSP -- Internet Message Support Protocol", Work in
-   Progress.
-
-   [MIME-1] Borenstein, N., and Freed, N., "MIME (Multipurpose Internet
-   Mail Extensions) Part One: Mechanisms for Specifying and Describing
-   the Format of Internet Message Bodies", RFC 1521, Bellcore, Innosoft,
-   September 1993.
-
-   [MIME-2] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
-   Part Two: Message Header Extensions for Non-ASCII Text", RFC 1522,
-   University of Tennessee, September 1993.
-
-   [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text
-   Messages", STD 11, RFC 822, University of Delaware, August 1982.
-
-   [SMTP] Postel, Jonathan B. "Simple Mail Transfer Protocol", STD 10,
-   RFC 821, USC/Information Sciences Institute, August 1982.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin                                                        [Page 70]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-E.      IMAP4 Keyword Index
-
-
-       +FLAGS <flag list> (store command data item) ...............   34
-       +FLAGS.SILENT <flag list> (store command data item) ........   34
-       -FLAGS <flag list> (store command data item) ...............   34
-       -FLAGS.SILENT <flag list> (store command data item) ........   34
-       ALERT (response code) ......................................   39
-       ALL (fetch item) ...........................................   29
-       ALL (search key) ...........................................   27
-       ANSWERED (search key) ......................................   27
-       APPEND (command) ...........................................   22
-       AUTHENTICATE (command) .....................................   12
-       BAD (response) .............................................   41
-       BCC <string> (search key) ..................................   27
-       BEFORE <date> (search key) .................................   27
-       BODY (fetch item) ..........................................   29
-       BODY (fetch result) ........................................   46
-       BODY <string> (search key) .................................   27
-       BODY.PEEK[<section>] (fetch item) ..........................   30
-       BODYSTRUCTURE (fetch item) .................................   31
-       BODYSTRUCTURE (fetch result) ...............................   47
-       BODY[<section>] (fetch item) ...............................   29
-       BODY[section] (fetch result) ...............................   46
-       BYE (response) .............................................   41
-       CAPABILITY (command) .......................................   10
-       CAPABILITY (response) ......................................   42
-       CC <string> (search key) ...................................   27
-       CHECK (command) ............................................   23
-       CLOSE (command) ............................................   24
-       COPY (command) .............................................   34
-       COPY (response) ............................................   68
-       CREATE (command) ...........................................   17
-       DELETE (command) ...........................................   18
-       DELETED (search key) .......................................   27
-       DRAFT (search key) .........................................   27
-       ENVELOPE (fetch item) ......................................   31
-       ENVELOPE (fetch result) ....................................   49
-       EXAMINE (command) ..........................................   16
-       EXISTS (response) ..........................................   45
-       EXPUNGE (command) ..........................................   25
-       EXPUNGE (response) .........................................   45
-       FAST (fetch item) ..........................................   31
-       FETCH (command) ............................................   29
-       FETCH (response) ...........................................   46
-       FIND ALL.MAILBOXES (command) ...............................   65
-       FIND MAILBOXES (command) ...................................   65
-       FLAGGED (search key) .......................................   27
-       FLAGS (fetch item) .........................................   31
-
-
-
-Crispin                                                        [Page 71]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-
-       FLAGS (fetch result) .......................................   50
-       FLAGS (response) ...........................................   44
-       FLAGS <flag list> (store command data item) ................   34
-       FLAGS.SILENT <flag list> (store command data item) .........   34
-       FROM <string> (search key) .................................   27
-       FULL (fetch item) ..........................................   31
-       HEADER <field-name> <string> (search key) ..................   27
-       INTERNALDATE (fetch item) ..................................   31
-       INTERNALDATE (fetch result) ................................   50
-       KEYWORD <flag> (search key) ................................   27
-       LARGER <n> (search key) ....................................   27
-       LIST (command) .............................................   20
-       LIST (response) ............................................   43
-       LOGIN (command) ............................................   14
-       LOGOUT (command) ...........................................   11
-       LSUB (command) .............................................   22
-       LSUB (response) ............................................   44
-       MAILBOX (response) .........................................   68
-       NEW (search key) ...........................................   27
-       NO (response) ..............................................   40
-       NOOP (command) .............................................   11
-       NOT <search-key> (search key) ..............................   28
-       OK (response) ..............................................   40
-       OLD (search key) ...........................................   28
-       ON <date> (search key) .....................................   28
-       OR <search-key1> <search-key2> (search key) ................   28
-       PARSE (response code) ......................................   39
-       PARTIAL (command) ..........................................   32
-       PERMANENTFLAGS (response code) .............................   39
-       PREAUTH (response) .........................................   41
-       READ-ONLY (response code) ..................................   39
-       READ-WRITE (response code) .................................   39
-       RECENT (response) ..........................................   45
-       RECENT (search key) ........................................   28
-       RENAME (command) ...........................................   18
-       RFC822 (fetch item) ........................................   31
-       RFC822 (fetch result) ......................................   50
-       RFC822.HEADER (fetch item) .................................   31
-       RFC822.HEADER (fetch result) ...............................   50
-       RFC822.HEADER.LINES <header_list> (fetch item) .............   31
-       RFC822.HEADER.LINES.NOT <header_list> (fetch item) .........   32
-       RFC822.PEEK (fetch item) ...................................   31
-       RFC822.SIZE (fetch item) ...................................   32
-       RFC822.SIZE (fetch result) .................................   50
-       RFC822.TEXT (fetch item) ...................................   32
-       RFC822.TEXT (fetch result) .................................   51
-       RFC822.TEXT.PEEK (fetch item) ..............................   32
-       SEARCH (command) ...........................................   25
-
-
-
-Crispin                                                        [Page 72]
-
-RFC 1730                         IMAP4                     December 1994
-
-
-
-       SEARCH (response) ..........................................   44
-       SEEN (search key) ..........................................   28
-       SELECT (command) ...........................................   15
-       SENTBEFORE <date> (search key) .............................   28
-       SENTON <date> (search key) .................................   28
-       SENTSINCE <date> (search key) ..............................   28
-       SINCE <date> (search key) ..................................   28
-       SMALLER <n> (search key) ...................................   28
-       STORE (command) ............................................   33
-       STORE (response) ...........................................   69
-       SUBJECT <string> (search key) ..............................   28
-       SUBSCRIBE (command) ........................................   19
-       SUBSCRIBE MAILBOX (command) ................................   66
-       TEXT <string> (search key) .................................   28
-       TO <string> (search key) ...................................   28
-       TRYCREATE (response code) ..................................   39
-       UID (command) ..............................................   35
-       UID (fetch item) ...........................................   32
-       UID (fetch result) .........................................   51
-       UID <message set> (search key) .............................   28
-       UIDVALIDITY (response code) ................................   40
-       UNANSWERED (search key) ....................................   29
-       UNDELETED (search key) .....................................   29
-       UNDRAFT (search key) .......................................   29
-       UNFLAGGED (search key) .....................................   29
-       UNKEYWORD <flag> (search key) ..............................   29
-       UNSEEN (response code) .....................................   40
-       UNSEEN (search key) ........................................   29
-       UNSUBSCRIBE (command) ......................................   19
-       UNSUBSCRIBE MAILBOX (command) ..............................   66
-       X<atom> (command) ..........................................   37
-       \Answered (system flag) ....................................   50
-       \Deleted (system flag) .....................................   50
-       \Draft (system flag) .......................................   50
-       \Flagged (system flag) .....................................   50
-       \Marked (mailbox name attribute) ...........................   43
-       \Noinferiors (mailbox name attribute) ......................   43
-       \Noselect (mailbox name attribute) .........................   43
-       \Recent (system flag) ......................................   50
-       \Seen (system flag) ........................................   50
-       \Unmarked (mailbox name attribute) .........................   43
-
-
-
-
-
-
-
-
-
-
-Crispin                                                        [Page 73]
-
diff --git a/RFC/rfc1731.txt b/RFC/rfc1731.txt
deleted file mode 100644
index 42215dec..00000000
--- a/RFC/rfc1731.txt
+++ /dev/null
@@ -1,339 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                           J. Myers
-Request for Comments: 1731                               Carnegie Mellon
-Category: Standards Track                                  December 1994
-
-
-                    IMAP4 Authentication Mechanisms
-
-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. Introduction
-
-   The Internet Message Access Protocol, Version 4 [IMAP4] contains the
-   AUTHENTICATE command, for identifying and authenticating a user to an
-   IMAP4 server and for optionally negotiating a protection mechanism
-   for subsequent protocol interactions.  This document describes
-   several authentication mechanisms for use by the IMAP4 AUTHENTICATE
-   command.
-
-
-2. Kerberos version 4 authentication mechanism
-
-   The authentication type associated with Kerberos version 4 is
-   "KERBEROS_V4".
-
-   The data encoded in the first ready response contains a random 32-bit
-   number in network byte order.  The client should respond with a
-   Kerberos ticket and an authenticator for the principal
-   "imap.hostname@realm", where "hostname" is the first component of the
-   host name of the server with all letters in lower case and where
-   "realm" is the Kerberos realm of the server.  The encrypted checksum
-   field included within the Kerberos authenticator should contain the
-   server provided 32-bit number in network byte order.
-
-   Upon decrypting and verifying the ticket and authenticator, the
-   server should verify that the contained checksum field equals the
-   original server provided random 32-bit number.  Should the
-   verification be successful, the server must add one to the checksum
-   and construct 8 octets of data, with the first four octets containing
-   the incremented checksum in network byte order, the fifth octet
-   containing a bit-mask specifying the protection mechanisms supported
-   by the server, and the sixth through eighth octets containing, in
-
-
-
-Myers                                                           [Page 1]
-
-RFC 1731            IMAP4 Authentication Mechanisms        December 1994
-
-
-   network byte order, the maximum cipher-text buffer size the server is
-   able to receive.  The server must encrypt the 8 octets of data in the
-   session key and issue that encrypted data in a second ready response.
-   The client should consider the server authenticated if the first four
-   octets the un-encrypted data is equal to one plus the checksum it
-   previously sent.
-
-   The client must construct data with the first four octets containing
-   the original server-issued checksum in network byte order, the fifth
-   octet containing the bit-mask specifying the selected protection
-   mechanism, the sixth through eighth octets containing in network byte
-   order the maximum cipher-text buffer size the client is able to
-   receive, and the following octets containing a user name string.  The
-   client must then append from one to eight octets so that the length
-   of the data is a multiple of eight octets. The client must then PCBC
-   encrypt the data with the session key and respond to the second ready
-   response with the encrypted data.  The server decrypts the data and
-   verifies the contained checksum.  The username field identifies the
-   user for whom subsequent IMAP operations are to be performed; the
-   server must verify that the principal identified in the Kerberos
-   ticket is authorized to connect as that user.  After these
-   verifications, the authentication process is complete.
-
-   The protection mechanisms and their corresponding bit-masks are as
-   follows:
-
-      1 No protection mechanism
-      2 Integrity (krb_mk_safe) protection
-      4 Privacy (krb_mk_priv) protection
-
-
-   EXAMPLE: The following are two Kerberos version 4 login scenarios
-   (note that the line breaks in the sample authenticators are for
-   editorial clarity and are not in real authenticators)
-
-      S: * OK IMAP4 Server
-      C: A001 AUTHENTICATE KERBEROS_V4
-      S: + AmFYig==
-      C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
-         +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd
-         WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
-      S: + or//EoAADZI=
-      C: DiAF5A4gA+oOIALuBkAAmw==
-      S: A001 OK Kerberos V4 authentication successful
-
-
-
-
-
-
-
-Myers                                                           [Page 2]
-
-RFC 1731            IMAP4 Authentication Mechanisms        December 1994
-
-
-      S: * OK IMAP4 Server
-      C: A001 AUTHENTICATE KERBEROS_V4
-      S: + gcfgCA==
-      C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
-         +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd
-         WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
-      S: A001 NO Kerberos V4 authentication failed
-
-
-3. GSSAPI authentication mechanism
-
-   The authentication type associated with all mechanisms employing the
-   GSSAPI [RFC1508] is "GSSAPI".
-
-   The first ready response issued by the server contains no data.  The
-   client should call GSS_Init_sec_context, passing in 0 for
-   input_context_handle (initially) and a targ_name equal to output_name
-   from GSS_Import_Name called with input_name_type of NULL and
-   input_name_string of "SERVICE:imap@hostname" where "hostname" is the
-   fully qualified host name of the server with all letters in lower
-   case.  The client must then respond with the resulting output_token.
-   If GSS_Init_sec_context returns GSS_CONTINUE_NEEDED, then the client
-   should expect the server to issue a token in a subsequent ready
-   response.  The client must pass the token to another call to
-   GSS_Init_sec_context.
-
-   If GSS_Init_sec_context returns GSS_COMPLETE, then the client should
-   respond with any resulting output_token.  If there is no
-   output_token, the client should respond with no data.  The client
-   should then expect the server to issue a token in a subsequent ready
-   response.  The client should pass this token to GSS_Unseal and
-   interpret the first octet of resulting cleartext as a bit-mask
-   specifying the protection mechanisms supported by the server and the
-   second through fourth octets as the maximum size output_message to
-   send to the server.  The client should construct data, with the first
-   octet containing the bit-mask specifying the selected protection
-   mechanism, the second through fourth octets containing in network
-   byte order the maximum size output_message the client is able to
-   receive, and the remaining octets containing a user name string.  The
-   client must pass the data to GSS_Seal with conf_flag set to FALSE,
-   and respond with the generated output_message.  The client can then
-   consider the server authenticated.
-
-   The server must issue a ready response with no data and pass the
-   resulting client supplied token to GSS_Accept_sec_context as
-   input_token, setting acceptor_cred_handle to NULL (for "use default
-   credentials"), and 0 for input_context_handle (initially).  If
-   GSS_Accept_sec_context returns GSS_CONTINUE_NEEDED, the server should
-
-
-
-Myers                                                           [Page 3]
-
-RFC 1731            IMAP4 Authentication Mechanisms        December 1994
-
-
-   return the generated output_token to the client in a ready response
-   and pass the resulting client supplied token to another call to
-   GSS_Accept_sec_context.
-
-   If GSS_Accept_sec_context returns GSS_COMPLETE, then if an
-   output_token is returned, the server should return it to the client
-   in a ready response and expect a reply from the client with no data.
-   Whether or not an output_token was returned, the server then should
-   then construct 4 octets of data, with the first octet containing a
-   bit-mask specifying the protection mechanisms supported by the server
-   and the second through fourth octets containing in network byte order
-   the maximum size output_token the server is able to receive.  The
-   server must then pass the plaintext to GSS_Seal with conf_flag set to
-   FALSE and issue the generated output_message to the client in a ready
-   response.  The server must then pass the resulting client supplied
-   token to GSS_Unseal and interpret the first octet of resulting
-   cleartext as the bit-mask for the selected protection mechanism, the
-   second through fourth octets as the maximum size output_message to
-   send to the client, and the remaining octets as the user name.  Upon
-   verifying the src_name is authorized to authenticate as the user
-   name, The server should then consider the client authenticated.
-
-   The protection mechanisms and their corresponding bit-masks are as
-   follows:
-
-      1 No protection mechanism
-      2 Integrity protection.
-        Sender calls GSS_Seal with conf_flag set to FALSE
-      4 Privacy protection.
-        Sender calls GSS_Seal with conf_flag set to TRUE
-
-
-4. S/Key authentication mechanism
-
-   The authentication type associated with S/Key [SKEY] is "SKEY".
-
-   The first ready response issued by the server contains no data.  The
-   client responds with the user name string.
-
-   The data encoded in the second ready response contains the decimal
-   sequence number followed by a single space and the seed string for
-   the indicated user.  The client responds with the one-time-password,
-   as either a 64-bit value in network byte order or encoded in the "six
-   English words" format.
-
-   Upon successful verification of the one-time-password, the server
-   should consider the client authenticated.
-
-
-
-
-Myers                                                           [Page 4]
-
-RFC 1731            IMAP4 Authentication Mechanisms        December 1994
-
-
-   S/Key authentication does not provide for any protection mechanisms.
-
-
-   EXAMPLE: The following are two S/Key login scenarios.
-
-      S: * OK IMAP4 Server
-      C: A001 AUTHENTICATE SKEY
-      S: +
-      C: bW9yZ2Fu
-      S: + OTUgUWE1ODMwOA==
-      C: Rk9VUiBNQU5OIFNPT04gRklSIFZBUlkgTUFTSA==
-      S: A001 OK S/Key authentication successful
-
-
-      S: * OK IMAP4 Server
-      C: A001 AUTHENTICATE SKEY
-      S: +
-      C: c21pdGg=
-      S: + OTUgUWE1ODMwOA==
-      C: BsAY3g4gBNo=
-      S: A001 NO S/Key authentication failed
-
-
-5. References
-
-   [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4",
-   RFC 1730, University of Washington, December 1994.
-
-   [RFC1508] Linn, J., "Generic Security Service Application Program
-   Interface", RFC 1508, Geer Zolot Associates, September 1993.
-
-   [SKEY] Haller, Neil M. "The S/Key One-Time Password System",
-   Bellcore, Morristown, New Jersey, October 1993,
-   thumper.bellcore.com:pub/nmh/docs/ISOC.symp.ps
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Myers                                                           [Page 5]
-
-RFC 1731            IMAP4 Authentication Mechanisms        December 1994
-
-
-6. Security Considerations
-
-   Security issues are discussed throughout this memo.
-
-
-7. Author's Address
-
-   John G. Myers
-   Carnegie-Mellon University
-   5000 Forbes Ave.
-   Pittsburgh PA, 15213-3890
-
-   EMail: jgm+@cmu.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Myers                                                           [Page 6]
-
diff --git a/RFC/rfc1732.txt b/RFC/rfc1732.txt
deleted file mode 100644
index cfae89c0..00000000
--- a/RFC/rfc1732.txt
+++ /dev/null
@@ -1,283 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         M. Crispin
-Request for Comments: 1732                      University of Washington
-Category: Informational                                    December 1994
-
-
-              IMAP4 COMPATIBILITY WITH IMAP2 AND IMAP2BIS
-
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  This memo
-   does not specify an Internet standard of any kind.  Distribution of
-   this memo is unlimited.
-
-Introduction
-
-   This is a summary of hints and recommendations to enable an IMAP4
-   implementation to interoperate with implementations that conform to
-   earlier specifications.  None of these hints and recommendations are
-   required by the IMAP4 specification; implementors must decide for
-   themselves whether they want their implementation to fail if it
-   encounters old software.
-
-   IMAP4 has been designed to be upwards compatible with earlier
-   specifications.  For the most part, IMAP4 facilities that were not in
-   earlier specifications should be invisible to clients unless the
-   client asks for the facility.
-
-   In some cases, older servers may support some of the capabilities
-   listed as being "new in IMAP4" as experimental extensions to the
-   IMAP2 protocol described in RFC 1176.
-
-   This information may not be complete; it reflects current knowledge
-   of server and client implementations as well as "folklore" acquired
-   in the evolution of the protocol.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin                                                         [Page 1]
-
-RFC 1732                 IMAP4 - Compatibility             December 1994
-
-
-IMAP4 client interoperability with old servers
-
-   In general, a client should be able to discover whether an IMAP2
-   server supports a facility by trial-and-error; if an attempt to use a
-   facility generates a BAD response, the client can assume that the
-   server does not support the facility.
-
-   A quick way to check whether a server implementation supports the
-   IMAP4 specification is to try the CAPABILITY command.  An OK response
-   that includes the IMAP4 capability value indicates a server that
-   supports IMAP4; a BAD response or one without the IMAP4 capability
-   value indicates an older server.
-
-   The following is a list of facilities that are only in IMAP4, and
-   suggestions for how new clients might interoperate with old servers:
-
-   CAPABILITY command
-            A BAD response to this command indicates that the server
-            implements IMAP2 (or IMAP2bis) and not IMAP4.
-
-   AUTHENTICATE command.
-            Use the LOGIN command.
-
-   LSUB and LIST commands
-            Try the RFC 1176 FIND command.
-
-   * in a sequence
-            Use the number of messages in the mailbox from the EXISTS
-            unsolicited response.
-
-   SEARCH extensions (character set, additional criteria)
-            Reformulate the search request using only the searching
-            options listed in search_old in the IMAP4 grammar.  This may
-            entail doing multiple searches to achieve the desired
-            results.
-
-   BODYSTRUCTURE fetch data item
-            Try to fetch the non-extensible BODY data item.
-
-   body section number 0
-            Fetch the entire message and extract the header.
-
-   RFC822.HEADER.LINES and RFC822.HEADER.LINES.NOT fetch data items
-            Use RFC822.HEADER and remove the unwanted information.
-
-   BODY.PEEK[section], RFC822.PEEK, and RFC822.TEXT.PEEK fetch data
-            items Use the corresponding non-PEEK versions and manually
-            clear the \Seen flag as necessary.
-
-
-
-Crispin                                                         [Page 2]
-
-RFC 1732                 IMAP4 - Compatibility             December 1994
-
-
-   UID fetch data item and the UID commands
-            No equivalent capabilitity exists in older servers.
-
-   FLAGS.SILENT, +FLAGS.SILENT, and -FLAGS.SILENT store data items
-            Use the corresponding non-SILENT versions and ignore the
-            untagged FETCH responses which com eback.
-
-
-   The following IMAP4 facilities were introduced in the experimental
-   IMAP2bis revisions to RFC-1176, and may be present in a server that
-   does not support the CAPABILITY command:
-
-   CREATE, DELETE, and RENAME commands
-            To test whether these commands are present, try a CREATE
-            INBOX command.  If the response is NO, these commands are
-            supported by the server.  If the response is BAD, they are
-            not.  Older servers without the CREATE capability may sup-
-            port implicit creation of a mailbox by a COPY command with a
-            non-existant name as the destination.
-
-   APPEND command
-            To test whether this command is present, try to append a
-            zero-length stream to a mailbox name that is known not to
-            exist (or at least, highly unlikely to exist) on the remote
-            system.
-
-   SUBSCRIBE and UNSUBSCRIBE commands
-            Try the form of these commands with the optional MAILBOX
-            keyword.
-
-   EXAMINE command
-            Use the SELECT command instead.
-
-   flags and internal date argument to APPEND command
-            Try the APPEND without any flag list and internal date argu-
-            ments.
-
-   BODY, BODY[section], and FULL fetch data items
-            Use RFC822.TEXT and ALL instead.  Server does not support
-            MIME.
-
-   PARTIAL command
-            Use the appropriate FETCH command and ignore the unwanted
-            data.
-
-
-   IMAP4 client implementations must accept all responses and data for-
-   mats documented in the IMAP4 specification, including those labeled
-
-
-
-Crispin                                                         [Page 3]
-
-RFC 1732                 IMAP4 - Compatibility             December 1994
-
-
-   as obsolete.  This includes the COPY and STORE unsolicited responses
-   and the old format of dates and times.  In particular, client imple-
-   mentations must not treat a date/time as a fixed format string; nor
-   may they assume that the time begins at a particular octet.
-
-   IMAP4 client implementations must not depend upon the presence of any
-   server extensions that are not in the base IMAP4 specification.
-
-   The experimental IMAP2bis version specified that the TRYCREATE spe-
-   cial information token is sent as a separate unsolicited OK response
-   instead of inside the NO response.
-
-   The FIND BBOARDS, FIND ALL.BBOARDS, and BBOARD commands of RFC 1176
-   are removed from IMAP4.  There is no equivalent to the bboard com-
-   mands, which provided a separate namespace with implicit restrictions
-   on what may be done in that namespace.
-
-   Older server implementations may automatically create the destination
-   mailbox on COPY if that mailbox does not already exist.  This was how
-   a new mailbox was created in older specifications.  If the server
-   does not support the CREATE command (see above for how to test for
-   this), it will probably create a mailbox on COPY.
-
-   Older server implementations may not preserve flags or internal dates
-   on COPY.  Some server implementations may not permit the preservation
-   of certain flags on COPY or their setting with APPEND as site policy.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin                                                         [Page 4]
-
-RFC 1732                 IMAP4 - Compatibility             December 1994
-
-
-IMAP4 server interoperability with old clients
-
-   In general, there should be no interoperation problem between a
-   server conforming to the IMAP4 specification and a well-written
-   client that conforms to an earlier specification.  Known problems are
-   noted below:
-
-      Poor wording in the description of the CHECK command in earlier
-      specifications implied that a CHECK command is the way to get the
-      current number of messages in the mailbox.  This is incorrect.  A
-      CHECK command does not necessarily result in an EXISTS response.
-      Clients must remember the most recent EXISTS value sent from the
-      server, and should not generate unnecessary CHECK commands.
-
-      An incompatibility exists with COPY in IMAP4.  COPY in IMAP4
-      servers does not automatically create the destination mailbox if
-      that mailbox does not already exist.  This may cause problems with
-      old clients that expect automatic mailbox creation in COPY.
-
-      The PREAUTH unsolicited response is new in IMAP4.  It is highly
-      unlikely that an old client would ever see this response.
-
-      The format of dates and times has changed due to the impending end
-      of the century.  Clients that fail to accept a four-digit year or
-      a signed four-digit timezone value will not work properly with
-      IMAP4.
-
-      An incompatibility exists with the use of "\" in quoted strings.
-      This is best avoided by using literals instead of quoted strings
-      if "\" or <"> is embedded in the string.
-
-Security Considerations
-
-   Security issues are not discussed in this memo.
-
-Author's Address:
-
-   Mark R. Crispin
-   Networks and Distributed Computing, JE-30
-   University of Washington
-   Seattle, WA  98195
-
-   Phone: (206) 543-5762
-
-   EMail: MRC@CAC.Washington.EDU
-
-
-
-
-
-
-Crispin                                                         [Page 5]
-
diff --git a/RFC/rfc1734.txt b/RFC/rfc1734.txt
deleted file mode 100644
index f37f29e0..00000000
--- a/RFC/rfc1734.txt
+++ /dev/null
@@ -1,283 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                           J. Myers
-Request for Comments: 1734                               Carnegie Mellon
-Category: Standards Track                                  December 1994
-
-
-                      POP3 AUTHentication command
-
-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. Introduction
-
-   This document describes the optional AUTH command, for indicating an
-   authentication mechanism to the server, performing an authentication
-   protocol exchange, and optionally negotiating a protection mechanism
-   for subsequent protocol interactions.  The authentication and
-   protection mechanisms used by the POP3 AUTH command are those used by
-   IMAP4.
-
-
-2. The AUTH command
-
-   AUTH mechanism
-
-         Arguments:
-             a string identifying an IMAP4 authentication mechanism,
-             such as defined by [IMAP4-AUTH].  Any use of the string
-             "imap" used in a server authentication identity in the
-             definition of an authentication mechanism is replaced with
-             the string "pop".
-
-         Restrictions:
-             may only be given in the AUTHORIZATION state
-
-         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 protection mechanism for
-             subsequent protocol interactions.  If the requested
-             authentication mechanism is not supported, the server
-
-
-
-Myers                                                           [Page 1]
-
-RFC 1734                       POP3 AUTH                   December 1994
-
-
-             should reject the AUTH command by sending a negative
-             response.
-
-             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 line consisting
-             of a "+" character followed by a single space and 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 should issue a
-             line with a single "*".  If the server receives such an
-             answer, it must reject the AUTH command by sending a
-             negative response.
-
-             A protection mechanism provides integrity and privacy
-             protection to the protocol session.  If a protection
-             mechanism is negotiated, it is applied to all subsequent
-             data sent over the connection.  The protection mechanism
-             takes effect immediately following the CRLF that concludes
-             the authentication exchange for the client, and the CRLF of
-             the positive response for the server.  Once the protection
-             mechanism is in effect, the stream of command and response
-             octets is processed into buffers of ciphertext.  Each
-             buffer is transferred over the connection as a stream of
-             octets prepended with a four octet field in network byte
-             order that represents the length of the following data.
-             The maximum ciphertext buffer length is defined by the
-             protection mechanism.
-
-             The server is not required to support any particular
-             authentication mechanism, nor are authentication mechanisms
-             required to support any protection mechanisms.  If an AUTH
-             command fails with a negative response, the session remains
-             in the AUTHORIZATION state and client may try another
-             authentication mechanism by issuing another AUTH command,
-             or may attempt to authenticate by using the USER/PASS or
-             APOP commands.  In other words, the client may request
-             authentication types in decreasing order of preference,
-             with the USER/PASS or APOP command as a last resort.
-
-             Should the client successfully complete the authentication
-             exchange, the POP3 server issues a positive response and
-             the POP3 session enters the TRANSACTION state.
-
-         Possible Responses:
-             +OK maildrop locked and ready
-             -ERR authentication exchange failed
-
-
-
-Myers                                                           [Page 2]
-
-RFC 1734                       POP3 AUTH                   December 1994
-
-
-
-         Examples:
-             S: +OK POP3 server ready
-             C: AUTH KERBEROS_V4
-             S: + AmFYig==
-             C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
-                +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd
-                WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
-             S: + or//EoAADZI=
-             C: DiAF5A4gA+oOIALuBkAAmw==
-             S: +OK Kerberos V4 authentication successful
-                ...
-             C: AUTH FOOBAR
-             S: -ERR Unrecognized authentication type
-
-              Note: the line breaks in the first client answer  are
-              for editorial clarity and are not in real authentica-
-              tors.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Myers                                                           [Page 3]
-
-RFC 1734                       POP3 AUTH                   December 1994
-
-
-3. Formal Syntax
-
-   The following syntax specification uses the augmented Backus-Naur
-   Form (BNF) notation as specified in RFC 822.
-
-   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.
-
-   ATOM_CHAR       ::= <any CHAR except atom_specials>
-
-   atom_specials   ::= "(" / ")" / "{" / SPACE / CTLs / "%" / "*" /
-                       <"> / "\"
-
-   auth            ::= "AUTH" 1*(SPACE / TAB) auth_type *(CRLF base64)
-                       CRLF
-
-   auth_type       ::= 1*ATOM_CHAR
-
-   base64          ::= *(4base64_CHAR) [base64_terminal]
-
-   base64_char     ::= "A" / "B" / "C" / "D" / "E" / "F" / "G" / "H" /
-           "I" / "J" / "K" / "L" / "M" / "N" / "O" / "P" /
-                       "Q" / "R" / "S" / "T" / "U" / "V" / "W" / "X" /
-                       "Y" / "Z" /
-                       "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" /
-                       "i" / "j" / "k" / "l" / "m" / "n" / "o" / "p" /
-                       "q" / "r" / "s" / "t" / "u" / "v" / "w" / "x" /
-                       "y" / "z" /
-                       "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" /
-                       "8" / "9" / "+" / "/"
-                       ;; Case-sensitive
-
-   base64_terminal ::= (2base64_char "==") / (3base64_char "=")
-
-   CHAR            ::= <any 7-bit US-ASCII character except NUL,
-                        0x01 - 0x7f>
-
-   continue_req    ::= "+" SPACE base64 CRLF
-
-   CR              ::= <ASCII CR, carriage return, 0x0C>
-
-   CRLF            ::= CR LF
-
-   CTL             ::= <any ASCII control character and DEL,
-                        0x00 - 0x1f, 0x7f>
-
-
-
-
-Myers                                                           [Page 4]
-
-RFC 1734                       POP3 AUTH                   December 1994
-
-
-   LF              ::= <ASCII LF, line feed, 0x0A>
-
-   SPACE           ::= <ASCII SP, space, 0x20>
-
-   TAB             ::= <ASCII HT, tab, 0x09>
-
-
-
-4. References
-
-   [IMAP4-AUTH]  Myers, J., "IMAP4 Authentication Mechanisms", RFC 1731,
-   Carnegie Mellon, December 1994.
-
-
-
-5. Security Considerations
-
-   Security issues are discussed throughout this memo.
-
-
-
-6. Author's Address
-
-   John G. Myers
-   Carnegie-Mellon University
-   5000 Forbes Ave
-   Pittsburgh, PA 15213
-
-   EMail: jgm+@cmu.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Myers                                                           [Page 5]
-
diff --git a/RFC/rfc1870.txt b/RFC/rfc1870.txt
deleted file mode 100644
index e24ccec6..00000000
--- a/RFC/rfc1870.txt
+++ /dev/null
@@ -1,507 +0,0 @@
-
-
-
-
-
-
-Network Working Group                               J. Klensin, WG Chair
-Request For Comments: 1870                                           MCI
-STD: 10                                                 N. Freed, Editor
-Obsoletes: 1653                             Innosoft International, Inc.
-Category: Standards Track                                       K. Moore
-                                                 University of Tennessee
-                                                           November 1995
-
-
-                         SMTP Service Extension
-                      for Message Size Declaration
-
-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 whereby an SMTP
-   client and server may interact to give the server an opportunity to
-   decline to accept a message (perhaps temporarily) based on the
-   client's estimate of the message size.
-
-2.  Introduction
-
-   The MIME extensions to the Internet message protocol provide for the
-   transmission of many kinds of data which were previously unsupported
-   in Internet mail.  One expected result of the use of MIME is that
-   SMTP will be expected to carry a much wider range of message sizes
-   than was previously the case.  This has an impact on the amount of
-   resources (e.g. disk space) required by a system acting as a server.
-
-   This memo uses the mechanism defined in [5] to define extensions to
-   the SMTP service whereby a client ("sender-SMTP") may declare the
-   size of a particular message to a server ("receiver-SMTP"), after
-   which the server may indicate to the client that it is or is not
-   willing to accept the message based on the declared message size and
-   whereby a server ("receiver-SMTP") may declare the maximum message
-   size it is willing to accept to a client ("sender-SMTP").
-
-
-
-
-
-
-
-
-Klensin, et al              Standards Track                     [Page 1]
-
-RFC 1870                 SMTP Size Declaration             November 1995
-
-
-3.  Framework for the Size Declaration Extension
-
-   The following service extension is therefore defined:
-
-   (1) the name of the SMTP service extension is "Message Size
-       Declaration";
-
-   (2) the EHLO keyword value associated with this extension is "SIZE";
-
-   (3) one optional parameter is allowed with this EHLO keyword value, a
-       decimal number indicating the fixed maximum message size in bytes
-       that the server will accept.  The syntax of the parameter is as
-       follows, using the augmented BNF notation of [2]:
-
-           size-param ::= [1*DIGIT]
-
-       A parameter value of 0 (zero) indicates that no fixed maximum
-       message size is in force.  If the parameter is omitted no
-       information is conveyed about the server's fixed maximum message
-       size;
-
-   (4) one optional parameter using the keyword "SIZE" is added to the
-       MAIL FROM command.  The value associated with this parameter is a
-       decimal number indicating the size of the message that is to be
-       transmitted.  The syntax of the value is as follows, using the
-       augmented BNF notation of [2]:
-
-           size-value ::= 1*20DIGIT
-
-   (5) the maximum length of a MAIL FROM command line is increased by 26
-       characters by the possible addition of the SIZE keyword and
-       value;
-
-   (6) 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.
-
-4.  The Message Size Declaration service extension
-
-   An SMTP server may have a fixed upper limit on message size.  Any
-   attempt by a client to transfer a message which is larger than this
-   fixed upper limit will fail.  In addition, a server normally has
-   limited space with which to store incoming messages.  Transfer of a
-   message may therefore also fail due to a lack of storage space, but
-   might succeed at a later time.
-
-
-
-
-
-Klensin, et al              Standards Track                     [Page 2]
-
-RFC 1870                 SMTP Size Declaration             November 1995
-
-
-   A client using the unextended SMTP protocol defined in [1], can only
-   be informed of such failures after transmitting the entire message to
-   the server (which discards the transferred message).  If, however,
-   both client and server support the Message Size Declaration service
-   extension, such conditions may be detected before any transfer is
-   attempted.
-
-   An SMTP client wishing to relay a large content 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 keyword
-   value SIZE, then the Message Size Declaration extension is supported.
-
-   If a numeric parameter follows the SIZE keyword value of the EHLO
-   response, it indicates the size of the largest message that the
-   server is willing to accept.  Any attempt by a client to transfer a
-   message which is larger than this limit will be rejected with a
-   permanent failure (552) reply code.
-
-   A server that supports the Message Size Declaration extension will
-   accept the extended version of the MAIL command described below.
-   When supported by the server, a client may use the extended MAIL
-   command (instead of the MAIL command as defined in [1]) to declare an
-   estimate of the size of a message it wishes to transfer.  The server
-   may then return an appropriate error code if it determines that an
-   attempt to transfer a message of that size would fail.
-
-5.  Definitions
-
-   The message size is defined as the number of octets, including CR-LF
-   pairs, but not the SMTP DATA command's terminating dot or doubled
-   quoting dots, to be transmitted by the SMTP client after receiving
-   reply code 354 to the DATA command.
-
-   The fixed maximum message size is defined as the message size of the
-   largest message that a server is ever willing to accept.  An attempt
-   to transfer any message larger than the fixed maximum message size
-   will always fail.  The fixed maximum message size may be an
-   implementation artifact of the SMTP server, or it may be chosen by
-   the administrator of the server.
-
-   The declared message size is defined as a client's estimate of the
-   message size for a particular message.
-
-
-
-
-
-
-
-
-Klensin, et al              Standards Track                     [Page 3]
-
-RFC 1870                 SMTP Size Declaration             November 1995
-
-
-6.  The extended MAIL command
-
-   The extended MAIL command is issued by a client when it wishes to
-   inform a server of the size of the message to be sent.  The extended
-   MAIL command is identical to the MAIL command as defined in [1],
-   except that a SIZE parameter appears after the address.
-
-   The complete syntax of this extended command is defined in [5]. The
-   esmtp-keyword is "SIZE" and the syntax for esmtp-value is given by
-   the syntax for size-value shown above.
-
-   The value associated with the SIZE parameter is a decimal
-   representation of the declared message size in octets.  This number
-   should include the message header, body, and the CR-LF sequences
-   between lines, but not the SMTP DATA command's terminating dot or
-   doubled quoting dots. Only one SIZE parameter may be specified in a
-   single MAIL command.
-
-   Ideally, the declared message size is equal to the true message size.
-   However, since exact computation of the message size may be
-   infeasable, the client may use a heuristically-derived estimate.
-   Such heuristics should be chosen so that the declared message size is
-   usually larger than the actual message size. (This has the effect of
-   making the counting or non-counting of SMTP DATA dots largely an
-   academic point.)
-
-   NOTE: Servers MUST NOT use the SIZE parameter to determine end of
-   content in the DATA command.
-
-6.1  Server action on receipt of the extended MAIL command
-
-   Upon receipt of an extended MAIL command containing a SIZE parameter,
-   a server should determine whether the declared message size exceeds
-   its fixed maximum message size.  If the declared message size is
-   smaller than the fixed maximum message size, the server may also wish
-   to determine whether sufficient resources are available to buffer a
-   message of the declared message size and to maintain it in stable
-   storage, until the message can be delivered or relayed to each of its
-   recipients.
-
-   A server may respond to the extended MAIL command with any of the
-   error codes defined in [1] for the MAIL command.  In addition, one of
-   the following error codes may be returned:
-
-   (1) If the server currently lacks sufficient resources to accept a
-       message of the indicated size, but may be able to accept the
-       message at a later time, it responds with code "452 insufficient
-       system storage".
-
-
-
-Klensin, et al              Standards Track                     [Page 4]
-
-RFC 1870                 SMTP Size Declaration             November 1995
-
-
-   (2) If the indicated size is larger than the server's fixed maximum
-       message size, the server responds with code "552 message size
-       exceeds fixed maximium message size".
-
-   A server is permitted, but not required, to accept a message which
-   is, in fact, larger than declared in the extended MAIL command, such
-   as might occur if the client employed a size-estimation heuristic
-   which was inaccurate.
-
-6.2  Client action on receiving response to extended MAIL command
-
-   The client, upon receiving the server's response to the extended MAIL
-   command, acts as follows:
-
-   (1) If the code "452 insufficient system storage" is returned, the
-       client should next send either a RSET command (if it wishes to
-       attempt to send other messages) or a QUIT command. The client
-       should then repeat the attempt to send the message to the server
-       at a later time.
-
-   (2) If the code "552 message exceeds fixed maximum message size" is
-       received, the client should immediately send either a RSET command
-       (if it wishes to attempt to send additional messages), or a QUIT
-       command.  The client should then declare the message undeliverable
-       and return appropriate notification to the sender (if a sender
-       address was present in the MAIL command).
-
-   A successful (250) reply code in response to the extended MAIL
-   command does not constitute an absolute guarantee that the message
-   transfer will succeed.  SMTP clients using the extended MAIL command
-   must still be prepared to handle both temporary and permanent error
-   reply codes (including codes 452 and 552), either immediately after
-   issuing the DATA command, or after transfer of the message.
-
-6.3  Messages larger than the declared size.
-
-   Once a server has agreed (via the extended MAIL command) to accept a
-   message of a particular size, it should not return a 552 reply code
-   after the transfer phase of the DATA command, unless the actual size
-   of the message transferred is greater than the declared message size.
-   A server may also choose to accept a message which is somewhat larger
-   than the declared message size.
-
-   A client is permitted to declare a message to be smaller than its
-   actual size.  However, in this case, a successful (250) reply code is
-   no assurance that the server will accept the message or has
-   sufficient resources to do so.  The server may reject such a message
-   after its DATA transfer.
-
-
-
-Klensin, et al              Standards Track                     [Page 5]
-
-RFC 1870                 SMTP Size Declaration             November 1995
-
-
-6.4  Per-recipient rejection based on message size.
-
-   A server that implements this extension may return a 452 or 552 reply
-   code in response to a RCPT command, based on its unwillingness to
-   accept a message of the declared size for a particular recipient.
-
-   (1) If a 452 code is returned, the client may requeue the message for
-       later delivery to the same recipient.
-
-   (2) If a 552 code is returned, the client may not requeue the message
-       for later delivery to the same recipient.
-
-7.  Minimal usage
-
-   A "minimal" client may use this extension to simply compare its
-   (perhaps estimated) size of the message that it wishes to relay, with
-   the server's fixed maximum message size (from the parameter to the
-   SIZE keyword in the EHLO response), to determine whether the server
-   will ever accept the message.  Such an implementation need not
-   declare message sizes via the extended MAIL command.  However,
-   neither will it be able to discover temporary limits on message size
-   due to server resource limitations, nor per-recipient limitations on
-   message size.
-
-   A minimal server that employs this service extension may simply use
-   the SIZE keyword value to inform the client of the size of the
-   largest message it will accept, or to inform the client that there is
-   no fixed limit on message size.  Such a server must accept the
-   extended MAIL command and return a 552 reply code if the client's
-   declared size exceeds its fixed size limit (if any), but it need not
-   detect "temporary" limitations on message size.
-
-   The numeric parameter to the EHLO SIZE keyword is optional.  If the
-   parameter is omitted entirely it indicates that the server does not
-   advertise a fixed maximum message size.  A server that returns the
-   SIZE keyword with no parameter in response to the EHLO command may
-   not issue a positive (250) response to an extended MAIL command
-   containing a SIZE specification without first checking to see if
-   sufficient resources are available to transfer a message of the
-   declared size, and to retain it in stable storage until it can be
-   relayed or delivered to its recipients.  If possible, the server
-   should actually reserve sufficient storage space to transfer the
-   message.
-
-
-
-
-
-
-
-
-Klensin, et al              Standards Track                     [Page 6]
-
-RFC 1870                 SMTP Size Declaration             November 1995
-
-
-8. Example
-
-   The following example illustrates the use of size declaration 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 SIZE 1000000
-   C: MAIL FROM:<ned@thor.innosoft.com> SIZE=500000
-   S: 250 Address Ok.
-   C: RCPT TO:<ned@innosoft.com>
-   S: 250 ned@innosoft.com OK; can accomodate 500000 byte message
-   C: RCPT TO:<ned@ymir.claremont.edu>
-   S: 552 Channel size limit exceeded: ned@YMIR.CLAREMONT.EDU
-   C: RCPT TO:<ned@hmcvax.claremont.edu>
-   S: 452 Insufficient channel storage: ned@hmcvax.CLAREMONT.EDU
-   C: DATA
-   S: 354 Send message, ending in CRLF.CRLF.
-    ...
-   C: .
-   S: 250 Some recipients OK
-   C: QUIT
-   S: 221 Goodbye
-
-9. Security Considerations
-
-   The size declaration extensions described in this memo can
-   conceivably be used to facilitate crude service denial attacks.
-   Specifically, both the information contained in the SIZE parameter
-   and use of the extended MAIL command make it somewhat quicker and
-   easier to devise an efficacious service denial attack.  However,
-   unless implementations are very weak, these extensions do not create
-   any vulnerability that has not always existed with SMTP. In addition,
-   no issues are addressed involving trusted systems and possible
-   release of information via the mechanisms described in this RFC.
-
-10.  Acknowledgements
-
-   This document was derived from an earlier Working Group work in
-   progess contribution.  Jim Conklin, Dave Crocker, Neil Katin, Eliot
-   Lear, Marshall T. Rose, and Einar Stefferud provided extensive
-   comments in response to earlier works in progress of both this and
-   the previous memo.
-
-
-
-Klensin, et al              Standards Track                     [Page 7]
-
-RFC 1870                 SMTP Size Declaration             November 1995
-
-
-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] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker,
-       "SMTP Service Extensions", STD 11, RFC 1869, MCI, Innosoft
-       International, Inc., Dover Beach Consulting, Inc., Network
-       Management Associates, Inc., Brandenburg Consulting, November
-       1995.
-
-   [6] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
-       974, BBN, January 1986.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Klensin, et al              Standards Track                     [Page 8]
-
-RFC 1870                 SMTP Size Declaration             November 1995
-
-
-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
-
-
-   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
-
-
-   Keith Moore
-   Computer Science Dept.
-   University of Tennessee
-   107 Ayres Hall
-   Knoxville, TN 37996-1301
-   USA
-
-   EMail: moore@cs.utk.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Klensin, et al              Standards Track                     [Page 9]
-
diff --git a/RFC/rfc1891.txt b/RFC/rfc1891.txt
deleted file mode 100644
index 23b58ba9..00000000
--- a/RFC/rfc1891.txt
+++ /dev/null
@@ -1,1739 +0,0 @@
-
-
-
-
-
-
-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/RFC/rfc1892.txt b/RFC/rfc1892.txt
deleted file mode 100644
index c4bdbd5f..00000000
--- a/RFC/rfc1892.txt
+++ /dev/null
@@ -1,227 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                       G. Vaudreuil
-Request for Comments: 1892                        Octel Network Services
-Category: Standards Track                                   January 1996
-
-
-                   The Multipart/Report Content Type
-                          for the Reporting of
-                  Mail System Administrative Messages
-
-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. The Multipart/Report MIME content-type
-
-   The Multipart/Report MIME content-type is a general "family" or
-   "container" type for electronic mail reports of any kind. Although
-   this memo defines only the use of the Multipart/Report content-type
-   with respect to delivery status reports, mail processing programs
-   will benefit if a single content-type is used to for all kinds of
-   reports.
-
-   The Multipart/Report content-type is defined as follows:
-
-             MIME type name: multipart
-             MIME subtype name: report
-             Required parameters: boundary, report-type
-             Optional parameters: none
-             Encoding considerations: 7bit should always be adequate
-             Security considerations: see section 4 of this memo.
-
-   The syntax of Multipart/Report is identical to the Multipart/Mixed
-   content type defined in [MIME].  When used to send a report, the
-   Multipart/Report content-type must be the top-level MIME content type
-   for any report message.  The report-type parameter identifies the
-   type of report.  The parameter is the MIME content sub-type of the
-   second body part of the Multipart/Report.
-
-      User agents and gateways must be able to automatically determine
-      that a message is a mail system report and should be processed as
-      such.  Placing the Multipart/Report as the outermost content
-      provides a mechanism whereby an auto-processor may detect through
-      parsing the RFC 822 headers that the message is a report.
-
-
-
-
-Vaudreuil                   Standards Track                     [Page 1]
-
-RFC 1892                    Multipart/Report                January 1996
-
-
-   The Multipart/Report content-type contains either two or three sub-
-   parts, in the following order:
-
-   (1) [required]  The first body part contains human readable message.
-       The purpose of this message is to provide an easily-understood
-       description of the condition(s) that caused the report to be
-       generated, for a human reader who may not have an user agent
-       capable of interpreting the second section of the
-       Multipart/Report.
-
-       The text in the first section may be in any MIME standards-track
-       content-type, charset, or language.  Where a description of the
-       error is desired in several languages or several media, a
-       Multipart/Alternative construct may be used.
-
-       This body part may also be used to send detailed information
-       that cannot be easily formatted into a Message/Report body part.
-
-   (2) [required]  A machine parsable body part containing an account
-       of the reported message handling event. The purpose of this body
-       part is to provide a machine-readable description of the
-       condition(s) which caused the report to be generated, along with
-       details not present in the first body part that may be useful to
-       human experts.  An initial body part, Message/delivery-status is
-       defined in [DSN]
-
-   (3) [optional]  A body part containing the returned message or a
-       portion thereof.  This information may be useful to aid human
-       experts in diagnosing problems.  (Although it may also be useful
-       to allow the sender to identify the message which the report was
-       issued, it is hoped that the envelope-id and original-recipient-
-       address returned in the Message/Report body part will replace
-       the traditional use of the returned content for this purpose.)
-
-   Return of content may be wasteful of network bandwidth and a variety
-   of implementation strategies can be used.  Generally the sender
-   should choose the appropriate strategy and inform the recipient of
-   the required level of returned content required.  In the absence of
-   an explicit request for level of return of content such as that
-   provided in [DRPT], the agent which generated the delivery service
-   report should return the full message content.
-
-   When data not encoded in 7 bits is to be returned, and the return
-   path is not guaranteed to be 8-bit capable, two options are
-   available.  The origional message MAY be reencoded into a legal 7 bit
-   MIME message or the Text/RFC822-Headers content-type MAY be used to
-   return only the origional message headers.
-
-
-
-
-Vaudreuil                   Standards Track                     [Page 2]
-
-RFC 1892                    Multipart/Report                January 1996
-
-
-2. The Text/RFC822-Headers MIME content-type
-
-   The Text/RFC822-Headers MIME content-type provides a mechanism to
-   label and return only the RFC 822 headers of a failed message.  These
-   headers are not the complete message and should not be returned as a
-   Message/RFC822.  The returned headers are useful for identifying the
-   failed message and for diagnostics based on the received: lines.
-
-   The Text/RFC822-Headers content-type is defined as follows:
-
-          MIME type name: Text
-          MIME subtype name: RFC822-Headers
-          Required parameters: None
-          Optional parameters: none
-          Encoding considerations: 7 bit is sufficient for normal RFC822
-                 headers, however, if the headers are broken and require
-                 encoding, they may be encoded in quoted-printable.
-          Security considerations: see section 4 of this memo.
-
-   The Text/RFC822-headers body part should contain all the RFC822
-   header lines from the message which caused the report.  The RFC822
-   headers include all lines prior to the blank line in the message.
-   They include the MIME-Version and MIME Content- headers.
-
-3. References
-
-   [DSN] Moore, K., and G. Vaudreuil, "An Extensible Message Format for
-       Delivery Status Notifications", RFC 1894, University of
-       Tennessee, Octel Network Services, January 1996.
-
-   [RFC822] Crocker, D., "Standard for the format of ARPA Internet Text
-       Messages", STD 11, RFC 822, UDEL, August 1982.
-
-   [MIME] Borenstein, N., and N. Freed, "Multipurpose Internet Mail
-       Extensions", RFC 1521, Bellcore, Innosoft, June 1992.
-
-   [DRPT] Moore, K., "SMTP Service Extension for Delivery Status
-       Notifications", RFC 1891, University of Tennessee, January 1996.
-
-4. Security Considerations
-
-   Automated use of report types without authentication presents several
-   security issues.  Forging negative reports presents the opportunity
-   for denial-of-service attacks when the reports are used for automated
-   maintenance of directories or mailing lists.  Forging positive
-   reports may cause the sender to incorrectly believe a message was
-   delivered when it was not.
-
-
-
-
-Vaudreuil                   Standards Track                     [Page 3]
-
-RFC 1892                    Multipart/Report                January 1996
-
-
-5. Author's Address
-
-   Gregory M. Vaudreuil
-   Octel Network Services
-   17060 Dallas Parkway
-   Dallas, TX 75248-1905
-
-   Phone: +1-214-733-2722
-   EMail: Greg.Vaudreuil@Octel.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Vaudreuil                   Standards Track                     [Page 4]
-
diff --git a/RFC/rfc1893.txt b/RFC/rfc1893.txt
deleted file mode 100644
index 9ca4efb5..00000000
--- a/RFC/rfc1893.txt
+++ /dev/null
@@ -1,843 +0,0 @@
-
-
-
-
-
-
-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/RFC/rfc1894.txt b/RFC/rfc1894.txt
deleted file mode 100644
index f1fc90d4..00000000
--- a/RFC/rfc1894.txt
+++ /dev/null
@@ -1,2187 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                           K. Moore
-Request for Comments: 1894                       University of Tennessee
-Category: Standards Track                                   G. Vaudreuil
-                                                  Octel Network Services
-                                                            January 1996
-
-
-     An Extensible Message Format 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.
-
-Abstract
-
-   This memo defines a MIME content-type that may be used by a message
-   transfer agent (MTA) or electronic mail gateway to report the result
-   of an attempt to deliver a message to one or more recipients.  This
-   content-type is intended as a machine-processable replacement for the
-   various types of delivery status notifications currently used in
-   Internet electronic mail.
-
-   Because many messages are sent between the Internet and other
-   messaging systems (such as X.400 or the so-called "LAN-based"
-   systems), the DSN protocol is designed to be useful in a multi-
-   protocol messaging environment.  To this end, the protocol described
-   in this memo provides for the carriage of "foreign" addresses and
-   error codes, in addition to those normally used in Internet mail.
-   Additional attributes may also be defined to support "tunneling" of
-   foreign notifications through Internet mail.
-
-   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
-
-
-
-Moore & Vaudreuil           Standards Track                     [Page 1]
-
-RFC 1894             Delivery Status Notifications          January 1996
-
-
-   experience, and are thus subject to change.
-
-1. Introduction
-
-   This memo defines a MIME [1] content-type for delivery status
-   notifications (DSNs).  A DSN can be used to notify the sender of a
-   message of any of several conditions:  failed delivery, delayed
-   delivery, successful delivery, or the gatewaying of a message into an
-   environment that may not support DSNs.  The "message/delivery-status"
-   content-type defined herein is intended for use within the framework
-   of the "multipart/report" content type defined in [2].
-
-   This memo defines only the format of the notifications.  An extension
-   to the Simple Message Transfer Protocol (SMTP) [3] to fully support
-   such notifications is the subject of a separate memo [4].
-
-1.1 Purposes
-
-   The DSNs defined in this memo are expected to serve several purposes:
-
-(a) Inform human beings of the status of message delivery processing, as
-    well as the reasons for any delivery problems or outright failures,
-    in a manner which is largely independent of human language;
-
-(b) Allow mail user agents to keep track of the delivery status of
-    messages sent, by associating returned DSNs with earlier message
-    transmissions;
-
-(c) Allow mailing list exploders to automatically maintain their
-    subscriber lists when delivery attempts repeatedly fail;
-
-(d) Convey delivery and non-delivery notifications resulting from
-    attempts to deliver messages to "foreign" mail systems via a
-    gateway;
-
-(e) Allow "foreign" notifications to be tunneled through a MIME-capable
-    message system and back into the original messaging system that
-    issued the original notification, or even to a third messaging
-    system;
-
-(f) Allow language-independent, yet reasonably precise, indications of
-    the reason for the failure of a message to be delivered (once status
-    codes of sufficient precision are defined); and
-
-(g) Provide sufficient information to remote MTA maintainers (via
-    "trouble tickets") so that they can understand the nature of
-    reported errors.  This feature is used in the case that failure to
-    deliver a message is due to the malfunction of a remote MTA and the
-
-
-
-Moore & Vaudreuil           Standards Track                     [Page 2]
-
-RFC 1894             Delivery Status Notifications          January 1996
-
-
-    sender wants to report the problem to the remote MTA administrator.
-
-1.2 Requirements
-
-    These purposes place the following constraints on the notification
-    protocol:
-
-(a) It must be readable by humans as well as being machine-parsable.
-
-(b) It must provide enough information to allow message senders (or the
-    user agents) to unambiguously associate a DSN with the message that
-    was sent and the original recipient address for which the DSN is
-    issued (if such information is available), even if the message was
-    forwarded to another recipient address.
-
-(c) It must be able to preserve the reason for the success or failure of
-    a delivery attempt in a remote messaging system, using the
-    "language" (mailbox addresses and status codes) of that remote
-    system.
-
-(d) It must also be able to describe the reason for the success or
-    failure of a delivery attempt, independent of any particular human
-    language or of the "language" of any particular mail system.
-
-(e) It must preserve enough information to allow the maintainer of a
-    remote MTA to understand (and if possible, reproduce) the conditions
-    that caused a delivery failure at that MTA.
-
-(f) For any notifications issued by foreign mail systems, which are
-    translated by a mail gateway to the DSN format, the DSN must
-    preserve the "type" of the foreign addresses and error codes, so
-    that these may be correctly interpreted by gateways.
-
-   A DSN contains a set of per-message fields which identify the message
-   and the transaction during which the message was submitted, along
-   with other fields that apply to all delivery attempts described by
-   the DSN.  The DSN also includes a set of per-recipient fields to
-   convey the result of the attempt to deliver the message to each of
-   one or more recipients.
-
-1.3 Terminology
-
-   A message may be transmitted through several message transfer agents
-   (MTAs) on its way to a recipient.  For a variety of reasons,
-   recipient addresses may be rewritten during this process, so each MTA
-   may potentially see a different recipient address.  Depending on the
-   purpose for which a DSN is used, different formats of a particular
-   recipient address will be needed.
-
-
-
-Moore & Vaudreuil           Standards Track                     [Page 3]
-
-RFC 1894             Delivery Status Notifications          January 1996
-
-
-   Several DSN fields are defined in terms of the view from a particular
-   MTA in the transmission.  The MTAs are assigned the following names:
-
-   (a) Original MTA
-
-   The Original MTA is the one to which the message is submitted for
-   delivery by the sender of the message.
-
-   (b) Reporting MTA
-
-   For any DSN, the Reporting MTA is the one which is reporting the
-   results of delivery attempts described in the DSN.
-
-   If the delivery attempts described occurred in a "foreign" (non-
-   Internet) mail system, and the DSN was produced by translating the
-   foreign notice into DSN format, the Reporting MTA will still identify
-   the "foreign" MTA where the delivery attempts occurred.
-
-   (c) Received-From MTA
-
-   The Received-From MTA is the MTA from which the Reporting MTA
-   received the message, and accepted responsibility for delivery of the
-   message.
-
-   (d) Remote MTA
-
-   If an MTA determines that it must relay a message to one or more
-   recipients, but the message cannot be transferred to its "next hop"
-   MTA, or if the "next hop" MTA refuses to accept responsibility for
-   delivery of the message to one or more of its intended recipients,
-   the relaying MTA may need to issue a DSN on behalf of the recipients
-   for whom the message cannot be delivered.  In this case the relaying
-   MTA is the Reporting MTA, and the "next hop" MTA is known as the
-   Remote MTA.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Moore & Vaudreuil           Standards Track                     [Page 4]
-
-RFC 1894             Delivery Status Notifications          January 1996
-
-
-Figure 1 illustrates the relationship between the various MTAs.
-
-
-+-----+    +--------+           +---------+    +---------+      +------+
-|     |    |        |           |Received-|    |         |      |      |
-|     | => |Original| => ... => |  From   | => |Reporting| ===> |Remote|
-| user|    |   MTA  |           |   MTA   |    |   MTA   | <No! |  MTA |
-|agent|    +--------+           +---------+    +----v----+      +------+
-|     |                                             |
-|     | <-------------------------------------------+
-+-----+      (DSN returned to sender by Reporting MTA)
-
-
-     Figure 1.  Original, Received-From, Reporting and Remote MTAs
-
-
-   Each of these MTAs may provide information which is useful in a DSN:
-
-+ Ideally, the DSN will contain the address of each recipient as
-  originally specified to the Original MTA by the sender of the message.
-  This version of the address is needed (rather than a forwarding
-  address or some modified version of the original address) so that the
-  sender may compare the recipient address in the DSN with the address
-  in the sender's records (e.g. an address book for an individual, the
-  list of subscribers for a mailing list) and take appropriate action.
-
-  Similarly, the DSN might contain an "envelope identifier" that was
-  known to both the sender's user agent and the Original MTA at the time
-  of message submission, and which, if included in the DSN, can be used
-  by the sender to keep track of which messages were or were not
-  delivered.
-
-+ If a message was (a) forwarded to a different address than that
-  specified by the sender, (b) gatewayed to a different mail system than
-  that used by the sender, or (c) subjected to address rewriting during
-  transmission, the "final" form of the recipient address (i.e. the one
-  seen by the Reporting MTA) will be different than the original
-  (sender-specified) recipient address.  Just as the sender's user agent
-  (or the sender) prefers the original recipient address, so the "final"
-  address is needed when reporting a problem to the postmaster of the
-  site where message delivery failed, because only the final recipient
-  address will allow her to reproduce the conditions that caused the
-  failure.
-
-+ A "failed" DSN should contain the most accurate explanation for the
-  delivery failure that is available.  For ease of interpretation, this
-  information should be a format which is independent of the mail
-  transport system that issued the DSN.  However, if a foreign error
-
-
-
-Moore & Vaudreuil           Standards Track                     [Page 5]
-
-RFC 1894             Delivery Status Notifications          January 1996
-
-
-  code is translated into some transport-independent format, some
-  information may be lost.  It is therefore desirable to provide both a
-  transport-independent status code and a mechanism for reporting
-  transport-specific codes.  Depending on the circumstances that
-  produced delivery failure, the transport-specific code might be
-  obtained from either the Reporting MTA or the Remote MTA.
-
-   Since different values for "recipient address" and "delivery status
-   code" are needed according to the circumstance in which a DSN will be
-   used, and since the MTA that issues the DSN cannot anticipate those
-   circumstances, the DSN format described here may contain both the
-   original and final forms of a recipient address, and both a
-   transport-independent and a transport-specific indication of delivery
-   status.
-
-   Extension fields may also be added by the Reporting MTA as needed to
-   provide additional information for use in a trouble ticket or to
-   preserve information for tunneling of foreign delivery reports
-   through Internet DSNs.
-
-   The Original, Reporting, and Remote MTAs may exist in very different
-   environments and use dissimilar transport protocols, MTA names,
-   address formats, and delivery status codes.  DSNs therefore do not
-   assume any particular format for mailbox addresses, MTA names, or
-   transport-specific status codes.  Instead, the various DSN fields
-   that carry such quantities consist of a "type" subfield followed by a
-   subfield whose contents are ordinary text characters, and the format
-   of which is indicated by the "type" subfield.  This allows a DSN to
-   convey these quantities regardless of format.
-
-2. Format of a Delivery Status Notification
-
-   A DSN is a MIME message with a top-level content-type of
-   multipart/report (defined in [2]).  When a multipart/report content
-   is used to transmit a DSN:
-
-(a) The report-type parameter of the multipart/report content is
-    "delivery-status".
-
-(b) The first component of the multipart/report contains a human-
-    readable explanation of the DSN, as described in [2].
-
-(c) The second component of the multipart/report is of content-type
-    message/delivery-status, described in section 2.1 of this document.
-
-(d) If the original message or a portion of the message is to be
-    returned to the sender, it appears as the third component of the
-    multipart/report.
-
-
-
-Moore & Vaudreuil           Standards Track                     [Page 6]
-
-RFC 1894             Delivery Status Notifications          January 1996
-
-
-    NOTE: For delivery status notifications gatewayed from foreign
-    systems, the headers of the original message may not be available.
-    In this case the third component of the DSN may be omitted, or it
-    may contain "simulated" RFC 822 headers which contain equivalent
-    information.  In particular, it is very desirable to preserve the
-    subject, date, and message-id (or equivalent) fields from the
-    original message.
-
-   The DSN MUST be addressed (in both the message header and the
-   transport envelope) to the return address from the transport envelope
-   which accompanied the original message for which the DSN was
-   generated.  (For a message that arrived via SMTP, the envelope return
-   address appears in the MAIL FROM command.)
-
-   The From field of the message header of the DSN SHOULD contain the
-   address of a human who is responsible for maintaining the mail system
-   at the Reporting MTA site (e.g.  Postmaster), so that a reply to the
-   DSN will reach that person.  Exception: if a DSN is translated from a
-   foreign delivery report, and the gateway performing the translation
-   cannot determine the appropriate address, the From field of the DSN
-   MAY be the address of a human who is responsible for maintaining the
-   gateway.
-
-   The envelope sender address of the DSN SHOULD be chosen to ensure
-   that no delivery status reports will be issued in response to the DSN
-   itself, and MUST be chosen so that DSNs will not generate mail loops.
-   Whenever an SMTP transaction is used to send a DSN, the MAIL FROM
-   command MUST use a NULL return address, i.e. "MAIL FROM:<>".
-
-   A particular DSN describes the delivery status for exactly one
-   message.  However, an MTA MAY report on the delivery status for
-   several recipients of the same message in a single DSN.  Due to the
-   nature of the mail transport system (where responsibility for
-   delivery of a message to its recipients may be split among several
-   MTAs, and delivery to any particular recipient may be delayed),
-   multiple DSNs may be still be issued in response to a single message
-   submission.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Moore & Vaudreuil           Standards Track                     [Page 7]
-
-RFC 1894             Delivery Status Notifications          January 1996
-
-
-2.1 The message/delivery-status content-type
-
-   The message/delivery-status content-type is defined as follows:
-
-     MIME type name:                message
-     MIME subtype name:             delivery-status
-     Optional parameters:           none
-     Encoding considerations:       "7bit" encoding is sufficient and
-                                    MUST be used to maintain readability
-                                    when viewed by non-MIME mail
-                                    readers.
-     Security considerations:       discussed in section 4 of this memo.
-
-   The message/delivery-status report type for use in the
-   multipart/report is "delivery-status".
-
-   The body of a message/delivery-status consists of one or more
-   "fields" formatted according to the ABNF of RFC 822 header "fields"
-   (see [6]).  The per-message fields appear first, followed by a blank
-   line.  Following the per-message fields are one or more groups of
-   per-recipient fields.  Each group of per-recipient fields is preceded
-   by a blank line.  Using the ABNF of RFC 822, the syntax of the
-   message/delivery-status content is as follows:
-
-     delivery-status-content =
-          per-message-fields 1*( CRLF per-recipient-fields )
-
-   The per-message fields are described in section 2.2.  The per-
-   recipient fields are described in section 2.3.
-
-
-2.1.1 General conventions for DSN fields
-
-   Since these fields are defined according to the rules of RFC 822, the
-   same conventions for continuation lines and comments apply.
-   Notification fields may be continued onto multiple lines by beginning
-   each additional line with a SPACE or HTAB.  Text which appears in
-   parentheses is considered a comment and not part of the contents of
-   that notification field.  Field names are case-insensitive, so the
-   names of notification fields may be spelled in any combination of
-   upper and lower case letters.  Comments in DSN fields may use the
-   "encoded-word" construct defined in [7].
-
-   A number of DSN fields are defined to have a portion of a field body
-   of "xtext".  "xtext" is used to allow encoding sequences of octets
-   which contain values outside the range [1-127 decimal] of traditional
-   ASCII characters, and also to allow comments to be inserted in the
-   data.  Any octet may be encoded as "+" followed by two upper case
-
-
-
-Moore & Vaudreuil           Standards Track                     [Page 8]
-
-RFC 1894             Delivery Status Notifications          January 1996
-
-
-   hexadecimal digits.  (The "+" character MUST be encoded as "+2B".)
-   With certain exceptions, octets that correspond to ASCII characters
-   may be represented as themselves.  SPACE and HTAB characters are
-   ignored.  Comments may be included by enclosing them in parenthesis.
-   Except within comments, encoded-words such as defined in [7] may NOT
-   be used in xtext.
-
-   "xtext" is formally defined as follows:
-
-     xtext = *( xchar / hexchar / linear-white-space / comment )
-
-     xchar = any ASCII CHAR between "!" (33) and "~" (126) inclusive,
-          except for "+", "\" and "(".
-
-   "hexchar"s are intended to encode octets that cannot be represented
-   as plain text, either because they are reserved, or because they are
-   non-printable.  However, any octet value may be represented by a
-   "hexchar".
-
-     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.  (Some CHARs in this range may
-     also be encoded as "hexchar"s, at the implementor's discretion.)
-
-   + ASCII CHARs that fall outside the range above must be encoded as
-     "hexchar".
-
-   + Line breaks (CR LF SPACE) MAY be inserted as necessary to keep line
-     lengths from becoming excessive.
-
-   + Comments MAY be added to clarify the meaning for human readers.
-
-2.1.2 "*-type" subfields
-
-   Several DSN fields consist of a "-type" subfield, followed by a
-   semicolon, followed by "*text".  For these fields, the keyword used
-   in the address-type, diagnostic-type, or MTA-name-type subfield
-   indicates the expected format of the address, status-code, or MTA-
-   name which follows.
-
-
-
-
-
-
-
-
-Moore & Vaudreuil           Standards Track                     [Page 9]
-
-RFC 1894             Delivery Status Notifications          January 1996
-
-
-   The "-type" subfields are defined as follows:
-
-(a) An "address-type" specifies the format of a mailbox address.  For
-    example, Internet mail addresses use the "rfc822" address-type.
-
-         address-type = atom
-
-(b) A "diagnostic-type" specifies the format of a status code.  For
-    example, when a DSN field contains a reply code reported via the
-    Simple Mail Transfer Protocol [3], the "smtp" diagnostic-type is
-    used.
-
-         diagnostic-type = atom
-
-(c) An "MTA-name-type" specifies the format of an MTA name.  For
-    example, for an SMTP server on an Internet host, the MTA name is the
-    domain name of that host, and the "dns" MTA-name-type is used.
-
-         mta-name-type = atom
-
-   Values for address-type, diagnostic-type, and MTA-name-type are
-   case-insensitive.  Thus address-type values of "RFC822" and "rfc822"
-   are equivalent.
-
-   The Internet Assigned Numbers Authority (IANA) will maintain a
-   registry of address-types, diagnostic-types, and MTA-name-types,
-   along with descriptions of the meanings and acceptable values of
-   each, or a reference to a one or more specifications that provide
-   such descriptions.  (The "rfc822" address-type, "smtp" diagnostic-
-   type, and "dns" MTA-name-type are defined in [4].)  Registration
-   forms for address-type, diagnostic-type, and MTA-name-type appear in
-   section 8 of this document.
-
-   IANA will not accept registrations for any address-type, diagnostic-
-   type, or MTA-name-type name that begins with "X-".  These type names
-   are reserved for experimental use.
-
-2.1.3 Lexical tokens imported from RFC 822
-
-   The following lexical tokens, defined in [6], are used in the ABNF
-   grammar for DSNs: atom, CHAR, comment, CR, CRLF, DIGIT, LF, linear-
-   white-space, SPACE, text.  The date-time lexical token is defined in
-   [8].
-
-
-
-
-
-
-
-
-Moore & Vaudreuil           Standards Track                    [Page 10]
-
-RFC 1894             Delivery Status Notifications          January 1996
-
-
-2.2 Per-Message DSN Fields
-
-   Some fields of a DSN apply to all of the delivery attempts described
-   by that DSN.  These fields may appear at most once in any DSN.  These
-   fields are used to correlate the DSN with the original message
-   transaction and to provide additional information which may be useful
-   to gateways.
-
-     per-message-fields =
-          [ original-envelope-id-field CRLF ]
-          reporting-mta-field CRLF
-          [ dsn-gateway-field CRLF ]
-          [ received-from-mta-field CRLF ]
-          [ arrival-date-field CRLF ]
-          *( extension-field CRLF )
-
-2.2.1 The Original-Envelope-Id field
-
-   The optional Original-Envelope-Id field contains an "envelope
-   identifier" which uniquely identifies the transaction during which
-   the message was submitted, and was either (a) specified by the sender
-   and supplied to the sender's MTA, or (b) generated by the sender's
-   MTA and made available to the sender when the message was submitted.
-   Its purpose is to allow the sender (or her user agent) to associate
-   the returned DSN with the specific transaction in which the message
-   was sent.
-
-   If such an envelope identifier was present in the envelope which
-   accompanied the message when it arrived at the Reporting MTA, it
-   SHOULD be supplied in the Original-Envelope-Id field of any DSNs
-   issued as a result of an attempt to deliver the message.  Except when
-   a DSN is issued by the sender's MTA, an MTA MUST NOT supply this
-   field unless there is an envelope-identifier field in the envelope
-   which accompanied this message on its arrival at the Reporting MTA.
-
-   The Original-Envelope-Id field is defined as follows:
-
-     original-envelope-id-field =
-          "Original-Envelope-Id" ":" envelope-id
-
-     envelope-id = *text
-
-   There may be at most one Original-Envelope-Id field per DSN.
-
-   The envelope-id is CASE-SENSITIVE.  The DSN MUST preserve the
-   original case and spelling of the envelope-id.
-
-
-
-
-
-Moore & Vaudreuil           Standards Track                    [Page 11]
-
-RFC 1894             Delivery Status Notifications          January 1996
-
-
-   NOTE: The Original-Envelope-Id is NOT the same as the Message-Id from
-   the message header.  The Message-Id identifies the content of the
-   message, while the Original-Envelope-Id identifies the transaction in
-   which the message is sent.
-
-2.2.2 The Reporting-MTA DSN field
-
-     reporting-mta-field =
-          "Reporting-MTA" ":" mta-name-type ";" mta-name
-
-     mta-name = *text
-
-   The Reporting-MTA field is defined as follows:
-
-   A DSN describes the results of attempts to deliver, relay, or gateway
-   a message to one or more recipients.  In all cases, the Reporting-MTA
-   is the MTA which attempted to perform the delivery, relay, or gateway
-   operation described in the DSN.  This field is required.
-
-   Note that if an SMTP client attempts to relay a message to an SMTP
-   server and receives an error reply to a RCPT command, the client is
-   responsible for generating the DSN, and the client's domain name will
-   appear in the Reporting-MTA field.  (The server's domain name will
-   appear in the Remote-MTA field.)
-
-   Note that the Reporting-MTA is not necessarily the MTA which actually
-   issued the DSN.  For example, if an attempt to deliver a message
-   outside of the Internet resulted in a nondelivery notification which
-   was gatewayed back into Internet mail, the Reporting-MTA field of the
-   resulting DSN would be that of the MTA that originally reported the
-   delivery failure, not that of the gateway which converted the foreign
-   notification into a DSN.  See Figure 2.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Moore & Vaudreuil           Standards Track                    [Page 12]
-
-RFC 1894             Delivery Status Notifications          January 1996
-
-
-sender's environment                            recipient's environment
-............................ ..........................................
-                           : :
-                       (1) : :                             (2)
-  +-----+  +--------+  +--------+  +---------+  +---------+   +------+
-  |     |  |        |  |        |  |Received-|  |         |   |      |
-  |     |=>|Original|=>|        |->|  From   |->|Reporting|-->|Remote|
-  | user|  |   MTA  |  |        |  |   MTA   |  |   MTA   |<No|  MTA |
-  |agent|  +--------+  |Gateway |  +---------+  +----v----+   +------+
-  |     |              |        |                    |
-  |     | <============|        |<-------------------+
-  +-----+              |        |(4)                (3)
-                       +--------+
-                           : :
-...........................: :.........................................
-
-              Figure 2.  DSNs in the presence of gateways
-
-     (1) message is gatewayed into recipient's environment
-     (2) attempt to relay message fails
-     (3) reporting-mta (in recipient's environment) returns nondelivery
-         notification
-     (4) gateway translates foreign notification into a DSN
-
-
-
-   The mta-name portion of the Reporting-MTA field is formatted
-   according to the conventions indicated by the mta-name-type subfield.
-   If an MTA functions as a gateway between dissimilar mail environments
-   and thus is known by multiple names depending on the environment, the
-   mta-name subfield SHOULD contain the name used by the environment
-   from which the message was accepted by the Reporting-MTA.
-
-   Because the exact spelling of an MTA name may be significant in a
-   particular environment, MTA names are CASE-SENSITIVE.
-
-2.2.3 The DSN-Gateway field
-
-   The DSN-Gateway field indicates the name of the gateway or MTA which
-   translated a foreign (non-Internet) delivery status notification into
-   this DSN.  This field MUST appear in any DSN which was translated by
-   a gateway from a foreign system into DSN format, and MUST NOT appear
-   otherwise.
-
-   dsn-gateway-field = "DSN-Gateway" ":" mta-name-type ";" mta-name
-
-
-
-
-
-
-Moore & Vaudreuil           Standards Track                    [Page 13]
-
-RFC 1894             Delivery Status Notifications          January 1996
-
-
-   For gateways into Internet mail, the MTA-name-type will normally be
-   "smtp", and the mta-name will be the Internet domain name of the
-   gateway.
-
-2.2.4 The Received-From-MTA DSN field
-
-   The optional Received-From-MTA field indicates the name of the MTA
-   from which the message was received.
-
-     received-from-mta-field =
-          "Received-From-MTA" ":" mta-name-type ";" mta-name
-
-   If the message was received from an Internet host via SMTP, the
-   contents of the mta-name subfield SHOULD be the Internet domain name
-   supplied in the HELO or EHLO command, and the network address used by
-   the SMTP client SHOULD be included as a comment enclosed in
-   parentheses.  (In this case, the MTA-name-type will be "smtp".)
-
-   The mta-name portion of the Received-From-MTA field is formatted
-   according to the conventions indicated by the MTA-name-type subfield.
-
-   Since case is significant in some mail systems, the exact spelling,
-   including case, of the MTA name SHOULD be preserved.
-
-2.2.5 The Arrival-Date DSN field
-
-   The optional Arrival-Date field indicates the date and time at which
-   the message arrived at the Reporting MTA.  If the Last-Attempt-Date
-   field is also provided in a per-recipient field, this can be used to
-   determine the interval between when the message arrived at the
-   Reporting MTA and when the report was issued for that recipient.
-
-     arrival-date-field = "Arrival-Date" ":" date-time
-
-   The date and time are expressed in RFC 822 'date-time' format, as
-   modified by [8].  Numeric timezones ([+/-]HHMM format) MUST be used.
-
-2.3 Per-Recipient DSN fields
-
-   A DSN contains information about attempts to deliver a message to one
-   or more recipients.  The delivery information for any particular
-   recipient is contained in a group of contiguous per-recipient fields.
-   Each group of per-recipient fields is preceded by a blank line.
-
-
-
-
-
-
-
-
-Moore & Vaudreuil           Standards Track                    [Page 14]
-
-RFC 1894             Delivery Status Notifications          January 1996
-
-
-   The syntax for the group of per-recipient fields is as follows:
-
-
-     per-recipient-fields =
-          [ original-recipient-field CRLF ]
-          final-recipient-field CRLF
-          action-field CRLF
-          status-field CRLF
-          [ remote-mta-field CRLF ]
-          [ diagnostic-code-field CRLF ]
-          [ last-attempt-date-field CRLF ]
-          [ will-retry-until-field CRLF ]
-          *( extension-field CRLF )
-
-2.3.1 Original-Recipient field
-
-   The Original-Recipient field indicates the original recipient address
-   as specified by the sender of the message for which the DSN is being
-   issued.
-
-     original-recipient-field =
-          "Original-Recipient" ":" address-type ";" generic-address
-
-     generic-address = *text
-
-   The address-type field indicates the type of the original recipient
-   address.  If the message originated within the Internet, the
-   address-type field field will normally be "rfc822", and the address
-   will be according to the syntax specified in [6].  The value
-   "unknown" should be used if the Reporting MTA cannot determine the
-   type of the original recipient address from the message envelope.
-
-   This field is optional.  It should be included only if the sender-
-   specified recipient address was present in the message envelope, such
-   as by the SMTP extensions defined in [4].  This address is the same
-   as that provided by the sender and can be used to automatically
-   correlate DSN reports and message transactions.
-
-2.3.2 Final-Recipient field
-
-   The Final-Recipient field indicates the recipient for which this set
-   of per-recipient fields applies.  This field MUST be present in each
-   set of per-recipient data.
-
-
-
-
-
-
-
-
-Moore & Vaudreuil           Standards Track                    [Page 15]
-
-RFC 1894             Delivery Status Notifications          January 1996
-
-
-   The syntax of the field is as follows:
-
-     final-recipient-field =
-          "Final-Recipient" ":" address-type ";" generic-address
-
-   The generic-address subfield of the Final-Recipient field MUST
-   contain the mailbox address of the recipient (from the transport
-   envelope) as it was when the message was accepted for delivery by the
-   Reporting MTA.
-
-   The Final-Recipient address may differ from the address originally
-   provided by the sender, because it may have been transformed during
-   forwarding and gatewaying into an totally unrecognizable mess.
-   However, in the absence of the optional Original-Recipient field, the
-   Final-Recipient field and any returned content may be the only
-   information available with which to correlate the DSN with a
-   particular message submission.
-
-   The address-type subfield indicates the type of address expected by
-   the reporting MTA in that context.  Recipient addresses obtained via
-   SMTP will normally be of address-type "rfc822".
-
-   NOTE: The Reporting MTA is not expected to ensure that the address
-   actually conforms to the syntax conventions of the address-type.
-   Instead, it MUST report exactly the address received in the envelope,
-   unless that address contains characters such as CR or LF which may
-   not appear in a DSN field.
-
-   Since mailbox addresses (including those used in the Internet) may be
-   case sensitive, the case of alphabetic characters in the address MUST
-   be preserved.
-
-2.3.3 Action field
-
-   The Action field indicates the action performed by the Reporting-MTA
-   as a result of its attempt to deliver the message to this recipient
-   address.  This field MUST be present for each recipient named in the
-   DSN.
-
-   The syntax for the action-field is:
-
-     action-field = "Action" ":" action-value
-
-     action-value =
-          "failed" / "delayed" / "delivered" / "relayed" / "expanded"
-
-
-
-
-
-
-Moore & Vaudreuil           Standards Track                    [Page 16]
-
-RFC 1894             Delivery Status Notifications          January 1996
-
-
-   The action-value may be spelled in any combination of upper and lower
-   case characters.
-
-"failed"     indicates that the message could not be delivered to the
-             recipient.  The Reporting MTA has abandoned any attempts to
-             deliver the message to this recipient.  No further
-             notifications should be expected.
-
-"delayed"    indicates that the Reporting MTA has so far been unable to
-             deliver or relay the message, but it will continue to
-             attempt to do so.  Additional notification messages may be
-             issued as the message is further delayed or successfully
-             delivered, or if delivery attempts are later abandoned.
-
-"delivered"  indicates that the message was successfully delivered to
-             the recipient address specified by the sender, which
-             includes "delivery" to a mailing list exploder.  It does
-             not indicate that the message has been read.  This is a
-             terminal state and no further DSN for this recipient should
-             be expected.
-
-"relayed"    indicates that the message has been relayed or gatewayed
-             into an environment that does not accept responsibility for
-             generating DSNs upon successful delivery.  This action-
-             value SHOULD NOT be used unless the sender has requested
-             notification of successful delivery for this recipient.
-
-"expanded"   indicates that the message has been successfully delivered
-             to the recipient address as specified by the sender, and
-             forwarded by the Reporting-MTA beyond that destination to
-             multiple additional recipient addresses.  An action-value
-             of "expanded" differs from "delivered" in that "expanded"
-             is not a terminal state. Further "failed" and/or "delayed"
-             notifications may be provided.
-
-             Using the terms "mailing list" and "alias" as defined in
-             [4], section 7.2.7:  An action-value of "expanded" is only
-             to be used when the message is delivered to a multiple-
-             recipient "alias".  An action-value of "expanded" SHOULD
-             NOT be used with a DSN issued on delivery of a message to a
-             "mailing list".
-
-   NOTE ON ACTION VS. STATUS CODES:  Although the 'action' field might
-   seem to be redundant with the 'status' field, this is not the case.
-   In particular, a "temporary failure" ("4") status code could be used
-   with an action-value of either "delayed" or "failed".  For example,
-   assume that an SMTP client repeatedly tries to relay a message to the
-   mail exchanger for a recipient, but fails because a query to a domain
-
-
-
-Moore & Vaudreuil           Standards Track                    [Page 17]
-
-RFC 1894             Delivery Status Notifications          January 1996
-
-
-   name server timed out.  After a few hours, it might issue a "delayed"
-   DSN to inform the sender that the message had not yet been delivered.
-   After a few days, the MTA might abandon its attempt to deliver the
-   message and return a "failed" DSN.  The status code (which would
-   begin with a "4" to indicate "temporary failure") would be the same
-   for both DSNs.
-
-   Another example for which the action and status codes may appear
-   contradictory:  If an MTA or mail gateway cannot deliver a message
-   because doing so would entail conversions resulting in an
-   unacceptable loss of information, it would issue a DSN with the
-   'action' field of "failure" and a status code of 'XXX'.  If the
-   message had instead been relayed, but with some loss of information,
-   it might generate a DSN with the same XXX status-code, but with an
-   action field of "relayed".
-
-2.3.4 Status field
-
-   The per-recipient Status field contains a transport-independent
-   status code which indicates the delivery status of the message to
-   that recipient.  This field MUST be present for each delivery attempt
-   which is described by a DSN.
-
-   The syntax of the status field is:
-
-     status-field = "Status" ":" status-code
-
-     status-code = DIGIT "." 1*3DIGIT "." 1*3DIGIT
-
-          ; White-space characters and comments are NOT allowed within a
-          ; status-code, though a comment enclosed in parentheses MAY follow
-          ; the last numeric subfield of the status-code.  Each numeric
-          ; subfield within the status-code MUST be expressed without
-          ; leading zero digits.
-
-   Status codes thus consist of three numerical fields separated by ".".
-   The first sub-field indicates whether the delivery attempt was
-   successful (2 = success, 4 = persistent temporary failure, 5 =
-   permanent failure).  The second sub-field indicates the probable
-   source of any delivery anomalies, and the third sub-field denotes a
-   precise error condition, if known.
-
-   The initial set of status-codes is defined in [5].
-
-
-
-
-
-
-
-
-Moore & Vaudreuil           Standards Track                    [Page 18]
-
-RFC 1894             Delivery Status Notifications          January 1996
-
-
-2.3.5 Remote-MTA field
-
-   The value associated with the Remote-MTA DSN field is a printable
-   ASCII representation of the name of the "remote" MTA that reported
-   delivery status to the "reporting" MTA.
-
-     remote-mta-field = "Remote-MTA" ":" mta-name-type ";" mta-name
-
-   NOTE: The Remote-MTA field preserves the "while talking to"
-   information that was provided in some pre-existing nondelivery
-   reports.
-
-   This field is optional.  It MUST NOT be included if no remote MTA was
-   involved in the attempted delivery of the message to that recipient.
-
-2.3.6 Diagnostic-Code field
-
-   For a "failed" or "delayed" recipient, the Diagnostic-Code DSN field
-   contains the actual diagnostic code issued by the mail transport.
-   Since such codes vary from one mail transport to another, the
-   diagnostic-type subfield is needed to specify which type of
-   diagnostic code is represented.
-
-     diagnostic-code-field =
-          "Diagnostic-Code" ":" diagnostic-type ";" *text
-
-   NOTE:  The information in the Diagnostic-Code field may be somewhat
-   redundant with that from the Status field.  The Status field is
-   needed so that any DSN, regardless of origin, may be understood by
-   any user agent or gateway that parses DSNs.  Since the Status code
-   will sometimes be less precise than the actual transport diagnostic
-   code, the Diagnostic-Code field is provided to retain the latter
-   information.  Such information may be useful in a trouble ticket sent
-   to the administrator of the Reporting MTA, or when tunneling foreign
-   nondelivery reports through DSNs.
-
-   If the Diagnostic Code was obtained from a Remote MTA during an
-   attempt to relay the message to that MTA, the Remote-MTA field should
-   be present.  When interpreting a DSN, the presence of a Remote-MTA
-   field indicates that the Diagnostic Code was issued by the Remote
-   MTA.  The absence of a Remote-MTA indicates that the Diagnostic Code
-   was issued by the Reporting MTA.
-
-   In addition to the Diagnostic-Code itself, additional textual
-   description of the diagnostic, MAY appear in a comment enclosed in
-   parentheses.
-
-
-
-
-
-Moore & Vaudreuil           Standards Track                    [Page 19]
-
-RFC 1894             Delivery Status Notifications          January 1996
-
-
-   This field is optional, because some mail systems supply no
-   additional information beyond that which is returned in the 'action'
-   and 'status' fields.  However, this field SHOULD be included if
-   transport-specific diagnostic information is available.
-
-2.3.7 Last-Attempt-Date field
-
-   The Last-Attempt-Date field gives the date and time of the last
-   attempt to relay, gateway, or deliver the message (whether successful
-   or unsuccessful) by the Reporting MTA.  This is not necessarily the
-   same as the value of the Date field from the header of the message
-   used to transmit this delivery status notification: In cases where
-   the DSN was generated by a gateway, the Date field in the message
-   header contains the time the DSN was sent by the gateway and the DSN
-   Last-Attempt-Date field contains the time the last delivery attempt
-   occurred.
-
-     last-attempt-date-field = "Last-Attempt-Date" ":" date-time
-
-   This field is optional.  It MUST NOT be included if the actual date
-   and time of the last delivery attempt are not available (which might
-   be the case if the DSN were being issued by a gateway).
-
-   The date and time are expressed in RFC 822 'date-time' format, as
-   modified by [8].  Numeric timezones ([+/-]HHMM format) MUST be used.
-
-   3.2.1.5 final-log-id field
-
-   The "final-log-id" field gives the final-log-id of the message that
-   was used by the final-mta.  This can be useful as an index to the
-   final-mta's log entry for that delivery attempt.
-
-     final-log-id-field = "Final-Log-ID" ":" *text
-
-   This field is optional.
-
-2.3.8 Will-Retry-Until field
-
-   For DSNs of type "delayed", the Will-Retry-Until field gives the date
-   after which the Reporting MTA expects to abandon all attempts to
-   deliver the message to that recipient.  The Will-Retry-Until field is
-   optional for "delay" DSNs, and MUST NOT appear in other DSNs.
-
-     will-retry-until-field = "Will-Retry-Until" ":" date-time
-
-   The date and time are expressed in RFC 822 'date-time' format, as
-   modified by [8].  Numeric timezones ([+/-]HHMM format) MUST be used.
-
-
-
-
-Moore & Vaudreuil           Standards Track                    [Page 20]
-
-RFC 1894             Delivery Status Notifications          January 1996
-
-
-2.4 Extension fields
-
-   Additional per-message or per-recipient DSN fields may be defined in
-   the future by later revisions or extensions to this specification.
-   Extension-field names beginning with "X-" will never be defined as
-   standard fields; such names are reserved for experimental use.  DSN
-   field names NOT beginning with "X-" MUST be registered with the
-   Internet Assigned Numbers Authority (IANA) and published in an RFC.
-
-   Extension DSN fields may be defined for the following reasons:
-
-   (a) To allow additional information from foreign delivery status
-       reports to be tunneled through Internet DSNs.  The names of such
-       DSN fields should begin with an indication of the foreign
-       environment name (e.g.  X400-Physical-Forwarding-Address).
-
-   (b) To allow the transmission of diagnostic information which is
-       specific to a particular mail transport protocol.  The names of
-       such DSN fields should begin with an indication of the mail
-       transport being used (e.g. SMTP-Remote-Recipient-Address).  Such
-       fields should be used for diagnostic purposes only and not by
-       user agents or mail gateways.
-
-   (c) To allow transmission of diagnostic information which is specific
-       to a particular message transfer agent (MTA).  The names of such
-       DSN fields should begin with an indication of the MTA
-       implementation which produced the DSN.  (e.g. Foomail-Queue-ID).
-
-   MTA implementors are encouraged to provide adequate information, via
-   extension fields if necessary, to allow an MTA maintainer to
-   understand the nature of correctable delivery failures and how to fix
-   them.  For example, if message delivery attempts are logged, the DSN
-   might include information which allows the MTA maintainer to easily
-   find the log entry for a failed delivery attempt.
-
-   If an MTA developer does not wish to register the meanings of such
-   extension fields, "X-" fields may be used for this purpose.  To avoid
-   name collisions, the name of the MTA implementation should follow the
-   "X-", (e.g.  "X-Foomail-Log-ID").
-
-3. Conformance and Usage Requirements
-
-   An MTA or gateway conforms to this specification if it generates DSNs
-   according to the protocol defined in this memo.  For MTAs and
-   gateways that do not support requests for positive delivery
-   notification (such as in [4]), it is sufficient that delivery failure
-   reports use this protocol.
-
-
-
-
-Moore & Vaudreuil           Standards Track                    [Page 21]
-
-RFC 1894             Delivery Status Notifications          January 1996
-
-
-   A minimal implementation of this specification need generate only the
-   Reporting-MTA per-message field, and the Final-Recipient, Action, and
-   Status fields for each attempt to deliver a message to a recipient
-   described by the DSN.  Generation of the other fields, when
-   appropriate, is strongly recommended.
-
-   MTAs and gateways MUST NOT generate the Original-Recipient field of a
-   DSN unless the mail transfer protocol provides the address originally
-   specified by the sender at the time of submission. (Ordinary SMTP
-   does not make that guarantee, but the SMTP extension defined in [4]
-   permits such information to be carried in the envelope if it is
-   available.)
-
-   Each sender-specified recipient address SHOULD result in at most one
-   "delivered" or "failed" DSN for that recipient.  If a positive DSN is
-   requested (e.g. one using NOTIFY=SUCCESS in SMTP) for a recipient
-   that is forwarded to multiple recipients of an "alias" (as defined in
-   [4], section 7.2.7), the forwarding MTA SHOULD normally issue a
-   "expanded" DSN for the originally-specified recipient and not
-   propagate the request for a DSN to the forwarding addresses.
-   Alternatively, the forwarding MTA MAY relay the request for a DSN to
-   exactly one of the forwarding addresses and not propagate the request
-   to the others.
-
-   By contrast, successful submission of a message to a mailing list
-   exploder is considered final delivery of the message.  Upon delivery
-   of a message to a recipient address corresponding to a mailing list
-   exploder, the Reporting MTA SHOULD issue an appropriate DSN exactly
-   as if the recipient address were that of an ordinary mailbox.
-
-   NOTE:  This is actually intended to make DSNs usable by mailing lists
-   themselves.  Any message sent to a mailing list subscriber should
-   have its envelope return address pointing to the list maintainer [see
-   RFC 1123, section 5.3.7(E)].  Since DSNs are sent to the envelope
-   return address, all DSNs resulting from delivery to the recipients of
-   a mailing list will be sent to the list maintainer.  The list
-   maintainer may elect to mechanically process DSNs upon receipt, and
-   thus automatically delete invalid addresses from the list.  (See
-   section 7 of this memo.)
-
-   This specification places no restrictions on the processing of DSNs
-   received by user agents or distribution lists.
-
-4. Security Considerations
-
-   The following security considerations apply when using DSNs:
-
-
-
-
-
-Moore & Vaudreuil           Standards Track                    [Page 22]
-
-RFC 1894             Delivery Status Notifications          January 1996
-
-
-4.1 Forgery
-
-   DSNs may be forged as easily as ordinary Internet electronic mail.
-   User agents and automatic mail handling facilities (such as mail
-   distribution list exploders) that wish to make automatic use of DSNs
-   should take appropriate precautions to minimize the potential damage
-   from denial-of-service attacks.
-
-   Security threats related to forged DSNs include the sending of:
-
-(a) A falsified delivery notification when the message is not delivered
-    to the indicated recipient,
-(b) A falsified non-delivery notification when the message was in fact
-    delivered to the indicated recipient,
-(c) A falsified Final-Recipient address,
-(d) A falsified Remote-MTA identification,
-(e) A falsified relay notification when the message is "dead ended".
-(f) Unsolicited DSNs
-
-4.2 Confidentiality
-
-   Another dimension of security is confidentiality.  There may be cases
-   in which a message recipient is autoforwarding messages but does not
-   wish to divulge the address to which the messages are autoforwarded.
-   The desire for such confidentiality will probably be heightened as
-   "wireless mailboxes", such as pagers, become more widely used as
-   autoforward addresses.
-
-   MTA authors are encouraged to provide a mechanism which enables the
-   end user to preserve the confidentiality of a forwarding address.
-   Depending on the degree of confidentiality required, and the nature
-   of the environment to which a message were being forwarded, this
-   might be accomplished by one or more of:
-
-(a) issuing a "relayed" DSN (if a positive DSN was requested) when a
-    message is forwarded to a confidential forwarding address, and
-    disabling requests for positive DSNs for the forwarded message,
-
-(b) declaring the message to be delivered, issuing a "delivered" DSN,
-    re-sending the message to the confidential forwarding address, and
-    arranging for no DSNs to be issued for the re-sent message,
-
-(c) omitting "Remote-*" or extension fields of a DSN whenever they would
-    otherwise contain confidential information (such as a confidential
-    forwarding address),
-
-(d) for messages forwarded to a confidential address, setting the
-    envelope return address (e.g. SMTP MAIL FROM address) to the NULL
-
-
-
-Moore & Vaudreuil           Standards Track                    [Page 23]
-
-RFC 1894             Delivery Status Notifications          January 1996
-
-
-    reverse-path ("<>") (so that no DSNs would be sent from a downstream
-    MTA to the original sender),
-
-(e) for messages forwarded to a confidential address, disabling delivery
-    notifications for the forwarded message (e.g. if the "next-hop" MTA
-    uses ESMTP and supports the DSN extension, by using the NOTIFY=NEVER
-    parameter to the RCPT command), or
-
-(f) when forwarding mail to a confidential address, having the
-    forwarding MTA rewrite the envelope return address for the forwarded
-    message and attempt delivery of that message as if the forwarding
-    MTA were the originator.  On its receipt of final delivery status,
-    the forwarding MTA would issue a DSN to the original sender.
-
-   In general, any optional DSN field may be omitted if the Reporting
-   MTA site determines that inclusion of the field would impose too
-   great a compromise of site confidentiality.  The need for such
-   confidentiality must be balanced against the utility of the omitted
-   information in trouble reports and DSNs gatewayed to foreign
-   environments.
-
-   Implementors are cautioned that many existing MTAs will send
-   nondelivery notifications to a return address in the message header
-   (rather than to the one in the envelope), in violation of SMTP and
-   other protocols.  If a message is forwarded through such an MTA, no
-   reasonable action on the part of the forwarding MTA will prevent the
-   downstream MTA from compromising the forwarding address.  Likewise,
-   if the recipient's MTA automatically responds to messages based on a
-   request in the message header (such as the nonstandard, but widely
-   used, Return-Receipt-To extension header), it will also compromise
-   the forwarding address.
-
-4.3 Non-Repudiation
-
-   Within the framework of today's internet mail, the DSNs defined in
-   this memo provide valuable information to the mail user; however,
-   even a "failed" DSN can not be relied upon as a guarantee that a
-   message was not received by the recipient.  Even if DSNs are not
-   actively forged, conditions exist under which a message can be
-   delivered despite the fact that a failure DSN was issued.
-
-
-
-
-
-
-
-
-
-
-
-Moore & Vaudreuil           Standards Track                    [Page 24]
-
-RFC 1894             Delivery Status Notifications          January 1996
-
-
-   For example, a race condition in the SMTP protocol allows for the
-   duplication of messages if the connection is dropped following a
-   completed DATA command, but before a response is seen by the SMTP
-   client.  This will cause the SMTP client to retransmit the message,
-   even though the SMTP server has already accepted it.[9] If one of
-   those delivery attempts succeeds and the other one fails, a "failed"
-   DSN could be issued even though the message actually reached the
-   recipient.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Moore & Vaudreuil           Standards Track                    [Page 25]
-
-RFC 1894             Delivery Status Notifications          January 1996
-
-
-5. Appendix - collected grammar
-
-   NOTE:  The following lexical tokens are defined in RFC 822:  atom,
-   CHAR, comment, CR, CRLF, DIGIT, LF, linear-white-space, SPACE, text.
-   The date-time lexical token is defined in [8].
-
-action-field = "Action" ":" action-value
-
-action-value =
-     "failed" / "delayed" / "delivered" / "relayed" / "expanded"
-
-address-type = atom
-
-arrival-date-field = "Arrival-Date" ":" date-time
-
-delivery-status-content =
-     per-message-fields 1*( CRLF per-recipient-fields )
-
-diagnostic-code-field =
-     "Diagnostic-Code" ":" diagnostic-type ";" *text
-
-diagnostic-type = atom
-
-dsn-gateway-field = "DSN-Gateway" ":" mta-name-type ";" mta-name
-
-envelope-id = *text
-
-extension-field = extension-field-name ":" *text
-
-extension-field-name = atom
-
-final-recipient-field =
-     "Final-Recipient" ":" address-type ";" generic-address
-
-generic-address = *text
-
-last-attempt-date-field = "Last-Attempt-Date" ":" date-time
-
-mta-name = *text
-
-mta-name-type = atom
-
-original-envelope-id-field =
-     "Original-Envelope-Id" ":" envelope-id
-
-original-recipient-field =
-     "Original-Recipient" ":" address-type ";" generic-address
-
-
-
-
-Moore & Vaudreuil           Standards Track                    [Page 26]
-
-RFC 1894             Delivery Status Notifications          January 1996
-
-
-per-message-fields =
-     [ original-envelope-id-field CRLF ]
-     reporting-mta-field CRLF
-     [ dsn-gateway-field CRLF ]
-     [ received-from-mta-field CRLF ]
-     [ arrival-date-field CRLF ]
-     *( extension-field CRLF )
-
-per-recipient-fields =
-     [ original-recipient-field CRLF ]
-     final-recipient-field CRLF
-     action-field CRLF
-     status-field CRLF
-     [ remote-mta-field CRLF ]
-     [ diagnostic-code-field CRLF ]
-     [ last-attempt-date-field CRLF ]
-     [ will-retry-until-field CRLF ]
-     *( extension-field CRLF )
-
-received-from-mta-field =
-     "Received-From-MTA" ":" mta-name-type ";" mta-name
-
-remote-mta-field = "Remote-MTA" ":" mta-name-type ";" mta-name
-
-reporting-mta-field =
-     "Reporting-MTA" ":" mta-name-type ";" mta-name
-
-status-code = DIGIT "." 1*3DIGIT "." 1*3DIGIT
-
-     ; White-space characters and comments are NOT allowed within a
-     ; status-code, though a comment enclosed in parentheses MAY follow
-     ; the last numeric subfield of the status-code.  Each numeric
-     ; subfield within the status-code MUST be expressed without
-     ; leading zero digits.
-
-status-field = "Status" ":" status-code
-
-will-retry-until-field = "Will-Retry-Until" ":" date-time
-
-
-
-
-
-
-
-
-
-
-
-
-
-Moore & Vaudreuil           Standards Track                    [Page 27]
-
-RFC 1894             Delivery Status Notifications          January 1996
-
-
-6. Appendix - Guidelines for gatewaying DSNs
-
-   NOTE:  This section provides non-binding recommendations for the
-   construction of mail gateways that wish to provide semi-transparent
-   delivery reports between the Internet and another electronic mail
-   system.  Specific DSN gateway requirements for a particular pair of
-   mail systems may be defined by other documents.
-
-6.1 Gatewaying from other mail systems to DSNs
-
-   A mail gateway may issue a DSN to convey the contents of a "foreign"
-   delivery or non-delivery notification over Internet mail.  When there
-   are appropriate mappings from the foreign notification elements to
-   DSN fields, the information may be transmitted in those DSN fields.
-   Additional information (such as might be useful in a trouble ticket
-   or needed to tunnel the foreign notification through the Internet)
-   may be defined in extension DSN fields.  (Such fields should be given
-   names that identify the foreign mail protocol, e.g. X400-* for X.400
-   NDN or DN protocol elements)
-
-   The gateway must attempt to supply reasonable values for the
-   Reporting-MTA, Final-Recipient, Action, and Status fields.  These
-   will normally be obtained by translating the values from the remote
-   delivery or non-delivery notification into their Internet-style
-   equivalents.  However, some loss of information is to be expected.
-   For example, the set of status-codes defined for DSNs may not be
-   adequate to fully convey the delivery diagnostic code from the
-   foreign system.  The gateway should assign the most precise code
-   which describes the failure condition, falling back on "generic"
-   codes such as 2.0.0 (success), 4.0.0 (temporary failure), and 5.0.0
-   (permanent failure) when necessary.  The actual foreign diagnostic
-   code should be retained in the Diagnostic-Code field (with an
-   appropriate diagnostic-type value) for use in trouble tickets or
-   tunneling.
-
-   The sender-specified recipient address, and the original envelope-id,
-   if present in the foreign transport envelope, should be preserved in
-   the Original-Recipient and Original-Envelope-ID fields.
-
-   The gateway should also attempt to preserve the "final" recipient
-   addresses and MTA names from the foreign system.  Whenever possible,
-   foreign protocol elements should be encoded as meaningful printable
-   ASCII strings.
-
-   For DSNs produced from foreign delivery or nondelivery notifications,
-   the name of the gateway MUST appear in the DSN-Gateway field of the
-   DSN.
-
-
-
-
-Moore & Vaudreuil           Standards Track                    [Page 28]
-
-RFC 1894             Delivery Status Notifications          January 1996
-
-
-6.2 Gatewaying from DSNs to other mail systems
-
-   It may be possible to gateway DSNs from the Internet into a foreign
-   mail system.  The primary purpose of such gatewaying is to convey
-   delivery status information in a form that is usable by the
-   destination system.  A secondary purpose is to allow "tunneling" of
-   DSNs through foreign mail systems, in case the DSN may be gatewayed
-   back into the Internet.
-
-   In general, the recipient of the DSN (i.e., the sender of the
-   original message) will want to know, for each recipient: the closest
-   available approximation to the original recipient address, the
-   delivery status (success, failure, or temporary failure), and for
-   failed deliveries, a diagnostic code that describes the reason for
-   the failure.
-
-   If possible, the gateway should attempt to preserve the Original-
-   Recipient address and Original-Envelope-ID (if present), in the
-   resulting foreign delivery status report.
-
-   When reporting delivery failures, if the diagnostic-type subfield of
-   the Diagnostic-Code field indicates that the original diagnostic code
-   is understood by the destination environment, the information from
-   the Diagnostic-Code field should be used.  Failing that, the
-   information in the Status field should be mapped into the closest
-   available diagnostic code used in the destination environment.
-
-   If it is possible to tunnel a DSN through the destination
-   environment, the gateway specification may define a means of
-   preserving the DSN information in the delivery status reports used by
-   that environment.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Moore & Vaudreuil           Standards Track                    [Page 29]
-
-RFC 1894             Delivery Status Notifications          January 1996
-
-
-7. Appendix - Guidelines for use of DSNs by mailing list exploders
-
-   NOTE: This section pertains only to the use of DSNs by "mailing
-   lists" as defined in [4], section 7.2.7.
-
-   DSNs are designed to be used by mailing list exploders to allow them
-   to detect and automatically delete recipients for whom mail delivery
-   fails repeatedly.
-
-   When forwarding a message to list subscribers, the mailing list
-   exploder should always set the envelope return address (e.g. SMTP
-   MAIL FROM address) to point to a special address which is set up to
-   received nondelivery reports.  A "smart" mailing list exploder can
-   therefore intercept such nondelivery reports, and if they are in the
-   DSN format, automatically examine them to determine for which
-   recipients a message delivery failed or was delayed.
-
-   The Original-Recipient field should be used if available, since it
-   should exactly match the subscriber address known to the list.  If
-   the Original-Recipient field is not available, the recipient field
-   may resemble the list subscriber address.  Often, however, the list
-   subscriber will have forwarded his mail to a different address, or
-   the address may be subject to some re-writing, so heuristics may be
-   required to successfully match an address from the recipient field.
-   Care is needed in this case to minimize the possibility of false
-   matches.
-
-   The reason for delivery failure can be obtained from the Status and
-   Action fields, and from the Diagnostic-Code field (if the status-type
-   is recognized).  Reports for recipients with action values other than
-   "failed" can generally be ignored; in particular, subscribers should
-   not be removed from a list due to "delayed" reports.
-
-   In general, almost any failure status code (even a "permanent" one)
-   can result from a temporary condition.  It is therefore recommended
-   that a list exploder not delete a subscriber based on any single
-   failure DSN (regardless of the status code), but only on the
-   persistence of delivery failure over a period of time.
-
-   However, some kinds of failures are less likely than others to have
-   been caused by temporary conditions, and some kinds of failures are
-   more likely to be noticed and corrected quickly than others.  Once
-   more precise status codes are defined, it may be useful to
-   differentiate between the status codes when deciding whether to
-   delete a subscriber.  For example, on a list with a high message
-   volume, it might be desirable to temporarily suspend delivery to a
-   recipient address which causes repeated "temporary" failures, rather
-   than simply deleting the recipient.  The duration of the suspension
-
-
-
-Moore & Vaudreuil           Standards Track                    [Page 30]
-
-RFC 1894             Delivery Status Notifications          January 1996
-
-
-   might depend on the type of error.  On the other hand, a "user
-   unknown" error which persisted for several days could be considered a
-   reliable indication that address were no longer valid.
-
-8. Appendix - IANA registration forms for DSN types
-
-   The forms below are for use when registering a new address-type,
-   diagnostic-type, or MTA-name-type with the Internet Assigned Numbers
-   Authority (IANA).  Each piece of information requested by a
-   registration form may be satisfied either by providing the
-   information on the form itself, or by including a reference to a
-   published, publicly available specification which includes the
-   necessary information.  IANA MAY reject DSN type registrations
-   because of incomplete registration forms, imprecise specifications,
-   or inappropriate type names.
-
-   To register a DSN type, complete the applicable form below and send
-   it via Internet electronic mail to <IANA@IANA.ORG>.
-
-8.1 IANA registration form for address-type
-
-   A registration for a DSN address-type MUST include the following
-   information:
-
-(a) The proposed address-type name.
-
-(b) The syntax for mailbox addresses of this type, specified using BNF,
-    regular expressions, ASN.1, or other non-ambiguous language.
-
-(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.
-
-(d) [optional] A specification for how addresses of this type are to be
-    translated to and from Internet electronic mail addresses.
-
-8.2 IANA registration form for diagnostic-type
-
-   A registration for a DSN address-type MUST include the following
-   information:
-
-(a) The proposed diagnostic-type name.
-
-(b) A description of the syntax to be used for expressing diagnostic
-    codes of this type as graphic characters from the US-ASCII
-    repertoire.
-
-
-
-
-Moore & Vaudreuil           Standards Track                    [Page 31]
-
-RFC 1894             Delivery Status Notifications          January 1996
-
-
-(c) A list of valid diagnostic codes of this type and the meaning of
-    each code.
-
-(d) [optional] A specification for mapping from diagnostic codes of this
-    type to DSN status codes (as defined in [5]).
-
-8.3 IANA registration form for MTA-name-type
-
-   A registration for a DSN MTA-name-type must include the following
-   information:
-
-(a) The proposed MTA-name-type name.
-
-(b) A description of the syntax of MTA names of this type, using BNF,
-    regular expressions, ASN.1, or other non-ambiguous language.
-
-(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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Moore & Vaudreuil           Standards Track                    [Page 32]
-
-RFC 1894             Delivery Status Notifications          January 1996
-
-
-9. Appendix - Examples
-
-   NOTE:  These examples are provided as illustration only, and are not
-   considered part of the DSN protocol specification.  If an example
-   conflicts with the protocol definition above, the example is wrong.
-
-   Likewise, the use of *-type subfield names or extension fields in
-   these examples is not to be construed as a definition for those type
-   names or extension fields.
-
-   These examples were manually translated from bounced messages using
-   whatever information was available.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Moore & Vaudreuil           Standards Track                    [Page 33]
-
-RFC 1894             Delivery Status Notifications          January 1996
-
-
-9.1  This is a simple DSN issued after repeated attempts
-     to deliver a message failed.  In this case, the DSN is
-     issued by the same MTA from which the message was originated.
-
-
-   Date: Thu, 7 Jul 1994 17:16:05 -0400
-   From: Mail Delivery Subsystem <MAILER-DAEMON@CS.UTK.EDU>
-   Message-Id: <199407072116.RAA14128@CS.UTK.EDU>
-   Subject: Returned mail: Cannot send message for 5 days
-   To: <owner-info-mime@cs.utk.edu>
-   MIME-Version: 1.0
-   Content-Type: multipart/report; report-type=delivery-status;
-         boundary="RAA14128.773615765/CS.UTK.EDU"
-
-   --RAA14128.773615765/CS.UTK.EDU
-
-   The original message was received at Sat, 2 Jul 1994 17:10:28 -0400
-   from root@localhost
-
-      ----- The following addresses had delivery problems -----
-   <louisl@larry.slip.umd.edu>  (unrecoverable error)
-
-      ----- Transcript of session follows -----
-   <louisl@larry.slip.umd.edu>... Deferred: Connection timed out
-         with larry.slip.umd.edu.
-   Message could not be delivered for 5 days
-   Message will be deleted from queue
-
-   --RAA14128.773615765/CS.UTK.EDU
-   content-type: message/delivery-status
-
-   Reporting-MTA: dns; cs.utk.edu
-
-   Original-Recipient: rfc822;louisl@larry.slip.umd.edu
-   Final-Recipient: rfc822;louisl@larry.slip.umd.edu
-   Action: failed
-   Status: 4.0.0
-   Diagnostic-Code: smtp; 426 connection timed out
-   Last-Attempt-Date: Thu, 7 Jul 1994 17:15:49 -0400
-
-   --RAA14128.773615765/CS.UTK.EDU
-   content-type: message/rfc822
-
-   [original message goes here]
-   --RAA14128.773615765/CS.UTK.EDU--
-
-
-
-
-
-
-Moore & Vaudreuil           Standards Track                    [Page 34]
-
-RFC 1894             Delivery Status Notifications          January 1996
-
-
-9.2  This is another DSN issued by the sender's MTA, which
-     contains details of multiple delivery attempts.  Some of
-     these were detected locally, and others by a remote MTA.
-
-
-   Date: Fri, 8 Jul 1994 09:21:47 -0400
-   From: Mail Delivery Subsystem <MAILER-DAEMON@CS.UTK.EDU>
-   Subject: Returned mail: User unknown
-   To: <owner-ups-mib@CS.UTK.EDU>
-   MIME-Version: 1.0
-   Content-Type: multipart/report; report-type=delivery-status;
-         boundary="JAA13167.773673707/CS.UTK.EDU"
-
-   --JAA13167.773673707/CS.UTK.EDU
-   content-type: text/plain; charset=us-ascii
-
-      ----- The following addresses had delivery problems -----
-   <arathib@vnet.ibm.com>  (unrecoverable error)
-   <wsnell@sdcc13.ucsd.edu>  (unrecoverable error)
-
-   --JAA13167.773673707/CS.UTK.EDU
-   content-type: message/delivery-status
-
-   Reporting-MTA: dns; cs.utk.edu
-
-   Original-Recipient: rfc822;arathib@vnet.ibm.com
-   Final-Recipient: rfc822;arathib@vnet.ibm.com
-   Action: failed
-   Status: 5.0.0 (permanent failure)
-   Diagnostic-Code: smtp;
-    550 'arathib@vnet.IBM.COM' is not a registered gateway user
-   Remote-MTA: dns; vnet.ibm.com
-
-   Original-Recipient: rfc822;johnh@hpnjld.njd.hp.com
-   Final-Recipient: rfc822;johnh@hpnjld.njd.hp.com
-   Action: delayed
-   Status: 4.0.0 (hpnjld.njd.jp.com: host name lookup failure)
-
-   Original-Recipient: rfc822;wsnell@sdcc13.ucsd.edu
-   Final-Recipient: rfc822;wsnell@sdcc13.ucsd.edu
-   Action: failed
-   Status: 5.0.0
-   Diagnostic-Code: smtp; 550 user unknown
-   Remote-MTA: dns; sdcc13.ucsd.edu
-
-   --JAA13167.773673707/CS.UTK.EDU
-   content-type: message/rfc822
-
-
-
-
-Moore & Vaudreuil           Standards Track                    [Page 35]
-
-RFC 1894             Delivery Status Notifications          January 1996
-
-
-   [original message goes here]
-   --JAA13167.773673707/CS.UTK.EDU--
-
-
-9.3 A delivery report generated by Message Router (MAILBUS) and
-    gatewayed by PMDF_MR to a DSN.  In this case the gateway did not
-    have sufficient information to supply an original-recipient address.
-
-
-
-   Disclose-recipients: prohibited
-   Date: Fri, 08 Jul 1994 09:21:25 -0400 (EDT)
-   From: Message Router Submission Agent <AMMGR@corp.timeplex.com>
-   Subject: Status of : Re: Battery current sense
-   To: owner-ups-mib@CS.UTK.EDU
-   Message-id: <01HEGJ0WNBY28Y95LN@mr.timeplex.com>
-   MIME-version: 1.0
-   content-type: multipart/report; report-type=delivery-status;
-         boundary="84229080704991.122306.SYS30"
-
-   --84229080704991.122306.SYS30
-   content-type: text/plain
-
-   Invalid address - nair_s
-   %DIR-E-NODIRMTCH, No matching Directory Entry found
-
-   --84229080704991.122306.SYS30
-   content-type: message/delivery-status
-
-   Reporting-MTA: mailbus; SYS30
-
-   Final-Recipient: unknown; nair_s
-   Status: 5.0.0 (unknown permanent failure)
-   Action: failed
-
-   --84229080704991.122306.SYS30--
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Moore & Vaudreuil           Standards Track                    [Page 36]
-
-RFC 1894             Delivery Status Notifications          January 1996
-
-
-9.4 A delay report from a multiprotocol MTA.  Note that there is no
-    returned content, so no third body part appears in the DSN.
-
-   From: <postmaster@nsfnet-relay.ac.uk>
-   Message-Id: <199407092338.TAA23293@CS.UTK.EDU>
-   Received: from nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk
-             id <g.12954-0@sun2.nsfnet-relay.ac.uk>;
-   Sun, 10 Jul 1994 00:36:51 +0100
-   To: owner-info-mime@cs.utk.edu
-   Date: Sun, 10 Jul 1994 00:36:51 +0100
-   Subject: WARNING: message delayed at "nsfnet-relay.ac.uk"
-   content-type: multipart/report; report-type=delivery-status;
-         boundary=foobar
-
-   --foobar
-   content-type: text/plain
-
-   The following message:
-
-   UA-ID:  Reliable PC (...
-   Q-ID:   sun2.nsf:77/msg.11820-0
-
-   has not been delivered to the intended recipient:
-
-   thomas@de-montfort.ac.uk
-
-   despite repeated delivery attempts over the past 24 hours.
-
-   The  usual cause of this problem is that the remote system is
-   temporarily unavailable.
-
-   Delivery will continue to be attempted up to a total elapsed
-   time of  168 hours, ie 7 days.
-
-   You  will  be  informed  if  delivery proves to be impossible
-   within this time.
-
-   Please quote the Q-ID in any queries regarding this mail.
-
-   --foobar
-   content-type: message/delivery-status
-
-   Reporting-MTA: dns; sun2.nsfnet-relay.ac.uk
-
-   Final-Recipient: rfc822;thomas@de-montfort.ac.uk
-   Status: 4.0.0 (unknown temporary failure)
-   Action: delayed
-
-
-
-
-Moore & Vaudreuil           Standards Track                    [Page 37]
-
-RFC 1894             Delivery Status Notifications          January 1996
-
-
-   --foobar--
-
-10. Acknowledgments
-
-   The authors wish to thank the following people for their reviews of
-   earlier drafts of this document and their suggestions for
-   improvement:  Eric Allman, Harald Alvestrand, Allan Cargille, Jim
-   Conklin, Peter Cowen, Dave Crocker, Roger Fajman, Ned Freed, Marko
-   Kaittola, Steve Kille, John Klensin, John Gardiner Myers, Mark
-   Nahabedian, Julian Onions, Jacob Palme, Jean Charles Roy, and Gregory
-   Sheehan.
-
-11. References
-
-[1] Borenstein, N., Freed, N. "Multipurpose Internet Mail Extensions",
-    RFC 1521, Bellcore, Innosoft, September 1993.
-
-[2] Vaudreuil, G., "The Multipart/Report Content Type for the Reporting
-    of Mail System Administrative Messages", RFC 1892, Octal Network
-    Services, January 1996.
-
-[3] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
-    USC/Information Sciences Institute, August 1982.
-
-[4] Moore, K., "SMTP Service Extension for Delivery Status
-    Notifications", RFC 1891, University of Tennessee, January 1996.
-
-[5] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893, Octal
-    Network Services, January 1996.
-
-[6] Crocker, D., "Standard for the Format of ARPA Internet Text
-    Messages", STD 11, RFC 822, UDEL, August 1982.
-
-[7] Moore, K. "MIME (Multipurpose Internet Mail Extensions) Part Two:
-    Message Header Extensions for Non-Ascii Text", RFC 1522, University
-    of Tennessee, September 1993.
-
-[8] Braden, R. (ed.)  "Requirements for Internet Hosts - Application and
-    Support", STD 3, RFC 1123, USC/Information Sciences Institute,
-    October 1989.
-
-[9] Partridge, C., "Duplicate Messages and SMTP", RFC 1047, BBN,
-    February 1988.
-
-
-
-
-
-
-
-
-Moore & Vaudreuil           Standards Track                    [Page 38]
-
-RFC 1894             Delivery Status Notifications          January 1996
-
-
-11. Authors' Addresses
-
-   Keith Moore
-   University of Tennessee
-   107 Ayres Hall
-   Knoxville, TN 37996-1301
-   USA
-
-   EMail: moore@cs.utk.edu
-   Phone: +1 615 974 3126
-   Fax: +1 615 974 8296
-
-
-   Gregory M. Vaudreuil
-   Octel Network Services
-   17080 Dallas Parkway
-   Dallas, TX 75248-1905
-   USA
-
-   EMail: Greg.Vaudreuil@Octel.Com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Moore & Vaudreuil           Standards Track                    [Page 39]
-
diff --git a/RFC/rfc1938.txt b/RFC/rfc1938.txt
deleted file mode 100644
index 5d3a9002..00000000
--- a/RFC/rfc1938.txt
+++ /dev/null
@@ -1,1011 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          N. Haller
-Request for Comments: 1938                                      Bellcore
-Category: Standards Track                                        C. Metz
-                                              Kaman Sciences Corporation
-                                                                May 1996
-
-
-                       A One-Time Password System
-
-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.0 ABSTRACT
-
-   This document describes a one-time password authentication system
-   (OTP). The system provides authentication for system access (login)
-   and other applications requiring authentication that is secure
-   against passive attacks based on replaying captured reusable
-   passwords. OTP evolved from the S/KEY (S/KEY is a trademark of
-   Bellcore) One-Time Password System that was released by Bellcore and
-   is described in references [3] and [5].
-
-2.0 OVERVIEW
-
-   One form of attack on networked computing systems is eavesdropping on
-   network connections to obtain authentication information such as the
-   login IDs and passwords of legitimate users. Once this information is
-   captured, it can be used at a later time to gain access to the
-   system. One-time password systems are designed to counter this type
-   of attack, called a "replay attack" [4].
-
-   The authentication system described in this document uses a secret
-   pass-phrase to generate a sequence of one-time (single use)
-   passwords.  With this system, the user's secret pass-phrase never
-   needs to cross the network at any time such as during authentication
-   or during pass-phrase changes. Thus, it is not vulnerable to replay
-   attacks.  Added security is provided by the property that no secret
-   information need be stored on any system, including the server being
-   protected.
-
-   The OTP system protects against external passive attacks against the
-   authentication subsystem. It does not prevent a network eavesdropper
-   from gaining access to private information and does not provide
-
-
-
-Haller & Metz               Standards Track                     [Page 1]
-
-RFC 1938               A One-Time Password System               May 1996
-
-
-   protection against either "social engineering" or active attacks [9].
-
-3.0 INTRODUCTION
-
-   There are two entities in the operation of the OTP one-time password
-   system. The generator must produce the appropriate one-time password
-   from the user's secret pass-phrase and from information provided in
-   the challenge from the server. The server must send a challenge that
-   includes the appropriate generation parameters to the generator, must
-   verify the one-time password received, must store the last valid
-   one-time password it received, and must store the corresponding one-
-   time password sequence number. The server must also facilitate the
-   changing of the user's secret pass-phrase in a secure manner.
-
-   The OTP system generator passes the user's secret pass-phrase, along
-   with a seed received from the server as part of the challenge,
-   through multiple iterations of a secure hash function to produce a
-   one-time password. After each successful authentication, the number
-   of secure hash function iterations is reduced by one.  Thus, a unique
-   sequence of passwords is generated.  The server verifies the one-time
-   password received from the generator by computing the secure hash
-   function once and comparing the result with the previously accepted
-   one-time password.  This technique was first suggested by Leslie
-   Lamport [1].
-
-4.0 REQUIREMENTS TERMINOLOGY
-
-   In this document, the words that are used to define the significance
-   of each particular requirement are usually capitalized.  These words
-   are:
-
-    - 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 might
-      exist valid reasons in particular circumstances to ignore this
-      item, but the full implications should be understood and the
-      case carefully weighed before taking a different course.
-
-    - MAY
-
-      This word or the adjective "OPTIONAL" means that this item is
-      truly optional.  One vendor might choose to include the item
-      because a particular marketplace requires it or because it
-
-
-
-Haller & Metz               Standards Track                     [Page 2]
-
-RFC 1938               A One-Time Password System               May 1996
-
-
-      enhances the product, for example; another vendor may omit the
-      same item.
-
-5.0 SECURE HASH FUNCTION
-
-   The security of the OTP system is based on the non-invertability of a
-   secure hash function. Such a function must be tractable to compute in
-   the forward direction, but computationally infeasible to invert.
-
-   The interfaces are currently defined for three such hash algorithms,
-   MD4 [2] and MD5 [6] by Ronald Rivest, and SHA [7] by NIST.  All
-   conforming implementations of both server and generators MUST support
-   MD5.  They SHOULD support SHA and MAY also support MD4.  Clearly, the
-   generator and server must use the same algorithm in order to
-   interoperate. Other hash algorithms may be specified for use with
-   this system by publishing the appropriate interfaces.
-
-   The secure hash algorithms listed above have the property that they
-   accept an input that is arbitrarily long and produce a fixed size
-   output. The OTP system folds this output to 64 bits using the
-   algorithms in the Appendix A. 64 bits is also the length of the one-
-   time passwords. This is believed to be long enough to be secure and
-   short enough to be entered manually (see below, Form of Output) when
-   necessary.
-
-6.0 GENERATION OF ONE-TIME PASSWORDS
-
-   This section describes the generation of the one-time passwords.
-   This process consists of an initial step in which all inputs are
-   combined, a computation step where the secure hash function is
-   applied a specified number of times, and an output function where the
-   64 bit one-time password is converted to a human readable form.
-
-   Initial Step
-
-      In principle, the user's secret pass-phrase may be of any length.
-      To reduce the risk from techniques such as exhaustive search or
-      dictionary attacks, character string pass-phrases MUST contain at
-      least 10 characters (see Form of Inputs below).  All
-      implementations MUST support a pass-phrases of at least 63
-      characters.  The secret pass-phrase is frequently, but is not
-      required to be, textual information provided by a user.
-
-      In this step, the pass phrase is concatenated with a seed that is
-      transmitted from the server in clear text. This non-secret seed
-      allows clients to use the same secret pass-phrase on multiple
-      machines (using different seeds) and to safely recycle their
-      secret pass-phrases by changing the seed.
-
-
-
-Haller & Metz               Standards Track                     [Page 3]
-
-RFC 1938               A One-Time Password System               May 1996
-
-
-      The result of the concatenation is passed through the secure hash
-      function and then is reduced to 64 bits using one of the function
-      dependent algorithms shown in Appendix A.
-
-   Computation Step
-
-      A sequence of one-time passwords is produced by applying the
-      secure hash function multiple times to the output of the initial
-      step (called S). That is, the first one-time password to be used
-      is produced by passing S through the secure hash function a number
-      of times (N) specified by the user. The next one-time password to
-      be used is generated by passing S though the secure hash function
-      N-1 times. An eavesdropper who has monitored the transmission of a
-      one- time password would not be able to generate the next required
-      password because doing so would mean inverting the hash function.
-
-   Form of Inputs
-
-      The secret pass-phrase is seen only by the OTP generator. To allow
-      interchangeability of generators, all generators MUST support a
-      secret pass-phrase of 10 to 63 characters. Implementations MAY
-      support a longer pass-phrase, but such implementations risk the
-      loss of interchangeability with implementations supporting only
-      the minimum.
-
-      The seed MUST consist of purely alphanumeric characters and MUST
-      be of one to 16 characters in length. The seed is a string of
-      characters that MUST not contain any blanks and SHOULD consist of
-      strictly alphanumeric characters from the ISO-646 Invariant Code
-      Set.  The seed MUST be case insensitive and MUST be internally
-      converted to lower case before it is processed.
-
-      The sequence number and seed together constitute a larger unit of
-      data called the challenge. The challenge gives the generator the
-      parameters it needs to calculate the correct one-time password
-      from the secret pass-phrase. The challenge MUST be in a standard
-      syntax so that automated generators can recognize the challenge in
-      context and extract these parameters. The syntax of the challenge
-      is:
-
-          otp-<algorithm identifier> <sequence integer> <seed>
-
-      The three tokens MUST be separated by a white space (defined as
-      any number of spaces and/or tabs) and the entire challenge string
-      MUST be terminated with either a space or a new line. The string
-      "otp-" MUST be in lower case.  The algorithm identifier is case
-      sensitive (the existing identifiers are all lower case), and the
-      seed is case insensitive and converted before use to lower case.
-
-
-
-Haller & Metz               Standards Track                     [Page 4]
-
-RFC 1938               A One-Time Password System               May 1996
-
-
-      If additional algorithms are defined, appropriate identifiers
-      (short, but not limited to three or four characters) must be
-      defined. The currently defined algorithm identifiers are:
-
-      md4        MD4 Message Digest
-      md5        MD5 Message Digest
-      sha1       NIST Secure Hash Algorithm Revision 1
-
-      An example of an OTP challenge is:   otp-md5 487 dog2
-
-   Form of Output
-
-      The one-time password generated by the above procedure is 64 bits
-      in length. Entering a 64 bit number is a difficult and error prone
-      process. Some generators insert this password into the input
-      stream and some others make it available for system "cut and
-      paste." Still other arrangements require the one-time password to
-      be entered manually. The OTP system is designed to facilitate this
-      manual entry without impeding automatic methods. The one-time
-      password therefore MAY be converted to, and all servers MUST be
-      capable of accepting it as, a sequence of six short (1 to 4
-      letter) easily typed words that only use characters from ISO-646
-      IVCS. Each word is chosen from a dictionary of 2048 words; at 11
-      bits per word, all one-time passwords may be encoded.
-
-      The two extra bits in this encoding are used to store a checksum.
-      The 64 bits of key are broken down into pairs of bits, then these
-      pairs are summed together. The two least significant bits of this
-      sum are encoded in the last two bits of the six word sequence with
-      the least significant bit of the sum as the last bit encoded. All
-      OTP generators MUST calculate this checksum and all OTP servers
-      MUST verify this checksum explicitly as part of the operation of
-      decoding this representation of the one-time password.
-
-      Generators that produce the six-word format MUST present the words
-      in upper case with single spaces used as separators. All servers
-      MUST accept six-word format without regard to case and white space
-      used as a separator. The two lines below represent the same one-
-      time password.  The first is valid as output from a generator and
-      as input a server, the second is valid only as human input to a
-      server.
-
-          OUST COAT FOAL MUG BEAK TOTE
-          oust coat foal  mug  beak  tote
-
-      Interoperability requires that all OTP servers and generators use
-      the same dictionary. The standard dictionary was originally
-      specified in the "S/KEY One Time Password System" that is
-
-
-
-Haller & Metz               Standards Track                     [Page 5]
-
-RFC 1938               A One-Time Password System               May 1996
-
-
-      described in RFC 1760 [5].  This dictionary is included in this
-      document as Appendix C.
-
-      To facilitate the implementation of smaller generators,
-      hexadecimal output is an acceptable alternative for the
-      presentation of the one-time password. All implementations of the
-      server software MUST accept case-insensitive hexadecimal as well
-      as six-word format. The hexadecimal digits may be separated by
-      white space so servers are REQUIRED to ignore all white space.  If
-      the representation is partitioned by white space, leading zeros
-      must be retained. Examples of hexadecimal format are:
-
-         Representation                Value
-
-         3503785b369cda8b              0x3503785b369cda8b
-         e5cc a1b8 7c13 096b           0xe5cca1b87c13096b
-         C7 48 90 F4 27 7B A1 CF       0xc74890f4277ba1cf
-         47 9 A68 28 4C 9D 0 1BC       0x479a68284c9d01bc
-
-      In addition to accepting six-word and hexadecimal encodings of the
-      64 bit one-time password, servers SHOULD accept the alternate
-      dictionary encoding described in Appendix B.  The six words in
-      this encoding MUST not overlap the set of words in the standard
-      dictionary.  To avoid ambiguity with the hexadecimal
-      representation, words in the alternate dictionary MUST not be
-      comprised solely of the letters A-F.  Decoding words thus encoded
-      does not require any knowledge of the alternative dictionary used
-      so the acceptance of any alternate dictionary implies the
-      acceptance of all alternate dictionaries.  Words in the
-      alternative dictionaries are case sensitive.  Generators and
-      servers MUST preserve the case in the processing of these words.
-
-      In summary, all conforming servers MUST accept six-word input that
-      uses the Standard Dictionary (RFC 1760 and Appendix C), MUST
-      accept hexadecimal encoding, and SHOULD accept six-word input that
-      uses the Alternative Dictionary technique (Appendix B).  As there
-      is a remote possibility that a hexadecimal encoding of a one-time
-      password will look like a valid six-word standard dictionary
-      encoding, all implementations MUST use the following scheme.  If a
-      six-word encoded one-time password is valid, it is accepted.
-      Otherwise, if the one-time password can be interpreted as
-      hexadecimal, and with that decoding it is valid, then it is
-      accepted.
-
-
-
-
-
-
-
-
-Haller & Metz               Standards Track                     [Page 6]
-
-RFC 1938               A One-Time Password System               May 1996
-
-
-7.0 VERIFICATION OF ONE-TIME PASSWORDS
-
-   An application on the server system that requires OTP authentication
-   is expected to issue an OTP challenge as described above. Given the
-   parameters from this challenge and the secret pass-phrase, the
-   generator can compute (or lookup) the one-time password that is
-   passed to the server to be verified.
-
-   The server system has a database containing, for each user, the one-
-   time password from the last successful authentication or the first
-   OTP of a newly initialized sequence. To authenticate the user, the
-   server decodes the one-time password received from the generator into
-   a 64-bit key and then runs this key through the secure hash function
-   once. If the result of this operation matches the stored previous
-   OTP, the authentication is successful and the accepted one-time
-   password is stored for future use.
-
-8.0 PASS-PHRASE CHANGES
-
-   Because the number of hash function applications executed by the
-   generator decreases by one each time, at some point the user must
-   reinitialize the system or be unable to authenticate.
-
-   Although some installations may not permit users to initialize
-   remotely, implementations MUST provide a means to do so that does not
-   reveal the user's secret pass-phrase.  One way is to provide a means
-   to reinitialize the  sequence through explicit specification of the
-   first one-time password.
-
-   When the sequence of one-time passwords is reinitialized,
-   implementations MUST verify that the seed or the pass-phrase is
-   changed.  Installations SHOULD discourage any operation that sends
-   the secret pass-phrase over a network in clear-text as such practice
-   defeats the concept of a one-time password.
-
-   Implementations MAY use the following technique for
-   [re]initialization:
-
-    o  The user picks a new seed and hash count (default values may
-       be offered).  The user provides these, along with the
-       corresponding generated one-time password, to the host system.
-
-    o  The user MAY also provide the corresponding generated one
-       time password for count-1 as an error check.
-
-    o  The user SHOULD provide the generated one-time password for
-       the old seed and old hash count to protect an idle terminal
-       or workstation (this implies that when the count is 1, the
-
-
-
-Haller & Metz               Standards Track                     [Page 7]
-
-RFC 1938               A One-Time Password System               May 1996
-
-
-       user can login but cannot then change the seed or count).
-
-   In the future a specific protocol may be defined for reinitialization
-   that will permit smooth and possibly automated interoperation of all
-   hosts and generators.
-
-9.0 PROTECTION AGAINST RACE ATTACK
-
-   All conforming server implementations MUST protect against the race
-   condition described in this section.  A defense against this attack
-   is outlined; implementations MAY use this approach or MAY select an
-   alternative defense.
-
-   It is possible for an attacker to listen to most of a one-time
-   password, guess the remainder, and then race the legitimate user to
-   complete the authentication.  Multiple guesses against the last word
-   of the six-word format are likely to succeed.
-
-   One possible defense is to prevent a user from starting multiple
-   simultaneous authentication sessions. This means that once the
-   legitimate user has initiated authentication, an attacker would be
-   blocked until the first authentication process has completed.  In
-   this approach, a timeout is necessary to thwart a denial of service
-   attack.
-
-10.0 SECURITY CONSIDERATIONS
-
-   This entire document discusses an authentication system that improves
-   security by limiting the danger of eavesdropping/replay attacks that
-   have been used against simple password systems [4].
-
-   The use of the OTP system only provides protections against passive
-   eavesdropping/replay attacks.  It does not provide for the privacy of
-   transmitted data, and it does not provide protection against active
-   attacks.  Active attacks against TCP connections are known to be
-   present in the current Internet [9].
-
-   The success of the OTP system to protect host systems is dependent on
-   the non-invertability of the secure hash functions used.  To our
-   knowledge, none of the hash algorithms have been broken, but it is
-   generally believed [6] that MD4 is not as strong as MD5.  If a server
-   supports multiple hash algorithms, it is only as secure as the
-   weakest algorithm.
-
-
-
-
-
-
-
-
-Haller & Metz               Standards Track                     [Page 8]
-
-RFC 1938               A One-Time Password System               May 1996
-
-
-11.0 ACKNOWLEDGMENTS
-
-   The idea behind OTP authentication was first proposed by Leslie
-   Lamport [1]. Bellcore's S/KEY system, from which OTP is derived, was
-   proposed by Phil Karn, who also wrote most of the Bellcore reference
-   implementation.
-
-12.0 REFERENCES
-
-  [1]  Leslie Lamport, "Password Authentication with Insecure
-       Communication", Communications of the ACM 24.11 (November
-       1981), 770-772
-
-  [2]  Rivest, R., "The MD4 Message-Digest Algorithm, RFC 1320",
-       MIT and RSA Data Security, Inc., April 1992.
-
-  [3]  Neil Haller, "The S/KEY One-Time Password System", Proceedings
-       of the ISOC Symposium on Network and Distributed System
-       Security, February 1994, San Diego, CA
-
-  [4]  Haller, N., and R. Atkinson, "On Internet Authentication",
-       RFC 1704, Bellcore and Naval Research Laboratory, October 1994.
-
-  [5]  Haller, N., "The S/KEY One-Time Password System", RFC 1760,
-       Bellcore, February 1995.
-
-  [6]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
-       MIT and RSA Data Security, Inc., April 1992.
-
-  [7]  National Institute of Standards and Technology (NIST),
-       "Announcing the Secure Hash Standard", FIPS 180-1, U.S.
-       Department of Commerce, April 1995.
-
-  [8]  International Standard - Information Processing -- ISO 7-bit
-       coded character set for information interchange (Invariant Code
-       Set), ISO-646, International Standards Organization, Geneva,
-       Switzerland, 1983
-
-  [9]  Computer Emergency Response Team (CERT), "IP Spoofing and
-       Hijacked Terminal Connections", CA-95:01, January 1995.
-       Available via anonymous ftp from info.cert.org in
-       /pub/cert_advisories.
-
-
-
-
-
-
-
-
-
-Haller & Metz               Standards Track                     [Page 9]
-
-RFC 1938               A One-Time Password System               May 1996
-
-
-13.0 AUTHORS' ADDRESSES
-
-   Neil Haller
-   Bellcore
-   MCC 1C-265B
-   445 South Street
-   Morristown, NJ, 07960-6438, USA
-
-   Phone: +1 201 829-4478
-   Fax:   +1 201 829-2504
-   EMail: nmh@bellcore.com
-
-
-   Craig Metz
-   Kaman Sciences Corporation
-   For NRL Code 5544
-   4555 Overlook Avenue, S.W.
-   Washington, DC, 20375-5337, USA
-
-   Phone: +1 202 404-7122
-   Fax:   +1 202 404-7942
-   EMail: cmetz@cs.nrl.navy.mil
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Haller & Metz               Standards Track                    [Page 10]
-
-RFC 1938               A One-Time Password System               May 1996
-
-
-Appendix A   -   Interfaces to Secure Hash Algorithms
-
-MD4 Message Digest (see reference [2])
-
-          strcpy(buf,seed);
-          strcat(buf,passwd);
-          MDbegin(&md)
-          MDupdate(&md,(unsigned char *)buf,8*buflen);
-
-          /* Fold result to 64 bits */
-          md.buffer[0] ^= md.buffer[2];
-          md.buffer[1] ^= md.buffer[3];
-
-
-MD5 Message Digest (see reference [6])
-
-          MD5_CTX mdCxt;
-
-          strcpy(buf,seed);
-          strcat(buf,passwd);
-
-          /* Crunch the key through MD5  */
-          MD5Init(&mdCxt);
-          MD5Update(&mdCxt,(unsigned char *)bits,strlen(bits));
-          MD5Update(&mdCxt,(unsigned char *)buf,buflen);
-          MD5Final(&mdCxt);
-
-          /* Fold result to 64 bits */
-          for( i = 0; i < 8; i++ )
-              result[i] = mdCxt.digest[i] ^ mdCxt.digest[i+8];
-
-
-SHA Secure Hash Algorithm (see reference [7])
-
-
-          /*  Fold 160 bit result to 64 bits */
-          md.buffer[0] ^= md.buffer[2];
-          md.buffer[1] ^= md.buffer[3];
-          md.buffer[0] ^= md.buffer[4];
-
-Appendix B   -   Alternative Dictionary Algorithm
-
-   The purpose of alternative dictionary encoding of the OTP one-time
-   password is to allow the use of language specific or friendly words.
-   As case translation is not always well defined, the alternative
-   dictionary encoding is case insensitive.  Servers SHOULD accept this
-   encoding in addition to the standard 6-word and hexadecimal
-   encodings.
-
-
-
-Haller & Metz               Standards Track                    [Page 11]
-
-RFC 1938               A One-Time Password System               May 1996
-
-
-GENERATOR ENCODING USING AN ALTERNATE DICTIONARY
-
-  The standard 6-word encoding uses the placement of a word in the
-  dictionary to represent an 11-bit number. The 64-bit one-time
-  password can then be represented by six words.
-
-  An alternative dictionary of 2048 words may be created such that
-  each word W and position of the word in the dictionary N obey the
-  relationship:
-
-          alg( W ) % 2048 == N
-  where
-          alg is the hash algorithm used (e.g. MD4, MD5, SHA1).
-
-  In addition, no words in the standard dictionary may be chosen.
-
-  The generator expands the 64-bit one-time password to 66 bits by
-  computing parity as with the standard 6-word encoding.  The six 11-
-  bit numbers are then converted to words using the dictionary that
-  was created such that the above relationship holds.
-
-
-SERVER DECODING OF ALTERNATE DICTIONARY ONE-TIME PASSWORDS
-
-  The server accepting alternative dictionary encoding converts each
-  word to an 11-bit number using the above encoding. These numbers are
-  then used in the same way as the decoded standard dictionary words
-  to form the 66-bit one-time password.
-
-  The server does not need to have access to the alternate dictionary
-  that was used to create the one-time password it is authenticating.
-  This is because the decoding from word to 11-bit number does not
-  make any use of the dictionary.  As a result of the independence of
-  the dictionary, a server accepting one alternate dictionary accept
-  all alternate dictionaries.
-
-Appendix C - Dictionary for Converting Between 6-Word and Binary
-Formats
-
-   This dictionary is from the module put.c in the original Bellcore
-   reference distribution.
-
-{        "A",    "ABE",   "ACE",   "ACT",   "AD",    "ADA",   "ADD",
-"AGO",   "AID",  "AIM",   "AIR",   "ALL",   "ALP",   "AM",    "AMY",
-"AN",    "ANA",  "AND",   "ANN",   "ANT",   "ANY",   "APE",   "APS",
-"APT",   "ARC",  "ARE",   "ARK",   "ARM",   "ART",   "AS",    "ASH",
-"ASK",   "AT",   "ATE",   "AUG",   "AUK",   "AVE",   "AWE",   "AWK",
-"AWL",   "AWN",  "AX",    "AYE",   "BAD",   "BAG",   "BAH",   "BAM",
-
-
-
-Haller & Metz               Standards Track                    [Page 12]
-
-RFC 1938               A One-Time Password System               May 1996
-
-
-"BAN",   "BAR",  "BAT",   "BAY",   "BE",    "BED",   "BEE",   "BEG",
-"BEN",   "BET",  "BEY",   "BIB",   "BID",   "BIG",   "BIN",   "BIT",
-"BOB",   "BOG",  "BON",   "BOO",   "BOP",   "BOW",   "BOY",   "BUB",
-"BUD",   "BUG",  "BUM",   "BUN",   "BUS",   "BUT",   "BUY",   "BY",
-"BYE",   "CAB",  "CAL",   "CAM",   "CAN",   "CAP",   "CAR",   "CAT",
-"CAW",   "COD",  "COG",   "COL",   "CON",   "COO",   "COP",   "COT",
-"COW",   "COY",  "CRY",   "CUB",   "CUE",   "CUP",   "CUR",   "CUT",
-"DAB",   "DAD",  "DAM",   "DAN",   "DAR",   "DAY",   "DEE",   "DEL",
-"DEN",   "DES",  "DEW",   "DID",   "DIE",   "DIG",   "DIN",   "DIP",
-"DO",    "DOE",  "DOG",   "DON",   "DOT",   "DOW",   "DRY",   "DUB",
-"DUD",   "DUE",  "DUG",   "DUN",   "EAR",   "EAT",   "ED",    "EEL",
-"EGG",   "EGO",  "ELI",   "ELK",   "ELM",   "ELY",   "EM",    "END",
-"EST",   "ETC",  "EVA",   "EVE",   "EWE",   "EYE",   "FAD",   "FAN",
-"FAR",   "FAT",  "FAY",   "FED",   "FEE",   "FEW",   "FIB",   "FIG",
-"FIN",   "FIR",  "FIT",   "FLO",   "FLY",   "FOE",   "FOG",   "FOR",
-"FRY",   "FUM",  "FUN",   "FUR",   "GAB",   "GAD",   "GAG",   "GAL",
-"GAM",   "GAP",  "GAS",   "GAY",   "GEE",   "GEL",   "GEM",   "GET",
-"GIG",   "GIL",  "GIN",   "GO",    "GOT",   "GUM",   "GUN",   "GUS",
-"GUT",   "GUY",  "GYM",   "GYP",   "HA",    "HAD",   "HAL",   "HAM",
-"HAN",   "HAP",  "HAS",   "HAT",   "HAW",   "HAY",   "HE",    "HEM",
-"HEN",   "HER",  "HEW",   "HEY",   "HI",    "HID",   "HIM",   "HIP",
-"HIS",   "HIT",  "HO",    "HOB",   "HOC",   "HOE",   "HOG",   "HOP",
-"HOT",   "HOW",  "HUB",   "HUE",   "HUG",   "HUH",   "HUM",   "HUT",
-"I",     "ICY",  "IDA",   "IF",    "IKE",   "ILL",   "INK",   "INN",
-"IO",    "ION",  "IQ",    "IRA",   "IRE",   "IRK",   "IS",    "IT",
-"ITS",   "IVY",  "JAB",   "JAG",   "JAM",   "JAN",   "JAR",   "JAW",
-"JAY",   "JET",  "JIG",   "JIM",   "JO",    "JOB",   "JOE",   "JOG",
-"JOT",   "JOY",  "JUG",   "JUT",   "KAY",   "KEG",   "KEN",   "KEY",
-"KID",   "KIM",  "KIN",   "KIT",   "LA",    "LAB",   "LAC",   "LAD",
-"LAG",   "LAM",  "LAP",   "LAW",   "LAY",   "LEA",   "LED",   "LEE",
-"LEG",   "LEN",  "LEO",   "LET",   "LEW",   "LID",   "LIE",   "LIN",
-"LIP",   "LIT",  "LO",    "LOB",   "LOG",   "LOP",   "LOS",   "LOT",
-"LOU",   "LOW",  "LOY",   "LUG",   "LYE",   "MA",    "MAC",   "MAD",
-"MAE",   "MAN",  "MAO",   "MAP",   "MAT",   "MAW",   "MAY",   "ME",
-"MEG",   "MEL",  "MEN",   "MET",   "MEW",   "MID",   "MIN",   "MIT",
-"MOB",   "MOD",  "MOE",   "MOO",   "MOP",   "MOS",   "MOT",   "MOW",
-"MUD",   "MUG",  "MUM",   "MY",    "NAB",   "NAG",   "NAN",   "NAP",
-"NAT",   "NAY",  "NE",    "NED",   "NEE",   "NET",   "NEW",   "NIB",
-"NIL",   "NIP",  "NIT",   "NO",    "NOB",   "NOD",   "NON",   "NOR",
-"NOT",   "NOV",  "NOW",   "NU",    "NUN",   "NUT",   "O",     "OAF",
-"OAK",   "OAR",  "OAT",   "ODD",   "ODE",   "OF",    "OFF",   "OFT",
-"OH",    "OIL",  "OK",    "OLD",   "ON",    "ONE",   "OR",    "ORB",
-"ORE",   "ORR",  "OS",    "OTT",   "OUR",   "OUT",   "OVA",   "OW",
-"OWE",   "OWL",  "OWN",   "OX",    "PA",    "PAD",   "PAL",   "PAM",
-"PAN",   "PAP",  "PAR",   "PAT",   "PAW",   "PAY",   "PEA",   "PEG",
-"PEN",   "PEP",  "PER",   "PET",   "PEW",   "PHI",   "PI",    "PIE",
-"PIN",   "PIT",  "PLY",   "PO",    "POD",   "POE",   "POP",   "POT",
-"POW",   "PRO",  "PRY",   "PUB",   "PUG",   "PUN",   "PUP",   "PUT",
-
-
-
-Haller & Metz               Standards Track                    [Page 13]
-
-RFC 1938               A One-Time Password System               May 1996
-
-
-"QUO",   "RAG",  "RAM",   "RAN",   "RAP",   "RAT",   "RAW",   "RAY",
-"REB",   "RED",  "REP",   "RET",   "RIB",   "RID",   "RIG",   "RIM",
-"RIO",   "RIP",  "ROB",   "ROD",   "ROE",   "RON",   "ROT",   "ROW",
-"ROY",   "RUB",  "RUE",   "RUG",   "RUM",   "RUN",   "RYE",   "SAC",
-"SAD",   "SAG",  "SAL",   "SAM",   "SAN",   "SAP",   "SAT",   "SAW",
-"SAY",   "SEA",  "SEC",   "SEE",   "SEN",   "SET",   "SEW",   "SHE",
-"SHY",   "SIN",  "SIP",   "SIR",   "SIS",   "SIT",   "SKI",   "SKY",
-"SLY",   "SO",   "SOB",   "SOD",   "SON",   "SOP",   "SOW",   "SOY",
-"SPA",   "SPY",  "SUB",   "SUD",   "SUE",   "SUM",   "SUN",   "SUP",
-"TAB",   "TAD",  "TAG",   "TAN",   "TAP",   "TAR",   "TEA",   "TED",
-"TEE",   "TEN",  "THE",   "THY",   "TIC",   "TIE",   "TIM",   "TIN",
-"TIP",   "TO",   "TOE",   "TOG",   "TOM",   "TON",   "TOO",   "TOP",
-"TOW",   "TOY",  "TRY",   "TUB",   "TUG",   "TUM",   "TUN",   "TWO",
-"UN",    "UP",   "US",    "USE",   "VAN",   "VAT",   "VET",   "VIE",
-"WAD",   "WAG",  "WAR",   "WAS",   "WAY",   "WE",    "WEB",   "WED",
-"WEE",   "WET",  "WHO",   "WHY",   "WIN",   "WIT",   "WOK",   "WON",
-"WOO",   "WOW",  "WRY",   "WU",    "YAM",   "YAP",   "YAW",   "YE",
-"YEA",   "YES",  "YET",   "YOU",   "ABED",  "ABEL",  "ABET",  "ABLE",
-"ABUT",  "ACHE",  "ACID", "ACME",  "ACRE",  "ACTA",  "ACTS",  "ADAM",
-"ADDS",  "ADEN",  "AFAR", "AFRO",  "AGEE",  "AHEM",  "AHOY",  "AIDA",
-"AIDE",  "AIDS",  "AIRY", "AJAR",  "AKIN",  "ALAN",  "ALEC",  "ALGA",
-"ALIA",  "ALLY",  "ALMA", "ALOE",  "ALSO",  "ALTO",  "ALUM",  "ALVA",
-"AMEN",  "AMES",  "AMID", "AMMO",  "AMOK",  "AMOS",  "AMRA",  "ANDY",
-"ANEW",  "ANNA",  "ANNE", "ANTE",  "ANTI",  "AQUA",  "ARAB",  "ARCH",
-"AREA",  "ARGO",  "ARID", "ARMY",  "ARTS",  "ARTY",  "ASIA",  "ASKS",
-"ATOM",  "AUNT",  "AURA", "AUTO",  "AVER",  "AVID",  "AVIS",  "AVON",
-"AVOW",  "AWAY",  "AWRY", "BABE",  "BABY",  "BACH",  "BACK",  "BADE",
-"BAIL",  "BAIT",  "BAKE", "BALD",  "BALE",  "BALI",  "BALK",  "BALL",
-"BALM",  "BAND",  "BANE", "BANG",  "BANK",  "BARB",  "BARD",  "BARE",
-"BARK",  "BARN",  "BARR", "BASE",  "BASH",  "BASK",  "BASS",  "BATE",
-"BATH",  "BAWD",  "BAWL", "BEAD",  "BEAK",  "BEAM",  "BEAN",  "BEAR",
-"BEAT",  "BEAU",  "BECK", "BEEF",  "BEEN",  "BEER",  "BEET",  "BELA",
-"BELL",  "BELT",  "BEND", "BENT",  "BERG",  "BERN",  "BERT",  "BESS",
-"BEST",  "BETA",  "BETH", "BHOY",  "BIAS",  "BIDE",  "BIEN",  "BILE",
-"BILK",  "BILL",  "BIND", "BING",  "BIRD",  "BITE",  "BITS",  "BLAB",
-"BLAT",  "BLED",  "BLEW", "BLOB",  "BLOC",  "BLOT",  "BLOW",  "BLUE",
-"BLUM",  "BLUR",  "BOAR", "BOAT",  "BOCA",  "BOCK",  "BODE",  "BODY",
-"BOGY",  "BOHR",  "BOIL", "BOLD",  "BOLO",  "BOLT",  "BOMB",  "BONA",
-"BOND",  "BONE",  "BONG", "BONN",  "BONY",  "BOOK",  "BOOM",  "BOON",
-"BOOT",  "BORE",  "BORG", "BORN",  "BOSE",  "BOSS",  "BOTH",  "BOUT",
-"BOWL",  "BOYD",  "BRAD", "BRAE",  "BRAG",  "BRAN",  "BRAY",  "BRED",
-"BREW",  "BRIG",  "BRIM", "BROW",  "BUCK",  "BUDD",  "BUFF",  "BULB",
-"BULK",  "BULL",  "BUNK", "BUNT",  "BUOY",  "BURG",  "BURL",  "BURN",
-"BURR",  "BURT",  "BURY", "BUSH",  "BUSS",  "BUST",  "BUSY",  "BYTE",
-"CADY",  "CAFE",  "CAGE", "CAIN",  "CAKE",  "CALF",  "CALL",  "CALM",
-"CAME",  "CANE",  "CANT", "CARD",  "CARE",  "CARL",  "CARR",  "CART",
-"CASE",  "CASH",  "CASK", "CAST",  "CAVE",  "CEIL",  "CELL",  "CENT",
-"CERN",  "CHAD",  "CHAR", "CHAT",  "CHAW",  "CHEF",  "CHEN",  "CHEW",
-
-
-
-Haller & Metz               Standards Track                    [Page 14]
-
-RFC 1938               A One-Time Password System               May 1996
-
-
-"CHIC",  "CHIN",  "CHOU", "CHOW",  "CHUB",  "CHUG",  "CHUM",  "CITE",
-"CITY",  "CLAD",  "CLAM", "CLAN",  "CLAW",  "CLAY",  "CLOD",  "CLOG",
-"CLOT",  "CLUB",  "CLUE", "COAL",  "COAT",  "COCA",  "COCK",  "COCO",
-"CODA",  "CODE",  "CODY", "COED",  "COIL",  "COIN",  "COKE",  "COLA",
-"COLD",  "COLT",  "COMA", "COMB",  "COME",  "COOK",  "COOL",  "COON",
-"COOT",  "CORD",  "CORE", "CORK",  "CORN",  "COST",  "COVE",  "COWL",
-"CRAB",  "CRAG",  "CRAM", "CRAY",  "CREW",  "CRIB",  "CROW",  "CRUD",
-"CUBA",  "CUBE",  "CUFF", "CULL",  "CULT",  "CUNY",  "CURB",  "CURD",
-"CURE",  "CURL",  "CURT", "CUTS",  "DADE",  "DALE",  "DAME",  "DANA",
-"DANE",  "DANG",  "DANK", "DARE",  "DARK",  "DARN",  "DART",  "DASH",
-"DATA",  "DATE",  "DAVE", "DAVY",  "DAWN",  "DAYS",  "DEAD",  "DEAF",
-"DEAL",  "DEAN",  "DEAR", "DEBT",  "DECK",  "DEED",  "DEEM",  "DEER",
-"DEFT",  "DEFY",  "DELL", "DENT",  "DENY",  "DESK",  "DIAL",  "DICE",
-"DIED",  "DIET",  "DIME", "DINE",  "DING",  "DINT",  "DIRE",  "DIRT",
-"DISC",  "DISH",  "DISK", "DIVE",  "DOCK",  "DOES",  "DOLE",  "DOLL",
-"DOLT",  "DOME",  "DONE", "DOOM",  "DOOR",  "DORA",  "DOSE",  "DOTE",
-"DOUG",  "DOUR",  "DOVE", "DOWN",  "DRAB",  "DRAG",  "DRAM",  "DRAW",
-"DREW",  "DRUB",  "DRUG", "DRUM",  "DUAL",  "DUCK",  "DUCT",  "DUEL",
-"DUET",  "DUKE",  "DULL", "DUMB",  "DUNE",  "DUNK",  "DUSK",  "DUST",
-"DUTY",  "EACH",  "EARL", "EARN",  "EASE",  "EAST",  "EASY",  "EBEN",
-"ECHO",  "EDDY",  "EDEN", "EDGE",  "EDGY",  "EDIT",  "EDNA",  "EGAN",
-"ELAN",  "ELBA",  "ELLA", "ELSE",  "EMIL",  "EMIT",  "EMMA",  "ENDS",
-"ERIC",  "EROS",  "EVEN", "EVER",  "EVIL",  "EYED",  "FACE",  "FACT",
-"FADE",  "FAIL",  "FAIN", "FAIR",  "FAKE",  "FALL",  "FAME",  "FANG",
-"FARM",  "FAST",  "FATE", "FAWN",  "FEAR",  "FEAT",  "FEED",  "FEEL",
-"FEET",  "FELL",  "FELT", "FEND",  "FERN",  "FEST",  "FEUD",  "FIEF",
-"FIGS",  "FILE",  "FILL", "FILM",  "FIND",  "FINE",  "FINK",  "FIRE",
-"FIRM",  "FISH",  "FISK", "FIST",  "FITS",  "FIVE",  "FLAG",  "FLAK",
-"FLAM",  "FLAT",  "FLAW", "FLEA",  "FLED",  "FLEW",  "FLIT",  "FLOC",
-"FLOG",  "FLOW",  "FLUB", "FLUE",  "FOAL",  "FOAM",  "FOGY",  "FOIL",
-"FOLD",  "FOLK",  "FOND", "FONT",  "FOOD",  "FOOL",  "FOOT",  "FORD",
-"FORE",  "FORK",  "FORM", "FORT",  "FOSS",  "FOUL",  "FOUR",  "FOWL",
-"FRAU",  "FRAY",  "FRED", "FREE",  "FRET",  "FREY",  "FROG",  "FROM",
-"FUEL",  "FULL",  "FUME", "FUND",  "FUNK",  "FURY",  "FUSE",  "FUSS",
-"GAFF",  "GAGE",  "GAIL", "GAIN",  "GAIT",  "GALA",  "GALE",  "GALL",
-"GALT",  "GAME",  "GANG", "GARB",  "GARY",  "GASH",  "GATE",  "GAUL",
-"GAUR",  "GAVE",  "GAWK", "GEAR",  "GELD",  "GENE",  "GENT",  "GERM",
-"GETS",  "GIBE",  "GIFT", "GILD",  "GILL",  "GILT",  "GINA",  "GIRD",
-"GIRL",  "GIST",  "GIVE", "GLAD",  "GLEE",  "GLEN",  "GLIB",  "GLOB",
-"GLOM",  "GLOW",  "GLUE", "GLUM",  "GLUT",  "GOAD",  "GOAL",  "GOAT",
-"GOER",  "GOES",  "GOLD", "GOLF",  "GONE",  "GONG",  "GOOD",  "GOOF",
-"GORE",  "GORY",  "GOSH", "GOUT",  "GOWN",  "GRAB",  "GRAD",  "GRAY",
-"GREG",  "GREW",  "GREY", "GRID",  "GRIM",  "GRIN",  "GRIT",  "GROW",
-"GRUB",  "GULF",  "GULL", "GUNK",  "GURU",  "GUSH",  "GUST",  "GWEN",
-"GWYN",  "HAAG",  "HAAS", "HACK",  "HAIL",  "HAIR",  "HALE",  "HALF",
-"HALL",  "HALO",  "HALT", "HAND",  "HANG",  "HANK",  "HANS",  "HARD",
-"HARK",  "HARM",  "HART", "HASH",  "HAST",  "HATE",  "HATH",  "HAUL",
-"HAVE",  "HAWK",  "HAYS", "HEAD",  "HEAL",  "HEAR",  "HEAT",  "HEBE",
-
-
-
-Haller & Metz               Standards Track                    [Page 15]
-
-RFC 1938               A One-Time Password System               May 1996
-
-
-"HECK",  "HEED",  "HEEL", "HEFT",  "HELD",  "HELL",  "HELM",  "HERB",
-"HERD",  "HERE",  "HERO", "HERS",  "HESS",  "HEWN",  "HICK",  "HIDE",
-"HIGH",  "HIKE",  "HILL", "HILT",  "HIND",  "HINT",  "HIRE",  "HISS",
-"HIVE",  "HOBO",  "HOCK", "HOFF",  "HOLD",  "HOLE",  "HOLM",  "HOLT",
-"HOME",  "HONE",  "HONK", "HOOD",  "HOOF",  "HOOK",  "HOOT",  "HORN",
-"HOSE",  "HOST",  "HOUR", "HOVE",  "HOWE",  "HOWL",  "HOYT",  "HUCK",
-"HUED",  "HUFF",  "HUGE", "HUGH",  "HUGO",  "HULK",  "HULL",  "HUNK",
-"HUNT",  "HURD",  "HURL", "HURT",  "HUSH",  "HYDE",  "HYMN",  "IBIS",
-"ICON",  "IDEA",  "IDLE", "IFFY",  "INCA",  "INCH",  "INTO",  "IONS",
-"IOTA",  "IOWA",  "IRIS", "IRMA",  "IRON",  "ISLE",  "ITCH",  "ITEM",
-"IVAN",  "JACK",  "JADE", "JAIL",  "JAKE",  "JANE",  "JAVA",  "JEAN",
-"JEFF",  "JERK",  "JESS", "JEST",  "JIBE",  "JILL",  "JILT",  "JIVE",
-"JOAN",  "JOBS",  "JOCK", "JOEL",  "JOEY",  "JOHN",  "JOIN",  "JOKE",
-"JOLT",  "JOVE",  "JUDD", "JUDE",  "JUDO",  "JUDY",  "JUJU",  "JUKE",
-"JULY",  "JUNE",  "JUNK", "JUNO",  "JURY",  "JUST",  "JUTE",  "KAHN",
-"KALE",  "KANE",  "KANT", "KARL",  "KATE",  "KEEL",  "KEEN",  "KENO",
-"KENT",  "KERN",  "KERR", "KEYS",  "KICK",  "KILL",  "KIND",  "KING",
-"KIRK",  "KISS",  "KITE", "KLAN",  "KNEE",  "KNEW",  "KNIT",  "KNOB",
-"KNOT",  "KNOW",  "KOCH", "KONG",  "KUDO",  "KURD",  "KURT",  "KYLE",
-"LACE",  "LACK",  "LACY", "LADY",  "LAID",  "LAIN",  "LAIR",  "LAKE",
-"LAMB",  "LAME",  "LAND", "LANE",  "LANG",  "LARD",  "LARK",  "LASS",
-"LAST",  "LATE",  "LAUD", "LAVA",  "LAWN",  "LAWS",  "LAYS",  "LEAD",
-"LEAF",  "LEAK",  "LEAN", "LEAR",  "LEEK",  "LEER",  "LEFT",  "LEND",
-"LENS",  "LENT",  "LEON", "LESK",  "LESS",  "LEST",  "LETS",  "LIAR",
-"LICE",  "LICK",  "LIED", "LIEN",  "LIES",  "LIEU",  "LIFE",  "LIFT",
-"LIKE",  "LILA",  "LILT", "LILY",  "LIMA",  "LIMB",  "LIME",  "LIND",
-"LINE",  "LINK",  "LINT", "LION",  "LISA",  "LIST",  "LIVE",  "LOAD",
-"LOAF",  "LOAM",  "LOAN", "LOCK",  "LOFT",  "LOGE",  "LOIS",  "LOLA",
-"LONE",  "LONG",  "LOOK", "LOON",  "LOOT",  "LORD",  "LORE",  "LOSE",
-"LOSS",  "LOST",  "LOUD", "LOVE",  "LOWE",  "LUCK",  "LUCY",  "LUGE",
-"LUKE",  "LULU",  "LUND", "LUNG",  "LURA",  "LURE",  "LURK",  "LUSH",
-"LUST",  "LYLE",  "LYNN", "LYON",  "LYRA",  "MACE",  "MADE",  "MAGI",
-"MAID",  "MAIL",  "MAIN", "MAKE",  "MALE",  "MALI",  "MALL",  "MALT",
-"MANA",  "MANN",  "MANY", "MARC",  "MARE",  "MARK",  "MARS",  "MART",
-"MARY",  "MASH",  "MASK", "MASS",  "MAST",  "MATE",  "MATH",  "MAUL",
-"MAYO",  "MEAD",  "MEAL", "MEAN",  "MEAT",  "MEEK",  "MEET",  "MELD",
-"MELT",  "MEMO",  "MEND", "MENU",  "MERT",  "MESH",  "MESS",  "MICE",
-"MIKE",  "MILD",  "MILE", "MILK",  "MILL",  "MILT",  "MIMI",  "MIND",
-"MINE",  "MINI",  "MINK", "MINT",  "MIRE",  "MISS",  "MIST",  "MITE",
-"MITT",  "MOAN",  "MOAT", "MOCK",  "MODE",  "MOLD",  "MOLE",  "MOLL",
-"MOLT",  "MONA",  "MONK", "MONT",  "MOOD",  "MOON",  "MOOR",  "MOOT",
-"MORE",  "MORN",  "MORT", "MOSS",  "MOST",  "MOTH",  "MOVE",  "MUCH",
-"MUCK",  "MUDD",  "MUFF", "MULE",  "MULL",  "MURK",  "MUSH",  "MUST",
-"MUTE",  "MUTT",  "MYRA", "MYTH",  "NAGY",  "NAIL",  "NAIR",  "NAME",
-"NARY",  "NASH",  "NAVE", "NAVY",  "NEAL",  "NEAR",  "NEAT",  "NECK",
-"NEED",  "NEIL",  "NELL", "NEON",  "NERO",  "NESS",  "NEST",  "NEWS",
-"NEWT",  "NIBS",  "NICE", "NICK",  "NILE",  "NINA",  "NINE",  "NOAH",
-"NODE",  "NOEL",  "NOLL", "NONE",  "NOOK",  "NOON",  "NORM",  "NOSE",
-
-
-
-Haller & Metz               Standards Track                    [Page 16]
-
-RFC 1938               A One-Time Password System               May 1996
-
-
-"NOTE",  "NOUN",  "NOVA", "NUDE",  "NULL",  "NUMB",  "OATH",  "OBEY",
-"OBOE",  "ODIN",  "OHIO", "OILY",  "OINT",  "OKAY",  "OLAF",  "OLDY",
-"OLGA",  "OLIN",  "OMAN", "OMEN",  "OMIT",  "ONCE",  "ONES",  "ONLY",
-"ONTO",  "ONUS",  "ORAL", "ORGY",  "OSLO",  "OTIS",  "OTTO",  "OUCH",
-"OUST",  "OUTS",  "OVAL", "OVEN",  "OVER",  "OWLY",  "OWNS",  "QUAD",
-"QUIT",  "QUOD",  "RACE", "RACK",  "RACY",  "RAFT",  "RAGE",  "RAID",
-"RAIL",  "RAIN",  "RAKE", "RANK",  "RANT",  "RARE",  "RASH",  "RATE",
-"RAVE",  "RAYS",  "READ", "REAL",  "REAM",  "REAR",  "RECK",  "REED",
-"REEF",  "REEK",  "REEL", "REID",  "REIN",  "RENA",  "REND",  "RENT",
-"REST",  "RICE",  "RICH", "RICK",  "RIDE",  "RIFT",  "RILL",  "RIME",
-"RING",  "RINK",  "RISE", "RISK",  "RITE",  "ROAD",  "ROAM",  "ROAR",
-"ROBE",  "ROCK",  "RODE", "ROIL",  "ROLL",  "ROME",  "ROOD",  "ROOF",
-"ROOK",  "ROOM",  "ROOT", "ROSA",  "ROSE",  "ROSS",  "ROSY",  "ROTH",
-"ROUT",  "ROVE",  "ROWE", "ROWS",  "RUBE",  "RUBY",  "RUDE",  "RUDY",
-"RUIN",  "RULE",  "RUNG", "RUNS",  "RUNT",  "RUSE",  "RUSH",  "RUSK",
-"RUSS",  "RUST",  "RUTH", "SACK",  "SAFE",  "SAGE",  "SAID",  "SAIL",
-"SALE",  "SALK",  "SALT", "SAME",  "SAND",  "SANE",  "SANG",  "SANK",
-"SARA",  "SAUL",  "SAVE", "SAYS",  "SCAN",  "SCAR",  "SCAT",  "SCOT",
-"SEAL",  "SEAM",  "SEAR", "SEAT",  "SEED",  "SEEK",  "SEEM",  "SEEN",
-"SEES",  "SELF",  "SELL", "SEND",  "SENT",  "SETS",  "SEWN",  "SHAG",
-"SHAM",  "SHAW",  "SHAY", "SHED",  "SHIM",  "SHIN",  "SHOD",  "SHOE",
-"SHOT",  "SHOW",  "SHUN", "SHUT",  "SICK",  "SIDE",  "SIFT",  "SIGH",
-"SIGN",  "SILK",  "SILL", "SILO",  "SILT",  "SINE",  "SING",  "SINK",
-"SIRE",  "SITE",  "SITS", "SITU",  "SKAT",  "SKEW",  "SKID",  "SKIM",
-"SKIN",  "SKIT",  "SLAB", "SLAM",  "SLAT",  "SLAY",  "SLED",  "SLEW",
-"SLID",  "SLIM",  "SLIT", "SLOB",  "SLOG",  "SLOT",  "SLOW",  "SLUG",
-"SLUM",  "SLUR",  "SMOG", "SMUG",  "SNAG",  "SNOB",  "SNOW",  "SNUB",
-"SNUG",  "SOAK",  "SOAR", "SOCK",  "SODA",  "SOFA",  "SOFT",  "SOIL",
-"SOLD",  "SOME",  "SONG", "SOON",  "SOOT",  "SORE",  "SORT",  "SOUL",
-"SOUR",  "SOWN",  "STAB", "STAG",  "STAN",  "STAR",  "STAY",  "STEM",
-"STEW",  "STIR",  "STOW", "STUB",  "STUN",  "SUCH",  "SUDS",  "SUIT",
-"SULK",  "SUMS",  "SUNG", "SUNK",  "SURE",  "SURF",  "SWAB",  "SWAG",
-"SWAM",  "SWAN",  "SWAT", "SWAY",  "SWIM",  "SWUM",  "TACK",  "TACT",
-"TAIL",  "TAKE",  "TALE", "TALK",  "TALL",  "TANK",  "TASK",  "TATE",
-"TAUT",  "TEAL",  "TEAM", "TEAR",  "TECH",  "TEEM",  "TEEN",  "TEET",
-"TELL",  "TEND",  "TENT", "TERM",  "TERN",  "TESS",  "TEST",  "THAN",
-"THAT",  "THEE",  "THEM", "THEN",  "THEY",  "THIN",  "THIS",  "THUD",
-"THUG",  "TICK",  "TIDE", "TIDY",  "TIED",  "TIER",  "TILE",  "TILL",
-"TILT",  "TIME",  "TINA", "TINE",  "TINT",  "TINY",  "TIRE",  "TOAD",
-"TOGO",  "TOIL",  "TOLD", "TOLL",  "TONE",  "TONG",  "TONY",  "TOOK",
-"TOOL",  "TOOT",  "TORE", "TORN",  "TOTE",  "TOUR",  "TOUT",  "TOWN",
-"TRAG",  "TRAM",  "TRAY", "TREE",  "TREK",  "TRIG",  "TRIM",  "TRIO",
-"TROD",  "TROT",  "TROY", "TRUE",  "TUBA",  "TUBE",  "TUCK",  "TUFT",
-"TUNA",  "TUNE",  "TUNG", "TURF",  "TURN",  "TUSK",  "TWIG",  "TWIN",
-"TWIT",  "ULAN",  "UNIT", "URGE",  "USED",  "USER",  "USES",  "UTAH",
-"VAIL",  "VAIN",  "VALE", "VARY",  "VASE",  "VAST",  "VEAL",  "VEDA",
-"VEIL",  "VEIN",  "VEND", "VENT",  "VERB",  "VERY",  "VETO",  "VICE",
-"VIEW",  "VINE",  "VISE", "VOID",  "VOLT",  "VOTE",  "WACK",  "WADE",
-
-
-
-Haller & Metz               Standards Track                    [Page 17]
-
-RFC 1938               A One-Time Password System               May 1996
-
-
-"WAGE",  "WAIL",  "WAIT", "WAKE",  "WALE",  "WALK",  "WALL",  "WALT",
-"WAND",  "WANE",  "WANG", "WANT",  "WARD",  "WARM",  "WARN",  "WART",
-"WASH",  "WAST",  "WATS", "WATT",  "WAVE",  "WAVY",  "WAYS",  "WEAK",
-"WEAL",  "WEAN",  "WEAR", "WEED",  "WEEK",  "WEIR",  "WELD",  "WELL",
-"WELT",  "WENT",  "WERE", "WERT",  "WEST",  "WHAM",  "WHAT",  "WHEE",
-"WHEN",  "WHET",  "WHOA", "WHOM",  "WICK",  "WIFE",  "WILD",  "WILL",
-"WIND",  "WINE",  "WING", "WINK",  "WINO",  "WIRE",  "WISE",  "WISH",
-"WITH",  "WOLF",  "WONT", "WOOD",  "WOOL",  "WORD",  "WORE",  "WORK",
-"WORM",  "WORN",  "WOVE", "WRIT",  "WYNN",  "YALE",  "YANG",  "YANK",
-"YARD",  "YARN",  "YAWL", "YAWN",  "YEAH",  "YEAR",  "YELL",  "YOGA",
-"YOKE"                         };
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Haller & Metz               Standards Track                    [Page 18]
-
diff --git a/RFC/rfc1939.txt b/RFC/rfc1939.txt
deleted file mode 100644
index b11350e9..00000000
--- a/RFC/rfc1939.txt
+++ /dev/null
@@ -1,1291 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                           J. Myers
-Request for Comments: 1939                               Carnegie Mellon
-STD: 53                                                          M. Rose
-Obsoletes: 1725                             Dover Beach Consulting, Inc.
-Category: Standards Track                                       May 1996
-
-
-                    Post Office Protocol - Version 3
-
-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.
-
-Table of Contents
-
-   1. Introduction ................................................    2
-   2. A Short Digression ..........................................    2
-   3. Basic Operation .............................................    3
-   4. The AUTHORIZATION State .....................................    4
-      QUIT Command ................................................    5
-   5. The TRANSACTION State .......................................    5
-      STAT Command ................................................    6
-      LIST Command ................................................    6
-      RETR Command ................................................    8
-      DELE Command ................................................    8
-      NOOP Command ................................................    9
-      RSET Command ................................................    9
-   6. The UPDATE State ............................................   10
-      QUIT Command ................................................   10
-   7. Optional POP3 Commands ......................................   11
-      TOP Command .................................................   11
-      UIDL Command ................................................   12
-      USER Command ................................................   13
-      PASS Command ................................................   14
-      APOP Command ................................................   15
-   8. Scaling and Operational Considerations ......................   16
-   9. POP3 Command Summary ........................................   18
-   10. Example POP3 Session .......................................   19
-   11. Message Format .............................................   19
-   12. References .................................................   20
-   13. Security Considerations ....................................   20
-   14. Acknowledgements ...........................................   20
-   15. Authors' Addresses .........................................   21
-   Appendix A. Differences from RFC 1725 ..........................   22
-
-
-
-Myers & Rose                Standards Track                     [Page 1]
-
-RFC 1939                          POP3                          May 1996
-
-
-   Appendix B. Command Index ......................................   23
-
-1. Introduction
-
-   On certain types of smaller nodes in the Internet it is often
-   impractical to maintain a message transport system (MTS).  For
-   example, a workstation may not have sufficient resources (cycles,
-   disk space) in order to permit a SMTP server [RFC821] and associated
-   local mail delivery system to be kept resident and continuously
-   running.  Similarly, it may be expensive (or impossible) to keep a
-   personal computer interconnected to an IP-style network for long
-   amounts of time (the node is lacking the resource known as
-   "connectivity").
-
-   Despite this, it is often very useful to be able to manage mail on
-   these smaller nodes, and they often support a user agent (UA) to aid
-   the tasks of mail handling.  To solve this problem, a node which can
-   support an MTS entity offers a maildrop service to these less endowed
-   nodes.  The Post Office Protocol - Version 3 (POP3) is intended to
-   permit a workstation to dynamically access a maildrop on a server
-   host in a useful fashion.  Usually, this means that the POP3 protocol
-   is used to allow a workstation to retrieve mail that the server is
-   holding for it.
-
-   POP3 is not intended to provide extensive manipulation operations of
-   mail on the server; normally, mail is downloaded and then deleted.  A
-   more advanced (and complex) protocol, IMAP4, is discussed in
-   [RFC1730].
-
-   For the remainder of this memo, the term "client host" refers to a
-   host making use of the POP3 service, while the term "server host"
-   refers to a host which offers the POP3 service.
-
-2. A Short Digression
-
-   This memo does not specify how a client host enters mail into the
-   transport system, although a method consistent with the philosophy of
-   this memo is presented here:
-
-      When the user agent on a client host wishes to enter a message
-      into the transport system, it establishes an SMTP connection to
-      its relay host and sends all mail to it.  This relay host could
-      be, but need not be, the POP3 server host for the client host.  Of
-      course, the relay host must accept mail for delivery to arbitrary
-      recipient addresses, that functionality is not required of all
-      SMTP servers.
-
-
-
-
-
-Myers & Rose                Standards Track                     [Page 2]
-
-RFC 1939                          POP3                          May 1996
-
-
-3. Basic Operation
-
-   Initially, the server host starts the POP3 service by listening on
-   TCP port 110.  When a client host wishes to make use of the service,
-   it establishes a TCP connection with the server host.  When the
-   connection is established, the POP3 server sends a greeting.  The
-   client and POP3 server then exchange commands and responses
-   (respectively) until the connection is closed or aborted.
-
-   Commands in the POP3 consist of a case-insensitive keyword, possibly
-   followed by one or more arguments.  All commands are terminated by a
-   CRLF pair.  Keywords and arguments consist of printable ASCII
-   characters.  Keywords and arguments are each separated by a single
-   SPACE character.  Keywords are three or four characters long. Each
-   argument may be up to 40 characters long.
-
-   Responses in the POP3 consist of a status indicator and a keyword
-   possibly followed by additional information.  All responses are
-   terminated by a CRLF pair.  Responses may be up to 512 characters
-   long, including the terminating CRLF.  There are currently two status
-   indicators: positive ("+OK") and negative ("-ERR").  Servers MUST
-   send the "+OK" and "-ERR" in upper case.
-
-   Responses to certain commands are multi-line.  In these cases, which
-   are clearly indicated below, after sending the first line of the
-   response and a CRLF, any additional lines are sent, each terminated
-   by a CRLF pair.  When all lines of the response have been sent, a
-   final line is sent, consisting of a termination octet (decimal code
-   046, ".") and a CRLF pair.  If any line of the multi-line response
-   begins with the termination octet, the line is "byte-stuffed" by
-   pre-pending the termination octet to that line of the response.
-   Hence a multi-line response is terminated with the five octets
-   "CRLF.CRLF".  When examining a multi-line response, the client checks
-   to see if the line begins with the termination octet.  If so and if
-   octets other than CRLF follow, the first octet of the line (the
-   termination octet) is stripped away.  If so and if CRLF immediately
-   follows the termination character, then the response from the POP
-   server is ended and the line containing ".CRLF" is not considered
-   part of the multi-line response.
-
-   A POP3 session progresses through a number of states during its
-   lifetime.  Once the TCP connection has been opened and the POP3
-   server has sent the greeting, the session enters the AUTHORIZATION
-   state.  In this state, the client must identify itself to the POP3
-   server.  Once the client has successfully done this, the server
-   acquires resources associated with the client's maildrop, and the
-   session enters the TRANSACTION state.  In this state, the client
-   requests actions on the part of the POP3 server.  When the client has
-
-
-
-Myers & Rose                Standards Track                     [Page 3]
-
-RFC 1939                          POP3                          May 1996
-
-
-   issued the QUIT command, the session enters the UPDATE state.  In
-   this state, the POP3 server releases any resources acquired during
-   the TRANSACTION state and says goodbye.  The TCP connection is then
-   closed.
-
-   A server MUST respond to an unrecognized, unimplemented, or
-   syntactically invalid command by responding with a negative status
-   indicator.  A server MUST respond to a command issued when the
-   session is in an incorrect state by responding with a negative status
-   indicator.  There is no general method for a client to distinguish
-   between a server which does not implement an optional command and a
-   server which is unwilling or unable to process the command.
-
-   A POP3 server MAY have an inactivity autologout timer.  Such a timer
-   MUST be of at least 10 minutes' duration.  The receipt of any command
-   from the client during that interval should suffice to reset the
-   autologout timer.  When the timer expires, the session does NOT enter
-   the UPDATE state--the server should close the TCP connection without
-   removing any messages or sending any response to the client.
-
-4. The AUTHORIZATION State
-
-   Once the TCP connection has been opened by a POP3 client, the POP3
-   server issues a one line greeting.  This can be any positive
-   response.  An example might be:
-
-      S:  +OK POP3 server ready
-
-   The POP3 session is now in the AUTHORIZATION state.  The client must
-   now identify and authenticate itself to the POP3 server.  Two
-   possible mechanisms for doing this are described in this document,
-   the USER and PASS command combination and the APOP command.  Both
-   mechanisms are described later in this document.  Additional
-   authentication mechanisms are described in [RFC1734].  While there is
-   no single authentication mechanism that is required of all POP3
-   servers, a POP3 server must of course support at least one
-   authentication mechanism.
-
-   Once the POP3 server has determined through the use of any
-   authentication command that the client should be given access to the
-   appropriate maildrop, the POP3 server then acquires an exclusive-
-   access lock on the maildrop, as necessary to prevent messages from
-   being modified or removed before the session enters the UPDATE state.
-   If the lock is successfully acquired, the POP3 server responds with a
-   positive status indicator.  The POP3 session now enters the
-   TRANSACTION state, with no messages marked as deleted.  If the
-   maildrop cannot be opened for some reason (for example, a lock can
-   not be acquired, the client is denied access to the appropriate
-
-
-
-Myers & Rose                Standards Track                     [Page 4]
-
-RFC 1939                          POP3                          May 1996
-
-
-   maildrop, or the maildrop cannot be parsed), the POP3 server responds
-   with a negative status indicator.  (If a lock was acquired but the
-   POP3 server intends to respond with a negative status indicator, the
-   POP3 server must release the lock prior to rejecting the command.)
-   After returning a negative status indicator, the server may close the
-   connection.  If the server does not close the connection, the client
-   may either issue a new authentication command and start again, or the
-   client may issue the QUIT command.
-
-   After the POP3 server has opened the maildrop, it assigns a message-
-   number to each message, and notes the size of each message in octets.
-   The first message in the maildrop is assigned a message-number of
-   "1", the second is assigned "2", and so on, so that the nth message
-   in a maildrop is assigned a message-number of "n".  In POP3 commands
-   and responses, all message-numbers and message sizes are expressed in
-   base-10 (i.e., decimal).
-
-   Here is the summary for the QUIT command when used in the
-   AUTHORIZATION state:
-
-      QUIT
-
-         Arguments: none
-
-         Restrictions: none
-
-         Possible Responses:
-             +OK
-
-         Examples:
-             C: QUIT
-             S: +OK dewey POP3 server signing off
-
-5. The TRANSACTION State
-
-   Once the client has successfully identified itself to the POP3 server
-   and the POP3 server has locked and opened the appropriate maildrop,
-   the POP3 session is now in the TRANSACTION state.  The client may now
-   issue any of the following POP3 commands repeatedly.  After each
-   command, the POP3 server issues a response.  Eventually, the client
-   issues the QUIT command and the POP3 session enters the UPDATE state.
-
-
-
-
-
-
-
-
-
-
-Myers & Rose                Standards Track                     [Page 5]
-
-RFC 1939                          POP3                          May 1996
-
-
-   Here are the POP3 commands valid in the TRANSACTION state:
-
-      STAT
-
-         Arguments: none
-
-         Restrictions:
-             may only be given in the TRANSACTION state
-
-         Discussion:
-             The POP3 server issues a positive response with a line
-             containing information for the maildrop.  This line is
-             called a "drop listing" for that maildrop.
-
-             In order to simplify parsing, all POP3 servers are
-             required to use a certain format for drop listings.  The
-             positive response consists of "+OK" followed by a single
-             space, the number of messages in the maildrop, a single
-             space, and the size of the maildrop in octets.  This memo
-             makes no requirement on what follows the maildrop size.
-             Minimal implementations should just end that line of the
-             response with a CRLF pair.  More advanced implementations
-             may include other information.
-
-                NOTE: This memo STRONGLY discourages implementations
-                from supplying additional information in the drop
-                listing.  Other, optional, facilities are discussed
-                later on which permit the client to parse the messages
-                in the maildrop.
-
-             Note that messages marked as deleted are not counted in
-             either total.
-
-         Possible Responses:
-             +OK nn mm
-
-         Examples:
-             C: STAT
-             S: +OK 2 320
-
-
-      LIST [msg]
-
-         Arguments:
-             a message-number (optional), which, if present, may NOT
-             refer to a message marked as deleted
-
-
-
-
-
-Myers & Rose                Standards Track                     [Page 6]
-
-RFC 1939                          POP3                          May 1996
-
-
-         Restrictions:
-             may only be given in the TRANSACTION state
-
-         Discussion:
-             If an argument was given and the POP3 server issues a
-             positive response with a line containing information for
-             that message.  This line is called a "scan listing" for
-             that message.
-
-             If no argument was given and the POP3 server issues a
-             positive response, then the response given is multi-line.
-             After the initial +OK, for each message in the maildrop,
-             the POP3 server responds with a line containing
-             information for that message.  This line is also called a
-             "scan listing" for that message.  If there are no
-             messages in the maildrop, then the POP3 server responds
-             with no scan listings--it issues a positive response
-             followed by a line containing a termination octet and a
-             CRLF pair.
-
-             In order to simplify parsing, all POP3 servers are
-             required to use a certain format for scan listings.  A
-             scan listing consists of the message-number of the
-             message, followed by a single space and the exact size of
-             the message in octets.  Methods for calculating the exact
-             size of the message are described in the "Message Format"
-             section below.  This memo makes no requirement on what
-             follows the message size in the scan listing.  Minimal
-             implementations should just end that line of the response
-             with a CRLF pair.  More advanced implementations may
-             include other information, as parsed from the message.
-
-                NOTE: This memo STRONGLY discourages implementations
-                from supplying additional information in the scan
-                listing.  Other, optional, facilities are discussed
-                later on which permit the client to parse the messages
-                in the maildrop.
-
-             Note that messages marked as deleted are not listed.
-
-         Possible Responses:
-             +OK scan listing follows
-             -ERR no such message
-
-         Examples:
-             C: LIST
-             S: +OK 2 messages (320 octets)
-             S: 1 120
-
-
-
-Myers & Rose                Standards Track                     [Page 7]
-
-RFC 1939                          POP3                          May 1996
-
-
-             S: 2 200
-             S: .
-               ...
-             C: LIST 2
-             S: +OK 2 200
-               ...
-             C: LIST 3
-             S: -ERR no such message, only 2 messages in maildrop
-
-
-      RETR msg
-
-         Arguments:
-             a message-number (required) which may NOT refer to a
-             message marked as deleted
-
-         Restrictions:
-             may only be given in the TRANSACTION state
-
-         Discussion:
-             If the POP3 server issues a positive response, then the
-             response given is multi-line.  After the initial +OK, the
-             POP3 server sends the message corresponding to the given
-             message-number, being careful to byte-stuff the termination
-             character (as with all multi-line responses).
-
-         Possible Responses:
-             +OK message follows
-             -ERR no such message
-
-         Examples:
-             C: RETR 1
-             S: +OK 120 octets
-             S: <the POP3 server sends the entire message here>
-             S: .
-
-
-      DELE msg
-
-         Arguments:
-             a message-number (required) which may NOT refer to a
-             message marked as deleted
-
-         Restrictions:
-             may only be given in the TRANSACTION state
-
-
-
-
-
-
-Myers & Rose                Standards Track                     [Page 8]
-
-RFC 1939                          POP3                          May 1996
-
-
-         Discussion:
-             The POP3 server marks the message as deleted.  Any future
-             reference to the message-number associated with the message
-             in a POP3 command generates an error.  The POP3 server does
-             not actually delete the message until the POP3 session
-             enters the UPDATE state.
-
-         Possible Responses:
-             +OK message deleted
-             -ERR no such message
-
-         Examples:
-             C: DELE 1
-             S: +OK message 1 deleted
-                ...
-             C: DELE 2
-             S: -ERR message 2 already deleted
-
-
-      NOOP
-
-         Arguments: none
-
-         Restrictions:
-             may only be given in the TRANSACTION state
-
-         Discussion:
-             The POP3 server does nothing, it merely replies with a
-             positive response.
-
-         Possible Responses:
-             +OK
-
-         Examples:
-             C: NOOP
-             S: +OK
-
-
-      RSET
-
-         Arguments: none
-
-         Restrictions:
-             may only be given in the TRANSACTION state
-
-         Discussion:
-             If any messages have been marked as deleted by the POP3
-             server, they are unmarked.  The POP3 server then replies
-
-
-
-Myers & Rose                Standards Track                     [Page 9]
-
-RFC 1939                          POP3                          May 1996
-
-
-             with a positive response.
-
-         Possible Responses:
-             +OK
-
-         Examples:
-             C: RSET
-             S: +OK maildrop has 2 messages (320 octets)
-
-6. The UPDATE State
-
-   When the client issues the QUIT command from the TRANSACTION state,
-   the POP3 session enters the UPDATE state.  (Note that if the client
-   issues the QUIT command from the AUTHORIZATION state, the POP3
-   session terminates but does NOT enter the UPDATE state.)
-
-   If a session terminates for some reason other than a client-issued
-   QUIT command, the POP3 session does NOT enter the UPDATE state and
-   MUST not remove any messages from the maildrop.
-
-      QUIT
-
-         Arguments: none
-
-         Restrictions: none
-
-         Discussion:
-             The POP3 server removes all messages marked as deleted
-             from the maildrop and replies as to the status of this
-             operation.  If there is an error, such as a resource
-             shortage, encountered while removing messages, the
-             maildrop may result in having some or none of the messages
-             marked as deleted be removed.  In no case may the server
-             remove any messages not marked as deleted.
-
-             Whether the removal was successful or not, the server
-             then releases any exclusive-access lock on the maildrop
-             and closes the TCP connection.
-
-         Possible Responses:
-             +OK
-             -ERR some deleted messages not removed
-
-         Examples:
-             C: QUIT
-             S: +OK dewey POP3 server signing off (maildrop empty)
-                ...
-             C: QUIT
-
-
-
-Myers & Rose                Standards Track                    [Page 10]
-
-RFC 1939                          POP3                          May 1996
-
-
-             S: +OK dewey POP3 server signing off (2 messages left)
-                ...
-
-7. Optional POP3 Commands
-
-   The POP3 commands discussed above must be supported by all minimal
-   implementations of POP3 servers.
-
-   The optional POP3 commands described below permit a POP3 client
-   greater freedom in message handling, while preserving a simple POP3
-   server implementation.
-
-      NOTE: This memo STRONGLY encourages implementations to support
-      these commands in lieu of developing augmented drop and scan
-      listings.  In short, the philosophy of this memo is to put
-      intelligence in the part of the POP3 client and not the POP3
-      server.
-
-      TOP msg n
-
-         Arguments:
-             a message-number (required) which may NOT refer to to a
-             message marked as deleted, and a non-negative number
-             of lines (required)
-
-         Restrictions:
-             may only be given in the TRANSACTION state
-
-         Discussion:
-             If the POP3 server issues a positive response, then the
-             response given is multi-line.  After the initial +OK, the
-             POP3 server sends the headers of the message, the blank
-             line separating the headers from the body, and then the
-             number of lines of the indicated message's body, being
-             careful to byte-stuff the termination character (as with
-             all multi-line responses).
-
-             Note that if the number of lines requested by the POP3
-             client is greater than than the number of lines in the
-             body, then the POP3 server sends the entire message.
-
-         Possible Responses:
-             +OK top of message follows
-             -ERR no such message
-
-         Examples:
-             C: TOP 1 10
-             S: +OK
-
-
-
-Myers & Rose                Standards Track                    [Page 11]
-
-RFC 1939                          POP3                          May 1996
-
-
-             S: <the POP3 server sends the headers of the
-                message, a blank line, and the first 10 lines
-                of the body of the message>
-             S: .
-                ...
-             C: TOP 100 3
-             S: -ERR no such message
-
-
-      UIDL [msg]
-
-      Arguments:
-          a message-number (optional), which, if present, may NOT
-          refer to a message marked as deleted
-
-      Restrictions:
-          may only be given in the TRANSACTION state.
-
-      Discussion:
-          If an argument was given and the POP3 server issues a positive
-          response with a line containing information for that message.
-          This line is called a "unique-id listing" for that message.
-
-          If no argument was given and the POP3 server issues a positive
-          response, then the response given is multi-line.  After the
-          initial +OK, for each message in the maildrop, the POP3 server
-          responds with a line containing information for that message.
-          This line is called a "unique-id listing" for that message.
-
-          In order to simplify parsing, all POP3 servers are required to
-          use a certain format for unique-id listings.  A unique-id
-          listing consists of the message-number of the message,
-          followed by a single space and the unique-id of the message.
-          No information follows the unique-id in the unique-id listing.
-
-          The unique-id of a message is an arbitrary server-determined
-          string, consisting of one to 70 characters in the range 0x21
-          to 0x7E, which uniquely identifies a message within a
-          maildrop and which persists across sessions.  This
-          persistence is required even if a session ends without
-          entering the UPDATE state.  The server should never reuse an
-          unique-id in a given maildrop, for as long as the entity
-          using the unique-id exists.
-
-          Note that messages marked as deleted are not listed.
-
-          While it is generally preferable for server implementations
-          to store arbitrarily assigned unique-ids in the maildrop,
-
-
-
-Myers & Rose                Standards Track                    [Page 12]
-
-RFC 1939                          POP3                          May 1996
-
-
-          this specification is intended to permit unique-ids to be
-          calculated as a hash of the message.  Clients should be able
-          to handle a situation where two identical copies of a
-          message in a maildrop have the same unique-id.
-
-      Possible Responses:
-          +OK unique-id listing follows
-          -ERR no such message
-
-      Examples:
-          C: UIDL
-          S: +OK
-          S: 1 whqtswO00WBw418f9t5JxYwZ
-          S: 2 QhdPYR:00WBw1Ph7x7
-          S: .
-             ...
-          C: UIDL 2
-          S: +OK 2 QhdPYR:00WBw1Ph7x7
-             ...
-          C: UIDL 3
-          S: -ERR no such message, only 2 messages in maildrop
-
-
-      USER name
-
-         Arguments:
-             a string identifying a mailbox (required), which is of
-             significance ONLY to the server
-
-         Restrictions:
-             may only be given in the AUTHORIZATION state after the POP3
-             greeting or after an unsuccessful USER or PASS command
-
-         Discussion:
-             To authenticate using the USER and PASS command
-             combination, the client must first issue the USER
-             command.  If the POP3 server responds with a positive
-             status indicator ("+OK"), then the client may issue
-             either the PASS command to complete the authentication,
-             or the QUIT command to terminate the POP3 session.  If
-             the POP3 server responds with a negative status indicator
-             ("-ERR") to the USER command, then the client may either
-             issue a new authentication command or may issue the QUIT
-             command.
-
-             The server may return a positive response even though no
-             such mailbox exists.  The server may return a negative
-             response if mailbox exists, but does not permit plaintext
-
-
-
-Myers & Rose                Standards Track                    [Page 13]
-
-RFC 1939                          POP3                          May 1996
-
-
-             password authentication.
-
-         Possible Responses:
-             +OK name is a valid mailbox
-             -ERR never heard of mailbox name
-
-         Examples:
-             C: USER frated
-             S: -ERR sorry, no mailbox for frated here
-                ...
-             C: USER mrose
-             S: +OK mrose is a real hoopy frood
-
-
-      PASS string
-
-         Arguments:
-             a server/mailbox-specific password (required)
-
-         Restrictions:
-             may only be given in the AUTHORIZATION state immediately
-             after a successful USER command
-
-         Discussion:
-             When the client issues the PASS command, the POP3 server
-             uses the argument pair from the USER and PASS commands to
-             determine if the client should be given access to the
-             appropriate maildrop.
-
-             Since the PASS command has exactly one argument, a POP3
-             server may treat spaces in the argument as part of the
-             password, instead of as argument separators.
-
-         Possible Responses:
-             +OK maildrop locked and ready
-             -ERR invalid password
-             -ERR unable to lock maildrop
-
-         Examples:
-             C: USER mrose
-             S: +OK mrose is a real hoopy frood
-             C: PASS secret
-             S: -ERR maildrop already locked
-               ...
-             C: USER mrose
-             S: +OK mrose is a real hoopy frood
-             C: PASS secret
-             S: +OK mrose's maildrop has 2 messages (320 octets)
-
-
-
-Myers & Rose                Standards Track                    [Page 14]
-
-RFC 1939                          POP3                          May 1996
-
-
-      APOP name digest
-
-         Arguments:
-             a string identifying a mailbox and a MD5 digest string
-             (both required)
-
-         Restrictions:
-             may only be given in the AUTHORIZATION state after the POP3
-             greeting or after an unsuccessful USER or PASS command
-
-         Discussion:
-             Normally, each POP3 session starts with a USER/PASS
-             exchange.  This results in a server/user-id specific
-             password being sent in the clear on the network.  For
-             intermittent use of POP3, this may not introduce a sizable
-             risk.  However, many POP3 client implementations connect to
-             the POP3 server on a regular basis -- to check for new
-             mail.  Further the interval of session initiation may be on
-             the order of five minutes.  Hence, the risk of password
-             capture is greatly enhanced.
-
-             An alternate method of authentication is required which
-             provides for both origin authentication and replay
-             protection, but which does not involve sending a password
-             in the clear over the network.  The APOP command provides
-             this functionality.
-
-             A POP3 server which implements the APOP command will
-             include a timestamp in its banner greeting.  The syntax of
-             the timestamp corresponds to the `msg-id' in [RFC822], and
-             MUST be different each time the POP3 server issues a banner
-             greeting.  For example, on a UNIX implementation in which a
-             separate UNIX process is used for each instance of a POP3
-             server, the syntax of the timestamp might be:
-
-                <process-ID.clock@hostname>
-
-             where `process-ID' is the decimal value of the process's
-             PID, clock is the decimal value of the system clock, and
-             hostname is the fully-qualified domain-name corresponding
-             to the host where the POP3 server is running.
-
-             The POP3 client makes note of this timestamp, and then
-             issues the APOP command.  The `name' parameter has
-             identical semantics to the `name' parameter of the USER
-             command. The `digest' parameter is calculated by applying
-             the MD5 algorithm [RFC1321] to a string consisting of the
-             timestamp (including angle-brackets) followed by a shared
-
-
-
-Myers & Rose                Standards Track                    [Page 15]
-
-RFC 1939                          POP3                          May 1996
-
-
-             secret.  This shared secret is a string known only to the
-             POP3 client and server.  Great care should be taken to
-             prevent unauthorized disclosure of the secret, as knowledge
-             of the secret will allow any entity to successfully
-             masquerade as the named user.  The `digest' parameter
-             itself is a 16-octet value which is sent in hexadecimal
-             format, using lower-case ASCII characters.
-
-             When the POP3 server receives the APOP command, it verifies
-             the digest provided.  If the digest is correct, the POP3
-             server issues a positive response, and the POP3 session
-             enters the TRANSACTION state.  Otherwise, a negative
-             response is issued and the POP3 session remains in the
-             AUTHORIZATION state.
-
-             Note that as the length of the shared secret increases, so
-             does the difficulty of deriving it.  As such, shared
-             secrets should be long strings (considerably longer than
-             the 8-character example shown below).
-
-         Possible Responses:
-             +OK maildrop locked and ready
-             -ERR permission denied
-
-         Examples:
-             S: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us>
-             C: APOP mrose c4c9334bac560ecc979e58001b3e22fb
-             S: +OK maildrop has 1 message (369 octets)
-
-             In this example, the shared  secret  is  the  string  `tan-
-             staaf'.  Hence, the MD5 algorithm is applied to the string
-
-                <1896.697170952@dbc.mtview.ca.us>tanstaaf
-
-             which produces a digest value of
-
-                c4c9334bac560ecc979e58001b3e22fb
-
-8. Scaling and Operational Considerations
-
-   Since some of the optional features described above were added to the
-   POP3 protocol, experience has accumulated in using them in large-
-   scale commercial post office operations where most of the users are
-   unrelated to each other.  In these situations and others, users and
-   vendors of POP3 clients have discovered that the combination of using
-   the UIDL command and not issuing the DELE command can provide a weak
-   version of the "maildrop as semi-permanent repository" functionality
-   normally associated with IMAP.  Of course the other capabilities of
-
-
-
-Myers & Rose                Standards Track                    [Page 16]
-
-RFC 1939                          POP3                          May 1996
-
-
-   IMAP, such as polling an existing connection for newly arrived
-   messages and supporting multiple folders on the server, are not
-   present in POP3.
-
-   When these facilities are used in this way by casual users, there has
-   been a tendency for already-read messages to accumulate on the server
-   without bound.  This is clearly an undesirable behavior pattern from
-   the standpoint of the server operator.  This situation is aggravated
-   by the fact that the limited capabilities of the POP3 do not permit
-   efficient handling of maildrops which have hundreds or thousands of
-   messages.
-
-   Consequently, it is recommended that operators of large-scale multi-
-   user servers, especially ones in which the user's only access to the
-   maildrop is via POP3, consider such options as:
-
-   *  Imposing a per-user maildrop storage quota or the like.
-
-      A disadvantage to this option is that accumulation of messages may
-      result in the user's inability to receive new ones into the
-      maildrop.  Sites which choose this option should be sure to inform
-      users of impending or current exhaustion of quota, perhaps by
-      inserting an appropriate message into the user's maildrop.
-
-   *  Enforce a site policy regarding mail retention on the server.
-
-      Sites are free to establish local policy regarding the storage and
-      retention of messages on the server, both read and unread.  For
-      example, a site might delete unread messages from the server after
-      60 days and delete read messages after 7 days.  Such message
-      deletions are outside the scope of the POP3 protocol and are not
-      considered a protocol violation.
-
-      Server operators enforcing message deletion policies should take
-      care to make all users aware of the policies in force.
-
-      Clients must not assume that a site policy will automate message
-      deletions, and should continue to explicitly delete messages using
-      the DELE command when appropriate.
-
-      It should be noted that enforcing site message deletion policies
-      may be confusing to the user community, since their POP3 client
-      may contain configuration options to leave mail on the server
-      which will not in fact be supported by the server.
-
-      One special case of a site policy is that messages may only be
-      downloaded once from the server, and are deleted after this has
-      been accomplished.  This could be implemented in POP3 server
-
-
-
-Myers & Rose                Standards Track                    [Page 17]
-
-RFC 1939                          POP3                          May 1996
-
-
-      software by the following mechanism: "following a POP3 login by a
-      client which was ended by a QUIT, delete all messages downloaded
-      during the session with the RETR command".  It is important not to
-      delete messages in the event of abnormal connection termination
-      (ie, if no QUIT was received from the client) because the client
-      may not have successfully received or stored the messages.
-      Servers implementing a download-and-delete policy may also wish to
-      disable or limit the optional TOP command, since it could be used
-      as an alternate mechanism to download entire messages.
-
-9. POP3 Command Summary
-
-      Minimal POP3 Commands:
-
-         USER name               valid in the AUTHORIZATION state
-         PASS string
-         QUIT
-
-         STAT                    valid in the TRANSACTION state
-         LIST [msg]
-         RETR msg
-         DELE msg
-         NOOP
-         RSET
-         QUIT
-
-      Optional POP3 Commands:
-
-         APOP name digest        valid in the AUTHORIZATION state
-
-         TOP msg n               valid in the TRANSACTION state
-         UIDL [msg]
-
-      POP3 Replies:
-
-         +OK
-         -ERR
-
-      Note that with the exception of the STAT, LIST, and UIDL commands,
-      the reply given by the POP3 server to any command is significant
-      only to "+OK" and "-ERR".  Any text occurring after this reply
-      may be ignored by the client.
-
-
-
-
-
-
-
-
-
-Myers & Rose                Standards Track                    [Page 18]
-
-RFC 1939                          POP3                          May 1996
-
-
-10. Example POP3 Session
-
-      S: <wait for connection on TCP port 110>
-      C: <open connection>
-      S:    +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us>
-      C:    APOP mrose c4c9334bac560ecc979e58001b3e22fb
-      S:    +OK mrose's maildrop has 2 messages (320 octets)
-      C:    STAT
-      S:    +OK 2 320
-      C:    LIST
-      S:    +OK 2 messages (320 octets)
-      S:    1 120
-      S:    2 200
-      S:    .
-      C:    RETR 1
-      S:    +OK 120 octets
-      S:    <the POP3 server sends message 1>
-      S:    .
-      C:    DELE 1
-      S:    +OK message 1 deleted
-      C:    RETR 2
-      S:    +OK 200 octets
-      S:    <the POP3 server sends message 2>
-      S:    .
-      C:    DELE 2
-      S:    +OK message 2 deleted
-      C:    QUIT
-      S:    +OK dewey POP3 server signing off (maildrop empty)
-      C:  <close connection>
-      S:  <wait for next connection>
-
-11. Message Format
-
-   All messages transmitted during a POP3 session are assumed to conform
-   to the standard for the format of Internet text messages [RFC822].
-
-   It is important to note that the octet count for a message on the
-   server host may differ from the octet count assigned to that message
-   due to local conventions for designating end-of-line.  Usually,
-   during the AUTHORIZATION state of the POP3 session, the POP3 server
-   can calculate the size of each message in octets when it opens the
-   maildrop.  For example, if the POP3 server host internally represents
-   end-of-line as a single character, then the POP3 server simply counts
-   each occurrence of this character in a message as two octets.  Note
-   that lines in the message which start with the termination octet need
-   not (and must not) be counted twice, since the POP3 client will
-   remove all byte-stuffed termination characters when it receives a
-   multi-line response.
-
-
-
-Myers & Rose                Standards Track                    [Page 19]
-
-RFC 1939                          POP3                          May 1996
-
-
-12. References
-
-   [RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
-       821, USC/Information Sciences Institute, August 1982.
-
-   [RFC822] Crocker, D., "Standard for the Format of ARPA-Internet Text
-       Messages", STD 11, RFC 822, University of Delaware, August 1982.
-
-   [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
-       MIT Laboratory for Computer Science, April 1992.
-
-   [RFC1730] Crispin, M., "Internet Message Access Protocol - Version
-       4", RFC 1730, University of Washington, December 1994.
-
-   [RFC1734] Myers, J., "POP3 AUTHentication command", RFC 1734,
-       Carnegie Mellon, December 1994.
-
-13. Security Considerations
-
-   It is conjectured that use of the APOP command provides origin
-   identification and replay protection for a POP3 session.
-   Accordingly, a POP3 server which implements both the PASS and APOP
-   commands should not allow both methods of access for a given user;
-   that is, for a given mailbox name, either the USER/PASS command
-   sequence or the APOP command is allowed, but not both.
-
-   Further, note that as the length of the shared secret increases, so
-   does the difficulty of deriving it.
-
-   Servers that answer -ERR to the USER command are giving potential
-   attackers clues about which names are valid.
-
-   Use of the PASS command sends passwords in the clear over the
-   network.
-
-   Use of the RETR and TOP commands sends mail in the clear over the
-   network.
-
-   Otherwise, security issues are not discussed in this memo.
-
-14. Acknowledgements
-
-   The POP family has a long and checkered history.  Although primarily
-   a minor revision to RFC 1460, POP3 is based on the ideas presented in
-   RFCs 918, 937, and 1081.
-
-   In addition, Alfred Grimstad, Keith McCloghrie, and Neil Ostroff
-   provided significant comments on the APOP command.
-
-
-
-Myers & Rose                Standards Track                    [Page 20]
-
-RFC 1939                          POP3                          May 1996
-
-
-15. Authors' Addresses
-
-   John G. Myers
-   Carnegie-Mellon University
-   5000 Forbes Ave
-   Pittsburgh, PA 15213
-
-   EMail: jgm+@cmu.edu
-
-
-   Marshall T. Rose
-   Dover Beach Consulting, Inc.
-   420 Whisman Court
-   Mountain View, CA  94043-2186
-
-   EMail: mrose@dbc.mtview.ca.us
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Myers & Rose                Standards Track                    [Page 21]
-
-RFC 1939                          POP3                          May 1996
-
-
-Appendix A. Differences from RFC 1725
-
-   This memo is a revision to RFC 1725, a Draft Standard.  It makes the
-   following changes from that document:
-
-      - clarifies that command keywords are case insensitive.
-
-      - specifies that servers must send "+OK" and "-ERR" in
-        upper case.
-
-      - specifies that the initial greeting is a positive response,
-        instead of any string which should be a positive response.
-
-      - clarifies behavior for unimplemented commands.
-
-      - makes the USER and PASS commands optional.
-
-      - clarified the set of possible responses to the USER command.
-
-      - reverses the order of the examples in the USER and PASS
-        commands, to reduce confusion.
-
-      - clarifies that the PASS command may only be given immediately
-        after a successful USER command.
-
-      - clarified the persistence requirements of UIDs and added some
-        implementation notes.
-
-      - specifies a UID length limitation of one to 70 octets.
-
-      - specifies a status indicator length limitation
-        of 512 octets, including the CRLF.
-
-      - clarifies that LIST with no arguments on an empty mailbox
-        returns success.
-
-      - adds a reference from the LIST command to the Message Format
-        section
-
-      - clarifies the behavior of QUIT upon failure
-
-      - clarifies the security section to not imply the use of the
-        USER command with the APOP command.
-
-      - adds references to RFCs 1730 and 1734
-
-      - clarifies the method by which a UA may enter mail into the
-        transport system.
-
-
-
-Myers & Rose                Standards Track                    [Page 22]
-
-RFC 1939                          POP3                          May 1996
-
-
-      - clarifies that the second argument to the TOP command is a
-        number of lines.
-
-      - changes the suggestion in the Security Considerations section
-        for a server to not accept both PASS and APOP for a given user
-        from a "must" to a "should".
-
-      - adds a section on scaling and operational considerations
-
-Appendix B. Command Index
-
-       APOP .......................................................   15
-       DELE .......................................................    8
-       LIST .......................................................    6
-       NOOP .......................................................    9
-       PASS .......................................................   14
-       QUIT .......................................................    5
-       QUIT .......................................................   10
-       RETR .......................................................    8
-       RSET .......................................................    9
-       STAT .......................................................    6
-       TOP ........................................................   11
-       UIDL .......................................................   12
-       USER .......................................................   13
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Myers & Rose                Standards Track                    [Page 23]
-
diff --git a/RFC/rfc1985.txt b/RFC/rfc1985.txt
deleted file mode 100644
index f49afd75..00000000
--- a/RFC/rfc1985.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-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/RFC/rfc2033.txt b/RFC/rfc2033.txt
deleted file mode 100644
index a47433e8..00000000
--- a/RFC/rfc2033.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                           J. Myers
-Request for Comments: 2033                               Carnegie Mellon
-Category: Informational                                     October 1996
-
-
-                      Local Mail Transfer Protocol
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  This memo
-   does not specify an Internet standard of any kind.  Distribution of
-   this memo is unlimited.
-
-1.  Abstract
-
-   SMTP [SMTP] [HOST-REQ] and its service extensions [ESMTP] provide a
-   mechanism for transferring mail reliably and efficiently.  The design
-   of the SMTP protocol effectively requires the server to manage a mail
-   delivery queue.
-
-   In some limited circumstances, outside the area of mail exchange
-   between independent hosts on public networks, it is desirable to
-   implement a system where a mail receiver does not manage a queue.
-   This document describes the LMTP protocol for transporting mail into
-   such systems.
-
-   Although LMTP is an alternative protocol to ESMTP, it uses (with a
-   few changes) the syntax and semantics of ESMTP.  This design permits
-   LMTP to utilize the extensions defined for ESMTP.  LMTP should be
-   used only by specific prior arrangement and configuration, and it
-   MUST NOT be used on TCP port 25.
-
-Table of Contents
-
-   1.   Abstract ................................................    1
-   2.   Conventions Used in this Document .......................    2
-   3.   Introduction and Overview ...............................    2
-   4.   The LMTP protocol .......................................    3
-   4.1. The LHLO, HELO and EHLO commands ........................    4
-   4.2. The DATA command ........................................    4
-   4.3. The BDAT command ........................................    5
-   5.   Implementation requirements .............................    6
-   6.   Acknowledgments .........................................    6
-   7.   References ..............................................    7
-   8.   Security Considerations .................................    7
-   9.   Author's Address ........................................    7
-
-
-
-
-
-Myers                        Informational                      [Page 1]
-
-RFC 2033                          LMTP                      October 1996
-
-
-2.  Conventions Used in this Document
-
-   In examples, "C:" and "S:" indicate lines sent by the client and
-   server respectively.
-
-3.  Introduction and Overview
-
-   The design of the SMTP protocol effectively requires the server to
-   manage a mail delivery queue.  This is because a single mail
-   transaction may specify multiple recipients and the final "." of the
-   DATA command may return only one reply code, to indicate the status
-   of the entire transaction.  If, for example, a server is given a
-   transaction for two recipients, delivery to the first succeeds, and
-   delivery to the second encounters a temporary failure condition,
-   there is no mechanism to inform the client of the situation.  The
-   server must queue the message and later attempt to deliver it to the
-   second recipient.
-
-   This queuing requirement is beneficial in the situation for which
-   SMTP was originally designed: store-and-forward relay of mail between
-   networked hosts.  In some limited situations, it is desirable to have
-   a server which does not manage a queue, instead relying on the client
-   to perform queue management.  As an example, consider a hypothetical
-   host with a mail system designed as follows:
-
-
-
-                    TCP port 25 +-----------------+
-         ---------------------->|                 |  #########
-                                |      Queue      |<># Mail  #
-         TCP port 25            |     Manager     |  # Queue #
-         <----------------------|                 |  #########
-                                +-----------------+
-                            Local *  ^ Local    * Local
-                              IPC *  | IPC      * IPC
-                                  *  |          *
-                                  *  |          *
-                                  *  |          *
-                                  V  |          V
-                  Non-SMTP    +----------+     +----------+
-                  Protocol    | Gateway  |     |  Local   |  #########
-              <==============>| Delivery |     | Delivery |>># Mail  #
-                              |  Agent   |     |  Agent   |  # Spool #
-                              +----------+     +----------+  #########
-
-
-   The host's mail system has three independent, communicating
-   subsystems.  The first is a queue manager, which acts as a
-
-
-
-Myers                        Informational                      [Page 2]
-
-RFC 2033                          LMTP                      October 1996
-
-
-   traditional SMTP agent, transferring messages to and from other hosts
-   over TCP and managing a mail queue in persistent storage.  The other
-   two are agents which handle delivery for addresses in domains for
-   which the host takes responsibility.  One agent performs gatewaying
-   to and from some other mail system.  The other agent delivers the
-   message into a persistent mail spool.
-
-   It would be desirable to use SMTP over a local inter-process
-   communication channel to transfer messages from the queue manager to
-   the delivery agents.  It would, however, significantly increase the
-   complexity of the delivery agents to require them to manage their own
-   mail queues.
-
-   The common practice of invoking a delivery agent with the envelope
-   address(es) as command-line arguments, then having the delivery agent
-   communicate status with an exit code has three serious problems: the
-   agent can only return one exit code to be applied to all recipients,
-   it is difficult to extend the interface to deal with ESMTP extensions
-   such as DSN [DSN] and ENHANCEDSTATUSCODES [ENHANCEDSTATUSCODES], and
-   exits performed by system libraries due to temporary conditions
-   frequently get interpreted as permanent errors.
-
-   The LMTP protocol causes the server to return, after the final "." of
-   the DATA command, one reply for each recipient.  Therefore, if the
-   queue manager is configured to use LMTP instead of SMTP when
-   transferring messages to the delivery agents, then the delivery
-   agents may attempt delivery to each recipient after the final "." and
-   individually report the status for each recipient.  Connections which
-   should use the LMTP protocol are drawn in the diagram above using
-   asterisks.
-
-   Note that it is not beneficial to use the LMTP protocol when
-   transferring messages to the queue manager, either from the network
-   or from a delivery agent.  The queue manager does implement a mail
-   queue, so it may store the message and take responsibility for later
-   delivering it.
-
-4.  The LMTP protocol
-
-   The LMTP protocol is identical to the SMTP protocol SMTP [SMTP]
-   [HOST-REQ] with its service extensions [ESMTP], except as modified by
-   this document.
-
-   A "successful" RCPT command is defined as an RCPT command which
-   returns a Positive Completion reply code.
-
-   A "Positive Completion reply code" is defined in Appendix E of STD
-   10, RFC 821 [SMTP] as a reply code which "2" as the first digit.
-
-
-
-Myers                        Informational                      [Page 3]
-
-RFC 2033                          LMTP                      October 1996
-
-
-4.1.  The LHLO, HELO and EHLO commands
-
-   The HELO and EHLO commands of ESMTP are replaced by the LHLO command.
-   This permits a misconfiguration where both parties are not using the
-   same protocol to be detected.
-
-   The LHLO command has identical semantics to the EHLO command of ESMTP
-   [ESMTP].
-
-   The HELO and EHLO commands of ESMTP are not present in LMTP.  A LMTP
-   server MUST NOT return a Postive Completion reply code to these
-   commands.  The 500 reply code is recommended.
-
-4.2.  The DATA command
-
-   In the LMTP protocol, there is one additional restriction placed on
-   the DATA command, and one change to how replies to the final "." are
-   sent.
-
-   The additional restriction is that when there have been no successful
-   RCPT commands in the mail transaction, the DATA command MUST fail
-   with a 503 reply code.
-
-   The change is that after the final ".", the server returns one reply
-   for each previously successful RCPT command in the mail transaction,
-   in the order that the RCPT commands were issued.  Even if there were
-   multiple successful RCPT commands giving the same forward-path, there
-   must be one reply for each successful RCPT command.
-
-   When one of these replies to the final "." is a Positive Completion
-   reply, the server is accepting responsibility for delivering or
-   relying the message to the corresponding recipient.  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.
-
-   A multiline reply is still considered a single reply and corresponds
-   to a single RCPT command.
-
-   EXAMPLE:
-
-   S: 220 foo.edu LMTP server ready
-   C: LHLO foo.edu
-   S: 250-foo.edu
-   S: 250-PIPELINING
-   S: 250 SIZE
-   C: MAIL FROM:<chris@bar.com>
-   S: 250 OK
-
-
-
-Myers                        Informational                      [Page 4]
-
-RFC 2033                          LMTP                      October 1996
-
-
-   C: RCPT TO:<pat@foo.edu>
-   S: 250 OK
-   C: RCPT TO:<jones@foo.edu>
-   S: 550 No such user here
-   C: RCPT TO:<green@foo.edu>
-   S: 250 OK
-   C: DATA
-   S: 354 Start mail input; end with <CRLF>.<CRLF>
-   C: Blah blah blah...
-   C: ...etc. etc. etc.
-   C: .
-   S: 250 OK
-   S: 452 <green@foo.edu> is temporarily over quota
-   C: QUIT
-   S: 221 foo.edu closing connection
-
-
-NOTE: in the above example, the domain names of both the client and
-   server are identical.  This is because in the example the client and
-   server are different subsystems of the same mail domain.
-
-4.3.  The BDAT command
-
-   If the server supports the ESMTP CHUNKING extension [BINARYMIME], a
-   BDAT command containing the LAST parameter returns one reply for each
-   previously successful RCPT command in the mail transaction, in the
-   order that the RCPT commands were issued.  Even if there were
-   multiple successful RCPT commands giving the same forward-path, there
-   must be one reply for each successful RCPT command.  If there were no
-   previously successful RCPT commands in the mail transaction, then the
-   BDAT LAST command returns zero replies.
-
-   When one of these replies to the BDAT LAST command is a Positive
-   Completion reply, the server is accepting responsibility for
-   delivering or relaying the message to the corresponding recipient.
-   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.
-
-   A multiline reply is still considered a single reply and corresponds
-   to a single RCPT command.
-
-   The behavior of BDAT commands without the LAST parameter is not
-   changed; they still return exactly one reply.
-
-
-
-
-
-
-
-Myers                        Informational                      [Page 5]
-
-RFC 2033                          LMTP                      October 1996
-
-
-5.  Implementation requirements
-
-   As LMTP is a different protocol than SMTP, it MUST NOT be used on the
-   TCP service port 25.
-
-   A server implementation MUST implement the PIPELINING [PIPELINING]
-   and ENHANCEDSTATUSCODES [ENHANCEDSTATUSCODES] ESMTP extensions.  A
-   server implementation SHOULD implement the 8BITMIME [8BITMIME]
-   extension.
-
-   Use of LMTP can aggravate the situation described in [DUP-MSGS].  To
-   avoid this synchronization problem, the following requirements are
-   made of implementations:
-
-   A server implementation which is capable of quickly accepting
-   responsibility for delivering or relaying a message to multiple
-   recipients and which is capable of sending any necessary notification
-   messages SHOULD NOT implement the LMTP protocol.
-
-   The LMTP protocol SHOULD NOT be used over wide area networks.
-
-   The server SHOULD send each reply as soon as possible.  If it is
-   going to spend a nontrivial amount of time handling delivery for the
-   next recipient, it SHOULD flush any outgoing LMTP buffer, so the
-   reply may be quickly received by the client.
-
-   The client SHOULD process the replies as they come in, instead of
-   waiting for all of the replies to arrive before processing any of
-   them.  If the connection closes after replies for some, but not all,
-   recipients have arrived, the client MUST process the replies that
-   arrived and treat the rest as temporary failures.
-
-6.  Acknowledgments
-
-   This work is a refinement of the MULT extension, which was invented
-   by Jeff Michaud and was used in implementing gateways to the Mail-11
-   mail system.
-
-   Many thanks to Matt Thomas for assisting me in understanding the
-   semantics of the Mail-11 MULT extension.
-
-
-
-
-
-
-
-
-
-
-
-Myers                        Informational                      [Page 6]
-
-RFC 2033                          LMTP                      October 1996
-
-
-7.  References
-
-   [8BITMIME] Klensin, J., et. al, "SMTP Service Extension for 8bit-MIME
-       transport", RFC 1652, July 1994.
-
-   [BINARYMIME] Vaudreuil, G., "SMTP Service Extensions for Transmission
-       of Large and Binary MIME Messages", RFC 1830, August 1995.
-
-   [DSN] Moore, K., Vaudreuil, G., "An Extensible Message Format for
-       Delivery Status Notifications", RFC 1894, January 1996.
-
-   [DUP-MSGS] Partridge, C., "Duplicate messages and SMTP", RFC 1047,
-       February 1988.
-
-   [ENHANCEDSTATUSCODES] Freed, N., "SMTP Service Extension for
-       Returning Enhanced Error Codes", RFC 2034, October 1996.
-
-   [ESMTP] Rose, M., Stefferud, E., Crocker, C., Klensin, J., Freed, N.,
-       "SMTP Service Extensions", RFC 1869, November 1995.
-
-   [HOST-REQ] Braden, R., "Requirements for Internet hosts - application
-       and support", STD 3, RFC 1123 section 5, October 1989.
-
-   [PIPELINING] Freed, N., Cargille, A, "SMTP Service Extension for
-       Command Pipelining", RFC 1854, October 1995.
-
-   [SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
-       August 1982.
-
-
-   There are no known security issues with the issues in this memo.
-
-9.  Author's Address
-
-   John G. Myers
-   Carnegie-Mellon University
-   5000 Forbes Ave.
-   Pittsburgh PA, 15213-3890
-
-   EMail: jgm+@cmu.edu
-
-
-
-
-
-
-
-
-
-
-
-Myers                        Informational                      [Page 7]
-
diff --git a/RFC/rfc2060.txt b/RFC/rfc2060.txt
deleted file mode 100644
index 591dec4d..00000000
--- a/RFC/rfc2060.txt
+++ /dev/null
@@ -1,4595 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        M. Crispin
-Request for Comments: 2060                     University of Washington
-Obsoletes: 1730                                           December 1996
-Category: Standards Track
-
-
-            INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1
-
-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
-
-   The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1)
-   allows a client to access and manipulate electronic mail messages on
-   a server.  IMAP4rev1 permits manipulation of remote message folders,
-   called "mailboxes", in a way that is functionally equivalent to local
-   mailboxes.  IMAP4rev1 also provides the capability for an offline
-   client to resynchronize with the server (see also [IMAP-DISC]).
-
-   IMAP4rev1 includes operations for creating, deleting, and renaming
-   mailboxes; checking for new messages; permanently removing messages;
-   setting and clearing flags; [RFC-822] and [MIME-IMB] parsing;
-   searching; and selective fetching of message attributes, texts, and
-   portions thereof.  Messages in IMAP4rev1 are accessed by the use of
-   numbers.  These numbers are either message sequence numbers or unique
-   identifiers.
-
-   IMAP4rev1 supports a single server.  A mechanism for accessing
-   configuration information to support multiple IMAP4rev1 servers is
-   discussed in [ACAP].
-
-   IMAP4rev1 does not specify a means of posting mail; this function is
-   handled by a mail transfer protocol such as [SMTP].
-
-   IMAP4rev1 is designed to be upwards compatible from the [IMAP2] and
-   unpublished IMAP2bis protocols.  In the course of the evolution of
-   IMAP4rev1, some aspects in the earlier protocol have become obsolete.
-   Obsolete commands, responses, and data formats which an IMAP4rev1
-   implementation may encounter when used with an earlier implementation
-   are described in [IMAP-OBSOLETE].
-
-
-
-
-
-Crispin                     Standards Track                     [Page 1]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-   Other compatibility issues with IMAP2bis, the most common variant of
-   the earlier protocol, are discussed in [IMAP-COMPAT].  A full
-   discussion of compatibility issues with rare (and presumed extinct)
-   variants of [IMAP2] is in [IMAP-HISTORICAL]; this document is
-   primarily of historical interest.
-
-Table of Contents
-
-IMAP4rev1 Protocol Specification ..................................    4
-1.      How to Read This Document .................................    4
-1.1.    Organization of This Document .............................    4
-1.2.    Conventions Used in This Document .........................    4
-2.      Protocol Overview .........................................    5
-2.1.    Link Level ................................................    5
-2.2.    Commands and Responses ....................................    6
-2.2.1.  Client Protocol Sender and Server Protocol Receiver .......    6
-2.2.2.  Server Protocol Sender and Client Protocol Receiver .......    7
-2.3.    Message Attributes ........................................    7
-2.3.1.  Message Numbers ...........................................    7
-2.3.1.1.        Unique Identifier (UID) Message Attribute .........    7
-2.3.1.2.        Message Sequence Number Message Attribute .........    9
-2.3.2.  Flags Message Attribute ....................................   9
-2.3.3.  Internal Date Message Attribute ...........................   10
-2.3.4.  [RFC-822] Size Message Attribute ..........................   11
-2.3.5.  Envelope Structure Message Attribute ......................   11
-2.3.6.  Body Structure Message Attribute ..........................   11
-2.4.    Message Texts .............................................   11
-3.      State and Flow Diagram ....................................   11
-3.1.    Non-Authenticated State ...................................   11
-3.2.    Authenticated State .......................................   11
-3.3.    Selected State ............................................   12
-3.4.    Logout State ..............................................   12
-4.      Data Formats ..............................................   12
-4.1.    Atom ......................................................   13
-4.2.    Number ....................................................   13
-4.3.    String .....................................................  13
-4.3.1.  8-bit and Binary Strings ..................................   13
-4.4.    Parenthesized List ........................................   14
-4.5.    NIL .......................................................   14
-5.      Operational Considerations ................................   14
-5.1.    Mailbox Naming ............................................   14
-5.1.1.  Mailbox Hierarchy Naming ..................................   14
-5.1.2.  Mailbox Namespace Naming Convention .......................   14
-5.1.3.  Mailbox International Naming Convention ...................   15
-5.2.    Mailbox Size and Message Status Updates ...................   16
-5.3.    Response when no Command in Progress ......................   16
-5.4.    Autologout Timer ..........................................   16
-5.5.    Multiple Commands in Progress .............................   17
-
-
-
-Crispin                     Standards Track                     [Page 2]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-6.      Client Commands ...........................................   17
-6.1.    Client Commands - Any State ...............................   18
-6.1.1.  CAPABILITY Command ........................................   18
-6.1.2.  NOOP Command ..............................................   19
-6.1.3.  LOGOUT Command ............................................   20
-6.2.    Client Commands - Non-Authenticated State .................   20
-6.2.1.  AUTHENTICATE Command ......................................   21
-6.2.2.  LOGIN Command .............................................   22
-6.3.    Client Commands - Authenticated State .....................   22
-6.3.1.  SELECT Command ............................................   23
-6.3.2.  EXAMINE Command ...........................................   24
-6.3.3.  CREATE Command ............................................   25
-6.3.4.  DELETE Command ............................................   26
-6.3.5.  RENAME Command ............................................   27
-6.3.6.  SUBSCRIBE Command .........................................   29
-6.3.7.  UNSUBSCRIBE Command .......................................   30
-6.3.8.  LIST Command ..............................................   30
-6.3.9.  LSUB Command ..............................................   32
-6.3.10. STATUS Command ............................................   33
-6.3.11. APPEND Command ............................................   34
-6.4.    Client Commands - Selected State ..........................   35
-6.4.1.  CHECK Command .............................................   36
-6.4.2.  CLOSE Command .............................................   36
-6.4.3.  EXPUNGE Command ...........................................   37
-6.4.4.  SEARCH Command ............................................   37
-6.4.5.  FETCH Command .............................................   41
-6.4.6.  STORE Command .............................................   45
-6.4.7.  COPY Command ..............................................   46
-6.4.8.  UID Command ...............................................   47
-6.5.    Client Commands - Experimental/Expansion ..................   48
-6.5.1.  X<atom> Command ...........................................   48
-7.      Server Responses ..........................................   48
-7.1.    Server Responses - Status Responses .......................   49
-7.1.1.  OK Response ...............................................   51
-7.1.2.  NO Response ...............................................   51
-7.1.3.  BAD Response ..............................................   52
-7.1.4.  PREAUTH Response ..........................................   52
-7.1.5.  BYE Response ..............................................   52
-7.2.    Server Responses - Server and Mailbox Status ..............   53
-7.2.1.  CAPABILITY Response .......................................   53
-7.2.2.  LIST Response ..............................................  54
-7.2.3.  LSUB Response .............................................   55
-7.2.4   STATUS Response ...........................................   55
-7.2.5.  SEARCH Response ...........................................   55
-7.2.6.  FLAGS Response ............................................   56
-7.3.    Server Responses - Mailbox Size ...........................   56
-7.3.1.  EXISTS Response ...........................................   56
-7.3.2.  RECENT Response ...........................................   57
-
-
-
-Crispin                     Standards Track                     [Page 3]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-7.4.    Server Responses - Message Status .........................   57
-7.4.1.  EXPUNGE Response ..........................................   57
-7.4.2.  FETCH Response ............................................   58
-7.5.    Server Responses - Command Continuation Request ...........   63
-8.      Sample IMAP4rev1 connection ...............................   63
-9.      Formal Syntax .............................................   64
-10.     Author's Note .............................................   74
-11.     Security Considerations ...................................   74
-12.     Author's Address ..........................................   75
-Appendices ........................................................   76
-A.      References ................................................   76
-B.      Changes from RFC 1730 .....................................   77
-C.      Key Word Index ............................................   79
-
-
-IMAP4rev1 Protocol Specification
-
-1.      How to Read This Document
-
-1.1.    Organization of This Document
-
-   This document is written from the point of view of the implementor of
-   an IMAP4rev1 client or server.  Beyond the protocol overview in
-   section 2, it is not optimized for someone trying to understand the
-   operation of the protocol.  The material in sections 3 through 5
-   provides the general context and definitions with which IMAP4rev1
-   operates.
-
-   Sections 6, 7, and 9 describe the IMAP commands, responses, and
-   syntax, respectively.  The relationships among these are such that it
-   is almost impossible to understand any of them separately.  In
-   particular, do not attempt to deduce command syntax from the command
-   section alone; instead refer to the Formal Syntax section.
-
-1.2.    Conventions Used in This Document
-
-   In examples, "C:" and "S:" indicate lines sent by the client and
-   server respectively.
-
-   The following terms are used in this document to signify the
-   requirements of this specification.
-
-   1) MUST, or the adjective REQUIRED, means that the definition is
-      an absolute requirement of the specification.
-
-   2) MUST NOT that the definition is an absolute prohibition of the
-      specification.
-
-
-
-
-Crispin                     Standards Track                     [Page 4]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-   3) SHOULD means that there may exist valid reasons in particular
-      circumstances to ignore a particular item, but the full
-      implications MUST be understood and carefully weighed before
-      choosing a different course.
-
-   4) SHOULD NOT means that there may exist valid reasons in
-      particular circumstances when the particular behavior is
-      acceptable or even useful, but the full implications SHOULD be
-      understood and the case carefully weighed before implementing
-      any behavior described with this label.
-
-   5) MAY, or the adjective OPTIONAL, means that an item is truly
-      optional.  One vendor may choose to include the item because a
-      particular marketplace requires it or because the vendor feels
-      that it enhances the product while another vendor may omit the
-      same item.  An implementation which does not include a
-      particular option MUST be prepared to interoperate with another
-      implementation which does include the option.
-
-      "Can" is used instead of "may" when referring to a possible
-      circumstance or situation, as opposed to an optional facility of
-      the protocol.
-
-      "User" is used to refer to a human user, whereas "client" refers
-      to the software being run by the user.
-
-      "Connection" refers to the entire sequence of client/server
-      interaction from the initial establishment of the network
-      connection until its termination.  "Session" refers to the
-      sequence of client/server interaction from the time that a mailbox
-      is selected (SELECT or EXAMINE command) until the time that
-      selection ends (SELECT or EXAMINE of another mailbox, CLOSE
-      command, or connection termination).
-
-       Characters are 7-bit US-ASCII unless otherwise specified.  Other
-       character sets are indicated using a "CHARSET", as described in
-       [MIME-IMT] and defined in [CHARSET].  CHARSETs have important
-       additional semantics in addition to defining character set; refer
-       to these documents for more detail.
-
-2.      Protocol Overview
-
-2.1.    Link Level
-
-   The IMAP4rev1 protocol assumes a reliable data stream such as
-   provided by TCP.  When TCP is used, an IMAP4rev1 server listens on
-   port 143.
-
-
-
-
-Crispin                     Standards Track                     [Page 5]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-2.2.    Commands and Responses
-
-   An IMAP4rev1 connection consists of the establishment of a
-   client/server network connection, an initial greeting from the
-   server, and client/server interactions.  These client/server
-   interactions consist of a client command, server data, and a server
-   completion result response.
-
-   All interactions transmitted by client and server are in the form of
-   lines; that is, strings that end with a CRLF.  The protocol receiver
-   of an IMAP4rev1 client or server is either reading a line, or is
-   reading a sequence of octets with a known count followed by a line.
-
-2.2.1.  Client Protocol Sender and Server Protocol Receiver
-
-   The client command begins an operation.  Each client command is
-   prefixed with an identifier (typically a short alphanumeric string,
-   e.g. A0001, A0002, etc.) called a "tag".  A different tag is
-   generated by the client for each command.
-
-   There are two cases in which a line from the client does not
-   represent a complete command.  In one case, a command argument is
-   quoted with an octet count (see the description of literal in String
-   under Data Formats); in the other case, the command arguments require
-   server feedback (see the AUTHENTICATE command).  In either case, the
-   server sends a command continuation request response if it is ready
-   for the octets (if appropriate) and the remainder of the command.
-   This response is prefixed with the token "+".
-
-      Note: If, instead, the server detected an error in the command, it
-      sends a BAD completion response with tag matching the command (as
-      described below) to reject the command and prevent the client from
-      sending any more of the command.
-
-      It is also possible for the server to send a completion response
-      for some other command (if multiple commands are in progress), or
-      untagged data.  In either case, the command continuation request
-      is still pending; the client takes the appropriate action for the
-      response, and reads another response from the server.  In all
-      cases, the client MUST send a complete command (including
-      receiving all command continuation request responses and command
-      continuations for the command) before initiating a new command.
-
-   The protocol receiver of an IMAP4rev1 server reads a command line
-   from the client, parses the command and its arguments, and transmits
-   server data and a server command completion result response.
-
-
-
-
-
-Crispin                     Standards Track                     [Page 6]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-2.2.2.  Server Protocol Sender and Client Protocol Receiver
-
-   Data transmitted by the server to the client and status responses
-   that do not indicate command completion are prefixed with the token
-   "*", and are called untagged responses.
-
-   Server data MAY be sent as a result of a client command, or MAY be
-   sent unilaterally by the server.  There is no syntactic difference
-   between server data that resulted from a specific command and server
-   data that were sent unilaterally.
-
-   The server completion result response indicates the success or
-   failure of the operation.  It is tagged with the same tag as the
-   client command which began the operation.  Thus, if more than one
-   command is in progress, the tag in a server completion response
-   identifies the command to which the response applies.  There are
-   three possible server completion responses: OK (indicating success),
-   NO (indicating failure), or BAD (indicating protocol error such as
-   unrecognized command or command syntax error).
-
-   The protocol receiver of an IMAP4rev1 client reads a response line
-   from the server.  It then takes action on the response based upon the
-   first token of the response, which can be a tag, a "*", or a "+".
-
-   A client MUST be prepared to accept any server response at all times.
-   This includes server data that was not requested.  Server data SHOULD
-   be recorded, so that the client can reference its recorded copy
-   rather than sending a command to the server to request the data.  In
-   the case of certain server data, the data MUST be recorded.
-
-   This topic is discussed in greater detail in the Server Responses
-   section.
-
-2.3.    Message Attributes
-
-   In addition to message text, each message has several attributes
-   associated with it.  These attributes may be retrieved individually
-   or in conjunction with other attributes or message texts.
-
-2.3.1.  Message Numbers
-
-   Messages in IMAP4rev1 are accessed by one of two numbers; the unique
-   identifier and the message sequence number.
-
-2.3.1.1.        Unique Identifier (UID) Message Attribute
-
-   A 32-bit value assigned to each message, which when used with the
-   unique identifier validity value (see below) forms a 64-bit value
-
-
-
-Crispin                     Standards Track                     [Page 7]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-   that is permanently guaranteed not to refer to any other message in
-   the mailbox.  Unique identifiers are assigned in a strictly ascending
-   fashion in the mailbox; as each message is added to the mailbox it is
-   assigned a higher UID than the message(s) which were added
-   previously.
-
-   Unlike message sequence numbers, unique identifiers are not
-   necessarily contiguous.  Unique identifiers also persist across
-   sessions.  This permits a client to resynchronize its state from a
-   previous session with the server (e.g. disconnected or offline access
-   clients); this is discussed further in [IMAP-DISC].
-
-   Associated with every mailbox is a unique identifier validity value,
-   which is sent in an UIDVALIDITY response code in an OK untagged
-   response at mailbox selection time.  If unique identifiers from an
-   earlier session fail to persist to this session, the unique
-   identifier validity value MUST be greater than the one used in the
-   earlier session.
-
-      Note: Unique identifiers MUST be strictly ascending in the mailbox
-      at all times.  If the physical message store is re-ordered by a
-      non-IMAP agent, this requires that the unique identifiers in the
-      mailbox be regenerated, since the former unique identifers are no
-      longer strictly ascending as a result of the re-ordering.  Another
-      instance in which unique identifiers are regenerated is if the
-      message store has no mechanism to store unique identifiers.
-      Although this specification recognizes that this may be
-      unavoidable in certain server environments, it STRONGLY ENCOURAGES
-      message store implementation techniques that avoid this problem.
-
-      Another cause of non-persistance is if the mailbox is deleted and
-      a new mailbox with the same name is created at a later date, Since
-      the name is the same, a client may not know that this is a new
-      mailbox unless the unique identifier validity is different.  A
-      good value to use for the unique identifier validity value is a
-      32-bit representation of the creation date/time of the mailbox.
-      It is alright to use a constant such as 1, but only if it
-      guaranteed that unique identifiers will never be reused, even in
-      the case of a mailbox being deleted (or renamed) and a new mailbox
-      by the same name created at some future time.
-
-   The unique identifier of a message MUST NOT change during the
-   session, and SHOULD NOT change between sessions.  However, if it is
-   not possible to preserve the unique identifier of a message in a
-   subsequent session, each subsequent session MUST have a new unique
-   identifier validity value that is larger than any that was used
-   previously.
-
-
-
-
-Crispin                     Standards Track                     [Page 8]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-2.3.1.2.        Message Sequence Number Message Attribute
-
-   A relative position from 1 to the number of messages in the mailbox.
-   This position MUST be ordered by ascending unique identifier.  As
-   each new message is added, it is assigned a message sequence number
-   that is 1 higher than the number of messages in the mailbox before
-   that new message was added.
-
-   Message sequence numbers can be reassigned during the session.  For
-   example, when a message is permanently removed (expunged) from the
-   mailbox, the message sequence number for all subsequent messages is
-   decremented.  Similarly, a new message can be assigned a message
-   sequence number that was once held by some other message prior to an
-   expunge.
-
-   In addition to accessing messages by relative position in the
-   mailbox, message sequence numbers can be used in mathematical
-   calculations.  For example, if an untagged "EXISTS 11" is received,
-   and previously an untagged "8 EXISTS" was received, three new
-   messages have arrived with message sequence numbers of 9, 10, and 11.
-   Another example; if message 287 in a 523 message mailbox has UID
-   12345, there are exactly 286 messages which have lesser UIDs and 236
-   messages which have greater UIDs.
-
-2.3.2.  Flags Message Attribute
-
-   A list of zero or more named tokens associated with the message.  A
-   flag is set by its addition to this list, and is cleared by its
-   removal.  There are two types of flags in IMAP4rev1.  A flag of
-   either type may be permanent or session-only.
-
-   A system flag is a flag name that is pre-defined in this
-   specification.  All system flags begin with "\".  Certain system
-   flags (\Deleted and \Seen) have special semantics described
-   elsewhere.  The currently-defined system flags are:
-
-        \Seen       Message has been read
-
-        \Answered   Message has been answered
-
-        \Flagged    Message is "flagged" for urgent/special attention
-
-        \Deleted    Message is "deleted" for removal by later EXPUNGE
-
-        \Draft      Message has not completed composition (marked as a
-                    draft).
-
-
-
-
-
-Crispin                     Standards Track                     [Page 9]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-        \Recent     Message is "recently" arrived in this mailbox.  This
-                    session is the first session to have been notified
-                    about this message; subsequent sessions will not see
-                    \Recent set for this message.  This flag can not be
-                    altered by the client.
-
-                    If it is not possible to determine whether or not
-                    this session is the first session to be notified
-                    about a message, then that message SHOULD be
-                    considered recent.
-
-                    If multiple connections have the same mailbox
-                    selected simultaneously, it is undefined which of
-                    these connections will see newly-arrives messages
-                    with \Recent set and which will see it without
-                    \Recent set.
-
-      A keyword is defined by the server implementation.  Keywords do
-      not begin with "\".  Servers MAY permit the client to define new
-      keywords in the mailbox (see the description of the
-      PERMANENTFLAGS response code for more information).
-
-      A flag may be permanent or session-only on a per-flag basis.
-      Permanent flags are those which the client can add or remove
-      from the message flags permanently; that is, subsequent sessions
-      will see any change in permanent flags.  Changes to session
-      flags are valid only in that session.
-
-      Note: The \Recent system flag is a special case of a
-      session flag.  \Recent can not be used as an argument in a
-      STORE command, and thus can not be changed at all.
-
-2.3.3.  Internal Date Message Attribute
-
-   The internal date and time of the message on the server.  This is not
-   the date and time in the [RFC-822] header, but rather a date and time
-   which reflects when the message was received.  In the case of
-   messages delivered via [SMTP], this SHOULD be the date and time of
-   final delivery of the message as defined by [SMTP].  In the case of
-   messages delivered by the IMAP4rev1 COPY command, this SHOULD be the
-   internal date and time of the source message.  In the case of
-   messages delivered by the IMAP4rev1 APPEND command, this SHOULD be
-   the date and time as specified in the APPEND command description.
-   All other cases are implementation defined.
-
-
-
-
-
-
-
-Crispin                     Standards Track                    [Page 10]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-2.3.4.  [RFC-822] Size Message Attribute
-
-   The number of octets in the message, as expressed in [RFC-822]
-   format.
-
-2.3.5.  Envelope Structure Message Attribute
-
-   A parsed representation of the [RFC-822] envelope information (not to
-   be confused with an [SMTP] envelope) of the message.
-
-2.3.6.  Body Structure Message Attribute
-
-   A parsed representation of the [MIME-IMB] body structure information
-   of the message.
-
-2.4.    Message Texts
-
-   In addition to being able to fetch the full [RFC-822] text of a
-   message, IMAP4rev1 permits the fetching of portions of the full
-   message text.  Specifically, it is possible to fetch the [RFC-822]
-   message header, [RFC-822] message body, a [MIME-IMB] body part, or a
-   [MIME-IMB] header.
-
-3.      State and Flow Diagram
-
-   An IMAP4rev1 server is in one of four states.  Most commands are
-   valid in only certain states.  It is a protocol error for the client
-   to attempt a command while the command is in an inappropriate state.
-   In this case, a server will respond with a BAD or NO (depending upon
-   server implementation) command completion result.
-
-3.1.    Non-Authenticated State
-
-   In non-authenticated state, the client MUST supply authentication
-   credentials before most commands will be permitted.  This state is
-   entered when a connection starts unless the connection has been pre-
-   authenticated.
-
-3.2.    Authenticated State
-
-   In authenticated state, the client is authenticated and MUST select a
-   mailbox to access before commands that affect messages will be
-   permitted.  This state is entered when a pre-authenticated connection
-   starts, when acceptable authentication credentials have been
-   provided, or after an error in selecting a mailbox.
-
-
-
-
-
-
-Crispin                     Standards Track                    [Page 11]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-3.3.    Selected State
-
-   In selected state, a mailbox has been selected to access.  This state
-   is entered when a mailbox has been successfully selected.
-
-3.4.    Logout State
-
-   In logout state, the connection is being terminated, and the server
-   will close the connection.  This state can be entered as a result of
-   a client request or by unilateral server decision.
-
-            +--------------------------------------+
-            |initial connection and server greeting|
-            +--------------------------------------+
-                      || (1)       || (2)        || (3)
-                      VV           ||            ||
-            +-----------------+    ||            ||
-            |non-authenticated|    ||            ||
-            +-----------------+    ||            ||
-             || (7)   || (4)       ||            ||
-             ||       VV           VV            ||
-             ||     +----------------+           ||
-             ||     | authenticated  |<=++       ||
-             ||     +----------------+  ||       ||
-             ||       || (7)   || (5)   || (6)   ||
-             ||       ||       VV       ||       ||
-             ||       ||    +--------+  ||       ||
-             ||       ||    |selected|==++       ||
-             ||       ||    +--------+           ||
-             ||       ||       || (7)            ||
-             VV       VV       VV                VV
-            +--------------------------------------+
-            |     logout and close connection      |
-            +--------------------------------------+
-
-         (1) connection without pre-authentication (OK greeting)
-         (2) pre-authenticated connection (PREAUTH greeting)
-         (3) rejected connection (BYE greeting)
-         (4) successful LOGIN or AUTHENTICATE command
-         (5) successful SELECT or EXAMINE command
-         (6) CLOSE command, or failed SELECT or EXAMINE command
-         (7) LOGOUT command, server shutdown, or connection closed
-
-4.      Data Formats
-
-   IMAP4rev1 uses textual commands and responses.  Data in IMAP4rev1 can
-   be in one of several forms: atom, number, string, parenthesized list,
-   or NIL.
-
-
-
-Crispin                     Standards Track                    [Page 12]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-4.1.    Atom
-
-   An atom consists of one or more non-special characters.
-
-4.2.    Number
-
-   A number consists of one or more digit characters, and represents a
-   numeric value.
-
-4.3.    String
-
-   A string is in one of two forms: literal and quoted string.  The
-   literal form is the general form of string.  The quoted string form
-   is an alternative that avoids the overhead of processing a literal at
-   the cost of limitations of characters that can be used in a quoted
-   string.
-
-   A literal is a sequence of zero or more octets (including CR and LF),
-   prefix-quoted with an octet count in the form of an open brace ("{"),
-   the number of octets, close brace ("}"), and CRLF.  In the case of
-   literals transmitted from server to client, the CRLF is immediately
-   followed by the octet data.  In the case of literals transmitted from
-   client to server, the client MUST wait to receive a command
-   continuation request (described later in this document) before
-   sending the octet data (and the remainder of the command).
-
-   A quoted string is a sequence of zero or more 7-bit characters,
-   excluding CR and LF, with double quote (<">) characters at each end.
-
-   The empty string is represented as either "" (a quoted string with
-   zero characters between double quotes) or as {0} followed by CRLF (a
-   literal with an octet count of 0).
-
-      Note: Even if the octet count is 0, a client transmitting a
-      literal MUST wait to receive a command continuation request.
-
-4.3.1.  8-bit and Binary Strings
-
-   8-bit textual and binary mail is supported through the use of a
-   [MIME-IMB] content transfer encoding.  IMAP4rev1 implementations MAY
-   transmit 8-bit or multi-octet characters in literals, but SHOULD do
-   so only when the [CHARSET] is identified.
-
-
-
-
-
-
-
-
-
-Crispin                     Standards Track                    [Page 13]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-   Although a BINARY body encoding is defined, unencoded binary strings
-   are not permitted.  A "binary string" is any string with NUL
-   characters.  Implementations MUST encode binary data into a textual
-   form such as BASE64 before transmitting the data.  A string with an
-   excessive amount of CTL characters MAY also be considered to be
-   binary.
-
-4.4.    Parenthesized List
-
-   Data structures are represented as a "parenthesized list"; a sequence
-   of data items, delimited by space, and bounded at each end by
-   parentheses.  A parenthesized list can contain other parenthesized
-   lists, using multiple levels of parentheses to indicate nesting.
-
-   The empty list is represented as () -- a parenthesized list with no
-   members.
-
-4.5.    NIL
-
-   The special atom "NIL" represents the non-existence of a particular
-   data item that is represented as a string or parenthesized list, as
-   distinct from the empty string "" or the empty parenthesized list ().
-
-5.      Operational Considerations
-
-5.1.    Mailbox Naming
-
-   The interpretation of mailbox names is implementation-dependent.
-   However, the case-insensitive mailbox name INBOX is a special name
-   reserved to mean "the primary mailbox for this user on this server".
-
-5.1.1.  Mailbox Hierarchy Naming
-
-   If it is desired to export hierarchical mailbox names, mailbox names
-   MUST be left-to-right hierarchical using a single character to
-   separate levels of hierarchy.  The same hierarchy separator character
-   is used for all levels of hierarchy within a single name.
-
-5.1.2.  Mailbox Namespace Naming Convention
-
-   By convention, the first hierarchical element of any mailbox name
-   which begins with "#" identifies the "namespace" of the remainder of
-   the name.  This makes it possible to disambiguate between different
-   types of mailbox stores, each of which have their own namespaces.
-
-
-
-
-
-
-
-Crispin                     Standards Track                    [Page 14]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-      For example, implementations which offer access to USENET
-      newsgroups MAY use the "#news" namespace to partition the USENET
-      newsgroup namespace from that of other mailboxes.  Thus, the
-      comp.mail.misc newsgroup would have an mailbox name of
-      "#news.comp.mail.misc", and the name "comp.mail.misc" could refer
-      to a different object (e.g. a user's private mailbox).
-
-5.1.3.  Mailbox International Naming Convention
-
-   By convention, international mailbox names are specified using a
-   modified version of the UTF-7 encoding described in [UTF-7].  The
-   purpose of these modifications is to correct the following problems
-   with UTF-7:
-
-      1) UTF-7 uses the "+" character for shifting; this conflicts with
-         the common use of "+" in mailbox names, in particular USENET
-         newsgroup names.
-
-      2) UTF-7's encoding is BASE64 which uses the "/" character; this
-         conflicts with the use of "/" as a popular hierarchy delimiter.
-
-      3) UTF-7 prohibits the unencoded usage of "\"; this conflicts with
-         the use of "\" as a popular hierarchy delimiter.
-
-      4) UTF-7 prohibits the unencoded usage of "~"; this conflicts with
-         the use of "~" in some servers as a home directory indicator.
-
-      5) UTF-7 permits multiple alternate forms to represent the same
-         string; in particular, printable US-ASCII chararacters can be
-         represented in encoded form.
-
-   In modified UTF-7, printable US-ASCII characters except for "&"
-   represent themselves; that is, characters with octet values 0x20-0x25
-   and 0x27-0x7e.  The character "&" (0x26) is represented by the two-
-   octet sequence "&-".
-
-   All other characters (octet values 0x00-0x1f, 0x7f-0xff, and all
-   Unicode 16-bit octets) are represented in modified BASE64, with a
-   further modification from [UTF-7] that "," is used instead of "/".
-   Modified BASE64 MUST NOT be used to represent any printing US-ASCII
-   character which can represent itself.
-
-   "&" is used to shift to modified BASE64 and "-" to shift back to US-
-   ASCII.  All names start in US-ASCII, and MUST end in US-ASCII (that
-   is, a name that ends with a Unicode 16-bit octet MUST end with a "-
-   ").
-
-
-
-
-
-Crispin                     Standards Track                    [Page 15]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-      For example, here is a mailbox name which mixes English, Japanese,
-      and Chinese text: ~peter/mail/&ZeVnLIqe-/&U,BTFw-
-
-5.2.    Mailbox Size and Message Status Updates
-
-   At any time, a server can send data that the client did not request.
-   Sometimes, such behavior is REQUIRED.  For example, agents other than
-   the server MAY add messages to the mailbox (e.g. new mail delivery),
-   change the flags of message in the mailbox (e.g. simultaneous access
-   to the same mailbox by multiple agents), or even remove messages from
-   the mailbox.  A server MUST send mailbox size updates automatically
-   if a mailbox size change is observed during the processing of a
-   command.  A server SHOULD send message flag updates automatically,
-   without requiring the client to request such updates explicitly.
-   Special rules exist for server notification of a client about the
-   removal of messages to prevent synchronization errors; see the
-   description of the EXPUNGE response for more detail.
-
-   Regardless of what implementation decisions a client makes on
-   remembering data from the server, a client implementation MUST record
-   mailbox size updates.  It MUST NOT assume that any command after
-   initial mailbox selection will return the size of the mailbox.
-
-5.3.    Response when no Command in Progress
-
-   Server implementations are permitted to send an untagged response
-   (except for EXPUNGE) while there is no command in progress.  Server
-   implementations that send such responses MUST deal with flow control
-   considerations.  Specifically, they MUST either (1) verify that the
-   size of the data does not exceed the underlying transport's available
-   window size, or (2) use non-blocking writes.
-
-5.4.    Autologout Timer
-
-   If a server has an inactivity autologout timer, that timer MUST be of
-   at least 30 minutes' duration.  The receipt of ANY command from the
-   client during that interval SHOULD suffice to reset the autologout
-   timer.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin                     Standards Track                    [Page 16]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-5.5.    Multiple Commands in Progress
-
-   The client MAY send another command without waiting for the
-   completion result response of a command, subject to ambiguity rules
-   (see below) and flow control constraints on the underlying data
-   stream.  Similarly, a server MAY begin processing another command
-   before processing the current command to completion, subject to
-   ambiguity rules.  However, any command continuation request responses
-   and command continuations MUST be negotiated before any subsequent
-   command is initiated.
-
-   The exception is if an ambiguity would result because of a command
-   that would affect the results of other commands.  Clients MUST NOT
-   send multiple commands without waiting if an ambiguity would result.
-   If the server detects a possible ambiguity, it MUST execute commands
-   to completion in the order given by the client.
-
-   The most obvious example of ambiguity is when a command would affect
-   the results of another command; for example, a FETCH of a message's
-   flags and a STORE of that same message's flags.
-
-   A non-obvious ambiguity occurs with commands that permit an untagged
-   EXPUNGE response (commands other than FETCH, STORE, and SEARCH),
-   since an untagged EXPUNGE response can invalidate sequence numbers in
-   a subsequent command.  This is not a problem for FETCH, STORE, or
-   SEARCH commands because servers are prohibited from sending EXPUNGE
-   responses while any of those commands are in progress.  Therefore, if
-   the client sends any command other than FETCH, STORE, or SEARCH, it
-   MUST wait for a response before sending a command with message
-   sequence numbers.
-
-   For example, the following non-waiting command sequences are invalid:
-
-      FETCH + NOOP + STORE
-      STORE + COPY + FETCH
-      COPY + COPY
-      CHECK + FETCH
-
-   The following are examples of valid non-waiting command sequences:
-
-      FETCH + STORE + SEARCH + CHECK
-      STORE + COPY + EXPUNGE
-
-6.      Client Commands
-
-   IMAP4rev1 commands are described in this section.  Commands are
-   organized by the state in which the command is permitted.  Commands
-   which are permitted in multiple states are listed in the minimum
-
-
-
-Crispin                     Standards Track                    [Page 17]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-   permitted state (for example, commands valid in authenticated and
-   selected state are listed in the authenticated state commands).
-
-   Command arguments, identified by "Arguments:" in the command
-   descriptions below, are described by function, not by syntax.  The
-   precise syntax of command arguments is described in the Formal Syntax
-   section.
-
-   Some commands cause specific server responses to be returned; these
-   are identified by "Responses:" in the command descriptions below.
-   See the response descriptions in the Responses section for
-   information on these responses, and the Formal Syntax section for the
-   precise syntax of these responses.  It is possible for server data to
-   be transmitted as a result of any command; thus, commands that do not
-   specifically require server data specify "no specific responses for
-   this command" instead of "none".
-
-   The "Result:" in the command description refers to the possible
-   tagged status responses to a command, and any special interpretation
-   of these status responses.
-
-6.1.    Client Commands - Any State
-
-   The following commands are valid in any state: CAPABILITY, NOOP, and
-   LOGOUT.
-
-6.1.1.  CAPABILITY Command
-
-   Arguments:  none
-
-   Responses:  REQUIRED untagged response: CAPABILITY
-
-   Result:     OK - capability completed
-               BAD - command unknown or arguments invalid
-
-      The CAPABILITY command requests a listing of capabilities that the
-      server supports.  The server MUST send a single untagged
-      CAPABILITY response with "IMAP4rev1" as one of the listed
-      capabilities before the (tagged) OK response.  This listing of
-      capabilities is not dependent upon connection state or user.  It
-      is therefore not necessary to issue a CAPABILITY command more than
-      once in a connection.
-
-
-
-
-
-
-
-
-
-Crispin                     Standards Track                    [Page 18]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-      A capability name which begins with "AUTH=" indicates that the
-      server supports that particular authentication mechanism.  All
-      such names are, by definition, part of this specification.  For
-      example, the authorization capability for an experimental
-      "blurdybloop" authenticator would be "AUTH=XBLURDYBLOOP" and not
-      "XAUTH=BLURDYBLOOP" or "XAUTH=XBLURDYBLOOP".
-
-      Other capability names refer to extensions, revisions, or
-      amendments to this specification.  See the documentation of the
-      CAPABILITY response for additional information.  No capabilities,
-      beyond the base IMAP4rev1 set defined in this specification, are
-      enabled without explicit client action to invoke the capability.
-
-      See the section entitled "Client Commands -
-      Experimental/Expansion" for information about the form of site or
-      implementation-specific capabilities.
-
-   Example:    C: abcd CAPABILITY
-               S: * CAPABILITY IMAP4rev1 AUTH=KERBEROS_V4
-               S: abcd OK CAPABILITY completed
-
-6.1.2.  NOOP Command
-
-   Arguments:  none
-
-   Responses:  no specific responses for this command (but see below)
-
-   Result:     OK - noop completed
-               BAD - command unknown or arguments invalid
-
-      The NOOP command always succeeds.  It does nothing.
-
-      Since any command can return a status update as untagged data, the
-      NOOP command can be used as a periodic poll for new messages or
-      message status updates during a period of inactivity.  The NOOP
-      command can also be used to reset any inactivity autologout timer
-      on the server.
-
-   Example:    C: a002 NOOP
-               S: a002 OK NOOP completed
-                  . . .
-               C: a047 NOOP
-               S: * 22 EXPUNGE
-               S: * 23 EXISTS
-               S: * 3 RECENT
-               S: * 14 FETCH (FLAGS (\Seen \Deleted))
-               S: a047 OK NOOP completed
-
-
-
-
-Crispin                     Standards Track                    [Page 19]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-6.1.3.  LOGOUT Command
-
-   Arguments:  none
-
-   Responses:  REQUIRED untagged response: BYE
-
-   Result:     OK - logout completed
-               BAD - command unknown or arguments invalid
-
-      The LOGOUT command informs the server that the client is done with
-      the connection.  The server MUST send a BYE untagged response
-      before the (tagged) OK response, and then close the network
-      connection.
-
-   Example:    C: A023 LOGOUT
-               S: * BYE IMAP4rev1 Server logging out
-               S: A023 OK LOGOUT completed
-               (Server and client then close the connection)
-
-6.2.    Client Commands - Non-Authenticated State
-
-   In non-authenticated state, the AUTHENTICATE or LOGIN command
-   establishes authentication and enter authenticated state.  The
-   AUTHENTICATE command provides a general mechanism for a variety of
-   authentication techniques, whereas the LOGIN command uses the
-   traditional user name and plaintext password pair.
-
-   Server implementations MAY allow non-authenticated access to certain
-   mailboxes.  The convention is to use a LOGIN command with the userid
-   "anonymous".  A password is REQUIRED.  It is implementation-dependent
-   what requirements, if any, are placed on the password and what access
-   restrictions are placed on anonymous users.
-
-   Once authenticated (including as anonymous), it is not possible to
-   re-enter non-authenticated state.
-
-   In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
-   the following commands are valid in non-authenticated state:
-   AUTHENTICATE and LOGIN.
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin                     Standards Track                    [Page 20]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-6.2.1.  AUTHENTICATE Command
-
-   Arguments:  authentication mechanism name
-
-   Responses:  continuation data can be requested
-
-   Result:     OK - authenticate completed, now in authenticated state
-               NO - authenticate failure: unsupported authentication
-                    mechanism, credentials rejected
-              BAD - command unknown or arguments invalid,
-                    authentication exchange cancelled
-
-      The AUTHENTICATE command indicates an authentication mechanism,
-      such as described in [IMAP-AUTH], to the server.  If the server
-      supports the requested authentication mechanism, it performs an
-      authentication protocol exchange to authenticate and identify the
-      client.  It MAY also negotiate an OPTIONAL protection mechanism
-      for subsequent protocol interactions.  If the requested
-      authentication mechanism is not supported, the server SHOULD
-      reject the AUTHENTICATE command by sending a tagged NO response.
-
-      The authentication protocol exchange consists of a series of
-      server challenges and client answers that are specific to the
-      authentication mechanism.  A server challenge consists of a
-      command continuation request response with the "+" token followed
-      by a BASE64 encoded string.  The client answer consists of a line
-      consisting of 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
-      AUTHENTICATE command by sending a tagged BAD response.
-
-      A protection mechanism provides integrity and privacy protection
-      to the connection.  If a protection mechanism is negotiated, it is
-      applied to all subsequent data sent over the connection.  The
-      protection mechanism takes effect immediately following the CRLF
-      that concludes the authentication exchange for the client, and the
-      CRLF of the tagged OK response for the server.  Once the
-      protection mechanism is in effect, the stream of command and
-      response octets is processed into buffers of ciphertext.  Each
-      buffer is transferred over the connection as a stream of octets
-      prepended with a four octet field in network byte order that
-      represents the length of the following data.  The maximum
-      ciphertext buffer length is defined by the protection mechanism.
-
-      Authentication mechanisms are OPTIONAL.  Protection mechanisms are
-      also OPTIONAL; an authentication mechanism MAY be implemented
-      without any protection mechanism.  If an AUTHENTICATE command
-      fails with a NO response, the client MAY try another
-
-
-
-Crispin                     Standards Track                    [Page 21]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-      authentication mechanism by issuing another AUTHENTICATE command,
-      or MAY attempt to authenticate by using the LOGIN command.  In
-      other words, the client MAY request authentication types in
-      decreasing order of preference, with the LOGIN command as a last
-      resort.
-
-   Example:    S: * OK KerberosV4 IMAP4rev1 Server
-               C: A001 AUTHENTICATE KERBEROS_V4
-               S: + AmFYig==
-               C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
-                  +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd
-                  WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
-               S: + or//EoAADZI=
-               C: DiAF5A4gA+oOIALuBkAAmw==
-               S: A001 OK Kerberos V4 authentication successful
-
-      Note: the line breaks in the first client answer are for editorial
-      clarity and are not in real authenticators.
-
-6.2.2.  LOGIN Command
-
-   Arguments:  user name
-               password
-
-   Responses:  no specific responses for this command
-
-   Result:     OK - login completed, now in authenticated state
-               NO - login failure: user name or password rejected
-               BAD - command unknown or arguments invalid
-
-      The LOGIN command identifies the client to the server and carries
-      the plaintext password authenticating this user.
-
-   Example:    C: a001 LOGIN SMITH SESAME
-               S: a001 OK LOGIN completed
-
-6.3.    Client Commands - Authenticated State
-
-   In authenticated state, commands that manipulate mailboxes as atomic
-   entities are permitted.  Of these commands, the SELECT and EXAMINE
-   commands will select a mailbox for access and enter selected state.
-
-   In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
-   the following commands are valid in authenticated state: SELECT,
-   EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB,
-   STATUS, and APPEND.
-
-
-
-
-
-Crispin                     Standards Track                    [Page 22]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-6.3.1.  SELECT Command
-
-   Arguments:  mailbox name
-
-   Responses:  REQUIRED untagged responses: FLAGS, EXISTS, RECENT
-               OPTIONAL OK untagged responses: UNSEEN, PERMANENTFLAGS
-
-   Result:     OK - select completed, now in selected state
-               NO - select failure, now in authenticated state: no
-                    such mailbox, can't access mailbox
-               BAD - command unknown or arguments invalid
-
-   The SELECT command selects a mailbox so that messages in the
-   mailbox can be accessed.  Before returning an OK to the client,
-   the server MUST send the following untagged data to the client:
-
-      FLAGS       Defined flags in the mailbox.  See the description
-                  of the FLAGS response for more detail.
-
-      <n> EXISTS  The number of messages in the mailbox.  See the
-                  description of the EXISTS response for more detail.
-
-      <n> RECENT  The number of messages with the \Recent flag set.
-                  See the description of the RECENT response for more
-                  detail.
-
-      OK [UIDVALIDITY <n>]
-                  The unique identifier validity value.  See the
-                  description of the UID command for more detail.
-
-   to define the initial state of the mailbox at the client.
-
-   The server SHOULD also send an UNSEEN response code in an OK
-   untagged response, indicating the message sequence number of the
-   first unseen message in the mailbox.
-
-   If the client can not change the permanent state of one or more of
-   the flags listed in the FLAGS untagged response, the server SHOULD
-   send a PERMANENTFLAGS response code in an OK untagged response,
-   listing the flags that the client can change permanently.
-
-   Only one mailbox can be selected at a time in a connection;
-   simultaneous access to multiple mailboxes requires multiple
-   connections.  The SELECT command automatically deselects any
-   currently selected mailbox before attempting the new selection.
-   Consequently, if a mailbox is selected and a SELECT command that
-   fails is attempted, no mailbox is selected.
-
-
-
-
-Crispin                     Standards Track                    [Page 23]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-   If the client is permitted to modify the mailbox, the server
-   SHOULD prefix the text of the tagged OK response with the
-         "[READ-WRITE]" response code.
-
-      If the client is not permitted to modify the mailbox but is
-      permitted read access, the mailbox is selected as read-only, and
-      the server MUST prefix the text of the tagged OK response to
-      SELECT with the "[READ-ONLY]" response code.  Read-only access
-      through SELECT differs from the EXAMINE command in that certain
-      read-only mailboxes MAY permit the change of permanent state on a
-      per-user (as opposed to global) basis.  Netnews messages marked in
-      a server-based .newsrc file are an example of such per-user
-      permanent state that can be modified with read-only mailboxes.
-
-   Example:    C: A142 SELECT INBOX
-               S: * 172 EXISTS
-               S: * 1 RECENT
-               S: * OK [UNSEEN 12] Message 12 is first unseen
-               S: * OK [UIDVALIDITY 3857529045] UIDs valid
-               S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
-               S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
-               S: A142 OK [READ-WRITE] SELECT completed
-
-6.3.2.  EXAMINE Command
-
-   Arguments:  mailbox name
-
-   Responses:  REQUIRED untagged responses: FLAGS, EXISTS, RECENT
-               OPTIONAL OK untagged responses: UNSEEN, PERMANENTFLAGS
-
-   Result:     OK - examine completed, now in selected state
-               NO - examine failure, now in authenticated state: no
-                    such mailbox, can't access mailbox
-               BAD - command unknown or arguments invalid
-
-      The EXAMINE command is identical to SELECT and returns the same
-      output; however, the selected mailbox is identified as read-only.
-      No changes to the permanent state of the mailbox, including
-      per-user state, are permitted.
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin                     Standards Track                    [Page 24]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-      The text of the tagged OK response to the EXAMINE command MUST
-      begin with the "[READ-ONLY]" response code.
-
-   Example:    C: A932 EXAMINE blurdybloop
-               S: * 17 EXISTS
-               S: * 2 RECENT
-               S: * OK [UNSEEN 8] Message 8 is first unseen
-               S: * OK [UIDVALIDITY 3857529045] UIDs valid
-               S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
-               S: * OK [PERMANENTFLAGS ()] No permanent flags permitted
-               S: A932 OK [READ-ONLY] EXAMINE completed
-
-6.3.3.  CREATE Command
-
-   Arguments:  mailbox name
-
-   Responses:  no specific responses for this command
-
-   Result:     OK - create completed
-               NO - create failure: can't create mailbox with that name
-               BAD - command unknown or arguments invalid
-
-      The CREATE command creates a mailbox with the given name.  An OK
-      response is returned only if a new mailbox with that name has been
-      created.  It is an error to attempt to create INBOX or a mailbox
-      with a name that refers to an extant mailbox.  Any error in
-      creation will return a tagged NO response.
-
-      If the mailbox name is suffixed with the server's hierarchy
-      separator character (as returned from the server by a LIST
-      command), this is a declaration that the client intends to create
-      mailbox names under this name in the hierarchy.  Server
-      implementations that do not require this declaration MUST ignore
-      it.
-
-      If the server's hierarchy separator character appears elsewhere in
-      the name, the server SHOULD create any superior hierarchical names
-      that are needed for the CREATE command to complete successfully.
-      In other words, an attempt to create "foo/bar/zap" on a server in
-      which "/" is the hierarchy separator character SHOULD create foo/
-      and foo/bar/ if they do not already exist.
-
-      If a new mailbox is created with the same name as a mailbox which
-      was deleted, its unique identifiers MUST be greater than any
-      unique identifiers used in the previous incarnation of the mailbox
-      UNLESS the new incarnation has a different unique identifier
-      validity value.  See the description of the UID command for more
-      detail.
-
-
-
-Crispin                     Standards Track                    [Page 25]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-   Example:    C: A003 CREATE owatagusiam/
-               S: A003 OK CREATE completed
-               C: A004 CREATE owatagusiam/blurdybloop
-               S: A004 OK CREATE completed
-
-      Note: the interpretation of this example depends on whether "/"
-      was returned as the hierarchy separator from LIST.  If "/" is the
-      hierarchy separator, a new level of hierarchy named "owatagusiam"
-      with a member called "blurdybloop" is created.  Otherwise, two
-      mailboxes at the same hierarchy level are created.
-
-6.3.4.  DELETE Command
-
-   Arguments:  mailbox name
-
-   Responses:  no specific responses for this command
-
-   Result:     OK - delete completed
-               NO - delete failure: can't delete mailbox with that name
-               BAD - command unknown or arguments invalid
-
-      The DELETE command permanently removes the mailbox with the given
-      name.  A tagged OK response is returned only if the mailbox has
-      been deleted.  It is an error to attempt to delete INBOX or a
-      mailbox name that does not exist.
-
-      The DELETE command MUST NOT remove inferior hierarchical names.
-      For example, if a mailbox "foo" has an inferior "foo.bar"
-      (assuming "." is the hierarchy delimiter character), removing
-      "foo" MUST NOT remove "foo.bar".  It is an error to attempt to
-      delete a name that has inferior hierarchical names and also has
-      the \Noselect mailbox name attribute (see the description of the
-      LIST response for more details).
-
-      It is permitted to delete a name that has inferior hierarchical
-      names and does not have the \Noselect mailbox name attribute.  In
-      this case, all messages in that mailbox are removed, and the name
-      will acquire the \Noselect mailbox name attribute.
-
-      The value of the highest-used unique identifier of the deleted
-      mailbox MUST be preserved so that a new mailbox created with the
-      same name will not reuse the identifiers of the former
-      incarnation, UNLESS the new incarnation has a different unique
-      identifier validity value.  See the description of the UID command
-      for more detail.
-
-
-
-
-
-
-Crispin                     Standards Track                    [Page 26]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-   Examples:   C: A682 LIST "" *
-               S: * LIST () "/" blurdybloop
-               S: * LIST (\Noselect) "/" foo
-               S: * LIST () "/" foo/bar
-               S: A682 OK LIST completed
-               C: A683 DELETE blurdybloop
-               S: A683 OK DELETE completed
-               C: A684 DELETE foo
-               S: A684 NO Name "foo" has inferior hierarchical names
-               C: A685 DELETE foo/bar
-               S: A685 OK DELETE Completed
-               C: A686 LIST "" *
-               S: * LIST (\Noselect) "/" foo
-               S: A686 OK LIST completed
-               C: A687 DELETE foo
-               S: A687 OK DELETE Completed
-
-
-               C: A82 LIST "" *
-               S: * LIST () "." blurdybloop
-               S: * LIST () "." foo
-               S: * LIST () "." foo.bar
-               S: A82 OK LIST completed
-               C: A83 DELETE blurdybloop
-               S: A83 OK DELETE completed
-               C: A84 DELETE foo
-               S: A84 OK DELETE Completed
-               C: A85 LIST "" *
-               S: * LIST () "." foo.bar
-               S: A85 OK LIST completed
-               C: A86 LIST "" %
-               S: * LIST (\Noselect) "." foo
-               S: A86 OK LIST completed
-
-6.3.5.  RENAME Command
-
-   Arguments:  existing mailbox name
-               new mailbox name
-
-   Responses:  no specific responses for this command
-
-   Result:     OK - rename completed
-               NO - rename failure: can't rename mailbox with that name,
-                    can't rename to mailbox with that name
-               BAD - command unknown or arguments invalid
-
-      The RENAME command changes the name of a mailbox.  A tagged OK
-      response is returned only if the mailbox has been renamed.  It is
-
-
-
-Crispin                     Standards Track                    [Page 27]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-      an error to attempt to rename from a mailbox name that does not
-      exist or to a mailbox name that already exists.  Any error in
-      renaming will return a tagged NO response.
-
-      If the name has inferior hierarchical names, then the inferior
-      hierarchical names MUST also be renamed.  For example, a rename of
-      "foo" to "zap" will rename "foo/bar" (assuming "/" is the
-      hierarchy delimiter character) to "zap/bar".
-
-      The value of the highest-used unique identifier of the old mailbox
-      name MUST be preserved so that a new mailbox created with the same
-      name will not reuse the identifiers of the former incarnation,
-      UNLESS the new incarnation has a different unique identifier
-      validity value.  See the description of the UID command for more
-      detail.
-
-      Renaming INBOX is permitted, and has special behavior.  It moves
-      all messages in INBOX to a new mailbox with the given name,
-      leaving INBOX empty.  If the server implementation supports
-      inferior hierarchical names of INBOX, these are unaffected by a
-      rename of INBOX.
-
-   Examples:   C: A682 LIST "" *
-               S: * LIST () "/" blurdybloop
-               S: * LIST (\Noselect) "/" foo
-               S: * LIST () "/" foo/bar
-               S: A682 OK LIST completed
-               C: A683 RENAME blurdybloop sarasoop
-               S: A683 OK RENAME completed
-               C: A684 RENAME foo zowie
-               S: A684 OK RENAME Completed
-               C: A685 LIST "" *
-               S: * LIST () "/" sarasoop
-               S: * LIST (\Noselect) "/" zowie
-               S: * LIST () "/" zowie/bar
-               S: A685 OK LIST completed
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin                     Standards Track                    [Page 28]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-               C: Z432 LIST "" *
-               S: * LIST () "." INBOX
-               S: * LIST () "." INBOX.bar
-               S: Z432 OK LIST completed
-               C: Z433 RENAME INBOX old-mail
-               S: Z433 OK RENAME completed
-               C: Z434 LIST "" *
-               S: * LIST () "." INBOX
-               S: * LIST () "." INBOX.bar
-               S: * LIST () "." old-mail
-               S: Z434 OK LIST completed
-
-6.3.6.  SUBSCRIBE Command
-
-   Arguments:  mailbox
-
-   Responses:  no specific responses for this command
-
-   Result:     OK - subscribe completed
-               NO - subscribe failure: can't subscribe to that name
-               BAD - command unknown or arguments invalid
-
-      The SUBSCRIBE command adds the specified mailbox name to the
-      server's set of "active" or "subscribed" mailboxes as returned by
-      the LSUB command.  This command returns a tagged OK response only
-      if the subscription is successful.
-
-      A server MAY validate the mailbox argument to SUBSCRIBE to verify
-      that it exists.  However, it MUST NOT unilaterally remove an
-      existing mailbox name from the subscription list even if a mailbox
-      by that name no longer exists.
-
-      Note: this requirement is because some server sites may routinely
-      remove a mailbox with a well-known name (e.g.  "system-alerts")
-      after its contents expire, with the intention of recreating it
-      when new contents are appropriate.
-
-   Example:    C: A002 SUBSCRIBE #news.comp.mail.mime
-               S: A002 OK SUBSCRIBE completed
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin                     Standards Track                    [Page 29]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-6.3.7.  UNSUBSCRIBE Command
-
-   Arguments:  mailbox name
-
-   Responses:  no specific responses for this command
-
-   Result:     OK - unsubscribe completed
-               NO - unsubscribe failure: can't unsubscribe that name
-               BAD - command unknown or arguments invalid
-
-      The UNSUBSCRIBE command removes the specified mailbox name from
-      the server's set of "active" or "subscribed" mailboxes as returned
-      by the LSUB command.  This command returns a tagged OK response
-      only if the unsubscription is successful.
-
-   Example:    C: A002 UNSUBSCRIBE #news.comp.mail.mime
-               S: A002 OK UNSUBSCRIBE completed
-
-6.3..8.  LIST Command
-
-   Arguments:  reference name
-               mailbox name with possible wildcards
-
-   Responses:  untagged responses: LIST
-
-   Result:     OK - list completed
-               NO - list failure: can't list that reference or name
-               BAD - command unknown or arguments invalid
-
-      The LIST command returns a subset of names from the complete set
-      of all names available to the client.  Zero or more untagged LIST
-      replies are returned, containing the name attributes, hierarchy
-      delimiter, and name; see the description of the LIST reply for
-      more detail.
-
-      The LIST command SHOULD return its data quickly, without undue
-      delay.  For example, it SHOULD NOT go to excess trouble to
-      calculate \Marked or \Unmarked status or perform other processing;
-      if each name requires 1 second of processing, then a list of 1200
-      names would take 20 minutes!
-
-      An empty ("" string) reference name argument indicates that the
-      mailbox name is interpreted as by SELECT. The returned mailbox
-      names MUST match the supplied mailbox name pattern.  A non-empty
-      reference name argument is the name of a mailbox or a level of
-      mailbox hierarchy, and indicates a context in which the mailbox
-      name is interpreted in an implementation-defined manner.
-
-
-
-
-Crispin                     Standards Track                    [Page 30]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-      An empty ("" string) mailbox name argument is a special request to
-      return the hierarchy delimiter and the root name of the name given
-      in the reference.  The value returned as the root MAY be null if
-      the reference is non-rooted or is null.  In all cases, the
-      hierarchy delimiter is returned.  This permits a client to get the
-      hierarchy delimiter even when no mailboxes by that name currently
-      exist.
-
-      The reference and mailbox name arguments are interpreted, in an
-      implementation-dependent fashion, into a canonical form that
-      represents an unambiguous left-to-right hierarchy.  The returned
-      mailbox names will be in the interpreted form.
-
-      Any part of the reference argument that is included in the
-      interpreted form SHOULD prefix the interpreted form.  It SHOULD
-      also be in the same form as the reference name argument.  This
-      rule permits the client to determine if the returned mailbox name
-      is in the context of the reference argument, or if something about
-      the mailbox argument overrode the reference argument.  Without
-      this rule, the client would have to have knowledge of the server's
-      naming semantics including what characters are "breakouts" that
-      override a naming context.
-
-      For example, here are some examples of how references and mailbox
-      names might be interpreted on a UNIX-based server:
-
-               Reference     Mailbox Name  Interpretation
-               ------------  ------------  --------------
-               ~smith/Mail/  foo.*         ~smith/Mail/foo.*
-               archive/      %             archive/%
-               #news.        comp.mail.*   #news.comp.mail.*
-               ~smith/Mail/  /usr/doc/foo  /usr/doc/foo
-               archive/      ~fred/Mail/*  ~fred/Mail/*
-
-      The first three examples demonstrate interpretations in the
-      context of the reference argument.  Note that "~smith/Mail" SHOULD
-      NOT be transformed into something like "/u2/users/smith/Mail", or
-      it would be impossible for the client to determine that the
-      interpretation was in the context of the reference.
-
-      The character "*" is a wildcard, and matches zero or more
-      characters at this position.  The character "%" is similar to "*",
-      but it does not match a hierarchy delimiter.  If the "%" wildcard
-      is the last character of a mailbox name argument, matching levels
-      of hierarchy are also returned.  If these levels of hierarchy are
-      not also selectable mailboxes, they are returned with the
-      \Noselect mailbox name attribute (see the description of the LIST
-      response for more details).
-
-
-
-Crispin                     Standards Track                    [Page 31]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-      Server implementations are permitted to "hide" otherwise
-      accessible mailboxes from the wildcard characters, by preventing
-      certain characters or names from matching a wildcard in certain
-      situations.  For example, a UNIX-based server might restrict the
-      interpretation of "*" so that an initial "/" character does not
-      match.
-
-      The special name INBOX is included in the output from LIST, if
-      INBOX is supported by this server for this user and if the
-      uppercase string "INBOX" matches the interpreted reference and
-      mailbox name arguments with wildcards as described above.  The
-      criteria for omitting INBOX is whether SELECT INBOX will return
-      failure; it is not relevant whether the user's real INBOX resides
-      on this or some other server.
-
-   Example:    C: A101 LIST "" ""
-               S: * LIST (\Noselect) "/" ""
-               S: A101 OK LIST Completed
-               C: A102 LIST #news.comp.mail.misc ""
-               S: * LIST (\Noselect) "." #news.
-               S: A102 OK LIST Completed
-               C: A103 LIST /usr/staff/jones ""
-               S: * LIST (\Noselect) "/" /
-               S: A103 OK LIST Completed
-               C: A202 LIST ~/Mail/ %
-               S: * LIST (\Noselect) "/" ~/Mail/foo
-               S: * LIST () "/" ~/Mail/meetings
-               S: A202 OK LIST completed
-
-6.3.9.  LSUB Command
-
-   Arguments:  reference name
-               mailbox name with possible wildcards
-
-   Responses:  untagged responses: LSUB
-
-   Result:     OK - lsub completed
-               NO - lsub failure: can't list that reference or name
-               BAD - command unknown or arguments invalid
-
-      The LSUB command returns a subset of names from the set of names
-      that the user has declared as being "active" or "subscribed".
-      Zero or more untagged LSUB replies are returned.  The arguments to
-      LSUB are in the same form as those for LIST.
-
-      A server MAY validate the subscribed names to see if they still
-      exist.  If a name does not exist, it SHOULD be flagged with the
-      \Noselect attribute in the LSUB response.  The server MUST NOT
-
-
-
-Crispin                     Standards Track                    [Page 32]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-      unilaterally remove an existing mailbox name from the subscription
-      list even if a mailbox by that name no longer exists.
-
-   Example:    C: A002 LSUB "#news." "comp.mail.*"
-               S: * LSUB () "." #news.comp.mail.mime
-               S: * LSUB () "." #news.comp.mail.misc
-               S: A002 OK LSUB completed
-
-6.3.10. STATUS Command
-
-   Arguments:  mailbox name
-               status data item names
-
-   Responses:  untagged responses: STATUS
-
-   Result:     OK - status completed
-               NO - status failure: no status for that name
-               BAD - command unknown or arguments invalid
-
-      The STATUS command requests the status of the indicated mailbox.
-      It does not change the currently selected mailbox, nor does it
-      affect the state of any messages in the queried mailbox (in
-      particular, STATUS MUST NOT cause messages to lose the \Recent
-      flag).
-
-      The STATUS command provides an alternative to opening a second
-      IMAP4rev1 connection and doing an EXAMINE command on a mailbox to
-      query that mailbox's status without deselecting the current
-      mailbox in the first IMAP4rev1 connection.
-
-      Unlike the LIST command, the STATUS command is not guaranteed to
-      be fast in its response.  In some implementations, the server is
-      obliged to open the mailbox read-only internally to obtain certain
-      status information.  Also unlike the LIST command, the STATUS
-      command does not accept wildcards.
-
-      The currently defined status data items that can be requested are:
-
-      MESSAGES       The number of messages in the mailbox.
-
-      RECENT         The number of messages with the \Recent flag set.
-
-      UIDNEXT        The next UID value that will be assigned to a new
-                     message in the mailbox.  It is guaranteed that this
-                     value will not change unless new messages are added
-                     to the mailbox; and that it will change when new
-                     messages are added even if those new messages are
-                     subsequently expunged.
-
-
-
-Crispin                     Standards Track                    [Page 33]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-      UIDVALIDITY    The unique identifier validity value of the
-                     mailbox.
-
-      UNSEEN         The number of messages which do not have the \Seen
-                     flag set.
-
-
-      Example:    C: A042 STATUS blurdybloop (UIDNEXT MESSAGES)
-                  S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292)
-                  S: A042 OK STATUS completed
-
-6.3.11. APPEND Command
-
-   Arguments:  mailbox name
-               OPTIONAL flag parenthesized list
-               OPTIONAL date/time string
-               message literal
-
-   Responses:  no specific responses for this command
-
-   Result:     OK - append completed
-               NO - append error: can't append to that mailbox, error
-                    in flags or date/time or message text
-               BAD - command unknown or arguments invalid
-
-      The APPEND command appends the literal argument as a new message
-      to the end of the specified destination mailbox.  This argument
-      SHOULD be in the format of an [RFC-822] message.  8-bit characters
-      are permitted in the message.  A server implementation that is
-      unable to preserve 8-bit data properly MUST be able to reversibly
-      convert 8-bit APPEND data to 7-bit using a [MIME-IMB] content
-      transfer encoding.
-
-      Note: There MAY be exceptions, e.g. draft messages, in which
-      required [RFC-822] header lines are omitted in the message literal
-      argument to APPEND.  The full implications of doing so MUST be
-      understood and carefully weighed.
-
-   If a flag parenthesized list is specified, the flags SHOULD be set in
-   the resulting message; otherwise, the flag list of the resulting
-   message is set empty by default.
-
-   If a date_time is specified, the internal date SHOULD be set in the
-   resulting message; otherwise, the internal date of the resulting
-   message is set to the current date and time by default.
-
-
-
-
-
-
-Crispin                     Standards Track                    [Page 34]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-   If the append is unsuccessful for any reason, the mailbox MUST be
-   restored to its state before the APPEND attempt; no partial appending
-   is permitted.
-
-   If the destination mailbox does not exist, a server MUST return an
-   error, and MUST NOT automatically create the mailbox.  Unless it is
-   certain that the destination mailbox can not be created, the server
-   MUST send the response code "[TRYCREATE]" as the prefix of the text
-   of the tagged NO response.  This gives a hint to the client that it
-   can attempt a CREATE command and retry the APPEND if the CREATE is
-   successful.
-
-   If the mailbox is currently selected, the normal new mail actions
-   SHOULD occur.  Specifically, the server SHOULD notify the client
-   immediately via an untagged EXISTS response.  If the server does not
-   do so, the client MAY issue a NOOP command (or failing that, a CHECK
-   command) after one or more APPEND commands.
-
-   Example:    C: A003 APPEND saved-messages (\Seen) {310}
-               C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
-               C: From: Fred Foobar <foobar@Blurdybloop.COM>
-               C: Subject: afternoon meeting
-               C: To: mooch@owatagu.siam.edu
-               C: Message-Id: <B27397-0100000@Blurdybloop.COM>
-               C: MIME-Version: 1.0
-               C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
-               C:
-               C: Hello Joe, do you think we can meet at 3:30 tomorrow?
-               C:
-               S: A003 OK APPEND completed
-
-      Note: the APPEND command is not used for message delivery, because
-      it does not provide a mechanism to transfer [SMTP] envelope
-      information.
-
-6.4.    Client Commands - Selected State
-
-   In selected state, commands that manipulate messages in a mailbox are
-   permitted.
-
-   In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
-   and the authenticated state commands (SELECT, EXAMINE, CREATE,
-   DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, STATUS, and
-   APPEND), the following commands are valid in the selected state:
-   CHECK, CLOSE, EXPUNGE, SEARCH, FETCH, STORE, COPY, and UID.
-
-
-
-
-
-
-Crispin                     Standards Track                    [Page 35]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-6.4.1.  CHECK Command
-
-   Arguments:  none
-
-   Responses:  no specific responses for this command
-
-   Result:     OK - check completed
-               BAD - command unknown or arguments invalid
-
-      The CHECK command requests a checkpoint of the currently selected
-      mailbox.  A checkpoint refers to any implementation-dependent
-      housekeeping associated with the mailbox (e.g. resolving the
-      server's in-memory state of the mailbox with the state on its
-      disk) that is not normally executed as part of each command.  A
-      checkpoint MAY take a non-instantaneous amount of real time to
-      complete.  If a server implementation has no such housekeeping
-      considerations, CHECK is equivalent to NOOP.
-
-      There is no guarantee that an EXISTS untagged response will happen
-      as a result of CHECK.  NOOP, not CHECK, SHOULD be used for new
-      mail polling.
-
-   Example:    C: FXXZ CHECK
-               S: FXXZ OK CHECK Completed
-
-6.4.2.  CLOSE Command
-
-   Arguments:  none
-
-   Responses:  no specific responses for this command
-
-   Result:     OK - close completed, now in authenticated state
-               NO - close failure: no mailbox selected
-               BAD - command unknown or arguments invalid
-
-      The CLOSE command permanently removes from the currently selected
-      mailbox all messages that have the \Deleted flag set, and returns
-      to authenticated state from selected state.  No untagged EXPUNGE
-      responses are sent.
-
-      No messages are removed, and no error is given, if the mailbox is
-      selected by an EXAMINE command or is otherwise selected read-only.
-
-      Even if a mailbox is selected, a SELECT, EXAMINE, or LOGOUT
-      command MAY be issued without previously issuing a CLOSE command.
-      The SELECT, EXAMINE, and LOGOUT commands implicitly close the
-      currently selected mailbox without doing an expunge.  However,
-      when many messages are deleted, a CLOSE-LOGOUT or CLOSE-SELECT
-
-
-
-Crispin                     Standards Track                    [Page 36]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-      sequence is considerably faster than an EXPUNGE-LOGOUT or
-      EXPUNGE-SELECT because no untagged EXPUNGE responses (which the
-      client would probably ignore) are sent.
-
-   Example:    C: A341 CLOSE
-               S: A341 OK CLOSE completed
-
-6.4.3.  EXPUNGE Command
-
-   Arguments:  none
-
-   Responses:  untagged responses: EXPUNGE
-
-   Result:     OK - expunge completed
-               NO - expunge failure: can't expunge (e.g. permission
-                    denied)
-               BAD - command unknown or arguments invalid
-
-      The EXPUNGE command permanently removes from the currently
-      selected mailbox all messages that have the \Deleted flag set.
-      Before returning an OK to the client, an untagged EXPUNGE response
-      is sent for each message that is removed.
-
-   Example:    C: A202 EXPUNGE
-               S: * 3 EXPUNGE
-               S: * 3 EXPUNGE
-               S: * 5 EXPUNGE
-               S: * 8 EXPUNGE
-               S: A202 OK EXPUNGE completed
-
-      Note: in this example, messages 3, 4, 7, and 11 had the
-      \Deleted flag set.  See the description of the EXPUNGE
-      response for further explanation.
-
-6.4.4.  SEARCH Command
-
-   Arguments:  OPTIONAL [CHARSET] specification
-               searching criteria (one or more)
-
-   Responses:  REQUIRED untagged response: SEARCH
-
-   Result:     OK - search completed
-               NO - search error: can't search that [CHARSET] or
-                    criteria
-               BAD - command unknown or arguments invalid
-
-
-
-
-
-
-Crispin                     Standards Track                    [Page 37]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-      The SEARCH command searches the mailbox for messages that match
-      the given searching criteria.  Searching criteria consist of one
-      or more search keys.  The untagged SEARCH response from the server
-      contains a listing of message sequence numbers corresponding to
-      those messages that match the searching criteria.
-
-      When multiple keys are specified, the result is the intersection
-      (AND function) of all the messages that match those keys.  For
-      example, the criteria DELETED FROM "SMITH" SINCE 1-Feb-1994 refers
-      to all deleted messages from Smith that were placed in the mailbox
-      since February 1, 1994.  A search key can also be a parenthesized
-      list of one or more search keys (e.g. for use with the OR and NOT
-      keys).
-
-      Server implementations MAY exclude [MIME-IMB] body parts with
-      terminal content media types other than TEXT and MESSAGE from
-      consideration in SEARCH matching.
-
-      The OPTIONAL [CHARSET] specification consists of the word
-      "CHARSET" followed by a registered [CHARSET].  It indicates the
-      [CHARSET] of the strings that appear in the search criteria.
-      [MIME-IMB] content transfer encodings, and [MIME-HDRS] strings in
-      [RFC-822]/[MIME-IMB] headers, MUST be decoded before comparing
-      text in a [CHARSET] other than US-ASCII.  US-ASCII MUST be
-      supported; other [CHARSET]s MAY be supported.  If the server does
-      not support the specified [CHARSET], it MUST return a tagged NO
-      response (not a BAD).
-
-      In all search keys that use strings, a message matches the key if
-      the string is a substring of the field.  The matching is case-
-      insensitive.
-
-      The defined search keys are as follows.  Refer to the Formal
-      Syntax section for the precise syntactic definitions of the
-      arguments.
-
-      <message set>  Messages with message sequence numbers
-                     corresponding to the specified message sequence
-                     number set
-
-      ALL            All messages in the mailbox; the default initial
-                     key for ANDing.
-
-      ANSWERED       Messages with the \Answered flag set.
-
-      BCC <string>   Messages that contain the specified string in the
-                     envelope structure's BCC field.
-
-
-
-
-Crispin                     Standards Track                    [Page 38]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-      BEFORE <date>  Messages whose internal date is earlier than the
-                     specified date.
-
-      BODY <string>  Messages that contain the specified string in the
-                     body of the message.
-
-      CC <string>    Messages that contain the specified string in the
-                     envelope structure's CC field.
-
-      DELETED        Messages with the \Deleted flag set.
-
-      DRAFT          Messages with the \Draft flag set.
-
-      FLAGGED        Messages with the \Flagged flag set.
-
-      FROM <string>  Messages that contain the specified string in the
-                     envelope structure's FROM field.
-
-      HEADER <field-name> <string>
-                     Messages that have a header with the specified
-                     field-name (as defined in [RFC-822]) and that
-                     contains the specified string in the [RFC-822]
-                     field-body.
-
-      KEYWORD <flag> Messages with the specified keyword set.
-
-      LARGER <n>     Messages with an [RFC-822] size larger than the
-                     specified number of octets.
-
-      NEW            Messages that have the \Recent flag set but not the
-                     \Seen flag.  This is functionally equivalent to
-                     "(RECENT UNSEEN)".
-
-      NOT <search-key>
-                     Messages that do not match the specified search
-                     key.
-
-      OLD            Messages that do not have the \Recent flag set.
-                     This is functionally equivalent to "NOT RECENT" (as
-                     opposed to "NOT NEW").
-
-      ON <date>      Messages whose internal date is within the
-                     specified date.
-
-      OR <search-key1> <search-key2>
-                     Messages that match either search key.
-
-      RECENT         Messages that have the \Recent flag set.
-
-
-
-Crispin                     Standards Track                    [Page 39]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-      SEEN           Messages that have the \Seen flag set.
-
-      SENTBEFORE <date>
-                     Messages whose [RFC-822] Date: header is earlier
-                     than the specified date.
-
-      SENTON <date>  Messages whose [RFC-822] Date: header is within the
-                     specified date.
-
-      SENTSINCE <date>
-                     Messages whose [RFC-822] Date: header is within or
-                     later than the specified date.
-
-      SINCE <date>   Messages whose internal date is within or later
-                     than the specified date.
-
-      SMALLER <n>    Messages with an [RFC-822] size smaller than the
-                     specified number of octets.
-
-      SUBJECT <string>
-                     Messages that contain the specified string in the
-                     envelope structure's SUBJECT field.
-
-      TEXT <string>  Messages that contain the specified string in the
-                     header or body of the message.
-
-      TO <string>    Messages that contain the specified string in the
-                     envelope structure's TO field.
-
-      UID <message set>
-                     Messages with unique identifiers corresponding to
-                     the specified unique identifier set.
-
-      UNANSWERED     Messages that do not have the \Answered flag set.
-
-      UNDELETED      Messages that do not have the \Deleted flag set.
-
-      UNDRAFT        Messages that do not have the \Draft flag set.
-
-      UNFLAGGED      Messages that do not have the \Flagged flag set.
-
-      UNKEYWORD <flag>
-                     Messages that do not have the specified keyword
-                     set.
-
-      UNSEEN         Messages that do not have the \Seen flag set.
-
-
-
-
-
-Crispin                     Standards Track                    [Page 40]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-   Example:    C: A282 SEARCH FLAGGED SINCE 1-Feb-1994 NOT FROM "Smith"
-               S: * SEARCH 2 84 882
-               S: A282 OK SEARCH completed
-
-6.4.5.  FETCH Command
-
-   Arguments:  message set
-               message data item names
-
-   Responses:  untagged responses: FETCH
-
-   Result:     OK - fetch completed
-               NO - fetch error: can't fetch that data
-               BAD - command unknown or arguments invalid
-
-      The FETCH command retrieves data associated with a message in the
-      mailbox.  The data items to be fetched can be either a single atom
-      or a parenthesized list.
-
-      The currently defined data items that can be fetched are:
-
-      ALL            Macro equivalent to: (FLAGS INTERNALDATE
-                     RFC822.SIZE ENVELOPE)
-
-      BODY           Non-extensible form of BODYSTRUCTURE.
-
-      BODY[<section>]<<partial>>
-                     The text of a particular body section.  The section
-                     specification is a set of zero or more part
-                     specifiers delimited by periods.  A part specifier
-                     is either a part number or one of the following:
-                     HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, MIME, and
-                     TEXT.  An empty section specification refers to the
-                     entire message, including the header.
-
-                     Every message has at least one part number.
-                     Non-[MIME-IMB] messages, and non-multipart
-                     [MIME-IMB] messages with no encapsulated message,
-                     only have a part 1.
-
-                     Multipart messages are assigned consecutive part
-                     numbers, as they occur in the message.  If a
-                     particular part is of type message or multipart,
-                     its parts MUST be indicated by a period followed by
-                     the part number within that nested multipart part.
-
-
-
-
-
-
-Crispin                     Standards Track                    [Page 41]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-                     A part of type MESSAGE/RFC822 also has nested part
-                     numbers, referring to parts of the MESSAGE part's
-                     body.
-
-                     The HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, and
-                     TEXT part specifiers can be the sole part specifier
-                     or can be prefixed by one or more numeric part
-                     specifiers, provided that the numeric part
-                     specifier refers to a part of type MESSAGE/RFC822.
-                     The MIME part specifier MUST be prefixed by one or
-                     more numeric part specifiers.
-
-                     The HEADER, HEADER.FIELDS, and HEADER.FIELDS.NOT
-                     part specifiers refer to the [RFC-822] header of
-                     the message or of an encapsulated [MIME-IMT]
-                     MESSAGE/RFC822 message.  HEADER.FIELDS and
-                     HEADER.FIELDS.NOT are followed by a list of
-                     field-name (as defined in [RFC-822]) names, and
-                     return a subset of the header.  The subset returned
-                     by HEADER.FIELDS contains only those header fields
-                     with a field-name that matches one of the names in
-                     the list; similarly, the subset returned by
-                     HEADER.FIELDS.NOT contains only the header fields
-                     with a non-matching field-name.  The field-matching
-                     is case-insensitive but otherwise exact.  In all
-                     cases, the delimiting blank line between the header
-                     and the body is always included.
-
-                     The MIME part specifier refers to the [MIME-IMB]
-                     header for this part.
-
-                     The TEXT part specifier refers to the text body of
-                     the message, omitting the [RFC-822] header.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin                     Standards Track                    [Page 42]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-                       Here is an example of a complex message
-                       with some of its part specifiers:
-
-                        HEADER     ([RFC-822] header of the message)
-                        TEXT       MULTIPART/MIXED
-                        1          TEXT/PLAIN
-                        2          APPLICATION/OCTET-STREAM
-                        3          MESSAGE/RFC822
-                        3.HEADER   ([RFC-822] header of the message)
-                        3.TEXT     ([RFC-822] text body of the message)
-                        3.1        TEXT/PLAIN
-                        3.2        APPLICATION/OCTET-STREAM
-                        4          MULTIPART/MIXED
-                        4.1        IMAGE/GIF
-                        4.1.MIME   ([MIME-IMB] header for the IMAGE/GIF)
-                        4.2        MESSAGE/RFC822
-                        4.2.HEADER ([RFC-822] header of the message)
-                        4.2.TEXT   ([RFC-822] text body of the message)
-                        4.2.1      TEXT/PLAIN
-                        4.2.2      MULTIPART/ALTERNATIVE
-                        4.2.2.1    TEXT/PLAIN
-                        4.2.2.2    TEXT/RICHTEXT
-
-
-                     It is possible to fetch a substring of the
-                     designated text.  This is done by appending an open
-                     angle bracket ("<"), the octet position of the
-                     first desired octet, a period, the maximum number
-                     of octets desired, and a close angle bracket (">")
-                     to the part specifier.  If the starting octet is
-                     beyond the end of the text, an empty string is
-                     returned.
-
-                     Any partial fetch that attempts to read beyond the
-                     end of the text is truncated as appropriate.  A
-                     partial fetch that starts at octet 0 is returned as
-                     a partial fetch, even if this truncation happened.
-
-                          Note: this means that BODY[]<0.2048> of a
-                          1500-octet message will return BODY[]<0>
-                          with a literal of size 1500, not BODY[].
-
-                          Note: a substring fetch of a
-                          HEADER.FIELDS or HEADER.FIELDS.NOT part
-                          specifier is calculated after subsetting
-                          the header.
-
-
-
-
-
-Crispin                     Standards Track                    [Page 43]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-                     The \Seen flag is implicitly set; if this causes
-                     the flags to change they SHOULD be included as part
-                     of the FETCH responses.
-
-      BODY.PEEK[<section>]<<partial>> An alternate form of
-                     BODY[<section>] that does not implicitly set the
-                     \Seen flag.
-
-      BODYSTRUCTURE  The [MIME-IMB] body structure of the message.  This
-                     is computed by the server by parsing the [MIME-IMB]
-                     header fields in the [RFC-822] header and
-                     [MIME-IMB] headers.
-
-      ENVELOPE       The envelope structure of the message.  This is
-                     computed by the server by parsing the [RFC-822]
-                     header into the component parts, defaulting various
-                     fields as necessary.
-
-      FAST           Macro equivalent to: (FLAGS INTERNALDATE
-                     RFC822.SIZE)
-
-      FLAGS          The flags that are set for this message.
-
-      FULL           Macro equivalent to: (FLAGS INTERNALDATE
-                     RFC822.SIZE ENVELOPE BODY)
-
-      INTERNALDATE   The internal date of the message.
-
-      RFC822         Functionally equivalent to BODY[], differing in the
-                     syntax of the resulting untagged FETCH data (RFC822
-                     is returned).
-
-      RFC822.HEADER  Functionally equivalent to BODY.PEEK[HEADER],
-                     differing in the syntax of the resulting untagged
-                     FETCH data (RFC822.HEADER is returned).
-
-      RFC822.SIZE    The [RFC-822] size of the message.
-
-      RFC822.TEXT    Functionally equivalent to BODY[TEXT], differing in
-                     the syntax of the resulting untagged FETCH data
-                     (RFC822.TEXT is returned).
-
-      UID            The unique identifier for the message.
-
-
-
-
-
-
-
-
-Crispin                     Standards Track                    [Page 44]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-   Example:    C: A654 FETCH 2:4 (FLAGS BODY[HEADER.FIELDS (DATE FROM)])
-               S: * 2 FETCH ....
-               S: * 3 FETCH ....
-               S: * 4 FETCH ....
-               S: A654 OK FETCH completed
-
-6.4.6.  STORE Command
-
-   Arguments:  message set
-               message data item name
-               value for message data item
-
-   Responses:  untagged responses: FETCH
-
-   Result:     OK - store completed
-               NO - store error: can't store that data
-               BAD - command unknown or arguments invalid
-
-      The STORE command alters data associated with a message in the
-      mailbox.  Normally, STORE will return the updated value of the
-      data with an untagged FETCH response.  A suffix of ".SILENT" in
-      the data item name prevents the untagged FETCH, and the server
-      SHOULD assume that the client has determined the updated value
-      itself or does not care about the updated value.
-
-         Note: regardless of whether or not the ".SILENT" suffix was
-         used, the server SHOULD send an untagged FETCH response if a
-         change to a message's flags from an external source is
-         observed.  The intent is that the status of the flags is
-         determinate without a race condition.
-
-      The currently defined data items that can be stored are:
-
-      FLAGS <flag list>
-                     Replace the flags for the message with the
-                     argument.  The new value of the flags are returned
-                     as if a FETCH of those flags was done.
-
-      FLAGS.SILENT <flag list>
-                     Equivalent to FLAGS, but without returning a new
-                     value.
-
-      +FLAGS <flag list>
-                     Add the argument to the flags for the message.  The
-                     new value of the flags are returned as if a FETCH
-                     of those flags was done.
-
-
-
-
-
-Crispin                     Standards Track                    [Page 45]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-      +FLAGS.SILENT <flag list>
-                     Equivalent to +FLAGS, but without returning a new
-                     value.
-
-      -FLAGS <flag list>
-                     Remove the argument from the flags for the message.
-                     The new value of the flags are returned as if a
-                     FETCH of those flags was done.
-
-      -FLAGS.SILENT <flag list>
-                     Equivalent to -FLAGS, but without returning a new
-                     value.
-
-   Example:    C: A003 STORE 2:4 +FLAGS (\Deleted)
-               S: * 2 FETCH FLAGS (\Deleted \Seen)
-               S: * 3 FETCH FLAGS (\Deleted)
-               S: * 4 FETCH FLAGS (\Deleted \Flagged \Seen)
-               S: A003 OK STORE completed
-
-6.4.7.  COPY Command
-
-   Arguments:  message set
-               mailbox name
-
-   Responses:  no specific responses for this command
-
-   Result:     OK - copy completed
-               NO - copy error: can't copy those messages or to that
-                    name
-               BAD - command unknown or arguments invalid
-
-      The COPY command copies the specified message(s) to the end of the
-      specified destination mailbox.  The flags and internal date of the
-      message(s) SHOULD be preserved in the copy.
-
-      If the destination mailbox does not exist, a server SHOULD return
-      an error.  It SHOULD NOT automatically create the mailbox.  Unless
-      it is certain that the destination mailbox can not be created, the
-      server MUST send the response code "[TRYCREATE]" as the prefix of
-      the text of the tagged NO response.  This gives a hint to the
-      client that it can attempt a CREATE command and retry the COPY if
-      the CREATE is successful.
-
-
-
-
-
-
-
-
-
-Crispin                     Standards Track                    [Page 46]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-      If the COPY command is unsuccessful for any reason, server
-      implementations MUST restore the destination mailbox to its state
-      before the COPY attempt.
-
-   Example:    C: A003 COPY 2:4 MEETING
-               S: A003 OK COPY completed
-
-6.4.8.  UID Command
-
-   Arguments:  command name
-               command arguments
-
-   Responses:  untagged responses: FETCH, SEARCH
-
-   Result:     OK - UID command completed
-               NO - UID command error
-               BAD - command unknown or arguments invalid
-
-      The UID command has two forms.  In the first form, it takes as its
-      arguments a COPY, FETCH, or STORE command with arguments
-      appropriate for the associated command.  However, the numbers in
-      the message set argument are unique identifiers instead of message
-      sequence numbers.
-
-      In the second form, the UID command takes a SEARCH command with
-      SEARCH command arguments.  The interpretation of the arguments is
-      the same as with SEARCH; however, the numbers returned in a SEARCH
-      response for a UID SEARCH command are unique identifiers instead
-      of message sequence numbers.  For example, the command UID SEARCH
-      1:100 UID 443:557 returns the unique identifiers corresponding to
-      the intersection of the message sequence number set 1:100 and the
-      UID set 443:557.
-
-      Message set ranges are permitted; however, there is no guarantee
-      that unique identifiers be contiguous.  A non-existent unique
-      identifier within a message set range is ignored without any error
-      message generated.
-
-      The number after the "*" in an untagged FETCH response is always a
-      message sequence number, not a unique identifier, even for a UID
-      command response.  However, server implementations MUST implicitly
-      include the UID message data item as part of any FETCH response
-      caused by a UID command, regardless of whether a UID was specified
-      as a message data item to the FETCH.
-
-
-
-
-
-
-
-Crispin                     Standards Track                    [Page 47]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-   Example:    C: A999 UID FETCH 4827313:4828442 FLAGS
-               S: * 23 FETCH (FLAGS (\Seen) UID 4827313)
-               S: * 24 FETCH (FLAGS (\Seen) UID 4827943)
-               S: * 25 FETCH (FLAGS (\Seen) UID 4828442)
-               S: A999 UID FETCH completed
-
-6.5.    Client Commands - Experimental/Expansion
-
-6.5.1.  X<atom> Command
-
-   Arguments:  implementation defined
-
-   Responses:  implementation defined
-
-   Result:     OK - command completed
-               NO - failure
-               BAD - command unknown or arguments invalid
-
-      Any command prefixed with an X is an experimental command.
-      Commands which are not part of this specification, a standard or
-      standards-track revision of this specification, or an IESG-
-      approved experimental protocol, MUST use the X prefix.
-
-      Any added untagged responses issued by an experimental command
-      MUST also be prefixed with an X.  Server implementations MUST NOT
-      send any such untagged responses, unless the client requested it
-      by issuing the associated experimental command.
-
-   Example:    C: a441 CAPABILITY
-               S: * CAPABILITY IMAP4rev1 AUTH=KERBEROS_V4 XPIG-LATIN
-               S: a441 OK CAPABILITY completed
-               C: A442 XPIG-LATIN
-               S: * XPIG-LATIN ow-nay eaking-spay ig-pay atin-lay
-               S: A442 OK XPIG-LATIN ompleted-cay
-
-7.      Server Responses
-
-   Server responses are in three forms: status responses, server data,
-   and command continuation request.  The information contained in a
-   server response, identified by "Contents:" in the response
-   descriptions below, is described by function, not by syntax.  The
-   precise syntax of server responses is described in the Formal Syntax
-   section.
-
-   The client MUST be prepared to accept any response at all times.
-
-
-
-
-
-
-Crispin                     Standards Track                    [Page 48]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-   Status responses can be tagged or untagged.  Tagged status responses
-   indicate the completion result (OK, NO, or BAD status) of a client
-   command, and have a tag matching the command.
-
-   Some status responses, and all server data, are untagged.  An
-   untagged response is indicated by the token "*" instead of a tag.
-   Untagged status responses indicate server greeting, or server status
-   that does not indicate the completion of a command (for example, an
-   impending system shutdown alert).  For historical reasons, untagged
-   server data responses are also called "unsolicited data", although
-   strictly speaking only unilateral server data is truly "unsolicited".
-
-   Certain server data MUST be recorded by the client when it is
-   received; this is noted in the description of that data.  Such data
-   conveys critical information which affects the interpretation of all
-   subsequent commands and responses (e.g. updates reflecting the
-   creation or destruction of messages).
-
-   Other server data SHOULD be recorded for later reference; if the
-   client does not need to record the data, or if recording the data has
-   no obvious purpose (e.g. a SEARCH response when no SEARCH command is
-   in progress), the data SHOULD be ignored.
-
-   An example of unilateral untagged server data occurs when the IMAP
-   connection is in selected state.  In selected state, the server
-   checks the mailbox for new messages as part of command execution.
-   Normally, this is part of the execution of every command; hence, a
-   NOOP command suffices to check for new messages.  If new messages are
-   found, the server sends untagged EXISTS and RECENT responses
-   reflecting the new size of the mailbox.  Server implementations that
-   offer multiple simultaneous access to the same mailbox SHOULD also
-   send appropriate unilateral untagged FETCH and EXPUNGE responses if
-   another agent changes the state of any message flags or expunges any
-   messages.
-
-   Command continuation request responses use the token "+" instead of a
-   tag.  These responses are sent by the server to indicate acceptance
-   of an incomplete client command and readiness for the remainder of
-   the command.
-
-7.1.    Server Responses - Status Responses
-
-   Status responses are OK, NO, BAD, PREAUTH and BYE.  OK, NO, and BAD
-   may be tagged or untagged.  PREAUTH and BYE are always untagged.
-
-   Status responses MAY include an OPTIONAL "response code".  A response
-   code consists of data inside square brackets in the form of an atom,
-   possibly followed by a space and arguments.  The response code
-
-
-
-Crispin                     Standards Track                    [Page 49]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-   contains additional information or status codes for client software
-   beyond the OK/NO/BAD condition, and are defined when there is a
-   specific action that a client can take based upon the additional
-   information.
-
-   The currently defined response codes are:
-
-      ALERT          The human-readable text contains a special alert
-                     that MUST be presented to the user in a fashion
-                     that calls the user's attention to the message.
-
-      NEWNAME        Followed by a mailbox name and a new mailbox name.
-                     A SELECT or EXAMINE is failing because the target
-                     mailbox name no longer exists because it was
-                     renamed to the new mailbox name.  This is a hint to
-                     the client that the operation can succeed if the
-                     SELECT or EXAMINE is reissued with the new mailbox
-                     name.
-
-      PARSE          The human-readable text represents an error in
-                     parsing the [RFC-822] header or [MIME-IMB] headers
-                     of a message in the mailbox.
-
-      PERMANENTFLAGS Followed by a parenthesized list of flags,
-                     indicates which of the known flags that the client
-                     can change permanently.  Any flags that are in the
-                     FLAGS untagged response, but not the PERMANENTFLAGS
-                     list, can not be set permanently.  If the client
-                     attempts to STORE a flag that is not in the
-                     PERMANENTFLAGS list, the server will either reject
-                     it with a NO reply or store the state for the
-                     remainder of the current session only.  The
-                     PERMANENTFLAGS list can also include the special
-                     flag \*, which indicates that it is possible to
-                     create new keywords by attempting to store those
-                     flags in the mailbox.
-
-      READ-ONLY      The mailbox is selected read-only, or its access
-                     while selected has changed from read-write to
-                     read-only.
-
-      READ-WRITE     The mailbox is selected read-write, or its access
-                     while selected has changed from read-only to
-                     read-write.
-
-
-
-
-
-
-
-Crispin                     Standards Track                    [Page 50]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-      TRYCREATE      An APPEND or COPY attempt is failing because the
-                     target mailbox does not exist (as opposed to some
-                     other reason).  This is a hint to the client that
-                     the operation can succeed if the mailbox is first
-                     created by the CREATE command.
-
-      UIDVALIDITY    Followed by a decimal number, indicates the unique
-                     identifier validity value.
-
-      UNSEEN         Followed by a decimal number, indicates the number
-                     of the first message without the \Seen flag set.
-
-      Additional response codes defined by particular client or server
-      implementations SHOULD be prefixed with an "X" until they are
-      added to a revision of this protocol.  Client implementations
-      SHOULD ignore response codes that they do not recognize.
-
-7.1.1.  OK Response
-
-   Contents:   OPTIONAL response code
-               human-readable text
-
-      The OK response indicates an information message from the server.
-      When tagged, it indicates successful completion of the associated
-      command.  The human-readable text MAY be presented to the user as
-      an information message.  The untagged form indicates an
-      information-only message; the nature of the information MAY be
-      indicated by a response code.
-
-      The untagged form is also used as one of three possible greetings
-      at connection startup.  It indicates that the connection is not
-      yet authenticated and that a LOGIN command is needed.
-
-   Example:    S: * OK IMAP4rev1 server ready
-               C: A001 LOGIN fred blurdybloop
-               S: * OK [ALERT] System shutdown in 10 minutes
-               S: A001 OK LOGIN Completed
-
-7.1.2.  NO Response
-
-      Contents:   OPTIONAL response code
-                  human-readable text
-
-      The NO response indicates an operational error message from the
-      server.  When tagged, it indicates unsuccessful completion of the
-      associated command.  The untagged form indicates a warning; the
-      command can still complete successfully.  The human-readable text
-      describes the condition.
-
-
-
-Crispin                     Standards Track                    [Page 51]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-   Example:    C: A222 COPY 1:2 owatagusiam
-               S: * NO Disk is 98% full, please delete unnecessary data
-               S: A222 OK COPY completed
-               C: A223 COPY 3:200 blurdybloop
-               S: * NO Disk is 98% full, please delete unnecessary data
-               S: * NO Disk is 99% full, please delete unnecessary data
-               S: A223 NO COPY failed: disk is full
-
-7.1.3.  BAD Response
-
-   Contents:   OPTIONAL response code
-               human-readable text
-
-      The BAD response indicates an error message from the server.  When
-      tagged, it reports a protocol-level error in the client's command;
-      the tag indicates the command that caused the error.  The untagged
-      form indicates a protocol-level error for which the associated
-      command can not be determined; it can also indicate an internal
-      server failure.  The human-readable text describes the condition.
-
-   Example:    C: ...very long command line...
-               S: * BAD Command line too long
-               C: ...empty line...
-               S: * BAD Empty command line
-               C: A443 EXPUNGE
-               S: * BAD Disk crash, attempting salvage to a new disk!
-               S: * OK Salvage successful, no data lost
-               S: A443 OK Expunge completed
-
-7.1.4.  PREAUTH Response
-
-   Contents:   OPTIONAL response code
-               human-readable text
-
-      The PREAUTH response is always untagged, and is one of three
-      possible greetings at connection startup.  It indicates that the
-      connection has already been authenticated by external means and
-      thus no LOGIN command is needed.
-
-   Example:    S: * PREAUTH IMAP4rev1 server logged in as Smith
-
-7.1.5.  BYE Response
-
-   Contents:   OPTIONAL response code
-               human-readable text
-
-
-
-
-
-
-Crispin                     Standards Track                    [Page 52]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-      The BYE response is always untagged, and indicates that the server
-      is about to close the connection.  The human-readable text MAY be
-      displayed to the user in a status report by the client.  The BYE
-      response is sent under one of four conditions:
-
-         1) as part of a normal logout sequence.  The server will close
-            the connection after sending the tagged OK response to the
-            LOGOUT command.
-
-         2) as a panic shutdown announcement.  The server closes the
-            connection immediately.
-
-         3) as an announcement of an inactivity autologout.  The server
-            closes the connection immediately.
-
-         4) as one of three possible greetings at connection startup,
-            indicating that the server is not willing to accept a
-            connection from this client.  The server closes the
-            connection immediately.
-
-      The difference between a BYE that occurs as part of a normal
-      LOGOUT sequence (the first case) and a BYE that occurs because of
-      a failure (the other three cases) is that the connection closes
-      immediately in the failure case.
-
-   Example:    S: * BYE Autologout; idle for too long
-
-7.2.    Server Responses - Server and Mailbox Status
-
-   These responses are always untagged.  This is how server and mailbox
-   status data are transmitted from the server to the client.  Many of
-   these responses typically result from a command with the same name.
-
-7.2.1.  CAPABILITY Response
-
-   Contents:   capability listing
-
-      The CAPABILITY response occurs as a result of a CAPABILITY
-      command.  The capability listing contains a space-separated
-      listing of capability names that the server supports.  The
-      capability listing MUST include the atom "IMAP4rev1".
-
-      A capability name which begins with "AUTH=" indicates that the
-      server supports that particular authentication mechanism.
-
-
-
-
-
-
-
-Crispin                     Standards Track                    [Page 53]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-      Other capability names indicate that the server supports an
-      extension, revision, or amendment to the IMAP4rev1 protocol.
-      Server responses MUST conform to this document until the client
-      issues a command that uses the associated capability.
-
-      Capability names MUST either begin with "X" or be standard or
-      standards-track IMAP4rev1 extensions, revisions, or amendments
-      registered with IANA.  A server MUST NOT offer unregistered or
-      non-standard capability names, unless such names are prefixed with
-      an "X".
-
-      Client implementations SHOULD NOT require any capability name
-      other than "IMAP4rev1", and MUST ignore any unknown capability
-      names.
-
-   Example:    S: * CAPABILITY IMAP4rev1 AUTH=KERBEROS_V4 XPIG-LATIN
-
-7.2.2.  LIST Response
-
-   Contents:   name attributes
-               hierarchy delimiter
-               name
-
-      The LIST response occurs as a result of a LIST command.  It
-      returns a single name that matches the LIST specification.  There
-      can be multiple LIST responses for a single LIST command.
-
-      Four name attributes are defined:
-
-      \Noinferiors   It is not possible for any child levels of
-                     hierarchy to exist under this name; no child levels
-                     exist now and none can be created in the future.
-
-      \Noselect      It is not possible to use this name as a selectable
-                     mailbox.
-
-      \Marked        The mailbox has been marked "interesting" by the
-                     server; the mailbox probably contains messages that
-                     have been added since the last time the mailbox was
-                     selected.
-
-      \Unmarked      The mailbox does not contain any additional
-                     messages since the last time the mailbox was
-                     selected.
-
-      If it is not feasible for the server to determine whether the
-      mailbox is "interesting" or not, or if the name is a \Noselect
-      name, the server SHOULD NOT send either \Marked or \Unmarked.
-
-
-
-Crispin                     Standards Track                    [Page 54]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-      The hierarchy delimiter is a character used to delimit levels of
-      hierarchy in a mailbox name.  A client can use it to create child
-      mailboxes, and to search higher or lower levels of naming
-      hierarchy.  All children of a top-level hierarchy node MUST use
-      the same separator character.  A NIL hierarchy delimiter means
-      that no hierarchy exists; the name is a "flat" name.
-
-      The name represents an unambiguous left-to-right hierarchy, and
-      MUST be valid for use as a reference in LIST and LSUB commands.
-      Unless \Noselect is indicated, the name MUST also be valid as an
-            argument for commands, such as SELECT, that accept mailbox
-      names.
-
-   Example:    S: * LIST (\Noselect) "/" ~/Mail/foo
-
-7.2.3.  LSUB Response
-
-   Contents:   name attributes
-               hierarchy delimiter
-               name
-
-      The LSUB response occurs as a result of an LSUB command.  It
-      returns a single name that matches the LSUB specification.  There
-      can be multiple LSUB responses for a single LSUB command.  The
-      data is identical in format to the LIST response.
-
-   Example:    S: * LSUB () "." #news.comp.mail.misc
-
-7.2.4   STATUS Response
-
-   Contents:   name
-               status parenthesized list
-
-      The STATUS response occurs as a result of an STATUS command.  It
-      returns the mailbox name that matches the STATUS specification and
-      the requested mailbox status information.
-
-   Example:    S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292)
-
-7.2.5.  SEARCH Response
-
-   Contents:   zero or more numbers
-
-
-
-
-
-
-
-
-
-Crispin                     Standards Track                    [Page 55]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-      The SEARCH response occurs as a result of a SEARCH or UID SEARCH
-      command.  The number(s) refer to those messages that match the
-      search criteria.  For SEARCH, these are message sequence numbers;
-      for UID SEARCH, these are unique identifiers.  Each number is
-      delimited by a space.
-
-   Example:    S: * SEARCH 2 3 6
-
-7.2.6.  FLAGS Response
-
-   Contents:   flag parenthesized list
-
-      The FLAGS response occurs as a result of a SELECT or EXAMINE
-      command.  The flag parenthesized list identifies the flags (at a
-      minimum, the system-defined flags) that are applicable for this
-      mailbox.  Flags other than the system flags can also exist,
-      depending on server implementation.
-
-      The update from the FLAGS response MUST be recorded by the client.
-
-   Example:    S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
-
-7.3.    Server Responses - Mailbox Size
-
-   These responses are always untagged.  This is how changes in the size
-   of the mailbox are trasnmitted from the server to the client.
-   Immediately following the "*" token is a number that represents a
-   message count.
-
-7.3.1.  EXISTS Response
-
-   Contents:   none
-
-      The EXISTS response reports the number of messages in the mailbox.
-      This response occurs as a result of a SELECT or EXAMINE command,
-      and if the size of the mailbox changes (e.g. new mail).
-
-      The update from the EXISTS response MUST be recorded by the
-      client.
-
-   Example:    S: * 23 EXISTS
-
-
-
-
-
-
-
-
-
-
-Crispin                     Standards Track                    [Page 56]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-7.3.2.  RECENT Response
-
-      Contents:   none
-
-      The RECENT response reports the number of messages with the
-      \Recent flag set.  This response occurs as a result of a SELECT or
-      EXAMINE command, and if the size of the mailbox changes (e.g. new
-      mail).
-
-         Note: It is not guaranteed that the message sequence numbers of
-         recent messages will be a contiguous range of the highest n
-         messages in the mailbox (where n is the value reported by the
-         RECENT response).  Examples of situations in which this is not
-         the case are: multiple clients having the same mailbox open
-         (the first session to be notified will see it as recent, others
-         will probably see it as non-recent), and when the mailbox is
-         re-ordered by a non-IMAP agent.
-
-         The only reliable way to identify recent messages is to look at
-         message flags to see which have the \Recent flag set, or to do
-         a SEARCH RECENT.
-
-         The update from the RECENT response MUST be recorded by the
-         client.
-
-   Example:    S: * 5 RECENT
-
-7.4.    Server Responses - Message Status
-
-   These responses are always untagged.  This is how message data are
-   transmitted from the server to the client, often as a result of a
-   command with the same name.  Immediately following the "*" token is a
-   number that represents a message sequence number.
-
-7.4.1.  EXPUNGE Response
-
-   Contents:   none
-
-      The EXPUNGE response reports that the specified message sequence
-      number has been permanently removed from the mailbox.  The message
-      sequence number for each successive message in the mailbox is
-      immediately decremented by 1, and this decrement is reflected in
-      message sequence numbers in subsequent responses (including other
-      untagged EXPUNGE responses).
-
-      As a result of the immediate decrement rule, message sequence
-      numbers that appear in a set of successive EXPUNGE responses
-      depend upon whether the messages are removed starting from lower
-
-
-
-Crispin                     Standards Track                    [Page 57]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-      numbers to higher numbers, or from higher numbers to lower
-      numbers.  For example, if the last 5 messages in a 9-message
-      mailbox are expunged; a "lower to higher" server will send five
-      untagged EXPUNGE responses for message sequence number 5, whereas
-      a "higher to lower server" will send successive untagged EXPUNGE
-      responses for message sequence numbers 9, 8, 7, 6, and 5.
-
-      An EXPUNGE response MUST NOT be sent when no command is in
-      progress; nor while responding to a FETCH, STORE, or SEARCH
-      command.  This rule is necessary to prevent a loss of
-      synchronization of message sequence numbers between client and
-      server.
-
-      The update from the EXPUNGE response MUST be recorded by the
-      client.
-
-   Example:    S: * 44 EXPUNGE
-
-7.4.2.  FETCH Response
-
-   Contents:   message data
-
-      The FETCH response returns data about a message to the client.
-      The data are pairs of data item names and their values in
-      parentheses.  This response occurs as the result of a FETCH or
-      STORE command, as well as by unilateral server decision (e.g. flag
-      updates).
-
-      The current data items are:
-
-      BODY           A form of BODYSTRUCTURE without extension data.
-
-      BODY[<section>]<<origin_octet>>
-                     A string expressing the body contents of the
-                     specified section.  The string SHOULD be
-                     interpreted by the client according to the content
-                     transfer encoding, body type, and subtype.
-
-                     If the origin octet is specified, this string is a
-                     substring of the entire body contents, starting at
-                     that origin octet.  This means that BODY[]<0> MAY
-                     be truncated, but BODY[] is NEVER truncated.
-
-                     8-bit textual data is permitted if a [CHARSET]
-                     identifier is part of the body parameter
-                     parenthesized list for this section.  Note that
-                     headers (part specifiers HEADER or MIME, or the
-                     header portion of a MESSAGE/RFC822 part), MUST be
-
-
-
-Crispin                     Standards Track                    [Page 58]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-                     7-bit; 8-bit characters are not permitted in
-                     headers.  Note also that the blank line at the end
-                     of the header is always included in header data.
-
-                     Non-textual data such as binary data MUST be
-                     transfer encoded into a textual form such as BASE64
-                     prior to being sent to the client.  To derive the
-                     original binary data, the client MUST decode the
-                     transfer encoded string.
-
-      BODYSTRUCTURE  A parenthesized list that describes the [MIME-IMB]
-                     body structure of a message.  This is computed by
-                     the server by parsing the [MIME-IMB] header fields,
-                     defaulting various fields as necessary.
-
-                     For example, a simple text message of 48 lines and
-                     2279 octets can have a body structure of: ("TEXT"
-                     "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 2279
-                     48)
-
-                     Multiple parts are indicated by parenthesis
-                     nesting.  Instead of a body type as the first
-                     element of the parenthesized list there is a nested
-                     body.  The second element of the parenthesized list
-                     is the multipart subtype (mixed, digest, parallel,
-                     alternative, etc.).
-
-                     For example, a two part message consisting of a
-                     text and a BASE645-encoded text attachment can have
-                     a body structure of: (("TEXT" "PLAIN" ("CHARSET"
-                     "US-ASCII") NIL NIL "7BIT" 1152 23)("TEXT" "PLAIN"
-                     ("CHARSET" "US-ASCII" "NAME" "cc.diff")
-                     "<960723163407.20117h@cac.washington.edu>"
-                     "Compiler diff" "BASE64" 4554 73) "MIXED"))
-
-                     Extension data follows the multipart subtype.
-                     Extension data is never returned with the BODY
-                     fetch, but can be returned with a BODYSTRUCTURE
-                     fetch.  Extension data, if present, MUST be in the
-                     defined order.
-
-                     The extension data of a multipart body part are in
-                     the following order:
-
-                     body parameter parenthesized list
-                        A parenthesized list of attribute/value pairs
-                        [e.g. ("foo" "bar" "baz" "rag") where "bar" is
-                        the value of "foo" and "rag" is the value of
-
-
-
-Crispin                     Standards Track                    [Page 59]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-                        "baz"] as defined in [MIME-IMB].
-
-                     body disposition
-                        A parenthesized list, consisting of a
-                        disposition type string followed by a
-                        parenthesized list of disposition
-                        attribute/value pairs.  The disposition type and
-                        attribute names will be defined in a future
-                        standards-track revision to [DISPOSITION].
-
-                     body language
-                        A string or parenthesized list giving the body
-                        language value as defined in [LANGUAGE-TAGS].
-
-                     Any following extension data are not yet defined in
-                     this version of the protocol.  Such extension data
-                     can consist of zero or more NILs, strings, numbers,
-                     or potentially nested parenthesized lists of such
-                     data.  Client implementations that do a
-                     BODYSTRUCTURE fetch MUST be prepared to accept such
-                     extension data.  Server implementations MUST NOT
-                     send such extension data until it has been defined
-                     by a revision of this protocol.
-
-                     The basic fields of a non-multipart body part are
-                     in the following order:
-
-                     body type
-                        A string giving the content media type name as
-                        defined in [MIME-IMB].
-
-                     body subtype
-                        A string giving the content subtype name as
-                        defined in [MIME-IMB].
-
-                     body parameter parenthesized list
-                        A parenthesized list of attribute/value pairs
-                        [e.g. ("foo" "bar" "baz" "rag") where "bar" is
-                        the value of "foo" and "rag" is the value of
-                        "baz"] as defined in [MIME-IMB].
-
-                     body id
-                        A string giving the content id as defined in
-                        [MIME-IMB].
-
-                     body description
-                        A string giving the content description as
-                        defined in [MIME-IMB].
-
-
-
-Crispin                     Standards Track                    [Page 60]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-                     body encoding
-                        A string giving the content transfer encoding as
-                        defined in [MIME-IMB].
-
-                     body size
-                        A number giving the size of the body in octets.
-                        Note that this size is the size in its transfer
-                        encoding and not the resulting size after any
-                        decoding.
-
-                     A body type of type MESSAGE and subtype RFC822
-                     contains, immediately after the basic fields, the
-                     envelope structure, body structure, and size in
-                     text lines of the encapsulated message.
-
-                     A body type of type TEXT contains, immediately
-                     after the basic fields, the size of the body in
-                     text lines.  Note that this size is the size in its
-                     content transfer encoding and not the resulting
-                     size after any decoding.
-
-                     Extension data follows the basic fields and the
-                     type-specific fields listed above.  Extension data
-                     is never returned with the BODY fetch, but can be
-                     returned with a BODYSTRUCTURE fetch.  Extension
-                     data, if present, MUST be in the defined order.
-
-                     The extension data of a non-multipart body part are
-                     in the following order:
-
-                     body MD5
-                        A string giving the body MD5 value as defined in
-                        [MD5].
-
-                     body disposition
-                        A parenthesized list with the same content and
-                        function as the body disposition for a multipart
-                        body part.
-
-                     body language
-                        A string or parenthesized list giving the body
-                        language value as defined in [LANGUAGE-TAGS].
-
-                     Any following extension data are not yet defined in
-                     this version of the protocol, and would be as
-                     described above under multipart extension data.
-
-
-
-
-
-Crispin                     Standards Track                    [Page 61]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-      ENVELOPE       A parenthesized list that describes the envelope
-                     structure of a message.  This is computed by the
-                     server by parsing the [RFC-822] header into the
-                     component parts, defaulting various fields as
-                     necessary.
-
-                     The fields of the envelope structure are in the
-                     following order: date, subject, from, sender,
-                     reply-to, to, cc, bcc, in-reply-to, and message-id.
-                     The date, subject, in-reply-to, and message-id
-                     fields are strings.  The from, sender, reply-to,
-                     to, cc, and bcc fields are parenthesized lists of
-                     address structures.
-
-                     An address structure is a parenthesized list that
-                     describes an electronic mail address.  The fields
-                     of an address structure are in the following order:
-                     personal name, [SMTP] at-domain-list (source
-                     route), mailbox name, and host name.
-
-                     [RFC-822] group syntax is indicated by a special
-                     form of address structure in which the host name
-                     field is NIL.  If the mailbox name field is also
-                     NIL, this is an end of group marker (semi-colon in
-                     RFC 822 syntax).  If the mailbox name field is
-                     non-NIL, this is a start of group marker, and the
-                     mailbox name field holds the group name phrase.
-
-                     Any field of an envelope or address structure that
-                     is not applicable is presented as NIL.  Note that
-                     the server MUST default the reply-to and sender
-                     fields from the from field; a client is not
-                     expected to know to do this.
-
-      FLAGS          A parenthesized list of flags that are set for this
-                     message.
-
-      INTERNALDATE   A string representing the internal date of the
-                     message.
-
-      RFC822         Equivalent to BODY[].
-
-      RFC822.HEADER  Equivalent to BODY.PEEK[HEADER].
-
-      RFC822.SIZE    A number expressing the [RFC-822] size of the
-                     message.
-
-      RFC822.TEXT    Equivalent to BODY[TEXT].
-
-
-
-Crispin                     Standards Track                    [Page 62]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-      UID            A number expressing the unique identifier of the
-                     message.
-
-
-   Example:    S: * 23 FETCH (FLAGS (\Seen) RFC822.SIZE 44827)
-
-7.5.    Server Responses - Command Continuation Request
-
-   The command continuation request response is indicated by a "+" token
-   instead of a tag.  This form of response indicates that the server is
-   ready to accept the continuation of a command from the client.  The
-   remainder of this response is a line of text.
-
-   This response is used in the AUTHORIZATION command to transmit server
-   data to the client, and request additional client data.  This
-   response is also used if an argument to any command is a literal.
-
-   The client is not permitted to send the octets of the literal unless
-   the server indicates that it expects it.  This permits the server to
-   process commands and reject errors on a line-by-line basis.  The
-   remainder of the command, including the CRLF that terminates a
-   command, follows the octets of the literal.  If there are any
-   additional command arguments the literal octets are followed by a
-   space and those arguments.
-
-   Example:    C: A001 LOGIN {11}
-               S: + Ready for additional command text
-               C: FRED FOOBAR {7}
-               S: + Ready for additional command text
-               C: fat man
-               S: A001 OK LOGIN completed
-               C: A044 BLURDYBLOOP {102856}
-               S: A044 BAD No such command as "BLURDYBLOOP"
-
-8.      Sample IMAP4rev1 connection
-
-   The following is a transcript of an IMAP4rev1 connection.  A long
-   line in this sample is broken for editorial clarity.
-
-S:   * OK IMAP4rev1 Service Ready
-C:   a001 login mrc secret
-S:   a001 OK LOGIN completed
-C:   a002 select inbox
-S:   * 18 EXISTS
-S:   * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
-S:   * 2 RECENT
-S:   * OK [UNSEEN 17] Message 17 is the first unseen message
-S:   * OK [UIDVALIDITY 3857529045] UIDs valid
-
-
-
-Crispin                     Standards Track                    [Page 63]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-S:   a002 OK [READ-WRITE] SELECT completed
-C:   a003 fetch 12 full
-S:   * 12 FETCH (FLAGS (\Seen) INTERNALDATE "17-Jul-1996 02:44:25 -0700"
-      RFC822.SIZE 4286 ENVELOPE ("Wed, 17 Jul 1996 02:23:25 -0700 (PDT)"
-      "IMAP4rev1 WG mtg summary and minutes"
-      (("Terry Gray" NIL "gray" "cac.washington.edu"))
-      (("Terry Gray" NIL "gray" "cac.washington.edu"))
-      (("Terry Gray" NIL "gray" "cac.washington.edu"))
-      ((NIL NIL "imap" "cac.washington.edu"))
-      ((NIL NIL "minutes" "CNRI.Reston.VA.US")
-      ("John Klensin" NIL "KLENSIN" "INFOODS.MIT.EDU")) NIL NIL
-      "<B27397-0100000@cac.washington.edu>")
-       BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 3028 92))
-S:    a003 OK FETCH completed
-C:    a004 fetch 12 body[header]
-S:    * 12 FETCH (BODY[HEADER] {350}
-S:    Date: Wed, 17 Jul 1996 02:23:25 -0700 (PDT)
-S:    From: Terry Gray <gray@cac.washington.edu>
-S:    Subject: IMAP4rev1 WG mtg summary and minutes
-S:    To: imap@cac.washington.edu
-S:    cc: minutes@CNRI.Reston.VA.US, John Klensin <KLENSIN@INFOODS.MIT.EDU>
-S:    Message-Id: <B27397-0100000@cac.washington.edu>
-S:    MIME-Version: 1.0
-S:    Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
-S:
-S:    )
-S:    a004 OK FETCH completed
-C:    a005 store 12 +flags \deleted
-S:    * 12 FETCH (FLAGS (\Seen \Deleted))
-S:    a005 OK +FLAGS completed
-C:    a006 logout
-S:    * BYE IMAP4rev1 server terminating connection
-S:    a006 OK LOGOUT completed
-
-9.      Formal Syntax
-
-   The following syntax specification uses the augmented Backus-Naur
-   Form (BNF) notation as specified in [RFC-822] with one exception; the
-   delimiter used with the "#" construct is a single space (SPACE) and
-   not one or more commas.
-
-   In the case of alternative or optional rules in which a later rule
-   overlaps an earlier rule, the rule which is listed earlier MUST take
-   priority.  For example, "\Seen" when parsed as a flag is the \Seen
-   flag name and not a flag_extension, even though "\Seen" could be
-   parsed as a flag_extension.  Some, but not all, instances of this
-   rule are noted below.
-
-
-
-
-Crispin                     Standards Track                    [Page 64]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-   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.
-
-address         ::= "(" addr_name SPACE addr_adl SPACE addr_mailbox
-                    SPACE addr_host ")"
-
-addr_adl        ::= nstring
-                    ;; Holds route from [RFC-822] route-addr if
-                    ;; non-NIL
-
-addr_host       ::= nstring
-                    ;; NIL indicates [RFC-822] group syntax.
-                    ;; Otherwise, holds [RFC-822] domain name
-
-addr_mailbox    ::= nstring
-                    ;; NIL indicates end of [RFC-822] group; if
-                    ;; non-NIL and addr_host is NIL, holds
-                    ;; [RFC-822] group name.
-                    ;; Otherwise, holds [RFC-822] local-part
-
-addr_name       ::= nstring
-                    ;; Holds phrase from [RFC-822] mailbox if
-                    ;; non-NIL
-
-alpha           ::= "A" / "B" / "C" / "D" / "E" / "F" / "G" / "H" /
-                    "I" / "J" / "K" / "L" / "M" / "N" / "O" / "P" /
-                    "Q" / "R" / "S" / "T" / "U" / "V" / "W" / "X" /
-                    "Y" / "Z" /
-                    "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" /
-                    "i" / "j" / "k" / "l" / "m" / "n" / "o" / "p" /
-                    "q" / "r" / "s" / "t" / "u" / "v" / "w" / "x" /
-                    "y" / "z"
-                    ;; Case-sensitive
-
-append          ::= "APPEND" SPACE mailbox [SPACE flag_list]
-                    [SPACE date_time] SPACE literal
-
-astring         ::= atom / string
-
-atom            ::= 1*ATOM_CHAR
-
-ATOM_CHAR       ::= <any CHAR except atom_specials>
-
-atom_specials   ::= "(" / ")" / "{" / SPACE / CTL / list_wildcards /
-                    quoted_specials
-
-
-
-
-Crispin                     Standards Track                    [Page 65]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-authenticate    ::= "AUTHENTICATE" SPACE auth_type *(CRLF base64)
-
-auth_type       ::= atom
-                    ;; Defined by [IMAP-AUTH]
-
-base64          ::= *(4base64_char) [base64_terminal]
-
-base64_char     ::= alpha / digit / "+" / "/"
-
-base64_terminal ::= (2base64_char "==") / (3base64_char "=")
-
-body            ::= "(" body_type_1part / body_type_mpart ")"
-
-body_extension  ::= nstring / number / "(" 1#body_extension ")"
-                    ;; Future expansion.  Client implementations
-                    ;; MUST accept body_extension fields.  Server
-                    ;; implementations MUST NOT generate
-                    ;; body_extension fields except as defined by
-                    ;; future standard or standards-track
-                    ;; revisions of this specification.
-
-body_ext_1part  ::= body_fld_md5 [SPACE body_fld_dsp
-                    [SPACE body_fld_lang
-                    [SPACE 1#body_extension]]]
-                    ;; MUST NOT be returned on non-extensible
-                    ;; "BODY" fetch
-
-body_ext_mpart  ::= body_fld_param
-                    [SPACE body_fld_dsp SPACE body_fld_lang
-                    [SPACE 1#body_extension]]
-                    ;; MUST NOT be returned on non-extensible
-                    ;; "BODY" fetch
-
-body_fields     ::= body_fld_param SPACE body_fld_id SPACE
-                    body_fld_desc SPACE body_fld_enc SPACE
-                    body_fld_octets
-
-body_fld_desc   ::= nstring
-
-body_fld_dsp    ::= "(" string SPACE body_fld_param ")" / nil
-
-body_fld_enc    ::= (<"> ("7BIT" / "8BIT" / "BINARY" / "BASE64"/
-                    "QUOTED-PRINTABLE") <">) / string
-
-body_fld_id     ::= nstring
-
-body_fld_lang   ::= nstring / "(" 1#string ")"
-
-
-
-
-Crispin                     Standards Track                    [Page 66]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-body_fld_lines  ::= number
-
-body_fld_md5    ::= nstring
-
-body_fld_octets ::= number
-
-body_fld_param  ::= "(" 1#(string SPACE string) ")" / nil
-
-body_type_1part ::= (body_type_basic / body_type_msg / body_type_text)
-                    [SPACE body_ext_1part]
-
-body_type_basic ::= media_basic SPACE body_fields
-                    ;; MESSAGE subtype MUST NOT be "RFC822"
-
-body_type_mpart ::= 1*body SPACE media_subtype
-                    [SPACE body_ext_mpart]
-
-body_type_msg   ::= media_message SPACE body_fields SPACE envelope
-                    SPACE body SPACE body_fld_lines
-
-body_type_text  ::= media_text SPACE body_fields SPACE body_fld_lines
-
-capability      ::= "AUTH=" auth_type / atom
-                    ;; New capabilities MUST begin with "X" or be
-                    ;; registered with IANA as standard or
-                    ;; standards-track
-
-capability_data ::= "CAPABILITY" SPACE [1#capability SPACE] "IMAP4rev1"
-                    [SPACE 1#capability]
-                    ;; IMAP4rev1 servers which offer RFC 1730
-                    ;; compatibility MUST list "IMAP4" as the first
-                    ;; capability.
-
-CHAR            ::= <any 7-bit US-ASCII character except NUL,
-                     0x01 - 0x7f>
-
-CHAR8           ::= <any 8-bit octet except NUL, 0x01 - 0xff>
-
-command         ::= tag SPACE (command_any / command_auth /
-                    command_nonauth / command_select) CRLF
-                    ;; Modal based on state
-
-command_any     ::= "CAPABILITY" / "LOGOUT" / "NOOP" / x_command
-                    ;; Valid in all states
-
-command_auth    ::= append / create / delete / examine / list / lsub /
-                    rename / select / status / subscribe / unsubscribe
-                    ;; Valid only in Authenticated or Selected state
-
-
-
-Crispin                     Standards Track                    [Page 67]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-command_nonauth ::= login / authenticate
-                    ;; Valid only when in Non-Authenticated state
-
-command_select  ::= "CHECK" / "CLOSE" / "EXPUNGE" /
-                     copy / fetch / store / uid / search
-                    ;; Valid only when in Selected state
-
-continue_req    ::= "+" SPACE (resp_text / base64)
-
-copy            ::= "COPY" SPACE set SPACE mailbox
-
-CR              ::= <ASCII CR, carriage return, 0x0D>
-
-create          ::= "CREATE" SPACE mailbox
-                    ;; Use of INBOX gives a NO error
-
-CRLF            ::= CR LF
-
-CTL             ::= <any ASCII control character and DEL,
-                        0x00 - 0x1f, 0x7f>
-
-date            ::= date_text / <"> date_text <">
-
-date_day        ::= 1*2digit
-                    ;; Day of month
-
-date_day_fixed  ::= (SPACE digit) / 2digit
-                    ;; Fixed-format version of date_day
-
-date_month      ::= "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" /
-                    "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec"
-
-date_text       ::= date_day "-" date_month "-" date_year
-
-date_year       ::= 4digit
-
-date_time       ::= <"> date_day_fixed "-" date_month "-" date_year
-                    SPACE time SPACE zone <">
-
-delete          ::= "DELETE" SPACE mailbox
-                    ;; Use of INBOX gives a NO error
-
-digit           ::= "0" / digit_nz
-
-digit_nz        ::= "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" /
-                    "9"
-
-
-
-
-
-Crispin                     Standards Track                    [Page 68]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-envelope        ::= "(" env_date SPACE env_subject SPACE env_from
-                    SPACE env_sender SPACE env_reply_to SPACE env_to
-                    SPACE env_cc SPACE env_bcc SPACE env_in_reply_to
-                    SPACE env_message_id ")"
-
-env_bcc         ::= "(" 1*address ")" / nil
-
-env_cc          ::= "(" 1*address ")" / nil
-
-env_date        ::= nstring
-
-env_from        ::= "(" 1*address ")" / nil
-
-env_in_reply_to ::= nstring
-
-env_message_id  ::= nstring
-
-env_reply_to    ::= "(" 1*address ")" / nil
-
-env_sender      ::= "(" 1*address ")" / nil
-
-env_subject     ::= nstring
-
-env_to          ::= "(" 1*address ")" / nil
-
-examine         ::= "EXAMINE" SPACE mailbox
-
-fetch           ::= "FETCH" SPACE set SPACE ("ALL" / "FULL" /
-                    "FAST" / fetch_att / "(" 1#fetch_att ")")
-
-fetch_att       ::= "ENVELOPE" / "FLAGS" / "INTERNALDATE" /
-                    "RFC822" [".HEADER" / ".SIZE" / ".TEXT"] /
-                    "BODY" ["STRUCTURE"] / "UID" /
-                    "BODY" [".PEEK"] section
-                    ["<" number "." nz_number ">"]
-
-flag            ::= "\Answered" / "\Flagged" / "\Deleted" /
-                    "\Seen" / "\Draft" / flag_keyword / flag_extension
-
-flag_extension  ::= "\" atom
-                    ;; Future expansion.  Client implementations
-                    ;; MUST accept flag_extension flags.  Server
-                    ;; implementations MUST NOT generate
-                    ;; flag_extension flags except as defined by
-                    ;; future standard or standards-track
-                    ;; revisions of this specification.
-
-flag_keyword    ::= atom
-
-
-
-Crispin                     Standards Track                    [Page 69]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-flag_list       ::= "(" #flag ")"
-
-greeting        ::= "*" SPACE (resp_cond_auth / resp_cond_bye) CRLF
-
-header_fld_name ::= astring
-
-header_list     ::= "(" 1#header_fld_name ")"
-
-LF              ::= <ASCII LF, line feed, 0x0A>
-
-list            ::= "LIST" SPACE mailbox SPACE list_mailbox
-
-list_mailbox    ::= 1*(ATOM_CHAR / list_wildcards) / string
-
-list_wildcards  ::= "%" / "*"
-
-literal         ::= "{" number "}" CRLF *CHAR8
-                    ;; Number represents the number of CHAR8 octets
-
-login           ::= "LOGIN" SPACE userid SPACE password
-
-lsub            ::= "LSUB" SPACE mailbox SPACE list_mailbox
-
-mailbox         ::= "INBOX" / astring
-                    ;; INBOX is case-insensitive.  All case variants of
-                    ;; INBOX (e.g. "iNbOx") MUST be interpreted as INBOX
-                    ;; not as an astring.  Refer to section 5.1 for
-                    ;; further semantic details of mailbox names.
-
-mailbox_data    ::=  "FLAGS" SPACE flag_list /
-                     "LIST" SPACE mailbox_list /
-                     "LSUB" SPACE mailbox_list /
-                     "MAILBOX" SPACE text /
-                     "SEARCH" [SPACE 1#nz_number] /
-                     "STATUS" SPACE mailbox SPACE
-                     "(" #<status_att number ")" /
-                     number SPACE "EXISTS" / number SPACE "RECENT"
-
-mailbox_list    ::= "(" #("\Marked" / "\Noinferiors" /
-                    "\Noselect" / "\Unmarked" / flag_extension) ")"
-                    SPACE (<"> QUOTED_CHAR <"> / nil) SPACE mailbox
-
-media_basic     ::= (<"> ("APPLICATION" / "AUDIO" / "IMAGE" /
-                    "MESSAGE" / "VIDEO") <">) / string)
-                    SPACE media_subtype
-                    ;; Defined in [MIME-IMT]
-
-media_message   ::= <"> "MESSAGE" <"> SPACE <"> "RFC822" <">
-
-
-
-Crispin                     Standards Track                    [Page 70]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-                    ;; Defined in [MIME-IMT]
-
-media_subtype   ::= string
-                    ;; Defined in [MIME-IMT]
-
-media_text      ::= <"> "TEXT" <"> SPACE media_subtype
-                    ;; Defined in [MIME-IMT]
-
-message_data    ::= nz_number SPACE ("EXPUNGE" /
-                                    ("FETCH" SPACE msg_att))
-
-msg_att         ::= "(" 1#("ENVELOPE" SPACE envelope /
-                    "FLAGS" SPACE "(" #(flag / "\Recent") ")" /
-                    "INTERNALDATE" SPACE date_time /
-                    "RFC822" [".HEADER" / ".TEXT"] SPACE nstring /
-                    "RFC822.SIZE" SPACE number /
-                    "BODY" ["STRUCTURE"] SPACE body /
-                    "BODY" section ["<" number ">"] SPACE nstring /
-                    "UID" SPACE uniqueid) ")"
-
-nil             ::= "NIL"
-
-nstring         ::= string / nil
-
-number          ::= 1*digit
-                    ;; Unsigned 32-bit integer
-                    ;; (0 <= n < 4,294,967,296)
-
-nz_number       ::= digit_nz *digit
-                    ;; Non-zero unsigned 32-bit integer
-                    ;; (0 < n < 4,294,967,296)
-
-password        ::= astring
-
-quoted          ::= <"> *QUOTED_CHAR <">
-
-QUOTED_CHAR     ::= <any TEXT_CHAR except quoted_specials> /
-                    "\" quoted_specials
-
-quoted_specials ::= <"> / "\"
-
-rename          ::= "RENAME" SPACE mailbox SPACE mailbox
-                    ;; Use of INBOX as a destination gives a NO error
-
-response        ::= *(continue_req / response_data) response_done
-
-response_data   ::= "*" SPACE (resp_cond_state / resp_cond_bye /
-                    mailbox_data / message_data / capability_data)
-
-
-
-Crispin                     Standards Track                    [Page 71]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-                    CRLF
-
-response_done   ::= response_tagged / response_fatal
-
-response_fatal  ::= "*" SPACE resp_cond_bye CRLF
-                    ;; Server closes connection immediately
-
-response_tagged ::= tag SPACE resp_cond_state CRLF
-
-resp_cond_auth  ::= ("OK" / "PREAUTH") SPACE resp_text
-                    ;; Authentication condition
-
-resp_cond_bye   ::= "BYE" SPACE resp_text
-
-resp_cond_state ::= ("OK" / "NO" / "BAD") SPACE resp_text
-                    ;; Status condition
-
-resp_text       ::= ["[" resp_text_code "]" SPACE] (text_mime2 / text)
-                    ;; text SHOULD NOT begin with "[" or "="
-
-resp_text_code  ::= "ALERT" / "PARSE" /
-                    "PERMANENTFLAGS" SPACE "(" #(flag / "\*") ")" /
-                    "READ-ONLY" / "READ-WRITE" / "TRYCREATE" /
-                    "UIDVALIDITY" SPACE nz_number /
-                    "UNSEEN" SPACE nz_number /
-                    atom [SPACE 1*<any TEXT_CHAR except "]">]
-
-search          ::= "SEARCH" SPACE ["CHARSET" SPACE astring SPACE]
-                    1#search_key
-                    ;; [CHARSET] MUST be registered with IANA
-
-search_key      ::= "ALL" / "ANSWERED" / "BCC" SPACE astring /
-                    "BEFORE" SPACE date / "BODY" SPACE astring /
-                    "CC" SPACE astring / "DELETED" / "FLAGGED" /
-                    "FROM" SPACE astring /
-                    "KEYWORD" SPACE flag_keyword / "NEW" / "OLD" /
-                    "ON" SPACE date / "RECENT" / "SEEN" /
-                    "SINCE" SPACE date / "SUBJECT" SPACE astring /
-                    "TEXT" SPACE astring / "TO" SPACE astring /
-                    "UNANSWERED" / "UNDELETED" / "UNFLAGGED" /
-                    "UNKEYWORD" SPACE flag_keyword / "UNSEEN" /
-                    ;; Above this line were in [IMAP2]
-                    "DRAFT" /
-                    "HEADER" SPACE header_fld_name SPACE astring /
-                    "LARGER" SPACE number / "NOT" SPACE search_key /
-                    "OR" SPACE search_key SPACE search_key /
-                    "SENTBEFORE" SPACE date / "SENTON" SPACE date /
-                    "SENTSINCE" SPACE date / "SMALLER" SPACE number /
-
-
-
-Crispin                     Standards Track                    [Page 72]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-                    "UID" SPACE set / "UNDRAFT" / set /
-                    "(" 1#search_key ")"
-
-section         ::= "[" [section_text / (nz_number *["." nz_number]
-                    ["." (section_text / "MIME")])] "]"
-
-section_text    ::= "HEADER" / "HEADER.FIELDS" [".NOT"]
-                    SPACE header_list / "TEXT"
-
-select          ::= "SELECT" SPACE mailbox
-
-sequence_num    ::= nz_number / "*"
-                    ;; * is the largest number in use.  For message
-                    ;; sequence numbers, it is the number of messages
-                    ;; in the mailbox.  For unique identifiers, it is
-                    ;; the unique identifier of the last message in
-                    ;; the mailbox.
-
-set             ::= sequence_num / (sequence_num ":" sequence_num) /
-                    (set "," set)
-                    ;; Identifies a set of messages.  For message
-                    ;; sequence numbers, these are consecutive
-                    ;; numbers from 1 to the number of messages in
-                    ;; the mailbox
-                    ;; Comma delimits individual numbers, colon
-                    ;; delimits between two numbers inclusive.
-                    ;; Example: 2,4:7,9,12:* is 2,4,5,6,7,9,12,13,
-                    ;; 14,15 for a mailbox with 15 messages.
-
-SPACE           ::= <ASCII SP, space, 0x20>
-
-status          ::= "STATUS" SPACE mailbox SPACE "(" 1#status_att ")"
-
-status_att      ::= "MESSAGES" / "RECENT" / "UIDNEXT" / "UIDVALIDITY" /
-                    "UNSEEN"
-
-store           ::= "STORE" SPACE set SPACE store_att_flags
-
-store_att_flags ::= (["+" / "-"] "FLAGS" [".SILENT"]) SPACE
-                    (flag_list / #flag)
-
-string          ::= quoted / literal
-
-subscribe       ::= "SUBSCRIBE" SPACE mailbox
-
-tag             ::= 1*<any ATOM_CHAR except "+">
-
-text            ::= 1*TEXT_CHAR
-
-
-
-Crispin                     Standards Track                    [Page 73]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-text_mime2       ::= "=?" <charset> "?" <encoding> "?"
-                     <encoded-text> "?="
-                     ;; Syntax defined in [MIME-HDRS]
-
-TEXT_CHAR       ::= <any CHAR except CR and LF>
-
-time            ::= 2digit ":" 2digit ":" 2digit
-                    ;; Hours minutes seconds
-
-uid             ::= "UID" SPACE (copy / fetch / search / store)
-                    ;; Unique identifiers used instead of message
-                    ;; sequence numbers
-
-uniqueid        ::= nz_number
-                    ;; Strictly ascending
-
-unsubscribe     ::= "UNSUBSCRIBE" SPACE mailbox
-
-userid          ::= astring
-
-x_command       ::= "X" atom <experimental command arguments>
-
-zone            ::= ("+" / "-") 4digit
-                    ;; Signed four-digit value of hhmm representing
-                    ;; hours and minutes west of Greenwich (that is,
-                    ;; (the amount that the given time differs from
-                    ;; Universal Time).  Subtracting the timezone
-                    ;; from the given time will give the UT form.
-                    ;; The Universal Time zone is "+0000".
-
-10.     Author's Note
-
-   This document is a revision or rewrite of earlier documents, and
-   supercedes the protocol specification in those documents: RFC 1730,
-   unpublished IMAP2bis.TXT document, RFC 1176, and RFC 1064.
-
-11.     Security Considerations
-
-   IMAP4rev1 protocol transactions, including electronic mail data, are
-   sent in the clear over the network unless privacy protection is
-   negotiated in the AUTHENTICATE command.
-
-   A server error message for an AUTHENTICATE command which fails due to
-   invalid credentials SHOULD NOT detail why the credentials are
-   invalid.
-
-   Use of the LOGIN command sends passwords in the clear.  This can be
-   avoided by using the AUTHENTICATE command instead.
-
-
-
-Crispin                     Standards Track                    [Page 74]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-   A server error message for a failing LOGIN command SHOULD NOT specify
-   that the user name, as opposed to the password, is invalid.
-
-   Additional security considerations are discussed in the section
-   discussing the AUTHENTICATE and LOGIN commands.
-
-12.     Author's Address
-
-   Mark R. Crispin
-   Networks and Distributed Computing
-   University of Washington
-   4545 15th Aveneue NE
-   Seattle, WA  98105-4527
-
-   Phone: (206) 543-5762
-
-   EMail: MRC@CAC.Washington.EDU
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin                     Standards Track                    [Page 75]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-Appendices
-
-A.      References
-
-[ACAP] Myers, J. "ACAP -- Application Configuration Access Protocol",
-Work in Progress.
-
-[CHARSET] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
-RFC 1700, USC/Information Sciences Institute, October 1994.
-
-[DISPOSITION] Troost, R., and Dorner, S., "Communicating Presentation
-Information in Internet Messages: The Content-Disposition Header",
-RFC 1806, June 1995.
-
-[IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanism", RFC 1731.
-Carnegie-Mellon University, December 1994.
-
-[IMAP-COMPAT] Crispin, M., "IMAP4 Compatibility with IMAP2bis", RFC
-2061, University of Washington, November 1996.
-
-[IMAP-DISC] Austein, R., "Synchronization Operations for Disconnected
-IMAP4 Clients", Work in Progress.
-
-[IMAP-HISTORICAL] Crispin, M. "IMAP4 Compatibility with IMAP2 and
-IMAP2bis", RFC 1732, University of Washington, December 1994.
-
-[IMAP-MODEL] Crispin, M., "Distributed Electronic Mail Models in
-IMAP4", RFC 1733, University of Washington, December 1994.
-
-[IMAP-OBSOLETE] Crispin, M., "Internet Message Access Protocol -
-Obsolete Syntax", RFC 2062, University of Washington, November 1996.
-
-[IMAP2] Crispin, M., "Interactive Mail Access Protocol - Version 2",
-RFC 1176, University of Washington, August 1990.
-
-[LANGUAGE-TAGS] Alvestrand, H., "Tags for the Identification of
-Languages", RFC 1766, March 1995.
-
-[MD5] Myers, J., and M. Rose, "The Content-MD5 Header Field", RFC
-1864, October 1995.
-
-[MIME-IMB] Freed, N., and N. Borenstein, "MIME (Multipurpose Internet
-Mail Extensions) Part One: Format of Internet Message Bodies", RFC
-2045, November 1996.
-
-[MIME-IMT] Freed, N., and N. Borenstein, "MIME (Multipurpose
-Internet Mail Extensions) Part Two: Media Types", RFC 2046,
-November 1996.
-
-
-
-Crispin                     Standards Track                    [Page 76]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-[MIME-HDRS] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
-Part Three: Message Header Extensions for Non-ASCII Text", RFC
-2047, November 1996.
-
-[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text
-Messages", STD 11, RFC 822, University of Delaware, August 1982.
-
-[SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10,
-RFC 821, USC/Information Sciences Institute, August 1982.
-
-[UTF-7] Goldsmith, D., and Davis, M., "UTF-7: A Mail-Safe
-Transformation Format of Unicode", RFC 1642, July 1994.
-
-B.      Changes from RFC 1730
-
-1) The STATUS command has been added.
-
-2) Clarify in the formal syntax that the "#" construct can never
-refer to multiple spaces.
-
-3) Obsolete syntax has been moved to a separate document.
-
-4) The PARTIAL command has been obsoleted.
-
-5) The RFC822.HEADER.LINES, RFC822.HEADER.LINES.NOT, RFC822.PEEK, and
-RFC822.TEXT.PEEK fetch attributes have been obsoleted.
-
-6) The "<" origin "." size ">" suffix for BODY text attributes has
-been added.
-
-7) The HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, MIME, and TEXT part
-specifiers have been added.
-
-8) Support for Content-Disposition and Content-Language has been
-added.
-
-9) The restriction on fetching nested MULTIPART parts has been
-removed.
-
-10) Body part number 0 has been obsoleted.
-
-11) Server-supported authenticators are now identified by
-capabilities.
-
-
-
-
-
-
-
-
-Crispin                     Standards Track                    [Page 77]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-12) The capability that identifies this protocol is now called
-"IMAP4rev1".  A server that provides backwards support for RFC 1730
-SHOULD emit the "IMAP4" capability in addition to "IMAP4rev1" in its
-CAPABILITY response.  Because RFC-1730 required "IMAP4" to appear as
-the first capability, it MUST listed first in the response.
-
-13) A description of the mailbox name namespace convention has been
-added.
-
-14) A description of the international mailbox name convention has
-been added.
-
-15) The UID-NEXT and UID-VALIDITY status items are now called UIDNEXT
-and UIDVALIDITY.  This is a change from the IMAP STATUS
-Work in Progress and not from RFC-1730
-
-16) Add a clarification that a null mailbox name argument to the LIST
-command returns an untagged LIST response with the hierarchy
-delimiter and root of the reference argument.
-
-17) Define terms such as "MUST", "SHOULD", and "MUST NOT".
-
-18) Add a section which defines message attributes and more
-thoroughly details the semantics of message sequence numbers, UIDs,
-and flags.
-
-19) Add a clarification detailing the circumstances when a client may
-send multiple commands without waiting for a response, and the
-circumstances in which ambiguities may result.
-
-20) Add a recommendation on server behavior for DELETE and RENAME
-when inferior hierarchical names of the given name exist.
-
-21) Add a clarification that a mailbox name may not be unilaterally
-unsubscribed by the server, even if that mailbox name no longer
-exists.
-
-22) Add a clarification that LIST should return its results quickly
-without undue delay.
-
-23) Add a clarification that the date_time argument to APPEND sets
-the internal date of the message.
-
-24) Add a clarification on APPEND behavior when the target mailbox is
-the currently selected mailbox.
-
-
-
-
-
-
-Crispin                     Standards Track                    [Page 78]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-25) Add a clarification that external changes to flags should be
-always announced via an untagged FETCH even if the current command is
-a STORE with the ".SILENT" suffix.
-
-26) Add a clarification that COPY appends to the target mailbox.
-
-27) Add the NEWNAME response code.
-
-28) Rewrite the description of the untagged BYE response to clarify
-its semantics.
-
-29) Change the reference for the body MD5 to refer to the proper RFC.
-
-30) Clarify that the formal syntax contains rules which may overlap,
-and that in the event of such an overlap the rule which occurs first
-takes precedence.
-
-31) Correct the definition of body_fld_param.
-
-32) More formal syntax for capability_data.
-
-33) Clarify that any case variant of "INBOX" must be interpreted as
-INBOX.
-
-34) Clarify that the human-readable text in resp_text should not
-begin with "[" or "=".
-
-35) Change MIME references to Draft Standard documents.
-
-36) Clarify \Recent semantics.
-
-37) Additional examples.
-
-C.      Key Word Index
-
-       +FLAGS <flag list> (store command data item) ...............   45
-       +FLAGS.SILENT <flag list> (store command data item) ........   46
-       -FLAGS <flag list> (store command data item) ...............   46
-       -FLAGS.SILENT <flag list> (store command data item) ........   46
-       ALERT (response code) ......................................   50
-       ALL (fetch item) ...........................................   41
-       ALL (search key) ...........................................   38
-       ANSWERED (search key) ......................................   38
-       APPEND (command) ...........................................   34
-       AUTHENTICATE (command) .....................................   20
-       BAD (response) .............................................   52
-       BCC <string> (search key) ..................................   38
-       BEFORE <date> (search key) .................................   39
-
-
-
-Crispin                     Standards Track                    [Page 79]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-       BODY (fetch item) ..........................................   41
-       BODY (fetch result) ........................................   58
-       BODY <string> (search key) .................................   39
-       BODY.PEEK[<section>]<<partial>> (fetch item) ...............   44
-       BODYSTRUCTURE (fetch item) .................................   44
-       BODYSTRUCTURE (fetch result) ...............................   59
-       BODY[<section>]<<origin_octet>> (fetch result) .............   58
-       BODY[<section>]<<partial>> (fetch item) ....................   41
-       BYE (response) .............................................   52
-       Body Structure (message attribute) .........................   11
-       CAPABILITY (command) .......................................   18
-       CAPABILITY (response) ......................................   53
-       CC <string> (search key) ...................................   39
-       CHECK (command) ............................................   36
-       CLOSE (command) ............................................   36
-       COPY (command) .............................................   46
-       CREATE (command) ...........................................   25
-       DELETE (command) ...........................................   26
-       DELETED (search key) .......................................   39
-       DRAFT (search key) .........................................   39
-       ENVELOPE (fetch item) ......................................   44
-       ENVELOPE (fetch result) ....................................   62
-       EXAMINE (command) ..........................................   24
-       EXISTS (response) ..........................................   56
-       EXPUNGE (command) ..........................................   37
-       EXPUNGE (response) .........................................   57
-       Envelope Structure (message attribute) .....................   11
-       FAST (fetch item) ..........................................   44
-       FETCH (command) ............................................   41
-       FETCH (response) ...........................................   58
-       FLAGGED (search key) .......................................   39
-       FLAGS (fetch item) .........................................   44
-       FLAGS (fetch result) .......................................   62
-       FLAGS (response) ...........................................   56
-       FLAGS <flag list> (store command data item) ................   45
-       FLAGS.SILENT <flag list> (store command data item) .........   45
-       FROM <string> (search key) .................................   39
-       FULL (fetch item) ..........................................   44
-       Flags (message attribute) ..................................    9
-       HEADER (part specifier) ....................................   41
-       HEADER <field-name> <string> (search key) ..................   39
-       HEADER.FIELDS <header_list> (part specifier) ...............   41
-       HEADER.FIELDS.NOT <header_list> (part specifier) ...........   41
-       INTERNALDATE (fetch item) ..................................   44
-       INTERNALDATE (fetch result) ................................   62
-       Internal Date (message attribute) ..........................   10
-       KEYWORD <flag> (search key) ................................   39
-       Keyword (type of flag) .....................................   10
-
-
-
-Crispin                     Standards Track                    [Page 80]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-       LARGER <n> (search key) ....................................   39
-       LIST (command) .............................................   30
-       LIST (response) ............................................   54
-       LOGIN (command) ............................................   22
-       LOGOUT (command) ...........................................   20
-       LSUB (command) .............................................   32
-       LSUB (response) ............................................   55
-       MAY (specification requirement term) .......................    5
-       MESSAGES (status item) .....................................   33
-       MIME (part specifier) ......................................   42
-       MUST (specification requirement term) ......................    4
-       MUST NOT (specification requirement term) ..................    4
-       Message Sequence Number (message attribute) ................    9
-       NEW (search key) ...........................................   39
-       NEWNAME (response code) ....................................   50
-       NO (response) ..............................................   51
-       NOOP (command) .............................................   19
-       NOT <search-key> (search key) ..............................   39
-       OK (response) ..............................................   51
-       OLD (search key) ...........................................   39
-       ON <date> (search key) .....................................   39
-       OPTIONAL (specification requirement term) ..................    5
-       OR <search-key1> <search-key2> (search key) ................   39
-       PARSE (response code) ......................................   50
-       PERMANENTFLAGS (response code) .............................   50
-       PREAUTH (response) .........................................   52
-       Permanent Flag (class of flag) .............................   10
-       READ-ONLY (response code) ..................................   50
-       READ-WRITE (response code) .................................   50
-       RECENT (response) ..........................................   57
-       RECENT (search key) ........................................   39
-       RECENT (status item) .......................................   33
-       RENAME (command) ...........................................   27
-       REQUIRED (specification requirement term) ..................    4
-       RFC822 (fetch item) ........................................   44
-       RFC822 (fetch result) ......................................   63
-       RFC822.HEADER (fetch item) .................................   44
-       RFC822.HEADER (fetch result) ...............................   62
-       RFC822.SIZE (fetch item) ...................................   44
-       RFC822.SIZE (fetch result) .................................   62
-       RFC822.TEXT (fetch item) ...................................   44
-       RFC822.TEXT (fetch result) .................................   62
-       SEARCH (command) ...........................................   37
-       SEARCH (response) ..........................................   55
-       SEEN (search key) ..........................................   40
-       SELECT (command) ...........................................   23
-       SENTBEFORE <date> (search key) .............................   40
-       SENTON <date> (search key) .................................   40
-
-
-
-Crispin                     Standards Track                    [Page 81]
-
-RFC 2060                       IMAP4rev1                   December 1996
-
-
-       SENTSINCE <date> (search key) ..............................   40
-       SHOULD (specification requirement term) ....................    5
-       SHOULD NOT (specification requirement term) ................    5
-       SINCE <date> (search key) ..................................   40
-       SMALLER <n> (search key) ...................................   40
-       STATUS (command) ...........................................   33
-       STATUS (response) ..........................................   55
-       STORE (command) ............................................   45
-       SUBJECT <string> (search key) ..............................   40
-       SUBSCRIBE (command) ........................................   29
-       Session Flag (class of flag) ...............................   10
-       System Flag (type of flag) .................................    9
-       TEXT (part specifier) ......................................   42
-       TEXT <string> (search key) .................................   40
-       TO <string> (search key) ...................................   40
-       TRYCREATE (response code) ..................................   51
-       UID (command) ..............................................   47
-       UID (fetch item) ...........................................   44
-       UID (fetch result) .........................................   63
-       UID <message set> (search key) .............................   40
-       UIDNEXT (status item) ......................................   33
-       UIDVALIDITY (response code) ................................   51
-       UIDVALIDITY (status item) ..................................   34
-       UNANSWERED (search key) ....................................   40
-       UNDELETED (search key) .....................................   40
-       UNDRAFT (search key) .......................................   40
-       UNFLAGGED (search key) .....................................   40
-       UNKEYWORD <flag> (search key) ..............................   40
-       UNSEEN (response code) .....................................   51
-       UNSEEN (search key) ........................................   40
-       UNSEEN (status item) .......................................   34
-       UNSUBSCRIBE (command) ......................................   30
-       Unique Identifier (UID) (message attribute) ................    7
-       X<atom> (command) ..........................................   48
-       [RFC-822] Size (message attribute) .........................   11
-       \Answered (system flag) ....................................    9
-       \Deleted (system flag) .....................................    9
-       \Draft (system flag) .......................................    9
-       \Flagged (system flag) .....................................    9
-       \Marked (mailbox name attribute) ...........................   54
-       \Noinferiors (mailbox name attribute) ......................   54
-       \Noselect (mailbox name attribute) .........................   54
-       \Recent (system flag) ......................................   10
-       \Seen (system flag) ........................................    9
-       \Unmarked (mailbox name attribute) .........................   54
-
-
-
-
-
-
-Crispin                     Standards Track                    [Page 82]
-
diff --git a/RFC/rfc2061.txt b/RFC/rfc2061.txt
deleted file mode 100644
index 7cb02bb2..00000000
--- a/RFC/rfc2061.txt
+++ /dev/null
@@ -1,171 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         M. Crispin
-Request for Comments: 2061                      University of Washington
-Category: Informational                                    December 1996
-
-
-                   IMAP4 COMPATIBILITY WITH IMAP2BIS
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  This memo
-   does not specify an Internet standard of any kind.  Distribution of
-   this memo is unlimited.
-
-Introduction
-
-   The Internet Message Access Protocol (IMAP) has been through several
-   revisions and variants in its 10-year history.  Many of these are
-   either extinct or extremely rare; in particular, several undocumented
-   variants and the variants described in RFC 1064, RFC 1176, and RFC
-   1203 fall into this category.
-
-   One variant, IMAP2bis, is at the time of this writing very common and
-   has been widely distributed with the Pine mailer.  Unfortunately,
-   there is no definite document describing IMAP2bis.  This document is
-   intended to be read along with RFC 1176 and the most recent IMAP4
-   specification (RFC 2060) to assist implementors in creating an IMAP4
-   implementation to interoperate with implementations that conform to
-   earlier specifications.  Nothing in this document is required by the
-   IMAP4 specification; implementors must decide for themselves whether
-   they want their implementation to fail if it encounters old software.
-
-   At the time of this writing, IMAP4 has been updated from the version
-   described in RFC 1730.  An implementor who wishes to interoperate
-   with both RFC 1730 and RFC 2060 should refer to both documents.
-
-   This information is not complete; it reflects current knowledge of
-   server and client implementations as well as "folklore" acquired in
-   the evolution of the protocol.  It is NOT a description of how to
-   interoperate with all variants of IMAP, but rather with the old
-   variant that is most likely to be encountered.  For detailed
-   information on interoperating with other old variants, refer to RFC
-   1732.
-
-IMAP4 client interoperability with IMAP2bis servers
-
-   A quick way to check whether a server implementation supports the
-   IMAP4 specification is to try the CAPABILITY command.  An OK response
-   will indicate which variant(s) of IMAP4 are supported by the server.
-
-
-
-Crispin                      Informational                      [Page 1]
-
-RFC 2061                  IMAP4 Compatibility              December 1996
-
-
-   If the client does not find any of its known variant in the response,
-   it should treat the server as IMAP2bis.  A BAD response indicates an
-   IMAP2bis or older server.
-
-   Most IMAP4 facilities are in IMAP2bis.  The following exceptions
-   exist:
-
-   CAPABILITY command
-            The absense of this command indicates IMAP2bis (or older).
-
-   AUTHENTICATE command.
-            Use the LOGIN command.
-
-   LSUB, SUBSCRIBE, and UNSUBSCRIBE commands
-            No direct functional equivalent.  IMAP2bis had a concept
-            called "bboards" which is not in IMAP4.  RFC 1176 supported
-            these with the BBOARD and FIND BBOARDS commands.  IMAP2bis
-            augmented these with the FIND ALL.BBOARDS, SUBSCRIBE BBOARD,
-            and UNSUBSCRIBE BBOARD commands.  It is recommended that
-            none of these commands be implemented in new software,
-            including servers that support old clients.
-
-   LIST command
-            Use the command FIND ALL.MAILBOXES, which has a similar syn-
-            tax and response to the FIND MAILBOXES command described in
-            RFC 1176.  The FIND MAILBOXES command is unlikely to produce
-            useful information.
-
-   * in a sequence
-            Use the number of messages in the mailbox from the EXISTS
-            unsolicited response.
-
-   SEARCH extensions (character set, additional criteria)
-            Reformulate the search request using only the RFC 1176 syn-
-            tax.  This may entail doing multiple searches to achieve the
-            desired results.
-
-   BODYSTRUCTURE fetch data item
-            Use the non-extensible BODY data item.
-
-   body sections HEADER, TEXT, MIME, HEADER.FIELDS, HEADER.FIELDS.NOT
-            Use body section numbers only.
-
-   BODY.PEEK[section]
-            Use BODY[section] and manually clear the \Seen flag as
-            necessary.
-
-
-
-
-
-Crispin                      Informational                      [Page 2]
-
-RFC 2061                  IMAP4 Compatibility              December 1996
-
-
-   FLAGS.SILENT, +FLAGS.SILENT, and -FLAGS.SILENT store data items
-            Use the corresponding non-SILENT versions and ignore the
-            untagged FETCH responses which come back.
-
-   UID fetch data item and the UID commands
-            No functional equivalent.
-
-   CLOSE command
-            No functional equivalent.
-
-
-   In IMAP2bis, the TRYCREATE special information token is sent as a
-   separate unsolicited OK response instead of inside the NO response.
-
-   IMAP2bis is ambiguous about whether or not flags or internal dates
-   are preserved on COPY.  It is impossible to know what behavior is
-   supported by the server.
-
-IMAP4 server interoperability with IMAP2bis clients
-
-   The only interoperability problem between an IMAP4 server and a
-   well-written IMAP2bis client is an incompatibility with the use of
-   "\" in quoted strings.  This is best avoided by using literals
-   instead of quoted strings if "\" or <"> is embedded in the string.
-
-Security Considerations
-
-   Security issues are not discussed in this memo.
-
-Author's Address
-
-   Mark R. Crispin
-   Networks and Distributed Computing
-   University of Washington
-   4545 15th Aveneue NE
-   Seattle, WA  98105-4527
-
-   Phone: (206) 543-5762
-   EMail: MRC@CAC.Washington.EDU
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin                      Informational                      [Page 3]
-
diff --git a/RFC/rfc2062.txt b/RFC/rfc2062.txt
deleted file mode 100644
index 865d1dad..00000000
--- a/RFC/rfc2062.txt
+++ /dev/null
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         M. Crispin
-Request for Comments: 2062                      University of Washington
-Category: Informational                                    December 1996
-
-
-           Internet Message Access Protocol - Obsolete Syntax
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  This memo
-   does not specify an Internet standard of any kind.  Distribution of
-   this memo is unlimited.
-
-Abstract
-
-   This document describes obsolete syntax which may be encountered by
-   IMAP4 implementations which deal with older versions of the Internet
-   Mail Access Protocol.  IMAP4 implementations MAY implement this
-   syntax in order to maximize interoperability with older
-   implementations.
-
-   This document repeats information from earlier documents, most
-   notably RFC 1176 and RFC 1730.
-
-Obsolete Commands and Fetch Data Items
-
-   The following commands are OBSOLETE.  It is NOT required to support
-   any of these commands or fetch data items in new server
-   implementations.  These commands are documented here for the benefit
-   of implementors who may wish to support them for compatibility with
-   old client implementations.
-
-   The section headings of these commands are intended to correspond
-   with where they would be located in the main document if they were
-   not obsoleted.
-
-6.3.OBS.1.      FIND ALL.MAILBOXES Command
-
-   Arguments:  mailbox name with possible wildcards
-
-   Data:       untagged responses: MAILBOX
-
-   Result:     OK - find completed
-               NO - find failure: can't list that name
-               BAD - command unknown or arguments invalid
-
-
-
-
-
-
-Crispin                      Informational                      [Page 1]
-
-RFC 2062                     IMAP4 Obsolete                December 1996
-
-
-      The FIND ALL.MAILBOXES command returns a subset of names from the
-      complete set of all names available to the user.  It returns zero
-      or more untagged MAILBOX replies.  The mailbox argument to FIND
-      ALL.MAILBOXES is similar to that for LIST with an empty reference,
-      except that the characters "%" and "?" match a single character.
-
-   Example:    C: A002 FIND ALL.MAILBOXES *
-               S: * MAILBOX blurdybloop
-               S: * MAILBOX INBOX
-               S: A002 OK FIND ALL.MAILBOXES completed
-
-6.3.OBS.2.      FIND MAILBOXES Command
-
-   Arguments:  mailbox name with possible wildcards
-
-   Data:       untagged responses: MAILBOX
-
-   Result:     OK - find completed
-               NO - find failure: can't list that name
-               BAD - command unknown or arguments invalid
-
-      The FIND MAILBOXES command returns a subset of names from the set
-      of names that the user has declared as being "active" or
-      "subscribed".  It returns zero or more untagged MAILBOX replies.
-      The mailbox argument to FIND MAILBOXES is similar to that for LSUB
-      with an empty reference, except that the characters "%" and "?"
-      match a single character.
-
-   Example:    C: A002 FIND MAILBOXES *
-               S: * MAILBOX blurdybloop
-               S: * MAILBOX INBOX
-               S: A002 OK FIND MAILBOXES completed
-
-6.3.OBS.3.      SUBSCRIBE MAILBOX Command
-
-   Arguments:  mailbox name
-
-   Data:       no specific data for this command
-
-   Result:     OK - subscribe completed
-               NO - subscribe failure: can't subscribe to that name
-               BAD - command unknown or arguments invalid
-
-      The SUBSCRIBE MAILBOX command is identical in effect to the
-      SUBSCRIBE command.  A server which implements this command must be
-      able to distinguish between a SUBSCRIBE MAILBOX command and a
-      SUBSCRIBE command with a mailbox name argument of "MAILBOX".
-
-
-
-
-Crispin                      Informational                      [Page 2]
-
-RFC 2062                     IMAP4 Obsolete                December 1996
-
-
-   Example:    C: A002 SUBSCRIBE MAILBOX #news.comp.mail.mime
-               S: A002 OK SUBSCRIBE MAILBOX to #news.comp.mail.mime
-               completed
-               C: A003 SUBSCRIBE MAILBOX
-               S: A003 OK SUBSCRIBE to MAILBOX completed
-
-
-6.3.OBS.4.      UNSUBSCRIBE MAILBOX Command
-
-   Arguments:  mailbox name
-
-   Data:       no specific data for this command
-
-   Result:     OK - unsubscribe completed
-               NO - unsubscribe failure: can't unsubscribe that name
-               BAD - command unknown or arguments invalid
-
-      The UNSUBSCRIBE MAILBOX command is identical in effect to the
-      UNSUBSCRIBE command.  A server which implements this command must
-      be able to distinguish between a UNSUBSCRIBE MAILBOX command and
-      an UNSUBSCRIBE command with a mailbox name argument of "MAILBOX".
-
-   Example:    C: A002 UNSUBSCRIBE MAILBOX #news.comp.mail.mime
-               S: A002 OK UNSUBSCRIBE MAILBOX from #news.comp.mail.mime
-               completed
-               C: A003 UNSUBSCRIBE MAILBOX
-               S: A003 OK UNSUBSCRIBE from MAILBOX completed
-
-6.4.OBS.1       PARTIAL Command
-
-   Arguments:  message sequence number
-               message data item name
-               position of first octet
-               number of octets
-
-   Data:       untagged responses: FETCH
-
-   Result:     OK - partial completed
-               NO - partial error: can't fetch that data
-               BAD - command unknown or arguments invalid
-
-      The PARTIAL command is equivalent to the associated FETCH command,
-      with the added functionality that only the specified number of
-      octets, beginning at the specified starting octet, are returned.
-      Only a single message can be fetched at a time.  The first octet
-      of a message, and hence the minimum for the starting octet, is
-      octet 1.
-
-
-
-
-Crispin                      Informational                      [Page 3]
-
-RFC 2062                     IMAP4 Obsolete                December 1996
-
-
-      The following FETCH items are valid data for PARTIAL: RFC822,
-      RFC822.HEADER, RFC822.TEXT, BODY[<section>], as well as any .PEEK
-      forms of these.
-
-      Any partial fetch that attempts to read beyond the end of the text
-      is truncated as appropriate.  If the starting octet is beyond the
-      end of the text, an empty string is returned.
-
-      The data are returned with the FETCH response.  There is no
-      indication of the range of the partial data in this response.  It
-      is not possible to stream multiple PARTIAL commands of the same
-      data item without processing and synchronizing at each step, since
-      streamed commands may be executed out of order.
-
-      There is no requirement that partial fetches follow any sequence.
-      For example, if a partial fetch of octets 1 through 10000 breaks
-      in an awkward place for BASE64 decoding, it is permitted to
-      continue with a partial fetch of 9987 through 19987, etc.
-
-      The handling of the \Seen flag is the same as in the associated
-      FETCH command.
-
-   Example:    C: A005 PARTIAL 4 RFC822 1 1024
-               S: * 1 FETCH (RFC822 {1024}
-               S: Return-Path: <gray@cac.washington.edu>
-               S: ...
-               S: .........  FLAGS (\Seen))
-               S: A005 OK PARTIAL completed
-
-6.4.5.OBS.1     Obsolete FETCH Data Items
-
-   The following FETCH data items are obsolete:
-
-      BODY[<...>0]   A body part number of 0 is the [RFC-822] header of
-                     the message.  BODY[0] is functionally equivalent to
-                     BODY[HEADER], differing in the syntax of the
-                     resulting untagged FETCH data (BODY[0] is
-                     returned).
-
-      RFC822.HEADER.LINES <header_list>
-                     Functionally equivalent to BODY.PEEK[HEADER.LINES
-                     <header_list>], differing in the syntax of the
-                     resulting untagged FETCH data (RFC822.HEADER is
-                     returned).
-
-
-
-
-
-
-
-Crispin                      Informational                      [Page 4]
-
-RFC 2062                     IMAP4 Obsolete                December 1996
-
-
-      RFC822.HEADER.LINES.NOT <header_list>
-                     Functionally equivalent to
-                     BODY.PEEK[HEADER.LINES.NOT <header_list>],
-                     differing in the syntax of the resulting untagged
-                     FETCH data (RFC822.HEADER is returned).
-
-      RFC822.PEEK    Functionally equivalent to BODY.PEEK[], except for
-                     the syntax of the resulting untagged FETCH data
-                     (RFC822 is returned).
-
-      RFC822.TEXT.PEEK
-                     Functionally equivalent to BODY.PEEK[TEXT], except
-                     for the syntax of the resulting untagged FETCH data
-                     (RFC822.TEXT is returned).
-
-Obsolete Responses
-
-   The following responses are OBSOLETE.  Except as noted below, these
-   responses MUST NOT be transmitted by new server implementations.
-   Client implementations SHOULD accept these responses.
-
-   The section headings of these responses are intended to correspond
-   with where they would be located in the main document if they were
-   not obsoleted.
-
-7.2.OBS.1.      MAILBOX Response
-
-   Data:       name
-
-      The MAILBOX response MUST NOT be transmitted by server
-      implementations except in response to the obsolete FIND MAILBOXES
-      and FIND ALL.MAILBOXES commands.  Client implementations that do
-      not use these commands MAY ignore this response.  It is documented
-      here for the benefit of implementors who may wish to support it
-      for compatibility with old client implementations.
-
-      This response occurs as a result of the FIND MAILBOXES and FIND
-      ALL.MAILBOXES commands.  It returns a single name that matches the
-      FIND specification.  There are no attributes or hierarchy
-      delimiter.
-
-   Example:    S: * MAILBOX blurdybloop
-
-
-
-
-
-
-
-
-
-Crispin                      Informational                      [Page 5]
-
-RFC 2062                     IMAP4 Obsolete                December 1996
-
-
-7.3.OBS.1.      COPY Response
-
-   Data:       none
-
-      The COPY response MUST NOT be transmitted by new server
-      implementations.  Client implementations MUST ignore the COPY
-      response.  It is documented here for the benefit of client
-      implementors who may encounter this response from old server
-      implementations.
-
-      In some experimental versions of this protocol, this response was
-      returned in response to a COPY command to indicate on a
-      per-message basis that the message was copied successfully.
-
-   Example:    S: * 44 COPY
-
-7.3.OBS.2.      STORE Response
-
-   Data:       message data
-
-      The STORE response MUST NOT be transmitted by new server
-      implementations.  Client implementations MUST treat the STORE
-      response as equivalent to the FETCH response.  It is documented
-      here for the benefit of client implementors who may encounter this
-      response from old server implementations.
-
-      In some experimental versions of this protocol, this response was
-      returned instead of FETCH in response to a STORE command to report
-      the new value of the flags.
-
-   Example:    S: * 69 STORE (FLAGS (\Deleted))
-
-Formal Syntax of Obsolete Commands and Responses
-
-   Each obsolete syntax rule that is suffixed with "_old" is added to
-   the corresponding name in the formal syntax.  For example,
-   command_auth_old adds the FIND command to command_auth.
-
-   command_auth_old ::= find
-
-   command_select_old
-                   ::= partial
-
-   date_year_old   ::= 2digit
-                       ;; (year - 1900)
-
-   date_time_old   ::= <"> date_day_fixed "-" date_month "-" date_year
-                       SPACE time "-" zone_name <">
-
-
-
-Crispin                      Informational                      [Page 6]
-
-RFC 2062                     IMAP4 Obsolete                December 1996
-
-
-   find            ::= "FIND" SPACE ["ALL."] "MAILBOXES" SPACE
-                       list_mailbox
-
-   fetch_att_old   ::= "RFC822.HEADER.LINES" [".NOT"] SPACE header_list /
-                       fetch_text_old
-
-   fetch_text_old  ::= "BODY" [".PEEK"] section_old /
-                       "RFC822" [".HEADER" / ".TEXT" [".PEEK"]]
-
-   msg_data_old    ::= "COPY" / ("STORE" SPACE msg_att)
-
-   partial         ::= "PARTIAL" SPACE nz_number SPACE fetch_text_old SPACE
-                       number SPACE number
-
-   section_old     ::= "[" (number ["." number]) "]"
-
-   subscribe_old   ::= "SUBSCRIBE" SPACE "MAILBOX" SPACE mailbox
-
-   unsubscribe_old ::= "UNSUBSCRIBE" SPACE "MAILBOX" SPACE mailbox
-
-   zone_name       ::= "UT" / "GMT" / "Z" /                ;; +0000
-                       "AST" / "EDT" /                     ;; -0400
-                       "EST" / "CDT" /                     ;; -0500
-                       "CST" / "MDT" /                     ;; -0600
-                       "MST" / "PDT" /                     ;; -0700
-                       "PST" / "YDT" /                     ;; -0800
-                       "YST" / "HDT" /                     ;; -0900
-                       "HST" / "BDT" /                     ;; -1000
-                       "BST" /                             ;; -1100
-                       "A" / "B" / "C" / "D" / "E" / "F" / ;; +1 to +6
-                       "G" / "H" / "I" / "K" / "L" / "M" / ;; +7 to +12
-                       "N" / "O" / "P" / "Q" / "R" / "S" / ;; -1 to -6
-                       "T" / "U" / "V" / "W" / "X" / "Y"   ;; -7 to -12
-
-Security Considerations
-
-   Security issues are not discussed in this memo.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin                      Informational                      [Page 7]
-
-RFC 2062                     IMAP4 Obsolete                December 1996
-
-
-Author's Address
-
-   Mark R. Crispin
-   Networks and Distributed Computing
-   University of Washington
-   4545 15th Aveneue NE
-   Seattle, WA  98105-4527
-
-   Phone: (206) 543-5762
-   EMail: MRC@CAC.Washington.EDU
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin                      Informational                      [Page 8]
-
diff --git a/RFC/rfc2177.txt b/RFC/rfc2177.txt
deleted file mode 100644
index ef28fad3..00000000
--- a/RFC/rfc2177.txt
+++ /dev/null
@@ -1,227 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                           B. Leiba
-Request for Comments: 2177               IBM T.J. Watson Research Center
-Category: Standards Track                                      June 1997
-
-
-                           IMAP4 IDLE command
-
-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
-
-   The Internet Message Access Protocol [IMAP4] requires a client to
-   poll the server for changes to the selected mailbox (new mail,
-   deletions).  It's often more desirable to have the server transmit
-   updates to the client in real time.  This allows a user to see new
-   mail immediately.  It also helps some real-time applications based on
-   IMAP, which might otherwise need to poll extremely often (such as
-   every few seconds).  (While the spec actually does allow a server to
-   push EXISTS responses aysynchronously, a client can't expect this
-   behaviour and must poll.)
-
-   This document specifies the syntax of an IDLE command, which will
-   allow a client to tell the server that it's ready to accept such
-   real-time updates.
-
-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 described in RFC 2060
-   [IMAP4].
-
-3.   Specification
-
-   IDLE Command
-
-   Arguments:  none
-
-   Responses:  continuation data will be requested; the client sends
-               the continuation data "DONE" to end the command
-
-
-
-Leiba                       Standards Track                     [Page 1]
-
-RFC 2177                   IMAP4 IDLE command                  June 1997
-
-
-
-   Result:     OK - IDLE completed after client sent "DONE"
-               NO - failure: the server will not allow the IDLE
-                    command at this time
-              BAD - command unknown or arguments invalid
-
-   The IDLE command may be used with any IMAP4 server implementation
-   that returns "IDLE" as one of the supported capabilities to the
-   CAPABILITY command.  If the server does not advertise the IDLE
-   capability, the client MUST NOT use the IDLE command and must poll
-   for mailbox updates.  In particular, the client MUST continue to be
-   able to accept unsolicited untagged responses to ANY command, as
-   specified in the base IMAP specification.
-
-   The IDLE command is sent from the client to the server when the
-   client is ready to accept unsolicited mailbox update messages.  The
-   server requests a response to the IDLE command using the continuation
-   ("+") response.  The IDLE command remains active until the client
-   responds to the continuation, and as long as an IDLE command is
-   active, the server is now free to send untagged EXISTS, EXPUNGE, and
-   other messages at any time.
-
-   The IDLE command is terminated by the receipt of a "DONE"
-   continuation from the client; such response satisfies the server's
-   continuation request.  At that point, the server MAY send any
-   remaining queued untagged responses and then MUST immediately send
-   the tagged response to the IDLE command and prepare to process other
-   commands. As in the base specification, the processing of any new
-   command may cause the sending of unsolicited untagged responses,
-   subject to the ambiguity limitations.  The client MUST NOT send a
-   command while the server is waiting for the DONE, since the server
-   will not be able to distinguish a command from a continuation.
-
-   The server MAY consider a client inactive if it has an IDLE command
-   running, and if such a server has an inactivity timeout it MAY log
-   the client off implicitly at the end of its timeout period.  Because
-   of that, clients using IDLE are advised to terminate the IDLE and
-   re-issue it at least every 29 minutes to avoid being logged off.
-   This still allows a client to receive immediate mailbox updates even
-   though it need only "poll" at half hour intervals.
-
-
-
-
-
-
-
-
-
-
-
-Leiba                       Standards Track                     [Page 2]
-
-RFC 2177                   IMAP4 IDLE command                  June 1997
-
-
-   Example:    C: A001 SELECT INBOX
-               S: * FLAGS (Deleted Seen)
-               S: * 3 EXISTS
-               S: * 0 RECENT
-               S: * OK [UIDVALIDITY 1]
-               S: A001 OK SELECT completed
-               C: A002 IDLE
-               S: + idling
-               ...time passes; new mail arrives...
-               S: * 4 EXISTS
-               C: DONE
-               S: A002 OK IDLE terminated
-               ...another client expunges message 2 now...
-               C: A003 FETCH 4 ALL
-               S: * 4 FETCH (...)
-               S: A003 OK FETCH completed
-               C: A004 IDLE
-               S: * 2 EXPUNGE
-               S: * 3 EXISTS
-               S: + idling
-               ...time passes; another client expunges message 3...
-               S: * 3 EXPUNGE
-               S: * 2 EXISTS
-               ...time passes; new mail arrives...
-               S: * 3 EXISTS
-               C: DONE
-               S: A004 OK IDLE terminated
-               C: A005 FETCH 3 ALL
-               S: * 3 FETCH (...)
-               S: A005 OK FETCH completed
-               C: A006 IDLE
-
-4.   Formal Syntax
-
-   The following syntax specification uses the augmented Backus-Naur
-   Form (BNF) notation as specified in [RFC-822] as modified by [IMAP4].
-   Non-terminals referenced but not defined below are as defined by
-   [IMAP4].
-
-   command_auth    ::= append / create / delete / examine / list / lsub /
-                       rename / select / status / subscribe / unsubscribe
-                       / idle
-                       ;; Valid only in Authenticated or Selected state
-
-   idle            ::= "IDLE" CRLF "DONE"
-
-
-
-
-
-
-Leiba                       Standards Track                     [Page 3]
-
-RFC 2177                   IMAP4 IDLE command                  June 1997
-
-
-5.   References
-
-   [IMAP4] Crispin, M., "Internet Message Access Protocol - Version
-   4rev1", RFC 2060, December 1996.
-
-6.   Security Considerations
-
-   There are no known security issues with this extension.
-
-7.   Author's Address
-
-   Barry Leiba
-   IBM T.J. Watson Research Center
-   30 Saw Mill River Road
-   Hawthorne, NY  10532
-
-   Email: leiba@watson.ibm.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Leiba                       Standards Track                     [Page 4]
-
diff --git a/RFC/rfc2195.txt b/RFC/rfc2195.txt
deleted file mode 100644
index 4a2725bf..00000000
--- a/RFC/rfc2195.txt
+++ /dev/null
@@ -1,283 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                       J. Klensin
-Request for Comments: 2195                                    R. Catoe
-Category: Standards Track                                 P. Krumviede
-Obsoletes: 2095                                                    MCI
-                                                        September 1997
-
-
-       IMAP/POP AUTHorize Extension for Simple Challenge/Response
-
-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
-
-   While IMAP4 supports a number of strong authentication mechanisms as
-   described in RFC 1731, it lacks any mechanism that neither passes
-   cleartext, reusable passwords across the network nor requires either
-   a significant security infrastructure or that the mail server update
-   a mail-system-wide user authentication file on each mail access.
-   This specification provides a simple challenge-response
-   authentication protocol that is suitable for use with IMAP4.  Since
-   it utilizes Keyed-MD5 digests and does not require that the secret be
-   stored in the clear on the server, it may also constitute an
-   improvement on APOP for POP3 use as specified in RFC 1734.
-
-1. Introduction
-
-   Existing Proposed Standards specify an AUTHENTICATE mechanism for the
-   IMAP4 protocol [IMAP, IMAP-AUTH] and a parallel AUTH mechanism for
-   the POP3 protocol [POP3-AUTH].  The AUTHENTICATE mechanism is
-   intended to be extensible; the four methods specified in [IMAP-AUTH]
-   are all fairly powerful and require some security infrastructure to
-   support.  The base POP3 specification [POP3] also contains a
-   lightweight challenge-response mechanism called APOP.  APOP is
-   associated with most of the risks associated with such protocols: in
-   particular, it requires that both the client and server machines have
-   access to the shared secret in cleartext form. CRAM offers a method
-   for avoiding such cleartext storage while retaining the algorithmic
-   simplicity of APOP in using only MD5, though in a "keyed" method.
-
-
-
-
-
-
-
-Klensin, Catoe & Krumviede  Standards Track                     [Page 1]
-
-RFC 2195              IMAP/POP AUTHorize Extension        September 1997
-
-
-   At present, IMAP [IMAP] lacks any facility corresponding to APOP.
-   The only alternative to the strong mechanisms identified in [IMAP-
-   AUTH] is a presumably cleartext username and password, supported
-   through the LOGIN command in [IMAP].  This document describes a
-   simple challenge-response mechanism, similar to APOP and PPP CHAP
-   [PPP], that can be used with IMAP (and, in principle, with POP3).
-
-   This mechanism also has the advantage over some possible alternatives
-   of not requiring that the server maintain information about email
-   "logins" on a per-login basis.  While mechanisms that do require such
-   per-login history records may offer enhanced security, protocols such
-   as IMAP, which may have several connections between a given client
-   and server open more or less simultaneous, may make their
-   implementation particularly challenging.
-
-2. Challenge-Response Authentication Mechanism (CRAM)
-
-   The authentication type associated with CRAM is "CRAM-MD5".
-
-   The data encoded in the first ready response contains an
-   presumptively arbitrary string of random digits, a timestamp, and the
-   fully-qualified primary host name of the server.  The syntax of the
-   unencoded form must correspond to that of an RFC 822 'msg-id'
-   [RFC822] as described in [POP3].
-
-   The client makes note of the data and then responds with a string
-   consisting of the user name, a space, and a 'digest'.  The latter is
-   computed by applying the keyed MD5 algorithm from [KEYED-MD5] where
-   the key is a shared secret and the digested text is the timestamp
-   (including angle-brackets).
-
-   This shared secret is a string known only to the client and server.
-   The `digest' parameter itself is a 16-octet value which is sent in
-   hexadecimal format, using lower-case ASCII characters.
-
-   When the server receives this client response, it verifies the digest
-   provided.  If the digest is correct, the server should consider the
-   client authenticated and respond appropriately.
-
-   Keyed MD5 is chosen for this application because of the greater
-   security imparted to authentication of short messages. In addition,
-   the use of the techniques described in [KEYED-MD5] for precomputation
-   of intermediate results make it possible to avoid explicit cleartext
-   storage of the shared secret on the server system by instead storing
-   the intermediate results which are known as "contexts".
-
-
-
-
-
-
-Klensin, Catoe & Krumviede  Standards Track                     [Page 2]
-
-RFC 2195              IMAP/POP AUTHorize Extension        September 1997
-
-
-   CRAM does not support a protection mechanism.
-
-   Example:
-
-   The examples in this document show the use of the CRAM mechanism with
-   the IMAP4 AUTHENTICATE command [IMAP-AUTH].  The base64 encoding of
-   the challenges and responses is part of the IMAP4 AUTHENTICATE
-   command, not part of the CRAM specification itself.
-
-     S: * OK IMAP4 Server
-     C: A0001 AUTHENTICATE CRAM-MD5
-     S: + PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+
-     C: dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw
-     S: A0001 OK CRAM authentication successful
-
-      In this example, the shared secret is the string
-      'tanstaaftanstaaf'.  Hence, the Keyed MD5 digest is produced by
-      calculating
-
-        MD5((tanstaaftanstaaf XOR opad),
-            MD5((tanstaaftanstaaf XOR ipad),
-            <1896.697170952@postoffice.reston.mci.net>))
-
-      where ipad and opad are as defined in the keyed-MD5 Work in
-      Progress [KEYED-MD5] and the string shown in the challenge is the
-      base64 encoding of <1896.697170952@postoffice.reston.mci.net>. The
-      shared secret is null-padded to a length of 64 bytes. If the
-      shared secret is longer than 64 bytes, the MD5 digest of the
-      shared secret is used as a 16 byte input to the keyed MD5
-      calculation.
-
-      This produces a digest value (in hexadecimal) of
-
-           b913a602c7eda7a495b4e6e7334d3890
-
-      The user name is then prepended to it, forming
-
-           tim b913a602c7eda7a495b4e6e7334d3890
-
-      Which is then base64 encoded to meet the requirements of the IMAP4
-      AUTHENTICATE command (or the similar POP3 AUTH command), yielding
-
-           dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw
-
-
-
-
-
-
-
-
-Klensin, Catoe & Krumviede  Standards Track                     [Page 3]
-
-RFC 2195              IMAP/POP AUTHorize Extension        September 1997
-
-
-3. References
-
-   [CHAP]  Lloyd, B., and W. Simpson, "PPP Authentication Protocols",
-       RFC 1334, October 1992.
-
-   [IMAP] Crispin, M., "Internet Message Access Protocol - Version
-       4rev1", RFC 2060, University of Washington, December 1996.
-
-   [IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanisms",
-       RFC 1731, Carnegie Mellon, December 1994.
-
-   [KEYED-MD5] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for
-       Message Authentication", RFC 2104, February 1997.
-
-   [MD5]  Rivest, R., "The MD5 Message Digest Algorithm",
-       RFC 1321, MIT Laboratory for Computer Science, April 1992.
-
-   [POP3] Myers, J., and M. Rose, "Post Office Protocol - Version 3",
-       STD 53, RFC 1939, Carnegie Mellon, May 1996.
-
-   [POP3-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734,
-       Carnegie Mellon, December, 1994.
-
-4. Security Considerations
-
-   It is conjectured that use of the CRAM authentication mechanism
-   provides origin identification and replay protection for a session.
-   Accordingly, a server that implements both a cleartext password
-   command and this authentication type should not allow both methods of
-   access for a given user.
-
-   While the saving, on the server, of "contexts" (see section 2) is
-   marginally better than saving the shared secrets in cleartext as is
-   required by CHAP [CHAP] and APOP [POP3], it is not sufficient to
-   protect the secrets if the server itself is compromised.
-   Consequently, servers that store the secrets or contexts must both be
-   protected to a level appropriate to the potential information value
-   in user mailboxes and identities.
-
-   As the length of the shared secret increases, so does the difficulty
-   of deriving it.
-
-   While there are now suggestions in the literature that the use of MD5
-   and keyed MD5 in authentication procedures probably has a limited
-   effective lifetime, the technique is now widely deployed and widely
-   understood.  It is believed that this general understanding may
-   assist with the rapid replacement, by CRAM-MD5, of the current uses
-   of permanent cleartext passwords in IMAP.   This document has been
-
-
-
-Klensin, Catoe & Krumviede  Standards Track                     [Page 4]
-
-RFC 2195              IMAP/POP AUTHorize Extension        September 1997
-
-
-   deliberately written to permit easy upgrading to use SHA (or whatever
-   alternatives emerge) when they are considered to be widely available
-   and adequately safe.
-
-   Even with the use of CRAM, users are still vulnerable to active
-   attacks.  An example of an increasingly common active attack is 'TCP
-   Session Hijacking' as described in CERT Advisory CA-95:01 [CERT95].
-
-   See section 1 above for additional discussion.
-
-5. Acknowledgements
-
-   This memo borrows ideas and some text liberally from [POP3] and
-   [RFC-1731] and thanks are due the authors of those documents.  Ran
-   Atkinson made a number of valuable technical and editorial
-   contributions to the document.
-
-6. Authors' Addresses
-
-   John C. Klensin
-   MCI Telecommunications
-   800 Boylston St, 7th floor
-   Boston, MA 02199
-   USA
-
-   EMail: klensin@mci.net
-   Phone: +1 617 960 1011
-
-   Randy Catoe
-   MCI Telecommunications
-   2100 Reston Parkway
-   Reston, VA 22091
-   USA
-
-   EMail: randy@mci.net
-   Phone: +1 703 715 7366
-
-   Paul Krumviede
-   MCI Telecommunications
-   2100 Reston Parkway
-   Reston, VA 22091
-   USA
-
-   EMail: paul@mci.net
-   Phone: +1 703 715 7251
-
-
-
-
-
-
-Klensin, Catoe & Krumviede  Standards Track                     [Page 5]
-
diff --git a/RFC/rfc2449.txt b/RFC/rfc2449.txt
deleted file mode 100644
index dbea10b2..00000000
--- a/RFC/rfc2449.txt
+++ /dev/null
@@ -1,1067 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         R. Gellens
-Request for Comments: 2449                                      Qualcomm
-Updates: 1939                                                  C. Newman
-Category: Standards Track                                       Innosoft
-                                                            L. Lundblade
-                                                                Qualcomm
-                                                           November 1998
-
-
-                        POP3 Extension Mechanism
-
-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.
-
-IESG Note
-
-   This extension to the POP3 protocol is to be used by a server to
-   express policy descisions taken by the server administrator.  It is
-   not an endorsement of implementations of further POP3 extensions
-   generally.  It is the general view that the POP3 protocol should stay
-   simple, and for the simple purpose of downloading email from a mail
-   server.  If more complicated operations are needed, the IMAP protocol
-   [RFC 2060] should be used.  The first paragraph of section 7 should
-   be read very carefully.
-
-Table of Contents
-
-    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . .  2
-    2.  Conventions Used in this Document . . . . . . . . . . . . .   3
-    3.  General Command and Response Grammar . . . . . . . . . . . .  3
-    4.  Parameter and Response Lengths  . . . . . . . . . . . . . .   4
-    5.  The CAPA Command . . . . . . . . . . . . . . . . . . . . . .  4
-    6.  Initial Set of Capabilities . . . . . . . . . . . . . . . .   5
-      6.1.  TOP capability . . . . . . . . . . . . . . . . . . . . .  6
-      6.2.  USER capability . . . . . . . . . . . . . . . . . . . .   6
-      6.3.  SASL capability  . . . . . . . . . . . . . . . . . . . .  7
-      6.4.  RESP-CODES capability . . . . . . . . . . . . . . . . .   8
-      6.5.  LOGIN-DELAY capability . . . . . . . . . . . . . . . . .  8
-      6.6.  PIPELINING capability . . . . . . . . . . . . . . . . .   9
-
-
-
-Gellens, et. al.            Standards Track                     [Page 1]
-
-RFC 2449                POP3 Extension Mechanism           November 1998
-
-
-      6.7.  EXPIRE capability  . . . . . . . . . . . . . . . . . . . 10
-      6.8.  UIDL capability . . . . . . . . . . . . . . . . . . . .  13
-      6.9.  IMPLEMENTATION capability  . . . . . . . . . . . . . . . 13
-    7.  Future Extensions to POP3 . . . . . . . . . . . . . . . . .  14
-    8.  Extended POP3 Response Codes . . . . . . . . . . . . . . . . 14
-      8.1.  Initial POP3 response codes . . . . . . . . . . . . . .  15
-        8.1.1.  The LOGIN-DELAY response code  . . . . . . . . . . . 15
-        8.1.2.  The IN-USE response code  . . . . . . . . . . . . .  16
-    9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . 16
-   10.  Security Considerations . . . . . . . . . . . . . . . . . .  17
-   11.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . 17
-   12.  References  . . . . . . . . . . . . . . . . . . . . . . . .  17
-   13.  Authors' Addresses  . . . . . . . . . . . . . . . . . . . .  18
-   14.  Full Copyright Statement . . . . . . . . . . . . . . . . . . 19
-
-1.  Introduction
-
-   The Post Office Protocol version 3 [POP3] is very widely used.
-   However, while it includes some optional commands (and some useful
-   protocol extensions have been published), it lacks a mechanism for
-   advertising support for these extensions or for behavior variations.
-
-   Currently these optional features and extensions can only be detected
-   by probing, if at all.  This is at best inefficient, and possibly
-   worse.  As a result, some clients have manual configuration options
-   for POP3 server capabilities.
-
-   Because one of the most important characteristics of POP3 is its
-   simplicity, it is desirable that extensions be few in number (see
-   section 7).  However, some extensions are necessary (such as ones
-   that provide improved security [POP-AUTH]), while others are very
-   desirable in certain situations.  In addition, a means for
-   discovering server behavior is needed.
-
-   This memo updates RFC 1939 [POP3] to define a mechanism to announce
-   support for optional commands, extensions, and unconditional server
-   behavior.  Included is an initial set of currently deployed
-   capabilities which vary between server implementations, and several
-   new capabilities (SASL, RESP-CODES, LOGIN-DELAY, PIPELINING, EXPIRE
-   and IMPLEMENTATION).  This document also extends POP3 error messages
-   so that machine parsable codes can be provided to the client.  An
-   initial set of response codes is included.  In addition, an [ABNF]
-   specification of POP3 commands and responses is defined.
-
-   Public comments should be sent to the IETF POP3 Extensions mailing
-   list, <ietf-pop3ext@imc.org>.  To subscribe, send a message
-   containing SUBSCRIBE to <ietf-pop3ext-request@imc.org>.
-
-
-
-
-Gellens, et. al.            Standards Track                     [Page 2]
-
-RFC 2449                POP3 Extension Mechanism           November 1998
-
-
-2.  Conventions Used in this Document
-
-   The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT",
-   and "MAY" in this document are to be interpreted as described in "Key
-   words for use in RFCs to Indicate Requirement Levels" [KEYWORDS].
-
-   In examples, "C:" and "S:" indicate lines sent by the client and
-   server respectively.
-
-3.  General Command and Response Grammar
-
-   The general form of POP3 commands and responses is described using
-   [ABNF]:
-
-   POP3 commands:
-
-      command      =  keyword *(SP param) CRLF    ;255 octets maximum
-      keyword      =  3*4VCHAR
-      param        =  1*VCHAR
-
-   POP3 responses:
-
-      response     =  greeting / single-line / capa-resp / multi-line
-      capa-resp    =  single-line *capability "." CRLF
-      capa-tag     =  1*cchar
-      capability   =  capa-tag *(SP param) CRLF   ;512 octets maximum
-      cchar        =  %x21-2D / %x2F-7F
-                          ;printable ASCII, excluding "."
-      dot-stuffed  =  *CHAR CRLF                  ;must be dot-stuffed
-      gchar        =  %x21-3B / %x3D-7F
-                          ;printable ASCII, excluding "<"
-      greeting     =  "+OK" [resp-code] *gchar [timestamp] *gchar CRLF
-                          ;512 octets maximum
-      multi-line   =  single-line *dot-stuffed "." CRLF
-      rchar        =  %x21-2E / %x30-5C / %x5E-7F
-                          ;printable ASCII, excluding "/" and "]"
-      resp-code    =  "[" resp-level *("/" resp-level) "]"
-      resp-level   =  1*rchar
-      schar        =  %x21-5A / %x5C-7F
-                          ;printable ASCII, excluding "["
-      single-line  =  status [SP text] CRLF       ;512 octets maximum
-      status       =  "+OK" / "-ERR"
-      text         =  *schar / resp-code *CHAR
-      timestamp    =  "<" *VCHAR ">"
-                          ;MUST conform to RFC-822 msg-id
-
-
-
-
-
-
-Gellens, et. al.            Standards Track                     [Page 3]
-
-RFC 2449                POP3 Extension Mechanism           November 1998
-
-
-4.  Parameter and Response Lengths
-
-   This specification increases the length restrictions on commands and
-   parameters imposed by RFC 1939.
-
-   The maximum length of a command is increased from 47 characters (4
-   character command, single space, 40 character argument, CRLF) to 255
-   octets, including the terminating CRLF.
-
-   Servers which support the CAPA command MUST support commands up to
-   255 octets.  Servers MUST also support the largest maximum command
-   length specified by any supported capability.
-
-   The maximum length of the first line of a command response (including
-   the initial greeting) is unchanged at 512 octets (including the
-   terminating CRLF).
-
-5.  The CAPA Command
-
-   The POP3 CAPA command returns a list of capabilities supported by the
-   POP3 server.  It is available in both the AUTHORIZATION and
-   TRANSACTION states.
-
-   A capability description MUST document in which states the capability
-   is announced, and in which states the commands are valid.
-
-   Capabilities available in the AUTHORIZATION state MUST be announced
-   in both states.
-
-   If a capability is announced in both states, but the argument might
-   differ after authentication, this possibility MUST be stated in the
-   capability description.
-
-   (These requirements allow a client to issue only one CAPA command if
-   it does not use any TRANSACTION-only capabilities, or any
-   capabilities whose values may differ after authentication.)
-
-   If the authentication step negotiates an integrity protection layer,
-   the client SHOULD reissue the CAPA command after authenticating, to
-   check for active down-negotiation attacks.
-
-   Each capability may enable additional protocol commands, additional
-   parameters and responses for existing commands, or describe an aspect
-   of server behavior.  These details are specified in the description
-   of the capability.
-
-
-
-
-
-
-Gellens, et. al.            Standards Track                     [Page 4]
-
-RFC 2449                POP3 Extension Mechanism           November 1998
-
-
-   Section 3 describes the CAPA response using [ABNF].  When a
-   capability response describes an optional command, the <capa-tag>
-   SHOULD be identical to the command keyword.  CAPA response tags are
-   case-insensitive.
-
-        CAPA
-
-        Arguments:
-            none
-
-        Restrictions:
-            none
-
-        Discussion:
-            An -ERR response indicates the capability command is not
-            implemented and the client will have to probe for
-            capabilities as before.
-
-            An +OK response is followed by a list of capabilities, one
-            per line.  Each capability name MAY be followed by a single
-            space and a space-separated list of parameters.  Each
-            capability line is limited to 512 octets (including the
-            CRLF).  The capability list is terminated by a line
-            containing a termination octet (".") and a CRLF pair.
-
-         Possible Responses:
-             +OK -ERR
-
-         Examples:
-             C: CAPA
-             S: +OK Capability list follows
-             S: TOP
-             S: USER
-             S: SASL CRAM-MD5 KERBEROS_V4
-             S: RESP-CODES
-             S: LOGIN-DELAY 900
-             S: PIPELINING
-             S: EXPIRE 60
-             S: UIDL
-             S: IMPLEMENTATION Shlemazle-Plotz-v302
-             S: .
-
-6.  Initial Set of Capabilities
-
-   This section defines an initial set of POP3 capabilities.  These
-   include the optional POP3 commands, already published POP3
-   extensions, and behavior variations between POP3 servers which can
-   impact clients.
-
-
-
-Gellens, et. al.            Standards Track                     [Page 5]
-
-RFC 2449                POP3 Extension Mechanism           November 1998
-
-
-   Note that there is no APOP capability, even though APOP is an
-   optional command in [POP3].  Clients discover server support of APOP
-   by the presence in the greeting banner of an initial challenge
-   enclosed in angle brackets ("<>").  Therefore, an APOP capability
-   would introduce two ways for a server to announce the same thing.
-
-6.1.  TOP capability
-
-   CAPA tag:
-       TOP
-
-   Arguments:
-       none
-
-   Added commands:
-       TOP
-
-   Standard commands affected:
-       none
-
-   Announced states / possible differences:
-       both / no
-
-   Commands valid in states:
-       TRANSACTION
-
-   Specification reference:
-       [POP3]
-
-   Discussion:
-       The TOP capability indicates the optional TOP command is
-       available.
-
-6.2.  USER capability
-
-   CAPA tag:
-       USER
-
-   Arguments:
-       none
-
-   Added commands:
-       USER PASS
-
-   Standard commands affected:
-       none
-
-
-
-
-
-Gellens, et. al.            Standards Track                     [Page 6]
-
-RFC 2449                POP3 Extension Mechanism           November 1998
-
-
-   Announced states / possible differences:
-       both / no
-
-   Commands valid in states:
-       AUTHENTICATION
-
-   Specification reference:
-       [POP3]
-
-   Discussion:
-       The USER capability indicates that the USER and PASS commands
-       are supported, although they may not be available to all users.
-
-6.3.  SASL capability
-
-   CAPA tag:
-       SASL
-
-   Arguments:
-       Supported SASL mechanisms
-
-   Added commands:
-       AUTH
-
-   Standard commands affected:
-       none
-
-   Announced states / possible differences:
-       both / no
-
-   Commands valid in states:
-       AUTHENTICATION
-
-   Specification reference:
-       [POP-AUTH, SASL]
-
-   Discussion:
-       The POP3 AUTH command [POP-AUTH] permits the use of [SASL]
-       authentication mechanisms with POP3.  The SASL capability
-       indicates that the AUTH command is available and that it supports
-       an optional base64 encoded second argument for an initial client
-       response as described in the SASL specification.  The argument to
-       the SASL capability is a space separated list of SASL mechanisms
-       which are supported.
-
-
-
-
-
-
-
-Gellens, et. al.            Standards Track                     [Page 7]
-
-RFC 2449                POP3 Extension Mechanism           November 1998
-
-
-6.4.  RESP-CODES capability
-
-   CAPA tag:
-       RESP-CODES
-
-   Arguments:
-       none
-
-   Added commands:
-       none
-
-   Standard commands affected:
-       none
-
-   Announced states / possible differences:
-       both / no
-
-   Commands valid in states:
-       n/a
-
-   Specification reference:
-       this document
-
-   Discussion:
-       The RESP-CODES capability indicates that any response text issued
-       by this server which begins with an open square bracket ("[") is
-       an extended response code (see section 8).
-
-6.5.  LOGIN-DELAY capability
-
-   CAPA tag:
-       LOGIN-DELAY
-
-   Arguments:
-       minimum seconds between logins; optionally followed by USER in
-       AUTHENTICATION state.
-
-   Added commands:
-       none
-
-   Standard commands affected:
-       USER PASS APOP AUTH
-
-   Announced states / possible differences:
-       both / yes
-
-   Commands valid in states:
-       n/a
-
-
-
-Gellens, et. al.            Standards Track                     [Page 8]
-
-RFC 2449                POP3 Extension Mechanism           November 1998
-
-
-   Specification reference:
-       this document
-
-   Discussion:
-       POP3 clients often login frequently to check for new mail.
-       Unfortunately, the process of creating a connection,
-       authenticating the user, and opening the user's maildrop can be
-       very resource intensive on the server.  A number of deployed POP3
-       servers try to reduce server load by requiring a delay between
-       logins.  The LOGIN-DELAY capability includes an integer argument
-       which indicates the number of seconds after an "+OK" response to
-       a PASS, APOP, or AUTH command before another authentication will
-       be accepted.  Clients which permit the user to configure a mail
-       check interval SHOULD use this capability to determine the
-       minimum permissible interval.  Servers which advertise LOGIN-
-       DELAY SHOULD enforce it.
-
-       If the minimum login delay period could differ per user (that is,
-       the LOGIN-DELAY argument might change after authentication), the
-       server MUST announce in AUTHENTICATION state the largest value
-       which could be set for any user.  This might be the largest value
-       currently in use for any user (so only one value per server), or
-       even the largest value which the server permits to be set for any
-       user.  The server SHOULD append the token "USER" to the LOGIN-
-       DELAY parameter in AUTHENTICATION state, to inform the client
-       that a more accurate value is available after authentication.
-       The server SHOULD announce the more accurate value in TRANSACTION
-       state. (The "USER" token allows the client to decide if a second
-       CAPA command is needed or not.)
-
-       Servers enforce LOGIN-DELAY by rejecting an authentication
-       command with or without the LOGIN-DELAY error response.  See
-       section 8.1.1 for more information.
-
-6.6.  PIPELINING capability
-
-   CAPA tag:
-       PIPELINING
-
-   Arguments:
-       none
-
-   Added commands:
-       none
-
-   Standard commands affected:
-       all
-
-
-
-
-Gellens, et. al.            Standards Track                     [Page 9]
-
-RFC 2449                POP3 Extension Mechanism           November 1998
-
-
-   Announced states / possible differences:
-       both / no
-
-   Commands valid in states:
-       n/a
-
-   Specification reference:
-       this document
-
-   Discussion:
-       The PIPELINING capability indicates the server is capable of
-       accepting multiple commands at a time; the client does not have
-       to wait for the response to a command before issuing a subsequent
-       command.  If a server supports PIPELINING, it MUST process each
-       command in turn.  If a client uses PIPELINING, it MUST keep track
-       of which commands it has outstanding, and match server responses
-       to commands in order.  If either the client or server uses
-       blocking writes, it MUST not exceed the window size of the
-       underlying transport layer.
-
-       Some POP3 clients have an option to indicate the server supports
-       "Overlapped POP3 commands." This capability removes the need to
-       configure this at the client.
-
-       This is roughly synonymous with the ESMTP PIPELINING extension
-       [PIPELINING], however, since SMTP [SMTP] tends to have short
-       commands and responses, the benefit is in grouping multiple
-       commands and sending them as a unit.  While there are cases of
-       this in POP (for example, USER and PASS could be batched,
-       multiple RETR and/or DELE commands could be sent as a group),
-       because POP has short commands and sometimes lengthy responses,
-       there is also an advantage is sending new commands while still
-       receiving the response to an earlier command (for example,
-       sending RETR and/or DELE commands while processing a UIDL reply).
-
-6.7.  EXPIRE capability
-
-   CAPA tag:
-       EXPIRE
-
-   Arguments:
-       server-guaranteed minimum retention days, or NEVER; optionally
-       followed by USER in AUTHENTICATION state
-
-   Added commands:
-       none
-
-
-
-
-
-Gellens, et. al.            Standards Track                    [Page 10]
-
-RFC 2449                POP3 Extension Mechanism           November 1998
-
-
-   Standard commands affected:
-       none
-
-   Announced states / possible differences:
-       both / yes
-
-   Commands valid in states:
-       n/a
-
-   Specification reference:
-       this document
-
-   Discussion:
-       While POP3 allows clients to leave messages on the server, RFC
-       1939 [POP3] warns about the problems that may arise from this,
-       and allows servers to delete messages based on site policy.
-
-       The EXPIRE capability avoids the problems mentioned in RFC 1939,
-       by allowing the server to inform the client as to the policy in
-       effect.  The argument to the EXPIRE capability indicates the
-       minimum server retention period, in days, for messages on the
-       server.
-
-       EXPIRE 0 indicates the client is not permitted to leave mail on
-       the server; when the session enters the UPDATE state the server
-       MAY assume an implicit DELE for each message which was downloaded
-       with RETR.
-
-       EXPIRE NEVER asserts that the server does not delete messages.
-
-       The concept of a "retention period" is intentionally vague.
-       Servers may start counting days to expiration when a message is
-       added to a maildrop, when a client becomes aware of the existence
-       of a message through the LIST or UIDL commands, when a message
-       has been acted upon in some way (for example, TOP or RETR), or at
-       some other event.  The EXPIRE capability cannot provide a precise
-       indication as to exactly when any specific message will expire.
-       The capability is intended to make it easier for clients to
-       behave in ways which conform to site policy and user wishes.  For
-       example, a client might display a warning for attempts to
-       configure a "leave mail on server" period which is greater than
-       or equal to some percentage of the value announced by the server.
-
-       If a site uses any automatic deletion policy, it SHOULD use the
-       EXPIRE capability to announce this.
-
-
-
-
-
-
-Gellens, et. al.            Standards Track                    [Page 11]
-
-RFC 2449                POP3 Extension Mechanism           November 1998
-
-
-       The EXPIRE capability, with a parameter other than 0 or NEVER, is
-       intended to let the client know that the server does permit mail
-       to be left on the server, and to present a value which is the
-       smallest which might be in force.
-
-       Sites which permit users to retain messages indefinitely SHOULD
-       announce this with the EXPIRE NEVER response.
-
-       If the expiration policy differs per user (that is, the EXPIRE
-       argument might change after authentication), the server MUST
-       announce in AUTHENTICATION state the smallest value which could
-       be set for any user.  This might be the smallest value currently
-       in use for any user (so only one value per server), or even the
-       smallest value which the server permits to be set for any user.
-       The server SHOULD append the token "USER" to the EXPIRE parameter
-       in AUTHENTICATION state, to inform the client that a more
-       accurate value is available after authentication.  The server
-       SHOULD announce the more accurate value in TRANSACTION state.
-       (The "USER" token allows the client to decide if a second CAPA
-       command is needed or not.)
-
-       A site may have a message expiration policy which treats messages
-       differently depending on which user actions have been performed,
-       or based on other factors.  For example, a site might delete
-       unseen messages after 60 days, and completely- or partially-seen
-       messages after 15 days.
-
-       The announced EXPIRE value is the smallest retention period which
-       is or might be used by any category or condition of the current
-       site policy, for any user (in AUTHENTICATION state) or the
-       specific user (in TRANSACTION state).  That is, EXPIRE informs
-       the client of the minimum number of days messages may remain on
-       the server under any circumstances.
-
-       Examples:
-           EXPIRE 5 USER
-           EXPIRE 30
-           EXPIRE NEVER
-           EXPIRE 0
-
-       The first example indicates the server might delete messages
-       after five days, but the period differs per user, and so a more
-       accurate value can be obtained by issuing a second CAPA command
-       in TRANSACTION state.  The second example indicates the server
-       could delete messages after 30 days.  In the third example, the
-       server announces it does not delete messages.  The fourth example
-       specifies that the site does not permit messages to be left on
-       the server.
-
-
-
-Gellens, et. al.            Standards Track                    [Page 12]
-
-RFC 2449                POP3 Extension Mechanism           November 1998
-
-
-6.8.  UIDL capability
-
-   CAPA tag:
-       UIDL
-
-   Arguments:
-       none
-
-   Added commands:
-       UIDL
-
-   Standard commands affected:
-       none
-
-   Announced states / possible differences:
-       both / no
-
-   Commands valid in states:
-       TRANSACTION
-
-   Specification reference:
-       [POP3]
-
-   Discussion:
-       The UIDL capability indicates that the optional UIDL command is
-       supported.
-
-6.9.  IMPLEMENTATION capability
-
-   CAPA tag:
-       IMPLEMENTATION
-
-   Arguments:
-       string giving server implementation information
-
-   Added commands:
-       none
-
-   Standard commands affected:
-       none
-
-   Announced states / possible differences:
-       both (optionally TRANSACTION only) / no
-
-   Commands valid in states:
-       n/a
-
-
-
-
-
-Gellens, et. al.            Standards Track                    [Page 13]
-
-RFC 2449                POP3 Extension Mechanism           November 1998
-
-
-   Specification reference:
-       this document
-
-   Discussion:
-       It is often useful to identify an implementation of a particular
-       server (for example, when logging).  This is commonly done in the
-       welcome banner, but one must guess if a string is an
-       implementation ID or not.
-
-       The argument to the IMPLEMENTATION capability consists of one or
-       more tokens which identify the server. (Note that since CAPA
-       response tag arguments are space-separated, it may be convenient
-       for the IMPLEMENTATION capability argument to not contain spaces,
-       so that it is a single token.)
-
-       Normally, servers announce IMPLEMENTATION in both states.
-       However, a server MAY chose to do so only in TRANSACTION state.
-
-       A server MAY include the implementation identification both in
-       the welcome banner and in the IMPLEMENTATION capability.
-
-       Clients MUST NOT modify their behavior based on the server
-       implementation.  Instead the server and client should agree on a
-       private extension.
-
-7.  Future Extensions to POP3
-
-   Future extensions to POP3 are in general discouraged, as POP3's
-   usefulness lies in its simplicity.  POP3 is intended as a download-
-   and-delete protocol; mail access capabilities are available in IMAP
-   [IMAP4].  Extensions which provide support for additional mailboxes,
-   allow uploading of messages to the server, or which deviate from
-   POP's download-and-delete model are strongly discouraged and unlikely
-   to be permitted on the IETF standards track.
-
-   Clients MUST NOT require the presence of any extension for basic
-   functionality, with the exception of the authentication commands
-   (APOP, AUTH [section 6.3] and USER/PASS).
-
-   Section 9 specifies how additional capabilities are defined.
-
-8.  Extended POP3 Response Codes
-
-   Unextended POP3 is only capable of indicating success or failure to
-   most commands.  Unfortunately, clients often need to know more
-   information about the cause of a failure in order to gracefully
-   recover.  This is especially important in response to a failed login
-
-
-
-
-Gellens, et. al.            Standards Track                    [Page 14]
-
-RFC 2449                POP3 Extension Mechanism           November 1998
-
-
-   (there are widely-deployed clients which attempt to decode the error
-   text of a PASS command result, to try and distinguish between "unable
-   to get maildrop lock" and "bad login").
-
-   This specification amends the POP3 standard to permit an optional
-   response code, enclosed in square brackets, at the beginning of the
-   human readable text portion of an "+OK" or "-ERR" response.  Clients
-   supporting this extension MAY remove any information enclosed in
-   square brackets prior to displaying human readable text to the user.
-   Immediately following the open square bracket "[" character is a
-   response code which is interpreted in a case-insensitive fashion by
-   the client.
-
-   The response code is hierarchical, with a "/" separating levels of
-   detail about the error.  Clients MUST ignore unknown hierarchical
-   detail about the response code.  This is important, as it could be
-   necessary to provide further detail for response codes in the future.
-
-   Section 3 describes response codes using [ABNF].
-
-   If a server supports extended response codes, it indicates this by
-   including the RESP-CODES capability in the CAPA response.
-
-   Examples:
-           C: APOP mrose c4c9334bac560ecc979e58001b3e22fb
-           S: -ERR [IN-USE] Do you have another POP session running?
-
-8.1.  Initial POP3 response codes
-
-   This specification defines two POP3 response codes which can be used
-   to determine the reason for a failed login.  Section 9 specifies how
-   additional response codes are defined.
-
-8.1.1.  The LOGIN-DELAY response code
-
-   This occurs on an -ERR response to an AUTH, USER (see note), PASS or
-   APOP command and indicates that the user has logged in recently and
-   will not be allowed to login again until the login delay period has
-   expired.
-
-   NOTE:  Returning the LOGIN-DELAY response code to the USER command
-   avoids the work of authenticating the user but reveals to the client
-   that the specified user exists.  Unless the server is operating in an
-   environment where user names are not secret (for example, many
-   popular email clients advertise the POP server and user name in an
-   outgoing mail header), or where server access is restricted, or the
-   server can verify that the connection is to the same user, it is
-
-
-
-
-Gellens, et. al.            Standards Track                    [Page 15]
-
-RFC 2449                POP3 Extension Mechanism           November 1998
-
-
-   strongly recommended that the server not issue this response code to
-   the USER command.  The server still saves the cost of opening the
-   maildrop, which in some environments is the most expensive step.
-
-8.1.2.  The IN-USE response code
-
-   This occurs on an -ERR response to an AUTH, APOP, or PASS command.
-   It indicates the authentication was successful, but the user's
-   maildrop is currently in use (probably by another POP3 client).
-
-9.  IANA Considerations
-
-   This document requests that IANA maintain two new registries:  POP3
-   capabilities and POP3 response codes.
-
-   New POP3 capabilities MUST be defined in a standards track or IESG
-   approved experimental RFC, and MUST NOT begin with the letter "X".
-
-   New POP3 capabilities MUST include the following information:
-        CAPA tag
-        Arguments
-        Added commands
-        Standard commands affected
-        Announced states / possible differences
-        Commands valid in states
-        Specification reference
-        Discussion
-
-   In addition, new limits for POP3 command and response lengths may
-   need to be included.
-
-   New POP3 response codes MUST be defined in an RFC or other permanent
-   and readily available reference, in sufficient detail so that
-   interoperability between independent implementations is possible.
-   (This is the "Specification Required" policy described in [IANA]).
-
-   New POP3 response code specifications MUST include the following
-   information: the complete response code, for which responses (+OK
-   or -ERR) and commands it is valid, and a definition of its meaning and
-   expected client behavior.
-
-
-
-
-
-
-
-
-
-
-
-Gellens, et. al.            Standards Track                    [Page 16]
-
-RFC 2449                POP3 Extension Mechanism           November 1998
-
-
-10.  Security Considerations
-
-   A capability list can reveal information about the server's
-   authentication mechanisms which can be used to determine if certain
-   attacks will be successful.  However, allowing clients to
-   automatically detect availability of stronger mechanisms and alter
-   their configurations to use them can improve overall security at a
-   site.
-
-   Section 8.1 discusses the security issues related to use of the
-   LOGIN-DELAY response code with the USER command.
-
-11.  Acknowledgments
-
-   This document has been revised in part based on comments and
-   discussions which took place on and off the IETF POP3 Extensions
-   mailing list.  The help of those who took the time to review this
-   memo and make suggestions is appreciated, especially that of Alexey
-   Melnikov, Harald Alvestrand, and Mike Gahrns.
-
-12.  References
-
-   [ABNF]       Crocker, D. and P. Overell, "Augmented BNF for Syntax
-                Specifications:  ABNF", RFC 2234, November 1997.
-
-   [IANA]       Narten, T. and H. Alvestrand, "Guidelines for Writing an
-                IANA Considerations Section in RFCs", BCP 26, RFC 2434,
-                October 1998.
-
-   [IMAP4]      Crispin, M., "Internet Message Access Protocol --
-                Version 4rev1", RFC 2060, December 1996.
-
-   [KEYWORDS]   Bradner, S., "Key words for use in RFCs to Indicate
-                Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [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.
-
-   [POP-AUTH]   Myers, J., "POP3 AUTHentication command", RFC 1734,
-                December 1994.
-
-   [SASL]       Myers, J., "Simple Authentication and Security Layer
-                (SASL)", RFC 2222, October 1997.
-
-
-
-
-
-Gellens, et. al.            Standards Track                    [Page 17]
-
-RFC 2449                POP3 Extension Mechanism           November 1998
-
-
-   [SMTP]       Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
-                821, August 1982.
-
-13.  Authors' Addresses
-
-   Randall Gellens
-   QUALCOMM Incorporated
-   6455 Lusk Blvd.
-   San Diego, CA  92121-2779
-   USA
-
-   Phone: +1 619 651 5115
-   Fax:   +1 619 845 7268
-   EMail: randy@qualcomm.com
-
-
-   Chris Newman
-   Innosoft International, Inc.
-   1050 Lakes Drive
-   West Covina, CA 91790
-   USA
-
-   EMail: chris.newman@innosoft.com
-
-
-   Laurence Lundblade
-   QUALCOMM Incorporated
-   6455 Lusk Blvd.
-   San Diego, Ca, 92121-2779
-   USA
-
-   Phone: +1 619 658 3584
-   Fax:   +1 619 845 7268
-   EMail: lgl@qualcomm.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gellens, et. al.            Standards Track                    [Page 18]
-
-RFC 2449                POP3 Extension Mechanism           November 1998
-
-
-14.  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, et. al.            Standards Track                    [Page 19]
-
diff --git a/RFC/rfc2554.txt b/RFC/rfc2554.txt
deleted file mode 100644
index 2922deae..00000000
--- a/RFC/rfc2554.txt
+++ /dev/null
@@ -1,619 +0,0 @@
-
-
-
-
-
-
-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/RFC/rfc2645.txt b/RFC/rfc2645.txt
deleted file mode 100644
index cb99fc84..00000000
--- a/RFC/rfc2645.txt
+++ /dev/null
@@ -1,507 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        R. Gellens
-Request for Comments: 2645                                     Qualcomm
-Category: Standards Track                                   August 1999
-
-
-                      ON-DEMAND MAIL RELAY (ODMR)
-                    SMTP with Dynamic IP Addresses
-
-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.
-
-Table of Contents
-
-    1.  Abstract . . . . . . . . . . . . . . . . . . . . . . . . . .  1
-    2.  Conventions Used in this Document . . . . . . . . . . . . . . 2
-    3.  Comments . . . . . . . . . . . . . . . . . . . . . . . . . .  2
-    4.  Description . . . . . . . . . . . . . . . . . . . . . . . . . 2
-    5.  States . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
-      5.1.  Initial State . . . . . . . . . . . . . . . . . . . . . . 4
-        5.1.1.  EHLO . . . . . . . . . . . . . . . . . . . . . . . .  4
-        5.1.2.  AUTH  . . . . . . . . . . . . . . . . . . . . . . . . 4
-        5.1.3.  QUIT . . . . . . . . . . . . . . . . . . . . . . . .  4
-      5.2.  Authenticated State . . . . . . . . . . . . . . . . . . . 4
-        5.2.1.  ATRN (Authenticated TURN)  . . . . . . . . . . . . .  4
-      5.3.  Reversed State  . . . . . . . . . . . . . . . . . . . . . 5
-      5.4.  Other Commands . . . . . . . . . . . . . . . . . . . . .  6
-    6.  Example On-Demand Mail Relay Session: . . . . . . . . . . . . 6
-    7.  Response Codes . . . . . . . . . . . . . . . . . . . . . . .  6
-    8.  Security Considerations . . . . . . . . . . . . . . . . . . . 6
-    9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  7
-   10.  References  . . . . . . . . . . . . . . . . . . . . . . . . . 7
-   11.  Author's Address   . . . . . . . . . . . . . . . . . . . . .  8
-   12.  Full Copyright Statement  . . . . . . . . . . . . . . . . . . 9
-
-1.  Abstract
-
-   With the spread of low-cost computer systems and Internet
-   connectivity, the demand for local mail servers has been rising.
-   Many people now want to operate a mail server on a system which has
-
-
-
-Gellens                     Standards Track                     [Page 1]
-
-RFC 2645                  On-Demand Mail Relay               August 1999
-
-
-   only an intermittent connection to a service provider.  If the system
-   has a static IP address, the ESMTP ETRN command [ETRN] can be used.
-   However, systems with dynamic IP addresses (which are very common
-   with low-cost connections) have no widely-deployed solution.
-
-   This memo proposes a new service, On-Demand Mail Relay (ODMR), which
-   is a profile of SMTP [SMTP, ESMTP], providing for a secure,
-   extensible, easy to implement approach to the problem.
-
-2.  Conventions Used in this Document
-
-   Because the client and server roles reverse during the session, to
-   avoid confusion, the terms "customer" and "provider" will be used in
-   place of "client" and "server", although of course this protocol may
-   be useful in cases other than commercial service providers and
-   customers.
-
-   In examples, "P:" is used to indicate lines sent by the provider, and
-   "C:" indicates those sent by the customer.  Line breaks within a
-   command are for editorial purposes only.
-
-   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
-   in this document are to be interpreted as defined in [KEYWORDS].
-
-   Examples use 'example.net' as the provider, and 'example.org' and '
-   example.com' as the customers.
-
-3.  Comments
-
-   Private comments should be sent to the author.  Public comments may
-   be sent to the IETF Disconnected SMTP mailing list,
-   <ietf-disconn-smtp@imc.org>.  To subscribe, send a message to
-   <ietf-disconn-smtp-request@imc.org> containing the word SUBSCRIBE as
-   the body.
-
-4.  Description
-
-   On-Demand Mail Relay is a restricted profile of SMTP [SMTP, ESMTP].
-   Port 366 is reserved for On-Demand Mail Relay.  The initial client
-   and server roles are short-lived, as the point is to allow the
-   intermittently-connected host to request mail held for it by a
-   service provider.
-
-   The customer initiates a connection to the provider, authenticates,
-   and requests its mail.  The roles of client and server then reverse,
-   and normal SMTP [SMTP, ESMTP] proceeds.
-
-
-
-
-
-Gellens                     Standards Track                     [Page 2]
-
-RFC 2645                  On-Demand Mail Relay               August 1999
-
-
-   The provider has an On-Demand Mail Relay process listening for
-   connections on the ODMR port.  This process does not need to be a
-   full SMTP server.  It does need to be an SMTP client with access to
-   the outgoing mail queues, and as a server implement the EHLO, AUTH,
-   ATRN, and QUIT commands.
-
-   An MTA normally has a mail client component which processes the
-   outgoing mail queues, attempting to send mail for particular domains,
-   based on time or event (such as new mail being placed in the queue,
-   or receipt of an ETRN command by the SMTP server component).  The
-   On-Demand Mail Relay service processes the outgoing queue not on a
-   timer or new mail creation, but on request.
-
-   The provider side has normal SMTP server responsibilities [SMTP],
-   including generation of delivery failure notices, etc. as needed.
-
-5.  States
-
-   The On-Demand Mail Relay service has three states: an initial state,
-   an authenticated state, and a reversed state.  The state progression
-   is illustrated in the following diagram:
-
-   ---------------------------
-   !      initial state      !
-   ---------------------------
-     !             !
-   QUIT           AUTH
-     !             !
-     !             V
-     !      -----------------------
-     !      ! authenticated state !
-     !      -----------------------
-     !       !            !
-     !      QUIT         ATRN
-     !       !            !
-     !       !            V
-     !       !      ------------------
-     !       !      ! reversed state !
-     !       !      ------------------
-     !       !         !
-     !       !        QUIT
-     !       !         !
-     V       V         V
-     ---------------------
-     !    termination    !
-     ---------------------
-
-
-
-
-
-Gellens                     Standards Track                     [Page 3]
-
-RFC 2645                  On-Demand Mail Relay               August 1999
-
-
-   (Note that in the reversed state, commands are sent by the provider,
-   not the customer.)
-
-5.1.  Initial State
-
-   In the initial state, the provider is the server and the customer is
-   the client.  Three commands are valid:  EHLO, AUTH, and QUIT.
-
-5.1.1.  EHLO
-
-   The EHLO command is the same as in [ESMTP].  The response MUST
-   include AUTH and ATRN.
-
-5.1.2.  AUTH
-
-   The AUTH command is specified in [AUTH].  The AUTH command uses a
-   [SASL] mechanism to authenticate the session.  The session is not
-   considered authenticated until a success response to AUTH has been
-   sent.
-
-   For interoperability, implementations MUST support the CRAM-MD5
-   mechanism [CRAM].  Other SASL mechanisms may be supported.  A site
-   MAY disable CRAM-MD5 support if it uses more secure methods.  The
-   EXTERNAL mechanism [SASL] might be useful in some cases, for example,
-   if the provider has already authenticated the client, such as during
-   a PPP connection.
-
-5.1.3.  QUIT
-
-   The QUIT command is the same as in [SMTP].
-
-5.2.  Authenticated State
-
-   The authenticated state is entered after a successful AUTH command.
-   Two commands are valid in the authenticated state:  ATRN and QUIT.
-
-5.2.1.  ATRN (Authenticated TURN)
-
-   Unlike the TURN command in [SMTP], the ATRN command optionally takes
-   one or more domains as a parameter.  The ATRN command MUST be
-   rejected if the session has not been authenticated.  Response code
-   530 [AUTH] is used for this.
-
-   The timeout for this command MUST be at least 10 minutes to allow the
-   provider time to process its mail queue.
-
-   An ATRN command sent with no domains is equivalent to an ATRN command
-   specifying all domains to which the customer has access.
-
-
-
-Gellens                     Standards Track                     [Page 4]
-
-RFC 2645                  On-Demand Mail Relay               August 1999
-
-
-   If the authentication used by the customer does not provide access to
-   all of the domains specified in ATRN, the provider MUST NOT send mail
-   for any domains to the customer; the provider MUST reject the ATRN
-   command with a 450 code.
-
-   If the customer does have access to all of the specified domains, but
-   none of them have any queued mail, the provider normally rejects the
-   ATRN command with response code 453.  The provider MAY instead issue
-   a 250 success code, and after the roles are reversed, send a QUIT
-   following the EHLO.
-
-   The provider MAY also reject the ATRN command with a 450 response to
-   indicate refusal to accept multiple requests issued within a
-   particular time interval.
-
-   If the customer has access to all of the specified domains and mail
-   exists in at least one of them, the provider issues a 250 success
-   code.
-
-   If the server is unable to verify access to the requested domains
-   (for example, a mapping database is temporarily unavailable),
-   response code 451 is sent.
-
-      [ABNF] for ATRN:
-
-      atrn          = "ATRN" [SP domain *("," domain)]
-
-      domain        = sub-domain 1*("." sub-domain)
-
-      sub-domain    = (ALPHA / DIGIT) *(ldh-str)
-
-      ldh-str       = *(ALPHA / DIGIT / "-") (ALPHA / DIGIT)
-
-5.3.  Reversed State
-
-   After the provider has sent a success reply to the ATRN command, the
-   roles reverse, and the customer becomes the server, and the provider
-   becomes the client.
-
-   After receiving the success response to ATRN, the customer sends a
-   standard SMTP initial greeting line.  At this point normal SMTP
-   [SMTP, ESMTP] commands are used.  Typically the provider sends EHLO
-   after seeing the customer's greeting, to be followed by MAIL FROM and
-   so on.
-
-
-
-
-
-
-
-Gellens                     Standards Track                     [Page 5]
-
-RFC 2645                  On-Demand Mail Relay               August 1999
-
-
-5.4.  Other Commands
-
-   The provider MAY reject all commands other than EHLO, AUTH, ATRN, and
-   QUIT with response code 502.
-
-6.  Example On-Demand Mail Relay Session
-
-      P:  220 EXAMPLE.NET on-demand mail relay server ready
-      C:  EHLO example.org
-      P:  250-EXAMPLE.NET
-      P:  250-AUTH CRAM-MD5 EXTERNAL
-      P:  250 ATRN
-      C:  AUTH CRAM-MD5
-      P:  334 MTg5Ni42OTcxNzA5NTJASVNQLkNPTQo=
-      C:  Zm9vYmFyLm5ldCBiOTEzYTYwMmM3ZWRhN2E0OTViNGU2ZTczMzRkMzg5MAo=
-      P:  235 now authenticated as example.org
-      C:  ATRN example.org,example.com
-      P:  250 OK now reversing the connection
-      C:  220 example.org ready to receive email
-      P:  EHLO EXAMPLE.NET
-      C:  250-example.org
-      C:  250 SIZE
-      P:  MAIL FROM: <Lester.Tester@dot.foo.bar>
-      C:  250 OK
-      P:  RCPT TO: <l.eva.msg@example.com>
-      C:  250 OK, recipient accepted
-      ...
-      P:  QUIT
-      C:  221 example.org closing connection
-
-7.  Response Codes
-
-   The response codes used in this document are:
-
-   250  Requested mail action okay, completed
-   450  ATRN request refused
-   451  Unable to process ATRN request now
-   453  You have no mail
-   502  Command not implemented
-   530  Authentication required [AUTH]
-
-8.  Security Considerations
-
-   Because access to the On-Demand Mail Relay server is only useful with
-   a prior arrangement between the parties (so the provider is the
-   target of MX records for the customer's domains and thus has mail to
-   relay), it may be useful for the provider to restrict access to the
-   On-Demand Mail Relay port.  For example, the ODMR server could be
-
-
-
-Gellens                     Standards Track                     [Page 6]
-
-RFC 2645                  On-Demand Mail Relay               August 1999
-
-
-   configurable, or a TCP wrapper or firewall could be used, to block
-   access to port 366 except within the provider's network.  This might
-   be useful when the provider is the customer's ISP.  Use of such
-   mechanisms does not reduce the need for the AUTH command, however,
-   but can increase the security it provides.
-
-   Use of SASL in the AUTH command allows for substitution of more
-   secure authentication mechanisms in the future.
-
-   See sections 5.1.2 and 5.2.1 for additional security details.
-
-9.  Acknowledgments
-
-   This memo has been developed in part based on comments and
-   discussions which took place on and off the IETF-disconn-smtp mailing
-   list.  Special thanks to Chris Newman and Ned Freed for their
-   comments.
-
-10.  References
-
-   [ABNF]      Crocker, D. and P. Overell,  "Augmented BNF for Syntax
-               Specifications: ABNF", RFC 2234, November 1997.
-
-   [AUTH]      Myers, J., "SMTP Service Extension for Authentication",
-               RFC 2554, March 1999.
-
-   [CRAM]      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.
-
-   [ETRN]      De Winter, J., "SMTP Service Extension for Remote Message
-               Queue Starting", RFC 1985, August 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.
-
-   [SMTP]      Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
-               821, August 1982.
-
-
-
-
-
-
-Gellens                     Standards Track                     [Page 7]
-
-RFC 2645                  On-Demand Mail Relay               August 1999
-
-
-11.  Author's Address
-
-   Randall Gellens
-   QUALCOMM Incorporated
-   5775 Morehouse Dr.
-   San Diego, CA  92121-2779
-   U.S.A.
-
-   Phone: +1.619.651.5115
-   EMail: randy@qualcomm.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gellens                     Standards Track                     [Page 8]
-
-RFC 2645                  On-Demand Mail Relay               August 1999
-
-
-12.  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.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gellens                     Standards Track                     [Page 9]
-
diff --git a/RFC/rfc2683.txt b/RFC/rfc2683.txt
deleted file mode 100644
index 651447b3..00000000
--- a/RFC/rfc2683.txt
+++ /dev/null
@@ -1,1291 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                           B. Leiba
-Request for Comments: 2683               IBM T.J. Watson Research Center
-Category: Informational                                   September 1999
-
-
-                  IMAP4 Implementation Recommendations
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-1. Abstract
-
-   The IMAP4 specification [RFC-2060] describes a rich protocol for use
-   in building clients and servers for storage, retrieval, and
-   manipulation of electronic mail.  Because the protocol is so rich and
-   has so many implementation choices, there are often trade-offs that
-   must be made and issues that must be considered when designing such
-   clients and servers.  This document attempts to outline these issues
-   and to make recommendations in order to make the end products as
-   interoperable as possible.
-
-2. Conventions used in this document
-
-   In examples, "C:" indicates lines sent by a client that is connected
-   to a server.  "S:" indicates lines sent by the server to the client.
-
-   The words "must", "must not", "should", "should not", and "may" are
-   used with specific meaning in this document; since their meaning is
-   somewhat different from that specified in RFC 2119, we do not put
-   them in all caps here.  Their meaning is as follows:
-
-   must --       This word means that the action described is necessary
-                 to ensure interoperability.  The recommendation should
-                 not be ignored.
-   must not --   This phrase means that the action described will be
-                 almost certain to hurt interoperability.  The
-                 recommendation should not be ignored.
-
-
-
-
-
-
-
-Leiba                        Informational                      [Page 1]
-
-RFC 2683          IMAP4 Implementation Recommendations    September 1999
-
-
-   should --     This word means that the action described is strongly
-                 recommended and will enhance interoperability or
-                 usability.  The recommendation should not be ignored
-                 without careful consideration.
-   should not -- This phrase means that the action described is strongly
-                 recommended against, and might hurt interoperability or
-                 usability.  The recommendation should not be ignored
-                 without careful consideration.
-   may --        This word means that the action described is an
-                 acceptable implementation choice.  No specific
-                 recommendation is implied; this word is used to point
-                 out a choice that might not be obvious, or to let
-                 implementors know what choices have been made by
-                 existing implementations.
-
-3. Interoperability Issues and Recommendations
-
-3.1.   Accessibility
-
-   This section describes the issues related to access to servers and
-   server resources.  Concerns here include data sharing and maintenance
-   of client/server connections.
-
-3.1.1. Multiple Accesses of the Same Mailbox
-
-   One strong point of IMAP4 is that, unlike POP3, it allows for
-   multiple simultaneous access to a single mailbox.  A user can, thus,
-   read mail from a client at home while the client in the office is
-   still connected; or the help desk staff can all work out of the same
-   inbox, all seeing the same pool of questions.  An important point
-   about this capability, though is that NO SERVER IS GUARANTEED TO
-   SUPPORT THIS.  If you are selecting an IMAP server and this facility
-   is important to you, be sure that the server you choose to install,
-   in the configuration you choose to use, supports it.
-
-   If you are designing a client, you must not assume that you can
-   access the same mailbox more than once at a time.  That means
-
-   1. you must handle gracefully the failure of a SELECT command if the
-      server refuses the second SELECT,
-   2. you must handle reasonably the severing of your connection (see
-      "Severed Connections", below) if the server chooses to allow the
-      second SELECT by forcing the first off,
-   3. you must avoid making multiple connections to the same mailbox in
-      your own client (for load balancing or other such reasons), and
-   4. you must avoid using the STATUS command on a mailbox that you have
-      selected (with some server implementations the STATUS command has
-      the same problems with multiple access as do the SELECT and
-
-
-
-Leiba                        Informational                      [Page 2]
-
-RFC 2683          IMAP4 Implementation Recommendations    September 1999
-
-
-      EXAMINE commands).
-
-   A further note about STATUS: The STATUS command is sometimes used to
-   check a non-selected mailbox for new mail.  This mechanism must not
-   be used to check for new mail in the selected mailbox; section 5.2 of
-   [RFC-2060] specifically forbids this in its last paragraph.  Further,
-   since STATUS takes a mailbox name it is an independent operation, not
-   operating on the selected mailbox.  Because of this, the information
-   it returns is not necessarily in synchronization with the selected
-   mailbox state.
-
-3.1.2. Severed Connections
-
-   The client/server connection may be severed for one of three reasons:
-   the client severs the connection, the server severs the connection,
-   or the connection is severed by outside forces beyond the control of
-   the client and the server (a telephone line drops, for example).
-   Clients and servers must both deal with these situations.
-
-   When the client wants to sever a connection, it's usually because it
-   has finished the work it needed to do on that connection.  The client
-   should send a LOGOUT command, wait for the tagged response, and then
-   close the socket.  But note that, while this is what's intended in
-   the protocol design, there isn't universal agreement here.  Some
-   contend that sending the LOGOUT and waiting for the two responses
-   (untagged BYE and tagged OK) is wasteful and unnecessary, and that
-   the client can simply close the socket.  The server should interpret
-   the closed socket as a log out by the client.  The counterargument is
-   that it's useful from the standpoint of cleanup, problem
-   determination, and the like, to have an explicit client log out,
-   because otherwise there is no way for the server to tell the
-   difference between "closed socket because of log out" and "closed
-   socket because communication was disrupted".  If there is a
-   client/server interaction problem, a client which routinely
-   terminates a session by breaking the connection without a LOGOUT will
-   make it much more difficult to determine the problem.
-
-   Because of this disagreement, server designers must be aware that
-   some clients might close the socket without sending a LOGOUT.  In any
-   case, whether or not a LOGOUT was sent, the server should not
-   implicitly expunge any messages from the selected mailbox.  If a
-   client wants the server to do so, it must send a CLOSE or EXPUNGE
-   command explicitly.
-
-   When the server wants to sever a connection it's usually due to an
-   inactivity timeout or is because a situation has arisen that has
-   changed the state of the mail store in a way that the server can not
-   communicate to the client.  The server should send an untagged BYE
-
-
-
-Leiba                        Informational                      [Page 3]
-
-RFC 2683          IMAP4 Implementation Recommendations    September 1999
-
-
-   response to the client and then close the socket.  Sending an
-   untagged BYE response before severing allows the server to send a
-   human-readable explanation of the problem to the client, which the
-   client may then log, display to the user, or both (see section 7.1.5
-   of [RFC-2060]).
-
-   Regarding inactivity timeouts, there is some controversy.  Unlike
-   POP, for which the design is for a client to connect, retrieve mail,
-   and log out, IMAP's design encourages long-lived (and mostly
-   inactive) client/server sessions.  As the number of users grows, this
-   can use up a lot of server resources, especially with clients that
-   are designed to maintain sessions for mailboxes that the user has
-   finished accessing.  To alleviate this, a server may implement an
-   inactivity timeout, unilaterally closing a session (after first
-   sending an untagged BYE, as noted above).  Some server operators have
-   reported dramatic improvements in server performance after doing
-   this.  As specified in [RFC-2060], if such a timeout is done it must
-   not be until at least 30 minutes of inactivity.  The reason for this
-   specification is to prevent clients from sending commands (such as
-   NOOP) to the server at frequent intervals simply to avert a too-early
-   timeout.  If the client knows that the server may not time out the
-   session for at least 30 minutes, then the client need not poll at
-   intervals more frequent than, say, 25 minutes.
-
-3.2.   Scaling
-
-   IMAP4 has many features that allow for scalability, as mail stores
-   become larger and more numerous.  Large numbers of users, mailboxes,
-   and messages, and very large messages require thought to handle
-   efficiently.  This document will not address the administrative
-   issues involved in large numbers of users, but we will look at the
-   other items.
-
-3.2.1. Flood Control
-
-   There are three situations when a client can make a request that will
-   result in a very large response - too large for the client reasonably
-   to deal with: there are a great many mailboxes available, there are a
-   great many messages in the selected mailbox, or there is a very large
-   message part.  The danger here is that the end user will be stuck
-   waiting while the server sends (and the client processes) an enormous
-   response.  In all of these cases there are things a client can do to
-   reduce that danger.
-
-   There is also the case where a client can flood a server, by sending
-   an arbitratily long command.  We'll discuss that issue, too, in this
-   section.
-
-
-
-
-Leiba                        Informational                      [Page 4]
-
-RFC 2683          IMAP4 Implementation Recommendations    September 1999
-
-
-3.2.1.1.  Listing Mailboxes
-
-   Some servers present Usenet newsgroups to IMAP users.  Newsgroups,
-   and other such hierarchical mailbox structures, can be very numerous
-   but may have only a few entries at the top level of hierarchy.  Also,
-   some servers are built against mail stores that can, unbeknownst to
-   the server, have circular hierarchies - that is, it's possible for
-   "a/b/c/d" to resolve to the same file structure as "a", which would
-   then mean that "a/b/c/d/b" is the same as "a/b", and the hierarchy
-   will never end.  The LIST response in this case will be unlimited.
-
-   Clients that will have trouble with this are those that use
-
-       C: 001 LIST "" *
-
-   to determine the mailbox list.  Because of this, clients should not
-   use an unqualified "*" that way in the LIST command.  A safer
-   approach is to list each level of hierarchy individually, allowing
-   the user to traverse the tree one limb at a time, thus:
-
-       C: 001 LIST "" %
-       S: * LIST () "/" Banana
-       S: * LIST ...etc...
-       S: 001 OK done
-
-   and then
-
-       C: 002 LIST "" Banana/%
-       S: * LIST () "/" Banana/Apple
-       S: * LIST ...etc...
-       S: 002 OK done
-
-   Using this technique the client's user interface can give the user
-   full flexibility without choking on the voluminous reply to "LIST *".
-
-   Of course, it is still possible that the reply to
-
-       C: 005 LIST "" alt.fan.celebrity.%
-
-   may be thousands of entries long, and there is, unfortunately,
-   nothing the client can do to protect itself from that.  This has not
-   yet been a notable problem.
-
-   Servers that may export circular hierarchies (any server that
-   directly presents a UNIX file system, for instance) should limit the
-   hierarchy depth to prevent unlimited LIST responses.  A suggested
-   depth limit is 20 hierarchy levels.
-
-
-
-
-Leiba                        Informational                      [Page 5]
-
-RFC 2683          IMAP4 Implementation Recommendations    September 1999
-
-
-3.2.1.2.  Fetching the List of Messages
-
-   When a client selects a mailbox, it is given a count, in the untagged
-   EXISTS response, of the messages in the mailbox.  This number can be
-   very large.  In such a case it might be unwise to use
-
-       C: 004 FETCH 1:* ALL
-
-   to populate the user's view of the mailbox.  One good method to avoid
-   problems with this is to batch the requests, thus:
-
-       C: 004 FETCH 1:50 ALL
-       S: * 1 FETCH ...etc...
-       S: 004 OK done
-       C: 005 FETCH 51:100 ALL
-       S: * 51 FETCH ...etc...
-       S: 005 OK done
-       C: 006 FETCH 101:150 ALL
-       ...etc...
-
-   Using this method, another command, such as "FETCH 6 BODY[1]" can be
-   inserted as necessary, and the client will not have its access to the
-   server blocked by a storm of FETCH replies.  (Such a method could be
-   reversed to fetch the LAST 50 messages first, then the 50 prior to
-   that, and so on.)
-
-   As a smart extension of this, a well designed client, prepared for
-   very large mailboxes, will not automatically fetch data for all
-   messages AT ALL.  Rather, the client will populate the user's view
-   only as the user sees it, possibly pre-fetching selected information,
-   and only fetching other information as the user scrolls to it.  For
-   example, to select only those messages beginning with the first
-   unseen one:
-
-       C: 003 SELECT INBOX
-       S: * 10000 EXISTS
-       S: * 80 RECENT
-       S: * FLAGS (\Answered \Flagged \Deleted \Draft \Seen)
-       S: * OK [UIDVALIDITY 824708485] UID validity status
-       S: * OK [UNSEEN 9921] First unseen message
-       S: 003 OK [READ-WRITE] SELECT completed
-       C: 004 FETCH 9921:* ALL
-       ... etc...
-
-   If the server does not return an OK [UNSEEN] response, the client may
-   use SEARCH UNSEEN to obtain that value.
-
-
-
-
-
-Leiba                        Informational                      [Page 6]
-
-RFC 2683          IMAP4 Implementation Recommendations    September 1999
-
-
-   This mechanism is good as a default presentation method, but only
-   works well if the default message order is acceptable.  A client may
-   want to present various sort orders to the user (by subject, by date
-   sent, by sender, and so on) and in that case (lacking a SORT
-   extension on the server side) the client WILL have to retrieve all
-   message descriptors.  A client that provides this service should not
-   do it by default and should inform the user of the costs of choosing
-   this option for large mailboxes.
-
-3.2.1.3.  Fetching a Large Body Part
-
-   The issue here is similar to the one for a list of messages.  In the
-   BODYSTRUCTURE response the client knows the size, in bytes, of the
-   body part it plans to fetch.  Suppose this is a 70 MB video clip. The
-   client can use partial fetches to retrieve the body part in pieces,
-   avoiding the problem of an uninterruptible 70 MB literal coming back
-   from the server:
-
-       C: 022 FETCH 3 BODY[1]<0.20000>
-       S: * 3 FETCH (FLAGS(\Seen) BODY[1]<0> {20000}
-       S: ...data...)
-       S: 022 OK done
-       C: 023 FETCH 3 BODY[1]<20001.20000>
-       S: * 3 FETCH (BODY[1]<20001> {20000}
-       S: ...data...)
-       S: 023 OK done
-       C: 024 FETCH 3 BODY[1]<40001.20000>
-       ...etc...
-
-3.2.1.4.  BODYSTRUCTURE vs. Entire Messages
-
-   Because FETCH BODYSTRUCTURE is necessary in order to determine the
-   number of body parts, and, thus, whether a message has "attachments",
-   clients often use FETCH FULL as their normal method of populating the
-   user's view of a mailbox.  The benefit is that the client can display
-   a paperclip icon or some such indication along with the normal
-   message summary.  However, this comes at a significant cost with some
-   server configurations.  The parsing needed to generate the FETCH
-   BODYSTRUCTURE response may be time-consuming compared with that
-   needed for FETCH ENVELOPE.  The client developer should consider this
-   issue when deciding whether the ability to add a paperclip icon is
-   worth the tradeoff in performance, especially with large mailboxes.
-
-   Some clients, rather than using FETCH BODYSTRUCTURE, use FETCH BODY[]
-   (or the equivalent FETCH RFC822) to retrieve the entire message.
-   They then do the MIME parsing in the client.  This may give the
-   client slightly more flexibility in some areas (access, for instance,
-   to header fields that aren't returned in the BODYSTRUCTURE and
-
-
-
-Leiba                        Informational                      [Page 7]
-
-RFC 2683          IMAP4 Implementation Recommendations    September 1999
-
-
-   ENVELOPE responses), but it can cause severe performance problems by
-   forcing the transfer of all body parts when the user might only want
-   to see some of them - a user logged on by modem and reading a small
-   text message with a large ZIP file attached may prefer to read the
-   text only and save the ZIP file for later.  Therefore, a client
-   should not normally retrieve entire messages and should retrieve
-   message body parts selectively.
-
-3.2.1.5.  Long Command Lines
-
-   A client can wind up building a very long command line in an effort to
-   try to be efficient about requesting information from a server.  This
-   can typically happen when a client builds a message set from selected
-   messages and doesn't recognise that contiguous blocks of messages may
-   be group in a range.  Suppose a user selects all 10,000 messages in a
-   large mailbox and then unselects message 287.  The client could build
-   that message set as "1:286,288:10000", but a client that doesn't
-   handle that might try to enumerate each message individually and build
-   "1,2,3,4, [and so on] ,9999,10000".  Adding that to the fetch command
-   results in a command line that's almost 49,000 octets long, and,
-   clearly, one can construct a command line that's even longer.
-
-   A client should limit the length of the command lines it generates to
-   approximately 1000 octets (including all quoted strings but not
-   including literals).  If the client is unable to group things into
-   ranges so that the command line is within that length, it should
-   split the request into multiple commands.  The client should use
-   literals instead of long quoted strings, in order to keep the command
-   length down.
-
-   For its part, a server should allow for a command line of at least
-   8000 octets.  This provides plenty of leeway for accepting reasonable
-   length commands from clients.  The server should send a BAD response
-   to a command that does not end within the server's maximum accepted
-   command length.
-
-3.2.2. Subscriptions
-
-   The client isn't the only entity that can get flooded: the end user,
-   too, may need some flood control.  The IMAP4 protocol provides such
-   control in the form of subscriptions.  Most servers support the
-   SUBSCRIBE, UNSUBSCRIBE, and LSUB commands, and many users choose to
-   narrow down a large list of available mailboxes by subscribing to the
-   ones that they usually want to see.  Clients, with this in mind,
-   should give the user a way to see only subscribed mailboxes.  A
-   client that never uses the LSUB command takes a significant usability
-   feature away from the user.  Of course, the client would not want to
-   hide the LIST command completely; the user needs to have a way to
-
-
-
-Leiba                        Informational                      [Page 8]
-
-RFC 2683          IMAP4 Implementation Recommendations    September 1999
-
-
-   choose between LIST and LSUB.  The usual way to do this is to provide
-   a setting like "show which mailboxes?:  [] all  [] subscribed only".
-
-3.2.3. Searching
-
-   IMAP SEARCH commands can become particularly troublesome (that is,
-   slow) on mailboxes containing a large number of messages.  So let's
-   put a few things in perspective in that regard.
-
-   The flag searches should be fast.  The flag searches (ALL, [UN]SEEN,
-   [UN]ANSWERED, [UN]DELETED, [UN]DRAFT, [UN]FLAGGED, NEW, OLD, RECENT)
-   are known to be used by clients for the client's own use (for
-   instance, some clients use "SEARCH UNSEEN" to find unseen mail and
-   "SEARCH DELETED" to warn the user before expunging messages).
-
-   Other searches, particularly the text searches (HEADER, TEXT, BODY)
-   are initiated by the user, rather than by the client itself, and
-   somewhat slower performance can be tolerated, since the user is aware
-   that the search is being done (and is probably aware that it might be
-   time-consuming).  A smart server might use dynamic indexing to speed
-   commonly used text searches.
-
-   The client may allow other commands to be sent to the server while a
-   SEARCH is in progress, but at the time of this writing there is
-   little or no server support for parallel processing of multiple
-   commands in the same session (and see "Multiple Accesses of the Same
-   Mailbox" above for a description of the dangers of trying to work
-   around this by doing your SEARCH in another session).
-
-   Another word about text searches: some servers, built on database
-   back-ends with indexed search capabilities, may return search results
-   that do not match the IMAP spec's "case-insensitive substring"
-   requirements.  While these servers are in violation of the protocol,
-   there is little harm in the violation as long as the search results
-   are used only in response to a user's request.  Still, developers of
-   such servers should be aware that they ARE violating the protocol,
-   should think carefully about that behaviour, and must be certain that
-   their servers respond accurately to the flag searches for the reasons
-   outlined above.
-
-   In addition, servers should support CHARSET UTF-8 [UTF-8] in
-   searches.
-
-
-
-
-
-
-
-
-
-Leiba                        Informational                      [Page 9]
-
-RFC 2683          IMAP4 Implementation Recommendations    September 1999
-
-
-3.3    Avoiding Invalid Requests
-
-   IMAP4 provides ways for a server to tell a client in advance what is
-   and isn't permitted in some circumstances.  Clients should use these
-   features to avoid sending requests that a well designed client would
-   know to be invalid.  This section explains this in more detail.
-
-3.3.1. The CAPABILITY Command
-
-   All IMAP4 clients should use the CAPABILITY command to determine what
-   version of IMAP and what optional features a server supports.  The
-   client should not send IMAP4rev1 commands and arguments to a server
-   that does not advertize IMAP4rev1 in its CAPABILITY response.
-   Similarly, the client should not send IMAP4 commands that no longer
-   exist in IMAP4rev1 to a server that does not advertize IMAP4 in its
-   CAPABILITY response.  An IMAP4rev1 server is NOT required to support
-   obsolete IMAP4 or IMAP2bis commands (though some do; do not let this
-   fact lull you into thinking that it's valid to send such commands to
-   an IMAP4rev1 server).
-
-   A client should not send commands to probe for the existance of
-   certain extensions.  All standard and standards-track extensions
-   include CAPABILITY tokens indicating their presense.  All private and
-   experimental extensions should do the same, and clients that take
-   advantage of them should use the CAPABILITY response to determine
-   whether they may be used or not.
-
-3.3.2. Don't Do What the Server Says You Can't
-
-   In many cases, the server, in response to a command, will tell the
-   client something about what can and can't be done with a particular
-   mailbox.  The client should pay attention to this information and
-   should not try to do things that it's been told it can't do.
-
-   Examples:
-
-   *  Do not try to SELECT a mailbox that has the \Noselect flag set.
-   *  Do not try to CREATE a sub-mailbox in a mailbox that has the
-      \Noinferiors flag set.
-   *  Do not respond to a failing COPY or APPEND command by trying to
-      CREATE the target mailbox if the server does not respond with a
-      [TRYCREATE] response code.
-   *  Do not try to expunge a mailbox that has been selected with the
-      [READ-ONLY] response code.
-
-
-
-
-
-
-
-Leiba                        Informational                     [Page 10]
-
-RFC 2683          IMAP4 Implementation Recommendations    September 1999
-
-
-3.4.   Miscellaneous Protocol Considerations
-
-   We describe here a number of important protocol-related issues, the
-   misunderstanding of which has caused significant interoperability
-   problems in IMAP4 implementations.  One general item is that every
-   implementer should be certain to take note of and to understand
-   section 2.2.2 and the preamble to section 7 of the IMAP4rev1 spec
-   [RFC-2060].
-
-3.4.1. Well Formed Protocol
-
-   We cannot stress enough the importance of adhering strictly to the
-   protocol grammar.  The specification of the protocol is quite rigid;
-   do not assume that you can insert blank space for "readability" if
-   none is called for.  Keep in mind that there are parsers out there
-   that will crash if there are protocol errors.  There are clients that
-   will report every parser burp to the user.  And in any case,
-   information that cannot be parsed is information that is lost.  Be
-   careful in your protocol generation.  And see "A Word About Testing",
-   below.
-
-   In particular, note that the string in the INTERNALDATE response is
-   NOT an RFC-822 date string - that is, it is not in the same format as
-   the first string in the ENVELOPE response.  Since most clients will,
-   in fact, accept an RFC-822 date string in the INTERNALDATE response,
-   it's easy to miss this in your interoperability testing.  But it will
-   cause a problem with some client, so be sure to generate the correct
-   string for this field.
-
-3.4.2. Special Characters
-
-   Certain characters, currently the double-quote and the backslash, may
-   not be sent as-is inside a quoted string.  These characters must be
-   preceded by the escape character if they are in a quoted string, or
-   else the string must be sent as a literal.  Both clients and servers
-   must handle this, both on output (they must send these characters
-   properly) and on input (they must be able to receive escaped
-   characters in quoted strings).  Example:
-
-       C: 001 LIST "" %
-       S: * LIST () "" INBOX
-       S: * LIST () "\\" TEST
-       S: * LIST () "\\" {12}
-       S: "My" mailbox
-       S: 001 OK done
-       C: 002 LIST "" "\"My\" mailbox\\%"
-       S: * LIST () "\\" {17}
-       S: "My" mailbox\Junk
-
-
-
-Leiba                        Informational                     [Page 11]
-
-RFC 2683          IMAP4 Implementation Recommendations    September 1999
-
-
-       S: 002 OK done
-
-   Note that in the example the server sent the hierarchy delimiter as
-   an escaped character in the quoted string and sent the mailbox name
-   containing imbedded double-quotes as a literal.  The client used only
-   quoted strings, escaping both the backslash and the double-quote
-   characters.
-
-   The CR and LF characters may be sent ONLY in literals; they are not
-   allowed, even if escaped, inside quoted strings.
-
-   And while we're talking about special characters: the IMAP spec, in
-   the section titled "Mailbox International Naming Convention",
-   describes how to encode mailbox names in modified UTF-7 [UTF-7 and
-   RFC-2060].  Implementations must adhere to this in order to be
-   interoperable in the international market, and servers should
-   validate mailbox names sent by client and reject names that do not
-   conform.
-
-   As to special characters in userids and passwords: clients must not
-   restrict what a user may type in for a userid or a password.  The
-   formal grammar specifies that these are "astrings", and an astring
-   can be a literal.  A literal, in turn can contain any 8-bit
-   character, and clients must allow users to enter all 8-bit characters
-   here, and must pass them, unchanged, to the server (being careful to
-   send them as literals when necessary).  In particular, some server
-   configurations use "@" in user names, and some clients do not allow
-   that character to be entered; this creates a severe interoperability
-   problem.
-
-3.4.3. UIDs and UIDVALIDITY
-
-   Servers that support existing back-end mail stores often have no good
-   place to save UIDs for messages.  Often the existing mail store will
-   not have the concept of UIDs in the sense that IMAP has: strictly
-   increasing, never re-issued, 32-bit integers.  Some servers solve
-   this by storing the UIDs in a place that's accessible to end users,
-   allowing for the possibility that the users will delete them.  Others
-   solve it by re-assigning UIDs every time a mailbox is selected.
-
-   The server should maintain UIDs permanently for all messages if it
-   can.  If that's not possible, the server must change the UIDVALIDITY
-   value for the mailbox whenever any of the UIDs may have become
-   invalid.  Clients must recognize that the UIDVALIDITY has changed and
-   must respond to that condition by throwing away any information that
-   they have saved about UIDs in that mailbox.  There have been many
-   problems in this area when clients have failed to do this; in the
-   worst case it will result in loss of mail when a client deletes the
-
-
-
-Leiba                        Informational                     [Page 12]
-
-RFC 2683          IMAP4 Implementation Recommendations    September 1999
-
-
-   wrong piece of mail by using a stale UID.
-
-   It seems to be a common misunderstanding that "the UIDVALIDITY and
-   the UID, taken together, form a 64-bit identifier that uniquely
-   identifies a message on a server".  This is absolutely NOT TRUE.
-   There is no assurance that the UIDVALIDITY values of two mailboxes be
-   different, so the UIDVALIDITY in no way identifies a mailbox.  The
-   ONLY purpose of UIDVALIDITY is, as its name indicates, to give the
-   client a way to check the validity of the UIDs it has cached.  While
-   it is a valid implementation choice to put these values together to
-   make a 64-bit identifier for the message, the important concept here
-   is that UIDs are not unique between mailboxes; they are only unique
-   WITHIN a given mailbox.
-
-   Some server implementations have attempted to make UIDs unique across
-   the entire server.  This is inadvisable, in that it limits the life
-   of UIDs unnecessarily.  The UID is a 32-bit number and will run out
-   in reasonably finite time if it's global across the server.  If you
-   assign UIDs sequentially in one mailbox, you will not have to start
-   re-using them until you have had, at one time or another, 2**32
-   different messages in that mailbox.  In the global case, you will
-   have to reuse them once you have had, at one time or another, 2**32
-   different messages in the entire mail store.  Suppose your server has
-   around 8000 users registered (2**13).  That gives an average of 2**19
-   UIDs per user.  Suppose each user gets 32 messages (2**5) per day.
-   That gives you 2**14 days (16000+ days = about 45 years) before you
-   run out.  That may seem like enough, but multiply the usage just a
-   little (a lot of spam, a lot of mailing list subscriptions, more
-   users) and you limit yourself too much.
-
-   What's worse is that if you have to wrap the UIDs, and, thus, you
-   have to change UIDVALIDITY and invalidate the UIDs in the mailbox,
-   you have to do it for EVERY mailbox in the system, since they all
-   share the same UID pool.  If you assign UIDs per mailbox and you have
-   a problem, you only have to kill the UIDs for that one mailbox.
-
-   Under extreme circumstances (and this is extreme, indeed), the server
-   may have to invalidate UIDs while a mailbox is in use by a client -
-   that is, the UIDs that the client knows about in its active mailbox
-   are no longer valid.  In that case, the server must immediately
-   change the UIDVALIDITY and must communicate this to the client.  The
-   server may do this by sending an unsolicited UIDVALIDITY message, in
-   the same form as in response to the SELECT command.  Clients must be
-   prepared to handle such a message and the possibly coincident failure
-   of the command in process.  For example:
-
-
-
-
-
-
-Leiba                        Informational                     [Page 13]
-
-RFC 2683          IMAP4 Implementation Recommendations    September 1999
-
-
-       C: 032 UID STORE 382 +Flags.silent \Deleted
-       S: * OK [UIDVALIDITY 12345] New UIDVALIDITY value!
-       S: 032 NO UID command rejected because UIDVALIDITY changed!
-       C: ...invalidates local information and re-fetches...
-       C: 033 FETCH 1:* UID
-       ...etc...
-
-   At the time of the writing of this document, the only server known to
-   do this does so only under the following condition: the client
-   selects INBOX, but there is not yet a physical INBOX file created.
-   Nonetheless, the SELECT succeeds, exporting an empty INBOX with a
-   temporary UIDVALIDITY of 1.  While the INBOX remains selected, mail
-   is delivered to the user, which creates the real INBOX file and
-   assigns a permanent UIDVALIDITY (that is likely not to be 1).  The
-   server reports the change of UIDVALIDITY, but as there were no
-   messages before, so no UIDs have actually changed, all the client
-   must do is accept the change in UIDVALIDITY.
-
-   Alternatively, a server may force the client to re-select the
-   mailbox, at which time it will obtain a new UIDVALIDITY value.  To do
-   this, the server closes this client session (see "Severed
-   Connections" above) and the client then reconnects and gets back in
-   synch.  Clients must be prepared for either of these behaviours.
-
-   We do not know of, nor do we anticipate the future existance of, a
-   server that changes UIDVALIDITY while there are existing messages,
-   but clients must be prepared to handle this eventuality.
-
-3.4.4. FETCH Responses
-
-   When a client asks for certain information in a FETCH command, the
-   server may return the requested information in any order, not
-   necessarily in the order that it was requested.  Further, the server
-   may return the information in separate FETCH responses and may also
-   return information that was not explicitly requested (to reflect to
-   the client changes in the state of the subject message).  Some
-   examples:
-
-       C: 001 FETCH 1 UID FLAGS INTERNALDATE
-       S: * 5 FETCH (FLAGS (\Deleted))
-       S: * 1 FETCH (FLAGS (\Seen) INTERNALDATE "..." UID 345)
-       S: 001 OK done
-
-   (In this case, the responses are in a different order.  Also, the
-   server returned a flag update for message 5, which wasn't part of the
-   client's request.)
-
-
-
-
-
-Leiba                        Informational                     [Page 14]
-
-RFC 2683          IMAP4 Implementation Recommendations    September 1999
-
-
-       C: 002 FETCH 2 UID FLAGS INTERNALDATE
-       S: * 2 FETCH (INTERNALDATE "...")
-       S: * 2 FETCH (UID 399)
-       S: * 2 FETCH (FLAGS ())
-       S: 002 OK done
-
-   (In this case, the responses are in a different order and were
-   returned in separate responses.)
-
-       C: 003 FETCH 2 BODY[1]
-       S: * 2 FETCH (FLAGS (\Seen) BODY[1] {14}
-       S: Hello world!
-       S: )
-       S: 003 OK done
-
-   (In this case, the FLAGS response was added by the server, since
-   fetching the body part caused the server to set the \Seen flag.)
-
-   Because of this characteristic a client must be ready to receive any
-   FETCH response at any time and should use that information to update
-   its local information about the message to which the FETCH response
-   refers.  A client must not assume that any FETCH responses will come
-   in any particular order, or even that any will come at all.  If after
-   receiving the tagged response for a FETCH command the client finds
-   that it did not get all of the information requested, the client
-   should send a NOOP command to the server to ensure that the server
-   has an opportunity to send any pending EXPUNGE responses to the
-   client (see [RFC-2180]).
-
-3.4.5. RFC822.SIZE
-
-   Some back-end mail stores keep the mail in a canonical form, rather
-   than retaining the original MIME format of the messages.  This means
-   that the server must reassemble the message to produce a MIME stream
-   when a client does a fetch such as RFC822 or BODY[], requesting the
-   entire message.  It also may mean that the server has no convenient
-   way to know the RFC822.SIZE of the message.  Often, such a server
-   will actually have to build the MIME stream to compute the size, only
-   to throw the stream away and report the size to the client.
-
-   When this is the case, some servers have chosen to estimate the size,
-   rather than to compute it precisely.  Such an estimate allows the
-   client to display an approximate size to the user and to use the
-   estimate in flood control considerations (q.v.), but requires that
-   the client not use the size for things such as allocation of buffers,
-   because those buffers might then be too small to hold the actual MIME
-   stream.  Instead, a client should use the size that's returned in the
-   literal when you fetch the data.
-
-
-
-Leiba                        Informational                     [Page 15]
-
-RFC 2683          IMAP4 Implementation Recommendations    September 1999
-
-
-   The protocol requires that the RFC822.SIZE value returned by the
-   server be EXACT.  Estimating the size is a protocol violation, and
-   server designers must be aware that, despite the performance savings
-   they might realize in using an estimate, this practice will cause
-   some clients to fail in various ways.  If possible, the server should
-   compute the RFC822.SIZE for a particular message once, and then save
-   it for later retrieval.  If that's not possible, the server must
-   compute the value exactly every time.  Incorrect estimates do cause
-   severe interoperability problems with some clients.
-
-3.4.6. Expunged Messages
-
-   If the server allows multiple connections to the same mailbox, it is
-   often possible for messages to be expunged in one client unbeknownst
-   to another client.  Since the server is not allowed to tell the
-   client about these expunged messages in response to a FETCH command,
-   the server may have to deal with the issue of how to return
-   information about an expunged message.  There was extensive
-   discussion about this issue, and the results of that discussion are
-   summarized in [RFC-2180].  See that reference for a detailed
-   explanation and for recommendations.
-
-3.4.7. The Namespace Issue
-
-   Namespaces are a very muddy area in IMAP4 implementation right now
-   (see [NAMESPACE] for a proposal to clear the water a bit).  Until the
-   issue is resolved, the important thing for client developers to
-   understand is that some servers provide access through IMAP to more
-   than just the user's personal mailboxes, and, in fact, the user's
-   personal mailboxes may be "hidden" somewhere in the user's default
-   hierarchy.  The client, therefore, should provide a setting wherein
-   the user can specify a prefix to be used when accessing mailboxes. If
-   the user's mailboxes are all in "~/mail/", for instance, then the
-   user can put that string in the prefix.  The client would then put
-   the prefix in front of any name pattern in the LIST and LSUB
-   commands:
-
-       C: 001 LIST "" ~/mail/%
-
-   (See also "Reference Names in the LIST Command" below.)
-
-3.4.8. Creating Special-Use Mailboxes
-
-   It may seem at first that this is part of the namespace issue; it is
-   not, and is only indirectly related to it.  A number of clients like
-   to create special-use mailboxes with particular names.  Most
-   commonly, clients with a "trash folder" model of message deletion
-   want to create a mailbox with the name "Trash" or "Deleted".  Some
-
-
-
-Leiba                        Informational                     [Page 16]
-
-RFC 2683          IMAP4 Implementation Recommendations    September 1999
-
-
-   clients want to create a "Drafts" mailbox, an "Outbox" mailbox, or a
-   "Sent Mail" mailbox.  And so on.  There are two major
-   interoperability problems with this practice:
-
-   1. different clients may use different names for mailboxes with
-      similar functions (such as "Trash" and "Deleted"), or may manage
-      the same mailboxes in different ways, causing problems if a user
-      switches between clients and
-   2. there is no guarantee that the server will allow the creation of
-      the desired mailbox.
-
-   The client developer is, therefore, well advised to consider
-   carefully the creation of any special-use mailboxes on the server,
-   and, further, the client must not require such mailbox creation -
-   that is, if you do decide to do this, you must handle gracefully the
-   failure of the CREATE command and behave reasonably when your
-   special-use mailboxes do not exist and can not be created.
-
-   In addition, the client developer should provide a convenient way for
-   the user to select the names for any special-use mailboxes, allowing
-   the user to make these names the same in all clients used and to put
-   them where the user wants them.
-
-3.4.9. Reference Names in the LIST Command
-
-   Many implementers of both clients and servers are confused by the
-   "reference name" on the LIST command.  The reference name is intended
-   to be used in much the way a "cd" (change directory) command is used
-   on Unix, PC DOS, Windows, and OS/2 systems.  That is, the mailbox
-   name is interpreted in much the same way as a file of that name would
-   be found if one had done a "cd" command into the directory specified
-   by the reference name.  For example, in Unix we have the following:
-
-       > cd /u/jones/junk
-       > vi banana        [file is "/u/jones/junk/banana"]
-       > vi stuff/banana  [file is "/u/jones/junk/stuff/banana"]
-       > vi /etc/hosts    [file is "/etc/hosts"]
-
-   In the past, there have been several interoperability problems with
-   this.  First, while some IMAP servers are built on Unix or PC file
-   systems, many others are not, and the file system semantics do not
-   make sense in those configurations.  Second, while some IMAP servers
-   expose the underlying file system to the clients, others allow access
-   only to the user's personal mailboxes, or to some other limited set
-   of files, making such file-system-like semantics less meaningful.
-   Third, because the IMAP spec leaves the interpretation of the
-   reference name as "implementation-dependent", in the past the various
-   server implementations handled it in vastly differing ways.
-
-
-
-Leiba                        Informational                     [Page 17]
-
-RFC 2683          IMAP4 Implementation Recommendations    September 1999
-
-
-   The following recommendations are the result of significant
-   operational experience, and are intended to maximize
-   interoperability.
-
-   Server implementations must implement the reference argument in a way
-   that matches the intended "change directory" operation as closely as
-   possible.  As a minimum implementation, the reference argument may be
-   prepended to the mailbox name (while suppressing double delimiters;
-   see the next paragraph).  Even servers that do not provide a way to
-   break out of the current hierarchy (see "breakout facility" below)
-   must provide a reasonable implementation of the reference argument,
-   as described here, so that they will interoperate with clients that
-   use it.
-
-   Server implementations that prepend the reference argument to the
-   mailbox name should insert a hierarchy delimiter between them, and
-   must not insert a second if one is already present:
-
-       C: A001 LIST ABC DEF
-       S: * LIST () "/" ABC/DEF   <=== should do this
-       S: A001 OK done
-
-       C: A002 LIST ABC/ /DEF
-       S: * LIST () "/" ABC//DEF     <=== must not do this
-       S: A002 OK done
-
-   On clients, the reference argument is chiefly used to implement a
-   "breakout facility", wherein the user may directly access a mailbox
-   outside the "current directory" hierarchy.  Client implementations
-   should have an operational mode that does not use the reference
-   argument.  This is to interoperate with older servers that did not
-   implement the reference argument properly.  While it's a good idea to
-   give the user access to a breakout facility, clients that do not
-   intend to do so should not use the reference argument at all.
-
-   Client implementations should always place a trailing hierarchy
-   delimiter on the reference argument.  This is because some servers
-   prepend the reference argument to the mailbox name without inserting
-   a hierarchy delimiter, while others do insert a hierarchy delimiter
-   if one is not already present.  A client that puts the delimiter in
-   will work with both varieties of server.
-
-   Client implementations that implement a breakout facility should
-   allow the user to choose whether or not to use a leading hierarchy
-   delimiter on the mailbox argument.  This is because the handling of a
-   leading mailbox hierarchy delimiter also varies from server to
-   server, and even between different mailstores on the same server.  In
-   some cases, a leading hierarchy delimiter means "discard the
-
-
-
-Leiba                        Informational                     [Page 18]
-
-RFC 2683          IMAP4 Implementation Recommendations    September 1999
-
-
-   reference argument" (implementing the intended breakout facility),
-   thus:
-
-       C: A001 LIST ABC/ /DEF
-       S: * LIST () "/" /DEF
-       S: A001 OK done
-
-   In other cases, however, the two are catenated and the extra
-   hierarchy delimiter is discarded, thus:
-
-       C: A001 LIST ABC/ /DEF
-       S: * LIST () "/" ABC/DEF
-       S: A001 OK done
-
-   Client implementations must not assume that the server supports a
-   breakout facility, but may provide a way for the user to use one if
-   it is available.  Any breakout facility should be exported to the
-   user interface.  Note that there may be other "breakout" characters
-   besides the hierarchy delimiter (for instance, UNIX filesystem
-   servers are likely to use a leading "~" as well), and that their
-   interpretation is server-dependent.
-
-3.4.10.   Mailbox Hierarchy Delimiters
-
-   The server's selection of what to use as a mailbox hierarchy
-   delimiter is a difficult one, involving several issues: What
-   characters do users expect to see?  What characters can they enter
-   for a hierarchy delimiter if it is desired (or required) that the
-   user enter it?  What character can be used for the hierarchy
-   delimiter, noting that the chosen character can not otherwise be used
-   in the mailbox name?
-
-   Because some interfaces show users the hierarchy delimiters or allow
-   users to enter qualified mailbox names containing them, server
-   implementations should use delimiter characters that users generally
-   expect to see as name separators.  The most common characters used
-   for this are "/" (as in Unix file names), "\" (as in OS/2 and Windows
-   file names), and "." (as in news groups).  There is little to choose
-   among these apart from what users may expect or what is dictated by
-   the underlying file system, if any.  One consideration about using
-   "\" is that it's also a special character in the IMAP protocol. While
-   the use of other hierarchy delimiter characters is permissible, A
-   DESIGNER IS WELL ADVISED TO STAY WITH ONE FROM THIS SET unless the
-   server is intended for special purposes only.  Implementers might be
-   thinking about using characters such as "-", "_", ";", "&", "#", "@",
-   and "!", but they should be aware of the surprise to the user as well
-   as of the effect on URLs and other external specifications (since
-   some of these characters have special meanings there).  Also, a
-
-
-
-Leiba                        Informational                     [Page 19]
-
-RFC 2683          IMAP4 Implementation Recommendations    September 1999
-
-
-   server that uses "\" (and clients of such a server) must remember to
-   escape that character in quoted strings or to send literals instead.
-   Literals are recommended over escaped characters in quoted strings in
-   order to maintain compatibility with older IMAP versions that did not
-   allow escaped characters in quoted strings (but check the grammar to
-   see where literals are allowed):
-
-       C: 001 LIST "" {13}
-       S: + send literal
-       C: this\%\%\%\h*
-       S: * LIST () "\\" {27}
-       S: this\is\a\mailbox\hierarchy
-       S: 001 OK LIST complete
-
-   In any case, a server should not use normal alpha-numeric characters
-   (such as "X" or "0") as delimiters; a user would be very surprised to
-   find that "EXPENDITURES" actually represented a two-level hierarchy.
-   And a server should not use characters that are non-printable or
-   difficult or impossible to enter on a standard US keyboard.  Control
-   characters, box-drawing characters, and characters from non-US
-   alphabets fit into this category.  Their use presents
-   interoperability problems that are best avoided.
-
-   The UTF-7 encoding of mailbox names also raises questions about what
-   to do with the hierarchy delimiters in encoded names: do we encode
-   each hierarchy level and separate them with delimiters, or do we
-   encode the fully qualified name, delimiters and all?  The answer for
-   IMAP is the former: encode each hierarchy level separately, and
-   insert delimiters between.  This makes it particularly important not
-   to use as a hierarchy delimiter a character that might cause
-   confusion with IMAP's modified UTF-7 [UTF-7 and RFC-2060] encoding.
-
-   To repeat: a server should use "/", "\", or "." as its hierarchy
-   delimiter.  The use of any other character is likely to cause
-   problems and is STRONGLY DISCOURAGED.
-
-3.4.11.   ALERT Response Codes
-
-   The protocol spec is very clear on the matter of what to do with
-   ALERT response codes, and yet there are many clients that violate it
-   so it needs to be said anyway: "The human-readable text contains a
-   special alert that must be presented to the user in a fashion that
-   calls the user's attention to the message."  That should be clear
-   enough, but I'll repeat it here: Clients must present ALERT text
-   clearly to the user.
-
-
-
-
-
-
-Leiba                        Informational                     [Page 20]
-
-RFC 2683          IMAP4 Implementation Recommendations    September 1999
-
-
-3.4.12.   Deleting Mailboxes
-
-   The protocol does not guarantee that a client may delete a mailbox
-   that is not empty, though on some servers it is permissible and is,
-   in fact, much faster than the alternative or deleting all the
-   messages from the client.  If the client chooses to try to take
-   advantage of this possibility it must be prepared to use the other
-   method in the even that the more convenient one fails.  Further, a
-   client should not try to delete the mailbox that it has selected, but
-   should first close that mailbox; some servers do not permit the
-   deletion of the selected mailbox.
-
-   That said, a server should permit the deletion of a non-empty
-   mailbox; there's little reason to pass this work on to the client.
-   Moreover, forbidding this prevents the deletion of a mailbox that for
-   some reason can not be opened or expunged, leading to possible
-   denial-of-service problems.
-
-   Example:
-
-       [User tells the client to delete mailbox BANANA, which is
-       currently selected...]
-       C: 008 CLOSE
-       S: 008 OK done
-       C: 009 DELETE BANANA
-       S: 009 NO Delete failed; mailbox is not empty.
-       C: 010 SELECT BANANA
-       S: * ... untagged SELECT responses
-       S: 010 OK done
-       C: 011 STORE 1:* +FLAGS.SILENT \DELETED
-       S: 011 OK done
-       C: 012 CLOSE
-       S: 012 OK done
-       C: 013 DELETE BANANA
-       S: 013 OK done
-
-3.5.   A Word About Testing
-
-   Since the whole point of IMAP is interoperability, and since
-   interoperability can not be tested in a vacuum, the final
-   recommendation of this treatise is, "Test against EVERYTHING."  Test
-   your client against every server you can get an account on.  Test
-   your server with every client you can get your hands on.  Many
-   clients make limited test versions available on the Web for the
-   downloading.  Many server owners will give serious client developers
-   guest accounts for testing.  Contact them and ask.  NEVER assume that
-   because your client works with one or two servers, or because your
-   server does fine with one or two clients, you will interoperate well
-
-
-
-Leiba                        Informational                     [Page 21]
-
-RFC 2683          IMAP4 Implementation Recommendations    September 1999
-
-
-   in general.
-
-   In particular, in addition to everything else, be sure to test
-   against the reference implementations: the PINE client, the
-   University of Washington server, and the Cyrus server.
-
-   See the following URLs on the web for more information here:
-
-       IMAP Products and Sources: http://www.imap.org/products.html
-       IMC MailConnect: http://www.imc.org/imc-mailconnect
-
-4. Security Considerations
-
-   This document describes behaviour of clients and servers that use the
-   IMAP4 protocol, and as such, has the same security considerations as
-   described in [RFC-2060].
-
-5. References
-
-   [RFC-2060]  Crispin, M., "Internet Message Access Protocol - Version
-               4rev1", RFC 2060, December 1996.
-
-   [RFC-2119]  Bradner, S., "Key words for use in RFCs to Indicate
-               Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC-2180]  Gahrns, M., "IMAP4 Multi-Accessed Mailbox Practice", RFC
-               2180, July 1997.
-
-   [UTF-8]     Yergeau, F., " UTF-8, a transformation format of Unicode
-               and ISO 10646", RFC 2044, October 1996.
-
-   [UTF-7]     Goldsmith, D. and M. Davis, "UTF-7, a Mail-Safe
-               Transformation Format of Unicode", RFC 2152, May 1997.
-
-   [NAMESPACE] Gahrns, M. and C. Newman, "IMAP4 Namespace", Work in
-               Progress.
-
-6. Author's Address
-
-   Barry Leiba
-   IBM T.J. Watson Research Center
-   30 Saw Mill River Road
-   Hawthorne, NY  10532
-
-   Phone: 1-914-784-7941
-   EMail: leiba@watson.ibm.com
-
-
-
-
-
-Leiba                        Informational                     [Page 22]
-
-RFC 2683          IMAP4 Implementation Recommendations    September 1999
-
-
-7. 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.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Leiba                        Informational                     [Page 23]
-
diff --git a/RFC/rfc821.txt b/RFC/rfc821.txt
deleted file mode 100644
index d877b72c..00000000
--- a/RFC/rfc821.txt
+++ /dev/null
@@ -1,4050 +0,0 @@
-
-                                                                        
-
-   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/RFC/rfc822.txt b/RFC/rfc822.txt
deleted file mode 100644
index 35b09a3c..00000000
--- a/RFC/rfc822.txt
+++ /dev/null
@@ -1,2901 +0,0 @@
-
- 
-
-
-
-
-     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/RFC/rfc937.txt b/RFC/rfc937.txt
deleted file mode 100644
index ae154ea8..00000000
--- a/RFC/rfc937.txt
+++ /dev/null
@@ -1,1392 +0,0 @@
-
-
-Network Working Group                                          M. Butler
-Request for Comments: 937                                      J. Postel
-                                                                D. Chase
-                                                           J. Goldberger
-                                                          J. K. Reynolds
-Obsoletes: RFC 918                                                   ISI
-                                                           February 1985
-
-
-                    POST OFFICE PROTOCOL - VERSION 2
-
-
-Status of this Memo
-
-   This RFC suggests a simple method for workstations to dynamically
-   access mail from a mailbox server.  This RFC specifies a proposed
-   protocol for the ARPA-Internet community, and requests discussion and
-   suggestions for improvement.  This memo is a revision of RFC 918.
-   Distribution of this memo is unlimited.
-
-Introduction
-
-   The intent of the Post Office Protocol Version 2 (POP2) is to allow a
-   user's workstation to access mail from a mailbox server.  It is
-   expected that mail will be posted from the workstation to the mailbox
-   server via the Simple Mail Transfer Protocol (SMTP).  For further
-   information see RFC-821 [1] and RFC-822 [2].
-
-   This protocol assumes a reliable data stream such as provided by TCP
-   or any similar protocol.  When TCP is used, the POP2 server listens
-   on port 109 [4].
-
-System Model and Philosophy
-
-   While we view the workstation as an Internet host in the sense that
-   it implements IP, we do not expect the workstation to contain the
-   user's mailbox.  We expect the mailbox to be on a server machine.
-
-   We believe it is important for the mailbox to be on an "always up"
-   machine and that a workstation may be frequently powered down, or
-   otherwise unavailable as an SMTP server.
-
-   POP2 is designed for an environment of workstations and servers on a
-   low-delay, high-throughput, local networks (such as Ethernets).  POP2
-   may be useful in other environments as well, but if the environment
-   is substantially different, a different division of labor between the
-   client and server may be appropriate, and a different protocol
-   required.
-
-   Suppose the user's real name is John Smith, the user's machine is
-   called FIDO, and that the mailbox server is called DOG-HOUSE.  Then
-
-
-
-Butler, et. al.                                                 [Page 1]
-
-
-
-RFC 937                                                    February 1985
-Post Office Protocol
-
-
-   we expect the user's mail to be addressed to JSmith@DOG-HOUSE.ARPA
-   (not JSmith@FIDO.ARPA).
-
-   That is, the destination of the mail is the mailbox on the server
-   machine.  The POP2 protocol and the workstation are merely a
-   mechanism for viewing the messages in the mailbox.
-
-   The user is not tied to any particular workstation for accessing his
-   mail.  The workstation does not appear as any part of the mailbox
-   address.
-
-   This is a very simple protocol.  This is not a user interface.  We
-   expect that there is a program in the workstation that is friendly to
-   the user.  This protocol is not "user friendly".  One basic rule of
-   this protocol is "if anything goes wrong close the connection".
-   Another basic rule is to have few options.
-
-   POP2 does not parse messages in any way.  It does not analyze message
-   headers (Date:, From:, To:, Cc:, or Subject:).  POP2 simply transmits
-   whole messages from a mailbox server to a client workstation.
-
-The Protocol
-
-   The POP2 protocol is a sequence of commands and replies.  The design
-   draws from many previous protocols of the ARPA-Internet community.
-
-      The server must be listening for a connection.  When a connection
-      is opened the server sends a greeting message and waits for
-      commands.  When commands are received the server acts on them and
-      responds with replies.
-
-      The client opens a connection, waits for the greeting, then sends
-      the HELO command with the user name and password arguments to
-      establish authorization to access mailboxes.  The server returns
-      the number of messages in the default mailbox.
-
-      The client may read the default mailbox associated with the user
-      name or may select another mailbox by using the FOLD command.  The
-      server returns the number of messages in the mailbox selected.
-
-      The client begins a message reading transaction with a READ
-      command.  The read command may optionally indicate which message
-      number to read, the default is the current message (incremented
-      when a message is read and set to one when a new folder is
-      selected).  The server returns the number of characters in the
-      message.
-
-
-
-
-Butler, et. al.                                                 [Page 2]
-
-
-
-RFC 937                                                    February 1985
-Post Office Protocol
-
-
-      The client asks for the content of the message to be sent with the
-      RETR command.  The server sends the message data.
-
-      When all the data has been received the client sends an
-      acknowledgment command.  This is one of ACKS, ACKD, and NACK.
-
-         ACKS means "I've received the message successfully and please
-         keep it in the mailbox".
-
-         ACKD means "I've received the message successfully and please
-         delete it from the mailbox".
-
-         NACK means "I did not receive the message and please keep it in
-         the mailbox".
-
-      In the case of ACKS or ACKD the server increments the current
-      message indicator.  In the case of NACK the current message
-      indicator stays the same.
-
-      In all cases the server returns the number of characters in the
-      (now) current message.
-
-      The client terminates the session with the QUIT command.  The
-      server returns an ok.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Butler, et. al.                                                 [Page 3]
-
-
-
-RFC 937                                                    February 1985
-Post Office Protocol
-
-
-   The Normal Scenario
-
-           Client                    Server
-           ------                    ------
-                                Wait for Connection
-      Open Connection  -->
-                           <--  + POP2 Server Ready
-                                Wait for Command
-      HELO Fred Secret -->
-                           <--  #13 messages for you
-                                Wait for Command
-      READ 13          -->   
-                           <--  =537 characters in that message
-                                Wait for Command
-      RETR             -->   
-                           <--  (send the message data)
-                                Wait for Command
-      ACKS             -->   
-                           <--  =0 no more messages
-                                Wait for Command
-      QUIT             -->
-                           <--  + OK
-      Close connection --> <--  Close connection
-                                Wait for Connection (go back to start)
-
-Conventions
-
-   Arguments
-
-      These arguments have system specific definitions.
-
-         user - A login account name.
-
-         password - The password for the login account.
-
-         mailbox - A mailbox name (also called a mail folder).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Butler, et. al.                                                 [Page 4]
-
-
-
-RFC 937                                                    February 1985
-Post Office Protocol
-
-
-   Default Mailboxes
-
-      TOPS-20
-
-         MAIL.TXT.1 - from login directory
-
-      UNIX
-
-         both
-            /usr/spool/mail/user
-         and
-            /usr/user/Mail/inbox/*
-
-            where "user" is the user value supplied in the HELO command.
-
-   End of Line
-
-      End of Line is Carriage Return (CR) followed by Line Feed (LF).
-      This sequence is indicated by "CRLF" in this document.  This end
-      of line convention must be used for commands and replies.
-
-   Message Length
-
-      The reply to the READ command or an acknowledgment command (ACKS,
-      ACKD, NACK) is the length (a character count) of the next message
-      to be transmitted.  This includes all the characters in the data
-      transmitted.  CRLF counts as two characters.  A length of zero
-      means the message does not exist or is empty.  A request to
-      transmit a message of zero length will result in the server
-      closing the connection.  The message is transmitted in the
-      standard internet format described in RFC-822 [2] and NVT-ASCII.
-      This may be different from the storage format and may make
-      computing the message length from the stored message non-trivial.
-
-   Message Numbers
-
-      The reply to the HELO and FOLD commands is a count of the number
-      of messages in a the selected mailbox.  The READ command has a
-      message number as an optional argument.  These numbers are
-      decimal, start at one, and computed with respect to the current
-      mailbox.  That is, the first message in a mailbox is message
-      number 1.
-
-   Numbers
-
-      All numbers in this memo and protocol are decimal.
-
-
-
-
-Butler, et. al.                                                 [Page 5]
-
-
-
-RFC 937                                                    February 1985
-Post Office Protocol
-
-
-   Quoting
-
-      In a few cases, there may be a need to have a special character in
-      an argument (user, password, or mailbox) that is not allowed by
-      the syntax.  For example, a space in a password. To allow for
-      this, a quoting convention is defined.  Unfortunately, such
-      quoting conventions "use up" another otherwise uninteresting
-      character.  In this protocol the back slash "\" is used as the
-      quote character.  To include a space in an argument the two
-      character sequence "back-slash, space" is transmitted.  To include
-      a back-slash in an argument the two character sequence
-      "back-slash, back-slash" is transmitted.  This quoting convention
-      is used in the command arguments only, it is not used in the mail
-      data transmitted in response to a RETR command.
-
-   Reply Strings
-
-      The first character is required to be as specified (i.e.,
-      "+", "-", "=", "#").  The optional strings that follow can be
-      whatever the implementer thinks is appropriate.
-
-Definitions of Commands and Replies
-
-   Summary of Commands and Replies
-
-      Commands                          Replies
-      --------                          -------
-      HELO user password                + OK
-      FOLD mailbox                      - Error
-      READ [n]                          #xxx
-      RETR                              =yyy
-      ACKS
-      ACKD
-      NACK
-      QUIT
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Butler, et. al.                                                 [Page 6]
-
-
-
-RFC 937                                                    February 1985
-Post Office Protocol
-
-
-   Commands
-
-      HELO user password
-
-         The Hello command identifies the user to the server and carries
-         the password authenticating this user.  This information is
-         used by the server to control access to the mailboxes.  The
-         Hello command is the "HELO" keyword, followed by the user
-         argument, followed by the password argument, followed by CRLF.
-
-            Possible responses:
-
-               "#nnn"
-
-                  where nnn is the number of messages in the default
-                  mailbox,"
-
-               "- error report" and Close the connection.
-
-      FOLD mailbox
-
-         The Folder command selects another mailbox or mail folder.  The
-         server must check that the user is permitted read access to
-         this mailbox.  If the mailbox is empty or does not exist, the
-         number of messages reported is zero.  The Folder command is the
-         "FOLD" keyword, followed by the mailbox argument, followed by
-         CRLF.
-
-            Possible responses:
-
-               "#nnn"
-
-                  where nnn is the number of messages in this mailbox.
-
-      READ [nnn]
-
-         The Read command begins a message reading transaction.  If the
-         Read command is given without an argument the current message
-         is  implied (the current message indicator is incremented  by
-         the ACKS or ACKD commands).  If an argument is used with the
-         Read command it is the message number to be read, and this
-         command sets the current message indicator to that value.  The
-         server returns the count of characters in the message to be
-         transmitted.  If there is no message to be read, the count of
-         zero is returned.  If the message was previously deleted with
-         the ACKD command, the count of zero is returned.  The Read
-         command is followed by the RETR command, the READ command, the
-         FOLD command, or the QUIT command.  Do not attempt to RETR a
-
-
-Butler, et. al.                                                 [Page 7]
-
-
-
-RFC 937                                                    February 1985
-Post Office Protocol
-
-
-         message of zero characters.  The Read command is the "READ"
-         keyword, optionally followed by the message number argument,
-         followed by CRLF.
-
-            Possible responses:
-
-               "=ccc"
-
-                  where ccc is the number of characters in this message.
-
-      RETR
-
-         The Retrieve command confirms that the client is ready to
-         receive the mail data.  It must be followed by an
-         acknowledgment command.  The server will close the connection
-         if asked to transmit a message of zero characters (i.e.,
-         transmit a non-existent message).  The message is transmitted
-         according to the Internet mail format standard RFC-822 [2] in
-         NVT-ASCII.  The Retrieve command is the "RETR" keyword,
-         followed by CRLF.
-
-            Possible responses:
-
-               the message data
-
-               Close the connection
-
-      ACKS
-
-         The Acknowledge and Save command confirms that the client has
-         received and accepted the message.  The ACKS command ends the
-         message reading transaction.  The message is kept in the
-         mailbox.  The current message indicator is incremented.  The
-         server returns the count of characters in the now current
-         message to be transmitted.  If there is no message to be read
-         or the message is marked deleted, the count of zero is
-         returned.  The Acknowledge and Save command is the "ACKS"
-         keyword, followed by CRLF.
-
-            Possible responses:
-
-               "=ccc"
-
-                  where ccc is the number of characters in the next
-                  message.
-
-
-
-
-
-Butler, et. al.                                                 [Page 8]
-
-
-
-RFC 937                                                    February 1985
-Post Office Protocol
-
-
-      ACKD
-
-         The Acknowledge and Delete command confirms that the client has
-         received and accepted the message.  The ACKD command ends the
-         message reading transaction.  If the user is authorized to have
-         write access to the mailbox, the message is deleted from the
-         mailbox.  Actually, the message is only marked for deletion.
-         The actual change is made  when the mailbox is released at the
-         end of the session or when the client selects another mailbox
-         with the FOLD command.  The messages are not renumbered until
-         the mailbox is released.  If the user does not have write
-         access to the mailbox no change is made to the mailbox.  The
-         response is the same whether or not the message was actually
-         deleted.  The current message indicator is incremented.  The
-         server returns the count of characters in the now current
-         message to be transmitted.  If there is no message to be read
-         or the message is marked deleted, the count of zero is
-         returned.  The Acknowledge and Delete command is the "ACKD"
-         keyword, followed by CRLF.
-
-            Possible responses:
-
-               "=ccc"
-
-                  where ccc is the number of characters in the next
-                  message.
-
-      NACK
-
-         The Negative Acknowledge command reports that the client did
-         not receive the message.  The NACK command ends the message
-         reading transaction.  The message is kept in the mailbox.  The
-         current message indicator remains the same.  The server returns
-         the count of characters in the current message.  Since the
-         count to be returned is for the message just transmitted it the
-         message must exist and not be marked deleted, and the count
-         must be positive (non-zero).  The Negative Acknowledge command
-         is the "NACK" keyword, followed by CRLF.
-
-            Possible responses:
-
-               "=ccc"
-
-                  where ccc is the number of characters in this message.
-
-
-
-
-
-
-Butler, et. al.                                                 [Page 9]
-
-
-
-RFC 937                                                    February 1985
-Post Office Protocol
-
-
-      QUIT
-
-         The Quit command indicates the client is done with the session.
-         The server sends an OK response and then closes the connection.
-         The Quit command is the "QUIT" keyword, followed by CRLF.
-
-            Possible responses:
-
-               "+ OK" and Close the connection
-
-   Replies
-
-      Greeting
-
-         The greeting is sent by the server as soon as the connection is
-         established.  The greeting is a plus sign, followed by the
-         protocol name ("POP2"), followed by the server host name,
-         optionally followed by text, and ending with a CRLF.
-
-      +
-
-         The success or plus sign response indicates successful
-         completion of the operation specified in the command.  The
-         success response is a plus sign, optionally followed by text,
-         and ending with a CRLF.
-
-      -
-
-         The failure or minus sign response indicates the failure of the
-         operation specified in the command.  The failure response is a
-         minus sign, optionally followed by text, and ending with a
-         CRLF.
-
-      =
-
-         The length or equal sign response tells the length in
-         characters of the message referenced by the command.  The
-         length response is a equal sign, followed by a number,
-         optionally followed by text, and ending with a CRLF.
-
-      #
-
-         The count or number sign response tells the number of messages
-         in a folder or mailbox referenced by the command.  The count
-         response is a number sign, followed by a number, optionally
-         followed by text, and ending with a CRLF.
-
-
-
-
-Butler, et. al.                                                [Page 10]
-
-
-
-RFC 937                                                    February 1985
-Post Office Protocol
-
-
-   Timeouts
-
-      In any protocol of this type there have to be timeouts.  Neither
-      side wants to get stuck waiting forever for the other side
-      (particularly is the other side has gone crazy or crashed).
-
-      The client expects a reply to a command fairly quickly and so
-      should have a short timeout for this.  This timeout is called T1.
-
-         For some servers, it may take some processing to compute the
-         number of messages in a mailbox, or the length of a message, or
-         to reformat a stored message for transmission, so this time out
-         has to allow for such processing time.  Also care must be taken
-         not to timeout waiting for the completion of a RETR reply while
-         a long message is in fact being transfered.
-
-      The server expects the session to progress with some but not
-      excessive delay between commands and so should have a long timeout
-      waiting for the next command.  This time out is T2.
-
-         One model of use of this protocol is that any number of
-         different types of clients can be built with different ways of
-         interacting with the human user and the server, but still
-         expecting the client to open the connection to the server,
-         present a sequence of commands, and close the connection,
-         without waiting for intervention by the human user.  With such
-         client implementations, it is reasonable for the server to have
-         a fairly small value for timeout T2.
-
-         On the other hand, one could easily have the client be very
-         human user directed with the user making decisions between
-         commands.  This would cause arbitrary delays between client
-         commands to the server, and require the value of timeout T2 to
-         be quite large.
-
-Implementation Discussion
-
-   Comments on a Server on TOPS-20
-
-      On TOPS-20, a mailbox is a single file.  New messages are appended
-      to the file.  There is a separator line between messages.
-
-      The tricky part of implementing a POP2 server on TOPS-20 is to
-      provide for deleting messages.  This only has to be done for the
-      mailboxes (files) for which the user has write access.  The
-      problem is to avoid both (1) preventing other users from accessing
-      or updating the mailbox for long periods, and (2) accidentally
-      deleting a message the user has not seen.
-
-
-Butler, et. al.                                                [Page 11]
-
-
-
-RFC 937                                                    February 1985
-Post Office Protocol
-
-
-      One suggestion is as follows:
-
-         When a mailbox is first selected, if the user has write access,
-         rename the mailbox file to some temporary name.  Thus new
-         messages will be placed in a new instance of the mailbox file.
-         Conduct all POP2 operation on the temporary mailbox file
-         (including deleting messages).  When the POP2 session is over
-         or another mailbox is selected, prepend any messages left
-         undeleted in the temporary file to the new instance of the
-         mailbox file.
-
-   Sizes
-
-      The maximum length of a command line is 512 characters (including
-      the command word and the CRLF).
-
-      The maximum length of a reply line is 512 characters (including
-      the success indicator (+, -, =, #) and the CRLF).
-
-      The maximum length of a text line is 1000 characters (including
-      CRLF).
-
-   ISI has developed a POP2 server for TOPS-20 and for Berkeley 4.2
-   Unix, and a POP2 client for an IBM-PC and for Berkeley 4.2 Unix.
-
-Extensions Not Supported
-
-   POP2 does not examine the internal data of messages.  In particular,
-   the server does not parse message headers.
-
-   The server doesn't have any state information (i.e., it doesn't know
-   from one session to the next what has happened).  For example, the
-   server doesn't know which messages were received since the last time
-   the user used POP2, so it can't send just the "new" messages.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Butler, et. al.                                                [Page 12]
-
-
-
-RFC 937                                                    February 1985
-Post Office Protocol
-
-
-Examples
-
-   Example 1:
-
-           Client                    Server
-           ------                    ------
-                                Wait for connection
-      Open connection  -->
-                           <--  + POP2 USC-ISIF.ARPA Server
-      HELO POSTEL SECRET -->
-                           <--  #2 messages in your mailbox
-      READ             -->   
-                           <--  =537 characters in message 1
-      RETR             -->   
-                           <--  [data of message 1]
-      ACKD             -->   
-                           <--  =234 characters in message 2
-      RETR             -->   
-                           <--  [data of message 2]
-      ACKD             -->   
-                           <--  =0 no more messages
-      QUIT             -->
-                           <--  + OK, bye, bye
-      Close connection --> <--  Close connection
-                                Go back to start
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Butler, et. al.                                                [Page 13]
-
-
-
-RFC 937                                                    February 1985
-Post Office Protocol
-
-
-   Example 2:
-
-           Client                    Server
-           ------                    ------
-                                Wait for connection
-      Open connection  -->
-                           <--  + POP2 ISI-VAXA.ARPA server here
-      HELO smith secret -->
-                           <--  #35 messages
-      FOLD /usr/spool/mail/smith -->
-                           <--  #27 messages
-      READ  27         -->   
-                           <--  =10123 characters in that message
-      RETR             -->   
-                           <--  [data of message 27]
-      ACKS             -->   
-                           <--  =0 no more messages
-      QUIT             -->
-                           <--  + bye, call again sometime.
-      Close connection --> <--  Close connection
-                                Go back to start
-
-   Example 3:
-
-           Client                    Server
-           ------                    ------
-                                Wait for connection
-      Open connection  -->
-                           <--  + POP2 ISI-VAXA.ARPA server here
-      HELO Jones secret -->
-                           <--  #0 messages
-      READ             -->   
-                           <--  Close connection
-      Close connection -->
-                                Go back to start
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Butler, et. al.                                                [Page 14]
-
-
-
-RFC 937                                                    February 1985
-Post Office Protocol
-
-
-Formal Syntax
-
-   <digit>    = 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
-
-   <letter>   = A | B | C | ... | Z
-                a | b | c | ... | z
-
-   <punct>    = ! | " | # | $ | % | & | ' | ( | ) | * |
-                + | , | - | / | : | < | = | > | ? | @ |
-                [ | ] | ^ | _ | ` | { | | | } | ~
-
-   <quote>    = \
-
-   <any>      = any one of the 128 ASCII codes
-
-   <CR>       = carriage return, code 10
-
-   <LF>       = line feed, code 13
-
-   <SP>       = space, code 32
-
-   <CRLF>     = <CR> <LF>
-
-   <print>    = <letter> | <digit> | <punct> | <quote> <any>
-
-   <char>     = <print> | <SP>
-
-   <word>     = <print> | <print> <word>
-
-   <string>   = <char> | <char> <string>
-
-   <ld>       = <letter> | <digit>
-
-   <ldh>      = <letter> | <digit> | -
-
-   <ldhs>     = <ldh> | <ldh> <ldhs>
-
-   <name>     = <letter> [ [ <ldhs> ] <ld> ]
-
-   <host>     =  <name> | <name> . <host>
-
-   <user>     = <word>
-
-   <password> = <word>
-
-   <mailbox>  = <string>
-
-   <number>   = <digit> | <digit> <number>
-
-
-Butler, et. al.                                                [Page 15]
-
-
-
-RFC 937                                                    February 1985
-Post Office Protocol
-
-
-   <helo>     = HELO <SP> <user> <SP> <password> <CRLF>
-
-   <fold>     = FOLD <SP> <mailbox> <CRLF>
-
-   <read>     = READ [<SP> <number>] <CRLF>
-
-   <retr>     = RETR <CRLF>
-
-   <acks>     = ACKS <CRLF>
-
-   <ackd>     = ACKD <CRLF>
-
-   <nack>     = NACK <CRLF>
-
-   <quit>     = QUIT <CRLF>
-
-   <ok>       = + [<SP> <string>] <CRLF>
-
-   <err>      = - [<SP> <string>] <CRLF>
-
-   <count>    = # <number> [<SP> <string>] <CRLF>
-
-   <greet>    = + <SP> POP2 <SP> <host> [<SP> <string>] <CRLF>
-
-   <length>   = = <number> [<SP> <string>] <CRLF>
-
-   <command>  = <helo> | <fold> | <read> | <retr> |
-                <acks> | <ackd> | <nack> | <quit>
-
-   <reply>    = <ok> | <err> | <count> | <length> | <greet>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Butler, et. al.                                                [Page 16]
-
-
-
-RFC 937                                                    February 1985
-Post Office Protocol
-
-
-Client State Diagram
-
-   
-                          |                    ^  + BYE  
-                          |  Open              |  -----  
-                          |           Greet    |  Close  
-                          V           -----    |         
-                      +-------+       QUIT    +-------+  
-                      | CALL  |-------------->| EXIT  |  
-                      +-------+               +-------+  
-                          |                       ^      
-                          |  Greet                |      
-                          |  -----                |      
-                          |  HELO                 |      
-              +---->+     |                       |      
-        #NNN  ^     |     |        #NNN           |      
-        ----  |     V     V        ----           |      
-        FOLD  |    +-------+       QUIT           |      
-              +<---| NMBR  |--------------------->+      
-                   +-------+                      ^      
-                    ^     |                       |      
-                    |     |  #NNN                 |      
-                    |     |  ----                 |      
-              =CCC  |     |  READ                 |      
-              ----  |     |                       |      
-              FOLD  |     |        =CCC           |      
-                    |     V        ----           |      
-        =CCC  +--->+-------+       QUIT           |      
-        ----  ^    | SIZE  |--------------------->+      
-        READ  +<---+-------+                             
-                    ^     |                              
-                    |     |  =CCC                        
-              data  |     |  ----                        
-              ----  |     |  RETR                        
-              ack   |     |                              
-                    |     V                              
-                   +-------+                             
-                   | XFER  |                             
-                   +-------+                             
-   
-
-
-
-
-
-
-
-
-
-
-Butler, et. al.                                                [Page 17]
-
-
-
-RFC 937                                                    February 1985
-Post Office Protocol
-
-
-Server State Diagram
-
-   
-                       +<----------------------+  Close  
-                       |                       |  -----  
-               Listen  |                       |  Close  
-                       V                       |         
-                   +-------+                  +-------+  
-                   | LSTN  |                  | DONE  |  
-                   +-------+                  +-------+  
-                       |                          ^      
-                       |  Open                    |      
-                       |  -----                   |      
-                       |  Greet                   |      
-                       |                          |      
-                       |           QUIT           |      
-                       V           -----          |      
-                   +-------+       + BYE          |      
-                   | AUTH  |--------------------->+      
-                   +-------+                      ^      
-                       |                          |      
-                       |  HELO                    |      
-                       |  ----                    |      
-                       |  #NNN                    |      
-                       |                          |      
-                       |           QUIT           |      
-                       V           -----          |      
-        FOLD  +--->+-------+       + BYE          |      
-        ----  ^    | MBOX  |--------------------->+      
-        #NNN  +<---+-------+                      ^      
-                    ^     |                       |      
-                    |     |  READ                 |      
-              FOLD  |     |  ----                 |      
-              ----  |     |  =CCC                 |      
-              #NNN  |     |        QUIT           |      
-                    |     V        -----          |      
-        READ  +--->+-------+       + BYE          |      
-        ----  ^    | ITEM  |--------------------->+      
-        =CCC  +<---+-------+                             
-                    ^     |                              
-                    |     |  RETR                        
-              ack   |     |  ----                        
-              ----  |     |  data                        
-              =CCC  |     |                              
-                    |     V                              
-                   +-------+                             
-                   | NEXT  |                             
-                   +-------+                             
-
-
-Butler, et. al.                                                [Page 18]
-
-
-
-RFC 937                                                    February 1985
-Post Office Protocol
-
-
-Combined Flow Diagram
-
-   
-   +----+                                                              
-   |CALL|<------------------------------------------------------------+
-   |LSTN|                                                             ^
-   +----+                                                             |
-    | Greet                                                           |
-    |                                                                 |
-    |  +----------------------------------------------------->+       |
-    |  ^ QUIT                                                 |       |
-    V  |                                                      V       |
-   +----+        +----+                                      +----+   |
-   |CALL| HELO   |NMBR|                                      |EXIT|   |
-   |AUTH|------->|AUTH|                                      |AUTH|   |
-   +----+        +----+                                      +----+   |
-                  | #NNN                                   + Bye |    |
-                  |                                              |    |
-                  |  +------------------------------------>+     |    |
-                  |  ^ QUIT                                |     |    |
-                  V  |                                     V     |    |
-            +--->+----+        +----+                     +----+ |    |
-       FOLD ^    |NMBR| READ   |SIZE|                     |EXIT| |    |
-       ---- |    |MBOX|------->|MBOX|                     |MBOX| |    |
-       #NNN +<---+----+        +----+                     +----+ |    |
-                     ^           | =CCC                 + Bye |  |    |
-                     |           |                            |  |    |
-                FOLD +<--------+ | +------------------->+     |  |    |
-                ----           ^ | ^ QUIT               |     |  |    |
-                #NNN           | V |                    V     |  |    |
-                         +--->+-----+        +----+    +----+ |  |    |
-                    READ ^    |SIZE | RETR   |XFER|    |EXIT| |  |    |
-                    ---- |    | ITEM|------->|ITEM|    |ITEM| |  |    |
-                    =CCC +<---+-----+        +----+    +----+ |  |    |
-                                 ^             | data      |  |  |    |
-                                 |             |           |  |  |    |
-                            =CCC |             V     + Bye |  |  |    |
-                               +----+        +----+        |  |  |    |
-                               |SIZE|    Ack |XFER|        |  |  |    |
-                               |NEXT|<-------|NEXT|        |  |  |    |
-                               +----+        +----+        |  |  |    |
-                                                           |  |  |    |
-                                                           |  |  |    |
-                                                           V  V  V    |
-                                                          +-------+   |
-                                                          | EXIT  |-->+
-                                                          | DONE  |    
-                                                          +-------+    
-
-
-Butler, et. al.                                                [Page 19]
-
-
-
-RFC 937                                                    February 1985
-Post Office Protocol
-
-
-Client Decision Table
-
-   
-          |            STATE                 |
-   -------+----------------------------------|
-   INPUT  | CALL | NMBR | SIZE | XFER | EXIT |
-   -------+----------------------------------|
-   Greet  |  2   |  1   |  1   |  1   |  6   |
-   -------+----------------------------------|
-   #NNN   |  1   |  3   |  1   |  1   |  6   |
-   -------+----------------------------------|
-   =CCC   |  1   |  1   |  4   |  1   |  6   |
-   -------+----------------------------------|
-   data   |  1   |  1   |  1   |  5   |  6   |
-   -------+----------------------------------|
-   + Bye  |  1   |  1   |  1   |  1   |  6   |
-   -------+----------------------------------|
-   Close  |  1   |  1   |  1   |  1   |  6   |
-   -------+----------------------------------|
-   other  |  1   |  1   |  1   |  1   |  6   |
-   -------+----------------------------------|
-   Timeout|  1   |  1   |  1   |  1   |  6   |
-   -------+----------------------------------|
-   
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Butler, et. al.                                                [Page 20]
-
-
-
-RFC 937                                                    February 1985
-Post Office Protocol
-
-
-   Actions:
-
-      1.  This is garbage.  Send "QUIT", and go to EXIT state.
-
-      2.  (a) If the greeting is right then send "HELO"
-              and go to NMBR state,
-          (b) Else send "QUIT" and go to EXIT state.
-
-      3.  (a) If user wants this folder and NNN > 0
-              then send "READ" and go to SIZE state,
-          (b) If user wants a this folder and NNN = 0
-              then send "QUIT" and go to EXIT state,
-          (c) If user wants a different folder
-              then send "FOLD" and go to NMBR state.
-
-      4.  (a) If user wants this message and CCC > 0
-              then send "RETR" and go to XFER state,
-          (b) If user wants a this message and CCC = 0
-              then send "QUIT" and go to EXIT state,
-          (c) If user wants a different message
-              then send "READ" and go to SIZE state.
-
-      5.  (a) If user wants this message kept
-              then send "ACKS" and go to SIZE state,
-          (b) If user wants a this message deleted
-              then send "ACKD" and go to SIZE state,
-          (c) If user wants a this message again
-              then send "NACK" and go to SIZE state.
-
-      6.  Close the connection.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Butler, et. al.                                                [Page 21]
-
-
-
-RFC 937                                                    February 1985
-Post Office Protocol
-
-
-Server Decision Table
-
-   
-          |              STATE                       
-   -------+----------------------------------------- 
-   INPUT  | LSTN | AUTH | MBOX | ITEM | NEXT | DONE |
-   -------+-----------------------------------------|
-   Open   |  2   |  1   |  1   |  1   |  1   |  1   |
-   -------+-----------------------------------------|
-   HELO   |  1   |  3   |  1   |  1   |  1   |  1   |
-   -------+-----------------------------------------|
-   FOLD   |  1   |  1   |  5   |  5   |  1   |  1   |
-   -------+-----------------------------------------|
-   READ   |  1   |  1   |  6   |  6   |  1   |  1   |
-   -------+-----------------------------------------|
-   RETR   |  1   |  1   |  1   |  7   |  1   |  1   |
-   -------+-----------------------------------------|
-   ACKS   |  1   |  1   |  1   |  1   |  8   |  1   |
-   -------+-----------------------------------------|
-   ACKD   |  1   |  1   |  1   |  1   |  8   |  1   |
-   -------+-----------------------------------------|
-   NACK   |  1   |  1   |  1   |  1   |  8   |  1   |
-   -------+-----------------------------------------|
-   QUIT   |  1   |  4   |  4   |  4   |  1   |  1   |
-   -------+-----------------------------------------|
-   Close  |  1   |  1   |  1   |  1   |  1   |  9   |
-   -------+-----------------------------------------|
-   other  |  1   |  1   |  1   |  1   |  1   |  1   |
-   -------+-----------------------------------------|
-   Timeout|      |  1   |  1   |  1   |  1   |  1   |
-   -------+-----------------------------------------|
-   
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Butler, et. al.                                                [Page 22]
-
-
-
-RFC 937                                                    February 1985
-Post Office Protocol
-
-
-   Actions:
-
-      1.  This is garbage.  Send "- error", and Close the connection.
-
-      2.  Send the greeting. Go to AUTH state.
-
-      3.  (a) If authorized user then send "#NNN" and go tp MBOX state,
-          (b) Else send "- error" and Close the connection.
-
-      4.  Send "+ Bye" and go to DONE state.
-
-      5.  Send "+NNN" and go to MBOX state.
-
-      6.  Send "=CCC" and go to ITEM state.
-
-      7.  If message exists then send the data and got to NEXT state,
-          Else Close the connection.
-
-      8.  Do what ACKS/ACKD/NACK require and go to ITEM state.
-
-      9.  Close the connection.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Butler, et. al.                                                [Page 23]
-
-
-
-RFC 937                                                    February 1985
-Post Office Protocol
-
-
-Acknowledgment
-
-   We would like to acknowledge the helpful comments that we received on
-   the first version of POP described in RFC 918, and the draft of POP2
-   distributed to interested parties.
-
-References
-
-   [1]  Postel, J., "Simple Mail Transfer Protocol", RFC 821,
-   USC/Information Sciences Institute, August 1982.
-
-   [2]  Crocker, D., "Standard for the Format of ARPA-Internet Text
-   Messages", RFC 822, University of Delaware, August 1982.
-
-   [3]  Reynolds, J.K., "Post Office Protocol", RFC 918, USC/Information
-   Sciences Institute, October 1984.
-
-   [4]  Reynolds, J.K., and J. Postel, "Assigned Numbers", RFC 923,
-   USC/Information Sciences Institute, October 1984.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Butler, et. al.                                                [Page 24]
-
diff --git a/RFC/rfc977.txt b/RFC/rfc977.txt
deleted file mode 100644
index 0f965c48..00000000
--- a/RFC/rfc977.txt
+++ /dev/null
@@ -1,1539 +0,0 @@
-
-
-Network Working Group                      Brian Kantor (U.C. San Diego)
-Request for Comments: 977                   Phil Lapsley (U.C. Berkeley)
-                                                           February 1986
-
-                     Network News Transfer Protocol
-                                    
-                A Proposed Standard for the Stream-Based
-                          Transmission of News
-
-Status of This Memo
-
-   NNTP specifies a protocol for the distribution, inquiry, retrieval,
-   and posting of news articles using a reliable stream-based
-   transmission of news among the ARPA-Internet community.  NNTP is
-   designed so that news articles are stored in a central database
-   allowing a subscriber to select only those items he wishes to read.
-   Indexing, cross-referencing, and expiration of aged messages are also
-   provided. This RFC suggests a proposed protocol for the ARPA-Internet
-   community, and requests discussion and suggestions for improvements.
-   Distribution of this memo is unlimited.
-
-1.  Introduction
-
-   For many years, the ARPA-Internet community has supported the
-   distribution of bulletins, information, and data in a timely fashion
-   to thousands of participants.  We collectively refer to such items of
-   information as "news".  Such news provides for the rapid
-   dissemination of items of interest such as software bug fixes, new
-   product reviews, technical tips, and programming pointers, as well as
-   rapid-fire discussions of matters of concern to the working computer
-   professional. News is very popular among its readers.
-
-   There are popularly two methods of distributing such news: the
-   Internet method of direct mailing, and the USENET news system.
-
-1.1.  Internet Mailing Lists
-
-   The Internet community distributes news by the use of mailing lists.
-   These are lists of subscriber's mailbox addresses and remailing
-   sublists of all intended recipients.  These mailing lists operate by
-   remailing a copy of the information to be distributed to each
-   subscriber on the mailing list.  Such remailing is inefficient when a
-   mailing list grows beyond a dozen or so people, since sending a
-   separate copy to each of the subscribers occupies large quantities of
-   network bandwidth, CPU resources, and significant amounts of disk
-   storage at the destination host.  There is also a significant problem
-   in maintenance of the list itself: as subscribers move from one job
-   to another; as new subscribers join and old ones leave; and as hosts
-   come in and out of service.
-
-
-
-
-Kantor & Lapsley                                                [Page 1]
-
-
-
-RFC 977                                                    February 1986
-Network News Transfer Protocol
-
-
-1.2.  The USENET News System
-
-   Clearly, a worthwhile reduction of the amount of these resources used
-   can be achieved if articles are stored in a central database on the
-   receiving host instead of in each subscriber's mailbox. The USENET
-   news system provides a method of doing just this.  There is a central
-   repository of the news articles in one place (customarily a spool
-   directory of some sort), and a set of programs that allow a
-   subscriber to select those items he wishes to read.  Indexing,
-   cross-referencing, and expiration of aged messages are also provided.
-
-1.3.  Central Storage of News
-
-   For clusters of hosts connected together by fast local area networks
-   (such as Ethernet), it makes even more sense to consolidate news
-   distribution onto one (or a very few) hosts, and to allow access to
-   these news articles using a server and client model.  Subscribers may
-   then request only the articles they wish to see, without having to
-   wastefully duplicate the storage of a copy of each item on each host.
-
-1.4.  A Central News Server
-
-   A way to achieve these economies is to have a central computer system
-   that can provide news service to the other systems on the local area
-   network.  Such a server would manage the collection of news articles
-   and index files, with each person who desires to read news bulletins
-   doing so over the LAN.  For a large cluster of computer systems, the
-   savings in total disk space is clearly worthwhile.  Also, this allows
-   workstations with limited disk storage space to participate in the
-   news without incoming items consuming oppressive amounts of the
-   workstation's disk storage.
-
-   We have heard rumors of somewhat successful attempts to provide
-   centralized news service using IBIS and other shared or distributed
-   file systems.  While it is possible that such a distributed file
-   system implementation might work well with a group of similar
-   computers running nearly identical operating systems, such a scheme
-   is not general enough to offer service to a wide range of client
-   systems, especially when many diverse operating systems may be in use
-   among a group of clients.  There are few (if any) shared or networked
-   file systems that can offer the generality of service that stream
-   connections using Internet TCP provide, particularly when a wide
-   range of host hardware and operating systems are considered.
-
-   NNTP specifies a protocol for the distribution, inquiry, retrieval,
-   and posting of news articles using a reliable stream (such as TCP)
-   server-client model. NNTP is designed so that news articles need only
-
-
-Kantor & Lapsley                                                [Page 2]
-
-
-
-RFC 977                                                    February 1986
-Network News Transfer Protocol
-
-
-   be stored on one (presumably central) host, and subscribers on other
-   hosts attached to the LAN may read news articles using stream
-   connections to the news host.
-
-   NNTP is modelled upon the news article specifications in RFC 850,
-   which describes the USENET news system.  However, NNTP makes few
-   demands upon the structure, content, or storage of news articles, and
-   thus we believe it easily can be adapted to other non-USENET news
-   systems.
-
-   Typically, the NNTP server runs as a background process on one host,
-   and would accept connections from other hosts on the LAN.  This works
-   well when there are a number of small computer systems (such as
-   workstations, with only one or at most a few users each), and a large
-   central server.
-
-1.5.  Intermediate News Servers
-
-   For clusters of machines with many users (as might be the case in a
-   university or large industrial environment), an intermediate server
-   might be used.  This intermediate or "slave" server runs on each
-   computer system, and is responsible for mediating news reading
-   requests and performing local caching of recently-retrieved news
-   articles.
-
-   Typically, a client attempting to obtain news service would first
-   attempt to connect to the news service port on the local machine.  If
-   this attempt were unsuccessful, indicating a failed server, an
-   installation might choose to either deny news access, or to permit
-   connection to the central "master" news server.
-
-   For workstations or other small systems, direct connection to the
-   master server would probably be the normal manner of operation.
-
-   This specification does not cover the operation of slave NNTP
-   servers.  We merely suggest that slave servers are a logical addition
-   to NNTP server usage which would enhance operation on large local
-   area networks.
-
-1.6.  News Distribution
-
-   NNTP has commands which provide a straightforward method of
-   exchanging articles between cooperating hosts. Hosts which are well
-   connected on a local area or other fast network and who wish to
-   actually obtain copies of news articles for local storage might well
-   find NNTP to be a more efficient way to distribute news than more
-   traditional transfer methods (such as UUCP).
-
-
-Kantor & Lapsley                                                [Page 3]
-
-
-
-RFC 977                                                    February 1986
-Network News Transfer Protocol
-
-
-   In the traditional method of distributing news articles, news is
-   propagated from host to host by flooding - that is, each host will
-   send all its new news articles on to each host that it feeds.  These
-   hosts will then in turn send these new articles on to other hosts
-   that they feed.  Clearly, sending articles that a host already has
-   obtained a copy of from another feed (many hosts that receive news
-   are redundantly fed) again is a waste of time and communications
-   resources, but for transport mechanisms that are single-transaction
-   based rather than interactive (such as UUCP in the UNIX-world <1>),
-   distribution time is diminished by sending all articles and having
-   the receiving host simply discard the duplicates.  This is an
-   especially true when communications sessions are limited to once a
-   day.
-
-   Using NNTP, hosts exchanging news articles have an interactive
-   mechanism for deciding which articles are to be transmitted.  A host
-   desiring new news, or which has new news to send, will typically
-   contact one or more of its neighbors using NNTP.  First it will
-   inquire if any new news groups have been created on the serving host
-   by means of the NEWGROUPS command.  If so, and those are appropriate
-   or desired (as established by local site-dependent rules), those new
-   newsgroups can be created.
-
-   The client host will then inquire as to which new articles have
-   arrived in all or some of the newsgroups that it desires to receive,
-   using the NEWNEWS command.  It will receive a list of new articles
-   from the server, and can request transmission of those articles that
-   it desires and does not already have.
-
-   Finally, the client can advise the server of those new articles which
-   the client has recently received.  The server will indicate those
-   articles that it has already obtained copies of, and which articles
-   should be sent to add to its collection.
-
-   In this manner, only those articles which are not duplicates and
-   which are desired are transferred.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kantor & Lapsley                                                [Page 4]
-
-
-
-RFC 977                                                    February 1986
-Network News Transfer Protocol
-
-
-2.  The NNTP Specification
-
-2.1.  Overview
-
-   The news server specified by this document uses a stream connection
-   (such as TCP) and SMTP-like commands and responses.  It is designed
-   to accept connections from hosts, and to provide a simple interface
-   to the news database.
-
-   This server is only an interface between programs and the news
-   databases. It does not perform any user interaction or presentation-
-   level functions. These "user-friendly" functions are better left to
-   the client programs, which have a better understanding of the
-   environment in which they are operating.
-
-   When used via Internet TCP, the contact port assigned for this
-   service is 119.
-
-2.2.  Character Codes
-
-   Commands and replies are composed of characters from the ASCII
-   character set.  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.
-
-2.3.  Commands
-
-   Commands consist of a command word, which in some cases may be
-   followed by a parameter.  Commands with parameters must separate the
-   parameters from each other and from the command by one or more space
-   or tab characters.  Command lines must be complete with all required
-   parameters, and may not contain more than one command.
-
-   Commands and command parameters are not case sensitive. That is, a
-   command or parameter word may be upper case, lower case, or any
-   mixture of upper and lower case.
-
-   Each command line must be terminated by a CR-LF (Carriage Return -
-   Line Feed) pair.
-
-   Command lines shall not exceed 512 characters in length, counting all
-   characters including spaces, separators, punctuation, and the
-   trailing CR-LF (thus there are 510 characters maximum allowed for the
-   command and its parameters).  There is no provision for continuation
-   command lines.
-
-
-
-
-Kantor & Lapsley                                                [Page 5]
-
-
-
-RFC 977                                                    February 1986
-Network News Transfer Protocol
-
-
-2.4.  Responses
-
-   Responses are of two kinds, textual and status.
-
-2.4.1.  Text Responses
-
-   Text is sent only after a numeric status response line has been sent
-   that indicates that text will follow.  Text is sent as a series of
-   successive lines of textual matter, each terminated with CR-LF pair.
-   A single line containing only a period (.) is sent to indicate the
-   end of the text (i.e., the server will send a CR-LF pair at the end
-   of the last line of text, a period, and another CR-LF pair).
-
-   If the text contained a period as the first character of the text
-   line in the original, that first period is doubled.  Therefore, the
-   client must examine the first character of each line received, and
-   for those beginning with a period, determine either that this is the
-   end of the text or whether to collapse the doubled period to a single
-   one.
-
-   The intention is that text messages will usually be displayed on the
-   user's terminal whereas command/status responses will be interpreted
-   by the client program before any possible display is done.
-
-2.4.2.  Status Responses
-
-   These are status reports from the server and indicate the response to
-   the last command received from the client.
-
-   Status response lines begin with a 3 digit numeric code which is
-   sufficient to distinguish all responses.  Some of these may herald
-   the subsequent transmission of text.
-
-   The first digit of the response broadly indicates the success,
-   failure, or progress of the previous command.
-
-      1xx - Informative message
-      2xx - Command ok
-      3xx - Command ok so far, send the rest of it.
-      4xx - Command was correct, but couldn't be performed for
-            some reason.
-      5xx - Command unimplemented, or incorrect, or a serious
-            program error occurred.
-
-
-
-
-
-
-Kantor & Lapsley                                                [Page 6]
-
-
-
-RFC 977                                                    February 1986
-Network News Transfer Protocol
-
-
-   The next digit in the code indicates the function response category.
-
-      x0x - Connection, setup, and miscellaneous messages
-      x1x - Newsgroup selection
-      x2x - Article selection
-      x3x - Distribution functions
-      x4x - Posting
-      x8x - Nonstandard (private implementation) extensions
-      x9x - Debugging output
-
-   The exact response codes that should be expected from each command
-   are detailed in the description of that command.  In addition, below
-   is listed a general set of response codes that may be received at any
-   time.
-
-   Certain status responses contain parameters such as numbers and
-   names. The number and type of such parameters is fixed for each
-   response code to simplify interpretation of the response.
-
-   Parameters are separated from the numeric response code and from each
-   other by a single space. All numeric parameters are decimal, and may
-   have leading zeros. All string parameters begin after the separating
-   space, and end before the following separating space or the CR-LF
-   pair at the end of the line. (String parameters may not, therefore,
-   contain spaces.) All text, if any, in the response which is not a
-   parameter of the response must follow and be separated from the last
-   parameter by a space.  Also, note that the text following a response
-   number may vary in different implementations of the server. The
-   3-digit numeric code should be used to determine what response was
-   sent.
-
-   Response codes not specified in this standard may be used for any
-   installation-specific additional commands also not specified. These
-   should be chosen to fit the pattern of x8x specified above.  (Note
-   that debugging is provided for explicitly in the x9x response codes.)
-   The use of unspecified response codes for standard commands is
-   prohibited.
-
-   We have provided a response pattern x9x for debugging.  Since much
-   debugging output may be classed as "informative messages", we would
-   expect, therefore, that responses 190 through 199 would be used for
-   various debugging outputs.  There is no requirement in this
-   specification for debugging output, but if such is provided over the
-   connected stream, it must use these response codes.  If appropriate
-   to a specific implementation, other x9x codes may be used for
-   debugging.  (An example might be to use e.g., 290 to acknowledge a
-   remote debugging request.)
-
-
-Kantor & Lapsley                                                [Page 7]
-
-
-
-RFC 977                                                    February 1986
-Network News Transfer Protocol
-
-
-2.4.3.  General Responses
-
-   The following is a list of general response codes that may be sent by
-   the NNTP server.  These are not specific to any one command, but may
-   be returned as the result of a connection, a failure, or some unusual
-   condition.
-
-   In general, 1xx codes may be ignored or displayed as desired;  code
-   200 or 201 is sent upon initial connection to the NNTP server
-   depending upon posting permission; code 400 will be sent when the
-   NNTP server discontinues service (by operator request, for example);
-   and 5xx codes indicate that the command could not be performed for
-   some unusual reason.
-
-      100 help text
-      190
-        through
-      199 debug output
-
-      200 server ready - posting allowed
-      201 server ready - no posting allowed
-
-      400 service discontinued
-
-      500 command not recognized
-      501 command syntax error
-      502 access restriction or permission denied
-      503 program fault - command not performed
-
-3.  Command and Response Details
-
-   On the following pages are descriptions of each command recognized by
-   the NNTP server and the responses which will be returned by those
-   commands.
-
-   Each command is shown in upper case for clarity, although case is
-   ignored in the interpretation of commands by the NNTP server.  Any
-   parameters are shown in lower case.  A parameter shown in [square
-   brackets] is optional.  For example, [GMT] indicates that the
-   triglyph GMT may present or omitted.
-
-   Every command described in this section must be implemented by all
-   NNTP servers.
-
-
-
-
-
-
-Kantor & Lapsley                                                [Page 8]
-
-
-
-RFC 977                                                    February 1986
-Network News Transfer Protocol
-
-
-   There is no prohibition against additional commands being added;
-   however, it is recommended that any such unspecified command begin
-   with the letter "X" to avoid conflict with later revisions of this
-   specification.
-
-   Implementors are reminded that such additional commands may not
-   redefine specified status response codes.  Using additional
-   unspecified responses for standard commands is also prohibited.
-
-3.1.  The ARTICLE, BODY, HEAD, and STAT commands
-
-   There are two forms to the ARTICLE command (and the related BODY,
-   HEAD, and STAT commands), each using a different method of specifying
-   which article is to be retrieved.  When the ARTICLE command is
-   followed by a message-id in angle brackets ("<" and ">"), the first
-   form of the command is used; when a numeric parameter or no parameter
-   is supplied, the second form is invoked.
-
-   The text of the article is returned as a textual response, as
-   described earlier in this document.
-
-   The HEAD and BODY commands are identical to the ARTICLE command
-   except that they respectively return only the header lines or text
-   body of the article.
-
-   The STAT command is similar to the ARTICLE command except that no
-   text is returned.  When selecting by message number within a group,
-   the STAT command serves to set the current article pointer without
-   sending text. The returned acknowledgement response will contain the
-   message-id, which may be of some value.  Using the STAT command to
-   select by message-id is valid but of questionable value, since a
-   selection by message-id does NOT alter the "current article pointer".
-
-3.1.1.  ARTICLE (selection by message-id)
-
-   ARTICLE <message-id>
-
-   Display the header, a blank line, then the body (text) of the
-   specified article.  Message-id is the message id of an article as
-   shown in that article's header.  It is anticipated that the client
-   will obtain the message-id from a list provided by the NEWNEWS
-   command, from references contained within another article, or from
-   the message-id provided in the response to some other commands.
-
-   Please note that the internally-maintained "current article pointer"
-   is NOT ALTERED by this command. This is both to facilitate the
-   presentation of articles that may be referenced within an article
-
-
-Kantor & Lapsley                                                [Page 9]
-
-
-
-RFC 977                                                    February 1986
-Network News Transfer Protocol
-
-
-   being read, and because of the semantic difficulties of determining
-   the proper sequence and membership of an article which may have been
-   posted to more than one newsgroup.
-
-3.1.2.  ARTICLE (selection by number)
-
-   ARTICLE [nnn]
-
-   Displays the header, a blank line, then the body (text) of the
-   current or specified article.  The optional parameter nnn is the
-
-   numeric id of an article in the current newsgroup and must be chosen
-   from the range of articles provided when the newsgroup was selected.
-   If it is omitted, the current article is assumed.
-
-   The internally-maintained "current article pointer" is set by this
-   command if a valid article number is specified.
-
-   [the following applies to both forms of the article command.] A
-   response indicating the current article number, a message-id string,
-   and that text is to follow will be returned.
-
-   The message-id string returned is an identification string contained
-   within angle brackets ("<" and ">"), which is derived from the header
-   of the article itself.  The Message-ID header line (required by
-   RFC850) from the article must be used to supply this information. If
-   the message-id header line is missing from the article, a single
-   digit "0" (zero) should be supplied within the angle brackets.
-
-   Since the message-id field is unique with each article, it may be
-   used by a news reading program to skip duplicate displays of articles
-   that have been posted more than once, or to more than one newsgroup.
-
-3.1.3.  Responses
-
-   220 n <a> article retrieved - head and body follow
-           (n = article number, <a> = message-id)
-   221 n <a> article retrieved - head follows
-   222 n <a> article retrieved - body follows
-   223 n <a> article retrieved - request text separately
-   412 no newsgroup has been selected
-   420 no current article has been selected
-   423 no such article number in this group
-   430 no such article found
-
-
-
-
-
-Kantor & Lapsley                                               [Page 10]
-
-
-
-RFC 977                                                    February 1986
-Network News Transfer Protocol
-
-
-3.2.  The GROUP command
-
-3.2.1.  GROUP
-
-   GROUP ggg
-
-   The required parameter ggg is the name of the newsgroup to be
-   selected (e.g. "net.news").  A list of valid newsgroups may be
-   obtained from the LIST command.
-
-   The successful selection response will return the article numbers of
-   the first and last articles in the group, and an estimate of the
-   number of articles on file in the group.  It is not necessary that
-   the estimate be correct, although that is helpful; it must only be
-   equal to or larger than the actual number of articles on file.  (Some
-   implementations will actually count the number of articles on file.
-   Others will just subtract first article number from last to get an
-   estimate.)
-
-   When a valid group is selected by means of this command, the
-   internally maintained "current article pointer" is set to the first
-   article in the group.  If an invalid group is specified, the
-   previously selected group and article remain selected.  If an empty
-   newsgroup is selected, the "current article pointer" is in an
-   indeterminate state and should not be used.
-
-   Note that the name of the newsgroup is not case-dependent.  It must
-   otherwise match a newsgroup obtained from the LIST command or an
-   error will result.
-
-3.2.2.  Responses
-
-   211 n f l s group selected
-           (n = estimated number of articles in group,
-           f = first article number in the group,
-           l = last article number in the group,
-           s = name of the group.)
-   411 no such news group
-
-
-
-
-
-
-
-
-
-
-
-Kantor & Lapsley                                               [Page 11]
-
-
-
-RFC 977                                                    February 1986
-Network News Transfer Protocol
-
-
-3.3.  The HELP command
-
-3.3.1.  HELP
-
-   HELP
-
-   Provides a short summary of commands that are understood by this
-   implementation of the server. The help text will be presented as a
-   textual response, terminated by a single period on a line by itself.
-
-   3.3.2.  Responses
-
-   100 help text follows
-
-3.4.  The IHAVE command
-
-3.4.1.  IHAVE
-
-   IHAVE <messageid>
-
-   The IHAVE command informs the server that the client has an article
-   whose id is <messageid>.  If the server desires a copy of that
-   article, it will return a response instructing the client to send the
-   entire article.  If the server does not want the article (if, for
-   example, the server already has a copy of it), a response indicating
-   that the article is not wanted will be returned.
-
-   If transmission of the article is requested, the client should send
-   the entire article, including header and body, in the manner
-   specified for text transmission from the server. A response code
-   indicating success or failure of the transferral of the article will
-   be returned.
-
-   This function differs from the POST command in that it is intended
-   for use in transferring already-posted articles between hosts.
-   Normally it will not be used when the client is a personal
-   newsreading program.  In particular, this function will invoke the
-   server's news posting program with the appropriate settings (flags,
-   options, etc) to indicate that the forthcoming article is being
-   forwarded from another host.
-
-   The server may, however, elect not to post or forward the article if
-   after further examination of the article it deems it inappropriate to
-   do so.  The 436 or 437 error codes may be returned as appropriate to
-   the situation.
-
-   Reasons for such subsequent rejection of an article may include such
-
-
-Kantor & Lapsley                                               [Page 12]
-
-
-
-RFC 977                                                    February 1986
-Network News Transfer Protocol
-
-
-   problems as inappropriate newsgroups or distributions, disk space
-   limitations, article lengths, garbled headers, and the like.  These
-   are typically restrictions enforced by the server host's news
-   software and not necessarily the NNTP server itself.
-
-3.4.2.  Responses
-
-   235 article transferred ok
-   335 send article to be transferred.  End with <CR-LF>.<CR-LF>
-   435 article not wanted - do not send it
-   436 transfer failed - try again later
-   437 article rejected - do not try again
-
-   An implementation note:
-
-   Because some host news posting software may not be able to decide
-   immediately that an article is inappropriate for posting or
-   forwarding, it is acceptable to acknowledge the successful transfer
-   of the article and to later silently discard it.  Thus it is
-   permitted to return the 235 acknowledgement code and later discard
-   the received article.  This is not a fully satisfactory solution to
-   the problem.  Perhaps some implementations will wish to send mail to
-   the author of the article in certain of these cases.
-
-3.5.  The LAST command
-
-3.5.1.  LAST
-
-   LAST
-
-   The internally maintained "current article pointer" is set to the
-   previous article in the current newsgroup.  If already positioned at
-   the first article of the newsgroup, an error message is returned and
-   the current article remains selected.
-
-   The internally-maintained "current article pointer" is set by this
-   command.
-
-   A response indicating the current article number, and a message-id
-   string will be returned.  No text is sent in response to this
-   command.
-
-3.5.2.  Responses
-
-   223 n a article retrieved - request text separately
-           (n = article number, a = unique article id)
-
-
-
-Kantor & Lapsley                                               [Page 13]
-
-
-
-RFC 977                                                    February 1986
-Network News Transfer Protocol
-
-
-   412 no newsgroup selected
-   420 no current article has been selected
-   422 no previous article in this group
-
-3.6.  The LIST command
-
-3.6.1.  LIST
-
-   LIST
-
-   Returns a list of valid newsgroups and associated information.  Each
-   newsgroup is sent as a line of text in the following format:
-
-      group last first p
-
-   where <group> is the name of the newsgroup, <last> is the number of
-   the last known article currently in that newsgroup, <first> is the
-   number of the first article currently in the newsgroup, and <p> is
-   either 'y' or 'n' indicating whether posting to this newsgroup is
-   allowed ('y') or prohibited ('n').
-
-   The <first> and <last> fields will always be numeric.  They may have
-   leading zeros.  If the <last> field evaluates to less than the
-   <first> field, there are no articles currently on file in the
-   newsgroup.
-
-   Note that posting may still be prohibited to a client even though the
-   LIST command indicates that posting is permitted to a particular
-   newsgroup. See the POST command for an explanation of client
-   prohibitions.  The posting flag exists for each newsgroup because
-   some newsgroups are moderated or are digests, and therefore cannot be
-   posted to; that is, articles posted to them must be mailed to a
-   moderator who will post them for the submitter.  This is independent
-   of the posting permission granted to a client by the NNTP server.
-
-   Please note that an empty list (i.e., the text body returned by this
-   command consists only of the terminating period) is a possible valid
-   response, and indicates that there are currently no valid newsgroups.
-
-3.6.2.  Responses
-
-   215 list of newsgroups follows
-
-
-
-
-
-
-
-Kantor & Lapsley                                               [Page 14]
-
-
-
-RFC 977                                                    February 1986
-Network News Transfer Protocol
-
-
-3.7.  The NEWGROUPS command
-
-3.7.1.  NEWGROUPS
-
-   NEWGROUPS date time [GMT] [<distributions>]
-
-   A list of newsgroups created since <date and time> will be listed in
-   the same format as the LIST command.
-
-   The date is sent as 6 digits in the format YYMMDD, where YY is the
-   last two digits of the year, MM is the two digits of the month (with
-   leading zero, if appropriate), and DD is the day of the month (with
-   leading zero, if appropriate).  The closest century is assumed as
-   part of the year (i.e., 86 specifies 1986, 30 specifies 2030, 99 is
-   1999, 00 is 2000).
-
-   Time must also be specified.  It must be as 6 digits HHMMSS with HH
-   being hours on the 24-hour clock, MM minutes 00-59, and SS seconds
-   00-59.  The time is assumed to be in the server's timezone unless the
-   token "GMT" appears, in which case both time and date are evaluated
-   at the 0 meridian.
-
-   The optional parameter "distributions" is a list of distribution
-   groups, enclosed in angle brackets.  If specified, the distribution
-   portion of a new newsgroup (e.g, 'net' in 'net.wombat') will be
-   examined for a match with the distribution categories listed, and
-   only those new newsgroups which match will be listed.  If more than
-   one distribution group is to be listed, they must be separated by
-   commas within the angle brackets.
-
-   Please note that an empty list (i.e., the text body returned by this
-   command consists only of the terminating period) is a possible valid
-   response, and indicates that there are currently no new newsgroups.
-
-3.7.2.  Responses
-
-   231 list of new newsgroups follows
-
-
-
-
-
-
-
-
-
-
-
-
-Kantor & Lapsley                                               [Page 15]
-
-
-
-RFC 977                                                    February 1986
-Network News Transfer Protocol
-
-
-3.8.  The NEWNEWS command
-
-3.8.1.  NEWNEWS
-
-   NEWNEWS newsgroups date time [GMT] [<distribution>]
-
-   A list of message-ids of articles posted or received to the specified
-   newsgroup since "date" will be listed. The format of the listing will
-   be one message-id per line, as though text were being sent.  A single
-   line consisting solely of one period followed by CR-LF will terminate
-   the list.
-
-   Date and time are in the same format as the NEWGROUPS command.
-
-   A newsgroup name containing a "*" (an asterisk) may be specified to
-   broaden the article search to some or all newsgroups.  The asterisk
-   will be extended to match any part of a newsgroup name (e.g.,
-   net.micro* will match net.micro.wombat, net.micro.apple, etc). Thus
-   if only an asterisk is given as the newsgroup name, all newsgroups
-   will be searched for new news.
-
-   (Please note that the asterisk "*" expansion is a general
-   replacement; in particular, the specification of e.g., net.*.unix
-   should be correctly expanded to embrace names such as net.wombat.unix
-   and net.whocares.unix.)
-
-   Conversely, if no asterisk appears in a given newsgroup name, only
-   the specified newsgroup will be searched for new articles. Newsgroup
-   names must be chosen from those returned in the listing of available
-   groups.  Multiple newsgroup names (including a "*") may be specified
-   in this command, separated by a comma.  No comma shall appear after
-   the last newsgroup in the list.  [Implementors are cautioned to keep
-   the 512 character command length limit in mind.]
-
-   The exclamation point ("!") may be used to negate a match. This can
-   be used to selectively omit certain newsgroups from an otherwise
-   larger list.  For example, a newsgroups specification of
-   "net.*,mod.*,!mod.map.*" would specify that all net.<anything> and
-   all mod.<anything> EXCEPT mod.map.<anything> newsgroup names would be
-   matched.  If used, the exclamation point must appear as the first
-   character of the given newsgroup name or pattern.
-
-   The optional parameter "distributions" is a list of distribution
-   groups, enclosed in angle brackets.  If specified, the distribution
-   portion of an article's newsgroup (e.g, 'net' in 'net.wombat') will
-   be examined for a match with the distribution categories listed, and
-   only those articles which have at least one newsgroup belonging to
-
-
-Kantor & Lapsley                                               [Page 16]
-
-
-
-RFC 977                                                    February 1986
-Network News Transfer Protocol
-
-
-   the list of distributions will be listed.  If more than one
-   distribution group is to be supplied, they must be separated by
-   commas within the angle brackets.
-
-   The use of the IHAVE, NEWNEWS, and NEWGROUPS commands to distribute
-   news is discussed in an earlier part of this document.
-
-   Please note that an empty list (i.e., the text body returned by this
-   command consists only of the terminating period) is a possible valid
-   response, and indicates that there is currently no new news.
-
-3.8.2.  Responses
-
-   230 list of new articles by message-id follows
-
-3.9.  The NEXT command
-
-3.9.1.  NEXT
-
-   NEXT
-
-   The internally maintained "current article pointer" is advanced to
-   the next article in the current newsgroup.  If no more articles
-   remain in the current group, an error message is returned and the
-   current article remains selected.
-
-   The internally-maintained "current article pointer" is set by this
-   command.
-
-   A response indicating the current article number, and the message-id
-   string will be returned.  No text is sent in response to this
-   command.
-
-3.9.2.  Responses
-
-   223 n a article retrieved - request text separately
-           (n = article number, a = unique article id)
-   412 no newsgroup selected
-   420 no current article has been selected
-   421 no next article in this group
-
-
-
-
-
-
-
-
-
-Kantor & Lapsley                                               [Page 17]
-
-
-
-RFC 977                                                    February 1986
-Network News Transfer Protocol
-
-
-3.10.  The POST command
-
-3.10.1.  POST
-
-   POST
-
-   If posting is allowed, response code 340 is returned to indicate that
-   the article to be posted should be sent. Response code 440 indicates
-   that posting is prohibited for some installation-dependent reason.
-
-   If posting is permitted, the article should be presented in the
-   format specified by RFC850, and should include all required header
-   lines. After the article's header and body have been completely sent
-   by the client to the server, a further response code will be returned
-   to indicate success or failure of the posting attempt.
-
-   The text forming the header and body of the message to be posted
-   should be sent by the client using the conventions for text received
-   from the news server:  A single period (".") on a line indicates the
-   end of the text, with lines starting with a period in the original
-   text having that period doubled during transmission.
-
-   No attempt shall be made by the server to filter characters, fold or
-   limit lines, or otherwise process incoming text.  It is our intent
-   that the server just pass the incoming message to be posted to the
-   server installation's news posting software, which is separate from
-   this specification.  See RFC850 for more details.
-
-   Since most installations will want the client news program to allow
-   the user to prepare his message using some sort of text editor, and
-   transmit it to the server for posting only after it is composed, the
-   client program should take note of the herald message that greeted it
-   when the connection was first established. This message indicates
-   whether postings from that client are permitted or not, and can be
-   used to caution the user that his access is read-only if that is the
-   case. This will prevent the user from wasting a good deal of time
-   composing a message only to find posting of the message was denied.
-   The method and determination of which clients and hosts may post is
-   installation dependent and is not covered by this specification.
-
-3.10.2.  Responses
-
-   240 article posted ok
-   340 send article to be posted. End with <CR-LF>.<CR-LF>
-   440 posting not allowed
-   441 posting failed
-
-
-
-Kantor & Lapsley                                               [Page 18]
-
-
-
-RFC 977                                                    February 1986
-Network News Transfer Protocol
-
-
-   (for reference, one of the following codes will be sent upon initial
-   connection; the client program should determine whether posting is
-   generally permitted from these:) 200 server ready - posting allowed
-   201 server ready - no posting allowed
-
-3.11.  The QUIT command
-
-3.11.1.  QUIT
-
-   QUIT
-
-   The server process acknowledges the QUIT command and then closes the
-   connection to the client.  This is the preferred method for a client
-   to indicate that it has finished all its transactions with the NNTP
-   server.
-
-   If a client simply disconnects (or the connection times out, or some
-   other fault occurs), the server should gracefully cease its attempts
-   to service the client.
-
-3.11.2.  Responses
-
-   205 closing connection - goodbye!
-
-3.12.  The SLAVE command
-
-3.12.1.  SLAVE
-
-   SLAVE
-
-   Indicates to the server that this client connection is to a slave
-   server, rather than a user.
-
-   This command is intended for use in separating connections to single
-   users from those to subsidiary ("slave") servers.  It may be used to
-   indicate that priority should therefore be given to requests from
-   this client, as it is presumably serving more than one person.  It
-   might also be used to determine which connections to close when
-   system load levels are exceeded, perhaps giving preference to slave
-   servers.  The actual use this command is put to is entirely
-   implementation dependent, and may vary from one host to another.  In
-   NNTP servers which do not give priority to slave servers, this
-   command must nonetheless be recognized and acknowledged.
-
-3.12.2.  Responses
-
-   202 slave status noted
-
-
-Kantor & Lapsley                                               [Page 19]
-
-
-
-RFC 977                                                    February 1986
-Network News Transfer Protocol
-
-
-4.  Sample Conversations
-
-   These are samples of the conversations that might be expected with
-   the news server in hypothetical sessions.  The notation C: indicates
-   commands sent to the news server from the client program; S: indicate
-   responses received from the server by the client.
-
-4.1.  Example 1 - relative access with NEXT
-
-   S:      (listens at TCP port 119)
-
-   C:      (requests connection on TCP port 119)
-   S:      200 wombatvax news server ready - posting ok
-
-   (client asks for a current newsgroup list)
-   C:      LIST
-   S:      215 list of newsgroups follows
-   S:      net.wombats 00543 00501 y
-   S:      net.unix-wizards 10125 10011 y
-           (more information here)
-   S:      net.idiots 00100 00001 n
-   S:      .
-
-   (client selects a newsgroup)
-   C:      GROUP net.unix-wizards
-   S:      211 104 10011 10125 net.unix-wizards group selected
-           (there are 104 articles on file, from 10011 to 10125)
-
-   (client selects an article to read)
-   C:      STAT 10110
-   S:      223 10110 <23445@sdcsvax.ARPA> article retrieved - statistics
-           only (article 10110 selected, its message-id is
-           <23445@sdcsvax.ARPA>)
-
-   (client examines the header)
-   C:      HEAD
-   S:      221 10110 <23445@sdcsvax.ARPA> article retrieved - head
-           follows (text of the header appears here)
-   S:      .
-
-   (client wants to see the text body of the article)
-   C:      BODY
-   S:      222 10110 <23445@sdcsvax.ARPA> article retrieved - body
-           follows (body text here)
-   S:      .
-
-   (client selects next article in group)
-
-
-Kantor & Lapsley                                               [Page 20]
-
-
-
-RFC 977                                                    February 1986
-Network News Transfer Protocol
-
-
-   C:      NEXT
-   S:      223 10113 <21495@nudebch.uucp> article retrieved - statistics
-           only (article 10113 was next in group)
-
-   (client finishes session)
-   C:      QUIT
-   S:      205 goodbye.
-
-4.2.  Example 2 - absolute article access with ARTICLE
-
-   S:      (listens at TCP port 119)
-
-   C:      (requests connection on TCP port 119)
-   S:      201 UCB-VAX netnews server ready -- no posting allowed
-
-   C:      GROUP msgs
-   S:      211 103 402 504 msgs Your new group is msgs
-           (there are 103 articles, from 402 to 504)
-
-   C:      ARTICLE 401
-   S:      423 No such article in this newsgroup
-
-   C:      ARTICLE 402
-   S:      220 402 <4105@ucbvax.ARPA> Article retrieved, text follows
-   S:      (article header and body follow)
-   S:      .
-
-   C:      HEAD 403
-   S:      221 403 <3108@mcvax.UUCP> Article retrieved, header follows
-   S:      (article header follows)
-   S:      .
-
-   C:      QUIT
-   S:      205 UCB-VAX news server closing connection.  Goodbye.
-
-4.3.  Example 3 - NEWGROUPS command
-
-   S:      (listens at TCP port 119)
-
-   C:      (requests connection on TCP port 119)
-   S:      200 Imaginary Institute News Server ready (posting ok)
-
-   (client asks for new newsgroups since April 3, 1985)
-   C:      NEWGROUPS 850403 020000
-
-   S:      231 New newsgroups since 03/04/85 02:00:00 follow
-
-
-
-Kantor & Lapsley                                               [Page 21]
-
-
-
-RFC 977                                                    February 1986
-Network News Transfer Protocol
-
-
-   S:      net.music.gdead
-   S:      net.games.sources
-   S:      .
-
-   C:      GROUP net.music.gdead
-   S:      211 0 1 1 net.music.gdead Newsgroup selected
-           (there are no articles in that newsgroup, and
-           the first and last article numbers should be ignored)
-
-   C:      QUIT
-   S:      205 Imaginary Institute news server ceasing service.  Bye!
-
-4.4.  Example 4 - posting a news article
-
-   S:      (listens at TCP port 119)
-
-   C:      (requests connection on TCP port 119)
-   S:      200 BANZAIVAX news server ready, posting allowed.
-
-   C:      POST
-   S:      340 Continue posting; Period on a line by itself to end
-   C:      (transmits news article in RFC850 format)
-   C:      .
-   S:      240 Article posted successfully.
-
-   C:      QUIT
-   S:      205 BANZAIVAX closing connection.  Goodbye.
-
-4.5.  Example 5 - interruption due to operator request
-
-   S:      (listens at TCP port 119)
-
-   C:      (requests connection on TCP port 119)
-   S:      201 genericvax news server ready, no posting allowed.
-
-           (assume normal conversation for some time, and
-           that a newsgroup has been selected)
-
-   C:      NEXT
-   S:      223 1013 <5734@mcvax.UUCP> Article retrieved; text separate.
-
-   C:      HEAD
-   C:      221 1013 <5734@mcvax.UUCP> Article retrieved; head follows.
-
-   S:      (sends head of article, but halfway through is
-           interrupted by an operator request.  The following
-           then occurs, without client intervention.)
-
-
-Kantor & Lapsley                                               [Page 22]
-
-
-
-RFC 977                                                    February 1986
-Network News Transfer Protocol
-
-
-   S:      (ends current line with a CR-LF pair)
-   S:      .
-   S:      400 Connection closed by operator.  Goodbye.
-   S:      (closes connection)
-
-4.6.  Example 6 - Using the news server to distribute news between
-      systems.
-
-   S:      (listens at TCP port 119)
-
-   C:      (requests connection on TCP port 119)
-   S:      201 Foobar NNTP server ready (no posting)
-
-   (client asks for new newsgroups since 2 am, May 15, 1985)
-   C:      NEWGROUPS 850515 020000
-   S:      235 New newsgroups since 850515 follow
-   S:      net.fluff
-   S:      net.lint
-   S:      .
-
-   (client asks for new news articles since 2 am, May 15, 1985)
-   C:      NEWNEWS * 850515 020000
-   S:      230 New news since 850515 020000 follows
-   S:      <1772@foo.UUCP>
-   S:      <87623@baz.UUCP>
-   S:      <17872@GOLD.CSNET>
-   S:      .
-
-   (client asks for article <1772@foo.UUCP>)
-   C:      ARTICLE <1772@foo.UUCP>
-   S:      220 <1772@foo.UUCP> All of article follows
-   S:      (sends entire message)
-   S:      .
-
-   (client asks for article <87623@baz.UUCP>
-   C:      ARTICLE <87623@baz.UUCP>
-   S:      220 <87623@baz.UUCP> All of article follows
-   S:      (sends entire message)
-   S:      .
-
-   (client asks for article <17872@GOLD.CSNET>
-   C:      ARTICLE <17872@GOLD.CSNET>
-   S:      220 <17872@GOLD.CSNET> All of article follows
-   S:      (sends entire message)
-   S:      .
-
-
-
-
-Kantor & Lapsley                                               [Page 23]
-
-
-
-RFC 977                                                    February 1986
-Network News Transfer Protocol
-
-
-   (client offers an article it has received recently)
-   C:      IHAVE <4105@ucbvax.ARPA>
-   S:      435 Already seen that one, where you been?
-
-   (client offers another article)
-   C:      IHAVE <4106@ucbvax.ARPA>
-   S:      335 News to me!  <CRLF.CRLF> to end.
-   C:      (sends article)
-   C:      .
-   S:      235 Article transferred successfully.  Thanks.
-
-   (or)
-
-   S:      436 Transfer failed.
-
-   (client is all through with the session)
-   C:      QUIT
-   S:      205 Foobar NNTP server bids you farewell.
-
-4.7.  Summary of commands and responses.
-
-   The following are the commands recognized and responses returned by
-   the NNTP server.
-
-4.7.1.  Commands
-
-   ARTICLE
-   BODY
-   GROUP
-   HEAD
-   HELP
-   IHAVE
-   LAST
-   LIST
-   NEWGROUPS
-   NEWNEWS
-   NEXT
-   POST
-   QUIT
-   SLAVE
-   STAT
-
-4.7.2.  Responses
-
-   100 help text follows
-   199 debug output
-
-
-
-Kantor & Lapsley                                               [Page 24]
-
-
-
-RFC 977                                                    February 1986
-Network News Transfer Protocol
-
-
-   200 server ready - posting allowed
-   201 server ready - no posting allowed
-   202 slave status noted
-   205 closing connection - goodbye!
-   211 n f l s group selected
-   215 list of newsgroups follows
-   220 n <a> article retrieved - head and body follow 221 n <a> article
-   retrieved - head follows
-   222 n <a> article retrieved - body follows
-   223 n <a> article retrieved - request text separately 230 list of new
-   articles by message-id follows
-   231 list of new newsgroups follows
-   235 article transferred ok
-   240 article posted ok
-
-   335 send article to be transferred.  End with <CR-LF>.<CR-LF>
-   340 send article to be posted. End with <CR-LF>.<CR-LF>
-
-   400 service discontinued
-   411 no such news group
-   412 no newsgroup has been selected
-   420 no current article has been selected
-   421 no next article in this group
-   422 no previous article in this group
-   423 no such article number in this group
-   430 no such article found
-   435 article not wanted - do not send it
-   436 transfer failed - try again later
-   437 article rejected - do not try again.
-   440 posting not allowed
-   441 posting failed
-
-   500 command not recognized
-   501 command syntax error
-   502 access restriction or permission denied
-   503 program fault - command not performed
-
-4.8.  A Brief Word about the USENET News System
-
-   In the UNIX world, which traditionally has been linked by 1200 baud
-   dial-up telephone lines, the USENET News system has evolved to handle
-   central storage, indexing, retrieval, and distribution of news.  With
-   the exception of its underlying transport mechanism (UUCP), USENET
-   News is an efficient means of providing news and bulletin service to
-   subscribers on UNIX and other hosts worldwide.  The USENET News
-
-
-
-
-Kantor & Lapsley                                               [Page 25]
-
-
-
-RFC 977                                                    February 1986
-Network News Transfer Protocol
-
-
-   system is discussed in detail in RFC 850.  It runs on most versions
-   of UNIX and on many other operating systems, and is customarily
-   distributed without charge.
-
-   USENET uses a spooling area on the UNIX host to store news articles,
-   one per file. Each article consists of a series of heading text,
-   which contain the sender's identification and organizational
-   affiliation, timestamps, electronic mail reply paths, subject,
-   newsgroup (subject category), and the like.  A complete news article
-   is reproduced in its entirety below.  Please consult RFC 850 for more
-   details.
-
-      Relay-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site
-      sdcsvax.UUCP
-      Posting-Version: version B 2.10.1 6/24/83 SMI; site unitek.uucp
-      Path:sdcsvax!sdcrdcf!hplabs!qantel!ihnp4!alberta!ubc-vision!unitek
-      !honman
-      From: honman@unitek.uucp (Man Wong)
-      Newsgroups: net.unix-wizards
-      Subject: foreground -> background ?
-      Message-ID: <167@unitek.uucp>
-      Date: 25 Sep 85 23:51:52 GMT
-      Date-Received: 29 Sep 85 09:54:48 GMT
-      Reply-To: honman@unitek.UUCP (Hon-Man Wong)
-      Distribution: net.all
-      Organization: Unitek Technologies Corporation
-      Lines: 12
-
-      I have a process (C program) which generates a child and waits for
-      it to return.  What I would like to do is to be able to run the
-      child process interactively for a while before kicking itself into
-      the background so I can return to the parent process (while the
-      child process is RUNNING in the background).  Can it be done?  And
-      if it can, how?
-
-      Please reply by E-mail.  Thanks in advance.
-
-      Hon-Man Wong
-
-
-
-
-
-
-
-
-
-
-
-Kantor & Lapsley                                               [Page 26]
-
-
-
-RFC 977                                                    February 1986
-Network News Transfer Protocol
-
-
-5.  References
-
-   [1]  Crocker, D., "Standard for the Format of ARPA Internet Text
-        Messages", RFC-822, Department of Electrical Engineering,
-        University of Delaware, August, 1982.
-
-   [2]  Horton, M., "Standard for Interchange of USENET Messages",
-        RFC-850, USENET Project, June, 1983.
-
-   [3]  Postel, J., "Transmission Control Protocol- DARPA Internet
-        Program Protocol Specification", RFC-793, USC/Information
-        Sciences Institute, September, 1981.
-
-   [4]  Postel, J., "Simple Mail Transfer Protocol", RFC-821,
-        USC/Information Sciences Institute, August, 1982.
-
-6.  Acknowledgements
-
-   The authors wish to express their heartfelt thanks to those many
-   people who contributed to this specification, and especially to Erik
-   Fair and Chuq von Rospach, without whose inspiration this whole thing
-   would not have been necessary.
-
-7.  Notes
-
-   <1> UNIX is a trademark of Bell Laboratories.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kantor & Lapsley                                               [Page 27]
-
diff --git a/design-notes.html b/design-notes.html
index 32025b78..8d4a841c 100644
--- a/design-notes.html
+++ b/design-notes.html
@@ -736,6 +736,16 @@ RFC2192 IMAP URL Scheme
 RFC2193 IMAP4 Mailbox Referrals
 RFC2221 IMAP4 Login Referrals
 -->
+
+<h1>Other useful documents</h1>
+
+<dl>
+<dt><a
+href="http://www.faqs.org/faqs/LANs/mail-protocols/">http://www.faqs.org/faqs/LANs/mail-protocols/</a></dt>
+
+<dd>LAN Mail Protocols Summary</dd>
+</dl>
+
 <hr />
 <table width="100%" cellpadding="0" summary="Canned page footer">
 <tr>