Пользователь
0,0
рейтинг
7 июля 2009 в 14:24

Что такое SPF

Думаю, никому не нужно объяснять, какой проблемой является спам в наше время. Борьба с этим злом — дело не простое, и если хочется приблизится к идеалу, требующее сочетания нескольких элементов. Одним из этих элементов является протокол 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, иметь записи обоих типов. Вместе с тем, как минимум одна запись должна присутствовать обязательно. В случае наличия двух записей они должны быть идентичны. Например:
example.com. IN TXT «v=spf1 +mx a:colo.example.com/28 -all»
example.com. IN SPF «v=spf1 +mx a:colo.example.com/28 -all»
Если установлена запись SPF, то TXT записи должны быть проигнорированы.

Механизм взаимодействия


Почтовый обмен с использованием 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:<user@example.com>
А вот в этом месте, после выдачи отправителем MAIL FROM должна последовать обязательная проверка, интерпретация результата и реакция на него.
В данный момент модуль, отвечающий за проверку 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 все шире и шире, что несет всем пользователям электронной почты пользу, почтовым серверам снижение трафика и в целом делает мир лучше :)

Алексей @intnzy
карма
46,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое

Комментарии (43)

  • +2
    К сожалению этим средством пользуются только «большие» фирмы… яндекс гугл и тд…
    а большинство фирм имеющих собвственные почтовые сервера (с которыми как правило и обмениваются деловой корреспонденцией) об этом забывают.

    Особенно этим грешат всякие гос. конторы… им не надо соблюдать стандарты, у них есть административный ресурс
    • 0
      Ну не только яндекс, гугл…

      В Европе (например) цивилизованный емэил-маркетинг вполне так развит. И компании, рассылающие письма клиентам и подписчикам (в том числе с использованием сторонних сервисов) используют SPF.
  • 0
    Спасибо за содержательную статью.
    Примеры более чем понятны.
    Если решу перенести почту с гугловского хостинга, то буду использовать информацию статьи.
    • 0
      кстати вопрос, к автору топика, если мой домен сидит на гуглопочте, то мне нужно что то прописывать в ДНС для включения этого механизма?
      • –2
        По идее нет. По крайней мере об этом не было написано в хелпе при переходе на гугловские сервера.
        Как перенес почту на гугл еще ни одно письмо не упало в спам у друзей/партнеров/клиентов.
        • +2
          нужно. нет записи- SPF не задействован — проверка просто не производится.
          • 0
            Видимо SPF далеко не приоритетная проверка. По крайней мере сейчас.
            Когда настраивал корпоративную почту была проблема из-за того, что не была добавлена PTR запись и почтовики просто отфутболивали почту.
            P.S. Пойду пропишу TXT и SPF.
            • 0
              SPF предназначен в основном не для отбраковки спама, а для того, что бы письма с определённых доменов автоматом в спам _не_ попадали (вайтлистинг) — это как раз и актуально для крупных бесплатных мылохостингов. Для блэклистинга есть DNSBL.
          • 0
            сори, веткой ошибся
      • 0
        по идее — да. т.е. если у вас сейчас ничего нет в TXT для домена — значит SPF просто нету.
        мне кажется, можно себе добавить «v=spf1 include:_netblocks.google.com ~all», так как ваши исходящие будут как раз из гуглосетки.
        • 0
          Почитал ссылку, которую дал swansson
          Нужно добавить TXT запись: v=spf1 include:aspmx.googlemail.com ~all
          P.S. Актуально для тех, кто хостит свою почту на серверах гугла.
      • 0
        Нужно.
        include:aspmx.googlemail.com
        Покурите справку, там где-то было.
    • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        Указал еще вчера.
        Просто думал, что раз почта хостится у гугла, то это не нужно.
        • НЛО прилетело и опубликовало эту надпись здесь
          • 0
            Я просто не придавал этому значения.
            Когда придет время разобраться с почтой более детально, тогда проштудирую литературу на данную тематику:)
            А пока a, mx, spf и ptr записи настроены и почта бегает отлично, спам не сыплется.
            • 0
              "… спам не сыплется."
              SPF нужен не для того, чтобы на ваши домены не сыпался спам.
              Скорее он нужен для уменьшения вероятности того, что получатель завернет ваши письма, приняв их за спам.
              По личным наблюдениям острее всего к отсутствию SPF относятся отдельные почтовые сервера средних организаций. Видимо, их админы любят -all
              • +1
                Извиняюсь, что ввел в заблуждение.
                Я говорил про личный домен, а не корпоративный, когда писал какие записи настроены.
                А с него письма уходят на gmail.com и подобные сервисы.
                Проблем, как я писал выше, не было. Скорее всего именно из-за того, что отправляются не на сервера средних организаций:)
                Тем не менее учел замечания и вчера прописал SPF записи как у себя на домене, так и на корпоративном.
                Спасибо за пояснения.
  • 0
    Интересно. Еще было бы интересно узнать как правильно настроить поддержку SPF в разных MTA (особенно в sendmail).
    • +1
      имхо лучше использовать для этих целей спамассассин:
      init.pre
      loadplugin Mail::SpamAssassin::Plugin::SPF
      тогда в случае, если у домена нет SPF записи, то письмо получит определенный SCORE для дальнейшего определения письма спамом или нет.
  • 0
    >Вообще, я считаю, что данный момент очень спорный. Использование промежуточного ящика для перенаправления трафика на другой ящик весьма напоминает спам-атаку. Вот, например, я регистрирую ящик, свечу его везде, где только можно, подписываюсь на миллион рассылок, и ставлю редирект на некий ящик, который я хочу завалить спамом.

    При включении пересылки требуется подтверждение от получателя.
    Да и можно просто отсечь письма в которых получателем значится не мой e-mail
    • 0
      При включении пересылки требуется подтверждение от получателя.
      ой-ли? прям-таки все-все почтовики интернетов делают такую проверку? а если я делаю форвардер на своем MTA на своем же серваке?

      Да и можно просто отсечь письма в которых получателем значится не мой e-mail
      отсечь — не вопрос! однако, в случае легитимности форвардера можно напоростся на проблемы с проверками.
      • +3
        мой моск понял что твой знает больше
  • –1
    mail.ru, кстати, в некоторых случаях (точно не смог выяснить в каких), не принимает почту с доменов, у которых не прописан SPF.
    • +1
      У нас почту отфутболивали до тех пор пока PTR запись не прописали. С этого момента сразу все стало нормально. SPF прописал только вчера.
      • 0
        Для нормальной работы почтовика обязательно нужны прямая и обратная зоны днс.
  • 0
    А у меня SPF выступает вторым эщелоном борьбы со спамом. Первый — Яндекс.Спамооборона, а если в заголовке писем нет отметки о том, что письмо проверено (бывает иногда сервис падает), то фильтр берет и все не-валидные по SPF призанку письма складывает отдельно.
  • +5
    Имхо, SPF никак не помогает в борьбе со спамом. С фишингом — да, но не со спамом.
    Нет никакой проблемы для спамера, чтобы зарегать тыщу доменов и прописать им корректные SPF.
    • +2
      и эти домены моментальным образом попадут в блэк-листы, и в абуз. Одни убытки, короче.
      самое эффективные — это бот-неты.
    • 0
      От спама больше грейлисты помогают)
      • 0
        Но получаем задержку первого письма, которая не всегда приемлима.
        • 0
          Ну чем то приходится жертвовать)
  • 0
    несколько лет назад выступая в г.Сочи на «ИБ. Региональные аспекты» с докладом о безопасности электронной почты, я упоминал про SPF, но только в плане спасения от фишинга. от спама, как уже было упомянуто, эта технология не спасет. а фишинг… ну хз, угроза, конечно, значимая, но не является основной у электронной почты на мой взгляд.
    • 0
      >>от спама, как уже было упомянуто, эта технология не спасет
      спасает. огромный процент спама генерят бот-неты. в данном случае — SPF легко выскрывает спамера
      • 0
        не буду спорить, давно уже не занимаюсь ИБ. очень вероятно что я не прав. технология будет работать на полную мощность, если больший процент серверов будет ее использовать.
        • 0
          как я уже говорил — SPF работает, но, конечно же, не панацея, а лишь один из элементов комплекса мер
  • 0
    Вопрос к тем, у кого корпаративные почовые сервера.
    Вы удаляете почту, определенную как спам или сохраняете ее в отдельную папку, типа СПАМ?
    Ведь потеря письма неприемлима в компаниях.
    Удалять спам или не удалять, принимать и хранить?
    • 0
      У меня стоит SpamAssassin, которые отклоняет письма получившие высокий score и пропускает те, у которых score близок к пороговому значению, помечая их как спам. То есть мой вариант — пропускать выборочно.
    • 0
      Помечаем в теме, перенаправление в папку пока не реализовали.
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      Что-то я очкую давать почтовому агенту возможность редактировать DNS записи:)
      • 0
        Ну не все ведь записи, а только TXT и SPF. Все остальное ему не захочется править, надеюсь :)

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.