Subject: Re: [marf] comments on DKIM Reporting draft

From: "J.D. Falk" <[email-masked]>
Date: Wed, 2 Feb 2011 10:28:13 -0800

On Jan 31, 2011, at 7:54 PM, Murray S. Kucherawy wrote:

>> 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"
> 
> 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 help with the DKIM, ADSP, and/or ARF portions; I don't know SPF well enough.

As for whether the split is necessary...it'd certainly be easier for someone who is only implementing DKIM, or only implementing SPF (it's hard to imagine someone implementing ARF auth-failure without also implementing DKIM or SPF or both.)  But it could be frustrating if someone is implementing them all at once.  So, I'm not sure which way to go.

I'm definitely in favor of splitting out the redaction discussion to a new Informational or BCP document, because I expect that other MARF docs will reference it often.

>> - 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?

Hmm.  I could imagine a scenario where someone with hundreds of domains uses the include mechanism to ensure that all of the domains have the same SPF record, and they'd want reporting to work.  Since SPF isn't in a service record like _spf.example.net, CNAMEs generally aren't an option.

Maybe all we can do is suggest that includes only be followed a few levels (or is this already in SPF?)

>> #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?

I think it should be in its own draft.  ARF probably won't be the only format where a discussion of redaction is appropriate.

> 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.

This also gets into the overlap between dkim-reporting and reporting-discovery, which we should probably discuss further.

There's no reason the advertisements described in reporting-discovery couldn't be used for auth-failure reports -- except that the mechanism for looking up the advertisement in reporting-discovery may use a different identifier:

R-D Report Consumers advertise at:
	destination of PTR of outbound SMTP server
	DKIM d=

R-D Report Generators advertise at:
	recipient domain (RCPT TO: <[email-masked]> = use example.com)

D-R Report Consumers
	DKIM d=
	SPF MAIL or HELO

Sometimes they'll match, sometimes they won't.

Also, it does make sense to tie reporting of authentication to the authentication-related DNS records rather than creating a new record.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 2 Feb 2011 11:05:52 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of J.D. Falk
> Sent: Wednesday, February 02, 2011 10:28 AM
> To: Message Abuse Report Format working group
> Subject: Re: [marf] comments on DKIM Reporting draft
> 

[as participant]

I think my preference given the input so far is to leave (1), (2) and (4) in one document since there's already one such implementation out there (granted it's mine; I admit to some bias there).  (3) could go out on its own as an add-on to that one, and Scott has volunteered to edit that; (5) could also go out on its own, probably as an informational or an update to RFC5965, and I think JD is saying he could take that one.

How does that sound, especially to those I've actually named here?  :-)

---

From: "J.D. Falk" <[email-masked]>
Date: Wed, 2 Feb 2011 12:05:55 -0800

> How does that sound, especially to those I've actually named here?  :-)

Makes sense to me, assuming there's consensus to split.  I'm willing to become editor of (5).

---

From: John Levine <[email-masked]>
Date: 3 Feb 2011 03:04:48 -0000

>> I think my preference given the input so far is to leave (1), (2)
>and (4) in one document since there's already one such implementation
>out there (granted it's mine; I admit to some bias there).  (3) could
>go out on its own as an add-on to that one, and Scott has volunteered
>to edit that

If all the work is going to be done at the same time, I don't see any
benefit to splitting out the SPF stuff.  It may be a political issue
to refer to an experimental RFC, but unless the IESG insists, our
readers will prefer to read one document.

As far as (5) is concerned, I'm one of the authors of 5965 so I'd be
happy to work on it with JD.  This seems somewhat independent of the
rest since it's equally useful (or not) in existing ARF applications.

R's,
John