Providing Feedback
Once the filter has reached an educated guess about a message, it needs to know if it has made a mistake. In order to improve the quality of the filter’s results, it must be provided with feedback. The feedback we generally provide to a spam filter is that of error. When the filter erroneously classifies a message, we tell it and it corrects itself accordingly. If particular characteristics in a message were incorrectly learned as spam in the dataset, they would be relearned as nonspam once we informed the filter of its error. To avoid high end-user maintenance, most language classifiers assume that their decisions are correct unless they are told otherwise.Feedback loops vary depending on the type of software being deployed. For example, correcting a spam filter written inside an email client (such as Thunderbird or Mail.app) may simply involve clicking a button labeled “This is Spam.” Server-side filters, on the other hand, generally use a slightly more complicated feedback loop, such as having the user forward the spam to a virtual email address or making a correction from a web page. The feedback process doesn’t necessarily need to be visible to the end user, as there are many ways to customize a filter for ease of use.
Note | If you are implementing a statistical filter on your network, finding an easy way for your users to correct errors is essential. If you are running POP3 email, you’ll want to use a filter that allows the user to forward (or bounce) a spam into the system. If you are running IMAP or web-based mail, you have many other options. Since the original message is stored on the IMAP server, many spam filters provide an easy way to build a custom interface for training. Many how-tos are available for setting up a system using X-TMDA headers and/or drag-and-drop functionality. Find the easiest, most effortless way for your users to report spams to the system. |