Updates & Maintenance

SpamFoo handles most updates automatically. ML models update in the background without interrupting mail processing, and client updates can be applied with a brief restart. This page covers how updates work and what maintenance tasks you may need to perform.

Model Updates

SpamFoo periodically checks for updated ML models from the Global API. When a new model is available:

  1. SpamFoo downloads the model to a temporary location
  2. The download is verified against a SHA-256 hash to ensure integrity
  3. SpamFoo waits for all active classification requests to complete
  4. The new model is loaded and classification resumes

This process is automatic and requires no administrator action. Model updates do not restart the service and cause no downtime. You can see the current model versions in the admin console under System > Status.

To trigger an immediate model check, go to System > Maintenance in the admin console and select the model update option.

Client Updates

Client updates contain new features, bug fixes, and performance improvements to the SpamFoo binary itself. How they are applied depends on your integration:

  • SmarterMail: SmarterMail checks for new SpamFoo client versions automatically, downloads them, and applies them. No manual action is needed.
  • Standalone installations: Download the latest release and replace the existing binary. Restart the SpamFoo service after replacing the files.
  • Docker: Pull the latest container image and restart the container.

Client version information is available in the admin console under System > Status.

Database Maintenance

SpamFoo's local SQLite database (admin.db) stores classification records, aggregate statistics, and overrides. Routine maintenance is handled automatically:

  • Data cleanup: Expired classification records and aggregates are purged daily based on retention settings.
  • WAL checkpointing: SQLite's write-ahead log is checkpointed periodically to keep the database file compact.

If the database has grown larger than expected, you can trigger a manual cleanup from the admin console under System > Maintenance. You can also reduce retention periods under Settings > Data Retention to limit future growth.

Backup

For a complete backup of SpamFoo's state, copy the following from the data directory:

  • admin.db (and admin.db-wal, admin.db-shm if present) for the SQLite database
  • personalization/ directory for per-user personalization data
  • etc/sf.key and etc/sf.installid for the license and installation identity

The trained-models/ directory does not need to be backed up, as models are re-downloaded automatically from the CDN.

Important: If you copy the SQLite database while SpamFoo is running, use sqlite3 admin.db ".backup backup.db" to get a consistent snapshot. Copying the file directly may produce a corrupted backup if a write is in progress.

Log Rotation

SpamFoo manages its own log rotation. Log files roll over daily and are automatically deleted after 30 days. Each file is capped at 50 MB. No external log rotation tool (such as logrotate) is needed, and configuring one may conflict with SpamFoo's built-in rotation.

Reinstallation

If you need to reinstall SpamFoo on a new server:

  1. Install SpamFoo on the new server (see Installation)
  2. Copy the sf.key, sf.installid, and admin.db files from the old server to the new data directory
  3. Copy the personalization/ directory to preserve per-user data
  4. Start SpamFoo. It will download the latest models automatically.

Personalization data is stored only on your server, so it cannot be recovered without a backup. If it is lost, users rebuild it over time as they make new corrections.