Spam is a big problem around the web, and even more so when it comes to wikis. Given the nature of a wiki and it's "anyone can edit and contribute" stance, fighting spam is a big deal.
Obviously you don't want to impact the ability of legitimate users of your wiki to contribute. But you also don't want spammers or other nefarious types to completely ruin your community's collaborative effort.
It is with this in mind that all anti-spam features of Aneuch have been carefully considered, not only for the impact they will have on your users, but the effectiveness they will have against combating spam.
Without further adieu, here is an overview of Aneuch's anti-spam capabilities, listed in order of their potential to impact legitimate users (from least amount of risk to greatest).
Aneuch adds the rel="nofollow" tag to all external links. This is to combat one of the main reasons why spammers push tons of links onto wiki sites - to increase their pagerank by having tons of incoming links. While this usually won't stop the spammers from trying, it certainly is effective at stopping what they are trying to accomplish. This should also have no effect on regular users.
On every page where a form is displayed that accepts input (i.e. the page editor, and the bottom of discussion pages), Aneuch will also present a hidden (to the human user) form which also accepts input. The difference is, anything submitted through this form is automatically flagged as spam. The reasoning for this is since a human user can't (under normal circumstances) even see the form, then they wouldn't be filling it out.
This form is displayed first before the legitimate edit form, and as such, most spam bots will see it first, and not even bother with the real form.
This method is moderately effective at combating most forms of automated spam, and should have absolutely no effect on any legitimate user (as they will never see the form anyways).
Captchas are pretty ubiquitous around the internet at this point. You'll know it when you see it, and undoubtedly, you've seen it many, many times. A captcha is an image that has (usually) difficult to read text in it, and then there is a form that asks you to type what you see.
But there are some drawbacks to captchas. Firstly, they have been broken by automated bots. And secondly, it could have a major impact on your users if they are impaired, or have diminished vision. Truth be told, there could be any number of scenarios whereby your users and contributers just can't make out the captcha, and are thus effectively blocked from participating in and contributing to your community. Heck, even I myself have had problems with captchas in the past. I once got a captcha that included Chinese text in it. Imagine my frustration upon encountering this!
Enter TextCha's. I got the idea for TextCha's from the MoinMoin wiki engine, which all but eliminated the spam problem facing MoinMoin powered websites once implemented.
Basically, it's a question/answer type of deal. Similar to captchas, however it's more logic-based rather than visual comprehension. For example, a site administrator could use as a question something very specific about the site that only its regular users would have knowledge of. An example of a poor question, however, would be a simplistic math problem (like "What is 2 + 2?")
A TextCha should:
Also, you should not share your questions with other sites / copy questions from other sites (or spammers might try to adapt to this).
Finally, Aneuch implements a banned content feature. Using rules that an administrator loads into the back-end, Aneuch will check the content being submitted for a page update. If one of the rules is triggered, the edit will be rejected as spam.
This has the potential for the most impact against your legitimate users. If an administrator inadvertently specifies a rule incorrectly, it's possible that the rule could get triggered in instances where it was never meant to be. If this happens, your legitimate contributors may be discouraged from participating further, and your community would experience a decline in overall engagement.
This option should be used carefully by an administrator who is comfortable using regular expressions (or pre-load our global BannedContentFile).
It should be noted that if a user is logged in to a site as an admin, then all spam checks will be bypassed. This is by design, as admins should effectively have free reign to do as they please. However, it certainly does leave an attack vector open. If a malicious user gains access to an admin password, then it's game over.