> -----Original Message----- > From: dmarc [mailto:[email protected]] On Behalf Of J. Gomez > Sent: Tuesday, March 24, 2015 4:39 PM > To: [email protected] > Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) > > On Tuesday, March 24, 2015 5:14 PM [GMT+1=CET], Stephen J. Turnbull > wrote: > > > J. Gomez writes: > > > > > I think we are not talking about the same thing: when I said > > > "depends on DMARC's success", I meant "depends on DMARC's success > as > > > an implemented technology in the real world", whereas it seems you > > > understood "depends on a successful DMARC check". > > > > No, we are talking about the same thing. What I am saying is that > > DMARC is already a "success as an implemented technology in the real > > world" by any reasonable standard, because it *does* work for exactly > > the transactional mail flows you worry about. > > I do not agree. As long a major ESPs downgrade p=reject to p=quarantine or > even p=none on reception of email which fails DMARC checks from domains > whose Owner has published p=reject, DMARC is little more than a reporting > protocol as Vlatko Salaj has already said in another post to this list. Which > is > nice, but is not a "success as an implemented technology in the real world" > for DMARC, because DMARC aims to be more than just a reporting tool. >
Mailbox providers/ISPs are going to do what they do. Recognizing local policy is one of the reasons that the large mailbox providers/ISPs decided to validate DMARC and play ball. By and large they get it right (at least in my experience and I've been doing DMARC since before it was public). Even for transactional mail from originators which have control over their mail flows, there will always be some small percentage of mail that gets broken because of certain types of forwarding (beyond mail lists). From my perspective, when a mailbox provider/ISP chooses to implement local policy over my request (through a published p=reject policy) then they are taking responsibility for their decision. To demand more from them is simply unrealistic. Any organization can publish a standard - the real proof is the extent to which people adopt that standard. > I know for sure I will publish only p=none for my client's domains, and use > DMARC only as a reporting tool, as long as DMARC's p=reject cannot be > reliably relied on. But I would love to be able to reliably rely on DMARC's > p=reject. > My experience is that the overwhelming majority of time you can reliably rely on DMARC's policy implementation - and I'm looking at a corpus of Billions of sent mail. You can check this yourself by looking at the reporting you receive. If mailbox providers would have overridden your p=reject it will show in the reporting you receive and you can gauge the potential outcome yourself. You are making assertions that the data doesn't support. Mailbox providers have no incentive to randomly override DMARC with local policy for non-trivial reasons. The real problem is that once you get past the top mailbox providers, the remainder of them don't have the resources/expertise/large enough data sets to implement local policy overrides in a manner that is workable and sustainable. Perhaps someone can make a go of offering this as a service - perhaps not. > In fact, I think that if at the end of all this process we cannot find a way > to > make p=reject to be reliably relied on, then p=reject should be suppressed > from the DMARC formal specification, as p=reject would effectively be equal > to p=do-whatever-who-cares. > Mike _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
