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.
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
- On the left sidebar, at the bottom, select Admin Area.
- 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.
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
JWTauthentication for this and specifying a bearer token as the API key. Native authentication for Spamcheck is in the works.
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.