Безпечне підключення DNSBL/RBL: вагові оцінки замість жорсткого блокування
Жорсткий reject на одному чорному списку — це не захист, а тиха втрата легітимної пошти. Розбираємо, як споживати DNSBL/RBL як зважені сигнали у postscreen і Rspamd, які списки мертві або токсичні у 2026, як читати коди 127.0.0.x і чому без власного резолвера Spamhaus вам просто не відповість.
EvilMail Team15 липня 2026 р.12 хв читання
Чому один DNSBL у режимі reject — це поломка, а не захист
Звичайний робочий день. Ваш контрагент сидить за CGNAT провайдера або на shared-IP дешевого хостера, з якого хтось три дні тому розсилав фарму. Його релей чистий, SPF і DKIM валідні, лист із підтвердженням замовлення летить до вас — і помирає на RCPT TO:
550 5.7.1 Service unavailable; Client host [203.0.113.10] blocked
using zen.spamhaus.org; https://www.spamhaus.org/query/ip/203.0.113.10
Відправник не отримав відповіді. Ви не отримали листа. У логах — один рядок, який ніхто не читає. Замовлення зникло, і ви дізнаєтесь про це за тиждень, коли клієнт зателефонує спитати, чому ви його ігноруєте.
Річ не в тім, що Spamhaus помилився — інколи діапазон справді брудний. Річ в архітектурі рішення. Булеве «є в списку / немає» не має градації довіри: воно не відрізняє підтверджене джерело спаму від динамічного діапазону, куди хост потрапив за фактом належності до пулу, не лишає місця ні грейлісту, ні перевірці контенту, ні компенсації білим списком. Один сигнал — і вирок.
Теза статті проста і в серйозній інфраструктурі не обговорюється: DNSBL/RBL — це вхідні ознаки для скорингу, а не вирок. Кожен список дає бали; бали сумуються разом із від'ємними вагами DNSWL, SPF, DKIM і Bayes; і лише перетин порогу впевненими списками веде до reject. Усе інше — привід підняти спам-score або відправити з'єднання в грейліст.
Які списки справді варті довіри у 2026
Реєстр коротко і без сентиментів. Не всі DNSBL живі, і геть не всі, що живі, варто пускати близько до reject.
Довіряємо:
Spamhaus `zen` — золотий стандарт. Агрегує SBL, CSS, XBL і PBL в одну зону. У 2026 публічний доступ через zen.spamhaus.org фактично мертвий для будь-якого серйозного трафіку: працює лише через DQS-ключ у форматі {key}.zen.dq.spamhaus.net. Найточніший інструмент, який у вас буде.
Barracudab.barracudacentral.org — сильний другий сигнал, але обов'язкова реєстрація вихідного IP вашого резолвера, інакше відповіді не буде.
Invaluementsip.invaluement.com / ivmURI — платний, наднизький рівень хибних спрацювань, дуже цінний як вагомий сигнал у скорингу.
PSBLpsbl.surriel.com — легкий, реактивний, добре працює як додаткова вага.
SpamCopbl.spamcop.net — тільки як легка вага. Швидко лістить за скаргами і так само швидко делістить, тому самостійно для reject непридатний.
Токсично або мертво:
SORBS — зупинено у червні 2024. dnsbl.sorbs.net більше не повертає осмислених відповідей. Якщо він досі у вашому конфізі — це зайвий DNS-запит у порожнечу; викидайте.
UCEPROTECT Level 2/3 — лістить цілі ASN та /24 через один брудний хост і відкрито торгує прискореним делістингом. У режимі reject це прямий шлях різати легітимних відправників пачками. Максимум — мікроскопічна вага, і то на любителя.
Правило, яке варто витатуювати: чим ширший об'єкт лістингу, тим менша вага. Список, що блокує окремий /32, заслуговує на довіру. Список, що блокує /24 чи цілого провайдера, — це колективна відповідальність, і в скорингу їй місце десь на рівні «+0.5», а не «reject».
Як правильно читати коди відповіді 127.0.0.x
DNSBL відповідає A-записом у діапазоні 127.0.0.0/8, і останній октет — це не «так/ні», а класифікація. Зливати всі коди в одне булеве значення — найпоширеніша і найдорожча помилка. Розберемо на zen:
127.0.0.2 — SBL, ручний лістинг підтвердженого спам-джерела. Висока впевненість.
127.0.0.3 — CSS, повністю автоматичний сублист SMTP-джерел із низькою репутацією. Впевненість висока, але ризик хибного спрацювання трохи вищий, ніж у ручного SBL.
127.0.0.4–127.0.0.7 — XBL, заражені машини, відкриті проксі, експлойти. Середня-висока вага.
127.0.0.9 — DROP/hijacked, викрадені мережі та ресурси відомих зловмисних операторів. Найвища впевненість — цей код завжди супроводжує і SBL-лістинг, і це чи не єдина відповідь, під яку я готовий поставити reject майже беззастережно.
127.0.0.10, 127.0.0.11 — PBL, динамічні та не-mail діапазони. Це не «спамер». Це «звідси не мали б слати SMTP напряму». Застосовне до submission-політики, категорично не для inbound reject на порту 25.
Перевіряємо руками, реверсуючи октети IP:
bash
# Чи в списку 203.0.113.10? Реверс: 10.113.0.203
dig +short 10.113.0.203.zen.spamhaus.org
# 127.0.0.2 -> SBL, підтверджене джерело
# Причина лістингу — у TXT
dig +short TXT 10.113.0.203.zen.spamhaus.org
# "https://www.spamhaus.org/sbl/query/SBLxxxxxx"
# Той самий запит через DQS-ключ (єдиний робочий шлях у 2026)
dig +short 10.113.0.203.{key}.zen.dq.spamhaus.net
Різні коди — різні ваги і різні дії. Хост у PBL і хост у DROP — це два зовсім різні світи, і конфіг, який трактує їх однаково, зламаний за визначенням.
Свій резолвер — інакше ваші запити просто не рахують
Ось де тихо вмирає більшість фільтрів. Spamhaus і Barracuda не обслуговують запити з публічних резолверів — 8.8.8.8, 1.1.1.1, 9.9.9.9. Через share і rate-limit вони або повертають порожнечу, або спеціальний код помилки 127.255.255.254. Ваш Postfix при цьому не бачить лістингів взагалі, спам тече, а ви впевнені, що захищені. Класична тиха відмова.
Рішення — власний рекурсивний резолвер, зазвичай unbound на локальному хості:
bash
# /etc/unbound/unbound.conf.d/dnsbl.conf
server:
# Не роздаємо резолвер назовні
interface: 127.0.0.1
access-control: 127.0.0.0/8 allow
# DNSBL-відповіді короткоживучі — кешуємо негатив помірно
cache-max-negative-ttl: 3600
cache-max-ttl: 3600
# Не переписуємо 127.0.0.0/8 як приватний діапазон
private-address: 10.0.0.0/8
do-not-query-localhost: no
prefetch: yes
Вихідний IP цього резолвера ви реєструєте в Barracuda і прив'язуєте до DQS-акаунта Spamhaus. Безкоштовний DQS має ліміт близько 300 000 запитів на добу на акаунт — для середнього релея з розумним кешуванням цього вистачає з запасом, для навантаженого шлюзу берете платний тариф.
І запам'ятайте діапазон 127.255.255.252–.255: якщо dig повертає щось звідти — це не «хост у списку». Це «ваш ключ протух», «резолвер не зареєстрований» або «вичерпано ліміт». Заведіть окремий алерт на ці коди, бо саме вони означають, що фільтрація насправді не працює, тоді як логи виглядають чистими.
Вагова модель замість reject: postscreen на передньому краї
postscreen — правильне місце для DNSBL у Postfix. Він працює доsmtpd, дешевий за ресурсами, і — головне — рахує саме зважену суму, а не спрацьовує на першому ж списку. Ключовий блок main.cf:
Зверніть увагу на два прийоми. По-перше, один і той самий zen розкладено на три рядки з різними множниками: PBL дає лише +1, XBL +2, а SBL/CSS/DROP +4. По-друге, list.dnswl.org підключений із від'ємними вагами. Саме DNSWL із вагою -2/-4 рятує форуми, білінги і легітимні розсилки, що ділять IP зі спамерами: PBL накидає +1, а білий список знімає -4, і сума йде в мінус. З порогом 4 жоден одиничний «м'який» сигнал не викликає reject — потрібне або підтверджене джерело (+4), або комбінація кількох середніх ваг.
Коли DQS-ключ активний, підставте {key}.zen.dq.spamhaus.net замість публічного zen.spamhaus.org.
Тонке доналаштування у Rspamd
Якщо потрібен скоринг на рівні контенту, а не лише на connect, DNSBL живе в RBL-модулі Rspamd поруч зі SPF, DKIM, DMARC і Bayes. Принцип той самий: символи додають вагу до загального score, самі по собі лист не викидають. Важлива деталь, на якій регулярно спотикаються: у блоці returncodes вага не задається — це лише відображення «символ → код відповіді». Ваги живуть окремо, у секції символів.
Для доменів у тілі листа додайте URIBL — dbl.spamhaus.org і multi.uribl.com — але малою вагою (0.5–2), бо URI-списки схильні лістити шортенери й хостинги, де сидить і легітимний контент. Реальний reject спрацьовує тільки коли сума перетнула actions { reject = ... }, а не за фактом одного символа. DNSWL із is_whitelist = true і від'ємним score працює симетрично postscreen — компенсує сумнівні сигнали для перевірених відправників.
Де народжуються хибні спрацювання і як їх гасити
SASL і свої мережі — в обхід усього. У smtpd_recipient_restrictions порядок вирішує все: permit_mynetworks, permit_sasl_authenticated йдуть перед будь-яким reject_rbl_client. Автентифікований клієнт не повинен навіть торкатися DNSBL.
PBL/динаміка — тільки на 587. Inbound на порту 25 не застосовує PBL до reject ніколи. Ваші власні користувачі з домашніх динамічних IP шлють через submission (587/465) з автентифікацією і байдужі до PBL.
Локальний whitelist контрагентів. Тримайте check_client_access або Rspamd multimap з IP/доменами ключових партнерів. Один впертий CGNAT-контрагент не вартий щотижневих скарг.
Shadow-режим перед enforce. Тиждень із postscreen_dnsbl_action = ignore — DNSBL рахується і логується, але нічого не ріже. Потім рахуєте розподіл рангів, які отримали б реальні з'єднання:
Дивитеся, скільки легітимної пошти впало б при обраному порозі, коригуєте поріг і множники — і лише потім перемикаєте на enforce.
Канал делістингу і TTL. Задокументуйте runbook: хто і як подає запит на делістинг у Spamhaus/Barracuda. Пам'ятайте, що негативний кеш резолвера тримає стару відповідь до cache-max-negative-ttl — після делістингу почистіть кеш unbound-control flush_zone, інакше чекатимете годину.
Чек-лист перед увімкненням enforce
[ ] Локальний unbound піднятий, публічні резолвери не використовуються для DNSBL.
[ ] Вихідний IP резолвера зареєстровано в Barracuda; DQS-ключ Spamhaus активний і перевірений dig.
[ ] Заведено алерт на коди 127.255.255.252/.254/.255 — ознака зламаної фільтрації.
[ ] DNSWL підключено з від'ємними вагами (-2/-4) у postscreen і Rspamd.
[ ] PBL застосовується лише до submission (587), ніколи до inbound reject на 25.
[ ] permit_mynetworks, permit_sasl_authenticated стоять першими в обмеженнях.
[ ] SORBS видалено; UCEPROTECT L2/L3 не в reject (максимум мікровага).
[ ] Поріг відкалібровано на реальному трафіку в shadow-режимі щонайменше тиждень.
DNSBL — потужний інструмент рівно доти, доки ви ставитеся до нього як до одного голосу серед багатьох. Той момент, коли один список отримує право одноосібного вироку, — це момент, коли ваш антиспам починає тихо коштувати вам доставленої пошти.
