The only thing that might throw people off is that it uses nano for creating your email... (from the video)
Actually, IIRC it uses the EDITOR environment variable, with some sane fallbacks. I happily wrote emails in vim for years. That said, defaulting to nano with a quick and well known way to swap your buffer to vim (and possibly back) might be a better solution overall. I love vim and use it as my IDE, but the cost/benefit ratio isn't in it's favor when your average time spent on a reply might be very short or when you're writing freeform. Especially if your default config is for wordwrap off because you use it as an IDE...
The other thing to make sure you get nailed down in Mutt is to set up links or elinks as your html view handler, so HTML-only emails can actually be read without extreme difficulty for those cases where a client sent an HTML email without a plain-text companion.
The thing to remember for any program that allows complex configuration like mutt is that you can often search for other people's configs[1] and copy them as your own, and once you get better, you can copy portions of them and tweak as needed to get your own specific customized behavior. I ran FVWM2 as my window manager for over a decade, and I remember every 5-6 months I would do some searching to find interesting new behavior people had implemented that I could tweak and steal (like here[2]). Every time some interesting new UI feature would come out somewhere someone would implement it in FVWM within a couple months.
1. [https://smalldata.tech/blog/2016/09/10/gmail-with-mutt]
2. [http://stevelosh.com/blog/2012/10/the-homely-mutt/]
3. [https://baptiste-wicht.com/posts/2014/07/a-mutt-journey-my-m...]
I personally use (al)pine and I could not agree more.
But here is a different, and I hope very provocative, reason that you should consider a terminal email client:
Local mail delivery does not traverse the Internet, or any network.
So, for instance, when I send an email to one of my engineers at rsync.net, even though it is sent in plaintext, it is a private communication and cannot be intercepted by either an ISP or some global observer. It's nothing but a local file operation between two mailspools...
Further, it would be extremely difficult to phish someone who is viewing their email in the terminal. The effort that it takes to view and copy a URL is greater than the discernment required to identify it as suspicious - so you'll catch them every time.
I'd probably run it in a non-privileged container.
Infact, I should be doing that for Mutt ...
Does mutt talk to the network or have a daemon or run as a service ? I don't know the answer to that but I know that for my own use-case, pine is basically a text editor. It executes no programs or code and does not talk to anything but the local SMTP daemon.
How much sanity checking and bounds checking does sendmail (or postfix or whatever) do on email ? That's the question, I think, because again, in my case, the threat vector is very limited - basically an arbitrary (weird) email or piece of an email that somehow breaks pine.
So no, I don't run it in a container - in fact, I run it as the user whose mail spool is the highest sensitivity asset that user owns ... so a container wouldn't help. If you get the mail spool, you get everything - at least or that user...
> Local mail delivery does not traverse the Internet, or any network.
The implication here being that you are running the clients on the email server. Wouldn't you effectively get the same security by tunneling IMAP over SSH?
That's a common scenario, but most linux/BSD distros ship with some mail server software installed and configured to run out of the box, even if also set to not allow external connections, as that's how the system delivers messages to users (e.g. cron output, etc). So almost every linux/BSD is a mail server, even if it may not be the mail server. If there's a main box that people in your company connect to as a terminal, email to local accounts on that box is essentially a internal messaging system. Hell, you could throw an IRC server on there with no outside access and use terminal IRC clients to have your own private chat channel as well. Who needs slack?
If you want to send someone a message, there is write (if the person have mesg set to yes). There is also talk, but it requires its own daemon.
Seriously, _nix started out in the mainframe era. Meaning that the basic assumption was multiple terminals hooked up to a single computer, with a different user on each terminal.
Sadly we have a generation or more that grew up with single user computers, and seems to insist on turning _nix into that rather than embrace what it can offer.
Yes... that's the point of the discussion. They exist, but there is (or is perceived to be) lack of knowledge about their existence and how to make use of them from some newer users, either because of the push for desktop linux, or for whatever reason.
> Yet here we all are having a discussion on HN instead.
I have no idea what you're trying to imply here. I suspect maybe we are discussing similar, but ultimately different, things.
And it is not about thin clients, thin clients btw is yet another Windows-ism, it is about the concepts embedded in the unix concept that current day devs seems to either sidestep or downplay while building house of cards in userspace that poorly replicate said concepts.
For a more up-to-date guide on how to use GPG for your e-mail password [1]
[1] https://pthree.org/2012/01/07/encrypted-mutt-imap-smtp-passw...
The guy is absolutely right. Mutt is not a gimmick like ascii video on terminal.
It actually makes a lot of sense as an email client and is surprisingly ergonomic. I also enjoy the fact that my config is a normal dotfile that I can version control etc. Also, your passwords can be encrypted using the tools that you choose, as opposed to whatever home grown crypto (if any) the [insert random Electron email client] uses. Some ways are outlined here:
https://www.mail-archive.com/[email protected]/msg36375.ht...