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

[GSoC] Encrypted mailing lists
by Jan Jancar 29 Aug '17

29 Aug '17

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 25 Jul '17

25 Jul '17

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

ANNOUNCE: Mailman 3.1.0 final!
by Barry Warsaw 26 May '17

26 May '17

Hello Mailpeople! On behalf of the entire team and all our wonderful contributors, I'm happy to announce the release of GNU Mailman 3.1 final. My deep thanks go to all the Mailman project sprinters at Pycon 2017 for getting us over the line! Two years after the original release of Mailman 3.0, this version contains a huge number of improvements across the entire stack. Many bugs have been fixed and new features added in the Core, Postorius (web u/i), and HyperKitty (archiver). Upgrading from Mailman 2.1 should be better too. We are seeing more production sites adopt Mailman 3, and we've been getting great feedback as these have rolled out. Important: mailman-bundler, our previous recommended way of deploying Mailman 3, has been deprecated. Abhilash Raj is putting the finishing touches on Docker images to deploy everything, and he'll have a further announcement in a week or two. Feedback is welcome: https://github.com/maxking/docker-mailman What is GNU Mailman? GNU Mailman is free software for managing electronic mail discussion and e-newsletter lists. Mailman is integrated with the web, making it easy for users to manage their accounts and for list owners to administer their lists. Mailman supports built-in archiving, automatic bounce processing, content filtering, digest delivery, and more. Mailman 3 is released under the terms of the GNU General Public License, version 3. The best places to start for all things related to this release: http://docs.mailman3.org/ http://www.list.org/ https://gitlab.com/mailman (Note: due to timezone skew, some of the tarballs may not be available on PyPI until tomorrow.) Happy Mailman Day, -Your friendly neighborhood cabal An overview of what's new in Mailman 3.1 ======================================== Feature parity with Mailman 2.1 ------------------------------- * You should be able to do just about everything that you could do in Mailman 2.1 *except* for topics and sibling/umbrella lists. Core ---- * Added support for Python 3.5 and 3.6 * MySQL is now an officially supported database * Many improvements with importing Mailman 2.1 lists * DMARC mitigations have been added, based on, but different than the same feature in Mailman 2.1 * The REST API requires HTTP/1.1 * A new REST API version (3.1) has been added which changes how UUIDs are interpreted, fixing the problem for some JavaScript libraries * Many new REST resources and methods have been added * Individual mailing lists can augment the system's header matching rules * `mailman create` now creates missing domains by default * `mailman digests` now has `--verbose` and `--dry-run` options * `mailman shell` now supports readline history * `mailman members` can filter members based on their subscription roles * A new template system has been added for all messages originating from inside Mailman. * The Message-ID-Hash header replaces X-Message-ID-Hash * New placeholders have been added for headers and footers * Unsubscriptions can now be confirmed and/or moderated Postorius/HyperKitty -------------------- * General U/I and U/X improvements * Many more features from the Core's have been plumbed through * We've adopted Django social auth logins and dropped Persona (since it's no longer supported upstream). You can now log in via Facebook, Google, GitHub, and GitLab. Backward incompatibilities -------------------------- * Core/REST: Held message resources now have an `original_subject` key that is not RFC 2047 decoded. `subject` is now RFC 2047 decoded. * Core/REST: If you've run pre-release versions from git head, and stored welcome and goodbye templates via REST, the template key names have changed backward incompatibility.

3 3

Re: [Mailman-Developers] Postorius and MRs for 3.1
by Barry Warsaw 24 May '17

24 May '17

On May 24, 2017, at 11:33 AM, Aurelien Bompard wrote: >Don't worry I'll do the releasing of HyperKitty when Mailman is up. Thanks! >However, I have just found two rather simple bugs: >- https://gitlab.com/mailman/mailman/issues/336 >- https://gitlab.com/mailman/mailman/issues/337 > >I have set the 3.1 milestone on them, and I think the 1st one should really >be fixed (I sent a merge request) before we release. > >What do you think? I'm reviewing these now. Follow ups on the issues. -Barry

1 0

Postorius and MRs for 3.1
by Terri Oda 24 May '17

24 May '17

Hi Florian, Your turn for the "last chance to tag things for 3.1" email now that Aurelien's weighed in. ;) (I'm cc'ing the rest of mailman-developers in case anyone else wants to advocate for a bug too...) I *think* we've got 3.1 tagged appropriately, which means that the unicode bug is the last big one, and I'd like to get the default preferences fixed for good (currently they display correctly but can't save). Do you have anything else that we should look at before we push out RC1? Also, if you have a chance, can you look at https://gitlab.com/mailman/postorius/merge_requests/159/ I put a question about address-based preferences and mailmanclient in there for you, but I could also use a second look for "what's the best way to fix it so these save properly?" if you have a chance. I've broken the django magic and need to override the save method I think. Terri

3 2

Re: [Mailman-Developers] Multiple REST servers
by Barry Warsaw 24 May '17

24 May '17

On May 19, 2017, at 07:59 PM, Aurelien Bompard wrote: >> Have you done any other analysis on where the bottlenecks are? Is it CPU, >> db, I/O? > >I haven't investigated properly but it seems to be the database (which >is on another host). That's interesting because most of that runs through SQLAlchemy. I wonder if it's a general problem with the way we integrate with that, or if there are specific queries that are inefficient. I have no doubt there's room for improvement on the latter, but we'd have to do the instrumentation to find out. >Interesting. I wonder if we can have SQLAlchemy play well with >asyncio, I haven't tried that before. Me neither! asyncio is pretty new, so we're seeing lots of efforts to async-ify more parts of the ecosystem. I don't know whether the SA folks are looking into that at all. A general search shows some interesting projects and discussions on the topic. >There is still a gunicorn.py file in the contrib directory, but I >haven't tested it either. I tried to get it to work but had problems. I'm really interested in seeing if we can leverage uvloop for improved performance. -Barry

1 0

Re: [Mailman-Developers] HyperKitty issues and MRs for 3.1
by Barry Warsaw 23 May '17

23 May '17

Hi Aurelien! On May 23, 2017, at 11:29 AM, Aurelien Bompard wrote: >I hope you're having a great time at PyCon :-) We are! >Fixed already, thanks to the sprinter for closing the bug. > >I'll work on the documentation issues, but it shouldn't block you from >releasing 3.1. Great! And thanks for taking a look at the milestoned issues. It looks like HyperKitty has no more open issues or merge requests milestoned to 3.1, and you're confirming that all HyperKitty systems are "go". Cheers, -Barry

1 0

HyperKitty issues and MRs for 3.1
by Barry Warsaw 23 May '17

23 May '17

Hi Aurelien, We're missing you and Florian at the Pycon sprints, but we have a good group of folks, and we're psyched to release Mailman 3.1 this week. We're noticing that there are no bugs or MRs assigned to milestone 3.1 for HyperKitty so our question is whether that's accurate and we can do a release, or whether we need to assign some to 3.1 and fix them before the release. Here are some issues we have questions about. #104 - Server Error (500) upon login with duplicate email addresses (we're thinking maybe just turning that into a non-500 error?) #127 - Server Error (500) upon signup #128 - hyperkitty/setup.py should require Django<1.11 (Assigned to a sprinter, should be easy) There are also a bunch of merge requests which we're unsure about. Can you do a quick triage and assign anything needed to 3.1 for HyperKitty? Thanks! -Barry

2 1

Signaling One-Click Functionality for List Email Headers
by Patrick Ben Koetter 20 May '17

20 May '17

Greetings, I'm not sure if anyone has followed development of RFC 8058 "Signaling One-Click Functionality for List Email Headers" located at <https://tools.ietf.org/rfc/rfc8058.txt> and brought this topic up on this list. Is that something mailman(2|3) should support? To me it looks useful. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein

6 7