почтовая архитектура со вторым MX

Чтобы при падении или кратковременном отсутствии связи с основным MX, не терялись сообщения?

Во-первых, именно это - не твоя проблема, это проблема серверов отправителей. Ибо https://datatracker.ietf.org/doc/html/rfc5321#section-4.5.4.1

The general model for an SMTP client is one or more processes that periodically attempt to transmit outgoing mail. In a typical system, the program that composes a message has some method for requesting immediate attention for a new piece of outgoing mail, while mail that cannot be transmitted immediately MUST be queued and periodically retried by the sender.
<...>
Retries continue until the message is transmitted or the sender gives up; the give-up time generally needs to be at least 4-5 days.

Как правильно организовать backup MX? Правильно ли понимаю, что надо на backup MX поднять MTA и потом гнать мессаги по rsync в maildir-каталоги файлы сообщений, либо поднять вместо этого Dovecot и оттуда забирать по POP3/IMAP4 на основной MX MTA?

Ну а во-вторых дальше варианты могут быть разные. Можно полностю автономный почтовый сервер сделать и с первого фетчмайлом каким забирать, можно отдельную железку (и, даже, кластер, например cyrus-imap+murder для этого вроде как) для pop/imap, а MTA на других разных железках и сливают туда принятое по LMTP.

либо поднять вместо этого Dovecot и оттуда забирать по POP3/IMAP4 на основной MX MTA?

this

Просто на backup MX MTA принимать и пересылать на основной MX, сделать почаще запуск и дольше хранение очереди.

Просто на backup MX MTA принимать и пересылать на основной MX, сделать почаще запуск и дольше хранение очереди.

Это имеет смысл только в том случае, если авария на срок, превышающий указанный в первом ответе. А это в сутках. То есть четверо суток без почты - это нормально по плану?

То есть четверо суток без почты - это нормально по плану?

Если основной почтовый сервер может не работать сутками, такой почтовый сервер не нужен. Резервные делаются на случай кратковременной недоступности основного чтобы получать почту с минимальными задержками и они должны сразу и часто пытаться пересылать письма т.к. некоторые сервисы не смотрят на приоритеты и отправляют на первый попавшийся MX.

Если основной почтовый сервер может не работать сутками, такой почтовый сервер не нужен.

Да что вы говорите. А всяческие аварии у ISP, пожары в ДЦ и не только, а так же другие строители уже не модны?
И это я только из вполне доступного крупняка перечислил, то что так сказать на поверхности.

Многое зависит от важности почты и количества пользователей. На каждом MX держать и MTA и IMAP сервер со всей базой пользователей и прочим, синхронизировать между ними почту чтобы ничего не пропустить или если вдруг во время аварии захочется ответить-посмотреть на старое письмо?? мне как то такая схема очень не нравится.

Если основной почтовый сервер может не работать сутками, такой почтовый сервер не нужен.

---

На каждом MX держать и MTA и IMAP сервер со всей базой пользователей и прочим, синхронизировать между ними почту чтобы ничего не пропустить или если вдруг во время аварии захочется ответить-посмотреть на старое письмо?? мне как то такая схема очень не нравится.

Вы уж определитесь с вашими предпочтениями.

Не всем нужна определённость.

предпочтениями.

У меня в домашних условиях (с ИБП и 2-3 провайдерами одновременно) основной почтовый сервер за более чем 10 лет ни разу не простаивал без питания и сети больше 4 часов подряд, поэтому не представляю как в условиях нормального ДЦ могут быть частые аварии на несколько часов-сутки и более. Были долго серверы в ДЦ посреди поля где ездят пьяные трактористы за Новосибирском, даже там не случалось перебоев на сутки ))

У меня в домашних условиях

...

ни разу не простаивал без питания и сети больше 4 часов подряд

Я за вас порадовался. Но может не надо ваши «истории успеха» транслировать в виде «делай как я»?

поэтому не представляю как в условиях нормального ДЦ могут быть частые аварии на несколько часов-сутки и более.

А это вы зачем сюда приплели?

ЗЫ Ну и у меня есть сильные сомнения в части вашей однозначности в высказывании «больше 4 часов подряд».

«истории успеха» транслировать в виде «делай как я»?

Напишите свой вариант архитектуры мультиMXов на разных серверах.

сильные сомнения

Понимаю, что доказать точно практически невозможно, могу предложить найти тут отсутствие кадров в архиве на большие промежутки времени.

Напишите свой вариант архитектуры мультиMXов на разных серверах.

Я вроде специально процитировал «в домашних условиях», вы не заметили?

Понимаю, что доказать точно практически невозможно, могу предложить найти тут отсутствие кадров в архиве на большие промежутки времени.

Даже не смешно. А с учетом того, что выше вы сами написали «с ИБП» - не смешно в кубе.

Резервные делаются на случай кратковременной недоступности основного чтобы получать почту с минимальными задержками и они должны сразу и часто пытаться пересылать письма т.к. некоторые сервисы не смотрят на приоритеты и отправляют на первый попавшийся MX.

Бессмысленно выполнять работу серверов отправителей. Ради кратковременной недоступности делать не нужно вообще ничего. Сервер поднимется, почта долетит. Вот если недоступность планируется длительная, тогда это нужно. Но нужен и механизм получения почты пользователями. По-этому имеет смысл либо полноценный почтовый сервер в качестве бакапа, либо отдельный POP/IMAP, вероятно в кластере, и куча MX, сразу сливающих данные на него. Для первого случая на основном можно держать fetchmail для периодического выгребания случайной почты с запасного.

На каждом MX держать и MTA и IMAP сервер со всей базой пользователей и прочим, синхронизировать между ними почту чтобы ничего не пропустить

Первый вариант. Если работа ведётся по pop3, а почта пользователями на сервере не хранится, то ничего синхронизировать не надо, кроме самой базы пользователей. Пользователь просто забирает из всех источников.

Второй вариант. Есть устойчивый POP/IMAP, отвечающий за базу пользователей. Каждый MX при приёме спрашивает у POP/IMAP «Есть пользователь»? Для этого есть Cyrus-IMAP, у которого есть smmapd, и есть Sendmail, который умеет в socket map. Наверное можно реализовать и через milter и прикрутить к Постфиксу. Может быть можно без smmapd, через общий sasl какой-нибудь, или LDAP. Но smmapd у Cyrus сразу ещё вопрос переполнения ящика решает, если квоты есть.

Без списка пользователей резервный MTA будет принимать всё для домена, то есть кучу спама на несуществующие адреса. А потом при пересылке на основой сервер получать от него отлуп и генерить bounce email...