none
421 4.3.2 System not accepting network messages RRS feed

  • Вопрос

  • Добрый день.

    Периодически возникает проблема обмена почтой с одним доменом.

    Нам письма не доходят. Останавливаются на Edge. Вот кусок лога:

    https://cdn1.savepice.ru/uploads/2020/1/15/c03edf8ec9a926d7670359c97aa77ae8-full.png

    В ответ отправителю приходит письмо с таким текстом:

    https://pastebin.com/vuTSBWVv

    Когда от нас письмо отправляется, то оно висит на Edge.

    В трекинге оно сначала висит с EventId - RECEIVED. Через пару секунд появляется запись со значением DEFER и в RecipientStatus - '451 4.7.1 Greylisting in action, please come back later'.

    После этого каждую минуту появляется новая аналогичная запись. (Я так понимаю, что мой сервер пытается повторить доставку, но из-за настроек стороннего письмо не уходит). Спустя полчаса письмо успешно уходит.

    Если в один день отправлять два письма, то второе сразу доходит до адресата (похоже отрабатывает настройка Greylist).

    Судя по всему задержка хождения почты от нас до адресата - это работа антиспама. Но что делать с хождением почты до нас?

    Я погуглил, и ошибка, вроде как, из-за проблем с NDR на моей стороне. Очередь заморожена. Но где это настраивать? Или проблема в чем-то другом?

    15 января 2020 г. 11:39

Ответы

  • Все. Разобрался с этой проблемой.

    Edge Rule Agent - отвечает за работу transport rule. Если отключить, то они работать не будут.

    Теперь по поводу проблемы. Все оказалось банальным и виной, в основном, моя не внимательность.

    Выяснив что проблема кроется где-то в transport rule, я добавил еще одно правило, которое писало в лог событие, если письмо проходило через него. (actions - log an event with message, сам лог смотреть в event views-> custom views -> Microsoft Exchange with Database Availability Group Events и настройка фильтра по MSExchange Messaging Policies)

    Соответственно передвигая правило, я нашел то, после которого в лог ничего не пишет и мое новое правило не обрабатывается.

    В итоге оказалось, что в одном правиле было условие "when any recipient address matches", в котором прописаны полные адреса ящиков и  отправитель "outside the organization". Тогда происходит drop connection.

    Как оказалось у получателя ящик  был примерно такого вида pupkinsd@domain.ru, а где-то в середине списка ящиков фигурировал ящик sd@domain.ru.

    Поэтому до пользователя не доходили письма.

    Остается вопрос, почему раньше они доходили. Скорее всего предыдущий администратор зачем-то вносил изменения в правило в последнюю неделю до НГ (с 1 января он уже не работал), а пользователю просто не слали на тот момент письма внешние абоненты. Соответственно проблема всплыла гораздо позже.

    Всем спасибо, особенно M.V.V. _, за то что пытался разобраться и помочь с проблемой

    • Помечено в качестве ответа Reaplay 22 января 2020 г. 10:43
    22 января 2020 г. 10:42

Все ответы

  • Файрволов на пути следования никаких нет, сканирующих SMTP траффик? Антиспам еще может химичить.
    15 января 2020 г. 14:56
  • Рекомендую для анализа использовать https://testconnectivity.microsoft.com/

    Message Header Analyzer

    The Message Header Analyzer has moved to a new location. Please find it at the link below:

    Message Header Analyzer

    Проверяйте настройки Kaspersky Security 8.0 for Linux Mail Server и milter-greylist-4.6.2, где-то он всеже блокирует. 


    MCITP, MCSE. Regards, Oleg

    15 января 2020 г. 17:17
    Модератор
  • Если на Edge не стоит стороннего агента антиспама (который тоже может такое поведение вызывать), то под подозрение попадает срабатывание механизма обратного давления (Back Pressure) - это такой механизм для защиты от исчерпания ресурсов. Для проверки, что причина установлена верно, смотрите в журнале событий Application события с кодами 150xx от источника MSExchangeTransport с категорией ResourceManager.

    Т.к. состояние исчерпания ресурсов у вас выглядит устойчивым, то наиболее вероятная причина - исчерпание свободного места на диске, где находится БД службы транспорта (по умолчанию - на C:). Имеет смысл проверить свободное место сразу, ещё до анализа журнала событий. Если с этим всё выглядит в порядке (места существенно больше 10%), то тогда придется анализировать те самые события, о которых я писал выше - там про состояние всех ресурсов написано.

    PS Более вероятная причина - см. следующее сообщение.


    Слава России!



    • Изменено M.V.V. _ 15 января 2020 г. 18:13
    15 января 2020 г. 18:02
  • Я погуглил, и ошибка, вроде как, из-за проблем с NDR на моей стороне. Очередь заморожена. Но где это настраивать? Или проблема в чем-то другом?

    Судя по коду, проблема именно в этом. Запустите из консоли управления Exchange Queue Viewer (в разделе Toolbox) - там можно управлять очередями.

    Слава России!

    15 января 2020 г. 18:12
  • Антиспам от Касперского, но он не причем, как и фаервол.

    Как выяснилось, не доходят сообщения только от внешних адресатов и только на этот ящик.

    С личной почты до меня сообщения доходят, до проблемной почты - нет.

    Предыдущие администраторы писали, что в такой проблеме просто увеличили квоту, но квота на ящик достаточная, места полно. На всякий случай добавил еще места, переместил в другую БД, ничего не изменилось.

    Что может быть еще?

    17 января 2020 г. 6:31
  • Мне не совсем понятно, что и где у вас происходит, нужны пояснения.

    На каком сервере заморожена очередь: как он называется (в соответствии с теми заменами, которые вы сделали в логах) и какие на нем роли.

    По поводу, что происходит, надо смотреть ошибки в журналах событий Application на том сервере HT, который должен доставлять письма в п/я и том сервере MBX, на котором активна БД с этим п/я (это может быть и один сервер, и разные, как у вас - не знаю).


    Слава России!

    17 января 2020 г. 11:45
  • Там где я давал ссылку на pastebin, никаких моих серверов не было указано, где скрин, мой сервер mail.first.domain.ru .

    В интернет смотрит Edge сервер. Там стоит Касперский (KES + KS для Exch), Forefront TMG.

    Роли стоят: DNS, FS, Network Policy and Service, Active Directory Lightweight Directory Services.

    Структура такова: есть 2 домена. Была миграция из локального, в большой общий.

    В итоге 4 сервера с базами, DAG, CAS в новом домене (описывал тут: https://social.technet.microsoft.com/Forums/ru-RU/46a176af-2ca9-48c0-b8d6-b444546f2d0a/-?forum=exchange2010ru) и примерно в такой же структуре 2 старых сервера в старом домене (старые вроде как не используются, все ящики отуда смигрированы). Edge смотрит в интернет и принимает/отдает почту, оттуда идут коннекторы до старых серверов и далее до новых.

    Касперский для exch отключал, на старых серверах ничего в логах нет. Как мне кажется, дальше edge не уходит.

    На сервере Edge в Application нет ничего подозрительного. На сервера базами у меня доступа нет, только через EMC с ограниченными правами

    Меня смущает то, что в EMC на Edge, если искать в Tracking Log Explorer, ничего нет, но в protocol log, smtp receive - там как раз строчки из скрина.

    Я так понимаю, что Edge начинает принимать письмо, ему что-то не нравится и он выдает ошибку.

    Отсылал письмо сразу на адреса: свой и сбойный - письмо не дошло с ошибкой. Через минуту послал только себе - дошло.

    Так же обратил внимание, что в очереди (Queue Viewer) на Edge подвисают на некоторое время с такой ошибкой в свойствах, а потом успешно уходят:

    Last Error: 452 4.3.1 Insufficient system resources

    https://cdn1.savepice.ru/uploads/2020/1/20/44adae7ce0b690267e7171282d0414cf-full.png




    • Изменено Reaplay 20 января 2020 г. 5:07
    20 января 2020 г. 4:27
  • Вот такие настройки коннектора "from internet to edge" в Receive connectors стоят:

    https://cdn1.savepice.ru/uploads/2020/1/20/0fd8f73e78f641ae012f8eb8f1da51f6-full.png

    https://cdn1.savepice.ru/uploads/2020/1/20/a484260dd9622131b5f3ae19e20e5326-full.png

    https://cdn1.savepice.ru/uploads/2020/1/20/c634a1370baf6b87b6e324d0b69a23e8-full.png


    • Изменено Reaplay 20 января 2020 г. 9:33
    20 января 2020 г. 9:32
  • Плохо, что у вас нет доступа к логам на HT- судя по имеющимся признакам, проблема именно там. Особенно - с учетом того, что проблемным является конкретный п/я: для Edge все п/я одинаковы и письма в них складываются в одну очередь чтобы отправить через один коннектор. Весьма вероятно, что проблема с единственным п/я отражается на всей очереди и приводит к её заморзке.

    Last Error: 452 4.3.1 Insufficient system resources - это как раз признак включения Back Pressure на внутреннем сервере, про которую я писал в своем первом ответе.

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


    Слава России!

    20 января 2020 г. 10:03
  • Поговорил с человеком поддерживающем наши конечные сервера. Говорит, что проблема на входящем шлюзе. Буду дальше ковырять.

    Спасибо за помощь. Если получится решить, постараюсь отписать что и как было

    21 января 2020 г. 5:31
  • Поговорил с человеком поддерживающем наши конечные сервера. Говорит, что проблема на входящем шлюзе. Буду дальше ковырять.

    Спасибо за помощь. Если получится решить, постараюсь отписать что и как было

    Плохо, видимо поговорили. Для таких раговоров надо в своих логах протокола SmtpSend найти ошибки с отправкой сообщений на внутренние серверы (4xx коды и, в частности, отсутствие нормального приема сообщений на проблемный п/я) и предметно поинтересоваться, как и почему они возникли - не вообще, а каждая конкретно.

    Иначе вам так и будут отвечать "у меня всё работает".


    Слава России!

    21 января 2020 г. 11:08
  • Уточню на всякий случай. Я разговаривал с человеком, который занимается конечным почтовым сервером.

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

    Включил трассировку (PipelineTracingEnabled) и сравнил 2 отправления.

    У сбойного последний агент "X-MessageSnapshot-Source: OnEndOfData,Edge Rule Agent". Создаются только SmtpReceive, файлы Routing отсутствуют

    А у нормального, следующий "X-MessageSnapshot-Source: OnEndOfData,Content Filter Agent"

    Отключил агент "Edge Rule Agent", письмо начало ходить до пользователя.

    Получается где-то в нем проблема в этом агенте.

    Проверил настройки anti-spam и transport rule. Ничего подозрительного нет.

    Где еще могут находится настройки Edge Rule Agent ?

    22 января 2020 г. 6:09
  • Все. Разобрался с этой проблемой.

    Edge Rule Agent - отвечает за работу transport rule. Если отключить, то они работать не будут.

    Теперь по поводу проблемы. Все оказалось банальным и виной, в основном, моя не внимательность.

    Выяснив что проблема кроется где-то в transport rule, я добавил еще одно правило, которое писало в лог событие, если письмо проходило через него. (actions - log an event with message, сам лог смотреть в event views-> custom views -> Microsoft Exchange with Database Availability Group Events и настройка фильтра по MSExchange Messaging Policies)

    Соответственно передвигая правило, я нашел то, после которого в лог ничего не пишет и мое новое правило не обрабатывается.

    В итоге оказалось, что в одном правиле было условие "when any recipient address matches", в котором прописаны полные адреса ящиков и  отправитель "outside the organization". Тогда происходит drop connection.

    Как оказалось у получателя ящик  был примерно такого вида pupkinsd@domain.ru, а где-то в середине списка ящиков фигурировал ящик sd@domain.ru.

    Поэтому до пользователя не доходили письма.

    Остается вопрос, почему раньше они доходили. Скорее всего предыдущий администратор зачем-то вносил изменения в правило в последнюю неделю до НГ (с 1 января он уже не работал), а пользователю просто не слали на тот момент письма внешние абоненты. Соответственно проблема всплыла гораздо позже.

    Всем спасибо, особенно M.V.V. _, за то что пытался разобраться и помочь с проблемой

    • Помечено в качестве ответа Reaplay 22 января 2020 г. 10:43
    22 января 2020 г. 10:42