Hello.
Returning to topic discussed a month ago...
On Wed, Jul 07, 2021 at 01:21:37AM +0300, Evgeniy Berdnikov wrote:
> On Tue, Jul 06, 2021 at 08:32:36PM +0100, Jeremy Harris via Exim-users wrote:
> > While there have been several changes in the DKIM code that probably
> > are not in the binary you are running:
>
> I run up-to-date version from Debian/bullseye (package exim4-daemon-heavy
> 4.94.2-5). Production environment, so the simplest way for me is to wait
> for Debian update and look for result.
Recently I install 4.95-RC2 on Debian/testing (32bit) and got segfaults
(they are reported in other thread). As for spurious DKIM failures,
they are present in this version too:
----------------------------------------------------------------------------
Authentication-Results: citrine.rdtex.ru (amavisd-new);
dkim=pass (1024-bit key) header.d=netology.ru header.b=JK5fS3uY;
dkim=pass (1024-bit key) header.d=mta.mindbox.ru header.b=aHlP1SF6
Received: from citrine.rdtex.ru ([127.0.0.1])
by localhost (citrine.rdtex.ru [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id fqfLoPQknlH6 for <xxxxxxxx.xxxxxxxxxx@???>;
Tue, 7 Sep 2021 15:02:37 +0300 (MSK)
[...]
X-Authentication-Results: citrine.rdtex.ru Exim-4.95-RC2;
iprev=pass (mta.mindbox.ru) smtp.remote-ip=185.99.9.136;
dkim=fail (body hash mismatch; body probably modified in transit)
header.d=netology.ru header.s=mindbox header.a=rsa-sha256;
dkim=fail (body hash mismatch; body probably modified in transit)
header.d=mta.mindbox.ru header.s=mindbox header.a=rsa-sha256
Received-SPF: pass (mta.mindbox.ru: 185.99.9.136 is authorized to use
'bounce.9ed50800000092d50000c0d2@???' in 'mfrom' identity
(mechanism 'a' matched)) receiver=citrine.rdtex.ru; identity=mailfrom;
envelope-from="bounce.9ed50800000092d50000c0d2@???";
client-ip=185.99.9.136
----------------------------------------------------------------------------
So, problem still exists.
There is some little progress in attempts to locate it: I found that
this sender (mta.mindbox.ru) have maximum probability to produce fault.
I've removed STARTTLS for its relays and made a traffic capture, it shows
that there is some bulk mailer there, and it 1. uses CHUNKING, 2. send
whole mail in single BDAT, 3. cut off connection without waiting for
status code, 4. mail body is sent without final CRLF. Raw mail body,
extracted from pcap data, passes DKIM test for both signatures.
Removal of TLS layer does not help to prevent DKIM failures. But not all
mails from this sender lead to fault, some mails pass DKIM verification.
--
Eugene Berdnikov
