Dear all,
We upgraded our mail gateways from Ubuntu 16.04 LTS ro 18.04 LTS, and thus
their Exim from 4.86.2 to 4.90.1. Since then I'm seeing two problems,
possibly related…
On receiving email from the outside world I now use cutthrough delivery to
certain onsite systems. Exim was also defaulting to the recently introduced
chunking (which I've now turned off to see if that helps).
Does anyone know anything about either of the following problems that I'm
seeing?
===============================================
*1) "failed to unlink" errors in paniclog*
I'm seeing a handful of errors going into paniclog each day of the form:
2018-09-25 16:19:03.201 [10343] 1g4p73-0002gf-1a failed to unlink
/var/spool/exim4//msglog/3/1g4p73-0002gf-1a: No such file or directory
Using exigrep to search the logs for each Exim id (eg, 1g4p73-0002gf-1a) I
find that cutthrough seems to be involved each time, with log entries like
this:
2018-09-25 15:57:00.362 [7341] 1g4olV-0001uP-GZ >> REDACTED@REDACTED.
york.ac.uk F=<gear.groupons@???> R=transmit_to_routed_server
T=remote_smtp S=34088 H=REDACTED.york.ac.uk [144.32.NNN.NNN]:25 PRX=[]:0
I=[144.32.129.29]:56292 X=TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256 CV=no
C="250 OK id=1g4olV-000Dm7-GW" QT=18s DT=0.000s
2018-09-25 15:57:00.364 [7341] 1g4olV-0001uP-GZ <=
gear.groupons@??? H=fantastic.nodetaisthanks.com
[67.214.168.46]:34387 I=[144.32.128.183]:25 P=esmtp S=33525 M8S=8 id=
uXvKvp-VkbSHl-KR6oLE8s-ayBVWLE2kv@???
T="=?UTF-8?B?TGltaXRlZCB0aW1lIG9uIGZyZWUgbWlsaXRhcnkgZ3JhZGUgdGFjIGZsYXNobGlnaHRz?="
from <gear.groupons@???> for REDACTED@???
2018-09-25 15:57:00.364 [7341] 1g4olV-0001uP-GZ Completed
+++ 1g4olV-0001uP-GZ has not completed +++
2018-09-25 15:57:06.583 [7383] 1g4olV-0001uP-GZ =>
REDACTED@??? F=<gear.groupons@???> P=<
gear.groupons@???> R=transmit_to_routed_server T=remote_smtp
S=34079 H=REDACTED.york.ac.uk [144.32.NNN.NNN]:25 PRX=[]:0
I=[144.32.129.29]:56304 X=TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256 CV=yes K
C="250- 33335 byte chunk, total 34079\\n250 OK id=1g4oln-000DmW-NR" QT=25s
DT=6s
2018-09-25 15:57:06.583 [7383] 1g4olV-0001uP-GZ failed to unlink
/var/spool/exim4//msglog/V/1g4olV-0001uP-GZ: No such file or directory
I saw this same problem with a previous release of Exim and disabled
cutthrough as it had issues in that release. However I thought this problem
had been addressed since then.
It doesn't seem to have been improved by my turning off chunking (see
below) so I'm guessing it's still related to cutthrough in some way. But
surely I'm not the only one to be seeing this issue?
===============================================
*2) Remote MTA doesn't get SMTP acknowledgements back*
I also have a report from someone that their remote mail server is
transmitting a message to Exim on our gateways but not getting the final
SMTP acknowledgement back indicating message acceptance.
According to my logs here we accepted the message into our queues (not
using cutthrough) and relayed it onwards. However the report says that the
remote mail server (also running Exim I believe) reports:
2018-09-23 15:23:17 1g44HA-000OKU-QT H=mta.york.ac.uk [144.32.128.183]:
SMTP timeout after pipelined end of data (2052 bytes written): Operation
timed out
2018-09-23 15:23:17 1g44HA-000OKU-QT == REDACTED@???
R=dnslookup T=remote_smtp defer (60): Operation timed out H=mta.york.ac.uk
[144.32.128.183]: SMTP timeout after pipelined end of data (2052 bytes
written)
The only difference I can think of is that Exim 4.90.1 now uses chunking,
and the logs show this was used for the message. I can see other examples
in the logs of a small number of messages from other senders/systems also
suffering the same fate: being sent to us several times because of retries.
I've turned off chucking temporarily to see if that improves/changes
things, and have asked our user who reported the issue to test again.
===============================================
With many thanks,
Mike B-)
--
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811
Web:
www.york.ac.uk/it-services
Disclaimer:
www.york.ac.uk/docs/disclaimer/email.htm
