My comments on Steve's diffs:
On 02/Feb/12 21:35, Steve Atkins wrote:
>
> Sorry for leaving it until this late (quite possibly too late)
Still better than never.
> Removing section 8:
That is a step toward banning mail domains below a critical size. It
has very bigbrotherish implications on the resiliency, privacy, and
even democracy of the mail system. I'm strongly opposed to that.
> 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:
What was the reference to Yahoo?
> --- 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.
I'd add that sending unsolicited messages can be a way of initiating
an FBL. With respect to RFC 6449, the resulting FBL is more based on
domain authentication (including SPF) and less on IP addresses. In
particular the IP validation mentioned in Section 3.6.1 of RFC 6449
shall be fully automatic, because changing ISP cannot imply filling
out several thousands of web forms.
> @@ -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.
Advice that a message was delivered to a junk folder might be useful,
though. I think we won't get it even if we ask for it, so putting too
much emphasis on this point is worthless. However, perhaps it has to
be said that rejected messages must not be reported.
> @@ -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.
Very much agreed! I suggest X be near 5 (abuse@authenticated-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.
This latter part should go to a different paragraph. Perhaps near 12
(replying to feedback). Replies may be mail- or web-based.
> @@ -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.
Paragraph 10, for receivers, should terminate here.
> 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.
The rest of paragraph 10 and paragraph 11 (for senders) are confusing
and need additional rewording, IMHO.
> @@ -354,7 +367,16 @@
> [snip]
> -
> + 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.
Non-actionable reports could still be useful for collecting
statistics, whose evaluation may eventually result in a better
sending. This is especially true for spf- or dkim-reporting.
Should we say that the 3rd mime part of non-actionable reports should
be "text/rfc822-headers"?
_______________________________________________
marf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/marf
