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

["Murray S. Kucherawy" <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Alessandro Vesely
> Sent: Wednesday, April 04, 2012 12:27 PM
> To: Pete Resnick
> Cc: [e-mail]
> Subject: Re: [marf] I-D Action: draft-ietf-marf-as-12.txt
> 
> > That wasn't my understanding of the intent of the original text. The
> > original seemed to say that you SHOULD use "abuse" unless you had good
> > reason to think doing otherwise was OK, and in fact choosing something
> > other than "abuse" might be unproductive since receivers might treat
> > everything as if it were "abuse".
> 
> 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.

> This doesn't seem to touch much on how to pause sending in case of an
> overwhelming number of reports, but that text is fine for me anyway.

I think that's already covered elsewhere.

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

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

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

-MSK