Электронный журнал "Спамтест". Все о борьбе со спамом

Электронный журнал "Спамтест" No. 60 в этом номере: Новости Спам - статистика за неделю 19 - 25 июля 2004 г. Технология SPF - за и против. Анализ предлагаемых решений и опыт практического использования метода SPF А. Тутубалин Часть 1 Новости Безопасность электронной почты вызывает тревогу 19.07.2004 59% пользователей готовы отказаться от электронной почты, если не будут решены проблемы с вирусами и спамом и будет предложен альтернативный способ коммуникаций. Таковы результаты последнего исследования MessageLabs. В мае-июне этого года компания MessageLabs провела онлайн-опрос, посвященный перспективам безопасности почтовых коммуникаций в ближайшие 10 лет. 43% опрошенных считают, что объем спама возрастет более чем на 100%, 24% полагает, что спама станет больше наполовину и лишь 15% думают, что его объем останется на прежнем уровне. Ситуация с вирусами, по мнению респондентов, не менее тревожная: 41% ожидает, что количество вирусов возрастет более чем вдвое, при этом вирусы станут более опасными (78%). По результатам опроса, основную угрозу для бизнеса в ближайшие 10 лет будут представлять онлайн мошенничество - фишинг, кража личных данных и тп. (22%), вирусы (21%), а также утечка конфиденциальной информации (18%) и промышленный шпионаж (15%). Исходя из перспектив, которые видят респонденты, не удивительно, что у 41% из них безопасность электронной почты в будущем вызывает беспокойство, а 59% отказались бы от электронной почты при наличии достойной альтернативы. Хотя 60% опрошенных полагают, что использование электронной почты возрастет более чем вдвое, всего 2% думают, что она останется прежней, а 63% считают, что произойдет объединение электронной почты с другими видами коммуникаций, такими как IM, SMS и др. Источник: MessageLabs Microsoft ставит перед фактом: Sender ID планируется ввести уже в октябре 22.07.2004 Представители корпорации Microsoft заявили, что с 1 октября на почтовых серверах Microsoft может быть введена проверка подлинности адресов отправителей писем Sender ID. Microsoft настоятельно советует провайдерам электронной почты и интернет-провайдерам к середине сентября перейти к идентификации писем, посылаемых из их сетей, с помощью протокола Sender Policy Framework (SPF). Microsoft намерена ввести обязательную проверку подлинности отправителей для почты, приходящей на почтовые адреса пользователей MSN, бесплатной почтовой службы MSN Hotmail и в почтовые ящики в домене microsoft.com. Письма с серверов без поддержки Sender ID отбрасываться не будут, но их подвергнут тщательному анализу и фильтрации антиспам фильтрами. Sender ID объединяет две технологии: предложенную Microsoft в марте Caller ID и SPF, разработанную Meng Weng Wong. Согласно технологии Sender ID, организации, отправляющие письмо, будут публиковать SPF-записи, идентифицирующие серверы исходящей почты в DNS. При этом подлинность адресов входящих писем будет проверяться и на уровне "конверта", и в "теле" письма. Как среагируют другие интернет-провайдеры на попытку Microsoft навязать выбранную им антиспамовую технологию, покажет время. Однако решение одного из крупнейших интернет-провайдеров использовать Sender ID не может не повлиять на дальнейший ход событий. Источник: www.infoword.com "Король спама" избежал серьезного штрафа 23.07.2004 Скотт Рихтер, который называет себя "королем спама", по решению суда заплатит 50000 долларов. Это много меньше тех 20 миллионов, которыми изначально грозил ему генеральный прокурор Элиот Спицер. Элиот Спицер (Eliot Spitzer) на основании представленных Microsoft доказательств обвинил Скотта Рихтера (Scott Richter) и принадлежащую ему компанию OptInRealBig.com в ежедневной рассылке 250 миллионов писем клиентам Hotmail, при этом в письмах зачастую был скрыт истинный источник рассылки. Спицер потребовал штрафа в размере 20 миллионов долларов. Однако Рихтер, уклонившись от обсуждения объемов рассылок, утверждает, что его компания всегда действовала в рамках Can-Spam Act, а судебные иски организованы его конкурентами. Стоит отметить, что в списке самых известных спамеров Spamhaus Рихтер занимает второе место. В результате разбирательств и использованных адвокатами подозреваемого лазеек, Рихтер отделался 40000 долларами штрафа и 10000 долларами компенсации судебных расходов. Рихтер обещал впредь никогда не нарушать антиспамового закона (никаких поддельных адресов отправителя и т.д.), а Спицер, со своей стороны, пригрозил, что возобновит судебное преследование Рихтера в том случае, если "король спама" закон нарушит. Между тем Рихтера ожидает разбирательство по еще одному иску, который подала против Рихтера корпорация Microsoft. Источник: www.computerweekly.com Австралийские антиспамовые законы доказали свою эффективность 23.07.2004 Управление связи Австралии (АСА) заявило, что антиспамовые законы, принятые в Австралии в апреле этого года, доказали свою эффективность в отношении местных спамеров. Боб Хортон (Bob Horton), глава АСА, заявил, что изначально целью закона были крупные спамеры, рассылающие порноспам и рекламу виагры. Через три месяца после вступления в силу антиспамовых законов жалобы на подобный спам практически прекратились. Согласно австралийским законам, коммерческие организации, которые неоднократно рассылают спам, могут быть оштрафованы за каждый день рассылки на сумму до 1,1 миллиона австралийских долларов. Однако эти законы могут быть применены только к австралийским спамерам, а проблема спама - глобальная. Так, в Австралии только 2% получаемого спама приходит из местных источников. Хортон считает, что другие страны должны принять аналогичные меры в борьбе со спамом. "Спам - это глобальная проблема, которая требует глобальных решений", - сказал Хортон. Spamhaus подтвердила падение уровня спама в Австралии. По мнению экспертов Spamhaus, австралийские антиспамовые законы - лучшие в мире. Источник: Australian IT Вторая национальная конференция "Проблема спама и ее решения" 23.07.2004 20 октября в Москве начнет работу вторая национальная конференция "Проблема спама и ее решения". По итогам 2003 года в России ущерб от спама составил 200 миллионов долларов. В настоящее время доля спама в почтовом трафике Рунета достигает 75-80%, за прошедшие полгода 2004 года его прирост составил 10-15% от общего объема почты. Спам является помехой для бизнеса, а объединение технологий спамеров и хакеров представляет серьезную угрозу сетевой безопасности. Проблема спама требует комплексного подхода - ее решение возможно лишь объединенными усилиями специалистов на техническом, юридическом и социальном уровнях. Вторая национальная конференция "Проблема спама и ее решения" посвящена всем аспектам борьбы со спамом. В ее работе примут участие ведущие специалисты в области антиспам-технологий, представители провайдеров и публичных почтовых служб, сотрудники служб безопасности и ИТ-специалисты компаний, а также юристы и представители структур власти. Конференция проводится компанией "Ашманов и Партнеры". Связаться с Оргкомитетом можно по e-mail: spamtest@ashmanov.com. Источник: Ашманов и Партнеры Спам - статистика за неделю 19 - 25 июля 2004 г. Ашманов и Партнеры Объем спама Объем спама в почтовом трафике Рунета сохраняется на уровне 70%. Популярные тематики По статистике конец июля - начало августа - период массовых отпусков. В период летнего затишья активность рекламодателей традиционно невелика, а спам - это разновидность рекламы. В целом объем спама слегка понизился, но доли основных спамерских тематик изменились незначительно. No Тематика Описание %% от общего объема Изменение за неделю 1 Для взрослых Средства для повышения потенции (виагра и пр.), а также для улучшения физических возможностей при занятих сексом 17% -2% 2 Образование Реклама семинаров, тренингов, курсов 12% +2% 3 Компьютеры и Интернет Предложения приобрести ПО, компьютерную технику, расходные материалы; также предложения для владельцев сайтов (хостинг, обмен баннерами и т.п.) 9% без изменений 4 Личные финансы Предложения по страхованию, уменьшению кредитной задолженности, выгодным условиям займов и т.п. В подавляющем большинстве англоязычные письма. 9% +1% 5 "Здоровый образ жизни" и "Медикаменты" Предложения сбросить лишний вес, улучшить состояние кожи, волос; приобрести правильную осанку, купить биологические добавки и т.п. Предложения приобрести лекарства в online 8% -1% 6 Отдых и путешествия Предложения туристических поездок, а также организации и проведения различных развлекательных мероприятий. 6% +1% 7 Услуги по электронной рекламе Предложения организовать спамерскую рассылку, программы для рассылок, базы электронных адресов и т.п. менее 2% -2% Лучшее предложение недели: "пpopок пpuнимает заказы на погoдy" Здесь: {e-mail} Самый назойливый спам (по частоте повторяющихся рассылок и количеству разосланных экземпляров) Самыми назойливыми были предложения e-mail рассылки и изучения английского с преподавателями из США. Эти письма, а также мошенническое письмо для доверчивых получателей вы найдете на сайте Спамтест.   Технология SPF - за и против. Анализ предлагаемых решений и опыт практического использования метода SPF А. Тутубалин Ашманов и Партнеры Содержание: Часть 1 1. Верификация отправителя и проблема спама 2. Описание технологии SPF     2.1 Общие принципы     2.2 Публикация SPF-политики     2.3 Использование данных SPF при приеме почты     2.4 Проблемы технологии SPF         2.4.1 Верификация отправителя и пересылка почты         2.4.2 Механизм exists         2.4.3 Проблемы SPF - краткое резюме Часть 2     2.5 Использование SPF для фильтрации спама         2.5.1 Использование SPF как "белого списка"         2.5.2 Использование SPF как "черного списка"         2.5.3 Проблемы производительности     2.6 Выводы и рекомендации         2.6.1 Публикация SPF-записей         2.6.2 Использование SPF при приеме почты 3. Опыт практической эксплуатации SPF     3.1 Описание эксперимента     3.2 SPF как фильтр спама     3.3 SPF и проблема пересылок     3.4 Выводы из экспериментов 4. Заключение Часть 1 1. Верификация отправителя и проблема спама Говоря о проблеме спама ("мусорной почты") необходимо прежде всего определить обсуждаемое явление. В данной статье под спамом понимаются "анонимные массовые рассылки электронной почты, как правило, имеющие рекламный характер". Данное определение удовлетворительно определяет спам как массовые рекламные рассылки, производимые профессионалами для зарабатывания денег. А ровно от этого бизнеса сейчас и страдают все пользователи Интернета. Прочая "нежелательная почта" (технические сообщения систем электронной почты, неанонимные рассылки с возможностью отписки, поздравительные открытки, посланные по ошибке письма) в данной статье как "спам" не рассматривается. Анализ технических данных приходящего спама показывает такие особенности: Подавляющее количество спама приходит с захваченных спамерами (зараженных вирусами) пользовательских машин (преимущественно, подключенных к Интернету по высокоскоростному соединению - ADSL, Cable internet и так далее). Практически весь спам имеет поддельную техническую информацию, в частности: Поддельный отправитель - в качестве отправителя указан E-mail адрес, скорее всего, не имеющий никакого отношения к компьютеру отправителя. Поддельные заголовки - в которые вставлены, например, лишние строки Received, из которых следует, что письмо, якобы, было порождено не на том почтовом сервере, с которого на самом деле пришло. Достаточно часто выдается и поддельный параметр SMTP HELO - сообщаемое в нем имя машины не имеет никакого отношения к тому IP-адресу, с которого идет SMTP-соединение. Спам является распределенным явлением - источников спама в мире миллионы, множество рассылающих машин постоянно пополняется при помощи компьютерных вирусов, троянских программ и подобных средств. Ежедневно регистрируются десятки тысяч новых IP-адресов рассылающих машин. Часть источников спама постоянно меняет свои IP-адреса т.к. это пользовательские компьютеры, получающие адрес динамически у своего провайдера. Таким образом, складывается неутешительная картина - фильтрация по черным спискам (RBL) не дает достаточно хорошего результата (так как в большинство списков RBL адрес отправителя попадает уже постфактум - по факту рассылки), при этом количество ложных срабатываний (ложной классификации нормальных E-mail сообщений как спама) при использовании RBL составляет до единиц процентов. Подробнее см. статью автора "RBL-вред или польза"). Раз фильтрация по IP-адресам работает плохо, то у разработчиков и администраторов антиспам-систем возникает понятное желание верифицировать другие параметры, передаваемые в SMTP-сессии: адрес отправителя и/или данных, предоставляемых в SMTP HELO. Для анализа этих данных не нужен доступ к тексту сообщения, "плохие" письма можно отвергать, не принимая их. К несчастью, протокол SMTP не предполагает верификации отправителя. Такие средства нужно разработать, обсудить, протестировать, принять как стандарт и повсеместно внедрить. За последний год было предложено около десятка различных технологий верификации отправителя. На сегодняшний день наибольшую известность получила технология SPF ("Sender Policy Framework", ранее она называлась "Sender Permitted From"). Помимо известности, началось ее относительно массовое внедрение, в том числе и у крупнейших игроков интернет-рынка (AOL, Google, Altavista, Earthlink и т.д.). В последние месяцы отмечена и активная PR-компания, нацеленная на всех пользователей Интернета: крупные игроки рынка сообщают о разработке (или процессе разработки) или внедрении (или начинающемся внедрении) подобных механизмов. Таким образом, создается впечатление, что проблема спама если и не решена окончательно, то скоро будет решена (и именно тем или иным способом верификации отправителя). Все предлагаемые технологии верификации отправителя на сегодня имеют статус "предварительное описание" (в виде "internet draft" или RFC); в качестве общепринятых стандартов будут приняты одна или две технологии. Наибольшие шансы стать общепринятыми имеют SPF (как получившая относительно широкое распространение) и SenderID (технология, поддерживаемая Microsoft). На сегодняшний день вопрос о поддержке той или иной технологии в рамках отдельно взятой почтовой системы может быть сформулирован так: Что выбрать: какой из имеющихся механизмов верификации внедрять (если внедрять); Какова эффективность метода: приведет ли это к заметным улучшениям при решении основной задачи - фильтрации спама; Каковы риски: не будет ли при этом отфильтрована "нормальная" почта (входящая или исходящая); Какова трудоемкость внедрения: понадобится ли дополнительное ПО или изменение имеющегося. Далее в статье вопрос, "какой механизм внедрять" не обсуждается, поскольку на сегодня поддержка в программном обеспечении реализована только для SPF. Ответу на остальные три вопроса (эффективность, риски, трудоемкость) и посвящена данная статья. 2. Описание технологии SPF 2.1. Общие принципы Технология верификации отправителя "Sender Permitted From" была предложена в 2003 году. Спецификации несколько раз изменялись, последний вариант опубликован 11 июля 2004 года. Вместе со спецификациями менялось и название, так что сейчас технология называется "Sender Policy Framework". В январе 2004 г. о тестировании SPF объявила компания AOL, эта инициатива была поддержана и другими крупными участниками рынка. Суть технологии заключается в следующем: Администратор (владелец) домена публикует данные, описывающие возможные источники электронной почты с адресами отправителя из этого домена. Почтовый сервер, принимающий E-mail с адресом отправителя из данного домена, может сопоставить реальный источник сообщения (IP-адрес стороны, посылающей почту) с данными, которые опубликовал владелец домена. Если IP-адрес посылающей стороны находится в списке рекомендованных, то E-mail сообщение рекомендовано принимать, в противном случае - не принимать. Публикуемые владельцем домена данные далее будут называться SPF-записью или SPF-политикой (так как владелец домена фактически публикует рекомендуемую им политику обращения с E-mail в зависимости от IP-адреса посылающей сообщение стороны). 2.2. Публикация SPF-политики Если какой-то домен (его владелец/администратор) хочет поддержать SPF для целей верификации сообщений, исходящих из данного домена (т.е. имеющих адрес отправителя в этом домене), то для этого в DNS-записи домена добавляется строка приблизительно такого вида: domain.name. IN TXT "v=spf1 ip4:192.168.0.0/16 +a:www.another.domain.com -all". Данный пример означает: Поддержан протокол SPF версии 1 (v=spf1); Почта с From: someuser@domain.name может приходить (рекомендовано принимать) с: IP-адресов диапазона 192.168.0.0/16 (192.168.0.0-192.168.255.255) Сервера с именем www.another.domain.com Почта с From: из данного домена не может приходить (не рекомендовано принимать) более ниоткуда (-all). В терминах технологии SPF, 'ip4', 'a', 'all' - это "механизмы" (mechanism), а префиксы (+,-,?,~) перед названием механизма так и называются "префиксы" (prefix). Поддерживаются такие механизмы (подробнее см. описание формата записей SPF): all - описывает весь диапазон IP-адресов. ip4:addresslist - диапазон адресов IPv4 в формате aa.bb.cc.dd или aa.bb.cc.dd/masklen (например, ip4:127.0.0.1 или или ip4:127.0.0.0/8). ip6:addresslist - диапазон адресов IPv6 (аналогично ip4). a:hostname - все IP-адреса машины hostname. mx - все IP-адреса MX-серверов данного домена. ptr:domain - IP-адреса, PTR-записи которых указывают на domain. include:domain - ссылка на SPF-политику домена domain. exists:macro - позволяет с помощью макроязыка сконструировать сложное доменное имя, затем проверить его существование в DNS. Например, запись вида "exists:%{l}._spf.domain.name" для адреса отправителя вида user@domain.name развернется в user._spf.domain.name. Если на запрос полученного доменного имени вернется положительный ответ, значит механизм "сработал" ("match"). Подробнее механизм exists описан в отдельном разделе ниже. При анализе SPF-записи все механизмы перебираются слева направо, и если какой-то из них описывает IP-адрес посылающей сообщение стороны, то механизм "сработал". Тогда следует выполнить действие, рекомендуемое владельцем домена. Действия определяются префиксами перед механизмами: + (или отсутствие префикса) - положительный префикс, сообщение рекомендуется принять. - (минус) - запрещающий префикс, сообщение принимать не рекомендуется. ~ - "нейтрально-отрицательный" префикс, означающий "адрес посылающей стороны может быть не в разрешенном диапазоне". Сообщение рекомендуется не отвергать, но возможно подвергнуть дополнительным проверкам. ? - "нейтральный" префикс, указывает на принципиальную неполноту данных (то есть владелец домена не может указать все IP-адреса источников почты из своего домена). Кроме механизмов, определены следующие модификаторы: redirect:domainname - "подменяет" проверяемое доменное имя с домена отправителя на domainname. exp:строка - определяет диагностическое сообщение, выдаваемое при неприеме почты. Таким образом, для поддержки SPF на посылающей стороне достаточно перечислить в DNS-записи все адреса почтовых серверов, посылающих почту "наружу", после чего протокол будет поддержан. Конечно, реализация сложных случаев (макросы с exists) потребует специального ПО, но для простых случаев exists не нужен. SPF-записи помещаются в стандартные для DNS записи типа TXT, следовательно, никакой модификации программного обеспечения DNS серверов и клиентов не требуется. 2.3. Использование данных SPF при приеме почты Принимающая сторона по получении MAIL FROM: user@domain.name в SMTP-сессии делает DNS-запрос, получает SPF-запись и сравнивает IP-адрес посылающей стороны SMTP-сессии с SPF-политикой. Результатом является рекомендация по приему или отвержению письма. Нужно сказать, что имеющиеся на сегодня общедоступные реализации фильтрации спам-почты на базе технологии SPF на принимающей стороне воспринимают рекомендации буквально - отвергая сообщение, для которого сработал механизм с префиксом "-" и принимая в противном случае почту от отправителя. Для поддержки SPF на этапе приема почты необходима модификация ПО почтового сервера. Необходимая функциональность реализована в библиотеке libspf2 (распространяется как OpenSource под лицензиями GNU и BSD - на выбор). Существуют также готовые наборы правок (патчей) и/или клиенты для большинства распространенных почтовых серверов (MTA). Резюме Поддержка SPF на стороне отправителя: публикация SPF-политики домена может быть (в простом случае) произведена очень быстро, это не требует каких-либо существенных затрат. Поддержка SPF на этапе анализа принимаемой почты: анализ SPF-политики для принимаемой почты требует модификации ПО почтовых серверов, однако для основных вариантов и версий существуют готовые и работоспособные решения. Таким образом, решение о поддержке SPF должно приниматься на основании оставшихся критериев: того, приведет ли эта поддержка к (частичному) решению проблемы спама и не приведет ли она к каким-либо потерям "нормальной" почты. 2.4. Проблемы технологии SPF Помимо понятных достоинств, SPF и аналогичные технологии имеют весьма существенный недостаток: отправитель сообщения не знает его дальнейшего пути к получателю; если сообщение будет пересылаться (forward), то в процессе пересылки могут быть задействованы почтовые серверы, не указанные отправителем как разрешенные. Другими словами и крупными буквами: ПРИ БУКВАЛЬНОМ ИСПОЛНЕНИИ SPF-ПОЛИТИКИ МОЖЕТ БЫТЬ ОТВЕРГНУТА НОРМАЛЬНАЯ ПОЧТА (НЕ СПАМ). Эта проблема является настолько серьезной, что требует отдельного внимательного рассмотрения ниже. 2.4.1. Верификация отправителя и пересылка почты Сообщения электронной почты обычно пересылаются напрямую (end-to-end) от отправителя к получателю. Однако это не так в следующих случаях: Прием получателем почты через резервный почтовый сервер (backup MX); Пересылка почты на другой адрес (механизм forward). Оба случая не являются редкими или экзотическими: резервные почтовые серверы предназначены для повышения надежности почтовых систем; пересылка почты с адреса на адрес является широко используемой, например, для сбора сообщений с нескольких адресов в один почтовый ящик. Резервные почтовые серверы Резервные почтовые серверы используются для приема почты в случаях, когда основной почтовый сервер организации по каким-либо причинам недоступен. После восстановления доступности резервный сервер доставляет почту на основной сервер. E-mail адрес отправителя при этом не изменяется. Предположим, мы доставляем почту с user@sender.com на user@receiver.com через резервный сервер backup.receiver.com: Sender.com -> backup.receiver.com -> receiver.com. В момент приема на receiver.com будет проверяться SPF-политика домена отправителя (sender.com), а SMTP-сессия инициирована с backup.receiver.com. Но отправитель про резервные серверы получателя ничего не знает и адреса backup.receiver.com в своей политике не указал. В случае, когда для sender.com указана запретительная политика по умолчанию (-all), то receiver.com получает рекомендацию отвергнуть письмо. Таким образом, для нормального приема почты с резервных серверов необходимо предпринять следующие действия: Поддержка SPF должна быть включена не только на основном почтовом сервере, но и на всех резервных. Основной почтовый сервер должен принимать почту с резервных серверов без SPF-проверки. В случае штатной пересылки почты внутри организации (скажем, с входного почтового сервера под Unix в почтовую систему под Windows) проверка SPF должна быть включена только на входном сервере. К сожалению, вышеперечисленные пожелания не всегда выполнимы. В частности, резервные почтовые сервера могут принадлежать другой организации (сервис-провайдеру или партнеру), которая не хочет реализовывать проверку SPF на них. В таких случаях, реализовать проверку SPF-политики для почты, приходящей через резервные серверы, невозможно (на резервном сервере - отказываются, проверять во время получения почты с резервного сервера - не имеет смысла, так как отправитель про резервные серверы получателя ничего не знает). Пересылка почты Пересылка (forward) почты используется в Интернете достаточно широко. Есть форвард-сервисы (обеспечивающие, например, "вечный" почтовый адрес), большинство бесплатных почт поддерживает пересылку, достаточно часто пересылку настраивают в "частном порядке". Как правило, при пересылке сохраняется исходный адрес отправителя - это необходимо, в частности, для корректной доставки квитанций о недоставке письма (bounce messages). Рассмотрим такую простую схему: (From)user@sender.com ->(To)user@mailbox.com(Forward)->user@receiver.com (пользователь user@sender.com шлет почту на user@mailbox.com, это сообщение пересылается "настоящему получателю" user@receiver.com). Если домен sender.com опубликовал SPF-политику (например - "вся почта идет только с mail.sender.com"), а почтовый сервис на receiver.com ее проверяет, то данное письмо будет отвергнуто, так как политика отправителя (sender.com) не предполагает, что письмо может перепосылаться (с mailbox.com). Эта проблема является ключевой при внедрении практически любой технологии верификации отправителя. Естественно, ее нужно каким-то образом решать, и на сегодня предлагаются такие решения: Использование SPF-механизма exists. Например, отправитель может указать SPF-политику вида "+exists %{l}._spf.domain.name" и на все DNS-запросы для адресов username._spf.domain.name отвечать положительно (возвращать какой-то адрес). Механизм сработает, принимающая сторона получит рекомендацию принять почту. Изменение адреса отправителя при пересылке (например, SRS - Sender Rewriting Scheme). То есть пересылаемое в нашем примере письмо должно уйти на receiver.com как "что-то@mailbox.com". Передача дополнительных данных о реальном отправителе в SMTP-сессии (см., например, документ MARID SMTP Service Extension for Indicating the Responsible Submitter of an E-mail Message). Добавление дополнительных данных в заголовки письма при пересылке и извлечение их оттуда при приеме (описано, например, в спецификациях CallerID). Достоинства и недостатки схемы с exists описаны в отдельном разделе ниже, а все остальные решения обладают очевидными недостатками: Требуется модификация ПО на пересыльщике почты. Таким образом, идея плавного введения SPF в действие перестает работать: кроме поддержки SPF на отправителе и получателе, требуется обязательная модификация ПО на всех почтовых серверах, где может происходить пересылка почты от отправителя (опубликовавшего SPF-политику) к получателю (анализирующему SPF-политику). Пересыльщик становится ответственным за пересланный спам. Другими словами, если на user@forwarder.com (см. пример) придет спам-сообщение, его отправитель будет подменен на что-то@mailbox.com. Во многих случаях такая подмена identity - неприемлема, ибо с точки зрения обычного пользователя mailbox.com становится "спамером". Помимо общих недостатков, есть и специфические для каждого из вариантов решения проблемы пересылок почты: А. Использование подмены отправителя приводит к таким дополнительным проблемам: Необходимо модифицировать ПО на серверах, пересылающих почту. Сообщения о недоставке (bounce messages) будут проходить по пути к исходному отправителю через всю цепочку пересылок, что увеличивает вероятность их утери и создает дополнительную нагрузку на сервер-пересыльщик. Б. Передача дополнительных данных в SMTP-cессии приводит к тому, что необходимо модифицировать ПО почтовых серверов (причем, готовых решений на сегодня нет, есть только предварительные спецификации). Эта модификация должна быть произведена на всех пересылающих серверах и на всех принимающих серверах. В. Извлечение данных о пересыльщике из заголовков писем приведет к таким усложнениям: Возможно, потребуется модификация ПО на пересылающих серверах (правда, большинство современного ПО необходимые спецификации уже поддерживает). Потребуется дополнительная модификация ПО на принимающей стороне, причем готовых решений на сегодня не существует. Для проверки валидности сообщения его придется принять на свой почтовый сервер, так как данных SMTP-сессии для проверки без приема письма - недостаточно. 2.4.2. Механизм exists Механизм exists предназначен для "тонкого" (fine-grained) управления SPF-политикой отправителя. Суть механизма заключается в следующем: Из домена отправителя, левой части адреса отправителя, IP-адреса посылающего сервера (и ряда других данных) получатель составляет доменное имя. Правила составления описываются в SPF-политике с помощью специального макроязыка. Полученное доменное имя проверяется на существование в DNS. Если имя существует, то механизм сработал; если не существует - не сработал. Например, если в SPF-политике домена example.com присутствует строка '+exists:%{l}.%{i}._spf.example.com', то для отправителя user@example.com и письма, посылаемого с адреса 127.0.0.1, будет составлено имя user.127.0.0.1._spf.example.com. Если на DNS-запрос для такого имени будет получен ответ, то письмо рекомендовано к получению. Таким образом, отправитель может сформировать DNS-записи для всех существующих пользователей своего домена в поддомене _spf.example.com, опубликовать политику '+exists:%{l}._spf.example.com' и таким образом разрешить пересылку (forward) всех писем для существующих пользователей и запретить - для несуществующих. При реализации такого подхода придется смириться со следующими трудностями: Требуется либо поддерживать вручную в DNS-зонах списки возможных отправителей почты из домена, либо реализовать специализированное ПО для этой цели. Если отправитель рассылает много почты (сервис бесплатной почты, например), либо спамеры рассылают много почты от его имени, то использование exists совместно с макросами (включающими IP или имя пользователя) создаст большую дополнительную нагрузку на DNS-серверы отправителя. К сожалению, использование механизма exists создает и серьезные проблемы безопасности, как для отправителей, так и для получателей: Возможность верификации списков адресов. Если реализация exists дает возможность удаленно отличить существующий адрес отправителя от несуществующего, то это дает спамерам возможность верификации баз данных адресов. Возможность рассылки спама. Если реализация SPF-политики с механизмом exists разрешает пересылку почты, то эта же политика будет разрешать и спам - пусть и с валидными обратными адресами, так как верифицировать адреса можно через ту же политику. Ведь пересылку почты от user@domain невозможно отличить от посылки спама с поддельным отправителем user@domain. Возможность отправителю следить за путем почты в системе получателя. Если недобросовестный отправитель создал SPF-политику с использованием exists и макросами %{l},%{i}, то при каждой проверке SPF-политики он будет получать данные: откуда пересылается письмо (расширение макроса %{i}), куда пересылается письмо (по адресу, с которого пришел DNS-запрос), от какого пользователя пересылается письмо (по макросу l). 2.4.3. Проблемы SPF - резюме На сегодняшний день SPF является несовместимой с пересылками почты, так как оба варианта решения "проблемы пересылок" неудовлетворительны: Протокол трудно ввести быстро и повсеместно. Мгновенное введение поддержки необходимых механизмов (подмены отправителя или расширений протокола SMTP) на всех (потенциальных) транзитных почтовых серверах представляется совершенно невероятным событием, а без такой поддержки будет либо теряться почта, либо будут появляться "дырки" для спама. Если же посылающие системы будут поддерживать либеральную политику ("?all"), то исчезнет стимул к модификации пересылающих систем, так как почта при пересылках будет доставляться, а не отвергаться. Использование SPF-механизма exists открывает очевидные дыры в безопасности (верификация наличия пользователей в домене, возможности слежения за путем письма), которые не могут считаться приемлемыми. Часть 2 - в следующем номере Спамтест.   Написать письмо Прислать статью редактору Мнение редакции не всегда совпадает с мнением авторов материалов. Редакция оставляет за собой право не публиковать присланную статью без объяснения причин. Присланные статьи не рецензируются. (C) ЗАО "Ашманов и Партнеры", 2003-2004