Mailman 3 May 2020 - 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

Re: conversation about 2->3 upgrade path
by Abhilash Raj May 24, 2020

May 24, 2020

On Tue, May 19, 2020, at 6:18 PM, Sumana Harihareswara wrote: > On 5/19/20 6:16 PM, Sumana Harihareswara wrote: > > On 5/17/20 10:05 PM, Abhilash Raj wrote: > >> On Sat, May 16, 2020, at 2:04 PM, Sumana Harihareswara wrote: > >>> https://mastodon.technology/@brion/104152363969142016 > >>> > >>> Hi folks - I figured you might want to know about this small Mastodon > >>> conversation. > >> > >> Thanks for letting us know, Sumana! I am not on Mastodon, so probably > >> won't be able to reply there. > >>> Seems like the world of folks who are currently using Mailman 2 lists > >>> includes people who need: > >>> * materials to help their sysadmins understand how and why to upgrade > >>> to 3 > >> > >> We do have migration docs for system admins: > >> https://docs.mailman3.org/en/latest/migration.html > >> > >> Although, the current migration involves running a command for all the > >> lists one-by-one and then import the Archives separately. The process > >> could be made a bit better IMO, but I haven't had time to prioritize > >> the effort recently. Maybe I should pick up my WIP MR again[1]. > >> > >> [1]: https://docs.mailman3.org/en/latest/migration.html > >> > >>> * major hosting companies like Dreamhost to start offering Mailman 3, > >>> and an easy upgrade path > >> > >> I am happy to help any hosting companies to migrate their Mailman 2 > >> users off to Mailman 3. I haven't had any previous conversations, but > >> was wondering if there are any representatives on this list to start > >> off a conversation perhaps? > >> > >> The process can be fairly easily automated I think. > >> > > > > > > Thanks! I replied to the thread and some conversation is continuing there. > > -Sumana > > One response in that thread: > > > to close the loop on the dreamhost bit, i got a response to the > effect that postorious doesn't expose enough settings via web UI, so > until the web configuration experience is workable for them dreamhost > won't be planning a migration. All the useful ones are now exposed, pending one (emergency flag for MailingLists), which is also exposed in master branch but not released yet. Unless they mean other "settings" of some sort, then they'd need to be a bit more specific since everything is a setting ;-). > > -Sumana > -- thanks, Abhilash Raj (maxking)

1 0

Postorius, Hyperkitty new release candidates
by Abhilash Raj May 24, 2020

May 24, 2020

Hi Everyone, I am pleased to announce a couple of more releases: - Postorius: 1.3.3rc1 Changelog: https://docs.mailman3.org/projects/postorius/en/latest/news.html#rc1 Download: https://pypi.org/project/postorius/1.3.3rc1/ - Hyperkitty: 1.3.3rc1 Changelog: https://hyperkitty.readthedocs.io/en/latest/news.html#rc1 Download: https://pypi.org/project/HyperKitty/1.3.3rc1/ - Mailmanclient: 3.3.1rc1 Changelog: https://docs.mailman3.org/projects/mailmanclient/en/latest/src/mailmanclien… Download: https://pypi.org/project/mailmanclient/3.3.1rc1/ - Django-mailman3: 1.3.3rc1 Changelog: https://gitlab.com/mailman/django-mailman3/-/blob/master/README.rst Download: https://pypi.org/project/django-mailman3/1.3.3rc1/ Python 3.6+ and Django 2.0+ is supported for all of them. Django 3.0 support for Hyperkitty requires manually upgrading a dependency (django-haystack>=3.0b2, once a stable version of this has been released, it shouldn't require manually upgrading). There are tons of bug-fixes across the board and some new features. Biggest visible change is switch to Bootstrap 4, which has been long pending for us. Bootstrap 4 completely changes the CSS grid model using the new Flexbox. There might be some small changes or breakages when using on mobile. Please report such issues to us via Gitlab! Some other notable changes are in Postorius, which includes many more list settings exposed include content filtering settings, bounce processing (which was added in the previous release of Mailman Core) settings and some other ones. You can now also specify a reason when rejecting held messages. There was also a gnarly bug, which caused the name of some members to be the string "None". For the longest time, I couldn't figure out the reason for it, but it ended up being a simple fix in mailmanclient's json serialization of display_name, which would result in Python's None value being passed as string "None" to Mailman's API for subscription. There is also better support for filtering visible lists based on the current vhost, which I see a few people are already waiting for from mailman-users list. A full changelog has been added to each project in the top. These are still pre-releases and if you are installing via pip, you would need the `--pre` flag, for e.g. $ pip install --pre --upgrade postorius hyperkitty As with all other releases, these have also been running on mail.python.org and lists.mailman3.org for some time now, so it should be relatively safe to upgrade to. Stable releases for this is now scheduled in 1 week, hopefully, next weekend. -- thanks, Abhilash Raj (maxking)

1 1

Re: conversation about 2->3 upgrade path
by Abhilash Raj May 18, 2020

May 18, 2020

On Sat, May 16, 2020, at 2:04 PM, Sumana Harihareswara wrote: > https://mastodon.technology/@brion/104152363969142016 > > Hi folks - I figured you might want to know about this small Mastodon > conversation. Thanks for letting us know, Sumana! I am not on Mastodon, so probably won't be able to reply there. > Seems like the world of folks who are currently using Mailman 2 lists > includes people who need: > * materials to help their sysadmins understand how and why to upgrade to 3 We do have migration docs for system admins: https://docs.mailman3.org/en/latest/migration.html Although, the current migration involves running a command for all the lists one-by-one and then import the Archives separately. The process could be made a bit better IMO, but I haven't had time to prioritize the effort recently. Maybe I should pick up my WIP MR again[1]. [1]: https://docs.mailman3.org/en/latest/migration.html > * major hosting companies like Dreamhost to start offering Mailman 3, > and an easy upgrade path I am happy to help any hosting companies to migrate their Mailman 2 users off to Mailman 3. I haven't had any previous conversations, but was wondering if there are any representatives on this list to start off a conversation perhaps? The process can be fairly easily automated I think. -- thanks, Abhilash Raj (maxking)

1 0

Mailman 2.1.33 released.
by Mark Sapiro May 7, 2020

May 7, 2020

For the third time in as many days I have released a new Mailman 2.1 version. This one is 2.1.33 and fixes another content injection vulnerability. See the attached README.txt and the bug report at https://bugs.launchpad.net/mailman/+bug/1877379 for details. Again, for those who don't want to install the full update, the above bug report contains a simple patch to fix the security issue. As noted Mailman 2.1.30 was the last feature release of the Mailman 2.1 branch from the GNU Mailman project. There has been some discussion as to what this means. It means there will be no more releases from the GNU Mailman project containing any new features. There may be future patch releases to address the following: i18n updates. security issues. bugs affecting operation for which no satisfactory workaround exists. Mailman 2.1.31 is the first such patch release, Mailman 2.1.32 is the second and Mailman 2.1.33 is the third. 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 https://www.gnu.org/software/mailman http://mailman.sourceforge.net/ Mailman 2.1.33 can be downloaded from https://launchpad.net/mailman/2.1/ https://ftp.gnu.org/gnu/mailman/ 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

Upcoming Mailman 2.1 security release
by Mark Sapiro May 6, 2020

May 6, 2020

A content injection vulnerability in Mailman 2.1 has been discovered and reported by Vishal Singh. This is a heads-up that I plan to release Mailman 2.1.30-1 on Tuesday, May 5 to fix this issue. At that time I will also post details of the issue and a patch that can easily be applied to existing installations. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 7

RFC: Config complexity [was: I have issue where it does not send ...]
by Stephen J. Turnbull May 2, 2020

May 2, 2020

Moved from mailman-users(a)mailman3.org.[1] Mark Sapiro writes: > For what it's worth, The actual mail list management, i.e. > receiving and delivering posts, only involves Mailman core and your > mailman suite config file is only for Postorius and HyperKitty and > doesn't affect Mailman core. Aaargghh! We should not be doing this to users. If we're going to have a "mailman suite" project, there should be a single file for configuration of *all* installed components, at least for "vanilla" installations. (It's bad enough that in many installations one has to configure the webserver three times, once in a front-end like Apache or nginx, once in a wsgi dispatcher like uWSGI, and once in Django.) I understand that it may take a ton of work and backward incompatibility to implement this, or even make substantial progress, so (until I have time to do it myself) I'm not seriously suggesting it at this time. It occurred to me that we could have a short comment at the top of every config file that lists all the config files and what they control, with one marked "(this file)". Or something. WDOT? Steve Footnotes: [1] https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message…

4 3