[PATCH] Re: Output more detailed error on corrupt LocalStatus

[Sebastian Spaeth]

On Wed, 4 May 2011 10:30:37 -0700 (PDT), chris coleman wrote:
> I agree it's wise to store the one additional piece of info (Message-ID appears like it could be a unique key), making it possible to regenerate the damaged file in a few seconds, up to a minute.

The problem is that the Message-ID is not unique. In some cases its
missing and in some cases it has very weird and broken formats. But
that aside it is very easy to have multiple messages with the same ID in
your inbox: If I send an email to a mailing list, I will get the email
in my SENT folder and my INBOX. If you send me a mail and CC a mailing
list on which I am, I might get both in my INBOX. If offlineimap is
confused it uploads the same message again to the server, leading to
multiple mails with the same ID.

In some cases the mails will be virtually the same, but in some cases
they will have different headers (if they traveled different paths). Not
to speak of horribly broken mailers that produce identical Message-IDs
(I can't give an example, but I heard it occurs).

Message-ID and some MD5/SHA1 hash can enable us to at least say that a
message is identical (well, MD5 would suffice for that :-)), so it would
go a long way in limiting the number of candidates. But there is
unfortunately no guarantee that Message-ID alone identifies a mail.

> Without the Message-ID to identify each message absolutely, is it
> possible there could be a condition where the data in LocalStatus
> becomes useless, and that would force re-downloading and re-uploading
> the entire mailbox. 

Only in the IMAP->IMAP case. For IMAP->Maildir we are already now able
to keep the local maildir and regenerate the LocalStatus without having
to upload/download anything. The IMAP<->IMAP case is tricky as we need
the UID mapping of messages between servers. For this, the Message-ID
would be helpful in reconstructing it.

Sebastian
-------------- 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/20110504/d60b8e2b/attachment-0001.sig>