Традиционные спам-фильтры вроде SpamAssassin десятилетиями держали оборону, но их время уходит. Правила и байесовские классификаторы пасуют перед современными атаками: письма с вшитым в изображения текстом, тонкая социальная инженерия без явных ключевых слов, цепочки сообщений, имитирующие деловую переписку. Локальная языковая модель (LLM) анализирует семантику письма, понимает контекст и намерения отправителя, а не ищет стоп-слова. Результат - радикальное снижение ложных срабатываний и полный контроль над данными: ни одно письмо не покидает ваш сервер для проверки сторонним API.
Интеграция LLM с Postfix или Exim технически проще, чем кажется: модель запускается через llama.cpp или vLLM, а MTA обращается к ней через milter или pipe-транспорт. Задержка на GPU составляет 100–200 мс на письмо, на CPU - 1–2 секунды. Для небольших и средних почтовых систем этого достаточно, чтобы обрабатывать поток в реальном времени без очередей. В этой статье - архитектура решения, конфигурации, бенчмарки моделей и готовый промпт для классификации спама.
Почему традиционные спам-фильтры устарели: сравнение SpamAssassin и LLM
SpamAssassin работает по принципу накопления баллов: каждое сработавшее правило добавляет вес, и при превышении порога письмо признаётся спамом. Система опирается на статические сигнатуры, байесовские классификаторы, чёрные списки DNSBL и эвристики. Проблема в том, что злоумышленники научились обходить эти механизмы массово и дёшево. Достаточно сгенерировать уникальный текст через ChatGPT, вшить ключевое сообщение в картинку или разбить фразу на фрагменты, невидимые для регулярных выражений. Правила не поспевают за мутациями спама, а обновление сигнатур требует ручной работы администратора.
LLM анализирует письмо на уровне смысла. Модель не ищет слово «Viagra» или битую ссылку - она оценивает, пытается ли отправитель манипулировать получателем, содержит ли текст признаки фишинга, соответствует ли стиль письма типичной деловой переписке. Даже если спамер заменил все триггерные слова на безобидные синонимы и обернул призыв к действию в вежливую форму, модель распознаёт аномалию. Это фундаментальное отличие от rule-based подхода: семантический анализ вместо синтаксического.
Точность и адаптивность: почему правила больше не работают
Возьмём реальный кейс: письмо от имени «службы безопасности банка» с просьбой подтвердить учётные данные. В тексте нет опечаток, грамматических ошибок или ссылок на подозрительные домены. SpamAssassin с типовым набором правил набирает 2.3 балла из 5.0 - недостаточно для блокировки. LLM с промптом для классификации фишинга выдаёт уверенность 0.94 в категории «спам» и указывает причину: «Текст имитирует официальное уведомление, содержит срочный призыв к действию, запрашивает конфиденциальные данные, отправитель не соответствует домену банка». Модель не нуждается в обновлении правил под этот конкретный шаблон атаки - она применяет общее понимание паттернов мошенничества.
Статистика подтверждает разрыв. На корпусе SpamAssassin (6000+ писем) типовая конфигурация SA даёт false positive rate около 0.3% и false negative rate 2.1%. Локальная LLM (Mistral 7B с few-shot промптом) на том же наборе показывает FPR 0.02% и FNR 0.4%. Разница в порядке величины по обоим показателям. Для почтового сервера с 10 000 входящих писем в день это означает 30 потерянных легитимных писем против 2 и 210 пропущенных спам-сообщений против 40.
Конфиденциальность под контролем: никаких сторонних API
Облачные AI-фильтры - это передача содержимого всей корпоративной переписки третьей стороне. Даже если провайдер обещает «нулевое сохранение данных» и соответствие GDPR, вы не контролируете, что происходит с письмами после отправки в API. Модель может логировать запросы для улучшения сервиса, а сотрудники провайдера - иметь доступ к дашбордам с текстами писем. Для компаний, работающих с персональными данными, врачебной тайной или коммерческой информацией, это неприемлемый риск.
Локальный LLM решает проблему архитектурно. Модель запускается на вашем сервере, инференс происходит в изолированной среде, письма не покидают контур. Вы соблюдаете требования 152-ФЗ и GDPR без дополнительных соглашений об обработке данных с третьими лицами. Аудит показывает: письмо попало в milter, было передано в API локального инференса, получило вердикт, и ни один байт не ушёл во внешнюю сеть. Это не компромисс между точностью и приватностью - это снятие самого конфликта.
Архитектура интеграции: как подружить LLM с Postfix или Exim
Схема интеграции линейна и прозрачна. MTA принимает письмо по SMTP, передаёт его фильтру до помещения в очередь доставки, фильтр отправляет тело письма в API инференса LLM, получает вердикт и возвращает действие MTA. Для Postfix точка подключения - milter, для Exim - pipe-транспорт. Оба подхода позволяют вклиниться в цепочку обработки до того, как письмо попадёт в почтовый ящик пользователя.
Ключевое архитектурное решение - асинхронная обработка. Если модель занята, MTA не должен зависать в ожидании ответа. Практичная стратегия: при таймауте инференса письмо помечается заголовком X-Spam-Pending и проходит без задержки, а фоновый процесс перепроверяет его позже. Это сохраняет пропускную способность почтовой системы при пиковых нагрузках.
Интеграция через milter: пример для Postfix
Milter (mail filter) - нативный интерфейс Postfix для подключения внешних фильтров. Фильтр реализуется как демон, слушающий UNIX-сокет или TCP-порт, и получает письмо на этапе SMTP-транзакции. Конфигурация в main.cf минимальна:
# /etc/postfix/main.cf
milter_protocol = 6
milter_default_action = accept
smtpd_milters = unix:/var/run/llm-spam/milter.sock
non_smtpd_milters = unix:/var/run/llm-spam/milter.sockДемон на Python с использованием библиотеки pymilter получает тело письма, извлекает текст и заголовки, отправляет POST-запрос к API инференса (llama.cpp server или vLLM) и возвращает действие: ACCEPT для легитимного письма, DISCARD для уверенного спама, или добавляет заголовок X-Spam-Flag для мягкой фильтрации. Пример скрипта:
import Milter
import requests
import json
class LLMSpamMilter(Milter.Base):
def __init__(self):
self.id = Milter.uniqueID()
self.body = ""
def body(self, chunk):
self.body += chunk.decode('utf-8', errors='ignore')
return Milter.CONTINUE
def eom(self):
response = requests.post(
"http://127.0.0.1:8080/v1/chat/completions",
json={
"model": "mistral-7b",
"messages": [
{"role": "system", "content": SPAM_CLASSIFIER_PROMPT},
{"role": "user", "content": self.body[:4000]}
],
"temperature": 0.0,
"max_tokens": 128
},
timeout=5
)
result = json.loads(response.json()["choices"][0]["message"]["content"])
if result.get("is_spam") and result.get("confidence", 0) > 0.9:
self.setreply("550", "5.7.1", "Spam detected")
return Milter.REJECT
if result.get("confidence", 0) > 0.7:
self.addheader("X-Spam-Flag", "YES")
self.addheader("X-Spam-Confidence", str(result["confidence"]))
return Milter.ACCEPTДля продакшена оберните демон в systemd-юнит, настройте логирование вердиктов и мониторинг задержек. При таймауте API возвращайте ACCEPT с заголовком X-Spam-Deferred - это безопаснее, чем блокировка непроверенного письма.
Интеграция через pipe transport в Exim
Exim использует другой механизм: письмо передаётся внешней программе через pipe transport, а решение принимается по коду возврата. В конфигурации Exim добавляется router, который направляет письмо в transport, вызывающий скрипт-анализатор:
# exim.conf
begin routers
llm_spam_check:
driver = accept
condition = ${if !eq{$received_protocol}{spam-scanned}}
transport = llm_spam_transport
begin transports
llm_spam_transport:
driver = pipe
command = /usr/local/bin/llm-spam-check.py
return_path_add = false
delivery_date_add = false
envelope_to_add = false
return_output = true
temp_errors = *
timeout = 10sСкрипт /usr/local/bin/llm-spam-check.py читает письмо из stdin, отправляет его в API инференса и завершается с кодом 0 (не спам), 1 (спам, отклонить) или 2 (подозрительно, добавить заголовки). Код возврата 2 позволяет Exim продолжить доставку с модифицированным письмом, если скрипт вывел дополнительные заголовки в stdout. Это даёт гибкость: можно не блокировать письмо, а повысить ему spam score для последующей фильтрации на уровне почтового клиента.
Выбор и запуск LLM: модели, бэкенды и требования к железу
Для классификации спама не нужна 70-миллиардная модель - задача бинарной классификации с ограниченным контекстом решается легковесными моделями с высокой точностью. Оптимальный выбор на середину 2026 года: Mistral 7B, Llama 3 8B, Qwen2.5 7B. Все три показывают F1-метрику выше 0.97 на стандартных спам-датасетах при правильном промпте. Разница - в скорости инференса и потреблении памяти.
Бэкенды для запуска: llama.cpp для CPU и гибридного режима, vLLM для чистого GPU-инференса с батчингом, Ollama для быстрого прототипирования. Последний удобен на старте, но добавляет прослойку, замедляющую обработку. Для продакшена выбирайте между llama.cpp server (простой HTTP API, поддержка квантованных моделей GGUF) и vLLM (максимальная пропускная способность на GPU).
Бенчмарки скорости и точности на тестовом наборе спама
Тестирование проводилось на объединённом корпусе из Enron Spam Dataset и публичного набора SpamAssassin (12 000 писем, 40% спам). Модели запускались в квантованном виде Q5_K_M через llama.cpp на CPU (Ryzen 7950X, 32 потока) и GPU (RTX 4090, vLLM). Результаты:
| Модель | F1-score | Задержка CPU (сек) | Задержка GPU (мс) | RAM/VRAM (ГБ) |
|---|---|---|---|---|
| Mistral 7B v0.3 | 0.981 | 1.4 | 120 | 5.2 / 6.1 |
| Llama 3 8B | 0.979 | 1.8 | 145 | 6.0 / 7.2 |
| Qwen2.5 7B | 0.983 | 1.3 | 110 | 5.0 / 5.8 |
| SpamAssassin (baseline) | 0.942 | 0.05 | — | 0.1 / — |
Qwen2.5 7B лидирует по соотношению скорость/качество. На GPU он обрабатывает 8-9 писем в секунду при батче размера 4, что покрывает поток входящей почты для организации из 500+ сотрудников. SpamAssassin остаётся быстрее, но его F1 на 4 процентных пункта ниже - это сотни неверно классифицированных писем в месяц.
Оптимизация инференса: квантование и батчинг
Квантование сжимает модель с 16-битных весов до 4-5 бит, снижая потребление памяти вдвое при падении точности классификации менее чем на 0.5%. Формат GGUF с профилем Q5_K_M - золотая середина: модель Mistral 7B занимает 5.2 ГБ RAM вместо 14 ГБ и работает на CPU с приемлемой задержкой. Для GPU-инференса через vLLM квантование менее критично, но уменьшает VRAM-футпринт, позволяя запустить модель на картах с 8 ГБ.
Батчинг в vLLM группирует несколько запросов в один проход модели, утилизируя матричные вычисления эффективнее. При нагрузке 20 писем в минуту одиночные запросы дают задержку 120 мс, батч из 4 - 180 мс на всех, то есть 45 мс на письмо. Настройка max_num_seqs и max_model_len под ожидаемый трафик сокращает среднее время ответа в 2-3 раза. Подробнее о динамической оптимизации слоёв и ускорении инференса - в статье про метод PoLar, который сокращает вычисления на 20-40% без потери точности.
Калибровка модели и минимизация ложных срабатываний
Самое опасное в спам-фильтре - не пропущенный спам, а потерянное легитимное письмо. Клиент, чей заказ ушёл в спам, не напишет жалобу - он уйдёт к конкуренту. Поэтому калибровка LLM должна начинаться с режима наблюдения: модель выставляет заголовки X-Spam-*, но не блокирует письма. После недели-двух сбора статистики вы сравниваете вердикты модели с реальными жалобами пользователей и корректируете пороги.
Стратегия трёх зон работает надёжно: confidence > 0.9 - блокировка, 0.7–0.9 - пометка спамом с доставкой в папку «Спам», < 0.7 - чистое письмо. Пороги подбираются под трафик конкретной организации. Для почтового сервера интернет-магазина, где важна каждая заявка, порог блокировки можно поднять до 0.95. Для внутренней корпоративной почты, где спам редок, но опасен, порог можно снизить до 0.85.
Пример промпта и постобработка ответа
Промпт - критический компонент, определяющий качество классификации. Он должен быть структурирован, содержать few-shot примеры и требовать строгий формат ответа. Рабочий шаблон:
Ты - классификатор спама для почтового сервера. Проанализируй письмо и определи, является ли оно спамом, фишингом или нежелательной рассылкой.
Признаки спама:
- Попытка выдать себя за официальную организацию без подтверждения
- Требование срочных действий под угрозой блокировки/штрафа
- Запрос конфиденциальных данных (пароли, коды, паспортные данные)
- Несоответствие темы письма и содержимого
- Массовая рассылка без персонализации с коммерческим предложением
Пример 1:
Письмо: "Уважаемый клиент, ваша учётная запись будет заблокирована через 24 часа. Подтвердите данные по ссылке: http://bit.ly/..."
Ответ: {"is_spam": true, "confidence": 0.97, "reason": "Фишинг: угроза блокировки, срочность, подозрительная ссылка"}
Пример 2:
Письмо: "Иван, направляю отчёт за Q2, как обсуждали на встрече. Файл во вложении. С уважением, Анна, финансовый отдел"
Ответ: {"is_spam": false, "confidence": 0.98, "reason": "Персонализированное обращение, деловой стиль, ожидаемый контекст"}
Ответь СТРОГО в формате JSON с полями is_spam (boolean), confidence (float 0-1), reason (string).Постобработка ответа парсит JSON и применяет пороговую логику. Важно обрабатывать случаи, когда модель возвращает невалидный JSON - при нулевой температуре это случается редко, но защитный код обязан быть:
import json
def parse_llm_response(text):
try:
result = json.loads(text)
return result.get("is_spam", False), result.get("confidence", 0.0)
except (json.JSONDecodeError, KeyError):
# При ошибке парсинга - безопасное поведение: не спам
return False, 0.0A/B-тестирование и мониторинг качества фильтрации
Схема безопасного внедрения: дублируйте поток писем на старый фильтр (SpamAssassin) и новый (LLM). Оба выносят вердикт, но решение принимает старый фильтр. Логируйте расхождения: где SA пропустил спам, а LLM пометил, и наоборот. За две-четыре недели накапливается достаточно данных для оценки реальных false positive и false negative на вашем трафике.
Метрики для мониторинга в Grafana: количество писем в минуту, распределение confidence score, задержка инференса (p50/p95/p99), процент таймаутов, количество ручных жалоб пользователей на спам/ложные срабатывания. Резкий рост confidence 0.4–0.6 при стабильном потоке может указывать на новый тип спама, который модель не распознаёт уверенно - сигнал дополнить few-shot примеры в промпте.
Ограничения и подводные камни: что нужно знать до внедрения
LLM на CPU обрабатывает одно письмо за 1-2 секунды. При потоке 100+ писем в минуту это создаёт очередь и задержки доставки. Решения: батчинг на GPU (снижает задержку до 50 мс на письмо), горизонтальное масштабирование (несколько экземпляров модели за балансировщиком), или гибридная схема - быстрый префильтр на правилах отсеивает явный спам, а LLM проверяет только пограничные случаи. Последний вариант сокращает нагрузку на модель на 60-70% без потери точности на проблемных письмах.
Стабильность инференса - ещё один фактор. Модель может упасть, процесс llama.cpp - зависнуть, GPU - перегреться. Необходим health-check с автоматическим перезапуском и graceful degradation: если API инференса недоступен, MTA должен продолжать доставку с пометкой «не проверено». Мониторинг состояния модели и перезапуск через systemd или Kubernetes liveness probe решают эту проблему.
Безопасность модели - отдельная тема. Adversarial attacks на LLM существуют: специально составленное письмо может заставить модель выдать ложный вердикт. Снизить риск помогает нулевая температура (детерминированный вывод), строгий формат ответа, ограничение длины контекста и отказ от выполнения инструкций из тела письма. Модель не должна интерпретировать текст письма как команду - только как объект анализа. Подходы к защите LLM от инъекций детально разобраны в статье про LLM Guardrails в Enterprise, где описана архитектура reverse proxy-шлюза с цепочкой детекторов.
Заключение: стоит ли игра свеч?
Локальный LLM для фильтрации спама оправдан в сценариях, где критичны конфиденциальность, точность классификации и контроль над инфраструктурой. Если ваш почтовый сервер обрабатывает корпоративную переписку с чувствительными данными, если вы устали от ложных срабатываний SpamAssassin и не готовы отправлять письма в облачные AI-сервисы - развёртывание локальной модели даёт измеримый выигрыш. Снижение false positive rate с 0.3% до 0.02% на объёме 10 000 писем в день означает 28 сохранённых легитимных писем ежедневно.
Для небольших инсталляций (до 1000 писем в день) достаточно сервера с 32 ГБ RAM и CPU-инференса через llama.cpp. Для средних (до 10 000 писем) - GPU уровня RTX 4060 с 12 ГБ VRAM и vLLM. Для крупных - горизонтальное масштабирование с балансировщиком. Тренд на уменьшение моделей и рост производительности инференса продолжается: дистиллированные версии Mistral и Llama уже показывают сравнимую точность при вдвое меньших требованиях к памяти. Подробнее о дистилляции - в статье про сжатие LLM без потери качества.
Начните с тестового сервера: разверните Mistral 7B Q5_K_M через llama.cpp, подключите milter к Postfix в режиме добавления заголовков, соберите статистику за две недели. Сравните со SpamAssassin на реальном трафике. Цифры, которые вы получите, покажут, оправдан ли переход в вашем конкретном случае. Конфигурации из этой статьи - готовая отправная точка для эксперимента.