Hacker News Reader

Comment by jeffbee | Hacker News Reader

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

Where out of those 2M domains with SPF records opening themselves up, <1k had set up DKIM/DMARC records and somehow even those with DKIM configured and neglected still pass as authentic in Gmail.

That part did not make any sense to me. I do not see how this person determined that these domains are not using DKIM. There is no standard DKIM domain name, so what did they check?

Worse than that. The platform itself didn't even attempt to verify domain ownership so you could send as anyone.

Except it's not an open relay. MailChannels would not exist on the internet if it didn't aggressively control spam and phishing. The DEFCON talk did not prove the existence of a gaping hole; it showed something that has existed since the dawn of internet email: the sender domain cannot be adequately authenticated unless you use message signatures such as S/MIME and DKIM. And even with DKIM, DKIM replay attacks allow widespread abuse.

Sorry, no. Any service that will issue emails masquerading as 3rd-party domains, which does not use an effective authentication mechanism, is an open relay by definition.

I disagree. The “open” part implies there is no control at all on what email can be relayed. That is not at all the case here.

Spammers try their best to send spam through MailChannels all day long, through compromised WordPress sites, hacked user accounts, etc. We block 28% of all the messages that are submitted, and of what remains, only 2% is rejected by receivers.

That’s not at all what an open relay looks like. An open relay would accept 100% and likely be blocked within an hour across the internet.

Spam. Isn't. The. Only. Concern.

It’s a nuance, but when I refer to “spam” I am incorporating the term “phishing.”

That's a terribly incomplete understanding of what's going on here.

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.

Why is it not valid for someone to send email from another domain? I’m asking seriously. That’s not an invalid thing to do. The RFC explicitly advises that flexibility in the envelope address is a necessary feature of internet email.

It may be a convention that transactional email services require proof of domain ownership, but that is a convention, not a standard.

I think the fact this was possible via the use of CF workers invalidates your point. Also, you choose to add the Domain Lockdown feature as a direct results of these findings.

I'd feel pretty silly too if my "email filters" kept me from acting sooner on this problem.

It's valid, but it needs to be authorized. Back when initial specs of SMTP were it didn't matter that much as users were mainly academics and it was primarily used for discussion/passing information.

These days you don't really want your finance team getting email which say it's from CEO and is asking them to make wire transfer, email from IT asking to password reset and so on. While it probably shouldn't be, the sender address is treated as very strong signal that email is legitimate so you should be taking steps to make it so that if someone tries to spoof it without authorization, it should be treated as suspicious.

IDK. First thing I say in every single security talk I give is "The Sender Address displayed in an email is just what the sender put there, nothing more". If the email needs some kind of validation it needs to carry that token itself (and here begins my long graybeard rant on why we should all be digitally signing emails as a matter of course).

You don't understand the situation at all

If you check their profile they’re the founder of MC. That would explain the comments more than understanding of the topic.

Oh yikes. Yeah, I've seen them arguing on the Cloudflare Discord channel and it is the definition of sticking your head in the sand. Their response to this serious problem has been absolutely awful

One of those "It is difficult to get a man to understand something, when his salary depends on his not understanding it." situations I guess.

Ironically it's not possible to use S/MIME with MailChannels here because you don't allow sending raw MIME content.

Yeah that restriction isn't immediately apparent when you look at the documentation that mailchannels link to on their site.[1]

However, it is mentioned in the openapi schema.[2]

I suppose they intend that people send up to 20M with just text/plain and text/html. (Send all the base64 encoded images I guess)

[1]https://api.mailchannels.net/tx/v1/documentation [2]https://api.mailchannels.net/tx/v1/openapi.yaml

Reply on news.ycombinator.com