Why email validation is not enough. Checking MX records with examples in PHP and Ruby
How many times has the World been told ... There is a long-standing and probably endless argument about which regular registration is correct and the user’s email field should be checked.
Yes, it’s really necessary to check with regulars. But our products work on the web. So why not use her real power?
Besides, there are often situations when users really make mistakes when entering an email address (including in the domain). Or, in the email field are introduced every possible "Habrakadabru" that is easy to fly through the regexp, but can not be by mail, because even such a domain does not exist in nature :)
By the way, on this nuance here, we literally just podzaleteli: essence the fact that on the site, raised on one, quite popular CMS-ke for some reason, we stopped to go email-divert.
The reason, as it turned out, was getting the sender's address in spam.
There were several reasons:
Total: spammers en masse to register, threw the script left email-s, where we tried to send emails. The same spam filter saw that from our email there is a series of letters, with texts that he has already seen many times from other email addresses, and at the same time a considerable number of them fall into non-existent email addresses.
In general, the mailing address periodically fell under spam.
Therefore, the experience, respectively, can and should be argued that checking the availability of a domain on the Internet, as well as the presence of a mail service on it (MX records for a domain), is what the idea is to exist and work in user registration systems.
Actually, the essence of verification is quite simple: during registration, at the stage of validation of user data, we split the domain from the email, and see what is there on the MX.
Complicated? Not really. But it can significantly reduce the load on postal services. And, by the way, it is much less likely to get into spam lists (after all, sending a large number of letters to non-existent email addresses is one of the signs of spam).
On PHP, oddly enough, it's pretty simple to do this:
I will explain on quite "monstrous" if. The fact is that in the documentation for the function getmxrr there were comments with references to its not quite correct behavior. And although I couldn’t find them on php7.1 - an extra check is not superfluous :)
On ruby, this is done in a similar way:
At the same time, I’ll clarify that such checking of the email field can not only seriously affect the quality of information in the database of your project (and reduce the risk of notifications sent to spam), but also lead to a reduction in loads. After all, sending emails from a script is a rather slow process in practice.
Yes, it’s really necessary to check with regulars. But our products work on the web. So why not use her real power?
Besides, there are often situations when users really make mistakes when entering an email address (including in the domain). Or, in the email field are introduced every possible "Habrakadabru" that is easy to fly through the regexp, but can not be by mail, because even such a domain does not exist in nature :)
By the way, on this nuance here, we literally just podzaleteli: essence the fact that on the site, raised on one, quite popular CMS-ke for some reason, we stopped to go email-divert.
The reason, as it turned out, was getting the sender's address in spam.
There were several reasons:
- CMS is quite popular, and, therefore, there are a lot of users registering with bot spammers. And what's more interesting - in the settings you can (and many do, by the way, and do) - disable email checking. In this case, you can (and so most bots do) enter any trash.
- Texts of letters were not rewritten from standard ones.
Total: spammers en masse to register, threw the script left email-s, where we tried to send emails. The same spam filter saw that from our email there is a series of letters, with texts that he has already seen many times from other email addresses, and at the same time a considerable number of them fall into non-existent email addresses.
In general, the mailing address periodically fell under spam.
Therefore, the experience, respectively, can and should be argued that checking the availability of a domain on the Internet, as well as the presence of a mail service on it (MX records for a domain), is what the idea is to exist and work in user registration systems.
Actually, the essence of verification is quite simple: during registration, at the stage of validation of user data, we split the domain from the email, and see what is there on the MX.
Complicated? Not really. But it can significantly reduce the load on postal services. And, by the way, it is much less likely to get into spam lists (after all, sending a large number of letters to non-existent email addresses is one of the signs of spam).
On PHP, oddly enough, it's pretty simple to do this:
$email ="11@sdlkfjsdl.co.uk";
$domain = substr(strrchr($email, "@"), 1);
$res = getmxrr($domain, $mx_records, $mx_weight);
if (false == $res || 0 == count($mx_records) || (1 == count($mx_records) && ($mx_records[0] == null || $mx_records[0] == "0.0.0.0" ) ) ){
//Проверка не пройдена - нормальные mx-записи не обнаруженыecho"No MX for domain: $domain";
}else{
//Проверка пройдена, живая MX-запись на домене есть, и почта на нём работаетecho"It seems that we have qualify MX-records for domain: $domain";
}
I will explain on quite "monstrous" if. The fact is that in the documentation for the function getmxrr there were comments with references to its not quite correct behavior. And although I couldn’t find them on php7.1 - an extra check is not superfluous :)
On ruby, this is done in a similar way:
domain = invite.email.split('@').last.mb_chars.downcase.to_s.force_encoding("UTF-8")
#На случай, если домен русскоязычный. Точнее уже не совсем помню зачем преобразовывал в UTF-8, но видимо нечто вылетало
mail_servers = Resolv::DNS.open.getresources(domain, Resolv::DNS::Resource::IN::MX)
if mail_servers.empty?
#Нет MX-серверов. Нечего и пытаться сюда слать письмаfalseelsetrueendAt the same time, I’ll clarify that such checking of the email field can not only seriously affect the quality of information in the database of your project (and reduce the risk of notifications sent to spam), but also lead to a reduction in loads. After all, sending emails from a script is a rather slow process in practice.