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

Dec 15th Mailman/Postorius/Hyperkitty hackathon
by Terri Oda 29 Nov '12

29 Nov '12

Well, our last online hackathon was sufficiently fun that Florian and I think we should do it again. So... You're all cordially invited to join us on #mailman on freenode on Saturday Dec 15th to do some Mailman-related hacking, project planning, and maybe some task creation for GSoC 2013. I'll be in Albuquerque on US Mountain time (UTC -700) and will probably be online from around 10am-11pm, as well as probably some the night before. Possibly helpful: http://timeanddate.com/worldclock/meetingtime.html?month=12&day=15&year=201… Mark your calendars! Terri

2 1

First alpha release of HyperKitty
by Aurélien Bompard 29 Nov '12

29 Nov '12

Hello Mailman devs ! HyperKitty, the Mailman 3 archiver, is advancing at a reasonable pace, and the time has come for its first alpha release. The code has been published on PyPI : - http://pypi.python.org/pypi/HyperKitty/ - http://pypi.python.org/pypi/KittyStore I've also written some installation and development documentation (with Sphinx), it's online at ReadTheDocs.org: http://hyperkitty.readthedocs.org/ If you're interested in HyperKitty, want to test it, or even contribute to it, it's now pretty easy, just follow the procedure described in the doc. Django hackers, and even regular Python hackers, will find it quite common. Please report any bug you can find on our tracker project page: https://fedorahosted.org/hyperkitty/newticket I hope you'll like it ! Aurélien -- http://aurelien.bompard.org ~~~~~~ jabber: aurelien(a)bompard.org "Millions long for immortality who do not know what to do with themselves on a rainy Sunday afternoon." -- Susan Ertz

2 1

Using bracketed prefixes in subject as filters
by Stephen J. Turnbull 24 Nov '12

24 Nov '12

Gordon P. Hemsley writes: > Thus, a subject line that begins "[css3-fonts]" will be assumed to > be about only the css3-fonts spec, [...] and not, say, the > css3-flexbox spec (subject lines prefixed with "[css3-flexbox]"). > > To handle this, the Mailman archive interface would provide an option > to filter only on particular prefixes (as well as messages that don't > have any prefixes), allowing a user of the archive to use it as they > otherwise would, but filtering the output such that they only see the > messages they want to see, instead of the whole archive. This would not be a big deal to implement in HyperKitty (though I don't personally have the necessary sum of time and interest). If you can wait until next August for product, it would make an excellent GSoC project, I suspect, and probably you could get a patch for Mailman 2's Pipermail archiver from the same GSoC project. > In addition, it would be helpful to allow mailing lists to > automatically prefix subject lines when the message is sent to an > e-mail address using a plus alias. > > For example, sending mail to www-style+css3-fonts(a)w3.org would prefix > the subject line of the message with "[css3-fonts]" in the message > sent to subscribers and in the archive, whereas sending mail to > www-style+css3-flexbox(a)w3.org would prefix the message with > "[css3-flexbox]". Yuck. (That's a technical term. :-) This is rather un-Pythonic (violates the "there should be one (and preferably only one) obvious way to do it" principle, AKA "TOOWTDI"). The conventional way to configure this in Mailman would be to have two normal mailing lists (css3-fonts and css3-flexbox), and one umbrella list (www-style) which subscribes to the css-* lists but doesn't receive posts directly. People who prefer to have the server make decisions for them would subscribe directly to css-* lists. Those who prefer to filter themselves would subscribe to www-style. > > It should also be allowed to have multiple prefixes on a message, [...]. > Now, I understand that this is likely a huge undertaking, but I think > it would go a long way to helping users with large and diverse mailing > lists. It's still not a huge undertaking, and would be suitable for a GSoC project IMO. However, this can also easily be handled by umbrella lists; you just cross-post to the various sub-lists. In the case of Mailman 3, it should also be possible to de-dupe automatically at the server side for subscribers with multiple subscriptions. This would be a GSoC- scale project too. For Mailman 2, it *would* be a pretty big project to de-dupe accurately, although "sibling lists" can help with this.

1 0

Using bracketed prefixes in subject as filters
by Gordon P. Hemsley 23 Nov '12

23 Nov '12

I filed a request for enhancement about using bracketed prefixes in subjects as filters: https://bugs.launchpad.net/mailman/+bug/1082495 Barry mentioned that I should raise the issue with regard to the dlist discussion, I presume because my proposal overlaps and/or conflicts with it. However, the only things I know about what a "dlist" even is has been garnered from skimming the four messages on the topic in the archive, and it's not clear to me they my idea is necessarily compatible with dlists. (They seem to be exclusive proposals that may handle the same usecase.) I've only just subscribed to this list to participate in this discussion, and my knowledge of the inner workings of mailman is fairly limited. But I present to you the contents of the RFE I filed, in order to facilitate discussion: =========== Many large mailing lists use bracketed prefixes in subjects as a way to filter messages into smaller buckets, allowing some subscribers to read all mail sent to the list while allowing others to filter messages (in their mail client) to read only the messages they are interested in. For example, the W3C's www-style mailing list uses these tags to filter messages based on which CSS spec they refer to. Thus, a subject line that begins "[css3-fonts]" will be assumed to be about only the css3-fonts spec, with a target audience of only those interested in that particular spec and not, say, the css3-flexbox spec (whose subject lines would be prefixed with "[css3-flexbox]"). To handle this, the Mailman archive interface would provide an option to filter only on particular prefixes (as well as messages that don't have any prefixes), allowing a user of the archive to use it as they otherwise would, but filtering the output such that they only see the messages they want to see, instead of the whole archive. In addition, it would be helpful to allow mailing lists to automatically prefix subject lines when the message is sent to an e-mail address using a plus alias. For example, sending mail to www-style+css3-fonts(a)w3.org would prefix the subject line of the message with "[css3-fonts]" in the message sent to subscribers and in the archive, whereas sending mail to www-style+css3-flexbox(a)w3.org would prefix the message with "[css3-flexbox]". It should also be allowed to have multiple prefixes on a message, and having such messages be treated as if they had any prefix individually. In terms of plus aliasing, there are two ways to handle it: (1) allow aliases to specify multiple prefixes in a plus alias using some separator (e.g. a comma: www-style+css3-fonts,css3-flexbox(a)w3.org); or (2) detecting and intercepting when a single message was sent to multiple e-mail addresses with different plus aliases for a single mailing list (e.g. sending the same e-mail to both www-style+css3-fonts(a)w3.org and www-style+css3-flexbox(a)w3.org), treating it as a single message with multiple subject prefixes when sent to subscribers or stored in the archive. Now, I understand that this is likely a huge undertaking, but I think it would go a long way to helping users with large and diverse mailing lists. [EDIT: It appears the W3C may not actually use Mailman. But my point is still the same, so take my usage of W3C e-mails as a hypothetical example, if necessary.] =========== (My first thinking on the matter arose when dealing with the WHATWG mailing list, which I know uses Mailman. I don't subscribe to any W3C mailing lists right now, so I didn't realize that W3C may not use Mailman; it was only my use of the W3C archives that prompted me to file my original idea as a Mailman RFE.) Regards, Gordon -- Gordon P. Hemsley me(a)gphemsley.org http://gphemsley.org/ • http://gphemsley.org/blog/

1 0

Re: [Mailman-Developers] Mailman 3.0 fresh install - problems from python interpreter
by Chris Cargile 12 Nov '12

12 Nov '12

In case others might be interested and appreciating a bit of help recalling what the search feature's development status is at the moment, this email spawned from a thread in June 2012, here: http://www.mail-archive.com/mailman-developers@python.org/msg12921.html > > On Mon, Nov 12, 2012 at 2:36 PM, Chris Cargile <follybeachris(a)gmail.com>wrote: > >> ** >> I have been facing some of the installation/configuration/CLI issues >> Jessy mentions and agree the documentation could call out a bit more >> explicitly the proper steps but all the same good progress is being made! >> >> I'm hoping to complete the same 'create new mailing lists' step that >> Jessy pointed to >> http://packages.python.org/mailman/src/mailman/commands/docs/create.html, >> but I did not install via the python-installation procedure.. rather, I >> completed the Ubuntu tutorial located here: >> https://help.ubuntu.com/12.04/serverguide/mailman.html >> >> A mailman instance is successfully running, but this installation has >> left me without (as far as I can find) certain bin/ commands to be run in >> the interpreter, including mailman (as in, e g: 'mailman info'). I am >> wondering if there is a simple way to access the functionality described in >> the python docs pages, such that importing the various zope,etc modules >> will work in the CLI, without rebuilding mailman from scratch (using the >> python build-out procedure) >> >> I hope I can make this work, but seeing as how my end-goal is to better >> learn the basics of a programming language that is probably better-position >> for future viability (-->Python) than ones I'd taken up previously (ie: >> php), in addition to developing for the mailman utility, I will remain in a >> good position either way :) >> >> - my end-goal with this endeavor is the create a script that accepts >> mlist as the argument and generates a separate file for each email >> (pickle?) in the list archive. Achieving this will allow me to more easily >> create the search interface I'm after which I'm hoping will become a >> proof-of-concept implementation for the "search engine for archives" >> to-do list feature <http://list.org/todo.html>. >> >> As I interpret this goal, another way of saying this I think is: "it >> would be great if list administrators could drop-in a module to deploy an >> html form-search interface that indexes previous archives, in addition to >> allowing mail-archive.com to archive future messages to the list." >> > >

1 0

Mailman 3: dlist integration
by Terri Oda 12 Nov '12

12 Nov '12

I suspect the person to answer this is Barry, but I'm sending to the developers list just in case. I'm working through getting dynamic sublists (dlists) integrated into Mailman 3 (probably targeting the 3.1 release) and I've got a question: where should the thread name be stored? Does that go with the message? Does it need to go in a separate table with message+list as keys? Some background: Dynamic sublists is an Mailman 2.1 extension that systers uses so that mailing list subscribers can subscribe or unsubscribe to individual conversations on a mailing list. It's sort of like a fancier, more automated version of topics, where users can start new conversations at will by sending to mailinglist+new(a)example.com. This is in contrast to topics, which need to be set up by the admin in advance. It's a pretty neat feature and one they've been using for quite a long time, so it's well-tested and because "I wish I could unsubscribe from this stupid thread" is a pretty common requested feature, I'm hoping we can use dynamic sublists to replace topics in Mailman 3. In a dlist-enabled list, every message is part of a thread, as determined by the posting address used (mailinglist+threadname(a)example.com or +new for a new thread whereupon we create a new name). We need to somehow have the thread name passed around with the message, and I'm *guessing* that just putting that metadata in with message is the right choice, but I'm worried that message doesn't seem to have listinf stored so maybe the message is list-independent and could be sent to multiple lists and thus be on multiple threads at once. (Incidentally, the other stuff we need to store is the user default preference for new threads, which can go in their preferences, and the user/list/thread preference for threads they've specifically subscribed or unsubscribed from, which will have to be a separate table.) So, um, Barry... where would you prefer that I stick the thread metadata? Terri

3 3

Mailing Lists and Non-ASCII Addresses
by Patrick Ben Koetter 07 Nov '12

07 Nov '12

Just published a few minutes ago: <http://www.rfc-editor.org/rfc/rfc6783.txt> Probably worth to read before pushing MM3 out. p@rick -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Joerg Heidrich

3 2

Listadmin and other alternate interfaces for Mailman
by Terri Oda 07 Nov '12

07 Nov '12

Since I now treat every gathering of hackers as an excuse to get people to tell me things about Mailman, I was chatting with folk at the GSoC mentor summit and my friend V was telling me that she really likes Listadmin as a nicer interface to Mailman: http://freecode.com/projects/listadmin Seems like something I might have to look at and learn some lessons from before we're done with postorius dev. Anyhow, it got me thinking: does anyone here use any other add-ons that they think I should know about? :) I used to have a set of greasemonkey scripts for my own lists, and I'll bet I'm not the only one. Terri

4 5