使用 MS365 作為 Python 應用程序的郵件中繼時的空電子郵件
我們這裡發生了一個非常奇怪的問題。
以這個範例電子郵件為例（原始形式，經過消毒）：
To: TestList@example.com From: Thomas Ward via TestList <TestList@example.com> Subject: Test Message Date: Wed, 4 Aug 2021 19:44:49 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------EFA1B8DAB3C4E625DD16F705" Content-Language: en-US Sender: TestList@example.com Reply-To: Thomas Ward <teward@NOPE> CC: Thomas Ward <teward@NOPE> Message-ID: <162812069430.22940.8470019517074758016@listserv-server> List-Id: TestList <TestList@example.com> List-Post: <mailto:TestList@example.com> --------------EFA1B8DAB3C4E625DD16F705 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Test --------------EFA1B8DAB3C4E625DD16F705 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> </head> <body> <p>Test<br> </p> </body> </html> --------------EFA1B8DAB3C4E625DD16F705--這是通過直接 SMTP 發送到 MS365 上的發送連接器，該發送連接器配置為從我們的本地郵件伺服器接收郵件並將其中繼到 MS365 以重新傳輸到 Internet。
除了…雖然電子郵件重新傳輸到目標外部收件人…它實際上只發送收件人、發件人、主題等，但完全忽略了郵件的實際內容。這也通過在 Python 中直接送出 MIMEText() 測試電子郵件來複製。
但是，同一封電子郵件在直接送出到我接收此郵件的外部郵件伺服器（
@NOPE我的實際域和伺服器在哪裡）時，可以很好地傳輸和中繼所有內容。當我們通過內部部署的 Postfix 中繼傳輸時也會發生同樣的事情，該中繼通過 Sophos 設備，然後直接進入接收伺服器。因此，似乎以這種方式通過 Exchange Online 路由任何郵件，而本地系統通過 MS365 發送郵件完全無法正常工作。無論送出的消息如何。
是否有其他人在這裡獲得了需要通過 MS365 路由的任何類型的本地郵件系統或解決方案，並且如果沒有 Microsoft 完全吃掉郵件就無法做到？
上述電子郵件從外部發送到測試列表，路由到本地 Exchange 伺服器（由於本地 listservs 導致 Exchange 混合設置），為符合 DMARC 進行了修改，然後作為新郵件重新傳輸到兩個外部地址，在收件人端同樣的問題。內部 MS365（組織內）收件人也有同樣的問題。
同樣，通過本地 Postfix 的東西可以很好地傳遞，但通過 MS365 中繼時就不行了（它顯然接受了電子郵件並重新傳輸了除了實際消息之外的所有內容）。
好的，所以看起來我想通了，但這是我不得不對微軟大喊大叫的事情。
我的問題中的消息逐字逐句地發送到 Postfix 以及發送到 Outlook SMTP 連接器的內容。然而，不同之處在於，Postfix 正確地處理了消息，然後以某種不同於 Python 的 smtplib 處理郵件傳輸的方式重新傳輸它。消息及其內容在通過 MS365 上的發送連接器發送到門外之前首先被傳遞到 Postfix 伺服器進行處理時得到正確傳遞。哪個…不是我們想要的，因為我們不想在 prem、Postfix 或其他方式上維護任何類型的實際郵件伺服器，只想直接傳遞給 Microsoft 365 進行處理，而不是需要“中間人跳”在郵件伺服器和 MTA之前從端點客戶端和連接器接收消息。
奇怪的是，Microsoft 365 無法正確處理直接傳遞給它的消息，除非 Microsoft 想要處理一些不符合 RFC 的奇怪格式……但這是另一場戰鬥。