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