On Thu, Jan 30, 2020, at 8:44 AM, tom@gather.coop wrote:

Hi folks! First time poster, long time Mailman user.

I am setting up a new Mailman 3 instance, and am super excited about the REST API. I plan to use it to enable tight integration with a separate web app that I maintain.

As I am setting up the mail server, I am wondering about two related things: deliverability (for outgoing mail) and spam filtering (for incoming mail).

What solutions have folks used for these? I know it is generally common now to outsource this critical task to a cloud provider like Mailgun or etc. Have folks needed this or is running ones own incoming and outgoing mail not a big deal? So many horror stories out there...

As far as Mailgun goes, I think it should be straightforward to configure it for outgoing mail, but I'm not sure how I'd use it for incoming. Mailgun can forward mail via HTTP or to another email address. Neither I think would work out of the box. It would be great if there were a REST API endpoint for incoming mail, but I don't think such a thing exists, right? Perhaps I could add one?

There does exist a way to insert messages into Mailman via REST API, if you want to do that. It is done via Queue API, which exposes the internal store where messages sit after they are received from LMTP before they are processed.

You can just inject the message in "IN" queue and it should be processed like a regular incoming message.

https://mailman.readthedocs.io/en/latest/src/mailman/rest/docs/queues.html

Although, it seems to only accept string representation of Email, which may not be ideal for your use case. It might be some work to make it work for raw bytes.

Another thought I had was that I could write a simple HTTP server that receives mail from Mailgun and forwards it to Mailman via LMTP. But it seems simpler to go right to Mailman's core API given that one exist already.

Or am I thinking about this all wrong? Are there other more suitable services out there? I looked for cloud MTA providers but didn't turn up much except for in the large enterprise space, which I'm sure I can't afford.

Thanks for any thoughts!

---

Mailman-users mailing list -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-leave@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/

-- thanks, Abhilash Raj (maxking)

On 1/30/20 1:58 PM, Tom @ Gather wrote:

Interesting! Does the in queue also work for emails to subaddresses like foo-owner, etc? Or is it only for list posts?

-bounces goes to bounces -confirm, -join, -leave (and their synonyms -subscribe and -unsubscribe) and -request go to command -owner goes to in.

But there's more to it that that. There's also things put in the metadata in the queue entry such as mail to -owner sets to_owner = True

Relatedly, why is list_id a required parameter? Isn't that information contained in the email?

Possibly not. The recipient list is the envelope recipient which may or may not be in the message headers - it could be a Bcc to the list. Thus, listid needs to be set in the metadata as well.

You need to look at mailman/runners/lmtp.py and emulate what it does.

-- Mark Sapiro mark@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan