> -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of Steve > Atkins > Sent: Monday, January 23, 2012 11:10 AM > To: Message Abuse Report Format working group > Subject: Re: [marf] Some thoughts on draft-ietf-marf-as-02 > > > A report generator SHOULD NOT generate automated reports based on > > inline content analysis tools that apply subjective 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. > > This does overlap with malware detection, though. Malware detection is > based on subjective heuristics, and does have occasional false > positives, but I think a report of an IP address sending malware would > be considered actionable by an ISP abuse desk where a report of it > sending "spam" based on subjective heuristics wouldn't. > > I'm not sure what the distinction is other than "likely to be > actionable".
Ah, true. But reducing this to just talk about "likely to be actionable" fails to point out the very distinction you've made, which I think is a good one. How about: OLD 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. NEW However, it is inadvisable to generate automated reports based on inline content analysis tools that apply subjective evaluation rules, such as filters that attempt to classify spam or phishing. This can cause reports that, because of their subjective nature, are not actionable by report receivers, which wastes valuable operator time in processing them. By contrast, virus detection reports are far more likely to be actionable. > > This is true, but I don't think that means the advice at the bottom > > of Section 5 is wrong, since it only suggests the DKIM-verified domain > > is a "reasonable candidate". > > It's not wrong, but it's a bit misleading. Calling out a DKIM-verified > domain in particular as a good candidate suggests it's one that should > be used, even though it's often going to be a bad candidate and the > heuristics needed to work out whether it's appropriate or not aren't > trivial. > > > Perhaps the right thing to do is describe cases where that'll be a > > good guess, but a wrong one. > > Perhaps. I think moving it to section 8 helps resolve the problem, as > the context is there. > > > I also think Section 8 should start at "abuse@" (referenced in > > Section 7) as being the only reasonable default. > > Probably, yes. That leaves open the question of "which domain", though. > The existing wording is sensible, but very vague on implementation > details (sensibly - it's something tricky to do well, and non-trivial > to even do non-abusively). The more we try and get into details there, > the more we're going to hit problems. Have a look at -03 (now posted) and see what you think. > > Section 8. Generating and Handling Unsolicited Reports > >> > >> Is authentication failure abusive? If it is, we should say why (and > >> in what context). If not, it shouldn't be in this document. > > > > There are cases where one might think it is, such as ADSP violations > > for sites that put a lot of faith in it, but it's not universal. > > Additional detail might be helpful there. > > Yup. It's not obvious which cases this means, so we probably need more > detail if we're going to mention it. > > (Does this overlap with draft-ietf-marf-dkim-reporting and draft-ietf- > marf-spf-reporting?) No, I don't think so. (And I think we should avoid doing so.) > >> I know for sure that there are ticketing systems in use that don't > >> handle anything other than plain text particularly well. They will > >> not handle ARF reports as well as they would handle plain text. > > > > I imagine the text there envisions a system that handles in an > > automated fashion anything that it understands, and leaves the rest to > > operators to figure out. > > Operators who are using typical MUAs or low-end CRM systems will have > difficulty handling ARF reports at all, and may only have convenient > access to the text/plain part of the message. If the intent is that the > report is acted on, it has to be able to be read and acted on by those > operators as well as by automation. Have a look at -03 and see what you think. > There's another can of worms - if we're talking about sending > unsolicited email to addresses guessed at via heuristics, do we also > want to talk about "MUST provide an easy way to opt-out of all future > reports"? Yes, that's probably good to include as well. Absent objection, I'll add that in -04. -MSK _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
