SpamChannel: Spoofing emails from 2M domains and virtually becoming Satan [pdf]

Video of the talk: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=NwnT15q_PS8">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=NwnT15q_PS8</a><p>or here (video format didn&#x27;t work in firefox for me but VLC plays it): <a href="https:&#x2F;&#x2F;media.defcon.org&#x2F;DEF%20CON%2031&#x2F;DEF%20CON%2031%20video%20and%20slides&#x2F;DEF%20CON%2031%20-%20SpamChannel%20-%20Spoofing%20Emails%20From%202%20Million%20Domains%20and%20Virtually%20Becoming%20Satan%20-%20byt3bl33d3r.mp4" rel="nofollow noreferrer">https:&#x2F;&#x2F;media.defcon.org&#x2F;DEF%20CON%2031&#x2F;DEF%20CON%2031%20vid...</a>

SPF is broken in many more ways than described in this presentation. I work as an email hardening &#x2F; deliverability support engineer and our advice is always to focus on DKIM + DMARC, rather than SPF. You still need SPF for legacy reasons, but it should never be relied on for deliverability or anti-impersonation.<p>Slide 54 says that DKIM + DMARC does not help against this attack, but that is not completely true.<p>If (and only if) you have set up DKIM for all your delegated senders, then (and only then) can you safely enable a DMARC p=reject policy. Once you have reached that level, you can start opting out of SPF for third party senders, by using the &#x27;?&#x27; (neutral) modifier in SPF.<p>So this:<p><pre><code> v=spf1 include:relay.mailchannels.net ~all </code></pre> Becomes this:<p><pre><code> v=spf1 ?include:relay.mailchannels.net ~all </code></pre> This gives emails from MailChannels a neutral SPF stance with DMARC capable receivers, causing them to use DKIM instead. Old legacy email services should still accept neutral results as well.<p>Granted, it is not a perfect solution, but email will never be 100% reliable, or secure anyway.

We use cloudflare workers + mailchannels in production. Yikes.<p>We were already sorking on migrating away from cf workers to real servers, and now also we&#x27;ll also have to move away from mailchannels I guess.<p>Security risks aren&#x27;t worth the convenience.

&gt; <i>Display a banner on any email that doesn’t have a DKIM signature but comes from a domain that’s implemented DKIM (I’ve never seen this, I’m assuming possible?)</i><p>IIUC, it’s mostly <i>not</i> possible, because there is no sure way to know if a domain has “implemented DKIM”.<p>You can, in theory, do a DNS query for “_domainkey.example.com” and see if you get NXDOMAIN or NOERROR; the latter usually¹ means that there are subdomains present, which in turn would imply that there are some DKIM keys present in DNS (although you can’t know what the selector names are). But you don’t know if these keys are active, or if they are meant to be activated later. Or there might be multiple authenticated senders for a domain name, and some might use DKIM signing, but others might not.<p>1. Not all DNS servers obey the standards correctly, so the NXDOMAIN&#x2F;NOERROR distinction only <i>mostly</i> works.

&gt; <i>MailChannels main customers are web hosting providers who don’t own the domains they send emails from!</i><p>That&#x27;s the lamest excuse I&#x27;ve heard in a while.<p>Web hosting providers generally don&#x27;t &quot;own&quot; the domains they host, but they absolutely know which domains they host. Routing domains to customer accounts&#x2F;directories is the whole point of web hosting!<p>All they need is some sort of cPanel integration to report the list of domains and tie each domain to a randomly generated key. All of this can (and should) be automated without bothering the end users in any way.

I wish there was some way to evolve the DMARC spec such that only DKIM and not SPF is used for validation. Sadly things like Google Calendar invites still fail DKIM…

As someone whose recently facechecked getting my domains email ready, including the absolute frustration of dealing with an ISP who has decreed that &quot;those who want to send email from their own metal shalt have a business account&quot;, shit like this makes my blood boil.<p>I bust my ass to be a responsible member of the Net and do my damnedest to ensure that my systems are up to snuff, up to and including ripping through&#x2F;tearing apart the current SotA... and yet assholes like that not only exist, but flippantly run as an open relay. With almost half of the Net paying them to do so. Are you frigging kidding me?!

TL;DR They found an open relay included in many SPF records.

The effect that ARC headers have on spam scores is interesting. As someone who runs his own private mail server, I can seemingly improve the deliverability of my emails by just adding a set of useless ARC headers to my own emails?

looks like this was even ack&#x27;d in May 2022: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=30533032">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=30533032</a>

Since about September 1st, email forwarding from my Gmail account to another Gmail account fails with a DMARC-related bounce depending on the original sender&#x27;s configuration. Email security has become too hard for email providers to get right.

Does the issue still exist if you register an $80 SMTP outbox and spoof the address?

I think this is primarily a problem of the domain owners&#x2F;sysadmins, all my domains have SPF, DKIM, and DMARC and I also keep them monitored for any blacklist&#x2F;alerts, if you are not aware of these, you should hire someone to audit it, email protocol is broken by design and all of these are duct tape solutions to prevent OP attempts. This whole document gives me nostalgia back in the late 90s early 2000s how there were tools you install to spoof emails!

Is this why I&#x27;m getting bounces from emails I didn&#x27;t send with broken DKIM signatures for the past couple of weeks?<p>(Edit: I&#x27;m not using MailChannels, though.)

Can anyone confirm whether that this short article I wrote a while ago is &quot;good enough&quot; for avoiding spoofing?<p><a href="https:&#x2F;&#x2F;www.uxwizz.com&#x2F;blog&#x2F;stop-others-use-your-domain-emails" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.uxwizz.com&#x2F;blog&#x2F;stop-others-use-your-domain-emai...</a>

But... What about BIMI

Well this explains all the email2text spam with spoofed emails lately.

The level of complacency of mailchannels when they were contacted about the issue is just unbelievable. Those guys are responsible for a sizeable portion of the corporate email traffic, and don&#x27;t seem to give a shit about security or spam (the cancer of the very thing they sell) until publicly shamed about it.<p>Entertaining presentation

Due to laziness &#x2F; ignorance &#x2F; some combination of both, many domains that use Amazon can be trivially spoofed by anyone else who can send via Amazon. Last I checked, that was true of outlook.com, too. I think there was a recent article about it...<p>These companies are so hungry for money, they forget that their products need anything else at all after they get to the &quot;charge customer money for service&quot; part. Companies have been told about issues like these for ages now, yet they all act so surprised when the same ancient problem pops up, time and time again.

Ken is a good friend in the industry and always has the best interest of email security at heart. This may have been an architectural oversight but they are not wrong that SPF is surely a cause for concern, as is misconfigured DNS based trust and recertifications via arc (which was supposed to solve a problem for forwarding scenarios).<p>The centralization of email services to a handful of providers basically has led to multihoming of millions of domains that open SPF auth to the same handful. Any integrations by them or changes to existing stack can cause issues to pop up, because delegation of sending rights isn&#x27;t strictly auth controlled. The same also happens with dkim delegation to saas providers who share backend keys across other customers of theirs and if their API is open to experiment (or an account gets popped) then the customer domains are possibly at risk.<p>Email is hard to do right. No auth no entry should be the default. But majority of domain owners aren&#x27;t very good at figuring out how to secure things, or have business&#x2F;product interests that are a priority, specially when delegated and authorized to third party senders on their behalf.