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

Announcing the new wiki.list.org
by Barry Warsaw 03 Mar '15

03 Mar '15

I am very happy to announce our new wiki! If you go to wiki.list.org you will see our shiny new Moin-based wiki. We are retiring the old Confluence-based wiki at the end of February. Until then, you can access it at old-wiki.list.org. Our very huge thanks go to Paul Boddie who did the amazing conversion work, almost single-handedly reverse engineering the Confluence dump through several iterations. Of course, our thanks also go to John Viega, owner of the list.org domain and Mailman's inventor for helping us get the DNS flipped over. Thanks too to everyone who gave feedback on the new wiki, contributed to the old wiki, and continue to help edit this important resource for the Mailman community. Our thanks also go to the Python Software Foundation and the PSF infrastructure team for providing us with the virtual machine hosting our new wiki. If you had write access to the old wiki and want it again for the new wiki, you will have to re-submit a request to mailman-cabal(a)python.org. Please be sure to register with wiki.list.org and provide us with your user name. With this conversion, I am happy to say that GNU Mailman is finally fully hosted on free software. While we appreciate the years of service donated to us by Atlassian and Contegix, it's important that we set an example by utilizing an entirely free software stack for our development and outreach. The wiki was our last remaining non-free bits. Let the gardening begin! Cheers, -Barry (On behalf of the GNU Mailman steering committee) P.S. We are working on the SSL certificate for the new wiki. Stay tuned.

6 21

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

Signed Mailing Lists
by Abhilash Raj 30 Jan '15

30 Jan '15

Hi all, I worked in GSoC 2013 (thanks to Steve and Barry!) to add support for verification and re-signing of emails in mailman3. I am working on the branch to rebase it with the recent changes in the trunk and make it ready to be merged. The reason for this post is to discuss about the current feature set and possible enhancements/changes to it (which probably was not included in my proposal due to time-limit of 3 months). * A new `signature` rule checks for validity and age of the signature in all the emails and appropriate action is taken according to the configuration variable `default_badsignature_action` which can also be configured from postorius. * For now, I have added this rule to the default pipeline which may or may not be desirable. I think if someone wants to accept unsigned emails as well, one can set `default_badsignature_action` to always `accept`. Thoughts on this? * Each list has a public/private key pair that can be generated from Postorius, the public is displayed in ascii-armor on the `list-summary` page on the postorius from which it can be imported. I think would be easy to just publish the public key to a keyserver (not implemented yet). * Users can import their public key from the keyservers (just paste your key-id and hit import) or by copy-pasting the ascii-armor'ed format in postorius. * A `signmessage` handler signs the email using its own private key (yes even those which are already signed). The structure of the email was decided so that both the signatures can be verified with maximum *unix based mail-clients. I tested with notmuch, mu4e, claws-mail, thunderbird (was able to verify the outermost signature iirc, but not the inner one i.e. by the actual sender). The structure is of this form: multipart/signed multipart/mixed multipart/signed text/plain application/pgp-signature text/plain application/pgp-signature For other structures that I tested with refer this[1] post. * For now all the outgoing messages are signed by default. Is a setting required to make this optional? Anything else that could be added or changed in this implementation? [1]: http://asynchronous.in/2013/09/12/message-structure/ -- thanks, Abhilash Raj

1 0

Launch band & song
by Andrew Stuart 30 Jan '15

30 Jan '15

Hey Barry If you are thinking of launching at Pycon, what do you think of the idea of playing some music - you’re a guitarist right? Maybe there could be “The Mailmen” - a Mailman band - if you can rope in some other musicians. Perhaps the song could be a play on Elton John’s “Rocket Man”. A bit of marketing theatre for the bloggers to post a Youtube video of. Would help to get the word out there about the launch. as

2 1

Mailman 2.1.19 release
by Mark Sapiro 30 Jan '15

30 Jan '15

I am pleased to announce the first release candidate for Mailman 2.1.19. Python 2.4 is the minimum supported, but Python 2.7 is recommended. This release has several new features, some newly implemented and some backported from the now truly defunct 2.2 branch - there is nothing left in that branch that isn't in this release. There are also bug fixes. See the attached README for more details. Associated with those changes are many things that have i18n impacts including new and modified strings in the message catalog, a new adminaddrchgack.txt template and a minor change to the admindbdetails.html template. I strongly encourage anyone with an interest in translations of Mailman to get this release and help with updating the translations. I plan to release the final 2.1.19 release at the end of February, and it would be good to have as many i18n updates as possible by then. Mailman is free software for managing email mailing lists and e-newsletters. Mailman is used for all the python.org and SourceForge.net mailing lists, as well as at hundreds of other sites. For more information, please see: http://www.list.org http://www.gnu.org/software/mailman http://mailman.sourceforge.net/ Mailman 2.1.19rc1 can be downloaded from https://launchpad.net/mailman/2.1/ http://ftp.gnu.org/gnu/mailman/ https://sourceforge.net/projects/mailman/ -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 0

Who is the "site administrator"?
by Andrew Stuart 26 Jan '15

26 Jan '15

Is this defined in any way? Is there any concept that a given Mailman user has “site admin rights”? Or is the concept of the “site administrator” not realised in the application and just considered to be someone with operating system level access to the system that Mailman is running on? thanks

5 12

TODOs for Mailman suite 3.0, PyCon sprint plans
by Sumana Harihareswara 25 Jan '15

25 Jan '15

I chatted with Barry a few days ago to clarify what we need to do if we want to release the Mailman suite, version 3.0, at the end of the PyCon sprints. The sprints are April 13th-16th, 11 weeks from now. I used what he said to update the TODO list for Mailman core, the client, Postorius, HyperKitty, the bundler, and the suite as a whole: http://wiki.mailman.psf.io/DEV/Mailman%203.0 If there are pieces that we ought to finish when we're together in person, maybe they ought to go here: http://wiki.mailman.psf.io/DEV/PyCon%202015%20Sprint -- Sumana Harihareswara http://brainwane.net

1 0

Heads up on pending Mailman 2.1.19 release
by Mark Sapiro 24 Jan '15

24 Jan '15

I will soon be packaging and announcing the first release candidate for Mailman 2.1.19. The details of changes since the 2.1.18-1 release are in the attached README. The reason for this heads up is there are many things in this release that have i18n impacts and I want to give as much notice as possible of these changes so that people who are interested in updating templates and the message catalogs for a particular language can hopefully get their changes in in time for the final release. If you are interested in helping with this, whether or not you are a current translator, see <http://wiki.list.org/x/MQ>. Many of the changes have to do with the fact that for several years, I have been maintaining the officially defunct 2.2 branch in parallel with 2.1. This branch had a number of features and fixes that had never been put in the 2.1 branch because of their i18n impacts. I have now decided to backport all those changes and finally abandon the 2.2 branch. These changes affect the message catalog and add a new adminaddrchgack.txt template and make a minor change to the admindbdetails.html template. I have also implemented new features that weren't in the 2.2 branch, but add new strings to the web admin UI. See the attached README for more on what all these changes are. The mailman.pot message template has been updated with all these changes and msgmerged with the various mailman.po files. All of this can be retrieved from the bazaar branch at <https://code.launchpad.net/~mailman-coders/mailman/2.1> at rev. 1520 (or later). -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 0

How can I run the REST tests against live servers?
by Andrew Stuart 24 Jan '15

24 Jan '15

I want to run the REST tests against my live Mailman server with its Postfix mail server and Postgres database, via: nose2 -v -P rest After many (many) hours of digging deep and figuring out how it works, I suspect at this stage that maybe the tests set up their own mock servers? If so, I’m guessing these mock servers are getting in the way of using the live servers and thus preventing the tests from running? Assuming it is correct that the tests are setting up their own mock http smtp ltmp responders, is there a way to turn this behaviour off so the tests will run against my live REST/Postgres/Postfix? thanks Andrew

3 12