Como eu configuraria DNS reverso para 2 servidores de e-mail?

Question

Eu tenho uma interessante pergunta de DNS (bem interessante para mim pelo menos).

Acabei de instalar um servidor hmail em nosso escritório remoto para funcionar como um backup MX no caso de o servidor do Exchange ficar inativo.

Os 2 nomes de host são

mail.campbellsurvey.com mail2.campbellsurvey.com

aponta para o endereço 98.XXX.91.XXX mail2 aponta para o endereço 70.XXX.190.XXX

Como eu configuraria um registro PTR no final do ISP para refletir os dois nomes de host?

UPDATE

Na verdade, descobri pelo meu ISP que não posso ter um MX de backup no escritório onde eu queria. A razão é que nossa conexão no escritório tem um IP dinâmico e eles não irão atribuir um PTR ao endereço. Então essa questão foi útil em termos informativos, mas é um fracasso no sentido físico. Obrigado mesmo assim a todos.

O PTR precisa apontar EXACTAMENTE para mail.campbellsurvey.com ou pode apontar apenas para campbellsurvey.com?

porque agora qualquer coisa que passa pelo endereço estático principal em nosso pool (aquele usado para internet padrão) é identificada como mail.campbellsurvey.com. Minha única idéia para consertar isso foi mover o servidor de e-mail para o próximo endereço disponível e dar apenas o nome mail.campbellsurvey.com, mas eu queria ver se havia outro jeito.

Obrigado antecipadamente.

    

Answer 1

Configure o ponteiro para cada servidor para indicar o nome do servidor nesse endereço. Isso deve ser o mesmo que seu servidor de e-mail está usando em suas mensagens de banner e ao emitir comandos HELO. Os registros PTR não são significativos para as mensagens recebidas, pois o servidor remoto confia em seus registros MX do DNS.

Você desejará configurar dois registros MX um para cada servidor com prioridades diferentes. Os registros MX devem apontar para registros. Se os seus registros SPF especificarem MX na lista de remetentes permitidos, você não deverá ter problemas com os endereços do servidor.

Os registros de PTR que você precisa são:

98.103.91.146     mail.campbellsurvey.com 
70.XXX.190.XXX    mail2.campbellsurvey.com

Obtenha o ISP apropriado para configurar o registro PTR para o endereço que eles hospedam. Parece que você está perdendo um registro A para seu servidor mail2. Também pode haver alguns problemas com a verificação de endereços no segundo servidor.

EDIT: Então, se eu estava enviando pelo exemplo.com, mas o PTR do meu remetente foi resolvido para mta532.mail.google.com ou some.other.thing12.smtp.rackspace.com ou canner46.blah.brightmail.com, você teria confia na minha mensagem?

O rDSN não se aplica ao domínio no endereço do remetente. Se o endereço do seu envelope for [email protected], eu verificaria o registro SPF de example.com. Se example.com tivesse um registro SPF com uma política -all , recusaria seu e-mail. Caso contrário, seria aceito a menos que fosse marcado como Spam.

Se o seu servidor alegou ser mail.example.com, isso acionaria algumas ações do meu lado destinadas a determinar se o seu servidor é um Spambot que provavelmente seria. A falta de uma configuração rDNS válida também aumentaria seu esporo Spam. Eu tenho limites separados para HAM (improvável que não seja Spam) e SPAM. As mensagens que estão entre esses limites são quase inteiramente enviadas por e-mail de sistemas automatizados e Spam. Os emails de pessoa para pessoa que recebo quase sempre têm o rDNS correto para um ou ambos os endereços IP e nome usados no comando HELO.

Se os servidores DNS não responderem por nenhuma das pesquisas de DNS necessárias para verificar o status do rDNS do seu endereço IP, eu dou um erro. Recentemente, descobri que isso está bloqueando com sucesso um bom número de spambots. Até alguns meses atrás, essa regra raramente era acionada. Acredito que vários ISPs configuraram o rDNS para falhar em intervalos de endereços dinâmicos. Se você, eu aprecio o esforço deles em reduzir o spam.

    

Answer 2

Embora não haja nenhum dano nele, seus registros PTR não precisam corresponder exatamente (ou se assemelhar vagamente) ao seu nome de domínio de e-mail. Certamente, nos servidores que você recebe, não há razão para que eles correspondam a algo. Os remetentes se conectarão aos IPs identificados pelos seus registros MX em ordem. PTRs não entram nele.

Se ambos os servidores forem seus, configure-os com um PTR que identifique seus nomes de host; nada mais. Se esses hosts tiverem outras tarefas ou um deles for o seu gateway principal, o fato de serem chamados bert.campbellsurvey.com e ernie.campbellsurvey.com (ou qualquer outro) não será um problema. Se você estiver usando um host compartilhado ou algum outro provedor onde não é possível definir o PTR, isso também não é um problema.

Resumindo: os registros PTR não têm relação com a provisão de e-mail, então você não precisa se preocupar.

EDITAR

Para esclarecer o que estou dizendo e corrigir alguns equívocos.

Recebimento de e-mails:

Você especificou dois registros MX. Algo ao longo das linhas de:

mail1.campbellsurvey.com          IN    MX   10    1.2.3.4
mail2.campbellsurvey.com          IN    MX   20    1.2.3.5

Um remetente pesquisará esses IPs e tentará se conectar a eles na ordem de preferência para entregar sua mensagem.

Envio de e-mails:

Seu MTA fará o mesmo ao enviar e-mails para outros domínios. Quando ele se conecta a mail1.example.com , a primeira coisa que envia será uma variante de:

EHLO mta.campbellsurvey.com 

Ele será conectado a partir de um endereço IP que seja algum ponto de saída em sua rede. (Talvez: gateway.campbellsurvey.com ). O IP deste gateway terá um registro PTR correspondente.

8.7.6.5.in-addr.arpa. 86341 IN    PTR    gateway.campbellsurvey.com

Se você controlar esses IPs, a maioria dos ISPs permitirá que você defina o registro PTR para corresponder ao nome principal do seu domínio.

Com isso em mente, aplica-se o seguinte:

• Acho que todos concordam que os PTRs dos seus MXs não afetam sua capacidade de receber e-mails.

• Ao enviar, o domínio de segundo nível ( campbellsurvey.com ) especificado na saudação EHLO deve corresponder ao seu domínio de e-mail. Essa é uma medida anti-spam razoável.

• É uma boa prática geral definir os registros PTR de qualquer endereço IP que você controla para o nome do host principal da máquina em que esse IP reside.

• Os registros SPF (se você os publica) devem especificar o registro PTR e / ou o endereço IP de todos os seus servidores de envio. Isso permite que os servidores rejeitem mensagens que pretendem formar seu domínio a partir de qualquer item que não esteja nessa lista.

  • Se um servidor de email de recepção encontrar um registro SPF publicado para o seu domínio e o IP de envio ou seu PTR não corresponder ao que você especificou como servidor de email legítimo, ele provavelmente rejeitará sua mensagem. É para isso que o SPF é.

• Se o servidor de recebimento procurar o registro PTR do seu IP de envio e rejeitar porque ele não corresponde ao seu domínio de e-mail, será quebrado . Esta medida irá rejeitar o correio legítimo.

  • Se ele rejeitar porque o PTR não corresponde exatamente a , será muito . Esta medida rejeitará lotes de correio legítimo
  • Se esse era um método válido para bloquear spam, cada host de e-mail compartilhado (Google, Rackspace, escolheria) teria que ter um endereço IP separado e PTR personalizado para cada domínio eles hospedam . Isso seria bobo.

@ Solignis: Desculpe roubar sua pergunta original, que era apenas sobre seus registros MX, mas achei que isso precisava ser esclarecido.

    

Answer 3

Não sei exatamente o que a SmallClanger quer dizer com "provisão de email" na declaração "Os registros PTR não têm relação com a provisão de correio", mas é certamente verdade que os registros PTR não devem afetar a capacidade dos servidores de receber emails.

Outro MTA que está tentando enviar para você não se importa com seus registros PTR.

É quando os seus servidores estão enviando mensagens que você deseja que correspondam. Então, você precisa de registros SPF que especifiquem seus servidores de e-mail.