[Mailman-Developers] Mailman 3 and LMTP

[Barry Warsaw]

On Nov 29, 2009, at 3:22 AM, Patrick Ben Koetter wrote:

> Hi!
>
> * Barry Warsaw <barry at python.org>:
>> I'm getting very near ready to release another alpha of Mailman 3,  
>> and on the
>> prompting of a private message from Robert Niederreiter I took some  
>> time to
>> fire up a VM and actually try Postfix+LMTP delivery in an  
>> experimental
>> production system.  I'd like to get some feedback from the Postfix  
>> experts in
>> the crowd so that we can update the wiki page here:
>>
>>    http://wiki.list.org/display/DEV/LMTP+process
>>
>> FTR: the VM is running Ubuntu Karmic Koala 9.10 server with Postfix  
>> 2.6.5 and
>> Mailman 3.0 from the lp:mailman bzr trunk.
>>
>> To start with, I mostly followed the instructions in the wiki.  I  
>> tried using
>> the standard lmtp transport in master.cf, creating /etc/postfix/ 
>> mailman_lists
>> as described in the wiki (not the dedicated list server example,  
>> but the
>> earlier one on the page).  I actually used:
>>
>> # Key                   # Value
>> test at xxx.example.com    lmtp:xxx.example.com
>>
>> where 'xxx.example.com' is replaced by my VM's host name.
>
> Additionally you probably want to add square brackets around the  
> hostname.
>
> Quoting "man 5 transport":
>
>  ...the [] suppress MX lookups.  This prevents mail routing loops  
> when your
>  machine is primary MX host for example.com.

This could have been Robert's problem.  I'd forgotten that we actually  
do create the transport map automatically, if you set the  
configuration to use Postfix's LMTP delivery (this is the default).   
In that case, we generate a file called data/postfix_lmtp (and use  
postmap to create the .db file) which should be usable directly as the  
transport_map.  I've changed it to include the brackets around the  
host name.

This actually greatly simplifies things, since all you need to do is  
set transport_maps and local_recipients and you're done.

>> The first gotcha is that unless you start Mailman as root, you  
>> can't bind its
>> LMTP server to port 24, which is Postfix's default.  By default  
>> Mailman's LMTP
>> server listens on localhost:8024, so you either need to append ': 
>> 8024' on the
>> Value above, or set
>>
>>    lmtp_tcp_port = 8024
>>
>> in Postfix's main.cf.  I ended up doing the latter, but both work.
>
> I think an option in MM3 should make this configurable.

It does.  Also putting the port in the Mailman generated transport_map  
means the right thing will always happen (modulo the permission  
dropping part which won't make it into 3.0a4).

>> I set up transport_maps and local_recipient_maps just as outlined  
>> in the wiki
>> page, fired everything up, and then sent a message to the VM's  
>> Postfix while
>> tailing the logs.  I kept seeing "Connection refused" messages from  
>> Postfix
>> and it never hit Mailman's LMTP server.
>>
>> This was highly confusing because I could see in the Postfix logs  
>> that it was
>> finding the right IP address for its own hostname and it was trying  
>> the right
>> port number.  Mailman's lmtp.log file claimed it was listening on  
>> the right IP
>> and port, and I could even telnet to it just fine.  So what was  
>> Postfix doing?
>>
>> It seems that Karmic is playing tricks with /etc/hosts.  I've got  
>> DNS set up
>> to correctly resolve the VM's hostname, but there was actually an  
>> entry in
>> /etc/hosts that set xxx.example.com to 127.0.1.1.  I'm not entirely  
>> sure which
>> process looks at what, when, but clearly this inconsistency was a  
>> key part of
>> the problem.  The other thing that surprised me was that Postfix  
>> was also
>
> On a sidenote: It also confuses a dhcpd server running on a machine  
> that
> promotes 127.0.1.1 to be xxx.example.com. I've opened a bug ticket  
> for that
> two Ubuntu releases ago, but it seems they only keep carrying it  
> further from
> release to release instead of addressing it. At least that's the  
> impression I
> get without knowing the real cause.

What's the bug number?

>> consulting /var/spool/postfix/etc/hosts, and I had to change both / 
>> etc/hosts
>
> That's because LaMont Jones delivers the Debian/Ubuntu Postfix package
> chrooted. If Postfix runs chrooted it uses /var/spool/postfix/etc/ 
> hosts
> instead of /etc/hosts.

Ah, the pieces click together.  Thanks!

>> and that file as well, so that the IP addresses jived with DNS.   
>> This is
>> unsatisfactory, but it seemed critical to getting things working.
>>
>> The last piece of the puzzle was to not use Postfix's standard lmtp  
>> server in
>
> lmtp client... SCNR

Erp. ;)

>> master.cf, but to define a new one like so:
>>
>> mailman3 unix - - - - - lmtp -o disable_dns_lookups=yes
>>
>> and then change the mailman_lists transport map to
>>
>> # Key                   # Value
>> test at xxx.example.com    mailman3:xxx.example.com
>>
>> After a restart, everything suddenly worked exactly as expected.
>
> suddenly... :)

Yeah.  Doesn't everybody call 6 hours on a Saturday "suddenly"? :)

>> Robert was having a different problem, but hopefully he will follow  
>> up here
>> with his experience and let us know if any of the above helps.  If  
>> any Postfix
>> experts have words of wisdom to make this better, please let me know.
>
> If MM relies on Postfix defaults and the postmaster changes them in  
> Postfix
> the MM part might end up being unusable.
>
> I recommend to take full control of the settings in the Postfix  
> transport map.
> Let MM create its own Postfix style transport map. Set the "Postfix  
> service
> name" (in your example its mailman3), put the hostname in square  
> brackets and
> set the port.

Yep, I like setting the service name to mailman3.  I'll note that  
Ubuntu's Postfix-Dovecot package already has a service for mailman  
(i.e. 2.x) which uses postfix-to-mailman.py.

>> I probably need to work on better dropping of privileges for  
>> qrunners so that
>> you can 'bin/mailman start' as root, and once the LMTP runner binds  
>> to port
>> 24, it can drop privs to 'mailman'.  I'll put that on the list for  
>> something
>> to do after the next alpha.
>
> I like that idea.
>
>
>> I'd also like to try to resurrect William Mead's LMTP branch.   
>> Sadly, it won't
>> merge cleanly into trunk any more (not the least of which because  
>> it's in the
>> wrong bzr format).  If anybody would like to contribute that before  
>> I get to
>> it, I'd be grateful.
>>
>> The good news is that I think Mailman 3 is getting more real every  
>> day.  My
>> plan over the next few weeks is:
>>
>> * release alpha 4
>> * get i18n translations working
>> * complete the split of the pipermail project
>> * hopefully get Patrick and friends going on the web u/i
>
> I will update to the latest branch that should fix the language file  
> problem
> we had discovered and then we will work on the REST client/server.

Excellent!  I forgot that one other thing must happen before 3.0 can  
be released; we need a migration script from 2.1.x to 3.0.

I'll update the wiki page and release 3.0a4 a little later today.   
Then perhaps other folks can try the LMTP connection on other *nix  
distributions.

Thanks Patrick,
-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20091129/438fddee/attachment.pgp>