Installing OpenDKIM RPM via Yum with Postfix or Sendmail (for RHEL / CentOS / Fedora) _1

For those who want or need to compile and install OpenDKIM from the source code, you can follow the instructions I wrote in this article.

If you’re looking for the fastest and easiest way to get OpenDKIM running on a RedHat system, I currently maintain the OpenDKIM package in the Fedora and EPEL repositories. This article will help you install the RPMs and then configure OpenDKIM with Postfix or Sendmail.

For general information about DKIM, check out http://www.dkim.org/. For more information about the OpenDKIM project, check out http://www.opendkim.org/.

Before you start

This tutorial assumes the following:

  • You are running a “modern” RedHat-compatible Linux distro (RHEL 5/6, CentOS 5/6, Fedora, etc).
  • You are running a milter-aware MTA, such as Postfix 2.3.3 or newer (do postconf -d mail_version to check) or Sendmail.
  • Your Postfix or Sendmail configuration is currently working (this is very important – you don’t want to troubleshoot two programs at once).
  • If you’re using Postfix, Sendmail is turned off (do service sendmail status to verify).
  • If you’re using Sendmail, Postfix is turned off (do service postfix status to verify).
  • The necessary commands in this tutorial are done as root. If you don’t know what that means, then you probably shouldn’t be doing this. You may be able to get away with just using sudo, but I wanted to make sure I didn’t run into any path issues, so I do it as root.

Install OpenDKIM with Yum

If you’re running Fedora 14 (or newer) or RHEL/CentOS 5 (or newer) then you can use Yum to quickly install OpenDKIM (RHEL/CentOS users must have the EPEL repositories enabled). Just do:

yum install opendkim

This will download and install OpenDKIM with all the default configuration options included below.

For those who like getting their hands dirtier, you can manually download one of my RPMs or even build your own RPM from my Source RPM, which are all available through the Fedora BuildSystem.

Generate keys for signing

Now you’re getting to the fun part. You need to generate a private and a public key for each of the domains for which you wish to sign mail. The private key is stored away from prying eyes on your server, while the public key gets published in your domain’s DNS records so that receiving mail servers can verify your DKIM-signed mail.

To make things easy, the first time you start opendkim after installing the RPM package, it will generate a default set of keys in /etc/opendkim/keys/ using your server’s domain name and the selector name “default.” However, if you want to sign for any virtual hosts or choose a different selector name than then default, you can easily generate your own keys. It really only takes a few seconds. Or, if you’re happy with the default keys, you can move on to the next step.

If you’re really hard-core, you can always build the keys manually. Or, you can use the easy script included with OpenDKIM to do it for you. I’ve manually generated enough keys in my life, so I use the script. :)

Before running this script, decide now what the name of your selector is going to be. A selector is a unique keyword that is associated with both keys (public and private), included in all the signatures, and published in your DNS records. For simplicity, I use the word default as my default selector. Not very creative, but it’s effective. Feel free to choose something different, but if you do, you’ll need to use it consistently throughout your setup. Also, while this should go without saying, you should use your mail domain instead of example.comthroughout the following steps.

Create your keys with:

mkdir /etc/opendkim/keys/example.com/usr/bin/opendkim-genkey -D /etc/opendkim/keys/example.com/ -d example.com -s defaultchown -R opendkim:opendkim /etc/opendkim/keys/example.commv /etc/opendkim/keys/example.com/default.private /etc/opendkim/keys/example.com/default

You can do a man opendkim-genkey if you’re interested in what additional options are available when creating your keys. In this example, I used the -D (directory) option, the -d(domain) option, and the -s (selector) options. That’s all you need to get this going.

Edit the configuration files

You’re getting really close now. You need to create and/or edit four files:

  1. /etc/opendkim.conf – OpenDKIM’s main configuration file
  2. /etc/opendkim/KeyTable – a list of keys available for signing
  3. /etc/opendkim/SigningTable – a list of domains and accounts allowed to sign
  4. /etc/opendkim/TrustedHosts – a list of servers to “trust” when signing or verifying

On install, the RPM package should have created a simple /etc/opendkim.conf file on your system. By default, this file is set up for verification only. In order to sign outgoing mail, you’ll have to comment, uncomment, and configure some additional options in the configuration file. Use your favorite text editor to open /etc/opendkim.conf and make it look like this:

01 ## CONFIGURATION OPTIONS
02
03 # Specifies the path to the process ID file.
04 PidFile /var/run/opendkim/opendkim.pid
05
06 # Selects operating modes. Valid modes are s (signer) and v (verifier). Default is v.
07 Mode    sv
08
09 # Log activity to the system log.
10 Syslog  yes
11
12 # Log additional entries indicating successful signing or verification of messages.
13 SyslogSuccess yes
14
15 # If logging is enabled, include detailed logging about why or why not a message was
16 # signed or verified. This causes a large increase in the amount of log data generated
17 # for each message, so it should be limited to debugging use only.
18 #LogWhy yes
19
20 # Attempt to become the specified user before starting operations.
21 UserID  opendkim:opendkim
22
23 # Create a socket through which your MTA can communicate.
24 Socket  inet:[email protected]
25
26 # Required to use local socket with MTAs that access the socket as a non-
27 # privileged user (e.g. Postfix)
28 Umask   002
29
30 # This specifies a file in which to store DKIM transaction statistics.
31 #Statistics              /var/spool/opendkim/stats.dat
32
33 ## SIGNING OPTIONS
34
35 # Selects the canonicalization method(s) to be used when signing messages.
36 Canonicalization        relaxed/simple
37
38 # Domain(s) whose mail should be signed by this filter. Mail from other domains will
39 # be verified rather than being signed. Uncomment and use your domain name.
40 # This parameter is not required if a SigningTable is in use.
41 Domain                  example.com
42
43 # Defines the name of the selector to be used when signing messages.
44 Selector                default
45
46 # Gives the location of a private key to be used for signing ALL messages.
47 #KeyFile                 /etc/opendkim/keys/default.private
48
49 # Gives the location of a file mapping key names to signing keys. In simple terms,
50 # this tells OpenDKIM where to find your keys. If present, overrides any KeyFile
51 # setting in the configuration file.
52 KeyTable                 refile:/etc/opendkim/KeyTable
53
54 # Defines a table used to select one or more signatures to apply to a message based
55 # on the address found in the From: header field. In simple terms, this tells
56 # OpenDKIM how to use your keys.
57 SigningTable                 refile:/etc/opendkim/SigningTable
58
59 # Identifies a set of "external" hosts that may send mail through the server as one
60 # of the signing domains without credentials as such.
61 ExternalIgnoreList      refile:/etc/opendkim/TrustedHosts
62
63 # Identifies a set internal hosts whose mail should be signed rather than verified.
64 InternalHosts           refile:/etc/opendkim/TrustedHosts

You can do man opendkim.conf for more information on each of the options in this file.

Uncomment the Domain option (and include your actual domain name), the KeyTable,SigningTableExternalIgnoreList, and InternalHosts options. Also, since you’ll be using aKeyTable, you can comment the KeyFile option.

Next, you’ll need to create the three text files that you just uncommented in your config file. First, using your favorite text editor, create an /etc/opendkim/KeyTable file that looks like this:

1 default._domainkey.example.com example.com:default:/etc/opendkim/keys/example.com/default

The KeyTable file tells OpenDKIM where to find your keys. Each entry in the KeyTable file is asingle line for each key location (for example, all of the text in the above example should be on a single line in your file). If you’re going to use multiple keys (to sign mail for virtual domains with different keys, for example), you’ll need to create a separate line in theKeyTable file for each domain, like this:

1 default._domainkey.example.com example.com:default:/etc/opendkim/keys/example.com/default
2 default._domainkey.example2.com example2.com:default:/etc/opendkim/keys/example2.com/default

Next, you need to create or edit the /etc/opendkim/SigningTable file. A default version of this file should have been installed in /etc/opendkim when you installed the RPM, so just uncomment the following line (or edit the file to include this line) so it reads:

1 *@example.com default._domainkey.example.com

The SigningTable file tells OpenDKIM how to use your keys, as in which senders should use which selectors for their signatures. In the above example, I’m saying that everyone (*) sending mail from the server “example.com” should use the selector named “default.” Again, for multiple domains and/or users, you’ll need multiple lines, like this:

01 *@example.com default._domainkey.example.com
02 [email protected]<script type="text/javascript">
03 /* <![CDATA[ */
04 (function(){try{var s,a,i,j,r,c,l=document.getElementById("__cf_email__");a=l.className;if(a){s='';r=parseInt(a.substr(0,2),16);for(j=2;a.length-j;j+=2){c=parseInt(a.substr(j,2),16)^r;s+=String.fromCharCode(c);}s=document.createTextNode(s);l.parentNode.replaceChild(s,l);}}catch(e){}})();
05 /* ]]> */
06 </script> default._domainkey.example2.com
07 [email protected]<script type="text/javascript">
08 /* <![CDATA[ */
09 (function(){try{var s,a,i,j,r,c,l=document.getElementById("__cf_email__");a=l.className;if(a){s='';r=parseInt(a.substr(0,2),16);for(j=2;a.length-j;j+=2){c=parseInt(a.substr(j,2),16)^r;s+=String.fromCharCode(c);}s=document.createTextNode(s);l.parentNode.replaceChild(s,l);}}catch(e){}})();
10 /* ]]> */
11 </script> default._domainkey.example2.com

In that example, everyone (*) sending mail from the server “example.com” can sign mail and should use the selector named “default.” But only Bob and Doug can sign mail for “example2.com” (also using a selector named default). It’s important to note that the * wildcard symbol will only work if the SigningTable option uses the refile: prefix before the filename (see the opendkim.conf documentation for more details).

Next, create an /etc/opendkim/TrustedHosts file that looks like this:

1 127.0.0.1
2 hostname1.example1.com
3 hostname2.example1.com
4 example1.com
5 hostname1.example2.com
6 hostname2.example2.com
7 example2.com

The TrustedHosts file tells OpenDKIM who to let use your keys. Because it’s referenced by theExternalIgnoreList directive in your conf file, OpenDKIM will ignore this list of hosts when verifying incoming mail. And, because it’s also referenced by the InternalHosts directive, this same list of hosts will be considered “internal,” and OpenDKIM will sign their outgoing mail.

IMPORTANT: Make sure you list the IP address for localhost (127.0.0.1) in the TrustedHostsfile or OpenDKIM won’t sign mail sent from this server. If you have multiple servers on the same network that relay mail through this server and you want to sign their mail as well, theymust be listed in the TrustedHosts file. Put each entry on its own line. An entry can be a hostname, domain name (e.g. “example.com”), IP address, an IPv6 address (including an IPv4 mapped address), or a CIDR-style IP specification (e.g. “192.168.1.0/24″).

It should also go without saying (but I’ll say it anyway) that if you’re planning to sign outgoing mail for remote hosts, your mail server should have been previously configured to allow relaying for those hosts.

发表评论

This site uses Akismet to reduce spam. Learn how your comment data is processed.