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

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

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:
> > I'm thinking it might be difficult to get an answer to this anywhere,
> > but I figured this would probably be the place to ask since I'm sure
> > some of you use terminal mail readers.
> >
> > 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.
> but I think mutt could
> be made to run in that mode. It would require pointing $folder,
> $mailboxes, $record, $smtp_url, $spoolfile, and maybe some other
> settings at remote relocations. E.g.,
>
>      set spoolfile = 'imaps://user@example.com@imap.gmail.com:993/INBOX'
>
>      set smtp_url  = 'smtp://user@example.com@smtp.gmail.com:587'
>
>      ...
>
> 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. What types of 
operations are those that might slow down? 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, 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.

> > 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.
>   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.
___________________________________________________________________________
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