Найти онлайн почтовый клиент,с MS-365 и форвардом на внешние адреса

Приветствую!
Возвращаюсь с апдейтом ))
Для тестов взял чистый лаптоп и привязал его к своей учётке, которая принадлежит к пулу экаунтов со стороны клиента, о котором идёт речь в задаче. Клиент использует MS решения (Share point, MS server, Azure и так далее)

Заняло какое-то время "легализовать" машину и получить все "галочки". Политика компании достаточно строгая - необходимо, что всё совпадало, начиная от антивируса и до шифрования диска машины битлокером. В итоге всё ОК, машина была одобрена и.. я прочесал кучу возможных и невозможных майл клиентов. 

Если не акцентировать внимание на всяких мелочах (например Мозилла пробует провести сейчас аутентификации через встроенный бразуер, со стороны клиента система не может этот встроенный браузер идентифицировать как браузер из списка разрешённых и не даёт доступ), то после удачной настройки и получения доступа к почте, результат выходит всегда один - по Ouath2 почта работает, авторизоваться можно, письма приходят и уходят. 

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

Итак, как только создаю правило, тестирую..... происходит отбой на стороне клиента со следующим сообщением:

Remote Server returned "550 5.7.520 Access denied, Your organization does not allow external forwarding. Please contact your administrator for further assitance. AS(7555)"

Мне на данном этапе видны два варианта: 

(1) Найти какой нибудь "магический" майл клиент, которые умеет без обращения к серверу со стороны клиента, который не даёт проводить форвардинг, сможет осуществлять форвардинг на своё локальном уровне.... Я сомневаюсь по поводу такого решения - я не знаю досконально всех нюансов работы почты, но т.к. как конечной задачей является не просто пересылка письма любой ценой, а пересылка по типу redirect, когда не изменяются данные того, от кого пришло письмо, то даже если и будет решение которое сможет пересылать, без обращения к серверу (который на данный момент запрещает пересылку), то, что произойдёт с адресом отправителя? Адрес отправителя нужен, в противном случае (если все письма будут с одного адреса) хелпедеск система, ради которой я и затеял всю эту движуху, не сможет нормально работать

(2) Второй вариант - перестать искать "философский камень" и просто попросить админов со стороны клиента отсрочить переход на Ouath2 до конца года. Это возможно, об это есть достаточно свежая статья от MS и вроде где-то в ноябре/декабре подоспеет и главный герой - товарищи из хелпдеск программы собираются завершить внедрение Ouath2 со своей стороны и это решит все текущие вопросы. Минус такого варианта - любые обращения к админам клиента это огромный геморой и я бы по прежнему предпочёл его оставить только на самый крайний случай. С другой стороны, приближаясь к концу месяца и вроде как к завершению поддержки простого IMAP не остаётся особых вариантов

(3) У меня третьего варианта нет, но если у вас есть какие-нибудь рабочие, альтернативные идеи, то я с удовольствием готов их рассмотреть! 🙂

Вот, теперь всё ))

Доброй ночи и спасибо за внимание к моей задаче 👍