On Mon, Dec 15, 2008 at 05:28:45PM -0500, Victor Duchovni wrote:
> I am sorry, please provide *corresponding* logs and PCAP files, one
> of each for a successful delivery and an unsuccessful one. The logs
> must include the clear-text of all client server SMTP interactions.
> You can drop the smtpd_tls_loglevel to 1 or 0, just the protocol
> debugging is sufficient. Log entries of the form:
On second thought make that smtpd_tls_loglevel=4 (!).
> Dec 15 14:38:51 [postfix/smtpd]
> < auxiliares.chapule.ich.edu.mx[192.168.10.4]: RCPT TO:<t...@test.bg>
>
> Dec 15 13:19:43 [postfix/smtpd]
> > auxiliares.chapule.ich.edu.mx[192.168.10.4]: 250 2.1.5 Ok
>
> 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?
Anything interesting the kernel TCP stack (traffic shaping, ...).
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?
--
Viktor.
Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.
To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:majord...@postfix.org?body=unsubscribe%20postfix-users>
If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.
