Spamcheck anti-spam service (PREMIUM SELF)

Introduced in GitLab 14.8.

Spamcheck is an anti-spam engine developed by GitLab originally to combat rising amount of spam in GitLab.com, and later made public to be used in self-managed GitLab instances.

Enable Spamcheck

Spamcheck is only available for package-based installations:

1. Edit /etc/gitlab/gitlab.rb and enable Spamcheck:

   spamcheck['enable'] = true

2. Reconfigure GitLab:

   sudo gitlab-ctl reconfigure

3. Verify that the new services spamcheck and spam-classifier are up and running:

   sudo gitlab-ctl status

Configure GitLab to use Spamcheck

1. On the top bar, select Menu > Admin.
2. On the left sidebar, select Settings > Reporting.
3. Expand Spam and Anti-bot Protection.
4. Update the Spam Check settings:
   1. Check the "Enable Spam Check via external API endpoint" checkbox.
   2. For URL of the external Spam Check endpoint use grpc://localhost:8001.
   3. Leave Spam Check API key blank.
5. Select Save changes.

NOTE: In single-node instances, Spamcehck runs over localhost, and hence is running in an unauthenticated mode. If on multi-node instances where GitLab runs on one server and Spamcheck runs on another server listening over a public endpoint, it is recommended to enforce some sort of authentication using a reverse proxy in front of the Spamcheck service that can be used along with an API key. One example would be to use JWT authentication for this and specifying a bearer token as the API key. Native authentication for Spamcheck is in the works.

Running Spamcheck over TLS

Spamcheck service on its own can not communicate directly over TLS with GitLab. However, Spamcheck can be deployed behind a reverse proxy which performs TLS termination. In such a scenario, GitLab can be made to communicate with Spamcheck over TLS by specifying tls:// scheme for the external Spamcheck URL instead of grpc:// in the Admin settings.