clarification about missing LMTP_README file
- Ok, this¹ has been raised over a few times in the past, but I'm not
satisfied with the answer (referral to man page of lmtp/smtp instead
of idiot-proof narrative version like other *_README howtos).
1. Do the cached file contents still apply to current release version
2. If yes, why is it retired/not present as
3. If not, why isn't there the updated version?
- On Sun, Jul 22, 2012 at 11:01:20AM +0300, mailing list subscriber
> Ok, this¹ has been raised over a few times in the past, but I'mAs Victor pointed out in the referenced thread, the most similar
> not satisfied with the answer (referral to man page of lmtp/smtp
> instead of idiot-proof narrative version like other *_README
> 1. Do the cached file contents still apply to current release
> version of postfix?
> 2. If yes, why is it retired/not present as
> 3. If not, why isn't there the updated version?
> ¹ http://nixforums.org/about29845-lmtp_readme.html
> ² https://www.google.com/search?q=lmtp_readme
document presently supported would be MAILDROP_README. Frankly I'm
not sure that MAILDROP_README is appropriate in Postfix
documentation. Dovecot's "deliver" LDA is probably more widely
I didn't carefully pick over the retired LMTP_README, but I did see
mention of virtual_maps therein, which gives a clue as to its
vintage, pre-Postfix 2.0.
The big difference between LMTP and Courier Maildrop (or Dovecot LDA)
delivery is that LMTP is a network process, more like
ADDRESS_CLASS_README.html#relay_domain_class , whereas maildrop &
deliver are commands invoked for receipt of mail.
The way I would implement LMTP (which I have not yet done, but I am
sure I'll do eventually, for a customer if not for my own site) is as
a relay domain, with that domain listed in transport_maps:
sqlite = sqlite:$config_directory/query
relay_domains = $sqlite/relay_dom.query
transport_maps = $sqlite/transport.query
$ postmap -q example.net sqlite:/etc/postfix/query/relay_dom.query
$ postmap -q example.net sqlite:/etc/postfix/query/transport.query
$ dig +short mx example.net.rob0
And my LMTP listener on localhost would be configured to accept and
deliver mail for example.net addresses. That part would be out of
scope for Postfix, depending on the LMTP/imapd implementation.
Bottom line: I think LMTP is covered well enough in README documents
as is. If I was to suggest a new README it would be called
TRANSPORT_README, and it would cover the concept of transport(5) in
Postfix. The transport(5) manual is good, but it could be augmented
with some high-level examples and illustrations of the various knobs
available, e.g. transport_* postconf(5) settings. My idea of a
TRANSPORT_README would show transports being used for delivery of
your own mail as well as their use for external sending.
If I had time I would start on a rough draft thereof. :) Lucky for
me, I've had some work lately. (Maybe in the fall I can get to it.)
For the OP, whom I guess is considering LMTP delivery, I would
suggest concentrating on understanding address classes and the
 That said, I would hate to see MAILDROP_README go, because it
credits our late friend and list participant, Tonni Earnshaw. :)
http://rob0.nodns4.us/ -- system administration and consulting
Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
- mailing list subscriber:
> Ok, this? has been raised over a few times in the past, but I'm notAs documented the LMTP and SMTP client are part of the same program.
> satisfied with the answer (referral to man page of lmtp/smtp instead
> of idiot-proof narrative version like other *_README howtos).
The clients have identical behavior unless documented otherwise or
required by Internet RFCs.
This change was made 20051208, more than seven years ago.
smtp - Postfix SMTP+LMTP client
The Postfix SMTP+LMTP client implements the SMTP and LMTP mail delivery
protocols. It processes message delivery requests from the queue man-
Before Postfix version 2.3, the LMTP client is a separate program that
implements only a subset of the functionality available with SMTP:
there is no support for TLS, and connections are cached in-process,
making it ineffective when the client is used for multiple domains.
Most smtp_xxx configuration parameters have an lmtp_xxx "mirror" param-
eter for the equivalent LMTP feature. This document describes only
those LMTP-related parameters that aren't simply "mirror" parameters.
> The way I would implement LMTP (which I have not yet done, but I amThis is not relaying, instead this is final delivery. I would
> sure I'll do eventually, for a customer if not for my own site) is as
> a relay domain, with that domain listed in transport_maps:
therefore suggest a final delivery address class. The virtual_mailbox
class would be most natural for this.
virtual_mailbox_domains = the list domains
virtual_transport = the lmtp transport
virtual_mailbox_maps = the list of users
You aren't using the Postfix virtual(8) delivery agent. Therefore
Postfix uses virtual_mailbox_maps only to look up the recipient,
and it doesn't matter what the lookup result looks like. That makes
virtual_mailbox_maps remarkably similar to relay_recipient_maps.
transport_maps are not needed for this (they would be needed for
destinations that require local(8) or pipe(8) features).
I think that virtual_mailbox_maps needs to be documented better,
for use cases like the one shown above.