Plan MailScanner, SpamAssassin and ClamAV Integration Safely

MailScanner can integrate mail processing with spam and antivirus tools such as SpamAssassin and ClamAV. This is a server-administrator deployment task, not a package list that can be safely pasted onto every mail server. Scanning reduces some risks; it does not guarantee a clean server, prevent every blacklist entry or replace abuse monitoring.

Why the legacy CentOS recipe should not be reused

The previous walkthrough downloaded a MailScanner 4 package over HTTP, mixed obsolete CentOS/init instructions with inconsistent Postfix paths, used typographic command dashes, and contained misspelled configuration keys and state directories. Its success statement was not evidence that the mail queue or delivery worked. CentOS Linux 7 and 8 are also end of life.

Do not run the old installer on a current or panel-managed mail server. Use supported operating-system packages and the installation/integration instructions matching the actual MailScanner release and MTA. Upstream pages can themselves contain legacy platform examples; verify release support instead of treating a historical OS list as a current security recommendation.

Plan the mail-processing path

1. Inventory the actual MTA, queue locations, existing content filters, panel management and outbound relay. Identify how both incoming and outgoing messages traverse the proposed scanner.
2. Preserve configuration and a recovery plan, including queue state and a maintenance window. Do not delete queued messages to simplify installation.
3. Choose one documented integration model for the installed versions. Do not combine an old hold-queue recipe with a different milter design or overwrite existing filter chains.
4. Confirm service identities, exact queue/state paths, ownership, socket permissions, resource needs and signature/rule-update mechanisms.
5. Install only verified release artifacts or supported packages. Keep private keys and service credentials out of public directories and logs.

A queue hold rule can stop delivery

A broad header rule that places mail on hold requires a functioning matching processor and release path. If that processor is absent or broken, mail can accumulate instead of being delivered. The old walkthrough inconsistently named header_checks and header_check; correcting a filename alone is not sufficient to validate the design. Do not broadly hold production mail as an installation test.

Verify before relying on the service

Use the release’s supported configuration-validation procedure, then stage authorized harmless test traffic. Check ordinary delivery, the intended detection/action path, queue draining, logs, resource load and what happens when a scanner is unavailable. Coordinate antivirus testing through the vendor’s approved method and your security policy; do not distribute live malware or spam.

Verify actual rule/signature freshness and scheduler operation. A lint pass, running process or one log line does not prove end-to-end delivery, virus coverage or off-server recovery. Roll back the exact integration change if delivery is disrupted; preserve diagnostic evidence and never weaken unrelated security globally.

References: MailScanner installation guidance, MailScanner Postfix integration, configuration index, ClamAV documentation and CentOS Linux lifecycle.

Reviewed October 15, 2026. This replaces an unsafe legacy deployment recipe with a scoped integration plan. No scanner, mail queue, signature update or production MTA was installed, changed or tested.