Авторские методы подписания доменов - Author Domain Signing Practices

В вычисление, Авторские методы подписания доменов (ADSP) является необязательным расширением DKIM Схема аутентификации электронной почты, при которой домен может публиковать методы подписи, которые он использует при ретрансляции почты от имени связанных авторов.

ADSP был принят как стандартная дорожка RFC 5617 в августе 2009 г., но объявлен «Историческим» в ноябре 2013 г. после того, как «... почти не использовались и не использовались в течение 4 лет с ...»[1]

Концепции

Адрес автора

В адрес автора тот, который указан в Из поле заголовка, определенное в RFC 5322. В необычных случаях, когда в этом поле указано более одного адреса, RFC 5322 предусматривает Отправитель поле, которое будет использоваться вместо него.

Домены в 5322-Из адреса не обязательно такие же, как в более сложных Предполагаемый ответственный адрес покрыт Удостоверение личности отправителя указано в RFC 4407. Домен в 5322-Из адрес также не обязательно совпадает с отправитель конверта адрес, указанный в RFC 5321, также известный как SMTP ПОЧТА ОТ, конверт-Из, 5321-Из, или же Обратный путь, опционально защищенный SPF указано в RFC 7208.

Подпись домена автора

An Подпись домена автора - действительная подпись DKIM, в которой доменное имя объекта подписи DKIM, т. е. d тег в DKIM-подпись поле заголовка совпадает с именем домена в адрес автора.

Эта привязка распознает более высокое значение для подписей домена автора, чем другие действительные подписи, которые могут быть найдены в сообщении. Фактически, это доказывает, что объект, который контролирует зону DNS для автора - а, следовательно, и место назначения ответов автору сообщения - имеет переданный сообщение автора. Скорее всего, автор отправил сообщение через соответствующий агент отправки сообщений. Такая квалификация сообщения может быть проверена независимо от какой-либо практики подписания опубликованного домена.

Авторские методы подписания доменов

В практики публикуются в DNS запись по домену автора. Для адреса автора [email protected], он может быть установлен как

_adsp._domainkey.example.com. в txt "dkim = unknown"

Предусмотрены три возможных метода подписания:

  • неизвестный, что равносильно отсутствию определения какой-либо записи, говорит, что домен может подписывать некоторые, большинство или все сообщения электронной почты,
  • все говорит, что вся почта из домена подписана подписью домена автора,
  • отбрасываемый говорит, что вся почта из домена подписана подписью домена автора; более того, если такая подпись отсутствует или недействительна, владельцы домена хотят, чтобы принимающий сервер отбросил сообщение; то есть молча выбросить.[2]

Предостережение

Спецификация ADSP явно не рекомендует публиковать записи, отличные от «unknown», для доменов, у которых есть независимые пользователи, и политика использования, которая явно не ограничивает их отправку почты только с назначенных почтовых серверов, поскольку почта, отправляемая независимо от организации, не будет подписана.[3]

Какими бы явными ни были формулировки этого предостережения, понять цель и ограничения ADSP непросто. Один из авторов ADSP считает, что лучше публиковать частные списки отбрасываемый домены, поддерживаемые компетентными людьми, вместо того, чтобы позволить каждому домену определять свою политику.[4][5] Признавая, что спецификация поставляла непроверенный прототип, автор популярной реализации ADSP предложил понизить версию ADSP до экспериментальный положение дел.[6] Позже его фактически понизили до исторический.[1] Соображение, что DMARC охватывает более или менее один и тот же вариант использования, оказавший влияние, но не связанный.[7]

История

Некоторое время ADSP был известен как ASP (Author Signing Practices),[8] или исходный SSP (Sender Signing Practices) до опроса именования протоколов.[9]

Доменные ключи, Предшественник DKIM, имел Политика исходящей подписи состоящий из одного символа: «-», если домен подписывает всю электронную почту, и «~» в противном случае.[10] DKIM намеренно избегал соображений политики подписывающих сторон, поэтому DKIM не проверяет поле "От" сообщения. напрямую, но это протокол проверки подлинности, не зависящий от политики. Связь между подписывающим лицом и правом на использование поля «От», видимого конечным пользователям, была перенесена в отдельную спецификацию.[11]


Эрик Оллман, автор Отправить письмо, был редактором спецификации ADSP для IETF DKIM Рабочая группа.

Проект спецификации ADSP начался в июне 2007 г. и прошел 11 изменений и длительное обсуждение, прежде чем был опубликован в виде RFC в августе 2009 г., но был объявлен «Историческим» четыре года спустя, в ноябре 2013 г., после того, как «… почти не было развертывания и использования в 4 лет с ... "[1]

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

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

  1. ^ а б c .Барри Лейба (25 ноября 2013 г.). «Измените статус ADSP (RFC 5617) на Исторический». IETF. Получено 26 ноября 2013.
  2. ^ Джон Левин (23 февраля 2008 г.). "отбрасываемый означает отбрасываемый". Список обсуждения IETF DKIM. мипассок. Получено 28 июн 2010.
  3. ^ rfc5617 # appendix-B.5
  4. ^ Джон Левин (17 января 2008 г.). «1: 1 и утверждения о третьих лицах». Список обсуждения IETF DKIM. мипассок. Получено 28 июн 2010.
  5. ^ Джон Левин (2 июня 2010 г.). "общие выпадающие списки". Список обсуждения IETF DKIM. мипассок. Получено 9 июн 2010.
  6. ^ Мюррей С. Кучерави (2 июня 2010 г.). "опасность ADSP: список vs участник". Список обсуждения IETF DKIM. мипассок. Получено 9 июн 2010.
  7. ^ Барри Лейба (3 октября 2013 г.). «Как защитить подписи DKIM: перемещение ADSP в режим Historic, вместо этого поддержка DMARC». Список обсуждения IETF. IETF. Получено 26 ноября 2013.
  8. ^ Джон Левин (31 января 2008 г.). «Проект ASP, Правила подписания авторов». Список обсуждения IETF DKIM. мипассок. Получено 24 июн 2010.
  9. ^ Стивен Фаррелл (4 апреля 2008 г.). «Опрос по именованию протоколов (закрывающий выпуск 1550)». Список обсуждения IETF DKIM. мипассок. Получено 24 июн 2010.
  10. ^ RFC 4870, Раздел 3.6 Заявление о политике отправляющего домена.
  11. ^ Эрик Оллман (9 августа 2005 г.). «DKIM Threat Assessment v0.02 (очень черновой вариант)». Список обсуждения IETF DKIM. мипассок. Получено 24 июн 2010.

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