[prev] [thread] [next] [lurker] [Date index for 2006/10/31]
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