Mailu: почтовый сервер в контейнерах

MAATRIX

Разворачивать свою почту руками — это не «поставить Postfix», а собрать и правильно подружить друг с другом полдюжины разных сервисов, каждый со своей логикой и конфигом. Если вы делаете это впервые, легко упустить деталь — и письма либо не доходят, либо падают в спам. Mailu решает именно эту проблему: упаковывает уже настроенный и интегрированный почтовый стек в Docker-контейнеры, которые поднимаются одной командой.

Проблема: почта — это не один сервис, а несколько

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

• Приём и отправка почты (MTA) — обычно Postfix, слушает SMTP, решает, кому доверять письма и кому отдавать дальше.
• Хранение и доступ по IMAP/POP3 — Dovecot, хранит письма на диске и отдаёт их почтовым клиентам.
• Антиспам-фильтрация — Rspamd или SpamAssassin, оценивает каждое письмо по десяткам признаков и решает, спам это или нет.
• Антивирус — опционально, но для входящей почты организации почти обязателен.
• DKIM-подпись исходящих писем — отдельный демон, который подписывает каждое письмо приватным ключом, чтобы получатель мог проверить подлинность отправителя.
• Веб-интерфейс (webmail) — Roundcube, SnappyMail или аналог, чтобы читать почту из браузера.

Каждый из этих компонентов не просто ставится отдельно — он должен *правильно разговаривать* с остальными: Postfix должен знать, куда передавать письма на проверку антиспамом и куда — на подпись DKIM, Dovecot должен быть доступен Postfix для LDA-доставки и одновременно webmail — для IMAP, у всех сервисов должны совпадать пути к почтовым ящикам и права доступа. Ошибка в любом из этих стыков — это не «сервис не запустился», а «письма тихо теряются» или «уходят в спам», что искать намного дольше.

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

Что такое Mailu и как он снимает эту проблему

Mailu — открытый проект, который берёт весь этот набор компонентов, уже настроенных для совместной работы, и упаковывает каждый в свой Docker-контейнер: front (nginx, единая точка входа для SMTP/IMAP/HTTPS), postfix (MTA), dovecot (IMAP/POP3), rspamd (антиспам и DKIM), webmail (Roundcube или SnappyMail на выбор), admin (веб-панель управления доменами и ящиками), webdav (Radicale — календари и контакты), resolver (свой DNS-резолвер для проверок), redis (общее состояние между контейнерами) и опционально clamav (антивирус, требователен к памяти).

Ключевая идея: разработчики Mailu уже решили все вопросы совместимости за вас. Контейнеры общаются друг с другом через внутреннюю Docker-сеть по заранее прописанным адресам и портам, конфиги согласованы между собой, а единственное, что от вас требуется, — заполнить несколько переменных окружения (домен, имя хоста, почта администратора) и поднять всё одной командой docker compose up -d. Официальный сайт Mailu даже предлагает веб-мастер (setup wizard), который по нескольким вопросам генерирует готовые docker-compose.yml и файл переменных под конкретную версию — это снимает и вопрос «какие переменные вообще нужны в этой версии».

Структура docker-compose.yml и ключевые переменные

Базовый файл переменных окружения (обычно mailu.env, подключается через env_file в docker-compose) задаёт параметры, общие для всех контейнеров:

# Домен, под которым работает почта
DOMAIN=example.com

# Полное имя почтового сервера, должно совпадать с A- и PTR-записью
HOSTNAMES=mail.example.com

# Почта администратора и часовой пояс
POSTMASTER=admin
TZ=Europe/Moscow

# Секретный ключ для шифрования сессий — сгенерируйте случайную строку
SECRET_KEY=замените-на-случайную-строку

# Подсеть для внутренней Docker-сети контейнеров Mailu
SUBNET=192.168.203.0/24

# Способ получения TLS-сертификата
TLS_FLAVOR=letsencrypt

# Какие компоненты включить
WEBMAIL=roundcube
WEBDAV=radicale
ANTIVIRUS=

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

services:
  front:
    image: ghcr.io/mailu/nginx:2024.06
    restart: always
    env_file: mailu.env
    ports:
      - "25:25"
      - "465:465"
      - "587:587"
      - "993:993"
      - "443:443"
    volumes:
      - "certs:/certs"
    networks:
      - default

  admin:
    image: ghcr.io/mailu/admin:2024.06
    restart: always
    env_file: mailu.env
    volumes:
      - "data:/data"
      - "dkim:/dkim"

  postfix:
    image: ghcr.io/mailu/postfix:2024.06
    restart: always
    env_file: mailu.env
    volumes:
      - "postfixdata:/queue"

  dovecot:
    image: ghcr.io/mailu/dovecot:2024.06
    restart: always
    env_file: mailu.env
    volumes:
      - "maildata:/mail"

  rspamd:
    image: ghcr.io/mailu/rspamd:2024.06
    restart: always
    env_file: mailu.env
    volumes:
      - "filterdata:/var/lib/rspamd"

  webmail:
    image: ghcr.io/mailu/roundcube:2024.06
    restart: always
    env_file: mailu.env

volumes:
  certs:
  data:
  dkim:
  postfixdata:
  maildata:
  filterdata:

Точные имена переменных и образов могут немного отличаться между версиями Mailu — перед реальным развёртыванием сверьтесь с документацией под конкретную версию или сгенерируйте файлы через официальный setup wizard, а не переносите этот пример один в один в продакшен.

DNS-записи: без них контейнеры бесполезны

Здесь важно понимать границу ответственности: Mailu решает вопрос *настройки почтовых сервисов*, но не решает вопрос *доверия к вашему домену* со стороны других почтовых серверов. Это делают DNS-записи, и их нужно выставить до того, как почта реально заработает:

• MX-запись — говорит остальному интернету, куда доставлять почту для вашего домена: example.com. MX 10 mail.example.com.
• A-запись для mail.example.com, указывающая на IP вашего сервера, и обязательно PTR-запись (обратный DNS) с этого IP обратно на mail.example.com — без PTR многие почтовые серверы будут считать вашу почту подозрительной вне зависимости от того, насколько правильно настроен сам Mailu.
• SPF-запись — список серверов, которым разрешено отправлять почту от имени вашего домена: example.com. TXT "v=spf1 mx ~all".
• DKIM-запись — публичный ключ для проверки подписи писем. Mailu генерирует пару ключей автоматически при первом запуске и показывает готовую TXT-запись в админ-панели — её нужно просто скопировать в DNS-зону домена.
• DMARC-запись (опционально, но настоятельно рекомендуется) — политика, что делать с письмами, не прошедшими SPF/DKIM: _dmarc.example.com. TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com".

Если разбираетесь в SPF/DKIM/DMARC впервые, стоит отдельно прочитать про настройку SPF, DKIM и DMARC — Mailu берёт на себя техническую генерацию ключей и подпись писем, но смысл каждой записи и последствия неправильной политики DMARC полезно понимать самостоятельно, а не вслепую копировать значения из панели.

Первый запуск и админ-панель

После docker compose up -d и готовности DNS заходите в веб-панель Mailu (обычно https://mail.example.com/admin/) под учёткой, которую задали при генерации конфигурации. Первым делом создаёте домен (если он ещё не создан автоматически из DOMAIN), затем — почтовые ящики и алиасы прямо через интерфейс, без единой команды в консоли. Панель показывает статус DKIM, дает готовые значения DNS-записей для копирования и позволяет включать/выключать антиспам-политики, квоты и переадресацию на уровне отдельного ящика.

Это тот момент, где преимущество готового пакета особенно заметно: те же операции при ручной сборке — это правки в БД или конфиг-файлах Postfix/Dovecot (virtual-домены, virtual-mailbox-maps и подобные таблицы), а не пара кликов в браузере.

Готовый пакет против ручной сборки: честный компромисс

Здесь стоит сказать прямо, а не только хвалить готовое решение.

Что вы получаете с Mailu:

• Значительно более быстрый старт — от нуля до работающей почты обычно часы, а не дни.
• Меньше риска ошибки конфигурации на старте: все компоненты уже интегрированы и протестированы разработчиками проекта вместе, а не собраны вами по разным мануалам, которые могли быть написаны под разные версии.
• Единая точка обновления и мониторинга — все сервисы обновляются вместе, логи можно смотреть через docker compose logs.

Чего вы не получаете (или получаете сложнее), чем при ручной сборке:

• Меньше гибкости для нестандартной кастомизации конкретного компонента. Если вам нужен специфический плагин для Dovecot, нестандартное правило Rspamd за пределами того, что позволяет панель Mailu, или редкая схема хранения писем — упереться в границы контейнеризованной сборки проще, чем при самостоятельной установке пакетов из репозитория.
• Контейнеры Mailu — это уже собранные образы с зашитыми версиями пакетов внутри; поменять, скажем, версию Dovecot независимо от остального стека — не тот сценарий, для которого проект спроектирован.
• Общий объём того, что крутится на сервере, выше, чем у голого Postfix с минимальным набором функций — для сервера, который отправляет только транзакционные письма без ящиков и вебмейла, Mailu избыточен.

Для типичного сценария — своя почта для организации или личного использования без экзотических требований к какому-то конкретному компоненту — это разумный практичный компромисс: вы отдаёте немного гибкости в узких местах и получаете рабочий, правильно интегрированный сервер за разумное время. Если знакомы со сборкой почты вручную, полезно почитать про ручную настройку Postfix, чтобы предметно сравнить объём работы, а также про выбор между Postfix и Mailcow — логика того же выбора применима и к Mailu как ещё одному готовому стеку.

Обновления: не оставляйте стек замороженным

Как и у любого готового контейнеризованного стека, у Mailu регулярно выходят новые версии образов — с исправлениями безопасности, обновлёнными правилами антиспама и совместимостью с новыми версиями TLS и почтовых протоколов. Здесь есть особенность, которую стоит понимать заранее: почтовый сервер — это система, обращённая наружу, в открытый интернет, и её компонент антиспама и приёма писем — ровно то место, где своевременные обновления важнее всего.

Практический подход:

• Следите за релизами Mailu (страница релизов на GitHub проекта) и не откладывайте обновление на месяцы — особенно патчи, которые касаются Rspamd или Postfix.
• Перед обновлением делайте бэкап томов с данными (data, maildata, dkim и остальные volumes из compose-файла) — откат к рабочей версии должен быть простым, если что-то пойдёт не так.
• Обновление обычно сводится к смене тега версии образа во всех сервисах compose-файла и docker compose pull && docker compose up -d — но перед этим стоит свериться с changelog конкретной версии на предмет изменений в переменных окружения или структуре конфигов.
• Не держите замороженную версию годами «потому что работает» — почтовый сервер без обновлений постепенно теряет актуальность антиспам-правил и рискует накопить неисправленные уязвимости именно в той части, которая напрямую открыта наружу.

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