Um registro PTR prova alguma coisa sobre o domínio de email do remetente?

Question

Meu servidor de email de saída tem problemas para alcançar alguns destinatários. Isso aconteceu depois que alteramos ISP para nosso endereço IP dedicado. Eu acho que pode ser devido a registros PTR , mas não tenho certeza.

Meu endereço IP atribuído é x.y.z.112/29 . Quando eu faço um nslookup em x.y.z.114 ( WAN - encaminhando o endereço IP público), dá 114.x-y-z.myisp.com . Estou certo em dizer que há, de fato, um registro PTR definido para o meu endereço IP, apenas que ele não corresponde ao meu MX mail.mycompany.com . (x.y.z.115)? **

Eu também aprendi que a medida em que os servidores de e-mail verificam os registros PTR varia. Alguns apenas verificam se existe uma pesquisa reversa de DNS (rDNS) hostname , enquanto alguns procuram garantir que o MX e o nome do host rDNS corresponde. Então, o que devo fazer? Devo ainda dizer ao meu provedor para definir registros PTR para mail.mycompany.com ?

Agora, meu registro PTR é resolvido como 114.x-y-z.myisp.com , cujo A resolve o mesmo endereço IP do PTR registro. Então, o que isso prova sobre o endereço de e-mail do remetente?

    

Answer 1

Para responder à sua nova pergunta primeiro: não, os PTRs não informam nada sobre o domínio do remetente. Veja abaixo a explicação.

Agora, voltemos à sua pergunta original:

Recebendo servidores de e-mail, verifique nenhum, um, muitos ou todos os itens a seguir:

1. O nome HELO é igual ao nome do host (registro A)?
2. O PTR do IP é igual ao registro A do nome do host (nome do host == (PTR) == > IP == (A) == > hostname)?
3. A parte IP do registro SPF é fornecida?
4. O domínio do remetente tem pelo menos um registro MX? Que não precisa corresponder ao IP / hostname.

O recebimento de servidores de e-mail que verificam se o servidor de envio também é o servidor MX está mal configurado e deve ser eliminado da Internet.

Edit: O PTR não prova absolutamente nada sobre o domínio de email. Nunca é para provar isso. Existem milhares de domínios hospedados no Google, Amazon, AOL e outros. Mas nenhum deles corresponde ao nome do host ou ao PTR do Google, Amazon, AOL e outros. Todos eles têm os nomes de servidores dos provedores. E não há nada de mal nisso.

O PTR apenas prova a identidade do servidor, mas não a identidade dos domínios hospedados. Ponto.

2a edição: Um bom exemplo para um ambiente de trabalho seria

• HELO = mail.example.com
• hostname = mail.example.com
• Um registro de mail.example.com = 172.20.25.25
• PTR de 172.20.25.25 = mail.example.com
• Domínios hospedados neste servidor / system = example.com, * .example.com, * .example.net, * .example.org, mycompany.invalid e muitos mais.
• Registros SPF de domínios hospedados (opcionalmente) = v = spf1 a: mail.example.com -all
• O registro MX de domínios hospedados pode ser qualquer coisa. Por exemplo. mx1.example.com, mx2.example.com, mailfilter.anti-spam-corp.invalid, mail.example.com, postini.google.invalid, ...

Answer 2

Você tem um registro PTR genérico agora, mas ainda faz sentido modificá-lo para o nome do seu servidor.

Por quê?

Você está correto em ter um registro PTR atribuído, e muitos sistemas de email hoje rejeitam o email de fontes sem registros PTR reversos. Uma condição que você perdeu é que um bom número de hosts de email / filtros de spam tendem a rejeitar o tráfego de servidores de envio cujos registros PTR reversos são "muito genéricos". Isso inclui hosts em que o PTR reverso é do in-addr.arpa... format ou contém um endereço IP no nome. O seu é o último caso em que 114.x-y-z.myisp.com é apenas um marcador de posição definido pelo seu ISP. Você não precisa ter o seu reverso coincidir com o nome da empresa (embora você também pode fazê-lo se você puder). Só precisa de ser um nome de domínio totalmente qualificado (FQDN) .

De Diretrizes do Postmaster da AOL :

O DNS reverso é uma maneira de associar um endereço IP com seu nome de host. O identificador DNS reverso está contido na parte PTR do arquivo de zona IP. O arquivo de zona IP contém todas as maneiras diferentes pelas quais seu IP e nome de domínio podem ser associados; cada associação atende a uma necessidade diferente.

• AOL requer que todos os Agentes de Transferência de Correio tenham estabelecido DNS reverso, independentemente de corresponder ao domínio.
• O DNS reverso deve estar na forma de um nome de domínio totalmente qualificado. DNS inverso contendo in-addr.arpa não é aceitável, pois estes são meros marcadores para um registro PTR válido.
• O DNS reverso que consiste em endereços IP também não é aceitável, pois eles não estabelecem corretamente o relacionamento entre um endereço IP e seu domínio associado.
• O DNS reverso que pode ser semelhante ao espaço IP dinâmico (contendo pool, dhcp, dyn etc.) pode ser tratado como suspeito e, portanto, deve ser alterado para refletir um nome de domínio totalmente qualificado com o DNS reverso padrão do MTA. [Exemplo: mail.aol.com] *

Answer 3

Isso prova que você é quem você diz que é.

Aqui está o cenário. Digamos que estou tentando enviar um spam fingindo ser o Gmail. Eu não sou Gmail, eu sou apenas um pouco de vida baixa com um VPS, com o controle do meu próprio DNS.

Eu posso definir o PTR de qualquer IP que possuo para mail.google.com . Mas ao fazer uma A procurar mail.google.com não mostrará meu endereço IP, ele mostrará os IPs do Google. A incompatibilidade significa que você está mentindo.

Atualização: algum histórico e esclarecimento.

Você precisa saber que nada disso tem garantia de funcionar.

O e-mail foi inventado em 1961. Pouco depois, estimou-se que o mundo inteiro só precisaria de cinco computadores.

A popularidade do e-mail explodiu no início dos anos 80 com a introdução da pilha TCP / IP no UNIX. Naquela época, todos os hosts da Internet eram o governo dos EUA, uma universidade ou uma corporação muito grande. Naquela época todos eram muito amigos. O primeiro worm não foi criado até 1988. Ninguém pensava que alguém faria algo malicioso porque era uma comunidade extremamente pequena (pelos padrões de hoje) e quase todo mundo conhecia todo mundo.

Houve muitos protocolos criados sobre os quais, hoje, estamos envergonhados. Entre eles estão ftp, telnet, rsh, rlogin, nfs e smtp. O SMTP, como era comum com vários protocolos, foi criado com sem segurança alguma . Supunha-se que tudo o que você disse era a verdade, porque alguém mentiria?

Um dia, alguns idiotas empreendedores decidiram enviar um e-mail para um grupo de pessoas que não o queriam e spam nasceu. Desde então, temos lutado contra uma batalha perdida contra o spam.

O problema de spam é tão grave que qualquer e todas táticas que reduzirão o spam até mesmo pela menor fração de um percentual significa que a carga em nossos servidores de e-mail cairá significativamente . Fiz uma verificação no meu servidor de e-mail uma vez e as mensagens que ele estava processando tinham mais de 99% de spam.

Os administradores estão desesperados por qualquer coisa que ajudará a nivelar o menor grau . Qualquer coisa que alguém tenha ouvido ajudou "aquela vez" se torna uma prática comum no combate ao spam. Não que qualquer tática seja particularmente eficaz. Mas hoje em dia colocamos tantas restrições quanto possível na transmissão de e-mail, na esperança de ganhar algum espaço na luta contra o spam.

Não há panacéia de spam. Mas mesmo uma verificação muito básica como essa pode significar a diferença em milhões de mensagens a menos enviadas.

    

Answer 4

Você tem tudo certo. O registro PTR do endereço IP do seu servidor de e-mail não corresponde ao nome do host que o seu servidor de e-mail se identifica. Seria bom que o ISP altere o registro PTR para corresponder ao FQDN de saída do seu servidor de e-mail.

A parte que não está certa é onde os servidores de recepção verificam se os registros PTR e MX correspondem, porque isso é uma coisa estúpida. O registro MX designa onde o email vai para, não de onde vem FROM. Um registro SPF designa de onde vem o email. Qualquer servidor de e-mail que verifique se o registro PTR corresponde ao registro MX antes de aceitar o e-mail desse servidor está fazendo errado.

    

Answer 5

Embora não seja obrigatório, é recomendável configurar um registro PTR para o servidor de envio de email que corresponda ao DNS de encaminhamento do servidor de envio de email. Isso dá alguma indicação de que o servidor de envio é um host adequado de seu domínio (você pode apontar um registro DNS em qualquer host) e que o administrador não é descuidado ou sem noção.

Se você começou a ter problemas depois de alterar os IPs, convém garantir que o IP do seu servidor de e-mail não esteja em nenhuma RBL (lista negra em tempo real). Para verificar as listas mais comuns, você pode inserir o IP do servidor de e-mail no RBL checker no anti-vírus. abuse.org.

    

Answer 6

Todas essas pessoas estão certas. Se você gosta ou entende por que, se você quiser enviar e-mails de forma confiável, você garantirá que o nome do helo / A / PTR seja o mesmo em toda a linha. Não importa de qual domínio você está enviando, mas o host que envia o e-mail deve ter sua casa DNS em ordem, por assim dizer.

Nome HELO = o nome do servidor de e-mail se reporta a quando um servidor smtp remoto é saudado:

[spork@hc1:/tmp]$ telnet example.com 25
Trying 127.0.0.1...
Connected to example.com.
Escape character is '^]'.
220 example.com ESMTP Postfix <<<--- remote server
HELO someserver.jake.com <<<--- your server using it's HELO name  
250 example.com <<<--- remote server answering

Um registro = o nome DNS publicado do seu servidor de e-mail (não precisa corresponder ao domínio do qual você está enviando e-mail). exemplo: jake.com = 10.10.10.2

Registro PTR = deve corresponder ao registro A do servidor. exemplo: 10.10.10.2 = jake.com

Você percorrerá um longo caminho em direção a uma melhor capacidade de entrega, garantindo que essas três coisas correspondam.

Lembre-se de que boa parte da filtragem de spam depende da avaliação geral do shadiness do host que está se conectando a uma mxer. Não seguir as melhores práticas comuns é uma grande bandeira vermelha. Se um administrador de sistema não puder obter o DNS correto, o que mais poderia estar errado com o servidor prestes a enviar seu e-mail? Há massa crítica suficiente nestes dias que realmente não vale a pena lutar contra o que é agora um BCP, mesmo que isso não faça sentido para você.

Quanto a rejeitar e-mails de IPs com PTRs "genéricos", isso também não é incomum, mesmo que seu trio de configurações relacionadas ao DNS mencionado acima esteja de acordo. Novamente, o host remoto está olhando para esse DNS genérico e assumindo que genérico significa "usuário doméstico aleatório", o que, por sua vez, significa que você está mais propenso a conversar com um robô do que com um servidor de correio real.

    

Answer 7

Eu sei que esta é uma conversa antiga, eu só queria adicionar meus dois centavos de valor ... A maioria das verificações reversas têm isso em comum: elas verificam algo do domínio DNS de encaminhamento e do domínio inverso (por exemplo, a sub-rede IP). Esses dois domínios geralmente não são controlados pela mesma entidade, especialmente quando se está tentando se disfarçar como um domínio diferente. Portanto, é difícil para uma entidade fazer com que os registros em ambos os domínios correspondam entre si, uma vez que eles normalmente possuem apenas o domínio reverso ou o encaminhamento, mas não os dois. Considerando que, em situações legítimas, você pode pedir ao outro administrador de domínio para fazer a alteração apropriada do lado deles também.