Mailman 3 October 2021 - 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

Mailman 2.1 security release
by Mark Sapiro 26 Oct '21

26 Oct '21

A couple of vulnerabilities have recently been reported. Thanks to Andre Protas, Richard Cloke and Andy Nuttall of Apple for reporting these and helping with the development of a fix. CVE-2021-42096 could allow a list member to discover the list admin password. CVE-2021-42097 could allow a list member to create a successful CSRF attack against another list member enabling takeover of the members account. These attacks can't be carried out by non-members so may not be of concern for sites with only trusted list members. In any case, I am planning to make a 2.1.35 release and to post a patch for those who don't want to upgrade to address these issues. This is scheduled for Tuesday, October 19. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 5

Hyperkitty and mailman-hyperkitty releases
by Abhilash Raj 12 Oct '21

12 Oct '21

Hello Everyone, I have just tagged and released Hyperkitty 1.3.5 and mailman-hyperkitty plugin 1.2.0 to PyPI. This release includes some changes in the authentication between mailman-hyperkitty plugin and Hyperkitty. For that reason, it is important to upgrade both Hyperkitty and mailman-hyperkitty plugin to the latest versions, or it could result in a broken installation. This release of Hyperkitty has bugfixes, some new features and some security enhancements. A full list of changes is available at: https://docs.mailman3.org/projects/hyperkitty/en/latest/news.html#news-1-3-5 The release tarball is available at PyPI: https://pypi.org/project/HyperKitty/#files https://pypi.org/project/mailman-hyperkitty/#files You can upgrade your installations by running: pip install mailman-hyperkitty hyperkitty -U After the upgrade, please make sure to run these commands: https://docs.mailman3.org/en/latest/upgrade-3.2.html#post-upgrade Also, make sure to restart Mailman Core after upgrading mailman-hyperkitty plugin. Finally, many thanks to all the people who contributed to this release. -- thanks, Abhilash Raj (maxking)

1 0

FYI: Another attempt at describing From: rewriting
by Alessandro Vesely 06 Oct '21

06 Oct '21

Hi, Douglas Foster posted this draft to the IETF. For discussion, see: https://mailarchive.ietf.org/arch/msg/dmarc/Fp1nnmBc242kxvxM7seVwoQ6ccU Best Ale ---------- Forwarded message --------- From: <internet-drafts(a)ietf.org> Date: Sun, Oct 3, 2021 at 8:14 PM Subject: New Version Notification for draft-fosterd-dmarc-compliant-mailing-lists-00.txt To: Douglas Foster <dougfoster.emailstandards(a)gmail.com> A new version of I-D, draft-fosterd-dmarc-compliant-mailing-lists-00.txt has been successfully submitted by Douglas Foster and posted to the IETF repository. Name: draft-fosterd-dmarc-compliant-mailing-lists Revision: 00 Title: DMARC Compliant Mailing Lists Document date: 2021-10-03 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/archive/id/draft-fosterd-dmarc-compliant-mailing-lists… Status: https://datatracker.ietf.org/doc/draft-fosterd-dmarc-compliant-mailing-list… Html: https://www.ietf.org/archive/id/draft-fosterd-dmarc-compliant-mailing-lists… Htmlized: https://datatracker.ietf.org/doc/html/draft-fosterd-dmarc-compliant-mailing… Abstract: Mailing Lists often make changes to a message before it is retransmitted. This invalidates DKIM signatures, causing a DMARC test on the RFC5322.From addres to fail. A DMARC-compliant mailing list is one which uses member alias addresses to identify the document as sent by a specific author via the mechanism of the list. An appropriate aliasing mechanism will not only prevent DMARC FAIL, but will also allow messages between members, will look natural to senders and recipients, and will allow list organization domains to advance to p=reject. This document describes an aliasing approach which meets these goals. The IETF Secretariat

1 0