+1 to virtual DMARC, -1 to the arguments against it. Office 365 already supports something like this for our customers to cut down on Business Email Compromise. Maybe 5% of our customers have DMARC records, yet we treat all inbound email destined to them as having p=quarantine and then we figure out roughly who is allowed to send email as them even when (especially when) they don't authenticate. I talk about this here: http://aka.ms/AntispoofingInOffice365.
We've been doing DMARC lookups on the header.from and stamping the result for a while now, and if it doesn't publish DMARC but would have passed if it did, we stamp the result and call it "Best Guess Pass". However, we use relaxed alignment, not strict. I talk about this here: http://blogs.msdn.com/b/tzink/archive/2015/05/06/what-is-dmarc-bestguesspass-in-office-365.aspx Figuring out implicit/virtual DMARC for everyone else is a much bigger body of water to boil, but is roughly the same problem. As a large receiver we have overrides for DMARC failures anyway, so implicit/virtual DMARC would have those same overrides. > Firstly, DMARC is an opt-in protocol for good reason. I'm saying this tongue-in-cheek, but that "good reason" is "very limited deployment in practice." If we would have waited for customers to publish DMARC records we'd be at 6% adoption rate. > In your first phase, p=none, this will have no effect. In your middle phase, > p=quarantine, this will cause massive loss of wanted email ... In your > final phase, p=reject, there will continue to be massive loss of wanted email. If large email receivers start junking messages because of implicit/virtual DMARC failures, senders figure it out eventually even without DMARC reporting. There's more tools in our toolbox than just junking. For example, we can add visual warnings to the message. We can choose not to extract/promote content if the header.from doesn't align with the SPF/DKIM domain (i.e., an airline sends a flight confirmation and that info is not shown to the user in a rich manner). We can add throttling limits. And so forth. -- Terry -----Original Message----- From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Steve Atkins Sent: Tuesday, March 15, 2016 5:33 AM To: dmarc Subject: Re: [dmarc-ietf] I-D Action: draft-akagiri-dmarc-virtual-verification-00.txt > On Mar 14, 2016, at 11:28 PM, Kouji Okada <o...@lepidum.co.jp> wrote: > > We have submitted a draft about DMARC default verification > for domains not publishing DMARC records. > Any comments will be appreciated. Summary: If a domain does not opt-in to using DMARC, treat the domain as though it had opted-in to using DMARC with "p=none adkim=s aspf=s". Once that's deployed, change it to "p=reject adkim=s aspf=s". Possibly do "p=quarantine" between the two. There are multiple problems with this suggestion. Firstly, DMARC is an opt-in protocol for good reason. It's a lot of work to clean up all the mail streams for a domain such that all email is authenticated. In many cases it is impossible to do so. Those domains that have not done so should not publish a DMARC record. Requiring DMARC-esque authentication (let alone strict alignment) from domains that are not ready to use DMARC will cause a lot of wanted email to be treated as having failed that test. In your first phase, p=none, this will have no effect. The value of using p=none in DMARC is so that domains can take advantage of DMARC reporting without loss of legitimate email. You have no reporting, so this provides no value. In your middle phase, p=quarantine, this will cause massive loss of wanted email while still providing no feedback to senders. In your final phase, p=reject, there will continue to be massive loss of wanted email. In none of those phases does your draft add any value. If a receiver wants to pay attention to whether mail is authenticated or not it can already do so, and it can do so much more effectively than any approach that requires strict DMARC style alignment. Cheers, Steve _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
