A not-yet mentioned characteristic of impersonating messages is that: "Impersonation requires that a message originate from an attacker-controlled server."
- Mailbox providers require user-level authentication. - Hosting services require domain administrator authentication and use Control Panel tools to ensure that the domain administrator does not create unacceptable configurations. - ESPs require client enrollment and run-time login. Among other reasons, this is necessary to ensure accurate and trusted billing statements. All of these environments can be (and are) used by malicious clients, but they are not usable for impersonation. For message sources that are reliably known to come from one of these environments, DMARC is unnecessary. Forwarding tricks can introduce complexity to this analysis, but the principle stands. Doug On Sat, Sep 9, 2023 at 12:20 PM Murray S. Kucherawy <superu...@gmail.com> wrote: > I'm not looking to change the WG's mind on this matter, but: > > On Sat, Sep 9, 2023 at 3:54 AM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> There are many percentages mixed up together in this issue: >> >> - The percentage of domain message sources which provide proper >> authentication at origination. >> - The percentage of domain messages which originate with proper >> authentication. This is determined by the volume distribution between >> sources, which is likely to be variable. >> - The percentage of domain messages which are received with >> authentication. This will be different for each evaluator, depending on >> the sources from which those messages originate. This is also affected by >> transit issues. >> >> But none of those percentages actually matter. The one that matters to >> the evaluator is: >> >> - The conditional probability that an unauthenticated message is >> actually from the domain and not from an impersonator. For this test, >> the >> denominator depends on the volume of impersonation messages, which is >> completely independent of the domain's message volumes. >> >> > This seems to over-complicate the point. RFC 7489 says that "pct" means: > > Percentage of messages from the Domain Owner's > mail stream to which the DMARC policy is to be applied. > > It goes on to say report messages are excluded from this test. It says > nothing about authentication. Thus, if I get N messages from example.com, > and the "pct" value is X, then the DMARC test is applied only to X% of that > N; the simplest way to do this per-message would be to pick a random number > between 0 and 1 and if it's greater than X%, the message simply bypasses > DMARC altogether. > > That's how we intended it when we wrote that, and that's how early > implementations did it. > > But maybe this is the lesson: People have inferred lots of different > things from that rather straightforward definition, so maybe it's more > ambiguous than we realized all those years ago. > > In RFC 7489, we have a domain-provided percentage whose calculation is >> left undefined. Whatever the calculation, the result has little relevance >> to the evaluator's risk assessment. It is actually harmful to advise >> evaluators to disposition using the sender's percentage and a random number >> generator. >> > > How do you figure "harmful"? The purpose was to enable a graduated > rollout. If 1-X% of those messages are outright ignored, what harm is > being introduced? > > -MSK, participating >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
