Comments 24
Интересно, насколько сложный в реализации такой кейс:
Почта для домена у mail\яндекса\gmail, у клиента — The Bat! (5 версии) на POP3, без сохранения писем на сервере. И надо всё перевести на MS Exchange.
Почта для домена у mail\яндекса\gmail, у клиента — The Bat! (5 версии) на POP3, без сохранения писем на сервере. И надо всё перевести на MS Exchange.
На самом деле на хабре уже есть статья о переносе почтовых ящиков при помощи ImapSync. Утилита умеет докачивать новые письма, так что проблем с синхронизацией быть не должно.
Некоторое время займёт создание почтовых ящиков, прописывание скрипта с паролями на синхронизацию, и в дальнейшем после подмены MX записей можно будет добрать письма, но потом обязательно убрать переносимые почтовые домены с обслуживания, так как например Яндекс использует свой DNS сервер, и после смены MX записей на хостинге он их игнорирует. Так можно потерять часть писем отправляемых с Яндекса (или настроить периодический запуск скрипта под imapsync).
Клиентская почтовая программа по большому счёту роли не играет, так как exchange умеет в POP3 и IMAP, главное чтобы сервер источник умел отдавать письма по IMAP.
Некоторое время займёт создание почтовых ящиков, прописывание скрипта с паролями на синхронизацию, и в дальнейшем после подмены MX записей можно будет добрать письма, но потом обязательно убрать переносимые почтовые домены с обслуживания, так как например Яндекс использует свой DNS сервер, и после смены MX записей на хостинге он их игнорирует. Так можно потерять часть писем отправляемых с Яндекса (или настроить периодический запуск скрипта под imapsync).
Клиентская почтовая программа по большому счёту роли не играет, так как exchange умеет в POP3 и IMAP, главное чтобы сервер источник умел отдавать письма по IMAP.
Вы, видимо, не до конца прочувствовали всю боль — писем на сервере нет, есть только локальная копия на компьютере, где устаревший клиент Bat, а формат его базы данных менялся. и протокол не IMAP, который допускает синхронизацию с сервером, а POP3.
Если Bat позволяет выгружать письма в eml формат, и почтовый ящик 1, а не сотня, то это просто «выгрузить из Bat, загрузить в outlook». Для временного хранилища можно использовать общие папки, или в режиме Exchange сразу грузить всё в нужные папки. Вот если это у всех клиентов — надо уже изобретать скрипт автовыгрузки из бата, но и это в целом реализуемо с помощью 1 ПЯ с расширенными на всю базу правами.
А Вы теоретизируете или в самом деле знаете, что Outlook открывает eml просто для чтения, и только через промежуточное звено в виде Express можно через IMAP пульнуть письмо на сервер?
Попутал с .msg файлами, моя ошибка. Нашёл нечто подходящее на StackOverflow. Гугл тоже показал несколько eml2msg конвертеров разной степени доверенности.
Задачка интересная, даже обидно, что сейчас другой почтовый сервер поддерживаю, было бы интересно получить такой опыт.
Задачка интересная, даже обидно, что сейчас другой почтовый сервер поддерживаю, было бы интересно получить такой опыт.
Делал подобный перенос… Поначалу тоже думал, что ситуация тупиковая.
Решение (ручное):
1.Создаем в самом Bat-е еще один аккаунт, только IMAP, и настройками на новый сервер.
2.Создаем в новом аккаунте нужную структуру папок.
3.Вручную, небольшими частями (писем по 50-100) копируем письма между папками разных почтовых аккаунтов Bat-а.
Все!
Решение (ручное):
1.Создаем в самом Bat-е еще один аккаунт, только IMAP, и настройками на новый сервер.
2.Создаем в новом аккаунте нужную структуру папок.
3.Вручную, небольшими частями (писем по 50-100) копируем письма между папками разных почтовых аккаунтов Bat-а.
Все!
Не всё. После этого надо всем Outlook настроить. Иначе зачем Exchange.
Действенный метод, переносил также.
Две потенциальные проблемы:
у пользователя POP3-аккаунт может иметь очень большой размер, а почтовый ящик на сервере — ограничения;
нагрузка на сеть и вычислительные ресурсы почтового сервера.
IMHO, первая наиболее критична для почты на хостинге; на второй проблеме споткнулся при «переезде» с POP3 на IMAP почтового ящика объёмом более 20 ГБ на внутреннем почтовом сервере, который не справился с таким объёмом.
Две потенциальные проблемы:
у пользователя POP3-аккаунт может иметь очень большой размер, а почтовый ящик на сервере — ограничения;
нагрузка на сеть и вычислительные ресурсы почтового сервера.
IMHO, первая наиболее критична для почты на хостинге; на второй проблеме споткнулся при «переезде» с POP3 на IMAP почтового ящика объёмом более 20 ГБ на внутреннем почтовом сервере, который не справился с таким объёмом.
Про ФЗ-242 интересно — кто-то реально переносит почту из-за этого? Странный кейс — почта обычно не является базой данных, не используется для сбора ПДн, поэтому по идее требование локализации не распространяется на почтовую систему.
UFO just landed and posted this here
Информационной системой персональных данных может быть не только «база данных», а в обработку персональных данных входит не только «сбор». Часто в почтовой системе фигурируют данные сотрудников (имя, фамилия, мобильный телефон), сюда же присылают анкеты соискателей для HR, сканы документов, информацию для заказа пропусков и так далее. Поэтому, персональные данные в почтовой системе в 99% случаев есть.
Конечно, можно запретить сотрудникам делать подписи, имена ящиков сделать вида employee123@dtln.ru, удалять вложения к письмам, парсить текст письма на наличие ПДн..., но работать с такой почтовой системой будет не удобно. Лично я бы не смог :)
Кстати в том же office 365 при регистрации содержится предупреждение о том, что все будет храниться не в РФ. Наверное, не просто так.
Конечно, можно запретить сотрудникам делать подписи, имена ящиков сделать вида employee123@dtln.ru, удалять вложения к письмам, парсить текст письма на наличие ПДн..., но работать с такой почтовой системой будет не удобно. Лично я бы не смог :)
Кстати в том же office 365 при регистрации содержится предупреждение о том, что все будет храниться не в РФ. Наверное, не просто так.
Из своего опыта скажу, что большие компании выбирают что-то типа Kaspersky Mail Security.
Это была ирония?
>High Availability. При отказе одного из серверов почтовые базы переедут на резервные. Конечный пользователь ничего не заметит. Эту схему можно реализовать и в рамках двух дата-центров.
Расскажите, пожалуйста, подробнее как вы в такой схеме переживаете не падение серверов (с этим-то все в порядке), а падение каналов между датацентрами, когда сервера в DAG кластерах перестают друг друга видеть. А вот клиенты, по странной стечению обстоятельств продолжают видеть все сервера.
Расскажите, пожалуйста, подробнее как вы в такой схеме переживаете не падение серверов (с этим-то все в порядке), а падение каналов между датацентрами, когда сервера в DAG кластерах перестают друг друга видеть. А вот клиенты, по странной стечению обстоятельств продолжают видеть все сервера.
Вопрос решается кворумом: как только члены DAG перестают видеть друг друга, происходит анализ кворума. Если количество серверов DAG и свидетельских сущностей, участвующих при подсчете, набирает кворум, то площадка остается рабочей, иначе – гаснет.
Чтобы избежать Split-brain, можно расположить свидетельские сущности на третьей площадке.
Интересно. Спасибо за опыт.
Вот только вопрос «из-за бугра ».
Я понимаю почему и зачем пользователи из РФ мигрируют свои данные ( и почту ) на отечественные площадки. Правильно это.
С интересом слежу за " избавлением от Microsoft -зависимости " в России. У нас в Германии сложно с этим. Давит монополист.
Но мигрировать почтовые системы из-за бугра и загонять в российские MS — Exchange? Где логика?
Вот только вопрос «из-за бугра ».
Я понимаю почему и зачем пользователи из РФ мигрируют свои данные ( и почту ) на отечественные площадки. Правильно это.
С интересом слежу за " избавлением от Microsoft -зависимости " в России. У нас в Германии сложно с этим. Давит монополист.
Но мигрировать почтовые системы из-за бугра и загонять в российские MS — Exchange? Где логика?
Здравствуйте.
Стратегически плохое решение. Гнать таких с офисных почтарей надо, и как можно скорее, а не ресурсов им добавлять. Если их не выгнать, то страдать все сотрудники будут. Сегдня миллион писем, затем 10М.
Офисные почтари не предназначены для спам-рыссылок. Для подобных рассылок поднимайте отдельный сервер, на отдельной ip адресе. Хоть Exchange, хоть Exim, хоть hmailserver на ваш вкус и бюджет заказчика. Или вообще выводите эти рассылки на специализированные сервисы.
забыл рассказать про то, что их маркетинг ежедневно рассылает миллионы писем
инфраструктура новой почтовой системы “прилегла”. Пришлось на ходу делать ресайзинг системы
Стратегически плохое решение. Гнать таких с офисных почтарей надо, и как можно скорее, а не ресурсов им добавлять. Если их не выгнать, то страдать все сотрудники будут. Сегдня миллион писем, затем 10М.
Офисные почтари не предназначены для спам-рыссылок. Для подобных рассылок поднимайте отдельный сервер, на отдельной ip адресе. Хоть Exchange, хоть Exim, хоть hmailserver на ваш вкус и бюджет заказчика. Или вообще выводите эти рассылки на специализированные сервисы.
High Availability. При отказе одного из серверов почтовые базы переедут на резервные. Конечный пользователь ничего не заметит.
В нашем окружении при миграции базы все клиенты теряют на минуту связь с почтовой службой и выводят сообщение типа «я стал автономным!»
Такое пользователи ещё как заметит. Может подсажет кто-нибудь рецепт как избавиться? Мы устали тысячам пользователей объяснять каждый раз при своих работах (плановых и не очень) что Outlook не обязан держать сервер на связи.
Sign up to leave a comment.
Операция “Миграция”: если ваша почта где-то там, а надо, чтобы была здесь