Why do I get RENEGOTIATING when sending RCPT TO to my SMTP service behind an AWS NLB?

Question

I'm using ECS Fargate via a network load balancer (NLB) using TLS 1.2 to host an SMTP service that uses the standard SMTP interrupts to communicate with the client.

I'm testing the service via openssl.

This works fine both locally and both on Fargate:

$openssl s_client -connect xxx.com:443
HELO
250 OK
MAIL FROM:[email protected]
250 OK
QUIT
250 OK

However, the Fargate service works fine for all SMTP commands on NLB/Fargate except any command that starts with the character R e.g. RCPT TO:.

I get RENEGOTIATING followed by connection close, which does not happen locally.

$openssl s_client -connect mynlbhost.tampabayclosure.com:443
HELO
250 Hello
MAIL FROM:[email protected]
250 OK
RCPT TO:[email protected]
RENEGOTIATING
write:errno=54

I tried openssl s_client -connect host:port -no_renegotiation & openssl s_client -connect host:port -no_renegotiation -tls1_2 none of which worked.

What is the issue?

Answer 1

Either of these solutions will work:

1. Use TLS v1.3

2. Use openssl s_client -quiet to suppress the interactive interpretation of R and Q characters

3. Use rcpt to: (which you can since SMTP commands are case-insensitive according to RFC 5321)

---

What is the issue?

This behaviour is related to openssl s_client:

When used interactively (which means neither -quiet nor -ign_eof have been given), and neither of -adv or -nocommands are given then "Basic" command mode is entered. In this mode certain commands are recognized which perform special operations. These commands are a letter which must appear at the start of a line.

R
Renegotiate the SSL session (TLSv1.2 and below only).

This is why you’re seeing the RENEGOTIATING message followed by a connection close when you input RCPT TO: or any other command starting with R.

Note that the position of the R is important - that's why you didn't get this issue when you used MAIL FROM: even though it contains an R.

---

does not happen locally

This is most likely because you're not using SSL locally.