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. 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. 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. Regard, J.Gomez _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
