Re: Seemingly eligible mails not getting DKIM signed

On Wed, 10 Jun 2026 08:11:06 +0100 Jeremy Harris via Exim-users wrote:

> 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.
> 
I will give that a spin tomorrow once I'm more capable of dealing with
curly brackets as this by itself results in badness:
---
failed to expand ACL string "${if > {${strlen:$h_References}} {1000}}": missing 2nd string in {} after ">"
---

For your amusement and edification, this same mail client is also the main
source of unset dkim_domain, the header From: is either not RFC compliant
or Exim has issues with the encoding.

Example:
---
Warning: DKIM is set to:  , extracted from -j%0%s%5%s\033(B <[email protected]>
---

The actual line was (sans address)
-> From: =?iso-2022-jp?B?GyRCLWolMCVzJTUlcxsoQg==?= 

And before you ask, I use this to parse the header From: (and it works for
basically everybody not using this client or some ancient custom mailer).
---
DKIM_DOMAIN = ${if def:h_from:{${lc:${domain:${address:$h_from:}}}}{$qualify_domain}}
---

This is likely the clients fault more than anything, but as mentioned
rspamd "correctly" determines that actual addresses in header and envelope
are indeed identical.

> 
> > 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.
> 

All 3 "remote smtp" type transports here have this and the ONLY thing that
can (and will) potentially fail is the dkim_domain.
---
  dkim_domain = DKIM_DOMAIN
  dkim_selector = DKIM_SELECTOR
  dkim_private_key = DKIM_PRIVATE_KEY
  dkim_canon = relaxed
  dkim_strict = 0
---

Thanks again for the feedback!

Christian

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


-- 
Christian Balzer        Network/Systems Engineer & Architect               
[email protected]   	Rakuten Mobile Inc.

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