[Redirecting to mailman-developers]

On Jul 25, 2015, at 01:34 PM, Michael Hierweck wrote:

We are currently running Mailman 2 in an very low-traffic environment without access to the mail server configuration. We can either use .forward or aliases to forward mails directly to Mailman via pipe. Fetching mails from POP3/IMAP mailboxes would be possible, too.

We would like to upgrade to Mailman 3 now. Thanks for lots of good work over many years btw. However Mailman 3 only supports feeding mails via LTMP. Is is possible to build a bridge between .forward/aliases and Mailmans LMTP interface in a convenient and secure manner?

An option might be letting fetchmail fetch the mails from a mailbox and forward them via LTMP. As the mails have already been successfully delivered to the mailbox before Mailman might reject them I can't image a chance of handling bounces due to rejects correctly in this setup.

Therefore I'm thinking of a small Python script that receives mail from stdin and forwards them via LMTP but I'm unsure whether this would be a correct way to achieve the goal because there might by problems with bounces when Mailman rejects those mails. This script oughts to terminate unsuccessfully when the LTMP delivery fails and should therefore make Postfix bounce the mail itself.

Postfix -> .forward -> pipe --(stdin)--> script --(LMTP)--> Mailman 3

Any opinions or hints are appreciated. Thanks in advance.

It wouldn't be out of the question to do it this way, although you're right that you have to have some special handling for rejections. Technically speaking, Mailman would still support "bounces", which are messages created out of whole-cloth by Mailman sent to the original sender out of band to the LMTP conversation, encapsulating the original message. In fact, your dot-forward-to-LMTP bridge would probably have to capture the LMTP 4xx and 5xx rejection codes and craft a bounce, although it could potentially allow Mailman itself to deliver this.

Remember though that the LMTP runner isn't all *that* special, in that upon successful acceptance of the message, it will just drop it in the appropriate queue for further processing. It's certainly conceivable that one could implement a new type of runner that interfaced with dot-forward files in much the same way that MM2 did, but with logic a bit more compatible with MM3's queue structure and database.

The trickiest part of all this is handling the security implications of using a dot-forward program. The core only supports LMTP delivery by default in MM3 so we get to ignore all the C wrappers and gid-mismatch fun of MM2.

FWIW, this could all be built as a separate plugin for the core.

Cheers, -Barry