The spam filter ran without errors, and phishing still reached the inboxes

The DNS blacklists ran, they just never said anything

The server used a public resolver. Operators of lists such as Spamhaus block queries from public resolvers because of their volume. The filter does not report an error in that case: it adds a rule ending in BLOCKED with zero points and carries on. The strongest reputation signals were dead, and the system looked healthy. SpamAssassin 4.0 also no longer ships the Spamhaus ZEN rules by default; they were added so that only real listing codes score, never error or rate-limit codes.

The filter had learned that phishing is fine

Modern spam is often perfectly authenticated: valid DKIM, SPF and DMARC, sent from large mail platforms. It collects negative points for that, falls below the auto-learning threshold as legitimate mail, and the Bayes filter learns that such content is fine. Before the first repair the database held 174 spam messages against 139,600 supposedly legitimate ones. Auto-learning is now off for good, and only the Sent folders serve as the pattern for legitimate mail. The inbox does not qualify, because it contains exactly the spam that got through.

A default limit silently discarded almost all of the training

The default size limit of the Bayes database is 150,000 tokens; above it the filter removes the oldest entries, and the sync after a large training run is enough to trigger that. A database built from about 147,000 messages had 134,000 tokens right after training; the same amount of mail, with automatic expiry off, gives 5.3 million. More than 95 percent of the first training had been thrown away before the filter could use it.

A forgotten cron job switched the filter off every hour

Two old entries in root's crontab trained the filter from the Spam folders every hour. Because the database path was set globally, they wrote into the same database the service uses, and files created by root became unreadable for the service user. Daily statistics looked fine. Only the breakdown by hour showed nights in which the filter ran without Bayes for seven hours, and one day on which that affected half of all messages.

A false alarm that could have cost a rebuild of the whole setup

At one point about 95 percent of the messages in the mailboxes had no filter header at all, which looked like mass bypassing. The Postfix logs explained it: these were the internal system notifications, about 12,000 a day, which take a separate trusted path. All external mail, about 600 messages a day, went through the filter. A real but smaller gap surfaced at the same time: the client program passes messages larger than 500 KB without checking, and about half of the external messages without a header were above that limit, including spam with a 1.9 MB attachment.

The service configuration overrode the global one

The global configuration named amavis with ClamAV as the content filter. The services that accept mail from the internet had their own parameter pointing at SpamAssassin, which takes precedence, so incoming mail never passed amavis while the documentation assumed it did. That matters for the antivirus assumptions as much as for spam.