Spamcheck anti-spam service (FREE SELF)
Introduced in GitLab 14.8.
WARNING: Spamcheck is available to all tiers, but only on instances using GitLab Enterprise Edition (EE). For licensing reasons, it is not included in the GitLab Community Edition (CE) package. You can migrate from CE to EE.
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.
Spamcheck is only available for package-based installations:
/etc/gitlab/gitlab.rband enable Spamcheck:
spamcheck['enable'] = true
sudo gitlab-ctl reconfigure
Verify that the new services
spam-classifierare up and running:
sudo gitlab-ctl status
Configure GitLab to use Spamcheck
- On the top bar, select Main menu > Admin.
- On the left sidebar, select Settings > Reporting.
- Expand Spam and Anti-bot Protection.
- Update the Spam Check settings:
- Check the "Enable Spam Check via external API endpoint" checkbox.
- For URL of the external Spam Check endpoint use
- Leave Spam Check API key blank.
- Select Save changes.
In single-node instances, Spamcheck 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 cannot 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
grpc:// in the Admin Area settings.