Subject: [marf] Additional dkim-reporting report type requests

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 29 Jan 2012 20:18:33 -0800

I think it's prudent for us to add two more report types for both ADSP and DKIM: "p", meaning the DKIM or ADSP test failed for local policy reasons, and "o", meaning there was a problem with DKIM or ADSP that was something other than the report types already listed.

DKIM in particular can be presented a perfectly valid DKIM signature that verifies, but the verifier could decide it doesn't want to accept the signature anyway for policy reasons, including (real use cases here) Subject: wasn't signed, or "l=" didn't cover enough of the message percentage-wise.  The existing report requests don't cover those.

I don't know if there's an SPF equivalent for "p", but I suspect adding the "o" case would be a good idea.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 29 Jan 2012 23:23:26 -0500

On Sunday, January 29, 2012 08:18:33 PM Murray S. Kucherawy wrote:
> I think it's prudent for us to add two more report types for both ADSP and
> DKIM: "p", meaning the DKIM or ADSP test failed for local policy reasons,
> and "o", meaning there was a problem with DKIM or ADSP that was something
> other than the report types already listed.
> 
> DKIM in particular can be presented a perfectly valid DKIM signature that
> verifies, but the verifier could decide it doesn't want to accept the
> signature anyway for policy reasons, including (real use cases here)
> Subject: wasn't signed, or "l=" didn't cover enough of the message
> percentage-wise.  The existing report requests don't cover those.
> 

"p" is embedded in SPF already.  If the SPF result is fail and you are 
rejecting due to SPF, it's by definition a policy issue.

I would suggest that "o" isn't needed for SPF since we've already covered the 
spectrum of reasons for an SPF related rejection and so if one is rejecting a 
mail due to some other reason, it's not an SPF auth failure that's causing the 
rejection, it's another type of policy of some kind (e.g. passes SPF, but it's 
a known spammer domain, so reject the mail isn't an SPF issue).

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 29 Jan 2012 20:44:26 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott Kitterman
> Sent: Sunday, January 29, 2012 8:23 PM
> To: [email-masked]
> Subject: Re: [marf] Additional dkim-reporting report type requests
> 

We're using "policy" differently.  An SPF example might be that SPF evaluation passes, but the Verifier demands that SPF only be given credit when the policy includes "-all", and anything else can't truly be trusted.  That would be a case where local policy overrides what SPF says, and you actually treat a "pass" as something other than a "pass".  That's probably a contrived example but you get the idea.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 29 Jan 2012 23:49:22 -0500

On Sunday, January 29, 2012 08:44:26 PM Murray S. Kucherawy wrote:
> > From: [email-masked] [mailto:[email-masked]] On Behalf Of
> > Scott Kitterman Sent: Sunday, January 29, 2012 8:23 PM
> > To: [email-masked]
> We're using "policy" differently.  An SPF example might be that SPF
> evaluation passes, but the Verifier demands that SPF only be given credit
> when the policy includes "-all", and anything else can't truly be trusted. 
> That would be a case where local policy overrides what SPF says, and you
> actually treat a "pass" as something other than a "pass".  That's probably
> a contrived example but you get the idea.

OK.  I would say that's not an SPF result at all.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 29 Jan 2012 20:53:22 -0800

> Sent: Sunday, January 29, 2012 8:49 PM
> To: [email-masked]

Right; I would say it's a Verifier policy override of an SPF result, and possible something a sender might want to know about.  But that's because I come from the DKIM side of things.

The difference is probably in the specs themselves: DKIM has always talked about the fact that a Verifier could render a signature failed for any reason it wants (e.g., last paragraph of Section 6.1.1 of RFC6376) even if all the bits line up to produce a valid signature, and I'm guessing SPF has always put policy stuff like that out of scope.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 29 Jan 2012 23:58:08 -0500

On Sunday, January 29, 2012 08:53:22 PM Murray S. Kucherawy wrote:
> > Scott Kitterman Sent: Sunday, January 29, 2012 8:49 PM
> > To: [email-masked]
> Right; I would say it's a Verifier policy override of an SPF result, and
> possible something a sender might want to know about.  But that's because I
> come from the DKIM side of things.
> 
> The difference is probably in the specs themselves: DKIM has always talked
> about the fact that a Verifier could render a signature failed for any
> reason it wants (e.g., last paragraph of Section 6.1.1 of RFC6376) even if
> all the bits line up to produce a valid signature, and I'm guessing SPF has
> always put policy stuff like that out of scope.

Right, DKIM has no policy component at all, so any policy reasons are 
inherently of some other class of things, but without policy there's no 
action, so it makes sense to bring it in.

In SPF, sender policy is embedded in the record and one can infer receiver 
policy based on results.  If one is doing non-SPF things then it should be 
reported in some other way.

I agree such reports would be of interest, I just don't seem them as SPF 
reports.  I think it'd be inappropriate to use the SPF type for an 
Authentication Results header in such cases too.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 29 Jan 2012 21:11:34 -0800

> Sent: Sunday, January 29, 2012 8:58 PM
> To: [email-masked]
> I agree such reports would be of interest, I just don't seem them as
> SPF reports.  I think it'd be inappropriate to use the SPF type for an

RFC5451 did bring in "policy" as a possible result for SPF and Sender-ID though.  Possible fodder for discussion on that other mailing list.

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 30 Jan 2012 00:14:40 -0500

On Sunday, January 29, 2012 09:11:34 PM Murray S. Kucherawy wrote:
> > Scott Kitterman Sent: Sunday, January 29, 2012 8:58 PM
> > To: [email-masked]
> RFC5451 did bring in "policy" as a possible result for SPF and Sender-ID
> though.  Possible fodder for discussion on that other mailing list.

I think that's a bug in 5451.

Scott K