Опыт создания собственного почтового сервера
Ваш домашний сервер (homelab) уже успешно заменил многие облачные сервисы: от Google Drive и Apple iCloud до Bitwarden Premium и NextDNS, которые были заменены бесплатными альтернативами. Окрыленный успехом, я решил перейти к более сложной задаче — заменить Google Workspace на собственный почтовый сервер. Однако результат оказался далек от ожиданий, а процесс настройки превратился в полноценный проект.
Первые шаги и выбор ПО
Изначально у меня были все необходимые условия: качественный интернет, публичный IP-адрес и открытый 25-й порт, который я проверил с помощью netcat. Я предполагал, что почтовый сервер на базе Debian будет работать так же стабильно, как и другие мои сервисы.
Изучив тематические форумы, я обратил внимание на Mailcow. Однако, ознакомившись с документацией, я отказался от этого решения: системные требования Mailcow предусматривали минимум 6 ГБ оперативной памяти плюс 1 ГБ swap. Мой сервер располагал 12 ГБ памяти, на которых уже работало более 20 различных сервисов, поэтому такой объем ресурсов был избыточен. В итоге я выбрал Stalwart — почтовый и коммуникационный сервер с открытым исходным кодом, написанный на языке Rust. Согласно документации, для обслуживания 5–10 пользователей этому решению достаточно всего 1 ГБ оперативной памяти.
Проблема обратного DNS (PTR)
После развертывания Stalwart и запуска мастера настройки я столкнулся с требованием наличия PTR-записи (обратного DNS). Этот параметр связывает IP-адрес с доменным именем и необходим почтовым провайдерам, таким как Gmail и Outlook, для проверки легитимности сервера. При использовании домашнего интернета PTR-записью управляет провайдер. Проверка через nslookup показала отсутствие записи, а запрос к провайдеру на ее создание был отклонен. Так мой план по хостингу почты на домашнем оборудовании оказался под угрозой.
Перенос на VPS от Hetzner
Я решил арендовать недорогой VPS. Выбор пал на Hetzner, где новый сервер был готов за несколько минут. Однако и здесь возникли сложности: по умолчанию Hetzner блокирует исходящий трафик на портах 25 и 465 для борьбы со спамерами. Чтобы их открыть, пришлось отправить запрос в службу поддержки. Благодаря тому, что мой аккаунт был зарегистрирован давно и имел историю оплаченных счетов, порты разблокировали за считанные минуты.
Затем последовала настройка: развертывание Stalwart через Docker Compose, установка сертификата Let’s Encrypt (с использованием acme.sh и scoped-токена Cloudflare, так как я управлял DNS вручную), добавление семи DNS-записей, четырех правил брандмауэра, одного почтового ящика и псевдонима postmaster. Финансово это было выгодно: при стоимости использования Google Workspace в $8.40 за пользователя в месяц, VPS обходился в $4.99.
Проблемы с доставкой писем
Stalwart — это решение, поддерживающее протоколы SMTP, IMAP, POP3, JMAP, CalDAV, CardDAV и WebDAV, а его Community Edition распространяется бесплатно. Несмотря на успешную настройку и прохождение всех технических проверок, я столкнулся с проблемами доставки. Отправив тестовые письма с нового адреса в Thunderbird на аккаунты Gmail, Outlook и Proton, я получил разный результат: Outlook и Proton приняли письма, а Google пометил их как спам.
Анализ доставляемости и подводные камни самостоятельного хостинга почты
При первой попытке отправки письма Google пометил его как спам, тогда как Outlook и Proton Mail сочли сообщение легитимным и доставили его во «Входящие». Поскольку два из трех крупнейших провайдеров восприняли письмо как нормальное, я отметил его в Gmail как «Не спам» и перешел к тесту на сбой и восстановление. Однако после завершения этого теста при отправке очередного письма на мой адрес в Workspace оно снова попало в спам. Неудачная попытка доставки заставила меня провести более глубокий анализ.
Я начал с проверки заголовков полученных писем у каждого провайдера. Gmail и Proton успешно валидировали RSA DKIM-подпись, однако их работа с дополнительной подписью Ed25519 различалась. Этого было недостаточно для объяснения спам-классификации в Gmail, так как RSA-подпись была действительной, а проверка DMARC проходила успешно. В то же время Outlook прошел те же проверки плюс композитную аутентификацию Microsoft (compauth=pass), проигнорировав Ed25519 как неподдерживаемый алгоритм подписи. Это открытие заставило меня копать глубже, так как Gmail и Proton не справились с Ed25519, но только один из них пометил письмо как спам.
Проверка IP-адреса моего VPS через MXToolbox не выявила попаданий в публичные черные списки, включая Spamhaus ZEN. Это исключило проблему с публичными блэклистами, но не подтвердило наличие у IP хорошей репутации в Gmail. Google использует собственные системы репутации отправителей, поэтому новый домен или IP-адрес VPS с низким объемом трафика может практически не иметь истории доверия. В конечном итоге я так и не выяснил, почему Gmail пометил письмо как спам, а поскольку Google не предоставляет никакой дополнительной информации, дальнейшее расследование стало бессмысленным.
Эксплуатационные трудности и повседневное использование
Ситуация с доставляемостью через несколько месяцев улучшилась, но возникли другие проблемы, заставившие меня отказаться от идеи самостоятельного хостинга почтового сервера. Настройка оказалась легкой частью, тогда как поддержание работоспособности — настоящей работой. Восстановление данных сработало, но привело к потере одного письма. Помимо доставляемости, возник ряд других сложностей.
Первым и самым важным аспектом стало повседневное использование. В случае с Gmail, Outlook или другими провайдерами мы используем их приложения или веб-клиенты. У Stalwart (в версии 0.16.24, которую я использовал) ничего подобного нет. Не существует традиционного способа войти в почту через веб-интерфейс или специальное приложение. Мне пришлось использовать сторонние клиенты, например Thunderbird, вводя данные IMAP-сервера, адрес электронной почты и пароль. После входа система работает, но вы не можете просто открыть браузер на чужом ноутбуке и отправить письмо — вам обязательно потребуется стороннее ПО с поддержкой IMAP. Существуют сторонние веб-клиенты, но их использование — это новая зависимость, а использование хостинговых решений обесценивает идею самостоятельного управления.
Поддержание сервера и экономический фактор
Хостинг сервиса — это не главное, основная задача заключается в обеспечении его непрерывной работы 24/7. Если сервер недоступен даже короткое время, входящие письма могут быть потеряны. Я провел тест: намеренно отключил Docker-контейнер и отправил письмо на свой адрес. Письмо было доставлено, но только через 20–25 минут после того, как контейнер снова запустился — успех зависел от политики повторных попыток отправителя. Также выяснилось, что при восстановлении из резервной копии, которая оказалась старше текущего состояния, новые сообщения были стерты, а почтовый клиент удалил их при следующей синхронизации.
Что касается расходов: я уже пользовался платным Google Workspace, поэтому VPS за $5 казался дешевым вариантом, но для того, кто привык к бесплатному Gmail, ежемесячный счет за VPS стал бы дополнительным расходом. Скриншоты в статье взяты с отдельного тестового почтового сервера, развернутого специально для этого материала, а не с того, что использовался для долгосрочного хостинга.
Некоторые проекты учат вас создавать что-то новое, другие — тому, что вы не хотите этим владеть. Столкнувшись с проблемами доставляемости, отсутствием веб-клиента, ответственностью за круглосуточное управление сервером и необходимостью обслуживания, я решил остаться с платным Google Workspace и принять дополнительные ежемесячные расходы. По крайней мере, платя немного больше, я избавляю себя от бремени эксплуатации почты. Stalwart сам по себе не является проблемой — это надежный и простой в развертывании почтовый сервер. Если вы готовы взять на себя всю ответственность за его содержание, на него определенно стоит обратить внимание.
Технические детали и нюансы работы с почтовыми протоколами
Важно учитывать, что Stalwart — это не просто SMTP-сервер, а полноценное решение для совместной работы, написанное на языке Rust. Оно предлагает широкий спектр возможностей: помимо стандартных протоколов SMTP, IMAP и POP3, сервер поддерживает JMAP, а также протоколы для синхронизации календарей и контактов — CalDAV, CardDAV и WebDAV. Администрирование осуществляется через встроенный веб-интерфейс, который значительно упрощает управление учетными записями и конфигурацией.
Тем не менее, при глубоком техническом анализе работы сервера выяснились интересные особенности взаимодействия с крупными провайдерами:
- Аутентификация и подписи: Хотя сервер корректно генерировал RSA DKIM-подписи, возникали вопросы к поддержке алгоритма Ed25519. При тестировании выяснилось, что Microsoft Outlook успешно проходит проверки безопасности, включая фирменную композитную аутентификацию (compauth=pass), при этом игнорируя Ed25519 как неподдерживаемый стандарт, что, как ни странно, не мешало доставке писем.
- Репутация IP-адреса: Даже при отсутствии в глобальных «черных списках» (таких как Spamhaus ZEN), отсутствие истории у нового VPS-адреса создает критические сложности. Google использует собственные, закрытые системы репутации отправителей, и для них новый домен или свежевыделенный IP-адрес по умолчанию не вызывает доверия.
Эксплуатационные риски: что значит «поддерживать сервер»
Главный вывод, к которому я пришел за время эксперимента, заключается в том, что развертывание (deploy) — это лишь вершина айсберга. Поддержание почтовой инфраструктуры — это процесс, требующий безотказной работы 24/7. В отличие от других self-hosted сервисов, здесь цена простоя крайне высока.
«Хостинг сервиса — это не великое достижение; главная задача — поддерживать его работоспособность. Почтовый сервер обязан работать круглосуточно: если он недоступен даже в течение нескольких минут, входящие сообщения могут либо потеряться, либо вызвать задержки, зависящие исключительно от политики повторных попыток на стороне отправителя».
В ходе моих тестов на устойчивость к сбоям я намеренно останавливал Docker-контейнер со Stalwart. Хотя отправители обычно совершают повторные попытки (в моем случае письмо пришло через 20-25 минут после подъема контейнера), полагаться на это в бизнес-переписке или при использовании личной почты нельзя. Кроме того, возникла серьезная проблема с процессом восстановления из резервных копий: поскольку резервная копия была сделана чуть раньше момента сбоя, при «откате» системы все новые письма, полученные сервером до сбоя, были безвозвратно удалены, а почтовые клиенты (Thunderbird), синхронизируясь, просто удалили их из своих локальных кэшей.
Отсутствие экосистемы и клиентской части
Еще одним барьером стало отсутствие полноценного «родного» веб-клиента. В версии 0.16.24, которую я использовал, работа с почтой была возможна только через сторонние программы. Это создает неудобство, когда нужно быстро проверить почту с чужого устройства или через браузер: вам необходимо либо настраивать сторонний IMAP-клиент, либо поднимать еще один сервис (веб-почту), что добавляет ненужную зависимость к и без того сложной инфраструктуре. По сути, отказ от Google Workspace в пользу самостоятельного хостинга перекладывает все риски доставки и обеспечения сохранности данных с плеч корпорации на ваши собственные, что оправдано только в том случае, если вы осознанно стремитесь к полному контролю, а не к экономии средств.
