[MlMt] Ideas to reduce the footprint of MailMate

[Bill Cole]

On 9 May 2020, at 15:45, Travis Risner wrote:

> Hi Guillaume,
>
> I have no direct knowledge of how MM works, but I have suspicions.  If 
> MM is __synchronizing__ with all the IMAP servers, then I suspect that 
> it has to do something for each of the 200,000 (or 500,000) emails to 
> verify that it is still there and hasn’t changed.

One fundamental rule of IMAP is that messages never change. Message 
flags can change, but the combination of mailbox name, UIDVALIDITY value 
for the mailbox, and UID must refer to a single immutable message on 
that server forever. Re-downloading a message only happens if the client 
or server has a major failure that forces a rebuild of its message 
indices.

> Maybe it downloads each email and compares checksums.  Maybe it has a 
> clever way of interacting with the IMAP server so it does not have to 
> download every byte of each email.  Even so, MM still has to do 
> something for each email every time it checks.  That might be what is 
> chewing up all the bandwidth.

IMAP synchronization does not usually require examination of every 
message. Instead, when a SELECT command is executed for a mailbox, the 
server responds with mailbox metadata which is roughly 400 bytes total, 
describing the state of the mailbox and its messages. This allows the 
client to determine what it needs to do to synchronize the mailbox. If 
nothing in a mailbox has changed since last sync and the server supports 
the "CONDSTORE" extension (as most do,) the client doesn't even need to 
look at any message flags. Without CONDSTORE, reliable synchronization 
requires the client to check the flags of all messages in a mailbox, 
which is a few dozen bytes per message in extreme cases.


-- 
Bill Cole
bill at scconsult.com or billcole at apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not For Hire (currently)