Currently, Enterprise Linux 7 deployments may run in to the following problem:

# systemctl enable clamd@amavisd.service
The unit files have no [Install] section. They are not meant to be enabled
using systemctl.
Possible reasons for having this kind of units are:
1) A unit may be statically enabled by being symlinked from another unit's
   .wants/ or .requires/ directory.
2) A unit's purpose may be to act as a helper for some other unit which has
   a requirement dependency on it.
3) A unit may be started when needed via activation (socket, path, timer,
   D-Bus, udev, scripted systemctl call, ...).

This is an issue with a package originating from EPEL, for which a solution is unclear and not available in the foreseeable future.

Rather, we can make PyKolab's setup-kolab read in /lib/systemd/system/clamd\@.service, see if there's an [Install] section, and otherwise write out a copy to /etc/systemd/system/clamd\@.service that has the necessary corrections, before issuing a systemctl enable clamd@amavisd.service.

Functionally, not starting ClamAV has two possible consequences:

1. No mail passes through Amavis
2. No virus scanning is applied

Implementation Design Considerations

• A system may or may not use systemd.
• A dependency under the kolab-mta sub-package is responsible for pulling in either clamav-server-systemd or clamav-server-sysvinit.

The eligibility for clamav-server-sysvinit to not start clamd@amavisd successfully has not been determined.