Mail.ru попросил 80 000 ₽ за почту

Корпоративной почтой Mail.ru мы пользовались много лет. Она была бесплатной, работала на нашем домене, имела API и общие рабочие папки. Для небольшой компании — то, что нужно: завел сотрудников и работаешь.

Остальные инструменты тем временем появлялись сами по себе. Рабочие чаты жили в Telegram, там же проходила часть созвонов. Файлами обменивались через Google: загрузил, открыл доступ, кинул ссылку в чат. Код, задачи, документация и пароли находились каждый в своем сервисе, часто со своей учетной записью.

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

Потом бесплатный тариф закончился. За первый год мы заплатили около 60 тысяч рублей. Продление на следующий год для 32 пользователей стоило уже 79 552 рубля.

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

Нас подтолкнула не только цена. В 2026 году Яндекс сообщил пользователям доменной почты, что IMAP, SMTP и POP3 будут доступны только на платном тарифе. Если почта подключена к Outlook, Thunderbird, боту или системе уведомлений, то после смены условий все это либо перестает работать, либо требует оплаты.

Следом похожая история произошла с Mail.ru: доступ через IMAP и SMTP привязали к платному Mail Space. У части пользователей отключились пароли приложений.

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

Ждать следующего письма о новых тарифах не хотелось. Решили потратить деньги на свое железо и свои сервисы.

Изначально мы собирались заменить только почту. Но когда начали обсуждать переезд, посмотрели на остальные рабочие инструменты и решили заодно навести порядок. Так почтовый сервер постепенно превратился в наш собственный «ящик Пегого Дудочника» из «Силиконовой долины». (Кто в теме, тот в теме :) )

В начале года купили сервер примерно за 140 000 рублей:

Еще 25 000 рублей ушло на ИБП. Обязательно берите с чистой синусоида, наличием USB и RS-232. Вместе сервер и ИБП обошлись примерно в 165 000 рублей.

ИБП мы брали не для долгой работы без электричества. Он должен пережить короткое отключение, а если питание не вернулось — дать серверу нормально выключиться. Мы настроили автоматическое завершение работы: сначала останавливаются виртуальные машины и контейнеры, данные записываются на диски, после чего выключается сам хост. Для почтовых баз, репозиториев и виртуалок это заметно безопаснее, чем внезапно выдернутая розетка.

На сервере сейчас работает такой набор:

Все развернуто в контейнерах. Установка и обновление конфигурации автоматизированы через GitLab CI. GitLab и Jira отправляют события в нужные каналы Mattermost, поэтому уведомления по проекту лежат рядом с обсуждением. Там же команда созванивается и показывает экран — отдельный сервис для рабочих звонков нам больше не нужен.

Если убрать технические подробности, схема выглядит так:

Говорить, что open source ничего не стоит, было бы нечестно. За лицензии многих продуктов платить не нужно, но само железо надо купить, подключить и обслуживать. Есть электричество, интернет, статический IP, бэкапы, замена аккумуляторов в ИБП и время инженеров. Иногда нужны платные плагины или лицензии.

Если смотреть только на почту, два года по текущей цене обошлись бы нам в 159 104 рубля. Это почти цена сервера вместе с ИБП.

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

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

Для почты выбрали mailcow: dockerized. Внутри уже есть админка, веб-клиент и все основные почтовые компоненты.

Главный вопрос был не в том, как запустить новый сервер, а в том, как перенести старые ящики вместе с папками и вложениями. Мы нашли imapsync, настроили его и успешно прогнали тестовую синхронизацию. А потом случайно заметили, что этот же механизм уже встроен в mailcow и доступен в разделе Sync Jobs. Через веб-интерфейс настраивать его оказалось проще.

Для переноса нужен доступ к старому ящику по IMAP, а для него — пароль приложения Mail.ru. Пользователь мог создать такой пароль только после привязки телефона. Один и тот же номер к куче аккаунтов не привяжешь, а у нас были и сервисные ящики, и сотрудники с несколькими учетками.

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

Запустить почтовый сервер мало. Нужно еще убедить остальные серверы принимать от него письма.

С PTR пришлось разбираться отдельно. Для офисного сервера эту запись настраивает интернет-провайдер, потому что IP принадлежит ему. Проверить PTR лучше до смены MX, а не когда письма уже начали попадать в спам.

После настройки прогнали несколько проверок: посмотрели распространение DNS через DNSChecker, проверили IP по DNSBL и отправили письмо на mail-tester. Получили 10/10.

10/10 не обещает, что каждое письмо попадет во «Входящие». У нового IP еще нет репутации, а у крупных почтовиков свои фильтры. Но грубые ошибки в SPF, DKIM и DMARC такой тест хорошо показывает.

Без проблем, конечно, не обошлось.

После смены MX часть писем шла на новый сервер, а часть — в VK WorkSpace. Выяснилось, что домен нужно удалить и на стороне старого сервиса. Но даже после удаления часть писем продолжала уходить туда.

В итоге написали в поддержку VK WorkSpace. У них оставалась какая-то внутренняя настройка, которую поправили вручную. После этого маршрутизация заработала как надо.

В mailcow есть отдельный провайдер Keycloak, но в нашей версии через него не получилось передать нужные scopes. Подключились через обычный OIDC — так все заработало. Ящик создается при первом входе, если у пользователя есть нужная роль.

GitLab подключили к Keycloak через OmniAuth/OIDC. Пользователи автоматически связываются с локальными учетками, 2FA проверяет Keycloak. Но выяснился нюанс: у локального пользователя GitLab все еще может быть свой пароль и восстановление через почту. Получается обход единой точки входа.

Такое поведение надо проверять в каждом приложении. Где возможно, локальный вход лучше отключать. При этом аварийную учетку администратора стоит оставить и хранить отдельно, иначе проблема с Keycloak отрежет доступ сразу ко всей инфраструктуре.

Mattermost у нас отвечает не только за переписку: через него проходят обычные рабочие и групповые звонки, в том числе с демонстрацией экрана. В настройках Calls стояло Enabled, однако звонки не проходили. Мы выключили плагин, сохранили настройки, снова включили и еще раз сохранили. Только после этого конфигурация применилась.

Мелочь, но времени съела прилично.

Сейчас почта, чаты, рабочие звонки, файлы, код, задачи и документация работают на нашем сервере. Пользователи и доступы управляются через Keycloak. Обсуждения, созвоны и уведомления по проектам собраны в Mattermost. Данные бэкапятся по нашим правилам, а не по правилам внешнего поставщика.

Самым ценным для нас оказался даже не прямой выигрыш в деньгах. Теперь мы сами решаем, где лежат данные, когда обновлять систему и как долго хранить резервные копии.

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

Но self-hosted подходит не всем. Если в компании пять человек, один недорогой SaaS и никто не хочет заниматься администрированием, свой сервер легко окажется дороже и сложнее. Нужно считать не только покупку железа, но и обслуживание, бэкапы и допустимое время простоя.

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

P. S. Еще мы поддерживаем C#-библиотеку SaaSoft.MAX.Bot для разработки ботов в MAX.

P.S.S. Да, часть статьи помогла писать ИИ, потому что мы все таки "ботаны", а не писатели. Надеемся маленькую, но пользу принесем