Visual RFC.
ALL RFCs / RFC 2033
Read the RFC ↗

RFC 2033 / START HERE

LMTP local delivery, before the details

LMTP means Local Mail Transfer Protocol.

LMTP carries a message from a queue manager to a delivery agent and returns a separate final result for each accepted recipient command. A queue manager stores pending work and arranges retries; a delivery agent handles the individual delivery.

The idea in one picture

  1. Queue manager

  2. Delivery agent

  3. Recipient results

A simplified picture of the idea; the chapters explain the actual mechanisms.

Why it exists

Ordinary SMTP gives one final result for a whole message transaction. LMTP lets a limited, configured delivery system report mixed recipient outcomes while leaving retry queues at the sending side. RFC2033 is Informational and defines these differences from ESMTP, not a replacement for public Internet SMTP.

A familiar example

Inside a mail service, one message might succeed for Ana while Bo’s mailbox is temporarily full. LMTP lets the queue manager retain Bo’s pending work without treating Ana as failed too. It must not use TCP port25, does not add encryption or sender authentication, and does not promise exactly-once delivery.

Helpful background

You can start here without reading another RFC. If these ideas are unfamiliar, these short introductions may help.

What you’ll learn next

Begin with chapter one, or choose a topic.

  1. Keep the queue at the sending sideA queue manager stores pending mail and retries delivery. LMTP lets it hand mail to a delivery agent that need not maintain its own retry queue.
  2. Greet with LHLO and check the envelopeLHLO replaces the SMTP greetings. A recipient enters this transaction’s successful set only after its RCPT command receives a 2xx positive completion.
  3. Match final replies to successful RCPT commandsAfter the DATA terminator, LMTP returns one final reply per previously successful RCPT command, in that command order. Rejected recipients do not occupy a reply slot.
  4. Count replies at the end of a chunked messageIf the server supports CHUNKING, BDAT sends counted content chunks. A LAST parameter identifies the final chunk; that command gets per-recipient results.
  5. Keep received results when the connection closesProcess recipient results as they arrive. A connection closing partway through does not erase the replies already received.
Start with chapter one →

This introduction explains RFC 2033 (1996). Read the original RFC ↗