Victor Duchovni escribió:
On Mon, Dec 15, 2008 at 05:59:52PM -0500, Victor Duchovni wrote:
and the exact corresponding PCAP capture.
In the capture you provide:
14:52:49.198960 192.168.10.4.4052 > 192.168.10.248.587: P 582:635(53) ack 5831
14:52:49.200609 192.168.10.248.587 > 192.168.10.4.4052: . ack 635
Client sends RCPT TO:<...>
Server TCP ACK
14:52:49.814719 192.168.10.248.587 > 192.168.10.4.4052: P 5831:5884(53) ack 635
14:52:49.825203 192.168.10.4.4052 > 192.168.10.248.587: P 635:672(37) ack 5884
14:52:49.825214 192.168.10.248.587 > 192.168.10.4.4052: . ack 672
Server responds 250 2.1.5 Ok
Client ACKS and sends something of the right length to be "DATA"
Server TCP ACK
14:52:49.853073 192.168.10.248.587 > 192.168.10.4.4052: R 5884:5884(0) ack 672
The server TCP ACK is directly followed by an unsolicited TCP RST, and
the most you can expect out of Postfix is FIN, not RST. Where are you
capturing the session, at the client or the server? What software on
the server aborts a TCP session with a RST without receiving traffic
for an already torn-down connection?
Apparently some Linux (and other) systems implement "half-duplex" TCP
close, which sends RST, not FIN when a socket is closed with application
data unread. If so, we must conclude that indeed the server closes the
connection without reading the client's command. I want to see the
"smtpd_tls_loglevel = 4" packet logging.
I want to see whether Postfix (which version again?) go to see the
last chunk of client data.
By the way, the successful session you sent, is a "resumed" session,
that re-used the SSL keys negotiated at the previous session. All
this changes is the amount of data sent back and forth between client
and server. I am again puzzled by the unclean 3-way FIN handshake:
14:53:06.135744 192.168.10.4.4061 > 192.168.10.248.587: P 964:1001(37) ack 942
14:53:06.135757 192.168.10.4.4061 > 192.168.10.248.587: F 1001:1001(0) ack 942
14:53:06.150498 192.168.10.248.587 > 192.168.10.4.4061: R 942:942(0) ack 1002
Client sends FIN, but server sends RST. In what manner have you "tuned"
your server TCP stack to cause this?
This too is interesting, what is it that the server leaves unread in
the success case?
Here is the log with smtpd_tls_loglevel = 4 (with a retry just after the
error) and the corresponding pcap file:
postfix-2.txt <http://www.ich.edu.mx/attachments/postfix-2.txt>
tcp-2.cap <http://www.ich.edu.mx/attachments/tcp-2.cap>
