Технология SPF — два года спустя

Проблема идентификации отправителя

За последние несколько лет электронная почта стала настолько популярной, что проникла практически во все сферы деятельности человека. Электронные письма используются как для повседневной болтовни между друзьями, так и для передачи чрезвычайно важных сообщений, от которых могут зависеть не только благосостояние отправителей и получателей письма, но, возможно, их здоровье или даже жизнь.

В то же самое время одна из основных проблем использования протокола передачи электронных сообщений (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. Однако они были быстро свернуты в связи с проблемами внедрения, вызванными несовместимостями с лицензиями open-source, и из-за несовместимости Sender ID с классическим вариантом SPF. В июле 2005 года Группа по стандартизации интернет-технологий утвердила в качестве «экспериментальных» два предложения стандарта аутентификации отправителя — Sender ID и SPF. С тех пор никаких нововведений в SPF не планировалось.

SPF сегодня

Для того, чтобы оценить эффективность SPF, можно привести результаты анализа, проведенного на почтовом потоке не очень большого хостинг-провайдера.

Анализировались логи за неделю. Для оценки эффективности SPF использовались результаты работы антиспам-фильтра, в котором проверки по SPF не производятся. При этом предполагается, что в период наблюдения этот фильтр не допускал ложных срабатываний.

По статистике антиспам-фильтра, 89% почтовых сообщений являлись спамом. Это значение несколько выше, чем средний объем спама в Рунете, что связано с большим количеством спам-ловушек, установленных у данного провайдера.

Выяснилось, что из общего количества обрабатываемой почты 18% сообщений имели SPF-записи для доменов отправителей сообщений. Результаты проверки писем, отправленных из доменов с SPF-записями, по статусам fail, softfail и pass, представлены в таблице 1 (статус neutral мы не рассматриваем, поскольку он не информативен).

Таблица 1.

Здесь «% от писем с 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, должны обеспечивать полную поддержку протокола в самых мелких особенностях, иначе они не смогут получить должное развитие.