On Tue, Jul 30, 2019 at 01:47:35AM +0530, Pankaj Jangid wrote: > On Mon, Jul 29, 2019 at 03:13:37PM -0400, Dan Ritter wrote: > > IMAP is, explicitly, a mail protocol for clients to do the > > minimal amount of fetching necessary. You can do a full sync on > > top of it, but that's not what it's there for. > > A lot has changed since then. I remember I used to pop everything > because the mailserver quota was less than 10mb (20 years back). And > then take backup of local emails on floppy drives. > > Now we check emails on mobiles, browser and obviously *mutt*. There must > be some inclusive intuitive changes now.
But none of this really affects how IMAP works, or should work. If
anything, it's a recommendation for using IMAP as intended.
As far as I can tell, your whole motivation is to avoid a bit of
latency as each message is downloaded for display, by downloading all
the messages ahead of time (and I guess storing them in some local
cache? Or something)... But that's sort of the antithesis of IMAP,
as Dan indicated. It requires a potentially lengthy wait while all of
the relevant message bodies are downloaded, which IMAP was expressly
designed to avoid.
As I said already, if you're on a fast, low-latency connection to your
IMAP server, generally you won't notice this latency, and this is
probably the case for the vast majority of e-mail users (who typically
are using IMAP at work, or at home, on a local LAN, OR to their ISP's
servers, over a fast broadband connection on the same network). So I
conclude that is not your situation. If you're not in that situation,
there are already solutions available to you:
1. Fetch the messages yourself and read them locally.
Fetchmail and mbsync were both designed for exactly this.
2. Accept that the latency is just something you have to deal with.
3. Investigate an alternative provider with whom you have a better
connection.
> Honestly speaking, I have tried a couple of tools - offlineimap, mbsync
> and fetchmail. All are flawed.
I don't know what you think the flaws are with this, but I can say
that I use fetchmail + procmail for this purpose myself at work for
reasons I won't get into here. I've been doing it for many years,
and find it to have no particular flaws. Together these tools are
extremely powerful and very flexible. It may just be that you have
not yet discovered how best to use such tools to accomplish your
goals and need to spend a bit more time learning them.
There's no need for Mutt to do this, and it's rather against its
design philosophy. Given that, I wouldn't guess you'd have much luck
getting such a feature accepted by the Mutt development community,
particularly since the primary maintainer has already basically said
so.
That said, I haven't used Mutt's IMAP functionality myself in many
years, and it has been completely rewritten since then. It could be
the case that it might be possible to optimize the way Mutt handles
the fetch and display of the message, such that it only reads enough
of the message to fill up the display window, and then continues
reading the rest of the message. But for all I know it already does
that. And of course in cases where the message is encoded in such a
way that reading the whole message is required to decode any of it
(I'm thinking encryption, for example), such an optimization will not
work. Surely Kevin would know and could comment further.
[My understanding is that it is technically possible to decrypt
messages encoded with asymmetric encryption in pieces, but neither
GnuPG nor OpenSSL do this, and Mutt's behavior is dependent on
theirs.]
--
Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address. Replying to it will result in
undeliverable mail due to spam prevention. Sorry for the inconvenience.
pgpeDOsO3IxVD.pgp
Description: PGP signature
