? 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
On Tue, 27 Feb 2001 08:17:10 -0700
Matthew Seidl <seidl(a)vex.cs.colorado.edu> wrote:
> Over the weekend one of the uesers on one of my lists had both
> their DNS servers go down. This means that any attempt to deliver
> mail to them had a 4 minute DNS failure timeout.
> This went fine, till about 5 messages for them accumulated in the
> qfiles directory. Then each qrunner that started up would try
> those 5 messages first, fail, and exceed its 15 minutes of
> runtime. This cycle would repeat forever.
> It seems to me that qrunner should at least try messages in a most
> recent first order, instead of oldest first. But that might still
> lead to starvation of some messages in the queue.
You are attempting to solve problems with an incoprrectly configured
MTA by changing Mailman. REconfigure your MTA to not do DNS
verifications on messages received from your list server (likely
localhost).
--
J C Lawrence claw(a)kanga.nu
---------(*) http://www.kanga.nu/~claw/
--=| A man is as sane as he is dangerous to his environment |=--
I setup the latest of mailman from cvs yesterday and I'm having some
difficulty getting it all working.
My first problem was with /scripts/mailcmd on line 49:
print >> sys.stderr 'Mailman error: mailcmd got bad listname: %s\n%s' \
^ -- missing comma after sys.stderr
I also had a problem with the mimelib import where everything worked
from from the command line but wouldn't work from the cron or when
sendmail called the wrapper commands. I fixed this by creating a soft
link:
$ ln -s /usr/local/lib/python2.0/site-packages/mimelib
/home/mailman/Mailman/mimelib
The problem I'm currently having now is also in mailcmd and mailowner
with the following error:
mailcmd(12300): File "/home/mailman/scripts/mailcmd", line 69, in ?
mailcmd(12300): main()
mailcmd(12300): File "/home/mailman/scripts/mailcmd", line 53, in main
mailcmd(12300): msg = Message.Message(sys.stdin)
mailcmd(12300): TypeError : too many arguments; expected 1, got 2
I looked into it and found that Mailman.Message.Message inherited from
mimelib.Message.Message had __init__(self) and no other means of parsing
the actual message. I would think that somewhere Parser should be used
to parse the message but I'm not sure where or how to maintain the
Mailman.Message.Message functionality that was added in the inheritance.
Does anyone know how this should be fixed or what I did wrong? I have
the latest of mimelib 0.2 installed.
Chris Ryan
chris(a)greatbridge.com
Over the weekend one of the uesers on one of my lists had both their
DNS servers go down. This means that any attempt to deliver mail to
them had a 4 minute DNS failure timeout.
This went fine, till about 5 messages for them accumulated in the
qfiles directory. Then each qrunner that started up would try those 5
messages first, fail, and exceed its 15 minutes of runtime. This
cycle would repeat forever.
It seems to me that qrunner should at least try messages in a most
recent first order, instead of oldest first. But that might still
lead to starvation of some messages in the queue.
A better approach would be for the qrunner to leave a file around that
said where in the queue it had gotten to, so the next qrunner process
could start on the next message in the queue. This should lead to the
whole queue being serviced before any elements are serviced a second
time. Does this make sense?
I'm too new to mailman and python to take a stab at this myself, but I
wanted to report the bug. If others agree that its a bug, and no one
else takes a shot at it, I might. But it will require some
non-trivial modifications to qrunner I believe.
-=- Matthew L. Seidl email: seidl(a)cs.colorado.edu =-=
=-= Graduate Student Project . . . What Project? -=-
-=- http://www.cs.colorado.edu/~seidl/Home.html -Morrow Quotes =-=
=-= http://www.cs.colorado.edu/~seidl/lawsuit -=-
In 2.0.1 pipermail.py takes any user-included Reply-To header and
uses that the address of the sender in the archives.
In other words, if I post a message to list that looks like this:
Date: Mon, 26 Feb 2001 14:03:03 -0800 (PST)
From: Darrell Fuhriman <darrell(a)grumblesmurf.net>
Subject: something really neat!
To: moderated-list(a)grumblesmurf.net
Reply-To: not-moderated-list(a)elsewhere.com
in the Archives, this gets re-written to be:
Darrell Fuhriman <mailto:not-moderated-list@grumblesmurf.net>
I maintain that this behavior is incorrect.
For instance, I just started a moderated, announce-only list. I
would like to give the poster the option of redirecting followups
for discussion to another list.
I'm happy to write a patch to change the behavior, but I'd like
to know what folks think the correct behavior should be.
I think that including the Reply-To as a separate header is the
appropriate thing to do, but I'm soliciting other opinions.
Secondly, archiving is a big old pig and slows down list
processing. Would it be possible to re-write the code so that
the archiver forks off? Once again, I'm willing to do it, but I
want to make sure that people will be happy with the design.
Darrell
On Wed, 21 Feb 2001 08:32:44 -0500
Chris Ryan <chris(a)greatbridge.com> wrote:
> Hello all, I've been using Mailman on our web site for open source
> development of "serious business software."
> http://www.greatbridge.org/. We are interested in seeing Mailman
> have a PostgreSQL database back end (and further in the future PHP
> front end web tools.) I have been given permission to start
> working on this as soon as I have completed my current project
> (should be done this week).
I would start out by reading the traffic among Chuq, Barry, and I at
the end of last year and early this year on proposed V3
architectures.
--
J C Lawrence claw(a)kanga.nu
---------(*) http://www.kanga.nu/~claw/
--=| A man is as sane as he is dangerous to his environment |=--
At 04:15 PM 2/16/01 -0500, I wrote:
>Jeez, Barry, that itty-bitty change you made last night to not
>import _ into the namespace by default broke a *lot* of things...
>
>I was trying to use config_list, and had to edit several modules
>to do a from Mailman.i18n import _...
Add Bouncer.py to that.
W.r.t my newlang problems..
Since I deleted the templates/en dir I had created to test the fallback, newlang wouldn't
work, because there's no en directory to copy to the new list... It needs to catch the fact
that ok_langs is empty before the loop that prints which languages were installed runs,
otherwise the status message looks stupid :-).
Perhaps instead of saying "language not supported" it say "No template directory for
language." Particularly since that's the only check; it doesn't matter if the language is
defined or not in Defaults, and, in fact, if it's NOT defined there, you can still install
support for it with newlang, you just can't tell mailman to use it later. (Which means,
come to think of it, that in a perfect world newlang would check the supported languages
array out of Defaults as well as looking for the directory...)
Newlang also has a nasty habit of leaving the list locked if anything goes wrong.
w.r.t your comment about needing to look at the call to HTMLFormatter. You do
need to init it, because mlist._template_path is used by it, and by newlang, and it's
*not* defined in MailList; HTMLFormatter adds it to the object when it runs. The
reason it's broken, however, which came to me in a blinding flash of "duh", is that
we instantiate an mlist for the list we're looking at, but do the initvars on "list", not
"mlist"... So on newlang line 86 change list to mlist.
BTW, there's going to be either a very smart update procedure needed, or a lot of
verbiage in the Readme... Or both. People need to install EN support into
each list they own. Which they can do by hand, or with newlang. However, if
newlang does it, it'll populate the files from the template directory. Now, because
all lists default to en, they'll be using *those* templates, which might differ from the
one that are installed in the list. (Which, is, of course, a regular occupational hazard
of updating mailman, but there's a new twist.) So those templates, which haven't
been changed by anyone, won't be used anymore, without admins being any the wiser
unless they pay attention.
Two things need to happen in an upgrade, order optional. Each list needs an "en" subdir,
and all the templates in the list dir need to move to the en dir. Also, all the templates, as usual,
need to be checked by hand against the new versions. (Luckily, so far, the only difference
between any of mine, and the defaults is the revision number in the comment.)
If everyone was running an english version, I'd say just have update move *.html, installing
a new headfoot.html, since that seems to be new, into an en dir for each list, then print the
standard warning to go compare configurations. Anyone that's already done any language
changes though will find their local language sitting in the english subdir... Either way, there's
copius notage in the readme necessary to explain where things are going and why...
Jeez, Barry, that itty-bitty change you made last night to not
import _ into the namespace by default broke a *lot* of things...
I was trying to use config_list, and had to edit several modules
to do a from Mailman.i18n import _...
Digester.py
Archiver.py
GatewayManager.py
MailList.py
(Of course, just my luck, MailList.py blows up the same place the admin
page blows up on a bad list, line 362 in GetConfigInfo, with the
same "ValueError: list.index(x): x not in list" error...)
I expect there's more places that need to do the import, Those are just the
first few.
Oh, and something about the HTMLFormatter change last night broke newlang,
I haven't had a chance to look at that since 4am.
