The real problem is that the connection was terminated mid-transaction.
The "shutdown while in init" is I think a distraction, Postfix was
cleaning up the TLS session, when it was not yet, or is no longer in a
state that is valid for calling SSL_shutdown(). If you manage to
collect a PCAP capture of the traffic for a failed delivery, it should
be possible (especially if limited to TLS 1.2, which is a bit easier to
debug from TCP captures) to see whether the failure is at the
application or TCP layer.
I think your next step is to get a PCAP of the traffic.
I've captured the relevant conversation. In doing so, it became clear to
me that when the message succeeds after immediately trying again, it
does so because the subsequent connection does not try to use TLS. So
the pattern is: attempt TLS connection, fail, attempt plaintext
connection, succeed. This was alarming to realize.
From the pcap, in brief: I see the connection, STARTTLS, TLSv1.2
handshake succeed, "application data" packets being exchanged using
TLSv1.2. Finally, my mail server sends two TCP packets with the RST flag
set. Between those two packets is an 'encrypted alert' packet from the
foreign mailserver.
I'm not certain on the norms of this mailing list but I can put the
entire pcap somewhere if it would be helpful, it's 35 frames long.
Alexander
