? This very message came to me with the following header:
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
OS: Solaris 5.7
I don't know if this has been fixed in the CVS version, but I thought I'd
submit it anyways. There seems to be a small authentication bug with the
chunking in the membership management page. The page will load up correctly
the first time it is accessed with the first chunk size shown. However, when
you request a different chunk, it requires a reauthentication and then gives
the chunk=0 page instead of the requested chunk. If you then click on the
alternate chunk it loads fine. However, the additional click and
authentication is annoying.
Ted Cabeen http://www.pobox.com/~secabeen secabeen(a)pobox.com
Check Website or finger for PGP Public Key secabeen(a)midway.uchicago.edu
"I have taken all knowledge to be my province." -F. Bacon cococabeen(a)aol.com
"Human kind cannot bear very much reality."-T.S.Eliot 73126.626(a)compuserve.com
Last night, I added some code to queue messages that fail delivery
when using SMTPDirect. What happens is this:
If a message either totally fails delivery (e.g. the smtp socket
connect fails) or partial delivery fails for some, but not all,
recipients, then the message is stored on the file system for a re-try
For every failed message, two files are created. The base name of
these files is the SHA hexdigest dump of the message text. This
should be nearly guaranteed unique. A new directory contains these
files, called `qfiles'. The first file created is the complete plain
text of the failed message. The second file is a marshal of useful
information related to the failed delivery. This contains the
listname and the failed recip list along with a few other moderately
useful bits of info.
There's a new cron script called `qrunner' which cruise the files in
qfiles. It claims a lock (to prevent multiple qrunner processes) and
then goes through each file it finds, attempting redelivery. If there
are any problems reading a qfile file, it skips it for next time
(assumes it's a transient problem with the file, but logs a message).
When qrunner notices that the message has been handed off the the smtp
daemon for all outstanding recipients, it deletes the two message
I've moderately tested this stuff with total delivery failure by
shutting off my smtp daemon, attempting some deliveries, turning it
back on and running qrunner. I don't have the time right now to test
partial delivery failures, but I still claim that without DSN support,
these will be unlikely. Hopefully some of you can help look at this.
I'm about to check all this stuff in. Let me know what you think.
There was a short discussion a month or so ago about the hyperarch 'mbox'
archives having the wrong kind of date in the 'From ' lines... 'unixfrom'
lines should have a very specific dateformat, namely that which 'time.ctime'
returns. The following patch fixes Archiver/HyperArch.py. However, I'm not
entirely sure if it will work correctly in other locales... can anyone test
that, and propose a locale-independant way of producing this format ?
Thomas Wouters <thomas(a)xs4all.net>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
> Actually, I just remembered sys.exitfunc! I can set that up to
> unlock a locked list automatically at interpreter exit. I don't
> want it to implicitly save the list though -- you'll still have to
> do that manually if you fiddle with it from the interpreter prompt.
> Note that this function doesn't run if the interpreter exits because
> of a signal or os._exit() call.
Regarding signals: Some time back, I occasionally received reports
from my users that some list, while its web admin interface was being
accessed, suddenly got unresponsive for a period of time that matched
the lock lifetime pretty well.
There were no entries/backtraces in logs/error, but I sometimes saw
list lock files left lying around, and upon checking their contents
found that their creating process was now gone.
I suspect this is what happened:
* Web browser connects to Mailman.
* Web browser for some reason closes its side of the connection
before Mailman has given any response.
* When Mailman tries to print out its response, it receives a
I tried fixing the problem with this patch:
RCS file: /projects/cvsroot/mailman/scripts/driver,v
retrieving revision 1.19
diff -u -r1.19 driver
--- driver 2000/04/06 19:30:38 1.19
+++ driver 2000/04/12 14:43:23
@@ -89,6 +89,13 @@
sys.stderr = sys.__stderr__
+ except IOError, e:
+ import errno
+ if e.errno == errno.EPIPE:
+ # Log something
+ logger.write("EPIPE caught, ARGV=%s\n" % sys.argv)
# this is a valid way for the function to exit
(Well, something like that patch anyway... :)
However, if my understanding of the problem is right, and this is the
correct fix for it, I don't understand why the bare except: clause
around the run_main() call in driver didn't kick in to produce a log
Does anyone have any insight on how to properly avoid SIGPIPEs in
> On Mon, Feb 07, 2000 at 09:31:44PM +0100, Ricardo Kustner wrote:
> > I wonder though what happens if some impatient moderator decides not to
> > wait before the page finnishes loading, switches to a differen webpage and
> > therefor breaks the python cgi process... will some approved posts stay in
> > the queue instead?
> Try it out ! ;) It depends on the exact behaviour of both the
> webbrowser and the webserver.
Yup. This might produce a SIGPIPE, and/or the corresponding IOError
EPIPE, and I've experienced that these didn't always get caught -- an
attempt at a fix is near the end of run_main in <URL:
http://www.uio.no/~hmeland/tmp/mailman-userdb/scripts/driver>, but I'm
by no means positive that it's the Right fix.
I think it could be better to place the heldmsg-* files
that are created for messages held for approval in
a directory like ~mailman/listname/lists/mailinglist/pending
instead of all messages for all lists in ~mailman/data...
does anybody agree with me? :)
-----BEGIN PGP SIGNED MESSAGE-----
I've been having a problem (using 2.0beta2) with a number of bounce
messages going back to the poster rather than the list owner. I've
tracked it down to the envelope sender being left as the poster, and not
being changed to the list admin address. It appeared to be inconsistent
since some MTAs were handling Errors-To, which was being set to the
admin address, while some use the envelope sender.
The change is on line 91 of Handlers/Sendmail.py, where msg.GetSender
needs to become mlist.GetAdminEmail.
 I don't know if this is also a problem in the direct SMTP module.
I'm using Sendmail.py because my MTA is sendmail, but I'm using postfix
in outgoing only configuration for the list delivery since mailman was
getting sendmail to send each message as one huge batch of addresses.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.5 and Gnu Privacy Guard <http://www.gnupg.org/>
-----END PGP SIGNATURE-----
> Does nightly_gzip only handle monthlies? It's not clear from the code
> (and my knowledge of python :-)), but it sure looks like it's only
> compressing monthlys.
It certainly isn't working for my weekly lists.
[ - Opinions expressed are personal and may not be shared by VData - ]
[ Nigel Metheringham Nigel.Metheringham(a)VData.co.uk ]
[ Phone: +44 1423 850000 Fax +44 1423 858866 ]