Spam Reporting

Spam reporting, more properly called abuse reporting, is the action of designating electronic messages as abusive for reporting to an authority (e.g. an email administrator) 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.

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'' 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, 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.

''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:

# 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. 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 of an authenticated domain who handled the reported message. DomainKeys Identified Mail (DKIM) is the usual authentication protocol, 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 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— or other databases created specifically for this purpose. There is a tendency to mandate the publication of exact abuse POCs.

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.One is Abusehelper

See also

* Abuse Reporting Format
* Feedback loop (email)

References

{{DEFAULTSORT:Spam Reporting
Email
Anti-spam