For fans of Mutt/NeoMutt looking to try something new, I've been getting a lot of mileage out of Aerc[1] and can recommend it as a somewhat more approachable alternative for the Mutt-curious.
I am shocked — shocked — to see the guide I wrote 22 years ago on Mutt & GPG to be linked as relevant in this modern guide. I don’t use the combo anymore, but there is sometime affirming to me about Mutt still being relevant after all this time. Good tools that do a good job are still valuable.
> I am shocked — shocked — to see the guide I wrote 22 years ago on Mutt & GPG to be linked as relevant in this modern guide. I don’t use the combo anymore, but there is sometime affirming to me about Mutt still being relevant after all this time. Good tools that do a good job are still valuable.
Yes! That should be the standard to aspire to with all software. Not the constant change for the sake of change.
I set up a very highly customized (simplified) mutt setup for my parents in 1996 and the exact same setup continues to work today and my now-almost-100 year old parent continues to use it.
Anyone who has tried to keep older people using software knows the nightmare of UI changes. Even a small movement in the placement of icons is a big hill to climb. Consistency is key. My parent has given up on using the web because both the browser and website UIs keep changing all the time, it becomes too frustrating for them. So they gave up.
But thanks to mutt they continue to use email actively, nothing has changed since 1996 when they memorized how to use it.
That's amazing, and great perspective. I see with my own parents (one of them more so) how difficult they find UI changes. For a lot of people, it's not just finding the same- or similarly-named button, but spatial placement and appearance can also be important.
I got as far as the assumption of POP3 for fetching mail and stopped reading TBH. Here was me hoping for some cool new guide about Mutt with Oauth or similar.
POP3 is still useful. I have many addresses for various needs and don't need to store email on servers for almost all of them (mostly because it costs money). There is at least one IMAP client* that supports fetching mail (not syncing like most of them do), but POP3 has much wider selection of clients and serves that need perfectly.
The key advantage to mutt is the limit/tag/pattern workflow. Everything else is more or less the way other mail clients work.
A pattern is a mail-specialized regular expression. There are shortcuts for the things that you are likely to be interested in: From and Cc, To, Subject, Date, status flags. After a few uses of each, they'll start to feel natural.
The limit/tag/pattern workflow goes like this. Start in a mailbox view -- say, your overloaded Inbox. Use a limit pattern to see just a subset of the mailbox -- l ~fjira to limit to messages from a sender with jira in their name or address. Use T to tag a pattern -- by default the one you just used. Then prefix any command with ; to make it apply to all the tagged messages. That isn't just deleting them or moving them off to a different mailbox. You can forward them all as attachments, or respond to them all as one message, feed them to a command line process or give them a new status flag. You can also tag and untag messages one at a time, if you need fine control but don't want to figure out a narrowed pattern. Then, untag anything left and unlimit back to the full mailbox.
The key is that this happens much faster than you can possibly make selections with a cursor in a GUI, and much faster than you can make selections with a scrolling TUI. And patterns don't miss something by accident.
One of my favorite limit patterns is "l~d<2d ~d>1d\n" which I have aliased to ".y". It shows everything that came in yesterday. You might be surprised how often this is the view that shows you what you've missed. Another great one is "l~(!~fDOMAIN)\n" which shows only threads that have outside mail addresses in them.
> Everything else is more or less the way other mail clients work.
Agreed on the limit/tag/pattern benefits, but there's even more to mutt. The greatest thing is how everything is configurable. It works and behaves exactly how you want, for any conceivable definition of want.
Most software these days takes the Apple approach of imposing one single way of doing things and you will shut up and like it. Which I hate. Mutt is the complete opposite, configure everything to taste and enjoy.
My professor used Mutt and I was always in awe every time I watched him zip through emails. From time to time I try to get into it, but always fail for a different reason.
This time, I made it about 30% of the way through this "quick guide" with a Gmail account. I don't want to have my password in plaintext, so I'm fine typing it in each time to get started, but I never got over the finish line. I got stuck somewhere around minimizing the number of system headers that go out with each message.
Please let me know if anyone has recommendations for a CLI email client that hooks up with Gmail on a modern Linux distro relatively simply.
In general I find that most people who have (or claim) a productive workflow sync their mail locally (rather than letting the client connect directly over IMAP). So decoupling your reader application from your mail fetching application.
[mb/i]sync or offlineimap, with or without notmuch.
> In general I find that most people who have (or claim) a productive workflow sync their mail locally (rather than letting the client connect directly over IMAP). So decoupling your reader application from your mail fetching application.
Can't speak for others but when I was using mutt this is indeed what I was doing. It's just way, way easier, there are no IMAP quirks to jump through and you get excellent offline functionality pretty much for free.
I'm not sure of the state of Gmail IMAP, but Mutt is "happiest" when you've got a classical UNIX system with mail being delivered locally. It's .. very old school. I suspect you could get 80% of the zipping benefit by learning all the Gmail keyboard commands (why is delete '#'? To avoid accidental usage? Is there a keyboard command for "label as"?)
I used Pine for years after I began using it daily inside early stage Amazon, and kept using it on my own systems after I left. Like Mutt, it is still a very efficient email client that lets your quickly process a large amount of email.
I've been using for about 20 years fetchmail, procmail and spamassassin to locally deliver email, that I can then read either with mutt (when I'm remotely connected, mostly) or claws-mail. Frankly, nothing can beat that setup IMO :)
"How about you use a mail client from this century." --IT at a place I worked.
Context: I was using Mutt to do email, and one day I found that Exchange was configured to send only HTML versions of each message. If it received a plain text message, it would convert it to HTML -- including changing things like ":)" into J in Microsoft Symbol font or Webdings or whatever it was. Typically in an HTML mail environment, the plain text and HTML versions would both be sent as separate MIME attachments, but in this setup, only the HTML was included.
I filed a ticket, requesting that plain text messages be enabled so I could read them easily in Mutt. This snippy remark was the only response from IT.
So if you use a client like Mutt, be warned: nobody these days feels any obligation to support your retro email experience.
> If it received a plain text message, it would convert it to HTML -- including changing things like ":)" into J in Microsoft Symbol font or Webdings or whatever it was.
Ah, that's what that was!
Many years ago I was experimenting with alternative clients for corporate email, and remember being confused by those J characters, usually at the end of emails. Never figured it out, so thanks for solving that mystery. J
I routinely work with people using screen readers and for whom plain text email is perfect, while HTML email is a minefield of unreadability. It's worse that different email providers use different, inconsistent, and variable HTML formats.
The more I work with people using accessibility tools, the more I realize that web accessibility is an afterthought (if thought about at all).
> ...web accessibility is an afterthought (if thought about at all).
Sadly, yes, it is almost never thought about by developers or business stakeholders....But, there are legitimate offerings (such as plenty of html elements and atributes) that exist/can be leveraged. The only way that i ahve been able to get folks on board to leverage such offerings is to say something like: Oh, but it will help with SEO to a degree. And, then, almost immediately, busiess folks want to throw money at adding accessibility elements...Sad really, when folks who need this stuff, and can benefit most from it, don't get thought of.
Heh, I started using Mutt only because of "peer pressure" during my university years: all cool guys were using it! (Still with Mutt, > 10 years later.)
I think this is somewhat akin to Emacs: startup costs are enormous, but you reap the fruits for the rest of your life.
Anyone still successfully using this or similar in a hardcore Microsoft Outlook environment? My university keeps making it harder, last time it broke I essentially just gave up temporarily, and I keep intending to try to fix it. Any help/ideas/insight is appreciated.
Never touched mutt, but I've been using Emacs+notmuch for email for quite a long time (and you can use mutt+notmuch together, unfortunately TFA doesn't even mention it - it's really good when you have too much mail).
My daily workflow involved quite a lot of mail, both from real people expecting a reply, and some automated reports. I've had many notmuch auto-tagging rules, and some custom Emacs key shortcuts to make tagging/sorting even more efficient. I think I've accumulated around 100k messages during my 4 years there.
Around 2017, I moved on to a job in a smaller company, where everyone was sitting in the same building. Ditched that setup, and definitely not looking back ;)
I use bower+notmuch; what's your emacs setup for using notmuch? Everything I find for emacs seems to be built around mu4e, and I don't want to recreate my tagging/moving/&c. notmuch setup in mu4e.
Past tense. I've deleted it with a sigh of relief, and switched to Apple Mail. I've trimmed my init.el down to <400 lines (according to cloc) but I'm still unhappy with that amount. I need a better editor, but I'm too hooked to magit.
I used to use davmail to get my email from an Exchange server, and it worked flawlessly.
Then we switched to an O365 email solution. I'm sure it still uses exchange on the backend, but I don't know microsoft stuff so correct me if I am wrong.
But ever since the switch from a selfhosted exchange server to O365, davmail has been useless.
For the HTML email that doesn't work as intended (which is not a lot, mostly newsletters, which I prefer to read via RSS), I use https://github.com/tshirtman/.mutt/blob/master/mutt_bgrun and this macro. It picks up the first HTML attachment in the mail, saves it to a local file and opens it in a Firefox tab (and Firefox is already typically running):
macro index,pager ,b "<view-attachments>/html<enter><view-mailcap><exit>" "View first HTML attachment in browser"
You'll need to combine it with this entry in .mailcap:
Will give it a whirl, I also have a roundcube install on my mail server (via mail-in-a-box), so it's easy enough to just flip to a tab and read it there... Still only use mutt for composing.
That'll presumably load all the spam tracking pixels if you ever accidentally open a spam mail, no? Displaying HTML e-mails really needs to run with all external resource fetch disabled…
I went all-in on this https://stevelosh.com/blog/2012/10/the-homely-mutt/ at some point but was eventually forced to give up due to the problem of HTML emails. A lot of the emails I receive are HTML-only, and the step of launching a browser tab to make them legible was too big a PITA/slow. If I could find a tool kind of like Firefox's "reader view" that could convert HTML emails by default to something plaintext I'd be in business. Until then I'm on horrendously slow Thunderbird, but at least the lag pain is upfront launching the program and not per email.
I know someone mentioned Lynx, another option is to set up your mailcap to view using w3m. For reference, see .config/mutt/{muttrc,mailcap} here: https://git.bracken.jp/dotfiles/files.html
you have to try all three and see what works best. In my experience, pandoc tries to reproduce the page faithfully using ascii art, while lynx output is the easiest to read.
If you're going to use w3m, it's wise to wrap it with socksify to prevent email spam from tracking you:
This creates a new user namespace (-U) and then network namespace (-n), meaning there is no way for the lynx process to communicate with the outside world.
(requires unprivileged userns, which is default enabled on recent distros. "sysctl -w kernel.unprivileged_userns_clone=1" if not.)
Note that this guide appears to be quite old, although there are updates as recently as 2022. E.g. there are added notes about issues that were fixed in Fedora 10, which came out in 2009. (not that this should be considered as a negative -- it's great that this resource is still useful after so many years. Just pointing out that this page appears to have a long history, and whatever idiosyncrasies come with that history).
You need the bridge, but after that mutt’s standard IMAP configuration is usable. The key is that when you set your imap config you would do something like:
[1] https://aerc-mail.org/