Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

[Hector Santos <[e-mail]>]

On 9/27/2020 11:44 PM, Dave Crocker wrote:
> On 9/27/2020 11:22 AM, Scott Kitterman wrote:
>> This seems to me to be an odd view because no RFC is needed to use From and
>> it's relationship to either DKIM signing domain or SPF validated Mail From.
>
> The DKIM d= value establishes no relationship with any other
> identifer, such as the From: field.  At all.  None.

DKIM has a single signature binding requirement, the 5322.From

> DMARC establishes the relationship.

I don't read it that way.

DKIM binds the signer d= domain and the from.domain with no 
enforcement on it nor any indication that they are related when they 
not the same (the missing link). But if they are the same domain, then 
they are viewed as self-signed and 100% related.

But who cares? A blind receiver will not know the actual relationship 
until it sees your DMARC record, if any, and we chose that to be based 
off the 5322.From domain -- the anchor field.

The DKIM POLICY augmented (add-on) technologies published (via DNS) a 
protocol expectation for a direct or indirect relationship.  DMARC 
describes a specific rule for a direct relationship. SSP had its 
rules, DSAP had its rules, and ADSP had its rules. But all of them had 
one thing in common -- an option to publish a public policy describing 
a direct and exclusive 1 to 1 relationship and a strong action is 
authorized when there is a deviation.  That was always the power of 
all this and why we are still here 15+ years.  Without it, imo, we 
would not be here. SPF would not be here if it didn't have a -ALL 
policy with strong authorization to reject with no questions asked.

> To reiterate: Among currently published specifications, without DMARC
> there is no relationship between DKIM's d= value and the rfc5322.From
> domain name.

To give you credit, you have been preaching this for at least a decade 
or more, always trying to establish non-binding relationship when the 
fact is, it is already burned into the DKIM protocol - the only header 
you MUST bind is 5322.From.  So how can it be said there is no strong 
relationship between the two identities embedded in the DKIM protocol? 
  You might be seeing this from a 3rd party list service where it 
doesn't wish to care what domains are using. It doesn't care.  It 
doesn't honor DMARC domains with restrictive policies.

DKIM policy protocol was always about providing the "authorizing" and 
"enforcement" protocol to act/respond to negative deviations from the 
published expectation for the published DKIM Mail policy.  If the 
publisher makes a public statement "I expect you to see XYZ"  But the 
receiver sees ABC, the DKIM Policy provides the receiver guidance as 
to what action is suggested.  In the case of  DMARC, we have:

p=reject (you can permanently reject)
p=quarantine (accept but put into spam box)
p=none (maybe you shouldn't judge based on DMARC deviations)

The problem, in my view, it is protocol incomplete. There are other 
scenarios not covered by the DMARC protocol syntax and language. We 
need an extended language for Domain Owners to communicate with DMARC 
processors in dealing with the deviation is a 3rd party signer domain.

So I need to see how using Sender fits into the equation. What can the 
DMARC domain owner "describe" via the 5322.From policy statement that 
says

"Please look at the Sender address using Dave's protocol steps before 
looking at the Author address"

Example, maybe using a tag.

DMARC p=reject sender=1

This offers backward compatibility. This could tell the receiver to 
consider using Dave's Sender protocol for DMARC before falling back to 
DMARC original logic. Don't try to ram Sender down DmarcBis's throat 
without some extended switch. If you want to explore an extension, a 
tag such as sender=1 could be used to trigger the a newer exploratory 
logic.

BTW, what are those steps? can it be outlined in itemized steps?

-- 
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos