Stalwart: новый почтовый сервер на Rust

MAATRIX

Собрать почтовый сервер по классике — значит поставить Postfix для приёма и отправки, Dovecot для IMAP, Rspamd для антиспама, и вручную состыковать их конфигами и сокетами. Это работает десятилетиями, но требует разбираться в нескольких проектах сразу. Stalwart предлагает другой путь: один процесс на Rust, который делает и то, и другое. Разберём, что это такое на практике, чем он реально отличается от привычной связки и почему выбор нового проекта — это не только про удобство, но и про риск.

Что такое Stalwart и в чём его архитектурная идея

Stalwart — это почтовый сервер, в котором функции MTA (приём и отправка писем по SMTP) и функции почтового клиентского доступа (IMAP, JMAP, часто и ManageSieve для серверных фильтров) реализованы внутри одного приложения, написанного на Rust. Это принципиально другая архитектура по сравнению с традиционным подходом, где эти функции разносят по отдельным специализированным программам: Postfix занимается только транспортом писем, Dovecot — только доступом к ящикам по IMAP/POP3, а связывает их администратор через LMTP-сокеты, общие пути к maildir и отдельно настроенный антиспам-слой.

В Stalwart вместо трёх-четырёх проектов от разных команд — один бинарник и один файл конфигурации (обычно config.toml), который управляет и приёмом почты, и её хранением, и выдачей клиентам. Внутри есть собственный антиспам-модуль, поддержка DKIM/DMARC-проверки на приём и подпись на отправку, а также встроенная веб-панель администратора. Хранить письма и метаданные можно в нескольких видах бэкендов — начиная от встроенного эмбеддед-хранилища и заканчивая PostgreSQL, MySQL или S3-совместимым объектным хранилищем — конкретный набор поддерживаемых опций стоит сверять с актуальной документацией на момент установки, потому что в таких молодых проектах список бэкендов и их статус (стабильно/экспериментально) может меняться от релиза к релизу.

Отдельная деталь позиционирования — JMAP. Это более новый протокол доступа к почте (JSON поверх HTTP), который Stalwart поддерживает нативно наравне с IMAP. Идея JMAP — устранить исторические неудобства IMAP (медленная синхронизация, сложный протокол расширений), но на практике поддержка JMAP в клиентских приложениях пока ограничена: далеко не каждый почтовый клиент умеет с ним работать, и IMAP на сегодня остаётся практическим стандартом для большинства пользователей и приложений. Если у вас Outlook, дефолтная почта на телефоне или большинство десктопных клиентов — вы всё равно будете подключаться по IMAP, а JMAP пригодится, только если ваш клиент (или самописная интеграция) действительно его поддерживает.

Rust как выбор языка: что это реально даёт

Rust — компилируемый язык без сборщика мусора, с системой владения (ownership) и заимствования (borrowing), которая заставляет компилятор проверять корректность работы с памятью ещё на этапе сборки. Для инфраструктурного софта — того самого, что принимает недоверенный трафик из интернета круглые сутки — это значимое позиционирование: целый класс ошибок (use-after-free, гонки по данным, некоторые виды переполнения буфера), которые в C/C++ обнаруживаются через сегфолты в проде или через CVE спустя годы эксплуатации, в Rust-коде компилятор в большинстве случаев отклоняет ещё до сборки бинарника.

Важно разделить два разных утверждения. Первое — про безопасность памяти: это структурное свойство языка, а не маркетинг, и оно действительно снижает вероятность определённого класса уязвимостей в новом коде. Второе — про производительность: часто говорят, что Rust даёт производительность на уровне C/C++ без накладных расходов сборщика мусора, и это разумное общее позиционирование языка как такового. Но выведенное отсюда утверждение вида «значит, Stalwart быстрее Postfix и Dovecot на X%» — это не измеренный факт, а домысел. Мы не приводим таких цифр в этой статье и советую относиться скептически к любому источнику, который приводит конкретные проценты прироста без ссылки на воспроизводимую методику бенчмарка на сопоставимой нагрузке.

Postfix и Dovecot тоже написаны на C и эксплуатируются десятилетиями без катастрофических проблем с памятью в проде — их код прошёл через огромное количество аудитов, фаззинга и реального продакшн-трафика, и накопленная зрелость кода частично компенсирует отсутствие языковых гарантий Rust. Так что выбор языка — это один из факторов надёжности, а не единственный и не решающий сам по себе.

Postfix и Dovecot: чего стоит многолетняя проверенность

Прежде чем сравнивать с новым решением, стоит честно назвать то, что даёт возраст проекта. Postfix существует с конца девяностых, Dovecot — с середины двухтысячных. За эти годы:

• Накоплено огромное количество задокументированных «граблей» — типовых ошибок конфигурации, разборов логов, причин отказов доставки — которые уже кто-то прошёл и описал. Если у вас postfix: warning: relay access denied или письма падают в noqueue reject — с высокой вероятностью решение уже есть в открытом доступе, разобрано по строчкам лога.
• Сообщество огромно: форумы, списки рассылки, Stack Overflow, документация с примерами конфигураций под конкретные сценарии — от одного домена на VPS до multi-domain enterprise-инсталляций на тысячи ящиков.
• Есть проверенные временем конфигурации почти под любой сценарий: multi-domain, виртуальные пользователи в базе данных, интеграция с Rspamd, кластеризация Dovecot, репликация почтовых ящиков.
• Поведение при нештатных ситуациях (переполнение очереди, недоступность DNS, битые сертификаты) изучено вдоль и поперёк — известно, что именно ломается и как это чинить.

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

Установка и первый запуск Stalwart на VPS

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

# Обновление системы
apt update && apt upgrade -y

# Официальный установочный скрипт (проверьте содержимое перед запуском)
curl --proto '=https' --tlsv1.2 -sSf https://get.stalw.art | sh

После установки сервис обычно поднимается как systemd-юнит, а конфигурация лежит в одном TOML-файле:

systemctl status stalwart
systemctl enable --now stalwart

Базовые вещи, которые нужно настроить сразу же, вне зависимости от версии:

# Пример фрагмента конфигурации — сверяйте ключи с актуальной документацией
[server.listener."smtp"]
bind = ["0.0.0.0:25"]
protocol = "smtp"

[server.listener."imaps"]
bind = ["0.0.0.0:993"]
protocol = "imap"
tls.implicit = true

[certificate."default"]
cert = "%{file:/etc/stalwart/certs/fullchain.pem}%"
private-key = "%{file:/etc/stalwart/certs/privkey.pem}%"

Дальше — стандартный для любого почтового сервера набор шагов, который от выбора Stalwart не меняется:

1. Настроить обратную DNS-запись (PTR) на IP сервера — без неё крупные почтовые провайдеры будут заворачивать письма в спам вне зависимости от того, какой софт стоит на сервере.
2. Выпустить и подключить TLS-сертификат (Let's Encrypt через certbot или встроенный ACME-клиент, если Stalwart его поддерживает в вашей версии).
3. Настроить SPF, DKIM и DMARC — это записи в DNS вашего домена, они одинаково нужны и для Postfix, и для Stalwart, и для любого другого MTA.
4. Создать домены и почтовые ящики через встроенную веб-панель или CLI-утилиту, если она входит в поставку.
5. Проверить приём и отправку тестовыми письмами на несколько крупных провайдеров (Gmail, Яндекс, Outlook) и посмотреть заголовки Received/Authentication-Results на предмет корректного прохождения SPF/DKIM/DMARC.

Отдельно: если вы уже эксплуатируете почту на Postfix и Dovecot и рассматриваете переход, не переносите продакшн-домен на новый сервер одномоментно. Сначала поднимите Stalwart на тестовом поддомене или отдельном VPS, прогоните через него часть трафика, и только затем принимайте решение о полной миграции.

Компромисс: меньше интеграционной сложности, меньше и коллективного опыта

Если свести всё к сути, выбор между Stalwart и связкой Postfix+Dovecot — это выбор между двумя разными видами сложности, а не между «сложно» и «просто» в абсолютном смысле.

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

Как оценить зрелость проекта перед реальным выбором

Эта статья написана в конце августа 2026 года, и ситуация с любым активно развивающимся проектом за прошедшее с момента чтения время могла заметно измениться — как в лучшую сторону (проект мог заметно повзрослеть), так и остаться прежней. Поэтому перед тем, как ставить Stalwart на действительно важную почтовую инфраструктуру, стоит на момент собственного выбора самостоятельно проверить несколько вещей:

• Активность разработки. Посмотрите репозиторий проекта: как часто выходят релизы, закрываются ли открытые issue, как быстро реагируют на баг-репорты и сообщения о уязвимостях. Заброшенный или почти не развивающийся проект — это отдельный, более серьёзный риск, чем просто «молодой».
• Размер и активность сообщества. Есть ли живой чат/форум, отвечают ли там реальные пользователи (не только разработчики), сколько людей реально держат проект в проде, а не только пробуют в тестовом окружении.
• Реальные отзывы о продакшн-эксплуатации. Ищите не рекламные посты «мы перешли и все довольны», а конкретные истории с деталями: сколько доменов/ящиков, сколько месяцев или лет в проде, какие проблемы встретились и как их решали. Отзывы из тестовых или демо-развёртываний почти ничего не говорят о поведении под реальной длительной нагрузкой.
• Модель лицензирования и условия использования. У молодых инфраструктурных проектов условия лицензии иногда меняются по мере роста коммерческого интереса к проекту — стоит свериться с актуальной лицензией непосредственно перед принятием решения, а не полагаться на то, что было написано в статьях годом ранее.
• Наличие пути отхода. Проверьте, насколько просто экспортировать почтовые ящики и конфигурацию обратно в стандартные форматы (maildir, стандартные DNS-записи), если решение не приживётся — это снижает цену ошибки при выборе.

Ни один из этих пунктов нельзя разово проверить один раз и на этом успокоиться — зрелость проекта меняется со временем, и оценивать её нужно на момент реального решения, а не по статьям многолетней давности.

Как внедрять осторожно, если риск приемлем

Если после честной оценки вы готовы принять определённый риск ради упрощения архитектуры и интереса к новым технологиям — разумный путь не «поставить сразу на прод», а поэтапное внедрение:

1. Начните с некритичного тестового домена или поддомена — того, где падение почты на день не станет катастрофой для бизнеса.
2. Понаблюдайте за реальной стабильностью в своих условиях минимум несколько недель: доставляемость, поведение при пиковой нагрузке, поведение после обновлений версии, поведение при перезапуске сервиса и сервера целиком.
3. Держите отдельный резервный канал приёма почты на время наблюдения — например, второй MX-адрес с меньшим приоритетом на проверенном Postfix, куда почта уйдёт, если основной сервер временно недоступен.
4. Настройте мониторинг и алерты заранее — очередь писем, ошибки TLS, ошибки аутентификации, использование диска под хранилище писем — чтобы узнать о проблеме от системы мониторинга, а не от пользователей, которые не получили важное письмо.
5. Регулярно делайте резервные копии конфигурации и хранилища писем в переносимом формате, чтобы откат на другое решение при необходимости не превратился в отдельную катастрофу.
6. Переводите на новый сервер боевые домены постепенно, а не одним днём — сначала менее критичные, затем, по мере накопления собственного опыта эксплуатации именно в ваших условиях, более важные.

Такой подход не устраняет риск полностью — риск и есть цена того, что вы пробуете более новое и потенциально более удобное решение раньше, чем оно прошло проверку временем в масштабах всей индустрии. Но он снижает цену ошибки до управляемого уровня и даёт вам собственные данные о поведении Stalwart в ваших конкретных условиях, вместо того чтобы полагаться исключительно на чужие обещания или чужой опыт.

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