Какие программы выбрать для антиспам-прокси перед почтовым сервером

Когда говорят «антиспамерский прокси», чаще всего имеют в виду почтовый шлюз, который стоит между интернетом и вашим почтовым сервером, принимает SMTP-сессию первым, проверяет письмо и только потом решает, пропускать письмо дальше, класть в карантин или отклонять на этапе SMTP. Термин старый, но сама задача никуда не делась. Просто в 2026 году такие продукты чаще называют Secure Email Gateway, Mail Gateway или spam filtering layer.

Главная ошибка при выборе здесь простая. Многие ищут «лучшую антиспам-программу», хотя выбирать надо не по громкому названию, а по архитектуре. Одной команде нужен конструктор с тонкой настройкой и высокой производительностью, другой нужен готовый шлюз с веб-интерфейсом и карантином для пользователей, а третья вообще живет на старом Exchange и хочет не идеал, а безболезненный переходный слой. Поэтому один и тот же продукт для одной компании будет отличным решением, а для другой станет вечной головной болью.

Что вообще считается антиспам-прокси

Нормальный антиспам-прокси работает до внутренней доставки письма. Входящее соединение сначала приходит на шлюз, дальше шлюз проверяет техническую подлинность отправителя, репутацию IP и домена, заголовки, тело письма, ссылки, вложения, эвристики и статистику, после чего либо отдает письмо дальше, либо помечает, либо режет. Такой подход описывал и SecurityLab, когда разбирал, как почтовые шлюзы реально фильтруют письма и почему даже хорошие фильтры все равно ошибаются.

Отсюда важный вывод. Антиспам-прокси не заменяет базовую почтовую гигиену домена. Без SPF, DKIM и DMARC почтовый шлюз может неплохо ловить мусор, но домен все равно останется слабым местом для подделки отправителя. Про эти механизмы нормально написано в разборе про DMARC. Для новой инсталляции отсутствие этих записей уже не нюанс, а красный флаг.

Если в компании нет SPF, DKIM, DMARC, обратной DNS-записи, понятной политики для исходящей почты и нормального учета доверенных отправителей, никакой «умный антиспам» не даст аккуратного результата. Получится дорогой фильтр поверх плохой почтовой дисциплины.

Какие архитектуры реально живут в проде

На практике есть три рабочих подхода.

• Конструктор из MTA и антиспам-движка. Самый типичный вариант сегодня, Rspamd плюс Postfix, реже OpenSMTPD или Haraka.
• Готовый шлюз-апплаенс. Устанавливается как отдельный сервер или виртуальная машина, дает интерфейс, карантин, отчеты и базовую эксплуатацию без долгой ручной сборки. Сюда попадают Proxmox Mail Gateway, MailCleaner, Scrollout F1.
• Классический SMTP-прокси старой школы. Жив до сих пор, но чаще встречается в наследуемых системах. Главный пример, ASSP.

Ниже разберем продукты именно в этой логике. Не по маркетингу, а по тому, как ими реально жить после установки.

Rspamd плюс Postfix, OpenSMTPD или Haraka: лучший вариант, если нужен свой конструктор

Rspamd в 2026 году выглядит самым здравым выбором для новой самостоятельной сборки. По сути это не «почтовый сервер», а независимый слой между MTA и интернетом. Движок умеет считать итоговый спам-балл по множеству символов, работать с SPF, DKIM, DMARC, ARC, серыми списками, rate limit, репутацией, байесом, fuzzy-хешами и модулями машинного обучения. Архитектурно Rspamd выглядит современнее старых связок на SpamAssassin, а интеграция через milter или HTTP делает сборку довольно чистой.

Сильная сторона Rspamd в том, что администратор получает именно платформу. Можно собрать жесткий корпоративный шлюз, можно поставить мягкую фильтрацию для малого бизнеса, можно кормить статистику из Redis, строить собственные правила, дописывать Lua-логику, интегрировать URL-проверки и антивирус, а можно начать почти с дефолтной конфигурации и постепенно ужесточать политику.

Но Rspamd не стоит идеализировать. Rspamd хорош, когда в команде есть человек, который понимает почтовые потоки, DNS, репутационные списки, нюансы DMARC-выравнивания и умеет смотреть не только в красивый веб-интерфейс, но и в логи. Если такой экспертизы нет, гибкость быстро превращается в хаос. Типичный провал выглядит так: Rspamd поставили, базовые пороги не подстроили, обратную связь от пользователей не собирают, исходящую почту через шлюз не прогоняют, а через месяц жалуются, что часть мусора проходит, а часть нормальных писем падает в карантин.

Кому подходит такой путь. Хостингам, мультидоменным площадкам, компаниям с Linux-экспертизой, тем, кто хочет реально контролировать фильтрацию, а не жить внутри чужого мастера настройки. Если нужен свой антиспам-прокси «по-взрослому», а не просто готовая коробка, Rspamd сегодня выглядит отправной точкой номер один.

Proxmox Mail Gateway: готовый шлюз для тех, кому важнее запуск и администрирование

Proxmox Mail Gateway хорош в другой логике. Это не набор кирпичей, а почти готовый почтовый шлюз. У продукта есть понятный веб-интерфейс, журнал сообщений, карантин, правила, кластеры, отчеты и нормальный сценарий развертывания как отдельной машины перед Exchange, Postfix или другой внутренней почтовой системой. Для небольшой или средней компании такой формат часто полезнее, чем ручная сборка на коленке.

Плюс Proxmox Mail Gateway в том, что система закрывает не только входящую, но и исходящую почту. На практике многие забывают именно про исходящий поток, а потом находят зараженную рабочую станцию уже после жалоб от внешних адресатов и падения репутации домена. В шлюзе такой сценарий контролировать проще.

Слабое место тоже есть. Под капотом у Proxmox Mail Gateway не какая-то тайная сверхтехнология, а довольно классический стек с Postfix, SpamAssassin и ClamAV. Для многих компаний такой состав вообще не проблема, наоборот, он понятен и предсказуем. Но тем, кто ждет максимально легкий и современный антиспам-движок, архитектура может показаться тяжеловатой. Еще один нюанс, с Proxmox удобно жить, пока правила и потоки укладываются в модель самого продукта. Когда компания хочет очень нестандартные политики, тонкие исключения и глубокую кастомизацию, ручной конструктор на Rspamd обычно дает больше свободы.

Где Proxmox особенно хорош. Малый и средний бизнес, IT-отделы без отдельного почтового инженера, компании с Exchange или смешанной инфраструктурой, те, кому нужен адекватный шлюз без долгой ручной сборки.

MailCleaner: удобен там, где нужен аппаратный стиль и самообслуживание пользователей

MailCleaner много лет живет в нише антиспам-шлюзов как appliance-подход. Сильная сторона продукта не в «волшебной детекции», а в удобной обертке вокруг типовой задачи. Администратор получает отдельный сервер-фильтр, пользователи получают карантин и понятную модель работы, а бизнес получает управляемый входной слой без необходимости собирать собственную систему из компонентов.

Если в компании много доменов, много пользователей и важна понятная процедура работы с карантином, MailCleaner выглядит вполне рационально. Особенно там, где пользователи привыкли сами смотреть сомнительные письма, а не писать в IT по каждому ложному срабатыванию.

Ограничения тоже очевидны. MailCleaner меньше похож на «платформу для инженера» и больше на готовый шлюз с заданной логикой. Когда нужна сложная кастомизация, специфические сценарии маршрутизации, нетривиальные интеграции или очень высокая прозрачность того, почему сработало конкретное правило, Rspamd-сборка обычно приятнее. Поэтому MailCleaner стоит выбирать не потому, что «он умнее всех», а потому, что он упрощает эксплуатацию конкретного типа инфраструктуры.

ASSP: старый добрый SMTP-прокси, который до сих пор жив, но уже не первый выбор

ASSP, Anti-Spam SMTP Proxy, относится к старой школе. По смыслу продукт очень честный. Перед вами именно SMTP-прокси со множеством антиспам-механизмов, а не абстрактный «почтовый ИИ-комбайн». У него есть автодоверие, байес, greylisting, DNSBL, URIBL, SPF, блокировка вложений и другие знакомые механики. Для наследуемой среды или специфического старого контура ASSP до сих пор может быть рабочим выбором.

Но для новой инсталляции ASSP уже не выглядит оптимальным стартом. Проблема не в том, что продукт бесполезен, а в возрасте архитектуры, общей эргономике и том, что современный рынок антиспама ушел в сторону более удобных и производительных решений. Если в компании ASSP уже стоит, администраторы понимают его поведение и миграция пока не окупается, ломать все только ради модного стека не надо. Если же система строится с нуля, обычно логичнее смотреть либо в сторону Rspamd, либо в сторону готового шлюза.

Scrollout F1: быстрый старт для маленьких площадок, но без особой роскоши

Scrollout F1 привлекает простой идеей. Это готовый почтовый шлюз, который можно поставить перед существующим сервером и быстро получить базовую защиту от спама и вредоносных вложений. Для маленькой компании, филиала, лаборатории или тестового полигона такой вариант иногда очень кстати.

Слабые стороны у такого подхода предсказуемы. Чем проще продукт позиционируется, тем быстрее вы упираетесь в потолок, когда начинаются сложные политики, много исключений, плотная интеграция с внутренними системами и требования к аккуратному разбору ложных срабатываний. Scrollout F1 я бы воспринимал не как стратегический антиспам-контур для сложного бизнеса, а как короткий путь к рабочему минимальному шлюзу там, где нет сил и смысла собирать более тяжелую конструкцию.

SpamAssassin и Amavis: не мертвые, но для новых проектов уже скорее вчерашний день

Про SpamAssassin говорить «устарел и не нужен» было бы слишком грубо. Проект жив, документация актуальна, а многие шлюзы и дистрибутивы до сих пор используют его как часть реального продакшена. Проблема не в самом факте существования, а в том, что для новых установок в 2026 году связка SpamAssassin плюс Amavis обычно оказывается не самой удобной отправной точкой.

У старой связки больше клея, больше отдельных компонентов, больше шансов получить тяжеловесную эксплуатацию и меньше удовольствия от последующей настройки. Поэтому правило простое. Если существующая система на SpamAssassin работает, команда ее знает, письма фильтруются приемлемо, а миграция может поломать больше, чем починить, можно жить дальше. Если проект новый, нет никакого смысла бежать именно в старый стек только потому, что по нему больше древних how-to.

Сравнение продуктов без маркетингового тумана

Где выбор ломается на практике

Проблема антиспам-прокси редко упирается в сам движок. Чаще все ломается в мелочах.

• Слишком рано включили жесткий reject и начали терять легитимные письма.
• Не включили исходящую фильтрацию и пропустили зараженный хост внутри сети.
• Не завели процесс обучения и обратной связи от пользователей.
• Оставили дефолтные пороги, хотя у компании свой профиль переписки.
• Забыли про SPF, DKIM, DMARC, PTR, TLS и нормальную репутацию исходящего домена.
• Перепутали антиспам с DLP и начали пытаться одним шлюзом решить все почтовые риски сразу.

Особенно часто компании недооценивают ложные срабатывания. На бумаге все любят фразу «блокировать на SMTP сразу», но в живой эксплуатации резкий reject без аккуратного периода наблюдения легко превращается в конфликт с бизнесом. Для первых недель почти всегда лучше карантин или добавление заголовков, а не безусловный отказ.

Какой вариант я бы выбрал в разных сценариях

Если проект новый и команда умеет работать с Linux, DNS и почтой, я бы смотрел в сторону Rspamd плюс Postfix. Такой стек дольше собирается, зато потом дает лучший контроль и меньше ощущения, что вас держат внутри чужой логики.

Если нужен не конструктор, а рабочий шлюз с быстрым запуском и понятным интерфейсом, Proxmox Mail Gateway выглядит самым практичным вариантом. Для многих компаний он закрывает 80 процентов потребностей без избыточной инженерной романтики.

Если важен именно appliance-стиль с понятным пользовательским карантином и мультидоменной эксплуатацией, MailCleaner тоже выглядит разумно. Просто не стоит ждать от него инженерной свободы уровня Rspamd.

Если инфраструктура старая, живая и завязана на ASSP или SpamAssassin, не надо устраивать миграцию только ради модного слова. Сначала посчитайте реальную цену изменений, объем ложных срабатываний, нагрузку на сопровождение и риски простоя.

Минимальный чек-лист перед запуском

• Поставьте шлюз отдельным узлом, а не внутрь того же сервера, где живет основная почта.
• Сначала включите мягкий режим, карантин или маркировку, потом ужесточайте политику.
• Прогоняйте через шлюз не только входящую, но и исходящую почту.
• Настройте SPF, DKIM, DMARC и обратную DNS-запись до ввода в прод.
• Собирайте обратную связь от пользователей по false positive и false negative.
• Следите за журналами, очередями, временем ответа DNS и обновлением сигнатур.

Юридическая часть тоже важна. При обработке корпоративной почты надо соблюдать требования законодательства, в том числе российского, внутренние политики компании, правила защиты персональных данных и тайны переписки. Антиспам-прокси нельзя превращать в скрытый инструмент несанкционированного перехвата, а сам шлюз нельзя оставлять в режиме открытого релея или с небезопасным доступом к карантину и журналам.

Итог

Если убрать маркетинг, картина простая. Лучший «продукт для создания антиспамерского прокси» не существует сам по себе. Для новой самостоятельной сборки в 2026 году самым сильным вариантом выглядит Rspamd. Для быстрого и предсказуемого корпоративного запуска, Proxmox Mail Gateway. Для сценариев с appliance-подходом и пользовательским карантином, MailCleaner. ASSP и старые связки на SpamAssassin остаются рабочими, но сегодня это скорее история про легаси, а не про лучший старт с нуля.

Самый практичный совет тут такой. Сначала выберите архитектуру и эксплуатационную модель, потом продукт. Не наоборот. И обязательно проверьте, что у компании в порядке доменная аутентификация, исходящая почта и процесс разбора ложных срабатываний. Без этой базы любой антиспам-прокси быстро превращается из защиты в еще один источник хаоса.

FAQ по программам для антиспам-прокси