0

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

2 Answers 2

0

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.

-1

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

4
  • 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. Aug 5, 2021 at 12:19
  • And regarding the SO thread, we are already generating a MIMEText context when submitting test messages via Python - so thats not the issue. Aug 5, 2021 at 12:21
  • 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: docs.microsoft.com/en-us/powershell/module/exchange/…
    – Ivan_Wang
    Aug 13, 2021 at 10:08
  • 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 Aug 17, 2021 at 21:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .