Why spam a newsletter signup form?

Question

I run a newsletter for my small business. It has been running for over a decade. Last week, I found out that one or several spambots have been signing up to it for the last 2 years (to the tune of over 3,000 "subscribers", or 8.5% of new subscribers since it started.)

The disturbing thing is that they sign up with REAL emails. I checked a few email addresses and the majority show up in Google results, so I assume they just scrapped them off the Web (or bought them somewhere.) Half of the unsolicited subscribers used the complaint button from their email service provider (ESP), so they got unsubscribed successfully, but this is terrible for email reputation and deliverability.

In addition to the email, I ask for a first name. The spambots sign up with a 8 to 16 random characters as their first name. I've now added an extra invisible input as a honeypot and they fill it up too, with random characters.

Now what I don't understand is: what is the point of such spam? I just don't see how this makes economic sense – they won't get my email this way, nothing gets published... What is it the spammers are hoping to gain in this case?

I'm consider adding a textarea to see if the bots will then post more meaningful content. Is this a bad idea?

Answer 1

Your service is being used to facilitate list bombing attacks, when attackers wants to inconvenience their victims, perhaps to overwhelm them so they don't notice an email alert that happens in the middle of the storm of subscription confirmations. (You're also a victim, as your sender IP reputation takes a hit every time somebody reports your confirmations as spam.)

I assume you're already using confirmed opt-in subscriptions, so victims get at most a single email from you. If that's not the case, I'd say you're sending spam.

Your honeypot field is a pretty good way to weed out the attack, at least until the bad actors figure that out and evade it. Another approach is to use a captcha. I don't see value in an html <textarea>, hidden or visible, as the text input should suffice.

The most foolproof way, which is also the most cumbersome to a potential subscriber, would be to require an authorized email to request the subscription. "Authorized" means it passes DMARC (it passes SPF or DKIM with alignment). In this case, you don't actually care about whether there's a DMARC record or how it is configured (the policy and reporting mechanisms are more important for detecting a forgery while I'm proposing its use to detect legitimacy). Not all uses will have enough control of their email-sending infrastructure to do this, and even among those that do, this is not at all convenient.

Answer 2

I can think of a few reasons.

First of all, it is possible that someone is trying to ruin your IP reputation. So if "someone" subscribes to your newsletter, you should request verification of the request by sending a link with a unique token. Do not send the newsletter until the subscriber has confirmed their intention.

If you start sending your newsletter prior to securing approval, then the victims will complain.

Sending a confirmation link to someone who turns out not to have requested anything is inconvenience for sure, but at least the game stops here.

The "attack" may be distributed over many different IP addresses, but try to have some common sense defenses in place ie: do not allow multiple signups from a single IP address within a short time frame. Even though I hate this, you may have to implement a captcha to thwart spamming attempts.

You can also decide to review all signups manually, on a daily/weekly basis depending on your schedule. Keep the new subscribers in a queue and discard the records that are obviously not genuine, like made up surnames. Any database requires maintenance and quality control, so the best is to control data quality ahead. You have a data quality problem, so it's time for the human being to take over and monitor the machine.

On my websites, I have an admin panel from which I can quickly "unapprove" new subscribers, it's just a matter of ticking checkboxes. If you don't have such tools, then try to write at least a small SQL script to review your table and make the task less tedious.

But the real motive could be more basic than you think. Spambots do attack the contact forms on websites, in the hope that at least one person will get (and read) the spam.

So it's possible that the bot simply makes no difference between a contact form and a newsletter subscription form here, because it was not taught to discriminate, and no "preselection" of victim sites was done by the spammers. This could be the result of an "autodiscovery" process: the bot crawls the web, and indexes everything that looks remotely "spammable".

Since your form contains at least one field whose name or placeholder suggests that an E-mail address is expected as input, this could be enough for a bot to flag your site as a valid target and attack it - blindly.

Finally, there have been incidents in the past where contact forms were hijacked to spam a lot of arbitrary recipients through null byte injection. The same technique can also be used against file upload forms to bypass restrictions on file name or extension for example.

I believe this type of attack has become less common nowadays because of increased awareness, and some libraries like phpmailer have built-in protection against it, but it still possible to be vulnerable if using old code and not being aware of all the possible pitfalls and best practices.