| | 15 | |
| | 16 | == How good is the filtering? == |
| | 17 | |
| | 18 | The spam filter will never be perfect. You need to check submissions to Trac and improve training or settings of the filter when it becomes necessary. But a fine trained setup will help you to run a site even if it is actively spammed (i.e. thousands of spam attempts a week/day). Even large sites with completely anonymous edits are possible. |
| | 19 | |
| | 20 | But from time to time spam attacks nevertheless will succeed and handwork is required. Try removing successful spam as fast as possible. The longer it stays in the pages the harder your work will get (some spammers seem to monitor successful attempts and retry more intensive). |
| | 21 | |
| | 22 | Spam should be removed completely (also in page history). Trac has options to delete tickets as well as wiki page versions. If done early enough this does not produce gaps in page history. Spam can also be in uploaded files. Delete them! |
| | 23 | |
| | 24 | Some spam bots edit a page twice, so the last change is harmless and the previous one added the spam. Be aware of such tactics. Sometimes spam is done by humans - this type is usually successful, but humans are easily discouraged by fast deletion. |
| | 25 | |
| | 26 | The bayes filter (when properly trained) usually has the best detection rates and can be adapted pretty fast to new attacks by training the successful spam attempts. Akismet and !TypePad are a good second line of defense (they also use adaptive algorithms). Training also helps the external services when a new type of attack begins. The other services are good to catch the spammers which have rather dumb methods (most of them). |
| | 27 | |
| | 28 | Sometimes its hard for the human admins to see if a submission is spam or not. Please understand that for plain software it may be impossible! |
