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
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not For Hire (currently)
_______________________________________________
mailmate mailing list
mailmate@lists.freron.com
https://lists.freron.com/listinfo/mailmate
