Controversy around SPF: Difference between revisions
No edit summary |
mNo edit summary |
||
| (One intermediate revision by the same user not shown) | |||
| Line 3: | Line 3: | ||
When E-Mail was documented in 1982, E-Mail was meant to be decentralised. The uprise of [[ISP|ISPs]], such as Yahoo, Hotmail and Gmail, a few decades later, has defeated this purpose. | When E-Mail was documented in 1982, E-Mail was meant to be decentralised. The uprise of [[ISP|ISPs]], such as Yahoo, Hotmail and Gmail, a few decades later, has defeated this purpose. | ||
Big ISPs tend to store all their IPs in a single SPF record. Customers who use their own domain for sending are instructed to add an include to this SPF record to their own domain. This way, all domains sending via - for example - Gmail have all Gmail IPs included in their SPF record. Impersonating a Gmail customer's domain on a Gmail SMTP connection would principally result in SPF pass. Most ISPs - also Gmail - have security measures in place to prevent their users from sending with any domain the are not authorised to send with, but security researchers have recently been able to circumvent those measures. | Big ISPs tend to store all their IPs in a single [[SPF]] record. Customers who use their own domain for sending are instructed to add an include to this SPF record to their own domain. This way, all domains sending via - for example - Gmail have all Gmail IPs included in their SPF record. Impersonating a Gmail customer's domain on a Gmail SMTP connection would principally result in SPF pass. Most ISPs - also Gmail - have security measures in place to prevent their users from sending with any domain the are not authorised to send with, but security researchers have recently been able to circumvent those measures. | ||
Because [[DMARC]] requires SPF ''or'' [[DKIM]] alignment to pass, this discovery also compromises the security of the DMARC protocol. And because [[BIMI]] depends on DMARC, also BIMI can't be trusted anymore on big ISPs plattforms as long as this issue hasn't been solved. | Because [[DMARC]] requires SPF ''or'' [[DKIM]] alignment to pass, this discovery also compromises the security of the DMARC protocol. And because [[BIMI]] depends on DMARC, also BIMI can't be trusted anymore on big ISPs plattforms as long as this issue hasn't been solved. | ||
| Line 9: | Line 9: | ||
=Mailchannels= | =Mailchannels= | ||
One extreme example of an [[ESP]] that doesn't limit users to sending with their own domains is [https://support.mailchannels.com/hc/en-us/articles/16918954360845-Secure-your-domain-name-against-spoofing-with-Domain-Lockdown- Mailchannels]. Mailchannels is one of the larger senders. Yet - as of September 2023 - they facilitate impersonation of unauthenticated domains as if it were a feature and, according to their CEO, they have no intention to stop doing so. After [https://youtu.be/NwnT15q_PS8 the company was exposed on DEFCON 31 (2023)], Mailchannels developed a feature named "[https://support.mailchannels.com/hc/en-us/articles/16918954360845-Secure-your-domain-name-against-spoofing-with-Domain-Lockdown- Domain Lockdown]". Mailchannels customers now actively have to set an additional [[DNS]] TXT record in order to limit abuse of their own domain. | One extreme example of an [[ESP]] that doesn't limit users to sending with their own domains is [https://support.mailchannels.com/hc/en-us/articles/16918954360845-Secure-your-domain-name-against-spoofing-with-Domain-Lockdown- Mailchannels]. Mailchannels is one of the larger senders. Yet - as of September 2023 - they facilitate impersonation of unauthenticated domains as if it were a feature and, according to their CEO, they have no intention to stop doing so. After [https://youtu.be/NwnT15q_PS8 the company was exposed on DEFCON 31 (2023)] by Marcello Salvati, Mailchannels developed a feature named "[https://support.mailchannels.com/hc/en-us/articles/16918954360845-Secure-your-domain-name-against-spoofing-with-Domain-Lockdown- Domain Lockdown]". Mailchannels customers now actively have to set an additional [[DNS]] TXT record in order to limit abuse of their own domain. | ||
Mailchannels customers are usually instructed to set an SPF include that includes all Mailchannels IPs. Combined with the allowance of domain spoofing, this renders all SPF-verifications in mail from those IPs useless. This shows again how severely the weakness in SPF can compromise DMARC and BIMI. | Mailchannels customers are usually instructed to set an SPF include that includes all Mailchannels IPs. Combined with the allowance of domain spoofing, this renders all SPF-verifications in mail from those IPs useless. This shows again how severely the weakness in SPF can compromise DMARC and BIMI. | ||
Latest revision as of 20:41, 21 September 2023
When E-Mail was documented in 1982, E-Mail was meant to be decentralised. The uprise of ISPs, such as Yahoo, Hotmail and Gmail, a few decades later, has defeated this purpose.
Big ISPs tend to store all their IPs in a single SPF record. Customers who use their own domain for sending are instructed to add an include to this SPF record to their own domain. This way, all domains sending via - for example - Gmail have all Gmail IPs included in their SPF record. Impersonating a Gmail customer's domain on a Gmail SMTP connection would principally result in SPF pass. Most ISPs - also Gmail - have security measures in place to prevent their users from sending with any domain the are not authorised to send with, but security researchers have recently been able to circumvent those measures.
Because DMARC requires SPF or DKIM alignment to pass, this discovery also compromises the security of the DMARC protocol. And because BIMI depends on DMARC, also BIMI can't be trusted anymore on big ISPs plattforms as long as this issue hasn't been solved.
Mailchannels
One extreme example of an ESP that doesn't limit users to sending with their own domains is Mailchannels. Mailchannels is one of the larger senders. Yet - as of September 2023 - they facilitate impersonation of unauthenticated domains as if it were a feature and, according to their CEO, they have no intention to stop doing so. After the company was exposed on DEFCON 31 (2023) by Marcello Salvati, Mailchannels developed a feature named "Domain Lockdown". Mailchannels customers now actively have to set an additional DNS TXT record in order to limit abuse of their own domain.
Mailchannels customers are usually instructed to set an SPF include that includes all Mailchannels IPs. Combined with the allowance of domain spoofing, this renders all SPF-verifications in mail from those IPs useless. This shows again how severely the weakness in SPF can compromise DMARC and BIMI.
ARC
The exposure video from DEFCON also showed another interesting fact: ARC headers may be trusted over inhouse authentication results and so the usage of ARC poses more of a security threat, than a remedy against bad mailing practices. Wikipedia states:
Validating an ARC chain only makes sense if the receiver trusts the ARC signers. In fact, an ARC chain can be counterfeited, so ARC processing applies when receivers trust the good faith of ARC signers, but not so much their filtering practices.
Conclusion
As long as this situation remains as it is, DKIM - locally processed - is the authentication method that's least compromised.