Mailman-Developers January 2001

mailman-developers@python.org

35 participants
45 discussions

Re: [Mailman-Developers] Mailman password and administrative reminders

by Dan Mick

? This very message came to me with the following header: Errors-To: mailman-developers-admin(a)python.org All my bounces come to the list admin address, set in the admin webpage, in the second field of General Options. Do you have that set to something, and bounces still come to root? > 2. Bounces are sent to the poor postmaster instead of a -admin address. > I'm not entirely certain, but I think an Errors-To: header or something > like that in all Mailman messages might allow one to distribute that load > somewhat.

18 years, 5 months

List of list admins

by Maryann Stopha

Hi, I need to get a list of all the admins for our Mailman system, and wondered if anyone could help me with this. I have tried to grep them out, but it has not worked with getting info out of the .db files. Does anyone know a simple way to accomplish this? Thanks, Maryann Stopha -- Web Development Professional Computing & Information Technology SUNY Geneseo 716.245.5577 stopha(a)geneseo.edu

20 years, 10 months

Re: [Mailman-Developers] Feature Request - Inbound MessageID tracking

by Darrell Fuhriman

Satya <satyap(a)satya.virtualave.net> writes: > [mailman]~$ chmod g-w ../mailman > [mailman]~$ bin/check_perms > directory must be at least 02775: /home/mailman > Problems found: 1 > Re-run as mailman (or root) with -f flag to fix > [mailman]~$ bin/version > Using Mailman version 2.0.1 > [mailman]~$ I know that's what it *claims* it needs. The reality is different. % ls -ld ~mailman drwxr-sr-x 18 mailman mailman 512 Oct 26 15:16 /usr/local/mailman/ Anyway, this discussion doesn't belong on -developers.... Darrell

20 years, 12 months

Re: [Mailman-Developers] Feature Request - Inbound MessageID tracking

by Darrell Fuhriman

Satya <satyap(a)satya.virtualave.net> writes: > flag, hates group-writeable directories. Mailman wants its home directory > writeable. Not really. Mine isn't, and never has been. All it really cares about is that the directories under ~mailman are group-writable. Darrell

20 years, 12 months

Re: [Mailman-Developers] Feature Request - Inbound MessageID tracking

by Darrell Fuhriman

Satya <satyap(a)satya.virtualave.net> writes: > comparing with a cache. I don't know how you could force each message > through formail, except through some simple but non-trivial shell scripts. Assuming you know how to set procmail up initially, it's pretty simple really, just change the alias for posting to the list to be simply the mailman user (which can't be aliased to anything else), then, in ~mailman/.procmailrc: MMHOME=/usr/local/mailman :0c * ^TOlistname(a)example.com { LISTNAME=listname PROCESSED=yes :0 Wh: msgid.lock.$LISTNAME | formail -D 8192 $HOME/msgid.cache.$LISTNAME :0 | $MMHOME/mail/wrapper post $LISTNAME } [repeat for each list] # when we reach this point, we should have been processed # by *something*. If we have, we can discard it, otherwise # let the admin look at it. :0 * PROCESSED ?? yes /dev/null :0 $DEFAULT I haven't tested this, though, so don't blame me if you break something. :) Anyhow, it should be included in mailman, yes. :) Darrell

20 years, 12 months

suggestion for documentation

by Chris Ryland

I can't check www.list.org right now, but if I remember correctly, during Mailman 2.0 installation, no note was made about Apache needing a <Directory $prefix/archives/public/> Options FollowSymLinks </Directory> which is required if such symlink following is turned off by default elsewhere in the Apache configuration file. I realize this is getting into pretty nebulous territory, but it might save someone some hair-pulling and is easy to mention. -- Cheers! Chris Ryland Em Software, Inc. www.emsoftware.com

20 years, 12 months

make admin password sticky

by Brian Edmonds

I would find it really handy if Mailman would set a special cookie when I authenticate to a list's admin page with the Mailman admin password, so that it would then let me in to all other lists without prompting for a password. I often go through a bunch of lists at a time clearing out the non-member spam posts from the admin approval queue, and it would be nice to not have to type passwords over and over. Brian.

20 years, 12 months

Feature Request - Inbound MessageID tracking

by Scott Brown

Ok - I dont know how widely useful this might be - but it would have saved my bacon today. I had a list get flooded by an upstream mail server that was stuck on sending a message to me. Every message that came in had the same messageID on it - and mailman dutifully kept pushing them out.... 200+ of them before I disabled the mailman list, and finally got the other server admin to clean up his machine. Would it be possible in the next release to get some sort of tracking on processed messages - tracking by incoming messageID - such that this sort of problem wouldnt be sent out to list subscribers? A message to the mailman-owner alias indicating the problem when it gets found should be sufficient to alert the admin to look into things.

20 years, 12 months

Re: [Mailman-Developers] suggestions for i18n

by Dan Mick

> >>>>> "JR" == John Read <john.read(a)newnet-marketing.de> writes: > > JR> I have a suggestion how this can be done very easily. If the > JR> function maketext (in Utils) had an addition parameter "list", > JR> it could first try to open the text file in > JR> mailman/list/"listname"/"lang". If the file is not there, then > JR> it could continue to take it from /mailman/templates/"lang" as > JR> you have coded it. This would mean that if the list manager > JR> wanted to put special messages in a list he can create them in > JR> the list/"listname"/"lang"/....... directory. The normal list > JR> manager would not notice any difference. > > That sounds like a good idea. That's exactly what my "per-list template" patch, which I've been reworking for every version since 2.0beta1, does. I figure the I18N stuff will completely make the patch invalid, but "first look in the list directory" is the easy poor-man's 'list-specific' hack. The only problem you had with it, Barry, as I remember, was the minor ugliness of "passing the list around to maketext". I ended up passing list._full_name just to keep *some* of the data abstraction in place, but was never really satisfied with the solution. Maybe there should be a "get list directory" method.

21 years

Pipermail, large archives and performance

by Bob Tanner

I am wondering what that road map is for mailman. Meaning what are the new features slated for the future. What enhancements to current features are planned. I posted a feature enchancement to SF: http://sourceforge.net/bugs/?func=detailbug&bug_id=128127&group_id=103 And pipermail is really causing problems. I have an mbox file that is 1.92Gb in size and it takes almost 14 hours to process the qfiles. I believe this is because qrunner(?) has a difficult time processing such large files to generate the archives. Am I way off base here? Browsing the archives is another unpleasant task. I think pipermail(?) does not work well on files of this size either. Is there any plans for enhance/replace these problems? I am willing to put my coding skill to work to fix these issues if there is some road map to follow. Thanks. -- Bob Tanner <tanner(a)real-time.com> | Phone : (952)943-8700 http://www.mn-linux.org | Fax : (952)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9

21 years

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

Mailman-Developers January 2001