[ SmokeDetector | MS ] Bad ip for hostname in body, bad ns for domain in body, bad keyword in body, bad keyword in link text in body, bad keyword in title, +4 more (598): Tableau Training in Chennai by kiran on superuser.com
User seems to have legitimate contributions on SO, so suspended instead of destroying. cc @Makyen, I can't see if there's anything untoward on the SO account
@Makyen A normalized version, {{'18777638488', '8777638488'}}, of that pattern is already on the number blacklist. You can use !!/bisect-number 877-763-8488 to determine which entries on the number lists match that pattern, which would tell you: '877-763-8488' is not caught by a blacklist or watchlist number.
Yes, but it shouldn't matter. If it does matter, it's a bug. That the normalized version both with the 1 and without it are shown as present indicates it should be detected.
@Makyen A normalized version, {{'8777638488', '18777638488'}}, of that pattern is already on the number blacklist. You can use !!/bisect-number 877-763-8488 to determine which entries on the number lists match that pattern, which would tell you: Matched by 877-7638-488(?#IS NorAm) on line 971 of blacklisted_numbers.txt: 8777638488 found normalized
@SmokeDetector The user who uploaded the YouTube video and the author of the post linked both have the same name and profile picture as the user who posted the answer. Undisclosed affiliation.
@Makyen cc @tripleee So, this is as designed. What's stated in SD's response is confusing and the text would be better if changed.
The issue is that the existing entry didn't detect as a NANP number, so only the version with 1 is on the normalized list. That this was the case was correctly shown when the entry was added. The proposed entry does get recognized as a NANP number, so both with and without a "1" are checked (as they should be). This results in a collision in the "starts with 1" case. The text posted in chat should make that more clear and more clearly indicate what's happening.
As to the detection, or not, of the original entry, +1 877-7638-488 as a NANP number, my opinion is that is should be detected as NANP when starting with a "1". The unclear case is if the version without a starting "1" (i.e. "877-7638-488") should be detected as a NANP and automatically used.
Currently, SD is conservative in identifying NANP numbers, and particularly in automatically deciding that it is a NANP number.
At a minimum, both versions should be able to be assigned as a NANP with (?#IS NorAm), so the "loose" version of the regex to recognize NANP numbers should change. The logic should change a bit too in order for the version starting with "1" to be auto-considered a NANP number, unless explicitly called out as (?#NO NorAm).
@Jesse That pattern looks like it's already caught by Potentially bad keyword in body and Potentially bad keyword in answer Append -force to the command word(s) if you really want to add the pattern you provided.
@Makyen I will be AWOL for a few days but off the top of my head, should the logic be changed to normalize anything which starts with +1 into (?#IsNorAm) internally when reading the patterns?
feel free to assign to me if you'd like me to take a closer look next week
@tripleee np. I expect to make the changes, but may delay the changes to the text SD posts into chat (i.e. functional changes now, with the chat feedback later). I've already worked on changes to auto-make anything that starts with a "1" and which fits the NANP pattern as a NANP number (including those with a non-digit prior to that, so including "+1"), unless marked as (?#NO NorAm) along with reasonable loosening the definition of what might be NANP. I still need to go through the watch and blacklisted numbers to see if that results in any entries overlapping.
I've noticed that there are at least some entries which start with "1" or "+1" which can't be NANP numbers, because the rest of the number doesn't meet the requirements (usually that the central office code number can't start with [01], but there are other requirements too).
I'll need to see how many of those there are and look at at least some of them to see what the intent was when added. If they are just what the spammer had in their post, then the entry should be fine. The entry just won't detect a number that doesn't start with "1", so might not be doing what was intended, but that's not a change from what's currently happening.
@Makyen That pattern looks like it's already caught by Potentially bad keyword in body and Potentially bad keyword in answer Append -force to the command word(s) if you really want to add the pattern you provided.
@SmokeDetector Spam seed - on the user's profile, their website is set to mapleinvestor.com. On that website, there is a post called Best Tax Filing Experts in Canada: Your Guide to a Hassle-Free Tax Season, so I highly suspect a spam seed
Oops, forgot that the word Spam wasn't part of the comment and marked it tpu. Fixing it in a moment
