Re: [exim] ARC signing and verification

Top Page
Delete this message
Reply to this message
Author: Tom Crane
Date:  
To: Jeremy Harris via Exim-users
CC: Tom Crane
Subject: Re: [exim] ARC signing and verification
On Fri, 24 Apr 2020, Jeremy Harris via Exim-users wrote:

> On 24/04/2020 03:19, Tom Crane via Exim-users wrote:
>> I wondered about this but DKIM verification is already turned on, and is
>> on by default (eg. section 58.1 of the Exim Book).  My college's Central
>> IT email service (O365), which I mainly use for testing my exim server
>> does not DKIM sign messages
>
> Use a test source which does DKIM-sign. Run your receiving daemon with
> debug enabled, and look at the full processing sequence.


Done but I am not much the wiser. I get (slightly obfuscated) eg.,

16:56:30 16565 using ACL "acl_check_data"
16:56:30 16565 processing "warn"
16:56:30 16565 check verify = arc/pass:none:fail
16:56:30 16565 ARC: collecting arc sets
16:56:30 16565 ARC verify result none NULL
16:56:30 16565 warn: condition test succeeded in ACL "acl_check_data"
16:56:30 16565  <E2><94><8C>considering: :at_start:${authresults {$primary_hostname}}
16:56:30 16565   <E2><94><8C>considering: $primary_hostname}}
16:56:30 16565   <E2><94><9C><E2><94><80><E2><94><80>expanding: $primary_hostname
16:56:30 16565   <E2><94><94><E2><94><80><E2><94><80><E2><94><80><E2><94><80><E2><94><80>result: <my exim server>
16:56:30 16565 DKIM: authres 'dkim=fail (signature did not verify; headers probably modified in transit)
16:56:30 16565           header.d=gmail.com header.s=20161025 header.a=rsa-sha256'
16:56:30 16565 ARC:  authres 'arc=none'
16:56:30 16565  <E2><94><9C><E2><94><80><E2><94><80>expanding: :at_start:${authresults {$primary_hostname}}
16:56:30 16565  <E2><94><94><E2><94><80><E2><94><80><E2><94><80><E2><94><80><E2><94><80>result: :at_start:Authentication-Results: <my exim server>;
16:56:30 16565          iprev=pass (steelapp01.rhul.ac.uk) smtp.remote-ip=134.219.220.21;
16:56:30 16565          dkim=fail (signature did not verify; headers probably modified in transit)
16:56:30 16565                   header.d=gmail.com header.s=20161025 header.a=rsa-sha256;
16:56:30 16565          arc=none
16:56:30 16565 check add_header = :at_start:${authresults {$primary_hostname}}
16:56:30 16565                  = :at_start:Authentication-Results: <my exim server>;
16:56:30 16565  iprev=pass (steelapp01.rhul.ac.uk) smtp.remote-ip=134.219.220.21;
16:56:30 16565  dkim=fail (signature did not verify; headers probably modified in transit)
16:56:30 16565           header.d=gmail.com header.s=20161025 header.a=rsa-sha256;
16:56:30 16565  arc=none
16:56:30 16565 accept: condition test succeeded in ACL "acl_check_data"
16:56:30 16565 end of ACL "acl_check_data": ACCEPT
16:56:30 16565 >>Headers added by DATA ACL:
16:56:30 16565   (at top)Authentication-Results: <my exim server>;
16:56:30 16565  iprev=pass (steelapp01.rhul.ac.uk) smtp.remote-ip=134.219.220.21;
16:56:30 16565  dkim=fail (signature did not verify; headers probably modified in transit)
16:56:30 16565           header.d=gmail.com header.s=20161025 header.a=rsa-sha256;
16:56:30 16565  arc=none



The DKIM verification failure is due to meddling by an upstream MTA (a
Microsoft O365 protection service) which filters email to my exim
server via its domain's DNS mx record, and prepends "[EXT] " onto Subject:
header lines.

Two question arise;

(1) Is the DKIM verification failure going to cause ARC to refuse to ARC
-sign the message?

(2) A wrote System Filter script to strip out the "[EXT] ". It works in
that if I extract the delivered message from my mailbox the "[EXT] " is
duly gone from the Subject: field and the dkimverify.pl tool successfully
verifies the message. Exim however, still gets a DKIM verify failure. I
call the system filter with a "system_filter =" statement in
main/global/top section of the exim.conf file. My question is; Is Exim's
DKIM verification check for the Authentication-Results: header carried out
before the System Filter runs and if so, if there anything I can do to
make it run before?


Thanks
Tom