RuPost: обзор почтового сервера и миграция с Exchange

rupost миграция с exchange: что важно знать перед принятием решения.

Разбираем контекст, ключевые критерии, риски и практические шаги без привязки к шаблонным сценариям.

RuPost — корпоративная почтовая система разработки «Группы Астра»: помимо почты включает календари, задачи и адресные книги. Продукт внесён в Единый реестр российского ПО (запись №14647, класс «Почтовые приложения») — это формальное основание для участия в закупках по 44-ФЗ/223-ФЗ и для замены западных решений там, где импортозамещение закреплено регламентом. На наших проектах юристы заказчика требуют не маркетинговое заявление, а выписку из реестра — рекомендуем сразу прикладывать её к ТЗ на миграцию.

По нашему опыту, тема «rupost миграция с exchange» приходит к интегратору в двух ситуациях: либо у клиента истёк срок лицензий Exchange и продлить их легально нельзя, либо ИБ-служба запрещает хранить почту на Microsoft-стеке. В обоих случаях RuPost закрывает требование «российское ПО» и не требует пересборки инфраструктуры с нуля. RuPost — один из реестровых вариантов; полное сравнение с CommuniGate Pro, Tegu, Mailion и FOSS-решениями — в обзоре российских аналогов Microsoft Exchange.

Важно понимать позиционирование: RuPost — управляемая платформа от единого вендора (с поддержкой, библиотекой готовых конфигураций и регламентом обновлений), а не сборка из open-source-компонентов, которую можно «переписать под себя». Это плюс для SLA и минус для тонкой кастомизации — учитывайте при выборе. Сам RuPost сертификата ФСТЭК не имеет, но работает на сертифицированной ФСТЭК ОС Astra Linux Special Edition — это обычно и закрывает требования регулятора к среде.

Архитектурно RuPost — это серверная часть (MTA, хранилище, веб-доступ, службы каталогов), клиент RuPost Desktop и веб-интерфейс. Кроссплатформенный клиент RuPost Desktop входит в поставку (версии для Astra Linux, Alt, RedHat и Windows; версия для macOS на момент написания — в разработке); помимо него поддерживается веб-доступ и популярные мобильные почтовые клиенты по стандартным протоколам. Пользователю не обязательно сразу пересаживаться на новый клиент — мобильные iOS/Android продолжают ходить по знакомым протоколам, а десктоп можно мигрировать поэтапно.

Решение умеет одновременно работать с разными ОС и службами каталогов (AD, LDAP, FreeIPA, ALD Pro). На наших проектах это критично: типовая инфраструктура — часть станций на Astra Linux, часть на Windows. RuPost закрывает такое смешанное окружение без необходимости унифицировать всё за один спринт. Если у клиента уже развёрнут стек «Группы Астра» (Astra Linux SE, ALD Pro), это дополнительный плюс по интеграции.

Для крупных инсталляций RuPost поддерживает кластеризацию: в редакции Enterprise — Active-Active с практически неограниченным числом узлов за счёт балансировки нагрузки. На практике это классическая схема «несколько узлов фронта + общее хранилище + резервный контур»; точные параметры развёртывания берите из официальной документации под вашу версию.

Отдельно про Outlook: RuPost ориентирован на собственный клиент и веб-доступ, а Outlook подключается через плагин — календари и контакты синхронизируются по CalDAV/CardDAV, а почта идёт по IMAP/SMTP. Нативной поддержки Exchange-протоколов (MAPI/EWS) у RuPost нет, поэтому сценарии, завязанные на MAPI, нужно проверять на тестовом стенде до подписания договора. У нас был случай, когда заказчик заложил «100% совместимость с Outlook по MAPI» без проверки — на этапе ОПЭ пришлось переводить часть пользователей на IMAP-профиль и веб-клиент.

Прежде чем браться за rupost миграция с exchange, стоит зафиксировать, какие сущности переезжают «один-в-один», какие — с ограничениями, а какие придётся пересобирать руками. По нашему опыту, переоценка совместимости — главная причина срыва сроков на таких проектах.

Ключевой риск — публичные папки. В крупных компаниях на Exchange их часто используют как «файлопомойку» с почтовыми треками за десятилетие. На наших проектах мы делали так: до миграции инвентаризовали все публичные папки, помечали актуальные (используются за последние 12 месяцев) и архивные, и переносили только актуальные — в виде общих ящиков с понятными именами. Остальное выгружали в PST и складывали в холодный архив, чтобы не тащить в новый сервер мёртвый груз.

Второй болезненный момент — server-side rules и подписи на уровне Exchange Transport Rules. Они в RuPost не приедут автоматически: правила воссоздаются вручную (или через клиентскую часть RuPost Desktop), а корпоративные подписи лучше пересобрать через шаблонизатор на стороне почтового сервера. Заложите на это отдельный пункт работ . мы видели, как «забытые» правила автоответов рассылали отпускные уведомления спустя месяц после переезда, потому что никто не пересоздал их в новой системе.

Типовой проект rupost миграция с exchange для компании на пару сотен ящиков мы разбиваем на пять контрольных этапов с обязательной точкой отката в конце каждого. По нашему опыту, попытка «переехать за выходные» без поэтапного плана почти всегда заканчивается продлёнными работами в понедельник и потерянным доверием бизнеса.

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

Этап 2. Развёртывание стенда RuPost. Поднимаем сервер на отдельном железе или ВМ, подключаем к каталогу (AD или ALD Pro), настраиваем DNS-зону для будущей боевой эксплуатации, проверяем приём/отправку с тестовых ящиков. На этом же шаге проверяем интеграцию с RuBackup и другими продуктами стека «Группы Астра» — если они есть у клиента.

Этап 3. Параллельная работа. Включаем режим параллельной работы RuPost со старым почтовым сервером — RuPost эту схему поддерживает «из коробки». Часть ящиков переводим на новый сервер, остальные продолжают принимать почту на Exchange; маршрутизация между ними настраивается через SMTP-релей. На этом этапе мы обычно запускаем «пилотный» отдел из 5–10 человек на 1–2 недели, чтобы поймать неочевидные сценарии: подписи, переадресации, заявки в helpdesk на «у меня в Outlook не открываются вложения».

Этап 4. Массовая миграция. После пилота переносим остальных пользователей пакетами по 20–50 ящиков. Между пакетами обязательно — пауза на 1–2 рабочих дня, чтобы успеть отловить ошибки. Точка отката: если в пакете больше 10% жалоб на потерю писем, останавливаем перенос и разбираемся.

Базовая проверка готовности после миграции пакета:

Этап 5. Отключение Exchange. Только после того, как все ящики переехали и прошла 1–2 недели без жалоб, переключаем MX на RuPost окончательно, оставляя старый сервер в режиме «только чтение» ещё на месяц. Это наш страховой буфер на случай, если кто-то вспомнит про папку, которую не указали в инвентаре.

Технически перенос почты делается через IMAP-синхронизацию: подключаемся к Exchange как клиент, читаем содержимое ящика и записываем его в RuPost. Штатный путь — RuPost Migration Tool; на смешанных инфраструктурах также применяют открытые IMAP-инструменты, которые работают инкрементально, переносят флаги прочтения и сохраняют структуру папок.

Первый прогон делаем заранее, за несколько дней до часа Х — он переносит основной объём. В день переключения запускаем повторный (инкрементальный) прогон — он копирует только новые письма, что занимает минуты, а не часы. В этом и смысл режима сосуществования RuPost со старым сервером: пользователь продолжает получать почту во время первой длинной синхронизации.

С календарями ситуация хуже, чем с почтой. Прямого «один-в-один» переноса повторяющихся событий Exchange в нативный календарь RuPost через стандартный IMAP не сделать — нужно экспортировать события в iCalendar (.ics) и импортировать на стороне RuPost. Подводные камни, которые мы встречали на нескольких проектах:

• Таймзоны. События, созданные в Outlook с локальной TZ, после импорта могут «съезжать» на час. Лечится указанием UTC в экспорте и выборочной проверкой у пользователей в разных регионах.
• Делегаты. Право «секретарь видит календарь руководителя» в Exchange и RuPost описывается по-разному. Список делегатов выгружаем отдельно и пересоздаём на новом сервере.
• Переговорные как ресурсы. В Exchange они часто заведены как mailbox с auto-accept. В RuPost их пересоздают как ресурсы и переподключают к политикам бронирования.

Публичные папки переносим в последнюю очередь и только те, что прошли инвентаризацию (см. предыдущий раздел). Не делайте автоматический «перелив всех публичных папок скриптом»: мы один раз так сделали и потом две недели разбирали, какие из 800 переехавших папок реально нужны, а какие — мусор пятилетней давности. Лучше потратить день на ручную сортировку с владельцем процесса до миграции, чем месяц чистки после.

Отдельно про мобильных пользователей: профили на iPhone/Android после смены сервера перенастраиваются вручную или через MDM. Кроссплатформенный клиент RuPost Desktop и веб-доступ помогают «закрыть дыру» на время перенастройки: у пользователя остаётся хотя бы один способ читать почту.

Прямую цену RuPost вендор формирует через партнёрскую сеть и статус покупателя (коммерческий заказчик, госсектор, образование), поэтому «прайса на сайте» нет: финальная стоимость считается под конкретный проект. Мы запрашиваем КП через авторизованного партнёра «Группы Астра» и параллельно у пары альтернативных поставщиков, чтобы получить адекватную вилку. Ориентир по редакции Standard, по открытым предложениям дилеров, порядка 2000–3300 ₽ за ящик (подписка или бессрочная); цену на Enterprise публично не раскрывают, только по запросу.

Совокупная стоимость владения для бизнеса на 100–500 ящиков обычно складывается из четырёх частей:

• Лицензии на серверную часть RuPost — по числу пользователей, с подпиской на обновления и поддержку.
• Лицензии RuPost Desktop — если нужен «толстый» клиент на станциях; при работе через веб-интерфейс этот пункт сокращается.
• Инфраструктура — серверы под почту, хранилище под архивы, бэкап. Для 500 ящиков с историей 5+ лет это единицы терабайт быстрого хранилища.
• Работы подрядчика — аудит, развёртывание, миграция, обучение, сопровождение 1–3 месяца после запуска.

Что обычно недооценивают в смете, это не лицензии, а человеко-часы на перенос публичных папок и обучение людей. Мы закладываем отдельной строкой час на пользователя на «вопросы первой недели»: где найти календарь, как создать правило, почему не работает старая подпись. Для 200 пользователей это ещё около 200 часов поддержки; игнорировать пункт нельзя, иначе всю нагрузку получит внутренний helpdesk заказчика.

Честное сравнение по окупаемости строится не «RuPost против бесплатного Exchange», а «RuPost против легально продлеваемых лицензий Exchange, Outlook и CAL». Когда западные лицензии продлить уже нельзя (типичная сегодня ситуация), окупаемость считается через регуляторный риск: сколько стоит отсутствие легально лицензированной почты на горизонте проверки. RuPost закрывает этот риск как «решение из реестра с вендорской поддержкой», что для отчёта в правление обычно весомее разницы в цене за лицензию.

RuPost — коммерческая платформа от единого вендора для корпоративного сегмента с требованиями к российскому ПО, поддержке и связке с экосистемой «Группы Астра». Мы рекомендуем его в трёх ситуациях.

Первая: есть формальное требование «софт из реестра» (госсектор, объекты КИИ, крупные заказчики с импортозамещающим регламентом). Здесь варианты на open-source отпадают сразу: Mailcow и Stalwart в реестре не числятся, и провести их через корпоративную закупку как «российское решение» нельзя. Сама запись RuPost в Реестре российского ПО, в отличие от маркетинговых регалий, и есть готовый аргумент для конкурсной заявки.

Вторая: у клиента уже развёрнут стек «Группы Астра» (Astra Linux SE, ALD Pro, RuBackup), и каждая новая связка должна работать без бубна. RuPost совместим с этим стеком и одновременно работает с разными ОС и службами каталогов, то есть закрывает и «чистый» Astra-контур, и смешанные среды.

Третья: нужна вендорская поддержка, обучение администраторов, SLA на инциденты и понятный roadmap. У open-source-проектов такого уровня поддержки в РФ нет, есть только сообщества и подрядчики ad-hoc.

Mailcow и Stalwart — другая лига и другой сценарий. Они уместны, когда:

• штат небольшой (десятки, максимум первые сотни ящиков) и почту держат силами одного-двух админов без вендорской поддержки;
• бюджет на лицензии в приоритете, а формального требования «реестр» нет;
• команда умеет читать логи Postfix/SMTP, разбираться в SPF/DKIM/DMARC и чинить доставляемость без эскалации к вендору;
• нужна максимальная гибкость настройки: нестандартная маршрутизация, свои anti-spam-механики, тесная связка с собственным IAM.

Не делайте и обратной ошибки. Мы видели проекты, где бизнес на 80 ящиков ставил «тяжёлую» платформу класса RuPost ради галочки в безопасности и потом жаловался на избыточную стоимость администрирования. И наоборот: на 500+ пользователей пытались жить на самосборном Mailcow без коммерческой поддержки и упирались в первый же серьёзный инцидент с потерей писем, который вендор закрыл бы по SLA. Соответствие платформы масштабу и регуляторике важнее экономии на лицензиях.

Ответы на часто задаваемые вопросы по теме статьи.

Константин Тютюнник — ведущий инженер IT For Prof. Специализируется на построении отказоустойчивых почтовых систем и миграции корпоративных данных. Имеет опыт реализации проектов для компаний с численностью штата от 50 до 5000 сотрудников. Эксперт в области импортозамещения ИТ-инфраструктуры и интеграции решений «Группы Астра».