mm-handler same as postfix-to-mailman.py
Mm-handler works well when mail-lists are in a separate domain.
I ran across postfix-to-mailman.py while researching mailman to postfix connections. I realized it performs the same function as mm-handler. I changed mm-handler to be a drop in as a replacement for postfix-to-mailman.py <https://github.com/fauria/docker-mailman/blob/master/centos7/postfix-to-mail...>. It is under:
http://sw.ziobro.info/mm-handler/
I did a test install of mailman with Postfix to test it. It worked.
I also setup a Mailman to Postfix connection using the aliases method as described in the documentation. That worked fine also. I don't use Postfix but using the postfix-to-mailman.py seemed a little more obvious than setting up through the aliases method. The Postfix package on CentOS 7 even had comments where the mailman transport entry would go. Configuring is especially tough if you are not familiar with Python. :-)
Setting up mailing lists in a separate domain has a nice administrative appeal. I did a little more research to see how popular that method might be. I got a list of 1922 US universities and 457 have a host "lists...." and 191 have a host "list..." in their DNS. I surveyed a few and ran across: Mailman, Lyris, Sympa, Listserv, Majordomo, and Google groups. Many universities outsource their Email to Outlook which has it own Group capability.
Running mail list software is clearly popular. Both mm-handler and postfix-to-mailman.py are contributed code. The folks who package the various tools add glue to make them easy to use. It looks like both Sympa <https://sympa-community.github.io/manual/>and Mailman have very similar requirements. Maybe time to work together?
I can hook up any mail system. Just give me the list of mail-lists and tell me how to inject messages. Glue will be more specific to a Mailer and OS than either Mailman or Sympa. I think we get a benefit if we make a clean interface between Mailman and its feeding MTA. We can then eliminate some of the hacks like mm-handler.
I have some ideas for Mailman2. I'll follow up.
Ciao, //Z\\ Jim Ziobro
Hi Jim,
On 1/4/19 3:40 AM, Jim Ziobro wrote:
Setting up mailing lists in a separate domain has a nice administrative appeal.
Agreed. That's how I've always done it.
If I ever cared enough, I could set up a forward (et al) from list@example.net to list@lists.example.net. Maybe not automatic. But it does function. (Or it did the last time I tried.) - I think it did require adding an alternate address for the list to recognize itself as.
I did a little more research to see how popular that method might be. I got a list of 1922 US universities and 457 have a host "lists...." and 191 have a host "list..." in their DNS. I surveyed a few and ran across: Mailman, Lyris, Sympa, Listserv, Majordomo, and Google groups. Many universities outsource their Email to Outlook which has it own Group capability.
Interesting.
I can hook up any mail system. Just give me the list of mail-lists and tell me how to inject messages. Glue will be more specific to a Mailer and OS than either Mailman or Sympa. I think we get a benefit if we make a clean interface between Mailman and its feeding MTA.
Agreed.
We can then eliminate some of the hacks like mm-handler.
Maybe. But I think the hacks just move elsewhere, especially if you want other features.
I have some ideas for Mailman2. I'll follow up.
I'd like to see some sort of integration into the Mailer (MTA) such that it can do some simple filtering and reject the message at SMTP time instead of needing to bounce it after the fact.
I think it should be somewhat easy to test the SMTP envelope sender to see if it's subscribed to a list that is the SMTP envelope recipient. If the sender is not a subscriber the MTA can reject the message.
It wouldn't be as simple, but I think similar could be done with the DATA phase of the SMTP transaction to filter body contents. Though I'm not sure how to parse a message to see if it should be rejected without actually having the message pass through part of Mailman.
I also think that an LMTP and / or SMTP interface to Mailman would be nice. I think that provides more features at the SMTP / DSN (maybe MDN) level than STDIN into Mailman can provide.
Nice work Jim.
-- Grant. . . . unix || die
On Sun, 6 Jan 2019 15:47:01 -0700 Grant Taylor via Mailman-Users <mailman-users@python.org> wrote:
Hi Jim,
On 1/4/19 3:40 AM, Jim Ziobro wrote:
Setting up mailing lists in a separate domain has a nice administrative appeal.
We used to run irix whose sendmail sent every message from host.domain and every A record had to have an adjacent MX record for e-mail to even work. That way lies madness.
I did a little more research to see how popular that method might be. I got a list of 1922 US universities and 457 have a host "lists...." and 191 have a host "list..." in their DNS. I surveyed a few and ran across: Mailman, Lyris, Sympa, Listserv, Majordomo, and Google groups. Many universities outsource their Email to Outlook which has it own Group capability.
Our university has lyris @ lists.uw, googlegoups, and has recently bought into lookout'365! as well. While we run our own mailman instances.
We have "lists" in our little niche. It's the web front-end, our list traffic comes from @domain.
So 500 out of 2000 universities having "list(s)" in DNS doesn't really mean all that much.
I think it should be somewhat easy to test the SMTP envelope sender to see if it's subscribed to a list that is the SMTP envelope recipient. If the sender is not a subscriber the MTA can reject the message.
Rather trivial with postfix but a) we have bona fide subscribers posting rom their gmail instead of subscribed From: -- I want those to get moderated instead of bounced, b) it is of course subject to spoofing, and c) how much of a problem is it IRL?
In our -- admittedly very lightly loaded -- domains, it's RBL and fail2ban that seem to provide best bang for the buck.
-- Dmitri Maziuk <dmaziuk@bmrb.wisc.edu>
On 01/07/2019 09:59 AM, Dmitri Maziuk via Mailman-Users wrote:
We used to run irix whose sendmail sent every message from host.domain and every A record had to have an adjacent MX record for e-mail to even work. That way lies madness.
Hum.
I think Sendmail (and other MTAs that I've tested) default to user@host.domain too. But that's just a default that's easy to change.
I thought that SMTP allowed for falling back to an A record to find where to send messages for host.domain. Or are you saying that you used MX records to route email to a different machine, possibly a mail hub?
I also thought that SMTP would iterate up through the right hand side of email addresses looking for MX / A records and trying to connect to an SMTP server. Thus it would be possible to have an MX record for domain and all hosts there in would cascade up to said MX record.
Or is all of this vagaries of SMTP and too unpredictable / unreliable and best avoided?
Rather trivial with postfix but a) we have bona fide subscribers posting rom their gmail instead of subscribed From: -- I want those to get moderated instead of bounced, b) it is of course subject to spoofing, and c) how much of a problem is it IRL?
A) Fair enough. I would expect there to be a per-list tunable to either reject or not-reject messages based on list membership. In the scenario that you describe, the messages would not be rejected based on sending email address and assuming the message passes other tests would be passed further into Mailman.
B) I would hope that other things like SPF / DKIM / DMARC would help reduce this considerably. But I'm not going to hope enough to hold my breath.
C) ¯\_(ツ)_/¯ I suspect it's highly mailing list dependent. - I personally like to do as much as possible during the SMTP transaction. So if there is a reasonable way to apply some Mailman filtering logic to applicable messages, why not do it?
In our -- admittedly very lightly loaded -- domains, it's RBL and fail2ban that seem to provide best bang for the buck.
*nod*
-- Grant. . . . unix || die
On 1/7/19 2:13 PM, Grant Taylor via Mailman-Users wrote:
I think Sendmail (and other MTAs that I've tested) default to user@host.domain too. But that's just a default that's easy to change.
LOL. Not on IRIX it wasn't.
Or are you saying that you used MX records to route email to a different machine, possibly a mail hub?
That. If you want a single MX accepting mail for the Internet, you have to have virtual domains on it for your every host, and make sure SMTP and/or DNS reliable routes addres@host.domain to address@domain. Which may be easier than I think, I never tried...
Granted we're talking "just one" @list.domain here. Well, maybe also @list.domain... and then by strong mathematical induction we arrive at the above.
B) I would hope that other things like SPF / DKIM / DMARC would help reduce this considerably. But I'm not going to hope enough to hold my breath.
But then you wouldn't need it in mailman: if it's spoofed as per dmarc, you just reject it regardless ot its destination.
C) ¯\_(ツ)_/¯ I suspect it's highly mailing list dependent. - I personally like to do as much as possible during the SMTP transaction. So if there is a reasonable way to apply some Mailman filtering logic to applicable messages, why not do it?
Like I said, it's probably whooping 10 extra lines of python -- as long as you use postfix. The question is how much work it is to support other MTAs.
-- Dimitri Maziuk Programmer/sysadmin BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu
participants (4)
-
Dimitri Maziuk -
Dmitri Maziuk
-
Grant Taylor -
Jim Ziobro