Идентификатор отправителя

Идентификатор отправителя является историческим ^[1] предложение по борьбе с спуфингом от бывшей рабочей группы MARID IETF , которая пыталась объединить структуру политики отправителей (SPF) и идентификатор вызывающего абонента. Идентификатор отправителя определен в основном в экспериментальном RFC 4406. ^[2] но в RFC 4405 есть дополнительные части, ^[3] RFC 4407 ^[4] и RFC 4408. ^[5]

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

Идентификатор отправителя во многом основан на SPF с некоторыми дополнениями.

Идентификатор отправителя пытается улучшить SPF: SPF не проверяет адреса заголовков (которых может быть несколько), которые указывают заявленную сторону-отправителя. Один из этих адресов заголовков обычно отображается пользователю и может использоваться для ответа на электронные письма. Эти адреса заголовков могут отличаться от адреса, который пытается проверить SPF; то есть SPF проверяет только адрес «MAIL FROM», также называемый отправителем конверта.

Однако существует множество похожих полей заголовка электронного письма, все из которых содержат информацию об отправившей стороне; поэтому идентификатор отправителя определяется в RFC 4407 ^[4] предполагаемый ответственный адрес (PRA), а также набор эвристических правил для определения этого адреса на основе множества типичных заголовков электронного письма.

Синтаксически идентификатор отправителя почти идентичен SPF, за исключением того, что v=spf1 заменяется одним из:

spf2.0/mfrom – означает проверку адреса отправителя конверта, как и SPF.
spf2.0/mfrom,pra или spf2.0/pra,mfrom – означает проверку как отправителя конверта, так и PRA.
spf2.0/pra – означает проверку только PRA.

Единственное другое синтаксическое отличие заключается в том, что идентификатор отправителя предлагает функцию позиционных модификаторов, не поддерживаемую в SPF. На практике до сих пор позиционный ни в одной реализации Sender ID не был указан модификатор.

На практике схема pra обычно обеспечивает защиту только в том случае, если электронная почта является законной, но не обеспечивает реальной защиты в случае спама или фишинга. Для большинства законных сообщений электронной почты используется либо знакомое поле заголовка From:, либо, в случае списков рассылки, поле заголовка Sender:. Однако в случае фишинга или спама пра может основываться на полях заголовка Resent-*, которые часто не отображаются пользователю. Чтобы стать эффективным инструментом защиты от фишинга, MUA (Mail User Agent или Mail Client) необходимо изменить для отображения либо pra для идентификатора отправителя, либо поля заголовка Return-Path: для SPF.

Pra mfrom пытается противостоять проблеме фишинга , в то время как SPF или пытаются противостоять проблеме возврата спама и других автоматических ответов на поддельные пути возврата. Две разные проблемы с двумя разными предлагаемыми решениями. Однако, согласно анализу миллиарда сообщений, Sender-ID и SPF дают одинаковый результат примерно в 80% случаев. ^[6]

Вопросы стандартизации

Pra имеет тот недостаток , что службы пересылки и списки рассылки могут поддерживать его только путем изменения заголовка письма, например, путем вставки Sender или Resent-Sender. Последнее нарушает RFC 2822. ^[7] и может быть несовместим с RFC 822. ^[8]

Благодаря SPF списки рассылки продолжают работать как есть. Службам пересылки, желающим поддерживать SPF, необходимо изменить только SMTP MAIL FROM и RCPT TO, а не почту. Эта концепция не нова: оригинальный RFC 821 ^[9] Серверы пересылки SMTP всегда добавляли свое имя хоста к обратному пути в MAIL FROM.

Самый проблемный момент ^{[ по мнению кого? ]} в базовой спецификации идентификатора отправителя рекомендуется интерпретировать v=spf1 политика, такая как spf2.0/mfrom,pra вместо spf2.0/mfrom. Это никогда не предполагалось во всех опубликованных проектах SPF с 2003 года, и для неизвестного большого количества v=spf1 политика оценка pra может привести к ложным результатам во многих случаях, когда pra и mfrom различны. Эта проблема легла в основу обращения в Совет по архитектуре Интернета (IAB) . В ответ на другое предыдущее обращение IESG уже отметила, что Sender ID не может продвигаться по пути стандартов IETF , не устранив несовместимость с обязательным требованием в RFC 2822. ^[7]

Различные опросы, проведенные в 2012 году, когда SPF превратился из экспериментального в предлагаемый стандарт, показали, что менее 3% почтовых доменов опубликовали конкретные запросы на использование pra по сравнению с примерно 40–50% почтовых доменов, использующих SPF. ^[6]

Патенты

Предложение Sender ID стало предметом споров по вопросам лицензирования : Microsoft владеет патентами ^[10]^[11] на ключевые части Sender ID и использовались для лицензирования этих патентов на условиях, которые не были совместимы со Стандартной общественной лицензией GNU и которые считались проблематичными для свободного программного обеспечения реализации в целом. 23 октября 2006 года Microsoft поместила эти патенты в рамках обещания открытой спецификации , которое совместимо с некоторыми бесплатными лицензиями и лицензиями с открытым исходным кодом, но не с самой последней версией лицензии GPL, версией 3.x. ^{[ нужна ссылка ]}

См. также

Категория:Аутентификация электронной почты
аутентификации по электронной почте Обзор
ILL (РГ IETF в 2004 г.)
ДКИМ
Доменные ключи

Ссылки

^ Алексей Мельников (7 февраля 2020 г.). «Перемещение RFC 4405, RFC 4406, RFC 4407 (Sender-ID) в исторический» . IETF .
^ Вонг, Мэн Венг; Лион, Джим. Идентификатор отправителя: проверка подлинности электронной почты . РФК 4406 .
^ Кац, Гарри; Оллман, Эрик. Расширение службы SMTP для указания ответственного отправителя сообщения электронной почты . дои : 10.17487/RFC4405 . РФК 4405 .
^ Jump up to: ^а ^б Лион, Джим. Предполагаемый ответственный адрес в сообщениях электронной почты . дои : 10.17487/RFC4407 . РФК 4407 .
^ Шлитт, Уэйн; Вонг, Мэн Венг. Структура политики отправителей (SPF) для авторизации использования доменов в электронной почте, версия 1 . дои : 10.17487/RFC4408 . RFC 4408 .
^ Jump up to: ^а ^б Мюррей Кучерави (2012). Решение проблемы структуры политики отправителей (SPF) и экспериментов с идентификаторами отправителей . IETF . дои : 10.17487/RFC6686 . РФК 6686 .
^ Jump up to: ^а ^б Резник, Питер В. Формат интернет-сообщений . дои : 10.17487/RFC2822 . РФК 2822 .
^ Крокер, Д. СТАНДАРТ ДЛЯ ФОРМАТА ТЕКСТОВЫХ СООБЩЕНИЙ ИНТЕРНЕТА ARPA . дои : 10.17487/RFC0822 . РФК 822 .
^ Постел, Дж. Простой протокол передачи почты . дои : 10.17487/RFC0821 . РФК 821 .
^ «FW: Обновленное заявление Microsoft о правах интеллектуальной собственности, заявленных в <draft-ietf-marid-core-03.txt> и <draft-ietf-marid-pra-00.txt> в комбинации» . Список IETF MARID (список рассылки). Архивировано из оригинала 14 апреля 2012 г. Проверено 20 декабря 2011 г.
^ «Обсуждаются раскрытые патенты на идентификатор отправителя» . 20 сентября 2004 г.

Внешние ссылки

Позиция ASF относительно заявления об идентификаторе отправителя от Apache Software Foundation
Апелляция IAB по поводу повторного использования идентификатора отправителя v=spf1 для АФР проекта SPF (2006).
может развернуть оператор идентификатора отправителя проекта Debian Проект Debian не
проблем SPF/Sender-ID IETF принимает решение по освещению и обсуждению на slashdot
Идентификатор отправителя мертв? - Отсутствие освещения консенсуса Рабочей группы MARID и обсуждения гроклау.
Сопредседатели MARID уточняют заявление о консенсусе
МАРИД закрывает ветку списка рассылки.
Идентификатор отправителя: история об открытых стандартах и корпоративной жадности?
«SPF: SPF против идентификатора отправителя»
«Типы идентификаторов отправителей в разных странах»
«Идентификатор отправителя»
Идентификаторы отправителей, шаблоны SMS

[1] Алексей Мельников (7 февраля 2020 г.). «Перемещение RFC 4405, RFC 4406, RFC 4407 (Sender-ID) в исторический» . IETF .

[2] Вонг, Мэн Венг; Лион, Джим. Идентификатор отправителя: проверка подлинности электронной почты . РФК 4406 .

[3] Кац, Гарри; Оллман, Эрик. Расширение службы SMTP для указания ответственного отправителя сообщения электронной почты . дои : 10.17487/RFC4405 . РФК 4405 .

[:0-4] Jump up to: ^а ^б Лион, Джим. Предполагаемый ответственный адрес в сообщениях электронной почты . дои : 10.17487/RFC4407 . РФК 4407 .

[5] Шлитт, Уэйн; Вонг, Мэн Венг. Структура политики отправителей (SPF) для авторизации использования доменов в электронной почте, версия 1 . дои : 10.17487/RFC4408 . RFC 4408 .

[rfc6686-6] Jump up to: ^а ^б Мюррей Кучерави (2012). Решение проблемы структуры политики отправителей (SPF) и экспериментов с идентификаторами отправителей . IETF . дои : 10.17487/RFC6686 . РФК 6686 .

[rfc2822-7] Jump up to: ^а ^б Резник, Питер В. Формат интернет-сообщений . дои : 10.17487/RFC2822 . РФК 2822 .

[8] Крокер, Д. СТАНДАРТ ДЛЯ ФОРМАТА ТЕКСТОВЫХ СООБЩЕНИЙ ИНТЕРНЕТА ARPA . дои : 10.17487/RFC0822 . РФК 822 .

[9] Постел, Дж. Простой протокол передачи почты . дои : 10.17487/RFC0821 . РФК 821 .

[10] «FW: Обновленное заявление Microsoft о правах интеллектуальной собственности, заявленных в <draft-ietf-marid-core-03.txt> и <draft-ietf-marid-pra-00.txt> в комбинации» . Список IETF MARID (список рассылки). Архивировано из оригинала 14 апреля 2012 г. Проверено 20 декабря 2011 г.

[11] «Обсуждаются раскрытые патенты на идентификатор отправителя» . 20 сентября 2004 г.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]