Hi, > The stupid evaluator says, "p=none means no problem here".
And the non-stupid evaluator knows that p=none means that the domain owner doesn't (yet) have the appropriate sending infrastructure to have p=reject. > The appropriate response to an authentication failure is to investigate, not > to block. When I first became interested in DMARC, I thought the idea of forensic reports was brilliant, as I was able to carry out investigations thanks to them. Today, however, forensic reports are not a trend. How can you properly investigate with limited information on the aggregate report? > that maliciously impersonate a major university It is not that related to DMARC but from what I've seen in France, scammers do not spoof domains name. They already have a pool of infected users in other universities and use those credentials to send us phishing emails (all the phishing I have seen comes from authenticated users at other universities) > How did DMARC go wrong? This is just my opinion, and I've published very little on this list. I just curiously read the discussions (especially the catchy subject like this one). I think DMARC went wrong as soon as the big organizations started to break away from the IETF and RFC7489 in particular. You only have to look at the inconsistencies between what is suggested and stated in the RFC and what happens in reality to understand why it went wrong. Best, Olivier Hureau De: "Douglas Foster" <[email protected]> À: "IETF DMARC WG" <[email protected]> Envoyé: Samedi 15 Juillet 2023 13:27:04 Objet: [dmarc-ietf] How did DMARC go wrong, and how does our document fix it? Murray recently observed, correctly, that something went horribly wrong with the DMARC rollout, because it caused (continues to cause) many safe and wanted messages to be blocked. My assessment was in a recent post: Something about the language of RFC 7489 caused implementers to focus on blocking individual messages, when the appropriate use of DMARC is to identify and investigate potentially malicious sources. The "message blocking" approach violates the interests of the users it is intended to protect: - An attacker sends 10 messages that maliciously impersonates a big bank. With help from DMARC p=reject, the evaluator blocks them all. The attacker follows up with 10 messages that maliciously impersonate a major university. The stupid evaluator says, "p=none means no problem here". The message is accepted and the user is harmed because the evaluator learned nothing from blocking the successful attack. Consider a variant of the above: The attacker never impersonates a big bank with p=reject, it only impersonates big universities with p=none. The foolish evaluator blocks nothing because it only acts on domains with p=reject. Again, the user is harmed. And we know the flip side: Safe and wanted messages get blocked because p=reject is enforced without investigation against mailing lists and other traffic. Security theory says that ANY unauthenticated message COULD be a malicious impersonation, and worthy of investigation. Experience says that malicious impersonations are a small percentage of all unauthenticated messages. As a result, the appropriate response to an authentication failure is to investigate, not to block. I don't know exactly how to communicate the difference between message blocking and sender investigation in DMARCbis, but I sure hope that we will try. Doug Foster
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
