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

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