Mailman 3 October 2009 - Mailman-Developers

Re: [Mailman-Developers] [Mailman-Users] A modest proposal: Reply-To munging considered *carefully*
by Barry Warsaw Oct. 13, 2009

Oct. 13, 2009

[Your original message probably didn't make it to mailman-developers since it was spelled "mailman-devel(a)python.org" -BAW] On Oct 10, 2009, at 4:19 AM, Stephen J. Turnbull wrote: > 2. A formal proposal of a new header field, Responses-To, whose sole > purpose is to allow mailing lists conforming to RFC 2369 to hint > to MUAs whether a reply or followup is usually appropriate on the > list. > > I've cross-posted to Mailman Developers because I'd like to solicit > the opinions of those folks about whether Mailman should implement > this draft RFC early in the process. Concrete proposals are a ways > off, though. Followup to Mailman Users, please. So a couple of things. I'm not opposed to implementing draft RFCs or even defacto proposals in Mailman as long as we label them experimental. IOW, should the RFC change, we'll obviously need to change Mailman to conform. A lot of email lore is just defacto standards and we already support many of them. We'll take them on a case-by-case basis, but Mailman should not blindly rule out supporting them. For the ones we like, Mailman support can go a long way to proving the feasibility and perhaps nudging others to support the proposals as well (see my Archived-At contents proposal). In general, I like Stephen's proposal as a way to help reduce the ambiguity in this very common workflow. I'll bikeshed on this detail: I think the header should be called Response-Precedence or maybe List- Response-Precedence. The 'List-*' prefix is evocative of RFC 2369 and since this is a list specific header, it should probably be prefixed as such. A counter argument would be that because it's the user and not the list that's making the value choice, it should not be a List-* header. Response-Precedence is evocative of the defacto Precedence header, and it makes some sense to me because you're specifying the precedence of where responses should go, based on the conditional you posted. *-To: headers feel more like they should contain an address but this has a limited vocabulary, as does Precedence, so I like it not being a *-To header. As for going the RFC route, I think it's not a bad idea, but I have no idea how much work is involved. ;) -Barry

2 5

Looking for a mailman developer to hire
by John Goodell Oct. 12, 2009

Oct. 12, 2009

Am looking for an experienced mailman developer to hire for a few small installations/upgrade to our deployment, including: personalized header/footer fields (using qmail injection), attachment issue for HTML messages, and a few others. Thanks, John

1 2

dkim and email list software - potential solution
by Daniel Black Oct. 10, 2009

Oct. 10, 2009

I proposed some ideas around DKIM compatibility with mail lists and tried to send here too. Obviously the anti-cross-post feature on mailman- developers(a)python.org is working well (which on some levels I appreciate). As leading maillist product I'm keep to know your opinion. This has obviously been mentioned before never quite got momentum[1]. Now that ADSP (RFC 5617) is out it seems that validating domains with a ADSP policy of dkim=all seems rather weak as anything other than a temporary spam bias (until spammers catch on). My nice controversial idea is to mangle the from: address in mailing lists in general so that the list domain becomes the author (for ADSP purposes) and those DKIM validating emails are given the ability to do more with ADSP than spam biasing. Original post here http://mipassoc.org/pipermail/dkim-dev/2009- September/000202.html Other ideas welcome. [1] http://wiki.list.org/display/DEV/DKIM -- Daniel Black Infrastructure Administrator CAcert

5 13

Re: [Mailman-Developers] a patch: init script cleanup for LSB compliance
by Mark Sapiro Oct. 7, 2009

Oct. 7, 2009

Daniel Novotny wrote: > >There's an effort in Fedora to improve all our init scripts >for better LSB compliance. Because I'm responsible for mailman >package here, I made following changes in the mailman init scripts: The patch you included is against RedHat's already heavily modified mailman-2.1.12/misc/mailman.in. See <http://bazaar.launchpad.net/~mailman-coders/mailman/2.1/annotate/head%3A/mi…> for the current upstream version. Also see <http://mail.python.org/pipermail/mailman-users/2009-September/067249.html> for an issue that may or may not affect this. I am happy to consider incorporating these changes upstream, but I need the whole file or a patch against my base. I also need the RedHat changes to bin/mailmanctl that support the 'status' and perhaps other RedHat extensions. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 0

Script to change a member's password
by Marc Juul Oct. 7, 2009

Oct. 7, 2009

Hello. I'm running mailman 2.1.11 and i wrote a script to change a user's password, but it doesn't change anything and i can't seem to find the problem. My other "withlist" scripts work fine. I'm using: mlist.setMemberPassword(member, password) and then mlist.Save() called using "withlist -l -r" I have attached my script. Thanks in advance. Marc Juul

2 1

a patch: init script cleanup for LSB compliance
by Daniel Novotny Oct. 7, 2009

Oct. 7, 2009

hello, There's an effort in Fedora to improve all our init scripts for better LSB compliance. Because I'm responsible for mailman package here, I made following changes in the mailman init scripts: * when mailman is unconfigured, `service mailman start' should exit with code 6, not 1. * `try-restart' was't implemented. This is an addition to condrestart and should have the same effect. * stopping mailman when already stopped doesn't print scary error message now, prints "mailman already stopped" instead * when /var/lock/subsys/mailman exists but mailman isn't running, and `service mailman status' was executed, the script just printed 'mailman is stopped' and exited with code 3. In this case, it should say that it's dead but its subsys is locked, and exit with code 2. * when no known parameter is passed to the init script, it should exit with code 2, not 3. patch attached, references: http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-gener… (Linux Standard Base init scripts specification) https://bugzilla.redhat.com/show_bug.cgi?id=524016 (Red Hat bugzilla entry addressing mailman init scripts) best regards, Daniel Novotny, Red Hat inc.

1 0