[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.