Bug 173139

This also affects RHEL3.

Note that Mandriva supplies in their latest SRPMS also following patch:
  mailman-2.1.5-date-overflows.patch.bz2


Should be perhaps also included.

--- mailman-2.1.5/Mailman/Queue/ArchRunner.py.date_overflows    2005-11-28
12:24:25.834395006 -0700
+++ mailman-2.1.5/Mailman/Queue/ArchRunner.py   2005-11-28 12:28:41.161403306 -0700
@@ -49,7 +49,7 @@
                 elif abs(now - mktime_tz(tup)) > \
                          mm_cfg.ARCHIVER_ALLOWABLE_SANE_DATE_SKEW:
                     clobber = 1
-            except ValueError:
+            except (OverflowError, ValueError):
                 # The likely cause of this is that the year in the Date: field
                 # is horribly incorrect, e.g. (from SF bug # 571634):
                 # Date: Tue, 18 Jun 0102 05:12:09 +0500
--- mailman-2.1.5/Mailman/Handlers/Scrubber.py.date_overflows   2005-11-28
12:26:39.825260152 -0700
+++ mailman-2.1.5/Mailman/Handlers/Scrubber.py  2005-11-28 12:28:41.161403306 -0700
@@ -113,7 +113,7 @@
 def safe_strftime(fmt, floatsecs):
     try:
         return time.strftime(fmt, floatsecs)
-    except (TypeError, ValueError):
+    except (OverflowError, TypeError, ValueError):
         return None


@@ -142,7 +142,7 @@
                      }.get(parts[3], 0)
             day = int(parts[4])
             year = int(parts[6])
-        except (IndexError, ValueError):
+        except (OverflowError, IndexError, ValueError):
             # Best we can do I think
             month = day = year = 0
         datedir = '%04d%02d%02d' % (year, month, day)


BTW: what happen to mailman maintainers?

Is it the following part ?

In mailman_2.1.5-10.diff.gz(debian):

--- mailman-2.1.5~/Mailman/Handlers/Scrubber.py	2003-12-01 02:43:18.000000000 +0100
+++ mailman-2.1.5/Mailman/Handlers/Scrubber.py	2005-11-13 15:29:26.585952860 +0100
@@ -266,7 +266,10 @@
             finally:
                 os.umask(omask)
             desc = part.get('content-description', _('not available'))
-            filename = part.get_filename(_('not available'))
+            try:
+                filename = part.get_filename(_('not available'))
+            except UnicodeDecodeError:
+                filename = _('not available')
             del part['content-type']
             del part['content-transfer-encoding']
             part.set_payload(_("""\
@@ -356,7 +359,10 @@
     # e.g. image/jpg (should be image/jpeg).  For now we just store such
     # things as application/octet-streams since that seems the safest.
     ctype = msg.get_content_type()
-    fnext = os.path.splitext(msg.get_filename(''))[1]
+    try:
+        fnext = os.path.splitext(msg.get_filename(''))[1]
+    except UnicodeDecodeError:
+        fnext = ''
     ext = guess_extension(ctype, fnext)
     if not ext:
         # We don't know what it is, so assume it's just a shapeless
@@ -375,7 +381,10 @@
     try:
         # Now base the filename on what's in the attachment, uniquifying it if
         # necessary.
-        filename = msg.get_filename()
+        try:
+            filename = msg.get_filename()
+        except UnicodeDecodeError:
+            filename = None
         if not filename:
             filebase = 'attachment'
         else:

the last one looks better

also RHEL3 is affected (mailman shipped in Update release)

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2006-0204.html