Должен ли резервный SMTP-сервер fi Фильтр / экран входящей электронной почты так же, как и основной сервер?
Предположим, у нас есть 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, или тот факт, что эти вещи проверяются на альфа , когда письмо доставлено, достаточно
Также будет beta ретрансляция электронных писем на альфа противоречит этим запросам SPF, учитывая, что beta.example.com вряд ли будет указан в качестве действительного отправителя arbitary.org ].
Технически я использую Postfix для SMTP (и Dovecot для аутентификации / IMAP), на случай, если это даст ответы.
Запуск того же типа проверок на вторичном сервере ничего не стоит, так почему бы просто не сделать это?
Некоторые другие причины:
- Вам придется адаптировать ваш первичный сервер, чтобы правильно обрабатывать почту со вторичного сервера, как если бы она приходила с одного прыжка раньше. Ваша проблема с SPF действительна и по умолчанию будет проблемой. Предположить, что фильтрация уже произошла, намного проще.
- Большинство антиспамовых решений отклоняют некоторые сообщения до того, как они будут полностью переданы (например, сразу после сообщения EHLO или после заголовка TO). Без этих фильтров вам сначала нужно принять их и полностью обработать их на основном сервере. В некоторых юрисдикциях это может даже стать юридической проблемой (например, в некоторых созвездиях допустимо полностью отклонить письмо, когда отправитель знает об этом, но не нормально сначала принимать почту, а затем все равно удалять ее на дальнейших этапах фильтрации. , без ведома отправителя).
Анализ Authentication-Results резервной копии MX здесь не является реальной проблемой. RFC 7601 описывает надежные механизмы для борьбы с потенциальным злоупотреблением - вы удаляете явно поддельные заголовки во время очистки заголовков и указываете своему программному обеспечению проверки доверять результатам, определенным вашим резервным mx ( TrustedAuthServIDs beta.example.com в opendmarc.conf ).
Однако Нет , запуск вторичного MX с той же конфигурацией, что и первичный MX, сводит на нет большую часть первоначальной цели его развертывания:
Существует ненулевая вероятность того, что сбой вашего основного почтового сервера вызван одной из ваших программ фильтрации почты - если вы просто продублируете настройку, одно плохое обновление spamassassin сломает оба, одно плохое обновление валидатора SPF сломается. оба, .. Резервный MX, который, вероятно, выходит из строя из-за общей основной причины, не стоит многого.
Ваш основной почтовый сервер, вероятно, уже фильтрует почту на основе статистических данных (например, Байесовская фильтрация ), что трудно синхронизировать первичный и резервный p mx. Если вы действительно настроите фильтрацию почты на резервном mx так же, как на основном mx - и эти данные будут другими, вы либо ухудшите качество фильтрации спама - либо отправите больше отказов (eww).
Если ваша задача - обеспечить некоторые Уровень обслуживания, такой как «98% ежегодной почты без спама должны отображаться в IMAP в течение 60 секунд», у вас уже есть много места для внепланового обслуживания. Вполне возможно, что потенциальное улучшение уровня обслуживания по сравнению с повторяющимися административными затратами на запуск резервного MX приведет к тому, что любая удаленная сложная настройка MX резервного копирования «не стоит того».