Дополнительная помощь в борьбе со спамом

Обычным пользователям часто бывает трудно понять, почему ИТ-специалисты не могут раз и навсегда решить проблему спама. Но тому, кто имеет большой опыт работы с компьютерами, ясно, что борьба со спамом сродни скорее шахматной игре, требующей терпения и аналитических способностей, чем игре в футбол. По мере совершенствования средств борьбы с потоком непрошеных сообщений, авторы спама изобретают все более хитроумные способы, чтобы обходить преграды.

Большинство инструментов идентифицируют спам после того, как послания уже приняты сервером для доставки — данный подход создает значительную нагрузку на серверы и каналы связи, к тому же отнимает массу времени у пользователей, которым приходится сортировать весь не отфильтрованный вовремя «мусор». Основная часть спама распространяется путем подмены адреса отправителя, спуфинга, поэтому в борьбе со спамом очень бы пригодился метод определения ложных соединений. В идеальном случае сервер должен установить, имеет ли система-отправитель разрешение на рассылку почтовых сообщений в домене DNS, частью которого она себя объявила. Такой инструмент позволил бы почтовым серверам ответить на вопрос: откуда в действительности отправлено сообщение?

Частичный ответ на него дают два похожих протокола — Sender Policy Framework (SPF) и Sender ID. С их помощью можно установить, из какого домена отправлено сообщение. Прежде чем подробно рассмотреть работу и возможности этих протоколов, коротко напомню их историю.

SPF, Caller ID и Sender ID

В 2003 году Мен Вен Вон начал выступать на конференциях с сообщениями об SPF — новом протоколе для борьбы со спамом. Протокол получил поддержку специалистов (в основном ориентированных на UNIX) и начал приобретать популярность среди различных Internet-провайдеров, организаций и провайдеров услуг по борьбе со спамом. Чтобы не отстать, компания Microsoft в феврале 2004 года опубликовала стандарт Caller ID for E-mail. У Caller ID for E-mail было одно важное техническое преимущество — для указания отличительных признаков серверов в протоколе использовался не простой текст, а формат XML. Несмотря на технические различия между двумя протоколами, цель у них общая: помочь почтовому серверу установить источник отправляемых сообщений. И сторонники SPF, и разработчики Microsoft поняли, что наличие двух систем неэффективно, и добиться победы над авторами спама легче с помощью унифицированной системы. Поэтому в июне 2004 года было объявлено о подготовке рабочей группой Internet Engineering Task Force (IETF) проекта спецификации Sender ID, унифицированной системы, сочетающей в себе возможности SPF и Caller ID for E-mail. SPF уже широко используется, но будущее — за Sender ID, в первую очередь потому, что протокол, вероятно, будет одобрен IETF в течение 2005 года.

Поэтому в данной статье речь идет в основном о Sender ID (хотя в некоторых случаях отмечаются существенные различия между этим протоколом и SPF). В отличие от SPF и Caller ID for E-mail, SPF и Sender ID предназначены для решения разных проблем: SPF ориентирован исключительно на формирование барьера для спама, а Sender ID расширяет диапазон доменных проверок, чтобы воспрепятствовать некоторым приемам мошенничества и спуфинга (в том числе атакам с поддельным URL — phishing attack).

Как работает Sender ID

Большинству читателей уже известно о серверных проверках, с помощью которых можно определить, является ли сообщение спамом. Например, Exchange Server обеспечивает обратное преобразование DNS для входящих сообщений и отвергает сообщения, в которых отсутствует запись DNS PTR. В распоряжении администратора имеются также разнообразные инструменты, которые анализируют заголовки сообщений и указывают на признаки спама. Компания Microsoft вложила немалые средства в разработку технологии SmartScreen, которая используется в Exchange Intelligent Message Filter (IMF), Hotmail и Microsoft Office Outlook 2003 Junk E-mail Filter.

Однако в SPF и Sender ID применяется иной подход. Предполагается, что каждый владелец домена DNS публикует записи, указывающие, откуда в этот домен поступают почтовые сообщения. Например, в простейшем случае можно опубликовать запись, которая, в сущности, гласит: «Все сообщения поступают с серверов, зарегистрированных в MX-записях для моих доменов». Эта запись соответствует MX-записи, указывающей, куда отправлять почтовые сообщения для конкретного домена. Система сопоставляет успешные процессы для физической почты. Разработчики SPF используют аналогию с письмом, на котором указан отправитель Amazon.com (компания, расположенная в Сиэттле), но приклеена нигерийская марка. У получателя возникнут вполне обоснованные сомнения в подлинности этого письма. Такие же подозрения возникнут и в отношении сообщения, отправленного, судя по надписи на конверте, компанией Citibank, но пришедшего из Китая.

Принцип действия Sender ID прост. Сначала владелец домена DNS публикует запись DNS TXT, которая содержит информацию Sender ID. Сделать это требуется лишь один раз (данный процесс описан в следующем разделе). Затем пользователи посылают почтовые сообщения как обычно; протокол Sender ID работает незаметно для них. Получив сообщение из домена, для которого была опубликована запись DNS TXT, сервер, использующий SPF или Sender ID, извлекает адрес PRA (Purported Responsible Address — предполагаемый адрес отправителя), или, иными словами, адрес почтового ящика, который объявлен как отправитель сообщения. В соответствии со спецификацией Sender ID, сервер-получатель должен определить PRA, проверяя заголовки сообщения в следующем порядке.

  1. Заголовок Resent-Sender. Если имеется непустой и действительный заголовок Resent-Sender (например, содержит только один адрес IETF Request for Comments — RFC — 2822) и нет никаких других заголовков, то следует использовать этот заголовок как PRA. Если непустой заголовок Resent-Sender существует, но недействителен, требуется отвергнуть сообщение, не определяя PRA. Если заголовок Resent-Sender отсутствует или следует за заголовками Resent-From и Received или Return-Path, то не нужно исследовать заголовок Resent-Sender. Вместо этого рекомендуется проводить остальные проверки до тех пор, пока не будет определен PRA или сообщение не будет окончательно отвергнуто.
  2. Заголовок Resent-From. Если существует непустой, действительный заголовок Resent-From, то следует использовать его в качестве PRA. Если заголовок Resent-From искажен или содержит несколько почтовых ящиков, нужно отвергнуть сообщение, не определяя PRA.
  3. Заголовки Delivered-To, X-Envelope-To и Envelope-To. Если один из этих заголовков не пуст, следует убедиться в его корректности. Если он содержит несколько имен, то сообщение отвергается без определения PRA. В противном случае нужно использовать содержимое первого обнаруженного заголовка в качестве PRA.
  4. Заголовок Sender. Если существует два или более заголовков Sender, то следует отвергнуть сообщение, не определяя PRA. Если единственный непустой заголовок Sender содержит более одного заголовка или иные искажения, то сообщение отвергается без определения PRA. Если имеется только один непустой корректный заголовок Sender, его содержимое используется в качестве PRA.
  5. Заголовок From. Если существует два или несколько заголовков From, необходимо отвергнуть сообщение, не определяя PRA. Если единственный непустой заголовок From содержит более одного заголовка или иные искажения, то сообщение отвергается без определения PRA. Если имеется только один непустой корректный заголовок From, то его содержимое используется в качестве PRA.

Как мы видим, заголовки проверяются в определенном порядке, который зависит от того, насколько сложно подменить тот или иной заголовок (например, заголовок From, подменить который проще всего, проверяется последним). На каждом этапе корректный или явно искаженный заголовок может быть использован для извлечения PRA или блокирования сообщения. Если выбранный заголовок не существует, то проверяется следующий заголовок в очереди. В конечном итоге нам удается или не удается получить PRA. Если PRA нет, то остальные проверки Sender ID ненадежны; в спецификации Sender ID рекомендуется немедленно отвергнуть сообщение.

Если сервер-получатель успешно извлекает PRA, то затем серверу нужно извлечь доменную часть PRA, которая дает PRD (Purported Responsible Domain — предполагаемый домен отправителя). С помощью PRD сервер составляет запрос DNS для записи SPF или Sender ID, более правильное название которой — E-mail Policy Document. Если E-mail Policy Document существует, то запрос DNS извлекает его, предоставляя почтовому серверу-приемнику список IP-адресов, которым разрешено отправлять почту от лица домена-отправителя.

Если IP-адрес, из которого исходит сообщение, имеется в E-mail Policy Document, то сообщение можно принять. В противном случае сообщение может быть принято, но подлежит более строгой проверке, поскольку поступило из неизвестного источника. Некоторые особенности этой процедуры заслуживают внимания. В зависимости от результатов поиска, в спецификации Sender ID предусмотрены следующие шесть исходов.

  • Pass означает, что E-mail Policy Document существует, был проверен на соответствие PRD и совпадает с ним. В этом случае сервер может принять сообщение как корректное.
  • Fail означает, что E-mail Policy Document существует, но не соответствует PRD. В этом случае сервер должен отвергнуть сообщение как некорректное и выдать сообщение об ошибке SMTP 500.
  • SoftFail указывает, что PRD и E-mail Policy Document не совпадают, но могут существовать уважительные причины для несоответствия. Поэтому в спецификации рекомендуется, чтобы SMTP-сервер принял сообщение, а затем были проведены дополнительные проверки.
  • Neutral означает, что у сервера недостаточно информации, чтобы оценить сообщение, скорее всего, из-за отсутствия E-mail Policy Document. Как и в случае SoftFail, серверу следует принять сообщение, но назначить дополнительную проверку другими фильтрами спама.
  • TransientError указывает, что процесс проверки не может быть завершен из-за неполадок DNS. SMTP-сервер может отвергнуть сообщение с ошибкой SMTP 450 или принять сообщение для более детального анализа. В большинстве SMTP-серверов это типичная процедура при появлении ошибок DNS: они передают извещение об ошибке, а затем пытаются доставить сообщение в течение установленного периода времени.
  • HardError означает, что сервер обнаружил недействительный E-mail Policy Document или процесс проверки был по какой-то причине прерван. В спецификации рекомендуется рассматривать результат как Neutral.
  • None просто означает, что для передающего домена не существует E-mail Policy Document и поэтому Sender ID для анализа сообщения не применялся.

Смысл такой иерархии вариантов заключается в том, что безусловно корректное сообщение (с совпадающим E-mail Policy Document) может обойти другие проверки, которые требуют более серьезных затрат ресурсов. При существующих методах борьбы со спамом такая фильтрация снижает нагрузку на серверы, которые получают огромное число почтовых сообщений, но может замедлить обработку сообщений, если для проверки PRD и E-mail Policy Document используются внешние службы.

Публикация записи Sender ID

Процесс проверки Sender ID достаточно сложен, но его достоинство в том, что всю работу выполняет SMTP-сервер. Администратору остается лишь проследить, чтобы сервер, использующий Sender ID или SPF, мог найти E-mail Policy Document для домена. Выполнить такое требование легко, хотя в этой области между Sender ID и SPF имеются существенные различия. В SPF используются чисто текстовые записи (которые легко генерировать с помощью мастера SPF Wizard, опубликованного по адресу http://spf.pobox.com), в Sender ID применяется более структурированная запись XML (структура точно определена в спецификации Sender ID по адресу www.microsoft.com/mscorp/twc/privacy/ spam_senderid.mspx).

В листинге приведен простой пример E-mail Policy Document для Sender ID. Каждый E-mail Policy Document должен содержать элемент , который представляет собой XML-контейнер для записи. Необязательный элемент указывает E-mail Policy Document. Элемент указывает серверы, которым разрешено посылать почту в каждый элемент . В примере, приведенном в листинге, единственный заданный элемент — , который указывает серверу, что в MX-записях домена зарегистрированы только авторизованные узлы-отправители. С помощью элемента можно указать диапазон IP-адресов (например, 10.10.20.0/24), элемент позволяет задать единственный IP-адрес, а элемент — список адресов.

Следующий шаг после создания XML-записи — опубликовать ее. Для этого нужно создать в домене новый поддомен, назвав его _ep.yourdomain.com. Этот метод удобен, так как поддомены можно построить для любого или для всех доменов в организации без посторонней помощи (если не используется служба DNS независимого поставщика). В своей домашней лаборатории я создал поддомен _ep.robichaux.net, содержащий одну запись DNS TXT с E-mail Policy Document для домена. Этого достаточно! После публикации E-mail Policy Document в корректном поддомене серверы, использующие Sender ID, могут проверять почтовые сообщения, отправляемые сотрудниками предприятия.

Критическая масса

Первый и самый очевидный недостаток большинства схем, применяемых для защиты SMTP, заключается в том, что любые меры, требующие изменений в большей части SMTP-серверов, не получат широкого распространения. Это утверждение, безусловно, верно, но верно также и то, что огромный процент почтовых сообщений, передаваемых через Internet, исходит из небольшого числа доменов — а именно AOL, Hotmail, MSN и Yahoo!. Таким образом, любая схема, применяемая в этих доменах, автоматически имеет очень хорошие шансы на широкое распространение. Недавно компания Microsoft объявила о начале использования Sender ID для проверки входящих сообщений по адресам Hotmail, MSN и microsoft.com. Это важный шаг, особенно если учесть, что AOL уже использует SPF (как и несколько тысяч других организаций, отправляющих почту). По мере совершенствования инструментов реализации и проверки Sender ID, будет расти и область применения протоколов. В любом случае, добавить запись Sender ID в домен так просто, что нет причины откладывать этот процесс.

Аргументы против внедрения Sender ID

Конечно, не все согласны с этим утверждением. Как у каждой технологии, возникшей со времени изобретения колеса, у Sender ID есть противники. Некоторые критические замечания в адрес Sender ID применимы и к SPF. Я привожу их исключительно потому, что рано или поздно их придется услышать всем администраторам, работающим с Sender ID.

  • Sender ID не получил широкого распространения. Точнее было бы сказать, что Sender ID пока не получил широкого распространения. Внедрение компанией Microsoft придаст развитию стандарта нужный импульс.
  • Не все серверы SMTP совместимы с Sender ID. Действительно, большинство серверов не поддерживают стандарт (в настоящее время даже Exchange), а недавние маневры сторонников открытого программного обеспечения свидетельствуют о том, что принятие Sender ID этим сообществом может затянуться. Однако можно с уверенностью утверждать, что Exchange Edge Services обеспечат полную поддержку Sender ID, и я не удивлюсь, если у Microsoft есть планы реализации технологии в Exchange Server 2003. В любом случае, не так уж сложно построить приемник событий для SPF или Sender ID. Еще более важно, что благодаря внедрению Sender ID почтовые сообщения, исходящие от сотрудников предприятия, не будут отмечаться как спам службами AOL, Hotmail, MSN и Yahoo!.
  • Sender ID не блокирует 100% спама. Однако стандарт поднимает порог и несколько затрудняет авторам спама рассылку поддельных сообщений. Поддельные заголовки — особая проблема для пользователей и таких компаний, как eBay и Citibank, которые подвергаются нападениям. Любые меры, сокращающие число атак, полезны. Как указывает на своем Web-узле Вон, задача SPF — помешать авторам спама подорвать репутацию честных людей. Если кто-то хочет рассылать спам, то, по крайней мере, он должен делать это от собственного имени.
  • SPF и Sender ID не аутентифицируют пользователей. Действительно это так. Поэтому в обеих спецификациях рекомендуется применять отдельное расширение SMTP, которое (при использовании совместно с SMTP AUTH) добавляет заголовок, указывающий, кто из пользователей отправил сообщение. Однако этот метод не только облегчает распознавание полезных сообщений, но и нарушает конфиденциальность пользователей. Будет ли найден приемлемый компромисс, покажет время.
  • Нарушается работа списков рассылки и служб передачи сообщений. Списки рассылки, службы передачи сообщений, такие как acm.org, и другие инструменты, которые принимают и ретранслируют почту, могут не выдержать проверок SPF и Sender ID. Но именно по этой причине в обоих протоколах проверяется несколько заголовков. Большинство программ почтовой рассылки уже добавляют в сообщения заголовки Sender, и не составляет труда настроить список на использование рекомендуемого разработчиками Sender ID заголовка Resent-From.

Если говорить о будущем, то вряд ли внедрение Sender ID приведет к исчезновению спама. Однако стандарт будет полезен в сочетании с другими инструментами и методами (в том числе клиентской и серверной эвристической фильтрацией, более развитой защитой клиентов от захвата и использования в качестве спам-роботов, и финансовыми рычагами давления на авторов спама). По мере распространения Sender ID и SPF эти протоколы, наряду с другими технологиями, превратятся в превосходный инструмент борьбы со спамом. В настоящее время я рекомендую собирать подробную информацию о протоколах и их внедрении. На главном Web-узле SPF (http://spf.pobox.com) имеется несколько полезных слайдовых презентаций, где рассматриваются конкретные проблемы, для решения которых предназначен SPF, и опубликован полный архив дискуссионного списка рассылки SPF. На Web-узле Sender ID (http://www.microsoft.com/mscorp/twc/privacy/ spam_senderid.mspx) представлены три интересных документа: обзор назначения Sender ID, руководство для администраторов, желающих применить протокол, и копия проекта стандарта IETF. Эти документы будут полезны для тех, кто действительно хочет разобраться в принципах работы Sender ID.

Старший системный архитектор компании EntireNet, имеет сертификаты MCSE и MCT. Поддерживает Web-сайт www.exchangefaq.org. С ним можно связаться по адресу: getting-started@robichaux.net