Honestly, these bots are really smart. They post a “thanks for your post” reply first. There is absolutely nothing suspicious about it, even their email address is similar to their user name. Only googling the email gives results on spam list, nothing else really.
They wait for you to approve the post. Only then they later activate their spam posting bits.
That’s been my impression too. It’s borne out in a variant of the technique described in the OP that we’ve seen. In this case the spammer “replies” to a comment and uses the Discourse quote feature to copy some of the other person’s text into their message. Then they insert their link into the copied block, thus making it look like the other user did it. Not sure if this is supposed to spoof the system into thinking the link is from someone of a higher T level or what. Kinda stupid, really, but definitely seems like something that had to be done manually, not by a bot. In particular, they don’t just drop the URL into the quoted text either; they highlight some text and use the link tool, adding a further layer of disguise. We’ve seen a few of these over the last couple of months.
The first step is to tighten up your allowed editing interval in post edit time limit from the default to something like one day. Unless your users regularly need to edit posts from weeks ago, you can close that in your site settings in about 15 seconds.
I’m changing the setting tonight, but I’m hoping that there is another way, since that would probably annoy some users. People tend to be more cautious about speaking freely if they know they they can’t go back and edit things later. (I don’t post as often in forums that lock the editing and am generally less comfortable.)
Ideally, I like unlimited editing windows, and every edit bumps the topic.
Why? Coming back “weeks later” to edit something is highly anomalous. And you can make things wiki if you want to signal that they are especially editable. There’s a nice middle ground of “a few days” you can test first.
I’m going to dial down the default on this setting a bit now actually, from 60 days to 30 days, since the use case for coming back so much later to edit is increasingly absurd to me.
For the moment, I’ve changed the trust levels required to add links and edit posts and made it a little harder to reach TL1.
The last spam post I saw wasn’t the usual obvious spammer — it was someone fully blending into the site, posting a thoughtful question like a regular user.
I’ll try to find the old spam by querying all edits done by TL0 users.
If one post were marked unread, wouldn’t it just add the blue dot next to the post and auto-scroll to it when a user visits that topic?
Sometimes people feel like they might have said something that they didn’t want to say, and they want to remove it. We’re living in a world where everything a person ever says can follow them around for the rest of their life, and it can lead to problems. People aren’t the same people for their whole lives, and they might not want their old self (or just an angry moment) to remain online forever. I tend to not speak as freely online in places where editing is limited.
I just remembered that there is a post webhook for “when there is a new reply, edit, deleted or recovered.” I didn’t check yet, but if I can get the action (“edited”) out of the header, then I can write a script to post those into an external dashboard for manual review. That would solve it on my site.
This form of spam only works because it’s invisible to moderators and the active community. That’s the only reason it’s happening. Perhaps all edits could bump the thread in the latest activity view — if the topic has already been read, then it’d be a direct link to that edited post. That would completely solve both issues (the spam and the worthless initial copy-paste content) in one fell swoop.
Even simpler (although not quite as effective), I know my fellow moderators and I would happily keep tabs on a special view that simply displayed posts that have been edited, sorted by their edit time (and perhaps optionally restricted by trust level).
@rimian@codinghorror Looking at the diff for this change, it looks like the old setting was reused for the TL0/1 users instead of the TL2+ users. This means that for sites that previously overrode the setting, that applies to TL0/1 users, while other users were forced back to the default setting. Was this intentional?