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:
# 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
# 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
/\ # PGP: 362056ADA8F2F4E421565EF87F4A448FE68F329D
/__\ # https://neuromancer.sk
/\ /\ # Eastern Seaboard Phishing Authority
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?
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:
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:
(Note: due to timezone skew, some of the tarballs may not be available on PyPI
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.
* 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
* 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
* 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
* 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.
* 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
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.
>However, I have just found two rather simple bugs:
>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.
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
Also, if you have a chance, can you look at
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.
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
>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.
On May 23, 2017, at 11:29 AM, Aurelien Bompard wrote:
>I hope you're having a great time at PyCon :-)
>Fixed already, thanks to the sprinter for closing the bug.
>I'll work on the documentation issues, but it shouldn't block you from
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".
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?
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
Is that something mailman(2|3) should support? To me it looks useful.
[*] 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
David Terni writes:
> I need to use the text of "description or information filed" used to
> describe the mailinglist and put this information in the firsts lines
> e-mail. Like the credits but on head of email.
> How I can do it?
You'll have to manually copy it to the "Header" options. There are
two of them, one each for the "Digest options" and the other for
If you want to do this programmatically across your site without the
manual copy, you'll need to write a script. It would also be possible
to patch the code to automatically pull in the "description" string,
but I doubt we want to support that in Mailman 2.
If you want help with those, just ask! (on list, there are several of
us who can help -- note we're mostly at PyCon so responses may be