On Thursday, March 26, 2015 4:08 AM [GMT+1=CET], Stephen J. Turnbull wrote:
> J. Gomez writes: > > > > > But I would love to be able to reliably rely on DMARC's > > > > p=reject. > > Even if you can in practice, you can't get to 100.0%. Even at > ducks-in-a-row sites like <frequent-DMARC-contributor-employer.com> > (which is a financial institution and uses that domain for > transactional mailflows), <frequent-DMARC-contributor> has at least > once used his/her "p=reject" address to post to a mailing list I > subscribe to (which didn't implement DMARC). These things happen. Yes, but then in that DMARC rejection which you describe above the Receiver can blame it on the Sender, who did not put his ducks neatly in a row as he should have done. The question is: who bears the cost of DMARC's p=reject "false positives"? As a Receiver, I will be blind and will not obey to Sender's p=reject unless I can blame on said Sender the rejection --derived form the Sender's declared DMARC of p=reject-- of legitimate email. > > The set (DMARC + p=reject) is unreliable, in the current situation, > > because it fails to describe the legitimate and real scenario of > > mailing lists. > > Technically, it does describe them: author domains "should not" use > p=reject if it authorizes indirect mailflows From its mailboxes. AOL > and Yahoo! were abusing p=reject according to the draft of April 2014. That Yahoo and AOL are "abusing p=reject" is a way to see the case. Another way to see it, is that DMARC's p=reject fails to describe real email usage, and therefore is unreliable (i.e., cannot be relied on). Regards, J.Gomez _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
