Good morning DMARC
I’m thinking I may need to deploy DMARC report automation sooner rather than later.
… and so on, and on, and on for a lot further down the mailbox.
I’m thinking I may need to deploy DMARC report automation sooner rather than later.
… and so on, and on, and on for a lot further down the mailbox.
On Friday I talked a little about DMARC being a negative assertion rather than an authentication method, and also about how and when it could be deployed without causing problems. Today, how DMARC went wrong and a partial fix for it that is coming down the standards pipeline.
What breaks?
DMARC (with p=reject) risks causing problems any time mail with the protected domain in the From: field is either sent from a mailserver that is not under the control of the protected domain, or forwarded by a mailserver not under the control of the protected domain (and modified, however trivially, as it’s forwarded). “Problems” meaning the email is silently discarded.
This table summarizes some of the mail forwarding situations and what they break – but only from the original sender’s perspective. (If forwarding mail from a users mailbox on provider A to their mailbox on provider-Y breaks because of a DMARC policy on provider-A that’s the user’s problem, or maybe provider-A or provider-Y, but not the original sender’s.)
A security researcher has identified a rendering flaw that allows for “perfect” phishing emails. From his website:
Read MoreA number of companies in the email industry have been working on a way to better identify authenticated emails to users. One proposal is Brand Indicators for Message Identification (BIMI). A couple weeks ago, Agari announced a pilot program with some brands and a number of major consumer mail providers. These logos should be available in the Yahoo interface now and will be rolling out at other providers.