0

On my server, mail is sometimes delayed for apparently no specific reason.

In this example two mails were generated by systemd-cron about failing cron jobs:

mailq output (domains edited):

 3m  1.9K 1i6W6d-0003UT-Ut <server@example.com>
          www-data@server

 3m  1.8K 1i6W6e-0003Uh-1y <server@example.com>
          root@server

After some minutes or when I issue exim -qf the mail is finally sent and delivered without any issue.

/var/log/exim4/mainlog (Domains/IPs edited):

2019-09-07 10:30:04 1i6W6d-0003UT-Ut <= server@example.com U=nobody P=local S=1914
2019-09-07 10:30:04 1i6W6e-0003Uh-1y <= server@example.com U=nobody P=local S=1875
2019-09-07 10:34:13 Start queue run: pid=13447 -qf
2019-09-07 10:34:14 1i6W6d-0003UT-Ut => me@example.com <www-data@server> R=smarthost T=remote_smtp_smarthost H=smtp.example.com [1.2.3.4] X=TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256 CV=yes DN="…" A=plain C="250 2.0.0 Ok: queued as 268D26139FAA"
2019-09-07 10:34:14 1i6W6d-0003UT-Ut Completed
2019-09-07 10:34:14 1i6W6e-0003Uh-1y => me@example.com <root@server> R=smarthost T=remote_smtp_smarthost H=smtp.example.com [1.2.3.4] X=TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256 CV=yes DN="…" A=plain C="250 2.0.0 Ok: queued as BA7EE6139FAC"
2019-09-07 10:34:14 1i6W6e-0003Uh-1y Completed
2019-09-07 10:34:14 End queue run: pid=13447 -qf

When I sent an email from command line echo 'Test' | mail -s test root, the mail is delivered immediately, without log entries for start/end queue run:

2019-09-07 10:35:21 1i6WBk-0003V9-VR <= server@example.com U=root P=local S=397
2019-09-07 10:35:21 1i6WBk-0003V9-VR => me@example.com <root@server> R=smarthost T=remote_smtp_smarthost H=smtp.example.com [1.2.3.4] X=TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256 CV=yes DN="…" A=plain C="250 2.0.0 Ok: queued as 723116139F77"
2019-09-07 10:35:21 1i6WBk-0003V9-VR Completed

Do you know the reason for the delay? How can I have exim process all mail immediately?

My configuration:

  • up to date Debian Buster
  • exim version 4.92-8+deb10u2
  • both, root and www-data (among others) have aliases to me@example.com (external)
  • standard Debian exim config (using update-exim4.conf)

/etc/exim4/update-exim4.conf.conf:

dc_eximconfig_configtype='smarthost'
dc_other_hostnames=''
dc_local_interfaces='127.0.0.1 ; ::1'
dc_readhost='server'
dc_relay_domains=''
dc_minimaldns='false'
dc_relay_nets=''
dc_smarthost='smtp.example.com::587'
CFILEMODE='644'
dc_use_split_config='true'
dc_hide_mailname='false'
dc_mailname_in_oh='true'
dc_localdelivery='maildir_home'
  • Is exim actually running? – Michael Hampton Sep 7 '19 at 9:37
  • Yes, it is, which I can confirm with systemctl. – steiny Sep 7 '19 at 11:48
0

Mail can stuck in exim's queue because of some error, DNS resolution fail for example. And if you are using Gmail, this may be caused by Google's IPv6 reverse DNS (PTR record) policies, as tkteun mentioned in his answer here. So, solution is to disable IPv6 lookups for Google's SMTP server.

If you are using 'split' exim configuration, just do as root:

echo "dns_ipv4_lookup = *google.com : *gmail.com" > /etc/exim4/conf.d/main/90_exim4-gmail_disable_ipv6
update-exim4.conf
systemctl restart exim4
| improve this answer | |
  • This answer does not address the symptoms described in the question. – womble Oct 24 '19 at 8:57
0

Apparently, this situation is caused by the combination of exim and systemd as described on the systemd-devel mailing list.

TL;DR: To send a mail from the command line exim forks a process to deliver the mail immediately. However, as the parent process exists, the systemd unit for this cron job terminates, and systemd kills all remaining processes in the control group, including the previously forked process responsible for mail delivery.

To prevent this I found two solutions (apart from fixing exim itself):

  • Using an SMTP client to send mail via TCP to the local exim daemon, such as swaks(1).
  • Delaying the end of the systemd unit, e.g., by calling exim -qf (queue flush) after calling mail.

Both solutions are not optimal. The first requires extra software and opens a local tcp connection while the second requires root privileges. For now, I will stick with swaks.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.