Re: [exim] Exim-users Digest, Vol 165, Issue 9 [verificatio…

On 2018-02-12 at 14:04 +0000, Jeremy Harris via Exim-users wrote:
> On 12/02/18 12:12, Martin Nicholas via Exim-users wrote:
> > I notice this from "Exim-users Digest, Vol 165, Issue 9":
> >
> > DKIM: d=exim.org s=d201802 c=relaxed/relaxed a=rsa-sha256 b=1248
> > [verification failed - body hash mismatch (body probably modified in
> > transit)]
>
> What date was that?

Today.

So Exim 4.90.1 as sender.
Nothing hinky in the exim.org hub's Exim logs; message id
1elCmD-0003Wp-1g was queued by ACL (because it's from Mailman); 3mins12s
later a connection was made the Martin's MX host. We log a certificate
verification failure because it's a self-signed cert and no DANE, but
continue on (as per normal for opportunistic TLS on SMTP/MX). 10
seconds later, we log successful delivery. (There are some SMTP banner
delays from the remote server, I think).

QT=3m22s DT=25s -- that's a little painful.
exigrep -I 'Exim-users Digest, Vol 165, Issue 10' /var/log/exim/main.log | pcregrep -o 'DT=\K\d+' | sort | uniq -c | sort -n

Result: (of 201 digest recipients total) 79 messages spent less than 1
second on the queue, 8 recipients took longer to deliver than 25seconds.
I'm assuming if it's not a slow network connection then it's heavy
processing before the message is accepted.

There's nothing else in the Exim mainlog; the sizes of each digest
message sent differ, which I expect for stuff with the recipient in the
body.

Hrm, the `b=` field is a little long for logging, with RSA keys, but
perhaps the `bh=` value could be included in the outbound logging? In
theory that would at least let us look at a received mail and detect
tampering after the message left our system; but really, if a broken
corporate mail-filtering device tampered with the body, it almost
certainly has not adjusted the claimed DKIM-Signature: header too, so it
should be possible to take the digest and reconstruct.

Part of the qualification for a new Exim install on the Exim mail-hub
involves sending a short mail through to Gmail and looking at the
headers to confirm that an independent implementation is verifying
messages fine. Won't help if it's a bug tickled by some large messages.

I've subscribed another address to the mailing-list, in digest mode, to
see what happens next time.

-Phil