Build 7236 breaks IMAP 993 & SMTP 465 authentication over SSL

0

Hello,

I am also very curious what this change implies, because we applied the update and had to immediately roll back to 7188.

In fact, after update to 7236 some IMAP clients weren't able to AUTH successfully on IMAP and our log was FILLED with hundreds of:

[2019.10.26] 12:17:18.623 [x.x.x.x][17970544] user@domain PLAIN authentication failed

After reverting to 7188 these log entries stopped and the accounts were able to successfully authenticate again.

So in order to understand what cause this, it would be interresting to know what exactly is this change because it is maybe related.

ps: I had already reported this when trying to install a custom build, that should fix another issue, but apparently it made it to the public build even we reported it.

3

Ng Cher Choon Replied

October 27 at 6:21 AM

I think Smartermail should give a detailed explanation to such fixes pertaining to security. We will then take precaution in future on the security issues caused by Smartermail software. Should we ask if the user to change password, or what are the other appropriate steps needed on our end.

Thanks

2

Michael Breines Replied

October 27 at 10:53 AM

This update ruined my weekend.

It was Saturday afternoon and we were patching various services. Thought we might as well roll out the latest Smarter Mail update as well. That started a 6 hour debacle to figure out what was going on. Dive into the logs etc.

Build 7236 breaks IMAP SSL & SMTP SSL authentication.

Our Android and Windows/Outlook devices that were set to IMAP could not connect despite being set to use 993 IMAP and 465 SMTP. Both are SSL.

We had to uncheck the "Disable AUTH LOGIN method for non-SSL SMTP authentication" under the SMTP In Protocol settings.

But this makes no sense since 993 and 465 are SSL.

Something is very wrong in this build.

0

Sébastien Riccio Replied

October 27 at 11:54 AM

Hi Michael,

That's maybe what we hit aswell as we had in our log a lot of failed IMAP login attempts after the update. We had no way to know if these attempts were made on standard port 143 or on port 993 as the logs don't tell which port the users connects to log in.

Does your IMAP logs was full of "PLAIN authentication failed" right after the update?

If yes, that's exactly what we already reported at least two weeks ago when testing a custom build...

0

Michael Breines Replied

October 27 at 1:24 PM

We saw it from the client side. Outlook and Android mail clients were saying "unable to verify certificate" or along the lines of the mail server does not support the encryption method. I'd need to pull the exact wording. Then IDS blocking blocked the IPs of various clients. We had seen this back in v15 so we disabled the setting above. It seems smarter tools can't decide how that function should work. They've gone back and forth on it. Since we had experienced this before we just toggled off AUTH setting for now in the SMTP protocol settings.

Seems like this should get attention ASAP anyone using SSL and IMAP is going to be affected if they deploy this build.

0

Sébastien Riccio Replied

October 27 at 10:08 PM

Okay thank you michael. I think we didn't even have the same issue as we already had "Disable AUTH LOGIN method for non-SSL SMTP authentication" unchecked. However both issues might still be related to the same changes as it's both authentication issues.

1

Derek Curtis Replied

October 28 at 7:54 AM

Employee Post

I forwarded this thread to the developers yesterday, and they're looking into it.

Derek Curtis

COO

SmarterTools Inc.

(877) 357-6278

www.smartertools.com

0

Michael Breines Replied

October 28 at 10:19 AM

Thanks Derek. We'll standby for more news...

3

Francis Wurtz Replied

October 28 at 10:40 AM

Hi, first, sorry for my poor english.

Exactly same thing for Us, we was forced to revert back to 7188. Made the update Thursday night. On Friday morning, we received a big wave of service calls and we lost a big part of this day to respond to this. I then decided to go back to version 7188 while the bug was fixed.

Personally, I find it very irritating that we can't trust these updates. Thinking of correcting some problems, the update brings us even more important ones ...

I do not know when I will remember to wait for some time before updating on the production server ( Even if it's an official version ..). I am not likely to criticize for nothing, but I must mention that I have a lot of frustrations for quite some time. This is not the first time this happens to us and every time I get caught installing these updates too quickly. I know. I's my fault!

0

rick Replied

October 29 at 5:43 AM

Anyone know if its safe to upgrade yet?

1

Christian Schmit Replied

October 29 at 6:10 AM

For us build 7236 seems to be fine. We upgraded over the weekend and so far we have not observed any issues with SMTP or IMAP over SSL (or without SSL).

We run Smartermail on Windows Server 2016 and Windows Server 2019 all patches applied.

0

Michael Muller Replied

October 29 at 7:26 AM

I was hoping this would be the bullet that laid the wandering-indexes down. Really need that bug gone. Users can't search in certain folders in webmail, and those very same folders do not appear in IMAP clients.

---
Montague WebWorks
Powered by RocketFusion

0

Andrea Rogers Replied

October 29 at 7:58 AM

Employee Post

Hi all,

You should certainly update your installations to Build 7236. There were security improvements made in recent versions of SmarterMail, and we believe these reports are a result of those improvements. The users who are failing authentication in this build will need to reset their passwords and re-connect their clients. As a Domain Administrator, you can easily force a password reset using the Expire Password option found in the Domain Settings > Accounts > Users tab > Actions [...] menu.

Andrea Rogers
Customer Operations Manager
SmarterTools Inc.
877-357-6278
www.smartertools.com

3

Michael Breines Replied

October 29 at 9:20 AM

Andrea, tell us more. Are you saying that after updating to 7236 all our users need to update their passwords? That seems like quite an undertaking. We'd like to know 1) why and 2) how the Disable AUTH LOGIN method for non-SSL SMTP authentication setting is affected or related.

1

Bruce Replied

October 29 at 9:27 AM

I would like more information as well so can judge how many customers will need to update their password and how much disruption this update will cause?

3

Michael Muller Replied

October 29 at 9:27 AM

Andrea, what specifically was "fixed" in regards to SSL? I have 485 users on my system. If even only 10% of them are using SSL in a client app, my day will be hijacked by this upgrade.

Does it also fix the indexing problem? Again, I have folders disappearing in my Thunderbird desktop app, that also do not fare well with searches in the web interface. Reindexing them does not appear to help every time.

Thanks

---
Montague WebWorks
Powered by RocketFusion

5

Webio Replied

October 29 at 10:42 AM

@Andrea. How this should be handled in scenario with SmarterMail that has more than 5k domains? Believe me I'm really not prepared for zombie apocalypse when I will have to force password change for X number of email accounts.

2

rick Replied

October 29 at 1:14 PM

Yeah asking people to reset their passwords is easier said than done. People are brutally dumb sometimes and generally don't want to be bothered.

0

Alex Clarke Replied

October 29 at 1:29 PM

I too would like to know more information about the recent security fix.

A few days ago one of my mailboxes was compromised. I noticed a Microsoft Outlook test email appear in my Inbox. Knowing that I hadn’t performed a test I examined the email headers and saw that someone authenticated with my credentials and sent this email from an IP in Canada.

Obviously, I’ve changed passwords for all my email accounts.

2

Michael Breines Replied

October 29 at 1:35 PM

hum...

5

pjeski Replied

October 30 at 6:07 AM

Is there any way to mark this thread unanswered? The answer isn't very complete.

What is the likelihood that all my users will have to change their passwords? Are most user accounts running into this issue? Or is it rare?

0

rick Replied

October 30 at 8:20 AM

*** UPDATE***

I need to retract this (below). I was only told to hold off upgrading because I reported a different issue and they didn't want to lose track of that issue by upgrading to different version. We're still running good on 7236 as of now.

---------------------------

I installed it this AM and so far it seems okay. But a few hours later I was told by support:

"hold off for now on build 7236".

So for now, I'm crossing my fingers. Not even sure how to revert back if necessary. Has anyone done that? If so, how?

3

Michael Breines Replied

October 30 at 4:59 PM

It's still not clear what was resolved with authentication, why some of us are having problems, and why there's a note above that we all may need to reset passwords.

3

Shayne Embry Replied

October 30 at 9:00 PM

Was planning to install newest build this evening, but after reading this thread I think we'll wait. Sure would be nice if information from SmarterTools was clear and concise. Sadly, after 10+ years, not a lot of confidence in this product right now.

2

Gabriele Maoret - SERSIS Replied

October 31 at 8:18 AM

We too are waiting a clear note from Smartertools before install this update.

If we have to reset 300+ customer users passwords it will be a pain in the ass...

2

Nathan Y Replied

November 1 at 6:43 AM

Any news on whether the latest build is safe? We are urged to install in the release notes but this thread suggests not proceeding.

Smartertools, can you please give a position on whether it is safe?

3

Bruce Replied

November 1 at 7:10 AM

We are holding off on this update as well till have more information from SmarterTools.

For those who have installed this latest release, how many mailboxes needed to have their passwords reset?

Does unchecking "Disable AUTH LOGIN method for non-SSL SMTP authentication" mean that customers do not need to reset their passwords?

3

Derek Curtis Replied

November 1 at 8:46 PM

Employee Post Marked As Answer

Just to follow up and close out this thread, we released Build 7242 today. It actually fixes a few of the issues people saw when upgrading to 7236.

Regarding resetting passwords, we don't anticipate that you'll need to reset the passwords of all users on your server. (Except in certain instances...discussed a bit later in this post.) It was suggested as a way to get users seeing authentication issues to be able to log in.

Regarding the issue itself, I won't go into the details because we don't want that info out in a public forum. There are many phases that go into the discovery, development, quality control and notification process around software bugs, especially when related to something delicate such as a security vulnerability. With that said, we work with largest technology companies in the world and we are constantly reporting not only bugs but security vulnerabilities that can go unresolved for months, if not years. With regards to SmarterTools and our products, we are extremely diligent with our releases, and these situations are VERY rare. However, when they do occur, we work incredibly fast, within a very small window, especially compared to other software companies.

Build 7242 does have some changes that should fix issues where customers couldn't log in due to their passwords being non-UTF-8 encoded. If you update to Build 7242 and users lose their client connection(s), you should expire the passwords of those users in order to force a password update. The user will then need to reconnect their client(s). If the authentication failure persists, you should submit a ticket to the Support Department for further review, as the issue is likely unrelated to these changes. In this case, we'll need to know the details of the client that's attempting the connection. This isn't an anticipated outcome, but we wanted to make it known just in case.

That said, we are not able to replicate any issue with the "Disable AUTH LOGIN method for non-SSL SMTP authentication" setting. I believe we have a ticket or two out regarding that issue. In addition, we've started support tickets with a few of you who had issues that were different than the ones others were reporting.

Derek Curtis

COO

SmarterTools Inc.

(877) 357-6278

www.smartertools.com

1

Michael Muller Replied

November 2 at 7:36 AM

We're upgrading to 7242 tonight.

---
Montague WebWorks
Powered by RocketFusion

0

Sébastien Riccio Replied

November 2 at 2:54 PM

I think latest available MAPI beta (at least 7202) has the same vulnerability and it would be wise for anyone using it to update asap. However I don't know if you can update from MAPI enabled beta to a "standard" build.

0

info Replied

November 3 at 6:21 AM

Did 7242 solve the problems?

4

Michael Breines Replied

November 3 at 7:58 PM

Build 7242 resolves the issues we found with the "Disable AUTH LOGIN method for non-SSL SMTP authentication" setting.

We have the setting toggled on now.

From what we can tell all is well. 7242 seem stable for our SSL connections IMAP and SMTP.

2

Michael Muller Replied

November 4 at 6:20 AM

So far so good.

---
Montague WebWorks
Powered by RocketFusion

2

Bruce Replied

November 4 at 8:15 AM

So far so good for us also.

Out of 10k mailboxes, we only had one customer so far who is using IMAP on port 993 on an old version of Andriod who needed to change the password type from 'normal' to 'encrypted' to fix the "PLAIN authentication failed" error message.

2

Linda Pagillo Replied

November 4 at 8:42 AM

I upgraded 3 servers to build 7242 Saturday evening and so far no issues :)

Linda Pagillo
Mail's Best Friend
Email: linda.pagillo@mailsbestfriend.com
Web: www.mailsbestfriend.com

Authorized SmarterTools Reseller

Authorized Message Sniffer Reseller

35 Replies

Reply to Thread

Related Community Threads

Related Knowledge Base Articles

35 Replies

Reply to Thread

Tags

Related Community Threads

Related Knowledge Base Articles