[greengreengrass]

What's the point of this article? The most I got was "email is here to stay," followed by some discussion of an MCP server for their proprietary mail platform.

I particularly don't understand the constant fanfare around discussions of SPF/DKIM/DMARC. They're widely understood, published RFCs that have been around for at least 10-15 years, some of them longer. They're not obscure folk wisdom passed down through generations of sysadmins, yet I read so many documents and articles that make it sound like a proprietary trade secret that the authors of such articles are graciously revealing to the world.

[hliyan]

Agreed. I had some vague hope that this article made it to the HN hope page because someone was saying what needs to be said: that the future of email should be protocols over platforms, as it was in the past. Mail servers and mail clients.

[layer8]

> HN hope page

Nice. ;)

[aquariusDue]

Yeah, it's the same thing with self-hosting email. The technical side is documented and the tradeoffs are well known. It's the up front effort of migration, maintenance and mails landing in spam that gets people down and so on. Though once you get going it's supposed to become easier with time.

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.

[joshka]

Same - I plugged it into ChatGPT to check if I'd missed something contentful. I hadn't really. Not news, more survey of things that matter a bit. If you know those things already then this is just fluff. Nothing about the future, more just here's some things I like.

[jprjr_]

> They're widely understood

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.

[marysol5]

I wouldn't recommend for your own mental stability to look at /r/sysadmin when it comes to any sort of DNS or E-Mail issues. It really shows just how many bad systems administrators there are out there, who do not have a basic understanding of the systems they're using.

[jprjr_]

Just a few years ago, Atlassian required you to add an unnecessary include: record to your SPF record, and wouldn't use your domain for emails until they scanned your SPF record for that include. https://jira.atlassian.com/browse/AX-1477

You'd think companies generating as much email as Atlassian would know what they're doing.

[greengreengrass]

I was expecting someone to say this when I said "widely understood" without qualification.

Unfortunately, I do tend to agree that we can't fix stupid or the inability to read the RFCs. :-(

Thanks for providing a balanced view

[the_bear]

I was going to say the same thing. I only saw two things that are sort of about the future and not the past:

- 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?

[jprjr_]

Lookalike domains are a problem but in my opinion the bigger problem is when attackers figure out how to hijack a real domain.

For example, making a company named "there's a problem with your account call this number" on a site like PayPal and getting it to generate emails. They'll be from actual paypal.com and pass all authentication.

The other issue I'll often see is subdomain takeovers. Company makes a subdomain a CNAME to some other, external domain. Usually with the intention of hosting a webpage externally or whatever.

That other domain expires, but the CNAME doesn't. Somebody buys up the external domain, now they can publish SPF records and pass DMARC relaxed alignment on the organizational domain.

Now you can send all the emails you want with literally anything you'd like and the providers will say "yep, this passed DMARC."