Hello community, how are you?, I hope everybody is fine.

Here in Argentina and Chile have detected several clients that after migrating them to version 18.2.1 report problems sending emails to O365 domains.

The error reported in the GWIA logs is 550 Host Unknown.

After testing we have been able to detect that the GWIA uses TLS 1.0 regardless of the --sslOption that we use.
If we make the GWIA relay via an AntiSpam, the emails arrive correctly at their destination, since the AntiSpam (MailCleaner, SMG, etc) has no problem using the new versions of TLS.

Note: The minimum version accepted by O365 is 1.2.

In the meantime, I just opened a SR.

Bes regards.,

If I could chime in here on the original reason for the thread with the GWIA and forcing TLS 1.2 or 1.3... This is a massive design flaw on part of the GroupWise developers. I'm currently dealing with this same issue with a customer. The GWIA, if TLS fails to establish a connection, should revert back to non-TLS. Sitting there retrying, with no chance of ever establishing a connection, until it reaches the defined timeout period, is just asinine. 

It either needs to generate an error that fails immediately and users are notified (Not a real solution but at least creates awareness of a problem sooner), or it needs to downstep to NON-TLS and allow the message to be delivered.

Saying this is a security issue is completely BS..  

1) If I want to mandate TLS and not allow non-TLS connections, I can choose that option on the GWIA.  However, it's generally not practical unless I'm sending all mail off to a 3rd party relay or spam device and I can guarantee that it will always be successful at negotiating TLS. 

2) Knowing that and being able to adapt to systems out there do not support newer TLS versions is the same as knowing that some systems out there still do not even support TLS at all.  So when you're sending an email, you can't possibly know what configuration the recipient system will have. You just know you need to get the email through...     So it's standard practice to configure the GWIA so that TLS is enabled but not required. That way when there is a failure to negotiate TLS, it steps down to non-TLS and the mail is delivered.   

3) Saying that by allowing TLS 1.0 or lower is a "security issue" is complete garbage thinking.   Sending email in non-tls is not secure either, but we allow that because sometimes we have to. It's just how the world works.

So the solution needs to be this: The GWIA needs to fail TLS and then downstep to GWIA rather than fail to downstep and generate a TCP 420 error because there's a TLS mismatch.

In the meantime now I have to automatically add this dumb switch to every GWIA for every customer I have so that they don't have delivery issues. 

Also to the point that someone said: "Change your retry from 96 hours".  That's not a solution, that's just trying to pretend it's a nice workaround. The reality is that even once the user gets a failure notice after whatever the timeout is, they still can't resend and get the mail to go through. They're absolutely stuck.  Even the admin can't help them.   Also,  I haven't used the default 96 hours for years.  I typically set my customers to 4 or 6 hours, but in this scenario, that is still not acceptable. What's the point of retrying a message that you KNOW WILL ABSOLUTELY FAIL EVERY SINGLE TIME.. Just fail the message already and return notification to the user, which still doesn't resolve the issue. I guess they can go over to their gmail account and send it from there.   Here's a better idea:  Fix the GWIA so this isn't a problem in the first place. 

Marvin

That was very wild guess, that changing TLS on GWIA will somehow change every GroupWise agent´s TLS setting. 

It´s problem with Retain plugin for sure, which is very old ( 2016 ) .

That's the reason why I was asking, Massimo. I do not see a connection now.

Diethmar

 
That makes no sense to me. The groupwise retain plugin simply opens the retain website from within the groupwise client, while passing on the groupwise credentials to it. What in this process does not work?

Also, Retain runs in recent Tomcat and/or Apache versions, but SSL has to be all manually enabled (by default retains runs unencrypted). So it surely supports anything you like (or configure) in terms of TLS in either Tomcat or Apache.

Well, I assume you "downgraded" your POA ...

I mean GroupWise Retain plugin, which is for single sign-on. 

What do you mean by "stop working", David?

Does your search within GroupWise not work? If yes, then please open a SR - you will get some new code. That's my experience 

Diethmar

It looks like, that this TLS 1.1 problem has larger consequences. When you downgrade GW 18.2 to TLS 1.1 AND you have Retain 4.9, GroupWise Windows client plugin will stop working because of Retain 4.9 doesn´t support TLS 1.1   :(.