? 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.
Anyone else notice something weird about the mail below ? It was sent by
Guido to python-dev, where Barry picked it up from and sent it to both
mailman-developers and mailman-users. I am only subscribed to
mailman-developers, and I got it twice. What's more, the second mail seems
to have gone to mailman-developers *through* mailman-users. Notice the extra
list-sig at the obttom of the mail, and extra [listname] in the subject.
Bug in Mailman ? ;-P
----- Forwarded message from "Barry A. Warsaw" <barry(a)wooz.org> -----
Date: Mon, 30 Oct 2000 11:24:57 -0500 (EST)
From: barry(a)wooz.org (Barry A. Warsaw)
Sender: mailman-developers-admin(a)python.org
To: catholic.org(a)catholicnet.org.uk
Cc: mailman-developers(a)python.org
Cc: mailman-users(a)python.org
Subject: [Mailman-Developers] [Mailman-Users] forwarded message from Guido van Rossum
Date: Fri, 27 Oct 2000 20:42:42 -0500
From: Guido van Rossum <guido(a)python.org>
Sender: python-dev-admin(a)python.org
To: python-list(a)python.org (Python mailing list),
python-announce-list(a)python.org, python-dev(a)python.org
Subject: [Python-Dev] PythonLabs Team Moves to Digital Creations
To all Python users and developers:
[[ .. snip .. ]]
_______________________________________________
Python-Dev mailing list
Python-Dev(a)python.org
http://www.python.org/mailman/listinfo/python-dev
------------------------------------------------------
Mailman-Users maillist - Mailman-Users(a)python.org
http://www.python.org/mailman/listinfo/mailman-users
_______________________________________________
Mailman-Developers mailing list
Mailman-Developers(a)python.org
http://www.python.org/mailman/listinfo/mailman-developers
----- End forwarded message -----
--
Thomas Wouters <thomas(a)xs4all.net>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
> if getattr(mlist, 'auto_reject', 0):
> raise DiscardMessage
Very nice; had no idea that one little exception is all it
takes.
Is there anything similarly-simple to generate a generic bounce
message and discard, or is that all "call some reply method
and then raise DiscardMessage"?
Okay, my admins on www.lists.apple.com have had a chance ot dig out
from the upgrade, and are starting to speak out...
And they ALL want an option to auto-reject mail sent from unsubscribed users.
Barry, can we squeeze something like this into 2.0? (he says,
doubting it...) technically, it shouldn't be too tough, from a quick
glance.
--
Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com)
Apple Mail List Gnome (mailto:chuq@apple.com)
Be just, and fear not.
This is more a cautionary tale then a real problem, but it brings up
a couple of issues to chew on.
I started having major problems with mailman when I brought
lists.apple.com live (I'll have more to say about this site later,
since there are a couple of things I need to look into more fully
before I core-dump on that install...)
The main problem was that I was getting huge numbers of messages to
the -admin addresses that were blank. Zero. First, I thought it was a
corrupted list database. then I thought it was a corrupted request
database. Then I thought it was a corrupted message in the qfile dir
that was causing corrupted messages to multiply. Then I didn't know
what to think, so I just started taking the syste apart piece by
piece and running qfile messages through ONE AT A TIME to see where
the probelm came from. My favorite way ot spend a weekend, that's for
sure... (grin)
End result -- one minor configuration error in the mailer. One of the
hostnames I use wasn't set up as a local name, so sendmail kept
erroring out trying to talk to itself in one special case. But the
bigger issue was -- the system was doing exactly what I told it to do.
I use demime to strip incoming e-mail to the text part. this works
really pretty well. At some point, however, instead of just attaching
demime to the posting and -request address, I also added it to the
admin address.
Most incoming bounces now are in MIME format. End result: they come
to the -admin address, the mime gets stripped, and an empty message
results. Since it's no longer a bounce message, it gets sent to the
admin. load in a fairly dirty subscriber list and start sending
messages -- and you get 10K blank message in your mailbox in the
morning.
Cautionary note: after you double-check all your configuration files
for problems, make syure you double-check all the custom stuff you
did that you did it right. The "good" thing about this particular
problem is that while I was busy mailbombing myself and my admins all
weekend fighting this beast, to the end user, the site worked fine...
If you HAVE to have problems, problems that arne't visible to the end
user are preferable...
But it brings up a couple of issues I see with qrunner.
first, it seems like qrunner re-stats the qfiles dir and reloads its
idea of what needs to be run. This creates a problem when you have
lots of messages, since it's not processing things FIFO -- I found
that some older messages were simply NEVER being run, because however
qrunner was choosing messages out of qfiles, it wasn't choosing them.
On a busy system, this can be a problem. I suggest instead that
qrunner start up, grab the list of messages to run, and run them,
oldest first, then exit. Let the next Qrunner handle what comes in in
the meantime. That way, things are run more of a FIFO, and you don't
get into the lost-stepchild queue file problem.
second, qrunner isn't good at letting me know what it's doing. If I'm
trying to figure out what it's processing, it's not telling me. When
trying to debug a possible corrupted file, that's a real hassle. It'd
be nice if it put something in qfiles that told me what fileset it
was working on, just so I can whack at it if I need to.
all in all, it's been a, um, fun weekend. But I now have demime doing
what it's supposed to be doing, and it is working a LOT better. And
it explains (in retrospeect) why, knowing the subscriber lists were
dirty, I wasn't seeing very many bounces... (grumble. That should
have been a hint. Hindsight is fun...)
*now* it's stable... (I think)
--
Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com)
Apple Mail List Gnome (mailto:chuq@apple.com)
Be just, and fear not.
We got the following error log:
Oct 25 16:31:00 2000 (4885) Bouncer exception: body
Oct 25 16:31:00 2000 (4885) Traceback (innermost last):
File "/var/mailman/Mailman/Bouncers/BouncerAPI.py", line 65, in
ScanMessages
mlist.RegisterBounce(addr, msg)
File "/var/mailman/Mailman/Bouncer.py", line 141, in RegisterBounce
self.HandleBouncingAddress(addr, msg)
File "/var/mailman/Mailman/Bouncer.py", line 236, in HandleBouncingAddress
text = text + \
AttributeError: body
... in combination with:
Oct 25 16:31:00 2000 (4885) unknownlist: - unknownuser(a)domain.ext
exceeded limits
Oct 25 16:31:00 2000 (4885) Alleasr: disabled
unknownuser(a)domian.ext
[hosts and e-mail address anonymized]
Obviously, disabling of an adress due to more than the allowed number of
bounces causes this error message.
Does this bug is going to be fixed in mailman 2.0 final?
Thanks in advance.
I've been moving a number of our lists to mailman in recent days and the
question about additional data to qualify subscribers has come up.
Some listowners want to know who the subscriber is and what their role is.
All are working the legal community and more sensitive about such matters
than the normal human.
So the question is: can I or should I add new elements like username or
userrole to config.db? What are the ramifications?
And can I define new variables in the needed programs of Mailman?
I must confess that I'm still using Mailman 1.1. Could I address my
problem with Mailman 2.x?
Any insights are appreciated.
Joe Hewitt joe(a)apollo.wuacc.edu
Barry:
lists.apple.com 249# ~chuq/bumpdigests
Traceback (innermost last):
File "/export/home/chuq/bumpdigests", line 35, in ?
import paths
ImportError: No module named paths
--
Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com)
Apple Mail List Gnome (mailto:chuq@apple.com)
Be just, and fear not.
it's monday, so users are starting to weigh in on the ugpraded
server. For the most part, it's pretty positive.
with one exception. they hate the text digest format. And in fact,
one user pointed out (correctly, it seems) that it's not conformant
with the digest RFC:
<http://www.rfc-editor.org/rfc/rfc1153.txt>
Looks like mailman as it's set up doesn't use a conformant separator,
and doesn't order header lines properly to the RFC.
Also, I've had a number of requests to bump the volume number. That
one is pretty badly hidden (it seems to be in Mailman/MailList.py).
That really needs to be made configurable through Defaults.PY, as
should (IMHO) the separator (which is hidden in Handers/ToDigest.py
as MIME_NONSEPARATOR.
it'd be Really Nice, also, if there were some programmatic way to
bump the volume, so it could be stuffed into cron and run at 0:00
1/1/*. And, to be honest, volume numbers need to (eventually) be
per-list...
These are primarily cosmetic issues, but I really think most of them
need to be looked at before 2.0 ships. Per-list volumes is beyond the
scope of this release, but the rest need to be looked at, especally
since the Mailman digest format breaks everyone's
digest-auto-processors (and yes, MIME digests are the real answer,
but not everyone is ready for them yet, and there's no reason to
arbitrarily break things...0
--
Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com)
Apple Mail List Gnome (mailto:chuq@apple.com)
Be just, and fear not.
This came up on the reiserfs list:-
hans(a)reiser.to said:
> One other thing we could consider doing is tagging all emails from
> nonsubscribers specially so that people can choose whether to filter
> them out.
Its an interesting idea - an open list but with an additional tag
(ideally an optional subject munging - except that would tend to
propagate into future postings from members too - and a header added or
changed so that filters could recognise it)
[I'm not necessarily hugely keen on this, but its an interesting idea
which merits further discussion and maybe adding to a future features
list.
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 ]