The need for separate DKIM failure codes to be able to separate between
in-transit changes and public key errors is more than just valid and I
don't consider SPF worthless in general, but I just find it disturbing
how the obviously misplaced confidence in SPF currently weakens the
whole DMARC standard.
Is it not in our best interest to encourage and motivate in particular
the less sophisticated senders to use the higher confidence mechanisms?
On 16.06.23 13:02, Douglas Foster wrote:
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.
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
