Mailman 3 September 2008 - 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

"Orignal" MySQL Member Adaptor - 1.71
by Kyrian (list) 07 Jan '09

07 Jan '09

All, I finally managed to find some vestige of free time after midnight (hardly the best time to be coding...) recently, and accordingly put out a new version of my MySQL MemberAdaptor. I have no time, and little motivation (no customers wanting to use it at the present time) to test it, so I haven't, but you're welcome to try it out. It should according to the docs I found, provided I've applied them correctly, fix the non-ASCII character encoding problems (I've relied on the assertions about list members to cover that angle, and just checked encoding on the 'user supplied' parameters to various function calls). Now would be a good time for someone to send me a Python language reference book ;-) However since I've changed development environment since the last version, it's possible that various things have gone wrong (certainly the version numbering has gone mad between RCS and CVS/Eclipse), so don't do it in a production environment. I've put it here, as version 1.71, whatever that might actually mean: http://www.orenet.co.uk/opensource/MailmanMysql/ Incidentally, since Fil seems to be taking all the credit for what I started I think he should actually put a proper credit in there for me, linking to my business website at http://www.orenet.co.uk/ rather than the vague passing mentions that are in the docs/code of his version of the system at the present time. With luck I will be able to coax one of my customers into 'sponsoring' further development of the MySQL Adaptor with proper integration into Mailman in a sane way that is agreed by everyone instead of (as seems to be the case from what little of this list I have had time to read) just going off on its own sweet way and reducing the likelyhood of acceptance into the main code base of Mailman, but I am not sure how that will go. If anyone else wants to sponsor my time to code this thing better and further, then just email me. Best of luck with it, whatever happens. More updates in whichever year I manage to find spare/free time. Yours Sincerely, Kev Green.

7 19

Looking for Help
by Thomas M Foley 07 Oct '08

07 Oct '08

I have a client who is looking to move to an In-House mailing system. They are currently using a commercial web company called vertical response, http://www.verticalresponse.com. They would like some assistance in developing some back end tools and interface to do tacking on their mailings. If someone out there is interested in working with us on this project, please let me know. You can call my office or send me back an email. The client is ready to move forward and any help would be appreciated. I would prefer to go with Mailman on this project. I think it can handle what they want to do, but I just need help on the backend and interface. Thanks in advance. Thomas M Foley TMF Consulting LLC 212.473.2325 O thomas(a)tmfconsulting.net

2 1

Getting Started with Mailman Development
by Morgan Reed 28 Sep '08

28 Sep '08

Hi All, I'm currently looking at creating a fork of mailman to add support for GPG encrypted mailing lists, however given that mailman is a rather complex beast I'm having trouble figuring out where to start. Can somebody direct me to a good structural overview of how all the bits and pieces of mailman fit together? Thanks in advance, Morgan

4 9

Analysis of MM2.x Admin slowness with, (not "because of") MySQL adaptor(s).
by Kyrian (List) 27 Sep '08

27 Sep '08

Folks, Okay, I've actually picked through the code (both the MySQL adaptor and Fil's code) on this one and made a couple of observations, and I think I've definitively found the culprit here. We're looking at Mailman/Cgi/admin.py here. Lines 871 onwards, for between 5 and 20 lines depending on whether you're looking at Fil's modified code or the distributed version. This is the case (although different code surrounds the offending bits) up to and including the latest 2.1.11 version, and of course only if I read the Python right ;-) First pass of the code suggested that Fil's code was a bit wide of the mark, although it would work for searches. This is because the patched code only uses his getMembersMatching() method if we are not given an empty search string (and the code uses the same search method of getMembers() with an empty string as a defined search string), so listing all members in order with Fil's code will be missing the "names" array, and be fast, but my original will populate the "names" array, and be cripplingly slow for large lists. This, however is not the source of the problem. Fil's code seems to only call his getMembersMatching() method to populate the 'all' array, and disregards the users "names" array, which is populated in the normal version. I don't suppose he's bothered about people's 'real name' values ;-) This is the root cause of the problem, because it's doing a foreach-type loop through all the members retrieved by getMembers() to get their names individually, rather than making a single database call to get them all, which would seem to be the cause of the slowness. It is even noted by Barry that this bit of code sucks: # BAW: There's got to be a more efficient way of doing this! names = [mlist.getMemberName(s) or '' for s in all] Therefore I would propose a change to admin.py that calls a member adaptor's mlist.getAllMemberNames() if it exists/is implemented, otherwise defaults to doing the aforementioned instead, which is ok for pickles. The obvious caveat is that getAllMemberNames() MUST return members in the same order as the getMembers() function or it'll cause funny things to happen. As long as we know what to sling into the SQL 'ORDER BY' that'll be fine though. I'd assume ordering by lower case address is the way it happens by default?? I suppose you could just move that offending line of code into a getAllMemberNames() function in OldStyleMemberships.py too though? This would allow SQL to do its thing in two shots (once for names, and once for addresses) rather than loads of individual user queries (once for addresses, loads of times for names), and remove the bottleneck, while also minimising the required mangling of core code. It would also allow backward compatibility, just *very slow* backward compatibility by not calling the new method in the adaptor ;-) Comments? K. -- Kev Green, aka Kyrian. E: kyrian@ore.org WWW: http://kyrian.ore.org/ Linux/Security Contractor/LAMP Coder/ISP, via http://www.orenet.co.uk/ DJ via http://www.hellnoise.co.uk/

1 0

(old) bug in gate_news
by Markus Grabner 26 Sep '08

26 Sep '08

Hi! As requested in http://www.gnu.org/software/mailman/devs.html, I would like to note that I noticed a bug in gate_news (mailman-2.1.11), for which a fix has been proposed a couple of years ago. I applied this fix, and it solved the problem for me, so I suggest that this fix goes into the next mailman release if the developers don't see potential problems with it. More details are here: https://bugs.launchpad.net/mailman/+bug/265941 Kind regards, Markus -- Markus Grabner - Computer Graphics and Vision Graz University of Technology, Inffeldgasse 16a/II, 8010 Graz, Austria Phone: +43/316/873-5041, Fax: +43/316/873-5050 WWW: http://www.icg.tugraz.at/Members/grabner

3 2

Re: [Mailman-Developers] [Mailman-checkins] [Branch ~mailman-coders/mailman/2.2] Rev 1007: Since Mailman 2.1.1, 2.0.x outstanding subscription and held message
by Barry Warsaw 19 Sep '08

19 Sep '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sep 19, 2008, at 11:07 AM, noreply(a)launchpad.net wrote: > ------------------------------------------------------------ > revno: 1007 > committer: Mark Sapiro <mark(a)msapiro.net> > branch nick: 2.2 > timestamp: Fri 2008-09-19 08:03:18 -0700 > message: > Since Mailman 2.1.1, 2.0.x outstanding subscription and held message > requests have not been migrated properly. This is fixed. > Bug #266106 (sf998384). Wow. Thanks for fixing this Mark! - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkjTwV0ACgkQ2YZpQepbvXEVnQCfZhY8th9AtNoVlZk1YrKNvqM/ Q58AoILZJWxKVIXtjqk8vepQ6qYxvDEz =NWoB -----END PGP SIGNATURE-----

1 0

Tracker migration to Launchpad
by Barry Warsaw 16 Sep '08

16 Sep '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We're planning on migrating the current SourceForge trackers for the Mailman project to Launchpad, this Thursday at 1200 UTC. Expect the conversion to take several hours. The SF trackers will still be available during the conversion, though I will try to remove as much write access to them as possible. Please be aware that any changes that occur to SF issues during the conversion will be lost. I'll send another announcement when the conversion is complete. Cheers, - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEUEARECAAYFAki9RGYACgkQ2YZpQepbvXHVzgCYpzfBr9n7WwGqoBRyIRXiqTA2 4wCeLCg5VfMH79n6JJh23Cu+UxccGbk= =UBTV -----END PGP SIGNATURE-----

1 2

Enabling topics with only one topic: can't exclude topic?
by Stephen J. Turnbull 07 Sep '08

07 Sep '08

Context: The bzr developers are considering splitting their Mailman list into a -dev and a -user list, but they don't like that because they feel it would split their community in an undesirable way. So the proposal is to create a [codereview] topic which gets workflow-related posts (nitty-gritty coding style comments as well as automatically generated messages from a patch queue manager). Most users aren't going to be interested in these, but will be interested in bug reports and their resolutions, and in design discussions, which will not get an explicit topic. So many users would like to select *only* messages *without* explicit topic. The quoted post claims that appears to be impossible. Seems like a bug to me, either in the topic feature (if it *is* impossible) or in the page template documenting usage. John Arbash Meinel writes: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Martin Pool wrote: > | I've set up a Mailman topic "codereview", and people can use this to > | opt out of getting review related mail. (Or, if you want, to get only > | code reviews, but that would look a bit strange.) > | > | Messages will be classified into this topic if they have either > | [merge] or [codereview] in the Subject, or in a Keywords header, or in > | a pseudoheader in the top 5 lines of the message body. > | > | I have to say that the interface through which users can configure > | this is not so obvious and people who want it may not find it. But, > | it's there and we can see how it goes. > | > | If anyone wants to try it out: go to > | <https://lists.ubuntu.com/mailman/options/bazaar>, enter your address, > | and scroll to the bottom of the resulting page. If it doesn't work as > | intended please let me know. > | > > So, I was reading through the description, and I found this: > > | If you do not select any topics of interest, you will get all the messages > | sent to the mailing list. > > And the description below that is: > | Do you want to receive messages that do not match any topic filter? > | > | This option only takes effect if you've subscribed to at least one > topic above. > > > So there is a problem. There is no way to say that don't want codereview > messages. > > You can get *only* codereview by checking the box, and then saying you > don't want unmatched messages. > > You can get all messages by either not checking codereview, or by > checking it and saying you *do* want unmatched messages. > > It seems that the only way to get what non-reviewers want, is to have > multiple topics, perhaps one as a dummy "ijustwanttodisablecodereview" > topic. > > Further, I *do* like the idea of sending merge requests directly to BB, > and having it forward the messages to the list. I think it could be an > optional feature for people who know the BB address. I suppose that I'm > a bit concerned with BB's stability if we do implement this. Because if > BB goes down, then all of our submissions get circular filed (trashed > until bounce, or whatever). > > John > =:-> > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (Cygwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkiZrLAACgkQJdeBCYSNAAPEcgCeIpAOODfcymjQ4y9x3MAO4tyT > Y4gAoJe/WS0vmrSsZ8GGz40OyIVGegrf > =OjCX > -----END PGP SIGNATURE----- >

3 5