The OpenNET Project / Index page

[ новости/++ | форум | wiki | теги ]

Методы борьбы со спамом (mail spam filter sendmail)


<< Предыдущая ИНДЕКС Поиск в статьях src Установить закладку Перейти на закладку Следующая >>
Ключевые слова: mail, spam, filter, sendmail,  (найти похожие документы)
From: Andy Gorev <http://www.linux.by/>; 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.

<< Предыдущая ИНДЕКС Поиск в статьях src Установить закладку Перейти на закладку Следующая >>

Обсуждение [ Линейный режим | Показать все | RSS ]
 
  • 1.1, Александр, 04:51, 15/10/2003 [ответить] [смотреть все]
  • +/
    Вчера послал другу письмо с моего ящика, через кнопку ответить на его письмо ко мне и получил вот такое сообщение. 450 Graylisted by DCC
    А Вы утверждаете, что проколов у Серого списка нет.
    Другому другу так и не смог послать письмо через Хотмейл, всегда приходит ответ, что не принимают письма от спамеров.  Сейчас чаще созваниваюсь с ним по телефону, спасибо АДМИНУ.


     
  • 1.2, nemo, 16:11, 27/10/2003 [ответить] [смотреть все]
  • +/
    никакого прокола в данном случае и нет.
    если твой почтовик, или почтовый сервис, которым ты пользуешься, при первом же отлупе от принимающей стороны бросает доставку письма - то это личные половые проблемы твоего сисадмина или почтового сервиса.
    если же он тебя только оповестил о возникшей проблеме, а через час-полтора-два-три снова попытался доставить письмо - то всё замечательно, письмо ушло, и впредь будет уходить без задержек. какие проблемы-то?
     
  • 1.3, Роман, 02: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 [ответить] [смотреть все]
  • +/
    Сейчас небольшая часть спама рассылается через провайдерский релей, как обычная ... весь текст скрыт [показать]
     
     
  • 2.7, олаф, 11:40, 07/05/2004 [^] [ответить] [смотреть все]  
  • +/
    >4) Создать базу данных адресов людей, которые не желают получать спам. Адреса
    >д.б. зашифрованы так, чтобы по базе можно было проверить наличие там
    >Адреса, но нельзя было бы получить список всех адресов - как
    >в Unix шифруется пароль пользователя, т.е. в базе должны храниться хаши
    >адресов.
    >

    Интересная идея / а она где-нибудь реализована?

     
  • 1.8, bmf, 17:13, 31/05/2005 [ответить] [смотреть все]  
  • +/
    точнее в версиях выше 2.1 организован грейлистинг скрипт есть перловый, а вот как туда же добавить тех кого пропускать без задержек? с access покопался но не разобрался :-(
     
  • 1.9, Oleg, 10:38, 07/07/2005 [ответить] [смотреть все]  
  • +/
    2 bmf
    в базе добавляешь запись как это написано в примере .sql файла.

    Нашел один существенный недостаток грейлиситинга.
    Но не пропускает письма, которые идут с многорелэйных почтовых систем.
    Например CNET и тд.

    Явно добавлять их всеъ в вайт лист уже откровенно достался...

    Суть такова.
    Удалённая система пытается отправить письмо с одного ип, получает темпфэйл, через час шлёт с другого, получает темпфэйл, ещё через час с третьего и тд. За это время записи о первых 2-х ипах протухают. Письмо так и крутится по циклу пока через 5 дней не выкидывается.

    Существенный imho недостаток.

     
  • 1.10, Oleg, 10:51, 07/07/2005 [ответить] [смотреть все]  
  • +/
    Может быть кто-то уже сделал себе явный белый список таких систем и поделится? =)
    Желательно с комментами =)
     
  • 1.11, Oleg Poruchikov, 20:13, 25/10/2005 [ответить] [смотреть все]  
  • +/
    Внимание!
    http://mail-abuse.org/cgi-bin/lookup перемещён на http://mail-abuse.com/cgi-bin/lookup
     
  • 1.12, Oleg Poruchikov, 20:50, 25/10/2005 [ответить] [смотреть все]  
  • +/
    Кстати, и http://dsbl.org/listing.php изменен на http://dsbl.org/listing
     
  • 1.15, Alex, 13:34, 17/03/2008 [ответить] [смотреть все]  
  • +/
    Не знаю, хорошие тут способы или плохие, но МНОГОЕ зависит и от того, кто предоставляет услуги почты. У меня есть (вернее был) ящик на mail.ru. Оригинально у них устроена борьба со спаммерами. Сначала они "сливают" базы рассыльщикам, а на претензии по этому поводу присылают стандартные отписки... А если продолжать им "надоедать", то результат - мой ящик они заблокировали, а на все вопросы - ни ответа, ни привета....
     

    Ваш комментарий
    Имя:         
    E-Mail:      
    Заголовок:
    Текст:





      Закладки на сайте
      Проследить за страницей
    Created 1996-2017 by Maxim Chirkov  
    ДобавитьРекламаВебмастеруГИД  
    Hosting by Ihor