Unexpected mail delivery failure and "retry timeout exceeded" NDR

[wish]

Has anyone seen this behavior? A message is sent and recorded by exim as delivered, but the delivery does not occur and an NDR is generated.

Here are the particulars, followed by anonymized snippits from exim_mainlog and the NDR.

1. Message, with small attachment, is sent and immediately received by exim
2. Exim promptly logs successful receipt and delivery
3. Exim immediately generates NDR citing "retry timeout exceeded" as reason for failure.

Of note:
- The sent message was not delivered to the recipient's mail box.
- A subsequent message was sent by same sender and successfully delivered.
- Recipient's mail box is/was well under quota.


exim_mainlog shows receipt and delivery of message:

2007-02-02 14:42:23 1HD6An-0006ll-O4 <= user@recipient.domain.com H=mail.sender.domain.com [nnn.nnn.nnn.nnn] U=hidden-user P=esmtp S=47454 id=A05D2AA3A69AE34B82044FC77285636BC4BDE0@sender.domain.com

2007-02-02 14:42:40 1HD6An-0006ll-O4 => user <user@recipient.domain.com> R=virtual_sa_user T=virtual_sa_userdelivery

2007-02-02 14:42:40 1HD6An-0006ll-O4 Completed

NDR sent by exim showing failure:

From: Mail Delivery System [mailto:Mailer-Daemon@host.recipient.domain.com]
Sent: Friday, February 02, 2007 2:43 PM
To: Sender
Subject: Mail delivery failed: returning message to sender

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed:

user@recipient.domain.com
retry timeout exceeded

This is unexpected behavior, and I'm hoping someone has seen or can explain this.

[justhost]

Did you ever find a resolution to this posting? I am having a similar situation with a few domains.

Does anyone have a response for this message?

[wish]

I found exim_mainlog contained regular and repeated timeouts when contacting one of the RBL services we use: relays.ordb.org. I removed it from the RBL check list and implemented a simple time-out watch crontab job to watch for and count daily occurances of "transport filter timeout while writing to pipe" in exim_mainlog.

Since removing the problem service, the timeouts have not reappeared and mail flow has been normal.

This may not be your exact problem, but the fact that Exim has problems with timeouts may at least point you in the right direction.