Can't change OpenDKIM socket in Debian stretch in /etc/default/opendkim

Solution 1:

I finally found the solution.

The /etc/init.d/opendkim doesn't seem to do anything. But instead the servicefile /lib/systemd/system/opendkim.service is used which had the wrong socket hardcoded.

But the debian package also seems to include a bash that generates the correct systemd service.

So after running

/lib/opendkim/opendkim.service.generate
systemctl daemon-reload
service opendkim restart

and restarting opendkim the socket file appears in the expected place, which can be verified by calling:

tail /var/log/mail.log | grep OpenDKIM

Update: It seems there is an debian bugreport about this issue: #861169

Update 2021:

As this question is still read quite often, I want to make everyone aware of the recent NEWS entry:

[...]

We remind users that opendkim is best configured by editing /etc/opendkim.conf. The legacy defaults file at /etc/default/opendkim is still available, as is the script /lib/opendkim/opendkim.service.generate. However, these provide no additional value over the default configuration file /etc/opendkim.conf. Please take this opportunity to review your configuration setup.

Also beginning with Debian Bullseye the /etc/default/opendkim starts with:

# NOTE: This is a legacy configuration file. It is not used by the opendkim
# systemd service. Please use the corresponding configuration parameters in
# /etc/opendkim.conf instead.
#
# Previously, one would edit the default settings here, and then execute
# /lib/opendkim/opendkim.service.generate to generate systemd override files at
# /etc/systemd/system/opendkim.service.d/override.conf and
# /etc/tmpfiles.d/opendkim.conf. While this is still possible, it is now
# recommended to adjust the settings directly in /etc/opendkim.conf.

Solution 2:

I don't have enough reputation to comment and wanted to acknowledge that after hours of searching for a solution to the OpenDKim-Postfix 'connection refused' error message, the /lib/systemd/system/opendkim.service edit provided by LocutusBE worked with Ubuntu 17.04:

warning: connect to Milter service inet:localhost:8891: Connection refused

edit /lib/systemd/system/opendkim.service

change:

ExecStart=/usr/sbin/opendkim -P /var/run/opendkim/opendkim.pid -p local:/var/run/opendkim/opendkim.sock

to:

ExecStart=/usr/sbin/opendkim -P /var/run/opendkim/opendkim.pid -p local:/var/run/opendkim/opendkim.sock -p inet:12301@localhost

systemctl daemon-reload

and

systemctl opendkim restart

Before attempting the edit I added the postfix user to the opendkim group and tried /lib/opendkim/opendkim.service.generate per Lukas Winkler's solution. The connection refused error persisted until the port number was added to /lib/systemd/system/opendkim.service.

To update /lib/systemd/system/opendkim.service, I used port 8891 for Ubuntu and commented out the original ExecStart line for testing purposes, then added a new line with port #:

/lib/systemd/system/opendkim.service (Service category):

    [Service]
    Type=forking
    PIDFile=/var/run/opendkim/opendkim.pid
    User=opendkim
    UMask=0007
    #ExecStart=/usr/sbin/opendkim -P /var/run/opendkim/opendkim.pid -p local:/var/run/opendkim/opendkim.sock
    ExecStart=/usr/sbin/opendkim -P /var/run/opendkim/opendkim.pid -p local:/var/run/opendkim/opendkim.sock -p inet:8891@localhost
    Restart=on-failure
    ExecReload=/bin/kill -USR1 $MAINPID

The matching port number was additionally specified in /etc/opendkim.conf:

Socket                  inet:8891@localhost

And /etc/postfix/main.cf:

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

After restarting the systemctl daemon, opendkim, and postfix, outgoing mail was signed without issue and the mail log showed "DKIM-Signature field added".

systemctl daemon-reload
systemctl opendkim restart
systemctl postfix restart

There was no connection issue when configuring OpenDkim with Centos7 recently, so apparently in this instance it was Ubuntu-related. Thanks to Lukas Winkler for posting the question and those who shared their solutions.