How I define a "Source": To the domain owner, it is all of the environments that need to be touched, as part of a DMARC implementation project, to ensure that they produce DKIM PASS with SPF PASS or DKIM PASS with SPF NONE. It includes corporate employee email, ESPs, CRMs, Web Sites, Shadow IT, etc.
To the evaluator, "Source" is a unique combination of Server domain and Mail From Domain which act as the last hop for a message from a particular domain. These are substantially the same thing, except for external forwarding. The forwarder is not a source that the domain owner can configure, but it is a source for purposes of the evaluator's security analysis. How "Sources" behave: Authentication success or failure is not a series of independent random events. The results are deterministic, based on the configuration (and legitimacy) of the source. A message either originates with authentication or not. It is either received directly or not. If forwarded, the DKIM signature is either intact or invalidated by the forwarder's changes. Perhaps In 2015, there was a presumption that authentication rates were essentially zero, so nobody would object to deferring authentication a little longer on a subset of messages. In 2023, I know that most messages can be authenticated because they are received directly and with SPF PASS. DKIM signatures bring the success rate even higher. SPF errors are common, but can be detected easily and corrected with local policy. When I read the 2015 language in 2023 context, I hear it expecting or perhaps requiring evaluators to ignore obvious evidence of a potential threat, and I cannot ever ask an evaluator to do that. In 2023, 100% authentication is entirely achievable, except for forwarding. Our sender authentication techniques are designed for a world without forwarding, which is why forwarding often involves identity rewrites. Although DMARC can survive forwarding-without-changes, it does not expose forwarding. For forwarded messages, the evaluator needs to know the identities of both originator and forwarder(s), so that reputation can be applied to each one. Currently, we cannot reliably apply all relevant reputations because we lose visibility to important identifiers. If the Mail From is rewritten, then the originating Mail From identity is lost. If the Mail From identity is preserved, then the forwarder identity becomes invisible. In either case, if forwarding is not detected, then the originating server organization identity is presumed to be an unimportant component in the forwarder's infrastructure, so its reputation is not checked. Forwarding is the remaining hole in our security model. Doug Foster On Sat, Sep 9, 2023 at 10:22 PM Murray S. Kucherawy <[email protected]> wrote: > On Sat, Sep 9, 2023 at 11:16 AM Douglas Foster < > [email protected]> wrote: > >> I understand the phased roll-out goal, but phased rollout and percentages >> are not applicable to the evaluator's task. >> > >> I start with an assumption that message sources reflect the character of >> the individual or organization that controls the source. Malicious >> traffic comes from malicious people. Innocuous traffic comes from >> non-malicious people. Determining the identifier which indicates >> the responsible people can be a little tricky, but once the responsible >> identifier is determined, it is a binary issue >> >> [...] >> > > I think this is ascribing layers of complexity to what was supposed to be > a simple capability. Maybe that's the way things are now and not how they > were in 2015, but really, if I as a sender am using "pct=" then I'm not > confident in the outcome, and as a receiver I think it's reasonable to > infer that you shouldn't be either; the sender is experimenting. Trying to > divine spam vs. ham in such a situation is to my mind about as reliable as > dowsing. > > >> DMARC flags possibly-suspicious senders, not possibly-suspicious >> messages, and an evaluator should use it accordingly. >> > > How is that possible, when different messages even from this domain take > different paths to their destinations, and can easily result in different > outcomes? > > >> Assume that Example.com is at 70% rollout, which means that of their 10 >> sources, 7 are DKIM-signing, two are doing SPF-only, and 1 is a non-signing >> ESP. >> > > I don't understand your use of "source". Are you saying example.com has > 10 different entities sending mail using that domain? If so, I can assure > you that none of that was considered when we defined "pct" in the first > place. > > The definition of "pct" doesn't talk about sources, it talks about > individual messages, evaluated independently. It's meant to be applied in > aggregate across all messages purporting to be from that domain, > independently and irrespective of source. > > -MSK >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
