? 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.
Mailman: 1.1
Python: 1.5.2
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
later.
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
files.
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.
-Barry
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 ?
Grtz,
--
Thomas Wouters <thomas(a)xs4all.net>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
[bwarsaw(a)cnri.reston.va.us]
> 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
SIGPIPE.
I tried fixing the problem with this patch:
Index: driver
===================================================================
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 @@
main()
finally:
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)
+ else:
+ raise
except SystemExit:
# this is a valid way for the function to exit
pass
(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
entry...
Does anyone have any insight on how to properly avoid SIGPIPEs in
python?
--
Harald
[Thomas Wouters]
> 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.
--
Harald
Hi,
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? :)
Ricardo.
--
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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[1], where msg.GetSender
needs to become mlist.GetAdminEmail.
Brian.
[1] 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/>
iD8DBQE5DKQbcCEFQUX5+OwRAvxkAJ91zqlhXTD5XAezZ/PHKKDWa+jNagCeKFO1
2zVlOt8M2I0sn3qFAXD2XGY=
=79kq
-----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.
jarrell(a)vt.edu said:
> 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.
Nigel.
--
[ - 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 ]
