Meu pressentimento diz que "isso não é um problema e logicamente não pode ser realmente corrigido". Estou configurando uma conexão ISP de backup para uso com nosso servidor de e-mail de troca no local.
Isto é o que eu configurei:
198.51.100.30 -> primary ISP
203.0.113.40 -> backup ISP
O seguinte foi adicionado ao nosso DNS de domínio example.com:
mail.example.com. A 198.51.100.30
mail2.example.com. A 203.0.113.40
example.com. MX 10 mail.example.com.
example.com. MX 20 mail2.example.com.
PTR adicionado por ISPs relevantes:
198.51.100.30 mail.example.com
203.0.113.40 mail2.example.com
Agora, nosso servidor de email sempre funcionou com apenas mail.example.com
o banner, está tudo bem, o MXToolBox está feliz. No entanto, o que faço com o banner referente ao nosso MX de failover? Obviamente, o PTR de failover é mail2.example.com
e produzirá um "DNS reverso não corresponde ao banner SMTP" no MXToolBox.
Não me preocupo com isso ou não configurei algo corretamente?
EDIT: O certificado SSL SAN instalado no servidor de email possui mail.example.com
e mail2.example.com
.
Você só precisa se preocupar com o nome do banner quando mail2 for usado para enviar um e-mail de saída. E, nesse caso, ele ainda deve corresponder ao DNS reverso do IP que está usando. A única coisa que resta a verificar é se o nome apropriado é usado em qualquer certificado SSL (todos os 3 nomes precisam corresponder a cada servidor - nome do banner/helo, nome no certificado SSL e pesquisa reversa) e que o servidor de backup está listado em qualquer registro SPF, etc. Quanto a isso, meus registros SPF simplesmente listam "todos os MXs para este domínio".
Então sim, tanto quanto eu posso dizer com o que você postou, você deve estar pronto para ir.
Sobre as melhores práticas: tenha dois servidores MX
A melhor opção é ter dois servidores, ou seja, configurar outro Exchange (ou, alternativamente, um servidor SMTP baseado em código aberto, por exemplo, Postfix) como um servidor MX de backup/secundário. Na maioria dos casos, o próprio servidor pode causar mais tempo de inatividade do que a conectividade com a Internet. Como a incompatibilidade de banner é apenas um problema no correio de saída, esse servidor pode perfeitamente estar
mail2.example.com
em sua configuração atual.Um único servidor com duas conexões de Internet
Configuração para e-mail de saída
A segunda abordagem seria ter ambas as conexões configuradas com o mesmo nome de host, pois na verdade é o mesmo host com diferentes endereços IP e rotas. Isso pode ser alcançado com uma configuração DNS round-robin + registros PTR correspondentes e banner SMTP, por exemplo
Não se esqueça de adicionar um registro SPF permitindo que ambos os endereços IP enviem mensagens, por exemplo
Configuração para e-mail de entrada
Se você quiser preferir o primeiro ISP ao secundário no e-mail de entrada (por exemplo, se ele tiver melhor largura de banda), você pode separar sua configuração MX disso, por exemplo, adicionando
A incompatibilidade de banner não é um problema para e-mails de entrada, então isso seria perfeitamente adequado.
Certificado
Para manter o certificado válido para ambas as configurações, ele deve agora ter SANs para todos
mail.example.com
e . Geralmente, isso não importa muito, pois os certificados de servidor de correio raramente são realmente validados, e a maioria dos sistemas de correio ainda permitiria o retorno a conexões não criptografadas.mx1.example.com
mx2.example.com
Em vez da validação de certificado baseada em CA, a Autenticação de Entidades Nomeadas baseada em DNS (DANE, RFC 6698 ) é uma alternativa proposta, permitindo também a verificação de certificados autoassinados. Para compatibilidade com versões anteriores, não é possível configurar um servidor SMTP para permitir apenas conexões criptografadas, o que deixa uma lacuna para ataques MitM para conexões que podem ser estabelecidas por TLS. Com o DANE é possível declarar que o TLS deve ser usado para a conexão e somente certificados publicados na zona DNS devem ser permitidos.
Você está certo com sua intuição de que isso não é um problema real por causa de duas coisas:
Seu registro MX de backup não deve ser usado para enviar e-mails, apenas para receber e-mails recebidos.
Receber e-mail é fácil: embora alguns remetentes possam ter verificações um pouco mais rigorosas, por exemplo, o conteúdo de um certificado TLS para compatibilidade com versões anteriores, quase todos os remetentes simplesmente entregam e-mails para seus registros MX, desde que algo esteja escutando na porta TCP 25, responde corretamente às mensagens do protocolo SMTP e está retornando uma
250
resposta "Ação de email solicitada concluída com êxito" após aceitar o email para entrega a você.(É apenas o envio de e-mail de forma confiável que definitivamente requer uma configuração muito mais cuidadosa e aderência ao protocolo.)
Até onde eu sei, apenas o número do código de retorno de resposta SMTP real em quase todas as mensagens do servidor é relevante para o próprio protocolo. O texto que segue o código de resposta do servidor SMTP não apenas na mensagem do banner, mas também em erro e na maioria das outras mensagens é interessante apenas para fins de depuração / interação humana e não é relevante do ponto de vista do protocolo SMTP (e principalmente ignorado). Por favor, note que é apenas para mensagens do servidor, para combater o spam, os próprios servidores SMTP são muito mais rigorosos quanto ao que eles exigem ao receber mensagens de clientes/outros servidores de correio.
De RFC 5321 :
Uma das maneiras de configurar o Postfix em situações como a sua é definir duas interfaces de transporte smtp de saída no master.conf:
Em seguida, defina o parâmetro 'default_transport' em seu main.cf:
Finalmente, crie um script de shell que verifique suas conexões ISP regularmente pelo cronjob e alterne o transporte Postfix em tempo real. Aqui está um exemplo de tal script bash (supondo que seus dois ISPs conectados às interfaces eth0 e eth1. Alternativamente, use a opção -S para o comando ping abaixo definindo o endereço IP de origem: ping -S 198.51.100.30 -c 2 $SERVERIP... - maneira particular depende da sua configuração de duas interfaces de gateway/tabela de roteamento), ele deve ser executado na raiz:
Exemplo de crontab do root (execute 'crontab -e' sob root para editar) para executar o script uma vez a cada 2 minutos:
Justificativa:
O banner SMTP é definido apenas para o daemon smtp (servidor) que recebe a conexão de entrada do cliente smtp. Com o servidor de banner SMTP, identifica-se para o cliente conectado durante o início da sessão. É opcional, no entanto.
De RFC 5321 :
O cliente (por exemplo, outro servidor que deseja entregar e-mail ao servidor de entrada) nunca envia o banner SMTP para o servidor de recebimento. O que é enviado para o servidor é o nome do host EHLO/HELO e isso é exatamente o que é verificado pelos servidores em relação à incompatibilidade de PTR em relação a spam, etc.
De RFC 5321 :
Baseado em EHLO/HELO o servidor pode checar o PTR (se o ip do remetente SMTP resolver de volta para o nome do host) e/ou spf e finalmente decidir se ele realmente quer receber ou retransmitir a mensagem de email originada do cliente SMTP.
Com base nisso, o que você deve fazer em geral é se preocupar com os comandos EHLO que seu servidor SMTP envia para outros servidores quando deseja enviar mensagens de email para eles (e atua como um cliente SMTP durante essas conexões). Você deve garantir que seu servidor SMTP use o endereço IP de origem adequado e envie o nome de host EHLO adequado que resolva de volta para esse IP usado para conexão. E você pode basicamente ignorar o banner SMTP simplesmente porque se trata de receber e-mail, não de enviar.
Eu acho que o mxtoolbox também mistura incompatibilidade de DNS reverso SMTP e incompatibilidade de banner SMTP e verifica o último sem motivo, e seu texto sobre o banner SMTP a esse respeito está parcialmente incorreto. SMTP rDNS Mismatch não importa, SMTP Banner Mismatch não. Novamente, o banner SMTP é enviado pelo servidor receptor (por isso é definido no Postfix no parâmetro 'smtpd_banner', não no 'smtp_banner') e não pelo cliente de envio/retransmissão. Assim, não tem nada a ver com spam, etc.
Nesse sentido, o banner SMTP serve ao mesmo propósito que os certificados para identificar o servidor receptor, embora sem a cadeia de confiança de terceiros.