Спам-очередь в 10 000 писем: как мы добавили greylisting и Spamhaus к Postfix

Symantec в своём отчёте за первый квартал написали, что больше 60% всего почтового трафика в мире - это спам. Мы в это верим, потому что в конце апреля очередь Postfix у одного из наших клиентов не опускалась ниже восьми тысяч сообщений, а в пике - мы видели чуть больше десяти. SpamAssassin к тому моменту жевал каждое письмо по нескольку секунд, процессор на сервере сидел под девяносто процентов, и легитимная почта доходила с задержкой в двадцать-тридцать минут. Людям это нравилось примерно как дырявый зуб.

Проблема в архитектуре, которую мы строили несколько лет назад: принять всё, потом разобраться. Postfix принимал соединение, передавал письмо SpamAssassin, тот анализировал заголовки, тело, прогонял по байесу - и только тогда либо доставлял, либо откладывал в карантин. Это работало, пока спам не превратился в промышленный поток. Сейчас же каждое входящее соединение - это CPU-время, память, дисковая операция. Масштаб не тот.

Что не так с «анализируй всё»

SpamAssassin хорош. Точность у него приличная, байесовский классификатор дообучается. Но у него есть фундаментальная слабость: он работает с содержимым письма, которое уже принято. Значит, спамер уже потратил нашу полосу, загрузил наш процессор, занял место в очереди. При 10к сообщений в очереди это начинает ощущаться физически.

Решение очевидное: чем раньше отказываем мусору, тем меньше ресурсов тратим. Идеально - вообще на стадии SMTP-сессии, не принимая письмо.

Greylisting: три переменных и временный отказ

Первое, что мы добавили - greylisting через postgrey. Принцип простой до смешного: при первом соединении от незнакомой тройки (IP отправителя, адрес отправителя, адрес получателя) сервер отвечает временным отказом 451. Нормальный MTA подождёт и попробует снова через несколько минут - это стандарт RFC. Спамботы, которые шлют по разовому списку и не ретраятся, получают 451 и уходят навсегда.

Настройка под Debian/Ubuntu:

apt-get install postgrey

В main.cf добавляем в smtpd_recipient_restrictions:

check_policy_service inet:127.0.0.1:10023

Порог ретрая мы поставили в 5 минут - компромисс между задержкой для легитимной почты и фильтрацией. Первые несколько дней после включения было немного жалоб от пользователей, что письмо от нового контрагента пришло с задержкой. Объясняем, переживаем, смотрим статистику.

Результат через неделю: очередь Postfix упала с 8-10к до примерно 1.5-2к. Уже лучше, но не победа.

DNSBL: Spamhaus и отказ ещё на соединении

Второй слой - DNS-based blackhole lists. Spamhaus ведёт несколько списков: SBL (Spamhaus Block List - известные спам-источники), XBL (Exploits Block List - заражённые машины, прокси, ботнеты) и объединённый ZEN, который включает оба плюс ещё несколько. Мы добавили ZEN в smtpd_recipient_restrictions:

reject_rbl_client zen.spamhaus.org

Это работает ещё до greylisting, на стадии RCPT TO - если IP в Spamhaus ZEN, соединение рвётся с 554. Никаких ресурсов на анализ содержимого.

Отдельный момент - SORBS (Spam and Open Relay Blocking System). Мы подключили его как дополнительный список, но с осторожностью: у SORBS есть репутация агрессивных блокировок с ложными срабатываниями. Spamhaus ZEN ведёт себя аккуратнее.

Итоговая картина

После двух недель с обоими инструментами:

• Очередь опустилась до 200-400 сообщений в пике - это уже рабочий уровень.
• SpamAssassin теперь работает с тем, что реально дошло до тела письма. Нагрузка на процессор упала с 90% до 15-20%.
• Greylisting отбивает грубо 40-50% попыток от спамботов, которые не ретраятся.
• Spamhaus ZEN добавляет ещё 30-35% на уровне IP-репутации.

Вместе это даёт около 80% отсева ещё до того, как SpamAssassin вообще видит письмо. Остаток SpamAssassin обрабатывает нормально и без давления.

Есть один нюанс с greylisting, который мы не сразу учли: большие почтовые сервисы (корпоративные системы типа Exchange за NAT) могут ретраиться с разных IP в пуле, и тогда каждый ретрай выглядит как новая тройка. Мы добавили whitelist для нескольких доверенных диапазонов и настроили postgrey с опцией --delay=300 --max-age=35, чтобы белый список не рос бесконтрольно.

Что дальше

SpamAssassin с обученным байесом мы пока не трогаем - он делает свою работу на том, что до него доходит. В сопровождении почтовых систем мы теперь прописываем greylisting + DNSBL как обязательный минимум для любого Postfix-шлюза с нагрузкой больше нескольких сотен писем в день. До этого была рекомендация. После апреля - требование.

Один клиент спросил, не будет ли greylisting блокировать его партнёров. Честный ответ: временная задержка будет при первом письме. Потом - нет. Для 99% бизнес-переписки это незаметно. Для спамбота - конец пути.