Перенаправить почту на другой сервер если нет получателя на текущем

перечислять ящики вручную в transport_maps - не вариант.

Можно же не вручную,а там же в ldap

Но если не через transport_map, то можно luser_relay , создав времененный несуществующий перевалочный домен, который будет алиасом на новом сервера. те на новом сервере юзеры имеют нормальный домен, но еще и перевалочный, как алисас.

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

честно - ничего не понял. Если можно - как для дурачка, я с постфиксом не дружу, но вот попросили сделать.

Вобщем конфиг такой - есть новый, пока тестовый, сервер с постфиксом с бакэндом в LDAP, есть старый, рабочий, сервер с бакэндом в MySQL. Нужно пользователей пересадить со старого сервера на новый. В LDAP есть пара тестовых пользователей, между ними переписка идёт без проблем. Хотим поставить сервак с LDAP’ом первым, и по очереди переносить на него пользователей. Соответственно нужно иметь возможность переслать почту на старый сервер, для тех пользователей которые пока не перенесены.

Сейчас если я пишу с тестового пользователя на новом серваке письмо пользователю который есть на старом сервере - я получаю отлуп, пользователь не найден. Т.е. после поиска в LDAP идёт остановка и баста. Возможно ситуация осложняется тем что это virtual_domain, с точки зрения postfix

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

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

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

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

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

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

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

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

Премного благодарен. Теперь понятен и смысл действий и процесс.

Я тут пока гуглил где-то наткнулся на совет сделать скрипт который для существующих пользователей будет возвращать этот самый local:, а для несуществующих адрес сервера куда перенаправлять. Но там была убитая ссылка и я больше нигде ничего подобного не нашёл. Это был бы идеальный вариант для меня. Просто переводом будет заниматься, не то чтобы первая линия, там люди вообще по ошибке попали в IT отдел, их командная строка в ступор вводит. Может ткнёте носом в мануал как можно к transport_map прикрутить такой скрипт? Сам скрипт я уж накидаю

тебе не нужно удалять нигде пользователей.

вот правильный алгоритм.

1. ты создаешь всех пользователей на втором сервере.( но пока никому не даешь туда доступ)

2. ты делаешь предварительный imapsync всех пользователей с первого сервера на второй. это большой объем и долго. это нужно сделать, чтобы потом досинхронизация занимала уже секунды или пару минут.

3. ты решаешь перенести на второй сервер например двух или 20 или 40 пользователей. тогда для них ты делаешь еще один imapsync с правилом «если на приемнике письмо существует, а на источнике его нет, то письмо на приеммнике надо удалить» те у тебя на втором сервере получается полная и актуальная копия ящика с первого сервера.

прописываешь этого этого юзера на первом сервере в транспорт редирект на второй сервер.

прописываешь на втором сервере этого юзера в транспорт что доставка локальная , а весь остальной домен маской редирект на первый сервер.

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

все. юзер переведен на новый сервер и все работает

повторяешь тоже самое с остальными юзерами. можно пачками.

когда все готово , то выключаешь первый сервер и удаляешь весь transport map на втором сервере. те он по умолчанию начинает складывать ВСЕХ юзеров локально.

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

Ещё раз спасибо. Что делать - понятно, как делать - понятно. Почитаю, потренируюсь на кошках и поедем.

Вопрос от меня, если синкаем, например, с GSuite на свой сервак (хостнеймы разные, понятно), тогда по логике достаточно такого

1. Создать домен на принимающем self-hosted серваке, но пока не трогать MX'ы

2. imapsync с GSuite на свой сервак. Насколько позволит пропускная способность сети и железо. Потихоньку делаем первичную синхронизацию

3. Вторичная синхронизация доливаем остатки писем, которые образовались за период между началом синхронизации первых учёток и окончанием синхронизации для последних.

4. Разворачиваем MX на новый хостнейм.

Это, скорее, набросок для себя, но может я что-то упустил в этом списке?

Подскажите.

да нет, все ок. гугл сьют умеет вроде в маршрутизации отдельных ящиков. но сразу всех юзеров фигануть на практике не получается из-за настроек почтовых клиентов, так как редко бывает, что они идентичны на обоих серверах.

поэтому все эти танцы с состоянием, когда мы в процессе миграции. это может занимать несколько недель. в зависимости от сил и объема.

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

в целом это имхо один из самых часто встречаемых и простых кейсов, дающих понимание маршрутизации почты.