MUA Plugins to Report Spam Messages from Debian MLs

Cord Beermann kindly introduced an API to report a mail message as spam (the returning message should be 'Ok' or so).

Since this is a url, it can be called from within the MUA of choice of any Debian users; I think the best solution is to present a button to report the current email as spam.

This page aims for a coordination/users requests collection/whatever to help people get involved in plugins writing/testing/adopting and so.

Status of plug-ins by MUA

Here below is a list of the current situation of MUA plugins:

MUA

Status

Author

Testers

People Interested

Where to get it

Notes

GMail

to be written

SandroTosi

Greesemonkey script? add a button when reading a message (something like "Report spam to Debian" along with classic "Report Spam" and also when seeing mails list in a label

mutt

Written

Kumar Appaiah, Hauke Rahm

Wiki: Mutt

Simple addition to muttrc.

icedove

written

LucaFalavigna

Mozdev.org

General-purpose bouncing extension, easily customizable

KMail

written

Frans Pop

Wiki: KMail

Describes two alternative methods using KMail's filter mechanism; for KMail 1.9.9 (KDE 3.5).

claws-mail

written

RicardoMones based on initial work by DavidPaleino

Debian package

Integrated upstream.

Gnus

written

RussAllbery

Ganneffs blog, and a different, no code implementation from Manoj

spam.el and spam-report.el in Gnus already had code --ms

sup-mail

to be written

because sup is made of pure awesome juice

evolution

to be written

?JossMouette

Should not be complicated in C or Vala with the EPlugin API

Feel free to add new MUAs, notes, step in as author etc.

Of course, your feedback is very welcome.

Specification

The plug-in should ideally have the following behaviour:

Is this not over detailed? Ideally, the plugin should integrate with the native MUA, and the usual way that that user agent deals with detecting, handling, and reporting spam. In the case of Gnus, it means that it should work with all the plugins the user has enabled to detect spam, creating the gnus-spam-mark. Then, after the user has finished reading the group, and exits it, the spam is reported, as normal, without any user interaction required for each individual spam, and the spam processing proceed as normal (including any training of the user's filters as configured). Certainly, no individual notifications should be sent, that would be maddening. The ideal behaviour will depend on the MUA, I would think.

Please don't nominate Articles because your Spam-Defence says it is. We want to have a human looking at it. (BTW: we are open for suggestions for better Filters --> Teams/ListMaster/FAQ#Thelistsarespam-laden.2CIwanttohelpyou)