Mailman 3 August 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

Multilingual Support
by sj boss 30 Aug '17

30 Aug '17

Can someone brief on the technologies that were used to provide multilingual support to mailman and how were they implemented ?

1 0

[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

Plugins
by Barry Warsaw 27 Aug '17

27 Aug '17

As part of his GSoC project, Jan Jancar implemented a plugin architecture for Mailman Core. I really liked a lot of it, and it serves as the basis for a set of my own tweaks on top of his branch. I think it’s very close to being ready to merge so I wanted to give folks here a heads up, especially if you don’t follow the GitLab MRs too closely. For reference, here’s Jan’s original MR: https://gitlab.com/mailman/mailman/merge_requests/288 Here’s my MR that builds on top of that. My current intent is to land this MR instead: https://gitlab.com/mailman/mailman/merge_requests/308 It may not be terribly helpful at this point to scour the MR’s comments. Instead, please read the documentation on plugins here: https://gitlab.com/mailman/mailman/blob/3572b11c2d42de0fa749786d35df5e660b2… GitLab does a passable job of rendering this, but it will look even better once this MR lands and the RTD docs are built. Notably, you’ll miss the “literal includes” which show how some of the configuration files and hook modules will look. Check out the branch and run `tox -e docs` to see the locally rendered page, or just view the source of the MR. You should be able to get enough of a gist about how it’ll work. Comments welcome, either here or in MR!308. Cheers, -Barry

1 0

Mailgun email libraries
by Barry Warsaw 15 Aug '17

15 Aug '17

Hi folks - apologies for the cross-posting; there is some intersection on the topic so I don’t want to leave anyone out. This past weekend, I was at PyBay 2017 and attended an excellent talk by Christine Spang, founder and CTO of Nylas, an email syncing platform. They’ve been using Mailgun’s Flanker library for email address and MIME parsing. Flanker is Apache 2.0 licensed although unfortunately only Python 2 currently. Here’s a blog post about it, along with their GitHub repo: http://blog.mailgun.com/we-just-open-sourced-flanker-our-python-email-addre… https://github.com/mailgun/flanker This is mostly an FYI email since I’ve only had time to read the blog post and briefly skim the docs, but there may be interesting things we can learn from their work. Cheers, -Barry

1 0

Re: [Mailman-Developers] Discourse Integration
by Vaibhav Lohani 05 Aug '17

05 Aug '17

Tom Browder wrote: > I'm happy just to hear about discourse. > > Without additional fancy new integration features not yet available, can > Discourse just be made to work now as is on the same server as MM3? I don't think it can be as of now without some modifications in the code. But will try to implement at least one way binding from mailman to discourse as soon as possible. Thanks and Regards, Vaibhav Lohani

1 0

Re: [Mailman-Developers] Discourse Integration
by Tom Browder 05 Aug '17

05 Aug '17

On Sat, Aug 5, 2017 at 09:21 Vaibhav Lohani <vbnlohani(a)gmail.com> wrote: > Stephen J. Turnbull wrote: > I'm happy just to hear about discourse. Without additional fancy new integration features not yet available, can Discourse just be made to work now as is on the same server as MM3? If so, I will probably try it after I get my MM3 working. Thanks. -Tom

1 0

Re: [Mailman-Developers] Discourse Integration
by Stephen J. Turnbull 05 Aug '17

05 Aug '17

Vaibhav Lohani writes: > Stephen J. Turnbull <turnbull.stephen.fw(a)u.tsukuba.ac.jp> wrote: > > What sort of integration do you have in mind? > > The idea is to have a two way binding sort of integration, where the > conversations can be carried out in discourse as well as mailing list > mode. The big issue here is that Discourse provides a centralized server, which means that conversations can be serialized properly, and you can even be notified if somebody else is replying at the same time. Mailing lists are asynchronous, so that posts often "cross in the mail". While these two modes are *fundamentally* incompatible, so cannot be perfectly merged, it's important that the two systems behave as much like each other as possible. In particular, you can't assume that mailing list subscribers will be using a browser. Many people use dedicated mail clients. Also, once you've got the basic syncing functionality down, it would be interesting to see if you could provide a mail protocol for manipulating Discourse features (likes, badges, etc) via the email interface. (This might be almost trivial if Discourse already provides such a protocol for email.) > the mailman rest api should not be opened publicly, The Mailman REST API is there to be used. The problem is that access is not authenticated at this point: anyone who can access it has the run of the installation. So everybody who has access to the REST API is effectively the site manager. Since you are planning to host the Discourse and Mailman instances on the same server, this should not be a problem. But you should be aware that that Mailman API will be firewalled from the Internet in any public instance for the foreseeable future. Hope this helps. Steve

2 1

Re: [Mailman-Developers] Mailman3 integration
by Jan Jancar 01 Aug '17

01 Aug '17

On 08/01/2017 04:22 PM, Nouha ouerheni wrote: > Hello Team , > > I configured mailman suite following this guide > http://docs.mailman3.org/en/latest/devsetup.html and now I want to > configure MySQL and postfix . I will appreciated if there are some > documents to provide to cotinue the intergration of mailman3 . > > ps : The web interface works correctly . > > Thanks in advance > Ms Ouerheni Nouha You can have a look at: http://docs.mailman3.org/en/latest/config-core.html both MTA and database configuration is covered there. Cheers, -- Jan ______________________________________________________ /\ # PGP: 362056ADA8F2F4E421565EF87F4A448FE68F329D /__\ # https://neuromancer.sk /\ /\ # Eastern Seaboard Phishing Authority /__\/__\ #

1 0

Mailman3 integration
by Nouha ouerheni 01 Aug '17

01 Aug '17

Hello Team , I configured mailman suite following this guide http://docs.mailman3.org/en/latest/devsetup.html and now I want to configure MySQL and postfix . I will appreciated if there are some documents to provide to cotinue the intergration of mailman3 . ps : The web interface works correctly . Thanks in advance Ms Ouerheni Nouha

1 0