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?
I know it might be a little early, but I'd like to talk about the plan
for Postorius (Mailman in general) releases moving forward.
Should there be more point releases? 3.1.X? Or just 3.X? Are releases
bound to Core releases (following core's release numbering?)? How often
do we do releases?
Every X merge requests and/or X months?
I'd like to know that just to organize issues/merge requests and so the
whole process can be planned a little more...
Would be also helpful to create this information in Gitlab milestones...
I have been working on containerizing Mailman 3 so that it becomes
easier to test and try Mailman 3. There are two images in total:
* maxking/mailman-core : This consists of Mailman Core and includes the
plugin to enable the Hyperkitty Archiver.
* maxking/mailman-web : This consists of a full Django installation and
run the Mailman's Web UI components. It has Mailman Client, Postorius
The images are built from the Dockerfiles hosted on Github in case
you want to look at it. You can find most of the documentation about
these images at https://asynchronous.in/docker-mailman/. The version of
the internal components included in each image is available here.
The images are versioned and the process is documented, please have a
look before you use them. Also, the images are signed and I encourage
you to verify them before using. The process of how-to verify is also
Docker Compose is a tool written in Python makes is very easy to deploy
connected-images and take the pain out of writing long long commands for
spinning of containers. There is a sample `docker-compose.yml` file in
the Github repository mentioned above which is kind-of tested to be able
to spin off these images in vanilla condition (without any
You can report issues, comments or concerns in the Github repo.
Since we launched 3.1, I have been trying to add more docs in whatever free time
that I get. I have mostly been focusing on making Mailman 3 documentation more
easily acceible by both users and contributors. If you have any
thoughts/questions/concerns about the current state or suggestions for
improvement, please feel free to send them to this list or even me personally if
you don't want to send it to everyone for some reason.
One thing that I wanted to announce before I start is breaking up mailmanclient
from one giant module (src/mailmanclient/_client.py) to seperate class based
modules. The current setup works but is huge (1300+ LOC) and that is ok for now,
but I want to add docstrings to classes/methods and it would definitely make it
I would love to hear what others think about this.