> -----Original Message----- > From: Benoit Claise [mailto:[email protected]] > Sent: Monday, April 23, 2012 2:45 AM > To: The IESG > Cc: [email protected]; [email protected] > Subject: Benoit Claise's Discuss on draft-ietf-marf-as-14: (with > DISCUSS and COMMENT) > > Benoit Claise has entered the following ballot position for > draft-ietf-marf-as-14: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > Please refer to http://www.ietf.org/iesg/statement/discuss- > criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > DISCUSS-DISCUSS > > Abstract > > RFC 5965 defines an extensible, machine-readable format intended for > mail operators to report feedback about received email to other > parties. This Applicability Statement describes common methods for > utilizing this format for reporting both abuse and authentication > failure events. Mailbox Providers of any size, mail sending > entities, and end users can use these methods as a basis to create > procedures that best suit them. Some related optional mechanisms are > also discussed. > > Before reviewing this draft, I browsed through the 4 RFCs at > http://datatracker.ietf.org/wg/marf/ > Question: is this intentional that the abstract and the draft only > mention the "abuse" and "auth-failure" Feedback Type Name, and not the > others ones? > fraud [RFC5965] > not-spam [RFC6430] > virus [RFC5965] > > Not a single reference to fraud, not-spam, virus, and [RFC6430] I'm > surprised not to see the full ARF capacities mentioned in a document > titled "An Applicability Statement for the Abuse Reporting Format > (ARF)", and would like to understand.
We've simply not seen enough use of these in the wild to be able to comment on their proper or recommended use in this AS. The original document that became RFC5965 actually listed a large number of other report types that were at one time thought to be useful, but were removed prior to publication because nobody had used them. "fraud" and "virus" did see rare use but remain edge cases, so they remained in the list registered by RFC5965. We can (and probably should) mention this in the Introduction. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > - I see a lot of sentences such as "... discussed in Section X of > [RFC6449]." > And the only sentence in the introduction related to that RFC is: > "Further introduction to this topic may be found in [RFC6449]." > Some sentences explaining what this informational RFC is about would be > very welcome. I propose this as the last paragraph to the Introduction: Further introduction to this topic may be found in <xref target="RFC6449"/>, which is effectively an Applicability Statement written outside of the IETF and thus never achieved IETF consensus. Much of the content for that document was input to this one. > - please expand SPF OK, and will do for DKIM as well. > - Section 5.2 > "RFC5321.MailFrom" Doesn't read right to me in: "If a Feedback Provider > applies SPF to arriving messages, a report SHOULD NOT be generated to > the RFC5321.MailFrom domain" It's a notation introduced in RFC5598, which is a normative reference here. -MSK _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
