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
Bhavishya Desai wrote:
> Now I would like to know(specifically) what are some other threats,which
> could effect this and any difficulties with implementation.
I imagine that the encryption and/or hash algorithms will change over time
as encryption is broken and people figure out ways to create hash
collisions. Therefore I'd imagine keys will change over time.
I'm guessing this carries some consequences:
- the list key will change over time, therefore:
- old subscribers need to be alerted to the new list key.
- MUAs need to be able to make use of the current list key (perhaps the
list accepts posts under the old key for a limited time to give subscribers
a chance to switch to using the new key).
- subscribers' keys will change over time, therefore:
- there needs to be an easy way for a subscriber to get the list to
accept posts under the subscriber's new key.
- list archives raise interesting questions:
- if the goal is to never let a list post travel unencrypted, I guess
the list archives will be encrypted too?
- each archive post will be signed+encrypted with the current list
key. Therefore each archive message will be decrypted and re-encrypted at
each list key change?
- yes: this implies a bigger and bigger decryption/re-encryption
job at each list key change as a list archive grows. Presumably this task
will become computationally intensive at some point, possibly beyond the
scale of being done at all for very large mailing lists carrying large list
posts.
- no: each archive post will be untouched after sending. Therefore
archives will feature a set of list posts signed+encrypted with whatever
list key was current at the time that post was sent out.
- thus old list public keys must be kept around and published
forever so archive readers can decrypt/verify signatures of archived posts?
- yes: this carries some questions about GPG policy (below).
- no: how will this work?
- GPG policy issues: the above raises questions about GPG:
- will GPG keep old encryption algorithms and hash algorithms around
(perhaps warning not to use them for new keys, and only using them for
decryption as needed)?
- or users going to need to retain old versions of GPG to handle
verifying archive list posts old encrypted & signed with list keys (I don't
see this working out well)?
It's possible there is something fundamental about this entire process I do
not understand and therefore I've completely missed something about this
process which led me down a path I should not have gone down. If that's the
case, please do let me know where I went wrong.
Thanks.
Hi,
I run a site where it is useful to have a small list of users
who should be able to email every list. Rather than manually
adding them by hand each time I make a new list, it would be
nice to be able to define a value in mm_cfg.py that would get
set at create time. The attached patch makes this a configurable
item and sets the default to an empty list (as it is now).
If you think this is useful functionality, feel free to include
this. If not, I'll just throw it out there in case anyone else
has the same need and might find it useful.
This patch is against version 2.1.23.
--
Greg Veldman
IT Infrastructure Services, Purdue University
gv(a)purdue.edu | (765)-496-2456
Hi All,
I have been working for the past two weeks on trying to create a
solution to easily deploy Mailman 3 in production. For those interested,
you can find the instructions about how to use my work at
http://asynchronous.in/docker-mailman/. I have tried to document the
process as much as possible.
This is still a work in progress, but I have a working deployment[1]
using these containers. I try to keep the deployment updated with the
github repo, but there is no automated deploy happening there so
sometimes it gets out of sync.
While this is aimed to finally become a production ready method to
deploy mailman 3, it is still not there. All I can say at this point is
that it works. I have tried my best to document everything and I keep
updating the documentation whenever I feel anything needs more clarity.
I would love some feedback to improve the process or documentation. You
can open issues on the github repo[2].
Currently, container images are built from the master branch of the
gitlab repos and are thus not branded as stable. I am waiting for 3.1
release to add a stable tag to the images.
[1]: https://mail.araj.me/
[2]: https://github.com/maxking/mailman
--
thanks,
Abhilash Raj
Hi Mailman Developers.
Considering the recent debate on this list regarding the possible
uses and usefulness of an encrypted Mailman mailing list, I tried
to look for orgs / groups that already use or are looking for an
encrypted mailing list. To see what they use / what would they
like to use / what required features they need / what nice to haves
they might want.
My first idea was Tor Project's private mailing lists, they have a
few security / organization related lists that are private [1].
They noted my idea was similar to Schleuder, which they started
using just recently [2].
I had few other people message me, most use Schleuder [3] and one use of
custom patched Sympa installation [4]:
> We have a project based on Sympa to integrate PGP support, the backend
> is completed and we still have some frontend parts open. We started
> with the project some time ago out of frustration of schleuder and
> the lack of the userinterface. We choose Sympa because of the high
> performance mail processing, however, the frontend is not very nice
I think that an organization such as the Tor Project, with their high
security requirements, using encrypted mailing lists means that the interest
in encrypted mailing lists is well-founded.
[1]: https://trac.torproject.org/projects/tor/wiki/doc/emailLists
[2]: https://lists.torproject.org/pipermail/tor-project/2017-March/001047.html
(and responses)
[3]: https://schleuder.nadir.org/
[4]: https://www.sympa.org/
Cheers,
--
Jan
_________________________________________________
OpenPGP: 362056ADA8F2F4E421565EF87F4A448FE68F329D
https://neuromancer.sk
