Douglas, With all due respect, I think that your demonstration is biased since your first assertion :
"Fail with Reject equals malicious, Fail with None is unimportant" RFC 7489 describes the handling policies as the policy a domain owner "wishes" to be applied when emails fail the DMARC check mechanism. It does not say that the email receiver MUST follow the handling policy. To prove my point : "These receivers can use these results to determine how the mail should be handled." RFC 7489, Introduction [ https://datatracker.ietf.org/doc/html/rfc7489#section-1 | https://datatracker.ietf.org/doc/html/rfc7489#section-1 ] "Recipient transport service either delivers the message to the recipient inbox or takes other local policy action based on the DMARC result (not shown)" RFC 7489, Flow Diagram [ https://datatracker.ietf.org/doc/html/rfc7489#section-4.3 | https://datatracker.ietf.org/doc/html/rfc7489#section-4.3 ] "p: Requested Mail Receiver policy (plain-text; REQUIRED for policy records). Indicates the policy to be enacted by the Receiver at the request of the Domain Owner." RFC 7489, General Record Format [ https://datatracker.ietf.org/doc/html/rfc7489#section-6.3 | https://datatracker.ietf.org/doc/html/rfc7489#section-6.3 ] Thus, your assertion, "Fail with Reject equals malicious, Fail with None is unimportant," is, in my opinion, wrong. I would reformulate it as follows: - Fail with p=reject means that the owner of the domain name wishes that the email recipient reject the message. - Fail with None means that the owner does not see any objections to delivering the message if the DMARC check mechanism fails. I agree with you that the behaviors of the evaluators who whitelisted the email from example.com are inappropriate. They should have behaved differently, as I have seen when working in a previous company: - Blocking the message - Do not silently discard it so that the sender, having a bounce back, will enforce the authentication of the email. To answer your immediate questions : > Why are these the only two options? Multiple arguments have already been provided in this mailing list. One of them is that we should need a version bump. The consensus of this WG was against the version bump. > Why should the evaluator delegate this decision to the owner of the From > domain? It does not. Please refer to the first part of this message. > Fix these problems, and I will be happy to stop objecting to this document. I may be wrong, but those problems are not part of the Working Group charter ? C.F Murray's email: [ https://mailarchive.ietf.org/arch/msg/dmarc/DDE1ciDa5FEavVtV_SIrKT4bzHQ/ | https://mailarchive.ietf.org/arch/msg/dmarc/DDE1ciDa5FEavVtV_SIrKT4bzHQ/ ] However, an RFC with Informational status about email delivery wouldn't be more helpful than trying to fit everything into dmarcbis? Best, Olivier Hureau De: "Douglas Foster" <[email protected]> À: "IETF DMARC WG" <[email protected]> Envoyé: Mercredi 16 Octobre 2024 12:27:32 Objet: [dmarc-ietf] Re: AD Evaluation for draft-ietf-dmarc-dmarcbis-33 At this point in document maturity, an accusation of bad design should be easily refuted by available evidence. But this cannot be done because we already have an entire RFC that documents the flaws. The DMARC design flaws, which DMARCbis preserves, are: * Fail with Reject equals malicious * Blocking individual messages is a sufficient response to "Fail with Reject" * Fail with None is unimportant To illustrate these problems, assume that an omniscient observer knows that 100 messages arriving to an evaluator from Example.Com will have these characteristics: * 94 authenticated and wanted * 3 unauthenticated and wanted * 3 unauthenticated and malicious DMARC and DMARCbis provides two outcomes: * If the sender policy is "reject" and the evaluator follows that policy, 6 messages are blocked, 3 of which are wanted, but all 3 attacks are blocked. * If the sender policy is "none" or the evaluator ignores that policy, all 100 messages are allowed, included the 3 attacks So the immediate questions are: * Why are these the only two options? * Why should the evaluator delegate this decision to the owner of the From domain? Further assume that for whichever reason, the relaxed approach is taken and all 100 messages proceed to content filtering. The evaluator gets lucky because all 3 attacks are blocked, and he has a perfect outcome for his users -- at first. But it leaves a ticking time bomb. Now assume that some of the authenticated messages get blocked by content filtering because they contain "franchise" and "wire transfer", words that keep showing up in spam. To solve this problem, the evaluator chooses to whitelist messages from Example.Com. This whitelists the wanted messages as well as the malicious attacks, triggering the time bomb, and the evaluator's network is successfully penetrated. What should have happened: * Both authentication failures and content filtering blocks should be investigated to the responsible party, and those responsible identifiers blocked. * Sender policy has little importance because all authentication failures need to be investigated and resolved. * Whitelisting rules should only be applied to authenticated messages. Fix these problems, and I will be happy to stop objecting to this document. Enforcing sender authentication has been a huge win to my network security. DMARC has the right idea, but it takes shortcuts that make it unsuitable as a general tool. The solution is not to minimize reject policies, as DMARCbis suggests. The solution is to put effort into evaluating DMARC results. Doug Foster On Mon, Oct 14, 2024 at 7:06 AM Douglas Foster < [ mailto:[email protected] | [email protected] ] > wrote: It is not about fixing the text, it is about fixing the design. Authentication has only 2 states: * Authenticated, therefore judged free of impersonation risk * Unauthenticated, therefore possibly an impersonation and possibly a malicious impersonation. The Unauthenticated result can occur for many reasons other than malicious impersonation, and many unauthenticated messages are actually acceptable. Therefore, an unauthenticated result is always an ambiguous result. Ambiguity always requires collection of additional information. Authentication state is an attribute of a mail stream. When information gathering resolves an ambiguity, that new information must be codified into local policy, so that the ambiguity is eliminated for all future messages with the same characteristics. For unwanted mailstreams, the local policy is implemented as a block rule. For wanted mailstreams, the local policy is implemented as an alternate authentication rule. An alternate authentication rule is always possible once the responsible identifier is determined. Some mail flows cause authentication to be lost in transit, while other mail flows cause authentication to be gained in transit. Consequently, the true Authentication state cannot always be determined using the final state of the message. Authentication analysis will be a process of continuous improvement to ensure that indirect mail flows are handled optimally. - - - Since the group has spent years working from inferior design assumptions, can we fix the problem with a Best Practices document? Doug Foster BQ_BEGIN BQ_END _______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
