Предположим, у нас есть SMTP-сервер с именем alpha.example.com, который является единственным сервером MX, указанным для example.com.
Как и большинство современных SMTP-серверов электронной почты, он отклоняет электронные письма, не привязанные к группе виртуальных пользователей, отклоняет входящую почту из доменов, перечисленных в spamhaus, пропускает почту через SpamAssassin, проверяет записи SPF и все такое хорошее.
Однако, будучи единственной записью MX, указанной для example.com, есть опасения, что, если машина будет отключена для обслуживания, электронная почта может быть отложена. Очевидно, что другие SMTP-серверы с хорошим поведением будут стоять в очереди и повторять попытку позже, но это может привести к задержкам в несколько десятков минут или часов, даже если основной будет отключен на небольшой промежуток времени, если это совпадет с попыткой доставки.
Мы хотим запустить вторичный SMTP-сервер, который назовем beta.example.com, который будет указан как запись MX с более низким приоритетом. Но alpha.example.com все еще там, где хранится вся почта, к нему все пользователи подключают свои MUA. Так beta.example.com будет просто хранить и пересылать электронную почту на alpha.example.com, поскольку это не "конечная точка".
Мой вопрос: есть ли beta необходимо также запустить его электронную почту через те же проверки, что и alpha? т.е. проверка виртуальных пользователей, spamhaus, поиск SPF, проверки DKIM или факт того, что эти вещи проверяются на alpha когда письмо доставлено, достаточно
Также будет beta пересылка писем на alpha не попадают в эти письма с запросами SPF, учитывая, что beta.example.com вряд ли будет указан в качестве действительного отправителя arbitary.orgэлектронные письма.
Технически я использую Postfix для SMTP (и Dovecot для стороны аутентификации / IMAP), если это дает ответы.
Выполнение на вторичном сервере таких же проверок ничего не стоит, так почему бы просто не сделать это?
Некоторые другие причины:
Парсинг Authentication-Results резервной копии MX здесь не проблема. RFC 7601 описывает надежные механизмы для борьбы с потенциальным злоупотреблением - вы удаляете явно поддельные заголовки во время очистки заголовка и указываете своему программному обеспечению проверки доверять результатам, определенным вашим резервным mx (TrustedAuthServIDs beta.example.com в opendmarc.conf).
Все же Нет, запуск вторичного MX с той же конфигурацией, что и первичный MX, во многом сводит на нет первоначальную цель его развертывания:
Существует ненулевая вероятность того, что сбой вашего основного почтового сервера вызван одной из ваших программ фильтрации почты - если вы просто продублируете настройку, одна ошибка спамассасин обновление ломает оба, одно плохое обновление валидатора SPF ломает оба, .. Резервная копия MX, которая, вероятно, выходит из строя по общей основной причине, не стоит многого.
Ваш основной почтовый сервер, вероятно, уже фильтрует почту на основе статистических данных (например, Байесовская фильтрация), который трудно синхронизировать между основным и резервным mx. Если вы действительно настроите фильтрацию почты на резервном mx так же, как на основном mx - и эти данные отличаются, вы либо ухудшите качество фильтрации спама, либо отправите больше отказов (eww).
Если ваша задача - обеспечить некоторый уровень обслуживания, такой как «98% ежегодной почты без спама должны отображаться в IMAP в течение 60 секунд», у вас уже есть масса места для внепланового обслуживания. Вполне возможно, что потенциальное улучшение уровня обслуживания по сравнению с повторяющимися административными затратами на запуск резервного MX в конечном итоге сделает любую удаленную сложную настройку MX для резервного копирования «не стоящей того».