Sender Policy Framework ( SPF ) — это метод аутентификации электронной почты , который гарантирует, что отправляющий почтовый сервер имеет право отправлять почту из домена отправителя электронной почты. [1] [2] Эта аутентификация применяется только к отправителю электронной почты, указанному в поле «Конверт от» во время первоначального SMTP-соединения. Если электронное письмо отклонено, на этот адрес отправляется сообщение [2] , и при нисходящей передаче оно обычно появляется в заголовке «Return-Path». Для аутентификации адреса электронной почты, который фактически виден получателям в строке «От:», необходимо использовать другие технологии, такие как DMARC . Подделка этого адреса известна как подмена электронной почты [ 3] и часто используется при фишинге и спаме в электронной почте .
Список авторизованных отправляющих хостов и IP-адресов для домена публикуется в записях DNS для этого домена. Структура политики отправителей определена в RFC 7208 от апреля 2014 года как «предлагаемый стандарт». [4]
Первое публичное упоминание концепции состоялось в 2000 году, но осталось практически незамеченным. [5] Эта концепция больше не упоминалась до тех пор, пока в 2002 году в списке рассылки «namedroppers» IETF не была опубликована первая попытка спецификации, подобной SPF , Дана Валери Риз, [6] [3] [5] , которая не знала упоминания об этой идее в 2000 году. На следующий день Пол Викси разместил в том же списке свою собственную спецификацию, подобную SPF. [7] [5] Эти сообщения вызвали большой интерес, что привело к формированию Антиспамовой исследовательской группы IETF (ASRG) и ее списка рассылки, где идея SPF получила дальнейшее развитие. Среди предложений, представленных ASRG, были «Обратный MX » (RMX) Хадмута Даниша и «Назначенный протокол почтовой программы» (DMP) Гордона Фесика. [8]
В июне 2003 года Мэн Вен Вонг объединил спецификации RMX и DMP [9] и запросил предложения от других. В течение следующих шести месяцев было внесено большое количество изменений, и большое сообщество начало работать над SPF. [10] Первоначально SPF расшифровывался как Sender Permit From и иногда также назывался SMTP+SPF ; но в феврале 2004 года его название было изменено на Sender Policy Framework .
В начале 2004 года IETF создал рабочую группу MARID и попытался использовать SPF и предложение Microsoft CallerID в качестве основы для того, что сейчас известно как Sender ID ; но это рухнуло из-за технических и лицензионных конфликтов. [11]
Сообщество SPF вернулось к исходной «классической» версии SPF. В июле 2005 года эта версия спецификации была одобрена IESG как эксперимент IETF , предложив сообществу наблюдать за SPF в течение двух лет после публикации. 28 апреля 2006 г. SPF RFC был опубликован как экспериментальный RFC 4408.
В апреле 2014 года IETF опубликовала SPF в RFC 7208 как «предлагаемый стандарт».
Простой протокол передачи почты позволяет любому компьютеру отправлять электронную почту, утверждая, что она отправлена с любого исходного адреса. Этим пользуются спамеры и мошенники, которые часто используют поддельные адреса электронной почты , [12] что затрудняет отслеживание источника сообщения и позволяет спамерам скрыть свою личность, чтобы избежать ответственности. Он также используется в методах фишинга , когда пользователей можно обманом заставить раскрыть личную информацию в ответ на электронное письмо, предположительно отправленное такой организацией, как банк.
SPF позволяет владельцу интернет-домена указать, какие компьютеры имеют право отправлять почту с адресами конверта в этом домене, используя записи системы доменных имен (DNS). Получатели, проверяющие информацию SPF в записях TXT, могут отклонять сообщения из неавторизованных источников до получения тела сообщения. Таким образом, принципы работы аналогичны принципам работы списков черных дыр на основе DNS ( DNSBL ), за исключением того, что SPF использует схему делегирования полномочий системы доменных имен. Текущая практика требует использования записей TXT [13] , как и в ранних реализациях. На некоторое время был зарегистрирован новый тип записи (SPF, тип 99), который стал доступен в обычном программном обеспечении DNS. В то время использование записей TXT для SPF задумывалось как переходный механизм. В экспериментальном RFC, RFC 4408, раздел 3.1.1, предлагалось, что «доменное имя, совместимое с SPF, ДОЛЖНО иметь записи SPF обоих типов RR». [14] В предлагаемом стандарте RFC 7208 говорится, что «использование альтернативных типов DNS RR поддерживалось на экспериментальной стадии SPF, но было прекращено». [13]
Адрес отправителя конверта передается в начале диалога SMTP. Если сервер отклоняет домен, неавторизованный клиент должен получить сообщение об отклонении, и если этот клиент был агентом ретрансляционной передачи сообщений (MTA), может быть сгенерировано сообщение о возврате на исходный адрес отправителя конверта. Если сервер принимает домен, а затем также принимает получателей и тело сообщения, он должен вставить поле Return-Path в заголовок сообщения, чтобы сохранить адрес отправителя конверта. Хотя адрес в Return-Path часто соответствует другим адресам отправителя в заголовке письма, например, header -from , это не обязательно так, и SPF не предотвращает подделку этих других адресов, таких как заголовок отправителя .
Спамеры могут отправлять электронную почту с результатом SPF PASS, если у них есть учетная запись в домене с политикой отправителя или они злоупотребляют взломанной системой в этом домене. Однако это упрощает отслеживание спамера.
Основное преимущество SPF — для владельцев адресов электронной почты, подделанных в Return-Path. Они получают большое количество нежелательных сообщений об ошибках и других автоматических ответов. Если такие получатели используют SPF для указания законных IP-адресов источника и указывают результат FAIL для всех остальных адресов, получатели, проверяющие SPF, могут отклонять подделки, тем самым уменьшая или устраняя количество обратного рассеяния .
SPF имеет потенциальные преимущества, помимо помощи в выявлении нежелательной почты. В частности, если отправитель предоставляет информацию SPF, получатели могут использовать результаты SPF PASS в сочетании со списком разрешений для идентификации известных надежных отправителей. Сценарии, подобные взломанным системам и почтовым программам совместной отправки, ограничивают такое использование.
Если домен публикует запись SPF, спамеры и фишеры с меньшей вероятностью будут подделывать электронные письма, выдавая себя за отправленные из этого домена, поскольку поддельные электронные письма с большей вероятностью попадут в спам-фильтры, которые проверяют запись SPF. Таким образом, домен, защищенный SPF, менее привлекателен для спамеров и фишеров. Поскольку домен, защищенный SPF, менее привлекателен в качестве поддельного адреса, он с меньшей вероятностью попадет в список запрещенных спам-фильтрами, и поэтому в конечном итоге законная электронная почта из домена с большей вероятностью пройдет. [15]
SPF нарушает обычную пересылку сообщений . Когда домен публикует политику SPF FAIL, законные сообщения, отправленные получателям, пересылающим почту третьим лицам, могут быть отклонены и/или возвращены, если происходит все следующее:
Это необходимая и очевидная особенность SPF — проверки за «границей» MTA ( MX ) получателя не могут работать напрямую.
Издатели политик SPF FAIL должны принять риск того, что их законные электронные письма будут отклонены или возвращены. Им следует тестировать (например, с помощью политики SOFTFAIL) до тех пор, пока они не будут удовлетворены результатами. Ниже приведен список альтернатив простой пересылке сообщений.
Для пустого Return-Path, используемого в сообщениях об ошибках и других автоматических ответах, проверка SPF идентификатора HELO является обязательной.
При поддельном идентификаторе HELO результат NONE не поможет, но для действительных имен хостов SPF также защищает идентификатор HELO. Эта функция SPF всегда поддерживалась как опция для приемников, и в более поздних проектах SPF, включая окончательную спецификацию, рекомендуется всегда проверять HELO.
Это позволяет получателям включать в список разрешенных отправителей почтовые программы на основе HELO PASS или отклонять все письма после HELO FAIL. Его также можно использовать в системах репутации (любой список разрешений или запретов — это простой случай системы репутации).
Соблюдение SPF состоит из трех слабо связанных друг с другом задач:
551 User not local; please try <[email protected]>)Таким образом, ключевым вопросом в SPF является спецификация новой информации DNS, которую устанавливают домены и используют получатели. Записи, представленные ниже, имеют типичный синтаксис DNS, например:
"v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.123 a -all"
"v=" определяет используемую версию SPF. Следующие слова предоставляют механизмы , которые можно использовать для определения того, имеет ли домен право отправлять почту. «ip4» и «a» указывают системы, которым разрешено отправлять сообщения для данного домена. «-all» в конце указывает, что если предыдущие механизмы не совпали, сообщение должно быть отклонено.
Определены восемь механизмов :
Каждый механизм можно комбинировать с одним из четырех квалификаторов :
+для результата PASS. Это можно опустить; например, +mxто же самое, что и mx.?для НЕЙТРАЛЬНОГО результата, интерпретируемого как НЕТ (нет политики).~(тильда) для SOFTFAIL, средства отладки между НЕЙТРАЛЬНЫМ и FAIL. Обычно сообщения, возвращающие SOFTFAIL, принимаются, но помечаются тегами.-(минус) в случае FAIL письмо должно быть отклонено (см. ниже).Модификаторы допускают будущие расширения платформы. На сегодняшний день широкое распространение получили только два модификатора, определенные в RFC 4408:
exp=some.example.comдает имя домена с записью DNS TXT (интерпретируемое с помощью языка макросов SPF), чтобы получить объяснение результатов FAIL — обычно URL-адрес , который добавляется к коду ошибки SMTP. Эта функция используется редко.redirect=some.example.comможет использоваться вместо механизма ALL- для связи с записью политики другого домена. Этот модификатор легче понять, чем несколько похожий механизм INCLUDE .Как только реализации SPF обнаруживают синтаксические ошибки в политике отправителя, они должны прервать оценку с результатом PERMERROR. Пропуск ошибочных механизмов не может работать должным образом, поэтому include:bad.exampleтакже redirect=bad.exampleвызывает ОШИБКУ.
Другая гарантия — это максимум десять механизмов, запрашивающих DNS, то есть любой механизм, кроме IP4, IP6 и ALL. Реализации могут прервать вычисление с результатом TEMPERROR, если оно занимает слишком много времени или время ожидания DNS-запроса истекло, или они могут продолжать делать вид, что запрос не вернул никаких данных — это называется «пустым поиском». Однако они должны вернуть PERMERROR, если политика прямо или косвенно требует более десяти запросов к механизмам . Кроме того, они должны возвращать PERMERROR, как только обнаружено более двух «пустых поисков». Любые redirect=также учитываются в рамках этих ограничений обработки . [16]
Типичная политика SPF HELO v=spf1 a mx ip4:192.0.2.0 -allможет выполнять четыре или более DNS-запросов: (1) запись TXT (тип SPF устарел согласно RFC 7208), (2) A или AAAA для механизма a, (3) запись MX и (4+) A или AAAA для каждого имени MX, для механизма mx. За исключением первого, все эти запросы учитываются до предела 10. Кроме того, если, например, отправитель имеет адрес IPv6, а его имя и два его имени MX имеют только адреса IPv4, то оценка первых двух механизмов уже приводит к более чем двум пустым поискам и, следовательно, к ошибке PERMERROR. Механизмы ip4и не требуют поиска DNS ip6.all
Чтобы обеспечить быстрое тестирование и развертывание, первоначальные версии SPF проверяли его настройку в записи DNS TXT отправляющего домена, хотя традиционно предполагалось, что эта запись будет текстом в свободной форме без какой-либо семантики. [17] Хотя в июле 2005 года IANA присвоило SPF конкретный тип записи ресурсов 99, популярность которого никогда не была высокой, а наличие двух механизмов сбивало пользователей с толку. В 2014 году использование этой записи было прекращено после того, как рабочая группа SPFbis пришла к выводу, что «...значительный переход на тип RR SPF в обозримом будущем очень маловероятен и что лучшим решением для решения этой проблемы совместимости является прекращение поддержки Тип SPF RR». [13]
Поскольку SPF все чаще предотвращает подделку спамерами адреса отправителя конверта, многие перешли к подделке только адреса в поле «От» заголовка письма, который фактически отображается получателю, а не только обрабатывается агентом передачи сообщений получателя (MTA). . Однако SPF (или DKIM ) можно использовать вместе с DMARC , чтобы также проверить поле «От» заголовка письма. Это называется «выравниванием идентификаторов».
Для защиты от такой подделки отображаемого имени необходимы специальные собственные реализации, которые не могут использовать SPF. [18] [19] [20]
Программное обеспечение для защиты от спама, такое как SpamAssassin версии 3.0.0 и ASSP, реализует SPF. Многие агенты передачи почты (MTA) напрямую поддерживают SPF, такие как Courier , CommuniGate Pro, Wildcat , MDaemon и Microsoft Exchange , или имеют доступные исправления или плагины, поддерживающие SPF, включая Postfix , Sendmail , Exim , qmail и Qpsmtpd . [21] По состоянию на 2017 год более восьми миллионов доменов опубликовали -allполитики SPF FAIL. [22] Согласно опросу, опубликованному в 2007 году, 5% доменов .comи .netимели ту или иную политику SPF. В 2009 году непрерывное исследование, проведенное Nokia Research, показало, что 51% протестированных доменов используют политику SPF. [23] Эти результаты могут включать тривиальные политики, такие как v=spf1 ?all. [24] [25] [ нужно обновить ]
В апреле 2007 года BITS, подразделение Круглого стола по финансовым услугам, опубликовало рекомендации по безопасности электронной почты для своих членов, включая развертывание SPF. [26] В 2008 году Рабочая группа по борьбе со злоупотреблениями сообщениями (MAAWG) опубликовала документ об аутентификации электронной почты, охватывающей SPF, Sender ID и DomainKeys Identified Mail (DKIM). [27] В своих «Лучших практиках общения с отправителями» MAAWG заявила: «По крайней мере, отправители должны включать записи SPF для своих почтовых доменов». [28] В 2015 году Рабочая группа по борьбе со злоупотреблением сообщениями (MAAWG) пересмотрела документ об аутентификации электронной почты, охватывающий SPF, почту, идентифицируемую доменными ключами (DKIM) и DMARC (DMARC). В своей пересмотренной «Лучшей практике общения с отправителями» MAAWG заявила: «Аутентификация поддерживает прозрачность путем дальнейшей идентификации отправителя (отправителей) сообщения, а также способствует сокращению или устранению поддельных и поддельных адресов». [29]
Тщательно настроенная запись SPF снизит вероятность мошеннической подделки вашего доменного имени и предотвратит пометку ваших сообщений как спама до того, как они достигнут получателей. Подмена электронной почты — это создание сообщений электронной почты с поддельным адресом отправителя; это просто сделать, потому что многие почтовые серверы не выполняют аутентификацию. В спам- и фишинговых письмах такая подмена обычно используется, чтобы ввести получателя в заблуждение относительно происхождения сообщения.