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

[Walt Mankowski via plug <plug@lists.phillylinux.org>]

On Tue, Jun 13, 2023 at 06:24:10AM -0400, 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:
> > > 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.

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.

> > > 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?

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

There's also mutt-users and mutt-dev mailing lists [1] which might be
better places to ask questions about mutt's internals.

Walt

1. http://www.mutt.org/mail-lists.html
___________________________________________________________________________
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