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

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

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 (2)

DISCLAIMER:

Some content on Community Tips & Information pages is not officially supported by Micro Focus. Please refer to our Terms of Use for more detail.
Comments

Sorry, this is a bug. Groupwise is supposed to fallback to plaintext (unless TLS/SSL is set to mandatory, which it virtually never is), and it doesn't.

Add this to the GWIA 18.2 startup file:

--sslOption "SSL_OP_ALLOW_TLSv1_1,SSL_OP_ALLOW_TLSv1"
 
 

Thanks Laura, this is a workaround (am I right there is not yet a TID containing this?).
But the fact remains that even under the original configuration, GWIA is supposed to fallback to unencrypted transfer when starttls doesn't succeed, and itdoesn't. This should be looked at, regardless what the cause for the failure in STARTTLS negotiation is.
Simply not sending the mail is wrong, and on top, pointlessly deferring and retrying it (420 Error as a final result) is yet another mistake in the code.

 

Thank you for the reminder Massimo.

https://support.microfocus.com/kb/doc.php?id=7024361 

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.

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.

Pam

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

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.

 

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.  😪

 

Top Contributors
Version history
Revision #:
3 of 3
Last update:
‎2019-11-25 14:11
Updated by:
 
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.