Это третья статья нашего цикла про mailcow. Напомню одной фразой: я Евгений Семёнов, техдиректор «АйТи Фреш», и на нашем собственном mailcow-сервере в дата-центре МТС живёт 21 домен и больше двухсот ящиков — наших и клиентских. Почему мы выбрали именно эту сборку, разобрано в обзоре mailcow 2026, как поставить сервер с нуля и не угодить в спам — в пошаговом регламенте установки. Сегодня — этап, которого заказчики боятся больше всего: переезд действующей компании со старой почты на новую. Страх обоснованный: почта — единственная IT-система, простой которой замечают все сотрудники одновременно, а потерянное письмо от ключевого клиента может стоить дороже всего проекта миграции. Поэтому наша формула жёсткая: почта не должна останавливаться ни на минуту, и ни одно письмо не имеет права пропасть. Ниже — схема, которой мы перевезли на один инстанс mailcow два десятка доменов с самых разных платформ: облачных сервисов, старых Exchange, серверов у прежних подрядчиков.
Стратегия миграции: почему «выключили старое — включили новое» не работает
Наивный план переезда выглядит так: в пятницу вечером выключаем старый сервер, поднимаем новый, меняем MX-запись — в понедельник все работают по-новому. На практике этот план гарантированно теряет письма, и виновата фундаментальная особенность DNS: инерция кэширования. MX-запись домена закэширована на тысячах чужих резолверов по всему интернету, и обновляется этот кэш не мгновенно, а по истечении TTL — у многих доменов это 24 часа, а с учётом провайдеров, игнорирующих TTL, реальный хвост растягивается до 48 часов. Двое суток после смены MX часть отправителей продолжит доставлять письма на старый адрес. Если старый сервер в этот момент уже выключен — отправители получат отказ или, что хуже, письма молча лягут в недоступный ящик.
Поэтому наша схема строится на трёх принципах. Первый: новый сервер разворачивается и тестируется полностью до какого-либо касания MX. mailcow ставится по регламенту из предыдущей статьи, заводятся все домены и ящики, генерируется DKIM, проверяется доставляемость с тестового ящика — старая почта в это время работает как ни в чём не бывало и даже не знает о существовании преемника. Второй принцип: параллельный период 3–7 дней, когда живы оба сервера. Письма ещё приходят на старый, пользователи уже подключены к новому, а синхронизацию хвостов закрывает imapsync. Третий: откат возможен на любом шаге. До смены MX откат — это просто «ничего не делать»; после смены — вернуть старую MX-запись, и через часы трафик потечёт обратно. Ни в одной точке схемы нет шага, после которого дороги назад нет.
Инвентаризация перед стартом
Половина сюрпризов миграции — это не техника, а незнание того, что вообще переезжает. Поэтому проект начинается не с imapsync, а с таблицы-инвентаризации, которую мы заполняем вместе с заказчиком. Наш шаблон:
| Что собираем | Зачем | Где брать |
|---|---|---|
| Список ящиков с объёмами | план imapsync, квоты, оценка времени переноса | панель старого сервера / опрос |
| Алиасы и виртуальные адреса | info@, sales@ обязаны заработать с первой минуты | конфигурация старого сервера |
| Группы рассылки | адреса «всем менеджерам» часто нигде не задокументированы | админ + опрос руководителей |
| Автоответчики и переадресации | уволенный сотрудник с форвардом на директора — классика | настройки ящиков |
| Технические отправители | 1С, CRM, сайт, сканеры — про них вспоминают в день X | опрос бухгалтерии и офиса |
| Мобильные устройства и клиенты | кому нужен ActiveSync, кому хватит IMAP | опрос сотрудников |
Отдельно предупреждаю про последнюю строку первой колонки, которой нет ни в одной панели: «теневые» ящики. Это адреса, о которых не знает даже директор, — почта старого бухгалтера, на которую до сих пор приходят акты, или ящик, зашитый в форму сайта пять лет назад. Их вылавливаем анализом логов старого сервера за последний месяц: любой адрес, принявший хоть одно письмо, попадает в таблицу.
Перенос писем: imapsync как рабочая лошадка
Для переноса содержимого ящиков мы используем imapsync — консольную утилиту, которая подключается к двум IMAP-серверам одновременно и докачивает на второй всё, чего там нет. Ключевое слово — «докачивает»: инструмент идемпотентен, его можно запускать по одному и тому же ящику сколько угодно раз, дубликатов не будет, а каждый следующий прогон переносит только новое. Именно это свойство и делает возможной всю нашу параллельную схему. Базовый вызов для одного ящика выглядит так:
imapsync \
--host1 mail.old-provider.ru --user1 ivanov@company.ru --password1 'СтарыйПароль' \
--host2 mail.company.ru --user2 ivanov@company.ru --password2 'НовыйПароль' \
--automap \
--useheader "Message-Id" \
--delete2duplicatesРазберу ключи, потому что каждый из них закрывает конкретную граблю. --automap — автоматическое сопоставление служебных папок: «Отправленные» на одном сервере могут называться Sent, Sent Items или INBOX.Sent, и без маппинга вы получите три разные папки с обрывками переписки. --useheader "Message-Id" — сравнивать письма по глобально уникальному заголовку, а не по размеру и дате: так повторные прогоны надёжно распознают уже перенесённое. --delete2duplicates — подчистить дубли на приёмнике, которые могли образоваться от прежних попыток переноса вручную.
Теперь про время, потому что его всегда недооценивают. По нашей статистике, ящик объёмом 5 ГБ переезжает за 40–90 минут — разброс зависит не столько от толщины канала, сколько от количества писем: десять тысяч мелких уведомлений по 20 КБ синхронизируются дольше, чем сто писем с тяжёлыми вложениями, потому что на каждое сообщение приходится свой цикл IMAP-команд. Умножьте на 30–40 ящиков типовой компании — и станет ясно, почему перенос нельзя откладывать на ночь переключения.
Двухпроходная схема: 95% заранее, дельта — в ночь X
Мы никогда не гоняем imapsync один раз. Схема всегда двухпроходная. Первый прогон запускается за несколько дней до переключения, в рабочее время, никого не предупреждая и ничему не мешая: пользователи продолжают работать в старой почте, а на новый сервер в фоне уезжает 95–99% исторического архива. Пусть он идёт хоть сутки — никто не заметит. Второй прогон выполняется в ночь переключения MX и переносит только дельту: письма, пришедшие на старый сервер после первого прогона. Благодаря идемпотентности это минуты, а не часы — даже по всей компании дельта-синк редко занимает больше получаса. В результате к утру пользователи открывают новый сервер и видят там всю переписку до последнего вечернего письма, а окно, в котором почта жила «на два дома», сжимается до одной ночи.
Частные случаи: Gmail, Яндекс, старый Exchange и кириллические папки
Идеальный сценарий — когда старый сервер отдаёт честный IMAP с обычным паролем. Реальность разнообразнее.
Gmail и Яндекс. Оба провайдера давно не пускают сторонние приложения по основному паролю учётки — для imapsync придётся выпустить пароль приложения в настройках безопасности каждого ящика (и на Gmail для этого должна быть включена двухэтапная проверка). Это самая нудная часть миграции с облаков: пароль приложения выпускается только владельцем ящика или админом, по одному на ящик. Вторая особенность облаков — лимиты на объём IMAP-трафика в сутки: большой ящик может упереться в квоту и оборваться на середине. Лечится это терпением — imapsync при следующем запуске продолжит с места обрыва, так что просто планируйте на облачные ящики больше календарных дней.
Старый Exchange. Здесь первым делом проверяем, включена ли на сервере IMAP-служба — на многих Exchange она выключена как класс, и её надо поднять до начала переноса. Если IMAP включить нельзя или он отдаёт покалеченные данные (бывает на совсем древних версиях), остаётся путь через EWS-совместимые инструменты выгрузки или экспорт в PST с последующей раздачей архивов пользователям. Мы всегда сначала бьёмся за IMAP: перенос через imapsync сохраняет структуру папок и флаги прочтения, а PST-путь — это ручная работа на каждом рабочем месте.
Кириллические имена папок. Русские названия в IMAP кодируются модифицированным UTF-7, и разные серверы делают это по-разному; вдобавок пользователи любят папки вида «Договоры 2019 (старое)». Когда --automap не справляется, подключается ключ --regextrans2 — регулярное выражение, переписывающее имя папки на лету при переносе:
# всё содержимое INBOX.Archive старого сервера сложить в Archive:
imapsync ... --regextrans2 's/^INBOX\.Archive/Archive/'
# заменить недопустимые на приёмнике символы:
imapsync ... --regextrans2 's/[&\\]/_/g'Совет из практики: перед боевым прогоном запустите imapsync с ключом --dry (сухой прогон) на двух-трёх самых захламлённых ящиках. Он покажет полную карту папок и что во что ляжет, не перенося ни одного письма. Пять минут сухого прогона экономят час разгребания папок-дублей после боевого.
Массовое заведение ящиков через API mailcow
Сорок ящиков можно накликать в панели за вечер, но мы этого не делаем никогда: ручной ввод сорока пар «логин-пароль» гарантирует пару опечаток, которые всплывут в худший момент. У mailcow есть полноценный REST API, и заведение ящиков — идеальная задача для него. Ключ генерируется в админ-панели в разделе API; там же настоятельно рекомендую сразу ограничить доступ по IP — ключ с правом записи умеет всё то же, что админ, и светить им на весь интернет не нужно. Создание ящика — это POST-запрос на /api/v1/add/mailbox с JSON-телом:
{
"local_part": "ivanov",
"domain": "company.ru",
"name": "Иванов Иван",
"password": "S3cure!Pass-2026",
"password2": "S3cure!Pass-2026",
"quota": "3072",
"active": "1"
}Правка существующего ящика — тот же стиль, POST /api/v1/edit/mailbox. На Python вся обвязка укладывается в десяток строк:
import csv, requests
API = "https://mail.company.ru/api/v1/add/mailbox"
KEY = "XXXXX-XXXXX-XXXXX-XXXXX-XXXXX"
with open("mailboxes.csv", encoding="utf-8") as f:
for row in csv.DictReader(f): # ФИО;ящик;пароль;квота
local, domain = row["email"].split("@")
r = requests.post(API,
headers={"X-API-Key": KEY},
json={"local_part": local, "domain": domain,
"name": row["fio"],
"password": row["password"], "password2": row["password"],
"quota": row["quota"], "active": "1"})
print(row["email"], r.status_code, r.text[:120])Грабля из нашего прода — не трогайте пароли через SQL. Однажды при миграции возник соблазн «быстро» массово задать пароли существующим ящикам прямым UPDATE в MariaDB — таблица с хэшами вот она, формат понятен. Не делайте так. Пароль ящика в mailcow меняется только через API или панель: прямой апдейт базы рассинхронизирует связку с SOGo SSO, и получается изощрённая поломка — сотрудник спокойно входит по IMAP из Outlook (Dovecot видит новый хэш), а веб-почта его не пускает. Диагностировать это, глядя в логи, — отдельное удовольствие: с точки зрения каждого компонента по отдельности всё работает. Мы потратили на разбор вечер; вылечилось повторной установкой тех же паролей уже через API.
CSV-импорт: от таблицы заказчика до готовых ящиков
На практике весь процесс выглядит так. Таблица инвентаризации из первого раздела превращается в CSV с четырьмя колонками: ФИО, ящик, пароль, квота. Пароли мы генерируем скриптом — длинные, но диктуемые по телефону (без похожих символов вроде l/I/1). Скрипт выше пробегает по файлу и создаёт ящики; тот же CSV потом становится источником для памятки каждому сотруднику и для конфигурации imapsync (колонка «ящик» + пароли старого и нового серверов). Один файл — три применения, ноль расхождений. Алиасы и группы рассылки заводятся следом тем же способом — у API есть аналогичный вызов add/alias, и инвентаризационная таблица снова оказывается единственным источником правды.
Подключение рабочих мест
Ящики созданы, письма едут — пора подключать людей. Здесь миграция выигрывается или проигрывается в глазах пользователей: письма их волнуют меньше, чем «а календарь мой где?».
ActiveSync: Outlook работает как с Exchange
Главный страх офиса при отказе от Exchange или облака — «Outlook перестанет работать». Не перестанет. mailcow (руками SOGo) отдаёт протокол Exchange ActiveSync — тот самый Microsoft-Server-ActiveSync, по которому Outlook и смартфоны привыкли общаться с Exchange. Это значит: push-доставка писем, синхронизация календаря и контактов, и всё это без единого плагина. А поскольку autodiscover и autoconfig встроены в nginx mailcow из коробки, процедура подключения для сотрудника сводится к двум полям: адрес почты и пароль. Outlook сам находит сервер по домену и сам настраивает профиль. В памятке сотруднику мы даже не пишем имён серверов и портов — только «удалите старую учётную запись, добавьте новую, введите почту и новый пароль».
Ограничение EAS и DAV: не всякому ящику — смартфон
В релизах mailcow 2026 года (актуальный — 2026-05 «Mooay 2026», ревизия C от 26 мая; проект выпускает обновления каждые один-два месяца) появилась функция, которую мы давно ждали: выборочный запрет протоколов EAS и DAV на уровне отдельного ящика. Зачем это нужно, понимает каждый, кто сопровождал бухгалтерию: почта главбуха с платёжками и ящик директора с договорами не должны синхронизироваться на личный телефон, потерянный потом в такси. Теперь это решается флагом в свойствах ящика: IMAP с рабочего места — пожалуйста, ActiveSync на смартфон — запрещено. Раньше подобное городили внешними правилами на прокси, теперь — штатная настройка. При миграции мы сразу спрашиваем заказчика, какие ящики относятся к «чувствительным», и закрываем им мобильную синхронизацию с первого дня.
IMAP-клиенты и веб: Thunderbird, смартфоны, SOGo
Не всем нужен ActiveSync. Thunderbird и другие классические клиенты подключаются по IMAP (порт 993, SSL/TLS) и SMTP (465) — и благодаря autoconfig тоже настраиваются одним адресом почты. Мобильные почтовые приложения умеют либо ActiveSync (тогда добавляется учётка типа Exchange), либо IMAP — работают оба пути. А для тех, кто не хочет ничего настраивать, есть SOGo в браузере: https://mail.company.ru/SOGo, вход по адресу и паролю, почта, календарь и адресная книга на русском. По нашему опыту, в первый день после переезда веб-почтой пользуется половина офиса — просто потому, что это быстрее, чем ждать очереди на перенастройку клиента, — а через месяц в ней остаётся стабильная треть.
Типовая ошибка дня переезда: офис банит сам себя
А теперь сцена, которая случалась у нас не раз и не два. Утро после переключения. Звонок: «Почта не открывается ни у кого!» Паника, подозрения на сервер — а сервер в полном порядке. Что произошло: у нескольких сотрудников в телефонах и ноутбуках остались учётки со старыми паролями, и эти устройства с шести утра молотят в IMAP неверными кредами каждые тридцать секунд. Контейнер netfilter, следящий в mailcow за перебором паролей, честно делает свою работу — и после N неудачных попыток банит IP-адрес источника. А источник — это внешний IP офисного роутера, за которым сидят все сорок человек. Итог: три забытых телефона отключили от почты целую компанию. Лечение штатное: в админ-панели mailcow вносим офисный IP в whitelist netfilter — и делаем это заранее, при подготовке к переезду, а не после первого звонка. В нашем чек-листе дня X этот пункт стоит жирным шрифтом, а в памятке сотрудникам отдельной строкой написано: «обновите пароль на ВСЕХ устройствах, включая планшет, который лежит дома».
Интеграции с бизнес-системами
Люди переехали — остались роботы. В любой компании почтой пользуются не только сотрудники: счета шлёт 1С, заявки собирает сайт, сканы отправляет МФУ. Про них вспоминают, когда бухгалтер в панике сообщает, что «счета не уходят». Мы закрываем интеграции до дня X, по списку из инвентаризации.
1С и ERP: отдельный технический ящик с sender_acl
Отправка счетов и актов из 1С — это обычный SMTP, и mailcow справляется с ним без какой-либо специфики. Но заводить для этого мы советуем не «почту бухгалтера», а отдельный технический ящик вида 1c@company.ru: свой пароль (который не меняется при увольнении бухгалтера), своя история отправки, свой след в логах. Если документы должны уходить «от имени» живого адреса — скажем, от buh@company.ru, — в mailcow это решается штатно через sender_acl: техническому ящику выдаётся право отправлять от имени чужого адреса, без раздачи пароля самого ящика роботу. В настройках 1С указываем SMTP mail.company.ru, порт 465, авторизация от технической учётки — и рассылка документов продолжает работать так же, как до переезда, только теперь каждое письмо робота отличимо от писем человека.
CRM и сайт: заявки на info@ и маршрутизация Sieve
Формы сайта и CRM обычно шлют заявки на общий адрес вроде info@. Сам адрес мы заводим алиасом ещё на этапе массового создания ящиков, но интереснее другое: в mailcow (руками Dovecot) работает язык фильтров Sieve, и на общем ящике можно построить настоящую маршрутизацию. Заявка с темой, содержащей маркер сайта, — копией в отдел продаж; письма с домена транспортной компании — логисту; всё с вложениями-актами — в бухгалтерию. Правила задаются в настройках ящика и выполняются на сервере, до всяких клиентов, — то есть работают одинаково, каким бы способом сотрудник ни читал почту. У пары наших клиентов Sieve-маршрутизация info@ заменила собой «секретаря, который пересылает письма», — и это был неожиданный бонус миграции, о котором заказчик не просил.
Сканеры и МФУ: старое железо против нового TLS
Самый недооценённый пункт списка. Офисный МФУ, отправляющий сканы на почту, был куплен десять лет назад, и его прошивка умеет в лучшем случае TLS 1.0, а то и вовсе только открытый SMTP. Современный сервер такое рукопожатие отвергает — и сканер молча перестаёт слать сканы, а выяснится это через неделю, когда кому-то понадобится скан договора. Наше решение — не ослаблять TLS для всех (это удар по безопасности всего сервера ради одной железки), а поднять для МФУ отдельную точку приёма: submission-порт со смягчёнными требованиями, доступ к которому жёстко ограничен внутренним IP-адресом сканера — снаружи и с других адресов локальной сети он закрыт фаерволом. Сканер шлёт по-старому, интернет об этом порте не знает, основной SMTP остаётся строгим. Если же МФУ относительно свежий — просто проверьте в его веб-морде поддержку TLS 1.2 и обновите прошивку: часто этого достаточно.
Мониторинг: квоты, очереди и Telegram
Последняя интеграция — для нас самих. Сразу после переезда на сервер встаёт мониторинг с уведомлениями в Telegram, и первым делом — контроль заполнения квот. Причина проста: после миграции ящики стартуют уже наполненными историческим архивом, и та самая квота, что выглядела щедрой при планировании, у самых активных пользователей заканчивается через месяц-другой. Переполненный ящик перестаёт принимать письма — то есть тихо теряет их, что противоречит главной формуле всего проекта. Алерт на 85% заполнения даёт время расширить квоту до того, как первый отправитель получит отказ. Туда же, в Telegram, уходят события посерьёзнее: рост очереди отправки, падение контейнера, попадание IP в чёрные списки.
День X: переключение MX по чек-листу
Всё готово: сервер протестирован, ящики созданы, архив перенесён первым прогоном, интеграции переведены, офисный IP в whitelist. Остался собственно переезд — и он у нас расписан по пунктам, потому что в два часа ночи импровизировать не надо.
За 48 часов до окна понижаем TTL у MX-записи (и у A-записи почтового имени, если она меняется) до 300–600 секунд. Смысл: сейчас по миру закэшировано старое значение с суточным TTL, и если менять MX сразу, хвост доставки на старый сервер растянется на двое суток. Пониженный заранее TTL сжимает этот хвост до минут — но чтобы понижение само успело расползтись по кэшам, его надо сделать за те же 48 часов, отсюда и цифра.
Ночное окно (мы берём ночь с пятницы на субботу — впереди два дня форы) выглядит так:
- Финальный прогон imapsync по всем ящикам — переносится дельта с первого прогона, обычно 15–30 минут на всю компанию.
- Смена MX на нового: одна правка в DNS-панели. Благодаря пониженному TTL новые письма начинают приходить на mailcow в течение минут.
- Контроль очереди старого сервера. Старый сервер не выключаем! На нём могли остаться письма, принятые в последние минуты и ещё не отданные в ящики, а какие-то отправители продолжат стучаться в него по старому кэшу. Смотрим очередь Postfix командой
postqueue -pи ждём её полного опустошения; всё, что за это время упало в старые ящики, добирается ещё одним коротким imapsync под утро. - Контрольные письма: с Gmail на мигрированный домен, с домена на Gmail и Mail.ru, между двумя внутренними ящиками. Проверяем заголовки: письма принял новый сервер, SPF/DKIM/DMARC — pass.
Точка невозврата — которой нет. Обратите внимание: даже после смены MX откат остаётся тривиальным — вернуть старое значение записи, и с тем же коротким TTL трафик за минуты потечёт на старый сервер, который мы предусмотрительно не выключали. За все наши миграции этой кнопкой не пришлось воспользоваться ни разу, но само её наличие меняет психологию ночи X: команда работает спокойно, потому что любая проблема стоит минуты отката, а не бессонные выходные.
Памятка сотрудникам — одной страницей
Вечером пятницы каждый сотрудник получает памятку. Требование к ней жёсткое: одна страница, ноль терминов. Наша структура: что произошло (у компании новая почта, адрес не изменился); ваш новый пароль (из CSV, индивидуально); что сделать в понедельник (удалить старую учётку в Outlook/телефоне, добавить новую: адрес + пароль, всё настроится само); ссылка на веб-почту на случай, если что-то не получилось; телефон поддержки. Отдельным пунктом, капслоком: обновите пароль на всех устройствах, включая домашние. Чем короче памятка, тем меньше утренних звонков — проверено на десятках переездов: подробные инструкции на три листа не читает никто.
Неделя двойного контроля
После переключения старый сервер живёт ещё минимум неделю — это и есть период двойного контроля. Причины держать его: остаточная доставка от провайдеров с упрямыми DNS-кэшами; забытые отправители из инвентаризации, которые проявятся только со временем; и спокойствие заказчика, знающего, что старая почта никуда не делась. Если старая платформа позволяет, настраиваем на ней пересылку входящих на новый сервер или оставляем её backup-MX с меньшим приоритетом — тогда даже самое заблудившееся письмо в итоге доедет до нового ящика. Через неделю смотрим логи старого сервера: если входящих ноль — прощаемся с ним; если что-то ещё капает — разбираемся с каждым отправителем и продлеваем период. Убивать старый сервер раньше, чем его логи станут пустыми, — единственный способ всё-таки потерять письма в нашей схеме, поэтому спешка здесь запрещена регламентом.
Итоги и метрики наших миграций
Сведу опыт в цифры, которые можно использовать для планирования. Типовой проект — компания на 25–40 ящиков — занимает два рабочих дня подготовки (инвентаризация, развёртывание mailcow по регламенту установки, ящики через API, первый прогон imapsync, интеграции) плюс одну ночь переключения и неделю фонового двойного контроля, которая инженерного времени почти не требует. Главная метрика по всем нашим переездам, включая собственный на 21 домен: ноль потерянных писем. Не потому, что нам везло, а потому, что в схеме с параллельным периодом письму физически некуда пропасть: в любой момент времени есть как минимум один живой сервер, принимающий почту домена, а idempotent-синхронизация добирает всё в единое место.
Честности ради — список того, что делает проект сложнее плана:
- PST-архивы по 50 ГБ. У руководителей нередко обнаруживаются локальные архивы Outlook размером с дистрибутив Windows. Через IMAP такие объёмы заливаются мучительно, и мы обычно договариваемся: оперативная переписка едет на сервер, а исторические PST остаются локальными архивами, подключёнными в Outlook рядом с новой учёткой. Если заказчик хочет весь архив на сервере — закладывайте отдельные дни и дисковые квоты.
- Самописные скрипты на старом сервере. За годы на почтовом сервере нарастает бахрома: скрипт, выгружающий вложения в папку обмена, ночной отчёт, самодельная рассылка. В панелях они не видны, в инвентаризации всплывают через опрос «а что ещё у вас происходит с почтой автоматически?». Каждый такой механизм — отдельная задача переноса, и лучше узнать о ней до дня X.
- «Теневые» ящики. Про них я писал в начале: адреса, о которых никто не помнит, но на которые приходит что-то важное. Анализ логов старого сервера за месяц вылавливает почти все; последние одиночки проявляются в период двойного контроля — ещё одна причина не выключать старый сервер раньше времени.
Если суммировать весь цикл из трёх статей: mailcow даёт малому и среднему бизнесу почту уровня «взрослых» систем без лицензионных платежей, ставится за считанные часы — а переезд на неё, вопреки страхам, при правильной схеме проходит незаметно для сотрудников. Ключевые слова — «при правильной схеме»: параллельный период, двухпроходный imapsync, заведение ящиков через API, whitelist для собственного офиса и неделя двойного контроля. Всё остальное — дисциплина исполнения чек-листа. Если хочется пройти этот путь с командой, которая уже перевезла на mailcow 21 домен, — напишите мне в Telegram @ITfresh_Boss или позвоните +7 903 729-62-41.
Оставить комментарий