This has nothing to do with MUST mandates. We are trying to write a document that people will choose to implement. Todd, in particular, has written several times about the principle that feedback reporting is critical to the success of DMARC. It is therefore appropriate to ask why a significant group of stakeholders have decided that they don't need to implement the whole design. If we are failing to meet their needs, we should ask whether that failure can be corrected.
The rest of the data leakage discussion is best understood in terms of game theory between an attacker and a defender. Reporting suggests that DMARC is not only evaluated but also enforced, so an attacker perceives a reduced probability of success, and is less likely to attempt an attack. Conversely, absence of reporting decreases the probability that DMARC is evaluated and enforced, and therefore the attacker perceives an increased probability of success. When a server does reporting on only some domains, what does that do to the perceived probability of success when attacking a non-reporting domain? I think an attacker will reasonably conclude that it makes the probability pretty high, and the increased probability of success also increases the probability of an attempted attack. But of course, perceived probability of success does not matter if the perception is wrong. A server that enforces DMARC for all domains, whether reported or not, does not need to fear a successful impersonation attack. They may even be happy to have the attack because it gives them information needed to block the source and gain protection from other attack types. But a defender does need to worry. Which is why my original language started with the state of the defender: If a defender enforces and reports DMARC on some domains, while ignoring DMARC on other domains, then the reporting process gives valuable information to the attacker. The existence of partial reporting makes an impersonation attack on the unprotected domains more likely, and the actual lack of defenses means that the impersonation will not be detected. Therefore, (a) Domains with DMARC reporting are less likely to see an impersonation attack attempted. Reporting becomes desirable even if DMARC enforcement is not applied. Therefore it is in every recipient domain's interest to publish reports, unless the domain enforces DMARC but uses impersonation attacks as a honeypot. Consequently, I was surprised to find major players that do not report, hence the question. (b) Domains without DMARC reporting are at increased risk of an impersonation attack because they do not report. If DMARC enforcement is also missing, those attacks will not be blocked. (c) Domains that neither enforce nor report are at increased risk when they are part of a server farm that reports on other hosted domains. My original point was to identify the evaluator's self-interest and document the situation in a way that helps evaluators act in their own self interest. My more recent topic is trying to ensure that our reporting plan is aligned with everyone's self interest, to maximize beneficial voluntary participation. Doug On Mon, Nov 21, 2022 at 3:14 AM Laura Atkins <[email protected]> wrote: > > > On 21 Nov 2022, at 01:13, Murray S. Kucherawy <[email protected]> wrote: > > On Sun, Nov 20, 2022 at 11:33 AM Douglas Foster < > [email protected]> wrote: > >> That is helpful, thank you. It says to me that their non-participation >> does not have any direct implications for what we are trying to do. >> >> Specifically, it is not that DMARC has too many false positives, or that >> the processing effort is unacceptable. It is simply a reflection of their >> assessment that valuable information should be purchased from them, not >> given away for free. >> > > I think this is a bit of a cynical viewpoint. There are other simpler > reasons not to participate in reporting. Off the top of my head: > > 1) It is a non-trivial compute, storage, and maintenance cost a report > generator has to undertake, proportional to the amount of mail they handle, > and is done largely for the benefit of others. > > 2) The policy part of the protocol works just fine, and is a benefit, > without the reporting component. > > 3) There are risks of privacy leaks, either actual or perceived (or both). > > Many operators' business models would find any one of these hard to > swallow, much less all of them in combination. > > > I repeat what I said previously: > > There is no reason we have to link reporting and policy enforcement for > recipient systems. If we start saying “you have to send reports if you > evaluate DMARC” then it’s not going to lead to more people sending reports > but may lead to fewer people enforcing policy or folks just ignoring the > spec. Neither seems a good result to me. > > Overall, we cannot assume that organizations that are sending reports are > enforcing DMARC policy - I have seen DMARC Fail/Fail, policy p=reject, > disposition inbox in some reports. Nor can we assume that organizations > that are not sending reports are not evaluating / enforcing policy. > > laura > > -- > The Delivery Experts > > Laura Atkins > Word to the Wise > [email protected] > > Email Delivery Blog: http://wordtothewise.com/blog > > > > > > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
