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 |
|
|
|
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 |
|
|
Wiki: Mutt |
Simple addition to muttrc. |
|
icedove |
written |
|
|
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 |
|
|
Integrated upstream. |
|
Gnus |
written |
|
|
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:
- The user realises a message they are currently reading is spam.
- The user selects some simple command (ideally, a single key-press).
- The program tests the current message to determine whether it's appropriate to report to the Debian spam reporting API:
test the header contains a List-Id field with a value matching the regex <[^ \t]+\.lists\.debian\.org>
- If not, end (or perhaps some other action, such as continue testing to determine if some other spam-reporting action is appropriate)
The program calls the API accordingly
- The program gives visual feedback of the action (for example changing the button message to "Done!" or similar).
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)