Практика подписания авторского домена

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

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

Концепции

Адрес автора

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

Домены в адресах 5322- От не обязательно совпадают с более сложным предполагаемым ответственным адресом, охватываемым идентификатором отправителя , указанным в RFC 4407. Домен в адресе 5322- От также не обязательно совпадает с отправителя конверта указанным в адресе . в RFC 5321, также известном как SMTP MAIL FROM, конверт -От , 5321- От или Обратный путь , дополнительно защищенный SPF , указанным в RFC 7208.

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

Подпись домена автора — это действительная подпись DKIM, в которой доменное имя подписывающего объекта DKIM, т. е. тег d в поле заголовка DKIM-Signature , совпадает с именем домена в адресе автора .

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

Практика подписания авторского домена

Практики записи публикуются в DNS- домена автора. По адресу автора [электронная почта защищена] , он может быть установлен как

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

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

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

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

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

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

История

Некоторое время ADSP был известен как ASP (практика подписи авторов). ^{[ 8 ]} или исходный SSP (практика подписи отправителей) до опроса имен протоколов. ^{[ 9 ]}

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

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

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

См. также

Ссылки

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

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

[historic-1] Jump up to: ^а ^б ^с . Барри Лейба (25 ноября 2013 г.). «Изменить статус ADSP (RFC 5617) на Исторический» . IETF . Проверено 26 ноября 2013 г.

[2] Джон Левин (23 февраля 2008 г.). «выбрасываемый» означает «выбрасываемый» . Список обсуждений IETF DKIM . мипассок . Проверено 28 июня 2010 г.

[3] rfc5617#приложение-B.5

[4] Джон Левин (17 января 2008 г.). "1:1 и утверждения о третьих лицах" . Список обсуждений IETF DKIM . мипассок . Проверено 28 июня 2010 г.

[5] Джон Левин (2 июня 2010 г.). «общие выпадающие списки» . Список обсуждений IETF DKIM . мипассок . Проверено 9 июня 2010 г.

[6] Мюррей С. Кучерави (2 июня 2010 г.). «Опасность ADSP заключалась в том, что список против участника» . Список обсуждений IETF DKIM . мипассок. Архивировано из оригинала 9 марта 2016 года . Проверено 9 июня 2010 г.

[7] Барри Лейба (3 октября 2013 г.). «Как защитить подписи DKIM: переход ADSP на исторический вариант с поддержкой 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 v0.02 (очень черновой вариант)» . Список обсуждений IETF DKIM . мипассок . Проверено 24 июня 2010 г.

[ 1 ]

[ 2 ]

[ 3 ]

[ 4 ]

[ 5 ]

[ 6 ]

[ 7 ]

[ 8 ]

[ 9 ]

[ 10 ]

[ 11 ]