Mailman 3 April 2008 - Mailman-Developers

Done.
by Jo Rhett 10 Apr '08

10 Apr '08

I've been incredibly tolerant of being abused on this issue for 3 weeks now, but the now-constant flood of people coming forward to say that I'm not respecting the mailman community is too funny. It breaks the bounds of reality. *I* did one thing. I pointed out an issue that *EVERYONE* knows about, even the non-technical news media. I asked that something be done soon. I wrote my post clearly and politely. http://mail.python.org/pipermail/mailman-developers/2008-March/019804.html Did I receive a respectful response addressing these issues from anyone who writes code for the project? Yes: Mark Sapiro wrote me a respectful reply on March 5. http://mail.python.org/pipermail/mailman-developers/2008-March/019807.html But that reply only negated my suggestions, with no solutions proposed. I attempted to respond to the insults and derision I received in most of the replies with honest, straightforward answers. Even when the questions were hopelessly supercilious and rude. At this time there has been more effort spent writing me back saying that I'm not respecting the community than it would have taken to write patches to fix the problem. I've certainly wasted more time here than I did writing my patches and testing them in the first place. I respected the community by coming here and trying to address the issue, rather than simply blacklisting Mailman sites. I respected the community by replying to everyone who replied to me, rather than ignoring the posts filled with derision or technical nonsense. Perhaps that was a mistake. I had a nice dinner with a number of people last night on this topic, and not a single person (all of whom witnessed this thread) felt that trying to address this issue here was producing any results. So I am done. Keep your derision to yourself, and keep wasting time telling people how they should respect you rather than solve the problem. I am right now updating our AUP documentation to mention that Mailman is explicitly banned unless the person provides documentation of the configuration/patches they have applied to prevent backscatter. I am notifying the known mailman sites within our network. We are done with this issue. -- Jo Rhett Net Consonance ... net philanthropy, open source and other randomness

4 3

Re: [Mailman-Developers] [Mailman-i18n] [Mailman-Users] [Mailman-Announce] Updated message catalogs needed for Mailman 2.1.10
by Barry Warsaw 09 Apr '08

09 Apr '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 12, 2008, at 5:07 AM, Clytie Siddall wrote: > > On 11/03/2008, at 12:11 PM, Brad Knowles wrote: > >> On 3/10/08, liste yoneticisi wrote: >> >>> (An explanation to all: I just asked if there is anyone who >>> responsible for Turkish translation of Mailman, attended to these >>> lists >>> from Turkiye.) >> >> This is a question that is better asked on the mailman-i18n mailing >> list. That's where all the Internationalization folks should be >> hanging out. > > I'd definitely vote for Pootle. It's free software, and gives you > complete control of access, plus syncing with source control > (including bzr, AFAIK). Its developers are extremely responsive to > admin or user needs. Clytie, I would like to set this up for Mailman 2.2 and 3.0. Could you or another volunteer outline what it would take to get a Pootle instance running for us? Is there some service that we can piggyback on? Would anybody out there be willing and able to run a reliable Pootle server for us? - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkf8NIQACgkQ2YZpQepbvXGAvQCggd1jTxioWaLKXR++uVoY3WFL 6okAn0VoffXIKTRGi++BqVSIDMYiFkGw =CRFK -----END PGP SIGNATURE-----

2 1

Feature Request: an improvement to approve-by-email
by Justin Long 09 Apr '08

09 Apr '08

Greetings, My name is Justin Long, and I manage the website www.strategicnetwork.org. We recently migrated to postfix/mailman from qmail/ezmlm because postfix had better anti-spam features and qmail/ezmlm simply hadn't been updated in a long while. We have about 400+ lists with about 160,000 subscribers. I've been very pleased so far with mailman's performance and utility (although admittedly the web interface leaves much to be desired--grin) One thing I have noticed that I would like to suggest for a fix. When a post comes into a moderated list, the bounce goes to the -owner address. It comes with an email attachment that contains a confirmation code in the subject line. This works great in an email client like Outlook. I, however, use gmail as my primary email source, and the confirmation code comes in a message buried in the message, not in the subject line. Of course, if I hit "reply" it doesn't go to -requests. I think it either goes to -bounce or -owner. In any event, it's not a simply reply-and-send like it was in ezmlm. So some suggestions: 1. Have the bounce message come to the owner from the -response address, for easy reply 2. Don't require the confirmation code to be in the subject line 3. Why is the password required? I can sort of see this, and I don't mind it too much, but wouldn't it be better to have perhaps an -approve and -reject email address that can be clicked as a link? (not a web address but an email address?) or something simple that doesn't require my remembering or typing in the password? I wouldn't mind #3 so much if #1 and #2 were fixed, so that all I have to do is hit REPLY and type in "Approved: " and the password. As it is, in gmail, I have to forward the email to the -response address, find-cut-paste the confirmation code, and then type the address line. This is a big deal for many of our members who are in significantly low bandwidth situations or in places where they do not have web access, and must moderate everything by email... Cordially, Justin Long -- Never retreat. Never surrender. Never cut a deal with a dragon. ------- Justin Long / justinlong(a)gmail.com http://www.strategicnetwork.org - 120,000 subscribers, 16,000 articles http://www.momentum-mag.org - bi-monthly magazine on unreached peoples http://www.momentum-mag.org/wiki - Missiopedia of Christian missions MSNIM justinlong(a)strategicnetwork.org / Skype nsmjustinlong ------- We help people build 6 things: Drive, Energy, Effort, Inspiration, Power, Strength ------- No armor? Unclean life? Then do not mess in the affairs of dragons, for you are crunchy and taste good with ketchup.

1 0

Has Mailman lost its way?
by David Lee 09 Apr '08

09 Apr '08

First there was Majordomo... Once upon a time, Majordomo version one was the leader in its field. So good was it, that ambitious plans were laid for a succeeding generation: version two. And at that point it went off the rails and ended up in a ditch. 'Domo V1 got stuck, because the development went into 'Domo V2. But V2 got stuck because it never got released and never got used. And so the once glorious Majordomo sadly faded into the night-time of obscurity. Move forward a few years... In another place, at a later time, Mailman v2.1 became the leader in its field. So good was it, that ambitious plans were laid, not just for one, but for two, succeeding generations: v2.2 and v3. And at that point... ... well what has happened? Nearly two years ago, the July 5 2006 "What I did on my summer vacation" email and wiki entry (http://wiki.list.org/x/vg) outlined a massive amount of potential progress. But, in reality, what actually have we (the subset of real-world end-users who could assist development) been able to do? Has Mailman lost its way? Could it be drifting to the same obscurity and oblivion as the entire majordomo project? Could I suggest that serious consideration be given to: 1. Freeze 2.1 now. No new features. The only exception would be security bug-fixes. Nothing else. 2. Freeze "new idea" development now. Concentrate solely on bugfixing the already implemented ideas. 3. Decide whether 2.2 or 3.0 is the way of the near future. The reality is that neither of these has delivered anything to the real-world end-user during two or more years. Choose only one. Freeze the other for the time being, until the "chosen one" has been properly post-beta released. 4. Whichever of the above is chosen, aim to start delivering betas fast. Get something out there that you (the main developers) and we (some real-world end-users who can help bug-hunt) can get to work on, knowing that our work will be productive in a foreseeable timescale. Set the goal. Drive towards it, ignoring distractions. 5. For a few months, change the mindset away from development (yes, I know we coders love it) and towards a firm, decisively-directed "release management" (to use ITIL-speak). Mailman used to be a leading product. But it is slipping behind. We, the end-users, need some of that new code that's being lying dormant, and (to an end-user) unuseable, during the last two years or so. Many of us, the enthusiastic real-world end-users, cannot realistically commit to developing something for which there is no clear strategy. Give us a strategy, a roadmap with real, near-future dates on it, then we can at least make local business cases to our local managements for our taking part in beta trials. Let's get some new code out now as beta. There may be a sizeable "TODO"; there may be a sizeable "Known Problems". But let's start releasing betas soon, and concentrate all our limited efforts on that one common task. Otherwise, are we not in danger of following Majordomo into oblivion? (Oh, and #1 on my own list is proper "virtual domains": the Jul/2005 paper mentioned that the code substantially existed. But sadly it's never come anywhere near a release schedule. If we have a realistic beta-release schedule, then I can locally justify actively investing in bug-hunting.) Sorry if that sounds harsh. It is meant to be constructive. (Honest!) Best wishes. -- : David Lee I.T. Service : : Senior Systems Programmer Computer Centre : : UNIX Team Leader Durham University : : South Road : : http://www.dur.ac.uk/t.d.lee/ Durham DH1 3LE : : Phone: +44 191 334 2752 U.K. :

2 1

Configurable options in Mailman 3
by Stephen J. Turnbull 09 Apr '08

09 Apr '08

Mark Sapiro writes: > What are you asking, and what is the issue? > > Upon rereading, I think your question is "is it possible to have > OLD_STYLE_PREFIXING = No in mm_cfg.py, but use the old style for > selected lists through some list setting". Unfortunately, the answer > to that is no. I don't understand why it should ever be the case that a configuration option that makes sense to configure per-list should be not configurable per-list. How is Mailman 3 handling this?

2 1