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
Difficulties and solutions for the first hop are as follows:
TBD
