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

GNU Mailman sprint at Pycon 2012
by Barry Warsaw 25 Jan '12

25 Jan '12

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: https://us.pycon.org/2012/community/sprints/projects/ 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! :) -Barry

1 0

MM3 testing report and beta timelines
by Geoff Mayes 20 Jan '12

20 Jan '12

Hello, 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, Geoff Mayes

1 1

Fw: About Tokio Kikuchi
by Barry Warsaw 18 Jan '12

18 Jan '12

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: http://wiki.list.org/display/COM/TokioKikuchi The following is forwarded with permission. -Barry Begin forwarded message: Date: Mon, 16 Jan 2012 14:22:43 +0900 From: Atsuo Ishimoto <ishimoto(a)gembook.org> To: barry(a)python.org Subject: About Tokio Kikuchi Hello, 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 cancer. http://www.kochinews.co.jp/?&nwSrl=284270&nwIW=1&nwVt=knd Regards, -- Atsuo Ishimoto Mail: ishimoto(a)gembook.org Blog: http://d.hatena.ne.jp/atsuoishimoto/ Twitter: atsuoishimoto

2 1

hostname -s
by Systems Support 11 Jan '12

11 Jan '12

Hmm, 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. -- Ian Eiloart Postmaster, University of Sussex +44 (0) 1273 87-3148

2 1

Mailman gone social ?
by "Marc Manthey (macbroadcast )" 11 Jan '12

11 Jan '12

hello everybody 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 Marc -- Les enfants teribbles - research / deployment Marc Manthey- Vogelsangerstrasse 97 50823 Köln - Germany Tel.:0049-221-29891489 Mobil:0049-1577-3329231 web: http://let.de project : http://stattfernsehen.com twitter: http://twitter.com/macbroadcast/ facebook: http://www.facebook.com/opencu 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).

4 3

Re: [Mailman-Developers] feature request: one-click setting to preserve DKIM
by Ian Eiloart 10 Jan '12

10 Jan '12

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. > > http://gmailblog.blogspot.com/2009/07/unsubscribing-made-easy.html 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. > Thanks, > Monica -- Ian Eiloart Postmaster, University of Sussex +44 (0) 1273 87-3148

1 0

draft-kucherawy-received-state
by Murray S. Kucherawy 09 Jan '12

09 Jan '12

Hi all, Over on ietf-smtp, https://datatracker.ietf.org/doc/draft-kucherawy-received-state/ was developed late last year. This is an optional tweak to email Received fields allowing annotation of entry into special states of mail handling, such as quarantines or hold-for-moderation MLM actions that would help to explain large gaps in timestamp sequences. I'm looking for a wider audience of reviewers and (hopefully) supporters. If this sort of thing seems like a good (or terrible) idea, please do follow up and comment on one of these IETF lists: apps-discuss: https://www.ietf.org/mailman/listinfo/apps-discuss ietf-822: http://www.imc.org/ietf-822/ ietf-smtp: http://www.imc.org/ietf-smtp/index.html How much and what kind of support is evident will guide the choice of what its next steps are (if any). Thanks, -MSK

1 0

Re: [Mailman-Developers] feature request: one-click setting to preserve DKIM
by Barry Warsaw 06 Jan '12

06 Jan '12

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 user. -Barry

2 1

Re: [Mailman-Developers] feature request: one-click setting to preserve DKIM
by Barry Warsaw 06 Jan '12

06 Jan '12

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. Cheers, -Barry

2 1