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.
Agreed. My company uses Google Workspace, and I find the Gmail UI/UX absolutely unbearable in every way. I personally like Outlook (or rather what it used to be), and just wish for a clean Outlook for Gmail integration.
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.
As much as Google Workspace email feels convenient, they have sort of broken the IMAP with the label system. Syncing to conventional email clients without label feature just creates multiple copies of emails if they have been labeled with more than 1 label. It is frustrating sometimes
JavaScript, embedded, in email is, pejoratively, a bad idea by putting too much power into a transmitted email.
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.
sure, but that's not a feature a protocol should have. Because the protocol itself does not interact with it in any way. It's clients that process that javascript and execute it. The protocol is about moving 'emails' from one place to another. If you don't want javascript in your email and run your own email stack you can certainly filter out javascript blobs if you want. Or you can chose clients that disable or simply don't even know what javascript is.
While it is a bit late to close the door on JS usage within SMTP protocol, choices of client SMTP becomes paramount given its legacy stage of SMTP protocol.
again, the protocol should be dumb, its a way to move bytes. If there is js encoded in those bytes the rotocol will not and should not know or care. It's up to a client do decide what it wants to do with the bytes it receives.
I can also put JavaScript in a DNS TXT record; the protocol does nothing to stop that!
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.
Even a cursery look into my languages Wikipedia notes that IMAP compared to JMAP is statefull and verbose which causes problems with mobile clients. Can you do some research on your own?
You still send data through a TCP port, there is not much difference. Yes the protocol is in itself different, but that's expected - it's a different protocol after all.
We might need a protocol update, but many mail providers disabled IMAP for non-premium users already because they tried to force people to use shitty web apps.
I want to like Outlook, even on my Mac. But it doesn't handle quoting in replies the way I want it to, and I have several correspondents whose email chains get heavily into replies to replies.
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.
Jup. Even using thunderbird with a gmail account it's not great. Google insists on displaying my emails in multiple locations; among others, sent emails show up in the default inbox folder. WTF google?
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.
It's not that Google insists, it's that IMAP is antiquated and JMAP doesn't fix it either. Same letter in multiple "folders" should've been added to IMAP/JMAP aeons ago.
So why didn't google add it to IMAP when they added the feature to their mail system? There is no point in clients adding support for label-like folders if there is no server using that extension including the servers that do actually have labels. Gmail on the other hand is big enough that by now most non-Outlook clients would have picked up support.
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.
I don't really understand corporations using gmail. Don't you have fears that your company secrets get leaked? Perhaps that isn't an issue for software but I would not be so sure.
AWS does industrial espionage, Google probably does too... Not that the encroaching reliance on Microsoft is much smarter...
It's simply not a concern. Google weaponizing Gmail against competition would be the biggest self-own the company could possibly undertake. Overnight they'd lose the trust of corporations in general, which would cost them the enterprise business, the Cloud business, and a non-insignificant chunk of the ads business.
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.
Maybe. AWS very likely did spy on customers. They met with startups and let them use their infrastructure. Then they launched their own service. They also host data centers for UK spy agencies. Industrial espionage is one of the largest field for these agencies. Doesn't have to be a chip like the Chinese used. And you wouldn't know anyone spied on you.
I emphatically agree that E-Mail clients suck, to the point of wondering whether I should build an E-Mail client (my answer is "probably not").
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...
Email clients are absolutely terrible. If the best we can do is Thunderbird, a slow-moving almost abandonware monolith (have a look at its extension store. It's a ghost town), the situation is dire.
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 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've used Thunderbird for probably like 15 years now and this is the first time I'm hearing that it ever was abandonware. At no point during that time did I not like it much better than all alternatives. Pretty impressive given that it apparently wasn't being developed for several years.
Does the Thunderbird calendar work as good as outlook for you? Does calendar invites and other communication programs have good integration with Thunderbird?
At my last gig I used a paid extension called owl to sync with outlook, even though the company did not support anything other than MS Outlook or the Office 365 web interface. It was not expensive and worked terrifyingly, even syncing the company calendar and address books.
I swear this Note 10 changes words that are a few words back. I've had similar "corrections" ever since I changed to this device. It's too late to edit now.
I'm going to experiment recording the screen while I type to confirm or deny this.
Good to see that the new developers are continuing Mozilla's legacy.
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.
I wouldn’t say it is because it is a miracle, but because it still focuses on being an e-mail client. In Ubuntu kmail requires a database server and groupware.
I wrote a console-based modal email-client, which was written in 50% C++ and 50% Lua for the user-interface and all scripting.
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
> The amount of broken MIME things you'll have to deal with, strong opinions on UI, and similar things will make you go crazy.
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?
IM sucks hard. IM used to be great when it was based on open protocols so you could download Trillian on Windows or Adium on Mac and choose your client and communicate across a wide variety of protocols from the same context.
Now you have to download and run massive resource hogging apps like Team and Slack to simply communicate on 2 protocols.
Matrix protocol has over 60m publicly addressable accounts, and that's not even including all the EU gov, healthcare, military or emergency services. You can even bridge closed protocol apps like Messenger, WhatsApp, Discord et al to your own Matrix Synapse server and get it all in a single client. Works great. Been using it for over a year, can even send files back and forth to people still on Messenger.
There is just no single universally and actually used IM ecosystem and with the expression of unchecked capitalism Web 2.0 has become (see what happened to XMPP), there is no chance there will be one. Besides that the asynchronous nature of e-mail is a highly desirable feature for everyone who has actually things to do.
> the asynchronous nature of e-mail is a highly desirable feature
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.
This is an excellent idea - on a per-conversation granularity at least you could declare whether the intent of the conversation is sync or async, distinguishing IM from mail or forums.
IM doesn't work unless everyone you want to keep in touch with is also on IM. I have regular, multiple-times-a-week email correspondents who are never on IM. They don't even keep their phones on enough for texting. It's email or nuthin'.
> Have you tried talking to the TikTok generation? They don't do email.
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!
What I want is a unified (?) comms client. Email, SMS, RSS, notifications, etc. in a single dashboard.
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.
Modernizing the existing feature set, bringing in Firefox Sync to allow syncing settings, tags et al. Even got an Android client for Thunderbird coming down the pipe.
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.
Yes it does. Unified comms via Matrix, which bridges SMS, Facebook Messenger and much more into a single pane. RSS? Yup. Notifications via Matrix, SMS and RSS? Yup. Exactly what he's asking for, and they're modernizing it and adding sync too.
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.
Thunderbird once had a chat extension that worked great. It supported the big protocols - including Yahoo, AOL, XXMP, MS Messenger, and IRC I believe and a whole slew of lesser known protocols. I had to stop using it when the world embraced Skype and everyone moved there, probably around 2006 or so I think.
Today, most chat protocols have the same flaw as Skype: hostility towards third party clients.
Thunderbird still has chat-support out of the box. I use it for XMPP and IRC. And it also still supports Newsfeeds, but I would say it could be improved on that part.
Email does suck, at least HTML email. And that's not just because HTML was and still is the wrong markup tool for email.
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.
Forsaking HTML doesn't imply embracing 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.
HTML vs plain text is a distraction; it's not the 1970's anymore and saving a byte or two here and there just isn't the computing world we're living in. Not when images, video, or audio files regularly get attached to email.
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.
> HTML vs plain text is a distraction; it's not the 1970's anymore and saving a byte or two here and there just isn't the computing world we're living in. Not when images, video, or audio files regularly get attached to email.
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.
> Forsaking HTML doesn't imply embracing command line.
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.)
In my day job I use Thunderbird on a Mac, with HTML turned off. Because too many colleagues send Office attachments. So you don't need to use a command line to turn HTML off (but neither do you need to be afraid to use it CLI ;-)
Agreed wholeheartedly. I'd love to see email clients embrace markdown rendering (and sending) as an alternative to HTML. For stuff like links, headings, bulleted lists, tables, etc. in a single page, markdown is perfect. Emails rarely exceed the complication of a readme, and markdown works amazingly for those.
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 offers three markdown mail composition options: Markdown (text/markdown), Markdown as Plain Text (text/plain), Markdown as HTML (text/plain and text/html). Doesn't seem to be a way to have text/markdown and text/html though.
It also renders incoming text/markdown emails in a HTML-like way using WebKit, rather than showing the raw markdown data.
95+% of computer users who mention not wanting to use or see a command line are so utterly terrified by the command line "bogeyman" that they imagine command lines appearing in places they would actually never be, or be required.
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 ...
It's not clueless or sloppy. They are most likely using https://en.wikipedia.org/wiki/JSON_Web_Token which is a well-defined standard and extremely common in the authentication world because it makes a ton of sense. It lets your authentication server be mostly stateless instead of storing tons of sessions unnecessarily.
As a fellow mutt user, I have the same complaints. Sometimes, the confirmation link can be activated by opening the HTML mail in lynx or w3m but in many cases, using the confirmation requires that the browser runs Javascript so I ended up having to copy the link from the terminal emulator, reformat it (remove line breaks and plus symbols) and paste it into Firefox. :(
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.
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.
I liked the article. The author seems to have the same attitudes and preferences about software that I do. But, does Wired have a policy that forbids linking to anything that’s not another Wired article? The piece contains only two hyperlinks, both pointing to Wired. One of the main points of the Web is that it’s a web of information. Every piece of software he talks about has a web page, and plenty of good articles and tutorials about it; there are certainly other interesting articles talking about the issues the author talks about. Why does Wired hate the web?
Not to mention the auto-playing video stuffed between two paragraphs. I wanted to upvote the article for its message but I can’t in good faith recommend anyone visit this site with its current aggression.
Yeah, that was ridiculous. A random video that has nothing to do with the article. Contempt for the reader and for the author and the material.
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.
With uBlock Origin blocking (by default) the javascript that wired serves, I read the whole article and was only aware of an auto-play video even being present when I read your comment.
Good for us? (Yes, I too browse without scripting.) Their offense still exists and we should be careful not to shift blame and the burden of defense to users.
I'd love to use a non-web-based email client, but I do need it to sync between my devices, including labels, and search to be available over the entire corpus.
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.
I use mutt from my desktops and phone through ssh to my email server running IMAP. (Mutt supports labels.) This way there’s never an issue of synchronization.
Email does suck. It's an insecure mess that is impossible to secure by its very nature. All it takes is one small mistake and your email is sent in plaintext.
My work computer has a SSL cert from the employer installed allong with the other ones. I don't see any improvement from plaintext. If we need secrecy we need to use encryption.
I use Claws Mail since ..uh.. forever (it was called Sylpheed back then) and never felt the need to change. It's fast, and I mean really fast; I keep all my email since day one online so I can quickly search among all messages exchanged since 1997 (I migrated the earlier mailboxes from Windows/Eudora flawlessly) and find everything, including spam filled with vintage Windows malware or those watermarked Viagra/Cialis banners. It's tens of thousand messages and searches in indexed fields is next to instantaneous. If you think web based mail sucks and console clients are too much for non tech users, Claws Mail might be a middle ground worth of consideration.
I'm kind of surprised no one has mentioned "Hey!" the email service from the Basecamp folks. I haven't had an opportunity to try it, but the UI looks like something that could be replicated locally.
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.
The same here. I use it with the wife, and we even use it for her mother’s shop. Worked great, except for the need of having an smtp server for available to sent email from services ( calendar notification, error, printer message, nas update…)
I don’t see the point in debating protocols when “the suckiness” always comes down to UI/UX
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.
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
Plenty, but I'm not in the space to speak to specifics.
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
IP reputation is done by everyone doing email who aren't tiny, in both directions.
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.
Try to send a short and concise email to gmail, especially from a new alias. Instant spam folder. Fill the mail with AI-generated gibberish (or just whatever scam you want) and it's suddenly fine.
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.
You're surprised that by following the pattern of a dead-average spammer your letters got treated as spam? That was rhetorical, don't answer.
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.
smtp sucks hard though. Pretty much the only major protocol that never got upgraded (along DNS until DNS over https). Dysfunctional encryption (as in optional, easily downgradable), no assurance on the identity of the sender, bad interoperability (the likes of gmail sending directly to spam folder half of the domains).
This. SMTP was built upon FTP originally, and it's a protocol designed for ARPAnet, not Internet. SMTP is inherently the wrong protocol for the job. But it keeps working and is the gold standard for email communication and is dead simple to implement, so it keeps being used.
It's not quite that bad; you can use SMTP over TLS (without the downgradable STARTTLS, plus there's REQUIRETLS now), and there's been plenty of extensions over the years (like SMTPUTF8). Identity verification has been handled in another layer (the message itself); you could argue that's not the best place, but it is there. And gmail's problems are gmail's problems.
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.
Assuming you mean identity verification is handled with GPG keys, nobody actually uses that in practice. Even the people that use Usenet today mostly don't.
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.
Mostly meant SPF/DKIM to verify the sender is authorized to send emails for a particular domain. Verifying that "it is actually the person Karrot_Kream who wrote that email" is harder; but I don't think you can blame that on the SMTP protocol.
If you create a smtpv2 that can guarantee encryption (ok, who cares) but mostly that guarantees the origin of the email, then the gmails of this world should go softer on classifying those emails as spam, and it won’t take long before only spammers and some forgotten box in a closet are using the old smtp, then its death would be imminent.
What do you mean "guarantees the origin of the email" though? That it was you who sent it? That you're allowed to send emails from mymail@example.com? The latter has been solved for some time; the first one is harder, but solvable through GPG or S/MIME, but few seems to have any interest in implementing it.
That won't stop anyone from creating a new email address (or mail server) that sends out spam though.
TLS without the certificate verification is still vulnerable to MITM.
You get basically the same security level with gpg and plaintext email as you do from email over TLS if someone is trying to MITM.
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?
> 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?
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.
I'm not sure what you're getting at. Properly configured https verifies the certificate's CA signature. Now it's true that that's only as secure as the web of trust that is the certificate authority system, but that's a whole other ball of wax. Smtp with TLS just doesn't check, except perhaps this new REQUIRETLS if implemented with all that extra configuration. For most of the smtp TLS already in use out there, it doesn't care if it's a CA signed cert or a self-signed cert. It's not verifying anything about identity.
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.
> Properly configured https verifies the certificate's CA signature.
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.
Verification was not required as a matter of protocol until a new standard for MTA-STS was published in 2018. Without this new standard configured, as is going to be the case for most organizations out there not on the bleeding edge, TLS over smtp has been opportunistic and not verified the certificates or strictly enforced verification.
https://www.digitalocean.com/community/tutorials/how-to-conf...
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.
You've been able to configure Postfix to verify TLS for ages; you don't need some new daemon for that. I've written plenty of email systems over the years and have always verified certificates (unless explicitly told not to by the user) and that works just fine.
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.
Okay, you configure Postfix to verify TLS. Validation fails, what will happen? What does the documentation say about that configuration option?
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.
> Dysfunctional encryption (as in optional, easily downgradable)
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.
Part of what makes it worse is that many of the pain points are such low hanging fruit.
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)
I've been using OWA for a while as my primary work email and it's nice. I probably pin too much shit, but it's overall a good app. And since MS is web tech obsessed, OWA will replace Outlook at some point in the future. Project Monarch / One Outlook is still super half baked and predictably an awful RAM hog compared to the native app, but the writing is on the wall.
I had an issue logging into my work account on the actual outlook application recently so I tried the web version in the interim and it really is a lot better. I am not saying it is a world-beater but when they couldn't figure out my issue, I just let the ticket close.
Still waiting for them to replace the desktop app on macOS with an Electron app. The fact that no mobile/desktop client for Outlook doesn't have the like feature like Outlook Web is frustrating.
Check out the Outlook web interface, it's so much better. They got the navigation delay down to 3-4 seconds! Also they have this safety feature where the delete button doesn't work unless you first archive and un-archive the message. The actual content view gets closer to a third of the screen space too, which is almost enough to load someone's 5 paragraph email signature. Now that's Enterprise Ready!
It's incorrect to assume that a Windows application will open the Find interface via the keyboard shortcut Ctrl+F. In Microsoft Word that shortcut opens the Navigation interface, and Find is now Advanced Find, which can be opened simply and intuitively via Ctrl+H - Alt+D.
Frequent revalidation training in the leverage of Microsoft products is something that would have helped your person avoid looking unprofessional.
> - remarkably unhelpful use of space in the inbox views,
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.
“ 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”
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:”
Im not sure I agree: sometimes it's easier to remember the names of your colleagues that were a part of a certain conversation. Especially if the sender is from outside your organisation, say a client, a journalist, a subcontractor.
I will say that it sucks just as a much from the developer front. I had to build some email templates for a project a few weeks ago and I was shocked how wired it was compared to regular webdev.
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?
I strongly disagree that the problem with email is clients. We simply get too much information sent to us via email. I don't want to have to filter my inbox--I want to receive just as much information that I need.
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.
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.
True, but I can automate throwing the email into the trash, I have to manually pickup the snail mail at least 3 times a week to keep the mailbox from overflowing. I have a sorting table right next to the trash can. Most days, it all goes into the trash.
>someone should really make an email client with user-friendly filters to let you sinkhole that junk into a folder you never look at
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.
Almost all clients have blacklists, instead of whitelists, which is the problem.
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:
I don't want to have to configure blacklists and whitelists. My current workflow which seems to be inline with the rest of the world is if the message is junk, send it to my email. If its important, send it to me via Teams/Slack.
At least everything sent to me via IM apps comes from a real person.
To each his/her own. I'm the opposite. Anything via IM is treated as fleeting, and if I don't get to it now it's forgotten. I'm not going to keep track of dozens of channels.
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.
> Anything via IM is treated as fleeting, and if I don't get to it now it's forgotten.
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).
So you sign up at my website for something. We send you an email. Your blocking system rejects it. I'm not going to send a suitably-formatted request to you.
The parent signed up to receive whatever it is that I am sending. But it will not arrive (fully) unless I do something (or they remember to add a From: address that they do not yet know).
> I'm not going to send a suitably-formatted request to you.
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 I really do want to read messages from your site
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.
> If you didn't want to read them, you wouldn't have signed up.
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.
Maybe the problem is that culturally, email is treated like face-to-face talking. We often talk to each other just to be pleasant. It wouldn't be weird for someone to remind you about a meeting if they saw you, or to ask if you're going to the company picnic. Actually, it would be weirder if they just posted it on the calendar and said nothing else.
So, maybe email clients aren't the issue, people are the issue (like most problems).
> I strongly disagree that the problem with email is clients. We simply get too much information sent to us via email. I don't want to have to filter my inbox--I want to receive just as much information that I need.
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.
> A stand-alone email client gives you the same advantages all native applications have over their web-based counterparts: speed, grace, and offline accessibility.
Approach to email suck, instead of async communication it is became information duplication and hoarding. I suspect it is come from usenet times. And of course enterprise, managers (and Microsoft) made it 100x worse.
There were attempts to make it sane - like Lotus Notes. Long gone and forgotten.
I am surprised that few commenters have criticized the tech-curmudgeon perspective that underlies most of the author's preferences. His rigid view of what email should consist of is not really mainstream.
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.
There's a large overlap between people that want to use email as a central part of their lives and people who think everything other than text is just unnecessary waste. It's not really a technical thing, but a cultural tie. Think suckless folks or the Gemini project people.
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.
If you feel that is a distinguishing factor between spam and corporate spam, you are quite simply wrong. The layout of an email means less than nothing for authenticating the source.
365 comments
[ 3.8 ms ] story [ 316 ms ] threadJoke 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.
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.
https://support.google.com/a/users/answer/171710?hl=en
https://jmap.io/software.html
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.
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?
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!
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.
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.
[1] https://github.com/42wim/matterbridge
[2] https://xkcd.com/1782/
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.
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.
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.
It needs to die yesterday.
https://claws-mail.org/downloads.php
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.
Still, love Hey. Expensive, but so good.
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.
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.
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.
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/
[3]: https://get.foundation/emails.html
There are many projects that start solving "Inbox" before they get in to the abyss that is calendar management and fall flat.
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.
That exactly describes Superhuman.
https://github.com/derek-zhou/liv
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.
The wretched hive of scum and villainy that is my postfix quarantine begs to differ.
Using it as notification system? That is a big no to me.