Menu
Index

Contact
LinkedIn
GitHub
Atom Feed
Comments Atom Feed



Tweet

Similar Articles

03/08/2010 07:59
Domainkeys,DKIM and SPF with Postfix on Debian
17/03/2017 09:14
Implementing opendmarc with Postfix
22/11/2009 16:49
Postfix stats on Cacti (via SNMP)
13/02/2015 22:51
opendkim on Cacti via SNMP
22/04/2010 22:00
Basic Postfix config guide for Cacti, Spam Blocking, TLS etc.

Recent Articles

23/04/2017 14:21
Raspberry Pi SD Card Test
07/04/2017 10:54
DNS Firewall (blackhole malicious, like Pi-hole) with bind9
28/03/2017 13:07
Kubernetes to learn Part 4
23/03/2017 16:09
Kubernetes to learn Part 3
21/03/2017 15:18
Kubernetes to learn Part 2

Glen Pitt-Pladdy :: Blog

DKIM & Postfix revisited with opendkim

A few years back I wrote a popular Debian orientated post on getting DKIM & SPF working with Postfix in a multi-domain, multi-key setup. Since then things have moved on. Packages used are no longer in Wheezy, old style DK seems to be safely gone now (no need to sign to avoid legacy setups rejecting your mail) and I'm building a new virtualised mail server I can migrate around or easily recover in failure scenarios.

This is more or less the steps I'm following to get things working with the new opendkim (fork of dkim-filter) packages. There is no need to change the SPF aspects of the last post, so this is purely DKIM.

I'm assuming anyone who finds their way to this page knows what DKIM is and the benefits of it even if beyond the big players and a few small scale mail servers, nobody else seems to care that much even if DKIM and SPF massively reduce SPAM, Phishing and other mail related abuse.

Notes on chroot in Postfix

The use of chroot in Postfix (at least on Debian and derivatives which is what I am mostly using) seems to have a history of changing. At this point I'm basing this on the defaults of my fresh install of Wheezy where broadly queue management and final-destination (on the local machine) delivery are not chroot, and everything public facing and more likely to be attacked (eg. smtpd) is.

If your configuration differs then things like paths of milter sockets may need changing to match where your Postfix services can access them or will be looking for them.

What's changed?

Since opendkim is a fork of dkim-filter used previously, much of the basic things remain the same, although configuration directives have changed names, in some cases subtly changed function, and some file formats are changed.

I'm also taking the opportunity to make things a bit tidier and easier to manage in the long term.

opendkim Configuration

For the purposes of simplicity, I'm using a selector of mailservername, but if you have a more complex setup or other reasons to do otherwise then adapt the config as neccessary.

Aside from the obvious stuff (install opendkim and opendkim-tools), like before we need to generate some keys to use:

# mkdir -p /etc/mail/dkim/keys/domain1
# cd /etc/mail/dkim/keys/domain1
# opendkim-genkey -r -d domain1 -s mailservername
# chown opendkim. mailservername.private

Repeat this for each domain this server handles.

Then we need to create some extra configuration to handle things neatly with multiple domains. First up we need to configure what keys are used. I created /etc/opendkim-KeyTable.conf but this is an arbitrary name since we will tell opendkim what file to find this config:

domain1identifier  domain1:mailservername:/etc/mail/dkim/keys/domain1/mailservername.private
domain2identifier  domain2:mailservername:/etc/mail/dkim/keys/domain2/mailservername.private
domain3identifier  domain3:mailservername:/etc/mail/dkim/keys/domain3/mailservername.private

This maps an identifier label onto 3 parameters:

  • Domain
  • Selector (we use the mail server name for consistency)
  • Path to the key (could be the key itself)

Next we need to tell opendkim when to use which configuration. I created /etc/opendkim-SigningTable.conf which again is an arbitrary name we will configure later:

*@domain1     domain1identifier
*@domain2     domain2identifier
*@domain3     domain3identifier

Now we pull it all together by updating the /etc/opendkim.conf and adding the relevant config. The default shipped config is benign so we can simply add to the file:

Socket                  inet:8891@localhost
KeyTable                /etc/opendkim-KeyTable.conf
SigningTable            refile:/etc/opendkim-SigningTable.conf
InternalHosts           /etc/opendkim-InternalHosts.conf
SyslogSuccess           yes
On-InternalError        accept
On-BadSignature         tempfail
#LogWhy                 yes

Things to note here:

  • We specify opendkim to listen on a local TCP socket which make things easier with Postfix chroot and permissions
  • In order to use wildcards in the SigningTable it has to be a "refile:"
  • We add some extra logging
  • The tempfail avoids configuration problems rejecting mail so once you are confident that everything is working properly you have the option to comment the line and enforce DKIM fully
  • It's very useful for debugging to enable the LogWhy option

Finally restart opendkim to bring all the change into operation:

# service opendkim restart

Postfix Configuration

In /etc/postfix/main.cf add the config to use the milter socket:

smtpd_milters =
        inet:localhost:8891
non_smtpd_milters =
        inet:localhost:8891
milter_default_action = accept

Then restart Postfix and it should start signing mails.

DNS Configuration

At this point the rest of the world needs to know what to do with mail from the server and how to validate it. For this we need to add TXT records to each of the domains we configured for DKIM. The selector record is the one contained in the .txt file created with each key above:

mailservername._domainkey IN TXT "v=DKIM1; k=rsa; p=MIGf....

Additionally we need to set our policy. This is a bit of a messy area as the "new" standard is ADSP, but there are a bunch of systems still on legacy Domainkeys style approaches. To avoid problems I personally set the legacy record to non-production, but the ADSP record to full enforcement:

_domainkey IN TXT "t=y;o=~"
_adsp._domainkey IN TXT "dkim=all"

At that point you should have a fully working opendkim setup with Postfix.

 

Comments:




Are you human? (reduces spam)
Note: Identity details will be stored in a cookie. Posts may not appear immediately