Điểm:0

Empty Email when using MS365 as a mail relay from a Python application

lá cờ co

We've got a very weird issue going on here.

Take this example email (raw form, sanitized):

To: [email protected]
From: Thomas Ward via TestList <[email protected]>
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: [email protected]
Reply-To: Thomas Ward <teward@NOPE>
CC: Thomas Ward <teward@NOPE>
Message-ID: <162812069430.22940.8470019517074758016@listserv-server>
List-Id: TestList <[email protected]>
List-Post: <mailto:[email protected]>

--------------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--

This is being sent via straight SMTP to a Send Connector at MS365 configured to receive and relay mail from our on-prem mail server to MS365 for retransmission to the Internet.

Except... while the email retransmits to the destination external recipients... it actually only sends the To, From, Subject, etc. but completely ignores the actual content of the message. This was replicated with direct submission of a MIMEText() test email in Python as well.

The same email, however, when directly submitted to the external mail servers where I'm receiving this (where @NOPE would be my actual domain and server), transmits and relays fine, with all content. The same thing happens as well when we transmit via an on-prem Postfix relay which goes through a Sophos appliance, which then goes directly to the recipient server.

So, it seems that routing any mail via Exchange Online in this way with an on-prem system sending mail via MS365 outright fails to function. Regardless of the message submitted.

Has anyone else got any kind of on-prem mail system(s) or solutions here which need to route via MS365, and simply is unable to without Microsoft eating the message in its entirety?

The above email was sent to the Test List from external, routed through to an on-prem Exchange server (Exchange Hybrid setup due to on-prem listservs), modified for DMARC compliance, and then retransmitted to two external addresses as a new message, same issue at recipient ends. Also same issue for internal MS365 (in-organization) recipients.

Again, delivery works fine via on-prem Postfix stuff, but not when relayed via MS365 (which clearly ACCEPTED the emails and retransmitted everything EXCEPT the actual message).

Điểm:0
lá cờ co

Được rồi, có vẻ như tôi đã hiểu ra điều này, nhưng đó là điều mà tôi sẽ phải la mắng Microsoft vì điều đó.

Các thông báo trong câu hỏi của tôi là nguyên văn những gì đang được gửi tới Postfix và những gì đang được gửi tới trình kết nối SMTP của Outlook. Tuy nhiên, sự khác biệt là Postfix xử lý thông điệp đúng cách và sau đó truyền lại nó bằng cách nào đó theo cách khác với cách smtplib của Python xử lý việc truyền thư. tin nhắn nội dung của chúng được gửi đúng cách khi lần đầu tiên được chuyển đến máy chủ Postfix để xử lý trước khi được gửi ra khỏi cửa thông qua Trình kết nối Gửi tại MS365. Đó... không phải là điều chúng tôi mong muốn vì chúng tôi không muốn duy trì bất kỳ loại máy chủ thư thực tế nào tại chỗ, Postfix hay cách khác, và chỉ muốn gửi trực tiếp đến Microsoft 365 để xử lý thay vì cần một 'bước nhảy trung gian' trong một máy chủ thư và MTA trước nhận tin nhắn từ máy khách điểm cuối và trình kết nối.

Cũng thật kỳ lạ khi Microsoft 365 không thể xử lý đúng cách các thư được gửi trực tiếp tới nó, trừ khi Microsoft có một số định dạng kỳ lạ mà Microsoft muốn xử lý việc đó không phải Tuân thủ RFC... nhưng đó là một cuộc chiến khác.

Điểm:-1
lá cờ us

Ứng dụng của bạn có đáp ứng các yêu cầu sau không? Cách thiết lập ứng dụng hoặc thiết bị đa chức năng để gửi email bằng Microsoft 365 hoặc Office 365

Hãy thử sử dụng Gửi ThưTin Nhắn hoặc mạng điện thoại trên máy chủ email của bạn để kiểm tra SMTP và xem có sự khác biệt nào không.

Bên cạnh đó, có lẽ chủ đề sau đây là hữu ích: Gửi emal stmp office 365 : tin nhắn trống

lá cờ co
Phương án 3 đã sẵn sàng. Chúng tôi biết rằng ứng dụng thư gửi SMTP qua Rơle tới MS365 kích hoạt phản hồi thành công xếp hàng đợi để gửi, nhưng sau đó MS365 thực hiện điều gì đó với thư và truyền một thư gần như trống. I E. mọi tiêu đề được giữ lại nhưng không có tải trọng nào được truyền lại. Theo hiểu biết của tôi, SMTP Relay sẽ không cần giấy phép cho việc này, trừ khi tôi nhầm? Chúng tôi có một số giấy phép Business Basic mà chúng tôi có thể sử dụng nếu cần sử dụng người gửi được xác thực/được cấp phép.
lá cờ co
Và liên quan đến luồng SO, chúng tôi đã tạo ngữ cảnh MIMEText khi gửi thông báo thử nghiệm qua Python - vì vậy đó không phải là vấn đề.
Ivan_Wang avatar
lá cờ us
Kết quả là gì nếu bạn kết nối với Exchange Online PowerShell và chạy các lệnh sau: 1. **Get-TransportConfig | fl SmtpClientAuthenticationĐã tắt** 2. **Nhận-CASMailbox | fl SmtpClientAuthenticationDisabled**. Tham số "SmtpClientAuthenticationDisabled" là để chỉ định có tắt SMTP đã xác thực (SMTP AUTH) cho toàn bộ tổ chức hoặc hộp thư đơn lẻ hay không. Thêm chi tiết về nó: https://docs.microsoft.com/en-us/powershell/module/exchange/set-casmailbox?view=exchange-ps
lá cờ co
Chúng tôi không có danh tính hộp thư cho việc này - chúng tôi đang cố gắng gửi thông báo từ hệ thống tại chỗ không có hộp thư thông qua chuyển phát SMTP thẳng tới người nhận của họ ở phía Đám mây của cơ sở hạ tầng. Lệnh đầu tiên trả về True, vì vậy xác thực ứng dụng khách bị tắt. Tuy nhiên, với trình kết nối tại chỗ (tức là MS365 được định cấu hình để CHẤP NHẬN thư mà không cần đặt câu hỏi hoặc xác thực từ máy chủ SMTP tại chỗ), nó sẽ không bao giờ bị lỗi do xác thực. Và chúng tôi *có thể* gửi thư theo cách này và thư KHÔNG được gửi đi, ngoại trừ không có *body* thư thực sự nào được bao gồm trong thư đã gửi

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.