У меня есть клиент, который использует внешний почтовый сервер для регистрации и фильтрации своей входящей электронной почты, прежде чем передавать ее в свою основную почтовую систему (то есть 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 и, похоже, остановил дополнительный поиск; письмо, которое раньше не доставлялось, теперь прошло.