Right, I believe I’ve solved this. I can’t guarantee that the root cause of this issue is the same on everyone’s server, so the same symptoms may not always require the same cure, but here was what was going on with two of my servers.
The symptom: When you run virus scanning on incoming email, and use clamd to scan rather than the standalone scanner, it fails to scan. You see the following entry in procmail.log: “ERROR: Could not lookup : Servname not supported for ai_socktype”
The trigger: Having fixed the problem, two things cause it to recur - (i) a server reboot, (ii) yum updating clamscan etc to a new version. (Simply restarting clamd@scan.service did not cause the problem, neither did updating the ClamAV signature files).
The way to get it working again: As in a post further up this thread. All in Virtualmin > Email Messages > Spam and Virus Scanning: (i) Set scanning back to the standalone; (ii) disable ClamAV server; (iii) enable ClamAV server; (iv) set scanning to use the “server scanner”.
The actual cause: Permissions. The socket for clamd is stored at /var/run/clamd.scan/clamd.sock. When you configure ClamAV for the first time, or reboot the server, the folder /var/run/clamd.scan is set to have permissions of 710. You can set the actual socket permissions in /etc/clam.d/scan.conf, but not the permissions for its containing folder. procmail will pass its scanning process to be run by the user of the mailbox receiving the message (i.e., Linux user username.domain). Unless that user is a member of the clamscan group, it won’t be able to enter the /var/run/clamd.scan folder, so it can’t access the socket. The painful route would be to add all mailbox users to the clamscan group. But the better solution is to set /var/run/clamd.scan to 755. The trouble is, a server reboot sees the folder permission revert to 710. [Why?]. Re-enabling “server scanner” in VirtualMin will reset the folder permissions to 755, but doing it manually is enough to get scanning working again.