p=reject has two effects: - It makes impersonation attacks less likely to be successful, and - It encourages attackers to chose other domains for impersonation, since attacks on protected domains are more likely to fail.
Therefore, evaluators should expect that most attacks will occur against non-enforcing domains, because: - Non-enforcing domains are the lion's share of all incoming messages, and - Attacks on these domains are more attractive because they are more likely to succeed. Consequently, an evaluator who only worries about p=reject is probably ignoring most of his incoming attacks. Given that the mailing list problem is only described as a problem for p=reject domains, I conclude that an important segment of evaluators are ignoring the largest portion of impersonation attacks. The appropriate security posture is to assume that any unauthenticated message may be an impersonation attack, and risk reduction requires that such messages be studied. Unacceptable messages need an unconditional block rule, and acceptable message need an alternate authentication rule. Those who are unwilling to investigate unauthenticated messages will remain vulnerable to deception. I don't know that obtaining different information from the domain owner will fix this. Doug Fosster On Tue, Aug 22, 2023 at 11:40 PM Jesse Thompson <z...@fastmail.com> wrote: > On Mon, Jul 24, 2023, at 1:03 PM, Neil Anuskiewicz wrote: > > > > > On Jul 19, 2023, at 3:21 PM, Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > > > > > > Perhaps you can clarify what you think DMARC is. > > > > Apparently a significant number of evaluators think that "DMARC Fail > with p=reject always means unwanted mail". Or to use Michael Hammer's > language, "DMARC Fail with p=reject means the domain owner wants it > rejected so I will reject it." These are exactly the attitudes that > cause us so much trouble because (a) DMARC Fail with p=reject does not mean > that rejection is always the correct response, and (b) DMARC Fail with > p=none is an important piece of information. > > Doug, if what you’re saying is true then the root cause might be our > fault. If we’ve not communicated clearly enough DMARC’s purpose. A > communication problem likely needs to be solved with more and better > communication via the standards doc itself and other channels. > > > (again, apologies if already suggested, still working my way through the > backlog in my spare time) > > I'm beginning to think that a solution to this problem is "other channels" > > Let's discuss p=interoperability, p=compliance, or p=orgname:policyname > > "By the book" receivers who see an "invalid" policy will treat it no > differently than p=none, and intermediaries will not bother trying to > munge. So, it is achieving the interoperability objectives of IETF > > "Smart" receivers will see that the policy is a reference to a policy > definition that can be queried in some standard fashion. The policy owner > can articulate clearly what the policy means. > > IETF should not be in the business of describing the mail handling > policies that exist in practice or any that will emerge, but should define > how those policies are communicated (for interoperability sake). > > Domain owners interested in achieving compliance will gravitate towards > p=compliance over p=reject (because compliance is what they are trying to > achieve), or they may choose to define their own p=orgname:policyname > namespace if they want to get more specific in describing their intended > mail flows > > Those that wish to express backwards compatibility can use > p=interoperability or a p=orgname:policyname namespace that expresses > policy in some other way > > Jesse >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
