Support for IMAP COMPRESS=DEFLATE
(I began working on this a while ago, but ran out of time and it's unlikely I'll pick it up again soon. It would probably super easy for someone more experienced, like Kevin, to implement, so here goes :)
RFC 4978 defines an IMAP extension called "COMPRESS". The RFC was written in a modular way, and allows for multiple different compression algorithms, but as far as I know only one that is actually implemented is DEFLATE (RFC1951). Note that the RFC text refers to TLS compression as well, but this part of TLS since has been deprecated since and fully removed in TLS 1.3, in favor of application-level compression (mainly instigated by the CRIME vulnerability).
The implementation should be fairly easy AIUI. zlib implements the algorithm and I don't think it'll be very hard to hook it up to mutt's IMAP and would not be much different than TLS and SASL. It would probably make sense for deflate to be implemented as a generic wrapper around conn that lives in a top-level mutt_deflate.c, as there are RFC drafts for implementing deflate in SMTP, and deflate already implemented in NNTP (which is implemented in some forks of mutt). I have a draft non-working patch but I think it'll be more work to review & fix it than it would be reimplementing this...
The only complication that I see is that TLS, SASL and DEFLATE should all be chained in a particular order, and the existing facilities for stacking filters on top of connections are virtually non-existent, so it gets a bit hairy and duplicative. mutt_sasl.c has a comment section that details this, and mentions that a "a general stackable connection system [...] seemed like overkill", but we may be reaching the point where it does make sense, as there will be at least 4-5 filters on connections that I can see of (tunnel, 2xTLS, SASL and DEFLATE).