Перенос общих ящиков, псевдонимов, рассылок и правил при переезде почты на свой сервер

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

Настройки — это тоже ваши данные

Облачный провайдер охотно отдаёт письма по IMAP. Но годами накопленная логика работы с почтой — кто читает общий ящик, куда уходят письма на sales@, какие правила раскладывают счета по папкам — хранится в его панели и выгрузке не подлежит. Пока вы в облаке, эта логика принадлежит провайдеру в той же мере, что и вам.

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

Вас обокрали по-тихому

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

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

Шаг 1. Инвентаризация

Прежде чем что-то переносить, составьте полный список. Источник — панель администратора Яндекс 360 и опрос руководителей отделов: администратор видит не всё, что сотрудники настроили в своих ящиках сами.

• общие ящики: адрес, кто читает, кто отправляет от имени
• дополнительные адреса каждого сотрудника
• рассылки отделов и их участники, включая внешних
• правила фильтрации, особенно пересылки на внешние адреса
• автоответы и подписи
• адреса, которые указаны на сайте, в договорах, в 1С

Шаг 2. Общие ящики: письма

Общий ящик в Яндекс 360 забирается по IMAP через сотрудника, у которого есть к нему доступ, с техническим логином по формату из справки Яндекса. Перед массовым переносом проверьте формат на одном ящике с --justfoldersizes: команда покажет число писем по папкам и ничего не перенесёт.

docker run --rm -v "$PWD":/var/tmp gilleslamiral/imapsync imapsync \
  --host1 imap.yandex.ru --ssl1 --user1 '<технический логин общего ящика>' --passfile1 /var/tmp/pass_anna \
  --host2 mail.company.ru --ssl2 --user2 info@company.ru --passfile2 /var/tmp/pass_info \
  --automap --justfoldersizes

На своём сервере общий ящик заранее создаётся как обычный ящик с собственным паролем. Если проверка прошла, уберите --justfoldersizes и запустите перенос. Подготовка Яндекс 360 и формат логина — в статье о подготовке Яндекс 360 к выгрузке.

Шаг 3. Общие ящики: права

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

В mailcow делегирование настраивается в карточке ящика, подробно — в статье «Общий ящик info@ в mailcow». Отдельно решите, кто может отправлять письма от имени общего адреса: это отдельное право, и без него сотрудник получит ошибку отправителя.

Шаг 4. Псевдонимы

Дополнительные адреса сотрудников — a.petrova@ для anna@, старые адреса уволенных, адреса из прошлых доменов — переносятся как псевдонимы. На своём сервере псевдоним — это запись «адрес → ящик или несколько ящиков». В mailcow, iRedMail и Carbonio они создаются в панели администратора; на «голом» Postfix — в таблице virtual.

# /etc/postfix/virtual — псевдонимы и рассылки при «голом» Postfix
sales@company.ru      anna@company.ru, ivan@company.ru
a.petrova@company.ru  anna@company.ru

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

Шаг 5. Рассылки отделов

Рассылка — это адрес, письма на который получают несколько человек: sales@, support@, all@. Технически это псевдоним с несколькими получателями. Перенесите состав каждой рассылки и проверьте внешних участников: если в рассылке есть адрес подрядчика, письма на неё будут уходить наружу — убедитесь, что это осознанно.

Для рассылки на всю компанию ограничьте, кто может в неё писать. Иначе all@company.ru становится каналом для спама и фишинга: одно письмо снаружи сразу попадает во все ящики. Как ограничивать права на рассылки, мы разбирали на примере Zimbra в статье о правах на списки рассылки.

Шаг 6. Правила фильтрации — в Sieve

Правила, которые сотрудники настроили в облачном интерфейсе, на своём сервере становятся правилами Sieve — стандартного языка фильтрации почты. Dovecot выполняет их при доставке, а пользователи редактируют через веб-почту: в SOGo, Roundcube и Carbonio есть конструктор правил без программирования.

require ["fileinto", "vacation"];
# письма от банка — в папку «Банк»
if address :domain "from" "bank.example" {
    fileinto "Банк";
    stop;
}
# автоответ на время отпуска
vacation :days 1 :subject "В отпуске до 20 октября"
  "Я в отпуске. По срочным вопросам пишите на info@company.ru.";

Перенос правил — ручная работа: облако их не экспортирует. Попросите сотрудников сделать снимки экрана своих правил до переключения и восстановите самые важные — раскладку счетов, пометку писем от ключевых клиентов. Подробно о Sieve — в статье «Фильтрация почты в Dovecot Sieve».

Пересылки на внешние адреса: повод навести порядок

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

Переезд — момент их закрыть. Переносите только пересылки, которые руководитель подтвердил письменно. На своём сервере можно запретить автоматическую пересылку наружу на уровне сервера — так ни одно правило, настроенное сотрудником, не выведет переписку за пределы компании.

Шаг 7. Автоответы и подписи

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

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

Шаг 8. Адреса во внешних системах

Общие адреса указаны не только в почте. Сайт отправляет заявки на zakaz@, 1С шлёт счета от buh@, на МФУ сканы уходят на scan@, в договорах указан info@. Пройдите по этим системам и убедитесь, что каждый адрес существует на новом сервере — как ящик или псевдоним — и что отправка из этих систем перенастроена на ваш SMTP.

Отправка от имени: технические детали

Когда сотрудник отправляет письмо от имени общего адреса, сервер проверяет, имеет ли его учётная запись право на этот адрес отправителя. В mailcow и Postfix это проверка соответствия логина и адреса отправителя; без явного разрешения письмо будет отклонено с ошибкой о том, что адрес не принадлежит пользователю. Это защита от подделки внутри компании, и отключать её не нужно — нужно выдать право тем, кому оно положено.

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

Проверка после переезда

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

• каждый общий адрес получает письма
• каждый псевдоним доставляет в нужный ящик
• рассылки доходят всем участникам
• отправка от имени общего ящика работает
• правила Sieve раскладывают письма
• автоответы срабатывают один раз
• сайт, 1С и МФУ отправляют через новый сервер

Типичные ошибки

Все они встречаются в реальных переездах и все предотвращаются инвентаризацией.

• забыли старые адреса — клиенты получают отказы в доставке
• общий ящик перенесён, а права не выданы — отдел не видит заявки
• рассылка all@ открыта для внешних — спам во всех ящиках
• перенесли пересылки на личные ящики — утечка переписки продолжилась
• автоответы не восстановлены — клиенты ждут ответа от отпускников
• заявки с сайта уходят на несуществующий адрес

Адреса с плюсом и catch-all

Некоторые сотрудники пользуются адресами с плюсом: anna+bank@company.ru попадает в ящик anna@, а метка после плюса помогает фильтровать. Проверьте, поддерживает ли это новый сервер и с каким разделителем: в mailcow тегированные адреса работают из коробки и могут сами раскладывать письма по папкам — подробности в статье о тегированных адресах в mailcow.

Catch-all — ящик, который получает письма на все несуществующие адреса домена. Его иногда включают «чтобы ничего не терять», но на практике он собирает в основном спам и мешает заметить ошибку в адресе. Мы рекомендуем вместо catch-all завести явные псевдонимы для всех адресов, на которые реально приходят письма, — инвентаризация как раз даёт этот список.

Ящики уволенных сотрудников

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

Ящики, которые не нужны ни по содержанию, ни по адресу, не переносите вовсе, но выгрузите в архив перед отключением тарифа. Решение по каждому такому ящику запишите: через год никто не вспомнит, почему его не стало.

Порядок работ по дням

Перенос настроек идёт параллельно с переносом писем, но заканчиваться должен раньше переключения MX: в момент смены записи все адреса на новом сервере уже должны существовать.

• неделя до переключения: инвентаризация, опрос отделов, снимки экрана правил
• за 4–5 дней: общие ящики, псевдонимы и рассылки созданы на новом сервере
• за 3 дня: права на общие ящики выданы, отправка от имени проверена
• за 2 дня: правила Sieve и автоответы восстановлены
• день переключения: смена MX, тестовые письма на каждый адрес
• первая неделя: разбор обращений, уточнение правил

Что получает компания

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

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