Mailman 3 August 2020 - Mailman-Developers

before next release: disable backscatter in default installation
by Jo Rhett 07 Nov '22

07 Nov '22

Hi. There's a fairly simple problem here that needs to be addressed. And it's mostly a documentation/install problem. I'm hoping we can get this resolved before the next release. PROBLEM: Mailman comes out of the box ready to backscatter spam people. Yes, it's easy enough to fix. But because it comes stock this way, and is documented to install this way, most people install it to do this. Those of us who work in abuse departments are tired of hearing "well that's how Mailman works". We also object to having to teach people how to fix their mailman installations because it's not documented in the current manual. This is *exactly* like Sendmail 14 years ago. We didn't accept it then, and Sendmail fixed the problem. RESOLUTION: Mailman default installation should not backscatter in a default configuration. 1. Don't create backscatter aliases for subscribe/unsubscribe/etc by default. Nearly everyone uses web based signup. 2. Discard or hold messages from non-subscribers by default. I would think that it would be perfectly reasonable to have documentation on how to enable the 1980s-style -request / -subscribe etc aliases. However this documentation should have a note that this is against the AUP of nearly every network provider, and enabling it will likely cause them to get listed in various blacklists as a backscatter source. FYI: I know that this goes against the instincts of many old-time mailing list advocates here. But after dealing with a 10k/hour backscatter DoS my tolerance for this problem is understandably limited. Yes, it was a sweet day back in the 1980s. I was running a mailing list server and several UUCP gateways at the time, so I remember them well. But those days are past, and we need to deal with the reality of today. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness

21 168

Working towards a hassle-free Docker deployment
by Hans-Martin Mosner 30 Aug '20

30 Aug '20

Hello, due to the need to modernize our Mailman installation, I want to switch two installations to Mailman3. My options currently seem to be: * Install from distro repository (Ubunut 20.04) - they only have Version 3.2.2, which does not play well with the Python version 3.8.2 that's also in the repository :-( * Install from sources - not really difficult, but I fear that regular updating might be a bit of a hassle, and integration into the system as a service needs a bit of manual work :-( * Run the Docker images created by maxking, which would probably be the most painless option for one of the sites, but there's still a caveat :-( One problem which is present in all 3 cases is that the mailman server (or container) is not on the same machine as Postfix. For mail input and output that's not a problem since Mailman speaks LMTP and SMTP, but sharing the Postfix maps between machines is a bit tricky. NFS should theoretically work, but getting all permissions right is not trivial. This is somewhat more pressing in Docker where I don't even have control over the UID running Mailman inside the container. Therefore I would like to add a socketmap service to Mailman that Postfix can query to get map information. Since this idea is probably not totally original I'd like to ask on this list whether someone already tried such a thing, and what their experiences were. Cheers, Hans-Martin

1 1

Better documentation for Mailman Core's config options
by Abhilash Raj 07 Aug '20

07 Aug '20

Hey All, For the past few days, I've been trying to improve the documentation style for Mailman Core's config options. Internally, Mailman has all configurations defined in an ini formatted `schema.cfg` file, which serves as a schema for our `zope.configuration` library. We had that file simply embedded in the sphinx documentation previously as a wall of text. I ended up writing a Sphinx (our documentation generator) plugin which parses the config file and presents the same documentation with more bells and whistles so it is easier to lookup and link sections and config options.[1] The process of doing that was fun and I learnt how to write a simple sphinx plugin, so yay! It treats the comments above each config option in the ini file as it's doc and basically generates ReST text that it passes to Sphinx to parse and convert to the markup format that you see in browser. You can look at it in the source repo[2] . Do note that not all sections are documented yet, I am still figuring out what would be a good way to document template sections like `[plugins.master]` and other similar sections of that kind. [1]: https://gnu-mailman--667.org.readthedocs.build/projects/mailman/en/667/src/… ((URL is for the PR, the main doc seems like is serving the cached version from an older build). [2]: https://gitlab.com/mailman/mailman/-/blob/master/_ext/configplugin.py -- thanks, Abhilash Raj (maxking)

2 1