Hacker News Reader

Comment by ttul | Hacker News Reader

Note that since June 2023, it is impossible to send email from Workers through MailChannels unless you publish a _mailchannels record in your DNS.

View on HN

This doesn’t seem like a real fix for the issue. This brings the number of spoofable sites way down from all MC users to just those who send mail through CF. But it is still a big vulnerability.

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.

The _mailchannels record includes the Cloudflare worker id, other workers can not send from that domain.

Source? The talk slides seem to contradict that:

>● 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!

https://community.cloudflare.com/t/this-week-mailchannels-wi...

> Source?

You're replying to the CEO of MailChannels

These slides are outdated

This seems like a hack. why doesn't mail channels do a proper authentication of the sender?

Ahh yes, another "standard". https://xkcd.com/927/

Absolutely. For reference, here is a TXT lookup for a random large corporation:

% host -t txt bosch.com bosch.com descriptive text "b5r8gr465ydgqlvwlwy6x7dshccwg37c" bosch.com descriptive text "mindmanager-verification=5eacd59de90dd7d9933da220294f2906a881fa6701d64a1a4667c05abac12546" bosch.com descriptive text "cisco-ci-domain-verification=20e8d94f041a742a6de560a038d031baf659330970e6f05bb03fb2468bba379a" bosch.com descriptive text "v=spf1 mx redirect=_spf.bosch.de" bosch.com descriptive text "r7bNBcUhS/tsO45+nP1dycu5UDrZ7TniKe858vhLNJwAcCNDQlpdaks8iBm3TxV9r3fCYRvup/QpaC1rdp4Dpg==" bosch.com descriptive text "google-site-verification=avGZ684w6lq0UwXmOHxz9l6u9GL8r-sXoV7io9KzZOc" bosch.com descriptive text "facebook-domain-verification=20380cm6fdq6h7tdcqzmhysa70ctdo" bosch.com descriptive text "google-site-verification=jWBLaKM6WZQoAV6crbGGsAre3rSvqaDtwnCKuwvDPCg" bosch.com descriptive text "adobe-idp-site-verification=e13fd7b27a30ca44261bc7ad3f0b2e0994b724830fe8afc38a6565a40d81bde4" bosch.com descriptive text "google-site-verification=yeXu97OTorw4QioF3yNiDvTn-0GL8__7-iTNLEp6Vbk" bosch.com descriptive text "docusign=4f8c3289-c1e1-42a5-a541-f3459d2da55e" bosch.com descriptive text "docusign=95ecd2d2-2737-4b07-9d40-95d065bfbc49" bosch.com descriptive text "atlassian-domain-verification=1XOeeaiW02aX/CXX/725tFzKFh4PA18JpZoyq9qBDqDxR2PP/9LDxCqlmYYgyb4D" bosch.com descriptive text "77D8-D4C6-1CCC-8D85-3127-5140-11D2-956B" bosch.com descriptive text "axway-amplify=af03bdb0-d4a8-429f-bf96-b7ba41051d49" bosch.com descriptive text "apple-domain-verification=VYw9jmavDBjP0C9S" bosch.com descriptive text "mongodb-site-verification=gf5347Wa7YvVkq4C51l3srxrco2GLGPl" bosch.com descriptive text "docusign=ebea8618-97e6-4a64-82a9-2e3fa036d5bb" bosch.com descriptive text "docusign=df164c89-5239-42d4-97f5-8f5710b1b929" bosch.com descriptive text "miro-verification=95bb46ca27717c388e091411d7fe643e3a3d2b3d" bosch.com descriptive text "docker-verification=224577a6-972f-4e1d-a8b9-c5fc2e8da018" bosch.com descriptive text "klaviyo-site-verification=THKvhQ" bosch.com descriptive text "atlassian-sending-domain-verification=e4597f31-7a29-47fd-b150-5e1eaeac437b" bosch.com descriptive text "sFHU8FVI0Jt2PIXJAn2DWGmT7UJmZJzyq2THJmabTvEcw0IGtPu2UHU9Wf/zdvZoGAvtmO5tD3rOSvXjQWZ57Q=="

Indent with four spaces to render as preformatted text which preserves newlines... I also removed the redundant info from each line and sorted alphabetically while I was at it

TXT records for bosch.com:

    77D8-D4C6-1CCC-8D85-3127-5140-11D2-956B
    adobe-idp-site-verification=e13fd7b27a30ca44261bc7ad3f0b2e0994b724830fe8afc38a6565a40d81bde4
    apple-domain-verification=VYw9jmavDBjP0C9S
    atlassian-domain-verification=1XOeeaiW02aX/CXX/725tFzKFh4PA18JpZoyq9qBDqDxR2PP/9LDxCqlmYYgyb4D
    atlassian-sending-domain-verification=e4597f31-7a29-47fd-b150-5e1eaeac437b
    axway-amplify=af03bdb0-d4a8-429f-bf96-b7ba41051d49
    b5r8gr465ydgqlvwlwy6x7dshccwg37c
    cisco-ci-domain-verification=20e8d94f041a742a6de560a038d031baf659330970e6f05bb03fb2468bba379a
    docker-verification=224577a6-972f-4e1d-a8b9-c5fc2e8da018
    docusign=4f8c3289-c1e1-42a5-a541-f3459d2da55e
    docusign=95ecd2d2-2737-4b07-9d40-95d065bfbc49
    docusign=df164c89-5239-42d4-97f5-8f5710b1b929
    docusign=ebea8618-97e6-4a64-82a9-2e3fa036d5bb
    facebook-domain-verification=20380cm6fdq6h7tdcqzmhysa70ctdo
    google-site-verification=avGZ684w6lq0UwXmOHxz9l6u9GL8r-sXoV7io9KzZOc
    google-site-verification=jWBLaKM6WZQoAV6crbGGsAre3rSvqaDtwnCKuwvDPCg
    google-site-verification=yeXu97OTorw4QioF3yNiDvTn-0GL8__7-iTNLEp6Vbk
    klaviyo-site-verification=THKvhQ
    mindmanager-verification=5eacd59de90dd7d9933da220294f2906a881fa6701d64a1a4667c05abac12546
    miro-verification=95bb46ca27717c388e091411d7fe643e3a3d2b3d
    mongodb-site-verification=gf5347Wa7YvVkq4C51l3srxrco2GLGPl
    r7bNBcUhS/tsO45+nP1dycu5UDrZ7TniKe858vhLNJwAcCNDQlpdaks8iBm3TxV9r3fCYRvup/QpaC1rdp4Dpg==
    sFHU8FVI0Jt2PIXJAn2DWGmT7UJmZJzyq2THJmabTvEcw0IGtPu2UHU9Wf/zdvZoGAvtmO5tD3rOSvXjQWZ57Q==
    v=spf1 mx redirect=_spf.bosch.de

I cannot believe how absurd and out of hand this has gotten.

Why did we not all standardise on some _well_known. subdomain or similar for these dozens of records?

The part that gives me an eye twitch is so many domains have multiple verifications for the same group, your own example has Google three times for example. The reason being one marketing company sets up Analytics. A few months later, a different company expects to be authorised to run another set, but all the admins get told is "you have to add this record".

Or just allocate proper DNS records as the standard intended.

There was a SPF record type in DNS, TXT was suggested as a transition, but we all know how that went.

Incidentally, SPF is a good example how a large company hijacked the process and tried to stuff the standard with things they had taken out patents on. That made the end standard less useful than what it could have been.

They also generally don't need to stay there it's usually one-shot (at least the ones I've seen) but no one bothers to delete them.

I give talks to IT teams on the importance of cleaning up transient auth records in DNS and, as the night follows the day, I don't do it on my own personal ones.

What would you have used?

I would have implemented DKIM and SPF.

Great. But that doesn't solve this particular problem. Why do you think every legit ESP makes you do domain level validation using a custom TXT record?

The only reason most do that is to enable branded tracking links.

You are thinking of CNAMEs, and no, it isn't related.

Reply on news.ycombinator.com