Спам непобедим?!

Спам, передаваемый по электронной почте, стал настоящим проклятием Internet. Некоторые специалисты всерьез полагают, что если не предпринять срочных мер, то лет через пять Internet превратится в «помойку».

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

Разумеется, на каждое действие находится противодействие, и сейчас повсеместно применяются самые разнообразные методы борьбы со спамом. Но, к сожалению, они либо не слишком эффективны, поскольку рассчитаны на сдерживание спамеров-дилетантов, либо препятствуют работе «законопослушных» пользователей.

В этой статье мне хотелось бы показать, что, по большому счету, борьба с этим злом — занятие неблагодарное и малоперспективное. Проблемы спама вызваны, во-первых, малыми затратами на пересылку электронной почты, во-вторых, техническим несовершенством принятой почтовой модели и, в-третьих, чрезмерной гибкостью протокола SMTP. В общем случае SMTP позволяет отправлять сообщения любого содержания от имени кого угодно кому угодно, да еще с передачей в третьи руки.

Недостатки модели почтовой системы Internet в целом и протокола SMTP в частности неустранимы, если только не пересмотреть всю нормативную базу, связанную с электронной почтой. Для того чтобы воспользоваться недостатками SMTP, не надо быть семи пядей во лбу, достаточно самых элементарных знаний.

НЕМНОГО О ТЕРМИНОЛОГИИ

Классификации спама посвящена масса статей и документов. С моей точки зрения, спам — это все те почтовые отправления в адрес пользователя, на которые он не подписывался и не желал бы получать. Помимо уже надоевшей рекламы, предложений способов быстрого обогащения, писем счастья/несчастья, наподобие «разошлите это письмо 20 своим знакомым, иначе...», сюда следует отнести почтовые вирусы. Этот вид спама очень быстро развивается, заявив о себе как о преобладающей тенденции в «вирусологии». Так, издательство «Открытые системы» за последние полгода подвергалось вирусным атакам около 6000 раз, причем 98% из них осуществлялось по почте. Кстати сказать, в отличие от прочих, послания с вирусами в большинстве своем инициируются не спамерами, а невинными жертвами уже зараженных компьютеров.

К спаму, притом самому страшному и опасному, относятся подложные письма, когда злоумышленник от чужого имени шлет послания третьим лицам. Недавно я получил несколько писем от возмущенных сограждан, из которых выяснилось, что кто-то отправлял послания с моим обратным адресом, предлагая вступить в «Московский клуб группового секса».

Но это еще цветочки. Гораздо неприятнее другой случай. Некто от имени президента нашего издательства (с его настоящими реквизитами и адресом) распространил среди партнеров издательства письмо, где, скажем так, некорректно выражался о деятельности издательства. К сожалению, SMTP позволяет с легкостью проделывать подобные трюки.

Теперь представьте, что кто-то от вашего лица послал вашему начальнику письмо с хамским содержанием. Поверьте, оправдаться будет нелегко. А если тот промолчит (и тогда даже не будет шанса выявить факт подлога) и просто возьмет на заметку ваше мнение о нем? Ведь не все осведомлены о «богатых» возможностях SMTP.

Условно можно выделить такое понятие, как вторичный спам. Некоторые почтовые вирусы используют подложные обратные адреса (в том числе и реально существующие), между тем как большинство почтовых антивирусных программ отсылает «отправителю» сообщение об обнаруженном вирусе. Подобный спам вводит в нервное возбуждение «отправителя», который в экстренном порядке начинает поиск вируса.

Еще один вид спама может порождаться почтовыми системами, где предусмотрена возможность автоматического ответа на почтовые сообщения. Например, пользователь Иванов уходит в отпуск и активизирует процедуру, которая при поступлении нового сообщения посылает отправителю послание вида «Ваше письмо получено и будет обработано. Но, к сожалению, я в отпуске».

Руководящие документы Internet (см. RFC 2505) настоятельно призывают не задействовать такие системы. И вот почему. Если, уходя в отпуск, Петров инициализировал систему автоматического ответа, а затем послал письмо Иванову, то почтовые системы начинают обмениваться сообщениями о том, что адресаты в отпуске. Эти письма, если не предпринять специальных мер, не только переполнят ящики Иванова и Петрова, но и вызовут серьезную нагрузку на почтовые серверы и линии связи. Даже если Петров не пошлет начального сообщения Иванову, такое письмо Иванову от имени Петрова может отправить злоумышленник. Подобной опасности потенциально подвержены любые почтовые системы, автоматически отвечающие на послания без анализа их содержимого.

КАК РАБОТАЕТ ПОЧТА

Прежде чем более конкретно говорить о несовершенстве почтовой системы Internet, рассмотрим типичную схему работы электронной почты (см. Рисунок). Пусть пользователь Петров с почтовым адресом petrov@a.ru посылает сообщение Иванову (адрес ivanov@z.ru) с таким текстом (используем английский для простоты):

Subject: Test
Hello, how are you?

При этом Петров использует популярную программу Microsoft Outlook Express (OE), предварительно настроив ее следующим образом:

Имя: Peter Petrov
Адрес: petrov@a.ru
Сервер исходящей почты (SMTP): source.a.ru
IP-адрес компьютера Петрова - 123.45.67.89
доменное имя - petrov.a.ru.

В свою очередь Иванов также пользуется Outlook Express, установив свои параметры:

Имя: Ivan Ivanov
Адрес: ivanov@z.ru
Сервер входящей почты (POP3): target.z.ru

Остальные параметры Иванова и Петрова для нас сейчас не существенны.

Пусть на сервере source.a.ru (IP-адрес 123.45.67.1) установлен сервис Microsoft SMTP, который по умолчанию входит в комплект Windows 2000 Server и задействуется почтовой системой Microsoft Exchange 2000. А на сервере target.z.ru (IP-адрес 199.99.99.99) установлен Linux с почтовыми программами sendmail и gnu-pop3d: первая из них реализует службу SMTP, а вторая — POP3. Впрочем, все это не суть важно, поскольку почта работает схожим образом и на других системах. Но нам нужна отправная точка.

В электронной почте Internet приняты термины «почтовый пользовательский агент» (Mail User Agent, MUA) и «почтовый транспортный агент» (Mail Transport Agent, MTA). MUA — это обычная клиентская программа, она отвечает за создание (прием) почтового сообщения, при этом передача (прием) сообщения осуществляется через MTA. В нашем случае в качестве MUA выступает Outlook Express. В свою очередь, MTA пересылает сообщения по Internet с помощью протокола SMTP и имеет развитые возможности работы сразу со множеством сообщений. В рассматриваемом примере в роли MTA выступают Microsoft SMTP и sendmail.

Любое электронное письмо состоит из двух частей: заголовков (headers) и тела (body). Заголовки располагаются в начале письма и отделены от тела пустой строкой. На Листинге 1 показано, как выглядит письмо в момент его отправки (заголовка Received: на самом деле не будет, поскольку его вставит сервер source.a.ru, но об этом чуть ниже).

Заголовки, начинающиеся с символов X-, не регламентируются стандартами и называются свободными (user-defined). Они служат для вспомогательных целей, в частности для идентификации клиентской программы.

Остальные заголовки в Листинге 1 самоочевидны (впрочем, сюда не вошло еще несколько интересных заголовков). Отметим, что заголовки From: и To: заполняются клиентской программой. Для рассылки копий используются Cc: и Bcc:, а Reply-To: указывает адрес, на который должны идти ответы. Он часто применяется, когда пользователь отправляет письмо не со своего рабочего места. Более подробную информацию о заголовках можно найти в руководящих документах RFC 2821 и RFC 2822.

В Outlook Express, как и во многие другие MUA, встроен клиент SMTP, правда, с ограниченными возможностями. OE пользователя Петрова соединяется с хостом source.a.ru, являющимся сервером SMTP, и передает ему письмо.

В свою очередь, по получении письма source.a.ru добавляет в сообщение заголовок Received:, после чего письмо принимает в точности такой вид, как на Листинге 1. В данном случае заголовок описывает, что хост source.a.ru, на котором установлен Microsoft SMTP, получил сообщение от хоста petrov.a.ru (IP-адрес 123.45.67.89) такого-то числа в такое-то время. Во время путешествия письма по Internet каждый MTA, через который проходит сообщение, добавляет в него свой заголовок Received:.

Теперь подробно рассмотрим процедуру установления соединения и переговоры между source.a.ru и target.z.ru (процедура связи между petrov.a.ru и source.a.ru происходит похожим образом, но она менее информативна, так как IP-адрес сервера SMTP был заранее известен). Сервер source.a.ru знает адрес электронной почты получателя (ivanov@z.ru), но ему надо определить, куда конкретно (по какому IP-адресу) посылать письмо. Для этого source.a.ru выделяет из адреса получателя электронного письма доменную часть (z.ru) и посылает запрос серверу DNS примерно такого содержания (в переводе с машинного языка на человеческий): «Требуется узнать записи MX для домена z.ru». Записи MX (Mail eXchanger) в доменной системе используются для обозначения почтовых серверов, обслуживающих домен. Не вдаваясь в детали, скажем только, что для одного домена может быть несколько записей MX, для каждой из которых администратор назначает приоритет.

Допустим, сервер DNS ответил на запрос таким образом:

«Для домена z.ru записи MX имеют следующие хосты:

target.z.ru (IP-адрес 199.99.99.99)
 с приоритетом 10
vol.z.ru (IP-адрес 199.99.99.98)
с приоритетом 20"

Приоритет почтового сервера тем выше, чем меньше номер. Поэтому source.a.ru, в первую очередь, попытается связаться с target.z.ru и, только если он не ответит, обратится к vol.z.ru. Бывает и так, что администратор не использует записи MX. В таком случае хост source.a.ru попробует установить соединение с сервером z.ru.

Допустим, target.z.ru функционирует и подключен к Internet. Тогда source.a.ru соединяется с портом 25 (через который работает сервер SMTP) по транспортному протоколу TCP. В этом соединении source.a.ru выступает клиентом SMTP, а target.z.ru — сервером. Протокол SMTP удивительно прост и довольствуется всего десятью командами, а для наших примеров потребуется и того меньше. Поэтому нелишне рассмотреть процесс переговоров между source.a.ru и target.z.ru (см. Листинг 2).