Назад | Перейти на главную страницу

Outlook 2013 создает фиктивные записи x500 при отправке электронной почты

У меня очень странная проблема, которую я потратил последние 6 недель на поиски в Google, исследования и попытки исправить разные вещи, но безрезультатно. Любая помощь будет принята с благодарностью.

Наше окружение:

Мы запускаем один сервер Exchange 2010 - последний пакет обновления / полностью исправлен. Все клиенты - это Outlook 2013, некоторые из них работают в режиме кеширования, некоторые нет. Мы находимся в процессе колеблющегося перехода на Exchange 2013. Мы завершили обновление с 2003 до 2010 года и планируем перейти на 2013 год в начале следующего года. У нас есть дочерняя компания - отдельный почтовый сервер, домен, пространство имен, сеть и т. Д. Однако у нас есть двусторонняя транзитивная установка доверия между нашими двумя доменами. Что касается обмена, то это просто еще один иностранный получатель. Каждую ночь мы запускаем стороннюю программу под названием GALSync, которая отправляет им по электронной почте определенную информацию о пользователях, а они, в свою очередь, отправляют нам по электронной почте некоторые из своих данных. Эта информация импортируется в наш глобальный список адресов в виде почтовых контактов. Это пережиток эпохи 2003 года, и я не уверен, что сейчас нет лучшего способа сделать это, но на данный момент он существует и функционирует.

Эта проблема.

Случайно пользователь отправит электронное письмо кому-то из нашей дочерней компании и получит отчет о недоставке 5.1.1 для адреса x500, который полностью неверен. Фактически он заменяет доменную часть электронного письма нашим внутренним доменным именем. Этот адрес не существует и никогда не существовал в нашем домене.

Пример:

Пользователь JaneDoe@internalname.com пишет на адрес JoeSmith@sistercompany.com В отчете о недоставке указано IMCEAEX-_O=!!OURCOMANY!!_OU=EXCHANGE+20ADMINISTRATIVE+20GROUP+20+28FYDIBOHF23SPDLT+29_CN=RECIPIENTS_mith1@JinoeSternal.com

Обратите внимание на «1» после имени и в конце, а также на то, как @ был изменен на наше внутреннее имя.

JoeSmith@internalname.com или любые варианты с 1 или любым другим номером никогда не существовали в нашей компании. Поиск с помощью PowerShell для всех почтовых ящиков и контактов LegacyExchangeDNS показывает, что он не выходит из любого места в AD.

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

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

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

Проблема не возникает ни с одним другим адресом.

Спасибо за уделенное время.