On 3/30/12 4:49 AM, Murray S. Kucherawy wrote:
Addresses AD feedback about use of normative language.
Finally back in the land of the living...
I did a thorough review and I still have a bunch of concerns. As always,
you can tell me I'm full of crap, but some of these are places where I
find the text incomprehensible, and I suspect other ADs will have
similar problems. Please have a look:
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.
5.1.1.
At the time this document is being written, for the use cases
described here, mail operators need to proactively request a
stream of ARF reports from Mailbox Providers. Recommendations
for preparing to make that request are discussed in Section 4.1
of [RFC6449].
Strike "At the time this document is being written, for the use cases
described here". It seems utterly obvious. If you write a new document
with new use cases, you can change the instruction. Also, why "need to"
instead of "MUST"?
2. Furthermore, this document assumes that mail operators exchange
abuse reports formatted per ARF [RFC5965] as email messages
[RFC5322] over SMTP [RFC5321]. These and other types of email
messages that can be received are discussed in Section 4.2 of
[RFC6449].
Ugh. I preferred your earlier attempt on the list or Barry's wording
much better. I don't really care what the "document assumes". I say go
with "Operators MUST be able to accept...".
3. Mail operators need to consider the idea of automating report
processing. Discussion of this can be found in Section 4.4 of
[RFC6449].
I don't really understand what that means and I don't see how it is
actionable. What do you want mail operators to do?
5.2.1.
An automated report processing system MUST accept all Feedback-
Types defined in [RFC5965] or extensions to it. However, report
receivers cannot assume that Mailbox Providers will make use of
any Feedback-Type other than "abuse", except with prior specific
knowledge. Additional analysis might be required to separate
different types of abuse reports after receipt.
The first sentence is fine. After that, I suggest, "However, Mailbox
Providers may only make use of the "abuse" Feedback-Type. Therefore
report receivers might be required to do additional analysis to separate
different types of abuse reports after receipt if they do not have prior
specific knowledge of the sender of the report."
2. Implementers SHOULD NOT expect all Mailbox Providers to include
the same optional fields.
How about, "Implementers MUST accept different combinations of optional
fields since Mailbox Providers might not include the same ones."?
3. Reports may have been subjected to redaction of user-identifiable
data as described in [I-D.IETF-MARF-REDACTION]. That document
also discusses the handling of such reports. This technique is
also discussed in Section 4.4 of [RFC6449].
"Report receivers MUST/SHOULD accept reports that have been subject to
redaction". Is that what you mean?
5.3.1
Actions that mail operators might take upon receiving a report
(or multiple reports) are discussed in Section 4.3 of [RFC6449].
Completely stylistic: "Section 4.3 of [RFC6449] discusses actions..."
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.
6.2.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.
I don't get why 2119 language is being avoided in the above. Why not
s/need to be aware of this and do all they reasonably can to avoid
sending/[MUST/SHOULD] NOT send ?
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.
6.4.3
Finally, they need to be
aware that the report could be discarded or ignored due to
failure to take these steps in the most extreme cases.
How about, "In extreme cases, failure to do these things may result in
the report being discarded or ignored."?
7.1
Selection of the recipient(s) for reports that are automatically
generated MUST be done based on data provided by the report
recipient, and MUST NOT be done heuristically. Therefore these
reports are always solicited, such as the mechanisms defined in
the examples listed above.
Stylistic: "Automatic report generators MUST select recipients based on
data provided by the report recipient. In particular, recipients MUST
NOT be selected heuristically."
3. When sending a new report via SMTP, it is necessary to construct
the message so as to avoid amplification attacks, deliberate or
otherwise. The envelope sender address of the report needs to be
chosen so that these reports will not generate mail loops.
Similar to Section 2 of [RFC3464], the envelope sender address of
the report needs to be chosen to ensure that no feedback reports
will be issued in response to the report itself. Therefore, when
an SMTP transaction is used to send a report, the MAIL FROM
command SHOULD use the NULL reverse-path, i.e., "MAIL FROM:<>".
Again, it seems that more 2119 language is appropriate here:
The message for a new report sent via SMTP MUST be constructed
so as to avoid amplification attacks, deliberate or
otherwise. The envelope sender address of the report MUST be
chosen so that these reports will not generate mail loops.
Similar to Section 2 of [RFC3464], the envelope sender address of
the report MUST be chosen to ensure that no feedback reports
will be issued in response to the report itself. Therefore, when
an SMTP transaction is used to send a report, the MAIL FROM
command SHOULD use the NULL reverse-path, i.e., "MAIL FROM:<>".
I'm not totally clear on why the final "SHOULD" is not a "MUST", but I
guess I can see that you might form it differently.
And finally, in the stylistic category, each section starts with:
The following subsections include statements applicable when XYZing
Gads, I hate the passive construction. I don't have a recommendation.
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
