Subject: [dmarc-ietf] nit - data integrity

From: [email-masked]
Date: Fri, 14 Jun 2019 18:34:25 -0700

A while back there was a request for reports on nits pertaining to the 
specification.

Here is one which I've circulated briefly to some folks recently in 
person, but I'm not sure how well received it will be here, as a 
plausible inclusion in the spec.

The suggestion: provide guidelines on data integrity, which data 
providers should follow.
Examples:
- raw SPF 'fail' should never result in DMARC-SPF 'pass'
- raw SPF 'pass' out of alignment with header_from should never result 
in DMARC-SPF 'pass'
- raw DKIM not being shown should never result in DMARC-DKIM 'pass'
etc

I'm not saying that these situations don't occur for legitimate reasons, 
but the DMARC result is a logical evaluation.  If the result of that 
evaluation is other than the receiving system wants to apply, then all 
of the correct evaluations should still be listed, but the disposition 
can change, and local_policy explain.

Is this something which can be simply stated in the specification, or 
would it belong solely in a 'DMARC XML generator BCP' document?

--Tomki

---

From: "John Levine" <[email-masked]>
Date: 14 Jun 2019 22:23:33 -0400

>- raw DKIM not being shown should never result in DMARC-DKIM 'pass'

I'm sorry, but I don't understand this at all.  The DMARC spec is
quite clear about what SPF and DKIM results are required for DMARC
alignment, and this has no connection I can see with the alignment
rules.

I also don't know what you mean by a "raw DKIM" or what it means to
show it or what you mean by "raw SPF" pass or fail.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Sat, 15 Jun 2019 14:39:52 -0400

On 6/14/2019 9:34 PM, dmarcietf=[email-masked] wrote:

> I'm not saying that these situations don't occur for legitimate
> reasons, but the DMARC result is a logical evaluation.  If the result
> of that evaluation is other than the receiving system wants to apply,
> then all of the correct evaluations should still be listed, but the
> disposition can change, and local_policy explain.
>

Reasons for sending reports?

What I think you are saying is:

If a domain's DMARC restrictive policy is going be overridden by local 
DMARC policy, then a DMARC report should be sent to the DMARC domain 
providing the DMARC technical reasons why DMARC failures were not 
rejected but instead accepted and passed to the user's eyeballs or 
quarantined?

I think I would interesting to know which DMARC receivers are 
accepting what are otherwise DMARC rejectable failures.  A lawyer 
might be interested too, in the off chance an innocent user was 
damaged by the receiver's local DMARC policy.  The DMARC domain did 
its part. The DMARC receiver did not. <g>

-- 
HLS