A Quick Guide to Mutt(srobb.net)
srobb.net
A Quick Guide to Mutt
https://srobb.net/mutt.html
64 comments
> I got stuck somewhere around minimizing the number of system headers that go out with each message.
What system headers are you trying to minimize?
What system headers are you trying to minimize?
I used aerc:
https://aerc-mail.org/
Who is maintaining aerc’s fork? I know Drew DeVault abandoned the original version…
This is what I'm curious about - I remember seeing that DD is no longer maintaining aerc...
rjarry does :)
https://sr.ht/~rjarry/aerc/
https://sr.ht/~rjarry/aerc/
> CLI email client that hooks up with Gmail
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'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"?)
label as = L + first letters of label
I made my own mutt-like CLI client from scratch.
https://meli.delivery/
Webassembly demo: https://meli.delivery/wasm2.html
Git: https://git.meli.delivery/meli/meli
https://meli.delivery/
Webassembly demo: https://meli.delivery/wasm2.html
Git: https://git.meli.delivery/meli/meli
Aside from the already recommended aerc, here's a fairly friendly and sane way to get started with neomutt: https://github.com/LukeSmithxyz/mutt-wizard
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.
[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.
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.
PINE/ALPINE is also great and available on pretty much every distro.
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.
Currently using aerc. It could be better, but I can assure you I tried several of them and this was the only one that stuck!
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.
[1] https://aerc-mail.org/
[1] https://aerc-mail.org/
Can anyone point to a guide to using mutt with Protonmail ? I guess it needs the Bridge. I wonder if mutt "e" (edit mail) works with it.
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:
set folder=“imaps://127.0.0.1:1143/“
and for SMTP you would do something like:
set smtp_url="smtps://[email protected]:1025/"
set folder=“imaps://127.0.0.1:1143/“
and for SMTP you would do something like:
set smtp_url="smtps://[email protected]:1025/"
David Petraeus, is that you?
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.
I think this is somewhat akin to Emacs: startup costs are enormous, but you reap the fruits for the rest of your life.
I am most certainly not an Emacs fan, but I have similar thoughts about WordStar, Vim, and of course Mutt.
Please note that if you are reading this, you almost certainly want to skip everything before the "IMAP" heading.
Mutt is great with mbsync and mstmp.
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 :)
Same here, that is email in its natural habitat where it works best.
Is there something awesom like this for Windows 11?
You can install Cygwin and run Mutt on that.
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.
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.
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.
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.
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.
*: https://github.com/nicm/fdm
*: https://github.com/nicm/fdm
Every company I've worked at for the last decade at least has disabled POP3.
I'm not saying it's right, I'm saying for a mail client to be useful in most orgs it needs to support IMAP (and these days Oauth2).
Having just found the updated instructions for using Oauth2 with isync on the Arch wiki I know what I'll be doing this weekend :)
I'm not saying it's right, I'm saying for a mail client to be useful in most orgs it needs to support IMAP (and these days Oauth2).
Having just found the updated instructions for using Oauth2 with isync on the Arch wiki I know what I'll be doing this weekend :)
I still use IMAP. I use fetchmail to fetch it. Ultimately, mutt is more of a MUA and not an MDA, so let some other tool deal with it.
(I no longer use mutt, but use notmuch).
(I no longer use mutt, but use notmuch).
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.
You can set up Mutt to display HTML mails with w3m or the like. That works very well.
Install lynx (or links or w3m). Add this to your ~/.muttrc:
auto_view text/html
alternative_order text/plain text/html
Add this to ~/.mailcap:
text/html; lynx -dump -localhost -force_html %s | sed 's/^ *//'; copiousoutput
auto_view text/html
alternative_order text/plain text/html
Add this to ~/.mailcap:
text/html; lynx -dump -localhost -force_html %s | sed 's/^ *//'; copiousoutput
Thanks! I'll give that a shot.
Another option is piping email body into pandoc:
If you're going to use w3m, it's wise to wrap it with socksify to prevent email spam from tracking you:
pandoc -f html -t plain
If you're going to use w3m, it's wise to wrap it with socksify to prevent email spam from tracking you:
export SOCKS_SERVER="127.0.0.1:1"
exec socksify w3m -dumpOn Linux, you can also use "unshare" in your mailcap, e.g.
(requires unprivileged userns, which is default enabled on recent distros. "sysctl -w kernel.unprivileged_userns_clone=1" if not.)
text/html; unshare -U -n lynx -assume_charset=%{charset} -stdin -dump; copiousoutput;
(requires unprivileged userns, which is default enabled on recent distros. "sysctl -w kernel.unprivileged_userns_clone=1" if not.)
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
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.
[deleted]
You will probably need davmail to download the mail from exchange before passing it on to offlineimap/whatever.
I had to do that with my uni’s corporate outlook mail, a real pain but it does work (although I use mu4e, not mutt, but have used the latter also).
I had to do that with my uni’s corporate outlook mail, a real pain but it does work (although I use mu4e, not mutt, but have used the latter also).
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.
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.
Have you tried setting clientID match outlook in ~/.davmail.properties
FWIW, user for login looks like: [email protected]
davmail.mode=O365Manual
davmail.oauth.clientId=d3590ed6-52b3-4102-aeff-aad2292ab01c
davmail.oauth.redirectUri=urn:ietf:wg:oauth:2.0:oob
FWIW, user for login looks like: [email protected]
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 ;)
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.
> what's your emacs setup for using notmuch?
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.
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 still use mutt mostly, but it's harder and harder as more emails come in as html - w3m only seems to get you so far...
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:
text/html; mutt_bgrun /usr/bin/firefox %s >/dev/null 2>&1; needsterminal
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:
text/html; mutt_bgrun /usr/bin/firefox %s >/dev/null 2>&1; needsterminal
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…
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.
"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.
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.
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).
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.
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.
> 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
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 stopped using local mail readers[1] when webmail became a thing - it was just too convenient.
But I was still chugging along using the mozilla mail client to read usenet (or maybe there was a separate usenet client?)
So after awhile I chose the path of least resistance and used the same local client for both email and usenet.
And then gradually stopped using usenet, at which point webmail became a thing again for me.
Now I use thunderbird, because local mail readers beat webmail interfaces for convenience factors.
[1] First pine, then I upgraded to mutt.
But I was still chugging along using the mozilla mail client to read usenet (or maybe there was a separate usenet client?)
So after awhile I chose the path of least resistance and used the same local client for both email and usenet.
And then gradually stopped using usenet, at which point webmail became a thing again for me.
Now I use thunderbird, because local mail readers beat webmail interfaces for convenience factors.
[1] First pine, then I upgraded to mutt.
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).
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.