I don't think it covers the problem. Section 7.4 does not address the problem of credential upgrade. I expected that my software would need the ability to override false FAIL results. Creating appropriate data structures and processing logic to do so was pretty easy. Detecting and correcting false PASS created by credential upgrade will require a substantial redesign of my filtering logic. Based on my limited knowledge of other environments, I think the entire ecosystem is poorly prepared to detect false Pass. Our document should address the problem.
The document does not articulate that the root of all DMARC limitations is its attempt to discern a message's initial authentication state using the it's final state. ARC is valuable because it helps to document prior message state. Data used to reject a possibly-suspicious message does not need to be verified. Data used to accept a possibly-suspicious message should be verified, since the attacker may attempt to manipulate that data in his favor. Consequently, ARC is always actionable if it triggers a block action. ARC can be actionable for allow if the ARC set author is trusted to report accurately, and a large portion of incoming messages come from infrastructure resources that are trusted to act in good faith, even if their clients do not. ARC deserves better treatment than the throwaway line that it has been given. The discussion of mailing list problems has an assumption that problems will only occur with p=reject policies. We should restate that this is only true if evaluators ignore our advice that "Fail with p=reject" is an ambiguous result because DMARC is a heuristic. More importantly, it implies that "Fail with p=none" is inconsequential and will (and should?) be ignored by most evaluators. We have no reason to believe that attackers will limit their efforts to p=reject policies, yet we provide no guidance about how to handle malicious impersonation in the absence of p=reject. Doug Foster On Sun, Nov 17, 2024 at 1:37 PM Murray S. Kucherawy <[email protected]> wrote: > On Mon, Oct 21, 2024 at 8:51 AM Todd Herr <todd.herr= > [email protected]> wrote: > >> Issue is here - >> https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/155 >> > > Does the WG consider this issue closed by the latest draft? It's still > open and the pull request John produced isn't attached. Just trying to tie > up loose ends before we move ahead. > > -MSK > _______________________________________________ > 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]
