VoIP для начинающих

За последний год спам достиг таких объемов, что начал угрожать самому существованию электронной почты. Если раньше спамовые письма были слабым шумом на фоне полезного сигнала, то в прошлом году речь шла, скорее, об искусном выделении слабого сигнала из сильного шума.
По счастью, широкое распространение яда вызвало сильное внимание к противоядию, и в 2004 году положение уже далеко не столь катастрофично. Сегодня организационные и технологические меры позволяют удерживать спам в разумных границах.
Распространению спама во многом способствовала открытость почтового протокола, и в частности — сложность определения реального отправителя письма.
Понятие «отправитель» вообще запутано. Есть три параметра, по которым можно пытаться определить источник письма:
1) Envelope-from (так обычно называется заголовок, добавляемый в письмо некоторыми почтовыми программами при доставке конечному получателю, когда само понятие конверта теряется вместе со всей содержавшейся в нем информацией);
2) From (значение поля «от кого» сообщения);
3) Другие служебные заголовки (Sender, Resent-To, Resent-From и т.п.).
Со значением Envelope-from работает почтовый сервер в момент приема письма, в частности, оно используется для отправки квитанций о недоставке сообщения. Значение From видит пользователь в почтовом клиенте. Заголовки, описанные в третьем пункте, могут использоваться как справочная информация.
Часто все три параметра совпадают, но это совершенно необязательно. Протокол SMTP изначально предусматривал ситуацию, когда пользователь, отправивший письмо, отличается от автора письма (того, от чьего имени письмо отправлено). Но никто не предполагал, что эту информацию будут сознательно подделывать.
Сегодня 99% спамовых и вирусных писем используют поддельные адреса. From — чтобы ввести в заблуждение пользователей, Envelope-from — чтобы обмануть почтовые сервера и антиспамовые системы. Для уменьшения возможности подобного обмана и была придумана технология идентификации отправителя электронного сообщения. Наиболее популярная сегодня реализация этой технологии называется SPF (Sender Policy Framework).
SPF-Classic позволяет владельцу почтового домена сформулировать политику, то есть описать, в какой степени он рекомендует доверять тем или иным серверам, отправляющим почту от имени почтовых адресов в этом домене; а получателю письма проверить, соответствуют ли два параметра — IP-адрес сервера отправителя и адрес, указанный в письме — политике домена, которому этот адрес принадлежит.
Проверка дает вероятность того, что адрес не был подделан. Дальше эту вероятность можно учесть в антиспамовом фильтре.
Тут надо чуть подробнее объяснить, что значит «учесть в фильтре». Современные эффективные антиспамовые системы, как правило, работают со всеми возможными признаками, присущими письму, его получателю и отправителю. Чтобы дать представление о признаках, перечислим некоторые из тех, которые используются в Спамообороне Яндекса:
— «маршрут» письма в сети, служебные заголовки;
— особенности оформления письма (например, невидимый текст);
— характерные для спама слова и фразы;
— статистические особенности письма (например, искажение написания слов);
— «черные» списки известных спамеров;
— «белые» списки — адреса корреспондентов получателя;
— счетчики массовости писем и аттачей.
и многие другие.
При этом ни один признак не обладает ни 100%-ой полнотой, ни 100%-ой точностью. То есть, если проводить фильтрацию любым ОДНИМ признаком, фильтр будет и пропускать много спама, и отфильтровывать «честные» письма. Однако проверка письма по большому набору признаков и вычисление кумулятивного веса дает возможность минимизировать число ошибок.
Сегодня в Спамообороне Яндекса используется около 2000 правил, что позволяет фильтровать не менее 95% спама, практически не допуская ложных срабатываний. С точки зрения Спамообороны проверка SPF является еще одним правилом, которое вносит свой (не решающий!) вклад в общий спамовый вес письма.
Надо отметить, что, несмотря на то, что технология SPF появилась совсем недавно, она уже обросла мифами. Ниже мы рассмотрим некоторые из них.

Миф 1. SPF не является панацеей от спама и поэтому не нужен.
Да, как было сказано выше, SPF не является универсальным антиспамовым фильтром, это лишь способ максимально возможной в существующей среде идентификации отправителя, степень доверия к которой определяет получатель.
При этом результаты эксперимента Алексея Тутубалина (статья «опыт практической эксплуатации SPF», обубликована в этом же номере СР в рубрике «Лабораторная работа»), в котором SPF-идентификация не совсем корректно использована как единственный признак фильтрации, показывают, что, даже в условиях едва начавшегося внедрения SPF и неоптимальной его интерпретации, это дает вполне осмысленные результаты и позволяет начать использование уже сейчас.
Надо также отметить, что SPF можно учитывать не только для подавления спама, но и для уменьшения ложных срабатываний, то есть как «белый» признак.
Например, есть сети, администраторы которых не в состоянии проследить за своими пользователями и состоянием их взломанных компьютеров. Такие сети часто попадают в «черные» списки. Публикация SPF позволит администраторам «отбелить» законные письма своих пользователей, которые в «нормальном» случае авторизуются и отправляют письма с «разрешенного» данным провайдером IP-адреса.

Миф 2. SPF могут установить все, то есть — и спамеры тоже.
Действительно, в теории любой человек может, даже корректно представившись, рекламировать себя самым навязчивым образом. Однако на практике это происходит крайне редко — ведь, однажды определив этого отправителя, его просто перестанут слушать, то есть принимать от него почту. Именно поэтому спам рассылается с разных поддельных адресов.
Теоретически спамер может для рассылки очередного десятка тысяч писем покупать за 10 долларов отдельный домен. Однако это явно усложнит и удорожит его деятельность. Кроме того, в условиях, когда на глазах ужесточается законодательство, подобный способ становится все более и более опасным для спамера.

Миф 3. SPF не применим при пересылке (forward) писем, поэтому его использование бессмысленно.
Простейшее решение — входной почтовый сервер применяет SPF с большей степенью доверия в случае с одним RECEIVED и в меньшей — в случае с несколькими. Надо отметить, что доля «пересыльного» трафика в общем трафике почты колеблется в районе 1%.
Рассмотрим ситуацию, когда пользователь с сервера sender.ru шлет письмо приятелю по адресу drug@reciever.ru, а приятель по какой-то причине настроил forward на адрес name@forward-server.ru.
В худшем случае SPF-политика сервера sender.ru описана таким образом, что запрещает использовать анонимных пересыльщиков, а пересылающий сервер reciever.ru ничего не знает про SPF, SUBMITTER, SRS и пр. и пр., и никак себя не идентифицирует, не имеет SPF-политики и т.д. то письмо будет отвергнуто.
То есть отправитель получит квитанцию с кодом и описанием ошибки, эквивалент которого на русском языке звучит примерно так:
«Почта данному получателю (name@forward-server.ru) доставлена быть не может, так как сервер, с которого пришло письмо (reciever.ru), не авторизован отправляющей стороной (sender.ru).»
Разумно предположить, что, получив такую квитанцию, пользователь догадается, что его приятель имеет новый адрес, и сможет послать письмо теперь уже напрямую, ведь адрес получателя — name@forward-server.ru — явно содержится в теле почтовой квитанции.
Но обычно администратор сети, принимающей пересылаемую почту, обладает информацией о том, кто пересылает сообщения в его сеть, и знанием, кому и как можно доверять. Эта информация может быть использована для разумной настройки.

Миф 4. SPF существенно затрудняет пересылку почты в локальной сети.
Рассмотрим работу SPF в локальной сети с резервными почтовыми серверами. Это может быть сеть одного провайдера или крупной компании.
В такой сети почта при приеме пересылается между двумя-тремя серверами, и, если администраторы не позаботятся о синхронном обновлении почтового ПО, работающего в этой сети — например, установят поддержку SPF не на всех серверах, не поставят патчи и т.д., — то могут возникнуть временные проблемы. Если при этом неаккуратному администратору еще придет в голову использовать SPF как единственный антиспам-фильтр, да еще и однозначно доверительный, проблема может стать заметной всем его пользователям.
Однако надо заметить, что администраторы и так имеют много способов нарушить связность сети, поскольку Интернет — сложная гетерогенная среда с массой протоколов, видов трафика и т.д. При этом следить за корректным прохождением почтового трафика — не бог весть какая задача, обычно после апдейта ПО на сервере достаточно отправить тестовое письмо и проследить за его прохождением.

Миф 5. SPF генерирует большую нагрузку — лишние обращения к DNS.
Уже сегодня типичная почтовая система, даже с минимальными антиспамовыми настройками совершает не менее трех обращений к DNS на каждое письмо, включая, по меньшей мере, один «тяжелый» запрос на обратное разрешение доменного имени. Еще не так давно таких обращений вообще не было, однако с это проблемой научились справляться достаточно дешево. Еще одного обращения просто никто не заметит.

Миф 6. SPF угрожает безопасности и помогает спамерам, поскольку позволяет посредством запросов к политике выяснить наличие или отсутствие пользователя с конкретным адресом.
Данное утверждение относится к лобовому применению метода exists, одним из способов использования которого является проверка имени пользователя.
Того же самого результата можно достичь с теми же затратами другим способом, без «помощи» SPF. Например, просто обращаясь к почтовому серверу, симулируя попытку послать письмо, или непосредственно в процессе рассылки спама. При этом, сама по себе «лобовая» проверка имени пользователя при использовании exists на практике не используется: гибкость механизма позволяет создать существенно более сложный «сервер принятия решения», учитывающий статистику IP, рассылающих спам, распределение запросов и другие факторы, тем самым затруднив пресловутую «лобовую проверку».

Миф 7. Не имеет смысла учитывать SPF, пока политику не пропишет подавляющее количество серверов.
В полном согласии с законом Ципфа, 10% серверов генерируют 90% трафика. То есть, если даже только крупные игроки начнут применять SPF, это поможет идентифицировать значительную долю почтовых сообщений.
Именно поэтому Яндекс поддерживает инициативу и способствует ее пропаганде и распространению. В том числе — и в форме данной статьи.

Илья Сегалович, Елена Колмановская, Павел Завьялов, компания «Яндекс».