Abuse Reporting: Difference between revisions
(→Abuse Reporting Format (ARF): link to wikipedia) |
No edit summary |
||
| Line 25: | Line 25: | ||
==Adding a spam button to MUAs== | ==Adding a spam button to MUAs== | ||
Discussed in [http://www.ietf.org/mail-archive/web/asrg/current/msg15780.html | Discussed in <ref>List thread on MUA abuse button[http://www.ietf.org/mail-archive/web/asrg/current/msg15780.html]</ref>. 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. | 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. | ||
| Line 38: | Line 38: | ||
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. | 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. | ||
==References== | |||
<References /> | |||
Revision as of 14:45, 14 December 2009
| 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
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.
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. 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 [1]. 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.
