Subject: [marf] I-D Action: draft-ietf-marf-dkim-reporting-09.txt

From: [email-masked]
Date: Sun, 05 Feb 2012 21:17:03 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Messaging Abuse Reporting Format Working Group of the IETF.

	Title           : Extensions to DKIM for Failure Reporting
	Author(s)       : Murray S. Kucherawy
	Filename        : draft-ietf-marf-dkim-reporting-09.txt
	Pages           : 22
	Date            : 2012-02-05

   This memo presents extensions to the DomainKeys Identified Mail
   (DKIM) specification to allow for detailed reporting of message
   authentication failures in an on-demand fashion.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-marf-dkim-reporting-09.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-marf-dkim-reporting-09.txt

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 5 Feb 2012 21:27:04 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Sunday, February 05, 2012 9:17 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [marf] I-D Action: draft-ietf-marf-dkim-reporting-09.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Messaging Abuse Reporting
> Format Working Group of the IETF.
> 

Similarly, here's an update based on the recent rearrangement of text:

- incorporate Alessandro's point that "rs=" is still actionable even if "ra=" is missing

- state that the report format is defined in the "authfailure-report" draft, but common-factor all the other normative stuff about construction/transmission of the report (e.g., the envelope) to the AS document

- further, common-factor the Security Considerations stuff that's applicable to both SPF reporting and DKIM reporting into the AS

- add/update references accordingly

How's that look?

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 06 Feb 2012 07:03:34 -0500

On Sunday, February 05, 2012 09:27:04 PM Murray S. Kucherawy wrote:
> - further, common-factor the Security Considerations stuff that's applicable
> to both SPF reporting and DKIM reporting into the AS

I'm against this.  It's the wrong place for it (see my note to Barry).

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 06 Feb 2012 13:23:37 +0100

> I'm against this.  It's the wrong place for it (see my note to Barry).

Auto-sending of hi-score messages, although not recommended, needs
precautions that are quite similar to those of sending auth-failures,
so it makes sense to gather them into a common document.

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 06 Feb 2012 08:02:10 -0500

>I'm against this.  It's the wrong place for it (see my note to Barry).

Now that there's an updated draft for last call, here are three additional last call comments:

1. If the DKIM and SPF drafts are supposed to be supported by this draft, then the discussion on reporting address discovery is inadequate. Those drafts enable domains to explicitly publish reporting addresses, so the heuristics for address discovery in this draft are inappropriate for those types of reports.

My preferred solution to this problem would be to separate them again (not providing a recommended diff since it's just reverting some of the changes in the last update).

2. Strongly suggesting use of SPF is, in my opinion, not appropriate in a general document like this. The current text adds up to SHOULD use SPF. The way it was before (IIRC), SPF only came up in the SPF draft.  I suspect a general SHOULD SPF is going to be a hard sell in a standards track document that's not limited in scope to domains already interested in SPF.

3. Due to now saying senders SHOULD use SPF in the envelope sender selection paragraph, the reference to RFC 4408 needs to be normative now.

My solution for #2 and #3 is the same as #1.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 6 Feb 2012 17:40:24 -0000

>How's that look?

Section 10 tells people to use SHA1 as a redaction hash.  The crypto
weenies who freaked out last time will do so again.  Suggest you
replace the text in the section with whatever we said last time, just
do something that's hard to reverse.

I have to say that I'm not thrilled that sections 3, 4, and 5 still
include the r= remote mailbombing feature.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 06 Feb 2012 12:44:51 -0500

> include the r= remote mailbombing feature.

I thought we had agreed we didn't want that?  I changed the SPF draft to 
provide local part only and I think they should be the same.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 6 Feb 2012 09:46:32 -0800

> From: John Levine [mailto:[email-masked]]
> Sent: Monday, February 06, 2012 9:40 AM
> To: [email-masked]
> Cc: Murray S. Kucherawy
> Subject: Re: [marf] I-D Action: draft-ietf-marf-dkim-reporting-09.txt
> 

There is no Section 10 in this document.  Which one are you looking at?

> include the r= remote mailbombing feature.

The algorithm in the draft is the one you've been suggesting, for the most part.  "r=" is now simply a Boolean indicator of a request for reports, and the rest of the reporting parameters are drawn from DNS records.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 6 Feb 2012 10:03:49 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott Kitterman
> Sent: Monday, February 06, 2012 5:02 AM
> To: [email-masked]
> 1. If the DKIM and SPF drafts are supposed to be supported by this
> draft, then the discussion on reporting address discovery is
> inadequate. Those drafts enable domains to explicitly publish reporting
> addresses, so the heuristics for address discovery in this draft are
> inappropriate for those types of reports.
> 
> My preferred solution to this problem would be to separate them again
> (not providing a recommended diff since it's just reverting some of the
> changes in the last update).

That's one option.  Another is to indicate that for automatic reports, a specific reporting address SHOULD be advertised by the party requesting the reports, and then refer to the two reporting drafts as examples.

> 2. Strongly suggesting use of SPF is, in my opinion, not appropriate in
> a general document like this. The current text adds up to SHOULD use
> SPF. The way it was before (IIRC), SPF only came up in the SPF draft.
> I suspect a general SHOULD SPF is going to be a hard sell in a
> standards track document that's not limited in scope to domains already
> interested in SPF.
> 
> 3. Due to now saying senders SHOULD use SPF in the envelope sender
> selection paragraph, the reference to RFC 4408 needs to be normative
> now.
> 

The SPF-specific text (i.e., the last paragraph of the AS Section 9.2) could be moved back to the SPF document, with more generic text left behind in the AS so that it addresses the problem without naming SPF specifically.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 06 Feb 2012 13:13:57 -0500

On Monday, February 06, 2012 10:03:49 AM Murray S. Kucherawy wrote:
> > From: [email-masked] [mailto:[email-masked]] On Behalf Of
> > Scott Kitterman Sent: Monday, February 06, 2012 5:02 AM
> > To: [email-masked]
> That's one option.  Another is to indicate that for automatic reports, a
> specific reporting address SHOULD be advertised by the party requesting the
> reports, and then refer to the two reporting drafts as examples.

I've read the AS draft again and other than the text you just moved into it, I 
don't find it particularly useful for implementers of auth failure FBRs.  I 
think the minimal efficiency for document producers provided by having one draft 
to update is more than offset by increased complexity for implementers having 
to sorth through a lot of irrelevant advice.

> The SPF-specific text (i.e., the last paragraph of the AS Section 9.2) could
> be moved back to the SPF document, with more generic text left behind in
> the AS so that it addresses the problem without naming SPF specifically.

Except that as written, 9.2 isn't giving advice for just SPF auth failure 
results.  It's now giving advice for all ARFs (as I understand it), so I don't 
think it can be pushed off into a document on how to due auth failure ARFs for 
SPF.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 6 Feb 2012 10:19:56 -0800

> Sent: Monday, February 06, 2012 10:14 AM
> To: [email-masked]
> I've read the AS draft again and other than the text you just moved
> into it, I don't find it particularly useful for implementers of auth
> failure FBRs.  I think the minimal efficiency for document producers
> provided by having one draft to update is more than offset by increased
> complexity for implementers having to sorth through a lot of irrelevant
> advice.

What I'm trying to avoid is having the same text in two documents (the two reporting drafts) without having to spin up yet another document to contain the common factoring.  As Barry pointed out, the AS is essentially our answer to the "How do you use ARF?" question in general, so it seems like a reasonable path to me.

That said, this has to have consensus, so I'm open to other opinions.

> > The SPF-specific text (i.e., the last paragraph of the AS Section 9.2)
> > could be moved back to the SPF document, with more generic text left
> > behind in the AS so that it addresses the problem without naming SPF
> specifically.
> 
> Except that as written, 9.2 isn't giving advice for just SPF auth
> failure results.  It's now giving advice for all ARFs (as I understand
> it), so I don't think it can be pushed off into a document on how to
> due auth failure ARFs for SPF.

Right, and my suggestion is to fix that by removing the SPF-specific stuff back to your document, as you suggested, and leaving something more generally applicable in its place.  It would not, for example, reappear in the DKIM reporting draft.

Section 9 overall is about automatic report generation such as is defined in the two reporting documents we have now, and how doing so differs from the rest of the document.  I thought the text in Section 9 itself says that, but I can make it more explicit if needed.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 6 Feb 2012 19:35:01 -0000

>>How's that look?

Oops, having now read the correct document, you need to say that
_report._domainkey.foo can return only one TXT record, no asking for
three different reports, but other than that, it's fine.  Ship it.

R's,
John