История изменений

Если можно можно

Оба сервера считают домен своим. Что означает, что они оба по умолчанию никуда смотреть не станут. Нет пользователя - до свидания.

Сейчас если я пишу с тестового пользователя на новом серваке письмо пользователю который есть на старом сервере - я получаю отлуп

Поэтому я написал, что ситуация зеркальная. «Оба сервера считают домен своим.» И на первом и на втором сервере для всех несуществующих дл них пользователей нужно прописывать отдельный транспорт на другой сервер.

те на первом сервере , допустим, есть юзеры

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

Млин уже лень все расписывать, на самом деле тут задача как перевести через реку овцу , волка и капусту.

Могу бесплатно проконсульировать в телеге или голосом, так будет быстрее, чем мне сейчас сидеть и прикидывать все ваши возможные исходные данные.

Если можно можно

Оба сервера считают домен своим. Что означает, что они оба по умолчанию никуда смотреть не станут. Нет пользователя - до свидания.

Сейчас если я пишу с тестового пользователя на новом серваке письмо пользователю который есть на старом сервере - я получаю отлуп

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

те на первом сервере , допустим, есть юзеры

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

Млин уже лень все расписывать, на самом деле тут задача как перевести через реку овцу , волка и капусту.

Могу бесплатно проконсульировать в телеге или голосом, так будет быстрее, чем мне сейчас сидеть и прикидывать все ваши возможные исходные данные.