Ключевые слова: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/lookuphttp://work-rss.mail-abuse.org/cgi-bin/nph-rsshttp://dsbl.org/listing.phphttp://ordb.org/lookuphttp://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.
Вчера послал другу письмо с моего ящика, через кнопку ответить на его письмо ко мне и получил вот такое сообщение. 450 Graylisted by DCC
А Вы утверждаете, что проколов у Серого списка нет.
Другому другу так и не смог послать письмо через Хотмейл, всегда приходит ответ, что не принимают письма от спамеров. Сейчас чаще созваниваюсь с ним по телефону, спасибо АДМИНУ.
никакого прокола в данном случае и нет.
если твой почтовик, или почтовый сервис, которым ты пользуешься, при первом же отлупе от принимающей стороны бросает доставку письма - то это личные половые проблемы твоего сисадмина или почтового сервиса.
если же он тебя только оповестил о возникшей проблеме, а через час-полтора-два-три снова попытался доставить письмо - то всё замечательно, письмо ушло, и впредь будет уходить без задержек. какие проблемы-то?
По≈моему, личные половые проблемы у тех, кто настраивает ентот грейлистинг. Посылаю письмо в 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.
Руки бы пообламывал.
И потом этот способ генерит уведомления, которые ничем от спама не отличаються. Даже хуже, спам я могу сразу стереть, не открывая, а это лайно надо еще просмотривать - вдруг задержка по иной причине.
Сейчас небольшая часть спама рассылается через провайдерский релей, как обычная почта; основная же часть спама рассылается напрямую, и потому м.б. блокирована черными списками. Причем (как и нговорится в статье) спамерские программы-рассылатели не пытаются повторно доставить почту при любых проблемах - как временном отказе, так и постоянном. Но никто не мешает спамерам модифицировать свои программы, приблизив их поведение к нормальным MTA. Так что, IMHO, широкое распространение "серых списков" даст лишь временную передышку.
Для борьбы со спамом я предлагаю такие методы:
1) Не оставлять спам без последствий, а звонить по спамерским телефонам и говорить спамеру, что он - "собака женского пола, женщина безнравственного поведения и мужчина нетрадиционной сексуальной ориентации, имвший анальный и оральный секс в пассивной форме". Как только таких звонков станет больше, чем полезных спамеру, спам станет экономически невыгодным. (Это я называю "атака на заказчика".)
2) Вести просвещение народа о вреде спама. В первую очередь это надо делать через рекламные газеты (в Москве - "Экстра-М", "Центр Плюс"), т.к. они - наши естественные союзники в борьбе со спамом, который забирает у них часть рекламных бюджетов фирм.
3) Добиваться принятия закона о спаме. В частности, в спаме д.б. указаны координаты не только заказчика, но и исполнителя рассылки.
4) Создать базу данных адресов людей, которые не желают получать спам. Адреса д.б. зашифрованы так, чтобы по базе можно было проверить наличие там Адреса, но нельзя было бы получить список всех адресов - как в Unix шифруется пароль пользователя, т.е. в базе должны храниться хаши адресов.
4a) Создать в DNS-зонах, в которых не хотят получать спам, особую заранее оговоренную запись, дабы спамеры, ежели их привлекут к суду, не могли отбояриться тем, что они не знали о нежелании пользователей данного домена получать спам.
>4) Создать базу данных адресов людей, которые не желают получать спам. Адреса
>д.б. зашифрованы так, чтобы по базе можно было проверить наличие там
>Адреса, но нельзя было бы получить список всех адресов - как
>в Unix шифруется пароль пользователя, т.е. в базе должны храниться хаши
>адресов.
>
точнее в версиях выше 2.1 организован грейлистинг скрипт есть перловый, а вот как туда же добавить тех кого пропускать без задержек? с access покопался но не разобрался :-(
2 bmf
в базе добавляешь запись как это написано в примере .sql файла.
Нашел один существенный недостаток грейлиситинга.
Но не пропускает письма, которые идут с многорелэйных почтовых систем.
Например CNET и тд.
Явно добавлять их всеъ в вайт лист уже откровенно достался...
Суть такова.
Удалённая система пытается отправить письмо с одного ип, получает темпфэйл, через час шлёт с другого, получает темпфэйл, ещё через час с третьего и тд. За это время записи о первых 2-х ипах протухают. Письмо так и крутится по циклу пока через 5 дней не выкидывается.
Не знаю, хорошие тут способы или плохие, но МНОГОЕ зависит и от того, кто предоставляет услуги почты. У меня есть (вернее был) ящик на mail.ru. Оригинально у них устроена борьба со спаммерами. Сначала они "сливают" базы рассыльщикам, а на претензии по этому поводу присылают стандартные отписки... А если продолжать им "надоедать", то результат - мой ящик они заблокировали, а на все вопросы - ни ответа, ни привета....
