RFC 7489 takes 8 different authentication mechanisms and lumps them into a single PASS result: DKIM or SPF, each with up to four types of alignment: same domain, parent->child, child->parent, and sibling->sibling
These eight mechanisms all provide some level of confidence that the message is not impersonated, but they do not provide an equal level of confidence. Unsophisticated senders have little incentive to use the higher confidence mechanisms because any PASS result is still PASS. The solution is not to pretend that SPF is worthless, because that is an overstatement. The solution is to talk about the differences in confidence provided by the different authentication methods, and note that evaluators have reason to distrust some of them. That distrust could cause a weakly authenticated message to be distrusted by some evaluators. Similarly, needs multiple types of FAIL. Since the data indicates that missing (or invalid) public keys are a significant portion of all failures, it needs a separate failure code from "normal" failures which suggest in-transit changes. The DKIM group needs to define the result code but this group would need to integrate it into our aggregate reports. On Fri, Jun 16, 2023 at 5:52 AM Sebastiaan de Vos <sebastiaan= 40inboxsys....@dmarc.ietf.org> wrote: > > > Many thanks. That figure seems to be more or less in agreement with > > what others here have obtained on smaller samples. However small, it > > may confer to SPF the role of a stabilizer in DMARC mail flows. > > How could SPF be a stabilizer when it's proven to be a highly unreliable > mechanism? I'd rather consider that a de-stabiliser. From what I > understand, SPF is part of the problem, not part of the solution. > > Sebastiaan > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
