delayed local delivery

gate2vn

Verified User
Joined
Nov 9, 2004
Messages
483
Location
Oslo
So, I am sending an email to another email address with the same domain (local delivery), and an email with external domain. The email to external domain arrived immediately. But the local address is delayed 30 - 60 minutes.

No error in exim log. Exim, exim.conf, Dovecot are the latest version. Server load is 0. No queued email. In fact, this is a testing server, so there is no other domain except one testing domain.

Any idea?

Thanks.
 
Last edited:
I'm experiencing the same issue, can you tell which version of Exim and eximconf you are using?
I recently updated to Exim 4.91 and exim.conf 4.5.10

When I check the mail queue I can just click the retry button and the local delivery is done.
 
Hello,

Kindly provide details from your exim logs, which would show the delayed mail delivery. You can use exigrep to collect all related information and discard unwanted.
 
This is one of the cases when I was at the client itself and he said to me that he just received an email which was sent by a colleague 1 hour ago, which I only could confirm when checking the logs.
I did a grep on the internal message id, hope that is enough:
Code:
[root@server1]# exigrep "1g7iK4-0007QI-US" /var/log/exim/mainlog
2018-10-03 16:40:21 cwd=/var/spool/exim 14 args: /usr/sbin/exim -MCD -MCP -MCS -MCt 136.144.141.99 57307 TLSv1.2:ECDHE-RSA-AES256-SHA384:256 -MC remote_smtp domain-nl0i.mail.protection.outlook.com 213.199.180.138 1 1g7iK4-0007QI-US

2018-10-03 16:40:21 1g7iK4-0007QI-US <= [email protected] H=d51a33b45.access.telenet.be ([192.168.0.244]) [81.165.1.1] P=esmtpa A=login:[email protected] S=309488 [email protected] T="Re: Vracht Someren - Keelung" from <[email protected]> for [email protected] [email protected]
2018-10-03 16:40:23 1g7iK4-0007QI-US => [email protected] F=<[email protected]> R=lookuphost T=remote_smtp S=315413 H=domain-nl0i.mail.protection.outlook.com [213.199.180.138] X=TLSv1.2:ECDHE-RSA-AES256-SHA384:256 CV=no C="250 2.6.0 <[email protected]> [InternalId=12558484381298, Hostname=DB7P191MB0474.EURP191.PROD.OUTLOOK.COM] 323717 bytes in 0.319, 988.523 KB/sec Queued mail for delivery"
2018-10-03 17:36:25 1g7iK4-0007QI-US => otheruser <[email protected]> F=<[email protected]> R=virtual_user T=dovecot_lmtp_udp S=314657 C="250 2.0.0 <[email protected]> eMpGA/nhtFsAagAAYDDtvw Saved"
2018-10-03 17:36:25 1g7iK4-0007QI-US Completed
Info: I replaced the sender email + the local user, the receiver email and own server ip
 
Check

- /var/log/maillog
- /var/log/dovecot-lmtp-errors.log
- /var/log/dovecot-lmtp

for possible clues on what might went wrong.

You might need to check rotated versions to find records related to your incident happened on `2018-10-03 16:40`
 
There is nothing in the dovecot logs related to this email at that time.
Also in the mainlog at that time there is nothing to find back.

Since I updated exim recently I rolled back to Exim 4.90_1 with exim.conf 4.5.9 yesterday
But apparently some of the messages are again queued:
img.png
I have to say that it's a client who is sending frequently emails.

Don't know (yet) which possiblities there are to debug exim more.

Thanks for the help so far.
 
Check logs and details on why emails are queued in Directadmin GUI. Probably they will provide some clues.
 
Same thing is happening on one of our servers. Latest dovecot/exim versions are installed.

Anyone knows how to fix this and/or why this is happening?
 
Same thing is happening on one of our servers. Latest dovecot/exim versions are installed.

Anyone knows how to fix this and/or why this is happening?

In my case, the reason was BlockCracking plugin. Disabled it, and the mail is working back normally. Tested in multiple servers.
Do you have BlockCracking with your Exim?
 
Yes, blockcracking is enabled.

I'll test the suggestion. Thanks for your anwsers guys :)
 
I started to experience the same issue some days ago. The problem went away just by restarting Exim but it came back again and again. Pretty stressful and real pain.
I think I finally got it solved following this guide: https://help.directadmin.com/item.php?id=2080
Essentially, you only need to add the following variable to the file /etc/exim.blockcracking/variables.conf.custom:
BC_VERIFY_CALLOUT ==callout=10s,maxwait=40s,connect=5s,defer_ok,use_sender

(Note you need to use de "==" which is correct.)

The problem seems to be gone now and fortunately didn't have to disable Blockcraking, which has proven very useful.
I hope it helps.

Best regards,

Isaias
 
I started to experience the same issue some days ago. The problem went away just by restarting Exim but it came back again and again. Pretty stressful and real pain.
I think I finally got it solved following this guide: https://help.directadmin.com/item.php?id=2080
Essentially, you only need to add the following variable to the file /etc/exim.blockcracking/variables.conf.custom:
BC_VERIFY_CALLOUT ==callout=10s,maxwait=40s,connect=5s,defer_ok,use_sender

(Note you need to use de "==" which is correct.)

The problem seems to be gone now and fortunately didn't have to disable Blockcraking, which has proven very useful.
I hope it helps.

Best regards,

Isaias

Yeah I can confirm the same solution, already answered this in my previous post here.
 
Back
Top