Difference between revisions of "Reducing spam in Moodle"

Jump to: navigation, search

Note: You are currently viewing documentation for Moodle 2.3. Up-to-date documentation for the latest stable version is available here: Reducing spam in Moodle.

Line 3: Line 3:
 
* Leave "Force users to login for profiles" enabled in ''Administration > Security > [[Site policies]]'' to keep anonymous visitors and search engines away from user profiles.
 
* Leave "Force users to login for profiles" enabled in ''Administration > Security > [[Site policies]]'' to keep anonymous visitors and search engines away from user profiles.
 
* Leave self registration disabled in ''Administration > Users > Authentication > [[Manage authentication]]'' common settings, or limit self registration to particular email domains with the allowed email domains setting, or only enable self registration for a short period of time to allow users to create accounts, and then later disable it.
 
* Leave self registration disabled in ''Administration > Users > Authentication > [[Manage authentication]]'' common settings, or limit self registration to particular email domains with the allowed email domains setting, or only enable self registration for a short period of time to allow users to create accounts, and then later disable it.
* If [[Email-based self-registration]] is used for self registration, add spam protection to the new account form by enabling reCAPTCHA (in Moodle 1.9.1 onwards). However, please realize that a) CAPTCHA will not foil manual attempts and there are documented CAPTCHA exploits now documented. In other words, CAPTCHA is NOT an ANSWER. It is only one more obstacle you might interpose between your site and neer-do-wells in the hope of limiting exploitation.
+
* If [[Email-based self-registration]] is used for self registration, add spam protection to the new account form by enabling reCAPTCHA (in Moodle 1.9.1 onwards). However, please realize that a) CAPTCHA will not foil manual attempts and there are documented CAPTCHA exploits now documented. In other words, CAPTCHA is NOT an ANSWER. It is only one more obstacle you might implement to discourage spammers.
 
* If Email-based self-registration is used for self registration, leave "Email change confirmation" enabled in ''Administration > Security > [[Site policies]]'' (in Moodle 1.8.6 or 1.9.2 onwards).
 
* If Email-based self-registration is used for self registration, leave "Email change confirmation" enabled in ''Administration > Security > [[Site policies]]'' (in Moodle 1.8.6 or 1.9.2 onwards).
 
* Consider the [[Risks|spam risks]] involved in allowing certain capabilities, such as [[Capabilities/mod/forum:replypost| replying to forum posts]], for visitor accounts.
 
* Consider the [[Risks|spam risks]] involved in allowing certain capabilities, such as [[Capabilities/mod/forum:replypost| replying to forum posts]], for visitor accounts.
 +
 +
 +
If your site was open and you have a spam problem then here are some things you can do to clean up the profiles.
 +
 +
* Upgrade the most recent version of Moodle to make sure you have the best tools at your disposal.  For example, you need 1.6.7, 1.7.5, 1.8.6, 1.9.2 or later to make sure deleted profiles are not available.
 +
* Browse your user list looking for patterns to detect users who need to be deleted.  For example, spammers might have chosen a country that none of your real users has.
 +
* Some tools should shortly be available to help you detect profiles containing common spam content.  Check back here for details.
  
 
[[Category:Security]]
 
[[Category:Security]]
  
 
[[eu:Spama_murriztu_Moodle-n]]
 
[[eu:Spama_murriztu_Moodle-n]]

Revision as of 05:19, 4 November 2008

Here are some suggestions for reducing the risk of spam in Moodle:

  • Leave "Force users to login for profiles" enabled in Administration > Security > Site policies to keep anonymous visitors and search engines away from user profiles.
  • Leave self registration disabled in Administration > Users > Authentication > Manage authentication common settings, or limit self registration to particular email domains with the allowed email domains setting, or only enable self registration for a short period of time to allow users to create accounts, and then later disable it.
  • If Email-based self-registration is used for self registration, add spam protection to the new account form by enabling reCAPTCHA (in Moodle 1.9.1 onwards). However, please realize that a) CAPTCHA will not foil manual attempts and there are documented CAPTCHA exploits now documented. In other words, CAPTCHA is NOT an ANSWER. It is only one more obstacle you might implement to discourage spammers.
  • If Email-based self-registration is used for self registration, leave "Email change confirmation" enabled in Administration > Security > Site policies (in Moodle 1.8.6 or 1.9.2 onwards).
  • Consider the spam risks involved in allowing certain capabilities, such as replying to forum posts, for visitor accounts.


If your site was open and you have a spam problem then here are some things you can do to clean up the profiles.

  • Upgrade the most recent version of Moodle to make sure you have the best tools at your disposal. For example, you need 1.6.7, 1.7.5, 1.8.6, 1.9.2 or later to make sure deleted profiles are not available.
  • Browse your user list looking for patterns to detect users who need to be deleted. For example, spammers might have chosen a country that none of your real users has.
  • Some tools should shortly be available to help you detect profiles containing common spam content. Check back here for details.