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