[GH-ISSUE #2768] DKIM key refresh issues #1699

New issue

Closed

opened 2026-02-27 11:18:38 +03:00 by kerem · 3 comments

kerem commented

2026-02-27 11:18:38 +03:00

Owner

Originally created by @olaf7 on GitHub (Jan 29, 2023).
Original GitHub issue: https://github.com/modoboa/modoboa/issues/2768

OS: Debian 11 Bullseye (stable)
Manual old (various) upgrades of Modoboa. Currently on version 2.0.3
Database: MariaDB

DKIM keys generated using Modoboa. I expected a path in the database like in (screenshot):
https://github.com/modoboa/modoboa/issues/2208#issuecomment-817108156
However only the name of the PEM file shows. No paths. Keys are stored in: /srv/modoboa/env/instance
A bit messy. Expected location on Debian would have been: /etc/dkimkeys

DKIM keys have been added to DNS.

DKIM signing does not work properly:

mail sent from commandline is delivered but not signed
mail sent from webmail (roundcube) errors: OpenDKIM is configured using TCP sockets, but problem and log entries are like: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944513 (although TCP sockets are claimed to be working there)

The Debian bug report suggested that the cause might be a corrupt key so I regenerated for 1 domain a DKIM key using the old(!) admin interface. I can let the admin panel show the key, so it seems ok, but ...
I decided to restart the opendkim service which failed. It turned out to be that:

the PEM file in /srv/modoboa/env/instance was not updated
afaik the PEM file was not stored in an other location
the database field holding the PEM-file (and path) is empty! This is the reason why opendkim does not restart

Originally created by @olaf7 on GitHub (Jan 29, 2023). Original GitHub issue: https://github.com/modoboa/modoboa/issues/2768 OS: Debian 11 Bullseye (stable) Manual old (various) upgrades of Modoboa. Currently on version 2.0.3 Database: MariaDB DKIM keys generated using Modoboa. I expected a path in the database like in (screenshot): https://github.com/modoboa/modoboa/issues/2208#issuecomment-817108156 However only the name of the PEM file shows. No paths. Keys are stored in: /srv/modoboa/env/instance A bit messy. Expected location on Debian would have been: /etc/dkimkeys DKIM keys have been added to DNS. DKIM signing does not work properly: - mail sent from commandline is delivered but not signed - mail sent from webmail (roundcube) errors: OpenDKIM is configured using TCP sockets, but problem and log entries are like: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944513 (although TCP sockets are claimed to be working there) The Debian bug report suggested that the cause might be a corrupt key so I regenerated for 1 domain a DKIM key using the old(!) admin interface. I can let the admin panel show the key, so it seems ok, but ... I decided to restart the opendkim service which failed. It turned out to be that: - the PEM file in /srv/modoboa/env/instance was not updated - afaik the PEM file was not stored in an other location - the database field holding the PEM-file (and path) is empty! This is the reason why opendkim does not restart

kerem

2026-02-27 11:18:38 +03:00

closed this issue
added the
enhancement
label

kerem commented

2026-02-27 11:18:39 +03:00

Author

Owner

@olaf7 commented on GitHub (Jan 29, 2023):

manually running: python manage.py modo manage_dkim_keys
fixed the empty field and refreshed/renewed the file in /srv/modoboa/env/instance
However I still think this is troublesome as in the meantime opendkim can not be restarted (or the server).
Also remains that the PEM files have no path in the DB, the storage location of the files is weird and the signing issues are still there.
The GUI says: SMTP Error: [451] 4.7.0 resource unavailable
But the logfile is more interesting and descriptive.

@olaf7 commented on GitHub (Jan 29, 2023): manually running: python manage.py modo manage_dkim_keys fixed the empty field and refreshed/renewed the file in /srv/modoboa/env/instance However I still think this is troublesome as in the meantime opendkim can not be restarted (or the server). Also remains that the PEM files have no path in the DB, the storage location of the files is weird and the signing issues are still there. The GUI says: SMTP Error: [451] 4.7.0 resource unavailable But the logfile is more interesting and descriptive.

kerem commented

2026-02-27 11:18:39 +03:00

Author

Owner

@tonioo commented on GitHub (Feb 1, 2023):

@olaf7 You should check why the command you ran manually was not called earlier. It is supposed to be run periodically as a cron task (look at /etc/cron.d/modoboa file)
And about keys location, that's something you can configure through the web interface.

@tonioo commented on GitHub (Feb 1, 2023): @olaf7 You should check why the command you ran manually was not called earlier. It is supposed to be run periodically as a cron task (look at /etc/cron.d/modoboa file) And about keys location, that's something you can configure through the web interface.

kerem commented

2026-02-27 11:18:39 +03:00

Author

Owner

@olaf7 commented on GitHub (Feb 17, 2023):

@tonioo , my comment on the restart failure issue is about that there is a time gap between key modification in the DB and the execution of the cron job. In that gap restart will fail. A solution would be if a mutation in the admin panel would result in immediately calling the code from the panel instead of waiting for the cronjob.

It turns out I have multiple issues getting DKIM to work. Here is my feedback on the issue addressed in this ticket:
In my Modoboa installation the DKIM key path was not defined. This results in storage of PEM files in the root of the Modoboa installation (in my case a virtual env owned by user Modoboa) owned by the user running Modoboa (username modoboa in my case). But also in a registry in the database of the filename without a path. This is troublesome by default: postfix will have no idea where to find the PEM files and produces SMTP errors. Maybe Modoboa would warn/error on not valid values for the key-path and incomplete path/filename field entries?

Related to this is that the desired location should be writable by the systemuser running Modoboa where as OpenDKIM wants more restrictive rights and ownership. I do not see how to work around that without manual intervention as sudo will not do the trick:

the path in the panel can not be set to the desired location (in my/Debian's case: /etc/dkimkeys) as it is not validated. It gives a warning, makes/keeps the setting empty and allows the user/admin to continue resulting in the situation described above.
the dkim cronjob script uses the openssl binary but not using sudo, so adding something to /etc/sudoers will not help as that would only do the trick when strictly using binaries and sudo should be called. Currently not the case afaik.

I manually intervened and copied files to /etc/dkimkeys, did set rights and ownership correctly. Next I added full path to the PEM filename in the database.
Result:

no more errors when sending email
getting a perfect score of 10 when using mail-tester.com, both from cli and when using roundcube webmail
unfortunately mail does not get signed and does not arrive at gmail and yahoo. According to the sent box it does not get signed. Hard to debug as there are no errors etc in /var/log/mail.* or syslog. But that is probably an entirely different issue.

@olaf7 commented on GitHub (Feb 17, 2023): @tonioo , my comment on the restart failure issue is about that there is a time gap between key modification in the DB and the execution of the cron job. In that gap restart will fail. A solution would be if a mutation in the admin panel would result in immediately calling the code from the panel instead of waiting for the cronjob. It turns out I have multiple issues getting DKIM to work. Here is my feedback on the issue addressed in this ticket: In my Modoboa installation the DKIM key path was not defined. This results in storage of PEM files in the root of the Modoboa installation (in my case a virtual env owned by user Modoboa) owned by the user running Modoboa (username modoboa in my case). But also in a registry in the database of the filename without a path. This is troublesome by default: postfix will have no idea where to find the PEM files and produces SMTP errors. Maybe Modoboa would warn/error on not valid values for the key-path and incomplete path/filename field entries? Related to this is that the desired location should be writable by the systemuser running Modoboa where as OpenDKIM wants more restrictive rights and ownership. I do not see how to work around that without manual intervention as sudo will not do the trick: - the path in the panel can not be set to the desired location (in my/Debian's case: /etc/dkimkeys) as it is not validated. It gives a warning, makes/keeps the setting empty and allows the user/admin to continue resulting in the situation described above. - the dkim cronjob script uses the openssl binary but not using sudo, so adding something to /etc/sudoers will not help as that would only do the trick when strictly using binaries and sudo should be called. Currently not the case afaik. I manually intervened and copied files to /etc/dkimkeys, did set rights and ownership correctly. Next I added full path to the PEM filename in the database. Result: - no more errors when sending email - getting a perfect score of 10 when using mail-tester.com, both from cli and when using roundcube webmail - unfortunately mail does not get signed and does not arrive at gmail and yahoo. According to the sent box it does not get signed. Hard to debug as there are no errors etc in /var/log/mail.* or syslog. But that is probably an entirely different issue.