Got “unsized object” errors with Debian’s Mailman ? Try this patch !

Last week I came across a showstopper bug on Mailman 2.1.9-7, the current version of Mailman package distributed with Debian Etch.

Here is the python traceback (from /var/log/mailman/error logfile) I get each time I’ve sent a mail to my brand new mailing-list:

Dec 20 01:20:04 2008 (14275) Uncaught runner exception: len() of unsized object
Dec 20 01:20:04 2008 (14275) Traceback (most recent call last):
  File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 112, in _oneloop
    self._onefile(msg, msgdata)
  File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 170, in _onefile
    keepqueued = self._dispose(mlist, msg, msgdata)
  File "/usr/lib/mailman/Mailman/Queue/IncomingRunner.py", line 130, in _dispose
    more = self._dopipeline(mlist, msg, msgdata, pipeline)
  File "/usr/lib/mailman/Mailman/Queue/IncomingRunner.py", line 153, in _dopipeline
    sys.modules[modname].process(mlist, msg, msgdata)
  File "/usr/lib/mailman/Mailman/Handlers/ToDigest.py", line 81, in process
    mbox.AppendMessage(msg)
  File "/usr/lib/mailman/Mailman/Mailbox.py", line 69, in AppendMessage
    g.flatten(msg, unixfrom=True)
  File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten
    self._write(msg)
  File "/usr/lib/mailman/pythonlib/email/Generator.py", line 136, in _write
    self._write_headers(msg)
  File "/usr/lib/mailman/pythonlib/email/Generator.py", line 182, in _write_headers
    header_name=h, continuation_ws='\t').encode()
  File "/usr/lib/mailman/pythonlib/email/Header.py", line 412, in encode
    newchunks += self._split(s, charset, targetlen, splitchars)
  File "/usr/lib/mailman/pythonlib/email/Header.py", line 297, in _split
    elen = charset.encoded_header_len(encoded)
  File "/usr/lib/mailman/pythonlib/email/Charset.py", line 354, in encoded_header_len
    raise repr(s)
TypeError: len() of unsized object

Dec 20 01:20:04 2008 (14275) SHUNTING: 1229732404.1069181+dcd89a08bf7911dac2db804b76cd42d20564c71c

Here is the corresponding (anonymized) mail sent to the mailing list from a Gmail account:

Received: by 10.180.244.13 with HTTP; Fri, 19 Dec 2008 16:32:22 -0800 (PST)
Message-ID: <1f7b086f0812192632x7427c0f7u2048609ddd50673@mail.gmail.com>
Date: Sat, 20 Dec 2008 01:32:22 +0100
From: "Kevin" <kevin@my-domain.com>
To: my-ml@lists.my-domain.com
Subject: sqdfqsdfqsfd
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64
Content-Disposition: inline
Delivered-To: kevin@my-domain.com

LS0KS2V2LgogIOKAoiBiYW5kOiBodHRwOi8vY29vbGNhdmVtZW4uY29tCiAg4oCiIGJsb2c6IGh0
dHA6Ly9rZXZpbi5kZWxkeWNrZS5jb20K

And now my hackish tale. Based on a quick look at Mailman’s source code, I made an educated guess that this error is just a side effect of the wrong assumption that the s variable in the Charset.encoded_header_len() method is always a string. So I came up with the following evil patch to handle (gracefully, I hope) the case of s being None.

Here is the resulting patch of my python-fu:

--- /usr/lib/mailman/pythonlib/email/Charset.py.orig   2008-12-28 19:46:23.000000000 +0100
+++ /usr/lib/mailman/pythonlib/email/Charset.py        2008-12-20 01:42:37.000000000 +0100
@@ -351,6 +351,7 @@
             lenqp = email.quopriMIME.header_quopri_len(s)
             return min(lenb64, lenqp) + len(cset) + MISC_LEN
         else:
+            return s is not None and len(str(s)) or 0
             return len(s)

     def header_encode(self, s, convert=False):

And it do the trick ! Of course I can’t guarantee that this patch is the way to definitely fix the bug. And it may corrupt data. So use it only if you’re as crazy as me ! :D

But I know, I know… As a responsible and serious hacker (sigh), I should report this bug to the Debian or Mailman project. But I’m still not familiar with Dedian’s way of reporting bugs (and to be honest, I feel lazy these days :p ). Maybe, one day…

Google Apps’ video chat comes with secure Gmail sessions

The story was spread by all top tech blogs last week: Google’s Gmail now features a video chat. And it requires the installation of a dedicated plugin.

Alas, there is no such plugin for any other platform except “Windows XP and later” (according the official website) and Macs (as read on the official blog). So it’s a quite sad news for us Linux users. Indeed, I’m confident about a future seamless integration into the free software ecosystem, as the Gmail’s video chat is based on a stack of open (or soon-to-be, according the recent controversy) standards and protocols: XMPP/Jingle, h264/SVC & RTP.

Anyways, that’s not the main purpose of this post.

I just wanted to point out an update that was not reported by the news: as soon as it was officially made available for the public, the brand new video feature was released for Google Apps’ Gmail too.

Not only that, Google also backported to Apps’ Gmail the much awaited HTTPs option that allow you to force secure encryption of your sessions:

These two updates are quite interesting to note. I long as I remember (and I might be wrong), Google Apps components were always out-of-sync with their legacy equivalent. So this maybe a sign of change in a really good direction for Google Apps users ! :)

How-to import a Maildir++ folder to Kmail

Let’s say you have a local copy of a mail folder you want to browse with Kmail. This folder is normally found on a dedicated mail server and you access it through the IMAP protocol. I was in this situation some days ago and I will tell you how I’ve done it.

Instinctively, I assumed that my folder was of the Maildir format, and Kmail local mails too. So I tried to copy my ~/Maildir folder from the mail server to my local machine (~/.kde/share/apps/kmail/mail/). And that was the result in Kmail:

kmail-no-sub-folders.png

It looks good but it’s not: there is no sub-folders !

After some googling, I found what was wrong: my ~/Maildir folder is not a Maildir, but a Maildir++ folder. This kind of folder is handle by popular IMAP MTA like qmail, Dovecot and courier-imap (which was used on the mail server where my ~/Maildir come from). There is some advantages of using the “++” flavor of Maildir over the classic one, like quotas and sub-folders. Unfortunately Kmail is not able to read the Maildir++ folder structure.

To fix this, I’ve created a tiny python script to migrate a Maildir++ folder to Kmail.

How-to use it ? Simply:

  1. Download it to your disk,
  2. Edit it and change the MAILDIR_SOURCE and KMAILDIR_DEST variables to match your local configuration,
  3. Give it execution privileges,
  4. Run it !

I advise you to try it first in a safe environment (like under a temporary user account). And don’t forget to backup everything before playing with it: because this script work for me doesn’t mean that it will work for you ! ;)