? 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!
[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
Exim adds a header to bounce messages that might be used to catch the
bounced addresses, rather than trying to parse the message text. I've
been using this trivial bouncer for a while with my 1.2CVS installation
and it seems to be doing the right thing.
--
Jim Tittsler, Tokyo
Python Starship http://starship.python.net/crew/jwt/
[Thomas Wouters]
> On Mon, Feb 07, 2000 at 10:01:36PM +0100, Harald Meland wrote:
>
> > My current CVS checkout is available ("live" :) under <URL:
> > http://www.uio.no/~hmeland/tmp/mailman-userdb/>, with <URL:
> > http://www.uio.no/~hmeland/tmp/mailman-userdb/Mailman/LockFile.py>
> > being of special interest in this discussion...
>
> Ah, very cool. You'll find my current version of LockFile.py
> attached, for reference, as you asked.
Thanks, I've skimmed through most of it now.
> I think the link() solutions, as opposed to the rename() solution,
> is a better one, if you'll premit me.
Sure :)
> For one, you can check on lock ownership by statting your own
> lockfile, which should only be touched by you, instead of reading a
> possibly highly volatile lockfile. You can also doublecheck the
> lockfile inode, see if it is equal to your own lockfiles' inode, to
> confirm that you have the lock.
... the downside being that if, e.g., anyone tries to read the info in
the lockfile in the middle of a refresh(), they'll get a ValueError --
which your module seems to take care of, but it all looks a bit
convoluted to my eyes. I especially dislike that lock() has to call
locked() _after_ the check on ST_NLINK, because further down in lock()
there's code that might break a lock it really shouldn't (if it
weren't for the nonatomic-write-of-lock-contents issue).
I also see some bugs that are fixed in my module but still present in
yours, but those are rather irrelevant to this discussion (as they can
easily be ported to your module if that's the one we'll go for).
Does anyone but Thomas and me have any opinions on which locking
scheme is preferrable? I guess I don't have any very strong feelings
about the issue ;), so any sagely advise on the matter would be
welcome.
[ I've tried to model my version of the module as closely as possible
after the way Exim does its lockfile locking, the idea being that
Exim really should have been around long enough to have solved these
things correctly. Reading the longish comment from ca. line 1206
and onwards in src/transports/appendfile.c of the Exim distribution
proved very helpful to me.
Of course, when it comes to lock stealing and other ugly (but
needed, I guess) stuff, Exim couldn't provide much help. ]
> Ah, well, I couldn't find any parts of Mailman in the CVS tree that
> acually _called_ steal, so I couldn't figure out what it should do
> in borderline cases.
The only place I know of is cron/gate_news.
> However, reading your LockFile.py made me realise how to steal the
> lock. LockFile.steal() now does its utmost best to steal the lock,
> only failing if someone else is busy stealing the lock from us. It
> returns 1 for success, 0 for failure, mostly because I wanted it to
> signify that in some way.
... but the caller should note that steal() returning 1 does not
necessarily imply that it is the owner of the lock (anymore). The
steal() stuff is bound to be full of race conditions, AFAICT -- so
whether it returns anything doesn't really matter (IMHO), as the
return code truly can't be trusted anyway.
Cheers,
--
Harald
[Jim Tittsler]
> A watermark value of 0 is used for two different purposes in cron/gate_news:
> 1. the group has never been gatewayed, so "catch up" to the highest article
> number
> 2. the highest article number seen for the group is 0 (which can be a valid
> "high article number" before the first posting in a newly created
> newsgroup)
> The result of this is the first article posted to the newly created newsgroup
> fails to get gatewayed to the mailing list because the watermark for that
> group is (still) 0 which is used as a flag to "catch up" so all that happens
> is the watermark gets set to 1.
>
> I believe I have fixed that in my copy by using the value None for the first
> time a group is gatewayed, allowing proper processing when the watermark is
> truly article number 0.
Hmmmm... When checking the contents of my "data/gate_watermarks"
marshal, I find several old mailing lists with an entry stating that
their watermark is 0 -- even though these lists aren't actually gating
any newsgroups.
As all these lists are rather old, I guess this could be how things
were stored in some early Mailman version -- back when gate_news were
forking processes to gate _all_ lists, regardless of whether the list
in question had requested that any gating should be done, and the
watermark file was written to by each and every child...
On checking this with CVS, it appears that revision 1.7 of gate_news
indeed has the behaviour I suspected, while 1.8, which was checked in
1998/12/18 00:22:23, seems to do it "right".
The upshot of this is that any list touch by rev. 1.7 (and maybe
earlier) which do not do any gating would possibly get *all* the
messages present in the group it's gating from posted to it if it
started gating after your patch was applied.
A possible way to approach all this would be to have "make update"
replace those 0 values in gate_watermarks with None values iff there
are no other None values (i.e. only change things on the first time
"make update" is run).
Or, even better, move the per-list watermark info from gate_watermarks
into the list's config.db, replacing any 0 values in gate_watermarks
with None values in config.db. This has the advantage of reducing the
number of different files that would have to be changed when
cloning/renaming a list.
--
Harald
Somehow, my /home/mailman/lists directory managed to get set
with permissions check_perms didn't check for; it was set to
d-wx-ws--x/mailman/mailman, which caused mailcmd to be unable to
list the directory (no read perms).
I fixed it once I figured it out, but I had a lot of check_perms
runs in there before I finally figured it out...mostly because
I was confused about what 'x' really means on a directory.
But check_perms could have saved me time if it had checked for
'owner-and-group-read'; I think it should.
Hi,
How about moving things like the list welcome message, headers, footers
and other multiple line texts out of the database and into seperate
text files? And treat/edit them in the same way as the html templates...
this would it also make it easier to edit them directly.
I remember having a lot of difficulties (when I started using mailman
about a year ago) with creating the welcome message because the textarea
was too small and strange things happened when i cut/pasted it into the
textarea with Netscape on Linux (I had to boot windows just to be able
to enter the welcome message properly ;) )
Ricardo.
--
