I think this is a bad idea as it adds unnecessary additional complexity. 
Currently, a domain owner can choose to only implement DKIM or SPF on a mail 
stream if they only wish one mechanism to be evaluated.

Further, if there is a (renewed?) desire to apply a policy layer to DKIM signed 
messages, then isn't that what ADSP (RFC 5617) was intended for?

Ken.

________________________________
From: dmarc <[email protected]> on behalf of Brotman, Alex 
<[email protected]>
Sent: Monday 14 June 2021, 18:10
To: [email protected]
Subject: [dmarc-ietf] Sender-supplied decision matrix for passing DMARC

Hello,

I was talking to some folks about DMARC, and a question came as to suggest as 
the domain holder that your messages should always pass DKIM.  Effectively, the 
asker wants to say "I intend to deploy SPF and DKIM, but I will *always* sign 
my messages with DKIM."  So the obvious answer may be "Just only use DKIM", but 
I'm not sure that completely answers the question.  While discussing with 
someone else, "Tell me when DKIM fails, but SPF is fully aligned".  There was 
recently an incident at a provider where they were allowing any sender to send 
as any domain (and I'm aware that's not specifically a DMARC issue).  We all 
know brands that have just dumped in a pile of "include" statements without 
fully understanding the implications.  In this case, other users could send as 
other domains, but perhaps they would not have been DKIM signed.  Should there 
be a method by which a domain holder can say "We want all message to have both, 
or be treated as a failure", or "We'll provide both, but DKI
 M is a must"?

>From a receiver side, it makes evaluation more complex.  From a sender side, 
>it gives them more control over what is considered pass/fail.

How does this look in practice?  Maybe 
"v=DMARC1;p=quarantine;rua=...;pm=dkim:must,spf:should;"
(pm=Policy Matrix)

Does this make everyone cringe, or perhaps worth a larger discussion?

--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc

_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc

Reply via email to