One solution is to make all your support categories restricted (not public). This won't stop the spam per se, but will make it far less useful for SEO. Run the following SQL using bin/ljdb:
update supportcat set public_read='0'
If what you want or need is to stop the spam completely, not just hide it, the best way depends on whether it's coming by email or the web form.
If by email, make sure bin/worker/incoming-email isn't running, either by hand or because you listed it in workers.conf. (With the change in layout, I'm not sure whether it lives in etc or ext/local/etc, so you may need to check both locations.)
If through the web form (and not letting your server run except when you need it isn't an option), I think your only solution is setting up CAPTCHAs, but I'm not sure how to do that.
Thanks for the very quick reply, Pau. I have no idea what the first part of your answer meant ;) but I found the setting allowing me to turn on captcha for anon requests. I already had captcha enabled but missed these settings when I went through the config files.
For info setting up captchas requires getting keys from the two captcha websites (http://www.google.com/recaptcha and http://textcaptcha.com/), adding the keys to config-private.pl then switching 'support_submit_anon' to 1 in config.pl.
Edit: and I've just noticed textcaptcha is missing from config-local in the github repo file so here's the code for it if one needs it:
There's a bunch of configuration items that specify how a support category (gunk, comms, entries, etc.) will behave. One of them specifies whether requests in that category are visible to all users, or only to those on a per-category list. (That's what determines whether the category gets a * next to its name on the http://www.dreamwidth.org/support/submit dropdown.) The bit of SQL I gave you is to mark all categories (table supportcat) as not public. bin/ljdb is a utility that sets up things so that you can enter SQL for your database by hand without having to paste your database credential from your hack config files into the shell command line.
At the end of config-local.pl, uncomment the TEXTCAPTCHA demo api key. (It should read "api_key => 'demo'"). The demo key only gives a small subset of the possible questions, but it might be sufficient to prevent the spam.
At the end of config.pl, in the section labelled "Pages where we want to see captcha", make sure that "support_submit_anon" is set to 1.
In Defaults.pm, make sure that $DEFAULT_CAPTCHA_TYPE is set to "T".
If you find that the demo textcaptchas don't stop the spam, it's only a little bit of hassle to sign up for free for a real API key.
no subject
If by email, make sure bin/worker/incoming-email isn't running, either by hand or because you listed it in workers.conf. (With the change in layout, I'm not sure whether it lives in etc or ext/local/etc, so you may need to check both locations.)
If through the web form (and not letting your server run except when you need it isn't an option), I think your only solution is setting up CAPTCHAs, but I'm not sure how to do that.
no subject
For info setting up captchas requires getting keys from the two captcha websites (http://www.google.com/recaptcha and http://textcaptcha.com/), adding the keys to config-private.pl then switching 'support_submit_anon' to 1 in config.pl.
Edit: and I've just noticed textcaptcha is missing from config-local in the github repo file so here's the code for it if one needs it:
# setup textcaptcha
%TEXTCAPTCHA = (
api_key => $DW::PRIVATE::TEXTCAPTCHA{api_key},
);
no subject
no subject
If you find that the demo textcaptchas don't stop the spam, it's only a little bit of hassle to sign up for free for a real API key.
HTH, and happy Christmas!