Como você pode testar um servidor MX secundário / de backup?

Estou querendo configurar um servidor MX secundário usando o Postfix, mas gostaria de saber qual é a melhor maneira de testar isso antes de colocar em produção (adicionando sua entrada MX)?

Uma maneira possível é testá-lo com um nome de domínio totalmente diferente, ou seja, comprar um domínio como "fake-test-domain.com" e configurar sua zona DNS somente com este servidor MX de backup.

De qualquer maneira mais fácil, posso forçar um servidor de email a enviar uma mensagem para esse servidor antes que ele seja listado no DNS?

Eu não acho que posso usar o arquivo hosts no sistema de envio porque isso não emularia um registro MX, certo?

— thomasrutter
fonte

Você pode apenas ativar o MX secundário. Desde que ele tenha um preço baixo nos registros MX, nenhuma entrega será feita e você poderá testar como o @EEAA mencionado. BTW: cuidado com o fato de os servidores de correio de reserva serem armadilhas de spam. E se você não configurar a verificação de destinatário, receberá muitas mensagens de rejeição para qualquer que seja o uso de spammers do endereço. Convém configurar um sistema manual ou automático que controle as regras do iptables para acessar a porta 25. A maioria dos servidores de envio tem um período de adiamento de três dias, portanto, é fácil abrir manualmente a porta 25 de fallback MX somente quando necessário.

— Halfgaar

Gostaria de perguntar por que você acha que precisa de um MX secundário?

— joeqwerty

@ Halfgaar, se o servidor MX secundário estiver configurado incorretamente, poderá levar à perda de e-mail no caso improvável de um remetente não conseguir se conectar ao servidor MX principal por qualquer motivo (incluindo um problema de conectividade no final). Pelo menos, se ainda não tiver sido adicionado ao DNS, um problema transitório no primário não causará perda de correio - um remetente apenas enfileirará o correio e tentará novamente mais tarde.

— thomasrutter

@joeqwerty Estou realmente pensando em migrar um servidor de email para outra máquina, o que envolverá a configuração do servidor antigo para retransmitir para o novo servidor durante a propagação do DNS (mesmo com valores TTL baixos, alguns resolvedores ficarão em cache por 30 minutos ou mais) . Como vou precisar fazer um esforço para que essa retransmissão funcione corretamente de qualquer maneira, pensei em criar uma configuração de servidor MX de backup. E será uma experiência de aprendizado. Isso foi apenas para dar um pouco de pano de fundo sobre o porquê.

— thomasrutter

Respostas:

Basta usar uma sessão de telnet para testar a entrega de email. Como um exemplo,

# telnet host.domain 25
Trying host.domain...
Connected to host.domain.
Escape character is '^]'.
220  ESMTP
HELO example.com
250
MAIL FROM:<user@example.com>
250 ok
RCPT TO:<user2@example.com>
250 ok
DATA

To: user2@example.com
From: user@example.com
Subject: a test message

Test message body.
.
250 ok

— EEAA
fonte

+1 - Qualquer pessoa que administra um servidor SMTP, mas não pode executar o protocolo "manualmente" no TELNET, não pode administrar um servidor SMTP.

— Evan Anderson

@EvanAnderson Esse é um bom princípio geral até o teste do STARTTLS ou de qualquer outro AUTH que não seja o PLAIN. Mas sim, neste caso, você está absolutamente certo.

— thomasrutter

@thomasrutter Testo rotineiramente STARTTLSà mão, usando openssl s_client -starttls smtp -connect .... Mas concordo que os métodos de autenticação não-PLAIN sejam problemáticos.

— MadHatter

Quando o telnet não é suficiente ou é muito tedioso, eu uso o SWAKS

por exemplo:

 cat email-content.txt | 
 swaks --body - --helo localhost.localhomain --server mail.example.com:25 \
  --auth-user fred --auth-password flintst1 -tls \
  --h-Subject Pebbles  --to wilma@example.org
  --from 'fred@example.biz'

— user313114
fonte

sudo apt install swakstrabalhou no ubuntu

— Donn Lee