Currently, whenever Mailman delivers a message to a list, a
list-specific `Sender' header is appended. As RFC822 specifies that
there should only be at most `Sender' header in any message, appending
is not right if there already is such a header present (e.g. whenever
the senders MUA added a `Sender' header).
The included (untested, but simplistic) patch (against current CVS
Mailman) tries to fix this.
[ However, I suspect my patch might not work for messages already
containing multiple `Sender' headers when Mailman receives them, as
Message.SetHeader doesn't appear to really be "crushing duplicates"
in those cases. ]
To cater for umbrella lists, similar fixes should probably be applied
to the `Errors-To' and `X-Mailman-Version' header appending in
--- Mailman/Deliverer.py.orig Sun Nov 29 22:12:12 1998
+++ Mailman/Deliverer.py Sun Nov 29 22:11:17 1998
@@ -110,7 +110,7 @@
msg.headers.append('Reply-To: %s\n' % self.GetListEmail())
- msg.headers.append('Sender: %s\n' % self.GetAdminEmail())
+ msg.SetHeader('Sender', self.GetAdminEmail())
if not msg.getheader('list-id'):
msg.headers.append('List-Id: %s\n' % self.GetListIdentifier())
msg.headers.append('Errors-To: %s\n' % self.GetAdminEmail())
> Anyone working on setting up the bounce detector for qmail/exim error
> messages ? I can send examples.
I developed such a bounce manager, AnaBounce. It recognises Exim and
othere MTA's bounce formats. Bounces are analysed, classified (by level
of recognition). A CGI gives access to results and makes it possible
to unsubscribe bad addresses from the list (provided that the list
is managed with SYMPA).
I haven't translated the README in english yet.....
Olivier SALAÜN Comité Réseau des Universités Tel: 02 99 84 71 27
Campus de Beaulieu 35042 Rennes Cedex
Anyone working on setting up the bounce detector for qmail/exim error
messages ? I can send examples.
Madarasz Gergely gorgo(a)caesar.elte.hu gorgo(a)linux.rulez.org
It's practically impossible to look at a penguin and feel angry.
Egy pingvinre gyakorlatilag lehetetlen haragosan nezni.
If a user submits a subscription request where the name does not include
a fully-qualified domain name, then everything blows up hard.
Mailman fails to recognize the bounce properly, attempts to parse it,
fails, sends a response, that bounces, it parses, it replies... BLAM.
Your machine's load average skyrockets and your mail queue starts to
Even worse is that it doesn't terminate. I had to shut down the sendmail
listener, clean the mail queue, and clear mailman's pending mail queue.
You also have to watch out from cron in case it tells mailman to process
its queue :-).
Back in August, this bug took out my system (had to reset and cold
boot). Happened again today, but I was able to catch it after about 15
minutes of grinding. I've also since adjusted my since to queue at a
lower load average (so that I can actually get a time slice and some
virtual mem while I correct the problem).
Is there a tweak that I can apply to the bounce detection to fix the
Greg Stein, http://www.lyra.org/
There are two problems with digest option in 1.0b6 (also this was
a bug in ver 1.0b4 too).
1. I can't set digest mode via email. The 'set digest on pw'
command returns with 'succeeded', but the next 'options' command
shows, that digest is off. So, I can set digest mode only via the
2. When subscribing to digest, I receive the email in MIME. No
matter which is the default format (mime/plain). I want the plain
mode to be the default.
I sent this once before and didn't hear anything. I just got my third
copy of this. Looking at the mailman-developers archive, it appears that
others are getting it to.
Can we get some kind of word on what the problem is?
Greg Stein, http://www.lyra.org/
I was away at the Python conference all last week, so it's nice to see
there are only about 113 Mailman messages to catch up on :-). I will
say that I thought Ken's talk went well, and we certainly had a lot of
interest from Pythoneers about Mailman. We had a lot of interesting
off-line discussions about where Mailman is and where it could go.
The following are my thoughts on what we need to do in the short
term. I would like to have a stable 1.0 release by the time of the
Usenix LISA 98 conference, where we have another paper and where John
will (hopefully) be giving a talk. This isn't very far away so I feel
we need to be *really* conservative in what we try to do before then.
I agree with John that internationalizing Mailman should be a top
priority, but I don't really think we can make much headway in the
next 3 weeks or so. In my experience CVS branches suck so I try to
avoid them, but if other core developers have more confidence in them,
I'll go along for the ride.
I think we should shoot for NO new features, but just banging the hell
out of the current source tree, expecting to have all the current bugs
shaken out in time for LISA. Once 1.0 is released, then we can talk
about an architecture for supporting all the contributed
translations. It's great to see there's a lot of enthusiasm for
supporting languages other than English.
First I'd like to say sorry I've kindof dropped off keeping up with
mailman over the last few days. I will come back, i've just been
really busy with other stuff.
At any rate, there's a problem with the way certain processes have to
wait for the completion of delivery of a message (or even lotsa
messages) before finishing.
you'll note that mass subscribe, admindb, convert_list, and many other
processes can trigger a mail delivery and that in many of those cases,
waiting for the delivery causes problems (especially the cgi's).
Here's an idea of how to deal with. i'm just bouncing this off
everyone for now:
add a mechanism that just queue's messages in mailman's mail queue,
and let the run_queue cron job take care of it.
some things to consider about this:
1) there's been talk of setting up mailman to allow command line
delivery again (i'm all for this). we'd have to take that into
account in run_queue.
2) the cgi's would no longer immediately make those deliveries, the
deliveries would take place on the next cron job. this may not be
entirely appropriate in some cases, like receiving a confirmation
messages upon subscribing from the web.
this is a problem that i believe should be addressed before v1 or
what do y'all think?
There are a number of obsolete files in the distribution. Should be
Also, there is a general problem in the code with using os.path.join to
construct URLs. A URL is NOT a file path. You don't want to use ":" or
"\" if Mailman is run on a different platform. The os.path.join should
go away and string concat should be used with "/".
HTMLFormatter.py: lines 96 and 299
Cgi/admin.py: 220, 401
Cgi/edithtml.py: 95, 161
Archiver/Archiver.py: 118, 122
Also, line 101 of MailList.py has a hard-coded "/" rather than using
Finally: Archiver/Archiver.py:122 should have a trailing "/" on the
public archive URL. The trailing slash prevents an internal redirection
in Apache -- this screws me because it switches the hostname from a
CNAME to the "real" hostname.
Greg Stein, http://www.lyra.org/