Войти
Sender ID - это историческое предложение по борьбе с спуфингом от бывшей рабочей группы MARID IETF, которая попытался присоединиться к Sender Policy Framework (SPF) и Caller ID. Идентификатор отправителя определен в основном в экспериментальном RFC 4406, но есть дополнительные части в RFC 4405, RFC 4407 и RFC 4408.
Идентификатор отправителя в значительной степени основан на SPF, с некоторыми дополнениями. Эти различия обсуждаются здесь.
Идентификатор отправителя пытается улучшить SPF: SPF не проверяет адреса заголовка (которых может быть несколько), которые указывают заявленную отправляющую сторону. Один из этих адресов заголовка обычно отображается пользователю и может использоваться для ответа на электронные письма. Эти адреса заголовков могут отличаться от адреса, который SPF пытается проверить; то есть SPF проверяет только адрес «MAIL FROM», который также называется отправителем конверта.
Однако есть много похожих полей заголовка электронной почты, которые все содержат информацию об отправляющей стороне; поэтому Sender ID определяет в RFC 4407 предполагаемый ответственный адрес (PRA), а также набор эвристических правил для определения этого адреса из множества типичных заголовков в электронном письме.
Синтаксически идентификатор отправителя почти идентичен SPF, за исключением того, что v = spf1заменяется одним из:
spf2.0 / mfrom- что означает проверку отправителя конверта. адрес точно такой же, как SPF.spf2.0 / mfrom, praили spf2.0 / pra, mfrom- это означает проверку как отправителя конверта, так и PRA.spf2.0 / pra- означает проверку только PRA.Единственное другое синтаксическое отличие состоит в том, что Sender ID предлагает функцию позиционных модификаторов, не поддерживаемых в SPF. На практике до сих пор позиционный модификатор не был указан ни в одной реализации Sender ID.
На практике схема pra обычно обеспечивает защиту только в том случае, если электронная почта является законной, и не предлагает реальной защиты в случае спама или фишинга. Правило для наиболее легитимной электронной почты будет либо знакомым полем заголовка From:, либо, в случае списков рассылки, полем заголовка Sender :. Однако в случае фишинга или спама права могут быть основаны на полях заголовка Resent- *, которые часто не отображаются для пользователя. Чтобы быть эффективным средством защиты от фишинга, MUA (почтовый пользовательский агент или почтовый клиент) должен быть модифицирован для отображения либо pra для идентификатора отправителя, либо поля заголовка Return-Path: для SPF.
pra пытается противостоять проблеме фишинга, в то время как SPF или mfrom пытается противостоять проблеме отказов спама и других автоответов на поддельные Return-Path. Две разные проблемы с двумя разными предлагаемыми решениями. Однако Sender-ID и SPF дают одинаковый результат примерно в 80% случаев, согласно анализу миллиарда сообщений.
У pra есть тот недостаток, что серверы пересылки и списки рассылки может поддерживать его только путем изменения заголовка письма, например вставьте Senderили Resent-Sender. Последний нарушает RFC 2822 и может быть несовместим с RFC 822.
. При использовании SPF списки рассылки продолжают работать как есть. Серверы пересылки, желающие поддерживать SPF, должны изменять только SMTP MAIL FROM и RCPT TO, но не почту. Это не новая концепция; с исходным RFC 821 серверы пересылки SMTP всегда добавляли свое имя хоста к обратному пути в MAIL FROM.
Самым проблемным моментом в основной спецификации Sender ID является рекомендация интерпретировать политики v = spf1, такие как spf2.0 / mfrom, praвместо spf2.0 / m от. Это никогда не предполагалось во всех опубликованных черновиках SPF с 2003 года, и для неизвестного большого количества политик v = spf1оценка pra могла привести к ложным результатам во многих случаях, когда pra и mfrom отличаются. Эта проблема послужила основанием для обращения в Совет по архитектуре Интернета (IAB). В ответ на еще одну предыдущую апелляцию IESG уже отметил, что идентификатор отправителя не может продвигаться по треку стандартов IETF без устранения несовместимости с ДОЛЖНЫМ в RFC 2822.
различных опросах проведенное в 2012 году, когда SPF перешло от экспериментального к предлагаемому стандарту, показало, что менее 3% почтовых доменов публикуют конкретные запросы на использование pra, по сравнению с примерно 40-50% почтовых доменов, использующих SPF.
Предложение по идентификатору отправителя было предметом разногласий по поводу интеллектуальной собственности лицензирования вопросов: Microsoft владеет патентами на ключевые части идентификатора отправителя и использовались для лицензирования этих патентов на условиях, несовместимых с Стандартной общественной лицензией GNU и считавшихся проблемными для реализаций бесплатного программного обеспечения в общем. 23 октября 2006 г. Microsoft разместила эти патенты в рамках Open Specification Promise, которое совместимо с некоторыми бесплатными лицензиями и лицензиями с открытым исходным кодом, но не с самой последней версией лицензии GPL, версией 3.x.
v = spf1для PRA из проекта SPF (2006 г.).