To be abundantly clear, if you create a Domain Lockdown record, then even someone paying MailChannel

To be abundantly clear, if you create a Domain Lockdown record, then even someone paying MailChannels $1M/mo cannot send email on behalf of your domain.

Unsmart•8/21/23, 10:45 PM

so $2M/mo is the lucky number /s

Sskoogeer To be abundantly clear, if you create a Domain Lockdown record, then even someon...

James•8/21/23, 10:54 PM

How would someone enforce Domain Lockdown when they don't use Workers? That's entirely related to the cf-workercf-worker header... no? How do I ensure only I can send from my domain, and not any of your other paying customers, outside of Workers?

James•8/21/23, 10:54 PM

All of the docs I've seen at least are explicitly talking about cf-workercf-worker. If there's something I'm missing, please let me know

Cchientrm.com I got MailChannels lockdown + SPF + DKIM + DMARC setup already.

DarkDeviL•8/21/23, 10:57 PM

Depending on your "trust", re. e.g. the messages above, you can also kill the SPF in various different ways (deleting the SPF record, removing "include:relay.mailchannels.net", ... or similar), and attempt that way to lean only on DKIM authentication, if you're 100% sure that DKIM is set up and working properly, which your DMARC reports can eventually assist with (over time).

While I am a fan of as strict security policies as possible, including e.g. having a DMARC reject, and SPF "-all" (e.g. DASH all) policy, setting SPF alone to "v=spf1 -all" as an attempt to lean on DKIM authentication alone, may be able to trigger some spam filters, believing that the "v=spf1 -all" means "this domain never sends mails".

That part should be solvable, by having any (apparent valid) part between "v=spf1" and "-all" though.

Final result, regardless what you do or attempt, will always depend on the individual receiving mail server / destination though.

Sskoogeer This no longer works because you must have a Domain Lockdown record in place bef...

James•8/21/23, 10:57 PM

But it does still work if someone just gives you $80 and uses your SMTP relay, no?

James•8/21/23, 10:59 PM

With Workers, yes

James•8/21/23, 10:59 PM

I'm talking outside of Workers entirely

James•8/21/23, 10:59 PM

How can I setup a Domain Lockdown record that lets only me send using the SMTP relay, and no on else? Not in Workers.

JJames How can I setup a Domain Lockdown record that lets only me send using the SMTP r...

DarkDeviL•8/21/23, 11:00 PM

Isn't that on https://support.mailchannels.com/hc/en-us/articles/16918954360845-Secure-your-domain-name-against-spoofing-with-Domain-Lockdown- ?

James•8/21/23, 11:01 PM

Oh I see, there's

auth

auth

and senderidsenderid options instead of cfidcfid. Okay this is good.

James•8/21/23, 11:01 PM

Now they need to enforce this for all customers.

James•8/21/23, 11:01 PM

And then, I'll be happy recommending MailChannels

JJames Now they need to enforce this for all customers.

DarkDeviL•8/21/23, 11:01 PM

This sounds what @ttul said abvove that it is (now being)?

DDarkDeviL This sounds what @ttul said abvove that it is (now being)?

James•8/21/23, 11:02 PM

I mean, enforce sender verification in general. Don't allow any email to be sent without this (or something) set. So actually protect their large customers like boston.govboston.gov.

DarkDeviL•8/21/23, 11:04 PM

Could be me, but doesn't general-discussions sound like it's in effect already?

James•8/21/23, 11:04 PM

It's wild to me that it's taken all of this public pressure for change, when this has been known since 2016. But once they actually enforce this, I'll be happy recommending MailChannels

DDarkDeviL Could be me, but doesn't https://discord.com/channels/595317990191398933/9094582...

James•8/21/23, 11:05 PM

No, that's an opt-in to not being spoofed. People still have to create that record.

James•8/21/23, 11:05 PM

You can still signup right now and spoof any customer without this record.

DarkDeviL•8/21/23, 11:05 PM

Oh, you meant it like that.

James•8/21/23, 11:06 PM

And I've not checked, but I would put a lot of money on the 2+ million affected not adding this record yet.

James•8/21/23, 11:06 PM

It's a great start, don't get me wrong. But it's still not enough in my opinion.

FFrerduro is obervatory broken? I am unable to check a website however 3rd pary websites w...

Frerduro•8/21/23, 11:07 PM

DarkDeviL•8/21/23, 11:08 PM

I just understood that you were looking into having $80+/mo SMTP relay customers to be locked out, if you had:

_mailchannels TXT "v=mc1 cfid=spaghetti.invalid"

which is what I meant that I understood was already the case

JJames It's a great start, don't get me wrong. But it's still not enough in my opinion.

DarkDeviL•8/21/23, 11:19 PM

It has literally been like that since the beginning of the Domain Lockdown.

I do however perfectly agree to the stuff "not enough"!

I would personally be happy as well, if no email providers allowed sending on behalf of my domains, except explicitly authorised.

Explicitly authorised could for example have been something like the stuff I mentioned in https://discord.com/channels/595317990191398933/812577823599755274/1140785631681855578 + 2 following posts, or a lot of other, different options.

James•8/21/23, 11:20 PM

For me personally, outside of the actual issue which is still a huge problem imo and basic identiy needs to be an enforced requirement ASAP, the way MailChannels handled this makes it very difficult for me to seriously recommend them. The response to the issue, the communication, the knowledge since 2016 with only being "fixed" after public pressure, etc. just doesn't give me a lot of confidence in a company I'd be trusting to send emails for me. If they do a big educational campaign about this and commit to some timeline of enforcing some basic sender domain verification, that might change, but until then I'm almost certainly going to continue recommending other solutions that have shown more care for their customer security.

Ffiirhok You can use "v=mc1" to completely prevent us from sending from your domain. Even...

DarkDeviL•8/21/23, 11:30 PM

At that point, I would agree with completely with @James, if I'm understanding him well, that his opinion is that it shouldn't be necessary for me to add any arbitrary, and per-individual provider DNS records, to prevent MailChannels from allowing it's customers to impersonate my domain.

Somehow, I'm thinking to that part:

What if (all) other providers started mandating the same, which would be a per-provider specific record to prevent the sending?

skoogeerOP•8/21/23, 11:36 PM

There are many valid reasons why someone will send emails "from" a domain they do not control, which is why the authors of RFC5321 said this:

"Efforts to make it more difficult for users to set envelope return
path and header "From" fields to point to valid addresses other than
their own are largely misguided: they frustrate legitimate
applications in which mail is sent by one user on behalf of another,
in which error (or normal) replies should be directed to a special
address, or in which a single message is sent to multiple recipients
on different hosts."

Purely transactional email services assume that you control your domain; these services are not used for sending general purpose email such as forwarded traffic or discussion list traffic. MailChannels operates a general purpose mail relay service. Only the Cloudflare API is purely transactional, which is why it was appropriate for us to roll out Domain Lockdown there. As for the rest of the infrastructure, we will make it easy for people to use Domain Lockdown if they want to prevent others from sending on behalf of their domain; however, we will caution that doing so will prevent email from their domain from being forwarded - for instance via a discussion list or mail forwarding setup on a hosting box.

skoogeerOP•8/21/23, 11:37 PM

Nora, not sure what you mean here. Domain Lockdown went into effect June 20th. Legacy Workers accounts were allowed a grace period (which ended last week), but all others have had to validate their domain ownership with Lockdown since June 20th.

Sskoogeer There are many valid reasons why someone will send emails "from" a domain they d...

James•8/21/23, 11:38 PM

Quoting an RFC really isn't helpful when other providers don't have this issue and allow others to spoof my domain by default without additional steps I have to take

Y'all really need to own this, and it's very disheartening that you're not.

James•8/21/23, 11:39 PM

"We f'ed up, we know that, we're working on fixing it, stay tuned for updates in X time". That's all it would take. Do the right thing for your customers here, please.

James•8/21/23, 11:39 PM

All you're doing at the moment is destroying trust.

DDarkDeviL At that point, I would agree with completely with @James, if I'm understanding h...

skoogeerOP•8/21/23, 11:47 PM

@nora I'd like to understand you better. What do you mean when you say "Then it's revealed that such a basic safety mechanism had not been thought of."?

Sskoogeer @nora I'd like to understand you better. What do you mean when you say "Then it'...

James•8/21/23, 11:49 PM

I don't want to put words in their mouth, but I think what they're pointing to is something as basic as sender domain verfication that without, allows anyone to send from their domain without them taking additional steps themselves (domain lockdown record) and even realising that it's an issue.

James•8/21/23, 11:50 PM

Basic security so that only my account can send from my domain should be standard, not some obscure opt-in DNS record

Sskoogeer There are many valid reasons why someone will send emails "from" a domain they d...

DarkDeviL•8/21/23, 11:51 PM

As for that specific part, - when you use the very-often shared trick in combination #email-routing, to use Gmail's SMTP relay with a free @gmail.com address, the envelope from is forced to be equal to that specific @gmail.com account used in authentication.

Gmail does, to my knowledge, not allow you to set an arbitrary envelope from there, but forces the @gmail.com, which is why you cannot get proper DMARC (SPF) alignment with a custom domain, with only a free Gmail alone.

DarkDeviL•8/21/23, 11:54 PM

You could have enforced, so that the specific domain MUST have explicitly authorised "the specific customer that tries to send on behalf of the domain name", which could for eaxmple have been done in a very granular way, like dynamic SPF examples shared around https://discord.com/channels/595317990191398933/812577823599755274/1140785631681855578

If it is so important for your mail relay customers to be able to send form any domain (in the From: header), unless they explicitly have allowed something like the above (based on e.g. a "dynamic" SPF), the (dynamic) envelope from could have been forced to be something like:

"@customers.mc.<hosting provider domain>"

Or in the event of e.g. Workers, it could have been anything like:

"@relayed.via.mailchannels.workers.dev"

skoogeerOP•8/21/23, 11:54 PM

@DarkDeviL, if you use an older-style email forwarding setup - as millions of people do today with domain registration services - then some of your forwarded email will likely get put into the garbage on account of violating the sender's DMARC policy. That being said, email receivers tend to detect forwarded traffic by analyzing message headers and applying machine learning techniques, so the impact on deliverability isn't as severe as the DMARC mis-alignment might suggest. Similarly, if you send emails via a Mailman-based mailing list service, if your domain's DMARC policy is strict, then it's possible that some people might not receive messages that you post to the list.

These are just a couple of the big challenges that the email industry is trying to resolve through better standards.

DarkDeviL•8/21/23, 11:54 PM

That way, it wouldn't pass DMARC, due to the alignment, but the sending would still be possible (although, ... still a bit negative, re. some of the above posts)...

A DMARC reject (and receiving end's rejection there) would have caught that though, even if you let it through.

Sskoogeer @DarkDeviL, if you use an older-style email forwarding setup - as millions of pe...

DarkDeviL•8/21/23, 11:56 PM

I know about the issues that there are with certain things out there, don't worry about that specific part.

DarkDeviL•8/21/23, 11:57 PM

All I am saying is just, there are various ways to limit the collateral damage (or even completely mitigate it), according to what seems to be demonstrated out there to be the actual issue, ... so far.

James•8/21/23, 11:59 PM

So much this ^. There's so much deflection and justfication being made towards "better standards" and "improved email security", etc. and that's all great. But it's not in place of just... basic protections you can implement today - and should have from the start.

skoogeerOP•8/21/23, 11:59 PM

@DarkDeviL the vintage of much of the hosting industry's infrastructure is not to be overstated. We would not have a business if we required hosting companies to modify sender email addresses. However, we do believe we can help providers improve their security in other ways. For example, we allow providers to receive immediate webhook pushes every time we detect unusual or spammy traffic coming from one of their users.

I know it's not apparent here, but we do a whole lot behind the scenes to detect and stop abuse - far more than most providers do. We sell anti-abuse technology to other transactional email providers, including in the top-five globally. The discussion here has been laser-focused on domain ownership verification, but that is just one tiny part of an enormous array of things you have to do to properly secure outgoing email and achieve decent delivery rates.

skoogeerOP•8/22/23, 12:01 AM

I have to run now. I would be pleased to answer any questions via PM if anyone here needs further clarification on what we are doing to ensure the security of our service and adherence to email standards.

To be abundantly clear, if you create a Domain Lockdown record, then even someone paying MailChannel

Similar Threads

Similar Threads

Similar Threads