First... Sam.... Courier is great... In running it 12 months-ish this is the first reall problem I've encountered....
My courier/fetchmail setup is having problems related to the SMTP RSET command sent by fetchmail to courier in response to courier refusing delivery (ie message is deemed as SPAM by the BOFH settings) Fetchmail receives the "550 Spam refused" and reports that courier refused delviery then sends an RSET. Courier responds to the RSET but - it appears - often not for 20-70 seconds. When the delay is >60 seconds, the upstream ISP pop3 connection has timed out (it seems to have a 60 second timeout). fetchmail: SMTP< 250 Ok. fetchmail: SMTP> RCPT TO:<[EMAIL PROTECTED]> fetchmail: SMTP< 250 Ok. fetchmail: SMTP> DATA fetchmail: SMTP< 354 Ok. fetchmail: SMTP>. (EOM) fetchmail: SMTP< 550 Spam refused. fetchmail: SMTP listener refused delivery fetchmail: SMTP> RSET fetchmail: SMTP< 250 Ok <---- this up to 70 seconds after the RSET fetchmail: flushed fetchmail: POP3> DELE 4 fetchmail: POP3< -ERR You can hang around all day if you like. I have better things to do. fetchmail: You can hang around all day if you like. I have better things to do. fetchmail: POP3> QUIT I've run a network trace on the SMTP traffic between fetchmail and courier and the delay definately seems to be on the "250 OK" being sent back by courier. I also wondered if courier was getting held up by some other online checking (dns etc) but another network trace shows no network activity from the courier server whatsoever during thsi time. Admittedly I'm running 0.43.2 which is a few months old , but the changelogs dont suggest this is a known (and fixed) issue and I don't want to change too many things at once. The whole configuration has worked fine for months so I'd be suprised if it's a config problem. I've noticed in the past that the fetchmail/ courier interactions seemed to 'pause' sometimes but it always 'working in the end' so I never looked at it in more detail... However, I';ve just changed ISP and I suspect their pop3 server's timeout is less tollerant of delays than the previous ISPs... Hence fetchmail now fails, I dont get mail and then wonder what's happning. At first I thought it was probably fetchmail not confirming to RFC etc but the more I look at the logs the more it looks like the courier process is the delaying factor. Has anyone seen this sort of problem before? Can anyone suggest anything I can try/look at to try to figure out what may be the cause..? Is there any additional logging in courier esmtpd that I can enable to see what it's doing ? Any help./suggestions gratefully received (If I can collect my email!!!) ------------------------------------------------------- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl _______________________________________________ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
