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

Adding CSS to mailman archives
by Andrew Daviel 13 Feb '15

13 Feb '15

A little while ago (November 2012 probably) I changed a mailing list from Hypermail to Mailman and wanted to keep some of the look-and-feel of the archives, e.g. background colour and fonts. So I patched mailman 2.1.9 in CentOS 5 to include a CSS stylesheet link in each generated HTML page, replacing e.g. <BODY BGCOLOR="#ffffff"> with just <body> and adding e.g. body {background-color: #ffffff ; color: black; } in /pipermail/mailman.css, so that HTML style such as FONT and SIZE is removed from the Python code. (I only have one list on that server and didn't implement per-list style) I also changed a few things e.g. content-type to get zero warnings and errors from the W3C online validator. Now if I want to get DMARC functionality I'll have to jump past the RedHat/CentOS release and build 2.1.18, and re-patch for CSS. I was wondering if there was any interest in incorporating CSS into the official releases. -- Andrew Daviel, TRIUMF, Canada Tel. +1 (604) 222-7376 (Pacific Time)

7 17

Proposed incompatible changes to the REST API
by Barry Warsaw 30 Aug '14

30 Aug '14

I'm considering making two small incompatible changes to the JSON representation of list requests in the REST API. Here's what you currently get (from rest/docs/moderation.rst) for a held subscription request: >>> dump_json('http://localhost:9001/3.0/lists/ant@example.com/requests/1') address: anne(a)example.com delivery_mode: regular display_name: Anne Person http_etag: "..." language: en password: password request_id: 1 type: subscription when: 2005-08-01T07:49:23 I want to change the 'address' key to 'email' and remove the 'password' key, e.g.: >>> dump_json('http://localhost:9001/3.0/lists/ant@example.com/requests/1') delivery_mode: regular display_name: Anne Person email: anne(a)example.com http_etag: "..." language: en request_id: 1 type: subscription when: 2005-08-01T07:49:23 Unsubscription requests would just rename 'address' to 'email' (there is no 'password' key). E.g. from: >>> dump_json('http://localhost:9001/3.0/lists/ant@example.com/requests/2') address: bart(a)example.com http_etag: "..." request_id: 2 type: unsubscription to: >>> dump_json('http://localhost:9001/3.0/lists/ant@example.com/requests/2') email: bart(a)example.com http_etag: "..." request_id: 2 type: unsubscription I could (mostly) keep backward compatibility by just adding the 'email' key and keeping the 'address' key for now. The 'password' key is trickier because a subscription request's password is internally and randomly generated anyway, and I am going to remove this. I could keep 'password' with either the empty string or some random garbage. I'd like to just get rid of these and break compatibility, but if it would cause pain to Postorius or other tools, I can deprecate the old names and remove them in the future. Let me know what you think. Cheers, -Barry

3 3

[Soc2014-mentors] Students whose evals are not yet completed
by Stephen J. Turnbull 21 Aug '14

21 Aug '14

Terri Oda writes: > We have 11 students who don't yet have evals in melange: None from Mailman! Yay, Mailman devs, you rock!

1 0

Messages not sent out of mailman v3.0.0b4
by Alex Azevedo 19 Aug '14

19 Aug '14

Hey guys, we are using mailman 3.0.0b4 and we are currently have some problems with some messages that are not being sent out of mailman. I would like to know if in this version we have a command to check all messages queued on mailman, and what’s the expected behavior of mailman in this case. I mean, we’ve restarted mailman - these messages should be sent? the queue files should be deleted after that? I’m grep’ing and just found some entries of an specific message that i’m looking for on var/queue/pipeline/ dir. What does that means? Thanks , Alex

2 1

[CLI Project] Enhanced documentation to bring in Sphinx Compatibility
by Rajeev S 17 Aug '14

17 Aug '14

Hi, I would like to add one final revision before the firm pencil down date (18/08/2014). The r72 consists largely of the documentation enhancements for the mailman CLI. More documentation has been added and all the docs have been modified to make docs sphinx compatible.The docs have been restructured and reorganized so that they build up cleanly. Here is a link to r72 http://bazaar.launchpad.net/~rajeevs1992/mailman.client/mailmancli/revision…

1 0

One (almost) down, one to go
by Barry Warsaw 15 Aug '14

15 Aug '14

As you know, I'm keen on porting Mailman 3 to Python 3. I can't even start this effort until all of our dependencies are compatible with Python 3. We have two big blockers, restish (which provides the framework for the REST administrative API), and Storm (our ORM). Development for both libraries is meager to nonexistent, and neither have been ported to Python 3, with no known active work in progress to do so[*]. There's good news on at least one front! I've found a very nice REST framework that is both under active development and is already Python 3 compatible. It's called 'falcon': http://falconframework.org/ http://falcon.readthedocs.org/en/latest/ I've had some spare time recently to work on porting MM3 from restish to falcon and I've been very encouraged with the results. I've had to make a few minor modifications to falcon, so its public release won't work, but I'm hopeful this pull request will be successful: https://github.com/racker/falcon/pull/307 As I describe in the PR, there are plenty of superficial API differences between restish and falcon, but they are close enough that porting was a breeze. The big thing missing is restish-ish @child path segment traversal, but with the above branch, I was able to implement the most important bits of that in a subclass. This means I was able to preserve the essential code of MM3's REST implementation, adjust for the cosmetic differences, and substitute falcon for restish *with no changes to the public MM3 administrative API*. This last bit is crucial - neither mailman.client nor any other client of the MM3 API will have to change. I think I was even able to preserve the body strings of the HTTP error codes, even though I don't consider this part of the official MM3 API. You can play with the MM3 falcon branch here: https://code.launchpad.net/~barry/mailman/falcon Until and unless a version of falcon is released with my changes above, you'll have to git clone my falcon branch and install it into your virtualenv in order to use the MM3 branch. I found it a little tricky to get that working (due to some weird dependencies on specific versions of the 'six' library), but it's certainly doable because the full MM3 test suite passes. That's it for now. I won't merge the falcon branch into MM3 trunk, at least until my PR has been merged, and I'll urge the falcon maintainer to release a new version on PyPI to make it even easier to use. Now, about that SQLAlchemy port... :) Cheers, -Barry [*] I and others have tried to port restish. I've failed at least twice. ;)

1 0

[CLI Project] Code refactored as per feedback
by Rajeev S 13 Aug '14

13 Aug '14

Hi, As per the feedback from Steve, I have made changes to the code in following areas - The get_listing method has been moved to the lib/utils and has been rebuilt in a class *independent* way, and it works as good as before. - The connection checking has been moved to the connect function, without the need of making a database call, by checking the Mailman version using client.system - The addition of CLI colors has been made more generalized by making it a module level variable, with colors stored in a separate file. - Removed class attributes from Filter class, and changed them to arguments - All files now have a header acknowledging the support of Google, along with the names and contacts of mentors. Here is a link to the r70 http://bazaar.launchpad.net/~rajeevs1992/mailman.client/mailmancli/revision… I will be improving the error handling, as mentioned in the comments, with the next revision.

2 1

Mailman 3 RPMs anyone?
by Victoriano Giralt 09 Aug '14

09 Aug '14

Hi! it's been a long time since I wrote here (12 years according to my archives!), but I've never stopped reading :) I'm following with a lot of interest the progress of Mailman 3 (great job, BTW), kudos to all devs, including the GSoC youngsters), and I've seen that the Fedora infrastructure people have HiperKitty RPMs, but I've been thrashing Google up and down and haven't been able to find RPMs for Mailman 3. Does any one know if they exist? I'd like to give it a try with a very low traffic list server I have, but I'm growing older => lazier ;) :) and a seldom compile anymore. Thanks! -- Victoriano Giralt Central ICT Services Systems Manager University of Malaga +34952131415 SPAIN ================================================================== Note: signature.asc is the electronic signature of present message A: Yes. > Q: Are you sure ? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting annoying in email ?

3 2

Re: [Mailman-Developers] [CLI Project] Added Backup and Restore Tool
by Stephen J. Turnbull 09 Aug '14

09 Aug '14

Rajeev S writes: > Further, The mmclient.py *should have* a callable function for it > to work as a module entry point (a.k.a shell command), when > installed through `python setup.py install`. The created executable > does `import` the mmclient I still don't understand this. You have a module whose "main function" would perfectly servicable as "the executable" if you unwrap it (delete the "def main" statement and fix indentation), and in fact doesn't serve any purpose other than to be imported into a generated script? Seems to violate TOOWDTI to me.

2 2