Mailman 3 November 2015 - 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

Let's try to package mailman3 in Debian!
by Pierre-Elliott Bécue 21 Feb '16

21 Feb '16

Hey, As a Debian fanboy and also a mailman addict, I'd like to try packaging it in Debian. As I'm not a DD and as I'm not in a hurry, I'd like to take some time to think about what would be relevant. For that, I'd like to have some help. And I was suggested to come here and ask. I decided to use https://gitlab.com/groups/mailman as a basis for my work. First of all, to create the source package, I've to think about what to put in it. It seems that if I want to have a good source package, I need 5 repos : - Mailman - HyperKitty - Postorius - HyperKitty - MailMan Plugin - MailmanClient My first question is "Am I right?". And the second one is whould I consider looking into mailman-suite-doc and also have it in the source package? On another way, I also see that there is a standalone postorius repo and also some django project files for HyperKitty in another one. I have the impression it is more designed for people to work on as standalone - forkable projects for other features, and so I wouldn't need them in a Debian package. Am I also right? Thanks for your answer, I hope I'll be able to make this package look as you'd like. :) Cheers, -- PEB

5 13

Mailman 3 production setup testbed
by Stephen J. Turnbull 25 Nov '15

25 Nov '15

Andrew Hodgson writes: > I want to set up as a production environment, the idea is we will > be getting people used to the MM3 interface and ways of working > before we eventually migrate when 3.1 becomes available. I would > have posted this to the users list, but recent traffic on there > regarding MM 3.0 has been redirected to the dev list. FYI, this is the kind of thing that would be perfectly reasonable and useful to post to Mailman Users. It deals with general Python, email, and OS-level knowledge and doesn't really require even knowing that Mailman 3 is a collection of three programs integrated by a REST API. I'll deal with finding an appropriate place in the docs, no need to repost to MM Users. > My confusion relates to the virtual environment that I create. I > am running from the dedicated MM3 user I created, and I am looking > to expand the bundler from the user’s home directory in /home (for > example). When I create the virtual environment, the files are all > held in this directory, and I really want the MM3 to be installed > system wide as this will be the only program running on this > machine. "System wide" doesn't really have any meaning in Unix, and especially not for pure network services. What benefits do you expect from a "system wide" installation? > Do I even need to create a virtual environment at all? No, but it is still recommended. The basic problem is what Windows developers refer to as "DLL hell" -- different programs require different versions of the same external software. AFAIK, several of the dependencies of the Mailman 3 suite are still specified as exact versions, not "this version or later", because this helps ensure a constant environment for bug diagnosis. >From your point of view, what this means is that if you upgrade Mailman using a new virtual environment for each upgrade, you can revert to an older version simply by stopping the new version and starting the old version. (Assuming file formats don't change, of course, but at least Mailman detects those and for upgrades will upgrade them automatically.) It takes a few more minutes for each installation, but can save many hours of hair pulling downtime due to dependency conflicts at installation and mysterious bugs at runtime. Because Mailman 3 is still evolving rapidly, I suspect you may find new versions very attractive. I would put my money on the virtual environment approach until a Mailman 3 package is available in Debian "testing" if I were you. At that point, the whole issue evaporates. > Are there any other guides relating to setting up MM3 for a purely > production environment with minimal dependencies? Probably not yet. If you decide to go that way, please do tell us about your experience. :-)

2 1

unsubscribe
by Chuck Peters 24 Nov '15

24 Nov '15

unsubscribe

1 0

Mailman 3 production setup testbed
by Andrew Hodgson 24 Nov '15

24 Nov '15

Hi Guys, I am a MM3 newbie coming from MM 2.1. I use Debian as my distro of choice. I am trying to follow the docs at: http://mailman-bundler.readthedocs.org/en/latest/ I want to set up as a production environment, the idea is we will be getting people used to the MM3 interface and ways of working before we eventually migrate when 3.1 becomes available. I would have posted this to the users list, but recent traffic on there regarding MM 3.0 has been redirected to the dev list. My confusion relates to the virtual environment that I create. I am running from the dedicated MM3 user I created, and I am looking to expand the bundler from the user’s home directory in /home (for example). When I create the virtual environment, the files are all held in this directory, and I really want the MM3 to be installed system wide as this will be the only program running on this machine. Do I even need to create a virtual environment at all? Are there any other guides relating to setting up MM3 for a purely production environment with minimal dependencies? Thanks, Andrew.

1 0

Mozilla funding opportunity for Mailman work
by Sumana Harihareswara 20 Nov '15

20 Nov '15

Hi Cabal. I'm sorry that I've neglected Mailman so much for the past several months; I've just registered for PyCon 2016 and will be ramping up my participation especially leading up to that. Mozilla https://blog.mozilla.org/blog/2015/10/23/mozilla-launches-open-source-su pport-program/ has just announced that it wants to "identify up to 10 projects we rely on and can fund in a thoughtful, meaningful way by December 12th". They use Mailman and if we can identify useful ways they can spend that money to advance Mailman's development and usefulness to them (e.g., paying for someone's time to get packaging or localization to a better state), I'd be happy to take point on organizing that proposal. Again, regrets on my absence. -- Sumana Harihareswara http://brainwane.net

4 4

Please add multipart/signed to DEFAULT_PASS_MIME_TYPES
by Carlos Alberto Lopez Perez 19 Nov '15

19 Nov '15

Hi, By default, mailman tarballs (at least the 2.x ones) contain a Defaults.py file with this configuration: DEFAULT_PASS_MIME_TYPES = ['multipart/mixed','multipart/alternative','text/plain'] So, when someone enables filtering on a mailing list by mime-type, the default is to filter all emails not matching any of those 3 mime-types. Therefore, this is unfortunately filtering multipart/signed emails. multipart/signed is defined on RFC 4880 and 3156 and is the recommended way of signing mails with GPG: See http://wiki.gnupg.org/SignatureHandling As an example, this email is multipart/signed. This default causes trouble to people that signs their mails with GPG. I already had problems due to this default on the Alioth Debian mailing lists and on the WebKit mailing lists. Please, change this default by adding multipart/signed to the list of types allowed. Thanks.

4 5

ANNOUNCING: GNU Mailman 3.0.1
by Barry Warsaw 15 Nov '15

15 Nov '15

I'm happy to announce the first maintenance release of GNU Mailman 3. This version 3.0.1 release includes updates to the core, Postorius, HyperKitty, and mailman.client. The release matrix of versions is available here: http://wiki.list.org/Mailman3 You can find more information about the changes in each component by following the version links in that overview page. Enjoy, -Barry (on behalf of the entire Mailman development team)

1 0

Usenet gateway posting issue
by Mark Sapiro 12 Nov '15

12 Nov '15

Due to the recent death and reincarnation of mail.python.org, we had to find a new news server as a gateway to/from a few python.org lists. I ran into an issue with the server we are now using. This is described at <https://bugs.launchpad.net/bugs/1512866>. The issue has to do with posts that may arrive via email to a list and are thus gated to usenet. Posts which are gated from usenet to the list are just posted to the list and are never gated back to usenet. The issue is if a post arrives by email and already contains a Newsgroups: header, the gateway will ensure that the group it gates to is in the header, adding it if necessary. This can result in posts gated to usenet with a Newsgroups: header mentioning other groups in addition to the gating list's group. In our case, this seemed to cause a reject if the other group didn't exist on the news server. I thought about this and decided we shouldn't be gating posts to usenet for groups other than the one(s) associated with the list and that the correct fix is just to ensure that gated posts contain a single Newsgroups: header mentioning only the target group(s). Then it occurred to me that past behavior, in our case for example where python-list gates to/from comp.lang.python and python-announce-list gates to/from comp.lang.python.announce that one could post by email to only say python-list with a 'Newsgroups: comp.lang.python,comp.lang.python.announce' header, the post would be gated to the news server for both groups, and the next time the news server is polled the post would come back for both lists and be posted to python-announce-list (python-list would be bypassed because of X-BeenThere:). Note: that this scenario may or may not have 'Message-ID:' issues, but assuming it works, my question is is this scenario a feature that people actually use that I would break by only putting comp.lang.python in the Newsgroups: header of posts gated from python-list or is it potentially a bug that should be fixed. Does anyone have an opinion on this? -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 1

[gpg] encrypted list management plug-in
by efkin 11 Nov '15

11 Nov '15

hi devs! from calafou hacklab & friends we wanted to reimplement schleuder in python. speaking and speaking we arrived at the conclusion that maybe writing a plug-in for Mailman 3 could be a good solution: we contribute to a great project and we have encrypt mailing list for hacktivist people. first and obvious question: is there already an ongoing effort to achieve gpg encryption that we could join? if not: we thought this plug-in as a milter (mail filter) with added features for executing commands. after reading your Core docs, things are little bit more complicated: 1. the preprocess (and maybe postprocess?) of the messages could be done by what you call `chains` and `pipelines` 2. the command system could be implemented extending the already existing Mailman command system (`echo` and `end`). 3. it is just not clear how to prompt if encripton is desired in your ecosystem. our questions are maybe: * is there a plug-in way to tackle this problem? * do we really need to submit a merge request to the core instead of doing an optional debian package? * are we totally on the wrong way? :) thx for the support! best wishes! efkin. Calafou.

4 7