Sendmail пытается найти имена хостов в заголовках без веской причины

У меня есть клиент, который использует внешний почтовый сервер для регистрации и фильтрации входящей электронной почты перед передачей ее в основную почтовую систему (которая представляет собой Office365). На внешнем сервере работает Sendmail, раньше на Debian, теперь на Ubuntu (версия Amazon).

Смена ОС (и хостинга) также повлекла за собой смену версии Sendmail: с 8.14.4 на старом сервере (довольно старом, да) до 8.15.2 на новом. К сожалению, это также вызвало небольшое изменение в поведении, и я пытаюсь понять, контролируется ли это флагом или другими настройками конфигурации.

Внешний сервер выполняет некоторую фильтрацию спама и прочей ерунды, и до смены сервера вся оставшаяся почта успешно доставлялась в O365. (Некоторые из них были помечены как спам, но все они, по крайней мере, попадали на их серверы). Теперь это не так. Большая часть почты, которая удерживается и не доставляется, - это сообщения об отказе из их рассылок, но им нужно видеть их, чтобы очистить свои списки".

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

    Received: from EXTERNAL.com (EXTERNAL.com [NN.NN.NN.NN])
        by OUR.SERVER (8.15.2/8.15.2/Debian-10) with ESMTP id xELIDED
        for <VALID@OUR.DOMAIN>; Sat, 11 May 2019 10:49:17 GMT
    Received: from EXTERNAL.com.local (EXTERNAL.com [NN.NN.NN.NN])
        by EXTERNAL.com (8.16.0.22/8.16.0.22) with ESMTPS id xELIDED
        (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT)
        for <VALID@OUR.DOMAIN>; Sat, 11 May 2019 18:49:15 +0800

- именно заголовок .local вызывает проблемы. Но мы не видим этих проблем, когда почта прибывает на сервер, только когда она покидает сервер и направляется в Office365. В этот момент мы видим

    EXTERNAL.com.local: Name server timeout

И транзакция завершается

    timeout writing message to OURDOMAIN-com.mail.protection.outlook.com.
<VALID@OUR.DOMAIN>... Deferred: Name server: OURDOMAIN-com.mail.protection.outlook.com.: host name lookup failure
Closing connection to OURDOMAIN-com.mail.protection.outlook.com.

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

Журналирование Sendmail и tcpdump показывают, что начальная часть SMTP-соединения проходит нормально. В секции DATA передаются заголовки, а затем соединение прерывается из-за невозможности поиска имени хоста, которое не имеет непосредственного отношения к соединению (оно никогда не доходит до передачи тела письма).

Помимо ситуаций, когда в заголовках содержалось имя хоста, которое невозможно было определить, я также видел, как это происходило в письмах, где в качестве reply-to был установлен несуществующий домен, который невозможно было определить. (Вполне вероятно, что это спам, но в данном случае вопрос не в этом).

Я просмотрел журналы изменений для соответствующих версий Sendmail и не обнаружил ничего, явно относящегося к делу; я также провел немного времени, копаясь в исходном коде. Журналы tcpdump показывают, что соединение прерывается на нашей стороне, а не на стороне Microsoft - у нас есть инженер с их стороны, который пытается нам помочь, но, поскольку для этих писем никогда не бывает успешного соединения, они не могут понять, что происходит. DNS-поиск для всего остального, похоже, работает нормально.

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

Заранее спасибо.

Edit Добавляю немного из журнала strace:

    connect(9, {sa_family=AF_UNIX, sun_path="/dev/log"}, 110) = 0
    sendto(9, "<22>May 15 09:52:20 sendmail[135"..., 176, MSG_NOSIGNAL, NULL, 0) = 176
    >>> EHLO our.server.name
    250-VE1EUR02FT009.mail.protection.outlook.com Hello [NN.NN.NN.NN]
    250-SIZE 157286400
    250-PIPELINING
    250-DSN
    250-ENHANCEDSTATUSCODES
    250-8BITMIME
    250-BINARYMIME
    250-CHUNKING
    250 SMTPUTF8
    >>> MAIL From:<> SIZE=23108
    250 2.1.0 Sender OK
    >>> RCPT To:<VALID@OUR.DOMAIN>
    >>> DATA
    250 2.1.5 Recipient OK
    354 Start mail input; end with <CRLF>.<CRLF>
    socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 12
    connect(12, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, 16) = 0
    sendto(12, "R>\1\0\0\1\0\0\0\0\0\1\2the\4dodgy\3com\5local\0\0"..., 46, MSG_NOSIGNAL, NULL, 0) = 46
    recvfrom(12, "R>\201\202\0\1\0\0\0\0\0\1\the\4dodgy\3com\5local\0\0"..., 8192, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, [28->16]) = 46
    [repeats six more times]
    the.dodgy.com.local: Name server timeout
    timeout writing message to OURDOMAIN-com.mail.protection.outlook.com.
    sendto(9, "<18>May 15 09:52:20 sendmail[135"..., 130, MSG_NOSIGNAL, NULL, 0) = 130
    <VALID@OUR.DOMAIN>... Deferred: Name server: OURDOMAIN-com.mail.protection.outlook.com.: host name lookup failure
    sendto(9, "<22>May 15 09:52:20 sendmail[135"..., 296, MSG_NOSIGNAL, NULL, 0) = 296
    Closing connection to OURDOMAIN-com.mail.protection.outlook.com.
    +++ exited with 70 +++

Итак, поиск, который не работает - это поиск на the.dodgy.com.local (упоминаемый как EXTERNAL.com. local в предыдущем санированном журнале, но я хотел сохранить структуру вызовов функций здесь), но тот, о котором сообщает Sendmail, является сбоем поиска на сервере, к которому он был подключен в то время. Он не выполняет этот поиск, и если бы выполнял, то не потерпел бы неудачу.

Edit (2): изменение DNS-резольвера не помогает.