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.
Mark your calendars!
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
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
It's still not a huge undertaking, and would be suitable for a GSoC
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.
I filed a request for enhancement about using bracketed prefixes in
subjects as filters:
Barry mentioned that I should raise the issue with regard to the dlist
discussion, I presume because my proposal overlaps and/or conflicts
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
I've only just subscribed to this list to participate in this
discussion, and my knowledge of the inner workings of mailman is
But I present to you the contents of the RFE I filed, in order to
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
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
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
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
[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.)
Gordon P. Hemsley
http://gphemsley.org/ • http://gphemsley.org/blog/
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:
> 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
>> but I did not install via the python-installation procedure.. rather, I
>> completed the Ubuntu tutorial located here:
>> 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."
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?
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?
Just published a few minutes ago:
Probably worth to read before pushing MM3 out.
[*] 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
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:
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.