Ключевые слова: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.
Методы
борьбы со спамом (mail spam filter sendmail),
Александр, 04:51:47,
10/15/2003 [ответить]
(1) Вчера послал другу письмо с моего ящика,
через кнопку ответить на его письмо ко мне и получил вот
такое сообщение. 450 Graylisted by DCC А Вы
утверждаете, что проколов у Серого списка нет.
Другому другу так и не смог послать письмо через
Хотмейл, всегда приходит ответ, что не принимают письма
от спамеров. Сейчас чаще созваниваюсь с ним
по телефону, спасибо АДМИНУ.
Методы
борьбы со спамом (mail spam filter sendmail),
nemo, 16:11:59, 10/27/2003 [ответить]
(2) никакого прокола в данном случае и
нет. если твой почтовик, или почтовый сервис, которым
ты пользуешься, при первом же отлупе от принимающей
стороны бросает доставку письма - то это личные половые
проблемы твоего сисадмина или почтового сервиса.
если же он тебя только оповестил о возникшей
проблеме, а через час-полтора-два-три снова попытался
доставить письмо - то всё замечательно, письмо ушло, и
впредь будет уходить без задержек. какие
проблемы-то?
Методы
борьбы со спамом (mail spam filter sendmail),
Роман, 02:12:26, 01/08/2004 [ответить]
(3) По—моему, личные половые проблемы у тех,
кто настраивает ентот грейлистинг. Посылаю письмо в
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.
Руки бы
пообламывал.
И потом этот способ генерит
уведомления, которые ничем от спама не отличаються. Даже
хуже, спам я могу сразу стереть, не открывая, а это
лайно надо еще просмотривать - вдруг задержка по иной
причине.
.files/p.gif){kind=small}