Talk:Spam blacklist/Archives/2015-08

Add topic
Active discussions

Proposed additions

  This section is for completed requests that a website be blacklisted

geet.me



URL shortener. MER-C (talk) 11:43, 7 August 2015 (UTC)

  Added --Herby talk thyme 12:40, 7 August 2015 (UTC)

transfers-in-europe.com









Spambot:

Checking reports and other stuff before deciding on adittion. —MarcoAurelio 13:18, 10 August 2015 (UTC)

Add new spammed domain and page. —MarcoAurelio 13:28, 10 August 2015 (UTC)
  Added —[[User:MarcoAurelio|Marc

1-online-generic.com



Spambot, and never ever going to be acceptable.  — billinghurst sDrewth 10:28, 14 August 2015 (UTC)

  Added  — billinghurst sDrewth 10:29, 14 August 2015 (UTC)

Proposed removals

  This section is for archiving proposals that a website be unlisted.

effd39.org



No idea why this website is blacklisted and I am new to this process but the link in question is the official website for the en:East Fishkill Fire District.--Zackmann08 (talk) 21:30, 16 June 2015 (UTC)

This is caught by a complex regex, I'll work this one out.   Approved. --Dirk Beetstra T C (en: U, T) 03:32, 17 June 2015 (UTC)

aviatorsale.com



Wanted to use a PDF on this site to reference the number of cycles in de:Entführung des Flugzeugs „Landshut“. To my understanding, the site has been blacklisted because six years ago somebody was spamming pictures from that site which most likely won't happen again anytime soon. --Studmult (talk) 17:49, 16 August 2015 (UTC)

  Declined 'a PDF' - if it is only one page then that is something that needs to be resolved using local whitelisting. Dirk Beetstra T C (en: U, T) 03:29, 26 August 2015 (UTC)

dot.tk



Registry for the .tk TLD. Linked to on its Wikipedia page. Undoubtedly, the nature of the .tk TLD causes it to be used primarily for nefarious purposes, but the TLD's registry should probably not be included in this list. 198.200.98.26 09:42, 25 August 2015 (UTC)

  Removed in a fashion. I have tightened to domain.dot.tk.  — billinghurst sDrewth 14:11, 25 August 2015 (UTC)


Troubleshooting and problems

  This section is for archiving Troubleshooting and problems.

SBHandler broken

SBHandler seems to be broken - both Glaisher and I had problems that it stops after the closing of the thread on this page, but before the actual blacklisting. Do we have someone knowledgeable who can look into why this does not work? --Dirk Beetstra T C (en: U, T) 04:08, 30 April 2014 (UTC)

User:Erwin - pinging you as the developer. --Dirk Beetstra T C (en: U, T) 04:16, 30 April 2014 (UTC)

FYI when you created this section with the name "SBHandler", you prevented SBHandler from being loaded at all (see MediaWiki:Gadget-SBHandler.js "Guard against double inclusions"). Of course, changing the heading won't fix the original issue you mentioned. But at least it will load now. PiRSquared17 (talk) 15:30, 18 June 2014 (UTC)
Another issue is that there's a bogus "undefined" edit summary when editing the SBL log. The customization of the script via our monobooks looks also broken. Thanks. — M 10:57, 06 December 2014 (UTC)

error block



www.jxlalk.com/888/d17/2013-11-06/1349.html 祝融八姓的新研究

I do not find jxlalk.com in our global blacklist.  — billinghurst sDrewth 12:45, 7 January 2015 (UTC)
Test the link, it's matched by xlalk.com (without j). VT offers "clean". –Be..anyone (talk) 08:18, 15 January 2015 (UTC)
The rule is 'xlal[0-9a-z-]*\.com' .. that is going to be a very difficult one to whitelist, as I don't know what the original intent was to block (which may very well have included 'jxlala.com', so excluding only the 'j' is not the way forward). I would suggest that you get '\bjxlalk\.com\b' added to your local whitelist. --Dirk Beetstra T C (en: U, T) 08:38, 15 January 2015 (UTC)
  Closed Please seek local whitelisting for the domain in question.  — billinghurst sDrewth 11:26, 16 January 2015 (UTC)

Bit of reference:



This was a rule that was removed after the 'blanket' xlal[0-9a-z-]*\.com was imposed. None of the additions are logged, but the '*' in the xlal-rule suggests that the string occured in multiple links with multiple characters after the xlal. --Dirk Beetstra T C (en: U, T) 04:31, 20 January 2015 (UTC)



Another one, multiple domain spamming using open proxies back in the days. The problem with these wide rules is that it is difficult to see what should be covered and what we can 'let through'. Xlalu.com is defined as a malicious site by my internet filter. --Dirk Beetstra T C (en: U, T) 05:33, 20 January 2015 (UTC)

  • jxlalk.com shows no sign of being connected. The original spam was in a short period over 8 years ago, and was apparently not cross-wiki. This was before en.wiki had a spam blacklist, so all blacklisting was done here. This should not be on the spam blacklist. In 2008, the admin who added it attempted to remove all his listings, and that was reverted. Maybe it's time to clean this one up. If nothing else the original regex could be eliminated and the specific sites added, so that jxlalk.com is not caught. But I simply removing it is easiest and harmless. --Abd (talk) 01:35, 21 January 2015 (UTC)
    • xlalu is defined as a malicious site by my internet filter, and I am still not sure if it is only xlale and xlalu, it may have also been xlalk and xlulabd that have been spammed. I AGF on the admin who added the rules that there was a reason for its broadness. You may be very right that the current owner of the site may have nothing to do with the spam, it may also be that the past abuser did not have anything to do with the site, but was abusing the site to make some point here on Wikipedia. It is not always a site-owner that is the spammer, and for the more sophisticated spammers, it is likely not the site-owner that spams.
    • I know that jxlalk.com does not show any sign of being connected, what I do see is just ONE wiki where ONE link is needed, and here a regex where exluding jxlalk.com specifically is giving a too difficult rule. And excluding specific domains from a rule is exactly why Wikis have a whitelist. --Dirk Beetstra T C (en: U, T) 05:53, 21 January 2015 (UTC)


... --Dirk Beetstra T C (en: U, T) 05:58, 21 January 2015 (UTC)

This is a can of worms, I find now also dozens of 'domains' spammed by dozens of SPAs (open proxies?) - both deleted and existing diffs on many different pages. This shows that the IPs were active globally (this edit is clearly of the same type of the spamming edits on en.wikipedia, though here no links were included). My advice stays: whitelist it locally, or show me exactly what was abused and we might consider a narrowing-down, excluding some collateral damage (as I said earlier, xlulu.com gives me a 'malicious site'-warning, I don't think that wholesale removal is a good idea). --Dirk Beetstra T C (en: U, T) 06:13, 21 January 2015 (UTC)

Thanks, Beetstra. xlala.com would fit a reasonable pattern used by the spammers. It's a "domain for sale." Dropped twice. However, xlalu.com is dead, and was dropped four times (nobody owns the domain, so your browser is relying on something old, that probably was not the original spammed domain owner. After all, it's been over eight years). xlale.com is not an active site, and is unlikely to be the original owner either. It was dropped four times as well.
The wikibooks link cited shows 61.64.115.253 as editing Wikibooks once, no spam. Global contributions show 5 edits with no visible relation to the xlale, xlalu, and xlala spammers. No spam, except one link [1] adding ひきこもり. How is this edit "of the same type of spamming edits on en.wikipedia"? We only have seen Contributions/71.207.33.167. The IP on enwiki added "Cool site!" followed by a series of links that could be highly deceptive, i.e., imitating real insurance company pages. Obviously, you may have seen more than that, but the Wikibooks IP added "Hi, you have very good site! Thank you!" This IP shows zero sign of being a spammer. The single link added is not blacklisted.
Yes, if there were a substantial reason to continue the blacklisting, then the whitelisting solution would make some sense. However, whitelisting is quite impractical for most users. I've researched problem blacklistings, and saw what happened with users. Very few will request a whitelisting, they just give up. And for some of those who do, the request sits for months. Many admins are clueless about the whole process, not to mention users.
Beetstra, I think you have never understood this. You see one request from one wiki. For every one request, there are likely dozens or more users frustrated who just give up. Ordinary users do not come to meta for delisting requests, especially if English is not their language. --Abd (talk) 21:11, 21 January 2015 (UTC)
The diff I gave uses the same language, same edit summary as the spammers, that editor is the cross-wiki spammer, the same person. The diff you gave on ja.wikipedia is not the spammer, it is a physically different person. --Dirk Beetstra T C (en: U, T) 03:22, 22 January 2015 (UTC)
"I've researched problem blacklistings, and saw what happened with users. Very few will request a whitelisting, they just give up." .. HOW do you know that a user gives up in stead of requesting whitelisting/deblacklisting. If you know it is a 'problem blacklisting' (as you call it), someone must have .. gone through the point of mentioning that it was a problem (e.g. ask for de-listing/whitelisting), otherwise you do not know what the intention was of the editor who ran into the blacklisting, you don't even know whether users ran into the rule. 'For every one request, there are likely dowzens or more users frustrated who just give up'. Yet, ZERO evidence that even one user ran into the rule, or, if users ran into the rule, that they were not actually spammers trying to add the link. --Dirk Beetstra T C (en: U, T) 05:22, 22 January 2015 (UTC)
We're done again, you found it necessary to make it personal again (as usual defense in these threads), ánd make yet more sweeping statements without evidence. If someone else has something substantial to add we can discuss further. --Dirk Beetstra T C (en: U, T) 03:22, 22 January 2015 (UTC)
  Removed, per provided evidence of no 'spammy hits'. --Dirk Beetstra T C (en: U, T) 07:06, 22 February 2015 (UTC)

palace.com



For reference: m:Talk:Spam_blacklist/Archive/Ukrainian_paper-writing_spam. That rule may indeed be too broad, maybe the two requests below should go on meta for an exclusion onto the rule. --Dirk Beetstra T C 17:04, 26 April 2015 (UTC)

www.lausanne-palace.com



For the article Lausanne Palace, I would like to use the official website www.lausanne-palace.com which is blocked because it contains "palace.com". Can you please allow this page? Johndrew Andson (talk) 18:11, 15 April 2015 (UTC).

www.host-palace.com



For the article List of Internet exchange points, I would like to use the official website www.host-palace.com which is blocked because it contains "palace.com". Can you please allow this page? --Never stop exploring (talk) 01:53, 26 April 2015 (UTC)

Discussion regarding palace.com

Above copied from en:MediaWiki talk:Spam-whitelist#palace.com. Suggest to 'whitelist' these through exclusion of the two prefixes 'lausanne-' and 'host-' onto \bpalace\.com\b. Posting here to get reports for analysis. --Dirk Beetstra T C (en: U, T) 17:13, 26 April 2015 (UTC)

I think that we would do well to either just remove the term or make it so that it is the whole term, ie. look to better blacklisting if required. It looks to be a pretty crude attempt to manage a dictionary word that could be prepended with many terms.  — billinghurst sDrewth 03:28, 30 April 2015 (UTC)

"4gk.com"'s regexp to be clarified





Hi. Please clarify \b4gk\.com\b to something which won't be triggered by "4gk.com.ua". Similar to this case. Thanks. --Base (talk) 12:49, 17 May 2015 (UTC)

Any progress? Come on guys it's just edit with example given and you are already doing it for over 2 weeks. --Base (talk) 16:00, 3 June 2015 (UTC)
  Done Negative lookahead added to the regex.  — billinghurst sDrewth 13:11, 18 June 2015 (UTC)

Discussion

  This section is for archiving Discussions.

COIBot Report Saving update

After another scheme update in the api, the bot was starting to throw a double error in saving, invalidating/blanking reports and not being able to fill the XWiki table. Upon finding the mistakingly closed reports, I noticed that that also happened back in 2010. I have therefore reverted a good handful of XWiki reports to the pre-error state (effectively reopening them) and have the bot reparse them (most will automatically close). In repairing the problem I did also note another 'error' - the bot would close reports for redirect sites if autoclose criteria were met, while some of those should simply be blacklisted anyway (real redirect sites), or LiWa3 should be told on-IRC to ignore the redirect detection for these domains ('link nr add ..' for the 'official domains' which nonetheless are redirected like 'facebook.de' to 'facebook.com') - in other words, they need always human interaction). I think I have solved these problems now.

There is now a category Category:Problematic XWiki reports, where the {{LinkStatus}} is 'unset'. For the reports in there, I look at the history and revert to the last 'open' state (having the bot close it; reverting reinstates some old data like users who added the link, that the bot will retain but which otherwise will be lost, and it adds blacklist rules and advertising IDs for the old reports), or if there is just one revid, I manually consider to open or immediately close it.

Please consider to have COIBot clear out its XWiki backlog, it will probably autoclose most of the ~95 open records (though there is no real harm in closing them manually). --Dirk Beetstra T C (en: U, T) 19:44, 21 April 2015 (UTC)

The bot is doing its job correctly now I think, so feel free to close the reports, especially the ones where COIBot is the last editor (it does leave more open now than usual). --Dirk Beetstra T C (en: U, T) 06:28, 24 April 2015 (UTC)
Return to "Spam blacklist/Archives/2015-08" page.