// Setting up DKIM signing with Postfix on Debian Wheezy

This is a log of my setup for OpenDKIM on Debian Wheezy. Some steps (like setting the proper access rights) might be omitted.

1. Install OpenDKIM

aptitude install opendkim opendkim-tools

On some distros, content of openkim-tools is included in the first package.

2. Generate domain key

cd /etc/postfix
opendkim-genkey -s mail -d
mv mail.private opendkim_mail.private
mv mail.txt opendkim_mail.txt

Publish the TXT record. Use the information in /etc/postfix/opendkim_mail.txt For selector “mail”, the DNS record path will be:

Complete DNS record (in the mail.txt file) will look like:

mail._domainkey IN TXT "v=DKIM1; k=rsa; p=There_will_be_your_public_key_base64_encoded" 

3. Set up the opendkim daemon.

I used a unix socket for communication. On Debian, Postfix is chrooted, so create the socket inside the chroot.

Create the directory for the socket and allow postfix to access it:

mkdir /var/spool/postfix/opendkim
chown opendkim:opendkim /var/spool/postfix/opendkim
adduser postfix opendkim #add postfix user to opendkim group (to gain access to the socket)

Modify /etc/default/opendkim:


Modify /etc/opendkim.conf:

Syslog                  yes      # Log to syslog
UMask                   002      # Allow opendkim group members to access the socket
KeyFile                 /etc/postfix/opendkim_mail.private      
Selector                mail
AutoRestart             Yes
AutoRestartRate         10/1h
Canonicalization        relaxed/relaxed  #canonize headers before signing
Mode                    s                #sign mode only
SubDomains              yes              #allow to sign emails from sub-domains

Restart the opendkim daemon and check the log

4. Set the postfix - /etc/postfix/

milter_default_action = accept
milter_protocol = 2
smtpd_milters = unix:opendkim/opendkim.sock
non_smtpd_milters = unix:opendkim/opendkim.sock

If two last lines already exist (e.g for Amavis), just append the new milter settings to the existing ones

Restart postfix and enjoy.

// Reading output of remote command with Dropbear ssh client

Today I faced strange behavior of Dropbear SSH client (dbclient) on my home OpenWRT home router. Before anything else, I would like to note that I do not have the recent version, but the version included in my OpenWRT installation. Exactly, it's Dropbear v0.53.1. But most distributions do not have recent versions so I hope this will remain usefull to others.

I have a shell script which uses ssh client to read some information from my other server. Imagine following shell code snippet:

result=`ssh -i key_file user@server remote_command` && {
  echo "Obtained information is $result"

This code will connect to remote machine and run remote_command which produces some output. This output will be assigned to variable $result. If remote command succeeds (returns exit code 0) the message with obtained value will be printed.

For particular reason, this snippet did not work if the whole script was run by cron. I googled a lot. I found some issues in Dropbear mailing list including quite dirty but working solution.

The reason is that script run by cron has no standard input available. Due to this, dbclient does not read any output from remote command either, so the $result variable is set empty and no error code is returned.

This behavior can be simulated from running shell as

ssh -i key_file user@server echo "foo" </dev/null

Nothing will be returned. Note that this modification does not affect OpenSSH client behavior (SSH implementation on most “big” Linux machines).

The quickest solution is to “create some stdin to ssh client”, redirect from /dev/zero is enough. Following code works:

result=`ssh -i key_file user@server remote_command </dev/zero` && {
  echo "Obtained information is $result"

Now the whole script works either standalone or as a cronjob.

About me
SW developer, amateur tennis player, rock'n'roll & heavy metal fan.