Thread by @lzsthw

I'm on a killing spree of BS technology giant companies force on us. For weeks I've been "cleaning up CSS" by simply using flexbox and CSS grids for layout. Today, I want to rant about DMARC, DKIM, and BIMI as my next BS standards topic:

I recently had Sendgrid shutdown my email for a week without telling me because one single "malicious email" apparently went through their servers, even though they couldn't prove it or provide any logs. I then tried SocketLabs, and they went down for a whole day for no reason.

That means I'm going to now try to do my own email hosting and comply with all the following standards as best I can:

1. SPF
2. DMARC
3. DKIM
4. BIMI .... whatever that is.

I'm using the tool mxtoolbox.com to help me diagnose the configuration.

MxToolBox has a very clunky UI, but it does actually work. It's pricey, but in theory if I get everything fixed then I don't have to keep paying them money unless I want their monitoring. What they do is fairly simple:

You add a CNAME record to one of their DMARC enforcement servers, they then collect all of the failure emails and report back to you what's failing. They also give you diagnostic tools with *real DNS* record changes to make, not suggestions. You copy-paste the SPF/TXT straight.

This one feature is huge because the #1 reason why all of these standards are so difficult to implement is it's impossible to find out what is failing, why it's failing, and how to fix it. I'd say the only reason SPF/DMARC aren't used is just debugging them is impossible.

What I couldn't understand though is why DMARC and DKIM exist at all of we have SPF. I tried *real hard* to find a legit reason that explained the security advantage and it's usually a tautology of "people get SPF wrong" or "SPF doesn't work with forwarding". What?

You see, debugging SPF is nearly impossible without something like what MXToolBox is doing. You need an email address where failures go and a way to report on them with what to set in the SPF. People get SPF wrong b/c GMail won't tell you how to fix it.

SPF is a simple TXT record in your DNS that basically says "the only IPs allowed to send email from X domain are Y, J, K". It's not technically that difficult.

DMARC though, is nearly the same thing with more requirements, so ... it doesn't solve the problem of "SPF too hard".

Not to mention, getting DKIM to work is also nearly impossible without a lot of debugging help. There's no way TWO more complicated solutions to SPF solves the """problem""" of "SPF is too hard". What's the real reason then?

That little thing "forwarding".

I read that at first to mean "I send an email to Mary and she forwards it to Joe? WAT? That doesn't require SPF check. It's from the other server as a forwarded MIME message with attachment or inline."

Hahaha, no no no silly dude, they mean GSuite handling your email for you.

You see, DMARC and DKIM make it so that that GSuite can do the email for your domain without Google having to also manage your DNS, and provides GSuite with vendor lock-in since the configuration is a pain and changing email providers can be devastating to delivery.

When they say "fowarding" they man that GSuite can take over your email, and using DKIM and DMARC, blast emails on a randomly supplied set of IPs that Goggle administers. Without this they would have to update your SPF/TXT record, and I suspect open them up to *you* spamming.

DMARC/DKIM seem to really only exist for two purposes:

1. It allows a hosting provider to masquerade as another domain and send their emails, without the other domain utilizing their resources.

2. Adds complexity that keeps out competitors and restricts small server setups.

For example, I have one postfix server that handles the email for one of my domains. If I set the SPF record to say only that server sends email, and GMail confirms this, then that should be the end. No need for anything else as to spoof that someone would have to hack DNS.

If you think "hacking DNS is easy", remember that DMARC also uses DNS, so it gives no security advantage over SPF.

SPF could also easily have added the "report abuse here" parts of DMARC and we'd then be done.

Buuuuuuut, Google and friends don't like this.

By adding *THREE* whole technical standards and *not* providing any diagnostic tools, you are very motivated to use a service that handles these for you. I was. It's nearly impossible to get all three right without some help. Here's an example about why:

All of my machines have IP4 and IP6 addresses. I setup my email servers to bind to the IP4 port, BUT, everyone who writes network software is a corporate tool, so they will randomly use both addresses to send. I now have to add 2 addresses per host to my SPF...oh but..wait..

IP6 machines randomly have two IP addresses or more. Link/Local, Link/Global, older machines list one, some name them differently. It's incredibly difficult to figure out what IP6 address postfix will use too. I was seeing all of them at random *after* I enabled mxtoolbox.

That's just a small problem with just IP addresses. Then throw in DNS issues, off-brand cryptography, attempting to sign email contents and headers which get modified in transit, and multiply by 3 ... oh 4 now that BIMI is a thing, and you get $$$$$ for email providers.

I'm going to bet you hard cash money that Google and friends had these solutions already written, then went in and just got the standards written to match their tech without sharing any of it. Hmmmm, this sounds familiar....

boingboing.net/2017/01/30/goo…

WebDRM has a similar story of Google and a few players already having DRM technology (Widevine), and writing a half-assed standard to force on everyone so that basically we all have to use 1 of 3 already working technologies.

So, I'm now working on implementing DKIM:

digitalocean.com/community/tuto…

But as I do this I'm totally thinking there needs to be a simple SPF/DMARC/DKIM manager/tester you can add to any email server. Think "spamassassin milter for DMARC".

In my fantasy, you'd do this:

1. Setup your mail server
2. Setup DMARC-DEBUG milter.
3. It grabs failed emails and generates reports for your web server.
4. You copy-paste and follow the report's advice until DMARC-DEBUG stops complaining.
5. It notifies you when things change.

Finally, what is BIMI? I think all you need to know is these companies are behind it, so it's all about grabbing more of your email dollars, and not about stopping the marketing email you irrationally hate while you happily scroll through Twitter/Facebook/Insta ads all day.