My stepmother's cousin, Jean-Pierre Radley, was a Unix enthusiast and consultant in New York City (mainly an early SCO adopter, who dabbled in Linux later on). He taught me to use mutt in 1997 or so -- apparently not long after it came out!
I'm still using mutt, although Jean-Pierre passed away three years ago.
I believe that at the time he started using mutt, he was still getting some of his e-mail over the declining UUCP network (as he was a tremendous UUCP enthusiast and even provided commercial UUCP connectivity and support at one point).
Shout out to davmail, an IMAP proxy that sits between mutt (or any other IMAP client) and Outlook365.
Davmail handles Outlook’s Modern Authentication, and launches a browser when a 2FA challenge/response is required. The latest version of davmail can cache authentication keys meaning you only have to go through 2FA once.
It’s been a real joy to return to mutt, in my latest job where Outlook is deployed, after years of using Gmail.
I use mutt, mbsync, maildrop, and mblaze, mairix, msmtp, oauth2 with gmail. I have local speed, two way sync, customized email filtering, fast searching, vim editing, and multiple machine freedom. I am happy.
I would love absolutely Mutt if it weren't for everyone in the world using html email. I know you can view or strip html emails down to their essentials, but it doesn't render properly enough where I can reply to everything at work and not look like a fool because I'm missing some context. Too bad because Mutt is amazing.
You just used the word “simply” in the same was as you used the word “just”.
The argument GP was making is that what is obvious to one reader may not be obvious to another. So using the words “simply” or “just” or “obviously” does not add information, except to signal that you feel the reader is ignorant if they are not aware of what you’re explaining.
My PhD advisor always crossed these words out of my scientific writing, and I think it was a good change to make.
Strangely, that's entirely the opposite of what I understood from the original comment. To me, "you can just use XXX" sounds like someone just told me that "all you need is XXX; don't worry it's simple". The assumption is that the HN'er saying it and the HN'er being said to share an implicit level of expertise since we are all talking about mutt here.
Fair point. It does probably make sense to just strip the words out in this case as well.
I do want to point out that I didn't use those words fully consciously and I most certainly did not mean to imply the reader was ignorant. The only thing those words were signalling is that the action in question does not take much effort (once you know it).
> The argument GP was making is that what is obvious to one reader may not be obvious to another.
Regardless of the argument, it's not obvious to anyone unless they've taken the time to read the documentation and possibly read through some examples. While there are those who may feel that it's simple and/or obvious after they have gained that knowledge, it shouldn't relieve anyone of the responsibility to read documentation and figure these things out for any tool that they use.
For anyone currently using a GUI mail client where HTML mail works out of the box, this is not something they will spend time figuring out before concluding that HTML mails just don't work. And this is a complete non-starter for those who like Mutt on the basis of having something that also works in non-graphical environments.
That's fair enough, but this is why I'm not recommending this to someone who is not willing to spend half a minute searching for this one-liner. I'd also wager that the intersection of such people with the people who would even consider using Mutt in the first place is basically empty.
My point is that if you don't have those two constraints, it's trivial to do and it works perfectly.
That's fine when you run mutt on your local machine, but the whole reason to use mutt is so that you have a dedicated email machine that you can ssh into and use screen to access email from anywhere. And then things like this become 10x harder (I never found a way, although last I tried was 15+ years ago). Attachments, too.
That's certainly a valid reason to use mutt, but this is not at all why I use. I use because I prefer keyboard control, customizability and a simple, clean UI. Also because it's actually the least sucky (IMO) of local email clients.
One of my main reasons for using Mutt is precisely the opposite: with mbsync I have copies of all emails on my laptop, so I can read, search, and compose emails when I don't have an internet connection.
Why would anyone use mutt when you can have 'local' (ie on a machine you ssh into) Maildirs? That's one of the selling points for using mutt. Imap sucks, it's just something we have to put up with for lack of something better, but I've never searched mail as fast as when I could just grep for what I needed.
I use Thunderbird and it's installed on multiple machines where I have it configured to access the same email account via IMAP. I never really had a problem with out of sync mail and searches are done locally on the machine rather than on the server. I don't have it configured to use Maildir, but the files that store messages are in plain text and I could use grep on them if I wanted to.
You probably don't want to risk the attack surface of a full browser by default. You can use something like this:
text/html; lynx -dump %s; nametemplate=%s.html; copiousoutput
The real problem though is not preserving the rich-text-ness of the quoted message when replying, and the inability to have inline images. I use Outlook at work and mutt for private email. Using mutt at work just wouldn’t be practical, as the text markup and inline images are often critical to the exchange.
On a related note, while I love the UX of mutt, I do find proportional fonts to be significantly more readable than fixed-width fonts for paragraphs of natural-language text.
> The real problem though is not preserving the rich-text-ness of the quoted message when replying,
Given the near ubiquitous use of top-posting and quoting the entire message that's being replied to, it stands to reason that others are not really reading the quoted material and are just reading the response on top.
> and the inability to have inline images
I wonder when email clients like Outlook would start rendering images based on a URL included in the message, similar to what Slack does. That could allow one to effectively include an inline image, which would be seen as a URL in other clients.
The quoted material is important, because people expect to be able to retrace the conversation within the single message. Technical (and also nontechnical) exchanges often consist of a dozen messages about a particular topic spread over weeks or sometimes months, where at almost each step you want to go back in the conversation to look at details of the previous discussion or to refresh your memory. Outlook users are used to doing so by scrolling through the message. They are generally not used to having to bring up the correct previous message -- Outlook also doesn't have a great UX for that.
> The quoted material is important, because people expect to be able to retrace the conversation within the single message.
Given the proliferation of rendering a thread of messages and showing them as a conversation (i.e., conversation view), reading the quoted material within the same message is not really necessary.
> Technical (and also nontechnical) exchanges often consist of a dozen messages about a particular topic spread over weeks or sometimes months, where at almost each step you want to go back in the conversation to look at details of the previous discussion or to refresh your memory.
While I have seen this done in threads where people follow the conventions of a typical mailing list or usenet newsgroup by replying inline and quoting only parts of the text they're responding to, I have not seen the equivalent in a threaded conversation in outlook. And, as you note:
> Outlook also doesn't have a great UX for that.
While they have addressed the UX issue to some extent with the conversation view, it still doesn't really lend itself to easily following the discussion amongst multiple people due to the fact that they don't typically use different subthreads under the same email chain.
I avoid that by replying inline, discarding the history of multiple-quoted emails from top-repliers. Everybody else uses Outlook, but nobody has yet complained.
For sending emails with formatting (italics, headings), I use Markdown in Vim then press H in Mutt before sending, which pipes it through an appropriate filter:
set send_multipart_alternative_filter=html_alternative
send-hook . 'set send_multipart_alternative=no'
macro compose H ':set send_multipart_alternative=yes<Enter><view-alt-mailcap>' 'add HTML alternative'
I do the same, mutt for personal email and web browser based for others (usually work provided email). I always keep work and private emails separate and correct people when they try to intermingle them (know me in RL as well as at work)
I use mutt a lot, and that's what I do when some HTML content is not viewable in the terminal but unless I'm missing something it's one of the areas where HTML-aware clients actually fare better, both in convenience and privacy/security.
For instance if I open some marketing email I got in the ProtonMail web client I
get a warning that "This message contains remote content" with the option to
allow it. Before that my browser makes no query to any third-party website so
nobody can track it.
If I open the same email in firefox from mutt, firefox immediately fetches the remote
content normally and unconditionally.
You could probably script something to start a browser in offline mode but I
haven't seen most people do it (see the replies in this thread that just tell
people to "open HTML with Firefox"). So paradoxically mutt users might be easier
to track than ProtonMail, GMail and other HTML-aware webmail users.
That's true, though I avoid this problem by only opening HTML email from known, trusted senders where I consider it acceptable to signal that I opened the email.
Unfortunately even "trusted" senders I know often like to use third-parties to handle tracking and analytics and from there you don't really know where it's going to end up.
Of course you might argue that I shouldn't trust people using these services but then I might as well stop using the internet altogether.
I render such emails in browser and it is rarely lossy. It is based on munpack and some hacky scripts. Basically construct a html page with all the info and attachments and open it in browser.
I’m ... not sure. There’s a limit to how complicated emails are in 99% of non-spam HTML emails, right? You’re working with a limited subset of HTML meant to be reflowed to small screens pretty easily, and the task here is to extract text content into a form that can then be shown in a terminal.
I would — at the very least — think it was worth giving a go
I'm amazed that you haven't had that experience yet.
Years ago, when the web was less commonly used, it was pretty much frowned upon to send HTML emails. These days, it's almost the opposite: people asks "what's wrong with you" when you use a text-only email client (setting).
Nobody really cares at any of the places I've worked either. I'm usually using company computers and one of the first things I do in the email client is set it to text
Although nobody has commented on my mails, I know some people read them on mobile, and because plain text is formatted for an 80-column terminal, it doesn't reflow nicely on their mobile devices so they have to scroll side-to-side to read my message.
I think people don't know that's because I use Mutt, but a hard-to-read mail is not an impression I want to convey sometimes.
Also, sometimes my mails render in Courier font for some people when regular HTML mails show up in Arial, just because of the content type.
So if possible I'd like to write Markdown or similar and have that auto-formatted to HTML mail before sending. Not sure if there's a good way to do that in Mutt.
It's funny this should come up on HN today, because just this week out of nowhere i thought i'd try Mutt again (after having been a Mutt user since mid-2000s, but switching to mu4e for the last ±5 years).
What i used to do back in the day, and appeared to work fine when i tested this weekend, is so-called flowed mode. [1] I think it's a controversial feature, because it's a brittle hack, but anecdotally an email i sent this weekend as a test displayed fine on an iPhone.
And indeed, i'm totally with you on wanting to use/send text email but not look like a freak with weirdly broken 80-char lines in paragraphs.
Interesting point. I can only do very limited testing, but I just sent an email with one very long line from mutt on my laptop to my gmail address. The long line was not broken, and the display flowed perfectly on the gmail client on Android.
I think you should be able to use a hook in Mutt to process the markdown to HTML (using Pandoc) before sending. I've never tried anything like this—it has interesting possibilities.
It's entirely possible to send mail as format=flowed plain text, so that messages will rewrap nicely on any screen. I do it all the time with Mutt, it's actually very easy.
> The suggestion to use `format=flowed` doesn’t help, as the standard is ill-supported: https://fastmail.blog/2016/12/17/format-flowed/ I’ve researched the issue far and wide and the only way to have responsive, nicely wrapped emails is using HTML.
> Update on 2019-07-16 The current GMail web-ui ignores format=flowed and renders such emails with hard linebreaks everywhere. Thank you Google for violating yet more email standards.
Most people I correspond with where I care about my mail looking "normal" to them seem to use Gmail (about 30-50%), then Apple Mail, Outlook or Thunderbird.
format=flowed does not solve the problem, but you don’t have to resort to HTML. This guy¹ has the right idea: just make each paragraph in your email a single long line (but no more than 998 characters). The idea that we need to break lines at 78 characters, or whatever, is false. Long lines will be wrapped responsively in any sane client, so the reader will have a good experience.
I mean... have you heard of ansi escapes and utf8?
you can underline, bold, italic, color, and some other stuff with escape codes, and use box drawing characters to make nicer UI like <hr> equivalent lines or, well, boxes, there's also hacky ways to use utf8 characters as alternate fonts, such as fraktur characters (you can search up fancy text generators for the hacky character sets)
I had a similar set-up and did some screencasts on it a few years back (link below). It worked well, and was the least-sucky thing out there for plain-text email, but in the end I just got fatigued at continuously having to switch to another viewer (a browser) in order to properly see HTML email, which was ubiquitous. I ran back into Gmail's loving embrace, not happily, but reluctantly.
I use a similar setup. I'm curious what you use for msmtp for though: most Mutt setup guides I've read recommend using msmtp as well, but I've always just used Mutt's native SMTP client and it works fine, so I've never understood the need for a separate SMTP program.
Not parent but I have a similar setup.
Yes, absolutely. I think storing our owns emails/attachments locally is part of best practices.
That is our data and having a safe backup of it is a must.
I store all mails local. I can share my setup. I will take a while for me to find time and collect things in the same place. I will report back to this comment.
Thank you Mutt (and also NeoMutt for pushing the envelope), you have been my e-mail client now for the last four years and as an academic that spends a significant amount of time reading and responding to e-mail it is (somehow?) the best option out there.
Setup:
* Mutt (I had slowdowns with NeoMutt)
* Vim with four e-mail specific lines in the `vimrc`
* fdm for retrieval and delivery rules
* Syncthing for synchronisation between machines (it is just files! although ~1,000,000 of them…)
* tmux to give me a single horizontal split so that I can browse and compose at the same time
* Notmuch for search
* Lynx to beat text/html into shape
* a tiny snooze shell script of my own coupled with an equally tiny unsnooze shell script that runs every few minutes on a box that is on 24/7
That is it, although I have to admit that I should clean up my `muttrc` at this point as it is an outright mess. There are always more tweaks one could perform, my next one probably being figuring out tagging and then sending multiple mails to the snooze script. But one has to exercise a bit of self restraint or get less rather than more work done due to “over tweaking”.
Gripes? Well, the configuration is very arcane at times and monolithic; you wish you had a more modern, scriptable, and modular interface. If so, you could probably cut down the time it takes to get something working by more than half. I also suffer occasional CPU spikes, perhaps due to some weird interaction with Syncthing when both monitor directories.
Other than that, it is very smooth and pleasant sailing. HTML e-mails in particular hardly if ever pose a challenge after I got Lynx into the mix.
> the configuration is very arcane at times and monolithic;
For my needs it seems quite modular. I have one ~/.mutt directory with separate muttrc files for every email account (10+) and within each account I use folder-hook to have separate (many are shared) config files.
It does get more intuitive over time once you grasp some of the fundamentals of interactions with external programmes and how the query language and hooks are what you should first reach for. This I suppose is the “arcane” part, it can be difficult to both grasp and find good resources that teach you the ropes. However, this is fairly common for the *NIX command line and can be a strength as well in the end.
What usually gets me is how some functionality is just barely out of reach, unless I am mistaken for example there is no way to pipe the path(s) (not the message(s) themselves!) to an external programme. So for my snooze script I instead pipe the messages(s), parse them to extract the Message-ID(s), pass them to Notmuch to turn them into path(s), save to a temporary file, launch another command pointed at the temporary file, query the user for input, create a directory based on the input, and move the file(s) into the directory. It works, but it is awfully roundabout and I do at times wish I had some sort of scripting language that interacted with Mutt primitives rather than a monolithic set of functions which can only be extended by patching the source.
After many years of using mutt the lack of flexibility really started to eat away at me. I decided I'd write my own console-based mail-client with a real/complete scripting language.
The result was very flexible and customizable for myself:
Unfortunately after 10+ years of self-hosting my email on a virtual machine I've now switched to paying for GSuite, so the project has become orphaned. For a while I thought there was a chance it would become popular and useful, but I guess the userbase for these kind of applications is pretty small - almost everyone still using mutt does so because they love it, and are used to it. Changing isn't an easy thing to do.
Mutt does not support virtual folders, so there is nothing fancy really about how I use Notmuch as I only use it for search (not tagging). I have a macro to call `mutt-notmuch.py` (there is a Perl version as well) to: search, create a temporary read-only maildir based on the current TTY, and lastly populate in with symlinks to the search results – Mutt then switches into that maildir.
I would love to use Notmuch more, but syncing between devices becomes a pain when everything is no longer a file. There is muchsync [1], but I really do not want to go down the rabbit hole of resolving potential conflicts, etc.
I'm subscribed to several mailing lists/forums and sometimes get a 3-figure number of emails per day. Since I can't (nor want to) read all of them, I score them based on the subject field (~s). Unfortunately, the scoring algorithm can't take the body into account (~b). That's why I considered notmuch for creating (virtual) mailboxes with context I'm interested in...
> tmux to give me a single horizontal split so that I can browse and compose at the same time
Do you mind sharing how you do this? Browsing plus composing has been the one thing that keeps annoying me for not being streamlined and typically I just open multiple mutts/neomutts.
Me too, but sometimes no need to make things more complicated. It's also a feature of mutt - that I can fire several instances almost instantaneously and use them for different purposes. I have to use outlook at work, and there's nothing more frustrating than waiting for it to load up, and not being able to view and search my old emails when I am composing emails (or is it when I'm selecting contacts - I can't remember).
I sometimes daydream that everyone at work uses Linux in general and a text-based email program in particular. It isn't too farfetched. When email took off, I was in college, and we all used Pine.
Anyway, if you email me, it will arrive on my virtual private server, and I will read it with Mutt.
Been running my email infrastructure for IIRC about 8-9 years (with postfix).
Spam isn't much of a thing, which perpetually surprised me but there it is.
Some background: before I ran my own email server I relied on my ISP for receiving email for my domains and I was getting hundreds (even thousands) of spam messages a day. I used spamprobe to classify the spam away, very effectively. But that ISP must've had a very lenient smtp configuration.
With my own email server I enforce everything postfix supports enforcing at the time of the connection itself. Watching the postfix logs, I get multiple spam attempts per second but all of them are rejected before the connection attempt is accepted by postfix.
Actual spam that gets through that is minimal. About zero to five per week for me. I'm still using spamprobe to classify them just out of inertia, but the volume of spam is so low it isn't necessary.
As to outgoing email getting junked, it's harder to have exact statistics on this but it has never been an issue for me in the sense of not getting a response from someone, so they must've received it. You do need to configure SPF, DKIM, etc but aside from that, it's not a big deal. There are sites which help verify your configuration, use them.
Every time an smtp thread pops up on yc the difficulty of running your own email infrastructure is overstated. Of course I wouldn't recommend it to completely non-technical people, but if you have any interest in internet standards, just do it.
Own your infrastructure, help us all decentralize email and don't be the next victim of "gmail locked me out of my life and I have no one to call for help".
I've only been running it for about a year, but I simply don't get spam --- perhaps partially because it isn't my main email address.
I went by this article, https://www.c0ffee.net/blog/mail-server-guide/ but I only set up Postfix and the various DNS records (MX, DKIM, etc.). I didn't set up Dovecot because I just use Mutt on the same server. And I haven't bothered to set up any kind of spam filter.
Not parent, but I'm in the same boat with the self-hosted email VPS. I usually use Thunderbird as a client though, but sometimes mutt.
- SpamAssassin does a wonderful job after training it about once every 3 years. I get almost no spam.
- I was able to send to most people from my VPS, but not Charter. Charter blanket-blocked my ip block. So I ended up setting up SMTP forwarding via sendgrid free tier (100 emails per day). Now I always get through.
For Gmail, DKIM is a must for deliverability. I initially only had SPF configured for my Postfix server, and Gmail just kept rejecting the SMTP connection.
- Virtual Windows Server 2012 R2 running on my Hyper-V host.
- Microsoft Exchange 2013
- Self written, internet facing MTA, that filters/rejects email before passing onto Exchange
- The MTA passes all email under X size through Spamassassin (SPAMD) running on a separate Ubuntu based virtual server
- The MTA also has some internal rules to straight up reject bad IPs and emails with 'badwords' in them.
- The MTA has an internal list of email aliases that it accepts email for, then it re-addresses them to the real internal email addresses that are configured in Exchange.
I've been running this setup in one form or another for about 20 years now, upgrading parts as I go along. Due to the version of Hyper-V I'm running, I can't run Windows Server 2016 or higher as virtual servers. Also, I've upgraded through Exchange 5.5, 2000, 2003, 2010 to 2013, but I tend to upgrade when I need to, not when there's a new version, hence still running 2013, which I only migrated to a few years ago.
It's the mail system for my whole family, plus handles the email for the 3 small companies that I run. Stability is more important than anything.
Outlook Anywhere is fully configured correctly - both iOS and Android can 'auto configure' for the mail server with just an email address and password.
I've got SPF and DKIM set-up, but send email through my ISPs smarthost just to be safe. Gmail and Outlook.com happily accept my emails without issue.
Regarding spam... This is the ongoing bugbear. No matter what you do, once you've been using an email address for a long time (in my case over 20 years for some of them) fighting spam is a constant battle. This weeks spam content is all about Air Conditioners and slimming aids.
I would NOT recommend that anyone set-up their own personal email system unless it was a learning exercise. It's just too much hassle these days. Personally, I'm am in the process of moving the whole lot to Office 365, which will cost me a bit more in yearly fees, but will give me some time back not having to admin it, which at this stage in my life is more important.
I also host my own email server. For the first several years, I didn't have a spam solution since I wasn't getting any. After it started coming (not in terrible amounts but enough to become a nuisance), I set up rspamd. It works nearly perfectly: all spam mail is correctly detected as such and legit email rarely ends up as junk (perhaps once in several months).
Same here, I was at university, and we used Pine too. I also wish the same. Often my colleagues find it strange I use a text-based program for email - as if 99% of communication online isn't using language.
I can't imagine doing email without mutt, without all the keyboard shortcuts I have, and without vim as the editor. Thank you mutt. Just what an email client should be. I wish there was better search support but that's about it.
i recently switched to Thunderbird from Neomutt + Notmuch + afew + gmailieer combination. I was satisfied mutt's responsiveness, simplicity. But more and more emails are only for html based and its conversion to text is horrendous, I had to view Html at its own format. Then Thunderbird becomes a good candidate.
The really annoying thing is that some mail is multipart where the text/plain is just “sorry, your email client does not support html”. Yeah thanks a lot but it does, it’s just I have it set to prefer text/plain, because I don’t want to look at the html dump version unless I have to.
If those people had simply sent only text/html and not a useless text/plain that only says that kind of stuff then everything would have worked fine.
Stuff like that makes me want to quit using mutt, and no fault of mutt mind you.
But laziness has kept me to using mutt for reading my self hosted mail for many years now.
I commend you for using “laziness” and “self hosted email” in the same sentence. I ran Mail-in-a-box a few years ago on a cheap VPS. Then I realized just how much I don’t want to do that. It was fun being my own email provider, even if it was only for a secondary account, but the risks definitely outweigh the benefits.
I also had that But the experience is way worse than reading email in html format. And these days, almost all emails are in html format with pretty basic text/plain in the form of multiformat.
That plain text doesn't have the intention of the composer, for instance, the inline image doesn't show inline and the email context says the figure above.
It is not that business form, but some ppl use colorful format to emphasize some text, which basically gives same text in the email, which makes the reader (in plain text) easily miss that part while skimming.
> It is not that business form, but some ppl use colorful format to emphasize some text, which basically gives same text in the email, which makes the reader (in plain text) easily miss that part while skimming.
I consider that a feature... On some email lists I'm on, there are endless complaints of how some people don't like some elses font/color/size etc. Using mutt I don't see any of that distraction, I just see the text. That's a win in my book.
I'll happily agree that it depends on the mail, and that for emails actually using graphics or fancy formatting, you really do probably need a real graphical interface. Personally, probably 90%+ of my mail can be reasonably rendered in plain text, so this works for most of it and then I use another client for the rest. But for the things it works for, mutt is amazing, so I use it when I can.
gmail is such a huge regression from mutt (or even pine or elm).
I rank the email experience of gmail on par with /bin/mail. It's that useless.
I use mutt as an IMAP client for gmail when I can, that works mostly ok. At current $DAYJOB they only allow gmail web client which is a complete disaster of unusability.
So I mostly just zoom or slack people since gmail is so useless.
gmail is email written by those who have never used a proper email client and don't really care about email anyway.
(gmail came out in 2004 - got the tshirt from the launch.)
As the search experts, I'm always surprised how poor and unreliable search in gmail is. I also use mutt with my gmail account via mbsync. At least you get to use gmail webmail. I have to use Outlook at work.
Lol side-story... I once worked for Big-Multi-National i.t/startup company they even have a stake in Tencent.
Their official mail policy was after 3 months we delete all your email.(You had to save/archive) it yourself if you wanted to have access to it. Some MSExchange setup.
The 'reason' back then was 'Some semi-high-level-executive lost his tablet somewhere with important mail. I couldn't believe a company this big and enough money to buy common sense and intelligence came up with this 3-month rule as a solution to 'lost executive tablet'. They closed allot of their local I.T/Startups in the last decade in South Africa.
Jeez, what an awful solution. I work in an academic environment and also in a healthcare environment. There is a national 'secure' MSexchange service for patient data, and we also use a local exchange server for within-hospital communication. I have no idea how secure any/all of this is, but I tried to add my 'national' account onto my regular outlook, and it broke everything. IT support told me that I wasn't allowed to do this because it wouldn't be secure. Which confused me given I used Outlook for confidential communication within the healthcare provider. So I'm forced to use their webmail client which is even worse than Outlook.
Not sure how email got into this mess. It should be simpler, and confidential communication should just use something different IMO.
Noooooo WAY. I started at Rice in '98 and remember using Pine on the Sun Solaris desktops spread all over campus. Of course I imagined Pine must be ancient software, and when someone told me to switch to Mutt halfway through college, I assumed it was just yet another super ancient program, not realizing it had been released when I was in high school!
Another extremely happy user of the following combination waves hi:
• Mutt
• OfflineIMAP (to be replaced with `mbsync`; OfflineIMAP is not being ported to Python 3, unfortunately)
• Notmuch — for fast indexing, searching, and tagging e-mails
• Postfix — Mail Transfer Agent; offline queuing. Overall, it's one of the most robust pieces of software; Postfix never failed even once on me in nearly six years.
Same here, though I moved to mbsync a few years ago and I need to check out postfix.
It is such a great email client that I feel lost and walking through treacle using anything else. I don't work in the tech field, but I have a lot of emails to deal with. People come to me now to ask me if I can find specific important emails from a while ago that they are after. Outlook is hilariously bad at searching. I wish I could use mutt instead of outlook for my work.
EDIT: It looks like I'm using msmtp instead of postfix - any advantages to switching over to postfix?
It's probably time for my annual attempt to convert over to using a mutt-based email workflow. I've always been happy with the mutt setup, but I think the majority of my problem is dealing with importing my existing Gmail and (work) Office 365 accounts. Sometimes I've synced the data to my laptop (last time I even had it all running in a container). But I still need to access enough of my email from my phone that I've found the mutt setup too cumbersome, even when using IMAP.
Does anyone have a good setup with multiple accounts or using both mutt with a mobile email client (iOS)?
mutt-wizard makes it very easy to setup mutt/neomutt to make it work with gmail and other services. It sets up encrypted offline versions of your mail and sets up most of the mutt environment for you:
https://github.com/LukeSmithxyz/mutt-wizard
One of the major reasons I use Gmail in the browser is because it’s in the browser: it’s always on the same tab and I can switch to it when I want to check it. I used Mutt (unsuccessfully) a few years ago since my other window that’s always open is a terminal emulator.
I wonder: should I fire up a Linux emulation in my browser and run Mutt inside that? I’m sure things have gotten fast enough that this would actually work.
I don't know about Gmail in the browser because I access it via IMAP and SMTP, but I have noticed that the browser process that's associated with tab that has the Google voice page open will occasionally start consuming a lot of CPU and memory resources to the point that I have to terminate the process.
This never happens with Thunderbird and is even less likely to happen with a TUI client like Mutt.
If you are already productive with Gmail and its web UI, why change?
I love mutt and have used it in the past, but I'm very productive with Gmail in the browser, especially with the vim-like shortcuts it provides and with an inbox-zero-like workflow.
I use mutt for Gmail in my terminal, the setup is fairly easy and documented across blog posts
example muttrc
=========================================================
set imap_user = '<username>@gmail.com'
set imap_authenticators="oauthbearer"
set imap_oauth_refresh_command="~/.mutt/oauth2.py --quiet --user=<username>@gmail.com --client_id=<id from google>.apps.googleusercontent.com --client_secret=<secret from google> --refresh_token=<token from, you guessed it, google>"
set smtp_authenticators="oauthbearer"
set smtp_oauth_refresh_command="~/.mutt/oauth2.py --quiet --user=<username>@gmail.com --client_id=<id from google>.apps.googleusercontent.com --client_secret=<secret from google> --refresh_token=<token from google>"
set ssl_starttls=yes
set ssl_force_tls=yes
set imap_pass = 'my really hard to guess gmail password'
set from='<username>@gmail.com'
set realname='Fancy pants name'
set folder = imaps://imap.gmail.com/
set spoolfile = +INBOX
set record = "+[Gmail]/Sent Mail"
set postponed = "+[Gmail]/Drafts"
set trash = "+[Gmail]/Trash"
set postponed="imaps://imap.gmail.com/[Gmail]/Drafts"
set header_cache = "~/.mutt/cache/headers"
set message_cachedir = "~/.mutt/cache/bodies"
set certificate_file = "~/.mutt/certificates"
set smtp_url = 'smtp://<username>@gmail.com:<my really hard to guess password>@smtp.gmail.com:587/'
set smtp_pass = 'my really hard to guess password'
set move = no
set imap_keepalive = 900
#refresh every 10 seconds
set timeout=10
set mail_check=20
# allow mutt to open new imap connection automatically
unset imap_passive
# vim!
set editor=vim
# email sorting
set sort=threads
set sort_browser=reverse-date
set sort_aux=last-date-received
# handy macros
macro index gd "<change-folder>$postponed<enter>" "go to drafts"
macro index gs "<change-folder>$record<enter>" "go to sent"
macro index gi "<change-folder>$spoolfile<Enter>" "go to inbox"
macro index gt "<change-folder>$trash<enter>" "go to trash"""
Sure, but the problem of storing messages indefinitely isn't from the protocol, it's from the client. The client may need to verify if it's actually seen a message before and keep a local index of them; it may need to double check the message still is what it expects before it tries to delete it; it needs to present you with options on how to handle message deletion; etc.
POP3 is actually less reliable at keeping messages indefinitely than IMAPv4 is, due to limitations of the protocol. Some clients have defaults which simply delete the remote copy after download (or reading, which is different), but again that's not the protocol's fault.
In brief, you use the limit command to see only the email you are interested in, then use the tag command to do something to those specific messages. Both limit and tag use the same pattern language to specify From, Subject, date ranges, message numbers, or more esoteric searches.
The only thing mutt is not great at is searching multiple mailboxes, and it's easy to integrate an external tool (notmuch, maildir-utils, mairix...) to do that search and link the results into a temporary maildir that mutt will then work on.
I find bower to be better than mutt at dealing with large quantities of email, but mutt is better at everything else. bower can also run locally with a mailbox on a remote, which allows things like easy seamless opening of attachments that don't work as well in a terminal (images, PDFs, &c.).
I still use mutt (with https://mailinabox.email/) -- and I like how it works, but the annoying thing is html-only emails - finding that unsubscribe link is so hard sometimes.
I actually stopped using email for private communication. Most emails are just invoices, confirmations or license keys. Gave up on email few years ago.
Professional I use email for mostly the same and for official trace communication....
I so happened to have spent yesterday afternoon figuring out mu4e on Emacs, which I'm new to. Figured out IMAP but not sending yet. Worked with gmail with a very simple config file.
the best times with mutt were the days where we were hanging out with michael elkins (me) at the linux user group meetings in L.A. during which i came up with this joke:
"i didn't write mutt, it was me"
i used mutt until a few years ago when i switched to sup.
I solved a problem with nmh last week. That felt good (finding ten emails by string search from a .mbox format archive and making another mbox archive from them)
I am pretty sure mutt would have done it too, I used mh because I had the muscle memory
Would be nice to modernize it by porting to Rust, thus reusing some of the libraries for network protocols, cryptography, file formats. It will allow developers to focus on the important things.
It's open source, so you are totally welcome to do that thing. Enjoy yourself. Please call the resulting program something related to but not identical to mutt, such as rustmutt, rustydog, mutt-ferric-oxide, or whatever else makes you happy.
I'm still using mutt, although Jean-Pierre passed away three years ago.
https://www.legacy.com/obituaries/nytimes/obituary.aspx?n=je...
I believe that at the time he started using mutt, he was still getting some of his e-mail over the declining UUCP network (as he was a tremendous UUCP enthusiast and even provided commercial UUCP connectivity and support at one point).