Re: [exim] ARC signing and verification

On 24/04/2020 19:52, Tom Crane via Exim-users wrote:
> 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 above best viewed with a UTF-8 - capable terminal]

OK. There would have been a big wadge of DKIM messages earlier on,
when the verification was actually being done - but you see the
results here.


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

How nice of them. Perhaps, some time in the future they'll be nice
enough to do ARC themselves...

> Two question arise;
>
> (1) Is the DKIM verification failure going to cause ARC to refuse to ARC
> -sign the message?

It won't stop you signing it, but all you'll be able to do is sign
the fact that DKIM was not-verifiable at the point you got your
hands on 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.

So the modifications made by that inerloper are predictable? OK.

You could have done the same edit using native Exim factilities,
and not needing the system-filter, but no matter.

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

It is, and no there is not. It would be an interesting RFE to raise,
a way of re-verifying DKIM after applying some such edits, though.
I see no technical obstacles.

Or you could get O365 to stop messing with your messages.

--
Cheers,
Jeremy