Sendmail 無緣無故地試圖在標頭中查找主機名
我有一個客戶使用外部郵件伺服器記錄和過濾他們的入站電子郵件，然後再將其傳遞到他們的主郵件系統（即 Office365）。外部伺服器正在執行 Sendmail，以前在 Debian 上，現在在 Ubuntu（亞馬遜版本）上。
作業系統（和主機）的變化也涉及到 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 的日誌顯示連接在我們這邊被終止，而不是在微軟那邊——我們有一位工程師從他們這邊試圖幫助我們，但是因為這些郵件從來沒有成功的連接，他們正在努力查看發生了什麼在。其他所有內容的 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 解析器無濟於事。
我在 To: 標頭中看到了為什麼 sendmail 為非收件人的域呼叫 dns_getcanonname 的連結？在邊欄中，結果證明有解決方案。我們需要添加
FEATURE(nocanonify', canonify_hosts')sendmail.mc，這似乎已經停止了額外的查找；以前無法投遞的郵件現在已經通過了。