Welkom bij Mechelen Mapt, Carlb! U kunt ook meewerken aan deze encyclopedie over Mechelen: wees niet beschroomd een fout te verbeteren of een artikel aan te maken. Neem ook even een kijkje bij de hulponderwerpen, indien u iets niet duidelijk is. Als u nog met vragen mocht zitten kunt u ons steeds een e-mail sturen. Nogmaals hartelijk dank voor de interesse!
User registration process[bewerken]
The Mechelen Mapt site has been suffering a good deal of automated spam lately. None of its three regular editors finds the time to cope with anything else here. The typical behaviour is the creation of a new user, which then takes one of three lines of action:
- Simply wait.
- Create a bogus user and/or user talk page with one or more linked urls.
- Create a new article with a bogus title, and several urls within the content.
As long as the modus operandi remains as is, it suffices to block the registration of a new user: Last month, there were merely 2 improper edits by an IP user.
Fortunately, the Php sources that I could find (from another wiki), show that the entire registration interface is an included pure Html sequence, and I expect this to be the case for us as well.
The Php (includes/templates/Usercreate.php ???) straightforwardly writes this into the page (the three required additions are shown in green colour):
Please do copy the literal Html text from this normally displayed talk page, not from its edit source.
In either the same or some other Php, there should also be:
but in case this can not be found immediately, it probably does not matter (registering by e-mail is not a problem and that button does not even appear in the more normal situations).
This has all been explained in Dutch on Henning's talk page, who gave his consent. I expect him to send you an email soon, in which he will also ask to upgrade the wiki to version 1.20 alpha. But please, do the above very simple modification on the old version first, so that for at least a couple of days we can verify whether my method actually helps against the spam plague. On an at the same time upgraded version, we could never be sure that any improvement would be caused by my thingy or by some other software difference that 'our' current spambots simply don't aim for.
— SomeHuman 2012-09-26 01:55-05:19 (UTC=CEST-2)
Minor spam question[bewerken]
Rarely upon attempting to block an IP by clicking 'blokkeren' (=' block') behind the user ID's reported IP, instead of the blocking form a message like "ProjectHoneyPot (127.44.28.5 - Suspicious & Comment Spammer) DroneBL counter.sample.txt is missing, I need this to create counter.txt unless you are going to create it yourself?" appears in the otherwise empty browser window. (For other readers: the aforementioned IP is not the one that needed blocking, which was 220.127.116.11).
Remarkable: a spambot 'user' had been working from 2 IPs, 18.104.22.168 and 22.214.171.124, which generate "ProjectHoneyPot (127.40.36.5 - Suspicious & Comment Spammer) DroneBL" etc and "ProjectHoneyPot (127.1.43.5 - Suspicious & Comment Spammer) DroneBL" etc respectively.
Another user's IP 126.96.36.199 showed "ProjectHoneyPot (127.15.26.5 - Suspicious & Comment Spammer) DroneBL" etc., and a double IP user had only one, 188.8.131.52, showing "ProjectHoneyPot (127.32.26.5 - Suspicious & Comment Spammer) DroneBL" etc.
The etc type of message also appeared three times for "Spamhaus (SBL)", most recently while failing to block 184.108.40.206 and 220.127.116.11.
Without any preceding name of the listing entity, the message has "DroneBL counter.sample.txt is missing, I need this to create counter.txt unless you are going to create it yourself?" for 18.104.22.168, for 22.214.171.124, and for 126.96.36.199. And once more, both known IPs 188.8.131.52 and 184.108.40.206 of a same user produce that identical message.
I know it's some kind of blacklist verification process in Php (Extension:Check Spambots/functions.php ???), though I wouldn't dare to guess how "to create it myself", that counter.txt. The error occurs seldomly enough (approx. 1%) to have me wondering what precisely may cause those few IPs to be so different from all others with identical histories on the wiki.
This type of error obviously prevents putting our own block on those IPs. Would it also prevent the assumed Php blacklist checking, leaving a warranted open access for those proven bad IPs (apart from Php blacklists checks in tandem and from our own range blocks)?
— SomeHuman 2012-09-28 22:45 - 2012-09-29 23:12 (UTC=CEST-2)