>> 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. > > When we use P=REJECT, we assert that anything which cannot be > confirmed is unacceptable. That makes for two pretty disjoint > groups. If Authentication is only to be used to validate a > whitelisting decision, then a one-sided test would be sufficient. In > practice, the primary use for DMARCv1 is to block messages, and much > of our discussion has been around the unwanted disposition that this > places on mailing lists.
Indeed; there is definitely a problem between DMARC's p=reject and mailing lists. > DKIM treats an invalid signature as non-existent. It also treats a > DKIM signature as fully optional. DMARCv1 changes the rules to > gather more usable information from the message. DMARCv1 with > P=REJECT says that a message which lacks authentication is > unacceptable, and since any message might be forwarded, it has > effectively made DKIM non-optional.. So we have already modified the > interpretation of DKIM. Here, again, I disagree with your premise: we have not modified the interpretation of DKIM. Senders still decide whether to sign with DKIM or not, and you're correct that it's a poor quality deployment to use p=reject (or even quarantine) without also deploying DKIM signing. But the interpretation has not changed: a valid DKIM signature still means the same as it always did, and the absence of a valid DKIM signature still means the same as well. We have not created -- and must not create -- an additional state that has been proscribed for a number of good reasons. > I have observed that IF the domain owner indicates that all messages > originate with DKIM signatures, then the presence of a signature is no > longer optional at the evaluation point. As I have said previously, > this provides a valid basis for partitioning messages between > verified, ambiguous, and repudiated. If you accept the premise that > mailing list messages should not always be repudiated, then nothing we > have done up to this point has provided a reliable way to repudiate. > I am saying that this is a problem that we can fix. It does not provide such a valid basis. With your proposal, any attacker can move her message from "repudiated" to "ambiguous" simply by attaching a fake DKIM signature that she knows will never validate. That alone is a reason this plan won't work. > Yes, I have gone radical, and I am no longer willing to be limited by > the design limitations of DMARCv1. I think that's a fine approach, but it has to come with proposals that do not violate the other protocols that we're relying on. Barry _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
