> I've posted with one kind attempt at fixing a problem. My ISP's mail > went down then said the problem was fixed. I'm still getting prblems > where eveything was ok before. Mostly I'm getting a socket error and > expected length problems. I have a selected log of the highlights > andadditional details if anyone can help. I'm not including the file so > as to not clog the list, even though it's 20k...
I trust that you've already checked Fetchmail's FAQ here http://www.tuxedo.org/~esr/fetchmail/fetchmail-FAQ.html, but if not, there's a few items related to socket errors and dying during mail fetching. ==================== Here they are: R7. Fetchmail randomly dies with socket errors. Check the MTU value in your PPP interface reported by /sbin/ifconfig. If it's over 600, change it in your PPP options file. (/etc/ppp/options on my box). Here are option values that work: mtu 552 mru 552 ==================== R9. Fetchmail is timing out after fetching certain messages but before deleting them There's a TCP/IP stalling problem under Redhat 6.0 (and possibly other recent Linuxes) that can cause this symptom. Brian Boutel writes: TCP timestamps are turned on on my Linux boxes (I assume it's now the default). This uses 12 extra bytes per segment. When the tcp connection starts, the other end agrees a MSS of 1460, and then fragments 1460 byte chunks into 1448 and 12, because is is not allowing for the timestamp. Then, for reasons I can't explain, it waits a long time (typically 2 minutes) after the ack is sent before sending the next (fragmented) packet. Turning off tcp timestamps avoids the fragmentation and restores normal behaviour. To do this, [execute] echo 0 > /proc/sys/net/ipv4/tcp_timestamps I'm still unclear about the details of why this is happening. At least [now] I am now getting good performance and no queue blocking. ==================== R10. Fetchmail is timing out during message fetches This is probably a general networking issue. Sending a "RETR" command will cause the server to start sending large amounts of data, which means large packets. If your networking layer has a packet-fragmentation problem, that's where you'll see it. ==================== Good luck ! Hall Stevenson
