Hey folks, it looks like we're going to have a quorum of core developers at
Pycon 2012 in Santa Clara, so we will definitely be sprinting on Mailman 3.
We'll be primarily working on the integration of the core engine with the
official Django-based web ui. If you want to participate, kibbitz, or just
learn more about MM3, I highly encourage you to join us.
Remember, the Pycon sprints are free and you do not need to register for the
conference to attend. Please do sign up on this page if you're going to join
us though, so we can plan sprint room sizes and such:
If you haven't been to a Pycon before though, I highly recommend it. There
are tons of great speakers and presentations, some great tutorials before the
conference starts, and always excellent BoFs and other events. Attendance is
capped at 1500 though, so if you're thinking about it, JFDI already! :)
I was wondering how stable/reliable MM3 is at this point. Does anyone know (subjectively or objectively) how much testing it has received in the wild? How much internal testing has it gone through apart from the wonderful unit tests I've read about? According to Barry's alpha8 release announcement, it sounds like now is the time to start using it, so does that mean you all, as developers, consider it stable and ready to be put into production by large organizations?
What are the hopes and/or realistic plans for the beta period and GA?
Very curious, and thanks for any info,
I'm sorry to forward some very sad news about one of our own from the Mailman
community. If you've ever looked at the ACKNOWLEDGMENTS file you will see
this entry in the core contributors section:
Tokio Kikuchi, Mailman's weatherman
Tokio Kikuchi was instrumental in our early internationalization efforts. I
remember testing out one of his early patches which enabled Japanese support
in Mailman. At a Python conference years ago, I started the branch and was
delighted to see the familiar Mailman admin pages come up in Japanese. Of
course, I could not read it, but I happened to be sitting next to a native
speaker who confirmed that it was indeed correct Japanese. That made me very
happy, and I'm proud of his ongoing contributions to Mailman in general and
internationalization in particular. He will be missed.
If you would like to leave a note of your own, please see this page:
The following is forwarded with permission.
Begin forwarded message:
Date: Mon, 16 Jan 2012 14:22:43 +0900
From: Atsuo Ishimoto <ishimoto(a)gembook.org>
Subject: About Tokio Kikuchi
I'm Japanese Python developer. You can see my name as an anuthor of
Python's PEP 3138.
Now, please let me inform you that Mr. Tokio Kikuchi, famous open
source developer and one of Mailman contributor, died at 14, Jan by
It turns out that "hostname -s" does very different things on linux and solaris hosts. On linux, it harmlessly reports the hostname, without qualifying it. On solaris, it silently changes the host name to "-s". This seems to cause Mailman to start throwing away mail, with error messages like " Low level smtp error: (8, 'node name or service name not known'), msgid: xxxx"
Now, this difference in behaviour, between harmless and bizarre, is the stuff of the Unix-haters' handbook http://www.art.net/~hopkins/Don/unix-haters/preface.html
However, It seems to me pretty disastrous that Mailman should throw away mail just because its own hostname changed.
Postmaster, University of Sussex
+44 (0) 1273 87-3148
apologize for my posting to this list, but i would like to share an
idea i had some time ago.
Most of us are subscribted to several mailinglists, forums , irc and
using socialmedia sites like facebook and/ or twitter.
Would´nt it be a great idea if there was a mailman plugin whitch post
automaticily to a facebook fanpage/profile or group
or s special twitter account to share this information ?
Right now i go the the mailinglist archive of mailman, find the
message i would like to share, use an url shortener of my choice ,
keep the headline and tweet it.
Would´nt it be cool if this would be automated ? Is there a way todo
this or are you guys planing something like this in the future ?
Thanks for reading
-- Les enfants teribbles - research / deployment
Marc Manthey- Vogelsangerstrasse 97
50823 Köln - Germany
project : http://stattfernsehen.com
Please think about your responsibility towards our environment: Each
printed e-mail causes about 0.3 grams of CO2 per page.
Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).
On 5 Jan 2012, at 23:35, Monica Chew wrote:
> Hi Ian,
> On Wed, Jan 4, 2012 at 5:23 AM, Ian Eiloart <iane(a)sussex.ac.uk> wrote:
>> Now, if Gmail also prominently exposed the list-unsubscribe header, then the EU regulations on marketing messages would be satisfied. In my view, hiding the unsubscribe information in a menu isn't enough to satisfy the "easy to use" requirement, though it seems that Gmail does better than most vendors in this respect.
> The exposure is more than in the menu dropdown. If the message comes
> from a mailing list with good reputation, and the user clicks "Report
> spam", then Gmail offers to send an unsubscribe message to the mailto
> address in List-Unsubscribe. The reason we have the reputation check
> is that we do not want spammy senders to use the unsubscribe emails
> for list washing.
That strikes me as very odd. Actually, awful.
This will encourage users to think that the way to unsubscribe from a mailing list is to hit the "report spam" button. That's really bad news for responsible list providers. It's bad because when those same users go to another client (perhaps they've been asked for advice by a hotmail user, for example), they'll hit "report spam" and generate a spam report without getting the opportunity to unsubscribe. The two options need to be separately identified at the top level of the interface.
>> Finally, if Mailman allowed users to choose whether to get the footer added, and subject munged, then Gmail users might avoid these issues anyway. Mailman might provide a list of domains for which this was the default behaviour, and site admins should be able to manage such a list. Mailman might even provide updates for this list. Of course, it's complicated: for example I use Gmail, but with a vanity domain. And then I use the IMAP interface with a client that doesn't expose list headers.
>> My view is that a one-click setting to preserve DKIM might be useful, but it should carry a health warning saying something like: "If you're an organisation in the EU, and this list helps to promote your organisation, or keep people in touch with your organisation, then selecting this option may be in breach of your country's mail privacy laws." In fact, it may be illegal if you simply have a list subscriber in the EU.
> Hmm, this seems difficult to enforce. How would I know if a list
> subscriber were in the EU? Even if the member address were obviously
> not hosted in the EU, it could easily forward to an EU address.
Good question. The best thing is to assume there is an EU subscriber. It's good practice, in any case, to include an unsubscribe option with all marketing messages.
However, things will change when the list-unsubscribe header is exposed to most users, in a way that makes it easy for them to unsubscribe. So, if Outlook, Apple Mail, Thunderbird, Hotmail, Gmail, and Yahoo were to get this right, then it would be reasonable to *only* provide list-unsubscribe.
Postmaster, University of Sussex
+44 (0) 1273 87-3148
On Jan 05, 2012, at 05:03 PM, Murray S. Kucherawy wrote:
>> Actually, I was asking about the default for personalized vs. non-
>> personalized delivery. Right now, the default is to send all users the
>> same copy of the message (with some configurable batching sizes) in
>> order to reduce network bandwidth, i.e. non-personalized. By switching
>> to personalization by default, we can enable VERP by default,
>> personalized footers, etc. Personalization would allow for giving
>> users more choices about subject munging, footer adding, etc. but of
>> course it would consume more network bandwidth and server resources to
>> stitch together individualized messages.
>A little optimization is possible in that scenario, namely the cross product
>of all the possible munging options that the current subscriber list has
>enabled. I don't know how easy or hard that might be to code in mailman, but
>I imagine it's possible.
Possibly, but it depends on the level of individualization. If you're doing
VERP or personalized footers you pretty much have to send one message per
On Jan 05, 2012, at 04:32 PM, Monica Chew wrote:
>On Thu, Jan 5, 2012 at 7:46 AM, Barry Warsaw <barry(a)list.org> wrote:
>> On Jan 04, 2012, at 01:23 PM, Ian Eiloart wrote:
>>>Finally, if Mailman allowed users to choose whether to get the footer added,
>>>and subject munged, then Gmail users might avoid these issues anyway.
>> Of course, such level of option would require personalization, i.e. one
>> message per recipient. Maybe for most sites (but not all) the decade-old
>> economics that pushed us toward avoiding personalization by default has
>> changed enough now. MM3's architecture is more conducive to loading more
>> functionality into personalized delivery.
>> What do you think about changing this default?
>Are you suggesting changing the default to not munging the subject and
>adding the footer? I would be in favor, but also be interested in
>surveying mailman users to see how many use clients that offer no
>support for identifying or unsubscribing from mailing list mail.
Actually, I was asking about the default for personalized vs. non-personalized
delivery. Right now, the default is to send all users the same copy of the
message (with some configurable batching sizes) in order to reduce network
bandwidth, i.e. non-personalized. By switching to personalization by default,
we can enable VERP by default, personalized footers, etc. Personalization
would allow for giving users more choices about subject munging, footer
adding, etc. but of course it would consume more network bandwidth and server
resources to stitch together individualized messages.
On Dec 06, 2011, at 10:17 AM, Murray S. Kucherawy wrote:
>> I think this is the one big lesson from these discussions: DKIM is
>> mostly incompatible with mailing lists. Where the two must be
>> integrated, some usability will likely be compromised.
>It depends on your expectations. If there's an expectation that the author's
>signature will/should/must persist through a mailing list, then I agree that
>they're largely incompatible. If on the other hand you intend for lists to
>re-sign mail and for receivers to evaluate the message based on the list
>signature rather than the author signature, then it's entirely workable. Of
>course, sometimes the author signature will indeed survive, and then you have
>two domains to evaluate instead of one. Bonus!
My own personal feeling is that having lists re-sign messages is the best
expectation to put forward. You're subscribed to a mailing list, so you trust
that list much more than you trust the senders on that list. So having the
mailing list site re-sign the outgoing messages seems to me to be best
practice. My inclination is that removing the original author's signature
first is not entirely inappropriate.
Note too that Mailman supports anonymizing list traffic to the extent that it
would wipe out the original From header. Some lists turn this on for a higher
degree of privacy than you see on most open discussion lists. In that case,
the From header would look like it's coming from the mailing list, and then it
would make the most sense to remove any original signature and leave only the
It seems to me that relying on From header signing of mailing list messages
just isn't that useful.
>As Monica points out, DKIM itself is oblivious to the context in which it's
>> I'm no DKIM expert by far, but it seems to me that a mailing list
>> message has enough clues that a DKIM verifier could do a better job at
>> helping recipients make good choices. For example, all Mailman
>> messages have a List-Id header that contains the domain name hosting
>> the list server. With re-signing, why couldn't you verify the
>> signature against the List-ID host instead of the original sender?
>You could. The issue isn't that doing so is wrong or impossible. It's
>simply that those semantics aren't built into DKIM, largely because we have
>no evidence that that's a useful test.
>The ESP community has argued that third-party signatures (those different
>than the one in the From: field) shouldn't be valued any less than one that
>does match, for various reasons. That argument was apparently persuasive.
>ADSP, and a draft I'm advancing called ATPS, extend DKIM's semantics to do
>more than just say "domain X handled this message" (which is really all a
>valid DKIM signature tells you). They both attempt to say things based on
>whether the domain delivered as part of a valid DKIM signature matches some
>identifier in the message, like the domain in the From: or in the List-ID
>field. If Mailman (or an MUA, or a filter, or something) implements such
>checks and finds that it's operationally beneficial to end users do so, then
>it could publish that mechanism in an RFC or elsewhere, and people could
>start to use it. The resistance isn't that this is a bad idea, but just that
>there's no evidence to back it up that would justify its standardization.
In that case, it would be interesting and feasible for you to perhaps line up
some mailing list sites to enable this and gather some statistics. It would
be pretty easy to do (I think) in Mailman 3 (though that's unreleased) and
probably not hard to do in Mailman 2.
>The trick, of course, is not just to do something like this, but to get MUA
>buy-in. That is, when a signature validates and it presents a domain name
>that matches some identifier, change the presentation of the message to show
>this in some meaningful way. And then make sure in doing so that you don't
>inadvertently discredit legitimate messages for which that's not true.
Right. So, Gmail is probably the 800lb MUA gorilla here. Monica, do you have
any thoughts on how you could run such an experiment and find out what is most
useful to your users?