On 2008-01-23 08:20, Gabriele Bulfon wrote:
Blacklists are not an issue, because my connection would be refused much eralier than when it happens: it usually timeouts during the send of DATA or at the end of the DATA chunk.
While your other diagnostic may rule out blacklists, your assumption about the behavior when blacklists are involved is incorrect.
As I mentioned, some MTAs apply a honeypot strategy to blacklisted IPs in an effort to slow down the transmitter. I.e., when they will refuse based on a blacklist, they go as far as allowing DATA, set a very long reject delay, and then respond with a 4xx or 5xx after DATA is complete. In addition, some blacklist tests are held out until DATA so that content filters can be applied to the inbound message, and also to make it ambiguous for the sender whether a blacklist is involved (not that the latter is a good practice).
Last but not least, any of these options seem to be the case, because the queue instantly flushes correctly if I temporarily disable ipfilter and run "postqueue -f".
When you snoop, what do you see on the outside when the hangs occur? Are there retransmits going on? Was there an RST packet? Are there frags? What is IP filter logging? Are you using a return-rst policy for your TCP block rules? What do the block rules look like? The excerpt you posted is too short.
Infact, I noticed that the machines having those problems are the ones I recently upgraded to new hardware and consequentely coming with newer releases of Solaris 10.
Is hardware checksumming enabled? Sometimes this causes bad behavior.
What I'd like to know, is if there is some way to remove the original packages and replace them with compiled binaries from the distribution, without having to reboot the machines.
I think you're better off finding the correct solution to the problem, as it's unlikely that it will only exhibit itself where Postfix is involved.
Even if you do run an alternate Postfix, there's no reason to remove the native load. Just disable it.
-- Jefferson Ogata <[EMAIL PROTECTED]> NOAA Computer Incident Response Team (N-CIRT) <[EMAIL PROTECTED]> "Never try to retrieve anything from a bear."--National Park Service
