offlineimap does not delete messages on server

Sebastian Spaeth Sebastian at
Tue May 17 13:00:39 BST 2011

On Mon, 16 May 2011 16:54:39 -0700, Antonio Terceiro wrote:
> Since I upgraded to the latest version of offlineimap my INBOXes started
> behaving weirdly, as if they were not being properly sync'ed with the IMAP
> servers. I move all my read messages to to local folders (not handled by
> offlineimap). But when sync again with offlineimap, those messages come back to
> my INBOX: it seems offlineimap did not delete them on the server, or did not
> perceived the fact that they were deleted locally.

Mmh, are you sure it only happens with the latest version? Because IMHO
nothing has changed between 6.3.2 and 6.3.3 that could affect this. But
I am sure you are right :-).

> This seems to happen only with my 'main' INBOX folders (for each account): the
> 'INBOX.*' folders are not affected by this problem, even though they *are*
> receiving new messages and I have tested deleting messages from them and they
> did not come back.

Now, that sounds really, really weird. We do not treat INBOX any
different from other folders.

> This happens with several different IMAP servers (all my 4 IMAP accounts), and
> I can reprodude it easily by some e-mails to myself, then syncing with
> offlineimap, then deleting messages locally and syncing again.  It does happen
> always, but happens frequently. When it happens, offlineimap gives warnings
> like this:
>   Deleting 6 messages (166, 167, 172, 173, 174, 175) in IMAP[INBOX]
>   WARNING: Attempted to modify flags for messages [166L, 167L, 172L, 173L, 174L, 175L] in folder IMAP[INBOX], but that folder is read-only.  No flags have been modified for that message.

Right, in this case, it detected local deletions, attempts to delete the
same messages on the IMAP server and fails because the folder claims it
is read-only. First, we removed it from the LocalStatus cache though. So
on the next sync, we detect the "unknown" new messages on the IMAP
server and transfer them to the local INBOX.

AFAIK, this is the expected behavior if we fail to delete a message on
the IMAP server. I would argue that we should not remove the message
From LocalStatus if we fail to delete the message in the
destination. This way, we would not retransfer the message from the IMAP
on the next sync, but retry to delete the deleted one (which would make
more sense). (current code snippet below)

in we do on deletion:
            for folder in [statusfolder, dstfolder]:

(and that should be a tad more sophisticated, checking for errors and
doing dstfolder first)

However, the remaining puzzle and underlying cause is, "why do we think
that INBOX is readonly" or why does the IMAP server actually tell
so. Can you gather a debug log when it happens with -d imap -l debug.log
and make it available (privately to me, if it contains sensitive
stuff). Make sure to scrub out your passwords in any case.

Thanks Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <>

More information about the OfflineIMAP-project mailing list