[dmarc-discuss] policy overrides and 'what-if'

[Paul Midgen]

We have a pending update to the draft that enumerates additional values, but for now and in spite of the difference between the current draft and Google's implementation, you can take Google's implementation as representative of what will follow.

When thinking about a tool that provides views of aggregate report data and extracts statistics and allows what-if modeling, I think it makes sense to provide explanations of the conditions that could cause a receiver to apply an override.

I may be missing your point about the information you'd rather have, but when a PolicyOverrideReason is present, the disposition associated with it is the result of the override. For example, if you have p=reject and mailing_list is present, you could expect to find disposition == none. Are you asking about something else?

-----Original Message-----
From: Ben Clifford [mailto:benc at cqx.ltd.uk] 
Sent: Wednesday, April 04, 2012 6:56 PM
To: Paul Midgen
Cc: dmarc-discuss at dmarc.org
Subject: Re: [dmarc-discuss] policy overrides and 'what-if'

How well defined are the well-known override cases you describe below?

Google is sending me overrides of type = mailing_list (which I can take a guess to what they mean)

but that type is not in draft-dmarc-base-00-01.txt

and I don't see anything relevant in a google search.

How comfortable should I be telling users that a mailing_list override means that it doesn't matter at all that their DKIM/SPF is failing? I think the intuitive answer is that's a fine thing to do - but its not clear that its the right-wrt-the-written-spec thing to tell them.

>From a what-if perspective, maybe instead of knowing the reason for the policy override, I'm more interested in what the policy override was: a statement along the lines of "I have non-dmarc evidence that causes me to treat this as a 'none'"; rather than "I have non-dmarc evidence that causes me to treat this as a mailing list; but I do not disclose to you how that will affect things".

On Apr 4, 2012, at 3:01 PM, Paul Midgen wrote:

> It's tricky. There are some well-known override cases such as forwarding and MLMs where you could infer what happened at the receiver, but when you see something like "local_policy" I think the best you can do is use the rate of occurrence as an error margin on what-if estimates derived by incorporating the total unambiguous results with the well-known override cases.
> 
> e.g. "set p=quarantine and 52% +/- 2.3% of your mail will be quarantined"
> 
> -----Original Message-----
> From: dmarc-discuss-bounces at blackops.org [mailto:dmarc-discuss-bounces at blackops.org] On Behalf Of Ben Clifford
> Sent: Tuesday, April 03, 2012 7:04 PM
> To: dmarc-discuss at dmarc.org
> Subject: [dmarc-discuss] policy overrides and 'what-if'
> 
> I'm interested in taking reports from p=none DMARC reports, and giving "what-if" results about those reports for when p=reject or p=quarantine.
> 
> Its not clear to me how I should interpret PolicyOverrideReasons when doing this.
> 
> I'll always see a disposition of 'none' because p=none, even when I see reports of DKIM and SPF mechanisms failing.
> 
> When there is no PolicyOverrideReason in a record, and I see all DKIM and SPF mechanisms failing in that record, I believe it is correct to infer that changing to p=reject would mean this record would change to a reject disposition, and so I can pop up a big red flag my report user interface. (is that a correct assumption?)
> 
> But, if I see a disposition of none, and a policyoverride, what can I assume?
> 
> Can I assume that the override means that the specified disposition would remain unchanged even if the DMARC policy changes to p=reject?
> 
> Or does the policyoverride mean "we applied a different policy. if you're a human maybe you can figure it out, but this report does not contain enough information for you to figure out the 'what-if' behaviour mechanically?"
> 
> Ben
> 
> -- 
> 
> 
> _______________________________________________
> dmarc-discuss mailing list
> dmarc-discuss at dmarc.org
> http://www.dmarc.org/mailman/listinfo/dmarc-discuss
> NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
> 
>