2009/10/10 MySQL Student <mysqlstud...@gmail.com>: >> Unfortunately, you deleted lots of useful information from the >> logging, including the break-down of handshake delays and of >> transmission delays. > > I wasn't sure that I should post the whole queued message here.
The logs for a single message are usually about half a dozen lines or less. Ingress, cleanup, queue manager, egress, removal; not big at all, and very useful. Mask "private" information if you must, but keep in mind that it can make it harder for others to help diagnose problems. >> - Broken TCP window scaling support in firewall or end-host. Postfix >> 2.6 and later have a main.cf:tcp_windowsize parameter. Setting >> this to some value under 65536 will work around this, otherwise >> you'd have to poke the kernel with sysctl or whatever. > > Many of the messages themselves are less than 65k. Does this make a > difference? I can't comment with authority, but I'd say "not directly". The TCP window generally counts bytes on the wire, which means there's other overheads in play, not just the message data. > Why would it only be broken handling some messages and not others? Or > is that what only tcpdump would be able to tell us? My first thought is, "we need to know more about these messages". You say they're mostly for one domain, but you don't really specify whether it's in or out, etc. Are the problematic messages perhaps: - all from the same domain, to other domains? - all to the same domain, from other domains? - all to/from one user/address? >> debug_peer_list can turn on logging for specific sites, not messages. > > It's really more of a mail router, so only handles mail for a single domain > :-( You mentioned a relayhost (smarthost) earlier. Do all mails go through it? Do the messages going via the relayhost have problems? Maybe the ones that don't go via the relayhost have problems? If you can narrow that down a little, you could use debug_peer_list on that host specifically, which may help.
