Dear Maintainer, The README file was not prescriptive about where to place the configuration files. It did say what the ownership, etc, of the files/directory should be. So I placed them in /etc/mail/dkim/ In recent versions of opendkim, I've been experiencing errors such as this: "key data is not secure: /etc/mail is writeable and owned by uid 100 which is not the executing uid (117) or the superuser" The directory /etc/mail/dkim has the correct ownership and permissions, but the parent directory /etc/mail does not. I can work around the problem by changing the ownership of /etc/mail to root. (but need to be careful, because I think /usr/sbin/sendmailconfig will change it back.) I feel that if a configuration directory was created by the installer, all users could write their files there as well as the opendkim.conf file. The installer could ensure the directory had the correct ownership and access permissions, so this error would not affect anyone else. I suggest: /etc/opendkim/ What do you think?
I decided to go with /etc/dkimkeys and leave opendkim.conf where it is. It's only the private keys that need special protection, not the config file. Scott K
We believe that the bug you reported is fixed in the latest version of
opendkim, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 706061@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Scott Kitterman <scott@kitterman.com> (supplier of updated opendkim package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Sun, 26 Apr 2015 15:59:57 -0400
Source: opendkim
Binary: opendkim opendkim-tools libopendkim10 libopendkim-dev libvbr2 libvbr-dev librbl1 librbl-dev
Architecture: source amd64
Version: 2.10.1-2
Distribution: unstable
Urgency: medium
Maintainer: Mike Markley <mike@markley.org>
Changed-By: Scott Kitterman <scott@kitterman.com>
Description:
libopendkim-dev - Headers and development libraries for the OpenDKIM library
libopendkim10 - Library for signing and verifying DomainKeys Identified Mail sign
librbl-dev - Headers/development libraries for the OpenDKIM RBL library
librbl1 - Library to support a DKIM based RBL system
libvbr-dev - Headers and development libraries for the OpenDKIM VBR library
libvbr2 - Library for RFC 5518 Vouch By Reference (VBR)
opendkim - Milter implementation of DomainKeys Identified Mail
opendkim-tools - Set of command line tools for OpenDKIM
Closes: 706061 751560 776590 780140 780619 782459 783260
Changes:
opendkim (2.10.1-2) unstable; urgency=medium
.
* Upload to unstable
* Use daemon name vice filename in init when checking to see if the pid file
is stale or not (Closes: #783260)
* Add /etc/dkimkeys directory with appropriate permissions set in postinst
for securely storing DKIM private keys (Closes: #706061)
* Update and improve key managemnet discussion in README.Debian
* Add unbound to opendkim suggests and UnboundConfigFile so shipped config
file to ease setup of DNSSEC (Closes: #751560)
* Use exit instead of return in opendkim.init in start, stop, status
(Closes: #776590)
* Update dates in debian/copyright
* Update comments in debian/opendkim.conf
* Fix missing text in libopendkim-dev long description (Closes:
#780140)
* Fix dubplicated text in libvbr-dev long description (Closes:
#780619)
* Add --with-domain=localhost to configure to make the build
reproducible (Closes: #782459)
- Thanks to Reiner Herrmann for the report and the patch
* Delete opendkim.postrm - we don't want to delete the user on purge
since it may still own key files
* Use pathfind from devref 6.4 to remove hard coded paths to
restorecon and fix lintian command-with-path-in-maintainer-script
warning
Checksums-Sha1:
b9c57aba68bc25fd22ea34ebcef48d6d853dc424 2316 opendkim_2.10.1-2.dsc
fa38d42547ca67ce109bca775d10dfe44ac98a43 19820 opendkim_2.10.1-2.debian.tar.xz
0ed92b7cdb7dcf6f316f3596b52c47d23d80c8e6 200232 opendkim_2.10.1-2_amd64.deb
6304807a535c4be3be6b8ae33c702f5269ebc8cc 129846 opendkim-tools_2.10.1-2_amd64.deb
fd0cf9a4c86f0f79063b21f75f5d2590c105c5a9 89148 libopendkim10_2.10.1-2_amd64.deb
a0d33830dc74ecbf0c097807ed24be86e0156394 156422 libopendkim-dev_2.10.1-2_amd64.deb
5d0982b22e97c0b14d5430e4864c30da10f1062d 46074 libvbr2_2.10.1-2_amd64.deb
b8f0bb101a35852eccc156ca486cdacbb36df5b4 50718 libvbr-dev_2.10.1-2_amd64.deb
f2ed7cfc11bd8e033d251aea97b7460a47e2477c 43984 librbl1_2.10.1-2_amd64.deb
8454e379e5ebd385b1d7cf54aee45c744d1afa9e 48800 librbl-dev_2.10.1-2_amd64.deb
Checksums-Sha256:
2cdf770cddb71d14b4d5072295378043b581812c59ac8d97167fead3e3024e17 2316 opendkim_2.10.1-2.dsc
2748a95ebeee7c20f5a81e4db4da2aa8f73984a751b7c5434f0d3a3b20052fec 19820 opendkim_2.10.1-2.debian.tar.xz
ba1d1788a0d274a3e5e33e0d77b1d26f36af0054e5b6b396af6a4951ac2d5211 200232 opendkim_2.10.1-2_amd64.deb
b335afcbc9abc332eed04ca465dbd297715949e8700b41630a732323a35b8fc6 129846 opendkim-tools_2.10.1-2_amd64.deb
4490a116ed2b8940dee4bf827b4fb9c3c69367e4deccf55168194428fad4cea2 89148 libopendkim10_2.10.1-2_amd64.deb
e3f4da00948f9b87f73a6a578c3491e3beb9e86ba3dab0f1c598e17beb3b2d93 156422 libopendkim-dev_2.10.1-2_amd64.deb
a2e233342f4cfbf30da8f8ca9d46c4f660b7c3b395c00b2188d3a6d0a942b86f 46074 libvbr2_2.10.1-2_amd64.deb
de682b115e97efefb6baead90db2f1af28cf39155396fd60e81438a2ba2cb274 50718 libvbr-dev_2.10.1-2_amd64.deb
a844dec901822f9a4a742d00dd3896203e0782b662ba9f10927c4ea91710ff50 43984 librbl1_2.10.1-2_amd64.deb
d812898fb07ef400d7f6e6d53453e47a642c30cf57a85750bfe0ce76b64c18c2 48800 librbl-dev_2.10.1-2_amd64.deb
Files:
a2047dfc98b27bf231fda3f0a9f97dee 2316 mail extra opendkim_2.10.1-2.dsc
d5236557d9b907bb4f37a3b457385a5e 19820 mail extra opendkim_2.10.1-2.debian.tar.xz
78e610272c4e1f4cae236a1146cfa569 200232 mail extra opendkim_2.10.1-2_amd64.deb
6d2269cadfa7525c9b9675ff2d677cf3 129846 mail extra opendkim-tools_2.10.1-2_amd64.deb
f53647e221919eb7f7cf9a46390e8773 89148 libs extra libopendkim10_2.10.1-2_amd64.deb
6978ec4e78396fc9b1a86464d2e490e7 156422 libdevel extra libopendkim-dev_2.10.1-2_amd64.deb
22911d2dfda9e11a0a13f806193d7f55 46074 libs extra libvbr2_2.10.1-2_amd64.deb
bc3fc6d7a0c442f966755a9dbd81f44a 50718 libdevel extra libvbr-dev_2.10.1-2_amd64.deb
89de23961204eb0a30aeaad637c87b09 43984 libs extra librbl1_2.10.1-2_amd64.deb
07e7c21fca4049ee3e44b4fe02a48098 48800 libdevel extra librbl-dev_2.10.1-2_amd64.deb
iQIcBAEBCAAGBQJVPUqhAAoJEHjX3vua1ZrxWYQP/A6Jjpap3M/jKUVSxdODNzi+
eFr1/ADmRIJCsi1tzbKhg0o7Z+wn3HUnIU4zAQIvr8Ks8rRnFfK0K6BAa6jSXDhc
sY1ZaYcrPWr3GmR0irRrE3XR27QU1iiMAnmCug8sdqCM+XWGBnTMkGTxm9MN9vFk
ZvW4MmaCKLdK0qq8Adh9fauZA1sAM8OM/E0cSUCwQDm/Im/8TGUaB1VOKnls5l9I
9G5WrOsvYjdtL422bnCr0vvptZWXkyw/wYUbcrJIOCW2dkAyO9oRtkx3KDp3L+Gn
JJClpKEUw+KblsErh1RhVO+EPpNqUfuhnI5vmqDUAvHPddgixaLspFiWVIwPWu2t
scE7ViRbc/9Q8RbmPfva2iOuImUGDtYOn025hS4NntHifXef5n8Ev49hrMYKQDlK
5xGy9RaI3NLsH8cg4oT/oifFVU/Zasbpgu2wZgDtEHpXNWjnJxwjz1p2wQqsXJdG
/LY1YdbzndihbJgMBUpmgc9v4NX3rRBLumfwBPiEqEAbZV7AiDgbKis+GgypaV2D
OjJGmWiyc1W1VnXVOXj/zjWNX95kf3DQ/Vp8jYtitwp+Fp0fJ4r3jCs9guAMW5mw
kviK1kaM/idHeHad9gLE+bh6W0IBphJuWLQYfW3h9eaOAwaM1ndQ6No9q9XN703r
M/0V7TSN/HvHP21OEL5g
=UF2k
-----END PGP SIGNATURE-----
I think this bug/request and its solution could use a revisit. I'm not sure about the state of the art in 2013, but in 2021 configuring OpenDKIM almost any virtual mail server requires a lot more configuration files. The new two-part signing system does not lend itself well to just a keys directory and opendkim.conf directly in /etc. The usual practice is a directory structure as shown: etc ├── opendkim | ├── opendkim.conf | ├── KeyTable | ├── SigningTable | ├── TrustedHosts | ├── Keys | | ├── domain1.ca | | | ├── mail.private | | | ├── mail.txt | | ├── domain2.ca | | | ├── mail.private | | | ├── mail.txt | | ├── ... | | | The original request back in 2013 was to create /etc/opendkim and to place the config file inside it. This is the standard practice for most anything that is non-trivial to configure. I would like to request that this be adopted. Backwards compatibility with the old method can be maintained by making /etc/opendkim.conf a softlink to /etc/opendkim/opendkim.conf. It is telling that I can find no howto or tutorial for OpenDKIM on Debian that doesn't instruct the user to create /etc/opendkim for further use: https://www.digitalocean.com/community/tutorials/how-to-install-and-configure-dkim-with-postfix-on-debian-wheezy https://allysmith.uk/using-dkim-with-postfix-on-debian https://meumobi.github.io/sendmail/2015/09/18/install-configure-dkim-sendmail-debian.html It would be a benefit if OpenDKIM's out-of-the box configuration structure could match what current practices are in the wild.
I think this request is not unreasonable. On the other hand, I don’t see a good reason for changing the default now, after it has served us well for so many years. /etc/opendkim.conf is what upstream uses as the default in its documentation. /etc/opendkim.conf is still all you need for a simple single-domain setup. For example, we use it to quickstart an OpenDKIM installation in the Debian wiki: https://wiki.debian.org/opendkim In my opinion, what we have now is a sensible default. Users with more complex requirements are free to create additional files and directory structure for their specific use case.
I fundamentally agree that a dedicated directory in /etc for some software package is the right way. I disagree with doing that now, only in Debian, only for the OpenDKIM package. I think the way forward would be to propose the change to upstream, for all of OpenDKIM, OpenDMARC, OpenARC. That way the change could eventually be rolled out everywhere evenly.