Today I received a mail from anacron, with subject "Anacron job 'cron.monthly'", that contained the message "Generating DH parameters, 2048 bit long safe prime" followed by all the dots and plusses that OpenSSL prints. It was unclear to me what happened there, because I have written no such script for my TLS deployment. I checked the directory and found the script /etc/cron.monthly/courier-imap with the following content: --- #!/bin/sh /usr/sbin/mkdhparams --- I was puzzled because I don't use courier-imap and investigated. mkdhparams is also a script that creates a new /etc/courier-imap/dhparams.pem file. I checked the courier-imap config and the file is indeed referenced. So I wonder about some things: 1. Doesn't the courier service need a restart/reload after changing one of the TLS files? Someone who runs the service should get the restart or a notice to restart manually. Someone who does *not* run the service and maybe uses another imapd like dovecot (like me), the program should certainly never run - but in that case why run the mkdhparams script in the first place? (ok, let's ask the question, why is it installed then; more about that later) 2. Is it a good idea to replace the file from a cronjob if the administrator generates and deploys his own TLS files? 3. Shouldn't the cronjob either print its name/purpose before executing the mkdhparams script or suppress its execution? 4. Should all other services that use a DH file (e.g. apache) create a new one each month? Why are there no cronjobs? (of course the existance of such a script for other services would cause the same issue again) Regarding 1: I checked the systemd services for courier-imapd.service and courier-imapd-ssl.service (they are not active and were never started - good) and found a logged issue in the journal: --- /usr/lib/systemd/system/courier-imapd-ssl.service:11: PIDFile= references a path below legacy directory /var/run/, updating /var/run/imapd-ssl.pid → /run/imapd-ssl.pid; please update the unit file accordingly. --- I am trying to find out why courier is installed in my system. Only maildrop requires it due to the gdbm USE flag. maildrop is from courier, but works standalone (so I think a dependency to courier is an error): Having an active gdbm USE flag pulls in 4 courier packages. I did not activate that USE flag manually (neither for the package, nor globally), so I think this is inherited from system settings and I doubt most users want to pull in courier automatically. Now I checked the files installed by net-mail/courier-imap (with active gdbm USE flag too) and found nothing that provides gdbm related function for external programs like maildrop: no include files, no libraries, not even programs (I checked with ldd), just /usr/sbin/courier-imapd itself, which isn't running in my case. In the maildrop programs the only dependency to some courier package is /usr/lib64/libcourier-unicode.so.8 which belongs to net-libs/courier-unicode - with and without gdbm USE flag. The gdbm flag just links against libgdbm.so.6, which would be fine. courier-common would be a sort-of dependency, it contains makedat which creates GDBM/DB files for maildrop according to the manpage (let's say, maildrop +gdbm could work without it even, we just could not create files for it to use); the courier-common dependency comes from the tools USE flag in maildrop. TL;DR: I think courier-imap should not be a dependency for maildrop, maildrop should get its USE dependencies checked and I think there are some design issues with the cronjob and the dh generation of courier-imap and there is a warning in its systemd units too.
oh, and the cronjob-generated /etc/courier-imapd/dhparams.pem stays behind after uninstallation of courier-imapd because it does not belong to a package. This is logical but the file is garbage nonetheless.
