Hello,
I have a (only recently deployed) exim instance handling mail for around
a dozen users in a small office. It appears that large messages
sometimes (but not always) get stuck on our mail queue. Some 7MB
outgoing messages have been delivered, but a handful of messages around
1.2MB in size have been sat on the queue for a couple of days now and
aren't looking like going.
Picking one message in particular, I have the following queue entry and
log lines:
27h 1.2M 1JtiP2-0007Re-4R <sam@???>
Admin@???
blackmorecomms@???
2008-05-08 14:17:36 1JtiP2-0007Re-4R == x@??? R=dnslookup
T=remote_smtp defer (-53): retry time not reached for any host
2008-05-08 14:49:58 1JtiP2-0007Re-4R == x@??? R=dnslookup
T=remote_smtp defer (110): Connection timed out: SMTP timeout while
connected to ibmr.btconnect.com [213.123.26.151] after sending data
block (589662 bytes written)
Other delivery attempts record a little more data written, but generally
between 570kB and 620kB.
Attempting a forced delivery with -M, with -d+all set on the command
line, gives little more insight. A very normal looking start to the SMTP
conversation, then after DATA, I get dozens of the following lines:
16:28:21 8755 writing data block fd=7 size=8190 timeout=300
16:28:22 8755 writing data block fd=7 size=8190 timeout=300
Around half a dozen (this varies wildly, though) of these lines appear
per second, judging by the timestamps, then they stop altogether and
nothing is logged for a minute. Then...
16:28:22 8755 writing data block fd=7 size=8190 timeout=300
16:29:14 8753 selecting on subprocess pipes
16:30:14 8753 selecting on subprocess pipes
Eventually after several minutes this simply times out, explaining the
"SMTP timeout" message recorded in the logs. What I don't understand is,
why my Exim has stopped sending data part way through a message -- is
this likely to be an issue at the receiving end, or a networking issue
between the two hosts, or is it a simple misconfiguration at my end?
I've found a few threads on exim-users relating to this, but none
provided a solution applicable in my case, that I could see -- any help
would be most gratefully received! I can make a packet capture from
tcpdump available if people think that might help.
All the best,
James
