Re: OfflineImap

[prev] [thread] [next] [lurker] [Date index for 2006/10/31]

From: Phil Pennock
Subject: Re: OfflineImap
Date: 13:49 on 31 Oct 2006
On 2006-10-31 at 05:28 +0000, Smylers wrote:
> OfflineImap crashes partway through syncing my mail with:
> 
>   Thread 'New msg sync from spam' terminated with exception:
>   Traceback (most recent call last):
>   [Snipped many lines of Python stack trace]
>   error: APPEND command error: BAD ['Invalid internal date.']

That BAD is a message from the IMAP server which you're syncing to.

OfflineIMAP's problem here apparently is that it's not gracefully coping
with an error from the server.  Buggy, yes.  Rejecting bad dates, no.

IMAP returns OK, NO or BAD in response to commands.  I mostly see BAD
from Cyrus IMAP, which can be rather picky.  The official stance from
the Cyrus team is roughly along the lines of: it's better to not expose
flakey mail-clients to potentially bad stuff and undefined behaviour, so
just reject it before it gets here.

> And this is despite the fact that the message is in the spam folder on
> this computer because I moved it there from my inbox, and it got to the
> inbox my, erm, you!  So you can happily sync invalid messages from the
> server to this computer, just not cope with sending them in t'other
> direction?

Your local server is more forgiving; the rejecting server apparently has
different checks for mail delivery from the MTA and for IMAP APPEND.
Possibly the problem is that the complaint is for the internal date &
time, which is per RFC set to time message received unless set via an
IMAP client.  In which case, the problem is explicitly in OfflineIMAP
setting the internal time, not the message-header time.

> Hate!

Target the hate and it's more intense and is more likely to help you
kick the hateful software for something more soothing.  If such soothing
software exists.  Which I doubt.

If the problem is OfflineIMAP providing a bad time string in the append,
then the easiest hack is to probably to change the python code to simply
not provide it -- it's optional.  RFC 3501 §6.3.11 (ooh look, linked to
that other recent thread).  The tricker but "better" fix would to ensure
that the internal times are preserved between servers by syncing the
right data.

-Phil

Generated at 15:01 on 01 Nov 2006 by mariachi 0.52