>From what I understand of your email, you would like DMARC to help receivers >in how to properly handles messages. As you mentioned, it is defined by local policies and I don't think it is IETF's role to educated people but to propose protocols that could fit the needs of the community.
> My main point was that DMARC FAIL is always a probability, not a certainty, > so evaluators who treat it as a certainty are unwise. And I think it is a risk some domain owners are willing to take. >From the few discussions I have read in the mailing list, some of you try to >adapt the protocol for the widest audience and forget about the expert that would like stricter policies. I can understand that protocols should be adopted by as many as domain owners possible. However, it is usually not the non-expert audience that is going to push for the adoption of the protocol. I've tried to catch up quickly with all the discussions, but I haven't succeeded, and I may be repeating proposals that have already been discussed. A few years ago, I'd skimmed through a blog post about DMARC. I thought that the DMARC control mechanism would fail if ONE of SPF and DKIM fails and that the purpose of the tags was to indicate your policies on DKIM and SPF for the DMARC control mechanism and not for forensic reporting. Since then, I've bet and won a lot of drinks with "security" administrators and engineers. I think is is normal to think that DMARC would operate like this. I don't know if the question has already been asked here: has it been considered in proposing DKIM and SPF processing policies? Since ADSP has been discontinued, I would find it interesting if domain owners had the ability to influence the DMARC verification mechanism. I apologize if the question has already been answered and if this message has wasted your time. Best, Olivier Hureau De: "Douglas Foster" <dougfoster.emailstanda...@gmail.com> À: "IETF DMARC WG" <dmarc@ietf.org> Envoyé: Lundi 17 Juillet 2023 03:42:35 Objet: Re: [dmarc-ietf] How did DMARC go wrong, and how does our document fix it? 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 < [ mailto:olivier.hur...@univ-grenoble-alpes.fr | olivier.hur...@univ-grenoble-alpes.fr ] > 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" < [ mailto:dougfoster.emailstanda...@gmail.com | dougfoster.emailstanda...@gmail.com ] > À: "IETF DMARC WG" < [ mailto:dmarc@ietf.org | dmarc@ietf.org ] > 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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
