Subject: [marf] comments on DKIM Reporting draft

From: Tim Draegen <[email-masked]>
Date: Tue, 25 Jan 2011 10:39:22 -0500

> One party that’s already seen the draft, whom I hope will pipe up on the list once it’s posted, has some concerns about the size of the document and thus would like us to consider breaking it into a small set of related documents.  I’ll let that discussion start separately along with any other points he may have.

Murray,

My apologies for being tardy!  My concern is that too much is covered.

AFAICT, this draft is actually 5 separate documents rolled up into one:

1. DKIM reporting extensions
2. ADSP reporting extensions
3. SPF reporting extensions
4. ARF auth-failure extensions
5. ARF "redaction"

#1 makes sense as a technical spec.  I think it's ready for focused operational testing.

#2 is just like #1.

#3 presents interesting ideas, for sure.  However the draft contains a few techno-warts:

- I'm having a hard time understanding how the SPF "reportopts" will be used.  The publisher of the record adds the policy piece of SPF that leads to a (fail, softfail, neutral) result, usually by adding something like "-all" or "~all" to their record.

EG, using the proposed syntax, I could write "v=spf1 ip4:1.2.3.4 report=email.address reportopts=f ~all". This would specify that I want reports on all SPF "fails" (distinct from "softfails").  However, my "~all" means that all my non-authorized email will end up receiving "softfails", resulting in me receiving zero reports.

- Lots of real-world SPF records "include:" other records.  What if two report-related extensions appear due to the use of include:?

- SPF records describe "mechanisms" for identifying authorized servers and "modifiers".  The extensions are "modifiers", but I'm uncertain if these will break existing SPF code, or if various implementors did the right the thing.  

- "reportsmtp=" is redundant with SPF's existing "exp:" modifier.

#4 is interesting, but needs another rev of specification (does it target deployers of authentication?  is it meant to allow implementors to debug their stacks?), preferably with input from real-world operations.

#5 isn't anything, except maybe a request to supply unique identifiers when supplying #4.  Even then there is a whole lot of stuff involved to get across-the-board anonymized identifies deployed across disparate systems within a single organization.  Maybe this should be carved out as a common unique-anonymized-identifier algorithm that implementors should adopt.

Cheers,
=- Tim

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 31 Jan 2011 19:54:41 -0800

Hi Tim, and thanks for the feedback!

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Tim Draegen
> Sent: Tuesday, January 25, 2011 7:39 AM
> To: [email-masked]
> Subject: [marf] comments on DKIM Reporting draft
> 

I'd hate to have to split it into five individual documents (and I think our AD might too) but I will if that appears to be the right path.  Would anyone be interested in taking up document editor roles should such a split occur?

> - I'm having a hard time understanding how the SPF "reportopts" will be
> used.  The publisher of the record adds the policy piece of SPF that
> leads to a (fail, softfail, neutral) result, usually by adding
> something like "-all" or "~all" to their record.
> 
> EG, using the proposed syntax, I could write "v=spf1 ip4:1.2.3.4
> report=email.address reportopts=f ~all". This would specify that I want
> reports on all SPF "fails" (distinct from "softfails").  However, my
> "~all" means that all my non-authorized email will end up receiving
> "softfails", resulting in me receiving zero reports.

Section 6 of RFC4408 says modifiers (which is what these are) "MAY appear anywhere in the record, but SHOULD appear at the end, after all mechanisms".  It would probably be sufficient for this draft to say the results of using these modifiers before any mechanism is undefined, i.e. they SHOULD always go at the end.

> - Lots of real-world SPF records "include:" other records.  What if two
> report-related extensions appear due to the use of include:?

True, I hadn't thought of this.  My gut reaction is to require that the reporting options within an included record SHOULD (or even MUST) be ignored.  Does it make sense to do that?

> - SPF records describe "mechanisms" for identifying authorized servers
> and "modifiers".  The extensions are "modifiers", but I'm uncertain if
> these will break existing SPF code, or if various implementors did the
> right the thing.

I don't think we can really handle the "did the wrong thing" case.  RFC4408 makes it pretty clear that unknown modifiers should be ignored regardless of where they are in the record.

> - "reportsmtp=" is redundant with SPF's existing "exp:" modifier.

Ah, good point.  It should be removed.

> #4 is interesting, but needs another rev of specification (does it
> target deployers of authentication?  is it meant to allow implementors
> to debug their stacks?), preferably with input from real-world
> operations.

The auth-failure extensions to ARF are meant to allow relaying of forensic material about specific message authentication failures, so "yes" to both questions.

An earlier version of this has been in use in OpenDKIM for some time now, though I don't know that it's interoperating with anything (yet).

> #5 isn't anything, except maybe a request to supply unique identifiers
> when supplying #4.  Even then there is a whole lot of stuff involved to
> get across-the-board anonymized identifies deployed across disparate
> systems within a single organization.  Maybe this should be carved out
> as a common unique-anonymized-identifier algorithm that implementors
> should adopt.

I think I've said elsewhere that the redaction section is something RFC5965 should've had.  We could certainly pull it out and save it for an RFC5965bis, or put it in its own draft updating RFC5965.  What do others think?

There is also discussion in another thread of supporting the IODEF format.  This draft could certainly include that as an option, although the issue of transport of the IODEF report would have to be covered as well.

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 01 Feb 2011 00:05:32 -0500

"Murray S. Kucherawy" <[email-masked]> wrote:

>I'd hate to have to split it into five individual documents (and I
>think our AD might too) but I will if that appears to be the right
>path.  Would anyone be interested in taking up document editor roles
>should such a split occur?

I could do SPF Reporting Extensions.

>> #3 presents interesting ideas, for sure.  However the draft contains
>a
>> few techno-warts:
>> 
>Section 6 of RFC4408 says modifiers (which is what these are) "MAY
>appear anywhere in the record, but SHOULD appear at the end, after all
>mechanisms".  It would probably be sufficient for this draft to say the
>results of using these modifiers before any mechanism is undefined,
>i.e. they SHOULD always go at the end.
>
>True, I hadn't thought of this.  My gut reaction is to require that the
>reporting options within an included record SHOULD (or even MUST) be
>ignored.  Does it make sense to do that?
>
Include can only match,not match, or cause an error, so I think these new modifiers MUST not be processed is they are reached via an include. Alternatively, redirect modifiers MUST be followed. This would be consistent with the treatment of existing modifiers, exp and redirect. I can write spec language for this if you want.

Scott K