Keep the queue at the sending side
01A 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.
After successful RCPT commands and message content, the agent returns separate final results: chosen 250 for Ana and 452 for Bo. The manager retains Bo’s retry work; Ana’s positive result transfers delivery responsibility to the agent.
Source for this drawing: RFC 2033 · Read RFC section 3 ↗
New to this? Start hereA quick picture + helpful background
The envelope and the letter do different jobs.
Mail transport moves a message between servers. The message format describes its contents. Authentication adds checks; it does not make every message safe.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
Different recipients can get different final results.
- LMTP reuses ESMTP syntax with specific changes. It is for prior arrangement and configuration, not independent public-network mail exchange.
- LMTP MUST NOT use TCP port 25 and SHOULD NOT be used over wide area networks. The local inter-process channel drawn here is the RFC’s architectural example, not its only possible transport.
- The queue manager keeps retry work for temporary failures. A delivery agent can report each recipient’s outcome without taking over a retry queue for all recipients.
SMTP remains useful for store-and-forward relays that accept responsibility into their own queues. RFC 2033 is an Informational publication, not an Internet Standard. It neither adds encryption nor authenticates a sender; a local deployment still needs an appropriate security design.
Read the RFC section ↗