LMTP in Mailman

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:

on connect:
accept the connection
HELO/EHLO:
reject if the sending MTA isn't known
MAIL FROM:
accept (perhaps unless the sender address is forbidden to post to all
lists).
RCPT TO:
accept if the sender has permissions to post to the list, otherwise reject.
This is the last chance to give a list specific response to an MTA that is
engaged in a callout.
DATA:
reject null senders here if appropriate. Rejecting a null sender at RCPT TO
or earlier might break callouts.
.............
.
Check the data, reject if inappropriate for a specific list (but this is
likely to cause a bounce from our MTA). Because we've decided to trust the
sender, we should be OK to bounce a message here, unless the list is an
open list.

I believe MM3's architecture can easily support this, and I've been working with Ian on the mailing list to sketch out a design. I think we should do this for MM3.

Ian also describes a useful set of enhanced error codes:

X.1.1   Bad destination mailbox address
X.2.4   Mailing list expansion problem
X.5.3   Too many recipients
X.7.2   Mailing list expansion prohibited
The sender is not authorized to send a message to the intended mailing list.

X is 4 for a temporary error, 5 for a permanent error.

For details see:

• RFC 1893 - Enhanced Mail System Status Codes

• RFC 2034 - SMTP Service Extension for Returning Enhanced Error Codes

LTMP with various MTAs

Here is detailed information about how Mailman should integrate with the various MTAs using LMTP.

Postfix

Postfix uses the Postfix lmtp client to transport messages to a LMTP server. The defaults for this client are configured in master.cf:

 1. ==========================================================================
 1. service type  private unpriv  chroot  wakeup  maxproc command + args
#               (yes)   (yes)   (yes)   (never) (100)

 1. ==========================================================================
...
lmtp      unix  -       -       -       -       -       lmtp
...

Transporting messages to mailman LMTP server

Create a transport(5) type table e.g. /etc/postfix/mailman_lists and add each mailman mailing list address on a single line as key to the left hand side of the transport table. For each key specify the destination of the LMTP server as value.

Here's an example of /etc/postfix/mailman_lists:

 1. key                           value
mailman@example.org             lmtp:inet:localhost
mailman-admin@example.org       lmtp:inet:localhost
mailman-bounces@example.org     lmtp:inet:localhost
mailman-confirm@example.org     lmtp:inet:localhost
mailman-join@example.org        lmtp:inet:localhost
mailman-leave@example.org       lmtp:inet:localhost
mailman-owner@example.org       lmtp:inet:localhost
mailman-request@example.org     lmtp:inet:localhost
mailman-subscribe@example.org   lmtp:inet:localhost
mailman-unsubscribe@example.org lmtp:inet:localhost

Once all entries have been added to the /etc/postfix/mailman_lists file use the Postfix postmap command to create a database:

# postmap /etc/postfix/mailman_lists

Then add the database to the list of $transport_maps in Postfix' main.cf configuration file:

transport_maps =
    ...
    hash:/etc/postfix/mailman_lists
    ...

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.

Adding mailman addresses to a list of valid recipients

Postfix maintains several lists of valid recipients - each destination type (local domain, virtual domain, relay domain) has its own list identified by a separate configuration parameter.

Local domain (mydomain)

If the mailman list addresses are within the namespace of the local domain ($mydomain, $mydestination) add mailman_lists to the listing of $local_recipient_maps:

local_recipient_maps =
    proxy:unix:passwd.byname
    $alias_maps
    hash:/etc/postfix/mailman_lists

Virtual domain

If the mailman list addresses are part of $virtual_alias_domains or $virtual_mailbox_domains add mailman_lists to the listing of $virtual_alias_maps:

virtual_alias_maps =
    ...
    hash:/etc/postfix/mailman_lists
    ...

Relay domain

If the mailman list addresses are part of the relay domain namespace add mailman_lists to the listing of $relay_recipient_maps:

relay_recipient_maps =
    ...
    hash:/etc/postfix/mailman_lists
    ...

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:

 1. key                           value
list.example.org                lmtp:inet:localhost

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

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: mailman) to the Postfix master.cf configuration file and add the configuration options which should override the default lmtp client behaviour:

 1. ==========================================================================
 1. service type  private unpriv  chroot  wakeup  maxproc command + args
#               (yes)   (yes)   (yes)   (never) (100)

 1. ==========================================================================
...
mailman   unix  -       -       -       -       -       lmtp
    -o lmtp_send_xforward_command=yes
    -o disable_dns_lookups=yes
...

Then specify the new service in the transport table e.g. /etc/postfix/mailman_lists:

 1. key                           value
mailman@example.org             mailman:inet:localhost
mailman-admin@example.org       mailman:inet:localhost
mailman-bounces@example.org     mailman:inet:localhost
mailman-confirm@example.org     mailman:inet:localhost
...

Exim

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:

mailman_remote_lmtp:
    driver = smtp
    protocol = lmtp
    hosts = localhost
    allow_localhost

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:

mailman_local_lmtp:
    driver = lmtp
    socket = "/var/run/path/to/unix/socket"
    batch_max = 40
    user = mailman

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:

mailman_aliases:
    driver = accept
    domains = +local_domains
    condition = ${lookup${local_part}lsearch{/path/to/genaliases/output}}
    transport = mailman_local_lmtp

 Alternatively, one can check directly for a list's existence:

mailman_direct:
    driver = accept
    domains = +local_domains
    require_files = /mail/mailman/lists/${lc::$local_part}/config.pck
    local_part_suffix_optional
    local_part_suffix =  -admin     : \
                      -bounces   : -bounces+* : \
                      -confirm   : -confirm+* : \
                      -join      : -leave     : \
                      -owner     : -request   : \
                      -subscribe : -unsubscribe
    transport = mailman_local_lmtp

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.

Sendmail

Comments