Abuse Reporting

Anti-spam technique: Abuse Reporting
Date of first use:	Before 2003
Effectiveness:	?
Popularity:	Medium
Difficulty of implementation:	?
Where implemented:	External
Harm:	?

Abuse Reporting is a cooperative technique whereby spam is suppressed at the origin by the administrators of an MSA. Mail domains' reputation can be preserved by limiting outgoing spam, thus operators are motivated to suppress spamming. Probably the earliest anti-spam defense, this technique relies on end users to submit abuse reports timely and correctly. It is supported by huge mailbox providers, who feature a This is Spam (TiS) button on their web-based mail clients.

Abuse Reporting Format (ARF)

The format for transmitting abuse reports is going to be standardized. See abuse-feedback-report list.

See also the Wikipedia page.

The Feedback Loop (FBL) and other usage of abuse reports

Huge mailbox providers may provide a means for ESPs to get abuse reports issued for messages that had been sent by themselves. This tool can be used to automate opt-out. The sender should tag each message, setting an opaque token and possibly signing it, so as to be able to retrieve necessary submission details.

Another use of abuse reports is to tune an MX server's spam filter. For Bayesian filters this requires a spam/ham indicator. Some hosts automatically convert reports into unsubscribe requests when the reported message contained a List-Unsubscribe header field.

Hypothetical usage of an abuse report (green) submitted in response to a spam message (violet).

While it is felt that proper use of abuse reports may result in reliable reputation recording, how abuse reports should be routed is still a debatable question. Rough consensus indicates that users should send abuse reports to their mailbox providers. However, a third party can manage the Reporting Service instead of (or in addition to) the Last MX. For example, SpamCop offers such service. FBLs as operated, e.g., by ReturnPath, are not scalable and may be questionable from a privacy point of view. The Abusix approach provides for routing abuse reports hierarchically, through top level IP assignments. The image beside depicts possible use:

1. Tuning filters at the 1st MX, assuming it is on the recipient side. The 1st MX can be identified as responsible for receiving, e.g. by authentication results.
2. Let the spammer's MSA suppress further attempts; this step is useless and questionable if the MSA is directly operated by the spammer. The MSA can be identified as responsible for sending, e.g. by author signatures.
3. Arguably, connection providers should terminate contracts with blatantly spamming MSAs. The connection provider can be identified via RIR whois; Abusix's database provides abuse-box lookup by IP address.
4. Reputation trackers should verify whether the MSA actually blocks the spammer.

The Reputation tracker, a.k.a. vouching service, sometimes also referred to as The "Mythical" Global Reputation System, would better operations and extend the functionality that is currently obtained by submitting mail through a well-reputed mailbox provider, as it decouples IP addresses from senders' reputation.

Adding a spam button to MUAs

Difficulties stem from the fact that a user may have multiple mailbox providers, which rules out single-address configurations.

The possibility that reports are cascaded back to the spammer may be considered a potential hazard that exposes the reporters and allows list washing. However, it has been pointed out that spammers are not interested in feedback and don't bother. There is also concern that a button might cause a flood of unwanted messages, specially when multiple targets can be determined.

Message's header based approach

An MX server may embed an header field indicating the address where abuse reports may be sent. If the MX doesn't support such field, MUAs may use the field provided by the sender, if any. Otherwise, MX operators may override that by removing the field, or by replacing it with their own FBL reporting address instead.

Reusing existing field has also been proposed: the topmost Received, any Delivered-To, VBR-Info, or any trusted Authentication-Results. The latter one already requires users to confirm that they trust the relevant authserv-id, thereby clearing that hazard concern. Fields with multiple values allow for multiple targets, which may be needed for forwarded messages in case abuse reports are used to tune spam filters. In addition, using a DNS RR to store one or more addresses allows even more flexibility: verifying that the service is actually supported, using addresses other than abuse@, and directly sending copies to reputation providers seem valid demands that a DNS call can fulfill.

Client's protocol based approach

Setting up an IMAP folder for this purpose has the advantage of requiring no special software on clients. This is in facts the most common solution for servers that maintain per-user Bayesian data, although it may be difficult to interpret users' intent in a non-interactive environment, and notwithstanding possible confusion or conflict with junk folders maintained by the client. When the SUBMIT and IMAP servers coincide, sending the report can be optimized by using BURL or similar techniques.

POP clients have no folders, hence they'd need special machinery, such as a new command to upload an abuse report or to retrieve the address where it should be sent.

UI problems and interpretation of spam reports

Difficulties with manually submitted reports stem from the scarce reliability that characterizes users and their computing equipments. Users error rates have been reported to be around 5~10%. In addition, users tend to categorize mail incoherently as wanted/not-wanted rather than legitimate/abusive (never mind the ham/spam dichotomy, which is fuzzy by definition.) Accordingly, servers may resort to interpret users' intentions by extracting further info from reported messages, e.g., if the sender has sent multiple messages before and it has a List-Unsubscribe: header, it's probably an opt-out, not a spam complaint.

UI design includes issues such as the number of buttons that users can reach. That UI might be configurable, so as to suit users with different skills. It seems clear that some experimentation is needed in order to understand users behavior. However, besides a user's skill and the UI design, a mailbox provider's stance and any effects of the way it processes abuse reports will also play a role.

See also

Adding a junk button to MUAs