spam reporting

Abuse reports are a type of feedback where users can flag others' posts as abusive content. Most websites that allow user-generated content either apply a moderation based on abuse reports, such as hiding or deleting offending content at a defined threshold, or implement various user roles that allow users to cooperatively govern the site's content.{{cite conference |author=Felix Schwagereit |author2=Ansgar Scherp |author3=Steffen Staab |date=June 14–17, 2011 |title=Survey on Governance of User-generated Content in Web Communities |conference=WebSci'11 |conference-url=http://www.websci11.org/ |publisher=ACM |accessdate=2012-01-04 |url=http://www.websci11.org/fileadmin/websci/Papers/65_paper.pdf}}

Spammers' behavior ranges from forcing users to opt in to cooperatively offering opt-out options, and even hiding the sender's identity (including phishing). The most intractable cases can be addressed by reporting the abusive message to hash-sharing systems{{cite web |url=http://wiki.apache.org/spamassassin/HashSharingSystem |title=Hash-Sharing Systems |publisher=Apache Foundation |work=wiki |accessdate=15 August 2012}} such as Vipul's Razor, which benefits other potential victims. In some cases, senders may cooperate by using spam reports to fix or mitigate the problem at its origin. For example, they may use reports to detect botnets,{{cite IETF |title=Recommendations for the Remediation of Bots in ISP Networks |rfc=6561 |author1=Jason Livingood |author2=Nirmal Mody |author3=Mike O'Reirdan |date=March 2012 |publisher=IETF |accessdate=15 August 2012}} educate the sender, or simply unsubscribe the reporting user. Email spam legislation varies, forbidding abusive behavior to some extent. In some cases, prosecuting spammers and claiming damages may be possible.

RFC 6650 recommends that recipients report abusive messages 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 has subscribed to a Feedback loop (email), the mailbox provider will forward the complaint as a feedback report according to the existing FBL agreement.{{Cite web |date=2023-03-01 |title=Email Feedback Loop: What It Is and Why It Matters [2023] |url=https://mailtrap.io/blog/email-feedback-loop/ |access-date=2023-04-18 |website=mailtrap.io |language=en-GB}} Otherwise, mailbox providers should determine who is responsible for the abuse and forward the complaint to them. Recipients of unsolicited abuse reports are effectively potential FBL subscribers, as the mailbox provider needs to offer them a way to manage the report stream. On the other hand, mailbox providers can prevent further messages from non-cooperative senders of abusive content.{{cite IETF |title=Creation and Use of Email Feedback Reports: An Applicability Statement for the Abuse Reporting Format (ARF) |rfc=6650 |editor=Murray Kucherawy |date=June 2012 |publisher=IETF |accessdate=28 June 2012 |quote=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.}}

Abuse reports are sent by email using the Abuse Reporting Format (ARF), except for initial notification by the recipient in cases where an mailbox implementation provides more direct means. The target address for an abuse report depends on the authority to which the abusive message is reported. Choices include the following:{{cite web |url=http://meta.wikimedia.org/wiki/Finding_network_abuse_contacts |title=Finding network abuse contacts |author=Theo Clarke |date=10 October 2005 |publisher=Wikimedia Foundation |accessdate=22 April 2011}}

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.{{cite mailing list |url=http://www.ietf.org/mail-archive/web/asrg/current/msg15780.html |title=Adding a spam button to MUAs |author=John R. Levine |date=9 December 2009 |mailing-list=ASRG mailing list |access-date=22 April 2011}} See also the [http://wiki.asrg.sp.am/wiki/Abuse_Reporting wiki summary] of that mail thread. 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 for an authenticated domain that handled the reported message. DomainKeys Identified Mail (DKIM) is the usual authentication protocol,{{cite IETF |title=Complaint Feedback Loop Operational Recommendations |rfc=6449 |editor=J.D. Falk |date=November 2011 |publisher=IETF |accessdate=18 November 2011 |quote=Appendix B. Using DKIM to Route Feedback }} 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 received the abusive message (before the recipient reported it) and annotated the relevant IP address. Various sites maintain POC databases, such as Network Abuse Clearinghouse (by name), Abusix (by IP address), and others. 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 (abuse@example.com), or determined by querying either the RIR's whois databases (which may have query result limits{{cite web |title=Community Consultation Underway - Removal of WHOIS Query Result Limit |url=https://www.arin.net/announcements/2007/20070312.html |quote=[T]he ARIN WHOIS query limit of 256 results [...] has been in place since ARIN's inception as a means of curtailing data mining. |publisher=ARIN |date=2007-03-12 |accessdate=2009-09-28}}) or other databases created specifically for this purpose. There is a tendency to mandate the publication of exact abuse POCs.{{cite web |url=https://www.arin.net/announcements/2011/20110718.html |title=Abuse Contact To Be Mandatory per Policy 2010-14 |author=Leslie Nobile |date=18 July 2011 |work=announcements |publisher=American Registry for Internet Numbers |accessdate=24 August 2011}}{{cite web |url=http://www.apnic.net/policy/proposals/prop-079 |title=Abuse contact information |author=Tobias Knecht |date=8 November 2010 |publisher=Asia-Pacific Network Information Centre |accessdate=22 April 2011}}

Abused recipients can automate spam reporting to different degrees: they can push a button when they see the message, or run a tool that automatically quarantines and reports messages it recognizes as spam. When no specific tools are available, recipients must report abuse by hand; that is, they forward the message as an attachment (so as to include the full header) to the chosen authority. Mailbox providers can also use tools to automatically process incident notifications.One is Abusehelper

• Abuse Reporting Format
• Feedback loop (email)

{{reflist}}

{{Spamming}}

{{DEFAULTSORT:Spam Reporting}}

Category:Email

Category:Anti-spam