Структура политики отправителя - Sender Policy Framework

Набор интернет-протоколов
Уровень приложения
Транспортный уровень
Интернет-уровень
Связующий слой

Отправитель[1] Основы политики (SPF) является проверка подлинности электронной почты метод, предназначенный для обнаружения подделки адресов отправителя во время доставки электронного письма.[2] Однако только SPF ограничен обнаружением поддельного заявления отправителя в конверте электронного письма, которое используется, когда письмо возвращается.[2] Только в сочетании с DMARC можно ли его использовать для обнаружения подделки видимого отправителя в электронных письмах (подмена электронной почты[3]), метод, часто используемый в фишинг и электронный спам.

SPF позволяет принимающему почтовому серверу проверять во время доставки почты, что письмо, которое, как утверждается, пришло из определенного домена, отправлено с IP-адреса, авторизованного администраторами этого домена.[4] Список авторизованных отправляющих хостов и IP-адресов для домена опубликован в DNS записи для этого домена.

Структура политики отправителя определена в RFC 7208 от апреля 2014 года как «предлагаемый стандарт».[5]

История

Первое публичное упоминание о концепции было в 2000 году, но в основном прошло незамеченным.[6] Эта концепция больше не упоминалась до тех пор, пока в 2002 году не была опубликована первая попытка создания спецификации, подобной SPF. IETF Список рассылки namedroppers, составленный Даной Валери Риз,[7][3][6] кто не знал об упоминании об этой идее в 2000 году. Уже на следующий день, Пол Викси разместил в том же списке свою собственную спецификацию, подобную SPF.[8][6] Эти сообщения вызвали большой интерес и привели к созданию IETF Anti-Spam Research Group (ASRG) и их списка рассылки, в котором идея SPF получила дальнейшее развитие. Среди предложений, представленных в ASRG, было «Обратное MX "(RMX) Хадмутом Данишем и" Протокол назначенной рассылки "(DMP) Гордоном Фециком.[9]

В июне 2003 г. Мэн Вэн Вонг объединили спецификации RMX и DMP[10] и запросил предложения от других. В течение следующих шести месяцев было внесено большое количество изменений, и большое сообщество начало работу над SPF.[11] Первоначально SPF расшифровывался как Отправитель разрешен от и иногда его также называли SMTP + SPF, но его имя было изменено на Структура политики отправителя в феврале 2004 г.

В начале 2004 г. IETF создала МАРИД рабочая группа и попыталась использовать SPF и предложение Microsoft CallerID в качестве основы для того, что теперь известно как Удостоверение личности отправителя; но это рухнуло из-за технических и лицензионных конфликтов.[12]

Сообщество SPF вернулось к исходной «классической» версии SPF. В июле 2005 г. эта версия спецификации была утверждена IESG как IETF эксперимент, предлагая сообществу наблюдать за SPF в течение двух лет после публикации. 28 апреля 2006 г. ФГИ RFC был опубликован как экспериментальный RFC 4408.

В апреле 2014 г. IETF опубликовал SPF в RFC 7208 как «предлагаемый стандарт».

Принцип работы

Дальнейшая информация: Схема перезаписи отправителя (SRS)

В Простой протокол передачи почты позволяет любому компьютеру отправлять сообщения электронной почты с любого исходного адреса. Это эксплуатируется спамеры кто часто использует кованые адрес электронной почты,[13] что затрудняет отслеживание источника сообщения до его источника, а спамерам легче скрыть свою личность, чтобы избежать ответственности. Он также используется в фишинг методы, при которых пользователи могут быть обмануты в раскрытии частной информации в ответ на электронное письмо, якобы отправленное такой организацией, как банк.

SPF позволяет владельцу Интернет-домена указать, какие компьютеры имеют право отправлять почту с адресами в конверте в этом домене, используя система доменных имен (DNS) записи. Получатели, проверяющие информацию SPF в TXT записи может отклонять сообщения от неавторизованных источников до получения тела сообщения. Таким образом, принципы работы аналогичны принципам работы черных списков на основе DNS (DNSBL ), за исключением того, что SPF использует схему делегирования полномочий системы доменных имен. Текущая практика требует использования записей TXT,[14] так же, как и в ранних реализациях. Некоторое время был зарегистрирован новый тип записи (SPF, тип 99), который стал доступен в обычном программном обеспечении DNS. В то время использование записей TXT для SPF было задумано как переходный механизм. Экспериментальный RFC, RFC 4408 в разделе 3.1.1 предлагается, что «доменное имя, совместимое с SPF, ДОЛЖНО иметь записи SPF обоих типов RR».[15] Предлагаемый стандарт, RFC 7208, говорит, что «использование альтернативных типов DNS RR поддерживалось на экспериментальной стадии SPF, но было прекращено».[14]

Адрес отправителя конверта передается в начале диалога SMTP. Если сервер отклоняет домен, неавторизованный клиент должен получить сообщение об отказе, и если этот клиент был ретранслятором агент передачи сообщений (MTA), а возврат сообщения на исходный адрес отправителя конверта. Если сервер принимает домен, а затем также принимает получателей и тело сообщения, он должен вставить поле Return-Path в заголовок сообщения, чтобы сохранить адрес отправителя конверта. Хотя адрес в Return-Path часто совпадает с адресами других отправителей в заголовке почты, такими как заголовок из, это не обязательно так, и SPF не предотвращает подделку этих других адресов, таких как отправитель заголовок.

Спамеры могут отправлять электронную почту с результатом SPF PASS, если у них есть учетная запись в домене с политикой отправителя, или использовать взломанную систему в этом домене. Однако это упрощает отслеживание спамера.

Основное преимущество SPF - это владельцы адресов электронной почты, подделанных в Return-Path. Они получают большое количество нежелательных сообщений об ошибках и других автоответчиков. Если такие получатели используют SPF для указания своих законных IP-адресов источника и указывают результат FAIL для всех остальных адресов, получатели, проверяющие SPF, могут отклонять подделки, тем самым уменьшая или устраняя количество обратное рассеяние.

У SPF есть потенциальные преимущества, помимо помощи в выявлении нежелательной почты. В частности, если отправитель предоставляет информацию SPF, то получатели могут использовать результаты SPF PASS в сочетании со списком разрешений для идентификации известных надежных отправителей. Такие сценарии, как взломанные системы и почтовые программы с общей отправкой, ограничивают это использование.

Причины внедрения

Если домен публикует запись SPF, спамеры и фишеры с меньшей вероятностью будут подделывать электронные письма, выдавая себя из этого домена, потому что поддельные электронные письма с большей вероятностью будут обнаружены фильтрами спама, которые проверяют запись SPF. Следовательно, домен, защищенный SPF, менее привлекателен для спамеров и фишеров. Поскольку домен, защищенный SPF, менее привлекателен в качестве поддельного адреса, он с меньшей вероятностью будет отклонен спам-фильтрами, и, в конечном итоге, легитимная электронная почта от домена с большей вероятностью пройдет.[16]

ОТКАЗ и пересылка

SPF ломается простая пересылка сообщений. Когда домен публикует политику SPF FAIL, легитимные сообщения, отправленные получателям, пересылающим их почту третьим лицам, могут быть отклонены и / или возвращены, если произойдет все следующее:

  1. Экспедитор не перезаписывает Обратный путь, в отличие от списков рассылки.
  2. Следующий переход не позволяет включить пересылку в список.
  3. Этот переход проверяет SPF.

Это необходимая и очевидная особенность SPF - проверок. позади границы" MTA (MX ) приемника не может работать напрямую.

Издатели политик SPF FAIL должны принимать на себя риск того, что их законные электронные письма будут отклонены или возвращены. Им следует проводить тестирование (например, с помощью политики SOFTFAIL), пока они не будут удовлетворены результатами. См. Ниже список альтернатив простой пересылке сообщений.

HELO тесты

Для пустого обратного пути, используемого в Сообщения об ошибках и другие автоответчики, проверка SPF HELO личность является обязательной.

С поддельным идентификатором HELO результат NONE не поможет, но для допустимых имен хостов SPF также защищает идентификатор HELO. Эта функция SPF всегда поддерживалась в качестве опции для приемников, и более поздние проекты SPF, включая окончательную спецификацию, рекомендуют всегда проверять HELO.

Это позволяет получателям разрешать список отправляющих почтовых программ на основе HELO PASS или отклонять все письма после HELO FAIL. Его также можно использовать в системы репутации (любой разрешающий или запрещающий список - это простой случай системы репутации).

Выполнение

Соблюдение SPF состоит из трех слабо связанных задач:

  • Опубликовать политику: Домены и хосты идентифицируют машины, которым разрешено отправлять электронную почту от их имени. Они делают это, добавляя дополнительные записи к существующей информации DNS: каждые доменное имя или хост, у которого есть Запись или же Запись MX должна иметь запись SPF, определяющую политику, если она используется либо в адресе электронной почты, либо в качестве аргумента HELO / EHLO. Хосты, которые не отправляют почту, должны иметь опубликованную запись SPF, указывающую на это ("v = spf1 -all").
  • Проверьте и используйте информацию SPF: Получатели используют обычные DNS-запросы, которые обычно кэшируются для повышения производительности. Затем получатели интерпретируют информацию SPF, как указано, и действуют в соответствии с результатом.
  • Изменить пересылку почты: SPF не разрешает пересылку обычной почты. Альтернативы:
    • Повторная рассылка (т. Е. Замена исходного отправителя отправителем из локального домена)
    • Отказ (т. Е. Ответ 551 Пользователь не локальный; попробуйте )
    • Разрешить на целевом сервере, чтобы он не отказывался от перенаправленного сообщения
    • Схема перезаписи отправителя, более сложный механизм, который обрабатывает уведомления о недоставке исходному отправителю.

Таким образом, ключевой проблемой SPF является спецификация новой информации DNS, которую устанавливают домены и используют получатели. Приведенные ниже записи имеют типичный синтаксис DNS, например:

"v = spf1 ip4: 192.0.2.0/24 ip4: 198.51.100.123 a -all"

«v =» определяет используемую версию SPF. Следующие слова обеспечивают механизмы для использования, чтобы определить, имеет ли домен право отправлять почту. «Ip4» и «a» указывают системы, которым разрешено отправлять сообщения для данного домена. "-All" в конце указывает, что если предыдущий механизмы не соответствует, сообщение следует отклонить.

Механизмы

8 механизмы определены:

ВСЕВсегда совпадает; используется для результата по умолчанию, например -все для всех IP-адресов, не соответствующих предыдущим механизмам.
АЕсли доменное имя имеет адресную запись (A или AAAA), которая может быть преобразована в адрес отправителя, она будет соответствовать.
IP4Если отправитель находится в заданном IPv4 диапазон адресов, совпадение.
IP6Если отправитель находится в заданном IPv6 диапазон адресов, совпадение.
MXЕсли в доменном имени есть Запись MX разрешая адрес отправителя, он будет совпадать (т.е. почта приходит с одного из серверов входящей почты домена).
PTRЕсли доменное имя (PTR запись ), поскольку адрес клиента находится в данном домене, и это доменное имя разрешается в адрес клиента (обратный DNS с прямым подтверждением ), матч. Этот механизм не рекомендуется, и по возможности его следует избегать.[14]
СУЩЕСТВУЮТЕсли данное доменное имя разрешается в какой-либо адрес, совпадение (независимо от адреса, в который оно разрешается). Это редко используется. Наряду с макроязыком SPF он предлагает более сложные сопоставления, например DNSBL -запросы.
ВКЛЮЧАЮТСсылается на политику другого домена. Если политика этого домена проходит, этот механизм проходит. Однако, если включенная политика дает сбой, обработка продолжается. Чтобы полностью делегировать политику другого домена, перенаправить необходимо использовать расширение.

Отборочные

Каждый механизм можно комбинировать с одним из четырех квалификаторы:

  • + для результата PASS. Это можно не указывать; например., + mx такой же как mx.
  • ? для НЕЙТРАЛЬНОГО результата, интерпретируемого как НЕТ (без политики).
  • ~ (тильда) для SOFTFAIL, средства отладки между NEUTRAL и FAIL. Как правило, сообщения, возвращающие SOFTFAIL, принимаются, но помечаются.
  • - (минус) для FAIL письмо должно быть отклонено (см. ниже).

Модификаторы

В модификаторы разрешить будущие расширения структуры. На сегодняшний день только двое модификаторы определено в RFC 4408 получили широкое распространение:

  • exp = some.example.com дает имя домена с DNS Запись TXT (интерпретируемая с использованием макроязыка SPF), чтобы получить объяснение результатов FAIL - обычно URL который добавляется к коду ошибки SMTP. Эта функция используется редко.
  • redirect = some.example.com может использоваться вместо ВСЕ-механизм для ссылки на запись политики другого домена. Этот модификатор легче понять, чем несколько похожий INCLUDE-механизм.

Обработка ошибок

Как только реализации SPF обнаруживают синтаксические ошибки в политике отправителя, они должен прервать оценку с результатом PERMERROR. Пропуск ошибочный механизмы не может работать должным образом, поэтому включить: bad.example и redirect = bad.example также вызывают PERMERROR.

Еще одна гарантия - это максимум десять механизмов, запрашивающих DNS, то есть любой механизм, кроме IP4, IP6 и ALL. Реализации могут прервать оценку с результатом TEMPERROR, если она занимает слишком много времени или истекает время ожидания DNS-запроса, или они могут продолжать делать вид, что запрос не вернул данных - это называется «недействительным поиском». Однако они должен вернуть PERMERROR, если политике прямо или косвенно требуется более десяти запросов для механизмы. Кроме того, они должен вернуть PERMERROR, как только было обнаружено более двух «недействительных поисков». Любой перенаправление = также имеет значение для этого пределы обработки.[17]

Типичная политика SPF HELO v = spf1 a mx ip4: 192.0.2.0 -все может выполнять четыре или более DNS-запроса: (1) запись TXT (тип SPF устарел RFC 7208 ), (2) A или AAAA для механизма а, (3) запись MX и (4+) A или AAAA для каждого имени MX, для механизма mx. За исключением первого, все эти запросы учитываются до 10. Кроме того, если, например, отправитель имеет адрес IPv6, а его имя и два его имени MX имеют только адреса IPv4, тогда оценка первых двух механизмов уже приводит к более чем двум пустым поискам и, следовательно, PERMERROR. Обратите внимание, что механизмы ip4 и все не требуется поиск DNS.

вопросы

Записи DNS SPF

Чтобы обеспечить быстрое тестирование и развертывание, первоначальные версии SPF проверяли его настройку в записи DNS TXT отправляющего домена, хотя традиционно эта запись должна была быть текстом произвольной формы без прикрепленной семантики.[18] Хотя в июле 2005 г. IANA назначил конкретный тип записи ресурса 99 для SPF, использование которого никогда не было высоким, а наличие двух механизмов сбивало пользователей с толку. В 2014 году использование этой записи было прекращено после того, как рабочая группа SPFbis пришла к выводу, что «... значительный переход к типу SPF RR в обозримом будущем был очень маловероятен, и что лучшим решением для решения этой проблемы взаимодействия было прекращение поддержки типа SPF RR».[14]

Ограничения заголовка

Поскольку SPF все больше препятствует спамеры от спуфинга адрес отправителя конверта, многие перешли только к подделке адреса в поле "От" заголовка почты, который фактически отображается для получателя, а не обрабатывается только адресом получателя. агент передачи сообщений (MTA). SPF (или DKIM ) можно использовать вместе с DMARC однако, чтобы также проверить поле От в заголовке сообщения. Это называется «выравниванием идентификатора». Кроме того, проприетарная реализация, выходящая за рамки схемы SPF, позволяет защитить от определенных реализаций подмены заголовков.[19][20][21]

Развертывание

Программное обеспечение для защиты от спама, такое как SpamAssassin версия 3.0.0 и ASSP внедрить SPF. Много агенты по пересылке почты (MTA) напрямую поддерживают SPF, например Курьер, CommuniGate Pro, Дикий кот, MDaemon и Microsoft Exchange или у вас есть исправления или плагины, поддерживающие SPF, в том числе Постфикс, Отправить письмо, Exim, qmail, и Qpsmtpd.[22] По состоянию на 2017 год более восьми миллионов доменов публикуют SPF FAIL -все политики.[23] В опросе, опубликованном в 2007 году, 5% опрошенных .com и .сеть домены имели какую-то политику SPF. В 2009 году, по данным непрерывного опроса Nokia Research, 51% протестированных доменов содержат политику SPF.[24] Эти результаты могут включать тривиальные политики, например v = spf1? все.[25][нуждается в обновлении ]

В апреле 2007 года BITS, подразделение Круглого стола по финансовым услугам, опубликовало рекомендации по безопасности электронной почты для своих членов, включая развертывание SPF.[26] В 2008 году Рабочая группа по борьбе со злоупотреблениями в сфере обмена сообщениями (MAAWG ) опубликовал статью о проверка подлинности электронной почты покрытие SPF, Удостоверение личности отправителя, и Почта, идентифицированная с помощью DomainKeys (ДКИМ).[27] В своих «Передовых методах связи с отправителями» MAAWG заявила: «По крайней мере, отправители должны включать записи SPF для своих почтовых доменов».[28] В 2015 году Рабочая группа по борьбе со злоупотреблениями в сфере обмена сообщениями (MAAWG ) отредактировал статью о проверка подлинности электронной почты покрытие SPF, Почта, идентифицированная с помощью DomainKeys (DKIM) и DMARC (DMARC). В своей пересмотренной «Передовой практике связи с отправителями» MAAWG заявила: «Аутентификация поддерживает прозрачность за счет дальнейшей идентификации отправителя (ей) сообщения, а также способствует сокращению или устранению поддельных и поддельных адресов».[29]

Смотрите также

Рекомендации

  1. ^ عبد الوهاب, وزیر وزیر عبد الوهاب; محمد, مختار محمد محمد; محمد, محمد ابراهیم محمد (2018-04-01). "المدعو snw سنو من إهناسیا المدینة". مجلة الدراسات التاریخیة والحضاریة المصریة. 4 (4): 34–49. Дои:10.21608 / jhse.2018.78336. ISSN  2682-4280.
  2. ^ а б Карранса, Пабло (16 июля 2013 г.). «Как использовать запись SPF для предотвращения спуфинга и повышения надежности электронной почты». DigitalOcean. Архивировано из оригинал 20 апреля 2015 г.. Получено 23 сентября 2019. Тщательно настроенная запись SPF снизит вероятность мошенничества с подделкой вашего доменного имени и предотвратит попадание ваших сообщений в спам до того, как они достигнут ваших получателей. Подмена электронной почты - это создание электронных писем с поддельным адресом отправителя; это просто сделать, потому что многие почтовые серверы не выполняют аутентификацию. Спам и фишинговые электронные письма обычно используют такую ​​подделку, чтобы ввести получателя в заблуждение относительно происхождения сообщения.
  3. ^ а б Дэвид, Грин. "Почтовый передатчик RR". marc.info. Получено 15 мая 2019.
  4. ^ «Структура политики отправителя: Введение». Архивировано из оригинал на 22.02.2019.
  5. ^ RFC7208 Статус
  6. ^ а б c «История НПФ». DMARCian. DMARCian.org. 2019-03-18. Получено 15 мая 2019.
  7. ^ писать как Дэвид Грин
  8. ^ Пол, Викси. "Re: Mail-Transmitter RR". marc.info. Получено 15 мая 2019.
  9. ^ «SPF: История / Pre-SPF». Получено 16 мая 2009.
  10. ^ Для сравнения RMX, DMP и SPF см. Сравнение RMX и DMP В архиве 2008-04-25 на Wayback Machine на историческом сайте openspf.
  11. ^ «НПФ: История / НПФ-2003». Получено 16 мая 2009.
  12. ^ Зельцер, Ларри (22 сентября 2004 г.). «Целевая группа Интернета закрывает рабочую группу по борьбе со спамом». eWeek. Получено 15 мая 2019.
  13. ^ Дэн Шлитт (29 августа 2013 г.). «Последний звонок: (структура политики отправителя (SPF) для авторизации использования доменов в электронной почте, версия 1) в соответствии с предлагаемым стандартом» ». Список обсуждения IETF. IETF. Получено 16 декабря 2013.
  14. ^ а б c d Скотт Киттерман (апрель 2014 г.). «Записи ресурсов DNS». Структура политики отправителя (SPF) для авторизации использования доменов в электронной почте, версия 1. IETF. сек. 3.1. Дои:10.17487 / RFC7208. RFC 7208. Получено 26 апреля 2014.
  15. ^ Вонг М. и У. Шлитт. RFC 4408. Апрель 2006 <http://tools.ietf.org/html/rfc4408 >
  16. ^ «Зачем мне внедрять запись SPF в моем домене?». Электронная почта Руководство. Май 2009. Архивировано с оригинал 29 января 2010 г.. Получено 2010-01-01.
  17. ^ Аткинс, Стив (14 марта 2016 г.). «SPF: Правило десяти». wordtothewise.com. Получено 23 сентября 2019.
  18. ^ Стив Белловин выражает сомнения В архиве 2004-04-13 на Wayback Machine (Янв 2004)
  19. ^ «Создайте политику блокировки входящего трафика MIMECAST, чтобы ОСТАНОВИТЬ ПОДПИСАНИЕ электронной почты». Получено 25 августа 2017.
  20. ^ "Предотвращение поддельных сообщений с помощью обнаружения поддельных отправителей". Получено 25 августа 2017.
  21. ^ «Как работает защита от спуфинга в Office 365». Получено 25 августа 2017.
  22. ^ "Плагин Qpsmtpd SPF". 2013. Архивировано с оригинал на 29.06.2013.
  23. ^ "Исследование всех доменов SPF". 2017. Получено 2017-11-07.
  24. ^ «Исследовательский отчет Nokia по внедрению SPF». Fit.Nokia.com. Nokia. 2011-09-19. Архивировано из оригинал на 2011-09-20. Получено 2016-04-05.
  25. ^ Лю, Крикет (январь 2007 г.). «Создание препятствий для новых расширений и приложений DNS». ONLamp. Получено 2007-10-04.
  26. ^ «Набор средств защиты электронной почты BITS» (PDF). БИТЫ. Апрель 2007 г.. Получено 2008-06-13.
  27. ^ Крокер, Дэйв (март 2008 г.). «Доверие к электронной почте начинается с аутентификации» (PDF). MAAWG. Архивировано из оригинал (PDF) в 2013-01-29. Получено 2011-07-28.
  28. ^ "Краткое изложение передовой практики связи с отправителями MAAWG" (PDF). MAAWG. 2011-10-07. Получено 2012-04-27.
  29. ^ "Передовые методы работы с отправителями M3AAWG" (PDF). MAAWG. 2015-02-01. Получено 2016-09-01.

внешняя ссылка