Mutt – Text-based mail client for Unix
mutt.org
mutt.org
https://github.com/leahneukirchen/mblaze
I've started cataloging all the terminal mail clients in a list: https://erock.lists.sh/terminal-mail-clients
Happy to add others if people know of some that I've missed.
> Happy to add others if people know of some that I've missed.
Here are a couple of lists with clients you're missing:
https://wiki.archlinux.org/title/List_of_applications#Email_...
Hmmmm... The real unix philosophy-consistent mail client would be a filesystem that you mount. To send a mail you copy a file to the folder mail/send, to view your mail you ls mail/inbox, etc. You can browse your mail archive by date or by other criteria by accessing the appropriate directories.
The backend was all perl, pulling data from stats.com or something like that. But the only way any of this was possible, was using terminal-based email (pine, not mutt, but similar enough).
Terminal-based email is a great example of a tool optimized for power users, and I'm realizing now that most of what I was able to do in Pine in 1998 I still can not do with any "modern" email client (I pay for Superhuman these days, which is still a far cry).
Secondly, it's unix, so you're operating a tool that allows you to construct ad-hoc workflows very quickly. There was a scoring bug where the stats software (literally a pipe-delimited text file that was updated by midnight the day of the game) had given a safety to the wrong player with the same name. I had hundreds of emails complaining about this bug, and I needed to fix it. I can search in Pine, find a result set (ie. everyone who mentioned this players unique name), compose an email to all of them (BCCd), and pull in a text file as the email body that I'd written previously, that explained how and when this would be fixed.
I had TONS of canned email responses, saved as text files, so finding a set of emails, and sending replies w/ the contents from a saved text file, was a very routine workflow that happened dozens of times a day for various situations.
I knew nothing about american football really, but with perl and pine, I felt like there was nothing I couldn't do.
Search in Pine is guaranteed to be better than Superhuman. Unfortunately, Superhuman uses stemming for _all_ search, and you literally can't turn it off. You can use quotes as much as you like, but search for "Shipped" and you'll find a billion emails with every permutation of the word "ship" in it. It's awful.
Sad, but a good lesson in how a bad license on good code kills the program.
(links to the netbsd copy of the code since I can't find a more reasonable project home, likely because terrible license)
1. http://cdn.netbsd.org/pub/pkgsrc/current/pkgsrc/mail/mush/in... 2. http://cdn.netbsd.org/pub/pkgsrc/current/pkgsrc/licenses/mus...
I'm not sure when Z-Mail Lite, the TUI version, was introduced, but I eventually made it my speciality because I fell in love with its speed. To this day, I detest web-based email clients; at a later gig, Windows ports of Pine, Vim and par, an awesome paragraph formatter, made life with Windows bearable.
Dan eventually sold out to Judy Estrin at NCD, maker of X terminals and, later, X servers for Windows. Then NCD sold out to NetManage, then I left and eventually made my way to Netscape (post-IPO, sadly) to support their email server product.
I definitely remember discovering Z-mail on an SGI machine and being fascinated with the programming/extensibility of it. Around the same time I also discovered mh and exmh (the Tcl/Tk interface), which also were very extensible.
Eventually I ended up using mutt for the last countless years...
However, given the hoops I have to jump through to even get my Office 365 webmail nowadays, I’m not entirely sure a text based email client is even possible. Which is sad.
For multiple IMAP accounts, you can employ mutt's folder-hook settings.
- Use an IMAP sync tool (offlineimap, imapsync, and others). Yes, mutt has its own tools for accessing accounts, IME you're better off to use a third-party tool.
- Dump those accounts to independent folders, generally. There are options for integrating / sorting mail as it arrives, including procmail and mailtool. If you prefer a single integrated inbox, that's also an option.
Mutt has numerous hook options to set values based on folder, which can be used to set various parameters.
Alternatively, you can also set specific configuration files to apply to specific folders. Your personal, work, and anonymous email profiles are each independent in this way.
Further, in 2022, I still find myself (albeit rarely) in low-bandwidth environments where an email client suitable for a 9600 baud modem comes in handy.
But perhaps most interesting:
When I send email to other rsync.net employees, it never traverses the Internet. They are logged in, via ssh, to our mailserver as am I. The content of the emails transmits only as (ephemeral) characters in a terminal and the data transfer over the Internet exists only as ssh.
This pleases me greatly ...
If you miss mh/nmh and wish that it had a wrapper that could do everything and made sense, mutt is your savior.
If you work with people who think that changing the colors and fonts in a message is a good way of clarifying what they are responding to, go find different people to work with.
If you need to spend several minutes synthesizing a reply from a bunch of different messages all of which should be on-screen at once, (a) you have my sympathies, and (b) yes, you need a GUI mail client.
I've never tried Gnus for email because VM has always met my needs. It does an amazingly good job rendering HTML mail into something readable on a text terminal (the way I use VM and Emacs), complete with keyboard-navigable links that VM sends to an external web browser, and for the few times I need to see the actual graphics, a single keystroke sends the message's source to said browser.
Personality Crisis (which is nowadays included with VM, as opposed to being separate back when you used it) automatically rewrites the From: line based on the message I'm replying to. Using BBDB, Personality Crisis also does so when creating a new message based on the recipient. Mairix handles superfast searching of my decades of mail archives.
You know this of course, but I can't overstate to other people how nice being able to modify/extend VM with Elisp is. I rewrote the link-navigation code to handle all link types, and wrote the code that the abovementioned single keystroke invokes.
VM isn't perfect. I know that I could do all of the above with Gnus, and quite possibly am missing out on other features that VM lacks. Overall, though, I really feel like I have a superpower for email handling with it.
I have a couple hundred thousand emails in FastMail and both their web client and Apple’s Mail app seem to scale to this absolutely no problem.
100k emails is way way less data than you think it is. Will likely fit in your laptop’s RAM!
Was with you until this point. A good tool doesn't limit what the user can do on the grounds of ideological purity.
If some corporate doofus wants to reply in red, that's their business. If your tool won't display colored text you need a better tool.
And I could be wrong, but AFAIK neomutt at least supports server side search.
1. https://www.ietf.org/rfc/rfc9051.html#name-search-command 2. https://tools.ietf.org/html/rfc5228
This is an objectively ridiculous statement.
A person using a modern email client can confine themselves to a single font and color, or they can use formatting. They can read plaintext mails, and they can read complex emails.
Being flexible > being dogmatic about other people communicate.
People who depend on the typeface, size and color to convey essential meaning end up communicating poorly.
Plaintext bigots love to assert that there's no communicative value in formatted or colored text, but that doesn't make it true.
The world has moved on. This argument was litigated and lost by the plaintext partisans when Clinton was president.
claws was posted 3 hours later and reached 50 points 2 hours before slypheed, only about 3 hours after posting and now has 122 points and 72 comments.
finally mutt was posted 5 hours ago, and reached 50 points after only about 1.5 hours and now has 134 points and 122 comments.
you may draw your own conclusions.
Sup – A curses threads-with-tags style email client
https://news.ycombinator.com/item?id=31696235
Mu4e – Emacs email client backed by Xapian
i have been using mutt for more than a decade after that, until i discovered sup (supmua). for me one of mutts's big weaknesses (and that of every other commandline client) was that it could only keep one mail folder open at one time. at some point i had four instances of mutt running in parallel in multiple screen/tmux windows so that i could switch between folders without having to reopen each one.
sup fixed that by allowing me to open multiple views and keeping state while switching between them. it also replaces folders with tags and an extensive search interface with saved searches that can be treated like virtual folders.
i haven't looked back.
sup inspired notmuch, that brings the search feature to other mail clients (including neomutt) but i don't know if neomutt also keeps state between views. i am sticking with sup because of that.
For those who don't want to use Emacs, notmuch has other clients: https://notmuchmail.org/frontends/
alot was one of the early ones and last I checked (years ago) was quite featureful.
For people who want something other than mutt, I strongly recommend something based on notmuch. It also comes with Python bindings so it's easy to write complex rules to filter incoming email.
I have always preferred text email clients. The first one I used was elm, then pine, then I was using gnus for a while but treating mail as news wasn't quite right. Switched to mutt, then back to emacs w/notmuch (using w3m to render HTML emails) and that has been the best for me for a number of years.
1. All clients except for the Emacs one are quite unfinished and development slowed down for quite a few of them.
2. Using it with multiple computers is not working well. I use two computers and am travelling often (so need offline access to my mail so can't just ssh into one machine). I have been using muchsync with an additional server (as the other computers are not always connected). The server syncs to the work exchange server using mbsync. That sort of works, but is brittle and sometimes things get out of sync (I had to search the the muchsync sqlite database recently to delete an entry) or break. I tried other solutions (e.g. sync the notmuch db using syncthing) but broke even more often. It gets even worse if you also use your phone for email like I do (you essentially have no search on the phone).
I think it is quite obvious that notmuch was designed by developers who use a single computer and don't travel much and don't see much value in mail on multiple devices. I really wish jmap would have better adoption because a jmap server with some local cache for offline work (similar to how e.g. mutt handles IMAP) would be the best solution IMO.
Curious what you find lacking in astroid or alot that is in Emacs.
Frankly, the Emacs one is quite barebones. I'm sure alot has a number of features not in the default Emacs client.
Also I frequently need to search my when e.g. on a plane so the ssh solution doesnt work.
it works for me because i have other things that i always want to be available, so yes, i always have that small laptop running on the side.
it's a GPD pocket btw. when that dies i'll probably replace it with a pine-phone, smaller and cheaper, but has a solid keyboard accessory.
i have been thinking about a portable mini-server without keyboard and screen, but i haven't found one that comes with a rechargeable battery instead of requiring external power at all times.
i have considered my active phone, but i don't trust that enough.
I had never heard of it and just looked at the GPD pocket 2, quite a neat little machine.
> i have been thinking about a portable mini-server without keyboard and screen, but i haven't found one that comes with a rechargeable battery instead of requiring external power at all times.
I wonder if one could hack one of the mobile hotspots that one can get from several providers nowadays to run some server software. I suspect they run some sort of locked down linux or bsd.
quick search turns up this thread: https://www.reddit.com/r/openwrt/comments/u5jh0b/openwrt_4g_...
and it mentions this device:
https://openwrt.org/toh/gl.inet/gl-e750
that does have a micro-sd card slot, which should give it enough space to store emails.
Offline access on a single computer is basically a core usecase notmuch was designed for.
Online access from multiple computers is trivial by writing a shell script that pretends to be notmuch but instead runs the real notmuch command on a remote machine through SSH. (Same trick applies to sending email too.) Works surprisingly well.
Have you found anything that does offline access across multiple computers well?
If I were to ever leave GMail (and there may be reasons to do so), it would be pretty painful for me to stop using tags. Folders don't cut it; many of my incoming emails have 2-3 tags. To have tags on my laptop but not on my phone (even in a rudimentary way) would be painful, too.
I can imagine that tags could be stored in some hidden / special folders, and a conforming client could be able to at least read them and synchronize with the local mail DB.
it might also be difficult to synchronize those. (how would you get a list of all keyword changes since last time?)
tracking keyword changes locally and then submitting a hidden message with the changes seems like a hack (and how would you deal with conflicts?)
likewise tracking tags for all messages in a hidden location. (how much space would that take?)
i sympathize with the problem, but it looks like a non-trivial challenge to me. it's probably easier to solve the local sync issues.
https://stackoverflow.com/questions/10689062/synchronize-rep...
and supposedly it is efficient, so this would work after all.
i am also on libera-chat irc, there is a #hackernews channel
No modern mail reader does well with plain text email. Most likely it doesn't wrap properly on small screens (phone) for example so they are scrolling horizontally. It doesn't wrap properly on large screens (they are seeing a narrow 80 or less character wide tower of text).
If you are bottom posting most likely the recipient doesn't even scroll down and see it.
If you are top posting plain texts probably break the ability for the reader to collapse the rest of the thread underneath and scatters > characters all over. The mail reader is probably choosing some nasty fixed width font.
I say this as someone who spent too many hours trying to send email with emacs and being embarrassed by the terrible results. In the end you need to hack in some markdown to html converter and write all your mail in markdown if you want any chance of a readable email.
Mutt, emacs, whatever. They are fine mail readers. But you really can't write actual professional emails in them anymore.
I am obsessive about formatting emails, and the `par' formatter is the only one I've encountered that can intelligently work with indentation and quoting characters:
Vim has a basic formatter, and I'm not familiar with Emacs' tool, but I'll bet it's not as good as par.
EDIT: Your point about reading plain-text email on mobile devices is very true, of course.
BUGS None. Mutts have fleas, not bugs.
aerc still crashes on me from time to time. Not too much that I'm turned off from it, but definitely enough that I feel it's less stable than mutt.
I also find it easier to work with attachments in general with mutt: picking which attachment to view and piping it into different programs.
Using notmuch backend, one could also have a key to display all the emails that are in the same thread as the current one, so that you get a nice conversation-like view which includes sent emails as well (Purebred does this by default, for example). This is not supported out of the box yet, but I'm thinking of implementing a patch for it in the coming weeks.
Aerc has filters and builtin terminal support. This allows cool syntax highlighting for displayed emails and also support for previewing unusual formats. Aerc has well-made multiple accounts support and tabs out of the box, while with Mutt I had to keep two separate muttrc files for my two accounts and create bash alias for them. Aerc can filter the emails in the current folder and show only the ones that match an expression, I could never do that it Mutt. And overall, it just feels more modern and reasonable, even its config file format feels better.
I had a few things I found weird in mutt and never could fix them through config. For example, PgDown in Mutt goes to next email when I reach the bottom of the current one. Or deleting email keeps it displayed in the list (making you spam $ after each deletion) but doesn't allow navigating to it to undelete (Mutt devs want me to select emails to undelete using regexp? seriously?). I kept having wtf moments like this with Mutt all the time, I almost never have them with Aerc.
Some things still need polishing in Aerc, but it's improving fast.
Recently it was producing errors if the mime-type of an email attachment is quoted. This is something very rare, but some mailers do that. The issue was fixed within a couple of days after my report.
set pager_stop=yes
-bind index n next-undeleted
-bind index p previous-undeleted
-bind pager n next-undeleted
-bind pager p previous-undeleted
+bind index n next-entry
+bind index p previous-entry
+bind pager n next-entry
+bind pager p previous-entry
Supporting OAuth would be good, but I also understand perfectly why they don’t: it’s not part of the standards. If Google wants universal adoption, they should go through a standards track rather than throwing their weight around. And again, I say that as someone who would gladly use OAuth in mutt.
So yes, it looks like it's roughly equivalent to a normal Google login (but without the 2FA requirements?). That's too bad.
Outside of those issues, it worked great with davmail grabbing email from an exchange server, and offlineimap saving mail locally.
Is there a beginners guide on how to get the essentials? What plugins should I use to get, say, similar experience as Gmail/Fastmail? Should I use Neomutt?
Edit: typo
What do you use on mobile? Do you not bother having email access on your phone? Or do you ssh into a tmux session somewhere? Or do you have a client on your phone in addition to using terminal at the desk.
That said the host would also run dovecot and allow reading via IMAP if there was ever a need to access things remotely.
If i really have to, i can SSH into the machine my mail lives on, and run alpine. I'm always surprised by how well that works.
I also have GMail as a secondary email account, so if i need something i've been emailed to be on my phone (eg a ticket), i forward it to GMail.
Please note i'm not bashing mutt, its a great peace of code
Huh? I use email for all my important communication, and Mutt is the only client that is powerful and convenient enough.
Not to speak about real life use case were the email is HTML formatted with images.
mutt, as far as i know is rooted to Unix local email handling. Which is not very friendly when used with common web providers 99% people use today
In 2022, I love linux and command line. But mutt is outside the limit i can tolerate about this dogma.
Email today should be a no-brainer really. Its a hobby to configure mutt.
If you want your email locally: Use offlineimap to grab the email for example. There are many ways to connect. If not: there are a lot of python/bash scripts to make imap/whatever work with mutt
Almost all of them use configuration files that can be stored in git/svn/csv/etc
I am now looking at what other solution to use. I used to use muttator which was a plugin for thunderbird that emulated mutt behavior and was great, but that hasn't been maintained for >7 years
Also, there's a lot of tools to have mutt imap support work with gmail/office365 etc.
Mutt is NOT suited for the professional world. The professional world has standardized on Outlook and Exchange. If you use something different, no one is going to change anything for your prima donna ass if your emails turn out unreadable. Use Outlook for your company mail.
You can just plug in an external program to convert HTML to plaintext; IIRC elinks/lynx/w3m can do it.
> "Try using an email client from this century."
Outlook launched in 1997, so obviously that's out.
> Mutt is NOT suited for the professional world. The professional world has standardized on Outlook and Exchange.
Yeah, no; a large chunk of the professional world lives in Microsoft's little bubble, but plenty of companies live outside of it quite happily.
It's not my hobby anymore to spend time around this. I just use the app provided by my telecom provider to send SMS, i haven't configured an obscure TUI tool to interface my local 4G antenna to just tell my wife i'm well. Email is the same. Life is short hence the idea that using mutt is just a nerd hobby today. You can't advocate common mortal to go this way it's just outdated and overall ridiculous.
If its your hobby, well, i'm happy for you
"Hi morelisp,
In the last email you sent the logo wasn't properly aligned to the left with the text and the font of the phone number was not correct. Please reset your signature block in your Outlook configuration based on the official template."
No thanks.
[1] http://www.dcs.gla.ac.uk/~jacobd/posts/2022/03/configure-mut...
[2] https://www.reddit.com/r/backtickbot/comments/kyuq11/httpsnp...
Please post any better sites you discover. It really is an overly server specific mess.
https://gist.github.com/bnagy/8914f712f689cc01c267
I set up application passwords, then configure a gmail rc file ~/.muttrc.gmail with the important bits:
source "gpg -d ~/.pass/gmail-mutt.asc|"
set from="ME@gmail.com"
set spoolfile="imaps://imap.gmail.com/INBOX"
set folder="imaps://imap.gmail.com/"
set postponed="imaps://imap.gmail.com/[Gmail]/Drafts"
set imap_user="ME"
set imap_pass="APP_PASSWORD"
set imap_idle="yes"
set smtp_url="smtps://ME@gmail.com:APP_PASSWORD@smtp.gmail.com:465/'
GPG pops up a password prompt, then mutt does it's thing and works just fine.
A barren, lonely place filled with frustration and populated with creaky relics such as ourselves, yelling at clouds.
HTML emails were much more readable than in their original form.
I don't know about you but I don't tend to get bothered too much when I get sent a HTML email because neomutt will normally use lynx to format it into plain text that can be read from a terminal. Lynx isn't very good for browsing the web but its better for this sort of purpose. I'd, of course, rather people use plain text more for email because I reckon a lot of the HTML emails I see really don't need to have been written in HTML at all. Although the only issue is that HTML emails generated from software sometimes look horrendous in neomutt which is slightly annoying.
text/html; w3m -I %{charset} -T text/html; copiousoutput;
Top posting and the like is not really a text client issue...
I have to use mutt to read and pull kernel patches, but I hate it. I would love a modern tui email client to rise from the ashes, but I doubt that will ever happen.
In fact, this is also what all self-hosted email guides expect in Anno Fucking Domini 2022! I don't want to have to create system users just so they can have their mailboxes! Somebody tell those guys that such defaults are not sensible in this age.
It's possible to configure mutt to handle multiple accounts by:
- Dumping accounts to independent mailboxes and accessing through through specific mutt configurations.
- Dumping accounts to independent folders and Using folder-hook to set account-specific configurations.
- Performing other configurations based on reciepient and/or sender.
For newsletters and such, you can have a shortcut that opens the HTML portion in a browser tab automatically.
This is done by adding this to your ~/.mailcap:
text/html; mutt_bgrun /usr/bin/firefox %s >/dev/null 2>&1; needsterminal
text/html; elinks -dump ; copiousoutput
And then on ~/.muttrc:
macro index,pager ,b "<view-attachments>/html<enter><view-mailcap><exit>" "View first HTML attachment in browser"
Who is sending you these obligate HTML emails?
i suspect that the threading support in gmail was probably inspired by mutt.
Mutt 2.2.0 - https://news.ycombinator.com/item?id=30317229 - Feb 2022 (16 comments)
Mutt releases version 2.0 - https://news.ycombinator.com/item?id=25222166 - Nov 2020 (40 comments)
Mutt and Gmail - https://news.ycombinator.com/item?id=25156796 - Nov 2020 (4 comments)
Mutt 2.0 Release Notes - https://news.ycombinator.com/item?id=25019901 - Nov 2020 (76 comments)
Mutt email client 25 years old - https://news.ycombinator.com/item?id=24173676 - Aug 2020 (158 comments)
Using Gmail with Mutt - https://news.ycombinator.com/item?id=23130859 - May 2020 (1 comment)
Patch Workflow with Mutt - https://news.ycombinator.com/item?id=20694586 - Aug 2019 (1 comment)
Using gmail with mutt (2016) - https://news.ycombinator.com/item?id=16962136 - April 2018 (18 comments)
Switching to the Mutt Email Client - https://news.ycombinator.com/item?id=14567074 - June 2017 (241 comments)
Using Gmail with Mutt - https://news.ycombinator.com/item?id=12563398 - Sept 2016 (53 comments)
Mutt 1.7.0 released - https://news.ycombinator.com/item?id=12324506 - Aug 2016 (90 comments)
Mutt 1.6 - https://news.ycombinator.com/item?id=11425642 - April 2016 (183 comments)
Why Some Security Experts Use Mutt - https://news.ycombinator.com/item?id=10182582 - Sept 2015 (157 comments)
The Homely Mutt - https://news.ycombinator.com/item?id=4597156 - Oct 2012 (110 comments)
Using Mutt with Gmail - https://news.ycombinator.com/item?id=1469915 - June 2010 (7 comments)