This will literally never happen. Email doesn't support the features that those messaging platforms need to have, such as recalling messages.

The security layers are also only on the sender part, not on the receiver part, which banks care a lot more about.

It's extremely difficult to accurately identify which emails have health info and which ones don't (even something like a person's name or IP address could count depending on the context) so they just default to sending everything through their message center. No amount of email security could change that.

As such, I tell anyone who sends me one to fuck off and send a real email.

And then also sends an e-mail, which sometimes I confuse and think is ANOTHER message, and log in again....

It has a "Download this message as a PDF" button, which just takes you to a web-browser wrapper....

I'm sure there's a sum of compliance reasons why this is not allowed, but it doesn't make any sense at all.

They have an MCP end-point, they want to market to both AI proponents and critics -- that's about what I learnt from scanning the article.

The thing is Fastmail can't speak with absolute authority about email because Fastmail is not email. It's subordinate to it.

You literally have a proton email address on your profile.

My 30 years of muscle memory using webmail is made useless by this "app" because some web developer somewhere wants to cosplay as a desktop app developer now.

It's not an oversight either. It's an intentional choice to not have a go-back-to-previous-page keyboard shortcut. A customer support person said they would add it as a "feature request". Gee, thanks.

Also there's a spectrum from Gmail to Fastmail to AWS SES to Wireguard on a VPS that's tunneling to a server running at home. And when the people from both extremes of the spectrum interact they look at each other as if they're from other planets.

It's the same for Auth stuff I believe, almost a decade of generic advice like "don't roll your own auth" has lead some people to file it into a tidy corner of their mind labelled "DON'T TOUCH" so most people end up gawking and staring in awe when someone does so and lose all nuance along the way. To be clear I'm advocating for learning how stuff works and playing around with it (time permitting) instead of simply delegating it to the technical equivalent of Higher Powers in perpetuity.

- BIMI (I hadn't heard of that before) which seems like a very minor thing to be calling "the future of email"

- AI might be easier to trick that humans

On that second point, here's the exact text:

> A person reading a suspicious email might notice that the sender’s domain has an extra character, or that something about the request feels off. An AI assistant scanning your inbox for items that need action may not slow down to check those things.

That seems wrong (AI should be better at this than the average human), but let's assume that assertion is correct. It then says "authentication is the safeguard that should stop it before it ever reaches your mailbox". Except then, a few paragraphs down, it says "A scammer with a convincing look-alike domain and a properly configured DMARC record will still pass sender authentication checks." Ok, so authentication isn't a solution to the stated problem at all (it does solve a different problem). And unless I'm missing something, no solution is proposed. No statement is made about what the future actually looks like.

Like you said, what is the point of this article?

I'll tell you right now, I've had multiple cases where I've had to quote parts of the RFCs to large companies because they were handling email authentication incorrectly.

They are wildly misunderstood. The moment I see "add this include: directive to your SPF record" in some marketing platform's integration documentation I know they're going to fuck something up.

To add-on, the really pro move is to not touch the client's SPF record at all. Use your own domain in the SMTP envelope and have SPF be valid for that. Just have the client establish DKIM records and use DKIM, and only DKIM, to pass DMARC.

If you insist on using the client domain in the envelope, make it a subdomain with MX records back to your infrastructure (so you can track bounces). That will pass relaxed alignment - or just use a subdomain in the from and now you're passing strict alignment as well.

Most companies have no idea how the envelope domain impacts bounces and frankly, doesn't care about tracking them.

A shockingly high number of companies have no idea of the concept of the envelope address.

Self hosting is hard (which is why I just use Fastmail now), but it's not because of that.

In time there will be a reckoning though. The geopolitical instability at the moment will see the end of the US dominant services used outside of the US so they will have to work out how to make a not small but balkanised email provider model work again.

Of all the stuff Gmail imposes on the rest of the world, requiring proper sender authentication was a good thing and we've helped thousands of senders set up proper authentication because of it.

Forcing the issue finally got rid of the ridiculous practice of ignoring SPF/DKIM failures and just setting the DMARC record to p=none.

None of this changes the fact that Gmail is a problem for so many other reasons, but this specific imposed change was a net benefit for the entire email ecosystem.

I was an email admin for a university. In the past - each college ran their own email. Before DKIM, before SPF, you'd just have basically random servers on the internet sending email as (school).edu. Tons of random subdomains too. math.(school).edu and so on.

Email was eventually centralized but you'd have parts of the university still running their own things. Insisting they're special and can't be brought into the fold.

So, we had a lot of stuff out there just not passing authentication. A lot of spammers could just impersonate our domain.

We'd go to leadership and say "hey we should really get our act together" - but everything was working. Our emails were still getting out. Hard to justify spending the time, getting various higher-ups within departments to give up their things, and so on.

Unless you can get like, the president to back your initiative- universities are very decentralized and it becomes an issue of "do we have the political capital to spend here." The overall relationship between central IT and the various college-based IT departments was terrible, often bordering on combative.

Google and Yahoo made it so we could go to leadership and say "people will not get our emails if we don't get this straightened out" and it became a priority. When I left our DMARC reports were showing something like a 99% pass rate when it was previously like, 50.

So, I'm glad Google and Yahoo made that call, it gave us the kick in the pants we needed to get our own shit together. I am 100% certain we were not the only org like this.

Plus for a small host - where you're just running a single mail server or something - you just need a few things to pass DMARC.

A DMARC record, and an SPF record, and for your emails to pass SPF. You technically don't need to do DKIM signing (though I'd still recommend it because that survives automated forwarding).

Keep in mind that the baseline is that, when you send an email, it is encrypted from your computer to your email server, your email server to your recipients' email servers, and your recipients' email servers to their computers. The only people other than you and the recipients who can see it are the email servers involved in the middle, so the best you can get with encrypted emails is maybe cutting out some of the entities that have a critical role in the process (and which therefore can't entirely be cut out). In particular, encrypted email leaves all the email headers public, so it's not like the best case here is particularly private.

But encrypted email also breaks the ability to do any server-side processing of email, like server-side email filters (okay, not the hugest loss in the world). Or spam processing--no one's come up with a workable solution here, especially given the vast amount of spam that never hits an email folder (the things that get routed to your spam folder are the emails your spam filters aren't sure is spam). Users also expect the ability to log onto their email server's website and just read their email: such webmail is the dominant email client used, and even people like me who almost exclusively use email clients still end up using a webmail client from time-to-time. You can fix this by giving your email server your key... which puts them back on the list of people who can read your email again, oops, you've gained nothing over the status quo.

Worse still is the problem of key distribution. To send an email, you need to look up the recipients' keys... and the most practical approach to make that work at scale is probably to ask the mail server what its users' public keys are. The one entity that is guaranteed to be able to intercept literally every message to somebody, and thus is in prime position to offer its own key instead, strip the encryption, and re-encrypt it to the user without anybody else finding out. Alternative approaches like keyservers don't work: the PGP keyserver ecosystem collapsed several years ago when PGP encryption was of interest to fewer than a million users, far less scale than the billions of email users.

Encrypted email is a useless pipedream, and not because of the business models of email vendors, but because the architecture of email provides good-enough security today that makes improving on it very challenging without negating the supposed benefits of extra encryption.

The model literally can't function if emails are encrypted. They have to be unencrypted for all the ML to run for the inbox to actually be useable.

But that makes me think of Hashcash, that was developed to limit email spam via proof of work, but I don't think that has ever been used in practice: https://en.wikipedia.org/wiki/Hashcash (and of course wouldn't work for the proof of humanness you're talking about).

It's basically "you need to pass DMARC now" which has been true for 2 years.

It also goes into how authentication helps stop spoofed domains which yes, is true. But in my opinion the biggest problem isn't spoofed domains at all.

Attackers will figure out how to make your payment platform (PayPal, Stripe, etc) send out emails. They'll figure out what pieces of info make it into the generated emails, so they'll do things like set their company name to "there's a problem call this phone number." So next thing you know you're getting an email from PayPal that sounds urgent because they'll put that company name in the subject or body of the email.

These emails will be legit, from-the-actual-company, passes-all-authentication emails. DMARC can't catch that, and that's what I've been observing attackers do. They'll find a ticketing system or payment processor and get them to generate "authentic" emails.

I was sincerely hoping that Fastmail had something to deal with that problem.

Genuinely curious. Why is it posted and being upvoted here?

We will eventually be forced down this path though, be patient! Upfront key exchange in-person will be the only way left to prove comms are real. GPG is just one path but someone will come along and make it easy on organizational level.

Metadata is more valuable than message content for analysis. GPG solves that how?