Mailman 3 June 2017 - Mailman-Developers

before next release: disable backscatter in default installation
by Jo Rhett Nov. 7, 2022

Nov. 7, 2022

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

[GSoC] Encrypted mailing lists
by Jan Jancar Aug. 29, 2017

Aug. 29, 2017

Hi Mailman Developers. I am sending this mail as my proposal of encrypted mailing lists for GNU Mailman got accepted and I will be working on it this summer. Sorry about not contacting you earlier, I had some issues where my site and mail server were down. If any of you tried to reach me and failed in the last ~week you can try next time on my backup mail jancar.jj(a)gmail.com which should always work. You can find the original (accepted) version of my proposal on: https://neuromancer.sk/static/mailman.pdf # Status report so far into the Community bonding period: - As it was proposed on this list a plugin-like implementation of encrypted mailing lists is really the only way to go forward here, as just pushing in what might end up being a rather niche feature into Mailman Core is not maintainable / wanted. - I started evaluating how much of my current proposal can be implemented without touching Mailman Core at all (as a plugin), what would require general changes and what might require specific changes (that means it needs a better solution). - So far it seems most functionality of encrypted mailing lists can be easily implemented out-of-tree with only minor general changes to Mailman Core with the following exceptions that I'm currently solving: * Making all commands require a confirmation (as subscribe / unsubscribe has). This is necessary to stop replay attacks. * Subscription command needs to contain users public key, either as an argument or attachment or any other way the plugin might get it. * List key fingerprint and per-address/user key fingerprints need to be stored somehow, directly in the mailing list model would make the most sense, but that's very specific so the plugin should store this itself. Although that means data duplication. * Plugins don't seem to have a way to add features to the core REST API, so exposing key administration for Postorious that way is out. + Some questions that I had in my original proposal: + Is exposing key management through the REST api and Postorius a good idea at all? Those have very different level of access control, changing a key on a list requires a signed request + signed confirmation token whereas doing it in Postorius might only require a password. + A way of sharing the lists public key that makes the user trust it the most. # What I would like to definitely finish in the Community bonding period: - Finish SMTPS/STARTTLS support for Mailman Core (really only needs tests now): https://gitlab.com/J08nY/mailman/tree/mta-smtps-starttls - Establish real-time communication channels with mentors (text/voice?) and have a meeting to discuss the proposal. - Add proper objective milestones to the proposal. - Change the proposal to reflect movement towards a more plugin-like implementation. Cheers, -- Jan ______________________________________________________ /\ # PGP: 362056ADA8F2F4E421565EF87F4A448FE68F329D /__\ # https://neuromancer.sk /\ /\ # Eastern Seaboard Phishing Authority /__\/__\ #

4 23

Discourse Integration
by Stephen J. Turnbull July 25, 2017

July 25, 2017

Vaibhav Lohani writes: > There was a mention of integrating mailman 3 with discourse some > times back. I am interested in working on it. Is someone else > interested in it or already working on it ? I don't know of anyone who is currently working on it, nor do we have specific plans at the moment. What sort of integration do you have in mind? Steve

2 1

Next Postorius release
by Simon Hanna June 30, 2017

June 30, 2017

Hi, I know it might be a little early, but I'd like to talk about the plan for Postorius (Mailman in general) releases moving forward. Should there be more point releases? 3.1.X? Or just 3.X? Are releases bound to Core releases (following core's release numbering?)? How often do we do releases? Every X merge requests and/or X months? I'd like to know that just to organize issues/merge requests and so the whole process can be planned a little more... Would be also helpful to create this information in Gitlab milestones... cheers, Simon

3 4

Mailman 3 Container Images v0.1
by Abhilash Raj June 26, 2017

June 26, 2017

Hi Everyone, I have been working on containerizing Mailman 3 so that it becomes easier to test and try Mailman 3. There are two images in total: * maxking/mailman-core : This consists of Mailman Core and includes the plugin to enable the Hyperkitty Archiver. * maxking/mailman-web : This consists of a full Django installation and run the Mailman's Web UI components. It has Mailman Client, Postorius & Hyperkitty. The images are built from the Dockerfiles hosted on Github[3] in case you want to look at it. You can find most of the documentation about these images at https://asynchronous.in/docker-mailman/. The version of the internal components included in each image is available here[7]. The images are versioned and the process is documented[4], please have a look before you use them. Also, the images are signed and I encourage you to verify them before using. The process of how-to verify is also documented. Docker Compose is a tool written in Python makes is very easy to deploy connected-images and take the pain out of writing long long commands for spinning of containers. There is a sample `docker-compose.yml` file in the Github repository mentioned above which is kind-of tested to be able to spin off these images in vanilla condition (without any customization/configuration). You can report issues, comments or concerns in the Github repo[6]. [1]: https://hub.docker.com/r/maxking/mailman-core/ [2]: https://hub.docker.com/r/maxking/mailman-web/ [3]: https://github.com/maxking/docker-mailman [4]: https://asynchronous.in/docker-mailman/#release [5]: http://semver.org/ [6]: https://github.com/maxking/docker-mailman/issues [7]: https://github.com/maxking/docker-mailman/wiki -- thanks, Abhilash Raj

1 0

GitLab 9.3 feature
by Barry Warsaw June 22, 2017

June 22, 2017

Gitlab 9.3 was just announced. I wonder if this would help with some of our problems coordinating between our various services, especially with the VCR tape generation. https://about.gitlab.com/2017/06/22/gitlab-9-3-released/?utm_medium=email&u… Cheers, -Barry

1 0

Breaking mailmanclient into seperate modules
by Abhilash Raj June 10, 2017

June 10, 2017

Hi All, Since we launched 3.1, I have been trying to add more docs in whatever free time that I get. I have mostly been focusing on making Mailman 3 documentation more easily acceible by both users and contributors. If you have any thoughts/questions/concerns about the current state or suggestions for improvement, please feel free to send them to this list or even me personally if you don't want to send it to everyone for some reason. One thing that I wanted to announce before I start is breaking up mailmanclient from one giant module (src/mailmanclient/_client.py) to seperate class based modules. The current setup works but is huge (1300+ LOC) and that is ok for now, but I want to add docstrings to classes/methods and it would definitely make it too big! I would love to hear what others think about this. -Abhilash -- thanks, Abhilash Raj

4 3

Mailman 2.1.24 released
by Mark Sapiro June 3, 2017

June 3, 2017

I am pleased to announce the release of Mailman 2.1.24. Python 2.4 is the minimum supported, but Python 2.7 is strongly recommended. This release has a few new features, a few i18n updates and several bug fixes. See the attached README.txt for details. Mailman is free software for managing email mailing lists and e-newsletters. Mailman is used for all the python.org and SourceForge.net mailing lists, as well as at hundreds of other sites. For more information, please see our web site at one of: http://www.list.org http://www.gnu.org/software/mailman http://mailman.sourceforge.net/ http://mirror.list.org/ Mailman 2.1.24 can be downloaded from https://launchpad.net/mailman/2.1/ http://ftp.gnu.org/gnu/mailman/ (not yet updated as of this writing) https://sourceforge.net/projects/mailman/ -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 0