On 2/3/16, Heiko Schlittermann <hs@???> wrote:
> Yes, as Jeremy wrote, it's in the ACL, there probably is some
>
> verify = recipient
>
> This is done during SMTP time, that is, during the time your MUA is
> talking to the server.
>
> As DNS normally shouldn't take 5…15 secs per query, I'd assume that
> either your DNS is broken (Exim uses the hosts resolver libraries, you
> should be able to do debugging using dig & co.)
>
> Or you're doing callouts, these may take a while, depending on how fast
> the recipient host is. (verify = recipient/callout)
Thanks for the response. I've checked dig on the servers and they are
all pretty quick >0.5 sec so that is not the problem. Hence it looks
like callouts is the cause as I have an ACL that checks for failed
recipients.
condition = ${if > {${eval:$rcpt_fail_count}}{3}{yes}{no}}
!verify = recipient/callout=2m,defer_ok,use_sender
The odd thing is, I have this ACL on other servers without problems,
as in Exim does not appear to hang onto the connection until every
single recipient is checked. I've adjusted the callout time to 1m and
wanted to set a maxwait=5m but I am unsure what will happen if the
maxwait limit is hit.
On the other hand, the users are saying things seems to be OK today.
The only difference is that I fixed the other problem I was having
while typing the original email, which I accidentally left in the
subject about spool file not found.
Would a corrupted callout db cause the delay in sending? This is
because I was getting a lot of errors in the log about spool file
xxxxx not found. Which went away after I rm the spool folder and
exim_tidydb the various db. This was the only change I could think of
that might had improved the situation.
