Fixing Email and Spam on the Server: What We Repaired Today

Today was a long maintenance day on the live mopar1973man.com mail server. The main problem was a flood of spam hitting one of my mailboxes. While chasing it I found and fixed several other things, and I'm writing them down in case it helps someone else running their own mail server.

1. Spam filtering wasn't working properly

SpamAssassin was tagging most incoming mail with a "URIBL_BLOCKED" warning. That means the server couldn't use the blacklist lookups it depends on, because the public DNS resolver it was using was being rate-limited or refused. Real scoring was being skipped.

The fix: I pointed the server's DNS lookups at its own local caching resolver first, with the old resolver as a fallback. Then I restarted the SpamAssassin daemon so it picked up the change. Lookups work again, and spam is scored properly.

I left the spam score thresholds alone for now. Raising them tends to catch real mail, and I'd rather fix the underlying problems first.

2. Someone was guessing mail passwords

The firewall logs showed an address hammering the SMTP login for one of my support mailboxes, trying password after password. My firewall (CSF/LFD) was set to tolerate far too many failed attempts before blocking.

The fix:

• I lowered the failed SMTP login limit from 100 to 5.

• I blocked the offending address.

If you run CSF, check LF_SMTPAUTH. A high number gives an attacker a lot of free guesses.

3. An old "temporary" allow rule was still hanging around

While in the firewall I found an address I had manually allowed back in June. It was in both the firewall allow list and the mail panel's trusted networks. I no longer had a reason for it, and a forgotten allow rule is a hole in your defenses. I removed it from both places.

4. Email authentication: SPF, DKIM and DMARC

I also started making the domain's email authentication airtight. Without it, anyone can forge mail that looks like it came from you.

• DMARC: I published a DMARC record and verified it. It started in monitoring mode, and I've since moved it to a quarantine policy applied to 25% of failing mail. The plan is to raise that to 100%, then to full reject once the reports come back clean.

• Testing: I sent a message to Gmail and checked "Show original". SPF, DKIM and DMARC all passed.

• DNS location: The domain's public DNS is hosted at LiquidWeb, not on the server itself, so these records are edited in their portal.

Still on the to-do list

• Remove the DKIM "testing" flag now that authentication is passing.

• Move SPF from a soft fail to a hard fail once the DMARC reports look clean.

• Whitelist the real senders I do business with, so they never get caught by the filter.

• Block the domains that only ever send spam.

• Rotate the spam filter's database password.

• Unsubscribe from the legitimate newsletters site by site, and clean out the mailbox after a backup.

Takeaways

1. Check the logs when something is odd. The blocked-lookup warnings were the real clue behind the spam problem.

2. Tighten your failed-login limits. The defaults are often too generous.

3. Audit your allow lists regularly. Old exceptions pile up.

4. Set up DMARC, but ramp it up gradually and watch the reports before you go to a strict policy.

I'll post a follow-up when the DMARC policy reaches full enforcement.