Методи боротьби зі спамом (mail spam filter sendmail)
Ключові слова: mail

, spam , filter , sendmail , ( знайти схожі документи )
From: Andy Gorev < http://www.linux.by/&gt ; Newsgroups: http://www.atmsk.ru/ Date: Mon, 25 Sep 2003 14:31:37 +0000 (UTC) Subject: Методи боротьби зі спамом Оригінал: http://www.atmsk.ru/index.php?option=articles&task=viewarticle&artid=25 Проблемою боротьби зі спамом зараз стурбовані всі, як користувачі, так і постачальники послуг, аж до AOL і інших найбільших компаній. Майкрософт взагалі обіцяє позбавити нас усіх від спаму вже менше ніж через два роки ( http://www.compulenta.ru/2003/6/2/39796/ ). Очевидно, що краще за все боротися зі спамом на стороні сервера, тобто SMTP релея, а не на стороні клієнта, налаштовуючи фільтри в поштовому рідері. Вигода очевидна - економія трафіку і більша точність роботи в першому випадку, ніж у другому. Найбільш поширені і прості методи боротьби зі спамом наявні сьогодні, на кшталт складання "чорних" і "білих списків", є негнучкими. Чорні списки легко обходяться зміною поштових адрес і використанням альтернативних серверів, а білі списки не дають приймати пошту з адрес, не дозволених користувачем. Однак існує ряд більш вдалих технік з ипользованием блек-листів, фільтрації по user-agentу і ін. Застосування спеціалізованих пакетів типу spamassassin ( http://useast.spamassassin.org/ ) Або spamoracle ( http://pauillac.inria.fr/~xleroy/software.html #spamoracle) вкрай рекомендується і неодноразово описувалося. Результатом "заклопотаності" проблемою, є виникнення все нових і нових аналітичних методів боротьби зі спамом. У нашій країні теж не стоять на місці, переконається в цьому можна на сайті http://www.antispam.ru/. А застосування http://www.spamtest.ru/ дозволяє однозначно виділяти спам, і що найприємніше - перекласти цю задачу на інших. Одним з таких перспективних методів є метод "сірих списків", запропонований Еваном Гарріс. Свою назву метод отримав через те, що він є проміжним між методом чорних і білих списків. Важливою перевагою методу є те, що він майже не вимагає втручання користувача і не віднімає великих ресурсів серверної системи. Не менш важливо і те, що система практично не має помилкових спрацьовувань. Ідея методу схожа на ряд вже наявних систем, які надсилають запити невідомим відправникам, вимагаючи підтвердити намір відправити лист. Однак людина в цьому процесі не бере участь, і вся взаємодія відбувається на рівні спілкування MTA-агентів. Чому це працює, як це працює, які є техніки у спамерів, і як з ними справляється фільтр можна прочитати за посиланням http://projects.puremagic.com/greylisting/ Там-же можна взяти сам фільтр і деталі по його конфігурації. Створення фільтра для postfix зараз в процесі, а зараз успішно експлуатується фільтр для sendmail. Розглянемо докладніше запропоновану конфігурацію. Після установки фільтра, сервер виконує наступний ланцюжок передачі даних: sendmail - libmilter - perl_milter - perl - graylist_filter - perl_DBI - DBD_MySQL - MySQL і назад. Причому, якщо приймається рішення про необхідність доставки, можуть спрацьовувати інші мільтер-фільтри, наприклад антивірусний захист. Сучасні антивіруси для серверних MTA як правило самі мають кілька простих антиспам-фільтрів, типу reject для undisclosed recipient або mass sender. Не дивлячись на використання MySQL і складного ланцюжка передачі даних від MTA до бази, навантаження на систему і CPU дуже невелика. Оперування проводиться триплету - IP адреса релея, @ Сендера, @ рецепиента. Коли поступет нове (по триплети) для бази лист, сервер говорить віддаленої стороні TEMPFAIL протягом 58 хвилин. Те-є лист не доходить. По закінченні цього часу, відкривається 4-х годинне вікно, протягом якого база чекає підтвердження триплета (повторної передачі листа). Якщо триплет не підтверджується, запис видаляється з бази. Те-є наш сервер треба умовити прийняти пошту. Теоретично хтось, який посилає безпосередньо (без релея) на наш сервер пошту раз на п'ять годин (або релей з ETRN = 5ч.), Може ніколи її не доставити. Але така ситуація майже неймовірна, так-як релеі завжди роблять ретрансміссіі з таймаут, а безпосередньо людина (спамер) втомиться слати листи саме з такою періодичністю. Крім того, фільтр має функції перевірки поштового клієнта в разі відправки безпосередньо. Навіть якщо така ситуація виникне, є білий список для її обходу. Якщо триплет підтверджується (resend or other mail), фільтр заносить триплет в білий список на 36 днів. Зрозуміло, все таймаут можна змінити на свій розсуд. Локальні мережі прописуються в "довічний" білий список. Це означає, що наші клієнти можуть спамити без проблем. Те-є пошта, що відправляється від нас, ніколи не буде затримуватися. Після запуску, база набирає валідниє триплети, за якими будуть пропускатися затримки. За ним будуть проходити в тому числі і urgent-листи, що не терплять затримок. Очевидно, що навряд чи хтось буде слати urgent і більше нічого раз в два місяці. Як обгрунтування обраних за замовчуванням таймаутів можна назвати наступні причини: Затримку в 58 хвилин не має сенсу зменшувати тому-що: 1) Час затримки не помітить більшість користувачів і жоден поштовий сервер. Для користувачів - це відбувається тільки перший раз для триплетів. Далі затримок не буде. Для серверів - інсталяції за замовчуванням сконфігуровані таким чином, що роблять спроби ретрансміссіі протягом 5-7 днів! Про який годині мова? icon_biggrin.gif 2) Якщо релей зламаний, годину необхідний адміну для виявлення і вирішення цієї проблеми. Якщо це свідомий спамерських відкритий релей, годину необхідний щоб хтось заніс його в чорний список. Підкреслю, що graylisting не видаляти пошту, а тільки затримує її. Тобто, якщо спамер буде дуже наполегливим, він таки "умовить" наш MTA приймати спам. Те-є ми приймемо рано чи пізно все, що нам послали, якщо воно буде надсилатися з чогось релея знову і знову. Щоб однозначно відкидати спам, сервер повинен паралельно використовувати інші техніки, названі вище. Найпростіше використовувати перевірку по чорному списку + антивірусний захист. Нижче я приведу приблизну конфігурацію чорний список для sendmail. 3) затримувати пошта може мати різні envelops в разі listservers, тому годинна затримка є оптимальною для серверів підписок, тому що це не критична пошта. Втім ця ситуація рідкісна, subscribe.ru до неї не належить. 4) Годинна затримка необхідна, щоб обламати спамерських софт який спробує обійти graylisting. 5) Якщо її знизити хоча-б в два рази, ефективність захисту впаде, а особливого толку не буде. Хоча треба визнати, що основний захист здійснюється в перші хвилини, так як у спамерів в основному діє принцип - "послав і забув". 6) Стандартна установка sendmail і інших MTA має на увазі спробу ретрансмісіі раз на годину, іноді пів-години. Обидві ці ситуації є переважною більшістю в інтернет. Тому за таймаут в 58 хвилин на другий раз пошта пройде. Спамерських софт або переляканий юзер може довбати і довбати. Час потрібен щоб охолодити запал. Чотирьох-годинне вікно визначено дослідним шляхом на основі шестимісячної експлуатації фільтра і дебатів в списку розсилки на цю тему. Робити його більшим небезпечно, тому що спамер може відновлювати активність через 5-8 годин, імітуючи робочий день. Робити його менше - збільшиться відсоток затриманої корисної пошти. 36 денний білий список гарантує проходження пошти, яка йде один раз на місяць, з запасом. При цьому видаляються старовинні записи, що забезпечує ротацію бази. Повторю, що поки пошта по триплети йде, запис в базі оновлюється і висить в білому списку без видалення. Видаляються тільки записи про те, що пошта пройшла по триплети пару раз і вже більше місяця не ходить, і застарілі not whitelisted записи. Аналіз ефективності за результатами тестування протягом 6 тижнів, наведений у статті, стверджує, що було затримається тільки 4% корисної кореспонденції, не рахуючи списків розсилок. Звичайно, основна їх маса припадає на початок формування бази валідних триплетів, тобто відразу після її запуску. Протягом деякого короткого часу вона почне містити тільки актуальні триплети, і нові затримки будуть відбуватися рідко. Там-же наводяться дуже вражаючі цифри економії трафіку. Можна по крону освобождаеть базу від expired records і оптимізувати її. В процесі оптимізації створюється копія робочої таблиці. Якщо фільтр не запущений, сендмеіл благополучно його не помічає. Якщо фільтр не бачить MySQL, він _всем_ розсилає TEMPFAIL. Тому треба моніторити життєдіяльність бази. Файл dbdef.sql не використовується, проте він описує структуру бази, деякі цікаві запити до неї і процедуру додавання в білий аркуш. Додавати в білий список слід в разі, коли клієнт звернеться з конкретним проханням на конкретний релей або поштову адресу. Якщо він не знає чого хоче - можна роз'яснити політику захисту від спаму, запропонувати просто почекати, пообіцяти що такого більше не буде, послатися на проблеми в мережі icon_smile.gif, запропонувати не користуватися нашим сервером, придумати інші варіанти. Нарешті, щоб додати підтримку чорного списку в сендмеіл: 1) додаємо наступні рядки в sendmail.mc: FEATURE ( `dnsbl ',` dul.ru', `550 Use mail relays of your ISP ') dnl FEATURE (` dnsbl', `dialups .mail-abuse.org ', `550 Mail from $ & {client_addr} rejected; see http://mail-abuse.org/dul/enduser.htm ') Dnl FEATURE ( `dnsbl',` blackholes.mail-abuse.org ', `550 Mail from $ & {client_addr} rejected; see http://mail-abuse.org/cgi-bin/lookup? $ & {Client_addr} ') dnl FEATURE ( `dnsbl',` relays.mail-abuse.org ', `550 Mail from $ & {client_addr} rejected; see http://work-rss.mail-abuse.org/cgi-bin/nph-rss? $ & {Client_addr} ') dnl FEATURE ( `dnsbl',` list.dsbl.org ', `550 Mail from $ & {client_addr} rejected; see http://dsbl.org/listing.php? $ & {Client_addr} ') dnl FEATURE ( `dnsbl',` multihop.dsbl.org ', `550 Mail from $ & {client_addr} rejected; see http://dsbl.org/listing.php $ & {Client_addr} ') dnl FEATURE ( `dnsbl',` unconfirmed.dsbl.org ', `550 Mail from $ & {client_addr} rejected; see http://dsbl.org/listing.php? $ & {Client_addr} ') dnl FEATURE ( `dnsbl',` relays.ordb.org ', `550 Rejected - see http://ordb.org/ ') Dnl FEATURE ( `enhdnsbl',` bl.spamcop.net ', `" Spam blocked see: http://spamcop.net/bl.shtml? "$ & {Client_addr} ') dnl 2) говоримо # m4 sendmail.mc> sendmail.cf 3) kill -s HUP` head -1 / var / run / sendmail / sendmail.pid` 4) вуаля, tail -f / var / log / maillog і дивимося як все крутиться Лукапа баз за цими списками (подивитися-перевірити хост), в порядку їх слідування в конфіги: http://www.dul.ru/cgi-bin/search.cgi (Тут можна майже ніколи не перевіряти) http://mail-abuse.org/cgi-bin/lookup http://work-rss.mail-abuse.org/cgi-bin/nph-rss http://dsbl.org/listing.php http://ordb.org/lookup http://spamcop.net/bl.shtml Ремувальние системи (видалити хост, якщо він знайшовся в базі) в тому-ж порядку: 1) З DULа не видаляють, а скоріше заносять. Це списки діалапних пулів провайдерів, і будь-який післьмо зупинене цим сервісом однозначно СПАМ, то-же стосується DULа MAPSа. 2) Друге посилання - чорні списки MAPSа. Звідти прибрати складно, але можна http://mail-abuse.org/rbl/removal.html 3) Треттья - база відкритих реле MAPSa. Ремувалка (на 4-му кроці) - http://work-rss.mail-abuse.org/rss/howtofix.html 4) DSBL видаляє за добу після короткої переписки - http://dsbl.org/removalquery 5) У російських (ORDB) цей термін трохи довше - http://ordb.org/removal. Але і система у них наворочена. 6) У старого-доброго спамкопа взагалі досить по посиланнях з листа покликати. І навіть якщо нічого не робити, а просто заткнути дірку, він сам прибирає з бази адреса через 48 годин. детально - http://spamcop.net/fom-serve/cache/298.html. У двох словах: по реле використовується ORDB (попередня посилання), а за скаргами, коли їх немає - 48 годин витримки. Фільтрацію на стороні клієнта можна будувати на рівні procmail і інших фільтрів, що також неодноразово описувалося, а також, наприклад, застосовуючи розподілену базу razor. Використання razor показує дуже непогані результати. Деталі по налаштуванню, можливостям і конфігурації - http://razor.sourceforge.net/ Не забуваємо також про існування адміністративних заходів при боротьбі зі спамом, які можуть застосовуватися як проти самих спамерів так і їх мереж на стороні провайдера. Зазвичай при цьому з'ясовують адресу relay-server з заголовка листа, далі роблять whois на цю адресу, і зв'язуються з провайдером спамера. Успіхів у боротьбі зі спамом. _________________________________________________________________ Знайшлося чимало людей, яких налякав сам факт можливої ​​затримки листи, який може статися тільки на початку обміну поштою. Нагадаю, що це тільки близько 4-х відсотків. Так ось таким людям треба взагалі не користуватися поштою, особливо якщо вона проходить через безліч релеев. Мало-хто-де в мережі буде з нею щось робити. Переглядати там, Дропана, видирати з заголовків адреси для спамерських баз, або ще чого гірше. Господа, користуйтеся телефонами і icq.

• 1.1 , Олександр (?), 4:51, 15/10/2003 [ відповісти ] [ +++ ] [ · · · ]

+

/ - Вчора послав одного листа з мого ящика, через кнопку відповісти на його лист до мене і отримав ось таке повідомлення. 450 Graylisted by DCC
А Ви стверджуєте, що проколів у Сірого списку немає.
Іншому одному так і не зміг надіслати листа через Хотмейл, завжди приходить відповідь, що не приймають листи від спамерів. Зараз частіше телефоную з ним по телефону, спасибі адміну.

• 1.2 , nemo (?), 16:11, 27/10/2003 [ відповісти ] [ +++ ] [ · · · ]

+

/ - ніякого проколу в даному випадку і немає.
якщо твій поштовик, або поштовий сервіс, яким ти користуєшся, при першому ж відлупцював від приймаючої сторони кидає доставку листа - то це особисті статеві проблеми твого сисадміна або поштового сервісу.
якщо ж він тебе тільки сповістив про проблему, а через годину-півтора-два-три знову спробував доставити лист - то все чудово, лист пішло, і надалі буде йти без затримок. які проблеми-то?

• 1.3 , Роман (?), 2:12, 08/01/2004 [ відповісти ] [ +++ ] [ · · · ]

+

/ - По≈моему, особисті статеві проблеми у тих, хто налаштовує ентот грейлистинг. Посилаю лист о 15:38 з будинку через робочий SMTP (провайдеровской SMTP в дауні більшу частину часу). О 15:39 отримую відповідь з мого SMTP:

450 Temporary failure, try again later
30 attempts will be made to re-send your e-mail. Each attempt will be 1 hours apart.

О 15:40 другого листа
450 Graylisted by DCC
This is permanent error, and the message will not be retried any further.

Руки б пообламивал.

І потім цей спосіб генерує повідомлення, які нічим від спаму НЕ отличаються. Навіть гірше, спам я можу відразу стерти, не відкриваючи, а це лайно треба ще переглядати - раптом затримка з іншої причини.

• 1.6 , Дмитро Ю. Карпов (?), 14:23, 24/03/2004 [ відповісти ] [ +++ ] [ · · · ]

+

/ - Зараз невелика частина спаму розсилається через провайдерский релей, як звичайна пошта; основна ж частина спаму розсилається безпосередньо, і тому м.б. блокована чорними списками. Причому (як і нговорітся в статті) спамерські програми-рассилателі не намагаються повторно доставити пошту при будь-яких проблемах - як тимчасову відмову, так і постійному. Але ніхто не заважає спамерам модифікувати свої програми, наблизивши їх поведінку до нормальних MTA. Так що, IMHO, широке поширення "сірих списків" дасть лише тимчасовий перепочинок.

Для боротьби зі спамом я пропоную такі методи:

1) Не залишати спам без наслідків, а дзвонити по спамерським телефонами і говорити спамеру, що він - "собака жіночої статі, жінка аморальної поведінки і чоловік нетрадиційної сексуальної орієнтації, імвшій анальний і оральний секс в пасивній формі". Як тільки таких дзвінків стане більше, ніж корисних спамеру, спам стане економічно невигідним. (Це я називаю "атака на замовника".)

2) Вести просвіта народу про шкоду спаму. В першу чергу це треба робити через рекламні газети (в Москві - "Екстра-М", "Центр Плюс"), тому що вони - наші природні союзники в боротьбі зі спамом, який забирає у них частину рекламних бюджетів фірм.

3) Домагатися прийняття закону про спам. Зокрема, в спам д.б.н. вказані координати не тільки замовника, але і виконавця розсилки.

4) Створити базу даних адрес людей, які не бажають отримувати спам. Адреси д.б.н. зашифровані так, щоб по базі можна було перевірити наявність там Адреси, але не можна було б отримати список всіх адрес - як в Unix шифрується пароль користувача, тобто в базі повинні зберігатися хаши адрес.

4a) Створити в DNS-зонах, в яких не хочуть отримувати спам, особливу заздалегідь обумовлену запис, щоб спамери, якщо їх притягнуть до суду, не могли отбояріться тим, що вони не знали про небажання користувачів цього сервісу отримувати спам.

• 2.7 , Олаф (?), 11:40, 07/05/2004 [ ^ ] [ ^^ ] [ ^^^ ] [ відповісти ]

+

/ - > 4) Створити базу даних адрес людей, які не бажають отримувати спам. адреси
> Д.б. зашифровані так, щоб по базі можна було перевірити наявність там
> Адреси, але не можна було б отримати список всіх адрес - як
> В Unix шифрується пароль користувача, тобто в базі повинні зберігатися хаши
> Адрес.
>

Цікава ідея / а вона де-небудь реалізована?

• 1.9 , Oleg (??), 10:38, 07/07/2005 [ відповісти ] [ +++ ] [ · · · ]

+

/ - 2 bmf
в базі додаєш запис як це написано в прикладі .sql файлу.

Знайшов один істотний недолік грейлісітінга.
Але не пропускає листи, які йдуть з многорелейних поштових систем.
Наприклад CNET і тд.

Явно додавати їх все' в вайт лист вже відверто дістався ...

Суть така.
Віддалена система намагається відправити лист з одного ип, отримує темпфейл, через годину шле з іншого, отримує темпфейл, ще через годину з третього і тд. За цей час запису про перших 2-х іпах протухають. Лист так і крутиться по циклу поки через 5 днів не викидається.

Істотний imho недолік.

• 1.10 , Oleg (??), 10:51, 07/07/2005 [ відповісти ] [ +++ ] [ · · · ]

+

/ - Може бути хтось вже зробив собі явний білий список таких систем і поділиться? =)
Бажано з коментарями =)

• 1.15 , Alex (??), 13:34, 17/03/2008 [ відповісти ] [ +++ ] [ · · · ]

+

/ - Не знаю, хороші тут способи або погані, але БАГАТО залежить і від того, хто надає послуги пошти. У мене є (вірніше був) ящик на mail.ru. Оригінально у них влаштована боротьба зі спамерами. Спочатку вони "зливають" бази розсильників, а на претензії з цього приводу надсилають стандартні відписки ... А якщо продовжувати їм "набридати", то результат - мій ящик вони заблокували, а на всі питання - ні відповіді, ні привіту ....


Додати коментар

Спонсори:

Хостинг: