? 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.
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
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
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
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
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
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.
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.
> >>>>> "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.
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