On Feb 2, 2012, at 11:20 AM, Murray S. Kucherawy wrote:
> Yes, please.
>
> I don’t need a unified diff for something simple like “Remove Section 8”, but
> if that leaves any connecting tissue dangling, I’d like some specific updates
> to resolve those.
>
Yup. Sorry for leaving it until this late (quite possibly too late) in the
process, but it wasn't until I was rereading section 8 for the n-th time
that I spotted the wood through the trees.
Removing section 8:
--- draft-ietf-marf-as-05.txt 2012-01-31 09:28:20.000000000 -0800
+++ new.txt 2012-02-02 11:35:46.000000000 -0800
@@ -143,22 +143,17 @@
messages as spam. We refer to these as solicited reports.
Other uses for ARF involve reports sent between parties that don't
- know each other, with the recipient address typically being
- abuse@domain (see [RFC2142]), looked up via WHOIS, or using other
- heuristics. The reports may be manual, or automated due to hitting
- spam traps, or caused by anything else that the sender of the report
- considers to merit an abuse report. Abuse addresses in WHOIS records
- of the source IP and of the domain found in the results of a PTR
- ("reverse lookup") query on that address are likely reasonable
- candidates for receiving feedback about the message, although
- automated parsing may be difficult, and such addresses are not
- guaranteed to be useful.
-
- However, it is inadvisable to generate automated reports based on
- inline content analysis tools that apply subjective evaluation rules.
- This can cause reports that, because of their subjective nature, are
- not actionable by report receivers, which wastes valuable operator
- time in processing them.
+ know each other. These unsolicited reports are sent without prior
+ agreement and without prior arrangement between the parties as to
+ the context and meaning of the reports, so the constraints on how
+ these unsolicited reports need to be generated such that they are
+ likely to be useful to the recipient, where they can usefully be
+ sent to, what issues they can be used to report and how they can
+ be handled by the receiver of the report are very different.
+
+ In this document we discuss only solicited reports. Further discussion
+ of unsolicited reports can be found in [reference].
+
Less drastic suggestion, moving the discussion of unsolicited
reports to it's own section, removing reference to Yahoo, mentioning
that ARF reports can be crafted to be more text/plain friendly, adding
a MUST allow unsubscribes, a few other minor tweaks and a moral
at the end:
--- draft-ietf-marf-as-05.txt 2012-01-31 09:28:20.000000000 -0800
+++ new2.txt 2012-02-02 12:30:01.000000000 -0800
@@ -143,22 +143,15 @@
messages as spam. We refer to these as solicited reports.
Other uses for ARF involve reports sent between parties that don't
- know each other, with the recipient address typically being
- abuse@domain (see [RFC2142]), looked up via WHOIS, or using other
- heuristics. The reports may be manual, or automated due to hitting
- spam traps, or caused by anything else that the sender of the report
- considers to merit an abuse report. Abuse addresses in WHOIS records
- of the source IP and of the domain found in the results of a PTR
- ("reverse lookup") query on that address are likely reasonable
- candidates for receiving feedback about the message, although
- automated parsing may be difficult, and such addresses are not
- guaranteed to be useful.
-
- However, it is inadvisable to generate automated reports based on
- inline content analysis tools that apply subjective evaluation rules.
- This can cause reports that, because of their subjective nature, are
- not actionable by report receivers, which wastes valuable operator
- time in processing them.
+ know each other. These unsolicited reports are sent without prior
+ agreement and without prior arrangement between the parties as to
+ the context and meaning of the reports, so the constraints on how
+ these unsolicited reports need to be generated such that they are
+ likely to be useful to the recipient, where they can usefully be
+ sent to, what issues they can be used to report and how they can
+ be handled by the receiver of the report are very different.
+
+
@@ -246,6 +239,8 @@
8. Generating and Handling Unsolicited Reports
+
+
1. Systems that generate unsolicited reports SHOULD ensure that the
criteria used to decide what messages to report accurately
identify messages that the reporting entity believes in good
@@ -255,7 +250,11 @@
failures, and virus reports. (These applications might be
described in future IETF documents.) Systems SHOULD NOT report
all mail sent from a particular sender merely because some of it
- is determined to be abusive.
+ is determined to be abusive. Mechanical reports of mail that
+ "looks like" spam, based solely on the results of inline content
+ analysis tools SHOULD NOT be sent as, because of their subjective
+ nature, they are unlikely to provide a basis for the recipient
+ to take action.
2. With respect to authentication failures, these could occur for
legitimate reasons outside of the control of the author. A
report generator SHOULD be cautious to generate reports only in
@@ -272,7 +271,21 @@
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.
-
+ X. Deciding where to send an unsolicited report will typically
+ rely on heuristics. Abuse addresses in WHOIS records
+ of the source IP and of the domain found in the results of
+ a PTR ("reverse lookup") query on that address are likely
+ reasonable candidates, as is the abuse@domain role address
+ (see [RFC2142]) of related domains. Unsolicited reports
+ SHOULD NOT be sent to email addresses which are not intended
+ to handle abuse reports, including any personal or role address
+ found in WHOIS records or on a web site that isn't either
+ explicitly described as an abuse contact or is of the form
+ abuse@domain.
+ Additionally, a report generator MUST provide a way for
+ a report recipient to request no further reports be sent
+ to them and MAY provide a way for recipients to change
+ the address(es) reports about them are sent to.
@@ -311,19 +324,19 @@
originating customer.
10. Published abuse mailbox addresses SHOULD NOT reject messages not
in the ARF format, as generation of ARF messages can
- occasionally be unavailable or not applicable. Nevertheless,
- some large messaging service providers specifically request that
- abuse reports be sent to them in ARF format. Experience of
+ occasionally be unavailable or not applicable. Experience of
systems that send abuse reports in ARF format suggests that even
automated recipient systems that haven't asked for ARF format
reports handle them at least as well as any other format such as
- plain text, with or without a copy of the message attached.
+ plain text, with or without a copy of the message attached, if
+ the original report has been generated with use by recipients
+ not using automated ARF parsing in mind.
This suggests use of ARF is advisable in most contexts.
11. This is, however, not universally true. Anyone sending
unsolicited reports in ARF format can legitimately presume that
recipients will not be able to see the ARF metadata (i.e., those
- elements present in the second part of the report), and instead
- MAY include all information needed in the human readable (first,
+ elements present in the second part of the report), and MAY
+ also include all information needed in the human readable (first,
text/plain) section of the report. Further, they MAY ensure
that the report is readable when viewed as plain text, to give
low-end ticketing systems as much assistance as possible.
@@ -354,7 +367,16 @@
reporting addresses belonging to the abusive parties themselves.
Reports SHOULD NOT be sent to such addresses if they can be
identified beforehand.
-
+ 14. Handling unsolicited reports has a significant cost to the
+ receiver. Senders of unsolicited reports, especially those
+ sending large volumes of them mechanically, need to be aware
+ of that and do all they reasonably can to avoid sending
+ reports that cannot be used as a basis for action by the
+ recipient - whether that is due to the report being sent
+ about an incident that isn't abuse-related, it being sent to
+ an email address that can't take action on it, or due to the
+ content or format of the report being hard for the recipient
+ to read or use.
9. IANA Considerations
Cheers,
Steve
_______________________________________________
marf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/marf
