The state of MUAs isn't bad/sad unless you apply a pile of unreasonable constraints, as you have. Then, yeah, you can't find anything. Loosen up. "Written in C" is an issue for you? And you use Linux? Just give Evolution another try and give it a little time.
Ask HN: Is the state of mail user agents that sad?
11–20 of 25 posts
Re: Ask HN: Is the state of mail user agents that sad?
#12I have been using mutt for triage and simple things, with Google web mail interface when necessary for e.g. HTML mail.
The workflow is ok. I get a large amount of email that I can just delete, and it's particularly nice to be able to select a bunch of cron emails with a regular expression.
In the last year it's become unreliable. When I move a message from one folder to another, it doesn't stay moved. I guess it's some error handling problem. I have lots of emails in some folders (10k).
I have thought about writing a driver for mutt that works directly against the Google API instead of IMAP, but writing REST code in C would be a slog.
Re: Ask HN: Is the state of mail user agents that sad?
#13It seems to me that majority of users don't want to deal with a native application - specially one that:
1. They would have to install, maintain, backup and configure themselves 2. Has a reasonable web application, that, as a major perk, they don't have to install, maintain, backup and configure themselves
Due to the lack of demand for such a product, I am not surprised the existing products arn't polished/well maintained.
Re: Ask HN: Is the state of mail user agents that sad?
#14Earlier quoted context omitted.
Can you recommend a good set of docs and tutorials to set up mu4e? I still use emacs and a separate (mutt) MUA and copy and paste things between, I know it sounds awful... but hard to escape entrenched habits. What would you suggest as the best steps for a good setup? Does everything go in the .emacs config? Do you need to write much e-lisp or it it a tickbox type config? Thanks for any pointers!
They are a bit all over the place - I started this years ago so I don't really have anything solid, but searching gives a few results that looks pretty solid ([1] [2]). If you temporarily tried doom [3], I think you could see how it would work for you. You need to install something like isync as well so you have a mailbox index locally. I would start with just one account - multiple accounts is a bit more effort. In…
Thank you. After I posted I realised my stupidity in not checking
out your linked config file. Having fun with that now. Cheers for
the additional nfo.
Re: Ask HN: Is the state of mail user agents that sad?
#15> Is the state of MUAs and e-mail in general really this bad/sad?
Undeniably, yes.
Personally, I still use the last real version of Eudora (7.1.0.9) along with a patch that gives it support for modern security (full TLSv1.2, LE root certs, etc).
I use it at home and at work, with over 20 years of email history in each one. I simply cannot find anything that does what it does as well...
Handles over 1 million messages with ease
Nice filtering rules
Super fast search tool
Files aren't stored in some inaccessible binary store
Keeps attachments stored externally from mailboxes
Makes it easy to manage multiple addresses & accounts
Very plain-text friendly
Has limited image/HTML support & doesn't run javascript (security though inability :) )
etc etc etc
Re: Ask HN: Is the state of mail user agents that sad?
#16I'm still fine with Thunderbird as a MUA (more or less). Using number 1 and 4 as shortcuts to mark an email as "todo" or "urgent". Invitation to appointments (ics file format) can be accepted as well. Integration of contacts is a paint point though. For email automation I have written a lightweight CLI in Rust [1] which supports MIME and SMTP. I'm currently integrating sendmail's capabilities as well, so that it can…
Thank you for responding, and for providing me with a link to your project. It is good to see that things like this exist in languages other than C. While some people on this thread in fact implied my constraints were unreasonable, I have to say I'm a bit fed up with all the statements on Wikipedia regarding security vulnerabilities of common mail software -- due to buffer overflows.
Re: Ask HN: Is the state of mail user agents that sad?
#17It seems to me that majority of users don't want to deal with a native application - specially one that: 1. They would have to install, maintain, backup and configure themselves 2. Has a reasonable web application, that, as a major perk, they don't have to install, maintain, backup and configure themselves Due to the lack of demand for such a product, I am not surprised the existing products arn't polished/well maint…
Yes, I totally see your point. Gmail and similar offers are convenient, which means that native software has some very stiff competition and not a lot of adoption.
I'm interested in frugal computing, and I want my software to run smoothly on a Raspberry Pi if at all possible. So I do have some demand for a native program or, rather, set of programs.
Besides, on a principle level, I fail to see how something as simple as e-mail should need (or be allowed to use) something as complicated and resource-hungry as a web browser.
Re: Ask HN: Is the state of mail user agents that sad?
#18The state of MUAs isn't bad/sad unless you apply a pile of unreasonable constraints, as you have. Then, yeah, you can't find anything. Loosen up. "Written in C" is an issue for you? And you use Linux? Just give Evolution another try and give it a little time.
I find your answer a bit intrusive, to be honest. Let's just stick to the subject matter instead of telling each other how unreasonable or uptight we are, okay?
Yes, "written in C" is an issue for me, for two reasons:
* I really do want to do rapid prototyping and testing hypotheses regarding MUA UX, and C is just not suitable for this end.
* I keep reading about security vulnerabilities in common mail software caused by (among others) buffer overflows.
I don't think that MUAs benefit from C the way system software (such as the kernel) does. And compared to MUAs that run in the browser, I think that the bloat introduced by using Go or Python is still justifiable. Fortunately, there already exists a MUA written in Go (namely aerc).
Re: Ask HN: Is the state of mail user agents that sad?
#19I really hope that encrypted email is not a lost cause because that would strongly imply that end to end encrypted messaging is a lost cause in general. If we can overcome the problem in any single case we can overcome the problem generally, even for encrypted email. This isn't something we can overcome with a purely technical solution. The basic ideas behind end to end encrypted messaging will eventually have to be…
With respect, I do object.
End-to-end encrypted messaging does work, and Signal (among others) is proof of that.
With e-mail, either (a) you are backwards compatible and sending unencrypted (even by accident) remains a possibility, or (b) you break compatibility, but then it's no longer e-mail. (Signal is an extreme example of the latter: it just uses its own protocol.)
Re: Ask HN: Is the state of mail user agents that sad?
#20I went down a rabbit-hole last year trying out different MUAs and configurations, searching for that perfect setup. I like CLI interfaces and I wanted something where search was not as painful. It was a nice distraction, then I realized that I only spend a few minutes each week reading email. It's just not a significant part of my workflow, either professionally or personally.
For me, it's not just about e-mail, but our industry/discipline in general, and the state of e-mail is a good indicator in my opinion, because almost everybody uses it every day, and its implementation complexity is still rather manageable.
Besides, I'm interested in frugal computing and would like to reach a point where I can do my day-to-day stuff on a Raspberry Pi or similar device.