Исправление constin, (текущая версия) :
Если можно можно
Оба сервера считают домен своим. Что означает, что они оба по умолчанию никуда смотреть не станут. Нет пользователя - до свидания.
Сейчас если я пишу с тестового пользователя на новом серваке письмо пользователю который есть на старом сервере - я получаю отлуп
Поэтому я написал, что ситуация зеркальная. «Оба сервера считают домен своим.» И на первом и на втором сервере для всех несуществующих дл них пользователей нужно прописывать отдельный транспорт на другой сервер.
те на первом сервере , допустим, есть юзеры
user1@domain.com , user2@domain.com
а на втором есть юзеры user3@domain.com и user4@domain.com
тогда: на первом сервере должно быть прописано, что для user3 и user4 транспорт на второй сервер. а на втором сервере должно быть прописано, что user1 и user2 транпорт на первый сервер.
Мне не очень понятно почему " перечислять ящики вручную в transport_maps - не вариант." Вы собираетесь переносить пользователей по кучками. Добавлять перенесенных в transport_maps по чуть-чуть как раз самый лучший вариант. Остальные варианты - ненужные велосипеды.
Если использовать transport_maps , то можно сделать так:
и так у нас есть юзеры user1@domain.com…. user100domain.com
переносим user1domain.com..user10domain.com на новый сервер.
тогда на старом сервере пишем, в transport_maps что user1/user2/user3..user10domain.com идут на второй сервер.
А на втором сервере пишем чутка по другому:
user1/user2/user3..user10domain.com идут в local delivery
а вот весь остальной домен @domain.com идет на старый сервер.
таким образом не все так плохо с transport_maps, трудозатраты на прописывание юзеров там минимальный по сравнению с самой миграцией. и если пользователей меньше 1000, то я бы советовал именно этот вариант.
после полной миграции все это убирается.
второй вариант, тоже transport_map, но не текстовый файл, а ldap реквест. тоде самое, только правила должны быть прописаны в ldap. имхо никакой выгоды, но если юзеров очень-очень много, то возможно это проще автоматизировать.
третий вариант про несуществующих юзеров. luser_relay
я не использовал никогда. но суть в том, что мы пересылаем всех несуществуюзщих юзеров с *@domain.com на *@domain2.local
domain2.local нам нужен временно. domain2.local должен быть прописан у второго сервера как обслуживаемый домен. при этом письмо , пришедшее на user@domain2.com должно падать в ящик user@domain.com
Млин уже лень все расписывать, на самом деле тут задача как перевести через реку овцу , волка и капусту.
Могу бесплатно проконсульировать в телеге или голосом, так будет быстрее, чем мне сейчас сидеть и прикидывать все ваши возможные исходные данные.
Исходная версия constin, :
Если можно можно
Оба сервера считают домен своим. Что означает, что они оба по умолчанию никуда смотреть не станут. Нет пользователя - до свидания.
Сейчас если я пишу с тестового пользователя на новом серваке письмо пользователю который есть на старом сервере - я получаю отлуп
Поэтому я написал, что ситуация зеркальная. И на первом и на втором сервере для всех несуществующих дл них пользователей нужно прописывать отдельный транспорт на другой сервер.
те на первом сервере , допустим, есть юзеры
user1@domain.com , user2@domain.com
а на втором есть юзеры user3@domain.com и user4@domain.com
тогда: на первом сервере должно быть прописано, что для user3 и user4 транспорт на второй сервер. а на втором сервере должно быть прописано, что user1 и user2 транпорт на первый сервер.
Мне не очень понятно почему " перечислять ящики вручную в transport_maps - не вариант." Вы собираетесь переносить пользователей по кучками. Добавлять перенесенных в transport_maps по чуть-чуть как раз самый лучший вариант. Остальные варианты - ненужные велосипеды.
Если использовать transport_maps , то можно сделать так:
и так у нас есть юзеры user1@domain.com…. user100domain.com
переносим user1domain.com..user10domain.com на новый сервер.
тогда на старом сервере пишем, в transport_maps что user1/user2/user3..user10domain.com идут на второй сервер.
А на втором сервере пишем чутка по другому:
user1/user2/user3..user10domain.com идут в local delivery
а вот весь остальной домен @domain.com идет на старый сервер.
таким образом не все так плохо с transport_maps, трудозатраты на прописывание юзеров там минимальный по сравнению с самой миграцией. и если пользователей меньше 1000, то я бы советовал именно этот вариант.
после полной миграции все это убирается.
второй вариант, тоже transport_map, но не текстовый файл, а ldap реквест. тоде самое, только правила должны быть прописаны в ldap. имхо никакой выгоды, но если юзеров очень-очень много, то возможно это проще автоматизировать.
третий вариант про несуществующих юзеров. luser_relay
я не использовал никогда. но суть в том, что мы пересылаем всех несуществуюзщих юзеров с *@domain.com на *@domain2.local
domain2.local нам нужен временно. domain2.local должен быть прописан у второго сервера как обслуживаемый домен. при этом письмо , пришедшее на user@domain2.com должно падать в ящик user@domain.com
Млин уже лень все расписывать, на самом деле тут задача как перевести через реку овцу , волка и капусту.
Могу бесплатно проконсульировать в телеге или голосом, так будет быстрее, чем мне сейчас сидеть и прикидывать все ваши возможные исходные данные.