Philip Prindeville wrote:
I'm trying to deliver email to some sites that seem to have obnoxiously long greet pause configured (yes, it's a Chinese site, and yes, it's their contact address for reporting abuse... guess they aren't about to make it easy to do): # date ; sendmail -q -v ; date Tue Feb 20 12:41:19 MST 2007 Running /var/spool/mqueue/l1J1BZTd015129 (sequence 1 of 4) <anti-spam@xxxxxxxxxxxxxxxxxx>... Connecting to ns.chinanet.cn.net. via esmtp...<anti-spam@xxxxxxxxxxxxxxxxxx>... Deferred: Connection timed out with ns.chinanet.cn.net. Running /var/spool/mqueue/l1HKVCiu004463 (sequence 2 of 4) <anti-spam@xxxxxxxxxxxxxxxxxx>... Deferred: Connection timed out with ns.chinanet.cn.net. Running /var/spool/mqueue/l1HKWqcD004481 (sequence 3 of 4) <anti-spam@xxxxxxxxxxxxxxxxxx>... Deferred: Connection timed out with ns.chinanet.cn.net. Running /var/spool/mqueue/l1GKJkvD011374 (sequence 4 of 4) <anti-spam@xxxxxxxxxxxxxxxxxx>... Deferred: Connection timed out with ns.chinanet.cn.net. Tue Feb 20 12:44:29 MST 2007 # I've tried bumping the connect timeout: define(`confTO_CONNECT', `5m')dnl (which results in "O Timeout.connect=5m")... as well as running sendmail as: sendmail -q -v -O Timeout.connect=5m -O Timeout.initial=5m but this doesn't seem to make any difference. It looks like the kernel's internal maximum timeout on a connect() is forcing a shorter interval. Anyone know what the workaround for this is? Do I need to force the kernel's TCP connect() timeout to something larger?
Before you try fixing anything please try.... telnet ns.chinanet.cn.net 25 It never answers the call. At least not from Taiwan. -- "May your future be limited only by your dreams." -- Christa McAuliffe
