On January 13, 2010 12:27:02 PM -0500 Wietse Venema <wie...@porcupine.org>
wrote:
Frank Cusack:
Contrary to what I said earlier, tcpdump is in fact interesting. I see
a 3 way handshake, and that's it. 10 minutes later, a reset. However
postfix logs a disconnect immediately. I do notice that their mss is
only 1260, so clearly they are going through some kind of packet mangling
firewall. But that doesn't excuse postfix for declaring the connection
disconnected when in fact no packet came from them.
Would you be willing to share this complete evidence so that other
people can learn from it, or do you expect that we just take your
eyewitness report every claim made here sofar?
Easy there. I am just reporting my interim findings. I thought I
had enough info to be worth the incomplete followup and took the
opportunity to muse a bit. I certainly wasn't casting any aspersions
on postfix.
Perhaps surprisingly, Postfix does not send or receive network
packets. Instead, packets are handled by the TCP/IP implementation
in the operating system kernel.
If anything decides "prematurely" that the connection is dead, it
is your operating system kernel not Postfix.
Unless of course postfix has a bug (heaven forbid).
Anyway that's why I added the note about how it seems impossible
that smtpd would die prematurely without my then seeing FIN/RST.
That can't happen unless someone is holding onto the connection
and would seem to exonerate postfix.
I haven't been able to prove this yet (have to wait the agonizing
delay until the remote server tries to run the queue again) but
I think maybe the smtpd log report actually occurs when the FIN
comes (firewall timeout, probably), not when the connection comes
in. If I create a test host with a huge PTR RRset, and connect
from there, postfix does not reply with a banner. Ever. (OK not
for at least 10 minutes.) This does in fact coincide with my tcpdump;
I see only the handshake and nothing else. When I disconnect from
my test host nothing gets logged whatsoever, not the connection and
not the disconnect. I think the OS resolver is indeed broken and/or
postfix is not handling the bug well. Not sure yet if postfix could
actually do anything about it. Also not sure yet why postfix logs
something for the real problem host and not my test host. Perhaps
the difference in how FIN vs RST is presented to the process holding
that fd.
-frank
