Qual a importância dos registros PTR para Servidores de E-mail?

Question

Alguém sabe de 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 de modo que, se um programa de spam considerar um email "duvidoso", a verificação inversa é feita?

    

Answer 1

Eu tentaria o máximo possível fazer com que a pesquisa inversa do endereço IP do servidor de e-mail resolvesse o nome que ele está usando nas conversas SMTP. Isso torna a vida mais fácil.

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

    

Answer 2

Se você não tiver essa configuração, receberá um email legítimo marcado. Cabe ao dispositivo de filtragem de spam como eles fazem suas verificações e não há nenhum padrão claro definido, por isso é imprevisível. Mas na maioria dos casos com uma pontuação de spam, eles vão enviar seus e-mails quando você não tiver uma pesquisa direta e inversa correspondente. Isso por si só, muitas vezes não vai ter os blocos de e-mail (mas sem promessas), mas alguma outra preocupação leve no e-mail pode levá-lo ao longo do topo.

    

Answer 3

Nós não costumávamos ter um registro PTR específico para nosso servidor de e-mail e estávamos recebendo rejeições do craigslist.org e de alguns dos nossos parceiros comerciais.
Você também precisa ter um registro A específico para sua entrada MX. Não * ou CNAMES permitidos para alguns servidores de e-mail restritos.

    

Answer 4

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 de envio dá no comando HELO / EHLO?

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

Portanto, não há dificuldades de configuração para se trabalhar o DNS para o nome do host HELO além da classificação do DNS reverso para acessibilidade geral de qualquer maneira.

    

Answer 5

Como Evan disse, sua melhor opção é fazer com que sua entrada PTR seja resolvida de volta para o endereço IP do seu servidor.

No entanto, se por algum motivo isso não for possível, o PTR deve sugerir que você está 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 atividades de botnets e mantêm listas negras de intervalos de IP. No entanto, independentemente de atividade suspeita ou não, eles geralmente incluem suas listas de usuários dinâmicos (DULs) em sua lista negra. Para criar esses DULs, eles usam registros PTR e expressões regulares, especificamente adaptados para os esquemas de nomenclatura de muitos ISPs grandes.

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

link

link

Ligeiramente fora do tópico, outra fonte de informações para black / whitelisting são registros de WHOIS SWIP .