ТЕХНИЧЕСКИЙ АНАЛИЗ
Многие уверены, что для устранения спама следует полностью изменить сами принципы работы электронной почты. Однако смена базовых стандартов, лежащих в основе пересылки сообщений через Интернет, т. е. протокола SMTP и системы доменных имен DNS, - дело долгое. К тому же это вряд ли поможет полностью избавиться от спама, разве что несколько сократит его объемы.
Такая доработка SMTP и DNS, которая бы позволила эффективно противодействовать спаму, возможна, как представляется сегодня, лишь в далеком будущем. Во всяком случае до комитета IETF не дошло пока ни одного предложения о том, как это сделать, хотя в его подкомитете Internet Research Task Force уже создана специальная рабочая группа - центральный отраслевой орган по изучению путей борьбы со спамом.
Стандарты механизма запрос/ответ
Большинство предложений в этой области содержит описание тех или иных способов, позволяющих убедиться, что у отправителя письма есть необходимые для участия в почтовом обмене полномочия. Для проведения такой проверки рекомендуется применять аутентификацию, модифицировать точки обмена почтой, использовать технологию DomainKeys (способ аутентификации от фирмы Yahoo), стандартизировать системы C/R (challenge/response - запрос/ответ).
Бесконтрольному распространению спама способствуют две фундаментальные слабости протокола SMTP. Во-первых, спамеру не составляет особого труда подменить адрес электронной почты. Подделка и фальсификация стали сейчас обычным явлением по целому ряду причин. Использование таких методов помогает избежать юридического преследования и мер со стороны Интернет-провайдера, позволяет легко обходить простые антиспамовые средства, основанные на блокировании адресов, упрощает применение различных схем фишинга (отправки спамером писем, замаскированных под сообщения от реальной компании, в которые вставляется ссылка на сфальсифицированную Web-страницу, внешне идентичную сайту этой компании).
Во-вторых, распространению спама невольно способствуют и серверы почтового обмена (mail exchanger, MX), которые пересылают электронные сообщения через Интернет. Дело в том, что они просто обязаны принимать почту от любого клиента в Сети и доставлять ее обслуживаемым клиентским системам. С учетом этого в основной массе предложений, основанных на проверке отправителя, предусматривается ограничение круга возможных источников сообщений: ими должны быть только почтовые серверы.
Но гарантировать, что сообщение поступило от почтового сервера с соответствующими полномочиями, можно только при наличии надежного механизма аутентификации. Такая проверка сама по себе, конечно, полностью устранить спам не сможет, однако позволит эффективнее блокировать отправителей, занесенных в "черные списки".
Технология DomainKeys намного облегчает идентификацию и блокировку электронной почты с подмененными или ложными адресами отправителя. Она предусматривает вставку в каждое сообщение заголовка с цифровой подписью отправителя и открытым ключом и дополнение системы DNS сети отправителя механизмом аутентификации с открытым ключом. На почтовом сервере при этом устанавливается специальное программное обеспечение проверки ключа. При поступлении сообщения оно связывается со службой DNS в домене отправителя и убеждается в соответствии пары ключей и цифровой подписи.
Главное достоинство технологии DomainKeys в том, что она не требует модернизации уже развернутых SMTP-систем. Этот протокол допускает применение экспериментальных заголовков, благодаря чему способен воспринимать и структуру DomainKeys. Более того, поскольку цифровые подписи здесь реализуются не на основе расширений MIME, принимать снабженные ими сообщения можно будет даже в системах, не поддерживающих MIME.
От конечного пользователя DomainKeys ничего не требует, так как функционирует только в серверном звене. Администратору же для применения данной технологии будет достаточно установить на почтовом сервере программный пакет с открытым кодом для управления ключами (который, правда, еще предстоит разработать) и сопровождать его.
Корректировка почтовых стандартов |
Борьба со спамом на уровне стандартов требует внесения изменений и в протокол SMTP, и в службу DNS. Необходимо также добавить уровень аутентификации в инфраструктуру обработки сообщений. Расширения SMTP - Протоколы МХ-серверов обеспечат возможность блокировки сообщений, поступающих с подозрительных клиентов и серверов. Однако реализация потребует совершенно новых почтовых систем и средств аутентификации для службы DNS. - Расширения C/R MIME позволят проводить аутентификацию, которая необходима системам запрос/ответ. Они упрощают С/R-решения, однако не мешают злоумышленникам собирать адреса электронной почты. Изменения DNS - Система DomainKeys привязывает исходящую почту к конкретному домену, благодаря чему получатель может быть убежден, что сообщение пришло из легитимного источника. Это позволяет снизить уровень спама из кооптированных адресов и вести "черные списки" спамеров. Но для реализации необходима система аутентификации ключей; к тому же растет сетевой трафик. - Запись в DNS о серверах IMX помогает проверять почту, поступающую из систем, находящихся внутри сегмента, защищенного сетевым экраном. Требует обновления системы DNS. |
В итоге эффективность этой технологии будет зависеть от готовности администраторов управлять полномочиями отправителей почты и почтовых доменов. Впрочем, ее реализация, вероятно, растянется на долгие годы. Об этом можно судить хотя бы по тому, что пока предложение циркулирует лишь на частном уровне. Не менее нескольких месяцев уйдет на подготовку проекта к публичному обсуждению и комментированию, затем нужно будет провести его через обычную процедуру IETF, и лишь после этого можно стандартизировать новый заголовок в качестве расширения SMTP.
Предлагается для борьбы со спамом изменить и сам принцип работы почтовых MX-серверов. С этой целью планируется разработать новый протокол, который позволил бы этим серверам принимать почтовые сообщения только с других MX-серверов и клиентских систем, входящих в их собственные сети. При получении любого письма MX-сервер прежде всего проверяет данные отправителя и убеждается, что тот входит в число уполномоченных MX-серверов или является внутренним клиентом. В противном случае сообщение блокируется.
Хотя такой подход и не помешает спамеру отправлять почту из уполномоченного домена, но зато предоставит администратору принимающего сервера возможность блокировать нежелательных отправителей или включать их в "черные списки". Компаниям же в этом случае придется следить, чтобы вся исходящая почта отправлялась только через MX-сервер с соответствующими полномочиями.
Все это заставит скорректировать записи DNS, с тем чтобы помочь в идентификации внутренних серверов почтового обмена (Internal Mail eXchanger, IMX), через которые исходящая почта организации пересылается на ее MX-сервер, подключенный к Интернету. Запись IMX DNS должна отмечать специальным флагом IP-адрес системы IMX, чтобы та признавалась в качестве разрешенного MX-сервера.
Самая серьезная проблема при реализации описываемого подхода связана с необходимостью вносить изменения в службу доменных имен DNS и обновлять систему. Организациям, отправляющим большие объемы исходящей корреспонденции, возможно, придется даже перенести внутренние MX-системы на внешние серверы электронной почты.
Еще одно предложение предусматривает использование протокола DMP (Designated Mailers Protocol), проект которого рассматривается в IETF. Главное его назначение - позволить агентам пересылки почты определять, имеет ли отправитель письма право на проведение такой операции. Для этого используются специальные формы с информацией о его правах. В основе технологии DMP лежит запись в службе DNS с информацией о системах, уполномоченных отправлять корреспонденцию. Вместо того чтобы проверять обратный адрес каждого поступившего письма, агент пересылки почты просто сверяется с записью DMP и определяет, имеет ли соответствующие полномочия система-отправитель. Весь несанкционированный трафик при этом блокируется.
Для борьбы со спамом создается также основанная на стандартах система обработки запросов и ответов на них (C/R). Предложенная комитетом по инженерным проблемам Интернета инфраструктура Challenge/Response Interworking Framework содержит набор правил обеспечения взаимодействия между системами запрос/ответ. Базовая модель упрощает такое взаимодействие, позволяя отправителю автоматически отвечать на запросы получателя. На случай, если системы C/R у отправителя нет, в запрос получателя включается описание того, как ответить на него вручную.
Стандартная модель поможет управлять C/R-системой, однако полной защиты от злоумышленников не обеспечит. В ней, в частности, не предусмотрено никаких средств, которые бы предотвратили сбор адресов электронной почты.
Муссируется сейчас и идея введения в том или ином виде платы за пересылку писем через Интернет. Проект Penny Black корпорации Microsoft, например, предполагает что процесс отправки сообщения будет сопряжен с некими накладными расходами (в виде оплаты специальных квитанций) или дополнительными циклами работы ЦПУ. Это намного затормозило бы работу хакерского оборудования, но одновременно затруднило бы и обычным пользователям доступ к тому, что является на сегодняшний день самым экономичным средством связи. Более подробная информация о проекте Penny Black приводится по адресу research.microsoft.com/research/sv/Penny Black.
Впрочем, ни одного предложения об оплате электронной почты в организацию Anti-Spam Research Group пока не поступало.
С техническим аналитиком Майклом Кейтоном можно связаться по адресу: michael_caton@ziffdavis.com.
