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?


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

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.


## 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/

Reply via email to