A message comes in for a number of recipients. In the log I see
deliveries for a number of them.
Then for one recipient, there is a problem with their server's SSL
certificate. Thus, there are two lines about a SSL verify error:
After that, this process is stuck and further queue runs produce:
2022-02-04 07:19:55.339 [76383] 1nFsr5-000Jqr-Hn Spool file for
1nFsr5-000Jqr-Hn is locked (another process is handling this message)
2022-02-04 07:49:55.360 [76801] 1nFsr5-000Jqr-Hn Spool file for
1nFsr5-000Jqr-Hn is locked (another process is handling this message)
2022-02-04 08:19:55.385 [77238] 1nFsr5-000Jqr-Hn Spool file for
1nFsr5-000Jqr-Hn is locked (another process is handling this message)
2022-02-04 08:49:55.400 [77639] 1nFsr5-000Jqr-Hn Spool file for
1nFsr5-000Jqr-Hn is locked (another process is handling this message)
2022-02-04 09:19:55.485 [78053] 1nFsr5-000Jqr-Hn Spool file for
1nFsr5-000Jqr-Hn is locked (another process is handling this message)
No delivery attempts are made for the remaining recipients - after the
one where the SSL error occurred.
Killing the process and restarting exim works insofar as the remaining
recipients get delivered, but there is no delivery line for the
problematic recipient.
For all I can see it is being silently discarded.
Apart from setting my own certificates, the options I set that look like
they might be relevant here are:
hosts_try_dane = *
tls_try_verify_hosts = *
Exim version is 4.95 running on FreeBSD (I use the exim-postgresql
package from FreeBSD ports).
Has anyone seen something like this before?
How do I prevent messages to those recipients being lost?
From the documentation, I gather that tls_try_verify_hosts should only
be diagnostic (which is what I want) and should not interfere with the
delivery?
