After dabbling with `aerc` I've moved to `mblaze` which has been a blast to work with. It really emphasizes the unix philosophy and allows for composition of commands.
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.
I just installed isync today and synched all my mail from 2012 up to now using msync. It was quite fast compared to getmail and it mirrors the maildir hierarchy on the imap server.
I migrated to mblaze after many years with MH and nmh, mostly because the Maildir backend allowed me to serve mail out as IMAP to have access from a mobile. Some things it does much better like threading but I still use parts of nmh where it's better.
I built a fantasy football app in 1998 for WDVE in Pittsburgh, PA and had to act as the "Commissioner" to handle all disputes, complaints, and other interesting feedback, all via email, and as a person who couldn't give a shit about Football and never watched a game.
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).
I think it would take a significant effort to bring some of the features I love about Superhuman to a Pine-like workflow. (Definitely not impossible!) The one I use most of all is a reminder -- "punt this email to my Archive until next Thursday at 8AM" where it will then re-appear in my inbox. I do something like that a dozen times a day and would need a very reliable replacement for that.
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.
Firstly, speed. Opening that mailbox with a GUI-based email application on a developer desktop was orders of magnitude slower, if it opened at all. The volume was just far more than most desktop email apps was used to at the time.
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.
Actually, there was a better mail user's shell, mush[1], that was ultimately murdered by its insane license[2] which forbade any modification to the source; I remember trying to puzzle through how to apply the various patches I'd found to make it compile and then do useful things.
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)
Dan (mush's author) went on to start Z-Mail, a commercial GUI mail client, using mush as its basis, which likely explains the restrictive license. SGI eventually bundled Z-Mail with IRIX, which is why I scored an Indigo workstation when Dan hired me away from SCO in the early 1990s to help support it.
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...
Neomutt is a fork of Mutt that adds some features. Some of these features are available as Mutt enhancements, and some have been added to Mutt since the fork. I have no interest in these particular features, so I’ve never used Neomutt. One comment on my LWN article claimed that Neomutt was increasingly buggy. I don’t know if that’s (still) true, but original Mutt has been rock-solid for me. Correctness and stability are crucial in an email client.
while mutt i think never crashed on me, it's imap implementation was far from pleasant to use. i do not know how much of that might have been because of server side, but in the end i moved on to mbsync instead of using the built-in imap syncing. now mutt is a top notch ui over a local maildir.
Of course this has to get posted on a Friday. And so thus begins my biannual experiment of trying to convert my mail usage over to Mutt. Every so often I try to convert back to Mutt from webmail. Every time I enjoy the process, but end up switching back. Part of the friction was supporting multiple imap accounts (Google and Office365). I know it’s possible, but there was still friction.
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.
alpine user here. I can't imagine mouse-mousing around to deal with email.
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.
If you manage large amounts of email (100K+ messages in a mailbox, 1K+ messages a day), mutt is the only reasonable choice.
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.
>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.
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.
It was a long time ago, but giving gnus a shot (and watching it c-r-a-w-l through my mailbox) makes me wonder if it’s a mutt -stand-in. My typical mutt workflow brought gnus to its gnees.
Yeah, I've been using Gnus for more than 25 years, although I now use mbsync to download e-mail first. Before that, I used the original GNUS for Usenet and VM for e-mail.
27 years on VM here (currently 8.2.0b), using fetchmail to download mail locally. I tried Gnus a couple of times for Usenet but never stuck with it because of Emacs's lack of multithreading.
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.
"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."
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.
Actually unless you install some additional extension like notmuch or mairix I would argue that mutt is worse for handling large amount of mail, because search becomes quite slow.
It's even worse if you use IMAP support, if I recall correctly mutt doesn't search on the server (using sieve) so if you search in an IMAP mailbox without cache enabled it downloads all email before searching.
Sorry you're obviously correct about sieve. Maybe I misremember about server side search in mutt (not sure if there is a difference to neomutt), but I remember imap search was very slow if caching was not enabled (IIRC there's even a warning in the mutt documentation about this).
I think the authors quote on the top of the page was potential inspiration of this website https://tools.suckless.org and it's tools. The suckless.org url showed up multiple times in hn-search, but they did not get upvotes like this one. As I understand it's pretty low-level stuff. But I find surf (browser) quite compelling, mostly because of default no-tabs and full screen for less distraction.
i don't remember when i started using mutt, but i sat at a table with michael elkins at LUG meetings, and tried to be funny by saying "i didn't write mutt, it was me"
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.
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 use notmuch as well (with astroid as frontend), but I definitely think there are 2 big issues:
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.
Yeah, the combination of offline access on multiple computers sounds tricky.
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?
As I wrote in my post I use mbsync on a always on machine and muchsync to synchronize, and it works well for quite a while, but every couple of months I encounter an issue and end up spending several hours troubleshooting. I really wish there was something better, because I really like the speed and the keyboard centric navigation of notmuch clients.
I still find astroid to be the best of the notmuch clients, however I've encountered a number of bugs (e.g. it messes up umlaut letters when replying) and it's not developed anymore. Also if you have a thread with several long unread emails scrolling up and down takes a while, this becomes especially annoying when you want to just open the an attachment. There were also issues about actions for attachments if I recall correctly (I haven't looked into that in a while). I've tried alot and neomutt at some point, but for both you can not view multiple emails at the same time, which is quite annoying.
when i travel i access mail from a laptop tethered through the phone. one big advantage of a terminal client is that this works even through a slow connection. especially in combination with mosh
But that means you have to have access to a server that runs constantly (I currently i do that as well for my work mail with muchsync) and you're just one step away from running a Mailserver. I'd like to move away from that solution because it feels hackish and overkill (sync from email server to "server", ssh into server for reading email)
Also I frequently need to search my when e.g. on a plane so the ssh solution doesnt work.
yes, true, i have that server, but i also have a small laptop that i can carry around everywhere. if i needed offline access to mails frequently, i would move email handling to that laptop. and even if i work on another device, i am able to run the laptop on the side and access it through ssh/mosh. in fact i do that for everything else. would that work for you?
Somewhat, but hackish. When I'm at home I use my desktop and if I follow your suggestion I would then have to turn on my laptop first to access my email. I appreciate the suggestions, but I think multi-device offline access is really not a well supported usecase with notmuch unfortunately. I'm sort of hacking around this with different sync options, but it sort of rubs me the wrong way that there is a mail server already, but I essentially have to set up another server (always on machine) to access the email. In the good old days ssh'ing into the mailserver and reading emails directly on the servers maildir made sense (although this still excludes offline work) and changes would also propagate to the server for access via imap. Unfortunately, having ssh access to the emailserver is incredibly rare these days.
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.
> 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 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.
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.
Can notmuch or sup somehow store the tags on the IMAP server?
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.
your name sounds very familiar, so it's quite likely we met. let's talk private. my email is in my profile, and i have mails from you in my email archive. watch your gmail spam folder.
i am also on libera-chat irc, there is a #hackernews channel
I used pine religiously until Gmail had keyboard shortcuts. Now I just can't get myself back into it. I applaud those who are still functioning with text based mail clients. At this point, it feels like a real effort of love and I can absolutely get behind that.
All these text only mail tools are fine for reading mail, but if you need to actually send mail most likely your recipients are seeing some nearly unreadable email.
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.
Anecdotal, but I have absolutely no problem sending plaintext-only mails. So far it works very well and I kind of cringe every time I see HTML in emails.
Well, you can send 'till the cows come home. But have you viewed those emails in a web browser, an fat email client, a phone, phones of different sizes, etc. I guarantee they don't render well most of the time.
The trick is that you have to use an email client that will accept an external editor, which in turn can format paragraphs.
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:
If by "formatting paragraphs" you mean putting line breaks in paragraphs, that's a losing battle. There is always a screen size where that's broken. There should be no line breaks, and viewer should wrap the text as needed. This is what HTML renderers are great at. Basically HTML is perfect for email, and the only reason plain text email exists is that it was invented before html.
I guess it depends on your emails. If you need graphics/formatting then yeah text-mode clients are a questionable pick. If you mostly deal with text, then they remain much nicer to use than "modern" alternatives.
I use both. I mainly still keep mutt for encryption and signing. For general, day-to-day use, I prefer aerc because I grok its configuration more -- I believe one of its key advantages is its simplicity of configuration. I find it much easier to think of a keybind or string of commands to make some menial task faster.
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.
Aerc has rolled out signing and encryption support recently. I've tested signing, seems to work fine. And now it uses normal GPG keystore, not its own.
I've moved to Aerc from Neomutt a few months ago and never regretted it.
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.
> PgDown in Mutt goes to next email when I reach the bottom of the current one.
set pager_stop=yes
> Or deleting email keeps it displayed in the list ... but doesn't allow navigating to it to undelete
-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
(Not sure why these aren't the defaults. They seem much more usable than the defaults!)
Notmuch backend doesn't allow saving sent messages to the maildir. Gpg encryption produced an error when I tried it just now. Scripting is limited: actions that you can assign to keybindings can do only very simple actions (which might be a good thing if aerc finds just the right set of simple actions to make available).
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.
Aerc can display a thread in a tree-view of a directory, yes. Run :toggle-threads to see it (I'm using Maildir backend).
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.
Last time I tried aerc (some time over a year ago), mutt had better threading and I stayed with mutt. Having read the aerc source and used it though, it comes across as a very nice modern take on a TUI MUA.
It's crazy how mutt still doesn't have native oauth support. I now there's external scripts, but this is a common authentication standard which is being neglected by developers. I wonder how many mutt users actually degrade account security to make their clients work without realizing the mistake.
I use an application password with mutt (really neomutt). IMO this is not a significant degradation in my security posture: the application password is scoped, and mutt executes my password manager to retrieve it.
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.
How is the application password "scoped"? Can I not retrieve your Drive, Photos and Hangouts content with the same credential you generated for Gmail? Unless you're using OAuth, I believe I most certainly can.
I feel the same. Supporting several methods of authentication is not selling out to big corporations, is part of being a modern software. Software doesn't need a GUI to be modern.
Well, oauth support won't help. OAuth2 support is required. And OAuth2 is not so much a standard as a standard to make standards. So supporting OAuth2 for one megacorp does not mean supporting it for another.
I used mutt for awhile but ultimately switched away from it because of two issues that came up a lot:
* calendar invitations (google or outlook calendar). I could not find any program that could process the invitation, respond and save to my calendar, so I had to handle calendar invitations on my phone. I looked into writing something myself (the CALDAV protocol is plain text and not overly complicated) but never got around to it.
* HTML emails -as others have noted, w3m is pretty good at rendering most emails but not all. The ones that it didn't render to plaintext well were annoying and required opening a browser to view them.
Outside of those issues, it worked great with davmail grabbing email from an exchange server, and offlineimap saving mail locally.
I've always wanted to try Mutt, but from the outside it seems quite daunting.
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?
Honestly, I find it easier to start from something minimal, read man pages, and then gradually make the setup more complex, rather than start from a massive heap of settings handed down from someone else.
When I started using mutt ~25 years ago, I took one or two afternoons to read through the manual and to configure everything the way I wanted. That was a good time investment. I rarely changed anything since then. :)
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.
i deliberately don't have email on my phone, because i really don't want to deal with longer messages there. also i don't want to use the phone for work. i use it for messaging, but anything that needs a longer response i prefer to write on a real keyboard. not having email on the phone allows me to limit phone use to short quick responses. anything else can wait.
Mostly, i don't do email on my phone. Email is a medium for when you have time to sit and write properly. If i'm out and about, some variety of messaging is more appropriate.
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.
The same thing I use on my desktop. I run a CLI on my Android. Termux had to move more exclusively to F-droid because of some Play Store changes, but I was already using F-droid so that made exactly no difference to me.
I tried and used it 10 years ago in my 20's period were i discoreved the joyful of terminal world. But as of today, no.. it is not sustainable in professional world. As Vim which i used to love for years, but now i must admit IntelliJ simply does the work... mutt, for a mail tool is simply not plug and play. have no time now to deal with configuration files, proxy tools and so on to deal with such a simple thing like sending an email.
Please note i'm not bashing mutt, its a great peace of code
I use offlineimap to get my mail to my local machine in maildir format, so no need for any imap etc in mutt.
Bonus: I can use tools like cat and grep etc on the emails.
Also, there's a lot of tools to have mutt imap support work with gmail/office365 etc.
I think you’re mistaken. Mutt works fine with IMAP servers. It’s quite flexible. In the small minority of cases when I need to see the email in a full-blown web browser, it takes two keystrokes to open it there.
I know this. i've spent a lot of time years ago to configure mutt to fetch my gmail/hotmail/free accounts and it worked pretty well. But when you change computer hardware what a hassle to reconfigure everything. Such a simple thing like sending email should now be a no-brainer. i quit this dogma to use my brain for more insighful things
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
The thing about offlineimap and isync (which I prefer because it is significantly faster in my experience) is they work great until they don't. I originally switched from offlineimap to isync, because of some bug (might have been offlineimap or exchange IMAP support, I don't recall) which caused some email loss.
Just this week I had to deal with some isync issue which causes the sync to duplicate mails when uploading to the server. I still haven't figured out what's going on, I'm getting Keywords not supported errors from the server when syncing, which caused this. It happened once before and I had to wipe the whole directory and resync to fix it.
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
I configured mine only on the days I switched jobs. Copy one entry to a new one, changed name, changed password/oauth keys and ran `git add .dotfiles/offlineimap.conf && git commit -m "new work email configs" && git push` and call it a day.
This is less time than I spend with ANY other program I use at a new job
How many time you spent the first time you digged into theses tools ? i'm sorry but i'm ready to spend huge amount of time to learn tools like GCC or anything else that's complex. Not for sending mail.
I miss mutt a lot, and would much rather be using it than the weird web messes we have. But I also have to have extremely specific corporate branding in all my outgoing emails. It's stupid as hell but it's also not worth fighting about.
Six hours of wrangling some HTML merging later, I get a message from bizdev@company.com
"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."
I once worked in a shop where Exchange was configured not to send text equivalent with HTML emails. Even messages sent in plain text would be munged by Exchange into unreadable HTML hash. These may in fact be the default settings. I emailed the sysadmin asking that they be changed, and his only response was "Try using an email client from this century."
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.
I have not found any issues using other email clients (including mutt) in our exchange environment. In fact one thing that can be said about outlook is that every single user hates it and their webclient is even worse.
Is the “professional world” a place where you’re paid for your work? Because I’ve been paid for my work for 35 years, and I’ve never touched or dealt with either of those programs. I’ve used Mutt for about 20 of those, and nobody’s complained about my emails, nor have I had any trouble reading others’. As other replies to you have pointed out, your particular experience is not definitive of the standards of some “professional world”. In fact, from your description, it sounds like you’ve been working in some pretty unprofessional places.
I understand the willignness to do everything in command line. But it's just dogma. Seriously, using so many external tools to deal with such a dumb and common thing like sending/read a mail doesn't have to be so complex. It's useless complexity for nothing. As i recall, mutt has been designed to handle local Unix mail. Not to deal with web providers as the majority of non-nerd people use today. It's a significant effort to configure the tool for this common use case, the soft originally has not been designed for that hense the useless effort to adapt it.
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.
After gmail recently greeted my mutt/IMAP request (which had worked perfectly for over a decade!) with "login failed", i've embarked upon the slow winding road to getting mutt to use OAuth2, or is it OAUTHBEARER?, for gmail. Out of a dozen or so hints spanning the last couple of years (many which depend on having python2 still around), i'd humbly promote these links to best hints:
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"
and the GPG encrypted file has the following:
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/'
I wrapped a simple gmail command to run:
mutt -F ~/.muttrc.gmail
GPG pops up a password prompt, then mutt does it's thing and works just fine.
What is the "plain text" email world like right now? We (I) get so much HTML email, massive amounts of top posting, "quote the entire thread", etc. etc., just curious what the plain text email experience is like in this day and age?
A lot of the emails I get that come from discussion mailing lists tend to be in plain text format, and they look fine. Some mailing lists also insist on plain text as I recall. I think gmail sends its emails in both plain text, and HTML so if I get an email in my organisation (which 9 times / 10 will normally be sent from gmail) it'll look fine. The only HTML emails I get tend to be newsletters from places like The Guardian, and I normally have to open them in a browser because they just don't look right looking at them straight from neomutt.
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.
Viewing HTML is not a problem (autoview via w3m or similar), and replying in plain text with the bottom-quoted original message usually isn’t a problem either. I believe there are some markdown-based setups you could use to write HTML messages with mutt, though I never used that. Otherwise the biggest restriction IMO with plain text is if you’d wanted to use inline images.
It's mostly fine for me. I've given up on fighting against top-posting, but most emails still contain a plain text copy and I've never had anyone complain about me responding in plain text.
Mutt's downfall is it's designed around a single account. Most people have at least a personal and work email account, if not more. People also access their email through IMAP these days. Mutt has many config hacks to try and make it load multiple IMAP accounts, but a single failure to auth or connect will leave mutt completely frozen.
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.
Mutt is not single account, mutt is account-agnostic. Dump your email to one mailbox or a thousand, and it'll process those according to your configuration setting(s).
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.
Not only that. It's still built around that ancient concept that users connect via TTYs to a single machine, and mail is actually moving mail locally to their /var/spool/mail/%u, no network involved.
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.
when i switched to sup, it was a paradigm change in terms of interfaces compared to mutt. i can't say how well it works with imap though because i don't use that feature.
For some reason Mutt was the last terminal based email, and I still never liked it as much as Pine. This was a decade ago and I pretty much have since just used Thunderbird (or meh, Outlook) for email. I still hate most web clients...
I tried to commit to mutt but, the vast majority of emails I receive are HTML based which means you have to launch and open a new web browser window to view almost every email. This was a total PITA.
It depends. Most HTML e-mail can be parsed within the mutt viewer using an external program that converts HTML -> text in a graceful way. That works for 99 % of the HTML e-mail (which is typically just people that send it that way because they don't know better.)
For newsletters and such, you can have a shortcut that opens the HTML portion in a browser tab automatically.
Weird. The vast majority of emails i get (which i actually want to read) work fine in Alpine. Either they have a plain text version, or Alpine is rendering the HTML, i'm not sure which.
Speed. Particularly if you're a touch typist, keyboard commands like those in Pine/Alpine allow one to blaze through messages virtually at the speed of thought.
I hear people say this, but shortcut keys for filing and whatnot exist in modern email clients, too. I can move through my mail without taking my hands off the keyboard in Outlook or in the naive Mac mail app just fine, and without having to use some other tool to see formatted mails or mails that contain images.
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.