Re: [dmarc-ietf] p=reject

[Hector Santos <[e-mail]>]

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