Этот контур появился не из желания «поиграться с почтовым сервером»
У компании уже был болезненный опыт: после проблем у прежнего хостера и DDoS-атаки РЕТОН примерно два месяца фактически оставался без нормальной корпоративной почты, а значительную часть истории писем восстановить не удалось
После такого архитектурная задача формулируется иначе
Не «как настроить почту», а как сделать так, чтобы одна внешняя площадка больше не могла оставить компанию без канала связи и истории
Основной провайдер остаётся, но перестаёт быть единственной точкой отказа
Сейчас основной почтовый транспорт снова находится у внешнего провайдера
При этом рядом поднят собственный резервный контур:
- Postfix
- Dovecot
- Roundcube
- отдельный резервный почтовый домен
- автоматическое наблюдение за внешним SMTP
- аварийный режим отправки
- локальная очередь сообщений
Это не попытка полностью отказаться от провайдера. Скорее страховочный слой вокруг него
Свой Roundcube нужен не ради красивого веб-интерфейса

Roundcube здесь полезен как независимая точка доступа к резервной почтовой инфраструктуре
Если основной веб-интерфейс провайдера недоступен, остаётся собственный интерфейс, связанный с локальным Dovecot
Важно, что он живёт на другом серверном контуре и не зависит от интерфейса основного хостинга
Автоматический failover проверяет не только порт
Фоновый watcher регулярно проверяет внешний SMTP с настоящим TLS-соединением
После нескольких подтверждённых сетевых ошибок он может переключить Postfix из обычного режима через relay провайдера в аварийную прямую отправку
Обратное переключение тоже не происходит после одного удачного запроса. Система ждёт несколько последовательных успешных проверок
Так единичное моргание не приводит к постоянному переключению режимов туда-сюда
Ошибка пароля и отказ провайдера — не одно и то же
Отдельно мне нравится небольшая деталь в failover
Если тестовый ящик вернул явную ошибку авторизации, система не считает это доказательством падения всего SMTP и не включает аварийный режим автоматически
Это защищает от очень неприятной ситуации: кто-то поменял пароль технической учётки, а сервер решил, что умер провайдер, и перестроил всю схему доставки
Очередь нужна для неопределённых ситуаций
Для части почтового пути существует отдельный durable spool
Письмо сначала сохраняется локально вместе с метаданными, размером и контрольной суммой. Worker перед отправкой проверяет целостность данных
Если письмо уже появилось в целевом IMAP, повторно оно не добавляется
Если сервер принял APPEND, но соединение оборвалось до уверенного подтверждения, элемент не удаляется слепо из очереди. На следующем проходе система сначала ищет тот же Message-ID
Это тот же принцип, который полезен в платежах и 1С: не повторять опасное действие, пока не проверил, не успело ли оно выполниться в прошлый раз
Зеркало — самая сложная и пока незакрытая часть
Для почтовых ящиков был построен периодический IMAP → локальный Dovecot mirror с защитами, повторными попытками и дедупликацией
Идея правильная: иметь независимую копию писем, которую можно открыть даже при проблеме внешней площадки
Но в текущем состоянии автоматическое копирование пришлось остановить после нестабильного поведения. Поэтому я не называю зеркало завершённым рабочим контуром
Сейчас это готовая архитектурная ветка, которую нужно отдельно доаудировать и усилить перед повторным включением
Что уже работает сейчас
На момент аудита активны Postfix, Dovecot, Nginx, собственный Roundcube и автоматический watcher внешнего SMTP
Очередь также обслуживается отдельным таймером. То есть резервная инфраструктура существует не только в виде конфигурационных файлов
При этом публикация этого кейса не означает, что «почта теперь никогда не упадёт». Такой гарантии вообще нельзя давать
Что для меня главное в этой истории
Отказоустойчивость редко появляется до первого серьёзного сбоя — пока всё работает, резерв кажется лишней сложностью
Но после ситуации, когда компания неделями не получает нормальную почту и теряет часть истории, цена одной точки отказа становится очень понятной
Поэтому этот проект для меня не про Postfix и Roundcube как технологии
Он про архитектурный вывод: критический канал бизнеса должен иметь независимый путь восстановления, а не только надежду на одного провайдера
