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.
Description: PGP signature