Как настроить веб-почту на своем сервере на Mox

Как настроить веб-почту на своем сервере на Mox

Иван Проскуряков
Автор статьи

Иван Проскуряков

РазработкаИнфраструктура

29 июня Яндекс закрывает протоколы IMAP, SMTP и POP3 для пользователей без платного тарифа. Похожие ограничения VK WorkMail ввел с 12 июня.

Что это значит на практике:

  • сторонние почтовые клиенты перестанут получать и отправлять почту;
  • боты, CRM и сайты, которые отправляют письма через SMTP, могут просто замолчать;
  • веб-интерфейс почтового сервиса останется, но автоматизация вокруг доменной почты сломается.

Можно заплатить за тариф и жить дальше. Иногда это самый дешевый вариант. Но если почта нужна не только как ящик в браузере, а как инфраструктура для сайта, админки, кодов входа и служебных уведомлений, я бы хотя бы посмотрел в сторону своего почтового сервера.

Один из самых адекватных вариантов сейчас — Mox. Это не связка из Postfix, Dovecot, OpenDKIM и Roundcube, которую надо собирать по кускам. Mox сразу дает SMTP, IMAP, webmail, админку, DKIM, SPF, DMARC, MTA-STS, TLS-RPT, автоконфигурацию клиентов и нормальные команды для проверки DNS.

Когда Mox подходит

Mox хорошо ложится на небольшой домен, где нужно:

  • принимать почту на адресах вида user@example.com;
  • отправлять служебные письма от сайта или админки;
  • читать почту через браузер;
  • подключать обычный почтовый клиент по IMAP и SMTP;
  • не держать отдельный зоопарк из Postfix, Dovecot, Roundcube и антиспам-компонентов.

Это не значит, что свой сервер всегда выгоднее тарифа. У своей почты есть операционка: DNS, репутация IP, бэкапы, обновления, логи, доставляемость. Но если VDS уже есть, домен свой, писем немного, а зависимость от чужого SMTP раздражает, Mox выглядит вполне разумно.

Что проверить до установки

До установки надо проверить не Mox, а саму возможность нормально держать почту на этом VDS.

Минимальный чеклист:

  • есть статический IPv4;
  • провайдер разрешает исходящий порт 25;
  • можно задать PTR / rDNS для IP;
  • входящие порты 25, 465, 587, 993 можно открыть;
  • 80 и 443 доступны для HTTPS, MTA-STS, autoconfig и webmail;
  • есть доступ к DNS домена;
  • IP не выглядит совсем убитым по почтовой репутации;
  • понятно, где будут бэкапы.

Для почты лучше использовать отдельный hostname:


mail.example.com

И у провайдера VDS прописать reverse DNS:


203.0.113.10 -> mail.example.com

PTR важен. Если сервер представляется как mail.example.com, а обратная запись ведет в случайное имя провайдера, крупные получатели будут смотреть на письма подозрительно.

Лучше отдельная машина, но можно рядом с сайтом

Самый простой вариант — отдельный VDS, где Mox забирает себе 80/443 и сам выпускает TLS-сертификаты через ACME.

Но в реальной жизни на сервере часто уже живет сайт за nginx. Тогда Mox можно ставить в режиме -existing-webserver: почтовые порты идут напрямую в Mox, а HTTP-часть проксируется через существующий nginx.

Схема получается такая:


internet

  -> 25/465/587/993 -> Mox

  -> 80/443 -> nginx -> Mox HTTP listeners

Это сложнее, чем чистый сервер под почту, но нормально работает, если не пытаться изобразить магию в nginx.

Установка Mox

Официальный quickstart у Mox простой. Сначала создаем отдельного пользователя:


useradd -m -d /home/mox mox

cd /home/mox

Дальше скачиваем бинарник или собираем из исходников. В документации Mox есть актуальная ссылка на сборку для linux/amd64, поэтому перед установкой лучше свериться с официальной страницей установки.

Для чистого почтового сервера команда будет примерно такой:


./mox quickstart -hostname mail.example.com admin@example.com mox

Если на 80/443 уже стоит nginx или другой webserver:


./mox quickstart -existing-webserver -hostname mail.example.com admin@example.com mox

Quickstart делает важные вещи:

  • создает mox.conf и domains.conf;
  • добавляет домен и первый аккаунт;
  • генерирует пароль админки и пароль почтового аккаунта;
  • печатает DNS-записи, которые надо добавить;
  • пишет команды для запуска systemd-сервиса;
  • сохраняет все инструкции в quickstart.log.

quickstart.log нельзя тащить в git, заметки, публичные статьи и чаты. Там есть пароли. Файл должен жить только на сервере с нормальными правами доступа.

Пароль админки и пароль ящика — разные вещи

В Mox есть минимум два разных секрета:

  • пароль админки Mox;
  • пароль почтового аккаунта для IMAP, SMTP и webmail.

Это не одно и то же. Пароль от SMTP не обязан пускать в админку, а пароль админки не надо использовать в приложениях.

Если пароль аккаунта нужно сменить:


cd /home/mox

./mox setaccountpassword accountname

Если нужно сменить пароль админки:


cd /home/mox

./mox setadminpassword

Пароли хранить в менеджере секретов или хотя бы в root-only файле на сервере. В репозитории должны быть только примеры env без реальных значений.

DNS-записи

Mox сам печатает DNS-записи, которые нужны конкретному домену. Это сильно лучше, чем копировать случайный шаблон из интернета.

В базовой схеме будут такие записи:


mail                 A      203.0.113.10

@                    MX     10 mail.example.com.

@                    TXT    "v=spf1 ip4:203.0.113.10 mx ~all"

mail                 TXT    "v=spf1 a -all"

selector._domainkey  TXT    "v=DKIM1; k=ed25519; p=..."

_dmarc               TXT    "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

_mta-sts             TXT    "v=STSv1; id=2026061801"

_smtp._tls           TXT    "v=TLSRPTv1; rua=mailto:tlsrpt@example.com"

DKIM-селекторы не надо придумывать руками. Берите то, что выдал Mox.

Проверки:


cd /home/mox

./mox config test

./mox config dnsrecords example.com

./mox config dnscheck example.com

Важный момент: не включайте MTA-STS в режиме enforce, если MX домена еще указывает на старого провайдера. Policy должна соответствовать реальному MX. Иначе часть отправителей может отказаться доставлять письма, потому что вы сами сказали им ходить на один mail host, а MX показывает другой.

Nginx и webmail

Если Mox работает за существующим nginx, нужно проксировать HTTP-часть Mox без переписывания важных путей.

Обычно наружу нужны:

  • https://mail.example.com/ — account UI и webmail;
  • https://mail.example.com/webmail/ — веб-почта;
  • https://mta-sts.example.com/.well-known/mta-sts.txt — MTA-STS policy;
  • https://autoconfig.example.com/... — автоконфигурация клиентов;
  • https://autodiscover.example.com/... — autodiscover.

Админку я бы не оставлял на стандартном публичном пути без дополнительной защиты. Если хотите вынести ее на нестандартный путь, path должен быть настроен в самом Mox, а nginx не должен переписывать его в другой URL.

Пример идеи:


AdminHTTP:

  Path: /private-admin/

  Forwarded: true

И nginx проксирует этот путь как есть:


location ^~ /private-admin/ {

    proxy_pass http://127.0.0.1:1080;

    proxy_set_header Host localhost;

    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

    proxy_set_header X-Forwarded-Proto $scheme;

}

Почему это важно: Mox использует path для login-token cookie. Если снаружи открыть /private-admin/, а внутри проксировать это как /admin/, можно получить ошибку входа из-за cookie path. Это неприятная мелочь, на которой легко потерять час.

После правок:


nginx -t

systemctl reload nginx

systemctl restart mox

SMTP для сайта и ботов

Для backend-приложения лучше завести отдельный адрес или хотя бы отдельный пароль. Настройки держим только в env:


SMTP_HOST=mail.example.com

SMTP_PORT=465

SMTP_SECURE=true

SMTP_USER=bot@example.com

SMTP_PASS=<secret>

MAIL_FROM=bot@example.com

Для порта 465 обычно используется TLS сразу, поэтому SMTP_SECURE=true.

Для 587 соединение начинается обычным SMTP и потом поднимает STARTTLS, поэтому в некоторых библиотеках, например в Nodemailer, secure=false для 587 — это нормально. Безопасность там дает STARTTLS, а не название boolean-поля.

Главное:

  • не коммитить .env;
  • не отправлять письма с личного пароля админки;
  • проверять nodemailer.verify() или аналог перед боевым переключением;
  • иметь понятный fallback, если SMTP временно недоступен.

IPv6 лучше не включать автоматически

Если у сервера есть IPv6, Mox может попытаться отправлять письма через него. Технически это нормально. Практически новый IPv6 без PTR, SPF, нормального hostname и репутации может получить отказ от крупных получателей.

Если вы не готовы отдельно настраивать IPv6-почту, стартуйте с IPv4:

  • не публикуйте AAAA для mail.example.com;
  • не добавляйте IPv6 в SPF;
  • настройте исходящий transport только через IPv4.

Идея конфига:


Transports:

  direct-ipv4:

    Direct:

      DisableIPv6: true

А для домена:


Routes:

  -

    FromDomain:

      - example.com

    Transport: direct-ipv4

После этого обязательно:


./mox config test

systemctl restart mox

Что проверить после запуска

Минимальный набор проверок:

  • systemctl status mox;
  • journalctl -u mox;
  • ss -ltnp показывает Mox на 25, 465, 587, 993;
  • openssl s_client -connect mail.example.com:465 -servername mail.example.com;
  • openssl s_client -starttls smtp -connect mail.example.com:587 -servername mail.example.com;
  • ./mox config dnscheck example.com;
  • отправка письма на Gmail, Яндекс, Mail.ru и свой ящик;
  • проверка заголовков письма: SPF, DKIM и DMARC должны проходить;
  • очередь Mox после теста не должна быть забита ошибками.

Если Gmail принял письмо, но положил его в спам, это еще не значит, что Mox настроен неправильно. Новый IP и новый почтовый поток часто требуют прогрева. Сначала смотрим на техническую часть: SPF pass, DKIM pass, DMARC pass, корректный PTR, TLS без ошибок. Потом уже занимаемся репутацией.

Бэкапы

Без бэкапов свой почтовый сервер превращается в азартную игру.

Минимально надо сохранять:

  • конфиги Mox;
  • данные аккаунтов и письма;
  • DKIM-ключи;
  • TLS-ключи, если они не восстанавливаются автоматически;
  • отдельную инструкцию восстановления.

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

Итог

Mox хорош тем, что убирает большую часть ручной сборки почтового стека. Webmail, SMTP, IMAP, DKIM, DMARC, MTA-STS и проверки DNS живут в одном понятном инструменте.

Но магии нет. Доставляемость все равно держится на базовых вещах: чистый IP, PTR, правильный DNS, TLS, аккуратная отправка, нормальные логи и бэкапы.

Если нужна просто почта в браузере для пары сотрудников, тариф у провайдера может быть дешевле по времени. Если почта завязана на сайт, админку и автоматические письма, свой Mox на VDS дает больше контроля и меньше зависимости от внезапных тарифных флажков.

Похожие статьи

Вам будет интересно