В своих заметках и статьях про почтовый сервер я ни разу не касался темы резервного сервера, который в рамках возможностей DNS записей вида MX реализу…

В своих заметках и статьях про почтовый сервер я ни разу не касался темы резервного сервера, который в рамках возможностей DNS записей вида MX реализуется очень просто. Для каждого домена могут быть указаны несколько почтовых серверов, используя разные приоритеты. Например:

# dig 1c.ru MX +short
20 relay.1c.ru.
30 mx1-ksmg.1c.ru.

Нашёл случайный пример. Для домена прописаны 2 сервера с разными приоритетами: 20 и 30. У кого приоритет меньше - туда по умолчанию отправляется письмо. Если первый сервер из списка недоступен, письмо отправляется на следующий в списке приоритетов сервер.

На практике я не знаю, насколько активно сейчас это применяется. Я проверил с десяток популярных доменов и только у 1С нашёл 2 сервера. В основном у всех один, либо несколько но с одинаковыми приоритетами для распределения нагрузки. Думаю, я знаю, в чём причина.

Когда я только начинал настраивать почтовые сервера, делал резервные сервера и MX записи к ним. На практике это приводило к серьёзным заботам и хлопотам:

1️⃣ По хорошему, вам нужно синхронизировать информацию о ящиках и пользователям между двумя серверами. Можно этого не делать и собирать всю почту в один ящик-ловушку для всех писем домена, но потом придётся каким-то образом раскладывать её по пользователям.

2️⃣ В случае, если ваш основной сервер по каким-то причинам был недоступен и письма попали на резервный, вам придётся потом каким-то образом вернуть эти письма на основной в ящики пользователей. Решения для этого есть - тот же fetchmail (https://t.me/srv_admin/5323). Он может на основании адреса получателя раскладывать письма по пользователям. Но всё это надо поддерживать в актуальном состоянии, следить, что нормально работает. На практике это не так то просто реализовать, если это не какое-то готовое решение.

3️⃣ На резервный MX сервер спамеры могут слать спам вопреки более высокому приоритету основного сервера. Это отдельные хлопоты по администрированию.

Надо ещё понимать особенность обмена письмами по SMTP. Стандартной настройкой почтовых серверов является многократные попытки доставить почту. Если у вас упал почтовый сервер, то отправитель, не доставив с первого раза письмо, будет пытаться доставить его ещё какое-то время. Причём существенное время, если администратор сервера отправителя для каких-то целей сильно не урезал время нахождения недоставленного письма в очереди. Обычно письма в очереди на отправку с периодическими попытками доставить находятся день-два, могут и больше.

При таких вводных получается, что даже если ваш почтовый сервер недоступен час-два, с большой долей вероятности вы не потеряете переписку. Все письма упадут в почтовые ящики пользователей, когда сервер вернётся в онлайн. И вам не придётся потом разбираться с синхронизацией почтовых ящиков между двумя серверами.

Собственно, я поэтому и перестал держать резервные сервера, когда один раз столкнулся с такой ситуацией. За пару часов на резервный сервер нападало писем, которые потом нужно было возвращать на основной. Вроде бы и хорошо, что ничего не потерял, но на деле я бы скорее всего и так ничего бы не потерял. Тем более если это рядовой сервер с перепиской пользователей. Обычно потеря письма некритична. Бывает, что письма не доходят. Если письмо не дошло до адресата из-за недоступности сервера, отправитель получит об этом уведомление.

Крупные же компании, где к почте предъявляются высокие требования по доступности, насколько я понимаю, предпочитают настраивать отказоустойчивые кластера основного сервера, а не выстраивать инфраструктуру с основным и резервными, так как это приводит к описанным выше хлопотам. Либо же это должно быть готовое программное обеспечение, которое автоматически реализует такую схему работы. Мне таковое неизвестно.

❗️Написанное выше исключительно моё мнение и опыт. Не претендую на правоту и истину. Если кто-то поделится своим опытом настройки основного и резервного MX серверов, с удовольствием прочитаю и приму к сведению.

#mailserver