[ANNOUNCE] OfflineIMAP v6.3.2-rc3 released

Sebastian Spaeth Sebastian at sspaeth.de
Tue Feb 8 10:21:42 GMT 2011

On Tue, 8 Feb 2011 08:51:07 +0300, Ivan Semin <ivun at wirebyte.com> wrote:
> I am running Centos 5, which is probably the most used OS on
> production webservers. That has 2.4 out of the box and unfortunately
> most end users are unable to update it. So at least you should warn in
> docs about that requirement.

Well, there are patches to make it still work on python 2.4. It's just
that I didn't test it on python 2.4 myself. So it's good that people
scream if they find bugs. That's what we have the rc's for :-).

>     successuid = tryappend.savemessage(uid, message, flags, rtime)
> error: APPEND command error: BAD ['Could not parse command']
> imap: Returned object from fetching 3032: ('OK', [('2990 (UID 3032
> BODY[] {32746719}',
> imap: savemessage: new content length is 32746809

> The number 32746809 makes me think about some limit to the message size?

Yep, that very much does sound like a limit to the message size. What is
the local IMAP server?

Google finds that Zimbra seems to be saying:
2214 BAD parse error: request too long

Others seem to be saying TOOBIG. I am not fit enough in IMAP RFCs to
know what the right answer should be.

A "Could not parse command" error message, doesn't seem to helpful

I am not sure how well we are protecting against these message limit
failures, but we probably should be more robust here too.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/offlineimap-project/attachments/20110208/a58005c0/attachment-0001.sig>

More information about the OfflineIMAP-project mailing list