Szerző: Cyborg Dátum: Címzett: exim-users Tárgy: [exim] problem with mails in queue while config changes routers
Version : 4.94.2
Release : 2.fc34
Architecture: x86_64
Hi,
I have found a curios problem in exim: mails, that are in the queue, do
not update route status on config changes.
We have these two routers, nothing fancy, besides the clever sql to find
out, if a local domain has in reality an external domain:
externalmx:
driver = dnslookup
domains = +local_domains
condition = .. sql for condition match on premise "domain has
external mx".. not important how that works
transport = transportselector .. also not important ( decides to use
gpg or not )
ignore_target_hosts = 0.0.0.0 : 127.0.0.0/8
no_more
dnslookup:
driver = dnslookup
domains = ! +local_domains
transport = transportselector .. also not important ( decides to use
gpg or not )
ignore_target_hosts = 0.0.0.0 : 127.0.0.0/8
IF the condition on "externalmx" matches, i.e. because of an wrongfully
made entry in the database, but the domain does not really have an
external mx,
the mail ends up in queue to try to deliver it later.
2021-12-27 11:47:06 1n1nWy-006Ps5-Uo <= SENDER H=ip-XXXXXXXXXXXXXXX (X)
[X] P=esmtpsa X=TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256 CV=no A=LOGIN:X
S=385112 id=X
2021-12-27 11:47:06 1n1nWy-006Ps5-Uo lowest numbered MX record points to
local host: receiver.domain
2021-12-27 11:47:06 1n1nWy-006Ps5-Uo == to@??? R=externalmx
defer (-1): lowest numbered MX record points to local host
2021-12-27 11:47:06 1n1nWy-006Ps5-Uo Frozen
That's fine so far.
Now, lets say at 15:00, the db entry is removed, because someone found
out, that this is a wrongfully made entry or it simply got outdated by
reality(DNS-TTL).
The next retry on the stored message does not recognize the necessarity
to switch to the now matching router.
2021-12-27 11:52:58 1n1nWy-006Ps5-Uo Message is frozen
2021-12-27 12:52:58 1n1nWy-006Ps5-Uo Message is frozen
2021-12-27 13:52:58 1n1nWy-006Ps5-Uo Message is frozen
2021-12-27 14:52:58 1n1nWy-006Ps5-Uo Message is frozen
2021-12-27 15:52:58 1n1nWy-006Ps5-Uo Message is frozen
2021-12-27 16:52:58 1n1nWy-006Ps5-Uo Message is frozen
2021-12-27 17:52:58 1n1nWy-006Ps5-Uo Message is frozen
2021-12-27 18:52:58 1n1nWy-006Ps5-Uo Message is frozen
2021-12-27 19:52:58 1n1nWy-006Ps5-Uo Message is frozen
2021-12-27 20:52:58 1n1nWy-006Ps5-Uo Message is frozen
2021-12-27 21:52:58 1n1nWy-006Ps5-Uo Message is frozen
2021-12-27 22:52:58 1n1nWy-006Ps5-Uo Message is frozen
2021-12-27 23:52:58 1n1nWy-006Ps5-Uo Message is frozen
2021-12-28 00:52:58 1n1nWy-006Ps5-Uo Message is frozen
2021-12-28 01:52:58 1n1nWy-006Ps5-Uo Message is frozen
2021-12-28 02:52:58 1n1nWy-006Ps5-Uo Message is frozen
2021-12-28 03:53:02 1n1nWy-006Ps5-Uo Message is frozen
2021-12-28 04:52:58 1n1nWy-006Ps5-Uo Message is frozen
2021-12-28 05:52:58 1n1nWy-006Ps5-Uo Message is frozen
2021-12-28 06:52:58 1n1nWy-006Ps5-Uo Message is frozen
2021-12-28 07:52:58 1n1nWy-006Ps5-Uo Message is frozen
2021-12-28 08:52:58 1n1nWy-006Ps5-Uo Message is frozen
2021-12-28 09:52:58 1n1nWy-006Ps5-Uo Message is frozen
2021-12-28 10:52:58 1n1nWy-006Ps5-Uo Message is frozen
2021-12-28 11:52:58 1n1nWy-006Ps5-Uo cancelled by timeout_frozen_after
2021-12-28 11:52:58 1n2A6E-00BYBW-OW <= <> R=1n1nWy-006Ps5-Uo U=exim
P=local S=2395
And here it failed permanently. It was stuck on "externalmx".
The same mail, send after 15:00 got handles correctly.
No idea how exim interally handles this, but exim does not seem to be
flexibel enough to react on dynamic changes in the environment.This is
bad luck, because freezing the mail in the queue is exactly there to
wait for things to change ;) (i.e. an external mx become online again )
Can this already be avoided with implemented functions/settings, or is
this something you need to implement in the coming exim 5?