Wikis - Page

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
Parents
  • 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.

     

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

     

Children
No Data
Related
Recommended