On 3/18/2019 3:48 PM, Michael Davis wrote:
If a sender's IP is in SPF, so SPF passes; and the applied DKIM signature
is successfully decrypted, so DKIM passes; what good is checking alignment
and rejecting a message? I have had Adobe and Cloudflare automated system
emails rejected based on those senders' DMARC policy, after SPF and DKIM
pass. These emails were regarding password resets and come from servers
that do not equal the spoofed address domain. It would seem that if the
sender is approved according to SPF and verified according to DKIM that
alignment being a reason for rejection post authenticas is an exercise of
absurdity.
Please help me understand otherwise.
Hi Michel,
I'll take a stab at this. My opinion.
I do agree with one vital (optimization) idea.
If a domain is 100% exclusive and restrictive and the domain's
DNS-exposed policies indicate this exclusivity for all parties
involved, then, in my opinion, DMARC is redundant. SPF should be good
enough as long as all all identities are aligned.
That said, there a few points here.
First, this is all about having "trust."
Second, we don't have a 3rd party authorization/trust system for
email, not like we do with HTTPS and the browsers relationship with
3rd party CA vendors.
Third, without the first and second thing, it becomes questionable
(almost to the level of absurdity) to use 3rd party services for high
value transactions where one might suggest a "password reset" would be
considered high value.
With DKIM, we have a self-signing 1st party signature system and a
DKIM Policy framework for a 1st party authorization system. It lacks
a 3rd party authorization framework like we have with HTTPS.
It is important to keep this in mind because this dearth has been the
"thorn on the dkim side" since the early days of DKIM-SSP (Sender
Signature Policy) where it did offer policies for the 3rd party.
o=! EXCLUSIVE (signature required, no 3rd party)
o=- STRONG (signature required, 3rd party allowed)
o=~ NEUTRAL (signature optional, 3rd party allowed)
o=? WEAK (signature optional, no third party)
o=. NEVER (no mail expected)
o=^ USER
Over the years, because of the complexity and the failure to work out
a 3rd party authorization protocol, ADSP and eventually DMARC reduced
this to only supporting the more powerful, more narrow, more
restrictive exclusive 1st party only signing protection policy.
But overall, what they all (SSP, ADSP, DMARC) lacked was a 3rd party
signature authorization protocol. Ideas like TPA and ATPS were
proposed as DKIM Policy extensions to fill in this big gap but
unfortunately, not much traction.
Note: By 3rd party, this means the RPID, SDID and AUID domains don't
align with ADID where:
ADID Author Domain Identity (5322.From.domain)
RPID Return Path Identity (5321.MailFrom.domain)
SDID Signer Domain Identity (5322.DKIM-Signature s= tag)
AUID Agent User Identity (5322.DKIM-Signature i= tag)
Honestly, I see your point, but vendors really do need to watch out
using a 3rd party sending ADID, RPID, SDID and AUID scenarios for
sensitive transactions. We simply do not have an automated 3rd party
authorization/trust and assessment system in place.
--
HLS
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
