Электронный журнал "Спамтест". Все о борьбе со спамом

Электронный журнал "Спамтест" No. 65 в этом номере: Новости Спам - статистика за неделю 23 - 29 августа 2004 г. Технология SPF - внедрять или подождать? Алексей Тутубалин Новости Новый червь управляет веб-камерами и микрофонами зараженного ПК 24.08.2004 Компания Sophos обнаружила новую модификацию вредоносной программы Rbot. Червь Rbot-GR помимо уже привычных "диверсионных" возможностей - организация DoS-атак, осуществление массовых рассылок спама и пр. - способен управлять подключенными к зараженному компьютеру веб-камерами и микрофонами. Автор вируса может незаметно наблюдать за сидящим перед монитором человеком и даже записывать все его разговоры. Червь Rbot-GR инфицирует машины под управлением Windows, причем вредоносная программа способна распространяться самостоятельно, эксплуатируя ряд уязвимостей в операционной системе, а также используя для доступа к сетевым ресурсам несложные, широко распространенные пароли. При первом запуске червь записывается в системную директорию под видом файла SYSTEMC32.EXE и вносит несколько записей в реестр с целью обеспечения автоматической загрузки. Далее Rbot-GR инсталлирует backdoor-компонент. Через этот "черный" ход злоумышленники могут получить полный доступ к инфицированному компьютеру. В частности, возможны организация DoS-атак на веб-сайты, осуществление массовых рассылок спама, просмотр, загрузка и удаление файлов. Наконец, Rbot-GR может применяться с целью хищения регистрационной информации и ключей к популярным играм, в том числе Counter-Strike, Half-Life, Legends of Might and Magic, Unreal Tournament 2003/2004, Need for Speed, FIFA 2002/2003, Nascar Racing 2002/2003 и Command and Conquer. В Sophos отмечают, что Rbot-GR является шпионской программой нового поколения, которая не только ворует информацию, вводимую пользователем или хранящуюся на жестких дисках, но и обладает достаточной функциональностью для управления периферийными устройствами. Червю присвоен рейтинг средней опасности. Источник: Компьюлента Sophos: "чертова дюжина" стран-лидеров рассылки спама 24.08.2004 По результатам последнего исследования компании Sophos, из США рассылается 42,53% спама. Следующие в рейтинге стран-спамеров - Южная Корея (15,42%) и Китай (11,62%). Компания Sophos (http://www.sophos.com/), предоставляющая услуги фильтрации почтового трафика и антивирусной защиты, провела исследование, в котором анализировалось происхождение спамовых писем, попавших в "ловушки" глобальной сети Sophos, в течение последнего месяца. В результате была выявлена "черная дюжина" стран, из которых рассылается основной объем спама. "Черная дюжина" крупнейших экспортеров спама: Страна % США 42,53% Южная Корея 15,42% Китай и Гонконг 11,62% Бразилия 6,17% Канада 2,91% Япония 2,87% Германия 1,28% Франция 1,24% Испания 1,16% Великобритания 1,15% Мексика 0,98% Тайвань 0,91% Прочие страны 11,76% Судя по полученным результатам, эффективность действующего закона Can-Spam Act крайне низкая - США остаются крупнейшим экспортером спама в мире. При этом, по крайне низкая. Отметим, что по результатам недавних исследований компании CipherTrust, доля "родного" спама, получаемого американцами, может достигать 86%. Некоторый прогресс достигнут в Канаде, где за прошедшие полгода объемы рассылаемого спама удалось снизить почти вдвое - с 6,8% до 2,9%. Много хуже ситуация в Южной Корее: с февраля количество рассылаемого из страны спама возросло в три раза. По-видимому, Южная Корея является перспективным плацдармом для спамеров, поскольку лидирует по числу широкополосных подключений. Специалисты Sophos считают, что спамерами движет жажда наживы, и они заинтересованы в новых точках рассылки. Многие спамеры с помощью хакеров захватывают чужие машины и используют для своих рассылок компьютеры невинных жертв. По оценкам аналитиков Sophos, в настоящее время с "зомбированных" машин с высокоскоростным доступом в Интернет рассылается около 40% всего спама. В опубликованном пресс-релизе подчеркивается, что ни одна из предлагаемых на сегодняшний день мер борьбы со спамом - от судебного преследования спамеров до технологий идентификации отправителя - сама по себе не решит проблему спама. Только объединение технологии, законов, действующих в различных странах, и активных действий пользователей положит спаму конец. Источник: Sophos Троян Mitglieder превращает компьютер в спам-машину 24.08.2004 Компания Symantec сообщает о появлении новой модификации вредоносной программы Mitglieder, который позволяет злоумышленникам использовать инфицированную машину в качестве платформы для рассылки спама. Инфицируются компьютеры под управлением операционных систем Windows 2000, Windows 95, Windows 98, Windows Me, Windows NT, Windows XP. После проникновения на компьютер Троян Mitglieder.О записывает собственные копии с именами foх.exe, norat.exe, winerdir.exe в системную директорию и модифицирует реестр, обеспечивая себе автоматический запуск при старте ОС. Далее Mitglieder.О пытается завершить процессы, связанные со службами безопасности и антивирусными пакетами. Кроме того, троян открывает и прослушивает порт 38883. Специалисты Symantec отмечают, что обычно эта функция используется для рассылки спама. Более подробное описание вредоносной программы здесь. Источник: Компьюлента SurfControl: технологии спамеров постоянно обновляются 26.08.2004 О новых видах мошенничества сообщает антиспамовая компания SurfControl. Чтобы заманить доверчивых пользователей на свои сайты, спамеры использовали в августе популярную олимпийскую тематику и "маскировались" под обновления Google. В общем потоке спама SurfControl обнаружила письма, в которых пользователям предлагалось загрузить последние обновления Google. Жулики обещали, что новые инструменты помогут блокировать всплывающие окна и шпионские программы. При этом загружаемые программы, по оценкам экспертов SurfControl, имели все признаки файлов, инфицированных "серьезным вирусом". Характерным признаком таких писем является персональный обратный адрес (а не адрес компании) и ссылки, которые не только не имеют никакого отношения к Google, но и включают IP-адрес, который использовался в других мошеннических письмах. Темами писем второго вида мошенничества были "Олимпийские игры", "Олимпийские медали" или "Афины 2004". В них якобы предлагались олимпийские сувениры. Как выяснилось, письма отсылали на спамерский сайт, хорошо известный по продажам Виагры. Еще один популярный в августе спамерский трюк - предпочтение вставки картинок HTML-кодированию. Это позволяет обходить антиспамовую защиту, анализирующую тексты писем. Специалисты SurfControl не были удивлены полученными результатами - чтобы добраться до получателей, спамеры постоянно обновляют арсенал приемов. Источник: www.intenetweek.com Американская "веб-ловушка". Каков эффект? 27.08.2004 В ходе операции "Веб-ловушка" по борьбе с преступниками, действующими в сфере высоких технологий, в США арестованы 156 человек, совершившие преступления в 2003-2004 годах. Среди правонарушений - рассылка спама, махинации с кредитными картами, хакерство и онлайн-мошенничество. На пресс-конференции генеральный прокурор США Джон Эшкрофт (John Ashcroft) заявил, что в 2003 г. в США было возбуждено 160 уголовных дел по факту преступлений в компьютерной сфере. От этих преступлений пострадало более 150 тыс. человек, потерявших $215 миллионов. Всего, по словам Эшкрофта, ежегодный ущерб от преступлений в компьютерной сфере в США составляет более $50 миллиардов. Чтобы "захлопнуть" "Веб-ловушку", были объединены усилия правоохранительных органов, представителей интернет-структур и некоммерческой организации National Cyber-Forensics and Training Alliance. Значительная часть операции финансировалась за счет "Ассоциации прямого маркетинга" (the DMA). DMA поздравила Министерство юстиции США и ФБР с успешным завершением операции, в результате которой, по мнению представителей DMA, спамерам стало ясно, что "они могут быть - и будут - найдены, и что их ожидают суровые последствия" незаконной деятельности. Генеральный прокурор Эштон назвал операцию "Веб-ловушка" самой крупной и наиболее успешной акцией против онлайн-мошенничества, воровства персональных данных и других компьютерных преступлений. Однако в праздничном хоре звучат и скептические голоса. Некоторые считают достижения властей запоздавшими и слишком незначительными. Так, Глен Петерсон (Glenn Peterson), представитель McDonough, Holland & Allen PC приветствует проведение операции, однако высказывает опасения, что федеральные власти слишком рано празднуют победу, - их достижения выглядят бледно в сравнении с масштабами проблемы. Кроме того, специалисты предупреждают, что разовой акции, даже с вовлечением столь значительных сил, явно недостаточно. Forbs замечает, что судебное преследование 100 или 150 спамеров никак не решит проблему спама и приводит данные компании Radicati Group, согласно которым, из 68 миллионов ежедневно отправляемых сообщений 35 миллионов являются спамом. По информации Sophos, 43% из них генерируются в США, а это составляет 15 миллионов спам-писем ежедневно и, соответственно, 5,5 миллионов в год. Даже если удастся "прижать" американских спамеров, спам-индустрия переберется в другие страны - Южная Корея и Китай уже сейчас занимают второе и третье место в мире по рассылке спама. И сточник: Reuters Источник: eWeek Источник: Forbs Премьер-министр Австралии разослал политический спам 27.08.2004 Премьер-министра Австралии обвинили в двойных стандартах и нарушении "духа" антиспамового закона: Джон Ховард (John Howard) разослал политический спам избирателям. Для рассылки избирателям Беннелонга писем, содержащих материалы Либеральной партии, премьер-министр нанял компанию Net Harbour, владельцем которой является его сын. Джон Ховард сам финансировал рекламную кампанию, однако уточнить выплаченную сумму отказался, поскольку это касается его "личных денег". Хотя в стране разыгрался настоящий спам-скандал, а антиспам-активисты и оппозиция обвиняют премьер-министра в двойных стандартах и нарушении "духа" антиспамового закона, формально нарушения действующего законодательства не было. Дело в том, что антиспамовый закон, принятый в Австралии, регулирует правила только коммерческих рекламных рассылок и не может быть применен в отношении некоммерческих рассылок зарегистрированной политической партии. В настоящее время руки властей связаны, и они не могут провести расследование на законном основании. Однако, если последуют официальные жалобы от получателей незапрошенной политической рекламы, будет проведен анализ содержания писем. Источник: ZDNet Спам - статистика за неделю 23 - 29 августа 2004 г. Ашманов и Партнеры Объем спама Общий объем спама остается в границах средних значений - от 75 до 85 % на разных почтовых серверах. Распределение спамерских тематик также остается стабильным. Популярные тематики No Тематика Описание %% от общего объема Изменение за неделю 1 Для взрослых Средства для повышения потенции (виагра и пр.), а также для улучшения физических возможностей при занятих сексом 12% без изменений 2 "Здоровый образ жизни" и "Медикаменты" Предложения сбросить лишний вес, улучшить состояние кожи, волос; приобрести правильную осанку, купить биологические добавки и т.п. Предложения приобрести лекарства в online 12% +1% 3 Образование Реклама семинаров, тренингов, курсов 9% -2% 4 Компьютеры и Интернет Предложения приобрести ПО, компьютерную технику, расходные материалы; также предложения для владельцев сайтов (хостинг, обмен баннерами и т.п.) 7% -3% 5 Отдых и путешествия Предложения туристических поездок, а также организации и проведения различных развлекательных мероприятий. 5% +3% 6 Личные финансы Предложения по страхованию, уменьшению кредитной задолженности, выгодным условиям займов и т.п. В подавляющем большинстве англоязычные письма. 4% -3% 7 Услуги по электронной рекламе Предложения организовать спамерскую рассылку, программы для рассылок, базы электронных адресов и т.п. 4% без изменений Письма недели Самое необычное предложение "Привет" Продаем честно накарденное! Всего за ~30% от реальной стоимости в обычных интернет-магазинах. Наш адрес - {LINK} Самые массовые По количеству разосланных экземпляров, а также по количеству повторов (одинаковых сообщений в одном и том же ящике) письма недели - лидируют письма "Английзский с преподавателями из С Ш А" и "вам доставлено сообщение". Эти письма вы найдете на сайте Спамтест. "вам доставлено сообщение" Это типичное объявление из сферы недвижимости "молодая семья снимет квартиру без посредников...". Мы часто встречаем такие бумажные объявления, расклеенные на столбах и остановках. Так же как и в случае бумажных объявлений, это письмо - фальшивка, за которой скрывается тот самый "посредник" или агентство по недвижимости. На сайте Спамтест приведены несколько экземпляров письма. Молодые пары везде указаны разные, а телефон один и тот же, да и стиль вполне узнаваем. Технология SPF - внедрять или подождать? Алексей Тутубалин Ашманов и Партнеры Введение В последние месяцы технология SPF (Sender Policy Framework) получила мощную публичную поддержку во многих изданиях. Вероятно, наиболее существенную роль в этом сыграла поддержка стандарта SPF/SenderID компанией Microsoft - в результате многие западные игроки интернет-рынка поспешили "засветиться" вместе с Микрософтом. В большинстве публикаций верификация отправителя с помощью SPF преподносится как "серебряная пуля" - как технология, способная решить проблему спама раз и навсегда. На самом деле это не совсем верно, или даже совсем неверно, поскольку SPF, решая одни проблемы, создает другие (это вообще свойство любых новых технологий). Наличие серьезных проблем в применении стандарта SPF при практическом отсутствии критических публикаций вынудило автора написать статью "Технология SPF - за и против". В этой статье много внимания было уделено как проблемам SPF, так и рекомендациям по относительно безболезненному их решению. Вышеуказанная статья вызвала бурные отклики, на которые нужно ответить. Кроме того, автором были накоплены дополнительные данные о применимости SPF в сегодняшних условиях. Все это требует повторного обращения к данной теме. Таким образом, настоящую статью следует рассматривать как дополнение (или как продолжение дискуссии) к предыдущей статье. Чтобы не заставлять читателя перечитывать предыдущий текст, необходимо здесь (максимально кратко) изложить самые общие сведения об SPF: Технология SPF предназначена для верификации отправителя электронного письма. Верификация отправителя происходит путем сравнения данных отправителя о возможных источниках письма из данного домена с реальным IP-адресом отправляющей стороны (в SMTP-сессии). Данные о возможных источниках (SPF-политику) публикует администратор домена путем внесения дополнительных записей в систему DNS. Результатом анализа SPF-политики на принимающей стороне является SPF-статус сообщения, который может иметь одно из следующих значений: Pass - отправитель сообщения не подделан (согласно анализу SPF-политики). Softfail - сообщение не отвечает "жестким" критериям достоверности отправителя, но нельзя и быть уверенным, что отправитель подделан. Fail - отправитель подделан. Прочие варианты (None, Neutral , Unknown, Error) - не вдаваясь в детали скажем, что все эти варианты примерно эквивалентны, и можно считать, что в данных случаях SPF-политика отсутствует. 1. Эффективность SPF как антиспам-средства При использовании SPF в качестве антиспам-средства результат анализа SPF-политики можно использовать несколькими способами: Использование "впрямую", без учета прочих свойств сообщения (SPF-fail: отвергаем письмо, pass: пропускаем). Использование совместно с другими средствами анализа. Полученные из анализа SPF-политики данные могут быть учтены в комплексной антиспам-системе как дополнительные свойства письма; решение о классификации письма как спама будет приниматься с учетом других параметров сообщения. Первый способ, очевидно, будет применяться в простых антиспам-системах, возможно, по очереди с другими жесткими методами (например, сначала проверяем по RBL, если письмо не отвергнуто, - по SPF, потом по Байесу; другими словами, все используемые антиспам-методы независимы друг от друга). Далее этот случай рассматривается в разделе "SPF как независимое антиспам-средство". Второй способ заключается в том, что сначала производится получение данных от всех используемых антиспам-методик, а затем - их комплексный учет (например, как в известном антиспам-фильтре SpamAssassin - каждое правило дает сколько-то "очков", решение о статусе письма принимается по сумме очков). Такое поведение характерно для сложных антиспам-систем, применяемых в первую очередь в крупных почтовых сервисах и у провайдеров (ISP). В таких организациях антиспам-система критична для бизнеса, и на ее настройку можно потратить значительные ресурсы. Этот случай рассмотрен ниже, в разделе "Использование SPF совместно с другими антиспам-средствами". Независимо от способа использования политик SPF, эффективность технологии SPF будет определяться распространенностью самой технологии, и "средней" по Интернету SPF-политикой. Определить эти параметры можно только экспериментальным путем - анализируя доступные потоки почты. 1.1. SPF-статусы в потоке почты Автор проанализировал SPF-статусы у 20464 спам-сообщений и 990 не-спам сообщений, пришедших к нему в течение 5 недель летом 2004 года. Обе выборки были просмотрены вручную, с тем, чтобы в выборке спама не было нормальных сообщений и наоборот . Было получено следующее распределение статусов SPF: Таблица 1 Доля сообщений с таким статусом SPF-статус Спам Нормальная почта None 89.34% 91.86% Softfail 4.57% 0.85% FailFail 3.21% 0% Neutral 1.45% 1.11% Unknown 0.93% 0.12% Pa/ss 0.42% 5.88% Error 0.08% 0.15% Из этих данных следуют два интересных вывода: Довольно много спам-сообщений (0.42% из 10.66%) c точки зрения технологии SPF являются легальными (статус pass). Считать сообщения спамом только на основании статуса softfail нельзя, это может дать почти 1% ложных срабатываний. Конечно, автор отдает себе отчет, что выборка личной почты может быть смещенной (ниже приводятся данные по второй, довольно представительной выборке из нескольких миллионов сообщений на публичном почтовом сервисе). 1.2. SPF как независимое антиспам-средство Автор имел возможность проанализировать SPF-статус 8 миллионов E-mail сообщений, полученных на одном из крупных почтовых сервисов в течение нескольких дней августа. Из рассмотрения были исключены сообщения от пользователей системы, рассматривался только поток из внешнего мира. Согласно полученным данным, SPF-статус отличный от none (none означает, что SPF не поддержан на стороне отправителя) для данного потока почты имеют на сегодня 8.35% всех сообщений. Все прочие SPF-статусы распределились таким образом: Таблица 2 Статус сообщения по SPF Доля таких сообщений в общем потоке почты softfail 3.244% pass 2.327% Fail 1.456% neutral 0.801% Unknown 0.514% Error 0.012% Как видно из таблицы, интересный с точки зрения борьбы со спамом статус (pass или fail) имеют 3.8% всех сообщений. Это и есть оценка сверху эффективности SPF в качестве антиспам-решения на сегодняшний день. Каким бы способом не учитывалась политика SPF в антиспам-средствах, только одно сообщение из 26 имеет сколько-нибудь "интересный" статус. 1.3. Использование SPF совместно с другими антиспам-средствами Рассматривая использование SPF в качестве источника дополнительных данных для комплексной антиспам-фильтрации, необходимо учитывать современный уровень технологий фильтрации спама - без использования SPF. Вот каковы в настоящее время средние параметры подобных систем: Качество распознавания спама - на уровне 85-98% и более. Доля ложных срабатываний - 0.01% и ниже. Как говорилось выше, при использовании SPF совместно с другими способами фильтрации спама польза от заключения фильтра, основанного на проверке политики SPF, будет крайне небольшой - поскольку значимый SPF-статус имеют всего несколько процентов сообщений. Из показателей "обычных" фильтров видно, что при этом большая часть спама может быть определена и без использования SPF-данных. Следовательно, нам интересны только те случаи, когда SPF-статус письма и результат анализа по другим признакам противоречат друг другу - тогда вклад от SPF может оказаться существенным для изменения классификации сообщения. В таблице приведены данные классификации рассматриваемой подборки из 8 млн. сообщений, проверенных фильтром Spamtest, и их SPF-статусы. В таблице 3 приведены данные только по тем письмам, которые имеют статус по SPF, отличный от нейтрального статуса (т.е. neutral, none или ошибка). Доли показаны относительно всего потока почты. Таблица 3 Статус SPF Статус Spamtest Pass Softfail Fail Not Spam 1.889% 0.293% 0.292% Probable Spam (возможно, спам) 0.161% 0.165% 0.124% Spam 0.277% 2.786% 1.039% Жирным шрифтом в таблице выделены те случаи, когда статус по SPF и статус, полученный анализом других признаков письма, противоречат друг другу. Как мы видим, SPF может помочь антиспам-фильтру "поймать" спамерское письмо менее чем в 1% всех случаев - это и есть оценка сверху эффективности SPF как добавки к имеющемуся антиспаму. Впрочем, с тем же успехом SPF может, наоборот, помешать анализу. Как показано выше, ложный (с точки зрения классификации спам/нормальная почта) статус Pass был получен для 0.42% спам-сообщений, и ровно эту величину мы видим в таблице 3 (0.277 + 0.161%). С точки зрения улучшения качества антиспам-системы, интереснее всего сочетание Not Spam/SPF fail и Not Spam/SPF softfail в таблице 3. В эти категории попадают: Пересылаемые (forward) сообщения c жесткой политикой отправителя (для статуса fail), либо пересылаемые сообщения с мягкой политикой отправителя (softfail). Спам, пропущенный фильтром. Какой-либо дополнительной информации, позволяющей разделить эти два случая, SPF нам не дает. Другими словами, принять решение о статусе письма антиспам-фильтр должен на основании других данных - как и в случае отсутствия SPF у отправителя. Вместе с тем, SPF обладает несомненной пользой как способ обратной связи между антиспам-фильтром и отправителями не-спам сообщений (включая сюда подписные массовые рассылки). В частности, при детектировании сообщений по частотности (повторяемости) подписные неанонимные рассылки (не спам) и спам-сообщения воспринимаются антиспам-системой одинаково. Использование SPF как "белого списка" поможет такие случаи различить. Впрочем, не следует забывать, что этот механизм будет доступен всем, в том числе и спамерам (и для рассылки спама уже используется). Выводы Использование SPF в качестве самостоятельного спам-фильтра на сегодня неэффективно. Общий уровень поддержки технологии находится в пределах 10% от общего почтового трафика, а сообщений с таким SPF-статусом, который можно использовать для независимой от других свойств письма классификации сообщения, - вообще единицы процентов. Использование SPF в качестве дополнения к имеющейся комплексной антиспам-системе еще менее эффективно - доля сообщений, на которых SPF дает вклад в классификацию спам/не-спам, составляет в лучшем случае 1%, причем эта величина того же порядка, что и уровень ошибочной классификации письма на основании SPF. Таким образом, заметный вклад в качество антиспам-системы может дать только использование SPF в качестве защиты от ложных срабатываний (то есть в виде "белого списка", возможно с небольшим весом). При этом следует учитывать, что SPF-механизм доступен для использования всеми, в том числе и спамерами. 2. SPF и пересылки почты Проблема пересылок почты является наиболее серьезным препятствием на пути внедрения SPF. Суть ее заключается в том, что при пересылке почты через "посредников", третье (и далее) звено пересылки получают сообщение вовсе не с тех адресов, которые разрешены SPF-политикой отправителя. При этом отправитель, как правило, не знает, через каких посредников пройдет его письмо, и не может добавить их список к своей SPF-политике. В качестве посредников могут выступать: Сервисы пересылки сообщений (почтовые сервисы, сервисы "одноразовых" адресов, просто пересылка почты со старого рабочего адреса). Резервные почтовые серверы (backup relays). Почтовые серверы провайдера - в случае, когда пользователь использует собственный адрес, а почту шлет через сервер провайдера. Во всех этих случаях в проверке SPF участвует адрес (домен) отправителя и IP-адрес пересыльщика. В результате, если в SPF-политике отправителя указано ': список... -all', то это будет истолковано как прямое пожелание отправителя не принимать пересылаемые письма. Как правило, на самом деле отправитель желает чего-то другого и просто не принимает во внимание проблему пересылок. Для решения проблемы пересылок предложены такие решения: Изменение программного обеспечения на тех машинах, которые занимаются пересылкой, таким образом, чтобы они пересылали письмо уже от своего домена. Наиболее известным предложением на эту тему является схема подстановки имени домена под названием SRS (Sender Rewriting Scheme, www.libsrs.org). Изменение SMTP-протокола: сохраняя адрес отправителя в неприкосновенности, передавать дополнительный атрибут "пересылается от имени такого-то" - и проверка по SPF дополнительного атрибута. Пересыльщики должны добавлять дополнительные заголовки в сообщение (многие это уже делают), а на приемной стороне нужно пытаться извлекать адрес пересыльщика именно из этих дополнительных заголовков. Все три способа требуют модификации программного обеспечения почтовых серверов везде, где может происходить пересылка. То есть практически везде. Следует также заметить, что простой подменой отправителя проблему решить нельзя: сохранение адреса исходного отправителя часто необходимо. В процессе пересылки сохранение адреса отправителя используется, например, для доставки почтовых квитанций (о недоставке или о доставке). Таким образом, простая подмена адреса отправителя на транзитном сервере не годится, нужен более сложный механизм, чтобы обеспечить доставку квитанций обратно вдоль всего пути, но не открыть при этом "открытый релей" на исходного отправителя. Модификация SMTP-протокола является более разумным решением. Проблема в том, что имеющиеся предложения пока являются только предварительными версиями описаний. Реализаций нет. Извлечение необходимых данных из заголовков письма не требует изобретения новых сущностей, но означает, что письмо нужно сначала принять, потом определить транзитного отправителя, а потом - принять решение о приеме письма. Резюмируя: на сегодняшний день не существует легкого решения проблемы совместимости SPF и легальных пересылок почты. Предлагаемые решения далеки от совершенства, вероятность их массового внедрения за короткое время представляется невероятной. Тот факт, что из-за SPF сегодня происходит недоставка почты, глупо подвергать сомнению - это происходит, и прецеденты автору известны. Проблема пересылок является наиболее болезненной для технологии SPF и сторонников ее внедрения, наибольшее число откликов на первую статью касалось именно этой проблемы. В целом возражения сводятся к следующим положениям: Большинство пересыльщиков уже поддержали подмену отправителя. А остальные - обязательно сделают это очень быстро, за один-два года. Пересылаемой почты очень немного, около 1%. Следовательно, проблема пересылок раздута. Если пересылаемое письмо не будет принято, то отправитель получит квитанцию, прочитает ее и будет знать, куда на самом деле нужно слать почту. И перешлет ее туда еще раз. Таким образом, проблема касается только писем, генерируемых автоматическими системами, а их совсем немного. Раз отправитель письма указал в политике -all, значит такова его воля, письмо должно быть утеряно. Пользователи сами теряют много почты (из-за неверных настроек серверов, неверно введенного адреса и пр.), и на этом фоне потери пересылок будут незаметны. Другие способы антиспам-фильтрации, например черные списки, имеют еще большую долю ложных срабатываний. Отвечаю по порядку: Кто-то из пересыльщиков схему подмены отправителя SRS наверняка поддержал. Но вообще таких немного. Проанализировав лог с данными одного миллиона сообщений (адресов From), автор обнаружил только два домена, поддержавших "классический SRS" (по From: SRS1=:), всего с них обнаружено 30 писем (на миллион). Тогда как доля пересылаемого трафика составляет порядка 1%, то есть 10 тысяч на миллион. Понятно, что кроме классического SRS есть другие методы формирования транзитных адресов, но SRS сейчас активно продвигается, и результаты должны бы быть более впечатляющими. Однако значимой поддержки SRS не наблюдается. Пересылаемых писем действительно не так много - оценка "в районе одного процента" дает правильный порядок величины. Хотя даже 1% - довольно много, если сравнивать с уровнем ложных срабатываний хороших антиспам-систем (0,01% - 0,0001%). Проблема в том, что у тех, кто использует пересылку, доля пересылаемых писем во всем объеме их почты может быть и 100% (был старый адрес, стал новый, а на старом - пересылка). Если вдруг на их реальном адресе появится жесткая проверка SPF (если, например, ее включит провайдер), то такие пользователи начнут терять входящую корреспонденцию. Сначала - немного (т.к. проверка SPF поддержана малым числом отправителей), потом все больше и больше. При этом и на стороне отправителя, и на стороне конечного получателя все хотят как лучше. Идея о том, что отправитель сообщения прочтет квитанцию о недоставке, поймет, куда на самом деле нужно доставлять сообщение, и переадресует его, требует развернутого комментария: Системные администраторы - поймут. Но Интернет продолжает расти, доля совсем новых пользователей - довольно большая, а вот они точно не поймут. Да и стандартная (предлагаемая по умолчанию) SPF-квитанция отсылает на англоязычный spf.pobox.com, что для Рунета - не решение. Собственно, если способ с квитанцией кажется разумным, то почему не внедрить TMDA или какой-то другую карантинную систему с запросом подтверждения от автора письма? Отправитель прочтет квитанцию, нажмет кнопку "я не спамер", и письмо дойдет. Однако системы с подтверждением считаются неприемлемыми - потому что порождается много паразитного трафика, а на кнопку подтверждения почти никто не нажимает. Почему же гораздо более сложные действия (прочитать квитанцию, перенаправить письмо по другому пути) - приемлемы? Насколько мне известно, те же люди, которые всерьез защищают идею "отправитель прочитает квитанцию", являются одновременно жесткими противниками систем с подтверждениями. Довольно часто встречается случай, когда сообщение является важным для получателя, но практически безразлично для отправителя. То есть отправитель письмо написал, отправил и тем считает свой долг выполненным, а если получатель не может их получить - то это его проблема. В этой ситуации отправитель читать квитанцию и перепосылать письмо не будет. Остаются еще автоматические системы - заказы в интернет-магазинах, регистрация на сервисах и т.п. Ирония заключается в том, что для общения с такими системами часто используются "одноразовые" адреса - пригодные для получения регистрационного письма и не более того. Это делается для предотвращения спама на регистрационный адрес. Одноразовые адреса, естественно, делаются через механизм пересылки. Отправитель мог указать -all вовсе не по той причине, что он не любит пересылки. Так рекомендуется в документации, а о проблеме пересылок он мог и не задуматься. Более того, SPF-политику часто формулируют одни люди (системные администраторы), а страдают от нее - другие (сотрудники той же организации). То, что пользователи теряют какое-то количество почты самостоятельно (наиболее часто встречающаяся оценка - 0.1%) не означает, что прочие почтовые технологии должны тоже терять почту. Не стоит усугублять проблему. То, что какие-то способы фильтрации спама не хороши, не означает, что нужно делать так же плохо в других системах фильтрации. Выводы Несмотря на все описанные выше ужасы, решение, пригодное для массового внедрения отправителями, имеется. Оно заключается в публикации мягкой SPF-политики по умолчанию (т.е. политика должна заканчиваться на ?all или ~all). Судя по всему, так сейчас все и делают - доля статусов softfail и neutral втрое выше, чем у fail (табл. 2). Проблема только в том, что это резко снижает эффективность SPF. Второе решение заключается в широком использовании exists - но на сегодня для этого нет готовых решений, придется программировать самостоятельно. Exists, впрочем, создает свои проблемы (см. раздел 5.2). Мнение автора: имеющиеся проблемы с пересылаемой почтой приведут к массовому внедрению более мягких SPF-политик, чем это могло бы быть сделано. Авторам технологии SPF следовало бы решить проблему заранее (или выбрать другую технологию), а сегодняшняя ситуация приведет к тому, что SPF будет куда менее полезной для борьбы со спамом, чем это было бы возможно. 3. SPF-политики "по умолчанию" Суть проблемы "политики по умолчанию" заключается в следующем: Стандарт SPF сейчас поддерживает достаточно мало отправителей, поэтому его эффективность невелика. Сам механизм - достаточно удобен, хочется его использовать для всей поступающей почты. В результате, во многих поддерживающих SPF почтовых серверах можно задать "политику по умолчанию" (обычно ее называют best guess) - т.е. при отсутствии SPF-политики у домена, почтовый сервер попытается ее угадать сам. Сама по себе идея умолчаний - не так плоха, если используются такие значения, которые не могут ухудшить ситуации. Другими словами, если используются только разрешительные умолчания (например, 'a/24 mx/24 ?all'). Однако, разрешительные умолчания не решают задачи борьбы со спамом (так как ничего не запрещают), а цель внедрения SPF - именно антиспам. В результате, в настоящий момент массово внедряются умолчания вида 'a/24 mx/24 -all', означающие, что почту от домена можно принимать из подсети (диапазона IP-адресов), где расположен сервер домена (обычно это Web-сервер), а также из подсети, где расположены почтовые серверы домена, и более ниоткуда. Таким образом, если у какого-то отправителя почтовые серверы "на прием" и почтовые серверы "на отправку" расположены в разных подсетях, то почта с такого домена приниматься не будет, даже если она легальна. Данная проблема не связана с технологией SPF как таковой, она связана с конкретными реализациями технологии и конкретными системными администраторами, которые настраивают излишне-жестокие правила фильтрации. Похожая проблема связана с использованием "политических" RBL-списков (SPEWS и подобные). Таким образом, с учетом "угадывания" SPF политики на принимающей стороне публикация какой-либо (мягкой) SPF-политики может оказаться лучше, чем ее отсутствие. 4. SPF Classic? SPFv1?? SPF2.0??? Технология на марше... Официальный сайт по SPF (spf.pobox.com) предлагает два описания стандарта - marid-protocol-00 (текущая версия протокола по версии spf.pobox.com), от 11 июля 2004 года и 'SPF-classic' от мая того же года. Одновременно, рабочая группа MARID предлагает уже более новую версию стандарта SenderID - marid-protocol-02 от 13 августа текущего года. К удивлению автора, новая версия протокола несовместима со старой, в частности: Предлагается публикация SPF-данных в специальном типе DNS-записей SPF2. При этом допускается публикация в предлагавшемся ранее типе записей TXT. Предлагается новая спецификация версии протокола: вместо старой строки версии (v=spfv1) предлагается новая (spf2.0/pra). Новая спецификация версии является несовместимой с имеющимися реализациями протокола (libspf, libspf2, rmspf). При этом описание SPF-classic официально устаревает в сентябре 2004, marid-protocol-00 - в январе 2005. Возникает резонный вопрос: какая версия протокола должна быть выбрана, если я прямо сегодня хочу опубликовать SPF-записи в DNS? SPF-Classic или SPF/2.0? Первая - поддержана в программном обеспечении, но устаревает через месяц. Вторая - нигде не поддержана пока, но это явно - mainstream. Ответа на этот вопрос у автора нет, он просто хочет обратить внимание читателей на тот факт, что описание технологии еще явно не устоялось, слишком раннее внедрение имеющихся реализаций может привести к тому, что через небольшое время придется перевнедрять. 5. Прочие проблемы В недавней публикации сотрудников Яндекса "Для чего нужен SPF", оспариваются следующие тезисы: Поддержка SPF при приеме почты создает избыточную нагрузку на DNS, что может быть проблемой. SPF-правило 'exists' является проблемой с точки зрения безопасности получателя почты. Полученная критика требует ответов, которые приведены далее. 5.1. SPF и DNS Поддержка SPF на стороне получателя вынуждает почтовый сервер получателя делать DNS-запросы для получения SPF-политики отправителя. Конечно, почтовый сервер делает и другие DNS-запросы, например, получает имя посылающего сервера по его IP-адресу (это необязательно, но практически всегда делается), а также, возможно, делает запросы к RBL. Как известно на примере RBL, крупные почтовые сервисы вынуждены кэшировать DNS-запросы, то есть держать у себя локальные копии используемых RBL-списков, а не обращаться к ним удаленно. Это делается именно по той причине, что DNS-запрос может быть достаточно долгим. Скажем, при потоке в 100 сообщений в секунду, каждая лишняя секунда ожидания в почтовом сервере добавляет 100 лишних копий почтовой программы на принимающей стороне. А ведь DNS-таймаут в стандартном DNS-клиенте - до 75 секунд. Но в отличие от RBL-_баз, сделать локальную копию всех SPF-записей всего мира - мягко говоря, затруднительно. Таким образом, мы создаем второй "тяжелый" DNS-запрос, т.е. увеличиваем нагрузку минимум вдвое. В случае нормального функционирования DNS, создаваемая SPF дополнительная нагрузка может быть и приемлемой. А может быть - неприемлемой, если без SPF загрузка почтового сервиса и так была близка к предельной. Проблемы начнутся, например, если DNS-сервер домена отправителя не отвечает. Более того, таким образом совершенно нетрудно провести DoS-атаку на получателя почты, так как DNS-серверы, к которым будет обращаться SPF-модуль на приемной стороне, выбираются именно отправителем (подстановкой нужного домена отправителя). Делается это так: выбираем (или делаем) домен с DNS-сервером, который не отвечает на запросы, затем шлем письма с отправителем из такого домена и наблюдаем, как почтовые серверы получателя ждут окончания DNS-таймаутов. 5.2. SPF-метод exists и безопасность При использовании метода exists, предусмотренного стандартом SPF, отправитель может, при правильном использовании SPF-макросов, получать следующие данные со всех пунктов пересылки сообщения: IP-адрес пересылающей стороны (будет в DNS-запросе); E-mail отправителя (в DNS-запросе); IP-адрес получателя (в адресе, с которого пришел DNS-запрос). Естественно, все эти данные приходят только с тех почтовых серверов, где включена поддержка SPF. Таким образом, если кто-либо хочет изучить структуру пересылки почты внутри какой-то компании, то он может а) выбрать домен и создать к нему SPF-запись с exists; б) послать сообщение с отправителем из выбранного домена. Допустима ли подобная "открытость" компании - пусть решают специалисты по безопасности. Вторая проблема связана с возможностью верификации спам-баз спамерами. Используя exists, можно быстро проверить адреса в домене (опубликовавшем запись с exists) на актуальность. На это рассуждение обычно возражают, что путем простой посылки почты на изучаемый почтовый сервер тоже можно провести такую проверку. Однако: Сегодняшние почтовые сервера с такой практикой все-таки борются, вставляя задержку перед ответом на Mail from. То есть проверять даже по 10 адресов в секунду не получится. А через exists - получится. Провести проверку через exists можно полностью анонимно, используя многочисленные DNS-серверы, разрешающие запросы всем желающим (лог-файлов на DNS-запросы обычно не ведут). В случае верификации через SMTP анонимности нет. 6. Выводы. Поддерживать ли SPF прямо сегодня? Поддержка SPF заключается в двух независимых действиях: Публикация SPF-записей для домена. Это затрагивает исходящую из домена почту. Поддержка SPF в почтовом сервере при приеме почты. Включение такой поддержки повлияет на процесс приема почты. 6.1. Публикация SPF-записей Публикация SPF-политики, несомненно, полезна. Даже если вы не страдаете от спама, рассылаемого от имени вашего домена, явное описание легальных источников почты из вашего домена может помочь прохождению легальной почты от вас через антиспам-фильтры, особенно если на принимающей почту стороне используют додумывание SPF-политики за вас (best guess). Описывая SPF-политику, следует явно включить в нее все ваши серверы, с которых может исходить почта. Более простое решение заключается в описании всего адресного пространства. Ваша SPF-политика должна быть "мягкой" т.е. оканчиваться на ?all или ~all. В противном случае, у вас могут возникнуть проблемы с теми письмами из вашего домена, которые пересылаются (forward) на пути к адресату. Слишком мягкая политика "по умолчанию" тоже может быть воспринята неверно. Если в вашей SPF-политике будет указано +all (т.е. вы явно хотите сказать всему миру, что письма из вашего домена могут приходить откуда угодно), то есть неплохой шанс, что такая политика будет проигнорирована - ибо домены с такими SPF-записями уже используются спамерами. 6.2. Использование SPF при приеме почты При использовании SPF на стадии приема почты необходимо учитывать такие соображения: Распространенность SPF в настоящее время невелика, не более 10% сообщений (в среднем потоке) будут иметь SPF-статус. Использовать статус softfail как признак спама не следует, достаточно большая доля нормальной почты имеет такой статус. Возможны ложные срабатывания на пересылаемой (forward) почте. Заметное количество спам-почты уже сейчас имеет статус pass, имеет смысл игнорировать '+all' в SPF-политике отправителя. Другими словами, использовать SPF в качестве дополнительного признака при фильтрации спама - можно. Принятие решений на основе только SPF не принесет большой пользы при фильтрации спама, но может привести к отвержению нормальной почты.   Написать письмо Прислать статью редактору Мнение редакции не всегда совпадает с мнением авторов материалов. Редакция оставляет за собой право не публиковать присланную статью без объяснения причин. Присланные статьи не рецензируются. (C) ЗАО "Ашманов и Партнеры", 2003-2004