FetchMail injects messages into the local mail system via SMTP. I see it also supports LMTP. So I guess you would not need a local mail system with Mailman3. But why not setup standard Mailman under your favorite mail system and let FetchMail do what it does best? It is a widely supported configuration.
Your favorite mail system would handle queues for you as well as support all the tools (milters, etc) surrounding your mailman deployment. Reliably handling the queue is important. You won't know how important until you start getting duplicate messages like RFC 1047 <https://tools.ietf.org/html/rfc1047>.
Just checking... when using fetchmail (for example "testlist" on Gmail) then you'd be fetching mail for: testlist@gmail.com as well as
testlist-admin@gmail.com testlist-bounces@gmail.com testlist-confirm@gmail.com testlist-join@gmail.com testlist-leave@gmail.com testlist-owner@gmail.com testlist-request@gmail.com testlist-subscribe@gmail.com testlist-unsubscribe@gmail.com owner-testlist@gmail.com
My fetchmail test is giving me reasonable Sender info.
Ciao, //Z\\
On 3/25/2019 12:45 PM, Mark Sapiro wrote:
On 3/25/19 8:21 AM, Grant Taylor via Mailman-Users wrote:
Noted. I think it would be possible to interject a shim between fetchmail that would extract what's necessary to speak LMTP to Mailman.
Yes, it would be possible.
Is the LMTP still STDIN / STDOUT or something else (possibly a Unix socket)?
The shim could receive a message on stdin from fetchmail, but it would have to deliver the message via LMTP (a subset of SMTP) to Mailman's lmtp runner which listens on a tcp socket, typically localhost:8024.
I'm trying to understand if I could drive Mailman 3 via Expect. Not that I would. I'm just wondering if I could.
You probably could if you created an Expect script to speak LMTP. I think the major issue in this is that fetchmail does not provide the envelope, so you don't know the actual envelope sender to use in the LMTP MAIL FROM command. If the MDA that delivered the mail to the remote mailbox was compliant, it will be in a Return-Path: header in the message, but otherwise you'd have to fake it by using a Sender: or From: header. Also, you don't directly know the original recipient, although you can infer it based on the mailbox you fetched from.