Баг: Exchange 2016 CU1 Edge

В недавно вышедшем Exchange 2016 CU1 обнаружился баг, который делает практически невозможным использование функции Recipient Validation. Для временного workaround есть 2 различных способа, но об этом чуть ниже.


Итак, как проявляется этот баг.

Внешний сервер отправитель подключается к нашему Edge серверу, пытается отправить письмо заведомо существующему получателю, а в ответ получает «550 5.1.10 RESOLVER.ADR.RecipientNotFound; Recipient not found by SMTP address lookup». В SMTP сессии это выглядит следующим образом:

И соответственно, тоже самое в транспортном логе:

2016-03-29T09:53:57.046Z,Connector,08D357B716EC2B3C,0,10.200.250.250:25,10.200.250.249:49575,+,,
2016-03-29T09:53:57.046Z,Connector,08D357B716EC2B3C,1,10.200.250.250:25,10.200.250.249:49575,>,"220 EX2016SRV04.E2016.Lab Microsoft ESMTP MAIL Service ready at Tue, 29 Mar 2016 12:53:56 +0300",
2016-03-29T09:54:01.662Z,Connector,08D357B716EC2B3C,2,10.200.250.250:25,10.200.250.249:49575,<,ehlo me,
2016-03-29T09:54:01.662Z,Connector,08D357B716EC2B3C,3,10.200.250.250:25,10.200.250.249:49575,>,250 EX2016SRV04.E2016.Lab Hello [10.200.250.249] SIZE 36700160 PIPELINING DSN ENHANCEDSTATUSCODES STARTTLS X-ANONYMOUSTLS X-EXPS NTLM 8BITMIME BINARYMIME CHUNKING XEXCH50 XSHADOW,
2016-03-29T09:54:06.503Z,Connector,08D357B716EC2B3C,4,10.200.250.250:25,10.200.250.249:49575,<,mail from:1@ya.ru,
2016-03-29T09:54:06.503Z,Connector,08D357B716EC2B3C,5,10.200.250.250:25,10.200.250.249:49575,*,08D357B716EC2B3C;2016-03-29T09:53:57.046Z;1,receiving message
2016-03-29T09:54:06.503Z,Connector,08D357B716EC2B3C,6,10.200.250.250:25,10.200.250.249:49575,>,250 2.1.0 Sender OK,
2016-03-29T09:54:15.237Z,Connector,08D357B716EC2B3C,7,10.200.250.250:25,10.200.250.249:49575,<,rcpt to:msft@e2016.lab,
2016-03-29T09:54:15.237Z,Connector,08D357B716EC2B3C,8,10.200.250.250:25,10.200.250.249:49575,*,Tarpit for '0.00:00:05' due to '550 5.1.10 RESOLVER.ADR.RecipientNotFound; Recipient not found by SMTP address lookup',
2016-03-29T09:54:20.245Z,Connector,08D357B716EC2B3C,9,10.200.250.250:25,10.200.250.249:49575,>,550 5.1.10 RESOLVER.ADR.RecipientNotFound; Recipient not found by SMTP address lookup,
2016-03-29T09:54:48.710Z,Connector,08D357B716EC2B3C,10,10.200.250.250:25,10.200.250.249:49575,<,quit,
2016-03-29T09:54:48.710Z,Connector,08D357B716EC2B3C,11,10.200.250.250:25,10.200.250.249:49575,>,221 2.0.0 Service closing transmission channel,
2016-03-29T09:54:48.710Z,Connector,08D357B716EC2B3C,12,10.200.250.250:25,10.200.250.249:49575,-,,Local


В итоге получается, что Edge сервер будет отклонять все письма в организацию, считая, что такого получателя нету. Чтобы убедиться, что проблема именно в недрах Exchange, можно подключиться к локальному AD LDS и проверить наличие получателей (на случай, если не работает синхронизация). Они там будут, но тут интересен сам способ подключения:

1. Запускаем ADSIEdit

2. Подключаем по следующим параметрам

  • Connection Point — OU=MsExchangeGateway
  • Computer – localhost:50389

3. Далее переходим по пути CN=Recipients,OU=MSExchangeGateway

4. Убеждаемся, что записи тут присутствуют


Другой способ проверки наличия получателя на Edge сервере, это запустить проверку с Exchange сервера в организации:



Workaround 1

Первый обходной вариант, который можно встретить на просторах интернета – отключить функцию Recipient Validation. Делается это следующей командой:

Set-RecipientFilterConfig -RecipientValidationEnabled $false

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

Disable-TransportAgent "Recipient Filter Agent"
Set-RecipientFilterConfig -Enabled $false
Set-AcceptedDomain yourdomain -AddressBookEnabled $false


Большой минус этого способа – отсутствие проверки существующих получателей.



Workaround 2

Второй обходной вариант позволит оставить включенной проверку на существование получателей, но это приведет к увеличению нагрузки, т.к. не будет использоваться кэш получателей в транспортной службе и запросы будут постоянно идти к локальной AD LDS. Конечно вырастет нагрузка на сервер, но каких-либо цифр на этот счет нету – придется смотреть в реальном времени.

Для этого варианта необходимо выполнить следующую команду и перезапустить службу транспорта MSExchangeTransport:

Get-TransportService | Set-TransportService -RecipientValidationCacheEnabled $false


И дальше остается ждать следующего CU J




Читайте также:

1 комментарий

  1. 29.03.2016

    […] Cumulative Update only), but Exchange MVP Maksim Barakin investigated the issue and came up with another workaround that temporarily fixes the issue by disabling the recipient validation cache of Exchange using the […]

Добавить комментарий