And my mail server is going crazy with messages like this:
Your message could not be delivered for more than 4 hour(s).
It will be retried until it is 5 day(s) old.
For further assistance, please send mail to postmaster.
If you do so, please include this problem report. You can
delete your own text from the attached returned message.
The mail system
<9298417059@tmomail.net>: delivery temporarily suspended: host
tmo-west.mx.a.cloudfilter.net[35.85.199.61] refused to talk to me: 421
tmo-ibgw-6004a.ext.cloudfilter.net cmsmtp too many sessions from
78.46.129.127 AUP#CNCT
Now I saw a new release that addresses blocking domains:
I was about to write in to support as I just noticed this occurring on a colleague’s Ghost(Pro) site as well, running on 5.106.2. You seem to be getting sign-ups from other SMS gateways than what I’ve seen.
@ajfriesen , @Stromfeldt I got these too, the day before yesterday. Same Bell and T-Mobile gateway email addresses. They seemed to be coming from a python aiohttp user agent — a UA I’ve gotten spam signups from before — and IP addresses in the US and Bangladesh.
Email delivered to them, but they created memberships without signing up for the newsletter (or unsubscribed immediately after signing up).
@Stromfeldt Ah, right. Well, I’m sure they’re more competent at this stuff that I am. It’s been quite a pain dealing with it for my self-hosted Ghost install(s).
Technically, you could probably point your DNS to a Nginx reverse proxy that points to your Ghost(Pro) subdomain, or some similar set-up, but that kind of defeats the point of having someone else deal with this kind of nuisance.
I’m am glad to see that Ghost is adding more spam protection into core. Technically this stuff is probably better handled at a lower level, but I would be delighted if there was a way for integrations to receive a webhook when a new member is created, before the magic link is sent, that includes user agent, IP, email, etc, and have an option to approve/deny the signup request based on that information.
Or perhaps the work that was done in the pull request you linked could be extended to include IP, user agent, etc. But if it gets too fancy, Ghost is kind of re-inventing the firewall, which probably isn’t good ROI.
There has indeed been an increase in spam signups across multiple Ghost sites originating from email domains like tmomail.net and txt.bell.ca.
These domains serve as email-to-SMS/MMS gateways, converting emails into SMS or MMS messages delivered to phone numbers.
To address this, we’ve introduced a configurable blocklist for email domains in Ghost. This blocklist is already active on all Ghost (Pro) sites, and our logs show it has successfully blocked thousands of spam signups since. We’re actively monitoring the situation and will continue to fine-tune the blocklist as needed.
Self-hosters can apply the same blocklist to their Ghost sites, by adding a list of blocked email domains to their config, under spam.blocked_email_domains. For example:
Great to see this @Sag! In the long run, is there any plan to have an option to block based on user-agent / IP / route combinations?
My concern is that these are all legitimate email addresses for getting newsletters by SMS, which real users might try sign up with, even though at this point all the signups from them seem to be spam.
It appears to me that someone has a list of stolen/bought email addresses (or in this case, phone numbers) that they are trying to validate for free using a Python script; most of the addresses might be real even if the signups aren’t.
I want to ban all domain email, only Gmail and yahoo or hotmail can sign up.
Cannot take a lot of time to update block list. The hacker always expand the black list, we cannot chase it unless ghost update it automatically in core.
Not sure if the default list contains @txt.att.net but it should as one appeared 7 hours ago
The other notable thing about these - I’ve only had a small number so far - is that they all use a non-existent signup info page /Membership/. Some appear to subscribe to the newsletter.
The default list only includes what @Sag mentioned here:
As a quick win, you can add the domain in the new configuration option:
I’ll need to evaluate what the best way to go is for this. There might be legitimate reasons for someone to allow these domains, so I don’t want to block too many per default.
