Mailman 3 April 2017 - Mailman-Developers

before next release: disable backscatter in default installation
by Jo Rhett Nov. 7, 2022

Nov. 7, 2022

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

Discourse Integration
by Stephen J. Turnbull July 25, 2017

July 25, 2017

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

Encrypted lists predictable difficulties and implementation needs
by J.B. Nicholson April 19, 2017

April 19, 2017

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.

9 27

Patch: Allow definition of a default accept_these_nonmembers list
by Greg Veldman April 13, 2017

April 13, 2017

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

2 1

Deploying mailman3 using containers
by Abhilash April 10, 2017

April 10, 2017

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

1 0

Encrypted mailing lists: Tor project uses Schleuder
by Jan Jancar April 2, 2017

April 2, 2017

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

1 0