Re: Seemingly eligible mails not getting DKIM signed
Jeremy Harris via Exim-users <[email protected]> Wed, 10 Jun 2026 08:11:06 +0100
| Newsgroups | gmane.mail.exim.user |
|---|---|
| Message-ID | <[email protected]> |
On 2026/06/10 7:37 AM, Christian Balzer via Exim-users wrote: > All of them had long (1000+ characters) and broken (split in the > middle of an id) References: like this: > --- > <unbroken> <delugeofids> <[email protected] > om> > --- > > Which is a known issue with this (EOL) mail client. That does feel like it (the total length, not the line-wrap) might be an item triggering a bug in Exim. Even though that's an out-of-spec header, it'd be good to do something more visible with it, if so... You could check it in the data ACL, with condition = ${if > {${strlen:$h_References}} {1000}} and trigger debug at that point. > acl_check_data: > > # What is it that we are supposed to sign? > warn log_message = DKIM is set to: DKIM_DOMAIN Note that this is only displaying some values (as given, macros - but perhaps you are ofuscating) in the receive processing. It does not says that we went on to transmit outbound using the transport you expect, nor what the options on that transport were. > I wonder which fallout would NOT signing References: at all > would cause A workaround only, but worth trying. We could at least make it specific to either the sender(s) or that header length (if that does turn out to be the trigger), using a suitable expansion for the dkim_sign_headers option. -- Cheers, Jeremy -- ## subscription configuration (requires account): ## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/ ## unsubscribe (doesn't require an account): ## [email protected] ## Exim details at https://www.exim.org/ ## Please use the Wiki with this list - https://code.exim.org/exim/wiki/wiki