In examine_updates() which is periodically executed in the IMAP watch
thread, the mailbox's contents get fetched regardless if the user has
fetched the mailbox before. That means eg a large mailbox that was
unused by the user might perform a large fetch all of a sudden without
the user's knowledge/touch.
Add `warm` property in ImapMailbox that states whether the mailbox has
been loaded before in current execution.
Closes#88 IMAP: don't examine unloaded mailboxes for updates, just for message count stats
In some cases when handling new server events, the entire body message
was unnecessarily fetched.
Closes#87 IMAP: don't fetch RFC822 except when requested
Previous commit changed bincode deserializes in maildir and sqlite3.rs
from bincode::deserialize_from to using bincode::config::DefaultOptions
and bincode::Options trait's method deserialize_from.
However, these two different deserializes use a different default
settings: https://github.com/servo/bincode/issues/348
Specifically, varint encoding for integers is the default for
DefaultOptions but not when using bincode::{de,}serialize_* functions.
That means that serialized structs were not able to be deserialized.
This commit makes all {de,}serializations use the DefaultOptions
interface rather than the top level functions.
If struct memory layout changes, bincode deserialize fails with memory
allocation error of an obscene amount of bytes. Set upper limit to
deserialized bytes in each place deserialize happens.
Meli currently uses the .well-known/jmap URL and the RFC8620 requires that any redirects are followed (https://tools.ietf.org/html/rfc8620#section-2.2). This small change allows redirects to happen.
Threading was broken if information was needed from References header.
For example, mailman might alter some Message-IDs when using its NNTP
bridge and the complete references are necessary to rebuild the thread,
which is only available in References whereas ENVELOPE has only
In-Reply-To.
FETCHing RECENT messages when receiving an untagged RECENT response from
the server didn't separate the message numbers with comma but with
space, which is invalid.