Postfix Dovecot Rspamd: замена почтового сервера в контуре

Зачем менять почтовый сервер и что может пойти не так

Коммерческий почтовый сервер часто выбирают за подход «все в одном». Но со временем начинают мешать практичные вещи: лицензии дорожают, часть настроек закрыта, а любое нестандартное требование превращается в переписку с вендором и ожидание.

В закрытом контуре это ощущается сильнее. Обычно под ним понимают среду без прямого выхода в интернет, со строгими правилами доступа, обязательным аудитом и запретом облачных зависимостей. Здесь важны прозрачные настройки, предсказуемые обновления и возможность объяснить, что именно происходит с письмами.

При замене почтовой системы чаще всего болят одни и те же точки: письма начинают приходить с задержками, часть сообщений теряется при переносе ящиков и очередей, растет спам и фишинг из-за слабых политик, а поддержка превращается в «поиск виноватого» между SMTP, IMAP, DNS и фильтрами. Отдельная категория рисков - несоответствие внутренним регламентам по журналам, хранению и доступу.

Связка Postfix + Dovecot + Rspamd хороша тем, что роли разделены. Postfix отвечает за прием и отправку, Dovecot - за доступ к ящикам, Rspamd - за проверку и оценку писем. Это упрощает диагностику и позволяет настраивать правила под вашу политику, а не под ограничения продукта.

Но «свобода» не страхует от ошибок. Типичный сценарий: организацию переводят в закрытый сегмент, оставляют старые DNS-записи и не фиксируют единый порядок подписи и проверки писем. В итоге у партнеров часть сообщений уходит в карантин, а пользователи видят только одно: «почта сломалась».

Имеет смысл менять сервер не ради «моды», а когда вы готовы заранее описать требования и принять, что первые недели после запуска придется внимательно смотреть на доставку, спам и журналы.

Архитектура Postfix + Dovecot + Rspamd без лишней сложности

В закрытом контуре связка Postfix + Dovecot + Rspamd удобна тем, что каждый компонент делает понятную часть работы.

Postfix принимает письма по SMTP и доставляет их дальше. Dovecot хранит почту в ящиках и выдает ее пользователям по IMAP. Rspamd проверяет входящие и исходящие сообщения и решает, что пропустить, что пометить, а что заблокировать.

По протоколам обычно так:

• SMTP нужен для приема и доставки писем между серверами.
• IMAP нужен пользователям, чтобы читать почту с разных устройств, при этом письма остаются на сервере.
• LMTP часто используют между Postfix и Dovecot, чтобы передавать почту в хранилище с понятными статусами доставки (это удобно для логов и разборов).

Антиспам можно развернуть несколькими способами. На одном узле с Postfix/Dovecot проще стартовать и меньше серверов. Отдельный почтовый шлюз перед основным сервером дает лучшую изоляцию и более ясные правила периметра. Два уровня (шлюз плюс внутренний фильтр) добавляют контроля, но повышают сложность.

Схему лучше выбрать сразу. Для небольшой организации часто достаточно одной машины, если на первом месте простота, а не отказоустойчивость. Две машины (шлюз и сервер ящиков) уже дают четкую границу: снаружи доступен только SMTP, внутри - IMAP и хранилище.

Отдельный вопрос - где хранятся ящики и как их восстанавливать. Локальный диск упрощает бэкапы, но при поломке железа восстановление зависит от того, насколько быстро вы поднимете замену. Сетевое хранилище или репликация повышают надежность, но требуют дисциплины изменений и надежной сети. Минимум, который стоит закрепить до внедрения: где лежат ящики, как часто делаются копии, сколько они хранятся и кто проверяет восстановление на тесте хотя бы раз в квартал.

Сбор требований: пользователи, домены, объемы, политики

Перед настройкой Postfix, Dovecot и Rspamd полезно зафиксировать простые цифры и правила. Это экономит время и снижает риск сюрпризов после запуска.

Начните с инвентаризации: сколько доменов обслуживается, сколько активных ящиков, сколько общих ящиков (например, support@), какой ожидается трафик писем в день. Отдельно уточните типичные размеры вложений и реальные лимиты: одно дело 2-5 ГБ на пользователя, другое - десятки гигабайт у отделов, где почта превращается в архив документов.

Дальше определите, как живут учетные записи. Если вход через AD, заранее согласуйте формат логина (user или user@domain), требования к MFA (если применимо) и правила для внешних подрядчиков. Если будут локальные пользователи, продумайте процесс создания, блокировки и восстановления доступа, чтобы это не превратилось в ручной хаос.

Политики безопасности лучше записать до миграции, а не после первого инцидента. Обычно достаточно согласовать:

• TLS для входа и отправки, а также исключения для старых устройств (если они неизбежны)
• требования к паролям и периодичность смены
• сроки хранения писем и правила удаления или архивирования
• что журналируется, где хранятся логи и у кого к ним доступ
• лимиты на размер письма и вложений

Отдельно проговорите миграционные окна. Сколько часов простоя допустимо, можно ли вести параллельную работу (старый сервер принимает, новый уже отдает пользователям), и как вы будете проверять, что письма не потерялись.

Пример из практики: в организации с филиалами часто оказывается, что часть пользователей работает через Outlook, часть - через мобильные клиенты, а общие ящики используются как мини-CRM. Эти детали напрямую влияют на выбор протоколов, лимитов и план переезда.

Схемы развертывания в закрытом контуре: от простого к надежному

В закрытом контуре почта почти всегда живет между сегментами сети: рабочие места, серверная зона, иногда DMZ, отдельные подсети для админов. Поэтому схема развертывания часто важнее выбора пакетов. Один и тот же набор Postfix + Dovecot + Rspamd можно собрать по-разному, а разница будет в простое, удобстве поддержки и том, насколько легко ограничить доступ.

От одного сервера к разделению ролей

Самый простой вариант - один сервер, где есть и прием/отправка, и ящики, и фильтрация. Он быстро запускается и легко объясняется. Минус тоже простой: любая проблема (диск, обновление, перегрузка фильтра) останавливает все сразу.

Следующий шаг - разделить роли. Частая схема: отдельный SMTP-шлюз (прием, очереди, антиспам) и отдельный сервер ящиков (IMAP/LMTP, хранение). Так проще обновлять компоненты по очереди и легче изолировать хранилище.

Если простои недопустимы, добавляют резерв. Для входящей почты обычно делают два шлюза в актив-актив. Для хранилища часто выбирают актив-пассив: второй узел готов подняться, но не пишет одновременно.

Важно не путать «два сервера» и «двойную запись». Одновременная запись в одно и то же хранилище двумя узлами без продуманной архитектуры часто заканчивается повреждениями данных. Актив-актив для ящиков имеет смысл только при подходящем общем хранилище и четких процедурах.

Хранилище и сеть: что решить заранее

В закрытом контуре обычно начинают с локальных дисков и RAID: это предсказуемо и меньше зависит от сети. Отдельное хранилище имеет смысл, если нужно быстро менять серверы или много ящиков, но тогда растут требования к надежности сети.

Перед установкой полезно согласовать с безопасностью и сетевой командой базовые вещи: где будут VLAN для шлюзов и для ящиков, как организован отдельный доступ админов (jump host, отдельная подсеть), какие межсегментные порты разрешены строго по необходимости, как решаются DNS и синхронизация времени внутри контура, где проходят границы доверия (например, между шлюзом и сервером ящиков).

Практический пример: при жестком разделении сегментов проще принимать почту на шлюзе в серверной зоне, проверять и класть в очередь, а к серверу ящиков разрешать доступ только с этого шлюза и из подсети админов. Так легче удерживать минимальные сетевые исключения и понятную зону ответственности.

Доставляемость: SPF, DKIM, DMARC и базовая гигиена домена

Доставляемость - это не только «антиспам». Это понятный путь письма: сервер принимает или отправляет сообщение, дальше оно проверяется по DNS и репутации, затем попадает в ящик, и только после этого его видит пользователь.

В связке Postfix + Dovecot + Rspamd проблемы часто всплывают на этапе проверки у получателя: удаленная сторона не верит, что письмо действительно от вашего домена.

Начните с гигиены домена и IP. Для исходящей почты критичны три вещи: корректный MX, согласованные имена и обратная зона (PTR), и явное разрешение на отправку (SPF). Если внешний IP один, правило простое: имя в PTR должно совпадать с именем сервера и SMTP-приветствием, а этот хост должен резолвиться обратно в тот же IP.

Минимальный набор DNS, который почти всегда нужен:

• MX на почтовый шлюз для домена
• A/AAAA для имени почтового сервера
• PTR (rDNS) для внешнего IP, который реально отправляет письма
• SPF (TXT) со списком разрешенных отправителей

DKIM добавляет подпись на исходящие письма. Приватный ключ хранится на сервере (часто на шлюзе исходящей почты), публичный ключ публикуется в DNS как TXT. Ключи лучше менять планово, например раз в 6-12 месяцев: сначала добавили новый selector и ключ в DNS, затем переключили подпись, потом убрали старый.

DMARC связывает SPF и DKIM и задает политику. Чтобы не получить массовые ложные отклонения, начинайте с p=none и сбором отчетов. Через несколько недель, когда станут видны реальные источники отправки, переходите к quarantine, и только затем к reject.

Если доменов несколько и часть систем старая (например, МФУ или legacy-CRM шлет напрямую), не ломайте все одним днем. Сначала соберите список источников по каждому домену, затем приведите их к одной модели: либо отправка только через ваш шлюз с авторизацией, либо отдельные SPF и отдельные DKIM-ключи для legacy-систем.

Антиспам и антифишинг на Rspamd: практичные настройки

Rspamd хорошо подходит для этой связки, но его опасно включать «на максимум» в первый день. Самая частая проблема при миграции - ложные срабатывания: важные счета, письма от госорганов или уведомления внутренних систем внезапно уходят в спам или отклоняются.

Rspamd оценивает письмо по сумме сигналов. Это и репутация источника (IP, домены), и структура письма, и ссылки, и типы вложений, и эвристики, и статистика. В закрытом контуре часть внешних проверок может быть недоступна, поэтому особенно важны понятные правила и аккуратные пороги.

С чего начать, чтобы не сломать почту

Стартуйте с мягкого режима: помечайте письма заголовками и переносите в папку «Спам», но не отклоняйте на SMTP. Дайте 1-2 недели на сбор статистики и подстройте пороги.

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

Greylisting в закрытом контуре уместен не всегда. Он помогает против примитивного спама, но может задерживать легитимные письма от партнеров и сервисов. Часто его включают точечно или заменяют лимитами и более строгими порогами.

Белые и черные списки без «вечных дыр»

Белый список держите минимальным: только критичные отправители и внутренние системы, и лучше по конкретным адресам или доменам, а не «все с этого IP». Черный список тоже используйте аккуратно: если домен партнера скомпрометировали, временный карантин обычно безопаснее, чем мгновенный отказ.

С бизнесом лучше заранее договориться о правилах: что уходит в карантин на проверку, а что отклоняется сразу (например, исполняемые вложения или явный фишинг). Тогда антиспам защищает, а не мешает работе.

Безопасность: TLS, доступ, журналы и базовые ограничения

Даже в закрытом контуре почта обычно общается с внешним миром: партнеры, госорганы, банки. Защита начинается с шифрования на транспорте и понятных правил доступа.

TLS: где включать и какие сертификаты брать

TLS нужен в двух местах: между серверами (SMTP) и между пользователем и сервером (IMAP/Submission). Для пользователей разумнее оставить только защищенные порты (IMAPS/Submission) и запретить вход по открытому IMAP/SMTP.

Сертификаты можно использовать от внутреннего УЦ (если все клиенты доверяют ему) или от публичного УЦ для внешних соединений. Важно, чтобы имя в сертификате совпадало с именем сервера (например, mail.company.kz). Иначе клиенты будут ругаться, а люди начнут искать обходные пути.

Доступ и защита от подбора паролей

Самое частое слабое место - учетные записи. Делайте пароли длинными, отключайте устаревшие методы входа и добавьте базовую защиту от перебора: временную блокировку по IP после серии неудачных попыток.

Чтобы сервер не превратился в источник спама, проверьте базовые ограничения: запрет открытого релея (отправка наружу только после аутентификации или из доверенных подсетей), лимиты на скорость и количество писем (отдельно для пользователей и сервисных учеток), ограничение размера письма и числа получателей, отдельные правила для массовых рассылок, разделение ролей (админ, оператор, аудит) без общих паролей.

Журналы, аудит и обновления в закрытом контуре

Логи нужны, чтобы быстро отвечать на вопросы: кто вошел и откуда, что отправил, почему письмо отклонено. Храните события аутентификации, отправки, отказов, действий антиспама и изменений конфигурации. Доступ к журналам дайте ограниченному кругу людей, а сами логи отправляйте в централизованное хранилище.

Обновления в закрытом контуре проще всего держать на понятном процессе: зеркало репозиториев, тестовый стенд, короткое окно внедрения и план отката.

Резервирование и бэкапы: что точно нужно продумать заранее

Почта ломается не «красиво». Часто все выглядит так: внезапно заканчивается место на диске, обновление прошло с ошибкой, умер накопитель или сервер просто не отвечает. Если заранее не определить, что именно вы восстанавливаете и за какое время, простой и потерянные письма становятся сюрпризом.

Бэкап должен позволять поднять сервис, а не только «сохранить файлы». Для Postfix + Dovecot + Rspamd обычно важно сохранить не только ящики, но и все, что делает доставку предсказуемой и безопасной: конфигурацию, ключи, правила.

Обычно резервируют:

• конфиги Postfix, Dovecot, Rspamd (включая списки и правила)
• секреты и ключи, особенно DKIM
• почтовые ящики пользователей (Maildir или используемое хранилище)
• служебные данные антиспама, если вы их используете для обучения
• очереди и spools, если критично не терять письма «в пути»

Чтобы не спорить в момент аварии, договоритесь про RPO и RTO простыми словами. RPO - сколько писем вы готовы потерять (например, максимум 15 минут). RTO - сколько времени у вас есть на восстановление (например, 2 часа до возобновления приема и отправки). Для закрытого контура со строгими регламентами эти цифры лучше закрепить письменно.

Бэкап без проверки восстановления почти всегда оказывается «условно рабочим». Раз в месяц делайте короткий тест: поднять сервис на отдельной машине, восстановить выборочно 1-2 ящика, убедиться, что TLS-сертификаты, DKIM и доступы на месте, и прием-отправка реально работают.

План переключения тоже лучше оформить заранее: кто принимает решение, кто меняет DNS или маршрутизацию внутри контура, кто проверяет очереди, диски и логи после восстановления, кто уведомляет пользователей и ИБ, как возвращаетесь на основной узел.

Контроль доставляемости: мониторинг, алерты и тесты

Почта часто ломается тихо: письма не пропадают, а зависают в очереди, уходят в карантин или получают временные отказы 4xx. Пользователи узнают об этом раньше админов и пишут: «не уходит».

Контроль доставляемости лучше строить как постоянный процесс.

Что измерять каждый день

Достаточно нескольких метрик и их динамики:

• размер и возраст очереди Postfix
• доля ошибок 4xx и 5xx по исходящим и входящим
• время доставки: от принятия Postfix до фактической отправки наружу
• доля писем, ушедших в карантин или спам по Rspamd
• отказы по политике (SPF/DKIM/DMARC) и причины

Пороги лучше задавать «по вашему нормальному дню». Например: очередь больше 200 писем или возраст старше 15 минут, 5xx больше 1-2% за час, рост карантина в 2 раза.

Как тестировать и поднимать тревогу

Алерт должен означать «нужно действовать», а не просто «что-то случилось». Рабочая практика - несколько тестовых писем по расписанию: одно наружу (в контрольный ящик), одно внутрь, одно с вложением. Если тест не дошел за N минут, уходит уведомление.

Для разборов полезно заранее договориться, какие факты вы всегда собираете по инциденту: message-id, время, отправитель, получатель, решение Rspamd, ответ удаленного сервера и путь письма по логам. Тогда на вопрос «почему не дошло» вы отвечаете за минуты.

Регулярность тоже помогает:

• раз в неделю: сверка очередей, карантина, топ ошибок
• раз в месяц: контроль DKIM-подписания, ревизия исключений, проверка плановой ротации ключей
• после изменений: внеплановые тестовые письма и наблюдение метрик первые 1-2 часа

Пошаговый план миграции: как переехать без потери писем

Миграция чаще ломается не на установке, а на мелочах: забытый системный отправитель, старый клиент с POP3, неподготовленный откат. Поэтому начните с инвентаризации и фиксированного плана по времени.

Соберите карту текущей системы: домены и ящики, алиасы и общие ящики, правила пересылки, лимиты на вложения, а также все системы, которые отправляют письма (принтеры, сервис-деск, 1С, мониторинг). Сохраните конфиги старого сервера и сделайте контрольный экспорт нескольких ящиков, чтобы было с чем сравнивать результат.

Дальше запускайте параллельно. Новый контур Postfix + Dovecot + Rspamd должен уметь принимать и отдавать почту хотя бы для тестового домена или небольшой группы. В закрытом контуре удобно выделить пилот из 10-20 пользователей и 1-2 системных отправителей и поднять новый сервер на отдельной ВМ или выделенном железе.

Обычно работает такая последовательность:

• поднять новый сервер и проверить входящую и исходящую на тестовых ящиках
• перенести письма партиями (по отделам), сохраняя структуру папок и права
• перенастроить клиентов (IMAP/SMTP, пароли, мобильные устройства)
• переключить MX в заранее выбранное окно и держать готовый откат
• зафиксировать изменения и заморозить правки на старом сервере

После переключения проверьте критичные сценарии: входящая и исходящая, большие вложения, рассылки, мобильные клиенты и отправка из всех внутренних систем. Практично держать старый сервер 48 часов в режиме только чтения и мониторить очереди, чтобы ни одно письмо не «застряло» незаметно.

Частые ошибки при переходе и как их избежать

Ошибки при миграции на Postfix + Dovecot + Rspamd обычно не про «сложный Linux», а про порядок действий и мелкие настройки. Они проявляются в первый рабочий день: часть писем не доходит, часть попадает в спам, внутренние сервисы перестают отправлять уведомления.

Ошибка 1: слишком жесткий DMARC с первого дня

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

Безопаснее идти по шагам: p=none и сбор отчетов, затем quarantine, и только потом reject, когда вы уверены, что SPF и DKIM покрывают все источники.

Ошибка 2: PTR и DNS сделаны «на глаз»

Неверный MX, отсутствующий PTR (reverse DNS) или несоответствие имени в HELO быстро ухудшают прием писем, особенно у крупных провайдеров. Проверьте, что A, MX, PTR и имя сервера согласованы, а TLS-сертификат выдан на то имя, которое реально видят получатели.

Ошибка 3: открытый релей и слабые лимиты

Один неверный параметр - и сервер превращается в точку рассылки спама. Это быстро убивает репутацию IP.

Перед запуском стоит сделать минимальный набор проверок:

• релей запрещен по умолчанию, разрешен только для авторизованных или доверенных сетей
• включены лимиты на соединения и скорость отправки
• разделены политики для внутренних подсетей и внешних клиентов
• сделан тест отправки «снаружи» без авторизации (должен быть отказ)

Ошибка 4: заканчивается диск или никто не смотрит очередь

Почта может «висеть» без явных жалоб: сервер принимает, но не доставляет. Причины часто простые: нет места на диске, разрослись логи, очередь Postfix не контролируется. Нужны алерты по диску, размеру очереди и числу отложенных сообщений.

Ошибка 5: забыли про внутренние системы

После переезда перестают уходить письма от принтеров, CRM, систем мониторинга и оповещений. Заранее соберите список таких источников, решите, как они будут отправлять (SMTP AUTH или доверенная подсеть), и проверьте, что их «From» не ломает SPF/DKIM/DMARC.

Короткий чеклист перед запуском и следующие шаги

Перед переключением MX полезно прогнать финальную проверку как будто вы внешний получатель, а не администратор внутри сети. Так быстрее ловятся мелкие ошибки, из-за которых письма «вроде отправляются», но часть уходит в спам или вообще не доходит.

Короткий чеклист перед запуском:

• DNS согласован: MX указывает куда нужно, SPF не слишком «широкий», DKIM подписывает исходящие, DMARC хотя бы в режиме мониторинга, PTR соответствует имени сервера.
• Безопасность проверена: TLS включен для SMTP и IMAP, сервер не является открытым релеем, есть защита от перебора паролей и базовые лимиты на подключения.
• Антиспам предсказуем: есть карантин, понятные правила для фишинга, минимальные белые списки для критичных адресов и систем.
• Отказоустойчивость подтверждена: бэкапы включены, тест восстановления уже выполнен хотя бы для одного ящика.
• Есть владелец процесса: кто утверждает изменения, кто принимает инциденты, где фиксируются решения, как часто смотрят отчеты по доставляемости.

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

Если требуется внедрение «под ключ» в закрытом контуре и подбор серверов под почтовые роли, это часто удобнее делать вместе с системным интегратором. Например, GSE.kz (gse.kz) занимается системной интеграцией и поставляет серверы для корпоративной инфраструктуры, что помогает сразу увязать требования по почте, железу и поддержке.