Как перенести почту без простоя: двойная доставка писем и поэтапное переключение ящиков на Postfix

Страх простоя держит компании в облаке годами. Но правда в том, что переезд без единой потерянной минуты — это технология, а не удача. Переезд с облака на собственный сервер не должен стоить компании ни одного рабочего часа — и для этого есть проверенные техники. Перенести почту без простоя для небольшой компании можно обычным порядком за одну ночь, а когда так нельзя — помогают двойная доставка (входящие письма на время попадают и в старую, и в новую систему) и поэтапное переключение, при котором ящики переводятся группами правкой таблиц маршрутизации без смены DNS. Мы проверили обе схемы на стенде с Postfix и двумя серверами Dovecot. Ниже — конфигурация, порядок перевода отделов, что делать, если MX пока у Яндекса, и проверки перед включением.

Переезд не должен стоить ни часа работы

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

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

Простой — это отговорка, а не причина

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

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

Что значит «без простоя» при переезде почты

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

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

Обе техники требуют почтового сервера, который принимает почту домена и сам решает, куда её доставить. Мы проверили их на стенде с Postfix и двумя серверами Dovecot. Общий план переезда — в руководстве по переносу почты с Яндекс 360.

Когда это нужно, а когда нет

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

Хороший тест: если вы не можете назвать причину, по которой переход за одну ночь не подходит, — он подходит.

Как это устроено технически

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

В Postfix за это отвечают две таблицы. virtual_alias_maps превращает адрес получателя в один или несколько адресов; если адресов несколько, письмо доставляется по всем. transport_maps говорит, куда и каким способом доставлять письма для домена или адреса: локально, по SMTP на другой сервер, по LMTP в хранилище. Документация: virtual_alias_maps, transport_maps, описание таблиц transport.

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

Стенд: двойная доставка и поэтапный переход на Postfix

На стенде у нас были два сервера Dovecot — «старый» и «новый» — и Postfix, принимающий почту для тестового домена company.test. Задача: письма для anna приходят на оба сервера (двойная доставка), info пока остаётся на старом, boss уже переведён на новый.

Фрагмент main.cf:

relay_domains = company.test, old.internal, new.internal
virtual_alias_maps = hash:/etc/postfix/virtual
transport_maps = hash:/etc/postfix/transport

Таблица /etc/postfix/virtual — кому куда:

anna@company.test    anna@old.internal, anna@new.internal
info@company.test    info@old.internal
boss@company.test    boss@new.internal

Таблица /etc/postfix/transport — где находятся «старый» и «новый» серверы:

old.internal   lmtp:inet:stand-src:24
new.internal   lmtp:inet:stand-dst:24

После postmap обеих таблиц мы отправили по письму каждому адресату. Журнал Postfix:

anna@company.test -> stand-src:24 : sent
anna@company.test -> stand-dst:24 : sent
info@company.test -> stand-src:24 : sent
boss@company.test -> stand-dst:24 : sent

Письмо для anna легло в оба сервера, для info — только в старый, для boss — только в новый. Чтобы перевести следующего сотрудника, достаточно поправить его строку в virtual и выполнить postmap — без перезапуска и без изменения DNS.

Где ставить такой шлюз

Роль шлюза может выполнять сам новый почтовый сервер: MX переключается на него, а он, кроме своих ящиков, пересылает почту на старый сервер для тех, кто ещё не переведён. Это самый частый вариант при переезде на собственный сервер — в mailcow, iRedMail и других сборках на Postfix такие таблицы настраиваются.

Второй вариант — отдельный шлюз перед обеими системами, часто совмещённый с антиспамом. Он удобен, когда переходный период долгий или когда гибрид остаётся навсегда.

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

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

Если почта в Яндекс 360: пересылка вместо шлюза

Пока MX домена указывает на Яндекс, двойную доставку можно сделать на его стороне — правилом пересылки с сохранением копии. По справке Яндекс Почты правило создаётся в «Все настройки» → «Правила обработки писем» → «Создать правило», с опцией «Переслать по адресу»; адрес нужно подтвердить по ссылке из письма. Опция «Сохранить копию при пересылке» оставляет письма в исходном ящике.

Так каждое новое письмо оказывается и в Яндексе, и на новом сервере — по адресу, на который вы пересылаете (это должен быть технический адрес на новом сервере, а не тот же адрес домена, иначе письмо вернётся по MX в Яндекс). Ограничение из справки: пересылка работает только для новых входящих писем, уже лежащие в ящике письма она не переносит — их забирает imapsync.

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

Поэтапный переход по отделам

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

1) Заранее перенести письма сотрудников отдела imapsync — повторные проходы докачивают новое. 2) В согласованное время поменять их строки в таблице: адрес → новый сервер. 3) Сразу сделать финальный проход imapsync для этих ящиков, чтобы забрать письма, пришедшие на старый сервер до изменения. 4) Перенастроить сотрудникам программы и телефоны.

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

Подробно про imapsync, повторные проходы и финальный проход с --maxage — в инструкции по imapsync.

Как выбрать порядок групп

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

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

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

Отправка писем в переходный период

Двойная и раздельная доставка касается входящих писем. С исходящими проще и сложнее одновременно: каждый сотрудник отправляет через тот сервер, к которому подключена его программа. Поэтому на переходный период в SPF домена должны быть разрешены оба сервера, а DKIM опубликован для обоих (с разными селекторами). Иначе письма одной из групп начнут попадать в спам.

Если старая система — облако, проверьте, что SPF содержит её запись (например, для Яндекс 360 по справке это include:_spf.yandex.net), а новый сервер добавлен рядом. Подробно — в статье «MX, SPF, DKIM, DMARC и TTL при смене почтового провайдера».

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

Двойная доставка как страховка на первые дни

Иногда двойную доставку включают не для поэтапного перехода, а как страховку: все переходят на новую систему, но первые несколько дней входящие письма продолжают падать и в старую. Если в новой системе что-то пойдёт не так, сотрудники могут временно вернуться в старую — входящие там будут.

Минус в том, что отправленные письма и изменения (прочитано, перемещено, удалено) в двух системах расходятся. Поэтому срок такой страховки должен быть коротким и заранее объявленным, а возврат — описан как сценарий плана Б.

После окончания срока маршрут к старому серверу удаляется, и двойная доставка выключается одной правкой таблицы.

Откат: как вернуть всё назад

Преимущество маршрутизации на шлюзе в том, что откат так же прост, как переход. Если после перевода группы что-то пошло не так, достаточно вернуть их строки в таблице на старый сервер и выполнить postmap. Новые письма снова пойдут на старый сервер, а письма, успевшие прийти на новый, переносятся обратно imapsync, поменяв местами источник и приёмник.

Держите копию таблиц перед каждым изменением — например, файлы virtual.<дата> рядом с рабочим. Тогда откат — это копирование файла и postmap, без поиска, что именно поменяли.

Откат DNS (если MX уже переключён на шлюз) — отдельная, более медленная операция: её стоит предусмотреть в плане, но рассчитывать на неё как на основной способ не стоит.

Чем схема отличается от гибридной почты навсегда

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

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

Частые ошибки в переходный период

Сколько длится поэтапный переезд

Сама смена маршрута для группы занимает минуты. Время уходит на перенос писем группы заранее, перенастройку устройств после переключения и сбор вопросов перед следующим этапом. На практике удобный темп — одна-две группы в неделю, с паузой на исправление инструкций.

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

Проверки перед включением

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

• каждый адрес домена есть в таблице virtual, иначе письма для него будут отклонены
• старый сервер принимает почту для внутренних адресов с вашего шлюза
• нет петель: письмо на старый сервер не возвращается по MX на шлюз
• SPF разрешает отправку обоим серверам, DKIM опубликован для обоих
• тестовое письмо каждой группе доходит туда, куда должно (журнал Postfix: status=sent)
• письмо между сотрудниками разных групп доходит
• у шлюза настроены антиспам и ограничение релея
• есть план отката: какие строки вернуть, если что-то пойдёт не так

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