sync with current (correct?), regen

17 files changed, 5693 insertions, 557 deletions

diff --git a/Documentation/en/I-D/draft-ema-vpim-pndn-04.txt b/Documentation/en/I-D/draft-ema-vpim-pndn-04.txt
index bdcd591f..61bd16a3 100644
--- a/Documentation/en/I-D/draft-ema-vpim-pndn-04.txt
+++ b/Documentation/en/I-D/draft-ema-vpim-pndn-04.txt
@@ -1,19 +1,19 @@
-

-This Internet-Draft has been deleted. Unrevised documents placed in the

-Internet-Drafts directories have a maximum life of six months. After

-that time, they are deleted. This Internet-Draft was not published as

-an RFC.

-

-Internet-Drafts are not an archival document series, and expired

-drafts, such as this one, are not available; please do not ask for

-copies... they are not available. The Secretariat does not have

-information as to future plans of the authors or working groups WRT the

-deleted Internet-Draft.

-

-For more information or a copy of the document, contact the author directly.

-

-Draft Author(s):

-

-E. Burger: e.burger@ieee.org                                                       

-

-

+
+This Internet-Draft has been deleted. Unrevised documents placed in the
+Internet-Drafts directories have a maximum life of six months. After
+that time, they are deleted. This Internet-Draft was not published as
+an RFC.
+
+Internet-Drafts are not an archival document series, and expired
+drafts, such as this one, are not available; please do not ask for
+copies... they are not available. The Secretariat does not have
+information as to future plans of the authors or working groups WRT the
+deleted Internet-Draft.
+
+For more information or a copy of the document, contact the author directly.
+
+Draft Author(s):
+
+E. Burger: e.burger@ieee.org                                                       
+
+
diff --git a/Documentation/en/I-D/draft-hall-dm-idns-00.txt b/Documentation/en/I-D/draft-hall-dm-idns-00.txt
index d3bc4b4e..9b183be5 100644
--- a/Documentation/en/I-D/draft-hall-dm-idns-00.txt
+++ b/Documentation/en/I-D/draft-hall-dm-idns-00.txt
@@ -123,15 +123,15 @@
       
      The following abbreviations are used throughout this document: 
       
-          UCS (Universal Character Set) “ The ISO/IEC 10646 character 
+          UCS (Universal Character Set) - The ISO/IEC 10646 character 
             set repertoire, as represented by the Unicode 3.1 
             specification. 
       
-          ACE (ASCII-Compatible Encoding) “ A transfer encoding which 
+          ACE (ASCII-Compatible Encoding) - A transfer encoding which 
             encodes UCS character codes into a seven-bit codespace 
             which is compatible with US-ASCII. 
       
-          UTF-8 (UCS Transformation Format, Eight-Bit) “ A transfer 
+          UTF-8 (UCS Transformation Format, Eight-Bit) - A transfer 
             encoding which encodes UCS characters into an eight-bit 
             codespace which is compatible with DNS message formats. 
       
@@ -313,7 +313,7 @@
      and application in one form or another. However, most usages fall 
      under one or more of the following scenarios: 
       
-        *   Connection identifiers “ Domain names are most commonly 
+        *   Connection identifiers. Domain names are most commonly 
             used as host-specific identifiers for outbound connection 
             requests, whether this be for a command-line application 
             such as ping, or as a host name which is stored in an 
@@ -352,7 +352,7 @@
             manner, the ACE equivalent domain name will be negotiated 
             for the operation at hand. 
       
-        *   Protocol data “ Some application protocols exchange domain 
+        *   Protocol data. Some application protocols exchange domain 
             names as protocol data, with those domain names either 
             determining or altering a service-specific operation. 
             Examples of this usage include SMTP envelopes ("RCPT TO 
@@ -375,7 +375,7 @@
             to provide these protocols with access to the 
             internationalized namespace. 
       
-        *   Structured application data “ Structured application data 
+        *   Structured application data. Structured application data 
             is similar to protocol data in that it can trigger or 
             affect some protocol action, although this will not always 
             occur. For example, a web browser can process an embedded 
@@ -406,7 +406,7 @@
             application data, and to determine the appropriate course 
             of action for each usage accordingly. 
       
-        *   Unstructured application data “ Many application protocols 
+        *   Unstructured application data. Many application protocols 
             provide free-text data which can contain domain names, but 
             with those domain names existing as unstructured data. For 
             example, an email message which is provided as a text/plain 
@@ -1550,14 +1550,14 @@
          |0 1|0 0 0 0 1 1|    length     |  label data  ///  | 
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       
-          0b01 “ The extended label identifier. 
+          0b01 - The extended label identifier. 
       
-          0b000011 “ The EDNS/UTF-8 extended label type identifier. 
+          0b000011 - The EDNS/UTF-8 extended label type identifier. 
       
-          Length “ The number of octets in the label data, or the off-
+          Length - The number of octets in the label data, or the off-
             set to the length octet of another EDNS/UTF-8 label. 
       
-          Label data “ The label data, encoded as UTF-8 octets. 
+          Label data - The label data, encoded as UTF-8 octets. 
       
      The following example shows the domain name of me.com, where the 
      "e" in "me" is the UCS character <LATIN SMALL LETTER E WITH ACUTE> 
diff --git a/Documentation/en/I-D/draft-hoffman-rfc2487bis-00.txt b/Documentation/en/I-D/draft-hoffman-rfc2487bis-00.txt
new file mode 100644
index 00000000..45245afd
--- /dev/null
+++ b/Documentation/en/I-D/draft-hoffman-rfc2487bis-00.txt
@@ -0,0 +1,364 @@
+Internet Draft                                          Paul Hoffman
+<draft-hoffman-rfc2487bis-00.txt>           Internet Mail Consortium
+April 15, 1999
+Expires in six months
+
+            SMTP Service Extension for Secure SMTP over TLS
+
+Status of this Memo
+
+This document is an Internet-Draft and is in full conformance with all
+provisions of Section 10 of RFC2026.
+
+Internet-Drafts are working documents of the Internet Engineering Task
+Force (IETF), its areas, and its working groups.  Note that other
+groups may also distribute working documents as Internet-Drafts.
+
+Internet-Drafts are draft documents valid for a maximum of six months
+and may be updated, replaced, or obsoleted by other documents at any
+time.  It is inappropriate to use Internet- Drafts as reference
+material or to cite them other than as "work in progress."
+
+The list of current Internet-Drafts can be accessed at
+http://www.ietf.org/ietf/1id-abstracts.txt
+
+The list of Internet-Draft Shadow Directories can be accessed at
+http://www.ietf.org/shadow.html.
+
+Copyright (C) The Internet Society (1999). All Rights Reserved.
+
+1. Abstract
+
+   This document describes an extension to the SMTP service that allows
+   an SMTP server and client to use transport-layer security to provide
+   private, authenticated communication over the Internet. This gives
+   SMTP agents the ability to protect some or all of their
+   communications from eavesdroppers and attackers.
+
+   This document is a revision of RFC 2487, which is currently a Proposed
+   Standard. The changes that this draft propose are:
+
+   - Additional discussion of when a server should and should not
+     advertise the STARTTLS extension (section 4)
+   - More discussion of the man-in-the-middle attacks (sections
+     5 and 7)
+   - Bugfix in the example in section 6 to indicate that the client
+     needs to issue a new EHLO command, as already is described in
+     section 5.2.
+
+2. Introduction
+
+   SMTP [RFC-821] servers and clients normally communicate in the clear
+   over the Internet. In many cases, this communication goes through one
+   or more router that is not controlled or trusted by either entity.
+   Such an untrusted router might allow a third party to monitor or
+   alter the communications between the server and client.
+
+   Further, there is often a desire for two SMTP agents to be able to
+   authenticate each others' identities. For example, a secure SMTP
+   server might only allow communications from other SMTP agents it
+   knows, or it might act differently for messages received from an
+   agent it knows than from one it doesn't know.
+
+   TLS [TLS], more commonly known as SSL, is a popular mechanism for
+   enhancing TCP communications with privacy and authentication. TLS is
+   in wide use with the HTTP protocol, and is also being used for adding
+   security to many other common protocols that run over TCP.
+
+2.1 Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC-2119].
+
+3. STARTTLS Extension
+
+   The STARTTLS extension to SMTP is laid out as follows:
+
+   (1) the name of the SMTP service defined here is STARTTLS;
+
+   (2) the EHLO keyword value associated with the extension is STARTTLS;
+
+   (3) the STARTTLS keyword has no parameters;
+
+   (4) a new SMTP verb, "STARTTLS", is defined;
+
+   (5) no additional parameters are added to any SMTP command.
+
+4. The STARTTLS Keyword
+
+    The STARTTLS keyword is used to tell the SMTP client that the SMTP
+    server is currently able to negotiate the use of TLS. It takes no
+    parameters.
+
+5. The STARTTLS Command
+
+   The format for the STARTTLS command is:
+
+   STARTTLS
+
+   with no parameters.
+
+   After the client gives the STARTTLS command, the server responds with
+   one of the following reply codes:
+
+   220 Ready to start TLS
+   501 Syntax error (no parameters allowed)
+   454 TLS not available due to temporary reason
+
+   If the client receives the 454 response, the client must decide
+   whether or not to continue the SMTP session. Such a decision is
+   based on local policy. For instance, if TLS was being used for
+   client authentication, the client might try to continue the
+   session, in case the server allows it even with no authentication.
+   However, if TLS was being negotiated for encryption, a client
+   that gets a 454 response needs to decide whether to send the
+   message anyway with no TLS encryption, whether to wait and try
+   again later, or whether to give up and notify the sender of the
+   error.
+
+   A publicly-referenced SMTP server MUST NOT require use of the
+   STARTTLS extension in order to deliver mail locally. This rule
+   prevents the STARTTLS extension from damaging the interoperability of
+   the Internet's SMTP infrastructure. A publicly-referenced SMTP server
+   is an SMTP server which runs on port 25 of an Internet host listed in
+   the MX record (or A record if an MX record is not present) for the
+   domain name on the right hand side of an Internet mail address.
+
+   Any SMTP server may refuse to accept messages for relay based on
+   authentication supplied during the TLS negotiation. An SMTP server
+   that is not publicly referenced may refuse to accept any messages for
+   relay or local delivery based on authentication supplied during the
+   TLS negotiation.
+
+   A SMTP server that is not publicly referenced may choose to require
+   that the client perform a TLS negotiation before accepting any
+   commands. In this case, the server SHOULD return the reply code:
+
+   530 Must issue a STARTTLS command first
+
+   to every command other than NOOP, EHLO, STARTTLS, or QUIT. If the
+   client and server are using the ENHANCEDSTATUSCODES ESMTP extension
+   [RFC-2034], the status code to be returned SHOULD be 5.7.0.
+
+   After receiving a 220 response to a STARTTLS command, the client
+   SHOULD start the TLS negotiation before giving any other SMTP
+   commands.
+
+   If the SMTP client is using pipelining as defined in RFC 1854, the
+   STARTTLS command must be the last command in a group.
+
+5.1 Processing After the STARTTLS Command
+
+   After the TLS handshake has been completed, both parties MUST
+   immediately decide whether or not to continue based on the
+   authentication and privacy achieved. The SMTP client and server may
+   decide to move ahead even if the TLS negotiation ended with no
+   authentication and/or no privacy because most SMTP services are
+   performed with no authentication and no privacy, but some SMTP
+   clients or servers may want to continue only if a particular level of
+   authentication and/or privacy was achieved.
+
+   If the SMTP client decides that the level of authentication or
+   privacy is not high enough for it to continue, it SHOULD issue an
+   SMTP QUIT command immediately after the TLS negotiation is complete.
+   If the SMTP server decides that the level of authentication or
+   privacy is not high enough for it to continue, it SHOULD reply to
+   every SMTP command from the client (other than a QUIT command) with
+   the 554 reply code (with a possible text string such as "Command
+   refused due to lack of security").
+
+   The decision of whether or not to believe the authenticity of the
+   other party in a TLS negotiation is a local matter. However, some
+   general rules for the decisions are:
+
+    - A SMTP client would probably only want to authenticate an SMTP
+      server whose server certificate has a domain name that is the
+      domain name that the client thought it was connecting to.
+    - A publicly-referenced  SMTP server would probably want to accept
+      any certificate from an SMTP client, and would possibly want to
+      put distinguishing information about the certificate in the
+      Received header of messages that were relayed or submitted from
+      the client.
+
+5.2 Result of the STARTTLS Command
+
+   Upon completion of the TLS handshake, the SMTP protocol is reset to
+   the initial state (the state in SMTP after a server issues a 220
+   service ready greeting). The server MUST discard any knowledge
+   obtained from the client, such as the argument to the EHLO command,
+   which was not obtained from the TLS negotiation itself. The client
+   MUST discard any knowledge obtained from the server, such as the list
+   of SMTP service extensions, which was not obtained from the TLS
+   negotiation itself. The client SHOULD send an EHLO command as the
+   first command after a successful TLS negotiation.
+
+   The list of SMTP service extensions returned in response to an EHLO
+   command received after the TLS handshake MAY be different than the
+   list returned before the TLS handshake. For example, an SMTP server
+   might not want to advertise support for a particular SASL mechanism
+   [SASL] unless a client has sent an appropriate client certificate
+   during a TLS handshake.
+
+   Both the client and the server MUST know if there is a TLS session
+   active.  A client MUST NOT attempt to start a TLS session if a TLS
+   session is already active. A server MUST NOT return the TLS extension
+   in response to an EHLO command received after a TLS handshake has
+   completed.
+
+6. Usage Example
+
+   The following dialog illustrates how a client and server can start a
+   TLS session:
+
+   S: <waits for connection on TCP port 25>
+   C: <opens connection>
+   S: 220 mail.imc.org SMTP service ready
+   C: EHLO mail.ietf.org
+   S: 250-mail.imc.org offers a warm hug of welcome
+   S: 250 STARTTLS
+   C: STARTTLS
+   S: 220 Go ahead
+   C: <starts TLS negotiation>
+
+   C & S: <negotiate a TLS session>
+   C & S: <check result of negotiation>
+   C: EHLO mail.ietf.org
+   S: 250-mail.imc.org touches your hand gently for a moment
+   S: 250 STARTTLS
+   . . .
+
+7. Security Considerations
+
+   It should be noted that SMTP is not an end-to-end mechanism. Thus, if
+   an SMTP client/server pair decide to add TLS privacy, they are not
+   securing the transport from the originating mail user agent to the
+   recipient.  Further, because delivery of a single piece of mail may
+   go between more than two SMTP servers, adding TLS privacy to one pair
+   of servers does not mean that the entire SMTP chain has been made
+   private. Further, just because an SMTP server can authenticate an
+   SMTP client, it does not mean that the mail from the SMTP client was
+   authenticated by the SMTP client when the client received it.
+
+   Both the STMP client and server must check the result of the TLS
+   negotiation to see whether acceptable authentication or privacy was
+   achieved. Ignoring this step completely invalidates using TLS for
+   security.  The decision about whether acceptable authentication or
+   privacy was achieved is made locally, is implementation-dependant,
+   and is beyond the scope of this document.
+
+   The SMTP client and server should note carefully the result of the
+   TLS negotiation. If the negotiation results in no privacy, or if it
+   results in privacy using algorithms or key lengths that are deemed
+   not strong enough, or if the authentication is not good enough for
+   either party, the client may choose to end the SMTP session with an
+   immediate QUIT command, or the server may choose to not accept any
+   more SMTP commands.
+
+   A server announcing in an EHLO response that it uses a particular TLS
+   protocol should not pose any security issues, since any use of TLS
+   will be at least as secure as no use of TLS.
+
+   A man-in-the-middle attack can be launched by deleting the "250
+   STARTTLS" response from the server. This would cause the client not
+   to try to start a TLS session. Another man-in-the-middle attack is
+   to allow the server to announce its STARTTLS capability, but to
+   alter the client's request to start TLS and the server's response.
+   An SMTP client can partially protect against these attacks by
+   recording the fact that a particular SMTP server offers TLS during
+   one session and generating an alarm if it does not appear in the
+   EHLO response for a later session. The lack of TLS during a session
+   SHOULD NOT result in the bouncing of email, although it could result
+   in delayed processing.
+
+   If the TLS negotiation fails or if the client receives a 454
+   response, the client has to decide what to do next. There are three
+   main choices: go ahead with the rest of the SMTP session, retry TLS
+   at a later time, or give up and return the mail to the sender. If a
+   failure or error occurs, the client can assume that the server may
+   be able to negotiate TLS in the future, and should try negotiate TLS
+   in a later session, until some locally-chosen timeout occurs, at
+   which point, the client should return the mail to the sender.
+   However, if the client and server were only using TLS for
+   authentication, the client may want to procede with the SMTP
+   session, in case some of the operations the client wanted to perform
+   are accepted by the server even if the client is unauthenticated.
+
+   Before the TLS handshake has begun, any protocol interactions are
+   performed in the clear and may be modified by an active attacker. For
+   this reason, clients and servers MUST discard any knowledge obtained
+   prior to the start of the TLS handshake upon completion of the TLS
+   handshake.
+
+   The STARTTLS extension is not suitable for authenticating the author
+   of an email message unless every hop in the delivery chain, including
+   the submission to the first SMTP server, is authenticated. Another
+   proposal [SMTP-AUTH] can be used to authenticate delivery and MIME
+   security multiparts [MIME-SEC] can be used to authenticate the author
+   of an email message. In addition, the [SMTP-AUTH] proposal offers
+   simpler and more flexible options to authenticate an SMTP client and
+   the SASL EXTERNAL mechanism [SASL] MAY be used in conjunction with
+   the STARTTLS command to provide an authorization identity.
+
+A. References
+
+   [RFC-821]   Postel, J., "Simple Mail Transfer Protocol", RFC 821,
+               August 1982.
+
+   [RFC-1869]  Klensin, J., Freed, N, Rose, M, Stefferud, E. and D.
+               Crocker, "SMTP Service Extensions", STD 10, RFC 1869,
+               November 1995.
+
+   [RFC-2034]  Freed, N., "SMTP Service Extension for Returning Enhanced
+               Error Codes", RFC 2034, October 1996.
+
+   [RFC-2119]  Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [SASL]      Myers, J., "Simple Authentication and Security Layer
+               (SASL)", RFC 2222, October 1997.
+
+   [SMTP-AUTH] "SMTP Service Extension for Authentication", Work in
+               Progress.
+
+   [TLS]       Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
+               RFC 2246, January 1999.
+
+B. Author's Address
+
+   Paul Hoffman
+   Internet Mail Consortium
+   127 Segre Place
+   Santa Cruz, CA  95060
+
+   Phone: (831) 426-9827
+   EMail: phoffman@imc.org
+
+C.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
diff --git a/Documentation/en/I-D/draft-hoffman-smtp-ssl-09.txt b/Documentation/en/I-D/draft-hoffman-smtp-ssl-09.txt
new file mode 100644
index 00000000..f9fb3be3
--- /dev/null
+++ b/Documentation/en/I-D/draft-hoffman-smtp-ssl-09.txt
@@ -0,0 +1,290 @@
+
+Internet Draft                              Paul Hoffman
+draft-hoffman-smtp-ssl-09.txt               Internet Mail Consortium
+October 25, 1998
+Expires in six months
+
+         SMTP Service Extension for Secure SMTP over TLS
+
+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 learn the current status of any Internet-Draft, please check the
+"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
+Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au
+(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West
+Coast).
+
+
+1. Abstract
+
+This document describes an extension to the SMTP service that allows an
+SMTP server and client to use transport-layer security to provide private,
+authenticated communication over the Internet. This gives SMTP agents the
+ability to protect some or all of their communications from eavesdroppers
+and attackers.
+
+
+2. Introduction
+
+SMTP [RFC-821] servers and clients normally communicate in the clear over
+the Internet. In many cases, this communication goes through one or more
+router that is not controlled or trusted by either entity. Such an
+untrusted router might allow a third party to monitor or alter the
+communications between the server and client.
+
+Further, there is often a desire for two SMTP agents to be able to
+authenticate each others' identities. For example, a secure SMTP server
+might only allow communications from other SMTP agents it knows, or it
+might act differently for messages received from an agent it knows than
+from one it doesn't know.
+
+TLS [TLS], more commonly known as SSL, is a popular mechanism for enhancing
+TCP communications with privacy and authentication. TLS is in wide use with
+the HTTP protocol, and is also being used for adding security to many other
+common protocols that run over TCP.
+
+2.1 Discussion of this Draft
+
+This draft is being discussed on the "ietf-apps-tls" mailing list. To
+subscribe, send a message to:
+     ietf-apps-tls-request@imc.org
+with the single word
+     subscribe
+in the body of the message. There is a Web site for the mailing list at
+<http://www.imc.org/ietf-apps-tls/>.
+
+
+3. STARTTLS Extension
+
+The STARTTLS extension to SMTP is laid out as follows:
+
+(1) the name of the SMTP service defined here is STARTTLS;
+
+(2) the EHLO keyword value associated with the extension is STARTTLS;
+
+(3) the STARTTLS keyword has no parameters;
+
+(4) a new SMTP verb, "STARTTLS", is defined;
+
+(5) no additional parameters are added to any SMTP command.
+
+
+4. The STARTTLS Keyword
+
+The STARTTLS keyword is used to tell the SMTP client that the SMTP server
+allows use of TLS. It takes no parameters.
+
+
+5. The STARTTLS Command
+
+The format for the STARTTLS command is:
+
+STARTTLS
+
+with no parameters.
+
+After the client gives the STARTTLS command, the server responds with one
+of the following reply codes:
+
+220 Ready to start TLS
+501 Syntax error (no parameters allowed)
+454 TLS not available due to temporary reason
+
+A publicly-referenced SMTP server MUST NOT require use of the STARTTLS
+extension in order to deliver mail locally. This rule prevents the STARTTLS
+extension from damaging the interoperability of the Internet's SMTP
+infrastructure. A publicly-referenced SMTP server is an SMTP server which
+runs on port 25 of an Internet host listed in the MX record (or A record if
+an MX record is not present) for the domain name on the right hand side of
+an Internet mail address.
+
+Any SMTP server may refuse to accept messages for relay based on
+authentication supplied during the TLS negotiation. An SMTP server that is
+not publicly referenced may refuse to accept any messages for relay or
+local delivery based on authentication supplied during the TLS negotiation.
+
+A SMTP server that is not publicly referenced may choose to require that
+the client perform a TLS negotiation before accepting any commands. In this
+case, the server SHOULD return the reply code:
+
+530 Must issue a STARTTLS command first
+
+to every command other than NOOP, EHLO, STARTTLS, or QUIT. If the client
+and server are using the ENHANCEDSTATUSCODES ESMTP extension [RFC-2034],
+the status code to be returned SHOULD be 5.7.0.
+
+After receiving a 220 response to a STARTTLS command, the client SHOULD
+start the TLS negotiation before giving any other SMTP commands.
+
+If the SMTP client is using pipelining as defined in RFC 1854, the STARTTLS
+command must be the last command in a group.
+
+5.1 Processing After the STARTTLS Command
+
+After the TLS handshake has been completed, both parties MUST immediately
+decide whether or not to continue based on the authentication and privacy
+achieved. The SMTP client and server may decide to move ahead even if the
+TLS negotiation ended with no authentication and/or no privacy because most
+SMTP services are performed with no authentication and no privacy, but some
+SMTP clients or servers may want to continue only if a particular level of
+authentication and/or privacy was achieved.
+
+If the SMTP client decides that the level of authentication or privacy is
+not high enough for it to continue, it SHOULD issue an SMTP QUIT command
+immediately after the TLS negotiation is complete. If the SMTP server
+decides that the level of authentication or privacy is not high enough for
+it to continue, it SHOULD reply to every SMTP command from the client
+(other than a QUIT command) with the 554 reply code (with a possible text
+string such as "Command refused due to lack of security").
+
+The decision of whether or not to believe the authenticity of the other
+party in a TLS negotiation is a local matter. However, some general rules
+for the decisions are:
+ - A SMTP client would probably only want to authenticate an SMTP
+   server whose server certificate has a domain name that is the
+   domain name that the client thought it was connecting to.
+ - A publicly-referenced  SMTP server would probably want to accept
+   any certificate from an SMTP client, and would possibly want to
+   put distinguishing information about the certificate in the
+   Received header of messages that were relayed or submitted from
+   the client.
+
+5.2 Result of the STARTTLS Command
+
+Upon completion of the TLS handshake, the SMTP protocol is reset to the
+initial state (the state in SMTP after a server issues a 220 service ready
+greeting). The server MUST discard any knowledge obtained from the client,
+such as the argument to the EHLO command, which was not obtained from the
+TLS negotiation itself. The client MUST discard any knowledge obtained from
+the server, such as the list of SMTP service extensions, which was not
+obtained from the TLS negotiation itself. The client SHOULD send an EHLO
+command as the first command after a successful TLS negotiation.
+
+The list of SMTP service extensions returned in response to an EHLO command
+received after the TLS handshake MAY be different than the list returned
+before the TLS handshake. For example, an SMTP server might not want to
+advertise support for a particular SASL mechanism [SASL] unless a client
+has sent an appropriate client certificate during a TLS handshake.
+
+Both the client and the server MUST know if there is a TLS session active.
+A client MUST NOT attempt to start a TLS session if a TLS session is
+already active. A server MUST NOT return the TLS extension in response to
+an EHLO command received after a TLS handshake has completed.
+
+
+6. Usage Example
+
+The following dialog illustrates how a client and server can start a TLS
+session:
+
+S: <waits for connection on TCP port 25>
+C: <opens connection>
+S: 220 mail.imc.org SMTP service ready
+C: EHLO mail.ietf.org
+S: 250-mail.imc.org offers a warm hug of welcome
+S: 250 STARTTLS
+C: STARTTLS
+S: 220 Go ahead
+C: <starts TLS negotiation>
+C & S: <negotiate a TLS session>
+C & S: <check result of negotiation>
+C: <continues by sending an SMTP command>
+. . .
+
+
+7. Security Considerations
+
+It should be noted that SMTP is not an end-to-end mechanism. Thus, if an
+SMTP client/server pair decide to add TLS privacy, they are not securing
+the transport from the originating mail user agent to the recipient.
+Further, because delivery of a single piece of mail may go between more
+than two SMTP servers, adding TLS privacy to one pair of servers does not
+mean that the entire SMTP chain has been made private. Further, just
+because an SMTP server can authenticate an SMTP client, it does not mean
+that the mail from the SMTP client was authenticated by the SMTP client
+when the client received it.
+
+Both the STMP client and server must check the result of the TLS
+negotiation to see whether acceptable authentication or privacy was
+achieved. Ignoring this step completely invalidates using TLS for security.
+The decision about whether acceptable authentication or privacy was
+achieved is made locally, is implementation-dependant, and is beyond the
+scope of this document.
+
+The SMTP client and server should note carefully the result of the TLS
+negotiation. If the negotiation results in no privacy, or if it results in
+privacy using algorithms or key lengths that are deemed not strong
+enough, or if the authentication is not good enough for either party, the
+client may choose to end the SMTP session with an immediate QUIT command,
+or the server may choose to not accept any more SMTP commands.
+
+A server announcing in an EHLO response that it uses a particular TLS
+protocol should not pose any security issues, since any use of TLS will be
+at least as secure as no use of TLS.
+
+A man-in-the-middle attack can be launched by deleting the "250 STARTTLS"
+response from the server. This would cause the client not to try to start a
+TLS session. An SMTP client can protect against this attack by recording
+the fact that a particular SMTP server offers TLS during one session and
+generating an alarm if it does not appear in the EHLO response for a later
+session. The lack of TLS during a session SHOULD NOT result in the bouncing
+of email, although it could result in delayed processing.
+
+Before the TLS handshake has begun, any protocol interactions are performed
+in the clear and may be modified by an active attacker. For this reason,
+clients and servers MUST discard any knowledge obtained prior to the start
+of the TLS handshake upon completion of the TLS handshake.
+
+The STARTTLS extension is not suitable for authenticating the author of an
+email message unless every hop in the delivery chain, including the
+submission to the first SMTP server, is authenticated. Another proposal
+[SMTP-AUTH] can be used to authenticate delivery and MIME security
+multiparts [MIME-SEC] can be used to authenticate the author of an email
+message. In addition, the [SMTP-AUTH] proposal offers simpler and more
+flexible options to authenticate an SMTP client and the SASL EXTERNAL
+mechanism [SASL] MAY be used in conjunction with the STARTTLS command to
+provide an authorization identity.
+
+
+A. References
+
+[RFC-821] "Simple Mail Transfer Protocol", RFC 821
+
+[RFC-1869] "SMTP Service Extensions", RFC 1869
+
+[RFC-2034] "SMTP Service Extension for Returning Enhanced Error Codes", RFC
+2034
+
+[SASL] "Simple Authentication and Security Layer (SASL)", RFC 2222
+
+[SMTP-AUTH] "SMTP Service Extension for Authentication",
+Internet Draft draft-myers-smtp-auth-xx.txt
+
+[TLS] "The TLS Protocol Version 1.0", draft-ietf-tls-protocol-xx.txt
+
+
+B. Changes from -08 to -09
+
+Removed previous appendix C about smtps port. A separate draft will cover
+that topic.
+
+C. Author's Address
+
+Paul Hoffman
+Internet Mail Consortium
+127 Segre Place
+Santa Cruz, CA  95060
+(408) 426-9827
+phoffman@imc.org
+
+
diff --git a/Documentation/en/I-D/draft-huitema-shipworm-01.txt b/Documentation/en/I-D/draft-huitema-shipworm-01.txt
index 9bb0b8fd..5ea9c2dd 100644
--- a/Documentation/en/I-D/draft-huitema-shipworm-01.txt
+++ b/Documentation/en/I-D/draft-huitema-shipworm-01.txt
@@ -1,9 +1,9 @@
-

+
 This  document has been replaced by draft-ietf-ngtrans-shipworm-00.txt.
-For more information or a copy of the document, contact the author directly.

-

-Draft Author(s):

-

-C. Huitema: huitema@bellcore.com                                                    

-

-

+For more information or a copy of the document, contact the author directly.
+
+Draft Author(s):
+
+C. Huitema: huitema@bellcore.com                                                    
+
+
diff --git a/Documentation/en/I-D/draft-ietf-drums-smtpupd-09.txt b/Documentation/en/I-D/draft-ietf-drums-smtpupd-09.txt
new file mode 100644
index 00000000..8f7aa50b
--- /dev/null
+++ b/Documentation/en/I-D/draft-ietf-drums-smtpupd-09.txt
@@ -0,0 +1,3734 @@
+INTERNET-DRAFT                                John C. Klensin, Editor
+Expires June 1999                         
+December 29, 1998
+                                                        
+
+                  Simple Mail Transfer Protocol 
+
+                 draft-ietf-drums-smtpupd-09.txt
+
+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).
+
+[[Sections marked with doubled brackets (e.g., "<<") are explicit
+placeholders or known major loose ends. Please review these ASAP. The
+sections with these placeholders are 4.1.2, 4.4, and X.2.]]
+
+[[Appendix X will be removed before the document is submitted to the
+IESG.]]
+
+[[If consensus is reached on this document, it will be forwarded to the
+IESG with the recommendation that it be processed onto the Standards
+track.]]
+
+Copyright Notice
+
+Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+                           Table of Contents
+
+0. Abstract
+
+1. Introduction
+
+2. The SMTP Model
+2.1 Basic Structure
+2.2 The Extension Model
+2.2.1 Background
+2.2.2 Definition and Registration of Extensions
+2.3 Terminology
+2.3.1 Mail Objects
+2.3.2 Senders and Receivers
+2.3.3 Mail Agents
+2.3.4 Host
+2.3.5 Domain
+2.3.6 Buffer and State Table
+2.3.7 Lines
+2.3.8 Originator, Delivery, Relay, and Gateway Systems
+2.3.9 Message Content and Mail Data
+2.3.10 Mailbox and Address
+2.3.11 Reply
+2.4 Syntax Principles
+2.4.1 General Syntax and Transaction Model
+2.4.2 Command and Reply Syntax
+
+3. The SMTP Procedures: An Overview
+3.1 Session Initiation
+3.2 Client Initiation
+3.3 Mail Transactions
+3.4 Forwarding for Address Correction or Updating
+3.5 Commands for Debugging Addresses
+3.5.1 Overview
+3.5.2 VRFY Normal Response
+3.5.3 Meaning of VRFY or EXPN Success Response
+3.5.4 Semantics and Applications of EXPN
+3.6 Domains
+3.7 Relaying
+3.8 Mail Gatewaying
+3.8.1 Header Fields in Gatewaying
+3.8.2 Received Lines in Gatewaying
+3.8.3 Addresses in Gatewaying
+3.8.4 Other Header Fields in Gatewaying
+3.8.5 Envelopes in Gatewaying
+3.9 Terminating Sessions and Connections
+3.10 Mailing Lists and Aliases
+3.10.1 Alias
+3.10.2 List
+
+4. The SMTP Specifications
+4.1 SMTP Commands
+4.1.1 Command Semantics and Syntax
+4.1.1.1  Extended HELLO (EHLO) or HELLO (HELO)
+4.1.1.2 MAIL (MAIL)
+4.1.1.3 RECIPIENT (RCPT)
+4.1.1.4 DATA (DATA)
+4.1.1.5 RESET (RSET)
+4.1.1.6 VERIFY (VRFY)
+4.1.1.7 EXPAND (EXPN)
+4.1.1.8 HELP (HELP)
+4.1.1.9 NOOP (NOOP)
+4.1.1.10 QUIT (QUIT)
+4.1.2 Lower-level Syntax
+4.1.3 Address Literals
+4.1.4 Order of Commands
+4.1.5 Private-use Commands
+4.2  SMTP Replies
+4.2.1 Reply Code Severities and Theory
+4.2.2 Reply Codes by Function Groups
+4.2.3  Reply Codes in Numeric Order
+4.2.4 Reply Code 502
+4.2.5 Reply Codes After DATA and the Subsequent <CRLF>.<CRLF>
+4.3 Sequencing of Commands and Replies
+4.3.1 Sequencing Overview
+4.3.2 Command-Reply Sequences
+4.4 Trace Information
+4.5 Additional Implementation Issues
+4.5.1 Minimum Implementation
+4.5.2 Transparency
+4.5.3 Sizes and Timeouts
+4.5.4 Queuing Strategies
+4.5.4.1 Sending Strategy
+4.5.4.2 Receiving Strategy
+4.5.5 Messages with a null reverse-path
+
+5. Address Resolution and Mail Handling
+
+6. Problem Detection and Handling
+6.1 Reliable Delivery and Replies by Email
+6.2 Loop Detection
+6.3 Compensating for Irregularities
+
+7. Security Considerations
+7.1 Mail Security and Spoofing
+7.2 "Blind" Copies
+7.3 VRFY, EXPN, and Security
+7.4 Information Disclosure in Announcements
+7.5 Information Disclosure in Trace Fields
+7.6 Scope of Operation of SMTP Servers
+
+8. IANA Considerations
+
+9. References
+
+10. Editors' Addresses
+
+11. Acknowledgments
+
+A. TCP Transport Service
+B. Generating SMTP Commands from RFC 822 Headers 
+C. Source Routes
+D. Scenarios
+E. Other Gateway Issues
+F. Deprecated Features of RFC 821
+X. Change Summary and Loose Ends (Temporary)
+
+
+0. Abstract
+
+This document is a self-contained specification of the basic protocol for
+the Internet electronic mail transport, consolidating and updating:
+
+ - the original SMTP specification of RFC 821 [RFC-821],
+
+ - domain name system requirements and implications for mail transport from
+   RFC 1035 [RFC-DNS] and RFC 974 [RFC-974],
+
+ - the clarifications and applicability statements in RFC 1123 [RFC-1123],
+   and
+
+ - material drawn from the SMTP Extension mechanisms [SMTPEXT].
+
+It replaces RFC 821, RFC 974, and the mail transport materials of RFC 1123.
+However, RFC 821 specifies some features that are not in significant use in
+the Internet of the mid-1990s and (in appendices) some additional transport
+models.  Those sections are omitted here in the interest of clarity and
+brevity; readers needing them should refer to RFC 821.
+
+It also includes some additional material from RFC 1123 that required
+amplification.  This material has been identified in multiple ways, mostly
+by tracking flaming on various lists and newsgroups and problems of unusual
+readings or interpretations that have turned up as the SMTP extensions have
+been deployed.  Where this specification moves beyond consolidation and
+actually differs from earlier documents, it supersedes them technically as
+well as textually.
+
+Although SMTP was designed as a mail transport and delivery protocol, this
+specification also contains information that is important to its use as a
+'mail posting' protocol, as recommended for POP [RFC-POP2, RFC-POP3] and
+IMAP [RFC-IMAP4].
+
+Section 2.3 provides definitions of terms specific to this document. Except
+when the historical terminology is necessary for clarity, this document
+uses the current 'client' and 'server' terminology to identify the sending
+and receiving SMTP processes, respectively.
+
+A companion document discusses message headers, message bodies and formats
+and structures for them, and their relationship - [MSGFMT].
+
+
+1. Introduction
+
+The objective of the 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.  While this document
+specifically discusses transport over TCP, other transports are possible.
+Appendices to RFC 821 describe some of them.
+
+An important feature of SMTP is its capability to transport mail across
+transport service environments, usually referred to as "SMTP mail relaying"
+(see section 3.8).  A transport service  environment might consist of the
+mutually-TCP-accessible hosts on  the public Internet, the
+mutually-TCP-accessible hosts on a firewall-isolated private TCP/IP
+Intranet, or hosts in some other LAN or WAN environment utilizing a
+different transport-level protocol.  It is important to realize that
+"transport service environments" are one-to-one with usual definitions of
+"networks".  A process can communicate directly with another process, and
+transport mail using this protocol, through any mutually known and
+connected transport service. Conversely, mail can be relayed or gatewayed
+between processes in two different transport service environments by a
+process known and connected to each of the two transport service
+environments. The Mail eXchanger mechanisms of the domain name system
+[RFC-DNS, and section 5 of this document] allows the identity of hosts
+supporting SMTP relay and gateway processes to be specified.
+
+
+2. The SMTP Model
+
+2.1 Basic Structure
+
+The SMTP design can be pictured as:
+
+               +----------+                +----------+
+   +------+    |          |                |          |
+   | User |<-->|          |      SMTP      |          |
+   +------+    |  Sender- |Commands/Replies| Receiver-|
+   +------+    |   SMTP   |<-------------->|    SMTP  |    +------+
+   | File |<-->|          |    and Mail    |          |<-->| File |
+   |System|    |          |                |          |    |System|
+   +------+    +----------+                +----------+    +------+
+                SMTP client                SMTP server
+
+When an SMTP client has a message to transmit, it establishes a two-way
+transmission channel to an SMTP server. The role of an SMTP client is to
+transfer mail messages to one or more SMTP servers, or report its failure
+to do so.
+
+The means by which a mail message is transferred to an SMTP client, and how
+that client determines the domain name(s) to which mail messages are to be
+transferred is a local matter, and is not addressed by this document. In
+some cases, the domain name(s) transferred to, or determined by, an SMTP
+client will identify the final destination(s) of the mail message. In other
+cases, common with SMTP clients associated with implementations of the POP
+[RFC-POP2, RFC-POP3] or IMAP [RFC-IMAP4] protocols, or when the SMTP client
+is inside an isolated transport service environment, the domain name
+determined will identify an intermediate destination through which all mail
+messages are to be relayed.  SMTP clients that transfer all traffic,
+regardless of the target domain names associated with the individual
+messages, or that do not maintain queues for retrying message transmissions
+that initially cannot be completed, may otherwise conform to this
+specification but are not considered fully-capable. Fully-capable SMTP
+implementations, including the relays used by these less capable ones, and
+their destinations, are expected to support all of the queuing, retrying,
+and alternate address functions discussed in this specification.
+
+The means by which an SMTP client, once it has determined a target domain
+name, determines the identity of an SMTP server to which a copy of a
+message is to be transferred, and then performs that transfer, is covered
+by this document. To effect a mail transfer to an SMTP server, an SMTP
+client establishes a two-way transmission channel to that SMTP server. An
+SMTP client determines the address of an appropriate host running an SMTP
+server by resolving a destination domain name to either an intermediate
+Mail eXchanger host or a final target host.
+
+An SMTP server may be either the ultimate destination or an intermediate
+"relay" (that is, it may assume the role of an SMTP client after receiving
+the message) or "gateway" (that is, it may transport the message further
+using some protocol other than SMTP).  SMTP commands are generated by the
+SMTP client and sent to the SMTP server.  SMTP replies are sent from the
+SMTP server to the SMTP client in response to the commands.
+
+Once the transmission channel is established and initial handshaking
+completed, the SMTP client normally initiates a mail transaction. Such a
+transaction consists of a series of commands to specify the originator and
+destination of the mail and transmission of the message content (including
+any headers or other structure) itself. When the same message is sent to
+multiple recipients, this protocol encourages the transmission of only one
+copy of the data for all recipients at the same destination (or
+intermediate relay) host.
+
+The server responds to each command with a reply; replies may indicate that
+the command was accepted, that additional commands are expected, or that a
+temporary or permanent error condition exists. Commands specifying the
+sender or recipients may include server-permitted SMTP service extension
+requests as discussed in section 2.2.  The dialog is purposely lock-step,
+one-at-a-time, although this can be modified by mutually-agreed extension
+requests such as in [RFC-Pipeline].
+
+Once a given mail message has been transmitted, the client may either
+request that the connection be shut down or may initiate other mail
+transactions. In addition, an SMTP client may use a connection to an SMTP
+server for ancillary services such as verification of email addresses or
+retrieval of mailing list subscriber addresses.
+
+As suggested above, this protocol provides mechanisms for the transmission
+of mail.  This transmission normally occurs directly from the sending
+user's host to the receiving user's host when the two hosts are connected
+to the same transport service.  When they are not connected to the same
+transport service, transmission occurs via one or more relay SMTP servers.
+An intermediate host that acts as either an SMTP relay or as a gateway into
+some other transmission environment is usually selected through the use of
+the domain name service (DNS) Mail eXchanger mechanism.
+
+To provide relay capability, the SMTP server is supplied with the name of
+the ultimate destination host as well as the destination mailbox name.
+Usually, intermediate hosts are determined via the DNS MX record, not by
+explicit "source" routing (see appendices C and F.2).
+
+2.2 The Extension Model
+
+2.2.1 Background
+
+In an effort that started in 1990, approximately a decade after RFC 821 was
+completed, the protocol was modified with a "service extensions" model that
+permits the client and server to agree to utilize shared functionality
+beyond the original SMTP requirements. The SMTP extension mechanism defines
+a means whereby an extended SMTP client and server may recognize each
+other, and the server can inform the client as to the service extensions
+that it supports.
+
+Contemporary SMTP implementations MUST support the basic extension
+mechanisms. For instance, servers MUST support the EHLO command even if
+they do not implement any specific extensions and clients SHOULD
+preferentially utilize EHLO rather than HELO. (However, for compatibility
+with older conforming implementations, SMTP clients and servers MUST
+support the original HELO mechanisms as a fallback.)  Unless the different
+characteristics of HELO must be identified for interoperability purposes,
+this document discusses only EHLO.
+
+SMTP is widely deployed and high-quality implementations have proven to be
+very robust. However, the Internet community now considers some services to
+be important that were not anticipated when the protocol was first
+designed.  If support for those services is to be added, it must be done in
+a way that permits older implementations to continue working acceptably.
+The extension framework consists of:
+
+ - The SMTP command EHLO, superseding the earlier HELO,
+
+ - a registry of SMTP service extensions,
+
+ - additional parameters to the SMTP MAIL FROM and RCPT TO commands, and
+
+ - optional replacements for verbs defined in this protocol, such as for
+   DATA (see [RFC-BDAT]).
+
+SMTP's strength comes primarily from its simplicity.  Experience with many
+protocols has shown that protocols with few options tend towards ubiquity,
+whereas protocols with many options tend towards obscurity.
+
+Each and every extension, regardless of its benefits, must be carefully
+scrutinized with respect to its implementation, deployment, and
+interoperability costs. In many cases, the cost of extending the SMTP
+service will likely outweigh the benefit.
+
+2.2.2 Definition and Registration of Extensions
+
+The IANA maintains a registry of SMTP service extensions.  A corresponding
+EHLO keyword value is associated with each extension. Each service
+extension registered with the IANA must be defined in a formal
+standards-track or IESG-approved experimental protocol document.  The
+definition must include:
+
+ - the textual name of the SMTP service extension;
+
+ - the EHLO keyword value associated with the extension;
+
+ - the syntax and possible values of parameters associated with the
+   EHLO keyword value;
+
+ - any additional SMTP verbs associated with the extension (additional
+   verbs will usually be, but are not required to be, the same as the
+   EHLO keyword value);
+
+ - any new parameters the extension associates with the MAIL FROM or
+   RCPT TO verbs;
+
+ - a description of how support for the extension affects the behavior
+   of a server and client SMTP; and,
+
+ - the increment by which the extension is increasing the maximum
+   length of the commands MAIL FROM and/or RCPT TO, over that specified
+   in this standard.
+
+In addition, any EHLO keyword value starting with an upper or lower case
+"X" refers to a local SMTP service extension used exclusively through
+bilateral agreement.  Keywords beginning with "X" MUST NOT be used in a
+registered service extension.  Conversely, keyword values presented in the
+EHLO response that do not begin with "X" MUST correspond to a standard,
+standards-track, or IESG-approved experimental SMTP service extension
+registered with IANA.  A conforming server MUST NOT offer non-"X"-prefixed
+keyword values that are not described in a registered extension.
+
+Additional verbs and parameter names are bound by the same rules as EHLO
+keywords; specifically, verbs beginning with "X" are local extensions that
+may not be registered or standardized.  Conversely, verbs not beginning
+with "X" must always be registered.
+
+2.3 Terminology
+
+Most of the terminology in this document is common in the Internet at the
+time of its writing.  However, the following terms and concepts are used
+in special ways here, or represent differences in terminology between RFC
+821 and this document, and should be understood before reading further.
+These definitions are normative, that is, they contain specifications to
+which SMTP implementations are required to conform.
+
+The terms "MUST" and "SHOULD" (and "MUST NOT" and "SHOULD NOT") are used
+in the same general sense here as in the Host Requirements Standards
+[RFC-1123].  Specifically, "MUST" or "MUST NOT" identify absolute
+requirements for conformance to this specification.  Implementations that
+do not conform to them lie outside the scope of this specification and
+often will not interoperate properly with SMTP implementations that do
+conform.  Implementations that are fully conforming also adhere to all
+"SHOULD" and "SHOULD NOT" requirements.  Implementations that adhere to
+all "MUST" ("MUST NOT") but not to all of these are considered to be
+partially conforming.  Such implementations may interoperate properly with
+fully conforming ones and with each other, but this will typically be the
+case only if great care is taken.  Consequently, an implementation should
+violation "SHOULD" ("SHOULD NOT") requirements only under exceptional and
+well-understood circumstances. "SHOULD" (and sometimes "MUST")
+requirements are often imposed by this specification when experience has
+shown that following such requirements or restrictions leads, in practice,
+to better interoperation, or smoother operation of the Internet email
+infrastructure. As a consequence, some of these statements constitute
+recommended practices, rather than the statistically most common practice
+at the time of this writing.  Statements using "MAY" describe features or
+styles of doing things that may be followed, or not, at the discretion of
+the implementation, normally without causing significant interoperability
+problems.  
+
+2.3.1 Mail Objects
+
+SMTP transports a mail object. A mail object contains an envelope and
+content.
+
+The SMTP envelope is sent as a series of SMTP protocol units (described in
+section 3). It consists of an originator address (to which error reports
+should be directed); a delivery mode (e.g., deliver to recipient
+mailboxes); one or more recipient addresses; and optional protocol
+extension material.
+
+The SMTP content is sent in the SMTP DATA protocol unit and has two parts:
+the headers and the body. If the content conforms to existing standards,
+the headers form a collection of field/value pairs structured as described
+in [MSGFMT]; the body, if structured, is defined according to MIME
+[RFC-MIME]. The content is textual in nature, expressed using the US-ASCII
+repertoire [US-ASCII]. Although SMTP extensions (such as [8BitMIME]) may
+relax this restriction for the content body, the content headers are always
+encoded using the US-ASCII repertoire. The algorithm defined in
+[RFC-INTLHDR] is used to represent header values outside the US-ASCII
+repertoire, while still encoding them using the US-ASCII repertoire.
+
+2.3.2 Senders and Receivers
+
+In RFC 821, the two hosts participating in an SMTP transaction were
+described as the "SMTP-sender" and "SMTP-receiver".  This document has been
+changed to reflect current industry terminology and hence refers to them as
+the "SMTP client" (or sometimes just "the client") and "SMTP server" (or
+just "the server"), respectively.  Since a given host may act both as
+server and client in a relay situation, "receiver" and "sender" terminology
+is still used where needed for clarity.
+
+2.3.3 Mail Agents
+
+Additional mail system terminology became common after RFC 821 was
+published and, where convenient, is used in this specification.  In
+particular, SMTP servers and clients provide a mail transport service and
+therefore act as Mail Transfer Agents (MTAs).  Mail User Agents (MUAs or
+UAs) are normally thought of as the sources and targets of mail.  At the
+source, an MUA might collect mail to be transmitted from a user and hand it
+off to an MTA; the final ("delivery") MTA would be thought of as handing
+the mail off to an MUA (or at least transferring responsibility to it).
+However, while these terms are used with at least the appearance of great
+precision in other environments, the implied boundaries between MUAs and
+MTAs often do not accurately match common, and conforming, practices with
+Internet mail.  Hence, the reader should be cautious about inferring the
+strong relationships and responsibilities that might be implied if these
+terms were used elsewhere.
+
+2.3.4 Host
+
+For the purposes of this specification, a host is a computer system
+attached to the Internet (or, in some cases, to a private TCP/IP network)
+and supporting the SMTP protocol.  Hosts are known by names (see "domain");
+identifying them by numerical address is discouraged.
+
+2.3.5 Domain
+
+A domain (or domain name) consists of one or more dot-separated components,
+each consisting of a sequence of letters, digits, and hyphens.  Domain
+names are used as names of hosts and of other entities in the domain name
+hierarchy. For example, a  domain may refer to an alias (label of a CNAME
+RR) or the label of Mail eXchanger records to be used to deliver mail
+instead of representing a host name. See [RFC-DNS] and section 5.
+
+The domain name, as described in this document and in [RFC-DNS], is the
+entire, fully-qualified name (often referred to as an "FQDN").  A domain
+name that is not in FQDN form is no more than a local alias.  Local aliases
+MUST NOT appear in any SMTP transaction.
+
+2.3.6 Buffer and State Table
+
+SMTP sessions are stateful, with both parties carefully maintaining a
+common view of the current state.  In this document we model this state by
+a virtual "buffer" and a "state table" on the server which may be used by
+the client to, for example, "clear the buffer" or "reset the state table,"
+causing the information in the buffer to be discarded and the state to be
+returned to some previous state
+
+2.3.7 Lines
+
+SMTP commands and, unless altered by a service extension, message data, are
+transmitted in "lines".  Lines consist of zero or more data characters
+terminated by the sequence ASCII character "CR" (hex value 0D) followed
+immediately by ASCII character "LF" (hex value 0A). This termination
+sequence is denoted as <CRLF> in this document. Conforming implementations
+MUST NOT recognize or generate any other character or character sequence as
+a line terminator.
+
+2.3.8 Originator, Delivery, Relay, and Gateway Systems
+
+This specification makes a distinction among four types of SMTP systems,
+based on the role those systems play in transmitting electronic mail.  An
+"originating" system (sometimes called an SMTP originator) introduces mail
+into the Internet or, more generally, into a transport service environment.
+A "delivery" SMTP system is one that receives mail from a transport service
+environment and hands it to a mail user agent or deposits it in a message
+store which a mail user agent is expected to subsequently access.  A
+"relay" SMTP system (usually referred to just as a "relay") receives mail
+from an SMTP client and transmits it, without modification to the message
+data other than adding trace information, to another SMTP server for
+further relaying or for delivery.
+
+A "gateway" SMTP system (usually referred to just as a "gateway") receives
+mail from a client system in one transport environment and transmits it to
+a server system in another transport environment. Differences in protocols
+or message semantics between the transport environments on either side of a
+gateway may require that the gateway system perform transformations to the
+message that are not permitted to SMTP relay systems.
+
+2.3.9 Message Content and Mail Data
+
+The terms "message content" and "mail data" are used interchangeably in
+this document to describe the material transmitted after the DATA command
+is accepted and before the end of data indication is transmitted.  Message
+content includes message headers and the possibly-structured message body.
+The MIME specification [RFC-MIME] provides the Standard mechanisms for
+structured message bodies.
+
+2.3.10 Mailbox and Address
+
+As used in this specification, an "address" is a character string that
+identifies a user to whom mail will be sent or a location into which mail
+will be deposited.  The term "mailbox" refers to that depository.  The two
+terms are typically used interchangeably unless the distinction between the
+location in which mail is placed (the mailbox) and a reference to it (the
+address) is important.  An address normally consists of user and domain
+specifications.  The standard mailbox naming convention is defined to be
+"local-part@domain": contemporary usage permits a much broader set of
+applications than simple "user names" and, consequently, the local-part is
+interpreted and assigned semantics only by the host specified in the domain
+part of the address.
+
+2.3.11 Reply
+
+An SMTP 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 numeric completion code (indicating
+failure or success) usually followed by a text string.  The codes are for
+use by programs and the text is usually intended for human users.
+
+2.4 Syntax Principles
+
+2.4.1 General Syntax and Transaction Model
+
+SMTP commands and replies have a rigid syntax. All commands begin with a
+four letter command verb. All Replies begin with a three digit numeric
+code. In some commands and replies, arguments MUST follow the verb or reply
+code. Some commands do not accept arguments (after the verb), and some
+reply codes are followed, sometimes optionally, by free form text. In both
+cases, where text appears, it is separated from the verb or reply code by a
+<SP>. Complete definitions of commands and replies appear in section 4.
+
+Verbs and argument values are not case sensitive, with the sole
+exception in this specification of a mailbox local-part (SMTP
+Extensions may explicitly specify case-sensitive elements). That is, a
+command verb, an argument value other than a mailbox local-part, and
+free form text MAY be encoded in upper case, lower case, or any mixture
+of upper and lower case with no impact on its meaning.  This is NOT
+true of a mailbox local-part. The local-part of a mailbox MUST BE
+treated as case sensitive. Therefore, SMTP implementations MUST take
+care to preserve the case of mailbox local-parts.  Mailbox domains are
+not case sensitive.  However, exploiting the case sensitivity of
+mailbox local-parts impedes interoperability and is discouraged.
+
+Commands and replies are composed of characters from the ASCII character
+set [US-ASCII]. 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. More specifically, the
+unextended SMTP service provides seven bit transport only.  An originating
+SMTP client which has not successfully negotiated an appropriate extension
+with a particular server MUST NOT transmit messages with information in the
+high-order bit of octets.  If such messages are transmitted in violation of
+this rule, receiving SMTP servers MAY clear the high-order bit or reject
+the message as invalid.  In general, a relay SMTP SHOULD assume that the
+message content it has received is valid and, assuming that the envelope
+permits doing so, relay it without inspecting that content.  Of course, if
+the content is mislabeled and the data path cannot accept the actual
+content, this may result in ultimate delivery of a severely garbled message
+to the recipient.  Delivery SMTP systems MAY reject ("bounce") such
+messages rather than deliver them.  No sending SMTP system is permitted to
+send envelope commands in any character set other than US-ASCII; receiving
+systems SHOULD reject such commands, normally using "500 syntax error -
+invalid character" replies.
+
+Eight-bit message content transmission MAY be requested of the server by a
+client using extended SMTP facilities, notably the "8BITMIME" extension
+[8BITMIME].  8BITMIME SHOULD be supported by SMTP servers. However, it MUST
+not be construed as authorization to transmit unrestricted eight bit
+material.  8BITMIME MUST NOT be requested by senders for material with the
+high bit on that is not in MIME format with an appropriate content-transfer
+encoding; servers MAY reject such messages.
+
+The metalinguistic notation used in this document corresponds to the
+"Augmented BNF" used in other Internet mail system documents. The reader
+who is not familiar with that syntax should consult [ABNF]. Metalanguage
+terms used in running text are surrounded by pointed brackets (e.g.,
+<CRLF>) for clarity.
+
+2.4.2 Command and Reply Syntax
+
+The commands consist of a command verb followed by an argument field.
+Command verbs are four alphabetic characters and are case insensitive.
+
+This also applies to any symbols representing parameter values, such as
+"TO" or "to" for the forward-path.  Command verbs and the argument fields
+are separated by one or more spaces.  However, case is important in the
+local-part within the reverse-path and forward-path arguments.  In
+particular, for some hosts the user "smith" is different from the user
+"Smith".
+
+A few SMTP servers, in violation of this specification (and RFC 821)
+require that command verbs and certain argument text (such as the
+forward-path and reverse-path in RCPT and MAIL commands) be encoded by
+clients in upper case. Implementations MAY wish to employ this encoding to
+accommodate those servers.
+
+The argument field consists of a variable length character string ending
+with the character sequence <CRLF>.  The receiver will take no action until
+this sequence is received.
+
+The syntax for each command is shown with the discussion of that command.
+Common elements and parameters are shown in section 4.1.2.
+
+
+3. The SMTP Procedures: An Overview
+
+This section contains descriptions of the procedures used in SMTP: session
+initiation, the mail transaction, forwarding mail, verifying mailbox names
+and expanding mailing lists, and the opening and closing exchanges.
+Comments on relaying, a note on mail domains, and a discussion of changing
+roles are included at the end of this section.  Several complete scenarios
+are presented in appendix D.
+
+3.1 Session Initiation
+
+An SMTP session is initiated when a client opens a connection to a server
+and the server responds with an opening message.
+
+SMTP server implementations MAY include identification of their software
+and version information in the connection greeting reply after the 220
+code, a practice that permits more efficient isolation and repair of any
+problems. Implementations MAY make provision for SMTP servers to disable
+the software and version announcement where it causes security concerns.
+While some systems also identify their contact point for mail problems,
+this is not a substitute for maintaining the required "postmaster" address
+(see section 4.5.1).
+
+The SMTP protocol allows a server to formally reject a transaction while
+still allowing the initial connection as follows: a 554 response MAY be
+given in the initial connection opening message instead of the 220.  A
+server taking this approach MUST still wait for the client to send a QUIT
+(see section 4.1.1.10) before closing the connection and SHOULD respond to
+any intervening commands with "503 bad sequence of commands".  Since an
+attempt to make an SMTP connection to such a system is probably in error, a
+server returning a 554 response on connection opening SHOULD provide enough
+information in the reply text to facilitate debugging of the sending
+system.
+
+3.2 Client Initiation
+
+Once the server has sent the welcoming message and the client has received
+it, the client normally sends the EHLO command to the server, indicating
+the client's identity.  In addition to opening the session, use of EHLO
+indicates that the client is able to process service extensions and
+requests that the server provide a list of the extensions it supports.
+Older SMTP systems which are unable to support service extensions and
+contemporary clients which do not require service extensions in the mail
+session being initiated, MAY use HELO instead of EHLO.  Servers MUST NOT
+return the extended EHLO-style response to a HELO command.
+
+In the EHLO command the host sending the command identifies itself; the
+command may be interpreted as saying "Hello, I am <domain>" (and, in the
+case of EHLO, "and I support service extension requests").
+
+3.3 Mail Transactions
+
+There are three steps to SMTP mail transactions.  The transaction starts
+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 initiates transfer of the mail data and is terminated by the "end
+of mail" data indicator, which also confirms the transaction.
+
+The first step in the procedure is the MAIL command.
+
+   MAIL FROM:<reverse-path> [ <mail-parameters> ] <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. The <reverse-path> contains the source mailbox
+(between "<" and ">" brackets, which can be used to report errors (see
+section 4.2 for a discussion of error reporting).  If accepted, the
+SMTP server returns a 250 OK reply.  If the mailbox specification is
+not acceptable for some reason, the server MUST return a reply
+indicating whether the failure is permanent (i.e., will occur again if
+the client tries to send the same address again) or temporary (i.e.,
+the address might be accepted if the client tries again later). Despite
+the apparent scope of this requirement, there are circumstances in
+which the acceptability of the reverse-path may not be determined until
+one or more forward-paths (in RCPT commands) can be examined.  In those
+cases, the server MAY reasonably accept the reverse-path (with a 250
+reply) and then report problems after the forward-paths are received
+and examined.  Normally, failures produce 550 or 553 replies.
+
+Historically, the <reverse-path> can contain more than just a mailbox,
+however, contemporary systems SHOULD NOT use source routing (see appendix
+C).
+
+The optional <mail-parameters> are associated with negotiated SMTP service
+extensions (see section 2.2).
+
+The second step in the procedure is the RCPT command.
+
+   RCPT TO:<forward-path> [ <SP> <rcpt-parameters> ] <CRLF>
+
+This command gives a forward-path (normally a mailbox and domain,
+always surrounded by "<" and ">" brackets) identifying one recipient.
+If accepted, the SMTP server returns a 250 OK reply and stores the
+forward-path.  If the recipient is known not to be a deliverable
+address, the SMTP server returns a 550 reply, typically with a string
+such as "no such user - " and the mailbox name (other circumstances and
+reply codes are possible).  This step of the procedure can be repeated
+any number of times.
+
+The <forward-path> can contain more than just a mailbox.  Historically, the
+<forward-path> can be a source routing list of hosts and the destination
+mailbox, however, contemporary SMTP clients SHOULD NOT utilize source
+routes (see appendix C). Servers MUST be prepared to encounter a list of
+source routes in the forward path, but SHOULD ignore the routes or MAY
+decline to support the relaying they imply.  Similarly, servers MAY decline
+to accept mail that is destined for other hosts or systems.  These
+restrictions make a server useless as a relay for clients that do not
+support full SMTP functionality.  Consequently, restricted-capability
+clients MUST NOT assume that any SMTP server on the Internet can be used as
+their mail processing  (relaying) site. If RCPT TO appears without a
+previous MAIL FROM, the server MUST return a 503 "Bad sequence of commands"
+response. The optional <rcpt-parameters> are associated with negotiated
+SMTP service extensions (see section 2.2).
+
+The third step in the procedure is the DATA command (or some alternative
+specified in a service extension).
+
+   DATA <CRLF>
+
+If accepted, the SMTP server returns a 354 Intermediate reply and considers
+all succeeding lines up to but not including the end of mail data indicator
+to be the message text.  When the end of text is successfully received and
+stored the SMTP-receiver sends a 250 OK reply.
+
+Since the mail data is sent on the transmission channel, the end of 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 or full stop).  A transparency procedure is used to prevent
+this from interfering with the user's text (see section 4.5.2).
+
+The end of mail data indicator also confirms the mail transaction and tells
+the SMTP server to now process the stored recipients and mail data.  If
+accepted, the SMTP server returns a 250 OK reply. The DATA command can fail
+in only two ways:
+
+ - If there was no MAIL FROM, or no RCPT TO, command, or all such commands
+   were rejected, the server MAY return a "command out of sequence" (503)
+   reply.  If that reply is received, the client MUST NOT send the message
+   data; more generally, message data MUST NOT be sent unless a 354 reply
+   is received.
+
+ - If the verb is initially accepted and the 354 reply issued, the DATA
+   command should fail only if the mail transaction was incomplete (for
+   example, no recipients), or if resources were unavailable, or if the
+   server determines that the message should be rejected for policy or
+   other reasons.
+
+However, in practice, some servers do not perform recipient verification
+until after the message text is received.  These servers SHOULD treat a
+failure for one or more recipients as a "subsequent failure" and return a
+mail message as discussed in section 6.  Using a "550 mailbox not found"
+(or equivalent) reply code after the data are accepted makes it difficult
+or impossible for the client to determine which recipients failed.
+
+When RFC 822 format is being used, the mail data include the memo header
+items such as Date, Subject, To, Cc, From [MSGFMT].  Server SMTP systems
+SHOULD NOT reject messages based on perceived defects in the RFC 822 or
+MIME [RFC-MIME] message header or message body.  In particular, they MUST
+NOT reject messages in which the numbers of Resent- fields do not match or
+Resent-to appears without Resent-from and/or Resent-date.
+
+Mail transaction commands MUST be used in the order discussed above.
+
+
+3.4 Forwarding for Address Correction or Updating
+
+Forwarding support is most often required to consolidate and simplify
+addresses within, or relative to, some enterprise and less frequently to
+establish addresses to link a person's prior address with current one.
+Silent forwarding of messages (without server notification to the sender),
+for security or non-disclosure purposes, is common in the contemporary
+Internet.
+
+In both the enterprise and the "new address" cases, information hiding
+(and sometimes security) considerations argue against exposure of the
+"final" address through the SMTP protocol as a side-effect of the
+forwarding activity.  This may be especially important when the final
+address may not even be reachable by the sender.  Consequently, the
+"forwarding" mechanisms described in section 3.2 of RFC 821, and
+especially the 251 (corrected destination) reply code from RCPT TO are
+deprecated: Servers SHOULD NOT provide that service or return that code.
+
+
+3.5 Commands for Debugging Addresses
+
+3.5.1 Overview
+
+SMTP provides commands to verify a user name or obtain the content of a
+mailing list.  This is done with the VRFY and EXPN commands, which have
+character string arguments.  Implementations SHOULD support VRFY and EXPN
+(however, see section 3.5.2 and 7.3).
+
+For the VRFY command, the string is a user name or a user name and domain
+(see below). If a normal (i.e., 250) response is returned, the response MAY
+include the full name of the user and MUST include the mailbox of the user.
+It MUST be in either of the following forms:
+
+   User Name <local-part@domain>
+   local-part@domain
+
+When a name that is the argument to VRFY could identify more than one
+mailbox, the server MAY either note the ambiguity or identify the
+alternatives.  In other words, any of the following are legitimate
+response to VRFY:
+
+   553 User ambiguous
+
+or
+
+   553- Ambiguous;  Possibilities are
+   553-Joe Smith <jsmith@foo.com>
+   553-Harry Smith <hsmith@foo.com>
+   553 Melvin Smith <dweep@foo.com>
+
+or
+
+   553-Ambiguous;  Possibilities 
+   553- <jsmith@foo.com>
+   553- <hsmith@foo.com>
+   553 <dweep@foo.com>
+
+Under normal circumstances, a client receiving a 553 reply would be
+expected to expose the result to the user.  Use of exactly the forms
+given, and the "user ambiguous" or "ambiguous" keywords, possibly
+supplemented by extended reply codes such as those described in
+[RFC-REPLY], will facilitate automated translation into other languages as
+needed. Of course, a client that was highly automated or that was
+operating in another language than English, might choose to try to
+translate the response, to return some other indication to the user than
+the literal text of the reply, or to take some automated action such as
+consulting a directory service for additional information before reporting
+to the user.
+
+For the EXPN command, the string identifies a mailing list, and the
+successful (i.e., 250) multiline response MAY include the full name of the
+users and MUST give the mailboxes on the mailing list.
+
+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 MAY be
+given if a message so addressed would be delivered to everyone on the list,
+otherwise an error SHOULD be reported (e.g., "550 That is a mailing list,
+not a user" or "252 Unable to verify members of mailing list").  If a
+request is made to expand a user name, the server MAY return a positive
+response consisting of a list containing one name, or an error MAY be
+reported (e.g., "550 That is a user name, not a mailing list").
+
+In the case of a successful multiline reply (normal for EXPN) exactly one
+mailbox is to be specified on each line of the reply.  The case of an
+ambiguous request is discussed above.
+
+"User name" is a fuzzy term and has been used deliberately.  An
+implementation of the VRFY or EXPN commands MUST include at least
+recognition of local mailboxes as "user names".  However, since current
+Internet practice often results in a single host handling mail for
+multiple domains, hosts, especially hosts that provide this functionality,
+SHOULD accept the "local-part@domain" form as a "user name"; hosts MAY
+also choose to recognize other strings as "user names".
+
+The case of expanding a mailbox list requires a multiline reply, such as:
+
+   C: EXPN Example-People
+   S: 250-Jon Postel <Postel@isi.edu>
+   S: 250-Fred Fonebone <Fonebone@physics.foo-u.edu>
+   S: 250 Sam Q. Smith <SQSmith@specific.generic.com>
+
+or
+
+   C EXPN Executive-Washroom-List
+   S: 550 Access Denied to You.
+
+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 are a variety of file naming conventions in
+the Internet.  Similarly, historical variations in what is returned by
+these commands are such that the response SHOULD be interpreted very
+carefully, if at all, and SHOULD generally only be used for diagnostic
+purposes.
+
+3.5.2 VRFY Normal Response
+
+When normal (2yz or 551) responses are returned from a VRFY or EXPN
+request, the reply MUST normally include the mailbox name.
+"<local-part@domain>", where "domain" is a fully qualified domain name,
+MUST appear in the syntax.  In exceptional circumstances, free-form text
+MAY be returned.  In order to facilitate parsing by both computers and
+people, addresses SHOULD appear in pointed brackets.  When addresses,
+rather than free-form debugging information, are returned, EXPN and VRFY
+MUST return only valid domain addresses that are usable in SMTP RCPT
+commands.  Consequently, if an address implies delivery to a program or
+other system, the mailbox name used to reach that target MUST be given.
+Paths (explicit source routes) MUST NOT be returned by VRFY or EXPN.
+
+Server implementations SHOULD support both VRFY and EXPN. For security
+reasons, implementations MAY provide local installations a way to disable
+either or both of these commands through configuration options or the
+equivalent.  When these commands are supported, they are not required to
+work across relays when relaying is supported.  Since they were both
+optional in RFC 821, they MUST be listed as service extensions in an EHLO
+response, if they are supported.
+
+3.5.3 Meaning of VRFY or EXPN Success Response
+
+A server MUST NOT return a 220 code in response to a VRFY or EXPN command
+unless it has actually verified the address.  In particular, a server MUST
+NOT return 220 if all it has done is to verify that the syntax given is
+valid.  In that case, 502 (Command not implemented) or 500 (Syntax error,
+command unrecognized) SHOULD be returned.  As stated elsewhere,
+implementation of VRFY and EXPN are strongly recommended.
+Hence, implementations that return 500 or 502 for VRFY are not in full
+compliance with this specification.
+
+There may be circumstances where an address appears to be valid but cannot
+reasonably be verified in real time, particularly when a server is acting
+as a mail exchanger for another server or domain. "Apparent validity" in
+this case would normally involve at least syntax checking and might
+involve verification that any domains specified were ones to which the
+host expected to be able to relay mail.  In these situations, reply code
+252 SHOULD be returned.  These cases parallel the discussion of RCPT
+verification discussed in section 2.1.  Implementations generally SHOULD
+be more aggressive about address verification in the case of VRFY than in
+the case of RCPT, even if it takes a little longer to do so.
+
+3.5.4 Semantics and Applications of EXPN
+
+EXPN is often very useful in debugging and understanding problems with
+mailing lists and multiple-target-address aliases. Some systems have
+attempted to use source expansion of mailing lists as a means of
+eliminating duplicates.  The propagation of aliasing systems with mail on
+the Internet, for hosts (typically with MX and CNAME DNS records), for
+mailboxes (various types of local host aliases), and in various proxying
+arrangements, has made it nearly impossible for these strategies to work,
+and mail systems SHOULD NOT attempt them.
+
+3.6 Domains
+
+Only resolvable, fully-qualified, domain names (FQDNs) are permitted when
+domain names are used in SMTP.  In other words, names that can be resolved
+to MX RRs or A RRs (as discussed in section 5) are permitted, as are CNAME
+RRs whose targets can be resolved, in turn, to MX or A RRs.  Local
+nicknames or unqualified names MUST NOT be used.  There are two exceptions
+to the rule requiring FQDNs:
+
+ - The domain name given in the EHLO command MUST BE either a primary host
+   name (a domain name that resolves to an A RR) or, if the host has no
+   name, an address literal as described in section 4.1.1.1.
+
+ - The reserved mailbox name "postmaster" may be used in a RCPT TO command
+   without domain qualification (see section 4.1.1.3) and MUST be accepted
+   if so used.
+
+3.7 Relaying
+
+In general, the availability of Mail eXchanger records in the domain name
+system [RFC-DNS] makes the use of explicit source routes in the Internet
+mail system unnecessary.  Many historical problems with their
+interpretation have made their use undesirable.  SMTP clients SHOULD NOT
+generate explicit source routes except under unusual circumstances.  SMTP
+servers MAY decline to act as mail relays or to accept addresses that
+specify source routes.  When route information is encountered, they are
+also permitted to ignore the route information and simply send to the final
+destination specified as the last element in the route and SHOULD do so.
+There has been an invalid practice of using names that do not appear in the
+DNS as destination names, with the senders counting on the intermediate
+hosts specified in source routing to resolve any problems.  If source
+routes are stripped, this practice will cause failures. This is one of
+several reasons why SMTP clients MUST NOT generate invalid source routes or
+depend on serial resolution of names.
+
+When source routes are not used, the process described in RFC 821 for
+constructing a reverse-path from the forward-path is not applicable and the
+reverse-path at the time of delivery will simply be the address that
+appeared in the MAIL command.
+
+A relay SMTP server is usually the target of a DNS MX record that
+designates it, rather than the final delivery system. The relay server may
+accept or reject the task of relaying the mail in the same way it accepts
+or rejects mail for a local user.  If it accepts the task, it then becomes
+an SMTP client, establishes a transmission channel to the next SMTP server
+specified in the DNS (according to the rules in section 5), and sends it
+the mail.  If it declines to relay mail to a particular address for policy
+reasons, a 550 response SHOULD be returned.
+
+If an SMTP server has accepted the task of relaying the mail and later
+finds that the destination is incorrect or that the mail cannot be
+delivered for some other 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).  Formats specified
+for non-delivery reports by other standards (see, for example,
+[RFC-NOTARY1]) SHOULD be used if possible.
+
+This notification message must be from the SMTP server at the relay host
+or the host that first determines that delivery cannot be accomplished.
+Of course, SMTP servers MUST NOT send notification messages about problems
+transporting 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 transmitted the reverse-path
+MUST be set to null (see section 4.5.5 for additional discussion).  A MAIL
+command with a null reverse-path appears as follows:
+
+   MAIL FROM:<>
+
+As discussed in section 2.4.1, a relay SMTP has no need to inspect or act
+upon the headers or body of the message data and MUST NOT do so except
+to add its own "Received:" header (section 4.4) and to perform simple
+counting of the number of "Received:" headers in a message (section 6.2).
+
+3.8 Mail Gatewaying
+
+While the relay function discussed above operates within the Internet SMTP
+transport service environment, MX records or various forms of explicit
+routing may require that an intermediate SMTP server perform a translation
+function between one transport service and another.  As discussed in
+section 2.3.8, when such a system is at the boundary between two transport
+service environments, we refer to it as a "gateway" or "gateway SMTP".
+
+Gatewaying mail between different mail environments, such as different mail
+formats and protocols, is complex and does not easily yield to
+standardization.  However, some general requirements may be given for a
+gateway between the Internet and another mail environment.
+
+3.8.1 Header Fields in Gatewaying
+
+Header fields MAY be rewritten when necessary as messages are gatewayed
+across mail environment boundaries. This may involve inspecting the message
+body or interpreting the local-part of the destination address in spite of
+the prohibitions in section 2.4.1
+
+Other mail systems gatewayed to the Internet often use a subset of RFC-822
+headers or provide similar functionality with a different syntax, but some
+of these mail systems 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 foreign environments and
+might risk disclosure of private information (see section 7.2).
+
+3.8.2 Received Lines in Gatewaying
+
+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.
+
+Received: fields of messages originating from other environments may not
+conform exactly to this specification.  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.  As another consequence of trace fields arising in non-SMTP
+environments, receiving systems MUST NOT reject mail based on the format of
+a trace field and SHOULD be extremely robust in the light of unexpected
+information or formats in those fields.
+
+The gateway SHOULD indicate the environment and protocol in the "via"
+clauses of Received field(s) that it supplies.
+
+3.8.3 Addresses in Gatewaying
+
+>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.
+Gateways are, of course, subject to the same rules for handling source
+routes as those described for other SMTP systems in section 3.3.
+
+3.8.4 Other Header Fields in Gatewaying
+
+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, MUST reference only
+fully-qualified domain names, and MUST be effective and useful for sending
+replies.  3.8.5 The translation algorithm used to convert mail from the
+Internet protocols to another environment's protocol SHOULD 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 (or other fields) of the RFC-822 message.
+
+3.8.5 Envelopes in Gatewaying
+
+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 supplied by the foreign
+environment.  If the foreign environment has no equivalent concept, the
+gateway must select and use a best approximation, with the message
+originator's address as the default of last resort.
+
+3.9 Terminating Sessions and Connections
+
+An SMTP connection is terminated when the client sends a QUIT command.  The
+server responds with a positive reply code, after which it closes the
+connection.
+
+An SMTP server MUST NOT intentionally close the connection except:
+
+ - After receiving a QUIT command and responding with a 221 reply.
+
+ - After detecting the need to shutdown the SMTP service and returning a
+   421 response code.  This response code can be issued after the server
+   receives any command or, if necessary, asynchronously from command
+   receipt (on the assumption that the client will receive it after the
+   next command is issued).
+
+In particular, a server that closes connections in response to commands
+that are not understood is in violation of this specification. Servers are
+expected to be tolerant of unknown commands, issuing a 500 reply and
+awaiting further instructions from the client.
+
+An SMTP server which is forcibly shut down via external means SHOULD
+attempt to send a line containing a 421 response code to the SMTP client
+before exiting.  The SMTP client will normally read the 421 response code
+after sending its next command.
+
+SMTP clients that experience a connection close, reset, or other
+communications failure due to circumstances not under their control (in
+violation of the intent of this specification but sometimes unavoidable)
+SHOULD, to maintain the robustness of the mail system, treat the mail
+transaction as if a 451 response had been received and act accordingly.
+
+3.10 Mailing Lists and Aliases
+
+An SMTP-capable host SHOULD support both the alias and the list models 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
+or other entity who administers the list.  However, in this case, the
+message header (see [MSGFMT]) MUST be left unchanged; in particular, the
+"From" field of the message header is unaffected.
+
+An important mail facility is a mechanism for multi-destination delivery
+of a single message, by transforming (or "expanding" or "exploding") 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.  Servers SHOULD simply utilize the addresses on the list;
+application of heuristics or other matching rules to eliminate some
+addresses, such as that of the originator, is strongly discouraged.  We
+classify such a pseudo-mailbox as an "alias" or a "list", depending upon
+the expansion rules.
+
+3.10.1 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.
+
+3.10.2 List
+
+A mailing list may be said to operate by "redistribution" rather than
+by "forwarding".  To expand a list, the recipient mailer replaces the
+pseudo-mailbox address in the envelope with all of the expanded
+addresses.  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.
+
+
+4. The SMTP Specifications
+
+4.1 SMTP Commands
+
+4.1.1 Command Semantics and Syntax
+
+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 commands themselves are alphabetic characters terminated by
+<SP> if parameters follow and <CRLF> otherwise.  (In the interest of
+improved interoperability, SMTP receivers are encouraged to tolerate
+trailing white space before the terminating <CRLF>.)  The syntax of the
+local part of a mailbox must conform to receiver site conventions and the
+syntax specified in section 4.1.2.  The SMTP commands are discussed below.
+The SMTP replies are discussed in 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.
+
+Several commands (RSET, DATA, QUIT) are specified as not permitting
+parameters.   In the absence of specific extensions offered by the server
+and accepted by the client, clients MUST NOT send such parameters and
+servers SHOULD reject commands containing them as having invalid syntax.  
+
+4.1.1.1  Extended HELLO (EHLO) or HELLO (HELO)
+
+These commands are used to identify the SMTP client to the SMTP server.
+The argument field contains the fully-qualified domain name of the SMTP
+client if one is available.  In situations in which the SMTP client system
+does not have a meaningful domain name (e.g., when its address is
+dynamically allocated and no reverse mapping record is available), the
+client SHOULD send an address literal (see section 4.1.3), optionally
+followed by information that will help to identify the client system.
+
+The SMTP server identifies itself to the SMTP client in the connection
+greeting reply and in the response to this command.
+
+A client SMTP SHOULD start an SMTP session by issuing the EHLO command. If
+the SMTP server supports the SMTP service extensions it will give a
+successful response, a failure response, or an error response. If the SMTP
+server, in violation of this specification, does not support any SMTP
+service extensions it will generate an error response.  Older client SMTP
+systems MAY, as discussed above, use HELO (as specified in RFC 821) instead
+of EHLO, and servers MUST support the HELO command and reply properly to
+it.  In any event, a client MUST issue HELO or EHLO before starting a mail
+transaction.
+
+These commands, and a "250 OK" reply to one of them, confirm that both the
+SMTP client and the SMTP server are in the initial state, that is, there is
+no transaction in progress and all state tables and buffers are cleared.
+
+Normally, the response to EHLO will be a multiline reply.  Each line of the
+response contains a keyword and, optionally, one or more parameters.  The
+syntax for a positive response, using the ABNF notation and low-level
+terminals of [ABNF], is:
+
+   ehlo-ok-rsp  ::=      "250"    domain [ <SP> greeting ] <CRLF>
+                  / (    "250-"   domain [ <SP> greeting ] <CRLF>
+                      *( "250-"   ehlo-line                <CRLF> )
+                         "250"    <SP> ehlo-line           <CRLF>    )
+   
+   greeting     ::= 1*<any character other than CR or LF>
+   
+   ehlo-line    ::= ehlo-keyword *( <SP> ehlo-param )
+   
+   ehlo-keyword ::= (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
+                ; syntax and values depend on ehlo-keyword
+
+   ehlo-param   ::= 1*<any CHAR excluding <SP> and all
+                       control characters (US-ASCII 0-31
+                       inclusive)>
+   
+   ALPHA        ::= any one of the 52 alphabetic characters, i.e.,
+                    (A through Z in upper case, and, a through z in lower
+					case) 
+
+Although EHLO keywords may be specified in upper, lower, or mixed case,
+they MUST always be recognized and processed in a case-insensitive manner.
+This is simply an extension of practices specified in RFC 821 and section
+2.4.1.
+
+4.1.1.2 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.  In general, the MAIL command may be sent only when no mail
+transaction is in progress, see section 4.1.4.
+
+The reverse-path consists of the sender mailbox or a list of hosts.  In
+some types of reporting messages for which a reply is likely to cause a
+mail loop (for example, mail delivery and nondelivery notifications), the
+reverse-path may be null (see section 3.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.
+
+If service extensions were negotiated, the MAIL command may also carry
+parameters associated with a particular service extension.
+
+Syntax:
+
+   "MAIL FROM:" Reverse-path  [ <SP> Mail-parameters ]
+
+or
+   "MAIL FROM:<>" [ <SP> Mail-parameters ] 
+
+4.1.1.3 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 normally consists of the required destination mailbox or
+mailboxes.  Sending systems SHOULD not generate the optional list of hosts
+known as a source route.  Receiving systems MUST recognize source route
+syntax but SHOULD strip off the source route specification and utilize the
+domain name associated with the mailbox as if the source route had not been
+provided.
+
+Similarly, relay hosts SHOULD strip or ignore source routes, and names MUST
+NOT be copied into the reverse-path. When mail reaches its ultimate
+destination (the forward-path contains only a destination mailbox), the
+SMTP server inserts it into the destination mailbox in accordance with its
+host mail conventions.
+
+For example, mail received at relay host xyz.com with envelope commands
+
+   MAIL FROM:<userx@y.foo.org>
+   RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org>
+
+will normally be sent directly on to host d.bar.org with envelope commands
+
+   MAIL FROM:<userx@y.foo.org>
+   RCPT TO:<USERC@D.bar.org>
+
+As provided in appendix C, xyz.com MAY also choose to relay the message to
+jkl.org, using the envelope commands
+
+   MAIL FROM:<userx@y.foo.org>
+   RCPT TO:<@jkl.org:userc@d.bar.org>
+
+Of course, since hosts are not required to relay mail at all, xyz.com may
+also reject the message entirely when the RCPT TO command is received,
+using a 550 code (since this is a "policy reason").
+
+If service extensions were negotiated, the RCPT TO command may also carry
+parameters associated with a particular service extension offered by the
+server.  The client MUST NOT transmit parameters other than those
+associated with a service extension offered by the server in its EHLO
+response.
+
+Syntax:
+   "RCPT TO:" Forward-path  [ <SP> Rcpt-parameters ]
+or
+   "RCPT TO:<Postmaster>" [ <SP> Rcpt-parameters ]
+
+4.1.1.4 DATA (DATA)
+
+The receiver treats the lines (strings ending in <CRLF> sequences, as
+described in section 2.3.7) following the command as mail data from the
+sender. This command causes the mail data to be appended to the mail data
+buffer.  The mail data may contain any of the 128 ASCII character codes,
+although experience has indicated that use of control characters other than
+SP, HT, CR, and LF (especially the ASCII "Null" character) may cause
+problems and SHOULD be avoided when possible.
+
+The mail data is terminated by a line containing only a period, that is,
+the character sequence "<CRLF>.<CRLF>" (see section 4.5.2).  This is the
+end of mail data indication.  Note that the first <CRLF> of this
+terminating sequence is also the <CRLF> that ends the final line of the
+data (message text) or, if there was no data, ends the DATA command itself.
+An extra <CRLF> MUST NOT be added, as that would cause an empty line to be
+added to the message. The only exception to this rule would arise if the
+message body were passed to the originating SMTP-sender with a final "line"
+that did not end in <CRLF>; in that case, the originating SMTP system MUST
+either reject the message as invalid or add <CRLF> in order to have the
+receiving SMTP server recognize the "end of data" condition.
+
+The custom of accepting lines ending only in <LF>, as a concession to
+non-conforming behavior on the part of some UNIX systems, has proven to
+cause more interoperability problems than it solves, and SMTP server
+systems MUST NOT do this, even in the name of improved robustness.  In
+particular, the sequence "<LF>.<LF>" (bare line feeds, without carriage
+returns) MUST NOT be treated as equivalent to <CRLF>.<CRLF> as the end of
+mail data indication.
+
+Receipt of the end of mail data indication requires the server to 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 the receiver MUST send a failure reply. The
+SMTP model does not allow for partial failures at this point: either the
+message is accepted by the server for delivery and a positive response is
+returned or it is not accepted and a failure reply is returned.  Errors
+that are diagnosed subsequently MUST be reported in a mail message, as
+discussed in section 4.4 In sending a positive completion reply to the end
+of data indication, the receiver takes full responsibility for the message
+(see section 6.1).
+
+When the SMTP server accepts a message either for relaying or for final
+delivery, it inserts a trace record (also referred to interchangeably as a
+"time stamp line" or "Received" line) at the top of the mail data.  This
+trace record indicates the identity of the host that sent the message, 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.  Details for formation of these lines,
+including their syntax, is specified in section 4.4.
+
+4.1.1.5 RESET (RSET)
+
+This command specifies that the current mail transaction will be aborted.
+Any stored sender, recipients, and mail data MUST be discarded, and all
+buffers and state tables cleared.  The receiver MUST send a "250 OK" reply
+to a RSET command with no arguments.  A reset command may be issued by the
+client at any time.  It is effectively equivalent to a NOOP if issued
+immediately after EHLO, before EHLO is issued in the session, after an
+end-of-data indicator has been sent and acknowledged, or immediately before
+a QUIT. In other situations, it restores the state to that immediately
+after the most recent EHLO.  An SMTP server MUST NOT close the connection
+as the result of receiving a RSET; that action is reserved for QUIT (see
+section 4.1.1.10).
+
+Since EHLO implies some additional processing and response by the server,
+RSET will normally be more efficient than reissuing that command, even
+though the formal semantics are the same.
+
+There are circumstances, contrary to the intent of this specification, in
+which an SMTP server may receive an indication that the underlying TCP
+connection has been closed or reset.  To preserve the robustness of the
+mail system, SMTP servers SHOULD be prepared for this condition and SHOULD
+treat it as if a QUIT had been received before the connection disappeared.
+
+Syntax:
+   "RSET"
+
+4.1.1.6 VERIFY (VRFY)
+
+This command asks the receiver to confirm that the argument identifies a
+user or mailbox.  If it is a user name, information is returned as
+specified in section 3.5.
+
+This command has no effect on the reverse-path buffer, the forward-path
+buffer, or the mail data buffer.
+
+Syntax: 
+   "VRFY" <SP> String
+
+4.1.1.7 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.  If the
+command is successful, a reply is returned containing information as
+described in section 3.5.  This reply will have multiple lines except in
+the trivial case of a one-member list.
+
+This command has no effect on the reverse-path buffer, the forward-path
+buffer, or the mail data buffer.
+
+Syntax:
+   "EXPN" <SP> String
+
+4.1.1.8 HELP (HELP)
+
+This command causes the server to send helpful information to the client.
+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 the reverse-path buffer, the forward-path
+buffer, or the mail data buffer.
+
+SMTP servers SHOULD support HELP without arguments and MAY support it with
+arguments.
+
+Syntax:
+   "HELP" [ <SP> String ]
+
+4.1.1.9 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 the reverse-path buffer, the forward-path
+buffer, or the mail data buffer.  If a parameter string is specified,
+servers SHOULD ignore it.
+
+Syntax:
+   "NOOP" [ <SP> String ]
+
+
+4.1.1.10 QUIT (QUIT)
+
+This command specifies that the receiver MUST send an OK reply, and then
+close the transmission channel.
+
+The receiver MUST NOT intentionally close the transmission channel until it
+receives and replies to a QUIT command (even if there was an error).  The
+sender MUST NOT intentionally close the transmission channel until it sends
+a QUIT command and receives the reply (even if there was an error response
+to a previous command).  If the connection is closed prematurely due to
+violations of the above or system or network failure, the server MUST
+cancel any pending transaction, but not undo any previously completed
+transaction, and generally MUST act as if the command or transaction in
+progress had received a temporary error (i.e., a 4yz response).
+
+Syntax: 
+   "QUIT"
+
+4.1.2 Lower-level Syntax
+
+The syntax of the argument fields of the above commands (using the syntax
+specified in [ABNF] where applicable) is given below.  Some of the
+productions given below are used only in conjunction with source routes as
+described in appendix C.  Terminals not defined in this document, such as
+ALPHA, DIGIT, SP, CR, LF, CRLF, are as defined in the "core" syntax
+(section 6) of [ABNF] or in the syntax of [MSGFMT].
+
+   Reverse-path = Path
+
+   Forward-path = Path
+
+   Path = "<" [ A-d-l ":" ] Mailbox ">"
+
+   A-d-l = At-domain *( "," A-d-l )    ; Note that this form, the
+                                 so-called "source route", MUST BE
+                                 accepted, SHOULD NOT be generated,
+                                 and SHOULD be ignored.
+
+   At-domain = "@" Domain
+
+   Mail-parameters = *( <SP> Keyword "=" Argument )
+
+   Rcpt-parameters =  *( <SP> Keyword "=" Argument )
+
+   Keyword  = Ldh-str
+   Argument = Atom
+
+   Domain = sub-domain 1*("." sub-domain) / address-literal
+
+   sub-domain = let-dig *(Ldh-str)
+   address-literal = "[" IPv4-address-literal / 
+                  IPv6-address-literal / General-address-literal "]"
+   IPv4-address-literal = snum 3*3("." snum)
+   IPv6-address-literal = "IPv6 " IPv6-addr-string
+   IPv6-addr-string = String         ; IPv6 address in standard form
+                                       [IPv6AddrSpec].  Since this
+                                       form uses colon characters,
+                                       the String will actually need
+                                       to be quoted in all cases.
+   General-address-literal = Standardized-tag <SP> String
+   Standardized-tag = Ldh-str        ; Specified in a
+                                       standards-track RFC 
+                                       and registered with IANA
+   snum = 1*3Digit                   ; representing a decimal integer
+                                       value in the range 0 through 255 
+   let-dig = Alpha / Digit
+   ldh-str = *( Alpha / Digit / "-" ) let-dig
+
+   Mailbox = Local-part "@" Domain
+
+   Local-part = Dot-string / Quoted-string
+
+   Dot-string = Atom [ "." Atom ]
+
+While the above definition for Local-part is relatively permissive, for
+maximum interoperability, a host that expects to receive mail SHOULD avoid
+defining mailboxes where the Local-part requires (or uses) the
+Quoted-string form or where the Local-part is case-sensitive.  For any
+purposes that require generating or comparing Local-parts (e.g., to
+specific mailbox names), all quoted forms MUST be treated as equivalent and
+the sending system SHOULD transmit the form that uses the minimum quoting
+possible.
+
+Systems MUST NOT define mailboxes in such a way as to require the use of
+non-ASCII characters (octets with the high order bit set to one) or ASCII
+"control characters" (decimal value 0-31 and 127).  These characters MUST
+NOT be used in MAIL FROM or RCPT TO commands or other commands that require
+mailbox names.
+
+   String = Atom / Quoted-string
+
+   special = <<Msg-fmt-special>> /     [[placeholder, see above]]
+             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" indicates a single nine
+character user field with the comma being the fourth character of the
+field.
+
+To promote interoperability and consistent with long-standing guidance
+about conservative use of the DNS in naming and applications (e.g., see
+section 2.3.1 of the base DNS document [RFC-1015]), characters outside the
+set of alphas, digits, and hyphen MUST NOT appear in domain name labels
+for SMTP clients or servers.  In particular, the underscore character is
+not permitted.  SMTP servers that receive a command in which illegal
+character codes have been employed, and for which there are no other
+reasons for rejection, MUST reject that command with a 501 response.
+
+4.1.3 Address Literals
+
+Sometimes a host is not known to the domain name system and communication
+(and, in particular, communication to report and repair the error) is
+blocked.  To bypass this barrier a special literal form of the address is
+allowed as an alternative to a domain name.  For IPv4 addresses, this form
+uses four small decimal integers separated by dots and enclosed by brackets
+such as [123.255.37.2], which indicates an (IPv4) Internet Address in
+sequence-of-octets form.  For IPv6 and other forms of addressing that might
+eventually be standardized, the form consists of a standardized "tag" that
+identifies the address syntax, a space, and the address itself, in a format
+specified as part of the IPv6 standards [IPv6AddrString].
+
+4.1.4 Order of Commands
+
+There are restrictions on the order in which these commands may be used.
+
+A session that will contain mail transactions MUST first be initialized by
+the use of the EHLO command.  An SMTP server SHOULD accept commands for
+non-mail transactions (e.g., VRFY or EXPN) without this initialization.
+
+An EHLO command MAY be issued by a client later in the session.  If it is
+issued after the session begins, the SMTP server MUST clear all buffers and
+reset the state exactly as if a RSET command had been issued.  In other
+words, the sequence of RSET followed immediately by EHLO is redundant, but
+not harmful other than in the performance cost of executing unnecessary
+commands.
+
+If the EHLO command is not acceptable to the SMTP server, 501, 500, or 502
+failure replies MUST be returned as appropriate.  The SMTP server MUST stay
+in the same state after transmitting these replies that it was in before
+the EHLO was received.
+
+The SMTP client MUST ensure that the domain parameter to the EHLO command
+is a valid principal host name (not a CNAME or MX name) for its host.  If
+this is not possible (e.g., when the client's address is dynamically
+assigned and the client does not have an obvious name), an address literal
+SHOULD be substituted for the domain name and supplemental information
+provided that will assist in identifying the client.
+
+An SMTP server MAY verify that the domain name parameter in the EHLO
+command actually corresponds to the IP address of the client. However, the
+server MUST NOT refuse to accept a message if the verification fails: the
+information about verification failure is for logging and tracing only.
+
+The NOOP, HELP, EXPN, VRFY, and RSET commands can be used at any time
+during a session, or without previously initializing a session.  SMTP
+servers SHOULD process these normally (that is, not return a 503 code) even
+if no EHLO command has yet been received; clients SHOULD open a session
+with EHLO before sending these commands.
+
+If these rules are followed, the example in RFC 821 that shows "550 access
+denied to you" in response to an EXPN command is incorrect unless an EHLO
+command precedes the EXPN or the denial of access is based on the client's
+IP address or other authentication or authorization-determining mechanisms.
+
+The MAIL command (or the obsolete SEND, SOML, or SAML commands) begins a
+mail transaction.  Once started, a mail transaction consists of a
+transaction beginning command, one or more RCPT commands, and a DATA
+command, in that order.  A mail transaction may be aborted by the RSET (or
+a new EHLO) command.  There may be zero or more transactions in a session.
+MAIL (or SEND, SOML, or SAML) MUST NOT be sent if a mail transaction is
+already open, i.e., it should be sent only if no mail transaction had been
+started in the session, or it the previous one successfully concluded with
+a successful DATA command, or if the previous one was aborted with a RSET.
+
+If the transaction beginning command argument is not acceptable, a 501
+failure reply MUST be returned and the SMTP server MUST stay in the same
+state.  If the commands in a transaction are out of order to the degree
+that they cannot be processed by the server, a 503 failure reply MUST be
+returned and the SMTP server MUST stay in the same state.
+
+The last command in a session MUST be the QUIT command.  The QUIT command
+cannot be used at any other time in a session, but SHOULD be used by the
+client SMTP to request connection closure, even when no session opening
+command was sent and accepted.
+
+4.1.5 Private-use Commands
+
+As specified in section 2.2.2, commands starting in "X" may be used by
+bilateral agreement between the client (sending) and server (receiving)
+SMTP agents.  An SMTP server that does not recognize such a command is
+expected to reply with "500 Command not recognized".  An extended SMTP
+server MAY list the feature names associated with these private commands in
+the response to the EHLO command.
+
+Commands sent or accepted by SMTP systems that do not start with "X" MUST
+conform to the requirements of section 2.2.2.
+
+4.2 SMTP Replies
+
+Replies to SMTP commands serve to ensure the synchronization of requests
+and actions in the process of mail transfer and to guarantee that the SMTP
+client always knows the state of the SMTP server. Every command MUST
+generate exactly one reply.
+
+The details of the command-reply sequence are described in section 4.3.
+
+An SMTP reply consists of a three digit number (transmitted as three
+alphanumeric characters) followed by some text unless specified otherwise
+in this document.  The number is for use by automata to determine what
+state to enter next; the text is for the human user.  The three digits
+contain enough encoded information that the SMTP client need not examine
+the text and may either discard it or pass it on to the user, as
+appropriate. Exceptions are as noted elsewhere in this document.  In
+particular, the 220, 221, 251, 421, and 551 reply codes are associated
+with message text that must be parsed and interpreted by machines.  In the
+general case, 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 section 4.2.1.  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 section 4.2.1).  Since, in
+violation of this specification, the text is sometimes not sent, clients
+which do not receive it SHOULD be prepared to process the code alone (with
+or without a trailing space character).  Only the EHLO, EXPN, and HELP
+commands are expected to result in multiline replies in normal
+circumstances, however, multiline replies are allowed for any command.
+
+In ABNF, server responses are:
+
+  Greeting = "220 " Domain [ SP text ] CRLF
+  Reply-line = Reply-code [ SP text ] CRLF 
+
+where "Greeting" appears only in the 220 response that announces that the
+server is opening its part of the connection.
+
+An SMTP server SHOULD send only the reply codes listed in this document.
+An SMTP server SHOULD use the text shown in the examples whenever
+appropriate.
+
+An SMTP client MUST determine its actions only by the reply code, not by
+the text (except for 251 and 551 and, if necessary, 220, 221, and 421
+replies); in the general case, any text, including no text at all (although
+senders SHOULD NOT send bare codes), MUST be acceptable. The space (blank)
+following the reply code is considered part of the text.  Whenever
+possible, a receiver-SMTP SHOULD test the first digit (severity indication)
+of the reply code.
+
+The list of codes that appears below must not be construed as permanent.
+While the addition of new codes should be a rare and significant activity,
+with supplemental information in the textual part of the response being
+preferred, new codes may be added as the result of new Standards or
+Standards-track specifications. Consequently, a sender-SMTP MUST be
+prepared to handle codes not specified in this document and MUST do so by
+interpreting the first digit only.
+
+4.2.1 Reply Code Severities and Theory
+
+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 SMTP client, or one that receives an unexpected code, will
+be able to determine its next action (proceed as planned, redo, retrench,
+etc.) by examining this first digit.  An SMTP client that wants to know
+approximately what kind of error occurred (e.g., mail system error, command
+syntax error) may examine the second digit.  The third digit and any
+supplemental information that may be present is reserved 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
+   SMTP client should send another command specifying whether to continue
+   or abort the action. Note: unextended SMTP does not have any commands
+   that allow this type of reply, and so does not have 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 SMTP client
+   should send another command specifying this information.  This reply is
+   used in command sequence groups (i.e., in DATA).
+
+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 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- SMTP agents)
+   must agree on the interpretation. Each reply in this category might have
+   a different time value, but the SMTP client is encouraged to try again.
+   A rule of thumb to determine whether a reply fits into the 4yz or the
+   5yz category (see below) is that replies are 4yz if they can be
+   successful if repeated without any change in command form or in
+   properties of the sender or receiver.  (that is, 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 SMTP client 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 SMTP client 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.
+
+x4z   Unspecified.
+
+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 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 SMTP client any new information, will return a 250 reply.  The
+reply 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 SMTP client 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>.  As
+noted above, servers SHOULD send the <SP> if subsequent text is not sent,
+but clients MUST be prepared for it to be omitted.
+
+For example:
+   123-First line
+   123-Second line
+   123-234 text beginning with numbers
+   123 The last line
+
+In many cases the SMTP client 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 client in the
+reply "text".  The client will be able to identify these cases from the
+current context.
+
+4.2.2 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  (see section 4.2.4)
+   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>
+      (See section 3.4)
+   252 Cannot VRFY user, but will accept message and attempt 
+       delivery
+      (See section 3.5.3)
+   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, or command rejected
+      for policy reasons)
+   451 Requested action aborted: error in processing
+   551 User not local; please try <forward-path>
+      (See section 3.4)
+   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 (Or, in the case of a connection-opening
+       response, "No SMTP service here")
+
+4.2.3  Reply Codes in Numeric Order
+
+   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>
+      (See section 3.4)
+   252 Cannot VRFY user, but will accept message and attempt 
+      delivery
+      (See section 3.5.3)
+
+   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 (see section 4.2.4)
+   503 Bad sequence of commands
+   504 Command parameter not implemented
+   550 Requested action not taken: mailbox unavailable
+      (e.g., mailbox not found, no access, or command rejected
+      for policy reasons)
+   551 User not local; please try <forward-path>
+      (See section 3.4)
+   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  (Or, in the case of a connection-opening
+       response, "No SMTP service here")
+
+4.2.4 Reply Code 502
+
+Questions have been raised as to when reply code 502 (Command not
+implemented) SHOULD be returned in preference to other codes.  502 SHOULD
+be used when the command is actually recognized by the SMTP server, but not
+implemented.  If the command is not recognized, code 500 SHOULD be
+returned.  Extended SMTP systems MUST NOT list capabilities in response to
+EHLO for which they will return 502 (or 500) replies.
+
+4.2.5 Reply Codes After DATA and the Subsequent <CRLF>.<CRLF>
+
+When an SMTP server returns a positive completion status (2yz code) after
+the DATA command is completed with <CRLF>.<CRLF>, it accepts responsibility
+for:
+
+ - delivering the message (if the recipient mailbox exists), or
+
+ - if attempts to deliver the message fail due to transient conditions,
+   retrying delivery some reasonable number of times at intervals as
+   specified in section 4.5.4.
+
+ - if attempts to deliver the message fail due to permanent conditions, or
+   if repeated attempts to deliver the message fail due to transient
+   conditions, returning appropriate notification to the sender of the
+   original message (using the address in the SMTP MAIL FROM command).
+
+When an SMTP server returns a transient error completion status (4yz) code
+after the DATA command is completed with <CRLF>.<CRLF>, it MUST NOT make
+any further attempt to deliver that message.  The SMTP client retains
+responsibility for delivery of that message and may either return it to the
+user or requeue it for a subsequent attempt (see section 4.5.4.1).  The
+sending user SHOULD be able to interpret the return of a transient or
+permanent failure status as a non-delivery indication.
+
+4.3 Sequencing of Commands and Replies
+
+4.3.1 Sequencing Overview
+
+The communication between the sender and receiver is an alternating
+dialogue, controlled by the sender.  As such, the sender issues a command
+and the receiver responds with a reply.  Unless other arrangements are
+negotiated through service extensions, 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 (the
+fully-qualified primary domain name) of the server host as the first word
+following the reply code.  Sometimes the host will have no meaningful name.
+See 4.1.3 for a discussion of alternatives in these situations.
+
+For example,
+   220 ISIF.USC.EDU Service ready
+or
+   220 mail.foo.com SuperSMTP v 6.1.2 Service ready
+or
+   220 [10.0.0.1] Clueless host service ready
+
+The table below lists alternative success and failure replies for each
+command.  These SHOULD 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.
+
+4.3.2 Command-Reply Sequences
+
+Each command is listed with its usual possible replies.  The prefixes used
+before the possible replies are "I" for intermediate, "S" for success, and
+"E" for error.  Since some servers may generate other replies under special
+circumstances, and to allow for future extension, SMTP clients SHOULD, when
+possible, interpret only the first digit of the reply and MUST be prepared
+to deal with unrecognized reply codes by interpreting the first digit only.
+Unless extended using the mechanisms described in section 2.2, SMTP servers
+MUST NOT transmit reply codes to an SMTP client that are other than three
+digits or that do not start in a digit between 2 and 5 inclusive.
+
+These sequencing rules and, in principle, the codes themselves, can be
+extended or modified by SMTP extensions offered by the server and accepted
+(requested) by the client.
+
+In addition to the codes listed below, any SMTP command can return any of
+the following codes if the corresponding unusual circumstances are
+encountered:
+
+500  For the "command line too long" case or if the command name was not
+   recognized.  Note that producing a "command not recognized" error in
+   response to the required subset of these commands is a violation of this
+   specification.
+
+501  Syntax error in command or arguments.  In order to provide for future
+   extensions, commands that are specified in this document as not
+   accepting arguments (DATA, RSET, QUIT) SHOULD return a 501 message if
+   arguments are supplied in the absence of EHLO-advertised extensions.
+
+421  Service shutting down and closing transmission channel
+
+Specific sequences are:
+
+CONNECTION ESTABLISHMENT
+   S: 220
+   E: 554
+EHLO or HELO
+   S: 250
+   E: 504, 550
+MAIL
+   S: 250
+   E: 552, 451, 452, 550, 553, 503
+RCPT
+   S: 250, 251 (but see section 3.4 for discussion of 251)
+   E: 550, 551, 552, 553, 450, 451, 452, 503, 550
+DATA
+   I: 354 -> data -> S: 250
+                     E: 552, 554, 451, 452
+   E: 451, 554, 503
+RSET
+   S: 250
+VRFY
+   S: 250, 251, 252
+   E: 550, 551, 553, 502, 504
+EXPN
+   S: 250, 252
+   E: 550, 500, 502, 504
+HELP
+   S: 211, 214
+   E: 502, 504
+NOOP
+   S: 250
+QUIT
+   S: 221
+
+4.4 Trace Information
+
+When an SMTP server receives a message for delivery or further processing,
+it MUST insert trace ("time stamp" or "Received") information at the
+beginning of the message content, as discussed in section 4.1.1.4.
+
+This line MUST be structured as follows:
+
+ - The FROM field, which MUST be supplied in an SMTP environment, SHOULD
+   contain both (1) the name of the source host as presented in the EHLO
+   command and (2) an address 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.  This may raise some security issues and is
+   usually not desirable; see section 7.2.
+
+An Internet mail program MUST NOT change a Received: line that was
+previously added to the message header.  SMTP servers MUST prepend Received
+lines to messages; they MUST NOT change the order of existing lines or
+insert Received lines in any other location.
+
+As the Internet grows, comparability of Received fields is important for
+detecting problems, especially slow relays.  SMTP servers that create
+Received fields SHOULD use explicit offsets in the dates (e.g., -0800),
+rather than time zone names of any type.  Local time (with an offset) is
+preferred to UT when feasible.  This formulation allows slightly more
+information about local circumstances to be specified.  If UT is needed,
+the receiver need merely do some simple arithmetic to convert the values.
+Use of UT loses information about the time zone-location of the server.  If
+a time zone name is used, it SHOULD be included in a comment.
+
+When the delivery SMTP server makes the "final delivery" of a message, it
+inserts a return-path line at the beginning of the mail data.  This use of
+return-path is required; mail systems MUST support it.  The return-path
+line preserves the information in the <reverse-path> from the MAIL
+command.  Here, final delivery means the message has left the SMTP
+enviroment.  Normally, this would mean it had been delivered to the
+destination user or an associated mail drop, 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 to be different from the
+actual sender's mailbox, for example, if error responses are to be
+delivered to a special error handling mailbox rather than to the message
+sender.  When mailing lists are involved, this arrangement is common and
+useful as a means of directing errors to the list maintainer rather than
+the message originator.
+
+The text above implies 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 headers and body [MSGFMT].
+
+It is sometimes difficult for an SMTP server to determine whether or not it
+is making final delivery since forwarding or other operations may occur
+after the message is accepted for delivery.  Consequently, any further
+(forwarding, gateway, or relay) systems MAY remove the return path and
+rebuild the MAIL FROM command as needed to ensure that exactly one such
+line appears in a delivered message.
+
+A message-originating SMTP system SHOULD NOT send a message that already
+contains a Return-path header.  SMTP servers performing a relay function
+MUST NOT inspect the message data, and especially not to the extent needed
+to determine if Return-path headers are present. SMTP servers making final
+delivery MAY remove Return-path headers before adding their own.
+
+The primary purpose of the Return-path is to designate the address to which
+messages indicating non-delivery or other mail system failures are to be
+sent.  For this to be unambiguous, exactly one return path SHOULD be
+present when the message is delivered.  Systems using RFC 822 syntax with
+non-SMTP transports SHOULD designate an unambiguous address, associated
+with the transport envelope, to which error reports (e.g., non-delivery
+messages) should be sent.
+
+Historical note: Text in RFC 822 that appears to contradict the use of the
+Return-path header (or the envelope MAIL FROM address) as the destination
+for error messages is not applicable on the Internet. The MAIL FROM address
+(as copied into the Return-path) MUST be used as the target of any mail
+containing delivery error messages.
+
+In particular:
+
+ - a gateway from SMTP->elsewhere SHOULD insert a return-path header,
+   unless it is known that the "elsewhere" transport also uses Internet
+   domain addresses and maintains the envelope sender address separately.
+
+ - a gateway from elsewhere->SMTP SHOULD delete any return-path header
+   present in the message, and either copy that information to the SMTP
+   envelope or combine it with information present in the envelope of the
+   other transport system to construct the MAIL FROM part of the SMTP
+   envelope.
+
+The server must give special treatment to cases in which the processing
+following the end of mail data indication is only partially successful.
+This could happen if, after accepting several recipients and the mail data,
+the SMTP server finds that the mail data could be successfully delivered to
+some, but not all, of the recipients.  In such cases, the response to the
+DATA command MUST be an OK reply.  However, the SMTP server MUST compose
+and send an "undeliverable mail" notification message to the originator of
+the message.
+
+A single notification listing all of the failed recipients or separate
+notification messages MUST be sent for each failed recipient.  For economy
+of processing by the sender, the former is preferred when possible.  All
+undeliverable mail notification messages are sent using the MAIL command
+(even if they result from processing the obsolete SEND, SOML, or SAML
+commands) and use a null return path as discussed in section 3.7.
+
+The time stamp line and the return path line are formally defined as
+follows:
+ 
+   Return-path-line = "Return-Path:" FWS Reverse-path <CRLF>
+   
+   Time-stamp-line = "Received:" FWS Stamp <CRLF>
+   
+   Stamp = From-domain By-domain Opt-info ";"  FWS Daytime
+   
+   From-domain = "FROM" FWS Extended-Domain CFWS 
+   
+   By-domain = "BY" FWS Extended-Domain CFWS
+   
+   Extended-Domain = Domain / 
+              ( Domain FWS "(" TCP-info ")" ) /
+              ( Address-literal FWS "(" TCP-info ")"
+    TCP-info = Address-literal / ( Domain FWS Address-literal )
+                   ; Information derived by server from TCP connection,
+ 				     not client EHLO. 
+
+   Opt-info = [Via] [With] [ID] [For]
+   
+   Via = "VIA" FWS Link CFWS 
+   
+   With = "WITH" FWS Protocol CFWS 
+   
+   ID = "ID" FWS String / msg-id CFWS 
+   
+   For = "FOR" FWS 1*( Path / Mailbox ) CFWS 
+   
+   Link = "TCP" / Addtl-Link
+   Addtl-Link = Atom       ; Additional standard names for links are
+                             registered with the Internet Assigned
+                             Numbers Authority (IANA).  "Via" is
+							 primarily of value with non-Internet
+							 transports.
+                             SMTP servers SHOULD NOT use unregistered
+                             names. 
+   Protocol = "ESMTP" / "SMTP" / Attdl-Protocol
+   Attdl-Protocol = Atom    ; Additional standard names for protocols
+                              are registered with the Internet Assigned
+                              Numbers Authority (IANA).  SMTP servers
+                              SHOULD NOT use unregistered names.
+   
+   Daytime =  FWS [ day-of-week "," FWS ] Date FWS Time
+   
+   Date = DD FWS Mon FWS YYYY
+          ; Note that the earlier form, which permits two-digit years, has
+            been deprecated.  SMTP systems MUST use four-digit years.
+   
+   Time = HH ":" MM ":" SS  FWS  Zone
+   
+   DD = 1*2Digit           ; the one or two digit integer day of the
+                             month in the range 1 to 31.
+   
+   Mon = "JAN" | "FEB" | "MAR" | "APR" | "MAY" | "JUN" |
+                "JUL" | "AUG" | "SEP" | "OCT" | "NOV" | "DEC"
+   
+   YYYY = 4*4Digit         ; the four decimal integer year in the range
+                             0000 to 9999. 
+   
+   HH = 2*2Digit           ; the two decimal digit hour of the day in
+                             the range 00 to 24.
+   
+   MM = 2*2Digit            ; the two decimal digit integer minute of the hour
+                              in the range 00 to 59.
+   
+   SS = 2*2Digit [ "." 1*Digit ]
+                            ; the two decimal digit integer second of the
+                              minute in the range 00 to 59, with
+                              optional fractional seconds.
+   
+   Zone = ( "+" / "-" ) 4*4Digit [ <SP> "(" String ")" ]
+                            ; A four digit, signed time zone offset,
+                              such as -0500 for US Eastern Standard
+                              Time.  This may be supplemented by a time
+                              zone name in parentheses, e.g., "-0800
+                              (PDT)". Note that there is no default;
+                              time zone information is required and
+                              MUST be supplied.
+                               
+4.5 Additional Implementation Issues
+
+4.5.1 Minimum Implementation
+
+In order to make SMTP workable, the following minimum implementation is
+required for all receivers. The following commands MUST be supported to
+conform to this specification:
+   EHLO
+   HELO
+   MAIL
+   RCPT
+   DATA
+   RSET
+   NOOP
+   QUIT
+
+VRFY, required by RFC 1123 [RFC-1123], is no longer required by this
+specification.   However, since it was required earlier, servers are
+strongly encouraged to at least recognize the syntax and provide pro-forma
+support.
+
+Any system that includes an SMTP server supporting mail relaying or
+delivery MUST support the reserved mailbox "postmaster" as a
+case-insensitive local name. This postmaster address is not strictly
+necessary if the server always returns 554 on connection opening (as
+described in section 3.1).  The requirement to accept mail for postmaster
+implies that RCPT TO commands which specify a mailbox for postmaster at any
+of the domains for which the SMTP server provides mail service, as well as
+the special case of "RCPT TO:<Postmaster>" (with no domain specification),
+MUST be supported.  This requirement does not imply that SMTP systems must
+deliver Postmaster mail in particular cases (e.g., problematic origin
+addresses) in which they have substantive reasons for not doing so.
+
+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:
+
+ - Before sending a line of mail text, the SMTP client checks the first
+   character of the line.  If it is a period, one additional period is
+   inserted at the beginning of the line.
+
+ - When a line of mail text is received by the SMTP server, it checks the
+   line.  If the line is composed of a single period, it is treated as the
+   end of mail indicator.  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 spaces, vertical
+and horizontal tabs, 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.  See 3.7 for special treatment of these conditions in SMTP
+systems serving a relay function.
+
+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 store data in records rather
+than strings.  If such transformations are necessary, they MUST be
+reversible, especially if such transformations are applied to mail being
+relayed.
+
+4.5.3 Sizes and Timeouts
+
+There are several objects that have required minimum/maximum sizes. Every
+implementation MUST be able to receive objects of at least these sizes.
+Objects larger than these sizes SHOULD be avoided when possible.  However,
+some Internet mail constructs such as encoded X.400 addresses [RFC-X400]
+will often require larger objects: clients MAY attempt to transmit these,
+but MUST be prepared for a server to reject them if they cannot be handled
+by it.  To the maximum extent possible, implementation techniques which
+impose no limits on the length of these objects should be used.
+
+local-part
+   The maximum total length of a user name or other local-part is 64
+   characters.
+
+domain
+   The maximum total length of a domain name or number is 255 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.  SMTP extensions may be used to
+   increase this limit.
+
+reply line
+   The maximum total length of a reply line including the reply code and
+   the <CRLF> is 512 characters.  More information may be conveyed through
+   multiple-line replies.
+
+text line
+   The maximum total length of a text line including the <CRLF> is 1000
+   characters (not counting the leading dot duplicated for transparency).
+   This number may be increased by the use of SMTP Service Extensions.
+
+message content
+   The maximum total length of a message content (including any message
+   headers as well as the message body) MUST BE at least 64K octets. Since
+   the introduction of multimedia mail [RFC-MIME], message lengths on the
+   Internet have grown dramatically, and message size restrictions should
+   be avoided if at all possible. SMTP server systems that must impose
+   restrictions SHOULD implement the "SIZE" service extension ([RFC-SIZE]),
+   and SMTP client systems that will send large messages SHOULD utilize it
+   when possible.
+
+recipients buffer
+   The minimum total number of recipients that must be buffered is 100
+   recipients. Rejection of messages (for excessive recipients) with fewer
+   than 100 RCPT TO commands is a violation of this specification.  The
+   general principle that relaying SMTP servers MUST NOT, and delivery SMTP
+   servers SHOULD NOT, perform validation tests on message headers suggests
+   that rejecting a message based on the total number of recipients shown
+   in header fields is to be discouraged.  A server which imposes a limit
+   on the number of recipients MUST behave in an orderly fashion,  such as
+   to reject additional addresses over its limit rather than silently
+   discarding addresses previously accepted.  A client that needs to
+   deliver a message containing over 100 RCPT TO commands SHOULD be
+   prepared to transmit in 100-recipient "chunks" if the server declines to
+   accept more than 100 recipients in a single message.
+
+Errors due to exceeding these limits may be reported by using the reply
+codes. Some examples of reply codes are:
+
+   500 Line too long.
+or
+   501 Path too long
+or
+   452 Too many recipients  (see below)
+or
+   552 Too much mail data.
+
+[RFC-821] incorrectly listed the error where an SMTP server exhausts its
+implementation limit on the number of RCPT TO commands ("too many
+recipients") as having reply code 552.  The correct reply code for this
+condition is 452. Clients SHOULD treat a 552 code in this case as a
+temporary, rather than permanent failure so the logic below works.
+
+When a conforming SMTP server encounters this condition, it has at least
+100 successful RCPT commands in its recipients buffer.  If the server is
+able to accept the message, then at least these 100 addresses will be
+removed from the SMTP client's queue.  When the client attempts
+retransmission of those addresses which received 452 responses, at least
+100 of these will be able to fit in the SMTP server's recipients buffer.
+Each retransmission attempt which is able to deliver anything will be able
+to dispose of at least 100 of these recipients.
+
+If an SMTP server has an implementation limit on the number of RCPT TO
+commands and this limit is exhausted, it MUST use a response code of 452.
+If the server has a configured site-policy limitation on the number of RCPT
+TO commands, it MAY instead use a 5XX response code.
+
+In order to interoperate with SMTP servers implementing an older version of
+the protocol, SMTP clients MAY treat a 552 code obtained in response to an
+RCPT command as if it were a 452 response code, especially after some RCPT
+commands have already been accepted in the same mail transaction.
+
+An SMTP client MUST provide a timeout mechanism.  It MUST use per-command
+timeouts rather than somehow trying to time the entire mail transaction.
+Timeouts SHOULD be easily reconfigurable, preferably without recompiling
+the SMTP code.  To implement this, 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:
+
+Initial 220 Message: 5 minutes
+   An SMTP client process needs to distinguish between a failed TCP
+   connection and a delay in receiving the initial 220 greeting message.
+   Many SMTP servers accept a TCP connection but delay delivery of the 220
+   message until their system load permits more mail to be processed.
+
+MAIL Command: 5 minutes
+
+RCPT Command: 5 minutes
+   A longer timeout is required if processing of mailing lists and aliases
+   is not deferred until after the message was accepted.
+
+DATA Initiation: 2 minutes
+   This is while awaiting the "354 Start Input" reply to a DATA command.
+
+Data Block: 3 minutes
+   This is while awaiting the completion of each TCP SEND call transmitting
+   a chunk of data.
+
+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 and would typically result in
+   delivery of multiple copies of the message, since it has been
+   successfully sent and the server has accepted responsibility for
+   delivery.  See section 6.1 for additional discussion.
+
+An SMTP server SHOULD have a timeout of at least 5 minutes while it is
+awaiting the next command from the sender.
+
+4.5.4 Queuing Strategies
+
+The common structure of a host SMTP implementation includes user mailboxes,
+one or more areas for queuing 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 queuing strategy MUST include timeouts on all activities on a
+per-command basis. A queuing strategy MUST NOT send error messages in
+response to error messages under any circumstances.
+
+4.5.4.1 Sending Strategy
+
+The general model for an SMTP client 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 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 SMTP client 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 client SHOULD keep a list of hosts it cannot reach and corresponding
+connection timeouts, rather than just retrying queued mail items.
+
+Experience suggests that failures are typically transient (the target
+system or its connection has crashed), favoring a policy of two connection
+attempts in the first hour the message is in the queue, and then backing
+off to one every two or three hours.
+
+The SMTP client can shorten the queuing delay in cooperation with the SMTP
+server.  For example, if mail is received from a particular address, it is
+likely that mail queued for that host can now be sent. Application of this
+principle may, in many cases, eliminate the requirement for an explicit
+"send queues now" function such as that discussed in [RFC-ETRN].
+
+The strategy may be further modified as a result of multiple addresses per
+host (see below) to optimize delivery time vs. resource usage.
+
+An SMTP client may have a large queue of messages for each unavailable
+destination host.  If all of these messages were retried in every retry
+cycle, there would be excessive Internet overhead and the sending system
+would be blocked for a long period.  Note that an SMTP client can generally
+determine that a delivery attempt has failed only after a timeout of
+several minutes and even a one-minute timeout per connection will result in
+a very large delay if retries are repeated for dozens, or even hundreds, of
+queued messages to the same host.
+
+At the same time, SMTP clients SHOULD use great care in caching negative
+responses from servers.  In an extreme case, if EHLO is issued multiple
+times during the same SMTP connection, different answers may be returned by
+the server. More significantly, 5yz responses to MAIL FROM MUST NOT be
+cached.
+
+When a mail message is to be delivered to multiple recipients, and the SMTP
+server to which a copy of the message is to be sent is the same for
+multiple recipients, then only one copy of the message SHOULD be
+transmitted.  That is, the SMTP client SHOULD use the command sequence:
+MAIL, RCPT, RCPT,... RCPT, DATA instead of the sequence: MAIL, RCPT, DATA,
+..., MAIL, RCPT, DATA.  However, if there are very many addresses, a limit
+on the number of RCPT commands per MAIL command MAY be imposed.
+Implementation of this efficiency feature is strongly encouraged.
+
+Similarly, to achieve timely delivery, the SMTP client MAY support multiple
+concurrent outgoing mail transactions.  However, some limit may be
+appropriate to protect the host from devoting all its resources to mail.
+
+4.5.4.2 Receiving Strategy
+
+The SMTP server SHOULD attempt to keep a pending listen on the SMTP port at
+all times.  This requires the support of multiple incoming TCP connections
+for SMTP.  Some limit MAY be imposed.
+
+As discussed above, when the SMTP server receives mail from a particular
+host address, it could notify the SMTP client to retry any mail pending for
+that host address.
+
+4.5.5   Messages with a null reverse-path
+
+There are several types of notification messages which are required by
+existing and proposed standards to be sent with a null reverse path,
+namely non-delivery notifications as discussed in section 3.7, other kinds
+of Delivery Status Notifications (DSNs, see [RFC 1894]) and also Message
+Disposition Notifications (MDNs, see [RFC 2298]). All of these kinds of
+messages are notifications about a previous message, and they are sent to
+the reverse-path of the previous mail message. (If the delivery of such a
+notification message fails, that usually indicates a problem with the mail
+system of the host to which the notification message is addressed. For
+this reason, at some hosts the MTA is set up to forward such failed
+notification messages to someone who is able to fix problems with the mail
+system, e.g. via the postmaster alias.)
+
+All other types of messages (i.e. any message which is not required by a
+standards-track RFC to have a null reverse-path) SHOULD be sent with with
+a valid, non-null reverse-path.
+
+Implementors of automated email processors should be careful to make sure
+that the various kinds of messages with null reverse-path are handled
+correctly, in particular such systems SHOULD NOT reply to messages with
+null reverse-path. 
+
+
+
+
+5. Address Resolution and Mail Handling
+
+Once an SMTP client lexically identifies a domain to which mail will be
+delivered for processing (as described in sections 3.6 and 3.7), a DNS
+lookup is performed to resolve the domain name (see [RFC-DNS]).  The names
+are expected to be fully-qualified domain names (FQDNs): mechanisms for
+inferring FQDNs from partial names or local aliases are outside of this
+specification and, due to a history of problems, are generally discouraged.
+The lookup first attempts to locate an MX record associated with the name.
+If a CNAME record is found instead, the resulting name is processed as if
+it were the initial name.  If no MX records are found, but an A RR is
+found, the A RR is treated as if it was associated with an implicit MX RR,
+with a preference of 0, pointing to that host.  If one or more MX RRs are
+found for a given name, SMTP systems MUST NOT utilize any A RRs associated
+with that name unless they are located using the MX RRs; the "implicit MX"
+rule above applies only if there are no MX records present.  If MX records
+are present, but none of them are usable, this situation MUST be reported
+as an error.
+
+When the lookup succeeds, the mapping can result in a list of alternative
+delivery addresses rather than a single address, because of multiple MX
+records, multihoming, or both.  To provide reliable mail transmission, the
+SMTP client MUST be able to try (and retry) each of the relevant 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.
+
+Two types of information is used to rank the host addresses: multiple MX
+records, and multihomed hosts.
+
+Multiple MX records contain a preference indication that MUST be used in
+sorting (see below).  Lower numbers are more preferred than higher ones.
+If there are multiple destinations with the same preference and there is no
+clear reason to favor one (e.g., by recognition of an easily-reached
+address), then the sender-SMTP MUST randomize them to spread the load
+across multiple mail exchangers for a specific organization.
+
+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 to have ordered this list by decreasing preference if
+necessary, and SMTP MUST try them in the order presented.
+
+Although the capability to try multiple alternative addresses is required,
+specific installations may 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
+sending strategy discussed in section 4.5.4.1.
+
+If a host receives a message with a destination for which it is a
+designated Mail eXchanger, it MAY relay the message (potentially after
+having rewritten the addresses), make final delivery of the message, or
+hand it off using some mechanism outside the SMTP-provided transport
+environment.
+
+If it determines that it should relay the message without rewriting the
+address, it MUST sort the MX records to determine candidates for delivery.
+The records are first ordered by preference, with the lowest-numbered
+records being most preferred.  The relay host MUST then inspect the list
+for any of the names or addresses by which it might be known in mail
+transactions.  If a matching record is found, all records at that
+preference level and higher-numbered ones MUST be discarded from
+consideration.  If there are no records left at that point, it is an error
+condition, and the message MUST be returned as undeliverable.  If records
+do remain, they SHOULD be tried, best preference first, as described above.
+
+
+6. Problem Detection and Handling
+
+6.1 Reliable Delivery and Replies by Email
+
+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. It
+MUST NOT lose the message for frivolous reasons, such as 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.
+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.  Obviously, nothing
+in this section can or should prohibit local decisions (i.e., as part of
+the same system environment as the receiver-SMTP) to log or otherwise
+transmit information about null address events locally if that is desired.
+If the address is an explicit source route, it MUST be stripped down to its
+final hop.
+
+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 using: 
+   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 receiving SMTP
+server to validate all the delivery addresses in RCPT command(s) due to a
+"soft" domain system error, because the target is a mailing list (see
+earlier discussion of RCPT), or because the server is acting as a relay and
+has no immediate access to the delivering system.
+
+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 <CRLF>.<CRLF> end of data indicator.  See RFC-1047 [RFC-1047] for a
+discussion of this problem.
+
+6.2 Loop Detection
+
+Simple counting of the number of "Received:" headers in a message has
+proven to be an effective, although rarely optimal, method of detecting
+loops in mail systems.  SMTP servers using this technique SHOULD use a
+large rejection threshold, normally at least 100 Received entries.
+Whatever mechanisms are used, servers MUST contain provisions for detecting
+and stopping trivial loops.
+
+6.3 Compensating for Irregularities
+
+Unfortunately, variations, creative interpretations, and outright
+violations of Internet mail protocols do occur; some would suggest that
+they occur quite frequently.  The debate as to whether a well-behaved SMTP
+receiver or relay should reject a malformed message, attempt to pass it on
+unchanged, or attempt to repair it to increase the odds of successful
+delivery (or subsequent reply) began almost with the dawn of structured
+network mail and shows no signs of abating.  Advocates of rejection claim
+that attempted repairs are rarely completely adequate and that rejection of
+bad messages is the only way to get the offending software repaired.
+Advocates of "repair" or "deliver no matter what" argue that users prefer
+that mail go through it if at all possible and that there are significant
+market pressures in that direction.  In practice, these market pressures
+may be more important to particular vendors than strict conformance to the
+standards, regardless of the preference of the actual developers.
+
+The problems associated with ill-formed messages were exacerbated by the
+introduction of the split-UA mail reading protocols [RFC-POP2, RFC-POP3,
+RFC-IMAP2, RFC-PCMAIL]. These protocols have encouraged the use of SMTP as
+a posting protocol, and SMTP servers as relay systems for these client
+hosts (which are often only intermittently connected to the Internet).
+Historically, many of those client machines lacked some of the mechanisms
+and information assumed by SMTP (and indeed, by the mail format protocol
+[RFC-822]).  Some could not keep adequate track of time; others had no
+concept of time zones; still others could not identify their own names or
+addresses; and, of course, none could satisfy the assumptions that underlay
+RFC-822's conception of authenticated addresses.
+
+In response to these weak SMTP clients, many SMTP systems now complete
+messages that are delivered to them in incomplete or incorrect form.  This
+strategy is generally considered appropriate when the server can identify
+or authenticate the client, and there are prior agreements between them.
+By contrast, there is at best great concern about fixes applied by a relay
+or delivery SMTP server that has little or no knowledge of the user or
+client machine.
+
+The following changes to a message being processed MAY be applied when
+necessary by an originating SMTP server, or one used as the target of SMTP
+as an initial posting protocol:
+
+ - Addition of a message-id field when none appears
+
+ - Addition of a date, time or time zone when none appears
+
+ - Correction of addresses to proper FQDN format
+
+The less information the server has about the client, the less likely these
+changes are to be correct and the more caution and conservatism should be
+applied when considering whether or not to perform fixes and how.  These
+changes MUST NOT be applied by an SMTP server that provides an intermediate
+relay function.
+
+In all cases, properly-operating clients supplying correct information are
+preferred to corrections by the SMTP server. In all cases, documentation of
+actions performed by the servers (in trace fields and/or header comments)
+is strongly encouraged.
+
+
+7. Security Considerations
+
+7.1 Mail Security and Spoofing
+
+SMTP mail is inherently insecure in that it is feasible for even fairly
+casual users to negotiate directly with receiving and relaying SMTP servers
+
+
+and create messages that will trick a naive recipient into believing that
+they came from somewhere else.  Constructing such a message so that the
+"spoofed" behavior cannot be detected by an expert is somewhat more
+difficult, but not sufficiently so as to be a deterrent to someone who is
+determined and knowledgeable. Consequently, as knowledge of Internet mail
+increases, so does the knowledge that SMTP mail inherently cannot be
+authenticated, or integrity checks provided, at the transport level. Real
+mail security lies only in end-to-end methods involving the message bodies,
+such as those that can be provided in the MOSS framework [RFC-MOSS].
+
+Various protocol extensions and configuration options that provide
+authentication at the transport level (e.g., from an SMTP client to an SMTP
+server) improve somewhat on the traditional situation described above.
+However, unless they are accompanied by careful handoffs of responsibility
+in a carefully-designed trust environment, they remain inherently weaker
+than end-to-end mechanisms which use digitally signed messages rather than
+depending on the integrity of the transport system.
+
+Efforts to make it more difficult for users to set envelope MAIL FROM and
+header "From" fields to point to valid addresses other than their own are
+largely misguided: they frustrate legitimate applications in which mail is
+sent by one user on behalf of another or in which error (or normal) replies
+should be directed to a special address. (Systems that provide convenient
+ways for users to alter these fields on a per-message basis should attempt
+to establish a primary and permanent mailbox address for the user so that
+Sender fields within the message data can be generated sensibly.)
+
+This specification does not further address the authentication issues
+associated with SMTP other than to advocate that useful functionality not
+be disabled in the hope of providing some small margin of protection
+against an ignorant user who is trying to fake mail.
+
+7.2 "Blind" Copies
+
+Addresses that do not appear in the message headers may appear in the RCPT
+TO commands to an SMTP server for a number of reasons.  The two most common
+involve the use of a mailing address as a "list exploder" (a single address
+that resolves into multiple addresses) and the appearance of "blind
+copies".  Especially when more than one RCPT command is present, and in
+order to avoid defeating some of the purpose of these mechanisms, SMTP
+clients and servers SHOULD NOT copy the full set of RCPT TO command
+arguments into the headers, either as part of trace headers or as
+informational or private-extension headers.  Since this rule is often
+violated in practice, and cannot be enforced, sending SMTP systems that are
+aware of "bcc" use MAY find it helpful to send each blind copy as a
+separate message transaction containing only a single RCPT TO command.
+
+There is no inherent relationship between either "reverse" (MAIL FROM, SAML
+FROM, etc.) or "forward" (RCPT TO) addresses in the SMTP transaction
+("envelope") and the addresses in the headers.  Receiving systems SHOULD
+NOT attempt to deduce such relationships and use them to alter the headers
+of the message for delivery.  The popular "Apparently-to" header is a
+violation of this principle and SHOULD NOT be used.
+
+7.3 VRFY, EXPN, and Security
+
+As discussed in section 3.5, individual sites may want to disable one or
+both VRFY or EXPN for security reasons.  As a corollary to the above,
+implementations that permit this MUST NOT appear to have verified addresses
+that are not, in fact, verified.  If a site disables these commands for
+security reasons, the SMTP server MUST return a 252 response, rather than a
+code that could be confused with successful or unsuccessful verification.
+
+Returning a 250 reply code with the address listed in the VRFY command
+after having checked it only for syntax violates this rule. Of course, an
+implementation that "supports" VRFY by always returning 550 whether or not
+the address is valid is equally not in conformance.
+
+Within the last few years, the contents of mailing lists have become
+popular as an address information source for so-called "spammers." The use
+of EXPN to "harvest" addresses has increased as list administrators have
+installed protections against inappropriate uses of the lists themselves.
+Implementations SHOULD still provide support for EXPN, but sites SHOULD
+carefully evaluate the tradeoffs. As authentication mechanisms are
+introduced into SMTP, some sites may choose to make EXPN available only to
+authenticated requestors.
+
+7.4 Information Disclosure in Announcements
+
+There has been an ongoing debate about the tradeoffs between the debugging
+advantages of announcing server type and version (and, sometimes, even
+server domain name) in the greeting response or in response to the HELP
+command and the disadvantages of exposing useful information to potential
+hostile attack.  The utility of the debugging information is beyond doubt.
+Those who argue for making it available point out that it is far better to
+actually secure an SMTP server rather than hope that trying to conceal
+known vulnerabilities by hiding the server's precise identity will provide
+more protection. Sites are encouraged to evaluate the tradeoff with that
+issue in mind; implementations are strongly encouraged to minimally provide
+for making type and version information available in some way to other
+network hosts.
+
+7.5 Information Disclosure in Trace Fields
+
+In some circumstances, such as when mail originates from within a LAN whose
+hosts are not directly from the public Internet, trace ("Received") fields
+produced in conformance with this specification may disclose host names and
+similar information that would not normally be available.  This ordinarily
+does not pose a problem, but sites with special concerns about name
+disclosure should be aware of it.  Also, the optional FOR clause should be
+supplied with caution or not at all when multiple recipients are involved
+lest it inadvertently disclose the identities of "blind copy" recipients to
+others.
+
+7.6 Scope of Operation of SMTP Servers
+
+It is a well-established principle that an SMTP server may refuse to accept
+mail for any operational or technical reason that makes sense to the site
+providing the server. However, cooperation among sites and installations
+makes the Internet possible.  If sites take excessive advantage of the
+right to reject traffic, the ubiquity of email availability (one of the
+strengths of the Internet) will be threatened; considerable care should be
+taken and balance maintained if a site decides to be selective about the
+traffic it will accept and process.
+
+In recent years, use of the relay function through arbitrary sites has been
+used as part of hostile efforts to hide the actual origins of mail.  Some
+sites have decided to limit the use of the relay function to known or
+identifiable sources, and implementations SHOULD provide the capability to
+perform this type of filtering.  When mail is rejected for these or other
+policy reasons, a 550 code SHOULD be used in response to EHLO, MAIL FROM,
+or RCPT TO as appropriate.
+
+
+8. IANA Considerations
+
+IANA will maintain three registries in support of this specification.  The
+first consists of SMTP service extensions with the associated keywords,
+and, as needed, parameters and verbs.  As specified in section 2.2.2, no
+entry may be made in this registry that starts in an "X".  Entries may be
+made only for service extensions (and associated keywords, parameters, or
+verbs) that are defined in standards-track or experimental RFCs
+specifically approved by the IESG for this purpose.
+
+The second registry consists of "tags" that identify forms of domain
+literals other than those for IPv4 addresses (specified in RFC 821 and in
+this document) and IPv6 addresses (specified in this document).  Additional
+literal types require standardization before being used; none are
+anticipated at this time.
+
+The third, established by RFC 821 and renewed by this specification, is a
+registry of link and protocol identifiers to be used with the "via" and
+"with" subclauses of the time stamp ("Received: header") described in
+section 4.4.  Link and protocol identifiers in addition to those specified
+in this document may be registered only by standardization or by way of an
+RFC-documented, IESG-approved, Experimental protocol extension.
+
+
+9. References
+
+[8BITMIME] J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker, "SMTP
+Service Extension for 8bit-MIMEtransport", RFC 1652, 07/18/1994.
+
+[ABNF] Crocker, D., P. Overell, Eds., "Augmented BNF for Syntax
+Specifications: ABNF", RFC 2234, November 1997.
+
+[IPv6AddrString] Hinden, R and S. Deering, Eds. "IP Version 6 Addressing
+Architecture", RFC 1884, December 1995.
+
+[MSGFMT] P. Resnick, Work in progress, draft-ietf-drums-msg-fmt-05.txt,
+August, 1998
+
+[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text
+Messages", RFC 822, Department of Electrical Engineering, University of
+Delaware, August 1982.
+
+[RFC-974] C. Partridge, "Mail routing and the domain system", RFC 974,
+01/01/1986
+
+[RFC-1047] C. Partridge, "Duplicate messages and SMTP", RFC 1047,
+02/01/1988.
+
+[RFC-1123] R. Braden, "Requirements for Internet hosts - application and
+support", 10/01/1989
+
+[RFC-BDAT] G. Vaudreuil, "SMTP Service Extensions for Transmission of Large
+and Binary MIME Messages", RFC 1830, 08/16/1995.
+
+[RFC-DNS] P. Mockapetris, "Domain names - implementation and
+specification", RFC 1035 and P. Mockapetris, "Domain names - concepts and
+facilities", RFC 1034. (STD 13)
+
+[RFC-ETRN] J. De Winter, "SMTP Service Extension for Remote Message Queue
+Starting", RFC 1985, 08/14/1996.
+
+[RFC-IMAP2] M. Crispin, "Interactive Mail Access Protocol - Version 2", RFC
+1176, 08/20/1990.
+
+[RFC-IMAP4] M. Crispin, "Internet Message Access Protocol - Version 4", RFC
+2060, 12/04/1996.
+
+[RFC-INTLHDR] K. Moore, "MIME (Multipurpose Internet Mail Extensions) Part
+Three: Message Header Extensions for Non-ASCII Text", RFC 2047, 12/02/1996.
+
+[RFC-MIME] N. Freed, N. Borenstein, "Multipurpose Internet Mail Extensions
+(MIME) Part One: Format of Internet Message Bodies", RFC 2045, 12/02/1996.
+
+[RFC-MOSS] S. Crocker, N. Freed, J. Galvin, S. Murphy, "MIME Object
+Security Services", RFC 1848, 10/03/1995.
+
+[RFC-NOTARY1] K. Moore, "SMTP Service Extension for Delivery Status
+Notifications", RFC 1891, 01/15/1996.
+
+[RFC-NOTARY2] K. Moore, G. Vaudreuil, "An Extensible Message Format for
+Delivery Status Notifications", RFC 1894, 01/15/1996.
+
+[RFC-PCMAIL] M. Lambert, "PCMAIL: A distributed mail system for personal
+computers", RFC 1056, 06/01/1988.
+
+[RFC-PIPELINE] N. Freed, A. Cargille, "SMTP Service Extension for Command
+Pipelining", RFC 1854, 10/04/1995.
+
+[RFC-POP2] M. Butler, D. Chase, J. Goldberger, J. Postel, J. Reynolds,
+"Post Office Protocol - version 2", RFC 937, 02/01/1985
+
+[RFC-POP3] J. Myers, M. Rose, "Post Office Protocol - Version 3", RFC 1930,
+5/14/96 (Std 53).
+
+[RFC-REPLY] G. Vaudreuil, "Enhanced Mail System Status Codes", RFC 1893,
+01/15/1996.
+
+[RFC-SIZE] J. Klensin, N. Freed, K. Moore, "SMTP Service Extension for
+Message Size Declaration", RFC 1870, 11/06/1995. (STD 10)
+
+[RFC-X400] S. Hardcastle-Kille, "Mapping between X.400(1988) / ISO 10021
+and RFC 822", RFC 1327, 05/18/1992.
+
+[SMTPEX] J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker, "SMTP
+Service Extensions", RFC-1869, 11/06/1995. (STD 10)
+
+[TCP] Postel, J., ed., "Transmission Control Protocol - DARPA Internet
+Program Protocol Specification", RFC 793, USC/Information Sciences
+Institute, NTIS AD Number A111091, September 1981.
+
+[US-ASCII] United States of America Standards Institute (now American
+National Standards Institute), X3.4, 1968, "USA Code for Information
+Interchange". ANSI X3.4-1968 has been replaced by newer versions with
+slight modifications, but the 1968 version remains definitive for the
+Internet.
+
+
+10. Editor's Address
+
+John C. Klensin
+MCI Communications
+800 Boylston St., 7th floor
+Boston, MA 02199
+USA
+Email: Klensin@mci.net
+Phone: +1 617 960 1011
+Fax:   +1 617 960 1009
+
+
+11. Acknowledgments
+
+Many people worked long and hard on the many iterations of this document.
+There was wide-ranging debate on the mailing list about many technical
+issues, and many contributors helped form the wording in this
+specification. The hundreds of participants in the many discussions since
+RFC 821 was produced are too numerous to mention, but they all helped this
+document become what it is.
+
+
+A. TCP Transport Service
+
+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.  Service extensions may modify
+this rule to permit transmission of full 8-bit data bytes as part of the
+message body, but not in SMTP commands or responses.
+
+
+B. Generating SMTP Commands from RFC 822 Headers
+ 
+Some systems use RFC 822 headers (only) in a mail submission protocol, or
+otherwise generate SMTP commands from RFC 822 headers when such a message
+is handed to an MTA from a UA.  While the MTA-UA protocol is a private
+matter, not covered by any Internet Standard, there are problems with this
+approach.  For example, there have been repeated problems with proper
+handling of "bcc" copies and redistribution lists when information that
+conceptually belongs to a mail envelopes is not separated early in
+processing from header information (and kept separate).
+
+It is recommended that the UA provide its initial MTA with an envelope
+separate from the message itself.  However, if the envelope is not
+supplied, SMTP commands SHOULD be generated as follows:
+
+1. Each recipient address from a TO, CC, or BCC header field SHOULD be
+   copied to a RCPT command (generating multiple message copies if that is
+   required for queuing or delivery).  This includes any addresses listed
+   in a RFC 822 "group".  Any BCC fields SHOULD then be removed from the
+   headers.  Once this process is completed, the remaining headers SHOULD
+   be checked to verify that at least one To:, Cc:, or Bcc: header remains.
+   If none do, then a bcc: header with no additional information SHOULD be
+   inserted as specified in [MSGFMT].
+
+2. The return address in the MAIL command SHOULD, if possible, be derived
+   from the system's identity for the submitting (local) user, and the From
+   header field otherwise.  If there is a system identity available, it
+   SHOULD also be copied to the Sender header field if it is different from
+   the address in the From header field.  (Any Sender field that was
+   already there SHOULD be removed.)  Systems may provide a way for
+   submitters to override the envelope return address, but may want to
+   restrict its use to privileged users.  This will not prevent mail
+   forgery, but may lessen its incidence; see section 7.1.
+
+When an MTA is being used in this way, it bears responsibility for ensuring
+that the message being transmitted is valid.  The mechanisms for checking
+that validity, and for handling (or returning) messages that are not valid
+at the time of arrival, are part of the MUA-MTA interface and not covered
+by this specification.
+
+A submission protocol based on Standard RFC 822 information alone MUST NOT
+be used to gateway a message from a foreign (non-SMTP) mail system into an
+SMTP environment.  Additional information to construct an envelope must
+come from some source in the other environment, whether supplemental
+headers or the foreign system's envelope.
+
+Attempts to gateway messages using only their header "to" and "cc" fields,
+have repeatedly caused mail loops and other behavior adverse to the proper
+functioning of the Internet mail environment.  These problems have been
+especially common when the message originates from an Internet mailing list
+and is distributed into the foreign environment using envelope information.
+When these messages are then processed by a header-only remailer, loops
+back to the Internet environment (and the mailing list) are almost
+inevitable.
+
+
+C. Source Routes
+
+The <reverse-path> is a reverse source routing list of hosts and a source
+mailbox.  The first host in the <reverse-path> SHOULD be the host sending
+the MAIL FROM command.  Similarly, the <forward-path> may be a source
+routing lists of hosts and a destination mailbox. However, in general, the
+<forward-path> SHOULD contain only a mailbox and domain name, relying on
+the domain name system to supply routing information if required.  The use
+of source routes is deprecated; while servers MUST be prepared to receive
+and handle them as discussed in section 3.3 and F.2, clients SHOULD NOT
+transmit them.
+
+For relay purposes, the forward-path may be a source route of the form
+"@ONE,@TWO:JOE@THREE", where ONE, TWO, and THREE MUST BE fully-qualified
+domain names.  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.
+
+If source routes are used, RFC 821 and the text below should be consulted
+for the mechanisms for constructing and updating the forward- and
+reverse-paths.
+
+The SMTP server transforms the command arguments by moving its own
+identifier (its domain name or that of any domain for which it is acting as
+a mail exchanger), if it appears, from the forward-path to the beginning of
+the reverse-path.
+
+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. Conversely, SMTP servers
+MUST NOT derive final message delivery information from message header
+fields.
+
+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 transport environment to which it is relaying the mail rather
+than that of the transport environment from which the mail came (if they
+are different).
+
+
+D. Scenarios
+
+This section presents complete scenarios of several types of SMTP sessions.
+In the examples, "C:" indicates what is said by the SMTP client, and "S:"
+indicates what is said by the SMTP server.
+
+D.1 A Typical SMTP Transaction Scenario
+
+This SMTP example shows mail sent by Smith at host bar.com, to Jones,
+Green, and Brown at host foo.com.  Here we assume that host bar.com
+contacts host foo.com directly.  The mail is accepted for Jones and Brown.
+Green does not have a mailbox at host foo.com.
+
+   S: 220 foo.com Simple Mail Transfer Service Ready
+   C: EHLO bar.com
+   S: 250-foo.com greets bar.com
+   S: 250-8BITMIME
+   S: 250-SIZE
+   S: 250-DSN
+   S: 250 HELP
+   C: MAIL FROM:<Smith@bar.com>
+   S: 250 OK
+   C: RCPT TO:<Jones@foo.com>
+   S: 250 OK
+   C: RCPT TO:<Green@foo.com>
+   S: 550 No such user here
+   C: RCPT TO:<Brown@foo.com>
+   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
+   C: QUIT
+   S: 221 foo.com Service closing transmission channel
+
+D.2 Aborted SMTP Transaction Scenario
+
+   S: 220 foo.com Simple Mail Transfer Service Ready
+   C: EHLO bar.com
+   S: 250-foo.com greets bar.com
+   S: 250-8BITMIME
+   S: 250-SIZE
+   S: 250-DSN
+   S: 250 HELP
+   C: MAIL FROM:<Smith@bar.com>
+   S: 250 OK
+   C: RCPT TO:<Jones@foo.com>
+   S: 250 OK
+   C: RCPT TO:<Green@foo.com>
+   S: 550 No such user here
+   C: RSET
+   S: 250 OK
+   C: QUIT
+   S: 221 foo.com Service closing transmission channel
+
+D.3 Relayed Mail Scenario
+
+Step 1  --  Source Host to Relay Host
+
+   S: 220 foo.com Simple Mail Transfer Service Ready
+   C: EHLO bar.com
+   S: 250-foo.com greets bar.com
+   S: 250-8BITMIME
+   S: 250-SIZE
+   S: 250-DSN
+   S: 250 HELP
+   C: MAIL FROM:<JQP@bar.com>
+   S: 250 OK
+   C: RCPT TO:<@foo.com:Jones@XYZ.COM>
+   S: 250 OK
+   C: DATA
+   S: 354 Start mail input; end with <CRLF>.<CRLF>
+   C: Date: Thu, 21 May 1998 05:33:29 -0700
+   C: From: John Q. Public <JQP@bar.com>
+   C: Subject:  The Next Meeting of the Board
+   C: To: Jones@xyz.com
+   C:
+   C: Bill:
+   C: The next meeting of the board of directors will be
+   C: on Tuesday.
+   C:                         John.
+   C: .
+   S: 250 OK
+   C: QUIT
+   S: 221 foo.com Service closing transmission channel
+
+Step 2  --  Relay Host to Destination Host
+
+   S: 220 xyz.com Simple Mail Transfer Service Ready
+   C: EHLO foo.com
+   S: 250 xyz.com is on the air
+   C: MAIL FROM:<@foo.com:JQP@bar.com>
+   S: 250 OK
+   C: RCPT TO:<Jones@XYZ.COM>
+   S: 250 OK
+   C: DATA
+   S: 354 Start mail input; end with <CRLF>.<CRLF>
+   C: Received: from bar.com by foo.com ; Thu, 21 May 1998 05:33:29 -0700
+   C: Date: Thu, 21 May 1998 05:33:22 -0700
+   C: From: John Q. Public <JQP@bar.com>
+   C: Subject:  The Next Meeting of the Board
+   C: To: Jones@xyz.com
+   C:
+   C: Bill:
+   C: The next meeting of the board of directors will be
+   C: on Tuesday.
+   C:                         John.
+   C: .
+   S: 250 OK
+
+   C: QUIT
+   S: 221 foo.com Service closing transmission channel
+
+D.4 Verifying and Sending Scenario
+
+   S: 220 foo.com Simple Mail Transfer Service Ready
+   C: EHLO bar.com
+   S: 250-foo.com greets bar.com
+   S: 250-8BITMIME
+   S: 250-SIZE
+   S: 250-DSN
+   S: 250 HELP
+   C: VRFY Crispin
+   S: 250 Mark Crispin <Admin.MRC@foo.com>
+   C: SEND FROM:<EAK@bar.com>
+   S: 250 OK
+   C: RCPT TO:<Admin.MRC@foo.com>
+   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
+   C: QUIT
+   S: 221 foo.com Service closing transmission channel
+
+
+E. Other Gateway Issues
+
+In general, gateways between the Internet and other mail systems SHOULD
+attempt to preserve any layering semantics across the boundaries between
+the two mail systems involved.  Gateway- translation approaches that
+attempt to take shortcuts by mapping, (such as envelope information from
+one system to the message headers or body of another) have generally proven
+to be inadequate in important ways.  Systems translating between
+environments that do not support both envelopes and headers and Internet
+mail must be written with the understanding that some information loss is
+almost inevitable.
+
+
+F. Deprecated Features of RFC 821
+
+A few features of RFC 821 have proven to be problematic and SHOULD NOT be
+used in Internet mail.
+
+F.1 TURN
+
+This command, described in RFC 821, raises important security issues since,
+in the absence of strong authentication of the host requesting that the
+client and server switch roles, it can easily be used to divert mail from
+its correct destination.  Its use is deprecated; SMTP systems SHOULD NOT
+use it unless the server can authenticate the client.
+
+F.2 Source Routing
+
+RFC 821 utilized the concept of explicit source routing to get mail from
+one host to another via a series of relays.  The requirement to utilize
+source routes in regular mail traffic was eliminated by the introduction of
+the domain name system "MX" record and the last significant justification
+for them was eliminated by the introduction, in RFC 1123, of a clear
+requirement that addresses following an "@" must all be fully-qualified
+domain names. Consequently, the only remaining justifications for the use
+of source routes are support for very old SMTP clients or MUAs and in mail
+system debugging.  They can, however, still be useful in the latter
+circumstance and for routing mail around serious, but temporary, problems
+such as problems with the relevant DNS records.
+
+SMTP servers MUST continue to accept source route syntax as specified in
+the main body of this document and in RFC 1123.  They MAY, if necessary,
+ignore the routes and utilize only the target domain in the address.  If
+they do utilize the source route, the message MUST be sent to the first
+domain shown in the address.  In particular, a server MUST NOT guess at
+shortcuts within the source route.
+
+Clients SHOULD NOT utilize explicit source routing except under unusual
+circumstances, such as debugging or potentially relaying around firewall or
+mail system configuration errors.
+
+F.3 HELO
+
+As discussed in sections 3.1 and 4.1.1, EHLO is strongly preferred to HELO
+when the server will accept the former.  Servers must continue to accept
+and process HELO in order to support older clients.
+
+F.4 #-literals
+
+RFC 821 provided for specifying an Internet address as a decimal integer
+host number prefixed by a pound sign, "#".  In practice, that form has been
+obsolete since the introduction of TCP/IP.  It is deprecated and MUST NOT
+be used.
+
+F.5 Dates and Years
+
+When dates are inserted into messages by SMTP clients or servers (e.g., in
+trace fields), four-digit years MUST BE used.  Two-digit years are
+deprecated; three-digit years were never permitted in the Internet mail
+system.
+
+F.6 Sending versus Mailing
+
+In addition to specifying a mechanism for delivering messages to user's
+mailboxes, RFC 821 provided additional, optional, commands to deliver
+messages directly to the user's terminal screen.  These commands (SEND,
+SAML, SOML) were rarely implemented, and changes in workstation technology
+and the introduction of other protocols may have rendered them obsolete
+even where they are implemented.
+
+Clients SHOULD NOT provide SEND, SAML, or SOML as services.  Servers MAY
+implement them.  If they are implemented by servers, the implementation
+model specified in RFC 821 MUST be used and the command names MUST be
+published in the response to the EHLO command.
+
+
+X. Change Summary and Loose Ends (Temporary)
+
+X.1 Change summary
+
+X.1.1 Substantive changes between draft-ietf-drums-smtpupd-00.txt and
+draft-ietf-drums-smtpupd-01.txt
+
+(i) Slightly clarified the discussions of rejection and failure of VRFY
+requests and the associated response codes.
+
+(ii) Slightly clarified the discussion of deferred address validation.
+
+(iii) Removed the IPCE terminology and modified the text in section 4.1.1.2
+to explicitly introduce the "mail gateway" terminology and to begin to
+distinguish a mail gateway from a conventional relay.
+
+(iv) Explicitly noted that SMTP clients for things like POP and IMAP may
+send everything to a single relay for further processing, rather than
+resolving final domain names.
+
+(v) Tightened the RSET discussion.
+
+(vi) Deprecation of 251 only for RCPT (still ok for VRFY)
+
+X.1.2.  Substantive changes between draft-ietf-drums-smtpupd-01.txt and
+draft-ietf-drums-smtpupd-02.txt.
+
+Incorporated additional RFC 1123 material; reorganized several sections for
+clarity.  Added definitions and other previous "loose end" material.
+
+X.1.3.  Substantive changes between draft-ietf-drums-smtpupd-02.txt and
+draft-ietf-drums-smtpupd-03.txt.
+
+(i) Eliminated a number of placeholders and tightened some of the
+definitions in section 2.  Added a few new placeholders for consistency
+checking against other documents.
+
+(ii) Removed the state diagrams, per direction at IETF Montreal.
+
+(iii) Added new section 6.3, an attempt to summarize WG discussions on the
+"posting" versus "delivery" versus "relay" functions of SMTP and on whether
+"fixups" are appropriate in different cases.
+
+(iv) Inserted section 6.1, a minor rewrite of section 5.3.3 of RFC1123.
+
+(v) Added new text to 3.5.5 to discuss the spammer - EXPN relationship.
+
+(vi) The "ASCII requirement" in 4.1.1.4 has been tightened somewhat.
+
+(v) The remaining miscellaneous changes agreed to in Montreal have been
+incorporated except as noted below.
+
+X.1.4.  Substantive changes between draft-ietf-drums-smtpupd-03.txt and
+draft-ietf-drums-smtpupd-04.txt.
+
+Many small changes have been made between these two versions; the list that
+follows is not exhaustive.
+
+(i) To clarify some of the text, definitions have been introduced to
+distinguish among originating, delivery, relay, and gateway SMTP systems.
+
+(ii) The role of LF-terminated lines has been clarified.
+
+(iii) Several changes have been made to clarify the principle that, no
+matter what originating and final delivery systems might do, relay systems
+are not permitted to tamper with message content, even to "fix" headers
+that are determined to be invalid.  If they deem message content to be
+seriously unacceptable, they are encouraged to reject the messages in
+preference to trying to fix them up, but, in general, the theme is "don't
+look/ don't tell".
+
+(iv) A few more definitions have been added to the terminology section, and
+the separate glossary has been eliminated.
+
+(v) I have taken a shot at text to address some of the controversies that
+have raged on the WG mailing list (e.g., sections 7.4 and 7.5). Since there
+was no consensus on most of those topics, I expect that the inserted text
+will satisfy no one except, perhaps, for agreement that saying nothing
+would have been worse.  As a mechanism for moving forward, the text in
+these controversial areas that now appears will be considered "base";
+alterations will be made only if clear consensus emerges.
+
+(vi) Per discussion in Los Angeles, source routes have been further
+deprecated.
+
+(vii) Some of the VRFY/EXPN materials have been moved to "security
+considerations", where they appear to belong, some text has been added, and
+the conformance statements adjusted to reflect what I perceive to be WG
+consensus.
+
+(viii) New MX resolution material has been added to section 5.  While most
+of this material is from RFC974, the rules have been further tightened to
+reflect current practice and experience (974 is written in a somewhat
+speculative fashion for a standard).  In particular, the behavior of trying
+the target host's A RR when MXs existed but all of them were eliminated is
+now prohibited, which seems necessary if another of other ideas being
+recommended or considered are to be feasible.
+
+X.1.5.  Substantive changes between draft-ietf-drums-smtpupd-04.txt and
+draft-ietf-drums-smtpupd-05.txt.
+
+(i) All normative references to RFC 1123 have been removed from the main
+body of the text (some still appear in the appendices where they will
+remain).
+
+(ii) Section 3.5 has been renamed slightly to distinguish between
+"debugging of SMTP implementations" and "debugging of addresses". Better
+terminology would be welcome.
+
+(iii) Error conditions resulting from the DATA command have been clarified.
+
+(iv) Section 4.2 (SMTP replies) has been revised and tightened to reflect
+reality and recent discussion on the list.
+
+(v) Appendix E has been revised a bit and moved into section 4.2.1. Given
+the importance of the "check only first digit" rule, it has to be there.
+
+(vi) Added new text for "no SMTP service supported" to sections 3.1, 4.2.2,
+4.2.3, and 4.3.2.  As noted in 3.1, I'd rather add 521 (which would work
+perfectly with the model) rather than overloading 554.
+
+(vii) The Return-path language in section 4.4 has been cleaned up a bit.
+
+(viii) Tightened the "postmaster" language in 4.5.1, requiring a small
+change to 4.1.1.3.
+
+(ix) I have unilaterally (with a little help from my friends), increased
+some of the size limits.  64 was much too short for a domain name, and the
+DNS limit of 255 (?) has now been inserted. That leaves the return path
+much too short, but I haven't fixed it (maybe that will cause us to get rid
+of them).  We still have a 64 character limit on the local-part, which is
+also *much* too short. Votes for 128 or longer limits accepted.  See
+X.1.6(I)
+
+(x) The text on the "recipients buffer" has been rewritten so that (I hope)
+it makes sense and gives some explicit guidance for how clients and servers
+should proceed if limits are imposed.
+
+X.1.6.  Substantive changes between draft-ietf-drums-smtpupd-05.txt and
+draft-ietf-drums-smtpupd-06.txt.
+
+Most of the changes in this revision have been editorial rather than
+substantive.  Major substantive changes include:
+
+(i)  The language about maximum sizes of SMTP command lines has been
+reworked, per WG mailing list discussion.
+
+(ii)  Several instances of  "Should" have been promoted to "Must" when the
+reasons for the weaker rule seemed to have disappeared.  In particular, the
+requirement that an SMTP implementation support timeouts has become a MUST.
+Also, conformance to this specification requires support of EHLO.  Older
+systems should claim conformance to the [to-be-historical] 821, not this
+specification.
+
+X.1.7.  Substantive changes between draft-ietf-drums-smtpupd-06.txt and
+draft-ietf-drums-smtpupd-07.txt.
+
+(i) Removed "implied RSET" text associated with QUIT, as specified at the
+December 1997 IETF
+
+(ii) Required that servers support EHLO, as specified at the December 1997
+IETF
+
+X.1.8. Substantive changes between draft-ietf-drums-smtpupd-07.txt and
+draft-ietf-drums-smtpupd-08.txt.
+
+This version involves mostly editorial work and cleanup of loose ends.
+
+(i) New 7.5 added (old one renumbered) to discuss info disclosure through
+Received fields.
+
+(ii) Some character set and minor syntax issues clarified.
+
+(iii) Material on code 571 added (thought this had been done long ago;
+slipped through the cracks)
+
+(iv) Many clarifications added as the result of list discussions and
+suggestions.
+
+(v) Error code presentation has been restructured.
+
+(vi) ABNF conversion done
+
+(vii) IPv6 address format inserted per RFC 1884, since we could not get
+clear agreement on an alternative.
+
+(viii) Trivial, silly, examples removed.  Others not yet renumbered.
+
+(ix) 3.5.2 and 4.1.1 altered slightly per Eric Allman's notes.  Eric may
+not like the way I've done either of these change very much: the first now
+makes the distinction between returning an address and returning other
+stuff (which was permitted by -06, but the text wasn't as clear as it
+should have been): if it looks like an address, it needs to be an address.
+Similarly, with 4.1.1, Eric wanted to explicitly permit/legitimize "DATA
+<SP> <CRLF>".  I see several disadvantages to doing that, so have inserted
+language that encourages receivers to tolerate trailing white space, which
+may have the same practical effect.
+
+
+X.1.9. Substantive changes between draft-ietf-drums-smtpupd-08.txt and
+draft-ietf-drums-smtpupd-09.txt.
+
+The first ten of these reflect, in order, minuted items from the Chicago
+IETF (IETF 42).
+
+(i) Clarification of "MUST", etc., in the context of this document
+(section 2.3).
+
+(ii) Altered VRFY text to make implementation a SHOULD (section 3.5.1) and
+removed VRFY from the mandatory to implement list (section 4.5.1), per
+42nd IETF (Chicago).
+
+(iii) Clarified that exploders are expected to not purge sender addresses
+from lists (section 3.10).  Note that the Chicago conclusion was that this
+should be a "MUST".  I could not figure out how to do that without
+absolutely prohibiting removing addresses to prevent loops, to guard
+against spammers, or for similar legitimate purposes.  So I have written
+this as a "SHOULD", with additional "strongly discouraged" words.   If
+someone still wants a MUST, suggest text.
+
+(iv) Altered text to permit clients that sometimes, or even always,
+initiate sessions with HELO, rather than EHLO, to be fully-conforming
+(section 3.2).  [[ Editor's note: I continue to believe that a client that
+does not have any service extension support, even to the extent of being
+able to send EHLO and parse the response without doing anything about it,
+should not be considered fully-conforming to this spec (as distinct from
+821).   Consequently, the new text in 3.2 stops well short of encouraging
+clients that don't need service extensions from preferentially using HELO,
+and the text in 2.2.1 (which specifies that the extension mechanisms must
+be supported) has not been changed.
+
+(v) Per Chicago discussions, the text requiring that QUIT be sent has not
+been changed.  The text in 4.1.1.10 requiring that the server wait for
+QUIT has been changed to a SHOULD.  However, the text in 4.1.1.5,
+prohibiting close on receipt of RSET and that elsewhere prohibiting close
+as a normal response, has not been changed.
+
+(vi) Text has been inserted in 4.1.1 and the text in 4.3.2 altered
+slightly to clarify the handling of parameters to RSET, DATA, and QUIT and
+to 4.1.1.9 specify semantics for parameters to NOOP.  I have followed the
+minutes on this although I personally agree with kre's mailing list
+comments that the "servers SHOULD reject" decision leads to silly states.
+I recommend that the WG review this.
+
+(vii) Per discussion in Chicago, no substantive change has been made to
+the specification about underscore characters in domain names (section
+4.1.2).  However, the text has been altered to more accurately reflect
+discussion on the mailing list and the source of the requirement.
+
+(viii) Per discussion in Chicago, no change has been made to the
+preference for local time in Received headers.
+
+(ix) Per discussion in Chicago, code 571 has been removed and policy
+rejection is now reflected i a 550 code (section 3.7 and the response code
+lists).
+
+(x)  Per discussion in Chicago, no change has been made to the
+specification of use of raw CR or LF.
+
+(xi) In section 4.3, the text has been changed, per comments from Dan
+Bernstein and others, to require that clients be able to handle replies
+that do not contain text strings. A few other places patched to match.
+
+(xii) In sections 4.1.1.1 and 8, the placeholders have been removed.
+
+(xiii) Per discussion on the mailing list (and specifically James
+Berriman's concerns), the text has been clarified (sections 4.1.1.2 and
+4.1.4) to prohibit MAIL unless no mail transaction is open.  This is a
+MUST NOT prohibition -- SHOULD NOT makes no sense if this is the direction
+we are going to go.  503 has also been added to the list of valid
+responses for "MAIL" in 4.3.1 - it can't be issued before EHLO/HELO in any
+event.  While it is clear that something should be said, this may not be
+the desired outcome (I selected it because it was conservative and easy
+given the text that was there already); the WG should check that the text
+is as intended.
+
+(xiv) Per discussion on the mailing list, a new section 4.5.5 has been
+added to describe null return paths and their handling (forward pointer
+from 3.7).  The text in 4.5.5 is substantially that suggested by Norbert
+Bollow.   As with (xiii), there is now clear text, but it may not be what
+the WG desires.  Please check.
+
+[9b] Text lost in upload process restored.
+
+(xv) "all addresses" substituted for "each...in turn" in 3.10.2.
+
+(xvi) Requirement for "<" and ">" around paths clarified in section 3.3
+(syntax productions were clear and correct, but not this overview
+material).
+
+[9c]
+
+(xvii) Clarified text in 3.3 to permit post-DATA bounces on policy
+matters. 
+
+
+
+Z.  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.
+
+Expires June 1999
diff --git a/Documentation/en/I-D/draft-ietf-drums-smtpupd-13.txt b/Documentation/en/I-D/draft-ietf-drums-smtpupd-13.txt
index e1b6fd11..8584790a 100644
--- a/Documentation/en/I-D/draft-ietf-drums-smtpupd-13.txt
+++ b/Documentation/en/I-D/draft-ietf-drums-smtpupd-13.txt
@@ -1,101 +1,101 @@
-

-A new Request for Comments is now available in online RFC libraries.

-

-

-        RFC 2821

-

-        Title:      Simple Mail Transfer Protocol

-        Author(s):  J. Klensin, Editor

-        Status:     Standards Track

-        Date:       April 2001

-        Mailbox:    klensin@research.att.com

-        Pages:      79

-        Characters: 192504

-        Updates:    1123

-        Obsoletes:  821, 974

-

-        I-D Tag:    draft-ietf-drums-smtpupd-13.txt

-

-        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc2821.txt

-

-

-This document is a self-contained specification of the basic protocol

-for the Internet electronic mail transport.  It consolidates, updates

-and clarifies, but doesn't add new or change existing functionality of

-the following:

- 

--  the original SMTP (Simple Mail Transfer Protocol) specification of

-   RFC 821,

- 

--  domain name system requirements and implications for mail

-   transport from RFC 1035 and RFC 974,

- 

--  the clarifications and applicability statements in RFC 1123,

-   and

- 

--  material drawn from the SMTP Extension mechanisms.

- 

-It obsoletes RFC 821, RFC 974, and updates RFC 1123 (replaces the

-mail transport materials of RFC 1123).  However, RFC 821 specifies

-some features that were not in significant use in the Internet by the

-mid-1990s and (in appendices) some additional transport models.  Those

-sections are omitted here in the interest of clarity and brevity;

-readers needing them should refer to RFC 821.

-

-It also includes some additional material from RFC 1123 that required

-amplification.  This material has been identified in multiple ways,

-mostly by tracking flaming on various lists and newsgroups and

-problems of unusual readings or interpretations that have

-appeared as the SMTP extensions have been deployed.  Where this

-specification moves beyond consolidation and actually differs from

-earlier documents, it supersedes them technically as well as

-textually.

- 

-Although SMTP was designed as a mail transport and delivery protocol,

-this specification also contains information that is important to its

-use as a 'mail submission' protocol, as recommended for POP and IMAP. 

-

-Additional submission issues are discussed in RFC 2476.

- 

-Section 2.3 provides definitions of terms specific to this document.

-Except when the historical terminology is necessary for clarity, this

-document uses the current 'client' and 'server' terminology to

-identify the sending and receiving SMTP processes, respectively.

- 

-A companion document discusses message headers, message bodies

-and formats and structures for them, and their relationship.

-

-This document is a product of the Detailed Revision/Update of Message

-Standards Working Group of the IETF.

-

-This is now a Proposed Standard Protocol.

-

-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.

-

-This announcement is sent to the IETF list and the RFC-DIST list.

-Requests to be added to or deleted from the IETF distribution list

-should be sent to IETF-REQUEST@IETF.ORG.  Requests to be

-added to or deleted from the RFC-DIST distribution list should

-be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.

-

-Details on obtaining RFCs via FTP or EMAIL may be obtained by sending

-an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body 

-help: ways_to_get_rfcs.  For example:

-

-        To: rfc-info@RFC-EDITOR.ORG

-        Subject: getting rfcs

-

-        help: ways_to_get_rfcs

-

-Requests for special distribution should be addressed to either the

-author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG.  Unless

-specifically noted otherwise on the RFC itself, all RFCs are for

-unlimited distribution.echo 

-Submissions for Requests for Comments should be sent to

-RFC-EDITOR@RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC

-Authors, for further information.

+
+A new Request for Comments is now available in online RFC libraries.
+
+
+        RFC 2821
+
+        Title:      Simple Mail Transfer Protocol
+        Author(s):  J. Klensin, Editor
+        Status:     Standards Track
+        Date:       April 2001
+        Mailbox:    klensin@research.att.com
+        Pages:      79
+        Characters: 192504
+        Updates:    1123
+        Obsoletes:  821, 974
+
+        I-D Tag:    draft-ietf-drums-smtpupd-13.txt
+
+        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc2821.txt
+
+
+This document is a self-contained specification of the basic protocol
+for the Internet electronic mail transport.  It consolidates, updates
+and clarifies, but doesn't add new or change existing functionality of
+the following:
+ 
+-  the original SMTP (Simple Mail Transfer Protocol) specification of
+   RFC 821,
+ 
+-  domain name system requirements and implications for mail
+   transport from RFC 1035 and RFC 974,
+ 
+-  the clarifications and applicability statements in RFC 1123,
+   and
+ 
+-  material drawn from the SMTP Extension mechanisms.
+ 
+It obsoletes RFC 821, RFC 974, and updates RFC 1123 (replaces the
+mail transport materials of RFC 1123).  However, RFC 821 specifies
+some features that were not in significant use in the Internet by the
+mid-1990s and (in appendices) some additional transport models.  Those
+sections are omitted here in the interest of clarity and brevity;
+readers needing them should refer to RFC 821.
+
+It also includes some additional material from RFC 1123 that required
+amplification.  This material has been identified in multiple ways,
+mostly by tracking flaming on various lists and newsgroups and
+problems of unusual readings or interpretations that have
+appeared as the SMTP extensions have been deployed.  Where this
+specification moves beyond consolidation and actually differs from
+earlier documents, it supersedes them technically as well as
+textually.
+ 
+Although SMTP was designed as a mail transport and delivery protocol,
+this specification also contains information that is important to its
+use as a 'mail submission' protocol, as recommended for POP and IMAP. 
+
+Additional submission issues are discussed in RFC 2476.
+ 
+Section 2.3 provides definitions of terms specific to this document.
+Except when the historical terminology is necessary for clarity, this
+document uses the current 'client' and 'server' terminology to
+identify the sending and receiving SMTP processes, respectively.
+ 
+A companion document discusses message headers, message bodies
+and formats and structures for them, and their relationship.
+
+This document is a product of the Detailed Revision/Update of Message
+Standards Working Group of the IETF.
+
+This is now a Proposed Standard Protocol.
+
+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.
+
+This announcement is sent to the IETF list and the RFC-DIST list.
+Requests to be added to or deleted from the IETF distribution list
+should be sent to IETF-REQUEST@IETF.ORG.  Requests to be
+added to or deleted from the RFC-DIST distribution list should
+be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.
+
+Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
+an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body 
+help: ways_to_get_rfcs.  For example:
+
+        To: rfc-info@RFC-EDITOR.ORG
+        Subject: getting rfcs
+
+        help: ways_to_get_rfcs
+
+Requests for special distribution should be addressed to either the
+author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG.  Unless
+specifically noted otherwise on the RFC itself, all RFCs are for
+unlimited distribution.echo 
+Submissions for Requests for Comments should be sent to
+RFC-EDITOR@RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
+Authors, for further information.
diff --git a/Documentation/en/I-D/draft-ietf-fax-esmtp-conneg-00.txt b/Documentation/en/I-D/draft-ietf-fax-esmtp-conneg-01.txt
index d661baa3..f8a652ac 100644
--- a/Documentation/en/I-D/draft-ietf-fax-esmtp-conneg-00.txt
+++ b/Documentation/en/I-D/draft-ietf-fax-esmtp-conneg-01.txt
@@ -2,8 +2,8 @@
 
 Network Working Group                        K. Toyoda, MGCS
 Internet Draft                       D. Crocker, Brandenburg
-  draft-ietf-fax-esmtp-conneg-00.txt               June 2001
-Expires: <12/01>
+  draft-ietf-fax-esmtp-conneg-01.txt           November 2001
+Expires: May 2002
 
 
 
@@ -105,35 +105,32 @@ Expires: <12/01>
      in the CONNEG RCPT-TO reply, and transform data that is
      sent, so that the target can accept the data. The
      client SHOULD transform the data to the "highest" level
-     of capability of the server.
+     of capability of the target.
      
      Server Action:
           
           If the client specifies CONNEG in the RCPT-TO, but
-     the server does not support the CONNEG parameter, the
-     server MUST reject the RCPT-TO command with a 504
+     the target does not support the CONNEG parameter, the
+     target MUST reject the RCPT-TO command with a 504
      reply.
           
-          If the server does support the CONNEG parameter,
+          If the target does support the CONNEG parameter,
      then it MUST issue a 250 reply, followed by its
      capabilities of the target that is specified by the
      RCPT-TO address.
           
-          The response to a CONNEG RCPT-TO request will be
-     multi-line.  For successful (250) responses, at least
-     the first line of the response is for RCPT-TO
-     information other than CONNEG.  Additional response
-     lines are for CONNEG.    In order to avoid problems due
-     to variations in line buffer sizes, the total
-     parametric listing must be provided as a series of
-     lines, each beginning with "250-CONNEG" except for the
-     last line, which is "250 CONNEG".
-          
-          An alternative approach for lengthy CONNEG data
-     would be to fit the entire parameter list into one,
-     very long virtual line, using backslash ("\") escapes
-     at the end of each physical line.  This risks the
-     buffer overflow problem, cited above.
+           Successful responses to CONNEG RCPT-TO 
+     requests will always be multiple SMTP lines.  The
+     first line is the normal RCPT-TO response, and 
+     subsequent lines beginning with the exact string
+     "250-CONNEG " and "250 CONNEG " are the CONNEG responses.
+     The last line begins with "250 CONNEG ".  if the SMTP 
+     server supports ENHANCEDSTATUSCODES, the exact strings 
+     are "250-2.1.5 CONNEG " and "250 2.1.5 CONNEG ".
+
+         All CONNEG-capable clients and CONNEG-capable servers MUST
+     be able to successfully process CONNEG lines that are up to 512
+     characters long, as required by RFC2821.
           
           The contents of the capability listing MUST
      conform to the specifications in "Content Feature
@@ -143,14 +140,24 @@ Expires: <12/01>
 
 4.   SYNTAX
      
-     Content_Negotiation =    "CONNEG"
-     
-     Capability          =    <<as per [RFC2879]>>
+     Command with "CONNEG":
+      "RCPT TO:" ("<Postmaster@" domain ">" / "<Postmaster>"
+                   / Forward-Path) (SP "CONNEG") CRLF
+
+     Reply:
+      ( ("250-" CRLF) *("250-CONNEG" capability CRLF)
+        ("250 CONNEG" capability CRLF) )/
+      ( ("250-2.1.5" CRLF) 
+          *("250-2.1.5 CONNEG" capability CRLF)
+           ("250 2.1.5 CONNEG" capability CRLF) )
+
+      capability  =  <<as per [RFC2879]>>
 
 
 
 5.   EXAMPLE
      
+
      S: 220 ifax1.jp IFAX
      
      C: EHLO ifax1.jp
@@ -202,6 +209,43 @@ Expires: <12/01>
      S: 221 goodbye
 
 
+     An example when CONNEG-capable server supports 
+     ENHANCEDSTATUSCODES.
+     
+
+     S: 220 ifax1.jp IFAX
+     
+     C: EHLO ifax1.jp
+     
+     S: 250-ifax1.jp
+     S: 250-DSN
+     S: 250-ENHANCEDSTATUSCODES
+     S: 250 CONNEG
+          
+     C: MAIL FROM:<May@ifax2.jp>
+     
+     S: 250 2.1.5<May@ifax2.jp> sender ok
+     
+     C: RCPT TO:<June@ifax1.jp> CONNEG
+     
+     S: 250-2.1.5<June@ifax1.jp> recipient ok
+     S: 250-2.1.5 CONNEG (&(image-file-structure=TIFF-minimal)
+     S: 250-2.1.5 CONNEG   (MRC-mode=0)
+     S: 250-2.1.5 CONNEG   (color=Binary)
+     S: 250-2.1.5 CONNEG   (|(&(dpi=204)
+     S: 250-2.1.5 CONNEG       (dpi-xyratio=[204/98,204/196]) )
+     S: 250-2.1.5 CONNEG     (&(dpi=200)
+     S: 250-2.1.5 CONNEG       (dpi-xyratio=[200/100,1]) )
+     S: 250-2.1.5 CONNEG     (&(dpi=400)
+     S: 250-2.1.5 CONNEG       (dpi-xyratio=1) ) )
+     S: 250-2.1.5 CONNEG   (|(image-coding=[MH,MR,MMR])
+     S: 250-2.1.5 CONNEG      (&(image-coding=JBIG)
+     S: 250-2.1.5 CONNEG        (image-coding-constraint=JBIG-T85)
+     S: 250-2.1.5 CONNEG        (JBIG-stripe-size=128) ) )
+     S: 250-2.1.5 CONNEG   (paper-size=[letter,A4,B4])
+     S: 250 2.1.5 CONNEG   (ua-media=stationery) )
+     
+
 
 6.   IANA CONSIDERATIONS
      
diff --git a/Documentation/en/I-D/draft-ietf-msgtrk-model-04.txt b/Documentation/en/I-D/draft-ietf-msgtrk-model-04.txt
index 51677c0d..2cad09fa 100644
--- a/Documentation/en/I-D/draft-ietf-msgtrk-model-04.txt
+++ b/Documentation/en/I-D/draft-ietf-msgtrk-model-04.txt
@@ -1,19 +1,562 @@
-

-This Internet-Draft has been deleted. Unrevised documents placed in the

-Internet-Drafts directories have a maximum life of six months. After

-that time, they are deleted. This Internet-Draft was not published as

-an RFC.

-

-Internet-Drafts are not an archival document series, and expired

-drafts, such as this one, are not available; please do not ask for

-copies... they are not available. The Secretariat does not have

-information as to future plans of the authors or working groups WRT the

-deleted Internet-Draft.

-

-For more information or a copy of the document, contact the author directly.

-

-Draft Author(s):

-

-T. Hansen: tony@att.com                                                            

-

-

+
+
+
+
+
+
+Internet Draft                                                 T. Hansen
+draft-ietf-msgtrk-model-04.txt                         AT&T Laboratories
+Valid for six months                                    November 6, 2001
+
+
+
+                Message Tracking Model and Requirements
+
+                    <draft-ietf-msgtrk-model-04.txt>
+
+                         Authors' version: 1.14
+
+     Status of this Memo
+
+     This document is an Internet-Draft and is in full conformance with
+all provisions of Section 10 of RFC2026.
+
+     Internet-Drafts are working documents of the Internet Engineering
+Task Force (IETF), its areas, and its working groups.  Note that other
+groups may also distribute working documents as Internet-Drafts.
+
+     Internet-Drafts are draft documents valid for a maximum of six
+months and may be updated, replaced, or obsoleted by other documents at
+any time.  It is inappropriate to use Internet-Drafts as reference
+material or to cite them other than as "work in progress."
+
+     The list of current Internet-Drafts can be accessed at
+http://www.ietf.org/ietf/1id-abstracts.txt.
+
+     The list of Internet-Draft Shadow Directories can be accessed at
+http://www.ietf.org/shadow.html.
+
+     This memo and its companions are discussed on the MSGTRK working
+group mailing list, ietf-msgtrk@imc.org.  To subscribe, send a message
+with the word "subscribe" in the body (on a line by itself) to the
+address ietf-msgtrk-request@imc.org.  An archive of the mailing list may
+be found at http://www.ietf.org/archive/msgtrk.
+
+Copyright Notice
+
+     Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+Abstract
+
+     Customers buying enterprise message systems often ask: Can I track
+the messages?  Message tracking is the ability to find out the path that
+a particular message has taken through a messaging system and the
+current routing status of that message.  This document provides a model
+
+
+
+Hansen,Lin                                                      [Page 1]
+
+Internet Draft  Message Tracking Model and Requirements November 6, 2001
+
+
+of message tracking that can be used for understanding the Internet-wide
+message infrastructure and to further enhance those capabilities to
+include message tracking, as well as requirements for proposed message
+tracking solutions.
+
+1.  Problem Statement
+
+     Consider sending a package through a package delivery company.
+Once you've sent a package, you would like to be able to find out if the
+package has been delivered or not, and if not, where that package
+currently is and what its status is.  Note that the status of a package
+may not include whether it was delivered to its addressee, but just the
+destination.  Many package carriers provide such services today, often
+via a web interface.
+
+     Message tracking extends that capability to the Internet-wide mes-
+sage infrastructure, analogous to the service provided by package car-
+riers:  the ability to quickly locate where a message (package) is, and
+to determine whether or not the message (package) has been delivered to
+its final destination.  An Internet-standard approach will allow the
+development of message tracking applications that can operate in a
+multi-vendor messaging environment, and will encourage the operation of
+the function across administrative boundaries.
+
+     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+"SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
+document are to be interpreted as described in RFC 2119 [RFC-KEYWORDS].
+
+2.  Definitions
+The following terms are relevant to message tracking.  The terms Track-
+ing User Agent and Tracking Server are new, while all other terms have
+been collected here from other sources.
+
+     Originating Mail User Agent (MUA)
+               The originating mail user agent is the software used to
+               compose and originate a message.  It is the software sit-
+               ting on a person's desktop.
+
+     Originating Mail Submission Agent (MSA)
+               The Mail Submission Agent accepts a message from a User
+               Agent, adds or modifies it as required for Internet stan-
+               dards and/or site policy, and injects the message into
+               the network.  The MSA may be the initial MTA or may hand
+               off the message to an MTA.
+
+     Message Transfer Agent (MTA)
+               A Message Transfer Agent accepts a message and moves it
+               forward towards its destination.  That destination may be
+
+
+
+Hansen,Lin                                                      [Page 2]
+
+Internet Draft  Message Tracking Model and Requirements November 6, 2001
+
+
+               local or reached via another MTA.  It may use a local
+               queue to store the message before transferring it
+               further.  Any MTA may generate a Non-Delivery Notifica-
+               tion.
+
+     Intermediate Message Transfer Agent (MTA)
+               An Intermediate MTA is an MTA that accepts a message for
+               transfer somewhere else.
+
+     Final Message Transfer Agent (MTA)
+               A Final MTA is an MTA that accepts a message for local
+               delivery.  It is the final place that a message is
+               accepted.  The final MTA is what sends any Delivery
+               Status Notificatons (DSNs).  (Intermediate MTA's may also
+               send a DSN if it relays to a non-DSN aware MTA.)
+
+     Foreign Message Transfer Agent
+               A foreign MTA provides delivery of messages using other
+               protocols than those specified for Internet mail, such as
+               an X.400 mail system.
+
+     Gateway Message Transfer Agent (GW-MTA)
+               A gateway MTA accepts a message for transfer to a foreign
+               MTA outside of the Internet protocol space.
+
+     Local Delivery Agent (LDA)
+               The local Delivery Agent delivers the message to the
+               local message store.  (The MTA and LDA are often combined
+               into the same program.)
+
+     Delivery Status Notification (DSN)
+               A Delivery Status Notification [RFC-DSN] is produced by
+               an MTA when a message is unsuccessfully delivered, either
+               to its next hop or the final message store, or when it is
+               successfully delivered, either to a foreign MTA, to a
+               local delivery agent, or a non-DSN aware MTA.  Positive
+               notifications are only performed [RFC-ESMTP-DSN] when
+               specifically requested.
+
+     Non-Delivery Notification (NDN)
+               A non-delivery notification is a special form of DSN
+               indicating unsuccessful delivery.
+
+     Message Disposition Notification (MDN)
+               A Message Disposition Notification is used to report the
+               disposition of a message after it has been successfully
+               delivered to a recipient.
+
+
+
+
+Hansen,Lin                                                      [Page 3]
+
+Internet Draft  Message Tracking Model and Requirements November 6, 2001
+
+
+     Tracking User Agent (TUA)
+               A tracking user agent wants to find information on a mes-
+               sage on the behalf of a user.  It is the requestor or
+               initiator of such a request.  (The MUA and TUA could be
+               combined into the same program.)
+
+     Tracking Server
+               A tracking server provides tracking information to a
+               tracking client.  It is the repository of the information
+               about a message for the traversal through a particular
+               MTA.  (The tracking server and MTA may run on the same
+               system.)
+
+3.  Entities
+
+     The entities involved in message tracking are:  message user
+agents, message submission agents, message transfer agents, tracking
+user agents and tracking servers.
+
+4.  Requirements
+
+     These are requirements that any message tracking solution must be
+able to satisfy:
+
+     The message tracking solution:
+
+     **   MUST scale to the internet.
+
+     **   MUST be easy to deploy.
+
+     **   SHOULD maximize the reuse of existing, already deployed tech-
+          nology and infrastructure.
+
+     **   If possible, SHOULD extend existing protocols and not invent
+          new ones.
+
+     **   SHOULD have a low implementation cost.  (This makes it easy to
+          incorporate into existing products.)
+
+     **   MUST restrict tracking of a message to the originator of the
+          message (or a delegate).
+
+     **   MUST be able to do authentication.
+
+     **   MAY allow an originator to delegate this responsibility to a
+          third party.
+
+     **   SHOULD have the property that they would allow per-message
+
+
+
+Hansen,Lin                                                      [Page 4]
+
+Internet Draft  Message Tracking Model and Requirements November 6, 2001
+
+
+          delegation of the tracking responsibility.
+
+     **   MUST require a tracking user agent to prove that they are per-
+          mitted to request the tracking information.
+
+     **   MUST be able to uniquely identify messages.
+
+     **   MUST require every message to have unique identification.
+
+5.  Interaction Models
+
+     There are several models by which tracking of messages can be
+enabled, by which messages can be tracked, and by which information can
+be requested and gathered.
+
+5.1.  Tracking Enabling Models
+
+     Either the envelope or message header must contain enough informa-
+tion to track a message and securely retrieve information about the mes-
+sage.  Any message that does not have enough information to track it is
+by definition not trackable.
+
+     If there is not enough information available in current standard
+envelopes or message headers, then the current standards will need to be
+extended.  Either the MUA or MSA must determine the additional informa-
+tion and enable the tracking by adding the additional information to
+either the envelope or header.
+
+     This leads to two tracking enabling models:  passive enabling and
+active enabling.
+
+5.1.1.  Passive Enabling Model
+The "passive enabling" model assumes that there is sufficient informa-
+tion available.  No UA or MSA interaction occurs to turn tracking on; it
+is on by default.
+
+5.1.2.  Active Enabling Model
+
+     The "active  enabling" model requires that the MUA and MSA exchange
+information when the message is submitted.  This exchange indicates that
+logging of the message's traversal should be performed, as well as pro-
+viding enough additional information to allow the message to be tracked.
+This information will need to be passed on to subsequent MTAs as needed.
+
+5.2.  Tracking Request Models
+There are several models by which tracking information may be requested.
+
+
+
+
+
+Hansen,Lin                                                      [Page 5]
+
+Internet Draft  Message Tracking Model and Requirements November 6, 2001
+
+
+5.2.1.  Passive Request Model
+
+     The "passive request" model requires active enabling to indicate
+that some form of tracking is to be performed.  The tracking information
+can be sent back immediately (as a form of telemetry) or sent to a 3rd
+party for later retrieval.
+
+5.2.2.  Passive Request Tracking Information
+
+     Forms of passive tracking information that could potentially be
+requested are  as  follows.  Note that mechanisms already exist for
+requesting the information marked with a (+).  The references for such
+mechanisms are listed at the end of each such entry.
+
+     **   send a DSN of a message arriving at an intermediate MTA
+
+     **   (+) send a DSN of a message being rejected while at an inter-
+          mediate MTA [RFC-DSN]
+
+     **   (+) send a DSN of a message leaving an intermediate MTA and
+          going to another MTA [RFC-DELIVER-BY]
+
+     **   send a DSN of a message arriving at a final MTA
+
+     **   (+) send a DSN of a message being rejected while at a final
+          MTA [RFC-DSN]
+
+     **   (+) send a DSN of a message being delivered to a user's mes-
+          sage store [RFC-DSN]
+
+     **   (+) send a DSN of a message being delivered to a foreign MTA
+          [RFC-DSN]
+
+     **   (+) send an MDN of a message being read by an end user [RFC-
+          MDN]
+
+5.3.  Active Request Model
+
+     The "active request" model requires an active query by a user's
+user agent to the MSA, intermediate MTAs and final MTA, or to a third
+party, to find the message's status as known by that MTA.  Active
+request will work with either passive enabling or active enabling.
+
+5.3.1.  Server Chaining vs. Server Referrals
+When a tracking server has been asked for tracking information, and the
+message has been passed on to another MTA of which this tracking server
+has no tracking knowledge, there are two modelling choices:
+
+
+
+
+Hansen,Lin                                                      [Page 6]
+
+Internet Draft  Message Tracking Model and Requirements November 6, 2001
+
+
+     **   the first tracking server will contact the next tracking
+          server to query for status and pass back the combined status
+          (server chaining), or
+
+     **   the first tracking server will return the address of the next
+          MTA and the tracking client has the responsibility of contact-
+          ing the next tracking server (server referrals).
+
+5.3.2.  Active Request Tracking Information
+Forms of active tracking information that could potentially be requested
+are as follows.  (Note that no mechanisms currently exist for requesting
+such information.)
+
+     **   the message has been queued for later delivery
+
+     **   the message was delivered locally
+
+     **   the message was delivered to another MTA,
+
+     **   the message was delivered to a foreign MTA
+
+     **   ask a different tracking server,
+
+     **   I know but can't tell you,
+
+     **   I don't know.
+
+5.4.  Combining DSN and MDN Information with Message Tracking Informa-
+tion
+
+     The information that would be retrieved by message tracking and the
+information that is returned for DSN and MDN requests all attempt to
+answer the question of "what happened to message XX"?  The information
+provided by each is complementary in nature, but similar.  A tracking
+user agent could use all three possible information  sources  to present
+a total view of the status of a message.
+
+     Both DSN and MDN notifications utilize the formats defined by RFC
+1892 [RFC-REPORT].  This suggests that the information returned by mes-
+sage tracking solutions should also be similar.
+
+6.  Security
+
+     This is a security model for message identification and authentica-
+tion that could be deployed.  (There may be others.)
+
+     A Tracking User Agent must prove that they are permitted to request
+tracking information about a message.  Every [RFC-822]-compliant message
+
+
+
+Hansen,Lin                                                      [Page 7]
+
+Internet Draft  Message Tracking Model and Requirements November 6, 2001
+
+
+is supposed to contain a Message-Id header.  One possible mechanism is
+for the originator to calculate a one-way hash A from the message ID +
+time stamp + a per-user secret.  The user then calculates another one-
+way hash B to be the hash of A.  The user includes B in the submitted
+message, and retains A.  Later, when the user makes a message tracking
+request to the messaging system or tracking entity, it submits A in the
+tracking request.  The entity receiving the tracking request then uses A
+to calculate B, since it was already provided B, verifying that the
+requestor is authentic.  In summary,
+
+     A = H(message ID + time stamp + secret)
+
+     B = H(A)
+
+Another possible mechanism for A is to ignore the message ID and time
+stamp and just use a one-way hash from a large (>128 bits) random
+number.  B would be calculated as before.  In summary,
+
+     A = H(large-random-number)
+
+     B = H(A)
+
+This is similar in technique to the methods used for One-Time Passwords
+[RFC-OTP].  The success of these techniques is dependent on the random-
+ness of the per-user secret or the large random number, which can be
+incredibly difficult in some environments.
+
+     If the originator of a message were to delegate his or her tracking
+request to a third party by sending it A, this would be vulnerable to
+snooping over unencrypted sessions.  The user can decide on a message-
+by-message basis if this risk is acceptable.
+
+7.  References
+
+
+     [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet
+               Text Messages", STD 11, RFC 822, UDEL, August 1982.
+
+     [RFC-DELIVER-BY]
+               Newman, D., "Deliver By SMTP Service Extension", draft-
+               newman-deliver-02.txt, Innosoft, January 1999.
+
+     [RFC-DSN] Moore, K., and G. Vaudreuil, "An Extensible Message For-
+               mat for Delivery Status Notifications", RFC 1894, Univer-
+               sity of Tennessee, Octel Network Services, January 1996.
+
+     [RFC-ESMTP-DSN]
+               Moore, K., "SMTP Service Extension for Delivery Status
+
+
+
+Hansen,Lin                                                      [Page 8]
+
+Internet Draft  Message Tracking Model and Requirements November 6, 2001
+
+
+               Notifications", RFC 1891, University of Tennessee, Janu-
+               ary 1996.
+
+     [RFC-KEYWORDS]
+               Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", RFC 2119, Harvard University, March
+               1997.
+
+     [RFC-MDN] Fajman, R., "An Extensible Message Format for Message
+               Disposition Notifications", RFC 2298, National Institutes
+               of Health, March 1998.
+
+     [RFC-OTP] Haller, N., Metz, C., Nesser, P., Straw, M., "A One-Time
+               Password System", RFC 2289, Bellcore, Kaman Sciences Cor-
+               poration, Nesser & Nesser Consulting, Bellcore, February
+               1998.
+
+     [RFC-REPORT]
+               Vaudreuil, G., "The Multipart/Report Content Type for the
+               Reporting of Mail System Administrative Messages", RFC
+               1892, Octel Network Services, January 1996.
+
+     [RFC-SMTP]Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
+               821, USC/Information Sciences Institute, August 1982.
+
+8.  Acknowledgements
+
+     This document is the product of input from many people and many
+sources, including all of the members of the Message Tracking Working
+Group.  It owes much to earlier work by Gordon Jones, Bruce Ernst and
+Greg Vaudreuil.  In particular, I'd like to also thank Ken Lin for his
+considerable contributions to the early drafts.
+
+9.  Authors' Addresses
+     Tony Hansen
+     AT&T Laboratories
+     Lincroft, NJ 07738
+     USA
+
+     Phone: +1 732 576-3207
+     E-Mail: tony@att.com
+
+10.  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
+
+
+
+Hansen,Lin                                                      [Page 9]
+
+Internet Draft  Message Tracking Model and Requirements November 6, 2001
+
+
+assist in its implmentation may be prepared, copied, published and dis-
+tributed, 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 organisations,
+except as needed for the purpose of developing Internet standards in
+which case the procedures for copyrights defined in the Internet Stan-
+dards 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.
+
+     This document expires May 6, 2002.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hansen,Lin                                                     [Page 10]
diff --git a/Documentation/en/I-D/draft-ietf-msgtrk-mtqp-03.txt b/Documentation/en/I-D/draft-ietf-msgtrk-mtqp-04.txt
index 2a49b521..733bb4dc 100644
--- a/Documentation/en/I-D/draft-ietf-msgtrk-mtqp-03.txt
+++ b/Documentation/en/I-D/draft-ietf-msgtrk-mtqp-04.txt
@@ -5,16 +5,16 @@
 
 
 Internet Draft                                                 T. Hansen
-draft-ietf-msgtrk-mtqp-03.txt                          AT&T Laboratories
-Valid for six months                                        July 1, 2001
+draft-ietf-msgtrk-mtqp-04.txt                          AT&T Laboratories
+Valid for six months                                   November 20, 2001
 
 
 
                     Message Tracking Query Protocol
 
-                    <draft-ietf-msgtrk-mtqp-03.txt>
+                    <draft-ietf-msgtrk-mtqp-04.txt>
 
-                         Authors' version: 1.7
+                         Authors' version: 1.10
 
      Status of this Memo
 
@@ -57,7 +57,7 @@ current routing status of that message.  This document describes the
 
 Hansen                                                          [Page 1]
 
-Internet Draft      Message Tracking Query Protocol         July 1, 2001
+Internet Draft      Message Tracking Query Protocol    November 20, 2001
 
 
 Message Tracking Query Protocol that is used in conjunction with exten-
@@ -76,9 +76,9 @@ The memo [DRAFT-TRACK-ESMTP] defines an extension to the SMTP service
 that provides the information necessary to track messages.  This memo
 defines a protocol that can be used to query the status of messages that
 have been transmitted on the Internet via SMTP.  The memo [DRAFT-TRACK-
-TSN] describes the message/tracking-status MIME media type that is used
-to report tracking status information.  Using the model document's ter-
-minology, this solution uses active enabling and active requests with
+TSN] describes the message/tracking-status [RFC-MIME] media type that is
+used to report tracking status information.  Using the model document's
+terminology, this solution uses active enabling and active requests with
 both request and chaining referrals.
 
 1.1.  Terminology
@@ -91,7 +91,48 @@ document are to be interpreted as described in [RFC-KEYWORDS].
 minal nodes not defined elsewhere in this document are defined in [RFC-
 ABNF], [RFC-URI], [DRAFT-TRACK-ESMTP] or [RFC-SMTPEXT].
 
-1.2.  Changes Made for -02
+1.2.  Changes Made for -04
+
+     Reworked the SRV lookup description.
+
+     Other comments from the list.
+
+     Changes to the ABNF.
+
+     Changed "must" to "MUST" in section 4.
+
+     Changed "may" to "MAY" in section 4.
+
+     More examples.
+
+     Eliminated the registry of vnd. options.
+
+     Eliminated lots of unused references.
+
+
+
+Hansen                                                          [Page 2]
+
+Internet Draft      Message Tracking Query Protocol    November 20, 2001
+
+
+1.3.  Changes Made for -03
+
+     Changed references.
+
+     Worked on error codes.
+
+     Made examples more real with secrets and hashes.
+
+     Fixes to examples.
+
+     Added dot-stuffed example.
+
+     Additional TLS info.
+
+     Better Security Considerations section.
+
+1.4.  Changes Made for -02
 
      This section will be removed before publication.
 
@@ -108,14 +149,6 @@ information on the option registry.
      Added text on various error conditions and fixed ABNF for error
 response codes.
 
-
-
-
-Hansen                                                          [Page 2]
-
-Internet Draft      Message Tracking Query Protocol         July 1, 2001
-
-
      Fleshed out the tracking examples.
 
 2.  Basic Operation
@@ -126,14 +159,22 @@ the server host starts the MTQP service by listening on TCP port XXXX
 (TBD by IANA).
 
      When an MTQP client wishes to make use of the message tracking ser-
-vice, it establishes a TCP connection with the server host.  To find the
-server host, the MTQP client first does an SRV lookup for the server
-host using DNS SRV records, with a service name of "mtqp".  (See the
-"Usage rules" section in [RFC-SRV] for details.)  If the host is not
-found, the MTQP client then does an MX lookup for the server host using
-DNS MX records, as specified in [RFC-DNS] and revised by [RFC-HOSTS].
-If the host is still not found, the MTQP client then does an A record
-lookup for the server host.
+vice, it establishes a TCP connection with the server host, as recorded
+from the initial message submission or as returned by a previous track-
+ing request.  To find the server host, the MTQP client first does an SRV
+lookup for the server host using DNS SRV records, with a service name of
+"mtqp" and a protocol name of "tcp", as in _mtqp._tcp.smtp3.example.com.
+
+
+
+Hansen                                                          [Page 3]
+
+Internet Draft      Message Tracking Query Protocol    November 20, 2001
+
+
+(See the "Usage rules" section in [RFC-SRV] for details.)  If the SRV
+records do not exist, the MTQP client then does an address record lookup
+for the server host.
 
      When the connection is established, the MTQP server sends a greet-
 ing.  The MTQP client and MTQP server then exchange commands and
@@ -153,7 +194,7 @@ Both mail and MTQP clients will access that host directly.
 ing queries to be performed on a different machine, MUST have an SRV
 MTQP record pointing at that different machine.
 
-     A mail system that uses multiple mail servers has two choices for
+     A mail system that uses multihomed mail servers has two choices for
 providing tracking services: either all mail servers must be running
 tracking servers that are able to retrieve information on all messages,
 or the tracking service must be performed on one (or more) machine(s)
@@ -161,16 +202,8 @@ that are able to retrieve information on all messages.  In the former
 case, no additional DNS records are needed beyond the MX records already
 in place for the mail system.  In the latter case, SRV MTQP records are
 needed that point at the machine(s) that are running the tracking ser-
-vice.  In both cases, note that the tracking service for a given mail
-domain MUST be able to handle the queries for all messages destined for
-that mail domain.
-
-
-
-Hansen                                                          [Page 3]
-
-Internet Draft      Message Tracking Query Protocol         July 1, 2001
-
+vice.  In both cases, note that the tracking service MUST be able to
+handle the queries for all messages accepted by that mail system.
 
 2.2.  Commands
 
@@ -187,20 +220,27 @@ before the CRLF.
 cess or failure.  Successful commands may also be followed by additional
 lines of data.  All response lines are terminated by a CRLF pair and are
 limited to 998 characters before the CRLF.  There are several status
+
+
+
+Hansen                                                          [Page 4]
+
+Internet Draft      Message Tracking Query Protocol    November 20, 2001
+
+
 indicators:  "+OK" indicates success; "+OK+" indicates a success fol-
 lowed by additional lines of data, a multi-line success response; "-
 TEMP" indicates a temporary failure; "-ERR" indicates a permanent
 failure; and "-BAD" indicates a protocol error (such as for unrecognized
 commands).
 
-     A status indicator MAY be followed by a series of machine-
-parseable, case-insensitive response information giving more data about
-the errors.  These are separated from the status indicator and each
-other by a single slash character ("/", decimal code 47).  Following
-that, there MAY be white space and a human-readable text message.  The
-human-readable text message is not intended to be presented to the end
-user, but should be appropriate for putting in a log for use in debug-
-ging problems.
+     A status indicator MAY be followed by a series of machine-parsable,
+case-insensitive response information giving more data about the errors.
+These are separated from the status indicator and each other by a single
+slash character ("/", decimal code 47).  Following that, there MAY be
+white space and a human-readable text message.  The human-readable text
+message is not intended to be presented to the end user, but should be
+appropriate for putting in a log for use in debugging problems.
 
      In a multi-line success response, each subsequent line is ter-
 minated by a CRLF pair and limited to 998 characters before the CRLF.
@@ -221,28 +261,30 @@ indicator.  A server MUST respond to a command issued when the session
 is in an incorrect state by responding with a negative -ERR status indi-
 cator.
 
-
-
-Hansen                                                          [Page 4]
-
-Internet Draft      Message Tracking Query Protocol         July 1, 2001
-
-
 2.4.  Optional Timers
 
      An MTQP server MAY have an inactivity autologout timer.  Such a
 timer MUST be of at least 10 minutes in duration.  The receipt of any
 command from the client during that interval should suffice to reset the
-autologout timer.  An MTQP server MAY limit the number of commands or
-total connection time to prevent denial of service attacks.
+autologout timer.  An MTQP server MAY limit the number of commands,
+unrecognized commands, or total connection time, or MAY use other cri-
+teria, to prevent denial of service attacks.
 
 2.5.  Firewall Considerations
 
      A firewall mail gateway has two choices when receiving a tracking
 query for a host within its domain: it may return a response to the
 query that says the message has been passed on, but no further informa-
-tion is available; or it may perform a chaining operation itself, gath-
-ering information on the message from the mail hosts behind the
+tion is available; or it may perform a chaining operation itself,
+
+
+
+Hansen                                                          [Page 5]
+
+Internet Draft      Message Tracking Query Protocol    November 20, 2001
+
+
+gathering information on the message from the mail hosts behind the
 firewall, and returning to the MTQP client the information for each
 behind-the-firewall hop, or possibly just the final hop information,
 possibly also disguising the names of any hosts behind the firewall.
@@ -264,9 +306,9 @@ vailable".
      "/" "unavailable"
      "/" "admin"
 
-     The reason code "/admin" may be used when the service is unavail-
-able for administrative reasons.  The reason code "/unavailable" may be
-used when the service is unavailable for other reasons.
+     The reason code "/admin" SHOULD be used when the service is una-
+vailable for administrative reasons.  The reason code "/unavailable"
+SHOULD be used when the service is unavailable for other reasons.
 
      If the server has any options enabled, they are listed as the
 multi-line response of the initial status response, one per line.  An
@@ -274,15 +316,8 @@ option specification consists of an identifier, optionally followed by
 option-specific parameters.  An option specification may be continued
 onto additional lines by starting the continuation lines with white
 space.  The option identifier is case insensitive.  Option identifiers
-beginning with the characters "vnd." are reserved for vendor use.
-
-
-
-
-Hansen                                                          [Page 5]
-
-Internet Draft      Message Tracking Query Protocol         July 1, 2001
-
+beginning with the characters "vnd." are reserved for vendor use.  (See
+below.)
 
      One option specification is defined here:
 
@@ -297,6 +332,14 @@ ported by the MTQP server.  It has no parameters.
      Example #2 (service temporarily unavailable):
      S: -TEMP/MTQP/admin Service down for admin, call back later
 
+
+
+
+Hansen                                                          [Page 6]
+
+Internet Draft      Message Tracking Query Protocol    November 20, 2001
+
+
      Example #3 (service permanently unavailable):
      S: -ERR/MTQP/unavailable Service down
 
@@ -307,8 +350,8 @@ ported by the MTQP server.  It has no parameters.
      Example #5 (options available):
      S: +OK+/MTQP MTQP server ready
      S: starttls
-     S: Option2 with parameters
-     S: Option3 with a very long
+     S: vnd.com.example.option2 with parameters private to example.com
+     S: vnd.com.example.option3 with a very long
      S:  list of parameters
      S: .
 
@@ -325,23 +368,15 @@ A described in [DRAFT-TRACK-ESMTP], encoded using base64.
      When the client issues the TRACK command, and the user is vali-
 dated, the MTQP server retrieves tracking information about an email
 message.  To validate the user, the value of mtrk-secret is hashed using
-SHA1, as described in [NIST-SHA1].  The hash value is then compared with
+SHA1, as described in [RFC-SHA1].  The hash value is then compared with
 the value passed with the message when it was originally sent.  If the
 hash values match, the user is validated.
 
-     A successful response MUST be multi-line, consisting of a [MIME]
-body part.  The MIME body part must be of type multipart/related, with
-subparts of message/tracking-status, as defined in [DRAFT-TRACK-TSN].
-
-
-
-Hansen                                                          [Page 6]
-
-Internet Draft      Message Tracking Query Protocol         July 1, 2001
-
-
-The response contains the tracking information about the email message
-that used the given tracking-id.
+     A successful response MUST be multi-line, consisting of a [RFC-
+MIME] body part.  The MIME body part MUST be of type multipart/related,
+with subparts of message/tracking-status, as defined in [DRAFT-TRACK-
+TSN].  The response contains the tracking information about the email
+message that used the given tracking-id.
 
 
      In each of the examples below, the envid is "<12345-
@@ -353,6 +388,14 @@ came from example.com and the MTQP server is example2.com.
      C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK
      S: +OK+ Tracking information follows
      S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status
+
+
+
+Hansen                                                          [Page 7]
+
+Internet Draft      Message Tracking Query Protocol    November 20, 2001
+
+
      S:
      S: --%%%%
      S: Content-Type: message/tracking-status
@@ -388,14 +431,6 @@ came from example.com and the MTQP server is example2.com.
      S: Last-Attempt-Date: Mon,  1 Jan 2001 19:15:03 -0500
      S: Status: 2.4.0
      S:
-
-
-
-Hansen                                                          [Page 7]
-
-Internet Draft      Message Tracking Query Protocol         July 1, 2001
-
-
      S: --%%%%--
      S: .
 
@@ -409,6 +444,14 @@ Internet Draft      Message Tracking Query Protocol         July 1, 2001
      S: Content-Type: message/tracking-status
      S:
      S: Original-Envelope-Id: 12345-20010101@example.com
+
+
+
+Hansen                                                          [Page 8]
+
+Internet Draft      Message Tracking Query Protocol    November 20, 2001
+
+
      S: Reporting-MTA: dns; example2.com
      S: Arrival-Date: Mon,  1 Jan 2001 15:15:15 -0500
      S:
@@ -444,23 +487,57 @@ Internet Draft      Message Tracking Query Protocol         July 1, 2001
      S:
      S: Original-Recipient: rfc822; user2@example1.com
      S: Final-Recipient: rfc822; user2@example1.com
+     S: Action: failed
+     S: Status 5.2.2 (Mailbox full)
+     S: Remote-MTA: dns; example3.com
+     S: Last-Attempt-Date: Mon,  1 Jan 2001 19:15:03 -0500
+     S:
+     S: --%%%%--
+     S: .
+
+     Example #10 Firewall:
+     C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK
+     S: +OK+ Tracking information follows
+     S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status
+     S:
 
 
 
-Hansen                                                          [Page 8]
+Hansen                                                          [Page 9]
 
-Internet Draft      Message Tracking Query Protocol         July 1, 2001
+Internet Draft      Message Tracking Query Protocol    November 20, 2001
 
 
-     S: Action: failed
-     S: Status 5.2.2 (Mailbox full)
-     S: Remote-MTA: dns; example3.com
+     S: --%%%%
+     S: Content-Type: message/tracking-status
+     S:
+     S: Original-Envelope-Id: 12345-20010101@example.com
+     S: Reporting-MTA: dns; example2.com
+     S: Arrival-Date: Mon,  1 Jan 2001 15:15:15 -0500
+     S:
+     S: Original-Recipient: rfc822; user1@example1.com
+     S: Final-Recipient: rfc822; user1@example1.com
+     S: Action: relayed
+     S: Status: 2.1.9
+     S: Remote-MTA: dns; example2.com
      S: Last-Attempt-Date: Mon,  1 Jan 2001 19:15:03 -0500
      S:
+     S: --%%%%
+     S: Content-Type: message/tracking-status
+     S:
+     S: Original-Envelope-Id: 12345-20010101@example.com
+     S: Reporting-MTA: dns; smtp.example3.com
+     S: Arrival-Date: Mon,  1 Jan 2001 15:15:15 -0500
+     S:
+     S: Original-Recipient: rfc822; user2@example1.com
+     S: Final-Recipient: rfc822; user4@example3.com
+     S: Action: delivered
+     S: Status: 2.5.0
+     S:
      S: --%%%%--
      S: .
 
-     Example #10 Firewall, Hiding System Names Behind the Firewall:
+     Example #11 Firewall, Combining Per-Recipient Blocks:
      C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK
      S: +OK+ Tracking information follows
      S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status
@@ -479,6 +556,27 @@ Internet Draft      Message Tracking Query Protocol         July 1, 2001
      S: Remote-MTA: dns; example2.com
      S: Last-Attempt-Date: Mon,  1 Jan 2001 19:15:03 -0500
      S:
+
+
+
+Hansen                                                         [Page 10]
+
+Internet Draft      Message Tracking Query Protocol    November 20, 2001
+
+
+     S: Original-Recipient: rfc822; user2@example1.com
+     S: Final-Recipient: rfc822; user4@example3.com
+     S: Action: delivered
+     S: Status: 2.5.0
+     S:
+     S: --%%%%--
+     S: .
+
+     Example #12 Firewall, Hiding System Names Behind the Firewall:
+     C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK
+     S: +OK+ Tracking information follows
+     S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status
+     S:
      S: --%%%%
      S: Content-Type: message/tracking-status
      S:
@@ -488,6 +586,20 @@ Internet Draft      Message Tracking Query Protocol         July 1, 2001
      S:
      S: Original-Recipient: rfc822; user1@example1.com
      S: Final-Recipient: rfc822; user1@example1.com
+     S: Action: relayed
+     S: Status: 2.1.9
+     S: Remote-MTA: dns; example2.com
+     S: Last-Attempt-Date: Mon,  1 Jan 2001 19:15:03 -0500
+     S:
+     S: --%%%%
+     S: Content-Type: message/tracking-status
+     S:
+     S: Original-Envelope-Id: 12345-20010101@example.com
+     S: Reporting-MTA: dns; example2.com
+     S: Arrival-Date: Mon,  1 Jan 2001 15:15:15 -0500
+     S:
+     S: Original-Recipient: rfc822; user2@example1.com
+     S: Final-Recipient: rfc822; user4@example1.com
      S: Action: delivered
      S: Status: 2.5.0
      S:
@@ -503,9 +615,9 @@ Internet Draft      Message Tracking Query Protocol         July 1, 2001
 
 
 
-Hansen                                                          [Page 9]
+Hansen                                                         [Page 11]
 
-Internet Draft      Message Tracking Query Protocol         July 1, 2001
+Internet Draft      Message Tracking Query Protocol    November 20, 2001
 
 
      When the client issues the COMMENT command, the MTQP server MUST
@@ -526,17 +638,20 @@ server MAY support TLS.  If an MTQP server supports TLS, it MUST include
 following response codes:
      "/" "unsupported"
      "/" "unavailable"
+     "/" "tlsinprogress"
 
-     If a TLS session is already in progress, then it is a protocol
-error and "-BAD" MUST be returned with a response code of "/tlsinpro-
-gress".
+     If TLS is not suported, then a response code of "/unsupported"
+SHOULD be used.  If TLS is not available for some other reason, then a
+reponse code of "/unavailable" SHOULD be used.  If a TLS session is
+already in progress, then it is a protocol error and "-BAD" MUST be
+returned with a response code of "/tlsinprogress".
 
      After receiving a positive response to a STARTTLS command, the
 client MUST start the TLS negotiation before giving any other MTQP com-
 mands.
 
-     If the MTQP client is using pipelining, the STARTTLS command must
-be the last command in a group.
+     If the MTQP client is using pipelining (see below), the STARTTLS
+command must be the last command in a group.
 
 6.1.  Processing After the STARTTLS Command
 
@@ -553,17 +668,17 @@ achieved.
 
      If the MTQP client decides that the level of authentication or
 privacy is not high enough for it to continue, it SHOULD issue an MTQP
-QUIT command immediately after the TLS negotiation is complete.  If the
-MTQP server decides that the level of authentication or privacy is not
-high enough for it to continue, it SHOULD reply to every MTQP command
 
 
 
-Hansen                                                         [Page 10]
+Hansen                                                         [Page 12]
 
-Internet Draft      Message Tracking Query Protocol         July 1, 2001
+Internet Draft      Message Tracking Query Protocol    November 20, 2001
 
 
+QUIT command immediately after the TLS negotiation is complete.  If the
+MTQP server decides that the level of authentication or privacy is not
+high enough for it to continue, it SHOULD reply to every MTQP command
 from the client (other than a QUIT command) with a negative "-ERR"
 response and a response code of "/insecure".
 
@@ -595,8 +710,9 @@ sion is already active.
 
      When the client issues the QUIT command, the MTQP session ter-
 minates.  The QUIT command has no parameters.  The server MUST respond
-with a successful response.  The client may close the session from its
-end immediately after issuing this command.
+with a successful response.  The client MAY close the session from its
+end immediately after issuing this command (if the client is on an
+operating system where this does not cause problems).
 
 8.  Pipelining
 
@@ -609,17 +725,16 @@ example, STARTTLS must be the last command in a batch of MTQP commands.
 
      The following two examples are identical:
 
-     Example #11 :
-     C: TRACK <tracking-id> YWJjZGVmZ2gK
-     S: +OK+ Tracking information follows
-
 
 
-Hansen                                                         [Page 11]
+Hansen                                                         [Page 13]
 
-Internet Draft      Message Tracking Query Protocol         July 1, 2001
+Internet Draft      Message Tracking Query Protocol    November 20, 2001
 
 
+     Example #13 :
+     C: TRACK <tracking-id> YWJjZGVmZ2gK
+     S: +OK+ Tracking information follows
      S:
      S: ... tracking details #1 go here ...
      S: .
@@ -629,7 +744,7 @@ Internet Draft      Message Tracking Query Protocol         July 1, 2001
      S: ... tracking details #2 go here ...
      S: .
 
-     Example #12 :
+     Example #14 :
      C: TRACK <tracking-id> YWJjZGVmZ2gK
      C: TRACK <tracking-id-2> QUJDREVGR0gK
      S: +OK+ Tracking information follows
@@ -653,28 +768,32 @@ following forms:
      The first form is used to refer to an MTQP server on the standard
 port, while the second form specifies a non-standard port.  Both of
 these forms specify that the TRACK command is to be issued using the
-given tracking id and authorization cookie.  The path element "/track/"
-is case insensitive, but the envid and mtrk-secret may not be.
+given tracking id (envid) and authorization secret (mtrk-secret).  The
+path element "/track/" is case insensitive, but the envid and mtrk-
+secret may not be.
 
 9.1.  MTQP URL Syntax
 
      This is an ABNF description of the MTQP URL.
 
-     mtqp-url = "mtqp://" net_loc "/track/" envid ":" mtrk-secret
+     mtqp-url = "mtqp://" net_loc "/track/" envid "/" mtrk-secret
 
-10.  IANA Considerations
 
-     System port number XXXX - TBA by IANA
 
-     The service name to be registered with the Internet Assigned Number
-Authority (IANA) is "MTQP".
 
 
 
-Hansen                                                         [Page 12]
+Hansen                                                         [Page 14]
 
-Internet Draft      Message Tracking Query Protocol         July 1, 2001
+Internet Draft      Message Tracking Query Protocol    November 20, 2001
+
+
+10.  IANA Considerations
 
+     System port number XXXX - TBD by IANA
+
+     The service name to be registered with the Internet Assigned Number
+Authority (IANA) is "MTQP".
 
      This document requests that IANA maintain one new registry: MTQP
 options.  The registry's purpose is to register options to this proto-
@@ -689,14 +808,17 @@ MUST include the following information as part of their definition:
      specification reference
      discussion
 
-     Additional vendor-specific options for this protocol whose names
-begin with "vnd."  MUST be registered with IANA on a Firt Come First
-Served basis.  It is expected that after the "vnd." would appear an
-abbreviated form of the vendor's name that is registering the option,
-followed by a second dot "." and a name for the option itself.  For
-example, "vnd.example.extinfo" might represent a vendor-specific exten-
-sion providing extended information being registered by the "Example,
-Inc." company.
+     One MTQP option is defined in this document:
+     option identifier: STARTTLS option parameters: none added commands:
+     STARTTLS standard commands affected: none specification reference:
+     RFC TBD discussion: see RFC TBD
+
+     Additional vendor-specific options for this protocol have names
+that begin with "vnd.".  After the "vnd." would appear the reversed
+domain name of the vendor, another dot ".", and a name for the option
+itself.  For example, "vnd.com.example.extinfo" might represent a
+vendor-specific extension providing extended information by the owner of
+the "example.com" domain.  These names MAY be registered with IANA.
 
 11.  Security Considerations
 
@@ -714,25 +836,26 @@ this level of exposure is too much, TLS may be used to reduce the expo-
 sure further.
 
      It should be noted that message tracking is not an end-to-end
+
+
+
+Hansen                                                         [Page 15]
+
+Internet Draft      Message Tracking Query Protocol    November 20, 2001
+
+
 mechanism.  Thus, if an MTQP client/server pair decide to use TLS
 privacy, they are not securing tracking queries with any prior or suc-
 cessive MTQP servers.
 
-     Both the STMP client and server must check the result of the TLS
+     Both the MTQP client and server must check the result of the TLS
 negotiation to see whether acceptable authentication or privacy was
 achieved.  Ignoring this step completely invalidates using TLS for secu-
 rity.  The decision about whether acceptable authentication or privacy
-was achieved is made locally, is implementation-dependant, and is beyond
+was achieved is made locally, is implementation-dependent, and is beyond
 the scope of this document.
 
-
-
-Hansen                                                         [Page 13]
-
-Internet Draft      Message Tracking Query Protocol         July 1, 2001
-
-
-     The SMTP client and server should note carefully the result of the
+     The MTQP client and server should note carefully the result of the
 TLS negotiation.  If the negotiation results in no privacy, or if it
 results in privacy using algorithms or key lengths that are deemed not
 strong enough, or if the authentication is not good enough for either
@@ -769,6 +892,14 @@ per user.
 12.  Protocol Syntax
 
      This is a collected ABNF description of the MTQP protocol.
+
+
+
+Hansen                                                         [Page 16]
+
+Internet Draft      Message Tracking Query Protocol    November 20, 2001
+
+
      conversation = command-response *( client-command command-response )
 
      # client side
@@ -780,14 +911,6 @@ per user.
 
      starttls-command = "STARTTLS" CRLF
 
-
-
-
-Hansen                                                         [Page 14]
-
-Internet Draft      Message Tracking Query Protocol         July 1, 2001
-
-
      quit-command = "QUIT" CRLF
 
      comment-command = "COMMENT" opt-text CRLF
@@ -815,64 +938,44 @@ Internet Draft      Message Tracking Query Protocol         July 1, 2001
 
      option-list = *option-line
 
-     option-line = identifier opt-text *[CRLF WSP opt-text] CRLF
-
-     identifier = (ALPHA / "_") *(ALPHA / DIGIT / "-" / "_")
+     option-line = identifier opt-text *(CRLF WSP opt-text) CRLF
 
-     response-info = *( "/" 1*(ALPHA / DIGIT / "-" / "_")
+     NAMECHAR = ALPHA / DIGIT / "-" / "_"
 
+     identifier = (ALPHA / "_") *NAMECHAR)
 
-13.  Acknowledgements
+     response-info = *( "/" ( "admin" / "unavailable" / "unsupported" /
+             "tlsinprogress" / "insecure" / 1*NAMECHAR ) )
 
-     The description of STARTTLS is based on [RFC-SMTP-TLS].
 
-14.  References
 
-     [NIST-SHA1] NIST FIPS  PUB  180-1, "Secure  Hash  Standard",
-National Institute of Standards and Technology, U.S. Department of Com-
-merce, May 1994.
 
-     [MIME] RFC 2045, N. Freed & N. Borenstein, "Multipurpose Internet
-Mail Extensions (MIME) Part One: Format of Internet Message Bodies",
-Innosoft, First Virtual, November 1996.
 
+Hansen                                                         [Page 17]
+
+Internet Draft      Message Tracking Query Protocol    November 20, 2001
 
 
+13.  Acknowledgements
 
-Hansen                                                         [Page 15]
-
-Internet Draft      Message Tracking Query Protocol         July 1, 2001
+     The description of STARTTLS is based on [RFC-SMTP-TLS].
 
+14.  References
 
-     [RFC-821] STD 10, RFC 821, J. Postel, "Simple Mail Transfer Proto-
-col", University of Southern California / Information Sciences Insti-
-tute, August 1982.
+     [RFC-SHA1] RFC TBD, D. Eastlake & P. Jones, "US Secure Hash Stan-
+dard 1 (SHA1)", TBD 2001.
 
-     [RFC-822] STD 11, RFC 822, D. Crocker, "Standard for the Format of
-ARPA Internet Text Messages", University of Delaware, August 1982.
+     [RFC-MIME] RFC 2045, N. Freed & N. Borenstein, "Multipurpose Inter-
+net Mail Extensions (MIME) Part One: Format of Internet Message Bodies",
+Innosoft, First Virtual, November 1996.
 
      [RFC-ABNF] RFC 2234, D. Crocker, Editor, and P. Overell, "Augmented
 BNF for Syntax Specifications: ABNF", Internet Mail Consortium, Demon
 Internet Ltd., November 1997.
 
-     [RFC-DNS] RFC 974, "Mail routing and the domain system", C. Par-
-tridge, January 1986.
-
-     [RFC-ESMTP] RFC 1651, J. Klensin, N. Freed, M. Rose, E. Stefferud,
-and D. Crocker, "SMTP Service Extensions", MCI, Innosoft, Dover Beach
-Consulting, Inc., network Management Associates, Inc., Silicon Graphics,
-Inc., July 1994.
-
-     [RFC-HOSTS] "Requirements for Internet Hosts - Application and Sup-
-port", R. Braden, Ed., October 1989.
-
      [RFC-KEYWORDS] RFC 2119, S. Bradner, "Key words for use in RFCs to
 Indicate Requirement Levels", Harvard University, March 1997.
 
-     [RFC-MD5] RFC 1321, R. Rivest, "The MD5 Message-Digest Algorithm",
-MIT Laboratory for Computer Science and RSA Data Security, Inc., April
-1992.
-
      [RFC-SMTPEXT] RFC 2554, J. Myers, "SMTP Service Extension for
 Authentication", Netscape Communications, March 1999.
 
@@ -885,22 +988,13 @@ Internet Software Consortium, Microsoft Corp., February 2000
 
      [DRAFT-TRACK-ESMTP] draft-ietf-msgtrk-smtpext-*.txt, E. Allman, T.
 Hansen, "SMTP Service Extension for Message Tracking", Sendmail, Inc.,
-AT&T Laboratories, TBD 2000.
+AT&T Laboratories, TBD 2001.
 
-     [DRAFT-TRACK-MODEL] draft-ietf-msgtrk-model-03.txt, T. Hansen,
-"Message Tracking Models and Requirements", AT&T Laboratories, November
-2000.
+     [DRAFT-TRACK-MODEL] draft-ietf-msgtrk-model-*.txt, T. Hansen, "Mes-
+sage Tracking Models and Requirements", AT&T Laboratories, TBD 2001.
 
      [DRAFT-TRACK-TSN] draft-ietf-msgtrk-trkstat-*.txt, E. Allman, "The
-
-
-
-Hansen                                                         [Page 16]
-
-Internet Draft      Message Tracking Query Protocol         July 1, 2001
-
-
-Message/Tracking-Status MIME Extension", Sendmail, Inc., TBD 2000.
+Message/Tracking-Status MIME Extension", Sendmail, Inc., TBD 2001.
 
      [RFC-URI] RFC 2396, T. Berners-Lee, R. Fielding, L. Masinter, "Uni-
 form Resource Identifiers (URI): Generic Syntax", MIT/LCS, U. C. Irvine,
@@ -910,6 +1004,14 @@ Xerox Corporation, August 1998.
 
      Tony Hansen
      AT&T Laboratories
+
+
+
+Hansen                                                         [Page 18]
+
+Internet Draft      Message Tracking Query Protocol    November 20, 2001
+
+
      Lincroft, NJ 07738
      USA
 
@@ -922,12 +1024,12 @@ Xerox Corporation, August 1998.
 
      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 implmentation may be prepared, copied, published and dis-
+assist in its implementation may be prepared, copied, published and dis-
 tributed, 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 organisations,
+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 Stan-
 dards process must be followed, or as required to translate it into
@@ -943,7 +1045,7 @@ 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.
 
-     This document expires January 1, 2002.
+     This document expires May 20, 2002.
 
 
 
@@ -951,4 +1053,14 @@ FITNESS FOR A PARTICULAR PURPOSE.
 
 
 
-Hansen                                                         [Page 17]
+
+
+
+
+
+
+
+
+
+
+Hansen                                                         [Page 19]
diff --git a/Documentation/en/I-D/draft-ietf-vpim-cc-04.txt b/Documentation/en/I-D/draft-ietf-vpim-cc-04.txt
index 0a5be272..8131443a 100644
--- a/Documentation/en/I-D/draft-ietf-vpim-cc-04.txt
+++ b/Documentation/en/I-D/draft-ietf-vpim-cc-04.txt
@@ -803,7 +803,7 @@ Burger                     Expires 9/30/01                  [Page 14]
 16. Acknowledgments 
     
    Emily Candell of Comverse Network Systems was instrumental in 
-   helping work out the base issues in the û00 draft in Adelaide. 
+   helping work out the base issues in the “00 draft in Adelaide. 
     
    Ned Freed pointed out that this mechanism was about criticality, not 
    notification.  That insight made the concept and descriptions 
diff --git a/Documentation/en/I-D/draft-ietf-vpim-hint-07.txt b/Documentation/en/I-D/draft-ietf-vpim-hint-07.txt
index 9b6ea071..707e4333 100644
--- a/Documentation/en/I-D/draft-ietf-vpim-hint-07.txt
+++ b/Documentation/en/I-D/draft-ietf-vpim-hint-07.txt
@@ -334,7 +334,7 @@ Burger et. al.             Expires 12/05/01                   [Page 5]
    convey information that is critical for presentation of the message.  
    One can conceive of goofy situations, such as a message marked 
    "voice-message" but without an audio body part.  In this case, the 
-   fact that the contents of a message donÆt match its context does not 
+   fact that the contents of a message donËt match its context does not 
    mean the receiving system should generate an error report or fail to 
    deliver or process the message.  
     
diff --git a/Documentation/en/I-D/draft-khanna-smtp-mail-transfer-reliability-01.txt b/Documentation/en/I-D/draft-khanna-smtp-mail-transfer-reliability-01.txt
index 123bea1d..0c1a4091 100644
--- a/Documentation/en/I-D/draft-khanna-smtp-mail-transfer-reliability-01.txt
+++ b/Documentation/en/I-D/draft-khanna-smtp-mail-transfer-reliability-01.txt
@@ -1,19 +1,19 @@
-

-This Internet-Draft has been deleted. Unrevised documents placed in the

-Internet-Drafts directories have a maximum life of six months. After

-that time, they are deleted. This Internet-Draft was not published as

-an RFC.

-

-Internet-Drafts are not an archival document series, and expired

-drafts, such as this one, are not available; please do not ask for

-copies... they are not available. The Secretariat does not have

-information as to future plans of the authors or working groups WRT the

-deleted Internet-Draft.

-

-For more information or a copy of the document, contact the author directly.

-

-Draft Author(s):

-

-K. Khanna: gauravkhanna@mailandnews.com                                            

-

-

+
+This Internet-Draft has been deleted. Unrevised documents placed in the
+Internet-Drafts directories have a maximum life of six months. After
+that time, they are deleted. This Internet-Draft was not published as
+an RFC.
+
+Internet-Drafts are not an archival document series, and expired
+drafts, such as this one, are not available; please do not ask for
+copies... they are not available. The Secretariat does not have
+information as to future plans of the authors or working groups WRT the
+deleted Internet-Draft.
+
+For more information or a copy of the document, contact the author directly.
+
+Draft Author(s):
+
+K. Khanna: gauravkhanna@mailandnews.com                                            
+
+
diff --git a/Documentation/en/I-D/draft-motonori-ipv6-smtp-requirement-01.txt b/Documentation/en/I-D/draft-motonori-ipv6-smtp-requirement-01.txt
index 92e7aad6..acda401d 100644
--- a/Documentation/en/I-D/draft-motonori-ipv6-smtp-requirement-01.txt
+++ b/Documentation/en/I-D/draft-motonori-ipv6-smtp-requirement-01.txt
@@ -1,20 +1,20 @@
-

-This Internet-Draft has been deleted. Unrevised documents placed in the

-Internet-Drafts directories have a maximum life of six months. After

-that time, they are deleted. This Internet-Draft was not published as

-an RFC.

-

-Internet-Drafts are not an archival document series, and expired

-drafts, such as this one, are not available; please do not ask for

-copies... they are not available. The Secretariat does not have

-information as to future plans of the authors or working groups WRT the

-deleted Internet-Draft.

-

-For more information or a copy of the document, contact the author directly.

-

-Draft Author(s):

-

-M. Nakamura: motonori@econ.kyoto-u.ac.jp                                             

-J. Hagino: itojun@jilab.net                                                        

-

-

+
+This Internet-Draft has been deleted. Unrevised documents placed in the
+Internet-Drafts directories have a maximum life of six months. After
+that time, they are deleted. This Internet-Draft was not published as
+an RFC.
+
+Internet-Drafts are not an archival document series, and expired
+drafts, such as this one, are not available; please do not ask for
+copies... they are not available. The Secretariat does not have
+information as to future plans of the authors or working groups WRT the
+deleted Internet-Draft.
+
+For more information or a copy of the document, contact the author directly.
+
+Draft Author(s):
+
+M. Nakamura: motonori@econ.kyoto-u.ac.jp                                             
+J. Hagino: itojun@jilab.net                                                        
+
+
diff --git a/Documentation/en/I-D/draft-palme-e-mail-translation-03.txt b/Documentation/en/I-D/draft-palme-e-mail-translation-03.txt
index 2cc38fc0..fa4ee0c2 100644
--- a/Documentation/en/I-D/draft-palme-e-mail-translation-03.txt
+++ b/Documentation/en/I-D/draft-palme-e-mail-translation-03.txt
@@ -1,19 +1,19 @@
-

-This Internet-Draft has been deleted. Unrevised documents placed in the

-Internet-Drafts directories have a maximum life of six months. After

-that time, they are deleted. This Internet-Draft was not published as

-an RFC.

-

-Internet-Drafts are not an archival document series, and expired

-drafts, such as this one, are not available; please do not ask for

-copies... they are not available. The Secretariat does not have

-information as to future plans of the authors or working groups WRT the

-deleted Internet-Draft.

-

-For more information or a copy of the document, contact the author directly.

-

-Draft Author(s):

-

-J. Palme: jpalme@dsv.su.se                                                        

-

-

+
+This Internet-Draft has been deleted. Unrevised documents placed in the
+Internet-Drafts directories have a maximum life of six months. After
+that time, they are deleted. This Internet-Draft was not published as
+an RFC.
+
+Internet-Drafts are not an archival document series, and expired
+drafts, such as this one, are not available; please do not ask for
+copies... they are not available. The Secretariat does not have
+information as to future plans of the authors or working groups WRT the
+deleted Internet-Draft.
+
+For more information or a copy of the document, contact the author directly.
+
+Draft Author(s):
+
+J. Palme: jpalme@dsv.su.se                                                        
+
+
diff --git a/Documentation/en/I-D/draft-palme-mailext-headers-06.txt b/Documentation/en/I-D/draft-palme-mailext-headers-06.txt
index 05d1392a..d8862390 100644
--- a/Documentation/en/I-D/draft-palme-mailext-headers-06.txt
+++ b/Documentation/en/I-D/draft-palme-mailext-headers-06.txt
@@ -1411,11 +1411,11 @@ archives.                     Yes
                            4. Acknowledgments
 
 Harald Tveit Alvestrand, Neil Carpenter, William C.
-Carpenter, Rob Chandhok, Ned Freed, Olle J„rnefors, Jukka
+Carpenter, Rob Chandhok, Ned Freed, Olle Järnefors, Jukka
 Korpela, Usi Paz, Martin Platt, Keith Moore, Robert A.
 Rosenberg, Mark Symons, Nick Smith Michael C. Tiernan and
 several other people have helped me with compiling this
-list. I especially thank Ned Freed and Olle J„rnefors for
+list. I especially thank Ned Freed and Olle Järnefors for
 their thorough review and many helpful suggestions for
 improvements. I alone take responsibility for any errors
 which may still be in the list.
diff --git a/Documentation/en/I-D/index.html b/Documentation/en/I-D/index.html
index bc0efc40..2fd49a4f 100644
--- a/Documentation/en/I-D/index.html
+++ b/Documentation/en/I-D/index.html
@@ -58,10 +58,19 @@
    <A HREF="draft-ietf-drums-smtpupd-13.txt">
    draft-ietf-drums-smtpupd-13.txt
    </A>
-	A new Request for Comments is now available in online RFC libraries.

+	A new Request for Comments is now available in online RFC libraries.
    <A HREF="../rfc/rfc2821.txt">RFC2821</A>
 
 
+   <LI>
+   <A HREF="draft-ietf-drums-smtpupd-09.txt">
+   draft-ietf-drums-smtpupd-09.txt
+   </A>
+	December 29, 1998
+	                  Simple Mail Transfer Protocol 
+	                 draft-ietf-drums-smtpupd-09.txt
+
+
 </UL><LI> E (e eplf esmtp)
 <UL>   <LI>
    <A HREF="draft-palme-e-mail-translation-03.txt">
@@ -85,14 +94,6 @@
 
 
    <LI>
-   <A HREF="draft-vaudreuil-esmtp-binary2-03.txt">
-   draft-vaudreuil-esmtp-binary2-03.txt
-   </A>
-	A new Request for Comments is now available in online RFC libraries.

-   <A HREF="../rfc/rfc3030.txt">RFC3030</A>
-
-
-   <LI>
    <A HREF="draft-melnikov-esmtp-lang-00.txt">
    draft-melnikov-esmtp-lang-00.txt
    </A>
@@ -107,18 +108,24 @@
 	This Internet-Draft has been deleted.
 
 
+   <LI>
+   <A HREF="draft-vaudreuil-esmtp-binary2-03.txt">
+   draft-vaudreuil-esmtp-binary2-03.txt
+   </A>
+	A new Request for Comments is now available in online RFC libraries.

+   <A HREF="../rfc/rfc3030.txt">RFC3030</A>
+
+
 </UL><LI> F (fax)
 <UL>   <LI>
-   <A HREF="draft-ietf-fax-smtp-session-04.txt">
-   draft-ietf-fax-smtp-session-04.txt
+   <A HREF="draft-ietf-fax-esmtp-conneg-01.txt">
+   draft-ietf-fax-esmtp-conneg-01.txt
    </A>
-	Applications Area                                             Neil Joffe
-	Internet Draft                                                  Dan Wing
-	August 7, 1998                                             Cisco Systems
-	                                                       Xerox Corporation
-	                       SMTP Service Extension for
-	                           Immediate Delivery
-	                   draft-ietf-fax-smtp-session-04.txt
+	Internet Draft                       D. Crocker, Brandenburg
+	  draft-ietf-fax-esmtp-conneg-01.txt           November 2001
+	Expires: May 2002
+	                   SMTP Service Extension
+	           for Content Negotiation of Internet Fax
 
 
    <LI>
@@ -129,29 +136,31 @@
 
 
    <LI>
-   <A HREF="draft-ietf-fax-esmtp-conneg-00.txt">
-   draft-ietf-fax-esmtp-conneg-00.txt
+   <A HREF="draft-ietf-fax-smtp-session-04.txt">
+   draft-ietf-fax-smtp-session-04.txt
    </A>
-	Internet Draft                       D. Crocker, Brandenburg
-	  draft-ietf-fax-esmtp-conneg-00.txt               June 2001
-	Expires: <12/01>
-	                   SMTP Service Extension
-	           for Content Negotiation of Internet Fax
+	Applications Area                                             Neil Joffe
+	Internet Draft                                                  Dan Wing
+	August 7, 1998                                             Cisco Systems
+	                                                       Xerox Corporation
+	                       SMTP Service Extension for
+	                           Immediate Delivery
+	                   draft-ietf-fax-smtp-session-04.txt
 
 
 </UL><LI> H (hcmssc)
 <UL>   <LI>
-   <A HREF="draft-bernstein-hcmssc-06.txt">
-   draft-bernstein-hcmssc-06.txt
+   <A HREF="draft-bernstein-hcmssc-02.txt">
+   draft-bernstein-hcmssc-02.txt
    </A>
-	This Internet-Draft has been deleted.
+	The Hash Convention For Mail System Status Codes (HCMSSC)
 
 
    <LI>
-   <A HREF="draft-bernstein-hcmssc-02.txt">
-   draft-bernstein-hcmssc-02.txt
+   <A HREF="draft-bernstein-hcmssc-06.txt">
+   draft-bernstein-hcmssc-06.txt
    </A>
-	The Hash Convention For Mail System Status Codes (HCMSSC)
+	This Internet-Draft has been deleted.
 
 
 </UL><LI> I (impp int ipngwg ipv6)
@@ -274,25 +283,6 @@
 
 
    <LI>
-   <A HREF="draft-ietf-msgtrk-mtqp-03.txt">
-   draft-ietf-msgtrk-mtqp-03.txt
-   </A>
-	Internet Draft                                                 T. Hansen
-	draft-ietf-msgtrk-mtqp-03.txt                          AT&T Laboratories
-	Valid for six months                                        July 1, 2001
-	                    Message Tracking Query Protocol
-	                    <draft-ietf-msgtrk-mtqp-03.txt>
-	                         Authors' version: 1.7
-
-
-   <LI>
-   <A HREF="draft-ietf-msgtrk-protocol-05.txt">
-   draft-ietf-msgtrk-protocol-05.txt
-   </A>
-	This Internet-Draft has been deleted.
-
-
-   <LI>
    <A HREF="draft-ietf-msgtrk-smtpext-03.txt">
    draft-ietf-msgtrk-smtpext-03.txt
    </A>
@@ -332,6 +322,45 @@
    <A HREF="draft-ietf-msgtrk-model-04.txt">
    draft-ietf-msgtrk-model-04.txt
    </A>
+	Internet Draft                                                 T. Hansen
+	draft-ietf-msgtrk-model-04.txt                         AT&T Laboratories
+	Valid for six months                                    November 6, 2001
+	                Message Tracking Model and Requirements
+	                    <draft-ietf-msgtrk-model-04.txt>
+	                         Authors' version: 1.14
+
+
+   <LI>
+   <A HREF="draft-ietf-msgtrk-mtqp-04.txt">
+   draft-ietf-msgtrk-mtqp-04.txt
+   </A>
+	Internet Draft                                                 T. Hansen
+	draft-ietf-msgtrk-mtqp-04.txt                          AT&T Laboratories
+	Valid for six months                                   November 20, 2001
+	                    Message Tracking Query Protocol
+	                    <draft-ietf-msgtrk-mtqp-04.txt>
+	                         Authors' version: 1.10
+
+
+   <LI>
+   <A HREF="draft-ietf-msgtrk-protocol-00.txt">
+   draft-ietf-msgtrk-protocol-00.txt
+   </A>
+	Internet Draft						       E. Allman
+	draft-ietf-msgtrk-protocol-00.txt			  Sendmail, Inc.
+	Valid for six months					       T. Hansen
+							       AT&T Laboratories
+								  March	10, 2000
+				 SMTP Service Extension
+				  for Message Tracking
+			  <draft-ietf-msgtrk-protocol-00.txt>
+				 Authors' version: 1.1
+
+
+   <LI>
+   <A HREF="draft-ietf-msgtrk-protocol-05.txt">
+   draft-ietf-msgtrk-protocol-05.txt
+   </A>
 	This Internet-Draft has been deleted.
 
 
@@ -397,17 +426,17 @@
 
 </UL><LI> O (owner)
 <UL>   <LI>
-   <A HREF="draft-bernstein-owner-hack-01.txt">
-   draft-bernstein-owner-hack-01.txt
+   <A HREF="draft-bernstein-owner-hack-05.txt">
+   draft-bernstein-owner-hack-05.txt
    </A>
-	The Owner Hack
+	This Internet-Draft has been deleted.
 
 
    <LI>
-   <A HREF="draft-bernstein-owner-hack-05.txt">
-   draft-bernstein-owner-hack-05.txt
+   <A HREF="draft-bernstein-owner-hack-01.txt">
+   draft-bernstein-owner-hack-01.txt
    </A>
-	This Internet-Draft has been deleted.
+	The Owner Hack
 
 
 </UL><LI> P (palme pirp)
@@ -423,28 +452,21 @@
 
 
    <LI>
-   <A HREF="draft-bernstein-pirp-06.txt">
-   draft-bernstein-pirp-06.txt
-   </A>
-	This Internet-Draft has been deleted.
-
-
-   <LI>
    <A HREF="draft-bernstein-pirp-02.txt">
    draft-bernstein-pirp-02.txt
    </A>
 	Public Information Retrieval Protocol (PIRP)
 
 
-</UL><LI> Q (qmtp qsbmf)
-<UL>   <LI>
-   <A HREF="draft-bernstein-qmtp-05.txt">
-   draft-bernstein-qmtp-05.txt
+   <LI>
+   <A HREF="draft-bernstein-pirp-06.txt">
+   draft-bernstein-pirp-06.txt
    </A>
 	This Internet-Draft has been deleted.
 
 
-   <LI>
+</UL><LI> Q (qmtp qsbmf)
+<UL>   <LI>
    <A HREF="draft-bernstein-qmtp-01.txt">
    draft-bernstein-qmtp-01.txt
    </A>
@@ -452,10 +474,10 @@
 
 
    <LI>
-   <A HREF="draft-bernstein-qsbmf-02.txt">
-   draft-bernstein-qsbmf-02.txt
+   <A HREF="draft-bernstein-qmtp-05.txt">
+   draft-bernstein-qmtp-05.txt
    </A>
-	The qmail-send Bounce Message Format (QSBMF)
+	This Internet-Draft has been deleted.
 
 
    <LI>
@@ -465,8 +487,25 @@
 	This Internet-Draft has been deleted.
 
 
+   <LI>
+   <A HREF="draft-bernstein-qsbmf-02.txt">
+   draft-bernstein-qsbmf-02.txt
+   </A>
+	The qmail-send Bounce Message Format (QSBMF)
+
+
 </UL><LI> R (rfc2487bis)
 <UL>   <LI>
+   <A HREF="draft-hoffman-rfc2487bis-00.txt">
+   draft-hoffman-rfc2487bis-00.txt
+   </A>
+	Internet Draft                                          Paul Hoffman
+	<draft-hoffman-rfc2487bis-00.txt>           Internet Mail Consortium
+	April 15, 1999
+	            SMTP Service Extension for Secure SMTP over TLS
+
+
+   <LI>
    <A HREF="draft-hoffman-rfc2487bis-06.txt">
    draft-hoffman-rfc2487bis-06.txt
    </A>
@@ -492,21 +531,20 @@
 
 
    <LI>
-   <A HREF="draft-freed-smtp-pipe-01.txt">
-   draft-freed-smtp-pipe-01.txt
+   <A HREF="draft-hoffman-smtp-ssl-09.txt">
+   draft-hoffman-smtp-ssl-09.txt
    </A>
-	A new Request for Comments is now available in online RFC libraries.

-	        STD 60 

-   <A HREF="../rfc/rfc2920.txt">RFC2920</A>
+	Internet Draft                              Paul Hoffman
+	draft-hoffman-smtp-ssl-09.txt               Internet Mail Consortium
+	October 25, 1998
+	         SMTP Service Extension for Secure SMTP over TLS
 
 
    <LI>
-   <A HREF="draft-wing-smtp-capabilities-00.txt">
-   draft-wing-smtp-capabilities-00.txt
+   <A HREF="draft-bose-smtp-integrity-00.txt">
+   draft-bose-smtp-integrity-00.txt
    </A>
-	This Internet-Draft <draft-wing-smtp-capabilities-00.txt> 
-	has been replaced by
-	another Internet-Draft <draft-ietf-fax-smtp-capabilities-00.txt>
+	        CHECKING OF MESSAGE INTEGRITY DURING SMTP TRANSACTIONS
 
 
    <LI>
@@ -525,10 +563,19 @@
 
 
    <LI>
-   <A HREF="draft-bose-smtp-integrity-00.txt">
-   draft-bose-smtp-integrity-00.txt
+   <A HREF="draft-myers-smtp-auth-12.txt">
+   draft-myers-smtp-auth-12.txt
    </A>
-	        CHECKING OF MESSAGE INTEGRITY DURING SMTP TRANSACTIONS
+	A new Request for Comments is now available in online RFC libraries.
+   <A HREF="../rfc/rfc2554.txt">RFC2554</A>
+
+
+   <LI>
+   <A HREF="draft-hoffman-smtp-ssl-10.txt">
+   draft-hoffman-smtp-ssl-10.txt
+   </A>
+	A new Request for Comments is now available in online RFC libraries.
+   <A HREF="../rfc/rfc2487.txt">RFC2487</A>
 
 
    <LI>
@@ -540,19 +587,21 @@
 
 
    <LI>
-   <A HREF="draft-hoffman-smtp-ssl-10.txt">
-   draft-hoffman-smtp-ssl-10.txt
+   <A HREF="draft-freed-smtp-pipe-01.txt">
+   draft-freed-smtp-pipe-01.txt
    </A>
-	A new Request for Comments is now available in online RFC libraries.
-   <A HREF="../rfc/rfc2487.txt">RFC2487</A>
+	A new Request for Comments is now available in online RFC libraries.

+	        STD 60 

+   <A HREF="../rfc/rfc2920.txt">RFC2920</A>
 
 
    <LI>
-   <A HREF="draft-myers-smtp-auth-12.txt">
-   draft-myers-smtp-auth-12.txt
+   <A HREF="draft-wing-smtp-capabilities-00.txt">
+   draft-wing-smtp-capabilities-00.txt
    </A>
-	A new Request for Comments is now available in online RFC libraries.
-   <A HREF="../rfc/rfc2554.txt">RFC2554</A>
+	This Internet-Draft <draft-wing-smtp-capabilities-00.txt> 
+	has been replaced by
+	another Internet-Draft <draft-ietf-fax-smtp-capabilities-00.txt>
 
 
    <LI>
@@ -585,6 +634,21 @@
 
 
    <LI>
+   <A HREF="draft-ietf-vpim-pndn-01.txt">
+   draft-ietf-vpim-pndn-01.txt
+   </A>
+	This Internet-Draft has been deleted.
+
+
+   <LI>
+   <A HREF="draft-burger-vpim-pc-01.txt">
+   draft-burger-vpim-pc-01.txt
+   </A>
+	This document has been replaced by draft-ietf-vpim-hint-00.txt.

+	For more information or a copy of the document, contact the author directly.

+
+
+   <LI>
    <A HREF="draft-ietf-vpim-hint-07.txt">
    draft-ietf-vpim-hint-07.txt
    </A>
@@ -613,19 +677,4 @@
 	This Internet-Draft has been deleted.
 
 
-   <LI>
-   <A HREF="draft-ietf-vpim-pndn-01.txt">
-   draft-ietf-vpim-pndn-01.txt
-   </A>
-	This Internet-Draft has been deleted.
-
-
-   <LI>
-   <A HREF="draft-burger-vpim-pc-01.txt">
-   draft-burger-vpim-pc-01.txt
-   </A>
-	This document has been replaced by draft-ietf-vpim-hint-00.txt.

-	For more information or a copy of the document, contact the author directly.

-
-
 </UL></UL>