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

[Alessandro Vesely <[e-mail]>]

On 04/Apr/12 20:40, Pete Resnick wrote:
> On 4/4/12 11:40 AM, Alessandro Vesely wrote:
>> On 03/Apr/12 20:08, Pete Resnick wrote:
>>   
>>> How about instead: "The reports SHOULD use "Feedback-Type: abuse" for
>>> its type. Although a Mailbox Provider generating the reports can use
>>> other types appropriate to the nature of the abuse being reported, the
>>> operator receiving the reports might not treat different feedback
>>> types differently." The "needs to understand" construction confused me
>>> as it didn't seem like something actionable.
>>
>> The suggested replacement seems to be saying that it is fine to use
>> "Feedback-Type: abuse" even if that doesn't correspond to the actual
>> content.  Would s/its type/such type/ avoid it?
> 
> 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.

> If you want to say "SHOULD use 'abuse' when it's abuse", then I'd
> like to hear why that's not a MUST.

Hmm... possibly to avoid putting too many requirements?  A good reason
to think that putting something different, e.g. "virus" is if one is
equipped to report viruses that way.  But even then, receivers may be
unable to treat it properly, and this has to be taken into account.
Using some common sense is probably better.

>> For Pete's info, the WG briefly discussed the possibility to describe
>> a mechanism, and concluded that mandating such compliance was too much
>> of a burden for a report generator.
> 
> Yes, Murray and I chatted about this offline, and what he has
> suggested for 6.1.1 explains that well:
> 
>    1.  Handling of unsolicited reports has a significant cost to the
>        receiver.  Senders of unsolicited reports, especially those
>        sending large volumes of them automatically, need to be aware of
>        this and do all they reasonably can to avoid sending reports that
>        cannot be used as a basis for action by the recipient, whether
>        this is due to the report being sent about an incident that is
>        not abuse-related, the report being sent to an email address that
>        won't result in action, or the content or format of the report
>        being hard for the recipient to read or use.

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.

>>> 6.3.1
>>>      MUAs SHOULD NOT generate abuse reports directly to entities
>>>      merely because they were found in the message, or by queries to
>>>      WHOIS ([RFC3912]) or other heuristic means.  Rather, the MUA
>>>      needs to signal, by some means, the mailbox provider to which it
>>>      connects to trigger generation of such a report.
>>>
>>> The first sentence seems to conflict with 6.3/3. I don't understand
>>> the second sentence. Please explain.
>>>      
>> I'd propose the following text, rather than striking the whole
>> paragraph:
>>
>>     MUAs SHOULD NOT send abuse reports directly to the entities they
>>     deem responsible of the abuse.  Rather, MUAs need to signal the
>>     abuse to the mailbox provider to which they connect.  A MUA's
>>     signal may or may not use ARF [RFC5965] format, depending on how
>>     it's done.  This document does not specify by what means MUAs do
>>     such signaling.  The rest of this section discusses where Mailbox
>>     Providers can send reports, albeit possibly triggered by MUAs'
>>     signals.
>>
>> Would that make the point any clearer?
> 
> Again, Murray and I chatted offline about this. It's not MUAs that are
> the problem. MUAs that follow all of the rules of a service provider
> (e.g., who send user initiated reports to an address in the
> appropriate header field) are well within rights to be sending abuse
> reports directly (and if you want to argue against that, I'm happy to
> argue back *strongly*).

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.

2. MUAs most often live behind a NAT and don't have the requisites
   for letting an occasional abuse report evolve into an established
   feedback arrangement.  A server may provide a web-based reporting
   shop for that.  This perspective is addressed in 6.5/4.

Is there a better way to convey that?

> The key is that you don't want reports that go addresses that *any*
> generator (MUA or otherwise) simply pulls out of some random From:
> field or the like. Again, I like Murray's suggested replacement:
> 
>    1.  Report generators SHOULD NOT send reports to recipients that are
>        uninvolved or only peripherally involved.  For example, they
>        SHOULD NOT send reports to the operator of every Autonomous
>        System in the path between the apparent originating system and
>        the operator generating the report.  Instead, they need to send
>        reports to recipients that are both responsible for the messages
>        and are able to do something about them.

Pete, please don't get distracted by the way the diffs get produced,
that paragraph was there already.