LMTP: Local Mail Transfer Protocol
A variant of SMTP for handing mail to a delivery system that keeps no queue, with one reply per recipient.
Myers, J., "Local Mail Transfer Protocol", RFC 2033, DOI 10.17487/RFC2033, October 1996, <https://www.rfc-editor.org/info/rfc2033>.
@misc{rfc2033,
series = {Request for Comments},
number = 2033,
howpublished = {RFC 2033},
publisher = {RFC Editor},
doi = {10.17487/RFC2033},
url = {https://www.rfc-editor.org/info/rfc2033},
author = {J. Myers},
title = {{Local Mail Transfer Protocol}},
pagetotal = 7,
year = 1996,
month = oct,
} RFC text
Contents
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
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
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.
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
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.
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.
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
AI ELI5
On this page
§1Why SMTP Forces a Queue
In SMTP a single mail transaction can name several recipients, but the final . of the DATA command gets only one reply code for the whole transaction. If delivery to the first recipient works and delivery to the second hits a temporary failure, there is no way to tell the client. The server has to queue the message and try the second recipient again later.
That is useful for store-and-forward relaying between hosts, which is what SMTP was designed for. In some limited situations, outside mail exchange between independent hosts on public networks, it is better for the server not to manage a queue and for the client to do that work instead.
If you hand a helper two letters and they can only answer yes or no for both, they must keep the one they could not deliver. LMTP lets them answer separately for each letter.
§2Where LMTP Fits in a Mail System
The RFC describes a hypothetical host with three subsystems. A queue manager speaks ordinary SMTP on TCP port 25 and keeps the mail queue in persistent storage. Two delivery agents handle addresses in the host's own domains: one is a gateway to another mail system, the other delivers into a persistent mail spool.
Using SMTP over a local inter-process channel to reach the delivery agents would make each agent manage its own queue. The common alternative, starting an agent with the addresses as command-line arguments and reading one exit code, has three problems: one exit code applies to all recipients, it is hard to extend for ESMTP features such as DSN and ENHANCEDSTATUSCODES, and exits caused by system libraries on temporary conditions are often read as permanent errors.
LMTP is used on the connections from the queue manager to the delivery agents. It is not useful toward the queue manager, because the queue manager has a queue and can take responsibility for later delivery.
A big post office sorts and holds mail. The little desks that put letters into boxes do not want to hold anything, so they just say 'done' or 'not now' for each letter.
§3LHLO and the Changed Commands
LMTP is identical to SMTP and its service extensions except as this document changes it. The HELO and EHLO commands are replaced by LHLO, which has the same semantics as EHLO. Using a different command lets a misconfiguration be detected when the two sides are not speaking the same protocol.
An LMTP server MUST NOT return a Positive Completion reply to HELO or EHLO; the 500 reply code is recommended. A Positive Completion reply is one whose first digit is 2, and a successful RCPT is one that returns such a reply.
LMTP uses a different secret hello word, so if someone says the wrong hello, both sides notice they are talking to the wrong kind of friend.
§4One Reply per Recipient
If no RCPT command succeeded in the transaction, DATA MUST fail with a 503 reply. Otherwise, after the final . the server returns one reply for each earlier successful RCPT, in the order the commands were issued, even when the same forward-path was given more than once. A multiline reply counts as a single reply.
A Positive Completion reply means the server accepts responsibility for delivering or relaying the message to that recipient, and it MUST NOT lose the message for frivolous reasons such as a later host crash or a predictable resource shortage.
If the server supports the CHUNKING extension, a BDAT command with the LAST parameter behaves the same way, returning zero replies if there were no successful RCPT commands. BDAT without LAST still returns exactly one reply.
After the letter is handed over, the helper answers once for each person on the list, in the same order, saying 'delivered' or 'try again later'.
- LHLO foo.edu
- RCPT TO pat@foo.edu
- 250 OK
- RCPT TO jones@foo.edu
- 550 No such user here
- RCPT TO green@foo.edu
- 250 OK
- DATA, then final .
- 250 OK (for pat)First reply, for the first successful RCPT.
- 452 temporarily over quota (for green)Second reply, for the second successful RCPT.
§5Implementation Requirements
LMTP MUST NOT be used on TCP service port 25. A server MUST implement the PIPELINING and ENHANCEDSTATUSCODES extensions and SHOULD implement 8BITMIME. LMTP SHOULD NOT be used over wide area networks, and a server that can quickly accept responsibility for multiple recipients and send any needed notifications SHOULD NOT implement LMTP at all. These rules limit the duplicate-message problem described in RFC 1047.
The server SHOULD send each reply as soon as possible, flushing its output buffer if the next recipient will take a while. The client SHOULD process replies as they arrive. If the connection closes after only some replies have arrived, the client MUST process those and treat the remaining recipients as temporary failures.
The RFC says it has no known security issues.
The rules say: answer quickly, keep this for short local trips, and if the line goes dead, treat the unanswered letters as 'try again later'.