« previous 1 2 3 4 5 6 7 next »

Signature

Choose "Add new entries" in the zone's context menu to create the TXT record for the public key in the DNS of a Windows server. Sendmail's milter protocol allows email headers and bodies to be modified on the fly. Wietse Venema, the original creator of Postfix, thought that any attempt to create a dedicated protocol was a "poor use of human and system resources", and taught his server the milter protocol. Although due to other internal structures the Postfix implementation does not offer the same milter macros as Sendmail, its range of features has been suitable for DKIM signatures since version 2.4.

Because the standard is relatively new, the software is currently undergoing frequent changes, and the distributions are lagging behind. Therefore, admins usually need to compile the DKIM application individually; in our case it is dkim-milter. If necessary, regular checks for security updates regarding dkim-milter will be required. It is advisable to switch to the distribution package once the distribution supports all the necessary features, once again making use of the automated security updates this way. The "milter development libraries" are a requirement. Postfix users can obtain them by installing either the sendmail-devel or the libmilterdev package; as the milter interface is no longer subject to change, the distribution package can be used. The somewhat unusual commands

sh ./Build
sh ./Build install

subsequently compile and install the dkim-filter program. It is advisable to set up a user without privileges for this purpose, for example one called "dkim". This user should have no connection to the mail system and should especially not belong to the same Unix group. dkim-filter takes its settings from the command line options and from a config file which is submitted with the program via the -x command line switch. The listing at the bottom of the page shows a simple configuration. Postfix admins, beware! While the notation appears to be similar to the Postfix syntax, it is in fact different. dkim-filter will use these settings to sign all outgoing emails of the example.com domain, but not of its respective subdomains (SubDomains parameter). The program will operate exclusively in sign mode (Mode) because in our mail system, signature verification is handled by SpamAssassin.

After starting at root privilege level, the program continues to run under the unprivileged dkim account. To allow it to use the signature key in the file specified at KeyFile, the admin needs to adjust its access rights:

chown dkim mail200801.private
chmod 0400 mail200801.private

After the start, dkim-filter listens on the channel specified at Socket for incoming traffic. The Canonicalisation parameter determines how line feeds and blank spaces are handled in header and body. In our example, relaxed/simple allows signed headers to contain more white space at the time of verification than they had at the time of signature, while the body has to arrive exactly as it was signed. This makes sense because some servers may "optimise" the email header along the way by wrapping lines and using spaces to indent long entries.

Some headers are not important to the email's authenticity and are particularly likely to get modified or removed along the way. To avoid invalidating the signature each time, the postmaster can use the OmitHeaders parameter to exclude those headers from the signature right at the beginning (see p. 124). The Selector parameter tells dkim-filter which public key name to insert into the signature. It needs to correspond to the previously generated DNS entry so that the verifier can later access the suitable TXT record. For testing, the additional options Syslog Yes and SyslogSuccess Yes dkim-filter allow error and success messages to be written to the system log. The dkim-filter -x /etc/mail/dkim-filter.conf command starts the program with the correct config file. It clears off into the background (Background parameter) and waits for requests. With the lsof -i | grep 8891 command, root quickly checks to make sure that dkim-filter listens on port 8891 as required. Then it's time to get Postfix and the new helper talking to each other. As explained at the beginning this should happen as late as possible. In our outlined system architecture, therefore, it only happens once amavisd-new returns a message to the Postfix mail system. A dedicated SMTP server accepts the message. It also retrieves its configuration from the master.cf file.

The signature program retrieves its settings from the dkim-filter.conf file.

The -o smtpd_milters=inet:localhost:8891 line at the end of this section is all that's required. Postfix now submits the email to the milter and sends out the result as soon as it is returned by dkim-filter. Once a postfix reload has been performed the dkim-filter is part of the Postfix email transport procedure and ready for testing. The operators of DKIM.org have set up the dkim-test@testing.dkim.org address specifically for testing emails signed with DKIM. A message sent to this address should a little while later result in an email reply containing the signature status of the message. The Authentication-Results header towards the end of the message returns whether dkim.org was able to verify the signature. Once dkim.org is happy, the signature mechanism has been successfully implemented. Some optional fine tuning like the KeyList parameter of dkim-filter is available. This parameter reads a table which can be used for assigning domain and even user specific signature keys.

« previous 1 2 3 4 5 6 7 next »