I know what "p=none" means to the sender, but that is no reason to ignore authentication failures when "p=none" or "no policy".
About DMARC wrong results: We will always have these types of messages: 1) Domain owner messages transmitted and received with authentication 2) Domain owner messages transmitted without authentication 3) Domain owner messages transmitted with authentication but received without authentication 4) Messages originating outside domain owner control for the benefit of a domain member 5) Messages originating outside domain owner control for bad purposes "p=reject" simply tells the evaluator that the domain owner believes he will never see a message in category 2. In many cases, this assertion is even true, but alas not always. The domain owner cannot know whether the evaluator will receive messages in category 3 or 4. Nor can he tell the evaluator how to distinguish unwanted category 5 messages from the messages in category 3 or 4. My main point was that DMARC FAIL is always a probability, not a certainty, so evaluators who treat it as a certainty are unwise. But about how to handle "p=none": "p=none" says that the evaluator might receive a message in category 2. Based on this discussion, another reason for "p=none" is that the domain owner is afraid of category 3 and 4 messages being rejected if they move to "p=reject". The only way for an evaluator to distinguish between the last three categories is to examine messages in greater detail, so that a judgement can be made about the identity of the sender and the motivation of the sender. This really needs to be done only once. After concluding that the sender is malicious or his messages are unwanted, the sender needs to be blocked. After concluding that the sender is benign and his messages are wanted, a local policy needs to be configured to authenticate that mail stream using alternate methods. (Alternate authentication does not require exemption from content filtering.) Since any unauthenticated message carries an impersonation risk, every unauthenticated message should be considered for in-depth review. As reviews are completed, the volume of messages requiring review gets steadily smaller. As you observed, lots of authenticated accounts are used for malicious purposes, but that is not relevant here. Experience has shown that unauthenticated traffic has a high percentage of malicious and unwanted messages, so time spent pruning out that traffic is time well spent. If there is value in the sender's disposition policy, it is as a tool for prioritizing which messages should be reviewed first. Doug Foster On Sun, Jul 16, 2023 at 6:50 PM OLIVIER HUREAU < [email protected]> wrote: > 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
