As participant: > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of Steve > Atkins > Sent: Wednesday, January 11, 2012 7:28 PM > To: Message Abuse Report Format working group > Subject: [marf] Some thoughts on draft-ietf-marf-as-02 > > 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. > 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". Perhaps the right thing to do is describe cases where that'll be a good guess, but a wrong one. > That's one instance of a more general issue of sending automated, > unsolicited reports. Identifying an appropriate recipient for a report > is *hard* to do automatically, while "shotgunning" reports to multiple > email addresses because one of them might be appropriate is unhelpful. > Sending them in a format that's intended primarily to be machine- > readable and handled automatically by the entity receiving the reports > leads to the problem of knowing what email address at what entity is > intended to handle machine-readable reports. There's no standard for > it, and there's a risk that those machine-readable reports will be > discarded or ignored if they're sent to role addresses chosen at > random. > > 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. > Section 7. Receiving and Processing Complaint-Based Solicited Reports > > "Point 3 - Mail operators SHOULD utilize an automated system to receive > and process these reports". > > That's really an engineering and operational decision. If I only > receive two or three ARF reports a day, and my MUA or ticketing system > can display them correctly, then handling them as part of my usual > customer support / abuse desk workflow is likely to be more reliable > (and much less expensive to implement) than an automated system. An ARF > based FBL is still of value to me, but automating it would be a poor > decision. RFC 6449 Section 4.4 says pretty much that. I think we'd be > better just pointing people at that section of RFC 6449, rather than > saying that automation is a SHOULD. Works for me. > 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. > 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. > 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. > 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? -MSK _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
