On Tuesday, March 15, 2016 04:06:42 PM Franck Martin wrote: > ----- Original Message ----- > > > From: "Terry Zink" <tz...@exchange.microsoft.com> > > To: "dmarc" <dmarc@ietf.org> > > Sent: Tuesday, March 15, 2016 1:04:52 PM > > Subject: Re: [dmarc-ietf] I-D Action: > > draft-akagiri-dmarc-virtual-verification-00.txt > > > > +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-bestguesspa > > ss-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. > > Yes, it may not be cool to call it Virtual DMARC, but basically it is > applying the DMARC logic, to pass information to other layers. > > Google has been doing virtual SPF (aka best guess SPF) for a while. The name > is confusing, and mixing the results of two systems may produce > non-comparable metrics. > > I think the point, is that several of us have been doing this for quite a > while and this has been useful in our own internal networks, I'm not sure > it needs to be formalized to the rest of Internet, except may be under > informational status or under a (B)CP.
SPF Best Guess is a horrible idea that should never have been invented and should die as soon as possible. http://www.openspf.org/FAQ/Best_guess_record SPF (and DMARC) are opt-in protocols. Trying to infer DMARC like things about non-participants in DMARC is just wrong. It is not an accident that SPF Best Guess apperas nowhere in RFC 4408 nor RFC 7208. It shouldn't be a model for anything. Scott K _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
