Some comments on https://datatracker.ietf.org/doc/draft-ietf-marf-as/?include_text=1
Most of the document looks fine, but I have some concerns about the sections that deal with unsolicited reports. Section 5. Solicited and Unsolicited Reports "Scored high by spam filters" really isn't a good reason to send an abuse report. Sending mail that "looks like" spam according to a mechanical content filter isn't an AUP violation, and reports about it aren't going to be actionable as there's nothing wrong with sending mail with a high spamassassin score. While, arguably, reports of mail that "looks like" spam might be a basis for investigation by an abuse desk as to whether a customer is doing something wrong it's not a very useful basis - if there is a source of mail on your network that's found offensive by recipients, you'll find out fairly quickly by receiving informed abuse reports, manually or from this-is-spam-button driven feedback loops, so reports of mail that "looks like" spam aren't going to provide much data that the abuse desk won't already have via other channels. 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". (Automated reports of spam-like content may well be useful as part of an "avoid false positives" sort of feedback loop, but not as an abuse report. And automated reports of mail that has virus or malware content might be appropriate, even though spam-like content isn't.) 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. 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? 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. 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. 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. 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. As an example, here's a snapshot of an ARF report displayed by Mail.app: https://skitch.com/steveatkins/g2bkt/inbox-27642-messages-33-unread And here's one displayed by gmail: https://skitch.com/steveatkins/g2bck/inbox-27642-messages-33-unread And Outlook Express: https://skitch.com/steveatkins/g2bpj/192.168.80.89 All three of those are more sophisticated than the web-based ticketing systems commonly used at smaller ISPs. (Alpine, OTOH, displayed it just fine - https://skitch.com/steveatkins/g2bq8/steve-infrastructure-mail ) Ticketing systems are one of the last bits of the email system that don't handle MIME particularly robustly, if at all, and abuse desks are (quite reasonably) wary of clicking on attachments - all attachments, including attached message/rfc822. Quite a few ISPs (including national US ISPs) ask reporters explicitly to not forward email as an attachment, rather to paste the headers and body of the mail being reported into a new message, due to either tool limitations or a policy not to open attachments for security reasons. Everybody can handle the lowest common denominator of text/plain, but that's about it. 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 don't think that experience purely of sending unsolicited ARF reports can really lead to the claim that all recipients handle them well - as the recipients that *don't* handle them well are simply going to discard or ignore the report, rather than trying to work out why it was sent. Abuse desks generally have more than enough actionable reports in their queue to waste time trying to decipher ones that they can't read. IIRC, John includes a link to a web-based rendering of each report in the plain text part of the unsolicited reports he sends out (not a bad idea, if you have the infrastructure for it), so they may be more widely readable by abuse desks than an ARF format report would be. Cheers, Steve _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
