Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

[Sebastiaan de Vos <[e-mail]>]

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.