RFC 2033 (rfc2033) - Page 2 of 7


Local Mail Transfer Protocol



Alternative Format: Original Text Document



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