Cannot send mail to certain recipients. SMTP STARTTLS failure (8922)

1 Likes

Symptoms

Cannot mail certain recipients. The sender sees this in the GW Client:

 

 

 

The reason given for the delay: 420 TCP write error

 

 

 

The following is shown in the GWIA log:

 

 

 

07:11:54 2323 DMN: MSG 2815270 Attempting to connect to mail12.surftown.se 07:11:54 2323 DMN: MSG 2815270 Connected to [212.97.132.52] (mail12.surftown.se) 07:11:54 2323 DMN: MSG 2815270 SMTP STARTTLS failure (8922) 07:11:55 2323 DMN: MSG 2815270 SMTP session ended: [212.97.132.52] (mail12.surftown.se)

 

 

 

 

Diagnosis

The best way to troubleshoot this would be to get a packet trace. On the GWIA server:

 

 

 

tcpdump -i any -s 0 -w /root/surftown.cap host 212.97.132.52

 

 

 

This will capture data just for that ip. Note that you cannot filter on a single IP if the recipient has multiple ones.

Open the packet trace in Wireshark. Look at the client and server hellos:

Client Hello. That is you:

clipboard_image_0.png

You are indicating that you support TLS up to 1.2. Ideally the receiving mailserver should use that version, but instead:
 
clipboard_image_2.png
Here the receiving mailserver uses TLS 1.0 and that protocol is regarded as unsecure and was deprecated in June 2018. GW 18.2 will not talk to him.

Solution

Ask the admin of the receiving mailserver to upgrade to a supported version of SSL

Labels:

How To-Best Practice
Comment List
Anonymous
Parents
  • 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

Comment
  • 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

Children
No Data
Related Discussions
Recommended