On 12/Jan/12 04:28, Steve Atkins wrote: > Some comments on > https://datatracker.ietf.org/doc/draft-ietf-marf-as/?include_text=1
Thank you, Steve. Glad to read from you again on this list. > Section 5. Solicited and Unsolicited Reports > > "Scored high by spam filters" really isn't a good reason to send an > abuse report. Yet, for good messages, that use case of ARF would very closely resemble the intended use of its ancestor NDN. > 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. [...] > > 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". So this is a case where it is useful to know whether the report-trigger was auto or manual. Previous mumbling is here: http://www.ietf.org/mail-archive/web/marf/current/msg01233.html > (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. This reasoning seems to imply it is better to add a new Feedback-Type rather than a new field with a human/auto indication. (Assuming we won't then need, say, a manually-discovered-virus type.) > 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. That can be covered by reporting-discovery. > 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. IMHO, ESPs should keep current and apply BCP 167. > 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. Reporting-discovery can only cover authenticated mail (DKIM and/or SPF). For the rest, only the relay's IP address can be a meaningful automated feedback target, AFAICS. But then we'd also need to tell network providers what to do when they receive ARF messages at their abuse-mailboxes, since they are neither authors nor senders. > 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. How about 3. Mail operators are urged to utilize a system that understands ARF messages and displays and processes them adequately, along the guidelines of Section 4 of [RFC6449]. Automated systems SHOULD receive and process these reports as discussed in Section 4.4 of [RFC6449]. ? > 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. Senders of unsolicited reports need some kind of acknowledgment, sometimes, especially from new consumers that are not yet well characterized. Not boilerplate, but a few crisply handwritten lines that help to decide whether to continue sending, or stop for the time being. Would such actions then turn the FBL into a "solicited" one? _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
