Fwd: [anti-abuse-wg] How to Ask For A Website to Be taken Down, was How Not To Ask For A Website to Be taken Down
... This too. ---------- Forwarded message ---------- From: Mark Foster <blakjak@gmail.com> Date: Fri, Dec 24, 2010 at 9:54 AM Subject: Re: [anti-abuse-wg] How to Ask For A Website to Be taken Down, was How Not To Ask For A Website to Be taken Down To: tk@abusix.com 2010/12/24 Tobias Knecht <tk@abusix.com> Hi all,
Does it make any sense to produce a RIPE document suggesting the proper way to report abuse?
This document can be short & sweet, just like the reports should be. A few good ideas are already in this thread: report to the right people, say the important bits up-front, and so on.
We are already working on a format, that is used by more and more people. It is meant as an extension to the well known RFC 5965 ARF. Called X-ARF. http://xarf.org
Everybody who is interested in helping and using it, let us know and we can subscribe you to the mailinglist.
Some tools are already available here: https://github.com/xarf
Anything that makes reporting abuse harder for the victim, is counter-productive, IMHO. This to me is all an attempt to make abuse-complaint-receivers better equipped to use automation to deal with complaints. Noone who reports abuse likes talking to automation. Mark.
On 24/Dec/10 22:44, Mark Foster wrote:
2010/12/24 Tobias Knecht <tk@abusix.com <mailto:tk@abusix.com>>
We are already working on a format, that is used by more and more people. It is meant as an extension to the well known RFC 5965 ARF. Called X-ARF. http://xarf.org
Anything that makes reporting abuse harder for the victim, is counter-productive, IMHO.
Automation is supposed to make reporting easier for the victim, not harder. Many webmail sites already have a "Report as Spam" button. It should be added to regular (POP3/IMAP) mail clients too.
This to me is all an attempt to make abuse-complaint-receivers better equipped to use automation to deal with complaints.
Yes, for the good and the bad of it. Among the goodies, it should be feasible to to route spam reports so that a network provider gets a copy and forwards it to the relevant mailbox provider, thereby allowing the former to somehow control the latter.
Noone who reports abuse likes talking to automation.
I think you mean noone who /manually/ reports abuse, as in the OP BofA case. If an abuse@ mailbox is equipped with software that recognizes automatic formats, human recipients might still be able to read the rest in the usual way. Whether a hand-written complaint should be sent to an abuse@ address depends on how report formats will take on. This consideration may explain why some organizations try and push a specific format. The abuse@ address is just mentioned by RFC 2142, but issuing a spam report does not necessarily require even SMTP, although it seems to be the most natural way of reporting email abuse. BTW, there is a third format, developed in the framework of RFC 6045.
On Wed, Dec 29, 2010 at 4:31 AM, Alessandro Vesely <vesely@tana.it> wrote:
On 24/Dec/10 22:44, Mark Foster wrote:
2010/12/24 Tobias Knecht <tk@abusix.com <mailto:tk@abusix.com>>
We are already working on a format, that is used by more and more people. It is meant as an extension to the well known RFC 5965 ARF. Called X-ARF. http://xarf.org
Anything that makes reporting abuse harder for the victim, is counter-productive, IMHO.
Automation is supposed to make reporting easier for the victim, not harder. Many webmail sites already have a "Report as Spam" button. It should be added to regular (POP3/IMAP) mail clients too.
Yes, and this is a key point. Standard formats for abuse reporting via email will in turn allow email client developers to embed the tech required to simplify reporting of abuse. However by making it easier, you also increase the chances that the report is inadvertant? For example Gmail allow you to 'undo' reporting as Spam. This would also need to be an option available to a user....
This to me is all an attempt to make abuse-complaint-receivers better equipped to use automation to deal with complaints.
Yes, for the good and the bad of it. Among the goodies, it should be feasible to to route spam reports so that a network provider gets a copy and forwards it to the relevant mailbox provider, thereby allowing the former to somehow control the latter.
Concur, though again the use of automation means that the network provider can turn a blind eye to it and claim that appropriate action is being taken... it doesn't inspire folks to manually check to ensure action is infact being taken, that reports aren't repeat in nature, etc.
Noone who reports abuse likes talking to automation.
I think you mean noone who /manually/ reports abuse, as in the OP BofA case. If an abuse@ mailbox is equipped with software that recognizes automatic formats, human recipients might still be able to read the rest in the usual way.
Whether a hand-written complaint should be sent to an abuse@ address depends on how report formats will take on. This consideration may explain why some organizations try and push a specific format. The abuse@ address is just mentioned by RFC 2142, but issuing a spam report does not necessarily require even SMTP, although it seems to be the most natural way of reporting email abuse.
BTW, there is a third format, developed in the framework of RFC 6045.
My main personal frustration is that as a 'power' end-user, I read email in various ways; serverside commandline mail program, webmail tool, various pop3/imap tools. At work i'm either using the COE email application or a CRM system that manages email. None of these will support a common, standards-driven method of generating abuse@ reports for spam, etc, for some time. In the meantime i'm constantly frustrated by the time that i'm obliged to waste either a) reporting abuse in the method that ISP X demands, or b) trashing large volumes of junk because to do anything else would taken even _ longer_. I'm not averse to standard (infact i'm a big fan) but i'm also a big fan of ensuring a human remains in the loop and able to accept reports that're not within the standard format, at least until it's reasonable to expect _everyone_ to be using the standard format (which could take years)... Mark.
In message <AANLkTim6d-VDGyjVWB9C6+dxEorSyCXjmrZKNO+npaWD@mail.gmail.com>, Mark Foster <blakjak@gmail.com> wrote:
Concur, though again the use of automation means that the network provider can turn a blind eye to it and claim that appropriate action is being taken...
Those so inclined are already doing that anyway, automation or no automation.
... it doesn't inspire folks to manually check to ensure action is infact being taken, that reports aren't repeat in nature, etc.
I'm not persuaded that it deters such follow-up either. As I (sort of) said earlier, we have have all the standards we want for WHO to report network abuse to, and even HOW gto report it, but until we have a standard that says what any decent self-respecting network operator or service provider should actually DO, at a minimum, in response to such reports, nothing is going to be any better than it is right now. (It may also not get any better even _after_ we have a formal BCP that we can try to shame wayward providers with, but at least it will be entirely less ambiguous who is and isn't living up to their community responsibilities, once a BCP for abuse handling is ratified and in place.) Regards, rfg
On 29/Dec/10 01:30, Mark Foster wrote:
On Wed, Dec 29, 2010 at 4:31 AM, Alessandro Vesely <vesely@tana.it <mailto:vesely@tana.it>> wrote:
Automation is supposed to make reporting easier for the victim, not harder. Many webmail sites already have a "Report as Spam" button. It should be added to regular (POP3/IMAP) mail clients too.
Yes, and this is a key point. Standard formats for abuse reporting via email will in turn allow email client developers to embed the tech required to simplify reporting of abuse. However by making it easier, you also increase the chances that the report is inadvertant? For example Gmail allow you to 'undo' reporting as Spam. This would also need to be an option available to a user....
Implementation is lacking. Policies should be devised so that complaints are transmitted backward to each responsible relay, forwarder, or author, along some trusted path. For single hops, this is currently carried out with feedback loops. The possibility to challenge a report should be granted to authors. That is, it would be fair if authors could prompt careless reporters for undoing their reports. In facts, purported authors are probably the only humans who may want to look at the body of a reported message.
This to me is all an attempt to make abuse-complaint-receivers better equipped to use automation to deal with complaints.
Yes, for the good and the bad of it. Among the goodies, it should be feasible to to route spam reports so that a network provider gets a copy and forwards it to the relevant mailbox provider, thereby allowing the former to somehow control the latter.
Concur, though again the use of automation means that the network provider can turn a blind eye to it and claim that appropriate action is being taken... it doesn't inspire folks to manually check to ensure action is infact being taken, that reports aren't repeat in nature, etc.
This may also be covered by adequate policy dressing. For example, a mailbox provider may choose to ban authors from sending for a period of time proportional to the number of complaints. Such policy can be verified by looking at the "auth" property of reported messages --along with a bunch of methods to validate authentication policies for the relevant provider. This kind of treatment hinges on the ever-missing reputation system...
Whether a hand-written complaint should be sent to an abuse@ address depends on how report formats will take on.
My main personal frustration is that as a 'power' end-user, I read email in various ways; serverside commandline mail program, webmail tool, various pop3/imap tools. At work i'm either using the COE email application or a CRM system that manages email. None of these will support a common, standards-driven method of generating abuse@ reports for spam, etc, for some time. In the meantime i'm constantly frustrated by the time that i'm obliged to waste either a) reporting abuse in the method that ISP X demands, or b) trashing large volumes of junk because to do anything else would taken even _ longer_.
Mailbox providers should help here. The entity responsible for accepting a message may want to provide the means for reporting it as spam, including any required formatting. IMAP allows for considerable optimizations for such kind of actions. For POP3, it has been proposed to submit reports to the abuse-mailbox at the server indicated in the Authentication-Results field (the authserv-id of RFC 5451, Section 2.3, in case it is actually a fully-qualified domain name). In any case, reporting through the receiver gives it a chance to adjust its reputation and Bayesian records.
I'm not averse to standard (infact i'm a big fan) but i'm also a big fan of ensuring a human remains in the loop and able to accept reports that're not within the standard format, at least until it's reasonable to expect _everyone_ to be using the standard format (which could take years)...
The fact remains that reading the body of messages reported as spam is a frustrating job that no human would want to routinely undertake. OTOH, there will always be unusual abuse cases that deserve human intelligence.
participants (3)
-
Alessandro Vesely -
Mark Foster -
Ronald F. Guilmette