throwaway2346mg

I don't think this is related.

The issue here is with inbound emails using Mailgun's inbound routes functionality.

Protecting your sending servers from abuse isn't an issue with Mailgun as far as I'm aware.

Yep - there are a number of scenarios:

- CRM system (obviously an issue) - Inbound email automation (eg. action based on reply from user / admin / etc)

But really, any inbound action where you don't want someone to be able to trivially spoof the sender, when the sender has SPF/DKIM/DMARC all configured.

For people using Mailgun purely for marketing email purposes, this is unlikely to be an issue, as you're unlikely to be using inbound routes for automation/processing.

Exactly this!

As pointed out on Reddit [1], if you want to trivially see companies using Mailgun it's as simple as looking at:

https://securitytrails.com/list/mx/mxb.mailgun.org

https://securitytrails.com/list/mx/mxa.mailgun.org

[1] - https://www.reddit.com/r/sysadmin/comments/14vtszl/comment/j...

I'm afraid I haven't checked this - are you a Mailgun user and want to report back on this? Alternatively, hopefully Mailgun themselves will spot this and can respond directly.

> Is the problem that they don't do the verifications for SPF/DKIM/DMARC for inbound emails?

Yes - the result of the checks aren't passed through for inbound emails (when sent to webhooks).

Agreed. I think the point here is that what % of Mailgun users will be doing this additional processing? I suspect it's basically 0%.

Why? It's not outlined in their specs, their sales copy implies they are handling it, and sensible headers are sometimes there which is extra misleading.

The sender can be anyone. They don't need to be a mailgun user.

The recipient has to be a mailgun user, yes.

> Is that not identical to "if a company runs an SMTP server, you send a spoofed email, and they don't do any validation then phishing is trivial"?

Yes. Except in this case, the company is paying Mailgun to process inbound mail and attach SPF/DKIM/DMARC headers, which they don't do. And this is counter to their own API spec.

If you are running your own SMTP server, then you wouldn't be relying on headers from Mailgun.

Essentially though you are right, using Mailgun is akin to having an SMTP server without any spam protection in place, and limited ability to put that spam protection in place. You are better off running the server yourself.

The point here is that Mailgun customers won't be aware of this, and as such, it's a vulnerability.

Yes - it's emails that hit a certain pre-determined spam assassin threshold (see Note B). But this is fairly easy to circumvent (spammers/phishers are especially good at it) and the threshold is reasonably high.

All in all this means the vast majority of emails don't have these headers included in webhooks, and we have plenty of examples of spoofed emails for our own domain (invalid SPF/DKIM and failed DMARC) that get through without triggering spam assassin.

This simplest way to verify this is to store the value of these headers along with all inbound emails hitting your webhooks, you'll quickly see they are missing the majority of the time.

I'm not sure if this is relevant in regards to the security disclosure itself. If you're not using Mailgun then this doesn't affect you.

However, with regards to "SPF is more than enough", the fact here is that the SPF header isn't passed to the webhook, so it can't used in a mailgun inbound route.