LMTP in Mailman 3
RFC 2033, Local Mail Transport Protocol (LMTP) provides Mailman with a unique opportunity to provide a better user experience when accepting initial postings. Two improvements in the process are available with LMTP.
First, we can eliminate most of the integration cruft we currently have with supporting multiple MTAs for incoming mail. Most of the major SMTP servers support LMTP delivery, so by providing an LMTP server in Mailman, the hope is that we can avoid all the crufty MTA-specific alias hackery.
Second, and perhaps more importantly, we can support better anti-backscatter and anti-spam defenses for messages sent to the mailing lists, by rejecting messages in the SMTP dialog instead of having to make the determination way later and sending a bounce message. Ian Eiloart describes what is possible.
How to set up LMTP delivery for Mailman 3
Here is detailed information about how Mailman should integrate with the various MTAs using LMTP.
If you're getting
Postfix uses the Postfix
lmtp client to transport messages to a LMTP
server. You probably already have this in your Postfix
We're going to use a transport map to tell Postfix to deliver all messages
destined for a Mailman mailing list to its lmtp service. Fortunately, Mailman
is already able to write the correct transport map based on your configuration
settings. All you need to do is add a
transport_maps setting in your
Now Postfix knows where it should transport messages to, but it doesn't know
yet it should accept messages for the given recipients - it doesn't know the
recipients are valid recipients. You can reuse the Mailman generated
transport map for this by adding the following to your
If the mailman list addresses are part of
postfix_lmtp to the listing of
If the mailman list addresses are part of the relay domain namespace add
postfix_lmtp to the listing of
Once Postfix has been reloaded the new settings will take effect.
A dedicated list server
For a dedicated list server e.g. list.example.com simply add the hostname as key to a transport map and specify the mailman LMTP server as destination:
Be aware though that Postfix has no knowledge of valid recipients in the destination's (sub)domain (here: list.example.org) if you specify the list server as noted above. Postfix will accept and transport any message destined for list.example.org to the mailman LMTP server and it will be the LMTP servers task to reject messages for invalid or non-existing recipients.
There are two ways to prevent putting such load on the mailman LMTP server. First specify each valid recipient address in a transport table as shown in the initial example. Alternatively use the
reject_unverified_recipient option and let the Postfix
verify(8) daemon find out if the recipient address exists. This way Postfix will reject messages to non-exsisting recipients during the SMTP session with the client that attempts to deliver the message. See
ADDRESS_VERIFICATION_README for details on implementing the reject_unverified_recipient option.
A dedicated lmtp client
As of Mailman 3.0a4, the service name used in the Mailman generated
There may be situations where a dedicated lmtp client, that differs in its configuration from the default lmtp client settings, is required.
To create such a client add a new service (here: mailman3) to the Postfix
master.cf configuration file and add the configuration options which should override the default lmtp client behaviour:
Then specify the new service in the transport table e.g.
There are two variants of LMTP support in Exim transports. The first of these exists as an option to the SMTP driver, instructing it to talk LMTP over the SMTP connection. Such a transport will look like this:
There is an independant LMTP transport driver, which is able to communicate using unix sockets. For reference, this transport will look like the following, excluding any additional local configuration options:
Email routing using Exim
The exim router should only need its transport option changed, the rest of the logic can remain the same. One can consult the output of genaliases:
Alternatively, one can check directly for a list's existence:
Access Controls in Exim
Once you've set up routing and transports, you can use Exim's call forwards in an ACL (with the use_sender option) to determine whether the sender is permitted to post to the list. You should get a definitive answer, and this mechanism allows you to use a remote Mailman installation as if it were local - that is, you don't need to consult any local files. See section 40.40 of the Exim docs.