Watch out for "Client socket is disconnected! Disconnect exception occurred: False, IsDisconnected: True, This message will be rejected."
Problem reported by Sandro - 3/11/2022 at 5:56 AM
Not A Problem
I hope this post helps people find a problem that they - like me - didn't know they had.
I would recommend everyone to check the SMTP logs for "Client socket is disconnected! Disconnect exception encountered: False, IsDisconnected: True".

We have several customers who did not receive certain messages. One customer alone did not receive over 50 emails in a one month period - all senders were Office365 users. The problem did not occur regularly but irregularly. One message from the sender arrived successfully, the next again not - without pattern. This probably also led to the fact that no customer noticed it immediately. Not receiving emails on this scale is not acceptable for any customer. And who is to blame? The customer is not interested. From his point of view, the product we offer him is unreliable. And the fact that besides mass mailers also Office365 is partially locked out does not make our point of view any more credible nor does it make the customer's problem any smaller, who now has to write to a large number of people to ask them to please deliver the message to them again.

Since this was only possible because SmarterTools enabled an option as the new default for everyone, an option that isn't even listed in the changelog, here are my thoughts on it based on a post by Tim U. on the subject that I found while searching for the error message:
The scope of this Client Disconnect / SMTP issue is important.  
We have had less than 10 tickets.
How SmarterMail works today will continue to be the default because it is correct.
There will be a setting at the SMTP IN level allowing clients that disconnect to continue to send a message.  
If you want to call this a win, call it a win. You will be opening yourself up to duplicate messages and more.
The clients that are most often an issue are components or tools used for mass emails.

Regarding "If you want to call this a win, call it a win. You will be opening yourself up to duplicate messages and more."
Was I not open to the problem of duplicates until now? And even if I was, should I call it a "win" when customers no longer receive normal emails from Office365 servers? I can't do Microsoft's homework. I need to be able to provide a working, reliable product. That's a "win", that's what I make money on, that's what I pay SmarterTools money for.

Regarding "How SmarterMail works today will continue to be the default because it is correct."
The wrong answer to the wrong question. The question is not what is correct. The question should be "what works, what is stable, what is reliable?". I find it irresponsible to introduce such an option and at the same time activate it over the decision of us customers without first having carefully examined the consequences.

I wish such measures would be rolled out more gently. Don't switch it on as default and then offer an option in the UI to disable it some releases later because customers demand it. But add an option first, work with larger customers and see what happens when they activate the option, etc.

I received the following response from support (whom I do not want to criticize and is always friendly and helpful): 
We have also observed this behavior coming from some Microsoft/O365 servers as well, and so recommend using the setting you've referenced to account for this in the future.
But if this is known to SmarterTools, surely I expect proactive information about it? As a non-SmarterTrack customer I even get notifications about maintenance windows that don't affect me but that an option that SmarterTools simply enables by default might lock out servers of big providers like O365 I am not informed about but have to wait until customers complain to me to contact SmarterTools and then learn that I better disable the option then? This is just totally customer unfriendly and reactive instead of proactive. If I had been informed, I could at least have decided for myself or check the logs regularly for this case.

I am sorry to say this but like many before me here in the community, I sometimes feel more like a test subject than a customer. In this respect, we SmarterMail customers are clearly in the weaker position, because even if our end customers leave us due to dissatisfaction or lack of stability of SmarterMail: as long as we still have active customers, we have to maintain our SmarterMail licenses.

The battle against O365 is tough enough otherwise. Why not listen to the community and start implementing some of the things others suggested here? For example, beta's or a listing of known issues at least for paying customers? I've spent countless amounts of time on bug reports to support where the response has been that SmarterTool already knows about it and is working on a solution. Thank you, if only I had known this sooner and could have just joined "the list" and then gotten a custom build instead of spending all that time. We are not talking about about software for a snack machine, it's about email - for probably every company one of the most important tools in their daily work (which is why I also totally don't get your 4 day week idea to be honest).

We want to offer our customers excellent service with top products and with no product do we stand behind our own requirements as we do with SmarterMail. With no customer group have we had to apologize as often as with the customers who use SmarterMail. That just makes you think. The market has become so tough with O365 and the advertising Microsoft is doing in Windows to get even more customers that we can't compete with alternative offerings unless they are outstandingly good. I believe in the idea of SmarterMail but the quality and the decisions made just have to get to a level that allows us to continue to offer our customers exciting and good solutions that are reliable.

As a small example to conclude: I don't do updates anymore, I wait and watch what others report and then maybe do an update if I have to. The thought about the daylight saving time change already makes me nervous, as there have been several cases in the past where calendar entries of customers were no longer correct - and that already with more than one daylight saving time change. These are all thoughts that, if SmarterMail is as reliable as SmarterTool likes to present it, I shouldn't have so present.

10 Replies

Reply to Thread
Matt Petty Replied
Employee Post
Just because Microsoft changes the way they do something after-the-fact, doesn't mean it becomes the new standard. I hate they can just swing their big sword around and cut everyone in its path without thinking about any repercussions because they have market domination. We've given system administrators a way to get around this new behavior check the following setting and it will start working again as expected.
System Admin > Protocol Settings > SMTP in > check "Continue delivery if session is disconnected by client"
Matt Petty Software Developer SmarterTools Inc. (877) 357-6278 www.smartertools.com
Sandro Replied
Thanks for your response, Matt. Of course, I absolutely agree with you. I also don't like the fact that Microsoft can do this because of their market position. However, the behavior of Microsoft's servers was already present before the automatic activation of the new SMTP procedure. If this had been tested on a small(er) scale first, it would have been noticed before all customers were exposed to the problem via an update. Microsoft's behavior would not have been a problem if SmarterTools had not automatically enabled the new SMTP processing. Because then we would have been able to decide for ourselves if we wanted to enable the option or not. Now we are faced with the situation that a change that was not even listed in the changelog has resulted in lost emails from customers.

Sure, we've changed the option now, but email is so incredibly important in the business environment that when messages are lost on this scale, there is always a loss of trust from the end customer towards us as a provider.

I can't change that Microsoft is Microsoft. But that SmarterTools doesn't just make such changes without warning, that would make me happy. For me it has to do with reliability in the end. I need to know what the software we use does and doesn't do - and that's not possible under the circumstances mentioned.
Tan Replied
Had the same problem too, thankful for this thread. I was forced to upgrade SmarterMail due to another bug. Had call raining in on this problem and really should not turn off by default. Should roll out and maybe such important issue, can flag in the changelog.
Paul Blank Replied
Some folks seem to disregard the plain fact that Microsoft is the 800 lb. gorilla (or at least one of them). For the time being, there is no getting around that, and we all need to adapt to their collective whims. 

For a non-email example, just look at the user interfaces for Windows 8 and beyond. Who knew that they got it pretty-much right with Windows 7 and have been going backwards ever since?
Reto Replied
I had to disable the setting too, we had problems where some mails from microsoft 365 servers got deleted. In my case Smartermail did reply with 250 ok after data, but did delete the email anyway. According to the RFC if a MTA reply with 250 ok it is his responsibility to finally deliver the email. In my opinion it's Smartermail that is not RFC compliant in this case by deleting the mail after sending 250 ok. I had no success with a ticket and as Paul says Microsoft is to big to not accept the mails. I'm at least happy that this setting was added. 
Gabriele Maoret - SERSIS Replied
We had to enable "System Admin > Protocol Settings > SMTP in > check "Continue delivery if session is disconnected by client" 

Without it too many customers started complain that it isn't working.
Gabriele Maoret - Head of SysAdmins at SERSIS Currently manages 6 SmarterMail installations (1 in the cloud for SERSIS which provides services to a few hundred third-party email domains + 5 on-premise for customers who prefer to have their mail server in-house)
Ryan Hendrickson Replied
Thank you for this.  I too was having this issue.  
Paul Blank Replied
Matt Petty says: "Just because Microsoft changes the way they do something after-the-fact, doesn't mean it becomes the new standard"

Pursuant to this comment and my own follow-up: Yeah, it often does become a new standard, whether it's RFC-compliant or not. Gorilla in the room, and all-that.

This is NOT in any way high praise for Microsoft. But many of their changes in direction certainly need to be adapted to.

All that said, Microsoft, who wants everyone to be part of their universe, doesn't make it simple for people (read that: usually email admins) to migrate accounts to online Outlook. Many of their tools are inadequate i.e. they either don't work or don't give progress reports/logs. So you can't tell when they're working, were successful, or if they've failed, just where the failure is. And then there's stuff like the "App Password," which is supposed to give access to an email account when needed via legacy (non-OAuth2) IMAP/SMTP protocols. This simply doesn't work a lot of the time, and this is not a new problem. There's more to say but enough for now. 

And again, I am not taking a swipe at SmarterMail. The reality on the ground is that many organizations need, or at least desire, some of their users to be on Microsoft 365 email. Setting up a split-domain with a product such as SmarterMail (SM <--> M365) is a good way to go in these instances.
Douglas Foster Replied
"Client disconnect" really is a serious problem that Microsoft needs to fix.   I am beginning efforts to have one of my correspondents address the problem with Microsoft.
Ricky Hignite Replied
This got me as well for some internal equipment delivering Voicemails. Emails going out from the server was mixed and I couldn't figure out what happened since our late update. 

Thanks for the quick fix!

Reply to Thread