Думаю, никому не нужно объяснять, какой проблемой является спам в наше время. Борьба с этим злом — дело не простое, и если хочется приблизится к идеалу, требующее сочетания нескольких элементов. Одним из этих элементов является протокол SPF. Будучи опубликованным в апреле 2006 года в RFC 2006 года к настоящему времени протокол имеет статус «экспериментальный», и достаточно неплохую распространенность.
SPF взят на вооружение такими гигантами, как Google, Яндекс, Mail.Ru, Microsoft, Рамблер. Yahoo не поддерживает SPF, а пытается продвигать свою разработку DKIM, к слову, не слишком успешно.
Итак — как же работает SPF?
Основная идея такова — хозяин адреса указывает, с каких адресов следует ожидать его почту, и как интерпретировать ошибку, в случае несоответствия. Важно понимать, что эти данные — всего лишь рекомендация отправителя по проверке. Да-да, конечно же, стандарт описывает, как должна принимающая сторона обрабатывать результат, но по всяким причинам принимающая сторона фактически может с ними делать все, что заблагорассудится — полностью соблюсти, интерпретировать по-своему или же вообще проигнорировать рекомендации.
Для размещения данных используется поле TXT в DNS. Так IANA назначила DNS поле с кодом 99 для SPF. Формат SPF поля идентичен TXT. Вообще, использование поля TXT не является оптимальным, но проблема в том, что не всякий DNS сервер и клиент понимает новый SPF тип записи. Поэтому совместное использование TXT и SPF считается хорошим подходом, обеспечивающим совместимость и будущее развитие.
Стандарт рекомендует доменам, удовлетворяющим требованиям SPF, иметь записи обоих типов. Вместе с тем, как минимум одна запись должна присутствовать обязательно. В случае наличия двух записей они должны быть идентичны. Например:
Почтовый обмен с использованием SPF происходит по следующему алгоритму.
Почтовый сервер mx.example.com отправляет письмо на адрес user@example.net. В DNS записи example.com содержатся такие строки:
Итак, mx.example.com устанавливает соединение с SMTP example.net и получает от него, нечто вроде
В данный момент модуль, отвечающий за проверку SPF делает следующие вещи. Осуществляется запрос к DNS. Запрашиваются SPF и TXT поля. Если в полученном ответе присутствует правило SPF, то оно разбирается и происходит анализ на соответствие. В нашем примере это правило «v=spf1 +mx -all». Согласно правила проверяются MX записи, и проводится сверка указанных в записях IP-адресов, полученного из представления DNS-имени и IP-адреса подключившегося отправителя. В данном случае все совпадает, управление возвращается почтовику, и он начинает прием сообщения.
Если бы, вдруг, фактический IP подключившегося отправителя был иным, то анализатор сообщил бы почтовику, что входящее сообщение не валидно, и лучше бы его вообще не принимать, ну или на крайний случай отмаркировать отдельно.
Запись SPF выглядит примерно так:
Эта запись содержит следующую информацию:
версия SPF — 1 (кстати, пока единственная используемая)
письмо может иметь отправителя с IP-адресом, соответствующим записям в MX для домена example.com
письмо может иметь отправителя с IP-адресом, соответствующим одному из адресов в подсети colo.example.com/28
Во всех остальных случаях, когда адрес не соответствует перечисленным условиям, считать отправителя недостоверным.
Вообще, в условии есть 2 части — определитель и механизм.
Определители могут быть: "+" Pass, "-" Fail, "~" SoftFail, "?" Neutral
Механизмы: all, include, A, MX, PTR, IP4, IP6, exists
Результатами проверки условий могут являться следующие определенные результаты:
Возьмем, для примера, какой-нибудь реальный домен. Допустим Google.com. Запрос TXT возвращает
тут говорится, что нужно включить правила из записи _netblocks.google.com. Интересно, что у _netblocks.google.com отсутствует A-запись, а есть только TXT-запись. Вот она:
Тут перечислены подсети, в которых могут находится почтовые сервера Google. Последний механизм all c определителем Neutral сообщает анализатору о том, что адрес отправителя может быть не из разрешенного диапазона. Письма из чужих адресных пространств рекомендуется проверять дополнительно, а не отвергать безусловно. Для такой масштабной структуры, как Google — это верное решение, ибо в процессе работы адреса могут изменятся, например, при временном отказе и переключении на резерв. И к тому же, адрес может меняться пересылками.
Более хитрая SPF запись у Рамблера:
тут указаны 2 подсети, из которых разрешено принимать почту, и 2 набора источников, почта с которых будет иметь результат проверки Fail.
Представьте себе следующую схему — пользователь отправляет письмо с адреса vasily@xyz.com на pupkin@mylo.ru, а там стоит автоматический форвардинг на pupkin@gmail.com. А у домена xyz.com прописано SPF «v=spf1 +mx -all». В итоге, конечный получатель gmail.com сделает проверку, и получит несовпадение адреса фактического отправителя с указанным, и по правилам SPF не примет письмо. Для решения данной проблемы существует SRS: Sender Rewriting Scheme. В двух словах — происходит переписывание форвардером заголовка return-path.
Вообще, я считаю, что данный момент очень спорный. Использование промежуточного ящика для перенаправления трафика на другой ящик весьма напоминает спам-атаку. Вот, например, я регистрирую ящик, свечу его везде, где только можно, подписываюсь на миллион рассылок, и ставлю редирект на некий ящик, который я хочу завалить спамом. В случае наличия у отправителей SPF и отсутствии SRS на пересылающем почтовике — цель отвергнет эти потоки как спам, а вот при работающем SRS он получит вполне «легитимные» потоки почты.
SPF является простым и достаточно эффективным способом оценить легитимность передаваемой почты. Администраторам почтовых серверов стоит минимальных телодвижений добавление SPF записей в DNS. Простота внедрения и поддержка основными популярными MTA делают распространение SPF все шире и шире, что несет всем пользователям электронной почты пользу, почтовым серверам снижение трафика и в целом делает мир лучше :)
SPF взят на вооружение такими гигантами, как Google, Яндекс, Mail.Ru, Microsoft, Рамблер. Yahoo не поддерживает SPF, а пытается продвигать свою разработку DKIM, к слову, не слишком успешно.
Итак — как же работает SPF?
Общие принципы работы
Основная идея такова — хозяин адреса указывает, с каких адресов следует ожидать его почту, и как интерпретировать ошибку, в случае несоответствия. Важно понимать, что эти данные — всего лишь рекомендация отправителя по проверке. Да-да, конечно же, стандарт описывает, как должна принимающая сторона обрабатывать результат, но по всяким причинам принимающая сторона фактически может с ними делать все, что заблагорассудится — полностью соблюсти, интерпретировать по-своему или же вообще проигнорировать рекомендации.
Технические детали
Для размещения данных используется поле TXT в DNS. Так IANA назначила DNS поле с кодом 99 для SPF. Формат SPF поля идентичен TXT. Вообще, использование поля TXT не является оптимальным, но проблема в том, что не всякий DNS сервер и клиент понимает новый SPF тип записи. Поэтому совместное использование TXT и SPF считается хорошим подходом, обеспечивающим совместимость и будущее развитие.
Стандарт рекомендует доменам, удовлетворяющим требованиям SPF, иметь записи обоих типов. Вместе с тем, как минимум одна запись должна присутствовать обязательно. В случае наличия двух записей они должны быть идентичны. Например:
example.com. IN TXT «v=spf1 +mx a:colo.example.com/28 -all»Если установлена запись SPF, то TXT записи должны быть проигнорированы.
example.com. IN SPF «v=spf1 +mx a:colo.example.com/28 -all»
Механизм взаимодействия
Почтовый обмен с использованием SPF происходит по следующему алгоритму.
Почтовый сервер mx.example.com отправляет письмо на адрес user@example.net. В DNS записи example.com содержатся такие строки:
mx.example.com. IN A 208.77.188.166
example.com. IN MX 10 mx.example.com.
example.com. IN TXT «v=spf1 +mx -all»
Итак, mx.example.com устанавливает соединение с SMTP example.net и получает от него, нечто вроде
>> 220 example.net ESMTP Service (Mailer v1.0) ready at 30.07.2009 12:28:21 UTCзатем mx.example.com представляется через HELO/EHLO.
<< HELO mx.example.comВ зависимости от настроек принимающей стороны, после данного представления уже может быть проверка на соответствие представленного имени правилам SPF, но в данном месте это не обязательно
>> 250 example.net Hello mx.example.com., pleased to meet youА вот в этом месте, после выдачи отправителем MAIL FROM должна последовать обязательная проверка, интерпретация результата и реакция на него.
<< MAIL From:<user@example.com>
В данный момент модуль, отвечающий за проверку SPF делает следующие вещи. Осуществляется запрос к DNS. Запрашиваются SPF и TXT поля. Если в полученном ответе присутствует правило SPF, то оно разбирается и происходит анализ на соответствие. В нашем примере это правило «v=spf1 +mx -all». Согласно правила проверяются MX записи, и проводится сверка указанных в записях IP-адресов, полученного из представления DNS-имени и IP-адреса подключившегося отправителя. В данном случае все совпадает, управление возвращается почтовику, и он начинает прием сообщения.
Если бы, вдруг, фактический IP подключившегося отправителя был иным, то анализатор сообщил бы почтовику, что входящее сообщение не валидно, и лучше бы его вообще не принимать, ну или на крайний случай отмаркировать отдельно.
Формат записи
Запись SPF выглядит примерно так:
example.com. IN SPF «v=spf1 +mx a:colo.example.com/28 -all»
Эта запись содержит следующую информацию:
версия SPF — 1 (кстати, пока единственная используемая)
письмо может иметь отправителя с IP-адресом, соответствующим записям в MX для домена example.com
письмо может иметь отправителя с IP-адресом, соответствующим одному из адресов в подсети colo.example.com/28
Во всех остальных случаях, когда адрес не соответствует перечисленным условиям, считать отправителя недостоверным.
Вообще, в условии есть 2 части — определитель и механизм.
Определители могут быть: "+" Pass, "-" Fail, "~" SoftFail, "?" Neutral
Механизмы: all, include, A, MX, PTR, IP4, IP6, exists
Результатами проверки условий могут являться следующие определенные результаты:
* None — означает, что либо в домене нет записей, либо вообще не удается проверить домен. В общем никакого внятного ответа не получено.
* Neutral — возникает в ситуации, когда хозяин домена не хочет или не может сообщить разрешен ли IP. Этот результат должен обрабатываться так же, как и None.
* Pass — означает, что все ОК и получатель может принять письмо.
* Fail — явно указывает на то, что письмо принимать не следует. Проверяющая сторона может отмаркировать письмо либо отбросить.
* SoftFail — находится где-то между Fail и Neutral. Принимающая сторона не должна отбрасывать письмо на основании только этого результата.
* TempError — результат, возникающий, если клиент в момент проверки получает временную ошибку. Сообщение можно принять или временно отвергнуть.
* PermError — ошибка, возникающая при невозможности корректной интерпретации DNS записей отправителя.
Возьмем, для примера, какой-нибудь реальный домен. Допустим Google.com. Запрос TXT возвращает
«v=spf1 include:_netblocks.google.com ~all»
тут говорится, что нужно включить правила из записи _netblocks.google.com. Интересно, что у _netblocks.google.com отсутствует A-запись, а есть только TXT-запись. Вот она:
«v=spf1 ip4:216.239.32.0/19 ip4:64.233.160.0/19 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:209.85.128.0/17 ip4:66.102.0.0/20 ip4:74.125.0.0/16 ip4:64.18.0.0/20 ip4:207.126.144.0/20 ?all»
Тут перечислены подсети, в которых могут находится почтовые сервера Google. Последний механизм all c определителем Neutral сообщает анализатору о том, что адрес отправителя может быть не из разрешенного диапазона. Письма из чужих адресных пространств рекомендуется проверять дополнительно, а не отвергать безусловно. Для такой масштабной структуры, как Google — это верное решение, ибо в процессе работы адреса могут изменятся, например, при временном отказе и переключении на резерв. И к тому же, адрес может меняться пересылками.
Более хитрая SPF запись у Рамблера:
«v=spf1 ip4:81.19.66.0/23 ip4:81.19.88.0/24 -exists:%{ir}.spf.rambler.ru -exists:%{l}.u.spf.rambler.ru ~all»
тут указаны 2 подсети, из которых разрешено принимать почту, и 2 набора источников, почта с которых будет иметь результат проверки Fail.
Проблема пересылки
Представьте себе следующую схему — пользователь отправляет письмо с адреса vasily@xyz.com на pupkin@mylo.ru, а там стоит автоматический форвардинг на pupkin@gmail.com. А у домена xyz.com прописано SPF «v=spf1 +mx -all». В итоге, конечный получатель gmail.com сделает проверку, и получит несовпадение адреса фактического отправителя с указанным, и по правилам SPF не примет письмо. Для решения данной проблемы существует SRS: Sender Rewriting Scheme. В двух словах — происходит переписывание форвардером заголовка return-path.
Вообще, я считаю, что данный момент очень спорный. Использование промежуточного ящика для перенаправления трафика на другой ящик весьма напоминает спам-атаку. Вот, например, я регистрирую ящик, свечу его везде, где только можно, подписываюсь на миллион рассылок, и ставлю редирект на некий ящик, который я хочу завалить спамом. В случае наличия у отправителей SPF и отсутствии SRS на пересылающем почтовике — цель отвергнет эти потоки как спам, а вот при работающем SRS он получит вполне «легитимные» потоки почты.
Заключение
SPF является простым и достаточно эффективным способом оценить легитимность передаваемой почты. Администраторам почтовых серверов стоит минимальных телодвижений добавление SPF записей в DNS. Простота внедрения и поддержка основными популярными MTA делают распространение SPF все шире и шире, что несет всем пользователям электронной почты пользу, почтовым серверам снижение трафика и в целом делает мир лучше :)
