At that point, I would agree with completely with @James, if I'm understanding him well, that his op

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?

skoogeer•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.

skoogeer•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...

skoogeer•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...

DarkDeviLOP•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.

DarkDeviLOP•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"

skoogeer•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.

DarkDeviLOP•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...

DarkDeviLOP•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.

DarkDeviLOP•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.

skoogeer•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.

skoogeer•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.

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

Okay, I think I'm done with this discussion moving forward - we're honestly just going in circles. The lack of ownership of this issue and constant deflection and justification is just not a productive use of either of our time. So that's fine, I'll just be heavily discouraging people continue use your service.

Sskoogeer @DarkDeviL the vintage of much of the hosting industry's infrastructure is not t...

DarkDeviLOP•8/22/23, 12:16 AM

The modifying of sender addresses part would alone be done if there wasn't (enough) domain validation in place, to ensure the customer<->domain relation.

And as I believe I already added in #off-topic last week, from what I see, it does indeed look like you're doing very well regarding preventing outbound spam / junk from happening from your network, unlike many others out there.

Should I choose a provider based on e.g. spam / junk parameter alone, you / your network would definitely be a good candidate.

No doubt about that specfiic part!

It is however purely the domain validation part (or stuff similar to that), that I've trying to suggest you alternative ways "to limit the collateral damage (or even completely mitigate it)".

That said, if you got any questions or whatever, regarding any parts of those suggestions I've made, or otherwise want to discuss them further, feel free to poke me as well.

FF0rce in Zero Trust what would the best practice be to allow everyone that has gateawa...

Soham•8/22/23, 1:52 AM

you can make it a requirement in your access rule

Soham•8/22/23, 1:53 AM

SSoham you can make it a requirement in your access rule

Erisa•8/22/23, 2:05 AM

Keep in mind that one includes the consumer app as well (without logging in), I would strongly suggest selecting "Gateway" instead which will only accept ZT clients logged into your org

EErisa Keep in mind that one includes the consumer app as well (without logging in), I ...

Soham•8/22/23, 2:06 AM

yeah i tried gateway but it seems to only work with the proxy feature enabled which then messes with my local network stuff such as spotify connect etc so I had to disable it

Erisa•8/22/23, 2:07 AM

Sure of course yeah, as long as you're aware of the difference between the two

Soham•8/22/23, 2:07 AM

yep

Soham•8/22/23, 2:10 AM

Confused with the wording a bit but does enabling proxy mean traffic directed to resources connected via a Cloudflare Tunnel, GRE tunnel, and/or IPsec tunnel is included when enabling it but outbound traffic is anyways filtered regardless of proxy being enabled

jimango•8/22/23, 12:26 PM

Im currently not able to upload more than 1mb to my own server when using cloudflare. When I try upload without Cloudflare im able to upload 100mb. But thought Cloudflare DNS its reduced to 1mb. Can anyone please help me solve this?

Jjimango Im currently not able to upload more than 1mb to my own server when using cloudf...

Erisa•8/22/23, 12:27 PM

When you try to upload 100mb, what error do you get back?

EErisa When you try to upload 100mb, what error do you get back?

jimango•8/22/23, 12:29 PM

From the frontside of the page I get just a custom error for our site, I have not access to the logs to see those, its a NFT marketplace and it works with files below 1mb. It stops in the moment when the wallet is supposed to verify the minting. Instead of opening the already connected wallet it gives an error.

jimango•8/22/23, 12:30 PM

as said, it works with less than 1mb files using Cloudflare and with 100mb when not going through Cloudflare

Erisa•8/22/23, 12:30 PM

That sounds suspiciously like an issue with your origin server, however I understand you said it doesn't happen without Cloudflare. Do you have steps for anyone to be able to reproduce?

jimango•8/22/23, 12:30 PM

yes. it happens to anyone trying this

Erisa•8/22/23, 12:31 PM

Are you able to share a link?

jimango•8/22/23, 12:31 PM

yes, can I share here? or in DM?

jimango•8/22/23, 12:33 PM

I sent it in private message

Erisa•8/22/23, 12:44 PM

I dont believe it exists anymore

EErisa Are you able to share a link?

jimango•8/22/23, 12:47 PM

could it be some settings I need to tick in Cloudflare panel?

Original message was deleted

Erisa•8/22/23, 12:50 PM

on which pages?

chientrm.com•8/22/23, 1:50 PM

is cache limit 512MB apply to whole account or per domain?

Cchientrm.com is cache limit 512MB apply to whole account or per domain?

Hello, I’m Allie!•8/22/23, 1:50 PM

Per cached value.

Hello, I’m Allie!•8/22/23, 1:51 PM

So it is applied per putput

HHello, I’m Allie!Per cached value.

chientrm.com•8/22/23, 1:51 PM

also, is cache api and cache header same?

Cchientrm.com also, is cache api and cache header same?

Hello, I’m Allie!•8/22/23, 1:52 PM

Not sure what you mean?

HHello, I’m Allie!Not sure what you mean?

chientrm.com•8/22/23, 2:07 PM

I'm reading more docs on cache and 'll be back soon

HHello, I’m Allie!Not sure what you mean?

chientrm.com•8/22/23, 2:35 PM

If I return a png image with this header: 'cache-control': 'public,max-age=31536000,immutable''cache-control': 'public,max-age=31536000,immutable'
Within the max-age time, will it ever miss the cache?

Cchientrm.com If I return a png image with this header: `'cache-control': 'public,max-age=3153...

DarkDeviLOP•8/22/23, 2:47 PM

There are always a chance that things, such as e.g. images, will be evicted from the cache before the max-age has elapsed, such as for example due to inactivity.

I wouldn't personally be expecting to be able to keep an image in cache for a full year, with only one single request to the origin during (the start of) that full year, no matter if we're talking about Cloudflare or any other CDN providers out there.

DDarkDeviL There are always a chance that things, such as e.g. images, will be evicted from...

chientrm.com•8/22/23, 2:49 PM

so the cdn can remove the cache anytime they want?

Cchientrm.com so the cdn can remove the cache anytime they want?

Chaika•8/22/23, 2:52 PM

not only can it evict it at any time, but cache by default is colo (CF Datacenter) specific, and with so many locations you're bound to have a handful of miss's. You can enable Tiered Caching to try to reduce that (the free version selects a colo closest to your origin to check for cache if not in colo, before contacting origin), or Cache Reserve (paid, might be slower then your origin in some cases, it's backed by R2 in a single location)

At that point, I would agree with completely with @James, if I'm understanding him well, that his op

Similar Threads

Similar Threads

Similar Threads