Mailman 3 August 2018 - 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

Hyperkitty MR Feedback - Hiding private lists from index
by Jake Scaltreto 31 Aug '18

31 Aug '18

I'm hoping for some feedback a MR I submitted for hyperkitty a few days ago: https://gitlab.com/mailman/hyperkitty/merge_requests/110 My initial goal was just to make it possible to hide private lists from the index for users who don't have access. However I expanded the scope a bit to also show private lists when sorting by popularity and activity IF the user is subscribed (currently all private lists are hidden from those views for all users). In the MR the behavior is enabled via a Django setting and is off by default. This mostly preserves the existing behavior, except I did make it such that superusers always see all lists. It occurred to me though that it may be desirable to have the "new" behavior be the default from a user experience perspective. Anyway, I just wanted to get some feedback on the approach as this is my first MR against mailman. Thanks! -Jake

1 0

hypekitty
by Catonano 28 Aug '18

28 Aug '18

is this the right place for questions about Hyperkitty ? The Hyperkitty mailing list doesn't accept registration and the irc channel doesn't work

2 1

GDPR disclaimers and redaction in mailman 2
by John Levine 01 Aug '18

01 Aug '18

Someone has asked me about some adjustments mailman 2 related to what they think they have to do for GDPR compliance. One is to add some checkbox stuff to agree at subscription time that you understand what info you're providing. I expect this could be spliced in the same way CAPTCHAs are. Another is to provide different views of what lists exist depending on what IP address you're connecting from, so internal lists are only visible on the internal network. Has anyone done stuff like this? I think they're running 2.15, probably possible to update to more recent versions of 2.x but 3.x is not in the cards. Tnx. R's, John PS: I am definitely not looking for arguments about whether the GDPR needs this. It's their money, they get to say what they want.

3 3