Score:0

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

co flag

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

Score:0
co flag

OK, so it looks like I figured this out, but it's something I'll have to yell at Microsoft for.

The messages in my question are verbatim what is being sent to Postfix and what's being sent to Outlook SMTP connector. The difference is, however, that Postfix properly handles the message and then retransmits it somehow in a way that's different than the way Python's smtplib handles mail transmission. Messages and their contents get delivered properly when first handed to a Postfix server for processing before being sent out the door via the Send Connector at MS365. Which... is not what we were wanting because we didn't want to maintain any kind of actual mail server on prem, Postfix or otherwise, and just wanted to deliver directly to Microsoft 365 for handling rather than needing a 'middleman hop' in a mail server and MTA before receiving messages from endpoint clients and connectors.

It's also odd that Microsoft 365 is incapable of properly handing messages handed directly to it, unless Microsoft has some weird format it wants to handle that isn't RFC compliant... but that's a different fight.

Score:-1
us flag

Does your application meet the following requirements? How to set up a multifunction device or application to send email using Microsoft 365 or Office 365

Try using Send-MailMessage or Telnet on your email server to test SMTP and see if there is any difference.

Besides, perhaps the following thread is helpful: Send emal stmp office 365 : message empty

co flag
Option 3 is already in place. We know that the mail application sending SMTP via Relay to MS365 triggers a successful response of queued for delivery, but then MS365 does something to the message and transmits a mostly blank message. I.E. every header is kept but no payload is retransmitted. To my knowledge SMTP Relay wouldnt need a license for this, unless I am mistaken? We have some Business Basic licenses we can play with if we need to use an authenticated/licensed sender.
co flag
And regarding the SO thread, we are already generating a MIMEText context when submitting test messages via Python - so thats not the issue.
Ivan_Wang avatar
us flag
What's the result if you connect to Exchange Online PowerShell and run the following commands: 1. **Get-TransportConfig | fl SmtpClientAuthenticationDisabled** 2. **Get-CASMailbox <Your mailbox Identity> | fl SmtpClientAuthenticationDisabled**. The parameter "SmtpClientAuthenticationDisabled" is to specify whether to disable authenticated SMTP (SMTP AUTH) for the whole organization or single mailbox. More details about it: https://docs.microsoft.com/en-us/powershell/module/exchange/set-casmailbox?view=exchange-ps
co flag
We don't have a mailbox identity for this - we're trying to send alerts from an on-prem system that has no mailbox via straight SMTP delivery to their recipients on the Cloud side of the infrastructure. The first command returns True, so client auth is disabled. However, with the connector in place (i.e. MS365 is configured to ACCEPT mail without question or authentication from the on prem SMTP server), it should never fail due to authentication. And we *can* send a message this way, and it DOES get delivered, except there's no actual mail *body* included in the delivered message
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.