On 4/4/12 11:40 AM, Alessandro Vesely wrote:
On 03/Apr/12 20:08, Pete Resnick wrote:
On 3/30/12 4:49 AM, Murray S. Kucherawy wrote:
4.3.1.
The reports SHOULD use "Feedback-Type: abuse", but can use other
types as appropriate to the nature of the abuse being reported.
However, the Mailbox Provider generating the reports needs to
understand that the operator receiving the reports might not
treat different feedback types any differently.
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". If you want to say "SHOULD use 'abuse'
when it's abuse", then I'd like to hear why that's not a MUST.
6.1.1
A report generator MUST provide a way for a report recipient to
request no further reports be sent to that address and MAY
provide a way for recipients to change the address(es) to which
reports about them are sent. Details of such mechanisms are
outside of the scope of [RFC5965], [RFC6449], and this document.
So, thinking about this, the above instruction is completely
non-interoperable. I am required to provide a mechanism, but how the
mechanism works is unspecified. Please explain what this means.
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.
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*). 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.
That explains the concern. Being an MUA is not the problem.
pr
--
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
_______________________________________________
marf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/marf
