Чому я не використовую DNSBL
Оренда сервера. Виділені сервери в Україні та НідерландахОренда сервера
VPS, VDS, Windows VPS - від $10VPS
Перед тим як бездумно вліпити собі в конфіг пару десятків блекалістів, пропоную разом подумати про те, для чого потрібні бляклісти і чому вони були створені.
Тепер повернемося до тих часів, коли ordb.org був потужним інструментом у боротьбі зі спамом. Технологія DNSBL набула такої популярності, що різних бляклістів з'явився вагон і маленький візок. При переході спамерів з відкритих релеїв на ботнети бліклісти намагалися йти в ногу з часом. Вони заносили у свої бази даних цілі підмережі, поділяючи їх за різними ознаками. Наприклад була спроба створити блекліст, що включає підмережі провайдерів, які призначені для виділення домашнім користувачам і малим офісам. Вважалося, що такі користувачі не повинні надсилати пошту безпосередньо, а використовувати провайдерові релеї. По факту ж цей задум провалився з двох причин: по-перше неможливо відстежити абсолютно всі клієнтські мережі всіх провайдерів, по-друге зараз безліч малих офісів, підключених на бюджетні тарифні плани і не можна їх обділяти в бажанні використовувати свій особистий поштовий сервер, якщо повідомлення від нього йдуть "чисті".
На сьогоднішній день ситуація склалася таким чином, що в бляклісти нерідко потрапляють чесні релеї. Це накладає свої обмеження використання блеклистів – їх можна використовувати за звичним раніше принципу: “Є запис у бляклісті – повідомлення однозначно відхиляється”. Блеклісти можна використовувати тільки при виваженій оцінці всіх факторів. Приклад такої реалізації можна спостерігати у фільтрі Spamassassin: якщовідправник присутній у бляклісті, то повідомленню нараховується N балів, за результатом усіх тестів бали підсумовуються та виноситься загальне рішення про “спамність” листа. Тобто. в цьому випадку ми спостерігаємо не однозначне відхилення повідомлення на підстави відповіді блекліста, а лише деяке збільшення ймовірності його спамності. Сьогодні це єдиний розумний підхід до використання блеклистів.
Ну ось розкритикував бляклісти, а як же тепер зі спамом боротися? Адже хочеться відсікати спам ще на стадії з'єднання, щоб заощадити ресурси системи і не навантажувати фільтр, той самий spamassassin, наприклад, зайвими повідомленнями. Про це нижче.
Я не буду детально розписувати що означає кожен з пунктів, а лише наведу частину конфігураційного файлу postfix з посиланням у дужках на пункти характеристик. Дужки, природно, потрібно прибрати перед використанням опцій у своєму конфізі.
unverified_recipient_reject_code=550 smtpd_helo_required = yes
smtpd_client_restrictions = permit_mynetworks, reject_unknown_client [1]
smtpd_helo_restrictions = permit_mynetworks, reject_invalid_hostname, [2] reject_non_fqdn_hostname, [3] reject_unknown_hostname [4]
smtpd_sender_restrictions = permit_mynetworks, reject_non_fqdn_sender, reject_unknown_sender_domain [6]
smtpd_recipient_restrictions = permit_mynetworks, reject_non_fqdn_recipient, reject_unauth_pipelining, reject_unauth_destination, reject_unlisted_recipient, check_policy2.
За п.5. Варто зауважити, що використання цієї особливості називається Greylisting. Більш детальну інформацію щодо Greylisting'у можна прочитати у вікіпедії. У даному випадку для грейлістингу рекомендується пакетpostgrey.
Цих опцій цілком достатньо для того, щоб кількість спам-листів у Вас зменшилася з кількох десятків до 1-2 на день. За умови використання додаткових контент-фільтрів (DSPAM або SpamAssassin) кількість спаму зменшиться до 1-2 листів на місяць.
P.S. Текст написаний для постмастерів-початківців, щоб застерегти їх від помилок.
Так, мені нещодавно тицьнули пачку блеклистів з форму сисадмінського зарубіжного якогось, AdminZone здається, і попросили вкрутити блокування відсулення листів І РЕЄСТРАЦІЇ користувачів з іменами, які під блеклісти підпадають. Подивився я туди, побачив утікачам поглядом mail.ru, yandex.ru та ін ... загалом-то дійсно треба діяти з розумом у цьому випадку.
Спасибі, розклали все по поличках. А то читав безліч прикладів конфігураційних файлів. Усі пишуть правильно, але така каша у голові з різних опцій утворилася.
@Troy Хто заважає на кожен фільтр тримати список винятків і додавати туди за необхідності? Наприклад ось так для helo: smtpd_helo_restrictions = permit_mynetworks, check_helo_access hash:/usr/local/etc/postfix/helo_access, reject_invalid_hostname, reject_unknown_hostname,
@Troy Так, так і є. Тільки ось криво налаштований сервер – це пряма помилка адміністратора на відміну від блекалістів, які наповнюються не зрозумій за яким принципом. Крім того, якщо адміністратор кривоналаштованого сервера побачить, що його повідомлення не приймаються через, скажімо, того ж кривого EHLO, то виправити проблему – справа 3 хвилин, на відміну від тих самих блекалістів, де політика делістингу не менш ідіотська, ніж політика наповнення .
Ну а баланс кожен будує під себе. Чарівної пігулки тут немає.
Воланд, а чого справді домігся 1-2 листівна день лише цими правилами? :) Не вірю! Ну з DSPAM ще можливо…
@ Lord Kaho 1) Так, правда. 2) Користуй check_client_***** для списків винятків.
reject_unverified_sender дуже потішно поводиться якщо на відправляючому сервері теж включений greylist. Можете перевірити самі.
Так, правда, помилка вкралася. Дякую :) Поправив пост
При цьому помилкових спрацьовувань 0, включаючи коректну доставку потрібних розсилок. Мої аркуші перевірені роками роботи. Вам вирішувати чи потрібні RBL чи ні, але для мене зайвих 1952 листів на місяць проти максимум 7, це дуже багато!
4. Статистика реджектів за добу:
# cat /var/log/mailloggrep -c NOQUEUE 616762
Хочете про щось посперечатися? :)
1. На жаль, далеко не всі такі прохання виконують. Я можу зрозуміти, коли 4 з 5 великих провайдерів відмовили мені в зворотній зоні для домашнього використання. Але таке явище буває і корп. секторі у різних субпровайдерів, особливо коли немає альтернативних провайдерів у будинках, на територіях заводів. Але річ навіть не в цьому. Перевірка зворотної зони позбавляє абсолютно «законослухняні» сервера відправляти вам пошту навіть якщо їх адміни не мають або не хочуть зробити заявку на запис до зворотної зони. Чи буде легше менеджеру чи бухгалтеру, якщо його повідомлення від клієнта було порізано правилом перевірки зворотної зони, а чи не RBL? Крім того, як я вже й говорив вище і без цієї перевірки все фільтрується чудово. 2. Може бути. В мене проблем не було. Як, втім, і з postgrey. 3. Справа не в спамхаусі, а в тому, що можна підібрати аркуші з адекватною політикою. Можете комбінувати та здійснювати фільтрацію за власною перевагою. Наприклад, залишити листи тільки вірусних розсилок. Ви ж, наскільки, я зрозумів кажете про те, що RBL –це зло у принципі. 4. Я не хочу ні про що сперечатися. Я просто висловив думку, що RBL, як додатковий засіб при здоровому підході – ефективна річ. Та й свою незгоду щодо зворотної зони спробував сформулювати. Не більше не менше.
На додаток. Запис у зворотній зоні не гарантує, що з цього хоста не спамити або розсилати віруси.
Не пересмикуйте. Я не казав, що зворотний запис щось гарантує. Якби була якась однозначна ознака, яка гарантувала розпізнавання спаму чи не спаму – проблеми не було б у принципі. І, як наслідок, цього постінгу також.