Re: [marf] I-D Action: draft-ietf-marf-as-12.txt

[Alessandro Vesely <[e-mail]>]

On Thu 05/Apr/2012 18:12:41 +0200 Murray S. Kucherawy wrote:
>> From: ietf.org On Behalf Of Alessandro Vesely
>
>> Uh, I understood it as the the statement that the expected type of
>> report is abuse, so much that some software can be equipped to only
>> write "abuse" or to assume that it is "abuse" even without reading it.
> 
> Sounds to me like you're saying the same thing.

More or less yes.  It's not a sharp concept, however tweaked.  I was
just trying to make sure we're not introducing wrong interpretations,
such as "always put the same type since recipients may not care"...

>> I wouldn't object against a MUA's right to send an abuse report,
>> especially if the server it connects to doesn't do such service, or
>> does it poorly.  The point is that that's not how things should be.
>> Two reasons are as follows:
>> 
>> 1. Rejecting spam is generally considered more effective than
>>    quarantining it.  Hence, it is good if the MUA cooperates with its
>>    server on this.  Signaling spam, in particular, provides a means to
>>    instruct filters for on-line rejection.
> 
> Ah, right, this was lost to memory when Pete and I discussed it in
> Paris.  So how about this, re-inserted as 6.3/1:
> 
>    1.  Rather than generating feedback reports themselves, MUAs SHOULD
>        make abuse reports back to their mailbox providers so that they
>        can generate and send ARF messages on behalf of end users.  This
>        allows centralized processing and tracking of reports, and
>        provides training input to filtering systems.

As long as "make abuse reports back" is clear, that may work.  MUAs
could use any of John's taxonomy techniques[1], I don't know if it
could be acceptable to refer to that page...

[1] http://wiki.asrg.sp.am/wiki/Adding_a_junk_button_to_MUAs

> ...with a reference to Section 3.2 of RFC6449 thrown in there, now
> that I look at it.

Neat idea, IMHO.

For a nit, the I-D uses the term "report generator".  Its meaning is
obvious.  However, RFC 6449 uses "Feedback Provider" instead.  Would
the addition of a definition in Section 2 ease such references?  E.g.
something like so:

   A "report generator" is the entity or process that generates and
   sends reports.  For feedback reports, it belongs to a "Feedback
   Provider" in the sense of [RFC6449].  This memo uses the term
   Mailbox Provider to refer to these facets too.

> (The deviation from the SHOULD would be cases where, for example,
> there is no mailbox provider separate from the end user.)

More commonly, when its mailbox provider doesn't do reporting.