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.

The Feedback Loop (FBL)

Huge mailbox providers may provide a means for ESPs to get abuse reports about messages that had been sent by themselves. This tool is being 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.

While it is felt that proper use of abuse report may result in reliable reputation records, how abuse reports should be routed is still a debatable question. Rough consensus indicates that users should send reports to their mailbox providers. 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.

Adding a spam button to MUAs

Discussed in this thread. 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.