Re: [exim] Can't get Exim to DKIM-sign

Top Page
Delete this message
Reply to this message
Author: Mike Brudenell
Date:  
To: Exim Users
Subject: Re: [exim] Can't get Exim to DKIM-sign
I've been just been setting up DKIM signing and verification here and have
a couple of comments/questions about John's setup (I want to be sure I've
not misunderstood something/have something wrong! :-)

John writes…

On 31 January 2016 at 18:36, John McMurray <john@???> wrote:

> Its really hard to offer help without seeing the relevant parts of your
> config file, but this is what I have in mine:
>
> remote_smtp:
>   driver = smtp
>         #dkim_domain = gingergoat.co.za
>         dkim_domain = $sender_address_domain
>         dkim_selector = x
>         #dkim_private_key = /etc/exim/dkim.private.key
>         dkim_private_key = ${if
> exists{/etc/virtual/$sender_address_domain/dkim.private.key}{/etc/virtual/$sender_address_domain/dkim.private.key}{0}}
>         dkim_canon = relaxed

>


*Selecting the dkim_domain*

John's configuration is selecting the domain to DKIM-sign with based on the
domain of the MAIL FROM address in the SMTP envelope. When I was setting
ours up I wasn't sure whether the selection should be made based on the
envelope or the "From:" header present within the message itself.

In one sense you're at liberty to sign based on whatever criteria you like.
However as we intend to go on to publish a DMARC policy I wanted to make
sure my DKIM-signing matched with what DMARC was causing to be checked.
(Eg, If my DMARC policy is causing checks against the "From:" header but
I'm signing based on the envelope there's potential for conflict.)

According to the Introduction to the DMARC RFC
<https://tools.ietf.org/html/rfc7489#section-1> (emphasis in bold is mine)…

"Receivers compare the *RFC5322.From address* in the mail to the SPF and
DKIM results, if present, and the DMARC policy in DNS."

and

"The domain name extracted from a message's *RFC5322.From* field is the
primary identifier in the DMARC mechanism. This identifier is used in
conjunction with the results of the underlying authentication technologies
to evaluate results under DMARC."


This led me to instead select the value for dkim_domain based on the domain
of the address in the "From:" header, which tallies with instructions I've
found in other guides since…

dkim_domain = ${lc:${domain:$h_from:}}


This tallies with other guides I've found since. Do others agree this is
correct practice?

*DKIM signing in the remote_smtp transport*

I use the same configuration for our mail gateways that handle messages
originating onsite and the those handling mail originating from offsite
(ie, the outside world) destined for some legacy domains we still host
locally rather than at Google.

There's a couple of Gotchas here though…

1. I have to take care *not* to sign messages arriving from an off-site
source but with an "@york.ac.uk" address in the "From:" header before
mapping to the recipients "@york.ac.uk" mailbox and transmitting to
Google for delivery. Such messages aren't from our users and are typically
spam or phishing and I definitely don't want to DKIM-sign them!

2. We subscribe to a couple of services hosted externally that
(currently!) send out messages with "@york.ac.uk" addresses in the
envelope and/or "From:" header. The first violates our SPF record; the
second won't be DKIM-signed and will violate our DMARC policy once it's
introduced. I'm currently trying to identify all such services to make
other arrangements with the service providers.

For the latter, what do others do?

- Encourage the service provider to use envelope/From addresses matching
their own domain?
- Set up a relaying arrangement for the service provider to transmit
through your own servers?
- Give them a key pair so they can DKIM-sign their messages using your
certificate? (which seems a little dangerous to me!)

Any thoughts?

Cheers,
Mike B-)

--
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm