> Электронный журнал "Спамтест" No. 161
________________________________
>
>
> Технология SPF - два года спустя
>
>
> Андрей Калинин, "Лаборатория Касперского"
> <
> 907121604/n/m4696343/-/www.kaspersky.ru/>
>
> Проблема идентификации отправителя
>
>
> За последние несколько лет электронная почта стала настолько
> популярной, что проникла практически во все сферы
> деятельности человека. Электронные письма используются как
> для повседневной болтовни между друзьями, так и для передачи
> чрезвычайно важных сообщений, от которых могут зависеть не
> только благосостояние отправителей и получателей письма, но,
> возможно, их здоровье или даже жизнь.
>
> В то же самое время одна из основных проблем использования
> протокола передачи электронных сообщений (SMTP - simple mail
> transfer protocol) заключается в полном отсутствии
> идентификации отправителя, то есть однозначной проверки того,
> что человек, указанный в конверте письма как отправитель,
> действительно его отправлял. Такой недостаток оставляет
> богатые возможности для использования электронной почты
> мошенниками или для рассылки спама и вирусов.
>
> В качестве примеров писем с поддельными обратными адресами
> можно привести спамовые письма, разосланные по адресным
> книгам пользователей от имени владельцев адресных книг,
> фишинговые письма-подделки под сообщения известных банков,
> которые рассылаются мошенниками с целью получения логинов и
> паролей клиентов банков и т.п.
>
> Основные принципы SPF
>
>
> Технологии SPF и Sender ID появились два года тому назад и
> были предназначены для прозрачной, быстрой и простой
> идентификации отправителя почтового сообщения. Их суть
> достаточно проста: системный администратор в информационных
> полях DNS, связанных с его доменом, публикует правила, по
> которым можно проверить, действительно ли отправитель письма
> с соответствующим обратным адресом посылал его из этого
> домена. Правила достаточно просты и в самом элементарном и
> общеупотребительном случае заключаются в перечислении
> IP-адресов тех серверов, которые могут отправлять почту с
> обратным адресом домена.
>
> На первый взгляд кажется, что проверка письма на соответствие
> SPF-правилам, опубликованным системными администраторами,
> может решить проблему подделки отправителя письма. Однако,
> еще два года тому назад высказывались сомнения в
> работоспособности предложенного решения.
>
> Основным доводом против SPF являлся тот факт, что легитимная
> почта на пути к конечному получателю может отправляться через
> посторонние сервера. Например, это может происходить, если
> получатель письма имеет несколько почтовых ящиков, при этом
> один их них был выбран в качестве основного, а с остальных
> почта перенаправляется на основной адрес средствами почтовой
> системы. В этом случае отправитель письма остается одним и
> тем же, но почтовый релей будет изменен, и проверка на
> корректность отправителя при получении письма будет
> провалена. Если же допустить, что при перенаправлении письма
> отправитель сообщения будет заменяться, то, при наличии
> проблем на основном почтовом ящике получателя, настоящий
> (оригинальный) отправитель письма никогда об этом не узнает,
> так как сообщение о недоставке письма до него не дойдет.
>
> Таким образом, при использовании проверок SPF в качестве
> характеристического метода отвержения почты возможны ложные
> срабатывания. Как будет показано ниже, они не только
> возможны, но и составляют достаточно значительную часть
> почтового потока, что приводит к невозможности использования
> проверок по SPF непосредственно для блокирования нежелательной почты.
>
> Для решения проблемы с перенаправлением почты через почтовые
> сервера была разработана технология SRS (Sender Rewriting
> Scheme), позволяющая отслеживать цепочку серверов и почтовых
> адресов, через которые прошло почтовое сообщение. Однако, в
> отличие от SPF, SRS требует, чтобы каждый из серверов,
> осуществляющих передачу почтового сообщения, поддерживал бы
> технологии SPF и SRS. Это приводит к необходимости
> модифицирования ПО на каждом почтовом сервере в мире, что
> невозможно выполнить практически.
>
> Хотя сомнения в том, что простое решение позволит полностью
> избавиться от недостатков протокола SMTP появились уже два
> года тому назад, в течение 2004-го года практически все
> крупнейшие почтовые системы опубликовали свои политики SPF,
> некоторые начали использовать проверки по SPF в своих
> программных комплексах по борьбе с нежелательной почтовой
> корреспонденцией.
>
> На волне популярности SPF в рамках рабочей группы MARID были
> начаты работы по созданию единого стандарта Sender ID,
> объединяющего SPF и технологию Caller ID, разработанную
> Microsoft. Однако они были быстро свернуты
> <
> 907121604/n/m4696343/-/www.spamtest.ru/news?id=330> в связи
> с проблемами внедрения, вызванными несовместимостями с
> лицензиями open-source, и из-за несовместимости Sender ID с
> классическим вариантом SPF. В июле 2005 года Группа по
> стандартизации интернет-технологий утвердила
> <
> 907121604/n/m4696343/-/www.spamtest.ru/news?id=19666> в
> качестве "экспериментальных" два предложения стандарта
> аутентификации отправителя - Sender ID и SPF. С тех пор
> никаких нововведений в SPF не планировалось.
>
> SPF сегодня
>
>
> Для того, чтобы оценить эффективность SPF, можно привести
> результаты анализа, проведенного на почтовом потоке не очень
> большого хостинг-провайдера.
>
> Анализировались логи за неделю. Для оценки эффективности SPF
> использовались результаты работы антиспам-фильтра, в котором
> проверки по SPF не производятся. При этом предполагается, что
> в период наблюдения этот фильтр не допускал ложных срабатываний.
>
> По статистике антиспам-фильтра, 89% почтовых сообщений
> являлись спамом. Это значение несколько выше, чем средний
> объем спама в Рунете, что связано с большим количеством
> спам-ловушек, установленных у данного провайдера.
>
> Выяснилось, что из общего количества обрабатываемой почты 18%
> сообщений имели SPF-записи для доменов отправителей
> сообщений. Результаты проверки писем, отправленных из доменов
> с SPF-записями, по статусам fail, softfail и pass,
> представлены в таблице 1 (статус neutral мы не рассматриваем,
> поскольку он не информативен).
>
> Таблица 1.
>
> SPF-статус % от писем c SPF % от всего потока
> Пересечение со спамом
> Fail 12% 2% 96%
> Softfail 67% 12% 97%
> Pass 9% 1,6% 20%
>
> Здесь "% от писем с SPF" - это доля писем, получивших данный
> статус, от всех почтовых сообщений, отправитель которых имел
> SPF-запись для своего домена. "% от всего потока" - это доля
> писем, получивших данный статус, от всего почтового потока.
> "Пересечение со спамом" - это доля писем, получивших метку
> "Спам" спам-фильтром, не использующим проверки по SPF, от
> общего количества писем, получивших соответствующий SPF-статус.
>
> Получение почтовым сообщением статуса fail означает, что
> провайдер должен был бы отвергнуть данное письмо как
> несоответствующее опубликованной жесткой политике владельца
> домена. Интересно видеть, что если бы этот статус
> действительно использовался таким образом, то процент
> распознавания спама повысился бы на сотые доли процента. С
> другой стороны, ручной просмотр записей в логах почтовой
> системы по сообщениям, получившим статус fail и не
> распознанным как спам антиспамерским фильтром, выявил, что
> как минимум 1% сообщений со статусом fail были пересылками
> легальной корреспонденции с другого адреса, то есть
> относились к ложным срабатываниям.
>
> Если считать, что другого спама, кроме распознанного
> имеющимся фильтром и статусом fail нет, то количество ложных
> срабатываний по статусу fail в целом составляет как минимум
> 0,2%. На самом деле этот показатель выше, так как наверняка
> был спам, не распознанный ни одним из методов (в этом случае
> уменьшается количество не спамерских сообщений, а доля ложных
> срабатываний, соответственно, возрастает).
>
> Статус softfail не предполагает однозначного отвержения
> письма почтовой системой, но может учитываться дополнительно
> к другим методам. Фактически, из приведенных чисел видно, что
> приблизительно в 0,3% случаев статус softfail мог бы
> чуть-чуть повысить "спамность" письма в терминах
> многокритерального фильтра спама.
>
> Статус pass означает, что отправитель был подтвержден, и, в
> принципе, письмо, получившее такой статус, должно было бы
> быть доставлено получателю. Однако 20% из писем, получивших
> статус pass, были распознаны установленным фильтром как спам.
> Поскольку было сделано предположение об отсутствии ложных
> срабатываний фильтра, то эти письма относились к категории
> нежелательной почтовой корреспонденции. Фактически, это
> означает, что в тех случаях, когда спамеры используют в
> качестве адресов отправителей свои адреса, а не поддельные,
> они могут прописывать для своих доменов нужную для них
> SPF-политику - и спамеры этим пользуются.
>
> Следовательно, как это ни странно звучит, в общем случае на
> этапе приема письма провайдером проверки по SPF практически
> никак не должны влиять на прием письма: получение почтовым
> сообщением статуса fail не означает, что оно должно быть
> отвергнуто; получение статуса pass не означает, что письмо
> должно быть принято.
>
> Таким образом, характеристическая проверка почтового
> сообщения по SPF может производиться только для выделенных
> отправителей, о которых получатель точно знает, что,
> во-первых, он хочет получать от них письма и, во-вторых, что
> их письма будут отправлены на сервер получателя напрямую, без
> пересылки.
>
> Но накладывание таких условий на применение технологии,
> которая должна была бы быть прозрачной для конечного
> получателя, фактически делает эту технологию бесполезной.
> Если сам получатель готов выполнить какие-либо действия по
> идентификации отправителя, то самым простым и действенным
> способом было бы применение средств подписывания отправителем
> почтовых сообщений и проверки подписи на стороне получателя.
>
> Причины неудачи SPF
>
>
> Основная причина неудачи SPF заключается в том, что новая
> технология не удовлетворяет сложившейся практике
> использования почты в достаточно мелком вопросе - пересылке
> писем. Поэтому, несмотря на то, что количество писем,
> перенаправляющихся с одного почтового ящика на другой, в
> общем объеме почты невелико, несовместимость пересылки с
> новой технологией привела к практической бесполезности SPF.
>
> Двухлетняя история развития SPF лишний раз показывает, как
> сложно менять или добавлять новую функциональность в широко
> используемый протокол передачи данных. Технологии,
> предлагающие расширение SMTP, должны обеспечивать полную
> поддержку протокола в самых мелких особенностях, иначе они не
> смогут получить должное развитие.
>
