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

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

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


> 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. Mutt allows the user to run arbitrary shell
commands, so that would need to be taken into account.


> It also shouldn't allow access to the file system in any way, e.g. 
> attaching documents from the file system needs to be restricted. 

For Mutt to serve the purpose, I think the file system would need to
be crafted in such a way as to be extremely minimal -- to not have
anything "interesting" to attach. AFAIK there's no way to prevent
the file system access, so there would need to be nothing of
interest on the file system (or nothing sensitive, if shared).


> Basically, I'm looking for something that's like a webmail client, in 
> that the way it utilizes the IMAP protocol is that of an online only 
> reader that doesn't cache anything locally. I've looked around a bit at 
> the usual stuff (mutt, alpine, neomutt, etc.), but they also seem to 
> very much rely on storing everything locally and often support multiple 
> formats (e.g. reading from a Maildir). Online only by definition means 
> IMAP only and nothing else, no POP3, no reading from maildirs on disk, etc.

Mutt's default settings do point to the local file system (e.g., for
the spoolfile), but they can all be overridden.


> Additionally, I need to be able to pass in the IMAP connection details 
> on the fly, i.e. via arguments or by specifying a config file.

Mutt supports both, with the command line options taking precedence
over settings in the config file. E.g.,

    $ mutt -F path/to/mutt-config \
           -f 'imaps://user@example.com@imap.gmail.com:993/INBOX' \
           -e 'set ssl_force_tls="yes"' \
           -e ...


> Another way to think about this: if you launched this program and then 
> gave your personal machine to a stranger, s/he shouldn't be able to do 
> anything "undesired" on your machine while the program is running... 
> i.e. there shouldn't be any access to the file system possible from 
> within the client, and the client shouldn't really modify anything on 
> the file system in the course of operation. The user shouldn't be able 
> to do anything that would make anything "stick around" after the program 
> exits.

Shelling out also allows the user to run jobs in the background. So
anything program (includeing Mutt) that allows a subshell to be
invoked will be able to create something that "sticks around" after
the program exits.


> It's fine if this isn't the only way the client operates, as long as it 
> can operate in this mode somehow, and the mode *can't* be changed while 
> the program is running (once launched).

Mutt will not do anything to prevent the user from changing its
configuration at runtime, so the preventive measures would need to
come from outside of the Mutt config itself. It would also not
prevent the user from changing the IMAP connection parameters, or
indeed from querying for them:

    :set ?imap_pass


> Does such a client even exist? I'd prefer not to have to write my own... 
> I've written an IMAP server and webmail client before, but working with 
> ncurses has never been much fun for me, and I don't want to reinvent the 
> wheel here.
>
> Thanks!
>    Albert

Thanks,
-Al


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