Email doesn't suck – it's email clients that need improving
wired.com
wired.com
Spam. The protocol is insecure. Consolidation of major webmail providers is a huge problem on multiple fronts (censorship, third-party acceptance (of both delivery and non-GmailMicrosoftYahoo email accounts --- my Protonmail service can't talk to GetPocket's support email on Gmail for months, f'rex), spam, account hacking, authentication, repudiability (yes, that coin has two sides), workflow integrations, proprietary workflows, spam, account lockouts, lack of common email formatting and practice standards, HTML email, spam, pervasive surveillance, attachments, spam, mobile access, spam, spam, infinite diversity in proprietary messaging systems and platforms each fractally worse than email in a myrad ways, spam, spam, spam, inbox overflow, spam, spam, spam, spam, email bankruptcy.
I've had an email account nearly continuously since the mid-1980s. I've all but abandoned it in the past decade.
There is no viable replacement on the horizon, though postal mail is looking increasingly attractive.
Here is the complete list:
'top','tv','biz','rocks','ru','science','bid','date','casa','buzz','xyz','click','online'
Do you have an example of sites where account creation mails do not arrive?
I've had to setup DKIM, update records and keep up with changes to it just to keep my custom domain.
As someone who operates a SaaS that does auto-block some account registrations based on email address, I feel like I should speak to this. We're actually fine with custom domains — and I imagine this is true for most SaaS companies. All our business customers use custom domains; and we're not about to blow holes in our funnel by making it harder to acquire new business customers. There's no logic in our codebase that especially favors the big email providers; no whitelist with gmail/outlook/etc. on it. (And we haven't found that any of the lifecycle-mail sending services we've tried have had trouble with custom domains, either.)
Instead, what we're mostly trying to stop is registrations using what you might call vanity or proxy domains — domains created by people who are only trying to obscure their real email address, but who aren't willing to invest the effort to make their domain into a "real" domain that has working email deliverability in both directions and maybe a web presence to go along with it.
Businesses almost always have such "real" domains; but people registering for illicit purposes (spamming, ban evasion, etc) almost never do, instead only bothering to set up e.g. an SMTP forwarding proxy that has no ability to originate mail. (Often they get such a service as a value add from their domain registrar; though there are independent services for this as well.)
To detect these, we check things like:
- Is your domain a known temporary email provider? (Immediate fail)
- Is your domain's MX record shared with one used by known temporary email providers? (Also an immediate fail; and zero false positives from this, surprisingly)
- Does your domain have SPF and DKIM records? (Good)
- Do your MX record hostname(s) resolve to the IP ranges of some skeezy VPS host, or to an IaaS's ephemeral-allocation IP ranges? (Bad)
- Does your NS record, or your MX record's NS record, point to a domain registrar that's well-known to be used for discovering + acquiring short nonsense domain names in bulk? (Bad)
- Does your domain have an apex A record? (Good) Is there a website there? (Good) Is that website a domain-parking page? (Very, very bad)
- How recently does your WHOIS record say that your domain was last transferred/acquired? Last 14 days? (Somewhat bad, but not as bad as the other things)
I would guess that if you're having problems, it's with one of these heuristics, or one in a similar vein.
If you jump through all the same hoops a business would jump through to make your custom domain "real", then any heuristics SaaS companies come up with to differentiate business domains from spam domains, should work out in your favor. (My own custom domain — which truly is just a vanity domain — passes all these tests easily; mostly by just doing the default stuff Google Workspace recommended I do when I set it up. Because that's all businesses are doing, too.)
I hope, I have stumbled into a couple of services that have some poor email verification implementation and my domain has not been blacklisted by some email protection company or something serious like that.
What do you mean by custom domain? Anything not @gmail.com? How could that be, since every corporation everywhere has a custom domain. Must be something else going on.
That is: organisations are increasingly abandoning email, at least for public-facing work.
Ironically, Google are perhaps most notorious for this (HN is one of numerous Google-email-contact alternatives for problem resolution).
More generally, the end state of any universal communications medium of unlimited reach and access ... is abandonment. Absent some viable mechanism for curtailing usage, the only viable options become either shutting off the system entirely, or at best, randomly sampling from amongst submissions.
Conversation, and communication, both scale poorly.
It would be the same if we had all been using - say- XMPP for the last 20 years.
There were from a few dozens to a few hundreds of hosts on the entire network at this time. Most were educational institutions, meaning a campus sysadmin could run herd over users (if students) or refer to deans / departments (faculty). This from the 1970s through the early 1990s, at which point things began evolving rapidly.
Transacting email itself wasn't all that expensive, though for many sites it was batched via uucp or similar mechanisms.
It's always going to be a bit of an awkward fit to today's Internet where you can trust that any and every exposed service will face some attempt at abuse.
If the friends and family address gets spam, offer a way to create and distribute a new address.
For business it is tricker as you want anyone to email you. Here regular antispam measure are probably best.
On the other hand people might want to keep pseudonymous and throwaway mails. Nearly the exact same warnings apply here as they would have applied to those that chose Google as a mail provider and now complain about lacking support and account closure. A largely self-inflicted problem. Don't continue this naivete...
Spam is annoying, but not a threat. Phishing is to a large degree. That needs user training, people stopping to pay ransoms and sensible IT policies for corporations.
That said I can count on my fingers and toes the number of spam messages (via hijacked accounts) that have reached my Facebook Messenger/Instagram inboxes and have received zero spam in several years on Snapchat.
Walled gardens have many downsides, but there are upsides as well.
So yes, most walled gardens' two-step approach makes the spam more civilized, but they don't eliminate it.
That said, I only communicate with a couple dozen close friends on snapchat so perhaps a more active user will get spam.
What's not arguable is that spam is email's problem.
What responses to my quite off-the-cuff though apparently resonating comment has (mostly) failed to recognise though is that spam is a problem not only for email users but across the spectrum for operators, administrators, senders, application designers, and a whole host of others. The fact, volume, and consequences of spam have a tremendous set of knock-on effects which are hard to express with any degree of coherence and sufficiency.
Which system gets it right and could email be fixed?
It's trivial to address spam on trivial systems --- those which are small, centralised, and tightly controlled. It's difficult to do so on nontrivial systems --- those which are large, decentralised, and loosely controlled.
Email is very much the latter. It also lacks costs (sending has exceedingly low marginal cost), and has very poor authentication / identity assertion, and reputational capabilities. All of this is baked into SMTP at pretty low levels, and the various bolt-on kludges to address this (SPF, DKIM, DMARC, and anything else that I'm not yet aware of) are at best only partially effective, and rather fragile and fiddly. Among the reasons large monopoly email services are so effective and useful is that they "see" the spam problem at a global level, across hundreds of millions to billions of accounts. My statistical background tells me that this is almost certainly overkill, and that even services with only a few hundreds or thousands of widely-shared known addresses (something easily accomplished by honeypots) would achieve much of their effectiveness.[1]
Another huge problem for email is that there's a lot of loose coupling between end-user clients and servers, especially for desktop-based (non-Web or mobile App) systems. Contrast with social media or webmail in which a person's flagging of an item as spam or abuse is instantly registered by the system, which has full awareness of where the item originated and what other activity has come from that account (or if sufficiently sophisticated, known clusters of accounts) recently. In the case of email, the end-user client, the receiving server, the sending or relaying server, and the original injection point(s) might well be three or four entirely independent systems, for which there's no through chain of identity and often asynchronous hand-offs meaning that flagging actions are noted only long after the message was initially accepted for delivery.
That flexibility was useful early in the history of SMTP's development. It's an Achilles heel now.
One possible reform would be for sender to spool mail until it's been accepted for delivery. This would complicate sending (especially at high volumes, not necessarily a Bad Thing), but would mean that the determination of whether or not a message was spam, or behavioural assessments (e.g., Sender A has requested delivery to 1,000 local addresses, many of which don't exist and/or are honeypots) might permit a presumption of spam before the actual acceptance of the message.
All of which would raise costs to spammers and make use of botnets for delivery far less reliable in that those sending hosts would be identified as spammers before many messages could actually be transacted, assuming that white-hat recipients share reputation data regarding sending sources.
Another practice generally is to have a varying level of service provided based on the level of familiarity, trust, and/or value associated with specific senders. Given weak authentication this is not especially robust, but it would again make simple-minded email blast spamming highly ineffective. This practice has been fairly widely adopted in some forms by corporate domains which require specific whitelisting of authorised senders as a general rule. Implementations last I was aware tended to be ad hoc and kludgey. It's an annoying but reasonably effective method.
________________________________
Notes:
1. The law of large numbers and spam's reliance on broadcast distribution largely account for this. A small number of individual spammers hitting effectively all known email addresses account for a huge proportion of spam. Knocking a single such operation offline can drop global spam. This is a 2008 story in which a single provider accounted for 75% of all spam: <http://voices.washingtonpost.com/securityfix/2008/11/major_s...> . Smaller systems (< 100m accounts, say) might tend to miss more sophisticated targeted attacks and lag in responding to these --- phishing, spear phishing, and APT attempts against specific accounts. I'm not sure if this is a trade-off or not, though I suspect any sufficiently highly-place PEP (politically exposed persons) would attract such attention, and that this risk is not especially scale-responsive. This is also somewhat tangential to spam in the sense of indiscriminate mass mailings, though both are serious concerns for email integrity.
My email works as long as I keep my domain name renewed and my personal postfix+dovecot server online and running properly.
Nearly every other possible asynchronous, text based two way communications system that people say is a "possible replacement for email" requires centralizing communications through something run by some specific company.
Email's great advantage is that it's a truly level playing field. Yes that also allows spammers to send outgoing shit smtp traffic, but I can deal with that.
If you are greatly troubled by spam and it's an actual ongoing problem in your inboxes I would say that your inbound smtp content filtering and spam scoring is not set up properly.
Agree so much.
I really don't get the spam complaint anymore. Commercial providers like gmail do get a lot of spam (I have a gmail account as well, it gets more spam than ham) but it doesn't need to be that way.
I run all my own email infrastructure and spam is a non-issue. My primary email has been around very publicly since the mid-90s and is surely on every spam list ever but between a strict postfix configuration and a bayesian spam filter, spam is not a thing anymore.
I'm trying to think the last time I got a spam email in my inbox and can't remember. It's so rare.
There's legitimate email that consistently gets marked as potential spam, and I don't know how to tell my mailreader to always trust that source. The tax service regularly mails me that there's a new message for me in my message box at the tax service site where I need to log in, which is a terrible way to communicate. Their paper mail does contain everything I need to know, but their email cannot because email is so insecure.
Something like email, but with authentication and encryption built in from the start, would be a really nice improvement.
Rest of it, is apparently not important to make a difference to me in any way.
The email I use for registering on sites, or using on mobile, is absolutely bombarded with spam. The email I use privately receives near zero spam (that isn't trivially filtered) even though it's a simple and common two word combination at a major mail server. Notably, I'm not registering for dodgy sites or anything like that on the spammed email. It's all major and ostensibly reputable sites. For sites I don't trust or care to receive a message from, I use throw-aways.
I simply assume any site you register on is going to sell, leak, or accidentally expose your email (or any other information you offer them). Similarly for mobile devices. And that seems to be a consistently validated assumption.
This makes it really easy to filter out spam (and I also know who sold my address). It's also trivial to block unwanted 'subscriptions'.
I use Thunderbird and create an identity for every one of these mails that require a reply (most don't) and TB automatically uses the unique address when replying.
The contemplative nature of reading paper is a bliss.
Spam is a problem, but honestly 15 year old slightly trained spam filter with a sensible config can filter all without any false positives.
Not that mail is not without its problems, but any modern alternative will suck much more. It will be a service attached to a corporation you will again make yourself dependent on. I feel for those whose Google accounts get locked, but to a large degree it is their own fault.
I don't know a lot of corps that block unknown mail servers. Have it sign outgoing mail with your known domains and your mail will not land in some sandbox or spam filter.
Instead, more than 60% of mid-sized companies use Gmail.
If it were that easy why do all the big players do it so badly? I'd rather get more spam in my inbox than miss the false positives (in fact most of what's in my spam folder is technically legitimate, but usually just broadcast emails from organizations I happen to have used my email address for at some point in the past). But I haven't found a way to sufficiently lower the threshold for spam detection for any email service I've used to avoid that problem.
If these were in place then it would be able to send all spam back to sender, instead of putting it a spam folder due to filtering, your email client just would send it back to the origin address.
It also would help if each send would cost a token (of some monetary system) that would be returned on delivery at the legitimate destination. This would help against bulk sending.
Email is a system that will always cripple at some point if there aren't real world cost incentives in place.
People are the biggest problem with email, which is hard to solve with mere technical solutions.
Being stuck with Outlook due to corporate inertia, most days i run into simple silly things that have been inconvenient for years:
- non standard shortcuts (what modern windows app doesn't use Ctrl F for Find which you would think would let you search an open email for text except it does something else!
- fragmented unintuitive disttribution of functions over tabs
- remarkably unhelpful use of space in the inbox views, such that columns rarely show enough of what you need to see
- annoying assumptions (eg typing a user name into the inbox search defaults to using From: when i frequently need to search with it as To: when I've got folders of email where I'm a co-recipient and need to search who the mail was address to)
For this, in Outlook, the explanation is (per Raymond Chen): Bill Gates
https://devblogs.microsoft.com/oldnewthing/20140715-00/?p=50...
Frequent revalidation training in the leverage of Microsoft products is something that would have helped your person avoid looking unprofessional.
I agree with you here. The one time we saw a progression with Google Inbox (which showed cards of events, photo-previews, etc.: https://cdn.vox-cdn.com/thumbor/vRLmb7RDrySSxylcMGIoV7dWTK8=...), it was quickly followed by a regression: they closed it, I suspect because the previews were costing them too much bandwidth. The day I see a well-made OSS replica of Google Inbox is the day I go back to doing my own email.
That seems like an odd use case that I have never needed to do. Not sure why there would be default support for that when you could just start your search with “to:”
Using a framework is almost a requirement if you don't want to spend all your time on little differences between email clients. The layout is really wired too, with the recommendation to use a ton of nested tables. Not to mention wired bugs like Apple Mail not rendering a background unless you have an image on the page.
The best solution I've found thus far is to use MJML React [1]. This sorta normalizes things and lets you write normal react code that gets transpiled into some abomination that Outlook can read. But it sucks that the only two options that are actually worth a damn seem to be MJML[2] and Foundation[3].
And even with those frameworks it's no silver bullet. I noticed an issue with one provider where they did not respect the `display` css property, making my mobile and desktop layouts both render on the page.
If someone works on these clients I would love to know why there is such difficulty in rendering email?
[1]: https://github.com/wix-incubator/mjml-react
[2]: https://mjml.io/
I'm reading most of my mail with mutt on the command line and that works quite well. Until … some email with a confirmation link for something shows up. Or with the wrong MIME structure.
Because these confirmation links more often than not are execessivly long, state-carrying links, which wrap around even in my 99 (or more) columns wide windows. Because lazy web designers don't use a short SHA key, which would relate to a database entry of the full data. No, they send their complete state.
Oh, and did I mention those MIME emails with the wrong structure? Where the first part is the text part telling me that my MUA cannot display their fine mail? It can (easily formatted with external helpers like w3m) but I have to select the 2nd or 3rd part of their "fine" mail first by hand.
I mean, citation needed. I’m ready to consider the idea but give me a reason!
95+% of computer users will not want to use a command line.
In my experience, most mails don't actually use any styling beyond the automatic blockquote for the endless quote chains that mail clients automatically add. So people are wasting storage and transfer for something they don't really use.
When I see a mail which could actually use some styling, it's usually something involving maths and HTML is not suitable for that case. People usually send LaTeX snippets in plain text in this case.
And while I'm at it, the endless quote chains are another thing which has no reason for existing. Each mail in a thread steadily grows in size, because mail clients "conveniently" always quote everything and put the text cursor above it so that the user doesn't stop for a moment to look at the size of what they're sending and consider the absurdity of the situation, when their client is perfectly capable of reconstructing the whole thread without copying all mails in each message. Quoting should be opt-in on a case-by-case basis. As they function in the wild today, the quotes are just useless garbage attached to everything.
Quote chains are why it's both email and email clients that need to improve. Without consensus on what's "right", we're left with poor solutions with poor UX, and implemented in a fragmented way, because all clients need to agree. What's more, how do you loop someone into a conversation they weren't previously a part of, if you don't have the history of the thread in each mail? This is something Slack gets right, and because they control the client as well, they can unilaterally make changes that support their view of how message history works. The strength of email is in its decentralization but here, it becomes a shortcoming.
It's not about HTML vs plain text. It's about HTML vs a way to style text which is actually useful to the users. HTML is so bad for this purpose, in practice 99% of HTML mails don't use any tags in their proper content and mails which could use some styling to make them more readable are using plain text, because HTML is of no help to them. My remark about overhead was actually about the quotes, whose sizes grow linearly as threads get longer (and the threads grow quadratically instead of linearly), not about HTML. You don't pay for tags you do not use (almost). The only rich HTML mails (as opposed to plain text HTML mails) I get are marketing mails, which want to track me and "stand out from the crowd", neither of which I have an interest in, and HR mails.
> What's more, how do you loop someone into a conversation they weren't previously a part of, if you don't have the history of the thread in each mail? This is something Slack gets right
Slack doesn't get it right. When you join a conversation, you always see the whole history. But in practice people conduct conversations according to the assumption of who is taking part in them at a given moment. They can't predict the future and that someone will add another person to the conversation, and now this person will see everything they wrote. There is no way to add them to the conversation with a context of "the last n messages" e.g. In an ideal mail client you would select which messages from the thread you want to share with the newly-added conversation participant.
To be clear, I agree, but it was the only reason I could see in GP for why HTML was annoying. (Not to say GP doesn't have a right to be annoyed, I just think that particular reason is unique.)
Citations:
"HTML Email: Whenever Possible, Turn It Off!" https://subversion.american.edu/aisaac/notes/htmlmail.htm
https://phishingtackle.com/articles/phishing-emails-with-htm...
Even better: it remains totally readable in its raw unrendered form. So you're not really forcing anyone else to adopt your syntax, just... nudging.
It also renders incoming text/markdown emails in a HTML-like way using WebKit, rather than showing the raw markdown data.
Oh, so that is what is happening ?
When I see these extremely long URLs I know, of course, that someone is being clueless and sloppy and I know, of course, that whatever they are embedding could be hashed or compressed to 64 (or fewer) characters ...
But you are saying that what I am witnessing is the entire state of the transaction is being passed in the URL ?
I guess I thought that they were passing multiple third party tracking strings all in the same URL and that different parts of the string were actually for different consumers of that data ...
My other annoyance is Mailchimp users sending emails that have the correct message in the HTML part but old or previous content in the plain-text part. That’s even worse than those who simply omit the plain-text part.
For example, my company sends me an email everyday telling me about company-sponsored social events. Often, the emails contain information they've already sent at least 5 times. Email is the wrong way to communicate this information. They should have a shared calendar or web page that lists this information. No email client UI can resolve poor information sharing practices.
I get way less physical mail than email.
People have to pay money to send me physical mail. It's not a lot of money, but it 99% of email spammers would not be able to afford to physical spam me.
If you read past it, he actually wrote "I don't want to have to filter my inbox".
I also agree with him. I never use email clients' software filtering "rules" or "smart folders" because that's extra digital housekeeping work I don't want to do.
Doesn't matter if the email client filtering UI is "user-friendly". I still don't want to mess with it.
Sometimes I wonder why the email client doesn't look more like Facebook with groups (=mailing lists) and posts/threads and DMs etc
Email should be "block" by default. If you want to send me an email, your email address/account should first request to be allowed to email me, and once I approve your emails can come through. If I ever get sick of you, I should be able to block you with a keystroke.
You can implement this flow. It makes a huge difference:
http://blog.nawaz.org/posts/2018/Sep/solving-my-email-proble...
At least everything sent to me via IM apps comes from a real person.
The benefit of email is its openness. I can organize it as I wish - I can't seem to do that with Teams (nor Slack, most likely). Can I copy a Slack message and put it into my personal channel? Can I tag it with a label, and then do a query to get all messages with a label? Can I make a TODO item in the TODO app of my choice and link to a message?
I do all this with email. It's even easy.
Also, Teams/Slack searching sucks. They're also resource hogs.
Agree on this - I'll reply to emails I got weeks ago when I finally get around to dealing with them. I've never responded to a chat message more than a day old (unless I've been offline for an extended period).
That is the intended goal.
In reality, if you read the article, your email goes into quarantine and if I really do want to read messages from your site, I simply whitelist the address with a keystroke.
If you didn't want to read them, you wouldn't have signed up. Your quarantine will be full (even more than "Spam"), and you won't know (necessarily) what the from address looks like.
There are many use cases beyond what you're stating. Often I need to sign up for a web site temporarily ("Sign up to get our free ebook!") ("You need to sign up to place an order") In those cases I simply ignore the emails.
If I sign up for a newsletter with the intention of reading it, I'll keep an eye out for it and whitelist it. It's not hard.
> Your quarantine will be full (even more than "Spam"), and you won't know (necessarily) what the from address looks like.
I've been using this system for 3-4 years now, and this so far has not been a problem. I still monitor the quarantine folder as I don't expect everyone to go through the hoops to get to me. It's just a much smaller burden than having it all show up in the inbox and I can check it at a different pace (e.g. once every few days).
And even if I somehow forget to whitelist your site, what's the worst that will happen? I won't get messages from your site. Of all my worries in this world, this just doesn't even register.
So, maybe email clients aren't the issue, people are the issue (like most problems).
Really? I tell everyone who emails me that emails are postcards written in granite. Anyone might be able to see them, forever, from now on.
I also tell them that I check my emails once a day. If something is really urgent, stand in front of me.
It sounds like you haven't tried an email client where filtering is ergonomic. I use mu / mu4e for filtering and reading emails. At my inbox, I press `s`, enter a search term, and instantly get matches. I can press `S` (capital s) to further refine the search with another term if the previous was too broad. Filtering is incredibly powerful and useful if it is presented in an accessible way in the client.
For personal and some business correspondence, sure, plain-text messages are fine. For transactional messages, structured metadata becomes more important. For anything from a brand, rich formatting helps convey information in a way that's consistent with the rest of the brand's digital presence -- which may not be important to him, but is important enough to enough other people that companies spend a lot of money to make it so, and many consumers appreciate it.
Dynamic elements, like calendar integrations, also have their place, and it feels like a lot of this stuff gets written off as cruft in his article, whereas it's not cruft to a lot of people.
If anything, I would like email to become even more advanced and fluid, rather than scaled back to fit in the little box he has crammed it into.
I think a good argument could be made for Email being a federated, open substrate to send and receive non-real-time messages but not many people who make that argument want to see rich messages even though it's technically an easily solvable problem (albeit hopefully not the way MIME has done it today.)
Yeah, ok. You lost me there. Technology should exist to enable people, not some marketing asshole that thinks a button would look significantly better five pixels to the left.
If I go to the Washington Post website, it obviously has a distinctive style that is different from other newspapers. If I download a Washington Post mobile app, it's got that same distinctive style.
Why should the email experience be inconsistent with the style of those other digital applications?
What might seem like a silly, arbitrary "5 pixels to the left" style choice to you can be extremely useful in helping email users distinguish between a trusted brand, like a newspaper they subscribe to, and a knock-off or spam message. When plain text is the only cue, that's somewhat harder to do.
I sure do -- if I get an email that has a ton of money spent on branding, it's a useful signal that the email is unimportant, and can be ignored.
Maybe this has been tried and it's shit. I dunno, but I like the sound of it. I think it might be a good way to cut through the noise of the inbox. When I get snail mail I will quickly sort by sender (then read the tedious shite first :-) ).
I should try and write it for myself.
https://addons.thunderbird.net/en-US/thunderbird/addon/gathe...
Only issue: Delta Chat doesn't allow to change the subject, so your conversation with someone is going to be a looooong unique thread.
I am myself thinking about doing something closer to what zulip does, with subjects as "channels". Yet another side project.
I have a few filters set up to send annoying things to spam or a dedicated folder (alas, dear JIRA, I have never wanted to read one of your notifications). But my personal account works perfectly without any kind of filters or folders at all. I even use my protonmail accounts through the protonmail app and those work fine.
Is there something wrong with me? Am _I_ the one using email wrong? But it works well for me, and I seem consistently better at responding to messages, so... I'm mostly just confused. I use read/unread as a means of triaging "email I have to deal with" and "email I've already dealt with", but that's basically my only system.
Seriously, can someone explain this problem? In my eyes, email and RSS are pretty much the only internet protocols that have JUST WORKED for 20-30 years, my entire life. Everything else has been infected by adware and spyware and garbage. Maybe they're stagnant... or maybe they're just mature?
The default outlook app is terrible. It keeps hiding important emails from me and putting unimportant ones front and center. It's bad enough I use thunderbird exclusively to manage those mail boxes and read emails only on the desktop/laptop.
I personally find Gmail is much worse at hiding things. I try to be responsive but for whatever reason the way they handle threading tends to cause me not just to neglect to read, but to not know that there is something there.
I think the difference is Outlook shows all of the emails (from all folders) in a thread in a way that makes sense. Google randomly chooses a point in the middle of the list to just stop showing a bunch of emails and you have to manually click to see.
I constantly hear that gmail is better but I just can’t see it. Not in a matter of taste way, but like if people said they preferred being stabbed in the face repeatedly with a dull knife to eating their favorite food. I just can’t understand or empathize and I wish I did. It is kind of lonely being one of the few who not just likes email, but likes the Outlook approach to email.
Please read the post before you reply to it. It's only a few lines.
I think fundamentally the problem is that email works great if you aren't the subject of a random influx. If you create an address and never tell anyone except a handful of good sites, you're okay! If your address is everywhere, ends up in a data breach, or ends up on a marketing list for "important business people / decision makers to try to pitch products to" then you're in for a much different experience.
Why not just use filters? It's truly random who sends what when. The only email provider that I truly appreciate is HEY, which has deny-by-default email. You explicitly allow people to contact you, which is a different and very nice approach. It has other problems, though, which make it hard for me to suggest it as a solution.
From memories long ago of using Outlook and Thunderbird I think I can see where people get a hate for e-mail clients. I don't remember either of those being particularly good clients. They've likely changed over the years and could be better but I have no desire to drop Apple Mail.
That said, some e-mail clients are worse than others. Outlook for Mac is the worst client I've used in years. It doesn't even use Mac's notification system.
The biggest complain I have is that it can’t open Windows EML files that some people forward as attachments. I have to go into the web version to see those. Just a weird miss there.
Using both Outlook and Mail on macOS, strongly prefer the latter, but our IT only allows Outlook for corporate emails :(
- spam spam spam of the utterly firehose type
- spam spam spam of the corporate "unsubscribe in these easy 10 steps"
- attachment viruses (sometimes without you opening it!)
- even conversation organization is inferior to searchable chat where it's just a history stream
- email addresses obscure the users, chat apps are far better at this
- email addresses are a PITA in general
- no indication of being online
- emoticons are still a bit iffy, certainly worse than chat
- smartphone experience is far worse (could be bad clients... but...)
- legally it's a paper trail, chat is... not?
- attachments are not as smooth as chat, although it's a lot better than it used to be (drag n drop to browsers/clients are a LOT better)
- chat clients can support "undeliver" a bit more easily
That said, email is:
- open standard
- ubiquitous
Email seems fundamentally broken because of lack of regulation, just like the POTS (plain old telephone) system is utterly overridden.
And it would really really be nice if governments would make official email addresses for citizens for official communication and delivery. Or some means for me making money from incoming spam by charging a delivery fee.
The fact there are so many email campaign startups still to this day is depressing. There is zero chance they aren't effectively keeping email unusable. So I guess that's another annoying aspect of email: it will always be attacked by corporations, ceaselessly.
At least chat apps have corporate defenders (while they make you the product) but life is about choosing among non-ideal options.
> - chat clients can support "undeliver" a bit more easily
Features, not problems.
> - email addresses obscure the users, chat apps are far better at this
What? Funnily enough, my XMPP ID and main E-Mail happen to be exactly the same.
> - even conversation organization is inferior to searchable chat where it's just a history stream
That is the only one out of the list I actually agree with, though I think that could be fixed by clients.
Of course it would be swamped with spam, just like the snail mail is. Which is an absolute travesty.
Snail mail is not swamped by spam everywhere BTW - that is just a regulation issue. The difference with E-Mail is that you can cheaply send them internationally (so from outside any regulation you control) but even then I think the spam problem is overblown.
I have > 5 domains on my mailserver, all with wildcard email going to my inbox and two addresses publicly on my website and in numerous git repositories and bug trackers. I do not have any server side spam filter except a manual subject regexp to filter reject the most lazy spam at submission time. Even that only means about 40-50 trashed mails per day (most of which are moved there automatically by Thunderbird's spam filter), which includes legit mail that I don't want to keep like notifications that I have subscribed to. It takes about no time to double check the subjects to look for false positives. Either your definition of firehose is vastly different from mine or you somehow get vastly more spam than me.
Perhaps one factor might be that I don't have notifications for new mails at all since I check often enough and anyone who deserves my immediate attention has my phone number and/or jabber ID.
> spam spam spam of the corporate "unsubscribe in these easy 10 steps"
These are not a problem since they will keep using the same sender address. Reject at submission if you run the server, filter automatically to trash otherwise. Most will eventually get the hint if you never load their tracking pixels. If you want, report them to their host/mail provider. Corporate spam is only annoying if you do nothing at all about it.
> attachment viruses (sometimes without you opening it!)
Meh, the web has the same "problem".
> email addresses obscure the users, chat apps are far better at this
Good. Central identities suck.
> email addresses are a PITA in general
How so? They are globally unique identifies that you can almost completely customize and therefor easily rememberable. They can be as short as 6 characters including the @ and . for the domain (if you have too much money).
> emoticons are still a bit iffy, certainly worse than chat
What more than unicode + embedded images do you need?
> legally it's a paper trail, chat is... not?
Really depends on the server(s) in both cases.
> chat clients can support "undeliver" a bit more easily
Not having that is a feature. You can do delayed delivery and then cancel that if you are prone to make mistakes but once someone has your message why should you be able to pretend that you never sent it. For all you know they made a screenshot anyway. And if you meen the paper trail then you can bet that most chat networks don't actually delete the message from the database.
3, how many emails do you get? I averaged 60 emails per day in 2021, or probably 80-90 work emails per work day. More than half don't need to be read, but even spending 30 seconds per email would be a problem. Many people probably get a lot more.
Then Google sunsetted it, and folded some of the best features from it into Gmail.
Heads up: you don't fix an overly-complex application by adding the features from a very simple application to it.
it kills me there is no spiritual successor. i’ve stripped down mac os mail.app to more or less work like that, but it’s not quite the same.
the hey.com client gets a lot of things right imo, but ive had the same gmail account for the past 17-18 years—and there's just no way im going to switch over to a hey.com address that requires that i keep paying for it or have it be deleted.
They sent an email this week to all subscribers titled: "NEW in HEY: Send emails via Gmail"
I confirmed this works.
I was only receiving my Gmail emails before.
Now, when I reply I can select my hey.com or my gmail.com domain to send.
Hey gets most of it right. I just wish they bundled emails automatically (similar to how Inbox did)
But the nightmare that is IMAP has prevented me from ever succeeding in cleanly integrating the two. In fact, the general experience of using Microsoft and Google products together is quite frustrating. I get that they are competitors, but not acknowledging the multi-platform reality of modern work and forcing me to suffer because you can't be healthy adversaries, is really ridiculous and I resent both companies for their user-hostile practices.
Looking at you too, Apple.
It has it's own quirks, but you don't have the Google IMAP weirdness.
Too many security holes, discovered and undiscovered with JavaScript, not to mention JMTP.
Better yet,
Hashing the local part of the email address and retrofitting mail clients to do the mapping and rejection is the best way to delete unwanted and unsolicited emails.
Couple that with new decentralized lookup of sender’s PKI (as well as DKIM).
That should add years/decades to SMTP viability and usability.
The exploits writers would like to politely disagree. /s
There is no "JavaScript" in JMAP in the sense that it's supported by the protocol, and the specification explicitly warns against email clients interpreting JavaScript.
Potential and actual vulnerabilities explodes, like the chronic problems of Microsoft Macros.
I mostly use Apple Mail, which is acceptable, if not great. I guess I need to look at Thunderbird (which I haven't looked at since I've been using a Mac) and, maybe, Vivaldi.
Anyhow, I am so happy I recently took the time to set up thunderbird for my gsuite account at work. I've been using thunderbird for a long time privately and the UX is just so much better than gmail, it really improved my quality of life during work hours.
Maybe if someone standardised such an extension they'd add support. Considering how ossified email is, they rightfully have little interest to do it alone.
AWS does industrial espionage, Google probably does too... Not that the encroaching reliance on Microsoft is much smarter...
Google is desperate to find a revenue tent-pole that even approaches the value of ads, and they've bet heavily on that tent-pole being Cloud. Any short-term gains they could acquire from cracking open a user's email would be dwarfed by the long-term losses from ruining their reputation as a reliable keeper of secrets, and they need that reputation to trade in the Cloud space at all.
There are many projects that start solving "Inbox" before they get in to the abyss that is calendar management and fall flat.
They all have the very similar properties. Sender / source, subject, body, attachments, etc.
And I want to make it easy to tag / organize them. Maybe a tab for each type + tags within each. Search across all (since too often I forget the medium of a particular msg)
Finally, I don't want the provider of this service / client reading the content and generally probing the sphincter of my privacy.
* Unified client for Email, SMS, RSS, notifications
* Easy to tag / organize mail.
* Service provider cannot read content
* https://developer.thunderbird.net/planning/roadmap
* Firefox Sync (Expected Delivery: Q4 2022)
* Unified Toolbar (Expected Delivery: Q4 2022)
* App Menu (Expected Delivery: Q3 2022)
* Mail Tab Redesign (Expected Delivery: Q4 2022 / Q1 2023)
* Link Preview Card Improvements (Expected Delivery: Q4 2022)
* Account Setup Hub (Expected Delivery: Q4 2022)
* Customizable Shortcuts (Expected Delivery: Q4 2022)
* Calendar UI (Expected Delivery: Q1 2023)
Lack of syncing read/unread state is what stops me from using Thunderbird for RSS currently, but this would change it to my go-to app for most things.
Email hosted by a 3rd party (like migadu or purelymail) then moved my cell number over to voip.ms, which sends all texts and voicemails to me via email, where I can now respond to texts via my email client. Then I use feedmail to have all my rss and social feeds email the full text and images to me in either a digest or when they are published.
I have to say I've been loving it. I'm currently setting up notmuch and alot as my mail indexer/sorter and commandline viewer, too.
Today, most chat protocols have the same flaw as Skype: hostility towards third party clients.
I use lynx for html formatting, which works, except with long confirmation link, for this I use urlscan[1] which let me browse and open links.
I don't think email must be loved or hated, it's not black and white, it is an old protocol with lots of problems, but it's also the only working federated protocol (and I do operate my own email server with 0 issues, google/ms never rejected me) which is an important freedom.
I agree that many client have bad UX, but many have nice UX, and you are free to use what you want, even if you have a gmail account.
Even if you're going to discount HTTP, DNS, and IRC for failing to meet various criteria from some definition of "federated", I think we mustn't overlook Matrix here.
Sure, you can claim that email is the most popular working federated protocol, or the oldest, or the best, and you could make some weird restriction like "only popular federated store-and-forward protocol", but I'm not sure if that's a helpful distinction.
The rest of what you say makes perfect sense though, thank you.
I do agree with matrix, but it still has a lot to improve before I would consider it working. I tried multiple time to get non technical users on it but it is too hard for them. And it is not a client problem but more an account problem.
That's interesting, thank you. For what it's worth, it looks like Matrix is going to become much more user-friendly in the coming months[0], and it will be worth taking another look at this "account problem" once they support Open ID Connect (which is also mentioned in that blog post, and has a dedicated progress page[1]).
[0] https://matrix.org/blog/2022/08/15/the-matrix-summer-special...
Instead I did the second best thing and came up with some user styles to make one of the better hosted E-Mail clients, IO.OX (B2B software used by mailbox.org and Strato), a bit more bearable and almost even comfortable: https://gist.github.com/solarkraft/6afcfff8d5283cefad40695c9...
Webmail is good enough, but PWA implementation across operating systems is terrible as well. I keep Fastmail pinned in a browser tab, and let's hope I don't close the browser.
I hear CLI email clients are great, but the latest startup newsletter didn't get the memo and I keep receiving HTML emails with images, and I don't want to live in the terminal either.
It literally was abandonware for several years.
It was only recently resurrected by 1-2 devs a few years ago and they’ve had to rebuild the community, funding and contributor support.
The fact that Thunderbird worked perfectly well even while being abandonware is a testament to Thunderbird and email.
I think the last part they really need to get completed is separation from the Firefox code. We’re already seeing accelerating delivery of features which should hopefully improve.
I'm going to experiment recording the screen while I type to confirm or deny this.
I suggest using a calendar.
Now that it's ended once again some of my extensions have stopped functioning.
I do have to agree tho. They force-upgraded from Enigmail to the built-in PGP support which ended up broken for me. Since no one uses PGP mail I haven't bothered looking for a fix...
What about KMail/Kontact? Evolution? Sylpheed Claws? The Client of the Vivaldi(?) Browser? Not to forgotten all the commercial clients. Are they all dead or trash?
> a slow-moving almost abandonware monolith (have a look at its extension store. It's a ghost town)
To be fair, Thunderbird has a complicated history. The unloved child of Mozilla, survived far too long on it's own, until it got love again, at the time when the parent moved away from XUL, giving the future of Thunderbird-extensions a timelimit. That it's still surviving on high levels is more of a miracle.
You can be logged into Fastmail from several devices simultaneously. And I often have several Fastmail tabs open at one time. No problem at all.
The only thing better than Fastmail webmail is the Fastmail app for iOS.
My advice to anybody considering writing an email client would be .. don't. The amount of broken MIME things you'll have to deal with, strong opinions on UI, and similar things will make you go crazy.
I used to use mutt, then my own client. These days there are a few console-based clients that are new such as aerc, but even so writing the basics is easy, but coping with real mail is way harder than you'd expect
Would it make more sense to first build a bunch of libs, to create a common ground, onto which people could more easily build their customized clients?
https://www.youtube.com/watch?v=4s9IjkMAmns
Email itself is a very weird quirk filled system. If you want to read about the insanity behind some of the protocols watch that talk. That's why things like JMAP are being developed.
Publishers will respond to criticism like this by claiming that economic realities force them to avoid linking outside the site and to use obtrusive advertising and self-promotion. But there are plenty of counterexamples: LWN, for example, links extensively in every article to destinations all over the web and uses none of these user-hostile techniques—and their content is varied and at a consistently high level.
Definitely Thunderbird could be better than it is. But it's definitely better than what it's replacing, at least for my use.
I migrated from Outlook to Gmail, and I found that I could process 2-4X the amount of emails as I could on Outlook. The key feature for me was the vi-key bindings in Gmail.
MUAs on contrary suck because people have never touched the power of desktops and so they shift blindly and acritically toward webmails for the sake of few giants and as a result most MUAs are stuck in the late '90s at best. Modern ones are just small projects by very small community (like notmuch, mu), too small and geeky to develop a full automation to give something working out-of-the-box for most users.
Another problem is that people still fail to understand their assets. They understand something physical they own, like cash money in their pockets, but they fail with digital assets, so most people fails to understand the value of their mails, from address/domain (like a personal one vs some from GAFAM&alike) to messages and so fails to comprehend why having local mails is important...
We need, for the sake of the society, to improve people knowledge/culture about the tools they need in current daily life, otherwise even a modern MUA will simply be a big effort of few with not much future.
I think quite a few MUAs could absolutely be rescued from their shadow death, if funded properly (and if they're capable of being funded). It's just that I personally haven't seen a strong candidate yet. I don't like any of them, they are irritating. Aerc is promising, but CLI is simply not for everyone. Then Thunderbird was on life support for a while, maybe if it gains some speed again? I'm not sure.
So lack of support from users is one side of the coin. But the other side, developers and companies doing email, I don't know if that can be fixed. Sidelined maybe. There's just an immense amount of feet-dragging and archaisms in the ecosystem. "We can't because others don't" - everyone. Can't enforce TLS, can't enforce SPF, can't enforce basically any standards that would improve the quality of the ecosystem. When was the last email-related flag day?
Enough of that rant, it's just a bit frustrating. Forced to use with no visible QoL improvements.
- search based, entirely
- tags, like GMail labels NOT folders, while they are equally integrated in search (just folder: instead of tag:)
The issue:
- does not embed ANYTHING to fetch your mails, so you need something else to do so, like OfflineIMAP/mbsync or fetchmail etc
- does not touch files so you need wrappers to delete/refile etc them
Why? Because no one have felt the need to integrate to help new users...
Similarly no modern UI, there is a semi-abandoned WebUI, Astroid a webkit/GTk GUI, but almost no one develop them...
Still, love Hey. Expensive, but so good.
The entire world still runs on DNS; as an end-user you can now use DNS-over-HTTPS and that's nice, but that's mostly a frontend for DNS, which as a whole hasn't really been "upgraded". Upgrading SMTP to something new would require upgrading all the world's email servers, otherwise mail.server1.com can't communicate with mail.server2.com. This will probably happen at the same speed as IPv6.
Email identity is handled de facto by a web of trust anchored by the big domains with no possibility of creating a new trust anchor. You're either managed by Google, Microsoft, or Apple and inherit their trust or you play endless games to not get your mails blocked by default. It's a sad world and didn't need to be this way, but there's no real urge to fix things because the only people who are clamoring to fix email are people who want to encourage folks to use niche experiences like mutt and PRs by mail while the incumbents like Google have no incentive to adopt decentralized trust.
That won't stop anyone from creating a new email address (or mail server) that sends out spam though.
Even this REQUIRETLS that you mention that I didn't know about before looks iffy. If the problem is that upgrading all the world's email servers is too onerous, that still would pretty much have to happen here to support the new smtp extension. DNSSEC for the MX record or this MTA-STS record. It would require each hop in the path to be equally strict in implementing REQUIRETLS unless you want to randomly drop that assurance somewhere in the middle of the route. If all the servers have to be updated to do this, is it really that much more difficult to just switch to a new protocol entirely to be secure by default?
Not to mention that as a store and forward protocol, any server hop along the way may store or copy the message at rest in plaintext. If DKIM isn't used to checksum the message, it can be modified too unless there's some mechanism here for that that I'm missing.
If every email server needs an infinity gauntlet full of plugins and extensions and DNS records to just have some assurance of the sender's or recipient's validity, how is that really better than just making something new?
It's just not made to be a secure protocol. Someone please correct me if I'm misreading the RFC, but can we please, please let smtp die some day?
The 80:20 solution here might be for the big email providers to declare a flag day (maybe with a 2 year countdown) saying that any email server they connect to after that date has to support TLS, or they will delay the processing of emails to/from that server by 5 minutes, doubling every 6 months.
Also, such servers will be named and shamed in their webmail interfaces, so users get a nasty red warning whenever you try to send an email to an affected address or receive one from it. I bet the problem would actually be 99% solved before the flag day even arrived, and most of the remaining 1% would be spam anyway.
By that standard all of https and ssh are insecure too...
With ssh it is trust on first use by default, so you kind of have a point with that, but:
1. Ssh then remembers that host key and alerts if it changes to protect against MITM of future connections, whereas smtp over TLS just... doesn't check as far as I'm aware.
2. Ssh implemented certificates a while back using an ssh certificate authority, and thus can work more like https where host key signatures are pre-trusted, or can even issue temporary credentials through something like Vault.
These things are not the same.
That's also what properly configured SMTP over TLS does. Maybe some clients don't verify the certificate, but that's on the clients and not the protocol.
The additional daemon that it looks like postfix requires to support this new standard, postfix-mta-sts-resolver, had its 1.0.0 tagged version release in Jun 13, 2020. This does not and would not represent the vast majority of extant deployed smtp over TLS configurations out there.
This right here is still in the README for postfix, one of the most popular MTAs in use:
>Despite the potential for eliminating "man-in-the-middle" and other attacks, mandatory certificate trust chain and subject name verification is not viable as a default Internet mail delivery policy. Some MX hosts do not support TLS at all, and a significant portion of TLS-enabled MTAs use self-signed certificates, or certificates that are signed by a private Certification Authority. On a machine that delivers mail to the Internet, you should not configure mandatory server certificate verification as a default policy.
That's a very load bearing "properly" in your sentence and I wonder just what you're referencing.
Edit: and another good writeup. https://lwn.net/Articles/866481/
You're confusing a lot of things that are related but actually quite distinct. That DigitalOcean article talks about STARTTLS, but that's something different than SMTP over TLS. I haven't worked that much with email in the last few years so haven't looked at MTA-STS in detail, but it just seems similar to setting a "always require a TLS connection"; that new Postfix service just looks up the DNS records and such; it's not required for TLS functionality.
That aside, an active attacker can also trivially force a downgrade.
Only with the introduction of MTA-STS, connections between MTA-MTA are secure. That's supported by, like, few major players - I guess by volume a fine percentage, but by total count, abysmal.
MTA-STS between MTA's does help, but IMHO MTA-MTA is not the biggest issue.
Better than the HTTP mess where all URLs had to change until people realized that that didn't solve it anyway and had to bolt on HSTS and HSTS preload lists - we just need to add those for SMTP and optional encryption is no longer an issue.
> This is the first step in improving your productivity—establishing a software workflow that conforms to your brain’s specific contours.
Well, I don't think any email client will solve my email problems. I forward email messages into my project management apps and deal with them there. I've never found email clients to be particularly good at managing projects.
In theory if one client sucks you can change client. Not so if your organization throws hissy fits unless you use "web outlook or else because 2FA sth sth".
So on my slow tiny laptop with a shitty connection, instead of using my lovely alpine client which would have been perfect for this laptop, I'm forced to choose between "zoom out until you can't see shit" vs "zoom in until the menu leaves no space for actual email" mode.
When the best vendors out there proudly advertise multiple whole integer seconds in average latency in the best case (https://postmarkapp.com/why), I can only assume there's a lot of room for improvement for the protocol itself, and it's not just an issue with clients.
Sending text between servers on the internet shouldn't take this long in 2022.
(And holy crap what's with Apple's 99s latency?)
Really surprising to see an article about email clients seemingly ignoring the fact that people have multiple devices. You can set your client however you like, sure, but for most people that's useless if it doesn't work the way you like consistently.
E.g. if my labels show up as clunky folder-ish things, no thank you.
The fact that I am using Gmail today will also be a problem, unless Gmail now uses those tags instead of folders to report its labels.
Joke aside, a lot of the pain from email seem to come from its users. I have to deal with a lot of people who refuse to reply to the list, add their reply inside of the quoted previous message (not interleaved - I mean inside the blockquote), reply to old unrelated threads with a new question, fail to use the subject field ("question", "inquiry", "please help"), have a questionable sender identity (From: "work account (new) <ad22@example.org>" - whose work account?).
I am not sure this can easily be fixed by improving either the protocol or user interface.
Now you have to download and run massive resource hogging apps like Team and Slack to simply communicate on 2 protocols.
e-mail is here to stay.
Nobody is saying email is going anywhere.
This is a good point and makes me wonder whether e.g. Matrix should incorporate something like a “prefers async” field that could be used by clients to treat messages more like mail.
And before that it was Snapchat! Met some young people who wanted to keep in touch with me a few years ago and had this funny conversation about email after me saying I didn't have Snapchat or Facebook or Instagram or WhatsApp. Oh, you can text me with SMS (that still works!) or email me!
I feel like Google/MS cover the bulk of recipients, the main barriers to running your own MTA
Just watch me! Here's what I imagine: These ~three major organizations all get together and announce that from now on, if you register a new domain with an MX record, you have to also put up a bond which can be slashed if they detect you sending spam from your domain.
Okay, there are obviously problems with this, but to address the main ones:
* All existing domains are grandfathered in, so this system only harms businesses that don't exist yet (and thus aren't around to complain)
* The cabal could instead delegate the bond-slashing power to some group of 5 or 9 guardians of the internet, who could be voted on each year by the ITU, with one vote per country
* This would require all domains to support DKIM signing, so that any evidence of spamming could be cryptographically verified, and let's mandate TLS while we're at it
* To make this system truly global, decentralized, and transparent, it will probably have to be implemented using a distributed ledger, which will also prevent a dependency on any specific national currency or banking networks
A personal friend runs MXRoute and they could go on, and on, and on about how maintaining delivery for them is a very expensive venture -- and I promise you they're doing these 'very basics'
At a minimum you'll need several outbound systems with queuing that leverages them. IP reputation is a full time affair
The large players really aren't doing anything special. It's just frequency bias, because you want to deliver to them.
It's also a full-time affair only if you're trying to deliver content people don't want. Yes it takes some effort in all cases because you can't just go on and start blasting, but it's not a full-time effort with those providers.
Want to send to outlook? Better pony up for a whole /24 or they will drop all your mail from time to time because of a bad neighbor that you have no control over.
That is the kind of policies they are setting.
I think you misinterpreted my sentence in one dimension, it's not that they don't require things, it's that everyone does. Build reputation, pick a better neighborhood, you'll be fine.
It's not Google's fault, it's just the vast amounts of abuse they get that follows the exact pattern you did.
Postcards would be the equivalent of email if they didn’t require a stamp. And then your mailbox would be full of 5,000 postcards every day from people you don’t know. You can change the mailbox (client) all you want, but it will still be full of junk.
Using it as notification system? That is a big no to me.
Nothing else even comes close as far as being able to efficiently handle any volume of email I've ever received.
The article even alludes to one of the biggest of these problems: lack of encryption.
I don't see how my email client can fix persistent spam from random accounts that constantly change their domains.
That exactly describes Superhuman.
I do share the author’s hatred of webmail, however.
1) There are people you can't instruct. Aristotle made that observation 2000 years ago and it's still true today.
2) There are bad actors out there who profit from abusing the system.
I'd really like to see the flow control of email completely reversed, where the only people who can send me email are the addresses I have whitelisted. For example, instead of subscribing to an email list, I add the email list's email address to my whitelist. A notification of some sort is then automatically sent to the email list requesting access. The email list can then accept or decline. It would work exactly the same way between two people, getting receipts, etc. Either side could revoke access at any time. Then you could automatically have email from certain accounts go into certain folders, tags, etc.
Most companies do. And yet, the problem persists. See the points in my previous comment to understand why.
There is also likely some major pushback from people who already have their workflows set just so and any major deviation from "list of items" is going to break that.
It just works.
Write markdown, send html.
I just write and becomes nice stuff.
I want my email to show me a list of contacts a-z (no mru). I can filter this list by: have unread messages, are unknown, etc. Sort however I want. Group however I want, “smart” or manually. Omnisearch at the top. No “inbox”, “trash”, “sent”. I can select a contact just like an icq/wa/tg chat and see messages with it to the right. Maybe group messages by subj maybe not. Subj is not mandatory. The client should remove all of the top and bottom auto-citation, automatically extract and update contact info from signatures, remove them and show messages’ meat in bubbles, mine to the right, theirs to the left. Replies, and forwards have links to their “parent”. I can join two email addresses into one contact card, maybe create a subtree. The envelope encryption just works, because the server has a pubkey, either mine or autogenerated and published, or both. I can choose between local storage and cloud storage per device. I can send files >> 20mb, including archives, executables, js files. My known contacts can see if I received/read their message and vice versa. I can ban, mute, hide contacts. I can change/add my address, phone, position, name, etc and contacts will pick that easily, if I allow them see it at all.
So no, I don’t think I can make any email client to work the way I want.
If you think that all of this was inspired by modern messengers, nope. It’s just common sense. The fact is, messengers f’ing nailed it and email as a whole is mostly a slow and unreliable bloatware and doesn’t make much sense. If it were decently designed, there would be no whatsapp and other pure-messaging systems, because we’d already have one.
Nobody ever said "email sucks", email is the best medium for online communication, look at the countless of projects using mailing lists, you can easily go back in time and follow the discussions, it is so good
What sucks nowadays is spam, that's it
The wretched hive of scum and villainy that is my postfix quarantine begs to differ.
BTW, I only read the title.
It needs to die yesterday.
UX that works for async comms and real time comms can be “backed by” HTTP. One does not literally need the data model to conform to the presentation in mind.
“Email” view might be a good default. “Chat view” could be a toggle for when the group is online at the same time.
UX needs a rethink in general. What a designer finds trendy in the moment is user hostile. I want flexibility and customization at the presentation layer. Give me an API key and I’ll build my own UX in Docker containers, thanks.