It also cuts down on legitimate mail that users get sent. Probably 90% of the email I send fails DMARC even though I have SPF set up and DKIM sign everything because it tends to go via lists that have not adapted to the world of DMARC.
I did publish a p=None DMARC record, so presumably I don't personally need to care about this, but typically small senders don't pay a huge amount of attention to things like new email authentication technologies. Based on your blog post, I see you're only using this for positive assertions. That's something which, as a receiver, I think you are certainly free to do, but it's not something that should be standardized. Since it's strictly an internal processing issue, there's no need to put this in an RFC and lots of reason not to. Scott K On Tuesday, March 15, 2016 08:04:52 PM Terry Zink wrote: > +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-bestguesspas > s-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 _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
