geek-out on squirrelmail and spam_buttons
Here is some gratuitous geek-outage mainly just so that I'm putting it down somewhere.
There is a plugin for SquirrelMail called Spam Buttons that I've had some interest in for a while. Spam Buttons allows you to put "Spam" and "Not Spam" buttons into your squirrelmail instance so that users can report spam to the sysadmin and more usefully to a spam filter that needs input. The problem that I have with it is that it only supports two methods. One is to report spam via an email address so that an admin can collect reported spam, I assume. The other is to report spam via a command. This is great for customization by site but it simply runs the configured command with the message on its input. At first glance this seems sufficient but here's the work flow that I would like:
1. User notices one or more spam messages in their inbox
2. User selects those messages
3. User clicks the "Spam" button
4. Behind the scenes:
* The message is removed from a bogofilter ham database, added to a bogofilter spam database, and sent to a site-wide report folder or email address.
* The message is deleted or...
* The message is marked as read and moved to a user-configurable folder
Doing this would either require the plugin to do the message manipulation or for the plugin to provide sufficient information to the reporting command so that the command could connect to the mailbox and perform the appropriate operations. This assumes an IMAP inbox, but that's what I use so it would be sufficient (for now, anyway).
A similar flow to the above would need to be used for auto-flagged messages that the user wants to mark as "Not Spam." These would be removed from the spam database, added to the ham database, and moved to the inbox.
Some of this functionality is in the todo list of the author of Spam Buttons however the one and only release, version 1.0, has been out since March 9, 2005 and I don't see a new version coming out any time soon. Such is the fate of opensource projects, unfortunately. I think the above thoughts help in solidifying a solution in my head, however. Looking at the plugin code I don't particularly want to do major modifications to make this work but passing the message ID to a program might allow me to modify the IMAP messages well enough to make a usable solution.
There is a plugin for SquirrelMail called Spam Buttons that I've had some interest in for a while. Spam Buttons allows you to put "Spam" and "Not Spam" buttons into your squirrelmail instance so that users can report spam to the sysadmin and more usefully to a spam filter that needs input. The problem that I have with it is that it only supports two methods. One is to report spam via an email address so that an admin can collect reported spam, I assume. The other is to report spam via a command. This is great for customization by site but it simply runs the configured command with the message on its input. At first glance this seems sufficient but here's the work flow that I would like:
1. User notices one or more spam messages in their inbox
2. User selects those messages
3. User clicks the "Spam" button
4. Behind the scenes:
* The message is removed from a bogofilter ham database, added to a bogofilter spam database, and sent to a site-wide report folder or email address.
* The message is deleted or...
* The message is marked as read and moved to a user-configurable folder
Doing this would either require the plugin to do the message manipulation or for the plugin to provide sufficient information to the reporting command so that the command could connect to the mailbox and perform the appropriate operations. This assumes an IMAP inbox, but that's what I use so it would be sufficient (for now, anyway).
A similar flow to the above would need to be used for auto-flagged messages that the user wants to mark as "Not Spam." These would be removed from the spam database, added to the ham database, and moved to the inbox.
Some of this functionality is in the todo list of the author of Spam Buttons however the one and only release, version 1.0, has been out since March 9, 2005 and I don't see a new version coming out any time soon. Such is the fate of opensource projects, unfortunately. I think the above thoughts help in solidifying a solution in my head, however. Looking at the plugin code I don't particularly want to do major modifications to make this work but passing the message ID to a program might allow me to modify the IMAP messages well enough to make a usable solution.