Continuing with phpc.social's trend of defederating instances that are abandonware (defined as no posts in their local timeline this year) other than spewing spam, we're defederating
My understanding of the current #spam issues is that it is people taking advantage of open registration instances. Essentially hijacking.. which is causing small-instance admins like me to domain-block those instances for sanity.
Question: Assuming the spammers will eventually be removed from the victim instances, is there a 'whitelist’ somewhere that #MastoAdmins#SelfHost community could consult so we can unblock domains that should no longer be a problem?
As part of the "spam sweep" we've been doing at phpc.social, we've limited and rejected media for mastodon-ero.xyz and meetbeauties.social. The instances are actively used, but between adult content and not cleaning up the current spam wave, something had to be done.
HugOps to other Mastodon instances whose mods have cleaned up the whole "being a vector for spam" thing. I see y'all, and appreciate the effort put toward having a clean feed going forward.
We have a semi-automated checker to tell spam vs. non-spam posts; DM me if you want to be added to the GitHub repo for it (not posting publicly as the "what is spam" signature is rather fragile)
phpc.social has defederated tech.retrotalk.live, as the instance hasn't had non-spam posts since 2022, so we expect that it will continue to be a vector of spam.
If you run a Mastodon server, especially if it's small and only lightly moderated, I would STRONGLY suggest enabling 'Approval required for sign up'. It means that your server is MUCH less likely to become the next source of spam in this wave we're seeing.
#fediblockclew.lol because Soapbox is for cucks who think that there are only two genders (bro that’s literally less than the number of human sexes there are)
phpc.social has defederated basstdn.jp, as the instance hasn't been touched in months, so we expect that it will continue to be a vector of spam, cool "bass-todon" theme notwithstanding :(
phpc.social has defederated with wulf.social as it's currently being used as a spam vector, hasn't had admin post activity in months, and hasn't interacted with our instance prior to spamming it.
We're erring on the side of keeping federation so instance admins whose only crime was allowing open signups don't get caught in the crossfire, but if an instance is abandonware other than spam, sorry :(
There has been too much spam coming into my timeline, causing a high load on my server. It was challenging to block as it was coming in through relays rather than directly mentioning me.
In the end, I applied a script that forcibly opens and inspects SSL communication content for filtering.
This has proven effective. I hope it helps someone.
It seems that currently the spam bots only target small instances with low moderation by manually creating multiple accounts, making email verification and captcha less efficient.
It's highly recommended to add this list to the list of banned email domains.
If you use misskey, then this option is available in Misskey 2024.2.0 or later
To all Fedi Admins Currently Being hit with a Spam Wave:
This kind of spam is now over! Unmute all the instances no longer on my list!
I've just released v4.0.0 of The UNmute List! I'd be very happy about a small donation because I have very little time and I cannot really justify working on this list with my current schedule :mycomputer:
There is a new type of spam, the same instances are affected as before. Those responsible in Japan are said to have been arrested.
Simply import this list and you'll mute the 47 worst spam instances currently known to me! I've worked on it for multiple weeks, sometimes ~9 hours at a time verifying all lists sent to me manually.
Limit first, defederate only in worst situations!
Consider re-federating with and un-silencing any of the mentioned instances once the spam is mitigated. The admins of some of these may have just been asleep when this all started.
Ban Spam Accounts via their E-Mail Domain
Block the following E-Mail Domain and whatever temp Mail provider it resolves to: chitthi.in
Just to be safe, block these ones too (same provider)
mailto.plus
fexpost.com
fexbox.org
mailbox.in.ua
any.pink
All our spam accounts came from these E-mails.
Since you probably have some of these accounts sleeping:
https://[your-instance.tld]/admin/accounts?email=%25%40chitthi.in there just select all and press “Ban”.
Find Remaining Spammers
I've seen instances that fixed the spam issue but began being hit later again. The spammers might use new E-Mails, so here is a way to find and block them anyway:
These spammers seem to be using the TOR Network as all of their IPs are TOR Exit Node IPs, hence an idea (with some collateral damage if executed) would be to ban all TOR exit node IPs for sign ups. I am personally against this idea as you'd also prevent users who simply wish to stay anonymous online (political refugees, leakers of important documents, etc.) from using your platform. For now, simply banning every user using a particular Spammer IP will not help and will merely ban users that try to stay anonymous! Not necessarily the spammers.
How To Block All Temp E-Mails in the Future
If you want to prevent this from ever happening again, you should block E-Mails from Temporary Mail providers all together:
In future updates on Mastodon, maybe Admins can simply click a button that says “Ban Temp E-Mail Providers” Automagically from the E-Mail Menu? There could be E-Mail categories that can be banned, such as temporary mails.
Why did this happen?
The real reason hundreds of us spent hours of our days during the spam on mitigating it is the following: