Сергей Яремчук
Интернет разрабатывался как закрытая военная сеть, со временем сеть стала
открытой, всплыли просчеты, результат которых – DOS-атаки, подделка имен DNS,
черви, спам и многое другое. Все это реалии сегодняшнего Интернета. Технология Sender
Policy Framework – лишь одна из попыток исправить ситуацию.
Технологии борьбы со спамом в
RFC
Изменить действующие технологии в глобальном масштабе уже невозможно. Это
потребует колоссальных затрат, как временных, так и финансовых. Поэтому все
наработки появляются в виде расширений к уже действующим протоколам. Так, Sender
Policy Framework (структура политики отправителя) является еще одним
расширением к протоколу отправки электронной почты SMTP (Simple Mail Transfer Protocol).
Протокол SMTP, заменивший в 80-х годах UUCP, не
поддерживает единой схемы авторизации пользователя при отправке сообщения. В
результате можно легко отправить сообщение, указав в команде MAIL FROM
произвольный, в том числе и несуществующий почтовый адрес отправителя. Такое
поведение нормально, ведь изначально протокол предусматривал и ситуацию, когда
автор сообщения и его отправитель не одно и то же лицо. Да и понятие
отправителя SMTP весьма запутанно. Под этот термин попадают заголовки From, Sender,
Resent-From и даже Envelope-from (заголовок, вырабатываемый почтовыми
программами).
Результатом стало появление нескольких
рекомендаций и дополнений к SMTP. Так, в RFC 2505 от февраля 1999 года, который
так и назывался «Anti-Spam Recommendations for SMTP MTAs» дана оценка спаму как
явлению, заговорили о необходимости борьбы со спамом, который в то время уже
достиг высокого уровня. И дано 13 рекомендаций, выполнение которых поможет
уменьшить количество спама.
В частности рекомендовалось подтверждение FQDN (Fully
Qualified Domain Name) отправителя сообщения, то есть проверка address -> name
должна соответствовать name -> address, и обсуждены все проблемы, которые
могут возникнуть при такой проверке. Все события должны регистрироваться, в
SMTP-серверах должна быть заложена возможность блокировки узла, сети или
конкретного отправителя.
Именно отсюда берет начало закат эры open
relay-серверов, так как первым пунктом рекомендации говорится о необходимости
аутентификации пользователя перед отправкой сообщения. Кстати в этом же году 1
марта открытым форумом ISP (http://www.ofisp.org)
был одобрен документ «Нормы пользования сетью» (Acceptable Use Policy), который
регламентировал нормы работы в сети, в том числе и ограничение на
информационный шум (спам) и был обязателен для всех пользователей.
Следующий вполне логичный этап – появление
специального расширения Simple Authentication and Security Layer (SASL),
которое позволяет клиенту SMTP указать серверу механизм аутентификации,
произвести обмен по выбранному протоколу аутентификации для идентификации
отправителя путем нового вызова «AUTH». Все это описано в RFC 2554 «SMTP Service
Extension for Authentication», вышедшем в марте 1999 года (то есть через месяц
после RFC 2505).
Параллельно развивались многочисленные
фильтрационные методы, использующие статистический анализ содержания письма
(здесь наиболее популярны решения, работающие по алгоритму, основанному на
теореме Байеса), системы определения признаков массовости сообщения, а также
различные варианты цветных списков: DNS Black List (DNSBL), серый и белый
списки.
