Spam reporting

Spam reporting, more properly called fake reporting, is the activity of pinning abusive messages and report them to some kind of authority so that they can be dealt with. Reported messages can be email messages, blog comments, or any kind of spam.

Flagging user generated content in web sites

Abuse reports are a particular kind of feedback whereby users can flag other users' posts as abusive content. Most web sites that allow user generated content either apply some sort of moderation based on abuse reports, such as hiding or deleting the offending content at a defined threshold, or implement a variety of user roles that allow users to govern the site's contents cooperatively.[1]

Email spam reporting

Spammers' behavior ranges from somehow forcing users to opt in, to cooperatively offering the possibility to opt out, to wildly hiding the sender's identity (including phishing). The most intractable cases can be dealt by reporting the abusive message to hash-sharing systems[2] like, for example, Vipul's Razor for the benefit of other victims. In some cases, there may be a cooperative component on the sender side who will use spam reports to fix or mitigate the problem at its origin; for example, it may use them to detect botnets,[3] educate the sender, or simply unsubscribe the report's originator. Email spam legislation varies by country, forbidding abusive behavior to some extent, and in some other cases it may be worth prosecuting spammers and claiming damages.

RFC 6650 recommends that recipients of abusive messages report that to their mailbox providers. The provider's abuse-team should determine the best course of action, possibly considering hash-sharing and legal steps. If the sender had subscribed to a Feedback Loop (FBL), the mailbox provider will forward the complaint as a feedback report according to the existing FBL agreement. Otherwise, mailbox providers should determine who is responsible of the abuse and forward the complaint to them. Those recipients of unsolicited abuse reports are actually prospect FBL subscribers, inasmuch as the mailbox provider needs to offer them some means to manage the report stream. On the other hand, mailbox providers can prevent further messages from non-cooperative senders of abusive content.[4]

Abuse reports are sent by email using the Abuse Reporting Format (ARF), except for the initial notification by the recipient in cases where a mailbox implementation provides for more direct means. The target address of an abuse report depends on which authority the abusive message is going to be reported to. Choices include the following:[5]

  1. A public reporting hub, or global reputation tracker, such as SpamCop or Abusix's blackhole.mx. Different degrees of skill are required to properly interact with different hubs.
  2. The domain-specific reporting hub is the recommended choice for end users.[6] If provided, it should be accessible by a visible button or menu item in the mail client.
  3. A feedback loop subscriber can be selected as a target by a mailbox provider after receiving an end-user report. Users should be aware of their provider's policy.
  4. The abuse POC of an authenticated domain who handled the reported message. DomainKeys Identified Mail (DKIM) is the usual authentication protocol,[7] but Sender Policy Framework (SPF) can be used in the same way. A mailbox provider choice.
  5. The abuse POC for the IP address of the last relay. Some skill is required to properly locate such data. This is the default choice for a mailbox provider whose server had received the abusive message (before the recipient reported it) and annotated the relevant IP address. There are various sites who maintain POC databases, such as Network Abuse Clearinghouse (by name), Abusix (by IP address (number)), and more. There is also a hierarchy of delegations at the relevant Regional Internet registry (RIR), and each corresponding Whois record may include a POC, either as a remark or as a more specific database object, e.g. an Incident response team.

The first three methods provide for full email addresses to send reports to. Otherwise, target abuse mailboxes can be assumed to be in the form defined by RFC 2142 ([email protected]), or determined by querying either the RIR's whois databases—which may have query result limits[8]— or other databases created specifically for this purpose. There is a tendency to mandate the publication of exact abuse POCs.[9][10]

Abused receivers can automate spam reporting to different degrees: they can push a button when they see the message, or they can run a tool that automatically quarantines and reports messages that it recognizes as spam. When no specific tools are available, receivers have to report abuse by hand; that is, they forward the spammy message as an attachment—so as to include the whole header—and send it to the chosen authority. Mailbox providers can also use tools to automatically process incidents notifications.[11]

See also

References
  1. Felix Schwagereit; Ansgar Scherp; Steffen Staab (June 14–17, 2011). Survey on Governance of User-generated Content in Web Communities (PDF). WebSci'11. ACM. Retrieved 2012-01-04.
  2. "Hash-Sharing Systems". wiki. Apache Foundation. Retrieved 15 August 2012.
  3. Jason Livingood; Nirmal Mody; Mike O'Reirdan (March 2012). Recommendations for the Remediation of Bots in ISP Networks. IETF. doi:10.17487/RFC6561. RFC 6561. Retrieved 15 August 2012.
  4. Murray Kucherawy, ed. (June 2012). Creation and Use of Email Feedback Reports: An Applicability Statement for the Abuse Reporting Format (ARF). IETF. doi:10.17487/RFC6650. RFC 6650. Retrieved 28 June 2012. Rather than generating feedback reports themselves, MUAs SHOULD create abuse reports and send these reports back to their Mailbox Providers so that they can generate and send ARF messages on behalf of end users (see Section 3.2 of [RFC6449]). This allows centralized processing and tracking of reports, and provides training input to filtering systems.
  5. Theo Clarke (10 October 2005). "Finding network abuse contacts". Wikimedia Foundation. Retrieved 22 April 2011.
  6. John R. Levine (9 December 2009). "Adding a spam button to MUAs". mail. ASRG. Retrieved 22 April 2011. See also the wiki summary of that mail thread.
  7. J.D. Falk, ed. (November 2011). Complaint Feedback Loop Operational Recommendations. IETF. doi:10.17487/RFC6449. RFC 6449. Retrieved 18 November 2011. Appendix B. Using DKIM to Route Feedback
  8. "Community Consultation Underway - Removal of WHOIS Query Result Limit". ARIN. 2007-03-12. Retrieved 2009-09-28. [T]he ARIN WHOIS query limit of 256 results [...] has been in place since ARIN's inception as a means of curtailing data mining.
  9. Leslie Nobile (18 July 2011). "Abuse Contact To Be Mandatory per Policy 2010-14". announcements. American Registry for Internet Numbers. Retrieved 24 August 2011.
  10. Tobias Knecht (8 November 2010). "Abuse contact information". Asia-Pacific Network Information Centre. Retrieved 22 April 2011.
  11. One is Abusehelper
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.