Миграция корпоративной почты при переносе домена от хостера к хостеру. Возможна ли?

Question

[I.CaR Soft]

(повторный, более развёрнутый вопрос)
Дано:

корпоративная почта на домене @org-name.ru (примеры: [e-mail], [e-mail] и т.п.)
доменное имя "org-name.ru" будет переносится на другой хостинг с бо́льшим пространством под почту (*опыт есть).
с предыдущим хостинг-провайдером будут полностью остановлены все предоставляемые сервисы.

Задача: Перенести всю почту. (*опыта ноль).
Принимающий провайдер подсказал про синхронизацию, и "консультирование по переносу корпоративной почты не даём".
Здесь мне непонятен нюанс с адресами. Т.е. в моменте нужно как-то настроить миграцию(синхронизацию) по IMAP с почты: [e-mail] (одного провайдера) на точно такую же [e-mail], но уже на новом месте.
Такое как может сработать?
Ещё у меня есть доступ к файловой системе почты на отдающем хостинге. А на принимающем нет.
Есть ли ПО выполняющее такие задачи?
Ещё мысль возникла с "посредниками", т.е. для каждого e-mail делать "брата" [e-mail], синхронизировать по IMAP, удалять на e-mail(аккаунт) на отдающем. И опять же повторно синхронизировать с по IMAP c временным, удалять временный. И как я понимаю IMAP не передаёт файлы, как POP3, а они висят все на сервере. А значит при удалении источника, не потеряю ли я информацию организации, хранящуюся в почтовых отправлениях? Или использовать SMTP и POP3.
В общем для кого-то задача возможно и простая, а для кого-то и не очень. Прошу помочь либо советом (инструкциями) либо дать ссылку на ПО для миграции почты.

P.S. Систему управление на хостингах разные. Одна IPS manager, вторая от "Бегет".

Comments

[Everything_is_bad]

рекомендация всё так же, нанять нормального сисадмина для выполнения этой работы.

[AUser0]

BTW, SMTP и POP3 и IMAP передают письмо. Если к письму добавлены файлы - они тоже передаются, поскольку вписаны в тело письма.

Ну и собственно изучайте меню обоих ISP-менеджеров, есть там экспорт и импорт в одинаковых форматах, или нет?

[AUser0]

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

[I.CaR Soft]

Everything_is_bad, сисадмина, нормального? Вы всегда так отвечаете на поставленные перед вами вопросы?
Если не знаете ответ, зачем пишите ерунду?

[Everything_is_bad]

I.CaR Soft, почему ты решил что это ерунда, по твоим вопросам же видно, что для решения данной проблемы у тебя не хватает компетенции, поэтому привлечение специалиста очень хороший вариант. Ну и сразу, это коммент, а не ответ на вопрос, ты разницу понимаешь?

[Alexey Dmitriev]

I.CaR Soft, а вам вероятно стоит изучить https://qna.habr.com/help/rules и в частности п.5.12.
Ответ от Everything_is_bad - "нанять специалиста" в связи с вероятным отсутствием у вас базовых знаний по гуглению ответа на ваш простой вопрос и понимания - возможно это вообще или нет, единственно правильный в такой ситуации.

[Евгений Хлебников]

I.CaR Soft, знание как сделать правильно - бОльшая часть обязанностей и работы сисадмина, поэтому вам советуют обратиться к специлисту. Это всегда выглядит "так это же просто" когда знаешь что делать.

[I.CaR Soft]

Everything_is_bad, да вашему стилю общения уже понятен уровень воспитания. С неизвестным вам человеком на "ты".
Хоть ответ, хоть комментарий не уместен.
Вы чувствую всеми компетенциями в ИТ "владеете", хотя с большей вероятностью, лишь ветер в пустую дуете.
Повторю, что КПД вашего хоть ответа, хоть комментария равен нулю.
Компетентные хотя бы на решение укажут. Не думаю что программист не сможет справится с переносом корп.почты.
Знайте что люди, тех кто умничает, не любят. Вы один из оных.
Просьба покинут мой вопрос. И не отвлекать людей от работы пустыми комментариями.

[Everything_is_bad]

I.CaR Soft, не нужно вываливать сюда бред, возникший в результате подгорания твоего зада. Пойми, что делегирование работы при отсутствие компетенции, это нормально практика.

Не думаю что программист не сможет справится с переносом корп.почты.

стандартное "тыж программист", а ну и старого - "любой водитель способен починить свой автомобиль"

Answer 1

[hint000]

Плоховато с планированием, возможно потому, что плоховато с пониманием бизнес-процессов.

Для текущей работы компании важнее что - архив старых писем или новые письма, которые приходят прямо в эту минуту? В 99% рабочих ситуаций важнее новые письма. Вам нужно в первую очередь планировать действия так, чтобы вся новая почта куда-то дошла и была доступна сотрудникам, а не пропала в "безвременье", когда старый почтовик уже недоступен, а новый ещё не совсем доступен из-за какой-то упущенной детали. Поэтому при правильном планировании у вас должен быть промежуток времени, когда доступны одновременно старый и новый почтовые сервера. Причём, доступны как для ваших пользователей, так и для внешнего мира, из которого вам что-то присылают.
Для внешнего мира это означает всего лишь две MX-записи в DNS. Потом вы поменяете приоритет этих записей. Дождётесь обновления во внешнем мире. Потом снова оставите только одну запись. До этого нужно прочитать и понять, как работают приоритеты MX.

Отдельно планируете, в какой момент вы замените исходящий сервер на новый. Тут совсем другая история, при замене исходящего никакая внешняя почта не потеряется, уже проще. Но зато нужно подумать о SPF, DKIM, DMARC, которые влияют только на отправку во внешний мир.

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

Итак. Напишите подробный план действий, обязательно. Сделайте это самостоятельно, полагайтесь не на чужие инструкции, а на собственное понимание. У всех организовано не одинаково и без понимания чужие инструкции могут ввести в заблуждение. А вот читать теорию до просветления, написать свой план, потом прийти сюда и сказать, "чуваки, у меня такой план, укажите на ошибки если они есть" - это бы совсем другое дело.
Из вышесказанного, ваш план на самом верхнем уровне будет состоять из трёх пунктов: (1) перенос входящего SMTP, (2) перенос исходящего SMTP, (3) перенос архива старых писем. Не зацикливайтесь на третьем пункте, он наименее важный.

Answer 2

[99insania99]

Выбрать изначально нормального хостера, где можно поднять такую-же конфигурацию почтовика как в предыдущем. У isp менеджера это вроде exim+dovecot.
Перенести все конфиги и ящики. Поменять на корректные mx, dmarc, dkim, ptr записи.
Проверить через https://mxtoolbox.com/SuperTool.aspx почтовик, что все записи и настройки правильные, иначе письма будут реджектится на всех нормальных почтовых сервисах.

Comments

[I.CaR Soft]

Очень согласен с "выбирать изначально нормального хостера". Выбор был сделан до меня. Я человек новый в организации. И да, поторопился. Перенос доменного имени прежде создания корп.почты решил бы эту проблему. Т.е. она бы и не возникла.
Сейчас под навалившимися проблемами и решил увести организацию, от местного хостера.
Буду разбираться, и думаю, это будет полезным опытом или крахом в карьере.

Answer 3

[Dmitry]

Если на source ещё работает сервис то можно использовать imapsync.

Answer 4

[Евгений Хлебников]

1. обратите внимание на ответ hint000, мне кажется, его мнение будет полезно.

Я бы предложил следующий подход:
1. Полная настройка почтового сервера на новом хостинге. (SPF, DKIM, проверка в спам базах и тд и тп) - полноценная. Завести все почтовые ящики, аналогично имеющимся. Добавить в MX с более низким приоритетом. Проверить отправку почты через новый почтовый сервер (получать , из-за приоритетов MX он ее все равно не будет)
2. Подготовка к миграции почтовых ящиков. Хорошо, если есть локальные клиенты (не вебмейл) - часто у них есть возможность архивации, благодаря чему после перенастройки на новый сервис можно все довольно быстро восстановить - подготовить бэкап почтовых ящиков, персонально для каждого пользователя
3. миграция.
Если пользователей немного:
Переключаем MX, почта начинает идти на новый хостинг, но не сразу - часть писем придется ловить в старом и переносить дополнительно. Перенастраиваем почтовые клиенты на новый хостинг. Загружаем подготовленные архивы писем в клиенты.

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