Come testare un server MX di backup / secondario?

Voglio creare un server MX secondario usando Postfix ma mi chiedo quale sia il modo migliore per testarlo prima di metterlo in produzione (aggiungendo la sua voce MX)?

Un modo possibile è testarlo con un nome di dominio completamente diverso, ovvero acquistare un dominio come "fake-test-domain.com" e configurarlo nella sua zona DNS con SOLO questo server MX di backup.

Un modo più semplice per forzare un server di posta a inviare un messaggio a questo server prima che sia elencato nel DNS?

Non credo di poter usare il file hosts sul sistema di invio perché non emulerebbe un record MX, giusto?

— thomasrutter
fonte

Puoi semplicemente abilitare il MX secondario. Finché ha un prio inferiore nei record MX, non verrà eseguita alcuna consegna e puoi testare come indicato da @EEAA. A proposito: attenzione che i server di posta fallback sono trappole di spam. E se non imposti la verifica del destinatario, ricevi molti messaggi di rimbalzo a qualunque spammer di indirizzo di indirizzo utilizzi. Potresti voler impostare un sistema manuale o automatico che controlli le regole di iptables per l'accesso alla porta 25. La maggior parte dei server di invio ha un tempo di differimento di tre giorni, quindi è facile aprire manualmente la porta MX di fallback 25 solo quando è necessario.

— Halfgaar,

Vorrei chiederti perché pensi di aver bisogno di un MX secondario?

— joeqwerty,

@Halfgaar se il server MX secondario non è configurato correttamente, potrebbe verificarsi la perdita di posta nel caso improbabile in cui un mittente non sia in grado di connettersi al server MX primario per qualsiasi motivo (incluso un problema di connettività alla fine). Almeno se non è stato ancora aggiunto al DNS, allora un problema temporaneo con il primario non causerà la perdita di posta - un mittente accoderà la posta e riproverà più tardi.

— thomasrutter,

@joeqwerty In realtà sto pensando di migrare un server di posta su un altro computer che comporterà la configurazione del vecchio server per l'inoltro al nuovo server durante la propagazione DNS (anche con valori TTL bassi, alcuni resolver memorizzeranno nella cache per 30 minuti o più) . Dal momento che dovrò impegnarmi per far funzionare correttamente questo inoltro, ho pensato che avrei potuto anche creare una configurazione del server MX di backup. E sarà un'esperienza di apprendimento. Questo era solo per dare un po 'di informazioni sul perché.

— thomasrutter,

Risposte:

Basta usare una sessione telnet per testare la consegna della posta elettronica. Come esempio,

# 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 - Chiunque amministri un server SMTP ma non può eseguire il protocollo "a mano" in TELNET non ha attività di amministrazione di un server SMTP.

— Evan Anderson,

@EvanAnderson Questo è un buon principio generale fino a quando non si tratta di testare STARTTLS o qualsiasi AUTH diverso da PLAIN. Ma sì, in questo caso hai perfettamente ragione.

— thomasrutter,

@thomasrutter Provo di routine STARTTLSa mano, usando openssl s_client -starttls smtp -connect .... Ma sono d'accordo sul fatto che i metodi di autenticazione non PLAIN siano problematici.

— MadHatter,

Quando telnet non è abbastanza, o troppo noioso, uso SWAKS

per esempio:

 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 swaksha lavorato su Ubuntu

— Donn Lee il