Today I am releasing Mailman 2.1.5, a bug fix release that also contains new support for the Turkish language, and a few minor new features. Mailman 2.1.5 is a significant upgrade which should improve disk i/o performance, administrative overhead for discarding held spams, and the behavior of bouncing member disables. This version also contains a fix for an exploit that could allow 3rd parties to retrieve member passwords. It is thus highly recommended that all existing sites upgrade to the latest version.
The full source tarball, as well as a patch against Mailman 2.1.4 have been made available. See
http://sourceforge.net/project/showfiles.php?group_id=103for links to downloads.
NOTE: You will want to read the UPGRADING file for important information regarding upgrading from earlier version to Mailman 2.1.5. A number of internal file formats have changed so you must shut down web and mail access to Mailman before you upgrade. You will also want to re-run configure (i.e. config.status) before you run "make install".
See also:
http://www.list.org
http://mailman.sf.net
http://www.gnu.org/software/mailmanFinally, a personal note. I have left Zope Corporation to join Secure Software, a company started by John Viega -- Mailman's original author. Although I won't be working on Mailman in any official capacity, it is exciting to be working with him and the rest of the folks there. I leave Zope Corp on a positive note and wish nothing but success for them too.
You can find Secure Software on the web at http://www.securesoftware.com. Please continue to use my barry@python.org email address for all Mailman correspondences. I don't expect much to change for the Mailman project at all.
Enjoy, -Barry
2.1.5 (15-May-2004)
- The admindb page has a checkbox that allows you to discard all held
messages that are marked Defer. On heavy lists with lots of spam holds,
this makes clearing them much faster.
- The qrunner system has changed to use only one file per message.
However the configuration variable METADATA_FORMAT has been removed, and
support for SAVE_MSGS_AS_PICKLES has been changed. The latter no longer
writes messages as plain text. Instead, they are stored as pickles of
plain strings, using the text pickle format. This still makes them
non-binary files readable and editable by humans.
bin/dumpdb also works differently. It will print out the entire pickle
file (with more verbosity) and if used with 'python -i', it binds msg to
a list of all objects found in the pickle file.
Removed from Defaults.py: PENDINGDB_LOCK_TIMEOUT,
PENDINGDB_LOCK_ATTEMPTS, METAFMT_MARSHAL, METAFMT_BSDDB_NATIVE,
METAFMT_ASCII, METADATA_FORMAT
- The bounce processor has been redesigned so that now when an address's
bounce score reaches the threshold, that address will be sent a probe
message. Only if the probe bounces will the address be disabled. The
score is reset to zero when the probe is sent. Also, bounce events are
now kept in an event file instead of in memory. This should help
contain the bloat of the BounceRunner.
New supporting variables in Defaults.py: VERP_PROBE_FORMAT,
VERP_PROBE_REGEXP
REGISTER_BOUNCES_EVERY is promoted to a Defaults.py variable.
- The pending database has been changed from a global pickle file, to a
unique pickle file per mailing list.
- The 'request' database file has changed from a marshal, to the more
secure pickle format.
- Disallow multiple password retrievals.
- The email package is updated to version 2.5.5.
- New language: Turkish.
- Bugs and patches: 869644, 869647 (NotAMemberError for old cookie data),
878087 (bug in Slovenian catalog), 899263 (ignore duplicate pending
ids), 810675 (discard all defers button)
Barry Warsaw wrote:
NOTE: You will want to read the UPGRADING file for important information regarding upgrading from earlier version to Mailman 2.1.5. A number of internal file formats have changed so you must shut down web and mail access to Mailman before you upgrade. You will also want to re-run configure (i.e. config.status) before you run "make install".
First of all, thanks for releasing another update for Mailman!
But I upgraded mailman over the weekend (from 2.1.4 to 2.1.5) and only today I noticed that moderated messages generates errors... I think it has something to do with my version of python (2.1 from Debian Stable) not having True/False booleans by default. The weird thing is that it does seem to work correctly in other scripts, but ListAdmin.py generates an error:
May 17 19:44:25 2004 (27717) Uncaught runner exception: global name 'True' is not defined May 17 19:44:25 2004 (27717) Traceback (most recent call last): File "/usr/local/mailman/Mailman/Queue/Runner.py", line 111, in _oneloop self._onefile(msg, msgdata) File "/usr/local/mailman/Mailman/Queue/Runner.py", line 167, in _onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/usr/local/mailman/Mailman/Queue/IncomingRunner.py", line 130, in _dispose more = self._dopipeline(mlist, msg, msgdata, pipeline) File "/usr/local/mailman/Mailman/Queue/IncomingRunner.py", line 153, in _dopipeline sys.modules[modname].process(mlist, msg, msgdata) File "/usr/local/mailman/Mailman/Handlers/Moderate.py", line 67, in process ModeratedMemberPost) File "/usr/local/mailman/Mailman/Handlers/Hold.py", line 214, in hold_for_approval id = mlist.HoldMessage(msg, reason, msgdata) File "/usr/local/mailman/Mailman/ListAdmin.py", line 180, in HoldMessage id = self.__nextid() File "/usr/local/mailman/Mailman/ListAdmin.py", line 113, in __nextid while True: NameError: global name 'True' is not defined
I tried adding the True/False defines on top of ListAdmin.py like I saw in some other mailman scripts, but that doesn't seem to work... any idea what is going on?
TIA...
Ricardo.
On Mon, 2004-05-17 at 13:55, Ricardo wrote:
But I upgraded mailman over the weekend (from 2.1.4 to 2.1.5) and only today I noticed that moderated messages generates errors... I think it has something to do with my version of python (2.1 from Debian Stable) not having True/False booleans by default.
Dang, dang, dang. It's getting quite untenable to continue to support older Pythons, even in the Mailman 2.1 branch. Given that Python 2.1 and 2.2 are no longer being supported by the PSF, I've very tempted to require Python 2.3 for some upcoming patch version of Mailman 2.1. How much hardship would that impose on folks?
I tried adding the True/False defines on top of ListAdmin.py like I saw in some other mailman scripts, but that doesn't seem to work... any idea what is going on?
Did you do a "mailmanctl restart" after patching that file? I'll upload a patch to SF, but it probably does mean a 2.1.6 isn't very far away.
-Barry
It would be a hardship over here. Not super major, but if it's a matter of a few simple defines, that would be a major blessing.
Bob
---------- Original Message ----------- From: Barry Warsaw <barry@python.org> To: Ricardo <ricardo@rixhq.nu> Sent: Mon, 17 May 2004 22:12:49 -0400 Subject: Re: [Mailman-Developers] RELEASED Mailman 2.1.5
On Mon, 2004-05-17 at 13:55, Ricardo wrote:
But I upgraded mailman over the weekend (from 2.1.4 to 2.1.5) and only today I noticed that moderated messages generates errors... I think it has something to do with my version of python (2.1 from Debian Stable) not having True/False booleans by default.
Dang, dang, dang. It's getting quite untenable to continue to support older Pythons, even in the Mailman 2.1 branch. Given that Python 2.1 and 2.2 are no longer being supported by the PSF, I've very tempted to require Python 2.3 for some upcoming patch version of Mailman 2.1. How much hardship would that impose on folks?
I tried adding the True/False defines on top of ListAdmin.py like I saw in some other mailman scripts, but that doesn't seem to work... any idea what is going on?
Did you do a "mailmanctl restart" after patching that file? I'll upload a patch to SF, but it probably does mean a 2.1.6 isn't very far away.
-Barry
Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/bob%40nleaudio.com ------- End of Original Message -------
Barry Warsaw wrote:
But I upgraded mailman over the weekend (from 2.1.4 to 2.1.5) and only today I noticed that moderated messages generates errors... I think it has something to do with my version of python (2.1 from Debian Stable) not having True/False booleans by default. Dang, dang, dang. It's getting quite untenable to continue to support older Pythons, even in the Mailman 2.1 branch. Given that Python 2.1 and 2.2 are no longer being supported by the PSF, I've very tempted to require Python 2.3 for some upcoming patch version of Mailman 2.1. How much hardship would that impose on folks?
Well, Debian stable doesn't go beyond python2.2, so that would mean Debian users will either need to install python from source or find a backport. It'll take a while before the new stable Debian is released. I don't now the state of other distro's. In my case installing from source would be an option, but I'm not a big fan of it. But what I was thinking, does it really have to be defined seperatedly in every python file which uses it? I'd think there should be a way in python to define it in just one place.
Ricardo.
On Monday, May 17, 2004, at 11:28 PM, Ricardo wrote:
Well, Debian stable doesn't go beyond python2.2, so that would mean Debian users will either need to install python from source or find a backport. It'll take a while before the new stable Debian is released. I don't now the state of other distro's. In my case installing from source would be an option, but I'm not a big fan of it.
Mac OS X 10.3 has Python 2.3, but Mac OS X 10.2 has 2.2; our web server has 10.2 and is likely to stay that way for about one more year. (Apple continues to support Mac OS X 10.2 and 10.2 Server with security updates.) Given current time constraints and lack of desire to track down dependencies, I probably would not perform any mailman upgrade that also required a python upgrade unless the python upgrade was *exceedingly* simple and did not require *any other* software or libraries to change; it was "interesting" enough getting mailman to work across two different platforms--the web portion and the mail portion are on Mac OS X and a very old Solaris, respectively.
On the other hand, I'm pushing for an integrated solution in which mailman's mail server and web server are both on the same machine, in which case this would no longer be a problem.
So in our case, it most likely will be an issue for about another year.
Jerry jerry@sandiego.edu http://www.sandiego.edu/~jerry/ Serra 188B/x8773
"The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at and repair."--Douglas Adams (Mostly Harmless)
On Tue, 2004-05-18 at 08:28, Ricardo wrote:
Dang, dang, dang. It's getting quite untenable to continue to support older Pythons, even in the Mailman 2.1 branch. Given that Python 2.1 and 2.2 are no longer being supported by the PSF, I've very tempted to require Python 2.3 for some upcoming patch version of Mailman 2.1. How much hardship would that impose on folks?
Well, Debian stable doesn't go beyond python2.2, so that would mean Debian users will either need to install python from source or find a backport. It'll take a while before the new stable Debian is released. I don't now the state of other distro's.
Here's a summary of Python versions on other popular distro's:
RedHat: RedHat 8.0 has Python 2.2.1 RedHat 9.0 has Python 2.2.2 Fedora Core 1 has Python 2.2.3
Mandrake: Mandrake Linux 9.2 has Python 2.3 Mandrake Linux 10.0 has Python 2.3.3
Gentoo supports these Python versions: 2.3.1-r1, 2.2.2, 2.2.3-r5. 2.3.3, 2.3.3-r1, 2.3.4_rc1
Looks like RedHat users will have to build Python from source if 2.3 becomes a requirement... :)
-Daniel
At 12:22 PM +0200 2004/05/20, Daniel Buchmann wrote:
Looks like RedHat users will have to build Python from source if 2.3 becomes a requirement... :)
Looks like this problem is already becoming a frequent question on mailman-users. We should put something into the FAQ to address this, or fix the code to suit.
-- Brad Knowles, <brad.knowles@skynet.be>
"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania.
SAGE member since 1995. See <http://www.sage.org/> for more info.
On Thu, 2004-05-20 at 06:22, Daniel Buchmann wrote:
Here's a summary of Python versions on other popular distro's:
RedHat: RedHat 8.0 has Python 2.2.1 RedHat 9.0 has Python 2.2.2 Fedora Core 1 has Python 2.2.3
Looks like RedHat users will have to build Python from source if 2.3 becomes a requirement...
FC2 which was just released has 2.3.3 as will RHEL4. Red Hat users if they use Red Hat rpms will never have to build Python from source.
-- John Dennis <jdennis@redhat.com>
--On Thursday, May 20, 2004 13:45:57 -0400 John Dennis <jdennis@redhat.com> wrote:
FC2 which was just released has 2.3.3 as will RHEL4. Red Hat users if they use Red Hat rpms will never have to build Python from source.
Speaking as a RHEL 3.0 (3.1 Real Soon Now - maybe this one will work!) customer, I seriously doubt we'll be on RHEL 4 any time soon (or did Red Hat do a better job of getting ISVs on board this time?). Of course, we don't run mailman (that I know of), and if we did, compiling python would be no trouble at all.
-- Carson
On Thu, 2004-05-20 at 18:45, John Dennis wrote:
FC2 which was just released has 2.3.3 as will RHEL4. Red Hat users if they use Red Hat rpms will never have to build Python from source.
Don't expect people to be running the current release all the time or to hold off mailman updates until OS refreshes.
Many of the mailman updates within 2.1 have been security related updates, but now appear to be mandate underlying package updates that do not have security related problems. Python 2.3 is also less than a year from release so forcing its requirement for packages that are undergoing minor release updates appears to me to be premature.
Personally I'd argue for continuing to support Python 2.2 in the 2.1 series. If this is really impracticable then we should make sure the installer picks up the python version and refuses to install without major threats and bludgeoning if the local python is not up to scratch.
Nigel.-- [ Nigel Metheringham Nigel.Metheringham@InTechnology.co.uk ] [ - Comments in this message are my own and not ITO opinion/policy - ]
"Daniel" == Daniel Buchmann <Daniel.Buchmann@bibsys.no> writes:
Daniel> Here's a summary of Python versions on other popular
Daniel> distro's:[Linux reports elided]
On Mac OS X 10.3 (aka Panther), we have
Apple -> 2.3IIRC Mac OS X 10.2 (aka Jaguar) was Python 2.1. On the third-party ditribution front:
Fink -> 2.3.3
DarwinPorts -> 2.3.3by default. As far as I can tell from the config files in both cases 2.3 would be the default on earlier versions of Mac OS X as well (Fink has different distributions for 10.2 and 10.3, AFAIK DarwinPorts does not). I'll let somebody else judge whether the population at risk of inconvenience from requiring Python 2.3 is large enough to worry about.
-- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.
On Sat, 2004-05-15 at 19:22, Barry Warsaw wrote:
This version also contains a fix for an exploit that could allow 3rd parties to retrieve member passwords. It is thus highly recommended that all existing sites upgrade to the latest version.
Could you be more specific about the exploit? Is there a CVE or CAN open against it? I assume given the public announcement this is not an embargoed security exploit, or is it?
-- John Dennis <jdennis@redhat.com>
Hi John and Hi Barry.
John Dennis wrote:
On Sat, 2004-05-15 at 19:22, Barry Warsaw wrote:
This version also contains a fix for an exploit that could allow 3rd parties to retrieve member passwords. It is thus highly recommended that all existing sites upgrade to the latest version.
Could you be more specific about the exploit? Is there a CVE or CAN open against it? I assume given the public announcement this is not an embargoed security exploit, or is it?
The exploit is very easy for anyone who can view the source (and diff) with curiosity. So, we should send CVE/CAN ASAP, I think.
-- Tokio
participants (11)
-
Barry Warsaw -
Bob Puff＠NLE -
Brad Knowles -
Carson Gaspar -
Daniel Buchmann -
Jerold Stratton -
John Dennis -
Nigel Metheringham -
Ricardo -
Stephen J. Turnbull -
Tokio Kikuchi