What is a SPAM registration
I think there is no need to explain what SPAM is, and I’ll just quote Wikipedia here:
unsolicited or undesired electronic messages
But what is a SPAM registration to your Magento 2 store?
By default, all Magento 2 stores are vulnerable to unwanted, automated registrations.
You might see a lot of registrations with data that doesn’t make much sense as a customer’s first or last names.
Those customer email addresses might belong to a domain zone from which you don’t have any purchasing customers.
For example, your store sells goods in USA, but many users are registering from @<some>.ru domain zone.
In short, a SPAM registration is an unwanted, often automated registration to your website.
But for the most part, it is unwanted to the owner of the email address that is being registered, because it sends an actual SPAM message to it.
But how?
Simply put, some bots will do the following:
- Put a lengthy SPAM message in the first and last name registration fields
- Fill out an email of a recipient in the corresponding field
Once they submit the registration, your server sends SPAM on their behalf.
The email will have some HTML templating of your website, but much of the content will be the SPAM payload for advertising / delivering a message from the bots.
Smart, eh?
The problem with SPAM registrations
A SPAM registration to your Magento store is problematic for a couple of reasons.
One, it pollutes your database data with irrelevant customer data.
The other, it actually causes your server to send out SPAM emails and you risk being banned by being blacklisted from sending emails.
Which is crucial to running an online business. Once you are blacklisted by external mail servers, you can no longer send genuine transactional emails to your customers.
How this whole issue is possible, is simply because Magento 2 allows 100 characters for either first or last name fields.
Delete existing SPAM registrations
As a first step, you may want to delete the existing SPAM registrations from your store.
For “SPAM users” which are registred from an irrelevant domain zone, e.g. .ru, you can run the following SQL queries against Magento database:
DELETE FROM customer_entity WHERE email LIKE '%.ru' AND created_at >= DATE_ADD(CURDATE(), INTERVAL -3 DAY);
DELETE FROM customer_grid_flat WHERE email LIKE '%.ru' AND created_at >= DATE_ADD(CURDATE(), INTERVAL -3 DAY);
Solving the problem at its core
A logical solution to fight the SPAM registrations is simply reducing the size of the first and the last name fields.
Think about it, what are the chances of either of the fields being 100 characters?
As an example, you may refer to the following full name:
El Tahir El Fadil El Siddig Abderrahman Mohammed Ahmed Abdel Karim El Mahdi
This is 75 characters long, and this is for both first and last names.
For a definite guideline on how much you want to reduce the length of those fields, it is best to follow up with your regional government recommendations.
For example, the UK Government Data Standards Catalogue details the UK standards for these things.
It suggests 35 characters for each of Given Name and Family Name or 70 characters for a single field that holds the Full Name, and 255 characters for an email address.
The following SQL queries will follow these recommendations and alter the fields to be 35 characters instead of the default, 100:
LOCK TABLE customer_entity WRITE, customer_grid_flat WRITE;
UPDATE customer_entity SET firstname = SUBSTRING(firstname, 1, 35);
UPDATE customer_entity SET middlename = SUBSTRING(firstname, 1, 35);
UPDATE customer_entity SET lastname = SUBSTRING(firstname, 1, 35);
ALTER TABLE `customer_entity` CHANGE `firstname` `firstname` VARCHAR(35) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT 'First Name';
ALTER TABLE `customer_entity` CHANGE `middlename` `middlename` VARCHAR(35) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT 'Middle Name/Initial';
ALTER TABLE `customer_entity` CHANGE `lastname` `lastname` VARCHAR(35) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT 'Last Name';
UPDATE customer_grid_flat SET name = SUBSTRING(name, 1, 105);
ALTER TABLE `customer_grid_flat` CHANGE `name` `name` VARCHAR(105) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT '' COMMENT 'Name';
UNLOCK TABLES;
The name field in customer_grid_flat holds the complete full name. We are being safe here and put it as 105 while the default is 65,535 length! (TEXT type).
Now think if you really want to use a framework that has insane defaults like that… 🙂