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

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 передаются заголовки, а затем соединение завершается из-за невозможности найти имя хоста, которое не имеет непосредственного отношения к соединению (оно никогда не доходит до передачи какого-либо тела письма).

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

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

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

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

редактировать Добавляем немного журнала 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, является ошибкой поиска на сервере, к которому он был подключен в то время. Это не делать этот поиск, и в противном случае он бы не потерпел неудачу.

Изменить (2): смена преобразователя DNS не помогает.

Я увидел ссылку на Почему sendmail вызывает dns_getcanonname для доменов не получателей в заголовке To :? на боковой панели, и оказалось, что есть решение. Нам нужно было добавить FEATURE(nocanonify', canonify_hosts') в sendmail.mc и, похоже, остановил дополнительный поиск; письмо, которое раньше не доставлялось, теперь прошло.