nuke old I-D

6 files changed, 0 insertions, 1918 deletions

diff --git a/Documentation/en/I-D/draft-hoffman-smtp-ssl-05.txt b/Documentation/en/I-D/draft-hoffman-smtp-ssl-05.txt
deleted file mode 100644
index 7650a69f..00000000
--- a/Documentation/en/I-D/draft-hoffman-smtp-ssl-05.txt
+++ /dev/null
@@ -1,277 +0,0 @@
-
-Internet Draft                              Paul Hoffman
-draft-hoffman-smtp-ssl-05.txt               Internet Mail Consortium
-November 15, 1997
-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), ds.internic.net (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. TLS Extension
-
-The TLS extension to SMTP is laid out as follows:
-
-(1) the name of the SMTP service defined here is TLS;
-
-(2) the EHLO keyword value associated with the extension is TLS;
-
-(3) the TLS keyword has no parameters;
-
-(4) a new SMTP verb, "STARTTLS", is defined;
-
-(5) no additional parameters are added to any SMTP command.
-
-
-4. The TLS Keyword
-
-The TLS keyword is used to tell the SMTP client that the SMTP server allows
-use of TLS. It 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:
-
-505 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 Result of 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.
-
-
-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 TLS
-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 lengthths 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 TLS"
-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.
-
-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
-
-[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 -04 to -05
-
-Extensive changes to section 5 to define what a publicly-accessed server is
-and to make clear what different types of servers can and cannot require from
-SMTP clients.
-
-Extensive changes to the last two paragraphs of section 7.
-
-
-C. Revocation of smtps Port
-
-An IANA port registration was made for an "smtps" port for use as a
-TLS-negotiated SMTP port. The email community has reached rough concensus
-that widespread use of such a port will be harmful to the performance,
-interoperability and security of SMTP. This document hereby revokes the
-IANA registration of the "smtps" port and forbids future registration of a
-port for any "secure SMTP" service. IANA is directed to replace the port
-registration with an indication that the port registration was revoked,
-including the effective date. Two years after the effective date of
-revocation, the port may be re-registered for a different purpose.
-
-
-D. 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-hoffman-smtp-ssl-06.txt b/Documentation/en/I-D/draft-hoffman-smtp-ssl-06.txt
deleted file mode 100644
index d810975f..00000000
--- a/Documentation/en/I-D/draft-hoffman-smtp-ssl-06.txt
+++ /dev/null
@@ -1,307 +0,0 @@
-
-Internet Draft                              Paul Hoffman
-draft-hoffman-smtp-ssl-06.txt               Internet Mail Consortium
-April 24, 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 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).
-
-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. TLS Extension
-
-The TLS extension to SMTP is laid out as follows:
-
-(1) the name of the SMTP service defined here is TLS;
-
-(2) the EHLO keyword value associated with the extension is TLS;
-
-(3) the TLS keyword has no parameters;
-
-(4) a new SMTP verb, "STARTTLS", is defined;
-
-(5) no additional parameters are added to any SMTP command.
-
-
-4. The TLS Keyword
-
-The TLS keyword is used to tell the SMTP client that the SMTP server allows
-use of TLS. It 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:
-
-505 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 sucessful 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 TLS
-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 lengthths 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 TLS"
-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 -04 to -05
-
-Extensive changes to section 5 to define what a publicly-accessed server is
-and to make clear what different types of servers can and cannot require from
-SMTP clients.
-
-Extensive changes to the last two paragraphs of section 7.
-
-
-C. Revocation of smtps Port
-
-An IANA port registration was made for an "smtps" port for use as a
-TLS-negotiated SMTP port. The email community has reached rough concensus
-that widespread use of such a port will be harmful to the performance,
-interoperability and security of SMTP. This document hereby revokes the
-IANA registration of the "smtps" port and forbids future registration of a
-port for any "secure SMTP" service. IANA is directed to replace the port
-registration with an indication that the port registration was revoked,
-including the effective date. Two years after the effective date of
-revocation, the port may be re-registered for a different purpose.
-
-
-D. 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-hoffman-smtp-ssl-07.txt b/Documentation/en/I-D/draft-hoffman-smtp-ssl-07.txt
deleted file mode 100644
index 363b21f9..00000000
--- a/Documentation/en/I-D/draft-hoffman-smtp-ssl-07.txt
+++ /dev/null
@@ -1,302 +0,0 @@
-
-Internet Draft                              Paul Hoffman
-draft-hoffman-smtp-ssl-07.txt               Internet Mail Consortium
-December 1, 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:
-
-505 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 -06 to -07
-
-Changed the EHLO value from "TLS" to "STARTTLS" to not conflict with
-applications that were based on earlier drafts.
-
-C. Revocation of smtps Port
-
-An IANA port registration was made for an "smtps" port for use as a
-TLS-negotiated SMTP port. The email community has reached rough consensus
-that widespread use of such a port will be harmful to the performance,
-interoperability and security of SMTP. This document hereby revokes the
-IANA registration of the "smtps" port and forbids future registration of a
-port for any "secure SMTP" service. IANA is directed to replace the port
-registration with an indication that the port registration was revoked,
-including the effective date. Two years after the effective date of
-revocation, the port may be re-registered for a different purpose.
-
-
-D. 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-hoffman-smtp-ssl-08.txt b/Documentation/en/I-D/draft-hoffman-smtp-ssl-08.txt
deleted file mode 100644
index 664fcf1a..00000000
--- a/Documentation/en/I-D/draft-hoffman-smtp-ssl-08.txt
+++ /dev/null
@@ -1,303 +0,0 @@
-
-Internet Draft                              Paul Hoffman
-draft-hoffman-smtp-ssl-08.txt               Internet Mail Consortium
-September 10, 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 -07 to -08
-
-Changed the reply code from 505 to 530. The condition is related to
-security, not syntax.
-
-C. Revocation of smtps Port
-
-An IANA port registration was made for an "smtps" port for use as a
-TLS-negotiated SMTP port. The email community has reached rough consensus
-that widespread use of such a port will be harmful to the performance,
-interoperability and security of SMTP. This document hereby revokes the
-IANA registration of the "smtps" port and forbids future registration of a
-port for any "secure SMTP" service. IANA is directed to replace the port
-registration with an indication that the port registration was revoked,
-including the effective date. Two years after the effective date of
-revocation, the port may be re-registered for a different purpose.
-
-
-D. 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-hoffman-smtp-ssl-09.txt b/Documentation/en/I-D/draft-hoffman-smtp-ssl-09.txt
deleted file mode 100644
index f9fb3be3..00000000
--- a/Documentation/en/I-D/draft-hoffman-smtp-ssl-09.txt
+++ /dev/null
@@ -1,290 +0,0 @@
-
-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-melnikov-smtp-lang-01.txt b/Documentation/en/I-D/draft-melnikov-smtp-lang-01.txt
deleted file mode 100644
index fd0bacef..00000000
--- a/Documentation/en/I-D/draft-melnikov-smtp-lang-01.txt
+++ /dev/null
@@ -1,439 +0,0 @@
-Network Working Group                            Mike Gahrns, Microsoft 
-Internet Draft                        Alexey Melnikov, Messaging Direct
-Document: draft-melnikov-smtp-lang-01.txt                  October 1999
-
-
-                          SMTP Language Extension
-
-
-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 document  suggests  a  proposed  protocol  for  the   Internet
-   community,    and   requests   discussion   and   suggestions   for
-   improvements. Distribution of this draft is unlimited.
-
-   The protocol discussed in this document is experimental and subject
-   to change.  Persons planning on either implementing or using this
-   protocol are STRONGLY URGED to get in touch with the author before
-   embarking on such a project.
-
-
-0. Meta Information on this draft 
-    
-   This information is intended to facilitate discussion.  It will be   
-   removed when this document leaves the Internet-Draft stage. 
-    
-
-   Changes since -00 
-    
-1) Corrected grammar error in LANG command description section
-
-2) Included Mark Crispin's suggestion of allowing the server to 
-   substitute a primary language if the sublanguage asked for is not
-   available.
-
-3) Added section 5 that describes extended LANG reply
-
-4) Corrected example, more examples
-
-5) Added extension mechanism
-
-6) Specified interaction with RFC-2034 ("SMTP Service Extension for Returning Enhanced)
-
-7) LANG command must always have language-tag as a parameter. Only EHLO response could
-   be used to examine list of supported languages.
-
-
-   Open issues
-
-1) Should language information be added to MAIL FROM so that it could be used
-   in DSN/MDN notification messages?
-
-
-1. Abstract
-
-   The Simple Mail Transfer Protocol [RFC-821] allows server
-   responses to include human-readable text that in many cases needs to
-   be presented to the user.  This document specifies a way for a
-   client to negotiate which language the server should use when
-   sending human-readable text.
-
-
-2. Conventions used in this document
-
-   In examples, "C:" and "S:" indicate lines sent by the client and
-   server respectively.   If such lines are wrapped without a new "C:"
-   or "S:" label, then the wrapping is for editorial clarity and is not
-   part of the command.
-
-   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 [KEYWORDS].
-
-
-3. Framework for the Language SMTP service extension
-
-   The Language SMTP  service  extension  uses the  SMTP  service  extension  
-   mechanism described in [ESMTP].  The following SMTP service extension is 
-   therefore defined:
-
-  (1) The name of the SMTP service extension is "Language".
-
-  (2) The EHLO keyword value associated with this service extension is
-      "LANGUAGE".
-
-  (3) The LANGUAGE EHLO keyword contains as a parameter a space separated
-      list of the names of supported language tags. This list is optional. 
-      If the language tag argument is omitted, this means that server is 
-      unable to enumerate the list of languages it supports.
-
-  (4) A new SMTP verb "LANG" is defined by this document.
-
-  (5) No additional SMTP parameters to either MAIL FROM or RCPT TO commands 
-      are defined by this extension.
-
-  An additional document may define an extension to LANGUAGE ESMTP extension.
-  Any such extension MUST use ESMTP extension name that starts with LANGUAGE
-  prefix. This document doesn't specify any LANG command extension.
-
-
-4. Requirements
-
-   A server that supports this extension SHOULD use the language "i-default"
-   as described in [CHARSET-POLICY] as its default language until another
-   supported language is negotiated by the client. A server MUST support
-   and include "i-default" in EHLO response.
-
-
-5. LANG Command
-
-   LANG language-tag [*extension]
-
-     Arguments:
-         language tag as defined by [RFC-1766].
-         optional extension specific parameters 
-
-     Restrictions:
-         The LANG command is permitted throughout a mail connection.
-
-     Reply Codes:
-         Success:
-            250 LANG command completed successfully
-         Error: 
-            504 Language is not supported
-            421 <domain> Service not available, closing transmission channel
-
-     Discussion:
-         The LANG command requests that human-readable text emitted by
-         the server be localized to the language specified in the language
-         tag argument.
-
-         If a sublanguage was asked for and not available but the primary
-         language is available, the server SHOULD switch to the primary language
-         and MUST use an extended LANG reply containing the identifier of the primary
-         language it switched to as described in section 5.
-
-         It is also recommended that server recognizes languages that have multiple
-         different tags (for example "ru" and "rus").
-
-         Note 1. Client MUST NOT use MUL (Multiple languages) and UND (Undetermined)
-         language tags and server MUST return BAD to the LANG command that is used
-         with such parameter.
-
-         Note 2. [RFC-1766] warns that there is no guaranteed relationship between
-         languages whose tags start out with the same series of subtags. However it
-         is believed that for the purpose of this document it is safe to treat all
-         languages, whose tags starts with primary language described in ISO 639-1
-         and ISO 639-2 (i.e. all 2 or 3 letters primary languages) as hierarchical.
-         For all languages with other primary tags described fallback rule MUST NOT
-         be used. In particular, language tags starting with 'i-' and 'x-' SHOULD NOT
-         be treated as hierarchical.
-
-         If the command succeeds, the server will return human-readable
-         responses in the specified language starting with the successful
-         250 response to the LANG command.  These responses will be in UTF-8
-         [RFC-2044]. In particular, LANG command MAY affect the result of 
-         a HELP command.
-
-         If the command fails, the server will continue to return human-
-         readable responses in the language it was previously using.
-
-
-         An additional document may define an extension to LANGUAGE ESMTP extension.
-         Any such extension MUST use ESMTP extension name that starts with LANGUAGE
-         prefix. This document doesn't specify any LANG extension.
-
-         LANG extension document may define additional parameters to LANG command.  Client
-         MUST NOT issue the optional extension parameters unless a server has indicated
-         in its EHLO response that it supports that extension. In case when server
-         doesn't support requested parameter(s) or any parameters, it MUST respond with
-         504 code.
-
-     Example 1:
-
-        < The server defaults to using responses in "i-default" language
-          until the user explicitly changes the language. >
-
-         S: 220 smtp.example.com ESMTP server ready
-         C: EHLO main.example.com
-         S: 250-smtp.example.com
-         S: 250-AUTH CRAM-MD5 DIGEST-MD5
-         S: 250 LANGUAGE EN FR RU i-default
-         C: HELP
-         S: 214-This is Sendmail version X.X.X
-         S: 214-Topics:
-         S: 214-    HELO    EHLO    MAIL    RCPT    DATA
-         S: 214-    RSET    NOOP    QUIT    HELP    VRFY
-         S: 214-    EXPN    VERB    ETRN    DSN
-         S: 214-For more info use "HELP <topic>".
-         S: 214 End of HELP info
-
-        < Once the client changes the language, all responses will be in
-          that language starting with 250 response to the LANG command. >
-
-         C: LANG FR
-         S: 250 La Language commande a ete execute avec success
-
-         C: HELP
-         S: 214-C'est le programme Sendmail version X.X.X
-         S: 214-Topics:
-         S: 214-    HELO    EHLO    MAIL    RCPT    DATA
-         S: 214-    RSET    NOOP    QUIT    HELP    VRFY
-         S: 214-    EXPN    VERB    ETRN    DSN
-         S: 214-Pour obtenir l'information supplementaire utilisez "HELP <topic>".
-         S: 214 La fin de l'information 
-
-        < If a server does not support the requested language, responses
-          will continue to be returned in the current language the server is
-          using. >
-
-         C: LANG DE
-         S: 504 Ce Language n'est pas supporte
-
-     Example 2:
-
-        < The client tries to select MUL language that couldn't be used with described
-          extension>
-
-         C: LANG MUL
-         S: 504 It is not allowed to use MUL language.
-
-     Example 3:
-
-        < The client tries to use LANG extension not supported by server>
-
-         C: LANG i-default (blah blah)
-         S: 504 LANG extension blah is not recognized.
-
-
-5. Extended LANG reply
-
-   Extended reply is the reply that contains additional information in the text
-   part. Extended reply allows to pass additional information from server to client.
-   Client may choose to ignore additional information in an extended reply. Thus client
-   that doesn't recognize an extended reply would treat it as a regular SMTP reply.
-
-     Example 4:
-
-        < The client tries to select the language, but it is unavailable.
-          However primary language is available>
-
-         C: LANG FR-ca
-         S: 250 [LANG FR]La Language commande a ete execute avec success
-
-   Client that supports LANGUAGE extension must recognize Enhanced Error Codes defined in 
-  [RFC-2034]. When server supports both LANGUAGE and ENHANCEDSTATUSCODES extensions,
-  Extended reply data MUST follow Enchanced Error Code in reply.
-
-     Example 5:
-
-        < The server supports both LANGUAGE and ENHANCEDSTATUSCODES>
-
-         S: 220 smtp.example.com ESMTP server ready
-         C: EHLO main.example.com
-         S: 250-smtp.example.com
-         S: 250 LANGUAGE EN FR RU i-default
-         S: 250 ENHANCEDSTATUSCODES
-         C: LANG FR-ca
-         S: 250 2.0.0 [LANG FR]La Language commande a ete execute avec success
-
-
-6. Formal Syntax
-
-   The following syntax specification uses the augmented Backus-Naur
-   Form (BNF) as described in [ABNF].
-
-   Except as noted otherwise, all alphabetic characters are case-
-   insensitive.  The use of upper or lower case characters to define
-   token strings is for editorial clarity only.  Implementations MUST
-   accept these strings in a case-insensitive fashion.
-
-   CR              = %x0C     ;; ASCII CR, carriage return
-
-   CRLF            = CR LF
-
-   LF              = %x0A     ;; ASCII LF, line feed
-
-   SPACE           = %x20     ;; ASCII SP, space
-
-   LANG_Command = "LANG" SPACE language_tag [*extension] CRLF
-      ; A client MUST NOT issue the optional extension parameter 
-      ; unless a server has indicated in its EHLO response that it 
-      ; supports that extension 
-
-   extension = SP "(" lang-ext-name SP lang-ext-values ")" 
-
-   lang-ext-name = text
-      ; Name of LANG extension
-
-   lang-ext-values = "(" lang-ext-value *(SP lang-ext-value)")"
-      ; List of LANG extension specific values 
-
-   lang-ext-value = text
-
-   LANGUAGE_List = "LANGUAGE" *(SPACE <language_tag>) CRLF
-      ; Note 1: the server is required to support the language i-default
-      ; and as such i-default MUST appear in the language response.
-      ; When "i-default" is used, all responses MUST contain only 
-      ; ASCII text.
-      ;
-      ; Note 2: Language tags MUL (Multiple languages) and UND (Undetermined)
-      ; MUST NOT be used.
-
-
-   language_tag =  <language_tag> as defined in [RFC-1766]
-
-   Reply-line |= Lang-Reply-line
-      ; Reply-line is defined in [SMTP-UPD]
-      ; See section 5 for definition of Lang-Reply-line
-
-   Lang-Reply-line = Reply-code [ SP ext-text ] CRLF
-      ; Reply line for LANG command
-
-   ext-text = ext-data text
-
-   ext-data = "[" ext-name SP ext-value "]"
-      ; Note 1: In the case of multiline response the same ext-data SHOULD appear
-      ; on every line.
-      ;
-      ; Note 2: In case when server also supports "SMTP Service Extension for
-      ; Returning Enhanced Error Codes" [RFC-2034], ext-data MUST follow Enhanced
-      ; Error Code. 
-
-   ext-name = "LANG"
-
-   ext-value = Primary-tag
-      ; Primary tag as defined by [RFC-1766]  
-
-
-6. Security Considerations
-
-   This extension allows the negotiation of a language for the human-
-   readable text returned by a server.  A user is able to query the
-   languages that a server supports.
-
-
-7. References
-
-   [RFC-821], Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
-   821, August 1982, <ftp://ftp.isi.edu/in-notes/rfc821.txt>
-
-   [SMTP-UPD], Klensin, J., "Simple Mail Transfer Protocol",
-   draft-ietf-drums-smtpupd-10.txt (work in progress), February 1999. 
-
-   [RFC-1766], Alvestrand, H., "Tags for the Identification of
-   Languages", RFC 1766, UNINETT, March 1995,
-   <ftp://ftp.isi.edu/in-notes/rfc1766.txt>
-
-   [CHARSET-POLICY] Alvestrand, H., "IETF Policy on Character Sets and 
-   Languages", RFC 2277, January 1998, <ftp://ftp.isi.edu/in-notes/rfc2277.txt>
-
-   [RFC-2044], Yergeau, F., "UTF-8, a transformation format of Unicode
-   and ISO 10646, RFC 2044, Alis Technologies, October 1996,
-   <ftp://ftp.isi.edu/in-notes/rfc2044.txt>
-
-   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
-   Requirement Levels", RFC 2119, March 1997,
-   <ftp://ftp.isi.edu/in-notes/rfc2119.txt>
-
-   [IMAP-LANGUAGE], Gahrns, M., "IMAP4 Language Extension", 
-   draft-gahrns-imap-language-01.txt (work in progress), Microsoft, 
-   October 1999
-
-   [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications:
-   ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd.,
-   November 1997, <ftp://ftp.isi.edu/in-notes/rfc2234.txt>
-
-   [RFC-2034] Freed, N., "SMTP Service Extension for Returning Enhanced
-   Error Codes", RFC 2034, Innosoft, October 1996
-
-8.  Acknowledgments
-
-   This document is derived from [IMAP-LANGUAGE]. Thus the work of
-   Mike Gahrns and Andrew McCown is appreciated.
-
-
-9.  Copyright
-
-   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.
-
-10. Author's Address
-
-    Mike Gahrns
-    Microsoft
-    One Microsoft Way
-    Redmond, WA, 98072
-
-    Phone: (425) 936-9833
-    Email: mikega@microsoft.com 
-
-    Alexey Melnikov
-    Messaging Direct, Inc.
-    #900, 10117 Jasper Avenue,
-    Edmonton, Alberta, T5J 1W8
-
-    Phone: (780) 424-4922 Ext 357
-    Email: mel@messagingdirect.com
-