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 -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/