Re: [PLUG] "Online only" terminal IMAP client?

["N. Albert via plug" <plug@lists.phillylinux.org>]

On 6/13/2023 8:43 AM, Walt Mankowski via plug wrote:
> You can certainly run without it, but header_cache in particular is a
> big time saver. Every time you go in a folder, most mail clients will
> show you all the messages in the folder. If there are 1000s of
> messages, it will have to download them all every time.

Thanks, Walt.

I have to disagree with that conclusion. In my case, it's a big *time 
waster*. I just tried out mutt on one of my email accounts, and I 
quickly realized that there is no practical way that I'm ever going to 
be able to use mutt with it, at least in its default configuration. 
After about half a minute, it was still here:

Fetching message headers... 952/74578 (1%)

I'd probably have to wait an hour just before mutt would even load. It's 
trying to download 74,554 headers that are completely useless, and will 
just be discarded since none of this is being saved.

This isn't a time saver, it's a time waster. Why does it need to fetch 
74,000 headers, simply to show me the most recent 20 messages that will 
fit in my terminal window only? It could do that in milliseconds. It 
seems mutt was designed with the assumption that either mailboxes would 
be small or data would always be cached locally[1], in which case the 
performance is too poor for my requirements.

Even regular offline clients, like those in the Thunderbird family, are 
configurable in what they download and they'll fetch headers in a 
certain order and show those immediately, so you don't need to wait for 
a large mailbox to populate before using it.

When I wrote my webmail application, I designed it so that, in theory, 
it would be performant on large mailboxes (in practice, it's a bit 
sluggish on large mailboxes, but that may just be the underlying 
library). It will only issue a single FETCH command to fetch the 
relevant data for the current page. In no case would it ever fetch all 
of the message headers in a mailbox. An IMAP client that supports online 
operation should never have to fetch *all* the headers in a mailbox in 
order to display the N most recent messages. That's just poor design, 
and webmail clients don't do that, so I can't accept that as a 
limitation of a console based one.

That said, I'm still putzing around with .muttrc to see if there's some 
way to fix this (if anyone has any tips on what they've put in their 
.muttrc, I'm open to hearing that). Here's what I've come up with so far:
(in particular, the imap_fetch_chunk_size doesn't help the problem 
described above - it chunks the FETCH commands, but it still tries to 
download EVERY message header).

The other annoyance I haven't figured out is how I can easily navigate 
the "sidebar". I'd like to just be able to use the arrow keys (which to 
me, seems the intuitive method), but it doesn't seem like that's 
possible? I see there's no default key bindings for sidebar prev/next, 
and I don't want to assign any per se; I'd like to just be able to hit 
"Left" to go from the message listing to the folder listing, and then be 
able to scroll with the arrow keys.

More inline further down.

[1] 
https://unix.stackexchange.com/questions/358165/mutt-load-message-headers-lazily

set imap_user=XXX
set folder=XXX
set imap_pass=XXX

set record = +Sent
set spoolfile=+INBOX
set imap_check_subscribed=yes
set imap_idle=yes
set imap_keepalive=1740
set imap_list_subscribed=yes
set header_cache=""
set message_cachedir=""
set sort=reverse-threads
set sort_aux=date-received
set text_flowed=yes
set mark_old=no
set sidebar_format="%B%* %S [%N]"
set mail_check_stats=yes
set sidebar_visible=yes
set sidebar_width=20
set sidebar_sort_method=alpha
set sidebar_short_path=yes
set sidebar_folder_indent=yes
set sidebar_indent_string="  "
set sidebar_divider_char="|"
set shell="/bin/false"

set imap_fetch_chunk_size=50

unset envelope_from_address
set use_envelope_from


> > > > By this, I mean a client that does not (or can be configured to not)
> > > > store anything locally while running, or modify the file system in any
> > > > way.
> > > To prevent modifying the file system in any way would (I think)
> > > require running Mutt in an isolated environment (chroot?) on a
> > > read-only file system.
> > Upon further thought, I could run it in a separate namespace (chroot-like
> > environment) to mitigate this (and should anyways). That doesn't address
> > everything but it lessens the requirements somewhat.
> I'm pretty rusty at it these days, but I wonder if you could
> accomplish a lot of what you're trying to do by running mutt inside
> Docker?

I don't use Docker, I just use the namespaces API in C directly (which 
is what Docker uses under the hood). But you're right, that would be the 
way to go.
cgroups are what control resource usage and I haven't dabbled with that 
so much. With namespaces I could put the program in a jail, but at 
present I don't have an easy way of preventing someone from, say, 
downloading 70,000 messages and filling the disk up, if that wasn't desired.

I'll amend the scope of my search to focus less on isolation from the OS 
to proper IMAP online operation. I can put mutt in a jail easily enough, 
but if it wants to download 70,000 headers every time you fire it up, 
that's just not going to work. So I'll have to look for a client which 
will only load the headers you see in the terminal per each page. In 
other words, I expect to be able to open up a new mailbox with 70,000 
messages instantly, just like you can with webmail, and page around 
quickly, just like you can with webmail.

I'm not yet sure if that expanded or narrowed my search ;)
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug