Комментарии 6
Пропущен вариант с использованием дополнительного элемента — ретранслятора почты.
На нем и рисуется правила форвардинга почты, для отдельных ящиков, на новый почтовик или на старый.
Он же и выступаем единственным MX для домена.
После окончательной миграции на новый почтовик — меняются MX на новый сервер, а ретранслятор понижается до backup MX.
Для пущей надежности можно использовать два хоста-ретранслятора, один из них сугубо backup MX.
На нем и рисуется правила форвардинга почты, для отдельных ящиков, на новый почтовик или на старый.
Он же и выступаем единственным MX для домена.
После окончательной миграции на новый почтовик — меняются MX на новый сервер, а ретранслятор понижается до backup MX.
Для пущей надежности можно использовать два хоста-ретранслятора, один из них сугубо backup MX.
Использование ретранслятора почты — это, скорее, альтернативный способ осуществления маршрутизации почтовых сообщений. Наличие третьей почтовой системы позволяет решить проблему сосуществования почтовых систем в случае, если основные почтовые системы не обладают необходимым функционалом по пересылке сообщений.
Описанная мною схема позволяет избавиться от дополнительной почтовой системы, при условии, что текущая и будущая системы обладают необходимым функционалом для осуществления такого сосуществования.
Описанная мною схема позволяет избавиться от дополнительной почтовой системы, при условии, что текущая и будущая системы обладают необходимым функционалом для осуществления такого сосуществования.
А теперь оцените трудоемкость каждого метода.
Вписать пару строчек на ретрансляторе быстрее, чем править конфиги двух МХ-хоста.
Вписать пару строчек на ретрансляторе быстрее, чем править конфиги двух МХ-хоста.
Если ретранслятор есть, то его использование для решения этой задачи оправдано и очевидно.
Если ретранслятора нет, то потребуется выделение ресурсов для его установки. Сама установка и первоначальная настройка ретранслятора также займет время. Несмотря на наличие ретранслятора, Вам все равно придется вносить изменения в настройки почтовых систем для организации двойной доставки. Создание дочернего домена является более простой задачей, чем настройка ретранслятора и переключение основного MX на него.
У каждого решения есть удачные и неудачные области применения. Выбор того или иного способа организации сосуществования очень сильно зависит от текущей архитектуры почтовой системы, выбора конечной почтовой системы и требований заказчика к функционированию на этом этапе.
Если ретранслятора нет, то потребуется выделение ресурсов для его установки. Сама установка и первоначальная настройка ретранслятора также займет время. Несмотря на наличие ретранслятора, Вам все равно придется вносить изменения в настройки почтовых систем для организации двойной доставки. Создание дочернего домена является более простой задачей, чем настройка ретранслятора и переключение основного MX на него.
У каждого решения есть удачные и неудачные области применения. Выбор того или иного способа организации сосуществования очень сильно зависит от текущей архитектуры почтовой системы, выбора конечной почтовой системы и требований заказчика к функционированию на этом этапе.
Брррр.
Вы взяли две непростые почтовые системы — gmail и m$ exchange, намеренно не использовали backup MX (как без этого в продакшене, я не понимаю), добавили лишние сущности в виде поддомена и отправки СС.
Создание дочернего поддомена еще больше усложняет.
Покопайтесь в своих почтовых системах, и разберитесь, как выставить приоритеты доставки:
1) если есть почтовый ящик, то слать почту туда
2) если домен локальный, но нет почтового ящика — то слать на ретранслятор
3) если домен нелокальный, то или отлуп или отправка от себя.
Настройка ретранслятора займет 5-15 минут.
1) купить или развернуть линукс|FreeBSD
2) поставить свежий sendmail
3) скачать конфиги со своей библиотеки (или нагуглить)
4) подправить под текущую задачу
5) подправить MX записи у домена
А если бы взяли и почитали старую книгу Немет — «UNIX. Руководство системного администратора», то б узнали, как мигрировать большие почтовые системы с с минимумом простоя. Эти рецепты еще с середины 90-х!
Вы взяли две непростые почтовые системы — gmail и m$ exchange, намеренно не использовали backup MX (как без этого в продакшене, я не понимаю), добавили лишние сущности в виде поддомена и отправки СС.
Создание дочернего поддомена еще больше усложняет.
Покопайтесь в своих почтовых системах, и разберитесь, как выставить приоритеты доставки:
1) если есть почтовый ящик, то слать почту туда
2) если домен локальный, но нет почтового ящика — то слать на ретранслятор
3) если домен нелокальный, то или отлуп или отправка от себя.
Настройка ретранслятора займет 5-15 минут.
1) купить или развернуть линукс|FreeBSD
2) поставить свежий sendmail
3) скачать конфиги со своей библиотеки (или нагуглить)
4) подправить под текущую задачу
5) подправить MX записи у домена
А если бы взяли и почитали старую книгу Немет — «UNIX. Руководство системного администратора», то б узнали, как мигрировать большие почтовые системы с с минимумом простоя. Эти рецепты еще с середины 90-х!
Я не понимаю, чего Вы хотите добиться своими комментариями. То, что предложенная Вами схема имеет право на существование я сразу согласился. Если Вы считаете, что это единственно верный вариант реализации данной задачи, то я с Вами категорически не согласен. Имея несколько вариантов решения можно выбирать, какой из них лучше подходит в разных условиях. Поэтому любое решение, имеет право на существование, даже если оно очень узко специализированное.
В описанной мной схеме я не отталкивался от наличия backup MX сервера, он может быть, его может не быть, это принципиально не изменяет схему маршрутизации сообщений. Для конкретно этой ситуации с MS Exchange и Google Apps наличие backup MX после миграции в Google Apps избыточно, так как Google Apps и так предоставляет свои backup MX сервера. По своему опыту могу сказать, что мне значительно реже попадаются системы, у которых есть backup MX сервер, Ваш опыт может отличаться от моего.
Вы описали раздельную доставку с использованием ретранслятора. У меня описана раздельная доставка и двойная доставка без использования ретранслятора. Мне известно, как настраивать приоритеты доставки. Я позволю себе не описывать процесс создания дополнительной доменной зоны. Добавление дополнительного домена занимает не больше времени.
Вы предлагаете добавить сервер, я предлагаю добавить дополнительный домен. В обоих этих случаях мы усложняем систему и добавляем сущности. Добавляя домен, мне не нужно беспокоиться и решать проблему его доступности, так как для этого используется сервис DNS, в котором и так уже заложена отказоустойчивость. Поддержка дополнительного домена требует меньше вычислительных ресурсов, и человеко-часов инженера, чем новый сервер. В случае настройки двойной доставки с использованием дополнительного домена нет необходимости вносить значимые изменения в конфигурацию почтовой системы и доменных имен. Согласование переноса основной MX записи с одного сервера на другой в некоторых организациях согласовывается по несколько дней. В случае же использования дополнительного домена такие согласования на данном этапе вообще не нужны и можно быстро настроить вторую почтовую систему. Перенос MX записи понадобится, но только один раз, со старой системы на новую, без промежуточного этапа.
Описанная мною схема не требует простоя в работе электронной почты.
В описанной мной схеме я не отталкивался от наличия backup MX сервера, он может быть, его может не быть, это принципиально не изменяет схему маршрутизации сообщений. Для конкретно этой ситуации с MS Exchange и Google Apps наличие backup MX после миграции в Google Apps избыточно, так как Google Apps и так предоставляет свои backup MX сервера. По своему опыту могу сказать, что мне значительно реже попадаются системы, у которых есть backup MX сервер, Ваш опыт может отличаться от моего.
Вы описали раздельную доставку с использованием ретранслятора. У меня описана раздельная доставка и двойная доставка без использования ретранслятора. Мне известно, как настраивать приоритеты доставки. Я позволю себе не описывать процесс создания дополнительной доменной зоны. Добавление дополнительного домена занимает не больше времени.
Вы предлагаете добавить сервер, я предлагаю добавить дополнительный домен. В обоих этих случаях мы усложняем систему и добавляем сущности. Добавляя домен, мне не нужно беспокоиться и решать проблему его доступности, так как для этого используется сервис DNS, в котором и так уже заложена отказоустойчивость. Поддержка дополнительного домена требует меньше вычислительных ресурсов, и человеко-часов инженера, чем новый сервер. В случае настройки двойной доставки с использованием дополнительного домена нет необходимости вносить значимые изменения в конфигурацию почтовой системы и доменных имен. Согласование переноса основной MX записи с одного сервера на другой в некоторых организациях согласовывается по несколько дней. В случае же использования дополнительного домена такие согласования на данном этапе вообще не нужны и можно быстро настроить вторую почтовую систему. Перенос MX записи понадобится, но только один раз, со старой системы на новую, без промежуточного этапа.
Описанная мною схема не требует простоя в работе электронной почты.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Миграция и сосуществование почтовых систем