LittleBITS: Email Delivery Problem and Blocking Spambot Accounts

Those who create and maintain online services seldom talk about just how hard it can be to keep everything working, but the reality is that websites and other Internet-based services require significant tending. We’ve had several incidents of late that you may have noticed.

TidBITS#1683 Email Issue Delivery Problem

Last week’s email issue of TidBITS#1683 suffered a delivery problem we haven’t been able to solve or reproduce. After sending to about 19,000 people, Sendy, the app that manages outgoing email messages based on addresses from our WordPress server, started receiving 403 or 503 errors when passing individual messages on to Amazon’s Simple Email Service (SES) for delivery. We could find nothing wrong at Amazon SES and nothing amiss with the remaining 5,500 addresses. Subsequent sends of individual articles to TidBITS members and of our Dutch and Japanese translations worked fine. After nearly a week, we had nothing more to try, so we canceled the remaining sends of TidBITS#1683 to prevent Sendy from filling the drive with error logs.

The upshot is that if you didn’t receive last week’s email issue, my apologies! You can read TidBITS#1683 on our website, along with all other back issues. I sincerely hope everything works better for TidBITS#1684 because nothing changed before the last issue, and we haven’t changed anything since. We plan to install an update to Sendy soon, but since we’ve never had a problem before, it’s hard to imagine it will fix whatever cosmic ray caused problems for last week’s issue.

Email Verification for New Accounts

A few months ago, we deployed email verification for new accounts. For years, we had been fighting a losing battle against spambots that created thousands of fake accounts in our WordPress system. I don’t know why they do this since these accounts have no significant capabilities. I suspect we were just among the random victims of roving spambots that detected a WordPress server.

Spambots can do this because WordPress, by default, lets potential users create accounts instantly. We had various forms of security in place—the Stop Spammers plug-in, non-standard URLs, reCAPTCHA, and more—but nothing stopped or even really slowed the spambots. And to be clear, it was terrible. At the peak, the spambots were creating hundreds of accounts daily. Even identifying the few legitimate accounts while deleting the fake ones was difficult.

Eventually, we installed the User Verification WordPress plug-in. It doesn’t prevent spambots from creating accounts, but new accounts are marked as Unverified until the user clicks a link in an email confirmation message. Although it’s conceivable that a spambot could subscribe a compromised email address and then click the link in the received confirmation message, most don’t. I hoped that, after we had marked all our existing users as Verified and become comfortable with User Verification, we could enable its option to automatically delete accounts that remained Unverified after some amount of time.

Alas, it was not to be. For reasons we never figured out, when I turned on that feature, it deleted 17 accounts marked as Verified and connected with actual people. I can’t trust it not to delete accounts again, so I’ve fallen back on deleting spambot accounts manually.

What I really want is a system that emails a token-secured link to someone who submits their email address in a subscription form but doesn’t create the account until the user manually clicks that link. That’s not something I’ve been able to find in the WordPress plug-in world, and our developer doesn’t have time to build such a system right now. Suggestions welcome.

Being able to see which accounts remained marked as Unverified simplified the process of deleting the spambot accounts a little, and while I was doing that, I noticed some commonality among the IP addresses associated with the spambot accounts. (Stop Spammers displays the source IP address in the WordPress user list.) When I looked them up, I discovered many were controlled by a Russian ISP called Biterika Group. Although Scamalytics currently considers Biterika Group a low fraud risk, at the time, it was definitely responsible for the spambots attacking my server. My efforts to block particular domains and Russia as a country using Stop Spammers had little effect, making me so frustrated and angry that I decided to go nuclear and block entire IP address ranges. That’s generally a bad idea because it can affect legitimate users and because the list is difficult to manage. But, Russia, so whatever.

(As an aside, the trick to blocking many of the 46,000 IP addresses controlled by Biterika was CIDR notation. CIDR is short for Classless Inter-Domain Routing and is an IP addressing scheme that allows a single IP address to designate many unique IP addresses with CIDR. A CIDR IP address looks like a regular IP address with a trailing slash, followed by a number called the IP network prefix. For instance, some of the Biterika IP addresses were around 109.248.204.0, and adding 109.248.204.0/23 to my Stop Spammers blocklist prevented spambots from that IP range from doing anything on my site. I use this CIDR to IPV4 calculator to determine the appropriate IP network prefix to use.)

Blocking all the Biterika IP addresses was ​​so successful that I started checking IP addresses on any spambot accounts and adding them to the blocklist if they weren’t from an English-, Dutch-, or Japanese-speaking country. I fully realize the implications of this, and if any TidBITS reader who has been blocked contacts me via email, I’ll remove the offending IP address range.

The combination of requiring users to click a link in a confirmation message and blocking spambot IP addresses has been highly effective. A few spambot accounts sneak through, but I can deal with a handful a week compared to hundreds per day.

From the user perspective, we’ve had some hiccups along the way, and I’m hugely appreciative of Lauri Reinhardt’s assistance in helping users and teasing out unexpected quirks and Eli Van Zoeren’s tech work in installing and configuring everything. It took us a while to configure the email verification options correctly, fix conflicts caused by multiple plug-ins providing CAPTCHA checking, eliminate broken Register buttons deep within the site, figure out the interaction between the TidBITS and TidBITS Talk sites (which share a login system), and work through various edge cases. Even now, we worry that there’s a bug in User Verification that causes some accounts to be marked as Unverified after a manual membership renewal, but we haven’t been able to track that down.

Existing users should be largely unaffected by these changes, but if you run into any problems using our sites, please let us know at [email protected]. We want everything to work!