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

- SPF breaks with forwarding. This is by far the biggest problem.

You typically end up with very large IP blocks being included in your policy (for example: MS365 includes a total of half a million IPv4 addresses, and billions of IPv6 addresses). All of which are now allowed to send on behalf of your domain. You'll have to trust (or hope) that the third party properly prevents other tenants from sending email on behalf of your domain. This is the problem with MailChannels as explained in the PDF.

- SPF can be very tricky to get right, one simple mistake and you either allow way to many IPs, or break your entire email domain. Even most seasoned IT administrators don't fully understand the entire RFC with all its errata and amendments. Now imagine some less technical user trying to set up SPF.

- You can only have one SPF record. If you want to add some external service, you'll need to merge your existing SPF record with the example given by your vendor. This can be highly confusing to many.

- The SPF DNS record is placed at the domain root (apex), which as shown in other comment here can be problematic for large orgs. This also prevents using a CNAME for SPF.

- SPF limits to 10 DNS lookups, which has proven far to low for modern use. The rules on how to calculate the number of required lookups is also ambiguous, so some receivers may accept your email, some may reject based on lookup limits.

- SPF contains many rarely used features (such as macros) that may or may not be implemented by the receiver, so you can't really rely on it.

- IP spoofing is an issue, but as you noted, this is not always a practical attack.

DKIM is in any regard more robust, more secure, and more important: easier to set up for the domain administrator. Just copy/paste the DKIM record provided by the third party email service. The third party vendor can (and most do) easily verify that the DKIM record is set up correctly. This is about as easy as it gets for DNS.

> Even for larger organisations which need to allowlist multiple sending systems, how would one spoof being one of the legitimate SPF sender in a situation where it is not also possible to spoof the DKIM records?

That is the problem with the (current) DMARC specification, you need SPF or DKIM to pass DMARC. Emphasis on or. So no matter how well you manage your DKIM keys, if someone can spoof (or has access to) one IP in your SPF policy, then the email is delivered. This is also explained in the talk.

Also, with DKIM you don't 'spoof' the record, you'd have to MITM the receiver when they fetch the DKIM DNS record, this is very hard to pull of in practice.

>● CF workers will be required to set their “Domain Lockdown” record in order to send emails after a specific cutoff date (TBA). You’re still able to spoof all the things until then!

For any domain that is using mailchannels through cloudflare, you can see what region they are using. And you can continue to spoof them. You just have to do it from the same region.

And this is terrible positioning from Cloudflare’s POV. Why would anyone send email through a CF worker since it requires advertising through a public record (DNS) that is by design accessible/scrapable by bots that you are using an insecure service. It’s like asking people to spoof you.

I don’t get why CF doesn’t do something more sensible, like limit sender addresses to domains that are already set up in the cloudflare account where the worker was created. Basically every other provider does this.

Yes, but you can’t know that every authenticated sender is using DKIM at all. If the mail you just recieved from a new sender (even if it is from a domain which you have recieved DKIM signed mail from before) passes SPF but is not signed using DKIM, they are quite probably from a valid, albeit rarely used, mail sender who simply does not use DKIM.

> I think what the line you quote is trying to say is reject mail from MailChannels that isn't DKIM signed.

No, they can’t be saying that, since elsewhere they say that only 105 out of 2 million MailChannel domains are using DKIM. Therefore, they can’t be reasonably suggesting to block all mail from all but 105 of these domains.

This mostly works today, for example SES allows the origin to sign messages (although as of a few months ago I started hitting an SES bug where they modify a header field that they said they wouldn't, breaking the signature) and there are a few other providers that allow this capability as well.

However I basically still need to mark them as trusted in the SPF record otherwise the spam score goes up. This effectively allows them to spoof messages from my domain. I would love to close off this loophole.

It also isn't great with sending from public cloud VM instances either since I have to update the SPF record with the changing IPs and DNS caching can cause false fails (if a new instance sends mail before the cache is refreshed) and false passes (if the old IP gets reused for a different customer before the cache expires).

Yeah, I know. I should just rent a public IP. But that raises costs and would require me to raise my prices. Especially at the current small scale.

It is incumbent upon them to validate that their API users own the domain they intend to send from. All the reputable senders do this. Allowing unchecked user-defined from field is the definition of an open relay.

> The presence of an arc=pass generally guarantees a better spam score. Confirmed with ProtonMail. Seems to be the case with Gmail and Outlook as well.

And it doesn't seem like there's anything that would prevent me from adding this to my own emails. I don't think it would turn blatant spam into non-spam, but it seems like it could help something that's already teetering on the line.

Yeah that's definitely not what I meant or what the presenter seems to be implying. If it helps spam scores even a little bit, that's very interesting and potentially worth implementing in private hosts that often get dinged by larger hosts just for not being well-known. It doesn't need to get anywhere near turning actual spam into non-spam.

The DEFCON presenter makes the assertion that you can set up a spamming operation for $80/mo, but has he tried?

[1] https://trends.builtwith.com/mx/transactional-email/traffic/...