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

[Jan Dušátko <[e-mail]>]

Hi

I would like to know your opinion on the options currently available to 
the system administrator. If it is trying to define a policy that allows 
recipients to authenticate emails, its options are, in my opinion, limited.
- The issue of SPF and cloud systems mentioned, or including over 
networks with mask /8 or /16 is extremely inappropriate
- It is not possible to set up the enforcement of DKIM signatures 
because DomainKey and its policies are not related to DKIM and there is 
no similar technology for DKIM (ADSP is not used)
- If I am the administrator of hundreds or thousands of domains, it is 
in my interest to provide the recipient with information about the 
sender's authentication options. For example, all emails use DKIM, all 
emails use ARC, all emails use SPF ... and if not, you can discard them. 
But I do not have this option with DMARC.
I understand that this is in the middle of what DMARC2 is supposed to 
address. But could there be a possibility for the DMARC2 record 
administrator to define a policy for domains and provide relevant 
information for recipients? It is the recipient's decision whether to do 
this verification, but it is also the sender's decision to offer this 
information. Unfortunately, at this point, either the signature is 
valid, or wrong, or it is not. If it is not possible to accept the 
e-mail, but the recipient does not have the option of verifying whether 
the sender's domain enforces this signature. It is similar with SPF. And 
DMARC2 seems to me to be a good place for these definitions. But I would 
like to avoid of forced removal of SPF, please let it for administrator 
decision.

Regards

Jan

Dne 16. 6. 2023 v 13:28 Sebastiaan de Vos napsal(a):
> 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.
>
>

-- 
-- --- ----- -
Jan Dušátko

Tracker number:	[phone]
e-mail:		[e-mail]
GPG Signature:	https://keys.dusatko.org/E535B585.asc
GPG Encrypt:	https://keys.dusatko.org/B76A1587.asc