• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Issue Smtp encrypted no longer works since the latest Windows update kb5018410 at all customers

T

telo

New Pleskian
Server operating system version
Windows 10
Plesk version and microupdate number
Version 18.0.47 Update #3
Hello everyone

Since the latest Windows 10 update from Tuesday "update kb5018410 (2022.10)" encrypted smtp no longer work on all our Plesk servers. Many customers have reported that all Outlook versions are affected. Only the Windows update kb5018410 is decisive. If the latest Windows Update kb5018410 is uninstalled, it works again. Do you also have this problem and do you have a solution for it? At the moment I can only tell the customer to deinstall or unencrypted SMTP

it affects all ports 25 587 465 and SSL/TLS and STARTTLS
 
If you can, tell the customers to upgrade to Thunderbird instead. I have been recommending that. Outlook is a POS in my humble opinion..
 
Yes, that works, but it's not a solution. I can't call thousands of mailbox users and tell them to replace their Outlook with Thunderbird. A majority of people use Outlook. and must use Outlook due to company policy
 
We are seeing the same and the only solutions we have are
  • Rollback the Windows Update - easiest but for some it will auto install again
  • Use Webmail temproarily while Plesk or Microsoft find a fix
  • Change to an Alternative Email Application like Thunderbird
  • Change Outlook to send emails using no SSL and port 25 (not really a good idea but if they are desperate and cannot do one of the other options)
Really hope a permanent fix is found soon
 
MS is trying to push Outlook users into their Office 365 subscriptions. They are retiring "basic authentication" for their O365 service since October and only allow basic authentication until January 31st 2023 when users explicitely re-enable the feature. "Basic authentication" in MS terminology is nothing else than ordinary IMAP, POP and SMTP authentication as all people outside the MS world are using it. MS argues that IMAPS, POPS and SMTPS are no safe methods to authenticate and transmit emails.

Beyond January 2023, no IMAPS, POPS, SMTPS etc. connects will be possible to O365 accounts. As of now they will still work with normal mail servers. But on O365, all users are being forced to stick to "modern authentication", which "accidentally" happens to work flawlessly with MS Exchange only. To my current knowledge, MS does not provide any support articles that show solutions on how to keep using IMAP, POP or SMTP along with O365 accounts. Also, Outlook in all the modern versions 2xxx never worked right with IMAP outside O365, specificially with folder management, and there are no plans to make it work correctly. It's moving away from being a good email client and more towards becoming a proprietary Unified Messaging Client for the MS Exchange environment. And we have all seen the long discussions here on the forum on autoconfig failures of Outlook, too. It's a nice tool, but reality seems to be that MS does not care about normal mail servers much, at least not with Outlook. They do a lot to push their proprietary solution to bind subscribers. Once support for IMAP, POP and SMTP with basic auth to O365 accounts is dropped we can expect their removal for "security reasons" in general. There are no plans made public on that so far, but seeing the path that their ecosystem has taken in the past, I think there is some likelihood that this will be a next step.

So for all of you who want a free mail world, you may want to recommend your customers a migration away from Outlook to other mail clients. It may be difficult to explain, but at least personally I still think it is important that the IT experts are aware of it and are watching this development closely so that they can advise their customers accordingly.
 
"NO_TICKET Enabled by default when needed in fully-patched Postfix ≥ 2.7. Not needed at all for Postfix ≥ 2.11, unless for some reason you do not want to support TLS session resumption. Best not set explicitly. "

I am wondering what other consequences NO_TICKET has besides allowing the connect? For example does this tell Postfix to ignore certificate failures? What does it do exactly?
 
According to RFC4507 there are a lot of "MUSTs". Omitting the ticket resumption capability downgrades the mail server's capabilities in session handling of TLS. So probably setting the value to "NO_TICKET" will have an impact on other mail software. If mail servers were meant to work without the function, that would probably be their default setting. Before this change (removing the session ticket resumption capability) is applied it should be tested with many different mail applications.

I am not yet convinced that the parameter change is a lasting solution and should be applied to servers that are used by many different mailbox users. To me it is still unclear what the practical impact will be.
 
Peter Debik said:
According to RFC4507 there are a lot of "MUSTs". Omitting the ticket resumption capability downgrades the mail server's capabilities in session handling of TLS. So probably setting the value to "NO_TICKET" will have an impact on other mail software. If mail servers were meant to work without the function, that would probably be their default setting. Before this change (removing the session ticket resumption capability) is applied it should be tested with many different mail applications.

I am not yet convinced that the parameter change is a lasting solution and should be applied to servers that are used by many different mailbox users. To me it is still unclear what the practical impact will be.
Click to expand...
I wrote it on my site - this is only a temporary fix. The error is clearly on the Windows side, where it needs to be fixed.

In my opinion, this modification should work with any email client. "Ticketing" is still just an extension of the protocol and if the client or server does not understand it, a fallback is made to the "session-ids" built into SSL.
 
There is a chance that MS has already fixed it, because as @Mehl has stated in the release candidate state for Outlook it seems to work as it did before the upgrade. For our customers here I tend to rather recommend using that switch than to apply the mail server change. For users that operate a Plesk with only a few subscribers or maybe only for their own use, the server-side change could be the right thing. I'd love to hear from other users here what their experience is with other mail clients when the NO_TICKET option is applied.
 
You must log in or register to reply here.

Similar threads

T
Issue Smtp encrypted no longer works since the latest Windows update
Replies
2
Views
1K
telo
T
M
Resolved Outlook Error 0x800ccc1a after Client update to Windows 11 22H2
Replies
3
Views
1K
bazzil
B
VojinP
Issue Cannot connect to SMTP on Plesk for Windows with SSL or TLS
Replies
12
Views
13K
VojinP
VojinP
custer
Removing deadweight in Plesk Onyx
Replies
0
Views
11K
custer
custer
J
How to start your online store with WooCommerce
Replies
0
Views
3K
joerg
J
Back
Top