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. It's possible that the rate of occurance is low enough that you would be happy to set your receiving MTA to reject that post because it failed alignment with the "p=reject" domain. But I might not, preferring to rely on a filter that weights "reject legitimate" (eg, "reject existing correspondent") far more negatively than yours does. Of course it's up to you what you do. I'm just saying that the protocol needs to deal with extreme preferences like the ones I (hypothetically) attribute to myself. > 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. The reason I bring this up is that I find it hard to imagine a world in which, even after that experience, non-transactional mailflows currently covered by p=none would have all of their third party relays registered with a third-party authorization protocol. On the other hand botnets mean that draft-kucherawy-dkim-delegate and draft-levine-dkim-conditional can be massively exploited if ordinary users at those sites are allowed to use those mechanisms without oversight by the author domain. So I suspect that a registry of third parties is an essential precondition for p=reject to be compatible with open-subscription mailing lists. AFAICS, that means that any such protocol is going to be unreliable in the face of a security breach like those at AOL and Yahoo!. Of course you could imagine a world where everybody implements DMARC and p=none doesn't exist. Then Mediators must register or their messages won't be delivered, period. But to me, that's not email. :-( _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
