Спам-ловушки в базе: как распознать pristine и recycled traps и вычистить список без потерь
Спам-ловушку нельзя провалидировать — она принимает почту и отвечает 250 OK, как живой ящик. Разбираем, чем pristine отличается от recycled, почему сервисы верификации их не видят, и как вычислить заражённые сегменты по косвенным следам до того, как один хит уронит ваш IP в Spamhaus SBL.
EvilMail Team15 июля 2026 г.13 мин чтения
Рассылка на 80 000 адресов. Контент вычитан, ссылки чистые, SPF/DKIM/DMARC сходятся, отправляющий IP грелся три недели. Через сутки после старта MX-серверы начинают отбивать письма кодом 550, доставляемость в Gmail проваливается в промоушен и дальше в спам, а dig показывает ваш IP в Spamhaus SBL. Вы перечитываете тему письма в поисках стоп-слов — и не там ищете. Проблема не в контенте. В списке был один адрес, который никогда не принадлежал человеку, — pristine-ловушка. Одного попадания хватило.
Главное надо понять сразу, потому что вокруг этого строится всё остальное: спам-ловушка принимает почту и отвечает `250 OK`, ровно как живой ящик. Она обязана это делать — иначе не соберёт доказательство, что вы шлёте на адреса, которые не запрашивали писем. Поэтому её нельзя «провалидировать»: любая SMTP-проверка существования адреса вернёт «ящик есть». Ловушки не находят прямым способом. Их вычисляют по косвенным следам и вычищают до рассылки, а не после листинга.
Две породы ловушек: pristine и recycled — это два разных диагноза
Pristine (чистые) ловушки — адреса, которые никогда не были почтовым ящиком реального пользователя. Их создают антиспам-команды и провайдеры блок-листов, затем сеют там, где живой человек их не наберёт руками: в скрытых полях на honeypot-страницах, в записях whois, в невидимом тексте на форумах, в дампах, которые заведомо утекут к парсерам. Логика железная: попадание pristine-ловушки в вашу базу означает ровно одно — вы её
спарсили или купили
, потому что легитимным путём этот адрес получить неоткуда. Ведут такие сети Spamhaus, SpamCop, Abusix и антиспам-подразделения крупных провайдеров. Наказание непропорционально жёсткое, и это намеренно: одного хита достаточно, чтобы уронить IP или целый
/24
в SBL.
Recycled (переработанные) ловушки — бывшие реальные ящики. Пользователь завёл почту, годами получал письма, потом бросил адрес. Провайдер какое-то время держит его в отказе 550 NXUSER (обычно 6–12 месяцев), а затем реактивирует — но уже как ловушку. Попадание recycled-ловушки не говорит, что база куплена. Оно говорит, что у вас гниёт гигиена: вы продолжаете слать на адрес, который уже несколько месяцев отдаёт hard bounce, и просто не обрабатываете отказы.
Отдельный подвид — typo-ловушки: домены-опечатки gmial.com, hotmial.com, yaho.com, outlok.com, скупленные ловцами именно для отлова неаккуратного сбора адресов. Человек ошибся на форме, вы не проверили ввод — и отправили письмо в ловушку.
Вывод, из которого дальше всё следует: pristine лечится источником адресов, recycled — дисциплиной обработки отказов. Это разные болезни, и таблетка от одной не помогает от другой.
Почему верификация списка их не ловит
Механика та же, что описана во вступлении: ловушка принимает соединение, MX отвечает 250, RCPT-проверка проходит. Валидатор рапортует «адрес валиден и существует» — и он формально прав. Ни один сервис верификации не может отличить принимающую ловушку от принимающего живого ящика, потому что на уровне SMTP они неотличимы.
Хуже того, агрессивная верификация вредит сама по себе. Когда валидатор прощупывает базу через RCPT TO без отправки DATA, он устанавливает соединения с MX по всему списку — включая honeypot-адреса. Некоторые провайдеры считают такое зондирование самостоятельным негативным сигналом и пессимизируют репутацию зондирующего IP. Вы платите за то, чтобы испачкать собственный отправляющий узел.
Есть и маркетинговая ловушка в самом слове «list cleaning». Такие сервисы честно убирают синтаксический мусор (user@@gmail..com), несуществующие домены без MX и явные дубликаты. Но отдать вам список ловушек они не могут по определению: расположение pristine-сетей — коммерческая тайна блок-листов, и любой сервис, публично помечающий адрес как ловушку, тут же обесценил бы этот адрес для всей индустрии. Реально снижают риск только вендоры с собственной сетью seed-ловушек (Validity, репутационные данные Kickbox по домену) — и то вероятностно, по агрегированной репутации, а не поадресно. Прямого детектора спам-ловушек не существует. Это фундамент, а не оговорка мелким шрифтом.
Косвенные сигналы: вычисляем заражённые сегменты
Раз прямой проверки нет, работаем по следам. Четыре маркера риска, по которым сегмент нужно отправлять в карантин, а не в рассылку:
Источник. Купленные, спарсенные, «партнёрские» и co-reg базы. Любой адрес, попавший к вам без явного действия его владельца, — кандидат в pristine-хит.
Дата импорта. Большие разовые заливки без истории опт-ина. Сегмент, появившийся одним INSERT на 40 000 строк в прошлый вторник, статистически опаснее адресов, копившихся по одному через форму.
История отказов. Адреса, которые начали отдавать 550/NXUSER. Это прямой предвестник recycled-ловушки.
Нулевой engagement. Ни одного открытия и клика за 6–12 месяцев. Классический маркер recycled: живой человек ушёл, ящик готовят к реактивации.
Чтобы это было воспроизводимо, гигиена должна жить в схеме БД, а не в голове маркетолога. Держите у каждого контакта поля source, imported_at, last_open_at, last_click_at, hard_bounced_at, consent_type (single/double/COI) и status (active/quarantine/suppressed). Тогда карантинный сегмент выражается одним запросом: импорт без подтверждённого опт-ина, плюс ноль engagement, плюс отсутствие явного согласия.
sql
-- Кандидаты в карантин: импорт без опт-ина и без активности
SELECT id, email, source, imported_at
FROM contacts
WHERE consent_type = 'single'
AND source IN ('import','purchased','partner','coreg')
AND last_open_at IS NULL
AND last_click_at IS NULL
AND imported_at < now() - interval '90 days'
AND status = 'active';
-- Результат этого запроса НЕ рассылается, а переводится в status='quarantine'
Читаем bounce-логи: recycled-ловушка начинается с 550
Recycled-ловушка всегда проходит фазу hard bounce, прежде чем стать ловушкой. Кто ловит и подавляет первый же 550, тот физически не докатывается до реактивации адреса. Поэтому обработка отказов — это не уборка после рассылки, а главный барьер против recycled-traps.
Различайте enhanced status codes по RFC 3463. Всё, что начинается на 5.x.x, — hard bounce, адрес в suppression немедленно и навсегда. Всё, что на 4.x.x, — soft (переполнен ящик, greylisting, временный сбой), это не повод подавлять. Ключевые коды:
5.1.1 — bad mailbox / user unknown (ящика нет)
5.1.2 — bad / non-existent domain
5.2.1 — mailbox disabled (отключён)
5.7.1 — policy / blocked (это уже отлуп по политике, часто признак того, что вы задели фильтр, — разбирать отдельно, не путать с несуществующим ящиком)
Извлечение hard-bounce адресов из лога Postfix (/var/log/mail.log на Debian/Ubuntu, /var/log/maillog на RHEL):
bash
# Все отбитые с кодом 5.1.1 — несуществующие ящики
grep "status=bounced" /var/log/mail.log \
| grep "5.1.1" \
| grep -oP 'to=<\K[^>]+' \
| sort -u > hardbounce_userunknown.txt
# Быстрый срез по всем 5.x.x за сегодня
grep "$(date +%b\ %e)" /var/log/mail.log \
| grep "status=bounced" \
| grep -oE 'to=<[^>]+>.*said: 5\.[0-9]\.[0-9]' \
| sort | uniq -c | sort -rn
Правило простое и жёсткое: suppression после ПЕРВОГО hard bounce, а не после третьего. Логика «дадим адресу три попытки» здесь работает против вас — к третьей попытке брошенный ящик уже успел стать ловушкой. Один 5.1.1 — и адрес уходит в стоп-лист навсегда.
Проверка по блок-листам своими руками: DNSBL и DBL
Убедиться, что вы уже влипли, надо раньше, чем это заметит клиент по проваленной кампании. Spamhaus ZEN проверяется обычным dig: берёте IP, переворачиваете октеты, дописываете зону.
bash
# IP отправителя 203.0.113.10 → перевернуть октеты → 210.69.22.212
dig +short 210.69.22.212.zen.spamhaus.org
# Пустой ответ = не листингован. Есть ответ — читаем код возврата:
# 127.0.0.2 SBL (ручной листинг, спам-источник)
# 127.0.0.3 SBL CSS (снежный ком — автолистинг)
# 127.0.0.4-7 XBL (заражённый/проксированный хост)
# 127.0.0.9 SBL DROP (не маршрутизировать вообще)
# 127.0.0.10/11 PBL (динамический/бытовой диапазон)
# Домен из ссылок и From проверяем по DBL:
dig +short example.com.dbl.spamhaus.org
# 127.0.1.2 = спам-домен
Важная оговорка, на которой спотыкаются почти все: Spamhaus не отвечает на запросы через публичные резолверы. Google 8.8.8.8, Cloudflare 1.1.1.1 и прочие open resolvers вернут не реальный листинг, а код-ошибку из диапазона 127.255.255.x (например, 127.255.255.254 — запрос через публичный DNS). Спрашивайте со своего рекурсивного резолвера или через DQS-ключ Spamhaus, иначе «чисто» в выводе dig не значит ничего.
Но листинг — это уже следствие. Опережающий индикатор — метрики жалоб, и мониторинг надо включать заранее, а не в момент пожара:
Google Postmaster Tools — держите User-reported spam rate ниже 0.10%; красная зона Gmail начинается около 0.30%, и после неё доставляемость деградирует лавинообразно.
Microsoft SNDS — цветовая шкала по complaint rate: зелёная дорожка это примерно <0.1%, жёлтая и красная — сигнал тормозить.
FBL / feedback loops (Yahoo, Comcast и др.) — каждая жалоба это адрес, который надо немедленно в suppression.
Если spam rate в Postmaster пополз к 0.20% — вы увидите беду за дни до того, как dig покажет SBL. Смотреть надо на метрики, а не на факт листинга.
Sunset-политика и реактивация без потерь
Чистить надо так, чтобы не выкинуть живых вместе с мёртвыми. Рабочее sunset-окно:
Адрес без открытий и кликов 90 дней → уходит в реактивационную ветку.
180 дней без единой реакции → в suppression.
Перед списанием — re-engagement кампания на 2–3 письма, и обязательно с отдельного тёплого субдомена или IP, а не по основному потоку. Мёртвый неактивный сегмент бьёт по репутации сильнее всего, и тащить его по каналу, которым идут транзакционные и активные рассылки, — значит подставлять весь трафик. Кто не отреагировал, того не удаляем в ноль, а переводим в suppressed: стоп-лист нужен и для комплаенса, и чтобы полгода спустя не залить этот адрес заново из старого экспорта. Для сомнительных когорт реактивацию делайте только через confirmed opt-in (COI) — пусть человек заново подтвердит клик.
Цифра, к которой стоит быть готовым морально: первая серьёзная чистка обычно снимает 10–25% списка. Это нормально и это на порядок дешевле, чем один листинг в SBL с последующим delisting и неделями восстановления репутации.
Профилактика на входе: опт-ин, honeypot-поля, коррекция опечаток
Не впустить дешевле, чем вычищать. Три барьера, которые срезают большинство ловушек ещё на форме:
Double opt-in отсекает pristine на корню. Ловушка получает письмо-подтверждение, но не кликает по ссылке — у неё нет человека, который бы это сделал. Адрес, не подтвердивший подписку, просто не попадает в рассылочный сегмент.
Honeypot-поле в форме регистрации — скрытый через CSS input, невидимый человеку, но заполняемый ботами. Заполнено поле — заявку в мусор. Это режет автоматические вбросы, которыми накачивают базу спарсенными адресами.
Клиентская коррекция typo-доменов до сабмита. Библиотека вроде mailcheck подсказывает gmail.com вместо gmial.com, mail.ru вместо частых опечаток — и человек не улетает в typo-ловушку из-за одной перепутанной буквы.
Запрет на импорт без явного согласия должен быть политикой, а не галочкой в чек-листе менеджера. Для evilmail.pro приём почты на временные адреса — легитимный сценарий, но для исходящих рассылок правило одно и без исключений: только адреса с явным подтверждённым согласием их владельца.
Чек-лист гигиены перед каждой крупной рассылкой
Подавлять hard bounce (5.x.x) немедленно, после первого отказа, навсегда.
Не трогать soft bounce (4.x.x) — это временные сбои, не ловушки.
Sunset-окно 90/180: 90 дней тишины → реактивация, 180 → suppression.
Никогда не слать на купленные, спарсенные и co-reg сегменты — вообще.
Double opt-in на всех формах подписки.
Honeypot-поле в каждой форме регистрации.
Клиентская коррекция опечаток домена до сабмита.
Еженедельная проверка отправляющих IP по ZEN и доменов по DBL через dig — со своего резолвера, не через публичный DNS.
Google Postmaster spam rate ниже 0.10%, SNDS в зелёной зоне.
Реактивационные кампании — только с отдельного тёплого субдомена/IP.
Хранить у каждого контакта source, imported_at, last_open_at, hard_bounced_at, consent_type — без этих полей триаж невозможен.
Спам-ловушку по-прежнему нельзя провалидировать — и не появится сервис, который «очистит базу от ловушек в один клик», потому что таких сервисов не бывает физически. Зато можно сделать так, чтобы ловушке было неоткуда взяться в вашем списке, а recycled-хит обрывался на первом 550. Это и есть вся работа: не поиск ловушек, а инженерия входа и отказов, при которой они просто не накапливаются.
