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
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
