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



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 07:11:54 2323 DMN: MSG 2815270 Connected to [] ( 07:11:54 2323 DMN: MSG 2815270 SMTP STARTTLS failure (8922) 07:11:55 2323 DMN: MSG 2815270 SMTP session ended: [] (






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




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:


You are indicating that you support TLS up to 1.2. Ideally the receiving mailserver should use that version, but instead:
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.


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


How To-Best Practice
Comment List
  • Right, David.

    I know that there are still some bugs to fight and to get rid of. However we should honor the efforts to make a product more secure. And we have to tell development if they create a solution which does not fit to the market.

    (btw 96 hours a too long in our business world - I use always 24 hours)

    Use "Verified Answers" if your problem/issue has been solved!

  • Dietmar,

    my point is NOT less security, but functionality first. Have you read what wrote Massimo about the 420 error ? User should get immediately information, that there is no go. Instead is GWIA wrongly trying 96 hours to convince "bad guy" on other end to improve security. There is no one who is listening. 

    If there is only one, which isn´t playing right, you can make consultancy, but not with 20 or 30 of it. 

    This isn´t solution, but only workaround. 


  • No, I do not agree David.

    Security is important. If you can live with less security then you can change your GWIA options. It's your world and your responsibility.

    This TID delivers an option if the original setting does not fit. And because you know the product you searched for a solution and found a solution - that is consultancy - outside of the "next button" community.

    Use "Verified Answers" if your problem/issue has been solved!

  • Hi,

    I see that GroupWise development is holier than Caesar’s wife. I upgraded to 18.2 and see what  ? Users started complaining, that they can not send emails, because of this great new super secure feature. 

    Internet is full of unpatched / old etc email servers , but users dont care, they need to send emails, very important emails, business emails . 

    If you so care about security, why there is no such function to downgrade to SSLv1 AND send email to postmaster , that his system is unsecure ? Or at least GroupWise system admin ?

    This is totally wrong ! I bet, that 99 % of admins , which upgrade to 18.2 will use TID 7024361 to make email work again.




  • When I first upgraded to 18.2 I added --ssloption "ssl_op_allow_tls_v1_1,ssl_op_allow_tlsv1" to my POA configs to support Macs. It was working and didn't think anything more of it.  Tuesday I upgraded my last remaining domain and PO to 2018.2 and much of my environment stopped working. The POAs would fail to connect to the MTAs. Finally I added the switch to my MTAs and the POAs began to work again. I had to update every POA, MTA and GWIA to allow tls1 before mail was working again.


    This whole thing would have been avoided if either there was a new Mac client or if the new Web client that's still in development was featured completely enough to replace the 10 year Mac client. 


  • Not allowing unencrypted at all is a prominently configurable option in GWIA already, so it's up to the admin to decide, there is absolutely no point to override that conscious admin decision from MF side. The admin, if he cares to, *can* himself disallow unencrypted transfer.

    On top, it's still totally unrealistic to enforce encryption on public SMTP servers, *WAY* too many legit SMTP servers out there do not (or not properly) support starttls yet, so enforcing it cuts you off from a significant amount of the internet.

    Last but not least, the supposedly "conscious" decision is implemented in a broken way, resulting in a pointless deferral and retry of the sent mail, with an error to the sender only days later when the retries have exhausted. *If* this is on purpose, at the very least on failure the GWIA has to give up immediately and send an error report back to it's sender.

    That alone warrants a bugzilla entry, and moves this outside the scope of an IDEA.


  • No. I am quite happy now there is a workaround. It is still very hard to find in the KB though.

  • Massimo,

    Laura turned this over to me.  In checking with engineering, as they are the ones that made the decision, here is what I have gotten back.

    We discussed the fact that GWIA does not fallback to unencrypted transfer.  We did not want to ever use TLS 1.0 without the admin explicitly "dumbing down" their system.  The fallback to unencrypted transfer could be argued, but we never recommend allowing unencrypted.

    So if you still believe that GWIA should fallback, please enter an enhancement request and let Mike decide if this is a decision he wants to reverse.


  • Thanks for the TID Laura, but I'm afraid I'm still unhappy. 

    Like the TID says, TLS 1.0 is considered insecure, yet the TID only tells people to how to re-enable an insecure protocol again. But all this still ignores the fact that this is all only necessary, because GWIA does *not* fallback to unencrypted transfer as it should (per it's configuration), but simply fails to send the mail altogether.

    So sorry for being insisting, but is there an exiting bug for this? If not, can/would you enter one? Or does Microfocus consider the current Situation not a bug, but properly working code?

  • Massimo - I'm busy making enquiries but am out of the office for the next 10 days or so.