SpamAssassin на Windows 11 / 2016+

---

Apache SpamAssassin многие годы остаётся де‑факто стандартом для фильтрации спама в Linux‑инфраструктуре, но на Windows его обычно вспоминают только как «что‑то экзотическое, если совсем прижало». Причина проста: в *nix всё решается systemd и cron, а под Windows админ часто вынужден собирать «велосипед» из ручного запуска spamd.exespamd.exe, планировщика заданий и самописных батников.

Репозиторий SpamAssassin-Windows-PS7 на GitHub как раз закрывает эту нишу: это набор скриптов на PowerShell 7, который превращает SpamAssassin на Windows 11 в управляемый сервис с ежедневным обновлением правил через Task Scheduler и нормально оформленной логикой запуска/остановки.

Дальше разберёмся, что даёт этот набор, как он устроен и как его встроить в существующую почтовую инфраструктуру на Windows.

---

Задача: сделать SpamAssassin «гражданином» Windows

Типичный сценарий использования SpamAssassin под Windows выглядит так:

• отдельный хост с портом 783/tcp под spamd;
• MTA (hMailServer, Exchange c транспортным агентом, постфиксный шлюз на Linux и т.д.) гоняет сообщения через spamc;
• админ как‑то запускает spamd.exe, следит, чтобы он не падал, и по ночам обновляет правила.

В Linux всё это делает пакетный менеджер (обновления) и systemd (сервис spamd). На Windows же без дополнительного кода нет:

• штатного сервиса spamd, который поднимется до логина пользователя и перезапустится после падения;
• предсказуемого механизма ежедневного обновления правил sa-update;
• централизованной конфигурации через один профиль/скрипт.

SpamAssassin-Windows-PS7 предлагает решение: поверх портированного SpamAssassin ставится PowerShell‑обвязка, которая:

• создаёт Windows‑сервис для spamd (через NSSM, собственный wrapper или sc.exe);
• разворачивает структуру каталогов и конфигов;
• подготавливает планировщик заданий для sa-update и, при необходимости, перезапуска сервиса после обновления.github+1

---

Архитектура PowerShell‑набора

Ключевая идея — вынести всё, что относится к инфраструктуре SpamAssassin под Windows, в набор PowerShell‑скриптов и модулей. Типично в таких проектах (и здесь не исключение) присутствуют несколько логических блоков: github

• Скрипт установки.
  • Проверяет наличие PowerShell 7.
  • Подтягивает бинарники SpamAssassin для Windows.
  • Создаёт каталог инсталляции (например, C:\SpamAssassin).
  • Готовит базовые конфиги local.cf, пути к правилам и логам.
• Создание системного сервиса.
  • Регистрирует сервис SpamAssassin в SCM Windows.
  • Задаёт командную строку запуска spamd (количество воркеров, порты, лог‑файл, параметры перезапуска).
  • Настраивает учётную запись, под которой работает сервис, и тип запуска (Automatic/Delayed).
• Интеграция с Task Scheduler.
  • Создаёт задание для ежедневного запуска sa-update.
  • Опционально добавляет триггер перезапуска сервиса после удачного обновления правил.
  • Настраивает логирование результатов обновления.
• Профиль/модуль PowerShell.
  • Определяет функции: установка, запуск/остановка, просмотр статуса, ручное обновление правил, диагностика.
  • Даёт администратору единый интерфейс: Start-SpamAssassinService, Invoke-SpamAssassinUpdate и т.п.

Такой подход делает SpamAssassin «первоклассным гражданином» Windows‑окружения: для админа всё выглядит и управляется так же, как любой другой сервис.

---

Практический сценарий: шлюз hMailServer + SpamAssassin на Windows 11

Представим типовую инфраструктуру небольшого офиса:

• один сервер Windows 11/Server 2022 с hMailServer;
• внешние MX на этом же сервере;
• требования фильтровать спам до попадания в ящики пользователей.

Как вписать сюда SpamAssassin с помощью рассматриваемого набора скриптов?

1. Разворачиваем SpamAssassin‑окружение.
   • Клонируем репозиторий SpamAssassin-Windows-PS7 с GitHub. github
   • Запускаем установочный скрипт из PowerShell 7 с повышенными правами.
   • Указываем путь установки, порты, параметры spamd.
2. Поднимаем сервис SpamAssassin.
   • Скрипт регистрирует Windows‑сервис и стартует его.
   • Проверяем, что spamd слушает нужный порт, и смотрим логи.
3. Включаем ежедневные обновления правил.
   • В планировщике появляется задача обновления правил.
   • При желании добавляем уведомление (например, через лог в Event Log или отправку отчёта по почте).
4. Настраиваем hMailServer.
   • В разделе антиспама указываем внешний фильтр на 127.0.0.1:783 (через spamc или транспортный агент). github
   • Вносим корректировки в пороговые значения спам‑оценки для локальной политики.
5. Добавляем мониторинг.
   • Через PowerShell‑функции и стандартные средства Windows можно быстро собрать минимальный мониторинг:
     • статус сервиса;
     • возраст базы правил;
     • объём лог‑файлов.

Результат: фильтрация спама реализована средствами, привычными администратору Windows, без необходимости держать отдельную Linux‑виртуалку только ради SpamAssassin.

---

Почему именно PowerShell 7 и чем это лучше bat‑скриптов

Выбор в пользу PowerShell 7, а не старого Windows PowerShell 5.1, неслучаен:

• Кроссплатформенность. Можно отлаживать и тестировать те же сценарии на Linux‑окружении, если часть инфраструктуры там. github
• Современный язык и экосистема. Модули, пакетный менеджер (Install-Module), нормальная работа с JSON, HTTP и т.д.
• Лучший контроль ошибок и логирования. По сравнению с batch‑скриптами PowerShell даёт более предсказуемый контроль потока и обработку ошибок.

Для админа это означает, что:

• инсталляция и обновление окружения превращаются в повторяемый, описанный кодом процесс (по сути, маленький IaC для конкретного сервиса);
• любой кастом — от смены каталога правил до интеграции с SIEM — можно реализовать на PowerShell, не вылезая в сторонние языки.

---

Заключение: когда имеет смысл использовать SpamAssassin‑Windows‑PS7

Набор скриптов SpamAssassin-Windows-PS7 будет особенно интересен в сценариях: github

• небольшие и средние компании, где вся почтовая инфраструктура крутится на Windows и не планируется отдельный Linux‑фильтр;
• тестовые стенды и лаборатории, где нужно быстро поднять SpamAssassin на рабочей станции администратора;
• гибридные инфраструктуры, где Linux‑шлюз пока не внедрён, но фильтрацию спама уже нужно «вчера».

Если вы привыкли к подходу «всё важное — под Linux», ставка на Windows‑порт SpamAssassin может показаться компромиссом. Но с появлением грамотной PowerShell‑оркестрации этот компромисс становится вполне рабочим решением, особенно в мире, где IT‑хаус часто начинается именно с одного Windows‑сервера.

---