Remove RFCs from the trunk, since we don't distribute them anyways. All of the removed RFCs are listed in the design-notes.html file, with the exception of NNTP (RFC977). Also add a link to the "LAN Mail Protocols" document to the design-notes.html file.

svn path=/trunk/; revision=4013

1 files changed, 0 insertions, 395 deletions

diff --git a/RFC/rfc2033.txt b/RFC/rfc2033.txt
deleted file mode 100644
index a47433e8..00000000
--- a/RFC/rfc2033.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                           J. Myers
-Request for Comments: 2033                               Carnegie Mellon
-Category: Informational                                     October 1996
-
-
-                      Local Mail Transfer Protocol
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  This memo
-   does not specify an Internet standard of any kind.  Distribution of
-   this memo is unlimited.
-
-1.  Abstract
-
-   SMTP [SMTP] [HOST-REQ] and its service extensions [ESMTP] provide a
-   mechanism for transferring mail reliably and efficiently.  The design
-   of the SMTP protocol effectively requires the server to manage a mail
-   delivery queue.
-
-   In some limited circumstances, outside the area of mail exchange
-   between independent hosts on public networks, it is desirable to
-   implement a system where a mail receiver does not manage a queue.
-   This document describes the LMTP protocol for transporting mail into
-   such systems.
-
-   Although LMTP is an alternative protocol to ESMTP, it uses (with a
-   few changes) the syntax and semantics of ESMTP.  This design permits
-   LMTP to utilize the extensions defined for ESMTP.  LMTP should be
-   used only by specific prior arrangement and configuration, and it
-   MUST NOT be used on TCP port 25.
-
-Table of Contents
-
-   1.   Abstract ................................................    1
-   2.   Conventions Used in this Document .......................    2
-   3.   Introduction and Overview ...............................    2
-   4.   The LMTP protocol .......................................    3
-   4.1. The LHLO, HELO and EHLO commands ........................    4
-   4.2. The DATA command ........................................    4
-   4.3. The BDAT command ........................................    5
-   5.   Implementation requirements .............................    6
-   6.   Acknowledgments .........................................    6
-   7.   References ..............................................    7
-   8.   Security Considerations .................................    7
-   9.   Author's Address ........................................    7
-
-
-
-
-
-Myers                        Informational                      [Page 1]
-
-RFC 2033                          LMTP                      October 1996
-
-
-2.  Conventions Used in this Document
-
-   In examples, "C:" and "S:" indicate lines sent by the client and
-   server respectively.
-
-3.  Introduction and Overview
-
-   The design of the SMTP protocol effectively requires the server to
-   manage a mail delivery queue.  This is because a single mail
-   transaction may specify multiple recipients and the final "." of the
-   DATA command may return only one reply code, to indicate the status
-   of the entire transaction.  If, for example, a server is given a
-   transaction for two recipients, delivery to the first succeeds, and
-   delivery to the second encounters a temporary failure condition,
-   there is no mechanism to inform the client of the situation.  The
-   server must queue the message and later attempt to deliver it to the
-   second recipient.
-
-   This queuing requirement is beneficial in the situation for which
-   SMTP was originally designed: store-and-forward relay of mail between
-   networked hosts.  In some limited situations, it is desirable to have
-   a server which does not manage a queue, instead relying on the client
-   to perform queue management.  As an example, consider a hypothetical
-   host with a mail system designed as follows:
-
-
-
-                    TCP port 25 +-----------------+
-         ---------------------->|                 |  #########
-                                |      Queue      |<># Mail  #
-         TCP port 25            |     Manager     |  # Queue #
-         <----------------------|                 |  #########
-                                +-----------------+
-                            Local *  ^ Local    * Local
-                              IPC *  | IPC      * IPC
-                                  *  |          *
-                                  *  |          *
-                                  *  |          *
-                                  V  |          V
-                  Non-SMTP    +----------+     +----------+
-                  Protocol    | Gateway  |     |  Local   |  #########
-              <==============>| Delivery |     | Delivery |>># Mail  #
-                              |  Agent   |     |  Agent   |  # Spool #
-                              +----------+     +----------+  #########
-
-
-   The host's mail system has three independent, communicating
-   subsystems.  The first is a queue manager, which acts as a
-
-
-
-Myers                        Informational                      [Page 2]
-
-RFC 2033                          LMTP                      October 1996
-
-
-   traditional SMTP agent, transferring messages to and from other hosts
-   over TCP and managing a mail queue in persistent storage.  The other
-   two are agents which handle delivery for addresses in domains for
-   which the host takes responsibility.  One agent performs gatewaying
-   to and from some other mail system.  The other agent delivers the
-   message into a persistent mail spool.
-
-   It would be desirable to use SMTP over a local inter-process
-   communication channel to transfer messages from the queue manager to
-   the delivery agents.  It would, however, significantly increase the
-   complexity of the delivery agents to require them to manage their own
-   mail queues.
-
-   The common practice of invoking a delivery agent with the envelope
-   address(es) as command-line arguments, then having the delivery agent
-   communicate status with an exit code has three serious problems: the
-   agent can only return one exit code to be applied to all recipients,
-   it is difficult to extend the interface to deal with ESMTP extensions
-   such as DSN [DSN] and ENHANCEDSTATUSCODES [ENHANCEDSTATUSCODES], and
-   exits performed by system libraries due to temporary conditions
-   frequently get interpreted as permanent errors.
-
-   The LMTP protocol causes the server to return, after the final "." of
-   the DATA command, one reply for each recipient.  Therefore, if the
-   queue manager is configured to use LMTP instead of SMTP when
-   transferring messages to the delivery agents, then the delivery
-   agents may attempt delivery to each recipient after the final "." and
-   individually report the status for each recipient.  Connections which
-   should use the LMTP protocol are drawn in the diagram above using
-   asterisks.
-
-   Note that it is not beneficial to use the LMTP protocol when
-   transferring messages to the queue manager, either from the network
-   or from a delivery agent.  The queue manager does implement a mail
-   queue, so it may store the message and take responsibility for later
-   delivering it.
-
-4.  The LMTP protocol
-
-   The LMTP protocol is identical to the SMTP protocol SMTP [SMTP]
-   [HOST-REQ] with its service extensions [ESMTP], except as modified by
-   this document.
-
-   A "successful" RCPT command is defined as an RCPT command which
-   returns a Positive Completion reply code.
-
-   A "Positive Completion reply code" is defined in Appendix E of STD
-   10, RFC 821 [SMTP] as a reply code which "2" as the first digit.
-
-
-
-Myers                        Informational                      [Page 3]
-
-RFC 2033                          LMTP                      October 1996
-
-
-4.1.  The LHLO, HELO and EHLO commands
-
-   The HELO and EHLO commands of ESMTP are replaced by the LHLO command.
-   This permits a misconfiguration where both parties are not using the
-   same protocol to be detected.
-
-   The LHLO command has identical semantics to the EHLO command of ESMTP
-   [ESMTP].
-
-   The HELO and EHLO commands of ESMTP are not present in LMTP.  A LMTP
-   server MUST NOT return a Postive Completion reply code to these
-   commands.  The 500 reply code is recommended.
-
-4.2.  The DATA command
-
-   In the LMTP protocol, there is one additional restriction placed on
-   the DATA command, and one change to how replies to the final "." are
-   sent.
-
-   The additional restriction is that when there have been no successful
-   RCPT commands in the mail transaction, the DATA command MUST fail
-   with a 503 reply code.
-
-   The change is that after the final ".", the server returns one reply
-   for each previously successful RCPT command in the mail transaction,
-   in the order that the RCPT commands were issued.  Even if there were
-   multiple successful RCPT commands giving the same forward-path, there
-   must be one reply for each successful RCPT command.
-
-   When one of these replies to the final "." is a Positive Completion
-   reply, the server is accepting responsibility for delivering or
-   relying the message to the corresponding recipient.  It must take
-   this responsibility seriously, i.e., it MUST NOT lose the message for
-   frivolous reasons, e.g., because the host later crashes or because of
-   a predictable resource shortage.
-
-   A multiline reply is still considered a single reply and corresponds
-   to a single RCPT command.
-
-   EXAMPLE:
-
-   S: 220 foo.edu LMTP server ready
-   C: LHLO foo.edu
-   S: 250-foo.edu
-   S: 250-PIPELINING
-   S: 250 SIZE
-   C: MAIL FROM:<chris@bar.com>
-   S: 250 OK
-
-
-
-Myers                        Informational                      [Page 4]
-
-RFC 2033                          LMTP                      October 1996
-
-
-   C: RCPT TO:<pat@foo.edu>
-   S: 250 OK
-   C: RCPT TO:<jones@foo.edu>
-   S: 550 No such user here
-   C: RCPT TO:<green@foo.edu>
-   S: 250 OK
-   C: DATA
-   S: 354 Start mail input; end with <CRLF>.<CRLF>
-   C: Blah blah blah...
-   C: ...etc. etc. etc.
-   C: .
-   S: 250 OK
-   S: 452 <green@foo.edu> is temporarily over quota
-   C: QUIT
-   S: 221 foo.edu closing connection
-
-
-NOTE: in the above example, the domain names of both the client and
-   server are identical.  This is because in the example the client and
-   server are different subsystems of the same mail domain.
-
-4.3.  The BDAT command
-
-   If the server supports the ESMTP CHUNKING extension [BINARYMIME], a
-   BDAT command containing the LAST parameter returns one reply for each
-   previously successful RCPT command in the mail transaction, in the
-   order that the RCPT commands were issued.  Even if there were
-   multiple successful RCPT commands giving the same forward-path, there
-   must be one reply for each successful RCPT command.  If there were no
-   previously successful RCPT commands in the mail transaction, then the
-   BDAT LAST command returns zero replies.
-
-   When one of these replies to the BDAT LAST command is a Positive
-   Completion reply, the server is accepting responsibility for
-   delivering or relaying the message to the corresponding recipient.
-   It must take this responsibility seriously, i.e., it MUST NOT lose
-   the message for frivolous reasons, e.g., because the host later
-   crashes or because of a predictable resource shortage.
-
-   A multiline reply is still considered a single reply and corresponds
-   to a single RCPT command.
-
-   The behavior of BDAT commands without the LAST parameter is not
-   changed; they still return exactly one reply.
-
-
-
-
-
-
-
-Myers                        Informational                      [Page 5]
-
-RFC 2033                          LMTP                      October 1996
-
-
-5.  Implementation requirements
-
-   As LMTP is a different protocol than SMTP, it MUST NOT be used on the
-   TCP service port 25.
-
-   A server implementation MUST implement the PIPELINING [PIPELINING]
-   and ENHANCEDSTATUSCODES [ENHANCEDSTATUSCODES] ESMTP extensions.  A
-   server implementation SHOULD implement the 8BITMIME [8BITMIME]
-   extension.
-
-   Use of LMTP can aggravate the situation described in [DUP-MSGS].  To
-   avoid this synchronization problem, the following requirements are
-   made of implementations:
-
-   A server implementation which is capable of quickly accepting
-   responsibility for delivering or relaying a message to multiple
-   recipients and which is capable of sending any necessary notification
-   messages SHOULD NOT implement the LMTP protocol.
-
-   The LMTP protocol SHOULD NOT be used over wide area networks.
-
-   The server SHOULD send each reply as soon as possible.  If it is
-   going to spend a nontrivial amount of time handling delivery for the
-   next recipient, it SHOULD flush any outgoing LMTP buffer, so the
-   reply may be quickly received by the client.
-
-   The client SHOULD process the replies as they come in, instead of
-   waiting for all of the replies to arrive before processing any of
-   them.  If the connection closes after replies for some, but not all,
-   recipients have arrived, the client MUST process the replies that
-   arrived and treat the rest as temporary failures.
-
-6.  Acknowledgments
-
-   This work is a refinement of the MULT extension, which was invented
-   by Jeff Michaud and was used in implementing gateways to the Mail-11
-   mail system.
-
-   Many thanks to Matt Thomas for assisting me in understanding the
-   semantics of the Mail-11 MULT extension.
-
-
-
-
-
-
-
-
-
-
-
-Myers                        Informational                      [Page 6]
-
-RFC 2033                          LMTP                      October 1996
-
-
-7.  References
-
-   [8BITMIME] Klensin, J., et. al, "SMTP Service Extension for 8bit-MIME
-       transport", RFC 1652, July 1994.
-
-   [BINARYMIME] Vaudreuil, G., "SMTP Service Extensions for Transmission
-       of Large and Binary MIME Messages", RFC 1830, August 1995.
-
-   [DSN] Moore, K., Vaudreuil, G., "An Extensible Message Format for
-       Delivery Status Notifications", RFC 1894, January 1996.
-
-   [DUP-MSGS] Partridge, C., "Duplicate messages and SMTP", RFC 1047,
-       February 1988.
-
-   [ENHANCEDSTATUSCODES] Freed, N., "SMTP Service Extension for
-       Returning Enhanced Error Codes", RFC 2034, October 1996.
-
-   [ESMTP] Rose, M., Stefferud, E., Crocker, C., Klensin, J., Freed, N.,
-       "SMTP Service Extensions", RFC 1869, November 1995.
-
-   [HOST-REQ] Braden, R., "Requirements for Internet hosts - application
-       and support", STD 3, RFC 1123 section 5, October 1989.
-
-   [PIPELINING] Freed, N., Cargille, A, "SMTP Service Extension for
-       Command Pipelining", RFC 1854, October 1995.
-
-   [SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
-       August 1982.
-
-
-   There are no known security issues with the issues in this memo.
-
-9.  Author's Address
-
-   John G. Myers
-   Carnegie-Mellon University
-   5000 Forbes Ave.
-   Pittsburgh PA, 15213-3890
-
-   EMail: jgm+@cmu.edu
-
-
-
-
-
-
-
-
-
-
-
-Myers                        Informational                      [Page 7]
-