Qual a importância dos registros PTR para os servidores de email?

Alguém conhece algum estudo feito para mostrar quanto email será rejeitado se não houver registro ptr para o nome do banner SMTP de um servidor de email?

As verificações reversas sempre são feitas quando ativadas ou, às vezes, são configuradas para que, se um programa de spam considere um email 'iffy', a verificação inversa seja feita?

Eu tentaria o máximo possível para que a pesquisa inversa do endereço IP do meu servidor de email resolvesse o nome que ele está usando nas conversas SMTP. Isso facilita a vida.

Não tenho nenhuma evidência estatística para fazer backup disso, mas foi minha experiência que, de tempos em tempos, as mensagens serão rejeitadas por alguns remetentes remotos por não terem uma pesquisa inversa que corresponda ao nome do host usado nas conversas SMTP. Em vez de precisar lidar com esse problema, é mais fácil começar com a configuração de pesquisa inversa. Nos últimos anos, eu apenas tratei de ter uma pesquisa direta / reversa consistente como um requisito, para que eu não tenha que lidar com o problema de não tê-la.

Se você não tiver a configuração, receberá um e-mail legítimo sinalizado. Cabe ao dispositivo de filtragem de spam a forma como eles fazem suas verificações e não há padrões claros definidos, por isso é uma falha ou não. Mas, na maioria dos casos, com uma pontuação de spam, eles enviarão seus e-mails quando você não tiver uma pesquisa direta e inversa correspondente. Esse ding, por si só, muitas vezes não recebe os bloqueios de e-mail (mas não promete), mas outra pequena preocupação no e-mail pode levá-lo ao topo.

Não costumávamos ter um registro PTR específico para o nosso servidor de correio e estávamos recebendo devoluções do craigslist.org e de alguns parceiros de negócios.
Você também precisa ter um registro A específico para a sua entrada MX. Nenhum * ou CNAMES permitido para alguns servidores de correio estritos.

Quando você diz "nome do banner", é um pouco enganador. O banner é o nome no lado do servidor, que é o lado que decide o que rejeitar. :) Eu acho que você quer dizer o nome que o lado remetente fornece no comando HELO / EHLO?

A maioria dos lugares faz verificações de sintaxe e rejeita HELO / EHLO obviamente ruim, porque há muito lixo quebrado por aí. Mas se você estiver executando um servidor de correio legítimo, deve apenas fornecer o nome do host público do seu próprio servidor de correio no HELO que você enviar. Há quem verifique. E como esse nome de host precisa ter DNS reverso funcionando, para que sua conexão TCP não seja imediatamente rejeitada por muitos MTAs, na verdade, você deve ter DNS reverso funcionando para o nome fornecido.

Portanto, não há dificuldades de configuração para obter o DNS funcionando para o nome de host HELO, além de separar o DNS reverso para acessibilidade geral de qualquer maneira.

Como Evan disse, sua melhor aposta é que a entrada do PTR seja resolvida de volta ao endereço IP do servidor.

No entanto, se por algum motivo isso não for possível, o PTR deve sugerir que você esteja usando um endereço IP alocado estaticamente, não uma linha DSL residencial (não comercial). Como parte de sua estratégia anti-spam, muitas organizações usam serviços de reputação (por exemplo, SORBS), que monitoram intervalos de endereços IP para atividade de botnet e mantêm listas negras de intervalos IP. No entanto, independentemente de atividades suspeitas ou não, eles geralmente incluem suas DULs (listas dinâmicas de usuários) em suas listas negras. Para criar esses DULs, eles usam registros PTR e expressões regulares, especificamente adaptados para os esquemas de nomeação de muitos ISPs grandes.

Por exemplo, um PTR como cable-66-103-40-69.clarenville.dyn.personainc.netprovavelmente seria automaticamente colocado na lista negra (corresponde a "dyn", portanto deve ser dinâmico). Existem alguns esforços de padronização na nomeação reversa de DNS na IETF, com sucesso misto:

http://tools.ietf.org/html/draft-msullivan-dnsop-generic-naming-schemes

http://tools.ietf.org/html/draft-ietf-dnsop-reverse-mapping-considerations

Um pouco fora do tópico, outra fonte de informação para listas negras / brancas são os registros WHOIS SWIP .