Subject: [dmarc-ietf] p=reject

From: Michael Davis <[email-masked]>
Date: Mon, 18 Mar 2019 14:48:41 -0500

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.

---

From: Autumn Tyr-Salvia <[email-masked]>
Date: Mon, 18 Mar 2019 20:03:32 +0000

Hello Michael,

Consider this scenario:

Friendly From: @yourbank.com
SMTP MAIL FROM: @spammer.ru
DKIM d=spammer.ru

SPF gets checked at the SMTP MAIL FROM domain, and DKIM gets checked at the d= domain. Either or both of these could pass authentication, but that would not mean the message is legitimately from yourbank.com. DMARC was intended to tie together the backend server information with the friendly From: address to prevent abusive spoofing like this, which is very common.

Thanks,

Autumn Tyr-Salvia
[email-masked]
Agari Principal Customer Success Engineer

________________________________
From: dmarc <[email-masked]> on behalf of Michael Davis <[email-masked]>
Sent: Monday, March 18, 2019 12:48 PM
To: [email-masked]
Subject: [dmarc-ietf] p=reject

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.

---

From: "John Levine" <[email-masked]>
Date: 18 Mar 2019 23:01:28 -0400

In article <CAOXFXsuLdsZgA-uJEDApRgW6bmzx5cORbiy=[email-masked]> you write:
>-=-=-=-=-=-
>and rejecting a message?

The short answer is that bad guys can publish SPF and DKIM just as
well as good guys.  Anecdotally, it appears that bad guys are better
at it than good guys.

The point of DMARC is not just that a message is authenticated, but
that it is authenticated by the same domain that's on the From: line,
which makes it highly likely that the message is actually from who it
appears to be from, rather than from some random crook with an SPF
record and a DKIM signer.

There are certainly plenty of ways that DMARC can do unfortunate
things but in this case it's working as intended.

---

From: Hector Santos <[email-masked]>
Date: Tue, 19 Mar 2019 09:24:04 -0400

> 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