> -----Original Message-----
> From: mailman-developers-bounces+john.airey=rnib.org.uk(a)python.org
> Behalf Of Tollef Fog Heen
> Sent: Monday, 06 September 2004 16:47
> To: mailman-developers(a)python.org
> Subject: Re: [Mailman-Developers] Min requirements for
> running Mailman?
> * Nigel Metheringham
> | I'd tend to take this as:-
> | * Mailman is a bitch to package
> Not really. It's fairly well-behaved in my experience. It's a
> semi-large web application with some requirements, but nothing
> | * RH have packaged it for a while
> | * RH found a good few of the gotchas in packaging Mailman
> | * RH have subsequently learnt from their mistakes and recently
> | have produced good packages.
> | * Other distros may do better, or may yet have to
> learn from their
> | mistakes :-)
> Mailman has been in Debian since June 1998 (1.0b4), so we've been
> working on it for a while as well. I think our packages are of good
> quality (far from perfect, but making perfect packages is _a lot_ of
> work. ;)
Just to throw my tuppence worth in...
I've used mailman since Red Hat 7.2. I found that the version that came with
Red Hat 9.0 wouldn't work for me (ie I couldn't upgrade to it) so I stuck
with the 7.2 version (2.0.13) till the end of Red Hat 9 support.
We are now running the 2.1.5 version that comes with Fedora but running it
on Red Hat Enterprise Linux (RHEL). I did however have to recreate all the
lists by hand in an overnight shift (what fun that was...) a few days before
leaving the country (hence the rush). At that time I didn't know I could
export the configuration (Doh!).
Red Hat have taken some packages out of RHEL eg arpwatch and mysql-server
(although this is in the "extras" channel) even though these are in the
source RPM. Mailman is currently not included but might be being put back in
to RHEL 4.0. I would like to hope so, as I find 2.1.5 far superior to
John Airey, BSc (Jt Hons), CNA, RHCE
Internet systems support officer, ITCSD, Royal National Institute of the
Bakewell Road, Peterborough PE2 6XU,
Tel.: +44 (0) 1733 375299 Fax: +44 (0) 1733 370848 John.Airey(a)rnib.org.uk
To truly believe in Evolution requires complete faith that life has no
meaning. Fortunately there are billions of people who aren't that stupid.
NOTICE: The information contained in this email and any attachments is
confidential and may be privileged. If you are not the intended
recipient you should not use, disclose, distribute or copy any of the
content of it or of any attachment; you are requested to notify the
sender immediately of your receipt of the email and then to delete it
and any attachments from your system.
RNIB endeavours to ensure that emails and any attachments generated by
its staff are free from viruses or other contaminants. However, it
cannot accept any responsibility for any such which are transmitted.
We therefore recommend you scan all attachments.
Please note that the statements and views expressed in this email and
any attachments are those of the author and do not necessarily represent
those of RNIB.
RNIB Registered Charity Number: 226227
Hi Developers and I18Ners,
I've bumped version number of mailman to 2.1.6a2 (a1 was not announced)
and made a tarball at my mailman-japanese site. Please get it at:
Mailman 2.1.6 should be compatible with Python 2.4 and including some
nice new features such as numbering in subject prefix and filtering
attachments by filename extensions.
Please download and test it and help us fixing bugs.
Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp
I see this topic has been discussed years ago, but I recently started
running some MailMan lists and this problem came up almost as soon as I
started running it. (Version 2.1.5)
Users WILL NOT set their clocks to some nicely synchronized time. This
is especially true since many of my subscribers are computer neophytes.
When sorted by date, some replies come before the original posting. The
worst offender is actually a highly competent computer user who claims
to have a defective clock in his laptop that produces messages from the
year 2080. (The truth of his claim is immaterial.) In an ideal world,
these things would never happen. This is not an ideal world.
There was a discussion about "not munging" the headers as a validation
for objecting to altering the "Date" header. Considering the actions of
"CookHeaders.py" and other files that variously alter the "Reply To"
header, delete unwanted headers, and obviously alter the "Subject" line,
these objections seem weak, if not ironic. The date set by the senders
computer is not sacrosanct. While it may have some "meaning," it is of
no "use." Also, if the date isn't set properly, it probably isn't even
important to the sender.
Since all of these messages are, in fact, being sent by my server I
think it quite reasonable to change the "Date" to reflect the time that
it was processed and changed by the server. I'm the one who has to
answer questions about why the archive dates seem wrong and who is
ultimately responsible for the smooth operation of the service. I would
LIKE this to be an option that I could set. I do not have the time or
inclination to write the code to make this a user option. However,
since it something I wanted applied to all of my lists, I added the code
to copy the "Date" field to "X-Original-Date" and put in the server's
time as the "Date."
Suddenly, my new archives are coherent. I don't have to worry about
aberrant or obnoxious users. I only added six lines of code (and two
imports) to "CookHeaders.py" to make this work. PLEASE tell me I wasted
my time and there is a simple option I can set! Tell me that I don't
have to port this code when I want to upgrade!
I don't speak Python, and I know I imported more than necessary, but it
seems to work. I'm including the code changes both to share what I
found to be Very Useful and to have others sanity-check my code. As I
said, I never wrote a line of Python before this.
PS I considered sending this message from the year 2080 as I've had to
deal with, but I thought I'd give you a chance to implement this patch
PPS No, I don't WANT there to be a "fuzzfactor" allowing "close enough"
dates. Server Time Only.
# SKuck Header additions to CookHeaders.py of Mailman 2.1.5 - Nov 18, 2004
from email.Utils import parsedate_tz, mktime_tz, formatdate
# End SKuck Header additions
msg['List-Id'] = listid_h
# The above included as an insertion location reference. I think
it'll work from anywhere in "def process"
# SKuck added to pounce on bad email time stamps.
originaldate = msg.get('date')
receivedtime = formatdate(time.time())
msg['Date'] = receivedtime
msg['X-Original-Date'] = originaldate
# End SKuck added
If the invited person uses the link included in an invite and tries to
cancel the invitation themselves, this happens....
Bug in Mailman version 2.1.5
We're sorry, we hit a bug!
If you would like to help us identify the problem, please email a copy of
this page to the webmaster for this site with a description of what
Traceback (most recent call last):
File "/Tools/SunOS_5.9_i86pc/mailman-2.1.5/scripts/driver", line 87, in
File "/Tools/SunOS_5.9_i86pc/mailman-2.1.5/Mailman/Cgi/confirm.py", line
114, in main
subscription_cancel(mlist, doc, cookie)
File "/Tools/SunOS_5.9_i86pc/mailman-2.1.5/Mailman/Cgi/confirm.py", line
312, in subscription_cancel
userdesc = mlist.pend_confirm(cookie)
File "/Tools/SunOS_5.9_i86pc/mailman-2.1.5/Mailman/Pending.py", line 141,
2.3.4 (#1, Oct 5 2004, 07:57:49) [C]