dovecot - Nov 2016 - <-FIN <-RST ->FIN,ACK <-RST on SSL connection shutdown

Hello,

a typical connection close, tcpdump'ed on the server side, looks as follows:

21:44:01.168131 IP xxx.xxx.3.101.143 > xxx.xxx.3.96.35518: Flags [FP.], seq
3982457856:3982457959, ack 1570044906, win 243, options [nop,nop,TS val
138698279 ecr 159494908], length 103
21:44:01.172405 IP xxx.xxx.3.101.143 > xxx.xxx.3.96.35518: Flags [R], seq
3982457960, win 0, length 0
21:44:01.172442 IP xxx.xxx.3.96.35518 > xxx.xxx.3.101.143: Flags [F.], seq
32, ack 104, win 342, options [nop,nop,TS val 159494909 ecr 138698279], length 0
21:44:01.172471 IP xxx.xxx.3.101.143 > xxx.xxx.3.96.35518: Flags [R], seq
3982457960, win 0, length 0


The server closes (FIN) the connection, and already 4.274 ms later the server
sends a RST to
the client. The clients response to FIN arrives some ?s later. (On the
client side the order of the packages is different (FIN from Server,
FIN,ACK from client, RST from Server, RST from Server)

This behaviour seems to be odd (the client side firewall complains about
the unexpected packages).

I can reproduce it using openssl -connect ? -starttls imap .. on the
client side. It happens on IMAP+STARTTLS as well as on IMAPS. It does
not happen on plaintext IMAP. There I see the expected shudown handshake
FIN - FIN,ACK - ACK.

Dovecot version is 2.2.24 (a82c823)

    Best regards from Dresden/Germany
    Viele Gr??e aus Dresden
    Heiko Schlittermann
-- 
 SCHLITTERMANN.de ---------------------------- internet & unix support -
 Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
 gnupg encrypted messages are welcome --------------- key ID: F69376CE -
 ! key id 7CBF764A and 972EAC9F are revoked since 2015-01 ------------ -
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20161109/ea6a67e3/attachment.sig>