Я не понимаю, чего Вы хотите добиться своими комментариями. То, что предложенная Вами схема имеет право на существование я сразу согласился. Если Вы считаете, что это единственно верный вариант реализации данной задачи, то я с Вами категорически не согласен. Имея несколько вариантов решения можно выбирать, какой из них лучше подходит в разных условиях. Поэтому любое решение, имеет право на существование, даже если оно очень узко специализированное.
В описанной мной схеме я не отталкивался от наличия backup MX сервера, он может быть, его может не быть, это принципиально не изменяет схему маршрутизации сообщений. Для конкретно этой ситуации с MS Exchange и Google Apps наличие backup MX после миграции в Google Apps избыточно, так как Google Apps и так предоставляет свои backup MX сервера. По своему опыту могу сказать, что мне значительно реже попадаются системы, у которых есть backup MX сервер, Ваш опыт может отличаться от моего.
Вы описали раздельную доставку с использованием ретранслятора. У меня описана раздельная доставка и двойная доставка без использования ретранслятора. Мне известно, как настраивать приоритеты доставки. Я позволю себе не описывать процесс создания дополнительной доменной зоны. Добавление дополнительного домена занимает не больше времени.
Вы предлагаете добавить сервер, я предлагаю добавить дополнительный домен. В обоих этих случаях мы усложняем систему и добавляем сущности. Добавляя домен, мне не нужно беспокоиться и решать проблему его доступности, так как для этого используется сервис DNS, в котором и так уже заложена отказоустойчивость. Поддержка дополнительного домена требует меньше вычислительных ресурсов, и человеко-часов инженера, чем новый сервер. В случае настройки двойной доставки с использованием дополнительного домена нет необходимости вносить значимые изменения в конфигурацию почтовой системы и доменных имен. Согласование переноса основной MX записи с одного сервера на другой в некоторых организациях согласовывается по несколько дней. В случае же использования дополнительного домена такие согласования на данном этапе вообще не нужны и можно быстро настроить вторую почтовую систему. Перенос MX записи понадобится, но только один раз, со старой системы на новую, без промежуточного этапа.
Описанная мною схема не требует простоя в работе электронной почты.
Если ретранслятор есть, то его использование для решения этой задачи оправдано и очевидно.
Если ретранслятора нет, то потребуется выделение ресурсов для его установки. Сама установка и первоначальная настройка ретранслятора также займет время. Несмотря на наличие ретранслятора, Вам все равно придется вносить изменения в настройки почтовых систем для организации двойной доставки. Создание дочернего домена является более простой задачей, чем настройка ретранслятора и переключение основного MX на него.
У каждого решения есть удачные и неудачные области применения. Выбор того или иного способа организации сосуществования очень сильно зависит от текущей архитектуры почтовой системы, выбора конечной почтовой системы и требований заказчика к функционированию на этом этапе.
Использование ретранслятора почты — это, скорее, альтернативный способ осуществления маршрутизации почтовых сообщений. Наличие третьей почтовой системы позволяет решить проблему сосуществования почтовых систем в случае, если основные почтовые системы не обладают необходимым функционалом по пересылке сообщений.
Описанная мною схема позволяет избавиться от дополнительной почтовой системы, при условии, что текущая и будущая системы обладают необходимым функционалом для осуществления такого сосуществования.
В описанной мной схеме я не отталкивался от наличия backup MX сервера, он может быть, его может не быть, это принципиально не изменяет схему маршрутизации сообщений. Для конкретно этой ситуации с MS Exchange и Google Apps наличие backup MX после миграции в Google Apps избыточно, так как Google Apps и так предоставляет свои backup MX сервера. По своему опыту могу сказать, что мне значительно реже попадаются системы, у которых есть backup MX сервер, Ваш опыт может отличаться от моего.
Вы описали раздельную доставку с использованием ретранслятора. У меня описана раздельная доставка и двойная доставка без использования ретранслятора. Мне известно, как настраивать приоритеты доставки. Я позволю себе не описывать процесс создания дополнительной доменной зоны. Добавление дополнительного домена занимает не больше времени.
Вы предлагаете добавить сервер, я предлагаю добавить дополнительный домен. В обоих этих случаях мы усложняем систему и добавляем сущности. Добавляя домен, мне не нужно беспокоиться и решать проблему его доступности, так как для этого используется сервис DNS, в котором и так уже заложена отказоустойчивость. Поддержка дополнительного домена требует меньше вычислительных ресурсов, и человеко-часов инженера, чем новый сервер. В случае настройки двойной доставки с использованием дополнительного домена нет необходимости вносить значимые изменения в конфигурацию почтовой системы и доменных имен. Согласование переноса основной MX записи с одного сервера на другой в некоторых организациях согласовывается по несколько дней. В случае же использования дополнительного домена такие согласования на данном этапе вообще не нужны и можно быстро настроить вторую почтовую систему. Перенос MX записи понадобится, но только один раз, со старой системы на новую, без промежуточного этапа.
Описанная мною схема не требует простоя в работе электронной почты.
Если ретранслятора нет, то потребуется выделение ресурсов для его установки. Сама установка и первоначальная настройка ретранслятора также займет время. Несмотря на наличие ретранслятора, Вам все равно придется вносить изменения в настройки почтовых систем для организации двойной доставки. Создание дочернего домена является более простой задачей, чем настройка ретранслятора и переключение основного MX на него.
У каждого решения есть удачные и неудачные области применения. Выбор того или иного способа организации сосуществования очень сильно зависит от текущей архитектуры почтовой системы, выбора конечной почтовой системы и требований заказчика к функционированию на этом этапе.
Описанная мною схема позволяет избавиться от дополнительной почтовой системы, при условии, что текущая и будущая системы обладают необходимым функционалом для осуществления такого сосуществования.