Issues with Outlook 2010 Sending Mail following RHEL7 QMail update...

Good afternoon.

One of our RHEL7 InterWorx Servers had updates to mail packages last night, and today one of the domains where the client uses Outlook 2010 gets the following message when they try to send mail :

"Sending reported error (0x800CCC80) : ‘None of the authentication methods supported by this client are supported by your server.’

Due to ISP restrictions they’re sending through port 587 which we have set to SMTP-AUTH over TLS required. It’s worked fine until this point, so we’re wondering if the recent update made any changes to the TLS requirements?

Thanks!

Phil D. Malmstrom
philm@diamondcomputer.com

Just a thought, they might have removed support for older TLS. I did this myself a while back so I could past those PCI test. I think on some Windows 7 computers you have to change some config so that they will use the updated TLS as well. Not sure if this is your issue, but worth looking into.

Take a look at these two threads back from when I was dealing with this.

http://forums.interworx.com/forum/general-interworx-cp-info/general-inquries/4856-has-anyone-got-starttls-to-work-for-imap

http://forums.interworx.com/forum/nodeworx/general-discussion-aa/4861-feature-request-add-sslprotocol-to-nodeworx-ssl-page-certificate-import-idea

Thank you Sir… That was my thought as well and it turned out to be the case. We did the Registry changes on the affected machines as documented by Microsoft and the issue was resolved.

Thanks again!

-Phil

So, it seems it’s more widespread than a few older Outlook clients having issues. Is there any way to re-enable the support for the older TLS versions?

Thanks!

-Phil

Hi Phil

If you login to nodeworx, server, ssl and you can then set your ciphers and protocols

Please remember to restart services such as email etc to be sure

If that does not work, you can edit the TLS-pop3s files etc for the protocols you want but I suspect the above should suffice

Many thanks

John

Hi Bertie

I hope your well

I think it must be the IW RC update to 6.3.1 as changelog shows

:black_medium_small_square:Updated the default TLS form qmail to TLS1.1+ for better compliance with PCI scans. This can be overridden at /var/qmail/control/tlsprotocol

so looking back, I think the protocols were

HIGH:!MEDIUM:!EXPORT:!SSLv2:!ADH:!aNULL:!eNULL:!NULL:!LOW:!RC4

and now are

ALL:!kRSA:!SRP:!kDHd:!DSS:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK:!RC4:!ADH:!LOW@STRENGTH

Many thanks

John

Hi Bertie.

Those are the same updates that led to our issue. When we made the modifications to the Windows Registry to enable TLS 1.1 and 1.2 in the clients experiencing issues, their problem went away (https://blogs.technet.microsoft.com/schrimsher/2016/07/08/enabling-tls-1-1-and-1-2-in-outlook-on-windows-7/). We have however, run into an issue sending from an older Interworx mail server still running on CentOS 5 to the updated server. The messages eventually bounce back as undeliverable with :

TLS not available: connect failed: error:00000000:lib(0):func(0):reason(0)

We’re in process of working to migrate domains off that server, but for the moment it’s an issue.

-Phil

Hi Bertie and phill

I would check the qmail tlsprotocol file shown in changelog above and make sure tlsv1 is not ! out or add tlsv1 back in

Phill, the issue is tlsv1 has been disabled so your 5 server cannot agree/use that protocol

You could whitelist the server ip as trusted in nodeworx I think

Bertie, those updated files look like it?s updated to newer versions

Please remember to stop/start email services once any changes have been made for them to take effect

Many thanks

John

Hi Bertie

Many thanks and sorry not in front of a computer- using Tapatalk from mobile

It would be tlsservercipher I think from memory

Please remember to restart email services

Many thanks

John

I believe you can control the protocols via NodeWorx SSL settings (https://yourserver.com:2443/nodeworx/ssl). When I originally worked on this I was editing the config files directly on the shell, but don’t think this is needed anymore. I’m guessing you can just add support back in for older TLS for now. I think InterWorx just removed them because those old TLS protocol are not secure anymore, but doubt they will specifically block you from adding it back.

This thread I shared above should shed a bit more light on this: http://forums.interworx.com/forum/nodeworx/general-discussion-aa/4861-feature-request-add-sslprotocol-to-nodeworx-ssl-page-certificate-import-idea

Hi Bertie and Phill

I believe I have this figured out

You need to create the file tlsprotocol (/var/qmail/control) and if you add the following into the new file, you will enable TLSv1 as follows:

SSH into server

vi /var/qmail/control/tlsprotocol

HIGH:MEDIUM:!SSLv2:!ADH:!aNULL:!eNULL:!NULL:!LOW

Save

service smtp restart

Hope that helps a little

Many thanks

John

Test before tlsprotocol added - no TLSv1

Testing protocols via sockets

SSLv2 not offered (OK)
SSLv3 not offered (OK)
TLS 1 not offered
TLS 1.1 offered
TLS 1.2 offered (OK)
TLS 1.3 not offered

Test after tlsprotocol added - TLSv1 now available

Testing protocols via sockets

SSLv2 not offered (OK)
SSLv3 not offered (OK)
TLS 1 offered
TLS 1.1 offered
TLS 1.2 offered (OK)
TLS 1.3 not offered

Hi Bertie, phill and Justin

I?m sorry I was nearly correct in a fashion but Jenna let me as below

Many thanks

John

Hello–

For that email issue, the latest update set TLS 1.1 as the default, which could affect older mail clients that do not have that option. If anyone puts in a ticket, they can resolve this by creating a file called /var/qmail/control/tlsprotocol and add: TLSv1+

cat /var/qmail/control/tlsprotocol
TLSv1+

Hi John.

Thanks so much for your help… That did the trick!

Have a great day!

-Phil