On Jan 23, 2012, at 10:22 AM, Murray S. Kucherawy wrote: > As participant: >> >> Section 5. Solicited and Unsolicited Reports >> [...] >> Non-actionable reports - whether they be false positives or not - >> reduce the efficiency of an abuse desk. Let's just not mention reports >> of mail scored high by spam filters, and quietly leave it as part of >> "anything else the sender considers". > > I agree, and actually I agree enough that I would advocate for addition of a > SHOULD NOT. The question is one of wording. Perhaps: > > 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". >> The DKIM signer of a message is definitely a good target for solicited >> reports as part of a feedback loop. For unsolicited reports it's much >> less clear that that's the case. There are some mechanical reasons - >> the d= value is an identifier for reputation, not a domain intended to >> receive email, so we don't want to imply that >> [email protected] is automatically a good place to report >> mail that's signed with d=transactional.blighty.com. In a broader >> sense, though, it's likely that the DKIM signing domain is the author >> of the mail - and if the mail is objectionable, they're often the least >> useful place to notify. In the case of mail sent through an ESP, the >> DKIM d= domain is likely to end up at the customer, rather than at the >> ESP where it's more likely to be handled correctly. > > 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. >> Section 8 discusses this issue again, and somewhat better. Would it >> make sense to move the mention of DKIM to section 8, where it would be >> in a better context? > > Yes, that seems reasonable. > > 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. > 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?) >> I'm not sure it's true that "even 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." >> >> 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. >> Unexpected multipart/* formats (such as the multipart/report type used >> by ARF) aren't necessarily going to be handled well even by MIME aware >> MUAs. Similarly, message/feedback-report isn't necessarily going to be >> handled well by MIME aware MUAs. > > I don't think that paragraph means to include MUAs in the agents it's > discussing, but rather is referring to automated systems. Perhaps that > should be made clearer here. If you're sending solicited reports that's a sensible distinction. I'm not sure it is in this context. >> So... I don't think it's valid to say that recipient systems that are not >> advertised to accept ARF will render ARF format messages in a way that >> will lead to them being handled. At the very least, anyone sending >> unsolicited messages in ARF format must assume that recipients will not >> be able to see the ARF metadata, and should include all information >> needed in human readable format in the first, text/plain section of the >> report. Also, they should ensure that the report is readable when >> viewed as plain text, to give low end ticketing systems as much help as >> possible - that might includes advice on appropriate MIME encoding and >> choice of character sets and so on. And they should be aware that the >> report may be discarded or ignored due to it's format. > > I wouldn't object to including this advice while avoiding use of normative > language. That is, I wouldn't want to say "SHOULD put all the useful data in > the text/plain part of an ARF report", because then why bother at all? You're sending unsolicited reports to people whose capabilities you have fairly limited information about. You would like them to be able to process that report using whatever system you happen to end up being delivered to. That includes ARF-aware full automation in some cases, and it includes very basic web-based MUAs (ticketing systems) in other cases. If you want the report to be easily processed by the ARF-aware automation then all the information needs to be available as ARF metadata. If you want the report to be easily processed by an MUA then it needs to be easily readable using a text/plain MUA. If you want it to be easily processed by both types of recipient, and you don't know which you're sending it to, then it needs to both have ARF metadata and be easily readable using a text/plain MUA. Anyone sending ARF-only reports with a non-actionable plain text part today is making the same sort of decision as someone who sent text/html-only email a decade ago. It's great for recipients who can read it, but many can't. That doesn't mean that we need normative language, but making it clear that if you're sending unsolicited reports that are not readable by a text/plain level MUA you may well be wasting your time and, more importantly, the time of the recipient of your report is something we should probably mention. "Senders SHOULD NOT assume that the recipient of an unsolicited report is able to make full use of an ARF format report. Unless the sender has reason to believe that all recipients of an unsolicited report can conveniently handle ARF format then they SHOULD ensure that the report is clear and contains enough information to be handled appropriately when viewed in a typical MUA or ticketing system." 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"? Cheers, Steve _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
