Как вы можете проверить резервный / вторичный сервер MX?

Я хочу настроить вторичный сервер MX с использованием Postfix, но мне интересно, каков наилучший способ проверить это перед вводом в эксплуатацию (добавив запись MX)?

Один из возможных способов - протестировать его с совершенно другим доменным именем, то есть купить домен, подобный «fake-test-domain.com», и настроить его DNS-зону ТОЛЬКО на этом резервном MX-сервере.

Какой-нибудь более простой способ заставить почтовый сервер отправить сообщение на этот сервер, прежде чем он будет указан в DNS?

Я не думаю, что смогу использовать файл hosts в отправляющей системе, потому что это не будет эмулировать запись MX, верно?

— thomasrutter
источник

Вы можете просто включить дополнительный MX. Пока он имеет более низкий приоритет в записях MX, доставка не будет выполнена, и вы можете проверить, как упомянуто @EEAA. Кстати: остерегайтесь того, что резервные почтовые серверы являются ловушками спама. А если вы не настроите проверку получателя, вы получите много сообщений о пересылке всем тем, кто использует спамеры с адреса. Возможно, вы захотите настроить ручную или автоматическую систему, управляющую правилами iptables для доступа к порту 25. У большинства отправляющих серверов есть три дня отсрочки, поэтому легко открыть запасной порт MX 25 вручную, только когда это необходимо.

— Halfgaar

Я хотел бы спросить, почему вы думаете, что вам нужен вторичный MX?

— Joeqwerty

@Halfgaar, если вторичный MX-сервер настроен неправильно, это может привести к потере почты в маловероятном случае, когда отправитель по какой-либо причине не сможет подключиться к первичному MX-серверу (включая проблему с подключением на их конце). По крайней мере, если он еще не был добавлен в DNS, то временная проблема с первичным сервером не приведет к потере почты - отправитель просто поставит почту в очередь и попытается позже.

— Томасруттер

@joeqwerty Я на самом деле думаю о переносе почтового сервера на другой компьютер, что потребует настройки старого сервера для ретрансляции на новый сервер во время распространения DNS (даже при низких значениях TTL некоторые распознаватели будут кэшироваться в течение 30 минут или более) , Так как мне все равно нужно приложить усилия, чтобы заставить эту ретрансляцию работать правильно, я подумал, что я также могу создать резервную конфигурацию MX-сервера. И это будет опыт обучения. Это было только для того, чтобы дать представление о том, почему.

— Томасруттер

Просто используйте сеанс telnet для проверки доставки электронной почты. В качестве примера,

# 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
источник

+1 - Любой, кто администрирует SMTP-сервер, но не может запустить протокол «вручную» в TELNET, не имеет права администрировать SMTP-сервер.

— Эван Андерсон

@EvanAnderson Это хороший общий принцип, пока речь не идет о тестировании STARTTLS или любого AUTH, кроме PLAIN. Но да, в этом случае вы абсолютно правы.

— Томасруттер

@thomasrutter Я обычно проверяю STARTTLSвручную, используя openssl s_client -starttls smtp -connect .... Но я согласен с тем, что методы аутентификации без PLAIN проблематичны.

— MadHatter

Когда Telnet недостаточно или утомительно, я использую SWAKS

например:

 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
источник

sudo apt install swaksработал над убунту

— Донн Ли