Когда офису подходит Postfix, а когда Mailcow

Для офиса до 50 сотрудников выбор зависит не от слова «бесплатно», а от того, кто отвечает за доставку, ящики, обновления и восстановление. Я выбираю Mailcow, когда нужна готовая связка и есть кому её обслуживать; Postfix отдельно — когда в компании готовы собрать и поддерживать остальные компоненты. Ниже — разбор без сказочной сметы.

Postfix и Mailcow: что именно сравниваем

Postfix отвечает за передачу почты по SMTP: принимает сообщения, ставит их в очередь и передаёт дальше. Пользовательский ящик, доступ по IMAP, веб-почта, антиспам и резервное копирование — отдельные задачи. В типовой самостоятельной сборке рядом с Postfix появляется Dovecot: он обслуживает IMAP и работу с почтовыми ящиками. Веб-клиент вроде SOGo нужен только если он действительно нужен сотрудникам. Это не мелочь в списке пакетов, а граница ответственности: если письмо не отправилось, разбирают очередь Postfix; если письмо доставлено, но не видно по IMAP, ищут уже в другом участке. Когда нужна корпоративная почта с сопровождением, я сначала уточняю, кто будет владеть каждым из этих участков. Для внешней доставки нужны рабочие DNS-записи и маршрут через сеть; для чтения старых писем — доступ к данным и индексам хранилища. Поэтому слово «почта» в заявке ещё не говорит, какой именно участок неисправен.

Mailcow собирает почтовые компоненты в общий управляемый стек на Docker: в нём есть Postfix, Dovecot, панель управления, веб-почта и другие службы. В штатной конфигурации за спам-фильтрацию отвечает Rspamd, а ClamAV можно использовать для проверки вложений; называть это SpamAssassin неправильно. В панели Mailcow можно сгенерировать DKIM-ключ и получить данные для DNS. SPF и DMARC публикуются в DNS домена, поэтому обещание «включить SPF флагом в main.cf» смешивает разные уровни настройки. Комплект экономит время на первичной стыковке, но не отменяет проверку DNS, сертификатов, доступа к серверу, обновлений и копий. Коробка избавляет от части сборки. Дежурство за неё всё равно не назначается автоматически. Вручную можно собрать ту же комбинацию, но тогда специалист сам следит за версиями и совместимостью, резервирует состояние и разбирает сбои между службами. В Mailcow часть решений связана проектом; домены, доступы и правила эксплуатации всё равно настраивает владелец.

• Postfix — SMTP-передача и очередь
• Dovecot — IMAP и почтовые ящики
• DNS — записи домена и почтовой аутентификации
• Mailcow — связанный стек компонентов

Сколько ресурсов нужно Mailcow

В старом варианте статьи фигурировали 2 vCPU, 4 ГБ памяти и 60 ГБ диска как универсальный минимум. Это неверно. В текущей официальной инструкции Mailcow указаны минимум 1 ГГц процессора, 6 ГиБ оперативной памяти плюс 1 ГиБ swap и 20 ГиБ диска без учёта писем. Это нижняя граница для запуска, а не готовый расчёт для любого офиса. Сам документ предупреждает, что ClamAV и полнотекстовый поиск могут заметно расходовать память. Там же приведён ориентир: при 15 телефонах с ActiveSync и примерно 50 одновременных IMAP-подключениях стоит планировать 16 ГиБ памяти. Это не норматив для каждого офиса, а пример нагрузки из документации Mailcow. Оговорка «без учёта писем» здесь принципиальна: архив сотрудников занимает отдельное место, а индексы и дополнительные подключения меняют профиль нагрузки. Swap помогает пережить отдельные пики, но не заменяет расчёт памяти под постоянную работу.

Считать нужно не только число заведённых адресов. Важны объём старого архива, одновременные подключения в рабочее утро, мобильная синхронизация, размер вложений, индексация, срок хранения и запас на рост. Диск выбирают под письма, индексы, журналы и резервные копии, причём копия на том же заполненном томе проблему не решает. У отдельного Postfix нагрузка и требования могут быть ниже, потому что его роль уже; сравнивать его минимальную установку с полной групповой почтой некорректно. Тезис «Postfix живёт на 512 МБ, значит вся почта будет работать» не описывает ни хранение, ни IMAP, ни фильтрацию, ни пики подключений. Перед закупкой я измеряю объём и режим работы, затем закладываю запас и проверяю его на тестовой конфигурации. Я отдельно уточняю, какой объём писем хранить, сколько устройств синхронизируется одновременно и нужна ли индексация старых папок. Потом проверяю фактическое потребление на пилоте и оставляю место для роста. Одна цифра «на 50 ящиков» этого не заменяет.

• Mailcow: 6 ГиБ RAM и 1 ГиБ swap минимум
• Диск: 20 ГиБ без почтовых данных
• Объём писем считается отдельно
• Ресурсы уточняются по нагрузке

Что безопаснее: готовый стек или своя сборка

Я не присваиваю Mailcow автоматическую победу в безопасности. Готовый стек уменьшает число ручных стыков между компонентами, но администратор всё равно отвечает за доступ к панели, обновления, DNS, сертификаты и правила сети. Mailcow поддерживает двухфакторную защиту панели, фильтрует спам через Rspamd и может проверять вложения ClamAV. Это полезные штатные возможности, а не гарантия, что вредоносное письмо не пройдёт или что учётную запись не украдут. Защиту нужно настроить, включить там, где она нужна, и проверять на практике. TLS защищает соединение на конкретном участке; он не означает, что письмо зашифровано от отправителя до получателя и недоступно владельцу сервера. В первую очередь я защищаю учётную запись администратора: уникальный пароль, MFA и ограниченный круг пользователей панели. Далее проверяю сертификат снаружи, тестирую входящие и исходящие сообщения и убеждаюсь, что нежелательные вложения обрабатываются согласно выбранной политике.

Самостоятельная сборка даёт больше свободы, но вместе с ней передаёт команде задачу следить за всеми компонентами. На Postfix отдельно настраивают правила приёма и передачи, а доступ к ящикам, спам-фильтрацию, сертификаты, защиту от перебора паролей и журналирование обеспечивают выбранные инструменты. На Mailcow меньше решений приходится склеивать руками, зато нужно понимать его Docker-стек и следить за хостом: контейнеры не превращают уязвимую операционную систему в безопасную. Обновление Mailcow запускают штатным скриптом ./update.sh; это управляемая операция, для которой сначала готовят резервную копию и окно работ. Формулировка «всё обновляется само, можно забыть» документацией не подтверждается. Для любого варианта я требую тест восстановления: зелёный значок «копирование прошло» ещё не доказывает, что письма можно вернуть. Перед обновлением читают заметки к выпуску, фиксируют текущее состояние и убеждаются, что есть свежая копия и понятный откат. После него проверяют отправку, получение, IMAP, сертификаты, фильтрацию и журналы. Это обычное обслуживание, а не признак того, что Mailcow особенно опасен.

Как сравнить стоимость владения без выдуманных смет

В условной сети «Омега-Логистик» я сравниваю не мифические 500 рублей за сервер с 20 тысячами за администратора, а две полные модели работ. У варианта на Postfix есть стоимость размещения, часы на сборку и поддержку каждого компонента, мониторинг очереди, резервные копии и время на разбор инцидентов. У Mailcow есть размещение с подходящими ресурсами, контроль обновлений, бэкапы, наблюдение за службами и работа специалиста. Я не называю «Омега-Логистик» реальным проектом и не приписываю ей выполненный переезд: это условный пример, на котором виден состав расчёта. Подставьте свои цены размещения и внутреннюю ставку — и сравнивайте одинаковый объём услуг. В условном сценарии я выписываю одинаковый перечень функций для обоих вариантов: адреса, хранение, доступ с устройств, фильтрация, восстановление и реакция на сбой. Иначе один расчёт включает труд специалиста, а второй почему-то считает его бесплатным.

Формула скучная, зато честная: инфраструктура + часы администратора + миграция + резервное хранилище + плановое обслуживание. В подсчёте для Postfix нужно учесть не только первоначальную настройку, но и ответственность за раздельные компоненты; для Mailcow — ресурсы полного стека и контроль его обновлений. Лицензия с открытым исходным кодом не делает эксплуатацию бесплатной, а готовая панель не означает, что сопровождение исчезнет. Я бы запросил у подрядчика список включённых работ: кто следит за доставкой, кто проверяет копии, как согласуются обновления и кто принимает заявку при сбое. Для другого сравнения готовых платформ есть отдельный разбор Mailcow и iRedMail; здесь вопрос уже: собирать почтовые роли самостоятельно или брать связанный стек. Практический вопрос для оценки — сколько часов и каких именно работ включено в договор, а не сколько строк в смете занимает аренда. Попросите указать регулярные проверки, резервное хранилище, порядок обновления и границы ответственности; затем сопоставьте это с работой внутреннего сотрудника.

• Инфраструктура и запас ресурсов
• Часы поддержки и обновлений
• Миграция и проверка результата
• Хранилище резервных копий
• Реакция на инциденты

Как перенести почту и проверить резервную копию

В миграции я сначала фиксирую объём ящиков, папки, календари, адресные книги, алиасы, правила доставки и способ входа сотрудников. Затем проверяю доступ к старому серверу и целевой системе, переношу пробную группу, сверяю сообщения и структуру папок, а после исправления замечаний синхронизирую новые письма. Переключение DNS планируют так, чтобы не терять входящую почту на время обновления записей; одной смены MX недостаточно, если часть клиентов ещё отправляет через прежнюю систему. Продолжительность зависит от размера архивов, скорости каналов, доступа к источнику и готовности пользователей. Поэтому обещание «весь офис переедет за 48 часов» без этих вводных — не план, а гадание. Для подготовки полезен тестовый стенд перед переносом почты, а после переключения нужна сверка после переноса. Перед пробным переносом согласуйте с сотрудниками, что именно проверять: вход на компьютере и телефоне, отправку, приём, вложения, папки и общие календари, если они используются. Так замечания появятся до переключения основного потока, когда исправить их проще.

В резервную копию входят не только письма: нужны конфигурация, данные сервисов и ключи, без которых зашифрованное содержимое не прочитать. В документации Mailcow прямо сказано, что почта хранится с шифрованием, а ключевая пара находится в томе crypt-vol-1; этот том необходимо копировать вместе с остальными данными. Копия должна находиться отдельно от основного сервера, иметь ограниченный доступ и проходить контрольное восстановление в изолированной среде. Я проверяю не факт создания архива, а открываются ли ящики, видны ли письма и папки, работают ли вход и отправка. Отдельная инструкция о том, как проверить восстановление почты, помогает составить такой сценарий. После приёмки фиксирую владельца расписания копирования, место хранения и порядок отката. Отдельно проверьте права доступа к копиям и ключам: они должны быть доступны для восстановления, но не всем пользователям сервера. Запишите дату последней успешной проверки и ответственного за повторение процедуры. Иначе резервирование со временем незаметно превращается в ритуал без результата.

• Инвентаризация ящиков и правил
• Пробный перенос и сверка
• План переключения и отката
• Отдельное хранилище копий
• Контрольное восстановление

Частые вопросы