Por que a validação regular de email não é suficiente. Validando registros MX com exemplos em PHP e Ruby

Quantas vezes eles repetem para o mundo ... Há um longo e provavelmente interminável debate sobre qual regularidade está correta e é necessário verificar o campo de email do usuário.

Sim, você realmente precisa verificar com a temporada regular. Mas nossos produtos estão online. Então, por que não usar seu verdadeiro poder?

Além disso, geralmente há situações em que os usuários realmente se enganam ao inserir um endereço de email (inclusive em um domínio). Bem, ou, no campo de email, insira qualquer "Habrakadabra" possível, que voa facilmente através do regexp, mas não pode ser correio, porque mesmo esse domínio não existe na natureza :)

A propósito, com essa nuance, literalmente acabamos de voar: o resultado final é que, no site criado em um CMS bastante popular, por algum motivo, paramos de enviar notificações por email.

O motivo, como se viu, era o endereço do remetente de spam.

Havia várias razões:

1. O CMS é bastante popular e, portanto, há muitos spammers registrados nele. E o que é mais interessante - nas configurações que você pode (e muitas o fazem) - desativar a verificação de e-mail. Nesse caso, você pode (e a maioria dos bots faz) aqui para inserir qualquer lixo
2. Os textos das cartas não foram reescritos dos padrões.

Total: os spammers escalaram maciçamente para se registrar, jogaram e-mails à esquerda no script, onde tentamos enviar cartas. O filtro de spam viu que vários e-mails vinham do nosso e-mail, com textos que ele já havia visto muitas vezes de outros endereços de e-mail e, ao mesmo tempo, um número considerável deles caiu em endereços de e-mail inexistentes.

Em geral, o endereço para correspondência ficava periodicamente sob spam.

Portanto, a experiência, respectivamente, pode e deve ser argumentada que a verificação da disponibilidade de um domínio na Internet, bem como a presença de um serviço de correio (registros MX para um domínio) nele, é o que, em teoria, deve existir e funcionar nos sistemas de registro de usuários.

Na verdade, a essência da verificação é bastante simples: durante o registro, na fase de validação dos dados do usuário, dividimos o domínio do email e vemos o que existe nos MXs.

Isso é difícil? Na verdade não. Mas pode reduzir significativamente a carga nos serviços postais. E, a propósito, é muito menos provável que entre em listas de spam (afinal, enviar um grande número de cartas para endereços de correio inexistentes é um dos sinais de spam).

Em PHP, curiosamente, isso é bastante simples:

$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"; } 

Vou explicar o bastante "monstruoso" se. O fato é que na documentação da função getmxrr houve comentários com referências ao seu comportamento que não estavam totalmente corretas. E embora eu não os tenha encontrado no php7.1 - uma verificação extra não é extra :)

No ruby, isso é feito de maneira semelhante:

 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-.       false else true end 

Ao mesmo tempo, vou esclarecer que essa verificação do campo de email pode não apenas afetar seriamente a qualidade das informações no banco de dados do seu projeto (e reduzir o risco de spammers enviar notificações), mas também levar a uma diminuição nas cargas de trabalho. Afinal, enviar cartas de um script é um processo bastante lento na prática.