Альянс ASTA (The Anti-Spam Technical Alliance), в который вошли Yahoo!, Microsoft, EarthLink и AOL, после года своей работы, опубликовал документ ASTA Statement of Intent (pdf) (http://corp.aol.com/press/ASTA_Statement_of_Intent.pdf) с общими рекомендациями по борьбе спамом.URL: http://docs.yahoo.com/docs/pr/release1169.html
Новость: https://www.opennet.ru/opennews/art.shtml?num=4015
А чего тут можно рассуждать? Ограничить количество отправляемых каждым клиентом-индивидуалом писем:
- не более двадцати штук в минуту;
- не более пятидесяти штук в час;
- не более двухсот штук в сутки.Кому мало (особенно копоративным пользователям) - пусть отдельно просит увеличить квоты под обязательство не рассылать спам и вирусы (если нарушит - штраф). При это рам.станциям д.б. запрещено рассылать письма напрямую - только через зарегестрированные у провайдера релеи:
- релеи самогО провайдера;
- общедоступные релеи типа mail.ru и hotmail.com;
- собственные релеи юзеров, зарегестрированные по заявке провайдеру.И спам с вирусами исчезнут как явление.
>А чего тут можно рассуждать? Ограничить количество отправляемых каждым клиентом-индивидуалом писем:
>- не более двухсот штук в сутки.Вполне приемлимые для спамеров рамки, с учетом того что в рассылке участвуют десятки тысяч машин. Именно столько у меня ежедневно попадает в блэклист новых IP (за последние 8 часов были попытки рассылки спама с 2337 новых уникальных IP, всего в блэклисте более миллиона, не считая адресов присутствующих в DSBL (там 3.5 миллиона)).
Блокировать рассылку спама пересылаемого через провайдерские релеи гораздо сложнее, их так просто в блэклист не занесеш, как сейчас заносят клиентские машины. Время реагирования администрации на пересылку спама будет несколько часов в лучшем случае, при рассылке ночью - пол дня, и это если не учитывать провайдеров вообще не реагирующих на abuse, которых занести в блоклист не дадут клиенты - у них переписка, бизнес, деньги...
Для многих клиентов двадцать писем в минуту - ежовые руковицы, некоторые раз день поключаются и разом пересылают всю дневную почту всех сотрудников. Престиж провайдера суппорт которого только и отвечает на вопросы "почему почта не отправляется" пошатнется. Не думаю, что крупные ISP будут воодить жесткие Rate-limit, более мягкие лимиты и так есть, только они не эффективны.
> 200 писем в сутки - вполне приемлимые для спамеров рамки,
> с учетом того, что в рассылке участвуют десятки тысяч машин.Интересно, а сколько писем реально рассылают спам-машины? Я не думаю, что всего 200 штук в сутки.
И если реальное количество сильно больше, то такой лимит резко снизит количество спама и затруднит жизнь спамерам.> Блокировать рассылку спама пересылаемого через провайдерские релеи гораздо сложнее,
> их так просто в блэклист не занесеш, как сейчас заносят клиентские машины.А почему же спамеры не рассылают спам через релеи? Неужели спамеры - дураки, чтобы позволять вносить себя в blacklists?
> Время реагирования администрации на пересылку спама
> будет несколько часов в лучшем случае, при рассылке ночью - пол дня,Зато клиенту, с машины которого был разослан спам, выставляется штраф - так что в следующий раз клиент сам не допустит рассылки спама со своей машины.
> и это если не учитывать провайдеров вообще не реагирующих на abuse, которых
> занести в блоклист не дадут клиенты - у них переписка, бизнес, деньги...Значит, придётся этим клиентам использовать Web-mail - или вынудить провайдеров реагировать на спам.
> Для многих клиентов двадцать писем в минуту - ежовые руковицы, некоторые
> раз день поключаются и разом пересылают всю дневную почту всех сотрудников.Я же сказал: "для клиентов-индивидуалов". Для корпоративных клиентов ограничения вообще можно снять, но штрафовать за спам.
> Не думаю, что крупные ISP будут вводить жесткие Rate-limit;
> более мягкие лимиты и так есть, только они не эффективны.IMHO, большинство провайдеров вообще никак не ограничивают клиентов, позволяя им слать что угодно и куда угодно со скоростью, которую позволяют каналы.
Провайдер, который посмеет реализовать описанный сценарий, однажды (и скорее рано, чем поздно) будет иметь дело с юридическими отделами своих корпоративных клиентов. А также с исками наиболее продвинутых в деле сутяжничества граждан.
>Провайдер, который посмеет реализовать описанный сценарий, однажды (и скорее рано, чем поздно)
>будет иметь дело с юридическими отделами своих корпоративных клиентов. А также
>с исками наиболее продвинутых в деле сутяжничества граждан.Именно!
А таких ща ой как много....
> Провайдер, который посмеет реализовать описанный сценарий,
> однажды (и скорее рано, чем поздно) будет иметь дело
> с юридическими отделами своих корпоративных клиентов.
> А также с исками наиболее продвинутых в деле сутяжничества граждан.Это зависит от того, как будет обосновано введение такой политики. Хорошо бы, государство приравняло по уровню опасности компьютер к собаке и ввело ответственность владельца за поведение его компьютера как за поведение его собаки (ответственность владельца за поведение животного введена ещё в Библии). И тогда клиенты (и корпоративные, и индивидуальные) сами будут требовать применения к ним предложенной мной политики, дабы какой вирус или троян, забравшись на их компьютер, не обрёк владельца на штрафы.
Дмитрий, вы так и ответили как конкретно собирайтесь бороться с внутренними спамерами.
В прошлом году в inet-admins была дискуссия на эту тему, вывод:http://www.lexa.ru/inet-admins/msg14613.html
"надо, наверное, признать -- что блокировать спам от своих клиентов
практически невозможно. возможно только успеть увеличить расходы клиента
на создание спама ( ну, карточку закрыть ему раньше, чем он успеет ее
израсходовать. )."http://www.lexa.ru/inet-admins/msg14623.html
"Исходящий спам с большой вероятностью будет "новым". Более того,
если на выходе от клиента стоит фильтр, то его наличие клиент чует сразу
(спам или уходит или нет), и будет модифицировать письмо пока оно не начнет
уходить (если спамтест - только детектор, то ситуация немного упрощается).
В-общем, для работы с исходящим спамом нужны скорее методы, ловящие
_одинаковые_ письма + белые списки клиентов, которым это можно ("хорошие
рассыльщики")"
> Дмитрий, вы так и ответили как конкретно собирайтесь бороться с внутренними спамерами.1а) Запрет рассылки напрямую:
ipfw add allow tcp from any to {RELAY} smtp
ipfw add allow tcp from any to {mail.ru,yandex.ru.hotmail.com,...} smtp
ipfw add deny tcp from {CLIENTS} to any smtpИсключение делается только по заявке клиента и только до первого случая спама.
1б) Ограничение на число пересылаемых через релей писем. Я не знаю, как это сделать - но очевидно, что программисты-профессионалы могут написАть это за пару дней.
Ограничения имеют следующий вид:
- не более 20 писем в минуту;
- не более 50 писем в час;
- не более 200 писем в день.
Принцип: обычный юзер посылает письма "вспышками", тогда как спамер шлёт много писем в течении продолжительного времени.2) Введение ЮРИДИЧЕСКОЙ/ФИНАНСОВОЙ ответственности за рассылку спама и вирусов.
Для людей, подключённых по выделенке, заключается договор и вносится залоговый платёж.
Для DialUp-клиентов фиксируется телефонный номер, и если с этого номера был спам, то в течении месяца к этому клиенту применяются совсем драконовские ограничения на рассылку почты.
>1б) Ограничение на число пересылаемых через релей писем. Я не знаю, как
>это сделать - но очевидно, что программисты-профессионалы могут написАть это за
>пару дней.Вы заблуждаетесь. Проблема именно в трудоемкости практической реализации.
Я просил привести алгортм для данного пункта с учетом __динамических__ IP у клиентов.
В предыдущем письме ссылка на обсуждение, где ведущие российские специалисты так ничего и не придумали.
Если учесть все нюансы реализация требует затрат системных ресурсов соизмеримых
с самим MTA (см. мое первое письмо в этом треде).
>Вы заблуждаетесь. Проблема именно в трудоемкости практической реализации.Просто задача поставлена не корректно. Блокировать при превышении rate-limit диалапщиков, без того чтобы под горячую руку не попал другой пользователь получивший тот же IP, нужно очень аккуратно (контролировать не выделен ли данный IP другому пользователю и если выделен снимать блокировку. Не так трудоемко и совсем не ресурсоемко (если кэшировать состояние IP, а не на каждое соединение лезть в базу), но требуется кооперация с биллингом, что не всегда возможно).
Но подобный rate-limit делать и не обязательно, достаточно организовать мониторинг, например, раз в 5 мин. анализирующего лог и в случае значительного превышения разумных границ генерирующего алерт.
Минус такого подхода - в компании должен работь круглосуточный суппорт, способный отличить ложную тревогу и наделенный полномочиями блокирования пользователей.
Надеюсь, с динамическими адресами по выделенке (таких как у Точки.ру) вопросов не возникнет - там IP-адрес меняется очень редко (держится порядка суток или недель, а то и месяцев).Можно прикинуть, сколько времени займёт разрыв и восстановления DialUp-соединения. IMHO, это уже сделает спам экономически невыгодным.
Действительно, разрыв DialUp-соединения должен сбрасывать статистику. Это действительно существенно усложняет систему. А если учесть, что у большинства провайдеров имеется АОН (это требует ФСБ для отлова хакеров), на базе которого можно сделать что-то типа ARP и вести статистику не по IP-номерам, а по телефонным номерам, то проблема выглядит сложной, но вполне решаемой - просто надо начать работу над решением этой проблемы.
DialUp-юзер всегда авторизуется по логину и паролю. Это значит, что можно использовать парольную авторизацию на релее. Правда, остаётся проблема со спамером, купившим несколько DialUp-карточек и отправляющим спам с них по очереди; вероятно, идентификация по телефонному номеру (АОН) привлекательнее, хотя и требует объединения SendMail с системой авторизации пользователей.
>Надеюсь, с динамическими адресами по выделенке (таких как у Точки.ру) вопросов не возникнетС ними (у кого нет фиксированного IP) ситуация аналогична диалапу. Выделенщики (например, таких много среди домовых и офисных сетей) соединяющиеся только по мере необходимости не редкость.
>DialUp-юзер всегда авторизуется по логину и паролю. Это значит, что можно использовать
>парольную авторизацию на релее.Диалапщик - частный случай, кроме них вы предлагайте и все другие классы пользователей принудительно только через релей провайдера пропускать. Каждой машине в сети выделенщиков логин/пароль не дашь. К тому же не у всех клиентов софт поддерживает SMTP авторизацию (напрмер, различные роботы, cgi-скрипты и т.д.). А есть еще организации работающие только через удаленный корпоративный почтовый сервер.
На практике, каждому пользователю предлагается выбрать свой уровень безопасности - от "все открыто", до "только icq, web и почта через релей провайдера", выбирает клиент.>Правда, остаётся проблема со спамером, купившим несколько
>DialUp-карточек и отправляющим спам с них по очереди; вероятно,Это мелочи, проблемы доставляют пользователи подхватившие вирус/троянский софт.
>Провайдер, который посмеет реализовать описанный сценарий, однажды (и скорее рано, чем поздно)
>будет иметь дело с юридическими отделами своих корпоративных клиентов. А также
>с исками наиболее продвинутых в деле сутяжничества граждан.гм, нужно просто договор составлять вdoom'чиво. ;-)
/poige
--
http://www.i.morning.ru/~poige/
> гм, нужно просто договор составлять вdoom'чиво. ;-)Ну, видишь ли, закон о защите прав потребителя никто пока еще не отменял...
>> гм, нужно просто договор составлять вdoom'чиво. ;-)
>
>Ну, видишь ли, закон о защите прав потребителя никто пока еще не
>отменял...А покажи мне, пожалуйста, мил человек, раздел этого закона
касательно предоставления услуг типа SMTP-relay, или ipv4
forwarding?Базис:
1) Очень многое определяется договором. Главное требование к нему --
чтобы он был законным, иначе он недействителен.2) Есть такое понятие "бизнес-практика", так вот, где-то в
законодательных документах есть ссылка на эту самую практику,
в тех случаях, когда что-либо законом четко не регламентировано
(в настоящее время даже блокировка по RBL уже бизнес-практика).Юристов нужно толковых нанимать на ответственные дела, и...
"пальцы скрещивать", ибо на деле, как давно уже многие поняли, "прав тот,
у кого больше прав". "Басманное правосудие", батенька, это неотъемлимая
часть реальности в стране RU.P. S. "на Бога надейся, а сам не плошай".
/poige
--
http://www.i.morning.ru/~poige/
Полностью и абсолютно согласен.
Только лень провайдеров позволяет до сих пор жить спаму.
И нечего бояться что мол у прова почта плохо настроена, а мне срочно надо..
Плохой пров либо настроит нормально почту, либо потеряет клиента - и это правильно.
>А чего тут можно рассуждать? Ограничить количество отправляемых каждым клиентом-индивидуалом писем:
>- не более двадцати штук в минуту;
>- не более пятидесяти штук в час;
>- не более двухсот штук в сутки.Буду признателен, если вы укажите хотябы один MTA или набор патчей
для которых данная схема будет работать, для начала можно ограничиться только первым пунктом.При этом, должны учитываться клиенты с динамическими IP и нагрузка на систему от таких патчей должна быть на порядок ниже нагрузки от работы самого MTA.
Что, для динамических IP каждому провадеру придется под свой огород писать свои патчи ?
Это ничего, после того как обранужится что реализация подобных лимитов грузит сервер не меньше самого MTA :-)
Не согласны ? Тогда жду от вас URL работающих патчей.
Могу предложить такой глобальный вариант:
Когда приходит письмо со спамом, из него всегда можно выудить ip, с которого оно пришло. Поэтому и отталкиваться от этого ip-адреса.
Я предлагаю ввести ответственность за рассылку спама по ip-адресу.
Т.е. провайдер отвечает за свои ip-адреса. Кроме того, за этого провайдера отвечает организация, предоставившая ему этот(или эти) айпишник. За эту организацию отвечает организация, предоставившая уже ей диапазон адресов, куда входит этот айпишник. И так далее.
Таким образом провайдер должен сам разбираться со своими клиентами. Если он не будет разбираться, то разбираться будут уже с ним.
В качестве меры наказания хватит отключения от интернета [и изъятия диапазона айпишников, откуда была рассылка спама].
Глобальность этой идеи в том, ответственность за рассылку спама с 1 айпишника будет лежать сразу на нескольких организациях. И никто уже не сможет сказать что то типа "я своих клиентов не контролирую, разбирайтесь с ними сами". Но для этого понадобится перезаключить большое количество договоров.