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


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

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

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

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


9
2018-06-23 02:52


Источник


Вы можете просто включить вторичный MX. До тех пор, пока в записи MX будет меньше prio, доставка на него не будет произведена, и вы можете протестировать это как указано @EEAA. Кстати: будьте осторожны, что резервные почтовые серверы - это спам-ловушки. И если вы не настроите проверку получателей, вы получите много сообщений об отказе от любых спамотонов-адресатов. Вы можете настроить ручную или автоматическую систему, которая управляет правилами iptables для доступа к порту 25. Большинство отправляющих серверов имеют время отсрочки на три дня, поэтому легко вручную открыть резервный MX-порт 25 только тогда, когда это необходимо. - Halfgaar
Я бы поставил под вопрос, почему вы думаете, что вам нужен вторичный MX? - joeqwerty
@Halfgaar, если вторичный сервер MX неправильно сконфигурирован, это может привести к потере почты в маловероятном случае, когда отправитель не может подключиться к основному серверу MX по какой-либо причине (включая проблему с подключением на их конце). По крайней мере, если он еще не был добавлен в DNS, тогда переходная проблема с первичным не приведет к потере почты - отправитель просто поставит в очередь почту и повторит попытку позже. - thomasrutter
@joeqwerty Я на самом деле думаю о переносе почтового сервера на другую машину, которая будет включать настройку старый сервер для ретрансляции на новый сервер во время распространения DNS (даже при низких значениях TTL, некоторые решатели будут кэшировать 30 минут и более). Поскольку мне нужно будет приложить все усилия, чтобы эта ретрансляция работала правильно, я подумал, что могу создать резервную конфигурацию MX-сервера. И это будет опыт обучения. Это было просто для того, чтобы немного рассказать о том, почему. - thomasrutter


Ответы:


Просто используйте сеанс 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

18
2018-06-23 03:04



+1 - Любой, кто управляет SMTP-сервером, но не может запустить протокол «вручную» в TELNET, не управляет SMTP-сервером. - Evan Anderson
@EvanAnderson Это хороший общий принцип, пока не дойдет до тестирования STARTTLS или любого AUTH, кроме PLAIN. Но да, в этом случае вы абсолютно правы. - thomasrutter
@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'

1
2018-02-15 00:47