Subject: [marf] I-D Action: draft-ietf-marf-as-04.txt

From: [email-masked]
Date: Wed, 25 Jan 2012 22:15:00 -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           : Creation and Use of Email Feedback Reports: An Applicability Statement for the Abuse Reporting Format (ARF)
	Author(s)       : J.D. Falk
                          M. Kucherawy
	Filename        : draft-ietf-marf-as-04.txt
	Pages           : 9
	Date            : 2012-01-25

   RFC 5965 defines an extensible, machine-readable format intended for
   mail operators to report feedback about received email to other
   parties.  This document describes common methods for utilizing this
   format for abuse reporting.  Mailbox Providers of any size, mail
   sending entities, and end users can use these methods as a basis to
   create procedures that best suit them.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-marf-as-04.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-as-04.txt

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 25 Jan 2012 22:16:58 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Wednesday, January 25, 2012 10:15 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: I-D Action: draft-ietf-marf-as-04.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.
> 
> 	Title           : Creation and Use of Email Feedback Reports: An
> Applicability Statement for the Abuse Reporting Format (ARF)
> 	Author(s)       : J.D. Falk
>                           M. Kucherawy

I'm caught up on the feedback for this, I think.  Please review the latest version and provide commentary.  The diffs are viewable through the datatracker's "History" tab.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 27 Jan 2012 20:17:26 +0100

Hi Murray,

version -04 looks nearly good for WGLC.  Thank you so much!

On 26/Jan/12 07:16, Murray S. Kucherawy wrote:
> 
> I'm caught up on the feedback for this, I think.  Please review the
> latest version and provide commentary.

Some points, nits, and ideas:

*Updates 5965*

It doesn't seem to actually update the format.  If the use of ARF is
meant to be updated, we probably need a section where that update is
identified.

*Section 5*

The second part of the second paragraph ("Abuse addresses in WHOIS
records [...]") covers a where-to-send question similar to the one
answered by bullet 5 in Section 8.  Would it be an improvement to have
them near to one another?  BTW, this method is also "not universally
true", as the retrieved abuse mailbox can belong to a network provider
who may or may not forward reports to the relevant mailbox provider or
ESP.

*Section 6*

The text "Section 3.4 of that document" gets a wrong link in bullet 1
of http://tools.ietf.org/html/draft-ietf-marf-as-04#section-6

Repeating the same reference makes for a less appealing prose, but is
easier to markup and search.

*Section 7*

In bullet 4, "That system" refers to the automated system considered
in the previous bullet.  It is unclear, now that that text has
changed.  Hints for rewording: bullets 4 and 5 apply to automated
systems, so they might be further indented.

Bullet 7 could also refer to Section 4.4 of [RFC6449], as it covers
redaction.  However, RFC 6449 treats that the same irrespectively of
the redaction algorithm used.  Should we say how to recognize and take
advantage of /conforming/ redaction?

*Section 8*

Bullets 1 and 2 sound quite obscure, or maybe it's just me.  As a
minor improvement, maybe s/generating/reporting/?

Bullet 3: s/service provider/mailbox provider/.

Bullet 5: sounds good, but see previous comment for Section 5.

Perhaps before bullet 9: do we want to mention that a network provider
MAY use ARF data for automated forwarding of Feedback Messages to the
originating customer, as described in the last paragraph of Section
4.4 of [RFC6449]?

Bullet 11: kudos for that, great!  Do we want to refer to Section 3.5
of [RFC6449] from there too?

In particular, feedback providers who save the unsolicited reports
they send (as they should) can provide a web page for the report at
hand.  That page would display all parts of the report --thereby
solving the issue of bullet 10-- and also provide any FBL-related link
that is mentioned in Section 3.5.1 of [RFC6449].  Would this be good?
 If we like it, we could summarize such approach by adding an example
of unsolicited feedback in an appendix of this I-D.  The human
readable part of the exemplified message might contain text such as:

   This is an unsolicited feedback report for an email message
   received from a.sender.example on 8 Oct 2011 20:15:58 +0000 (GMT)
   and generated according to [this memo].  If you are unable to
   correctly visualize any of its parts, you may want to access
   https://postmaster.feedback-provider.example/fbl?key=1a2b3c4d5e
   (certified by http://unusual-CAcert.example/certs/root.crt).

   Our web page above also contains links to general information on
   our Complaint Feedback Loop program and how to get enrolled, so as
   to receive feedback reports like this regularly or to stop them
   altogether.

   Alternatively, you may reply to this message to confirm the email
   address that was used to send this report.  Please tell us what
   action you took in order to avoid that the abusive behavior we are
   complaining about will continue.

Just a thought.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 27 Jan 2012 14:01:16 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alessandro Vesely
> Sent: Friday, January 27, 2012 11:17 AM
> To: [email-masked]
> Subject: Re: [marf] I-D Action: draft-ietf-marf-as-04.txt
> 

It's my understanding that "RFCx updates RFCy" means "if you are implementing RFCy, you really also need to read RFCx".  For an applicability statement, therefore, this is typical.

> them near to one another?

That doesn't seem to be beneficial enough to warrant rearranging the whole thing.

> BTW, this method is also "not universally

True, will add that nit-text.

> easier to markup and search.

That's unfortunate, so OK.

> *Section 7*
> 
> In bullet 4, "That system" refers to the automated system considered in
> the previous bullet.  It is unclear, now that that text has changed.
> Hints for rewording: bullets 4 and 5 apply to automated systems, so
> they might be further indented.

I just changed "That system" to "An automatic report processing system".

> advantage of /conforming/ redaction?

Added the reference and a sentence reiterating the point of standard redaction, which is to enable correlation and prioritization by the recipient.

> *Section 8*
> 
> Bullets 1 and 2 sound quite obscure, or maybe it's just me.  As a minor
> improvement, maybe s/generating/reporting/?

Done.

> Bullet 3: s/service provider/mailbox provider/.

Done.

> originating customer, as described in the last paragraph of Section

Added.

> of [RFC6449] from there too?

Added.

> In particular, feedback providers who save the unsolicited reports they
> send (as they should) can provide a web page for the report at hand.
> That page would display all parts of the report --thereby solving the
> issue of bullet 10-- and also provide any FBL-related link that is
> mentioned in Section 3.5.1 of [RFC6449].  Would this be good?

Possibly, but without an implementation it's hard to say that we can justify including it in an applicability statement.  Have you actually tried this?

> of unsolicited feedback in an appendix of this I-D.  The human readable
> part of the exemplified message might contain text such as:
> 

Simpler would be to suggest that sending unsolicited feedback SHOULD populate the text/plain part of the report with ample explanatory text about what this message is and where to get more information, since there's no guarantee the recipient will understand the other two MIME parts.  But I believe bullet 10 already covers that.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 31 Jan 2012 16:32:35 +0100

On 27/Jan/12 23:01, Murray S. Kucherawy wrote:
>> From: ietf.org On Behalf Of Alessandro Vesely
> 
>> *Updates 5965*
>> 
> It's my understanding that "RFCx updates RFCy" means "if you are
> implementing RFCy, you really also need to read RFCx".

Agreed, that's more or less what Section 12 of RFC 2223 says.

> For an applicability statement, therefore, this is typical.

That's the point I don't get.  If anything, I'd say marf-as updates
RFC 6449.  RFC 5965 implementations might well do without this I-D, IMHO.