Spam reporting
Spam reporting, more properly called abuse reporting, is the process of identifying electronic messages as abusive and reporting them to an authority (e.g., an email administrator) for resolution. Reported messages can be email messages, blog comments, or any kind of spam.
Flagging user generated content in web sites
[edit]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.[1]
Email spam reporting
[edit]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[2] 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,[3] 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.[4] 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.[5]
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:[6]
- 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.
- The domain-specific reporting hub is the recommended choice for end users.[7] If provided, it should be accessible by a visible button or menu item in the mail client.
- 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.
- The abuse POC for an authenticated domain that handled the reported message. DomainKeys Identified Mail (DKIM) is the usual authentication protocol,[8] but Sender Policy Framework (SPF) can be used in the same way. A mailbox provider choice.
- 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[9]) or other databases created specifically for this purpose. There is a tendency to mandate the publication of exact abuse POCs.[10][11]
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.[12]
See also
[edit]References
[edit]- ^ 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.
- ^ "Hash-Sharing Systems". wiki. Apache Foundation. Retrieved 15 August 2012.
- ^ 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.
- ^ "Email Feedback Loop: What It Is and Why It Matters [2023]". mailtrap.io. 2023-03-01. Retrieved 2023-04-18.
- ^ 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.
- ^ Theo Clarke (10 October 2005). "Finding network abuse contacts". Wikimedia Foundation. Retrieved 22 April 2011.
- ^ John R. Levine (9 December 2009). "Adding a spam button to MUAs". ASRG mailing list (Mailing list). Retrieved 22 April 2011. See also the wiki summary of that mail thread.
- ^ 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
- ^ "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.
- ^ Leslie Nobile (18 July 2011). "Abuse Contact To Be Mandatory per Policy 2010-14". announcements. American Registry for Internet Numbers. Retrieved 24 August 2011.
- ^ Tobias Knecht (8 November 2010). "Abuse contact information". Asia-Pacific Network Information Centre. Retrieved 22 April 2011.
- ^ One is Abusehelper