Robin H. Johnson wrote:
s_client is in the wrong, because it didn't wait for the 220 output to complete
before starting the transaction. qpsmtpd is in the wrong because it gets
confused.
ENOTOURPROBLEM
s_client is not a real mail client, so the fact that they have a
-startls option isn't necessarily typical of other mail clients. The
entire 220 line is required to be accepted before the next exchange
begins (that is what the RFC's state).
I also don't think qpsmtpd is the one that is confused. It seems
obvious from the traces below:
SSL_connect:SSLv2/v3 write client hello A
read from 005707C0 [00576950] (7 bytes => 7 (0x7))
0000 - 32 32 30 20 47 6f 220 Go
0007 - <SPACES/NULS>
SSL_connect:error in SSLv2/v3 read server hello A
27620:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown
protocol:s23_clnt.c:601:
SSL_connect:SSLv3 write client hello A
read from 005705C0 [00576750] (5 bytes => 5 (0x5))
0000 - 32 32 30 20 47 220 G
write to 005705C0 [00580910] (7 bytes => 7 (0x7))
0000 - 15 32 30 00 02 02 46 .20...F
that s_client is trying to merge the text that qpsmtp has already sent
(as part of the 220) with the actual TLS server greeting that qpsmtpd
has sent. s_client is reading only 5 and 7 bytes of the previous line
before sending the TLS hello. It looks like s_client isn't clearing the
buffer after the last read, so the trailing bits of the previous line
are interfering with the negotiation. There is nothing qpsmtpd can do
to recover from that AFAICT.
You'll need to open a bug with the OPENSSL people...
John
