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

["Alan D. Salewski via plug" <plug@lists.phillylinux.org>]

On Tue, Jun 13, 2023, at 06:24, N. Albert via plug wrote:
> On 6/13/2023 12:52 AM, Alan D. Salewski via plug wrote:
>> Hi Albert,
>>
>> On Mon, Jun 12, 2023, at 21:12, N. Albert via plug wrote:
[...]

>>> Does anyone here know of any console mail clients (IMAP/SMTP) for Linux
>>> that can operate *fully online*?
>> This is not an ideal answer to you question,
> Thanks for the insight! I was thinking there might not be an ideal 
> answer anyways, so tips on how to kludge an existing client to work here 
> are helpful nonetheless.
[...]

>> It would also require avoiding use of the 'header_cache' and
>> 'message_cachedir', which would make IMAP usage on large mailboxes
>> (thousands of messages) feel sluggish or downright slow.
>
> This could be of concern... Is this due to an inherent limitation in how 
> Mutt is designed? A proper IMAP client should still be very fast with 
> the cache disabled, since all it needs to do is query the server for 
> everything (assuming messages aren't insanely large, of course). If the 
> source is written to assume an offline cache though and it does 
> roundabout things that could get interesting though.

Though Mutt has had IMAP support at least since version 1.0
(released in October 1999), it wasn't designed as "IMAP only".  The
IMAP support lives along side other implementation features that
support a mail spool on the local machine.

Mutt does not assume an offline cache, and in fact users have to go
out of their way to configure one. But speed and efficiency for the
user are key selling points, and configuring header and message
caches allow the user to work /much/ more quickly.

Mutt's header and message caches are Mutt's solution to the remote
data problem and work well in practice. But that aspect of its
design does assume that there is a local filesystem that can be
used.

Since the location of the header cache is configurable, perhaps a
workaround might be to use an in-memory file system (e.g.,
tmpfs[0]). It would still be slow the first time it gets populated,
but if the use case is for the host to have a long uptime, maybe
that first-time hit is not too bad.


> What types of 
> operations are those that might slow down?

I think the two most apparent things would be the fetching of all of
the headers at startup time (a little slow), and then repeatedly
re-fetching message bodies to build the Mutt "index" view (a lot
slow). The 'header_cache' helps with the former, and the
'message_cachedir' helps with the latter. In general, the effect on
interactive use of 'message_cachedir' is much more pronounced than
the effect of the header cache.

How slow the re-fetching of message bodies is for the purpose of
building each page of the Mutt "index" view is directly proportional
to the number of message headers that will fit on the screen
(roughly the number of lines in the terminal) -- more lines of
screen real estate means more messages to be fetched for each page
of data. The size of the messages themselves and the bandwidth of
the network pipe are also significant factors.


> If it's just, e.g. SEARCH, 
> for example, if it's hardcoded to search locally rather than using IMAP 
> SEARCH, maybe that's reasonable,

Mutt is unusually flexible in it's approach to message searching. It
can use IMAP to do strictly remote-server-side searching, it has
built-in searching for local messages, and it can also integrate one
or more third-party indexers such as mu(1) -- and these separate
mechanisms can all be used within the same configuration. For your
use case, it sounds like you might want to limit the searching to be
strictly server side, or maybe also allow searching via a local
index on an in-memory file system.


> but if simply paging through a message 
> listing will be slow, that could be an issue, since in an online client, 
> that should be a constant speed operation, regardless of how large the 
> mailbox is.
[...]

I just tried it with an IMAP-based config without either a header
cache or a message cache, and then with just one cache or the
other. It works well enough for occasional use, but I would not want
to use it as my daily driver without using the message cache.

The speed is pretty consistent page to page[1], but it's not
fast. Anecdotally, Gmail in a web browser feels faster to me.


>>   Mutt allows the user to run arbitrary shell
>> commands, so that would need to be taken into account.
>   I'll have to see if this can be disabled in any way, or see if I can 
> modify it to not permit that.
> I did stumble across something called "neomutt" recently which is in 
> active development (seems to just be mutt with more features), so maybe 
> that would be the right place to try to make this configurable.

Perhaps. My understanding is that the 'neomutt' project provides a
collecting place for the tons of Mutt patches that have been
floating around over the past 2+ decades, and the community around
it provides care and feeding of those patches to keep them up to
date and/or to get them incorporated into the mainline Mutt.

Thanks,
-Al

[0] https://www.kernel.org/doc/html/latest/filesystems/tmpfs.html

[1] Most messages were between 42 and 70 lines, FWIW.

-- 
a l a n   d.   s a l e w s k i
ads@salewski.email
salewski@att.net
https://github.com/salewski
___________________________________________________________________________
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