This is a generalized version of the email that I am using to explain the Office365 disconnect bug to our correspondents.   I am posting it here in hopes that others will use something similar to work the issue with their correspondents.   It also explains why this is much more than a SmarterMail problem.

<After introducing myself:>

We discovered a problem with a message sent from your organization to ours.    The problem has been traced to Microsoft, and it may be affecting any of your outbound messages to any organization.   

 

By the SMTP standard, a sending system is supposed to indicate end-of-data and then wait for an SMTP response code to confirm whether the message has been accepted or not.    This leaves a design question of how the receiving system should act if the session is disconnected after end-of-data but before the SMTP response can be sent.   The receiving system can reasonably assume that the disconnect was accidental, and therefore the sender will reattempt delivery.   Based on this expectation, the submitted but unconfirmed message should be discarded so that the recipient does not receive two copies when the message is resubmitted.

 

A problem occurs if the sending system disconnects intentionally, without waiting for a status code, and has no intention of resubmitting the message.   The users are left in a vacuum, because the sending system has declared delivery success, while the receiving system has declared delivery failure.

 

What's worse, the deliberate-disconnect behavior is most often observed from spamming sources, which may be more concerned about maximizing attacks than about confirming whether an attack is accepted.   However, the behavior has also been observed by outbound Office365 servers.   After becoming aware of this issue yesterday, I reviewed our logs back to <date>.   As expected, 52 of the incidents were spam, and the other 2 were from Office365.  The problem is also very intermiitent - it occurred on only 2 of the 2,421 messages we received from Office365 servers during that same time period.  Our two problems were observed on traffic from these two servers:

40.107.89.105 (mail-bl0gcc02on2105.outbound.protection.outlook.com)

40.107.89.89  (mail-bl0gcc02on2089.outbound.protection.outlook.com)

 

Our mail system vendor has provided an option to continue delivery when a remote disconnect occurs after end-of-data, and I have activated that option for our environment.   This ensures that future messages from you will not be affected by this Microsoft bug.   However, it may increase our exposure to both unwanted messages and wanted-but-duplicate messages.   Consequently, I would like to disable the feature as soon as Microsoft has found and fixed their problem.  I am hoping that you can open a ticket with them to get this issue investigated.