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

[GSoC] Encrypted mailing lists
by Jan Jancar Aug. 29, 2017

Aug. 29, 2017

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

Re: [Mailman-Developers] Discourse Integration
by Stephen J. Turnbull Aug. 5, 2017

Aug. 5, 2017

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

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

Click CLI branch
by Barry Warsaw July 21, 2017

July 21, 2017

Just a quick note to mention that my big branch to adopt click for command line option parsing should now be done. https://gitlab.com/mailman/mailman/merge_requests/292 This will close #319 and #346 and make adding new `mailman` subcommands much easier. (We still need the bits to define additional search paths, and probably some better documentation that would be part of a general “Extending Mailman” section.) Along the way I think I’ve made several other improvements, including (I hope!) reducing or eliminating the occasional hangs we see on CI, speeding up the test suite a bit, and making things more robust. Please feel free to review it and play with it. It’s finishing CI now but I’ll hold off on merging it for a day or two. I’m especially interested to hear what Jan thinks for the plugin work he’s doing. The big downside could be that because this is such a big change, existing MPs may have to be rebased. It’s a big branch with lots of little sweater threads that took longer than I expected, but I should be done now, and I think it will be a good improvement to the code. Cheers, -Barry

4 13

Telling Apache about Mailman Rest API
by Erin Test July 12, 2017

July 12, 2017

We are currently using Mailman 2 for a number of mailing lists on our website (PHP based). We have mailing lists but need to have these people grouped in the same groups on our website and don't want to have to maintain 2 lists of the same people. I'd like to move us to Mailman 3 and take advantage of the REST API and write my own PHP code in interact with it. All of that being said I'm missing something in getting my basic setup finalized. I have a web server (Apache) running and have installed mailman core. When I try to access the REST API I get some variation of connection refused depending on what I'm using (python command line, curl, etc). I'm feeling like apache doesn't know where to point port 8001, and I don't know what to tell it. For the previous version of mailman you had to put and Alias and a Script Alias into the apache config. I've seen some documentation about what to put in for Postorius, but haven't found anything for just mailman. Any thoughts and/or pointers would be greatly appreciated. -Erin

3 11

Pluggable workflows
by Jan Jancar July 3, 2017

July 3, 2017

Hi all! As I note in one of my GSoC project updates, the PGP-enabled mailing lists require two new features from Mailman Core, both related to workflows. The first is to be able to inject steps into a subscription workflow to request the users pubkey before moderation checks. The second it to be able to require confirmation on all commands (to prevent replay attacks), although this could be avoided by storing the hashes from all the user sent signed commands. In this message I propose a way of refactoring the workflows into pluggable components. This post is also on my blog, for inline images I recommend going there: https://neuromancer.sk/article/10 Current workflows ----------------- Both of these requirements require changes to the way [Un]SubscriptionWorkflows and workflows in general work. Currently the subscription policy of a mailing list is determined by its `subscription_policy` attribute of the `SubscriptionPolicy` enum. That policy is enforced in the `SubscriptionWorkflow` state machine, which curently works with a queue of states, and looks like this: [See attached subscription_workflow.png] It is quite complex, and the `UnsubscriptionWorkflow` has much of the same code except the verification and moderation parts. Proposal -------- What I propose is to make the [Un]SubscriptionWorkflows, more generally workflows, pluggable components which would work on a stack state machine and be composed of mixins like so: [See attached subscription_workflow_split.png] This way a mailing list will have the name of its `SubscriptionWorkflow` component in the `subscription_policy` attribute. Which would mean for example an `SubscriptionPolicy.open` would be transformed into a class like so: @public @implementer(ISubscriptionWorkflow) class OpenSubscriptionPolicy(SubscriptionBase, VerificationMixin): """""" name = 'policy-open' description = 'An open subscription policy, only requires verification.' initial_state = 'prepare' def _step_prepare(self): self.push('do_subscription') self.push('verification_checks') self.push('sanity_checks') I believe this simplifies the policies and also allows chaining and composing of workflow steps, which would enable plugins to add custom subscription policies enforcing more steps/checks during the [un]subscription process. For example an organization-only mailing list could add a check that checks for the subscribing address in the organization database, therefore removing the need for manual moderation of subscriptions. This should also allow for requiring confirmation of all commands, by attaching a workflow instance to them. For the membership commands, this would be the corresponding [Un]SubscriptionWorkflows, and for other commands it would be currently disabled/empty workflow. Then a plugin could set the confirm workflow on commands it needs to. Comments? --------- I am currently working on this as a MR [1], although I am not sure if this is the right track to go on with workflows, so feedback/help is appreciated. I think something to split the monolithic [Un]SubscriptionWorkflows would be a nice thing in Mailman Core, as they share a lot of the same code and are overly complex for what they are, a linear series of checks with some skipping possible. [1]: https://gitlab.com/mailman/mailman/merge_requests/299 Cheers, -- Jan ______________________________________________________ /\ # PGP: 362056ADA8F2F4E421565EF87F4A448FE68F329D /__\ # https://neuromancer.sk /\ /\ # Eastern Seaboard Phishing Authority /__\/__\ #

1 0

Re: [Mailman-Developers] Error in configuring hyperkitty
by Mark Sapiro July 2, 2017

July 2, 2017

On 7/2/17 1:04 PM, ADITI GUPTA wrote: > > I am getting this on injecting email. > "mailman.interfaces.configuration.MissingConfigurationFileError: > ~/Documents/dev/mailman/mailman-hyperkitty/mailman-hyperkitty.cfg " . > > I am trying this in mailman.cfg file : > [archiver.hyperkitty] > class: mailman_hyperkitty.Archiver > enable: yes > configuration:~/Documents/dev/mailman/mailman-hyperkitty/mailman-hyperkitty.cfg > > I am not able to figure out that why it is not able to find the > configuration file. Perhaps because its home directory is not yours. Try an absolute path without ~ -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 0

Error in configuring hyperkitty
by ADITI GUPTA July 2, 2017

July 2, 2017

Hello, I tried to inject an email through command line to the archive queue but am unable to do so. I am using this command "mailman inject -q archive -f email.txt gsoc-demo(a)systers.org" . When I try to inject in "bad" queue, I am able to see the email in the bad queue folder. How can I see the email in the hyperkitty ui? I am getting this on injecting email. "mailman.interfaces.configuration.MissingConfigurationFileError: ~/Documents/dev/mailman/mailman-hyperkitty/mailman-hyperkitty.cfg " . I am trying this in mailman.cfg file : [archiver.hyperkitty] class: mailman_hyperkitty.Archiver enable: yes configuration:~/Documents/dev/mailman/mailman-hyperkitty/mailman-hyperkitty.cfg I am not able to figure out that why it is not able to find the configuration file. Thank You, Aditi ᐧ

1 0