Doug, I think the issue here is that I disagree with your premise, so the rest of the argument fails for me:
> The goal is to partition all incoming messages into two mutually exclusive > groups: Those messages which > originated under domain owner control, and those which originated under > domain owner control, and those > which originated outside domain owner control. This requires two things: I don't agree with the characterization of the second group. I would say that we are partitioning messages into these two groups: - Those for which we can confirm that they originated in the domain they say they did. - Those for which we can not confirm that. Note that the second of those is subtly different to your characterization, in that there's a difference between knowing that they did not originate in the domain... and not knowing whether they did or didn't. It has never been a claim of either DKIM or SPF that we can know anything in particular about a message when validation fails: all either of them tells us is that validation has failed. As Jim says, DKIM is very clear about that, when it tells us to treat a validation failure the same as an absent signature. Any proposal that tries to treat a signature that fails to validate in any special way is a non-starter, as it violates DKIM. Barry On Sat, Jul 17, 2021 at 8:38 AM Douglas Foster <[email protected]> wrote: > > > The goal is to partition all incoming messages into two mutually exclusive > groups: Those messages which originated under domain owner control, and > those which originated under domain owner control, and those which originated > outside domain owner control. This requires two things: > > - First, that at origination, credentials are in place so that a first-hop > MTA can reliably perform this partitioning. I have a much longer analysis, > but the short version is that this requires an aligned and verified DKIM > signature on all messages. There is no partial participation, which is why > the percentage notion needs to be discarded. Of course, fully authenticated > messages are always detectable. However, in the absence of DKIM on all > messages, the partitioning is not possible because both domain owner and > non-owner messages will both fail to be authenticated. > > - Secondly, the message addresses and the associated DKIM credential must be > preserved until the message is received. We know that this is not the case > because forwarding with changes will break the DKIM signature. The absence > of verification does not reliably indicate the absence of domain owner > control, it can result from a domain owner message which was modified or a > non-owner message which was received in transit for any reason. > > Consequently, we need three categories: > 1) Messages which can be reliably attributed to the domain owner because > authentication passess. > 2) Messages which can be reliably attributed to non-owners because of a > repudiation rule. > 3) Messages which are ambiguous because they neither meet an authentication > rule nor meet a repudiation rule. > > When we acknowledge this three-category reality, we have solved the mailing > list problem. Mailing list messages can never be in category one. They > belong in category 2. The current DMARCv1 specification forces them into > category 3. The two-possibility worldview creates the problem. The > three-possibility worldview solves the problem. > > I suggest these repudiation rules: > > Rule 1: The domain owner asserts that all messages from this domain will > originate with a verifiable DKIM signature. If a message does not have an > aligned DKIM signature, or does not have a DNS public key available for the > scope ID, then the message originated outside domain owner control, As I > have said, this is a mandatory first step to any policy being applied to > non-authenticated mail. > > Rule 2: The domain owner asserts that all messages from this domain will > originate with an SPF policy, including messages from email service > providers. Results of SPF NONE or SPF NXDOMAIN indicate messages that are > outside domain owner control. > > Rule 3: The domain owner asserts that all messages from this domain will > have RFC5322.FROM addresses that "exist". Messages that do not have FROM > addresses which "exist" have originated outside domain owner control. The > definition of "Exists" is still being debated, and I have expressed strong > feelings about the right definition. > > Rule 4: The domain owner asserts that all messages from the domain will > originate with an initial ARC Set. Messages which do not have an ARC Set > from the domain have originated outside domain owner control. I am inclined > to include broken-chain ARC sets in this rule, but John would be a better > person to clarify this question > > Everything that is not authenticated or repudiated is in category 2. I > understand that category 2 includes a large number of messages. These > messages require more analysis because the DMARC result is indeterminate. > In most cases, this means that the next step is to put the message through > the full suite of content filters. If the message is not blocked based on > content filters, then it may be desirable to do an in-depth analysis of the > message. Full header analysis is complex, ambiguous, subject to spoofing, and > very much outside of the capabilities of this document. > > Note: I am being careful to use "outside domain owner control" because some > such messages are very much wanted and should not be blocked. Even though > such cases exist, the partitioning effort is indeed useful, because it can be > used to block some unwanted messages. So "p=reject" fails on multiple > levels: It presumes that the domain owner knows that credentials will be > preserved until reception, which is false, and it assumes that > non-credentials messages should always be blocked, which is also false. > "Pct=50" fails because it presumes that partial participation is possible, > and it presumes that a message evaluator will be willing to use a random > number generator to decide message fates. > > Doug Foster > > > Doug Foster > > > On Fri, Jul 16, 2021 at 7:24 PM Jim Fenton <[email protected]> wrote: >> >> On 15 Jul 2021, at 18:07, Douglas Foster wrote: >> >> >> The aligned DKIM signature test can have three conclusions, not just two: >> >> >> >> · Fully Authenticated: A signature is present, a DNS public >> >> key is available, and the key can be used to verify the signature. >> >> >> >> · Provided: A signature is present, and a DNS public key is >> >> available, but the key cannot be used to validate the signature. >> >> >> >> · No Signature or No key: A signature is not present or is >> >> present but the DNS public key is not available. >> >> >> >> If the domain owner indicates that all messages originate with a >> >> signature, then messages with “No Signature or No Key” are verifiably not >> >> from the domain owner and can be confidently repudiated. >> >> Why would “Provided” be handled any differently from “No signature or no >> key”? An attacker can easily provide a signature for a message they are >> spoofing, and after observing some of that domain’s traffic will know what >> selector name to use that has a published public key. >> >> DKIM is very explicit about its results: either the signature verifies or it >> does not. There is no third case. >> >> -Jim > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
