✖


Jump to content

Идентифицированная почта DomainKeys

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

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

DKIM позволяет получателю проверить, что электронное письмо, якобы отправленное из определенного домена , действительно было авторизовано владельцем этого домена. [1] Это достигается путем прикрепления цифровой подписи , связанной с доменным именем, к каждому исходящему сообщению электронной почты. Система-получатель может проверить это, просматривая открытый ключ отправителя , опубликованный в DNS . Действительная подпись также гарантирует, что некоторые части электронного письма (возможно, включая вложения ) не были изменены с момента проставления подписи. [2] Обычно подписи DKIM не видны конечным пользователям и проставляются или проверяются инфраструктурой, а не авторами и получателями сообщения.

DKIM — это Интернет-стандарт . [3] Он определен в RFC 6376 от сентября 2011 года с обновлениями в RFC 8301 и RFC 8463.

Обзор

[ редактировать ]

Потребность в подтверждении идентификации по электронной почте возникает потому, что в противном случае легко создаются поддельные адреса и контент, и они широко используются в спаме , фишинге и другом мошенничестве с использованием электронной почты. [4] Например, мошенник может отправить сообщение, утверждая, что оно пришло от [email protected] с целью убедить получателя принять и прочитать электронное письмо — и получателям сложно определить, можно ли доверять этому сообщению. Системным администраторам также приходится иметь дело с жалобами на вредоносную электронную почту, которая, по-видимому, исходит из их систем, но это не так. [5]

DKIM предоставляет возможность подписать сообщение и позволяет подписавшему ( организации- автору ) сообщить, какой адрес электронной почты он считает законным. Он не предотвращает напрямую и не раскрывает оскорбительное поведение.

DKIM также предоставляет процесс проверки подписанного сообщения. Проверяющие модули обычно действуют от имени организации- получателя , возможно, на каждом переходе .

Все это не зависит от аспектов маршрутизации SMTP , поскольку оно работает с сообщением RFC 5322 — заголовком и телом транспортируемого письма, а не с «конвертом SMTP», определенным в RFC 5321. Следовательно, подписи DKIM сохраняются в базовом режиме. ретрансляция между несколькими агентами передачи сообщений .

Технические детали

[ редактировать ]

Подписание

[ редактировать ]

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

Модули подписи вставляют один или несколько DKIM-Signature: поля заголовка, возможно, от имени организации- автора или исходного поставщика услуг. Спецификация позволяет подписывающим сторонам выбирать, какие поля заголовка они подписывают, но From: поле всегда должно быть подписано. [6] [7] Результирующее поле заголовка состоит из списка tag=value части, как в примере ниже: 

DKIM-Signature: v=1; a=rsa-sha256; d=example.net; s=brisbane;
     c=relaxed/simple; q=dns/txt; [email protected];
     t=1117574938; x=1118006938; l=200;
     h=from:to:subject:date:keywords:keywords;
     z=From:[email protected]|To:[email protected]|
       Subject:demo=20run|Date:July=205,=202005=203:44:08=20PM=20-0700;
     bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=;
     b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ
              VoG4ZHRNiYzR

где используются теги:

  • v (обязательно), версия
  • ( обязательно), алгоритм подписи
  • d (обязательно), Идентификатор домена подписи (SDID)
  • s (обязательно), селектор
  • c (необязательно), алгоритм(ы) канонизации для заголовка и тела
  • q (необязательно), метод запроса по умолчанию
  • i (необязательно), идентификатор агента или пользователя (AUID)
  • t (рекомендуется), временная метка подписи
  • x (рекомендуется), срок действия
  • l (опционально), длина корпуса
  • h (обязательно), поля заголовка — список подписанных
  • z (необязательно), поля заголовка — копия выбранных полей и значений заголовка.
  • bh (обязательно), хеш тела
  • б (обязательно), подпись заголовков и тела

Наиболее подходящими из них являются b для фактической цифровой подписи содержимого (заголовков и тела) почтового сообщения, bh для хеша тела (необязательно ограниченного первыми октетами тела), d для подписывающего домена и s. для селектора.

При желании можно включить идентификатор агента или пользователя (AUID). Формат представляет собой адрес электронной почты с необязательной локальной частью. Домен должен быть равен подписывающему домену или быть его субдоменом. Семантика AUID намеренно оставлена ​​неопределенной и может использоваться подписывающим доменом для установления более детальной сферы ответственности.

И заголовок, и тело вносят вклад в подпись. Сначала тело сообщения хешируется, всегда с начала, возможно, усекаясь до заданной длины l (которая может быть равна нулю). Во-вторых, выбранные поля заголовка хешируются в порядке, заданном h . Повторяющиеся имена полей сопоставляются снизу вверх, в том порядке, в котором Received: поля вставляются в заголовок. Несуществующее поле соответствует пустой строке, поэтому добавление поля с таким именем нарушит подпись. DKIM-Signature: Поле создаваемой подписи, где bh равно вычисленному хешу тела, а b равно пустой строке, неявно добавляется ко второму хешу, хотя его имя не должно появляться в h — если оно встречается, оно ссылается на другой, ранее существовавший подпись. Для обоих хэшей текст канонизируется в соответствии с соответствующими C. алгоритмами Результатом после шифрования с помощью закрытого ключа подписывающего лица и кодирования с использованием Base64 является b .

В дополнение к списку полей заголовков, перечисленных в h , список полей заголовков (включая имя и значение поля), присутствующих на момент подписания, может быть предоставлен в z . Этот список не обязательно должен совпадать со списком заголовков в h .

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

Проверка

[ редактировать ]

Получающий SMTP- сервер, желающий проверить, использует имя домена и селектор для выполнения поиска DNS. [8] Например, учитывая приведенный выше пример подписи: тег d указывает домен автора , который необходимо проверить, example.net ; тег s - селектор, Брисбен . Строка _domainkey является фиксированной частью спецификации. Это дает запись ресурса TXT , которую нужно искать как:

brisbane._domainkey.example.net

Обратите внимание, что в интернационализированной электронной почте селектор и имя домена могут быть в формате UTF-8. [9] В этом случае перед поиском метка должна быть закодирована в соответствии с IDNA . Данные, возвращаемые в результате запроса этой записи, также представляют собой список пар тег-значение. домена Он включает в себя открытый ключ , а также другие токены и флаги использования ключа (например, из командной строки: nslookup -q=TXT brisbane._domainkey.example.net), как в этом примере: 

"k=rsa; t=s; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDDmzRmJRQxLEuyYiyMg4suA2Sy
MwR5MGHpP9diNT1hRiwUd/mZp1ro7kIDTKS8ttkI6z6eTRW9e9dDOxzSxNuXmume60Cjbu08gOyhPG3
GfWdg7QkdN6kR4V75MFlw624VY35DaXBvnlTJTgRg/EW72O1DiYVThkyCgpSYS8nmEQIDAQAB"

Запись CNAME также можно использовать для указания другой записи TXT, например, когда одна организация отправляет электронную почту от имени другой.

Получатель может использовать открытый ключ (значение тега p ), чтобы затем проверить подпись по значению хеш-функции в поле заголовка и сравнить ее со значением хеш-функции для полученного почтового сообщения (заголовки и тело). Если два значения совпадают, это криптографически доказывает, что письмо было подписано указанным доменом и не было подделано при передаче.

Сбой проверки подписи не приводит к отклонению сообщения. Вместо этого точные причины, по которым подлинность сообщения не может быть доказана, должны быть доступны для последующих и вышестоящих процессов. Способы сделать это могут включать отправку обратно сообщения FBL или добавление поля заголовка Authentication-Results к сообщению, как описано в RFC 7001.

Патент

[ редактировать ]

На DomainKeys распространяется патент США № 6 986 049 , срок действия которого истек. Yahoo! лицензировала свои патентные претензии по схеме двойной лицензии: Патентно-лицензионное соглашение DomainKeys v1.2 , [10] или GNU General Public License v2.0 (и никакая другая версия) . [11] [12]

Связь с SPF и DMARC

[ редактировать ]

По сути, и DKIM, и SPF обеспечивают разные показатели подлинности электронной почты. DMARC предоставляет организации возможность публиковать политику, определяющую, какой механизм (DKIM, SPF или оба) используется при отправке электронной почты из этого домена; как проверить поле «От:», представленное конечным пользователям; как получатель должен реагировать на сбои, а также механизм отчетности о действиях, выполненных в соответствии с этими политиками. [13]

Преимущества

[ редактировать ]

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

Для отправителей почты существуют некоторые стимулы подписывать исходящую электронную почту:

  • Это позволяет значительно сократить объем работы по борьбе со злоупотреблениями для доменов с поддержкой DKIM, если получатели электронной почты используют систему DKIM для выявления поддельных сообщений электронной почты, утверждающих, что они пришли из этого домена.
  • Владелец домена может затем сосредоточить усилия своей группы по борьбе с нарушениями на собственных пользователях, которые на самом деле используют этот домен ненадлежащим образом.

Использование с фильтрацией спама

[ редактировать ]

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

Антифишинг

[ редактировать ]

DKIM может быть полезен в качестве технологии защиты от фишинга . Почтовые программы в доменах, активно подвергаемых фишингу, могут подписывать свою почту, чтобы показать, что она подлинный. Получатели могут воспринимать отсутствие действительной подписи в почте из этих доменов как признак того, что письмо, вероятно, поддельное. Лучший способ определить набор доменов, заслуживающих такого уровня внимания, остается открытым вопросом. Раньше в DKIM была дополнительная функция ADSP , которая позволяла авторам, подписывающим всю свою почту, идентифицировать себя, но в ноябре 2013 года ей был присвоен исторический статус. [15] Вместо этого DMARC. для той же цели можно использовать [16] и позволяет доменам самостоятельно публиковать, какие методы (включая SPF и DKIM) они используют, что облегчает получателю принятие обоснованного решения, является ли определенное письмо спамом или нет. [17] Например, используя DMARC, eBay и PayPal публикуют политику, согласно которой вся их почта аутентифицируется, и требуют, чтобы любая принимающая система, такая как Gmail , отклоняла все, что не проверено. [18]

Совместимость

[ редактировать ]

Поскольку DKIM реализован с использованием записей DNS и добавленного поля заголовка RFC 5322, он совместим с существующей инфраструктурой электронной почты. В частности, он прозрачен для существующих систем электронной почты, в которых отсутствует поддержка DKIM. [19]

Этот подход к проектированию также совместим с другими сопутствующими службами, такими как S/MIME и OpenPGP стандарты защиты контента . DKIM совместим со стандартом DNSSEC и SPF .

Накладные расходы на вычисления

[ редактировать ]

DKIM требует создания криптографических контрольных сумм для каждого сообщения, отправляемого через почтовый сервер, что приводит к дополнительным вычислительным затратам, которые в противном случае не требуются для доставки электронной почты. Эти дополнительные вычислительные затраты являются отличительной чертой цифровых почтовых штемпелей, что делает рассылку массового спама более дорогостоящей (в вычислительном отношении). [20] Этот аспект DKIM может выглядеть похожим на hashcash , за исключением того, что проверка на стороне получателя требует незначительного объема работы, в то время как типичный алгоритм hashcash потребует гораздо больше работы. [ нужна ссылка ]

Неотказуемость

[ редактировать ]

DKIM Функция неотказуемости не позволяет отправителям (например, спамерам) достоверно отрицать отправку электронного письма. Это оказалось полезным для таких источников средств массовой информации, как WikiLeaks , которые смогли использовать подписи тела DKIM, чтобы доказать, что просочившиеся электронные письма были подлинными и не были подделаны. [21]

Многие считают неотказуемость нежелательной функцией DKIM, вызванной поведением, подобным только что описанному. Действительно, протокол DKIM предусматривает срок действия. На каждой подписи имеется необязательный тег x=, который устанавливает формальный срок действия; однако проверяющие могут игнорировать это. Кроме того, владельцы доменов могут отозвать открытый ключ, удалив его криптографические данные из записи, тем самым предотвращая проверку подписи, если кто-то заранее не сохранил данные открытого ключа. Ротацию ключей DKIM часто рекомендуют просто для того, чтобы минимизировать влияние скомпрометированных ключей. Однако, чтобы окончательно отключить неотказуемость, можно опубликовать секретные ключи с истекшим сроком действия, что позволит каждому создавать поддельные подписи, тем самым аннулируя значимость оригинальных подписей. [22] [23] [24]

Слабые стороны

[ редактировать ]

Сам RFC определяет ряд потенциальных векторов атак. [25]

Подписи DKIM не включают конверт сообщения, в котором содержится обратный путь и получатели сообщения. Поскольку DKIM не пытается защитить от неправильной адресации, это не влияет на его полезность.

Ряд опасений был высказан и опровергнут в 2013 году во время стандартизации. [26]

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

Для сравнения различных методов решения этой проблемы см. аутентификацию по электронной почте .

Произвольная переадресация

[ редактировать ]

Как упоминалось выше, аутентификация — это не то же самое, что предотвращение злоупотреблений. Злонамеренный пользователь электронной почты авторитетного домена может составить плохое сообщение, подписать его DKIM и отправить из этого домена в любой почтовый ящик, откуда он сможет получить его в виде файла, чтобы получить подписанную копию сообщения. Использование тега l в подписях еще больше упрощает редактирование таких сообщений. переслать миллиону получателей, например, через ботнет Подписанную копию можно затем бесконтрольно . Поставщик электронной почты, подписавший сообщение, может заблокировать пользователя-нарушителя, но не может остановить распространение уже подписанных сообщений. Срок действия подписей в таких сообщениях можно ограничить, всегда включая в подписи метку срока действия или путем периодического отзыва открытого ключа или после уведомления об инциденте. Эффективность сценария вряд ли можно ограничить фильтрацией исходящей почты, поскольку это подразумевает возможность определить, может ли сообщение потенциально быть полезным для спамеров. [27]

Модификация контента

[ редактировать ]

В настоящее время DKIM поддерживает два канонизации : алгоритма простой и Relaxed , ни то, ни другое не поддерживает MIME . [28] Почтовые серверы могут законно конвертировать в другой набор символов и часто документируют это с помощью X-MIME-Autoconverted полей заголовка . Кроме того, серверам в определенных обстоятельствах приходится переписывать структуру MIME, тем самым изменяя преамбулу , эпилог и границы сущностей, любая из которых нарушает подписи DKIM. Только текстовые сообщения, написанные в us-ascii , при условии, что поля заголовка MIME не подписаны. [29] наслаждайтесь надежностью, необходимой для обеспечения сквозной целостности.

Проект OpenDKIM организовал сбор данных с участием 21 почтового сервера и миллионов сообщений. 92,3% наблюдаемых подписей были успешно проверены, и этот показатель немного снижается (90,5%), если учитывать только трафик списков рассылки. [30]

Аннотации по спискам рассылки

[ редактировать ]

Проблемы могут усугубляться, если программное обеспечение для фильтрации или ретрансляции вносит изменения в сообщение. Без особых мер предосторожности, принятых отправителем, добавление нижнего колонтитула, используемое большинством списков рассылки и многими центральными антивирусными решениями, нарушит подпись DKIM. Возможным решением проблемы является подписание только назначенного количества байтов тела сообщения. На это указывает тег l в заголовке DKIM-Signature . Все, что добавлено сверх указанной длины тела сообщения, не учитывается при расчете подписи DKIM. Это не будет работать для сообщений MIME. [31]

Другой обходной путь — внести в белый список известных серверов пересылки; например, с помощью SPF . В качестве еще одного обходного пути было предложено, чтобы службы пересылки проверяли подпись, изменяли электронное письмо, а затем повторно подписывали сообщение с заголовком Sender:. [32] Однако это решение имеет свой риск, связанный с перенаправлением подписанных сообщений третьей стороны, полученных на приемниках SMTP, поддерживающих протокол RFC 5617 ADSP . Таким образом, на практике принимающему серверу все равно приходится вносить в белый список известные потоки сообщений .

Authenticated Received Chain (ARC) — это система аутентификации электронной почты , предназначенная для того, чтобы позволить промежуточному почтовому серверу, такому как список рассылки или служба пересылки, подписывать исходные результаты аутентификации электронного письма. Это позволяет принимающей службе проверять электронное письмо, когда записи SPF и DKIM электронного письма становятся недействительными в результате обработки промежуточного сервера. [33] ARC определен в RFC 8617, опубликованном в июле 2019 года, как «экспериментальный». [34]

Уязвимость короткого ключа

[ редактировать ]

В октябре 2012 года журнал Wired сообщил, что математик Зак Харрис обнаружил и продемонстрировал уязвимость подмены источника электронной почты с помощью коротких ключей DKIM для google.com корпоративный домен, а также несколько других громких доменов. Он заявил, что аутентификация с помощью 384-битных ключей может занять всего 24 часа «на моем ноутбуке», а 512-битных ключей — примерно 72 часа с использованием ресурсов облачных вычислений. Харрис обнаружил, что многие организации подписывают электронные письма такими короткими ключами; он учел их все и уведомил организации об уязвимости. Он утверждает, что 768-битные ключи могут быть учтены с доступом к очень большим объемам вычислительной мощности, поэтому он предлагает, чтобы для подписи DKIM использовались ключи длиной более 1024.

Wired заявил, что Харрис сообщил, а Google подтвердил, что они начали использовать новые более длинные ключи вскоре после его раскрытия. Согласно RFC 6376, принимающая сторона должна иметь возможность проверять подписи с ключами длиной от 512 до 2048 бит, поэтому использование ключей короче 512 бит может быть несовместимым, и его следует избегать. В RFC 6376 также говорится, что подписывающие лица должны использовать ключи длиной не менее 1024 бит для долгоживущих ключей, хотя долговечность там не указана. [35]

История

[ редактировать ]

DKIM возник в 2004 году в результате слияния двух аналогичных усилий: «расширенного DomainKeys» от Yahoo и «Identified Internet Mail» от Cisco . [36] [37] Эта объединенная спецификация легла в основу серии IETF спецификаций и вспомогательных документов , которые в конечном итоге привели к созданию STD 76 , в настоящее время RFC 6376. [38] «Идентифицированная почта Интернета» была предложена Cisco в качестве стандарта аутентификации почты на основе подписи. [39] [40] в то время как DomainKeys был разработан Yahoo [41] [42] для проверки DNS-домена отправителя электронной почты и целостности сообщения .

Аспекты DomainKeys вместе с частями Identified Internet Mail были объединены для создания Identified Mail DomainKeys (DKIM). [41] [43] [44] В число ведущих поставщиков услуг, внедряющих DKIM, входят Yahoo , Gmail , AOL и FastMail . Любая почта от этих организаций должна иметь подпись DKIM. [41] [45] [46] [47]

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

В 2017 году была создана еще одна рабочая группа, DKIM Crypto Update (dcrup), с особым ограничением по проверке методов подписи. [49] RFC 8301 был выпущен в январе 2018 года. Он запрещает SHA-1 и обновляет размеры ключей (с 512-2048 до 1024-4096). [50] RFC 8463 был выпущен в сентябре 2018 года. Он добавляет алгоритм эллиптической кривой к существующему RSA . Добавленный тип ключа, k=ed25519 достаточно надежен, но имеет короткие открытые ключи, которые легче публиковать в DNS. [51]

Разработка

[ редактировать ]

Оригинальная версия DomainKeys была разработана Марком Делани из Yahoo! и улучшен благодаря комментариям многих других с 2004 года. Он указан в историческом RFC 4870, заменен стандартным треком RFC 4871, Подписи почты, идентифицированные доменными ключами (DKIM); оба опубликованы в мае 2007 года. После этого был собран ряд разъяснений и концептуализаций, которые указаны в RFC 5672, август 2009 года, в виде исправлений к существующей спецификации. В сентябре 2011 года RFC 6376 объединил и обновил два последних документа, сохранив при этом суть протокола DKIM. Также возможна совместимость открытого ключа с более ранними версиями DomainKeys.

Первоначально DKIM был разработан неформальным отраслевым консорциумом, а затем был представлен на доработку и стандартизацию рабочей группе IETF DKIM под председательством Барри Лейбы и Стивена Фаррелла. Эрик Оллман из sendmail , Джон Каллас из PGP Corporation , Марк Делани и Майлз Либби из Yahoo! и Джим Фентон и Майкл Томас из Cisco Systems, указанные в качестве основных авторов.

Разработку исходного кода одной общей библиотеки возглавляет проект OpenDKIM с учетом последних дополнений протокола и лицензирования по новой лицензии BSD . [52]

Правоприменение

[ редактировать ]

Поставщики услуг электронной почты все чаще требуют от отправителей реализации аутентификации электронной почты для успешной доставки почты в почтовые ящики своих пользователей.

В феврале 2024 года Google начал требовать от массовых отправителей аутентификации своих электронных писем с помощью DKIM для успешной доставки электронных писем в почтовые ящики, размещенные в Google. [53] [54]

Аналогичным образом в феврале 2024 года Yahoo начала требовать от массовых отправителей внедрения SPF и DKIM для успешной доставки электронных писем пользователям Yahoo. [55]

См. также

[ редактировать ]

Ссылки

[ редактировать ]
  1. ^ Тони Хансен; Дэйв Крокер; Филип Халлам-Бейкер (июль 2009 г.). Обзор службы идентификации почты DomainKeys (DKIM) . IETF . дои : 10.17487/RFC5585 . РФК 5585 . Проверено 6 января 2016 г. Получатели, успешно проверившие подпись, могут использовать информацию о подписавшей стороне в рамках программы по ограничению спама, подделки, фишинга или других нежелательных действий. DKIM сам по себе не предписывает получателю каких-либо конкретных действий; скорее, это технология, открывающая возможности для услуг, которые это делают.
  2. ^ Перейти обратно: а б Дэйв Крокер; Тони Хансен; Мюррей С. Кучерави , ред. (сентябрь 2011 г.). «Целостность данных» . Подписи идентифицируемой почты DomainKeys (DKIM) . IETF . сек. 1,5. дои : 10.17487/RFC6376 . РФК 6376 . Проверено 6 января 2016 г. Проверка подписи подтверждает, что хешированное содержимое не изменилось с момента его подписания, и ничего больше не утверждает о «защите» сквозной целостности сообщения.
  3. ^ Крокер, Д.; Хансен, Т.; Кучерави, М. (сентябрь 2011 г.). «Подписи электронной почты, идентифицированные DomainKeys (DKIM)» . Редактор RFC . ISSN   2070-1721 . Проверено 30 марта 2020 г.
  4. ^ «ДКИМ: Что это такое и почему это важно?» . postmarkapp.com . Проверено 19 февраля 2022 г.
  5. ^ Джейсон П. Штадтландер (16 января 2015 г.). «Подмена электронной почты: объяснение (и как защитить себя)» . ХаффПост . Проверено 11 января 2016 г.
  6. ^ Дэйв Крокер; Тони Хансен; Мюррей С. Кучерави, ред. (июль 2009 г.). «Определить поля заголовка для подписи» . Подписи идентифицируемой почты DomainKeys (DKIM) . IETF . сек. 5.4. дои : 10.17487/RFC6376 . РФК 6376 . Проверено 6 января 2016 г. Поле заголовка From ДОЛЖНО быть подписано (то есть включено в тег «h=" результирующего поля заголовка DKIM-Signature).
  7. ^ Модули подписи используют частную половину пары ключей для подписи и публикуют общедоступную половину в записи DNS TXT, как описано в разделе «Проверка» ниже.
  8. ^ Обратите внимание, что в управлении ключами DKIM не задействованы ни центры сертификации , ни списки отзыва, а селектор — это простой метод, позволяющий подписывающим сторонам добавлять и удалять ключи в любое время — долговременные подписи для целей архивирования выходят за рамки DKIM.
  9. ^ Джон Левин (июнь 2019 г.). «DKIM и интернационализированная почта» . Аутентификация электронной почты для интернационализированной почты . IETF . сек. 5. дои : 10.17487/RFC8616 . РФК 8616 .
  10. ^ «Патентное лицензионное соглашение Yahoo! DomainKeys v1.1» . СоурсФордж . 2006 год . Проверено 30 мая 2010 г. Yahoo! Патентно-лицензионное соглашение DomainKeys v1.2
  11. ^ Левин, Джон Р. (25 января 2010 г.). «Раскрытие прав интеллектуальной собственности, сбор вопросов по повторному фрахтованию» . Список рассылки ietf-dkim . Ассоциация взаимной интернет-практики. Архивировано из оригинала 14 сентября 2016 года . Проверено 30 мая 2010 г. Мне кажется, что ссылка на GPL распространяется только на старую библиотеку Sourceforge DK, которую, я думаю, никто больше не использует. Патент, что немаловажно, защищен отдельной лицензией, выписанной Yahoo.
  12. ^ Чен, Энди (26 сентября 2011 г.). «Заявление Yahoo! Inc. о правах интеллектуальной собственности, связанных с RFC 6376» . Раскрытие прав интеллектуальной собственности . IETF . Проверено 3 октября 2011 г.
  13. ^ «История» . dmarc.org .
  14. ^ Перейти обратно: а б Фальк, JD (17 марта 2009 г.). «В поисках истины в DKIM» . ID круга.
  15. ^ Барри Лейба (25 ноября 2013 г.). «Изменить статус ADSP (RFC 5617) на Исторический» . IETF . Проверено 13 марта 2015 г.
  16. ^ «Часто задаваемые вопросы — DMARC Wiki» . В разделе 6.7 стандарта DMARC указано, что в случае обнаружения политики DMARC получатель должен игнорировать политики, объявленные с помощью других средств, таких как SPF или ADSP.
  17. ^ «Добавление записи DMARC – Справка администратора Google Apps» .
  18. ^ «О DMARC – Справка администратора Google Apps» . Ваша политика может быть строгой или смягченной. Например, eBay и PayPal публикуют политику, требующую аутентификации всей их почты, чтобы она могла появиться в чьем-либо почтовом ящике. В соответствии со своей политикой Google отклоняет все сообщения от eBay или PayPal, не прошедшие проверку подлинности.
  19. ^ Тони Хансен; Дэйв Крокер; Филип Халлам-Бейкер (июль 2009 г.). Обзор службы идентификации почты DomainKeys (DKIM) . IETF . дои : 10.17487/RFC5585 . РФК 5585 . Проверено 1 июля 2013 г.
  20. ↑ Ройс, Алессио (5 июля 2007 г.). «Почтовый штемпель: помощь в борьбе со спамом». Архивировано 17 июля 2011 года в Wayback Machine . Блог Microsoft Office Outlook.
  21. ^ «Проверка DKIM» . www.wikileaks.org . 4 ноября 2016 г. Проверено 7 ноября 2016 г.
  22. ^ Мэтью Д. Грин (16 ноября 2020 г.). «Окей, Google: опубликуйте свои секретные ключи DKIM» . cryptographyengineering.com . Google.
  23. ^ Ян Джексон (2022). «dkim-rotate — Принципы работы» . manpages.ubuntu.com . Убунту.
  24. ^ «Ключи подписи DKIM» . iecc.com . 10 апреля 2023 г. Проверено 27 апреля 2023 г.
  25. ^ Д. Крокер; Т. Хансен; М. Кучерави . «Соображения безопасности» . Подписи идентифицируемой почты DomainKeys (DKIM) . IETF . сек. 8. дои : 10.17487/RFC6376 . РФК 6376 .
  26. ^ «Отчет IESG относительно «Апелляции на решение о продвижении RFC6376» » . IETF.org . IETF . Проверено 26 декабря 2018 г.
  27. ^ Джим Фентон (сентябрь 2006 г.). «Воспроизведение выбранного сообщения» . Анализ угроз, мотивирующих почту с идентификатором DomainKeys (DKIM) . IETF . сек. 4.1.4. дои : 10.17487/RFC4686 . РФК 4686 . Проверено 10 января 2016 г.
  28. ^ Нед Фрид (с согласия Джона Кленсина ) (5 марта 2010 г.). "вторая проверка проекта-ietf-yam-rfc1652bis-03" . Список рассылки YAM . IETF . Проверено 30 мая 2010 г. Рабочая группа DKIM предпочла простоту канонической формы канонической форме, устойчивой к изменениям кодировки. Это был их инженерный выбор, и они его сделали.
  29. ^ RFC 2045 позволяет значению параметра быть либо токеном, либо строкой в ​​кавычках, например в {{{1}}} кавычки можно удалить по закону, что нарушает подписи DKIM.
  30. ^ Кучерави, Мюррей (28 марта 2011 г.). «Отчет о реализации RFC4871» . IETF . Проверено 18 февраля 2012 г.
  31. ^ Мюррей С. Кучерави (сентябрь 2011 г.). Идентифицированная почта DomainKeys (DKIM) и списки рассылки . IETF . дои : 10.17487/RFC6377 . RFC 6377 . Проверено 10 января 2016 г.
  32. ^ Эрик Оллман; Марк Делани; Джим Фентон (август 2006 г.). «Действия менеджера списков рассылки» . Практика подписания отправителей DKIM . IETF . сек. 5.1. Идентификатор черновика-allman-dkim-ssp-02 . Проверено 10 января 2016 г.
  33. ^ «Обзор цепочки полученных с проверкой подлинности» (PDF) . Проверено 15 июня 2017 г.
  34. ^ К. Андерсен; Б. Лонг; С. Бланк; М. Кучерави . Протокол аутентифицированной полученной цепочки (ARC) . IETF . дои : 10.17487/RFC8617/ . RFC 8617/ .
  35. ↑ Зеттер, Ким (24 октября 2012 г.). «Как электронная почта хедхантера Google обнаружила огромную дыру в безопасности сети» . Проводной . По состоянию на 24 октября 2012 г.
  36. ^ «Часто задаваемые вопросы по DKIM» . DKIM.org . 16 октября 2007 года . Проверено 4 января 2016 г. DKIM был разработан отраслевым консорциумом в 2004 году. Он объединил и усовершенствовал DomainKeys от Yahoo! и «Опознанная почта Интернета» от Cisco.
  37. ^ Джим Фентон (15 июня 2009 г.). «Почта с идентификатором DomainKeys (DKIM) значительно растет» . Циско . Архивировано из оригинала 24 декабря 2014 года . Проверено 28 октября 2014 г.
  38. ^ «STD 76, RFC 6376 о подписях почты, идентифицируемых доменными ключами (DKIM)» . IETF . 11 июля 2013 года . Проверено 12 июля 2013 г. RFC 6376 повышен до уровня интернет-стандарта.
  39. ^ «Идентифицированная почта Интернета: сетевой подход к подписанию сообщений для борьбы с мошенничеством с электронной почтой» . 26 апреля 2006 г. Архивировано из оригинала 27 апреля 2006 г. Проверено 4 января 2016 г.
  40. ^ Джим Фентон; Майкл Томас (1 июня 2004 г.). Идентифицированная почта Интернета . IETF . Идентификатор Draft-Fenton-identified-mail-00 . Проверено 6 января 2016 г.
  41. ^ Перейти обратно: а б с Делани, Марк (22 мая 2007 г.). «Один маленький шаг для электронной почты, большой скачок для безопасности в Интернете». Архивировано 14 марта 2013 года в Wayback Machine . Yahoo! корпоративный блог. Делани считается главным архитектором и изобретателем DomainKeys.
  42. ^ «Yahoo публикует спецификации для DomainKeys» . DMNews.com . 19 мая 2004 г.
  43. ^ RFC 4870 («Аутентификация электронной почты на основе домена с использованием открытых ключей, объявленных в DNS (DomainKeys)»; устаревший RFC 4871).
  44. ^ RFC 6376 («Подписи почты, идентифицированные доменными ключами (DKIM)»; устаревшие RFC 4871 и RFC 5672).
  45. ↑ Тейлор, Брэд (8 июля 2008 г.). «Борьба с фишингом с помощью eBay и Paypal» . Блог Gmail.
  46. ^ «У меня проблемы с отправкой сообщений в Gmail» . Запись в справке Gmail, в которой упоминается поддержка DKIM при отправке.
  47. ↑ Мюллер, Роб (13 августа 2009 г.). «Вся исходящая электронная почта теперь подписывается DKIM». Архивировано 6 октября 2011 г. на Wayback Machine . Блог Fastmail.
  48. ^ «История группы DMARC» . IETF .
  49. ^ «Обновление криптографии DKIM (dcrup)» . IETF .
  50. ^ Скотт Киттерман (январь 2018 г.). Обновление криптографического алгоритма и использования ключей для почты с идентификатором DomainKeys (DKIM) . IETF . дои : 10.17487/RFC8301 . RFC 8301 .
  51. ^ Джон Левин (сентябрь 2018 г.). Новый метод криптографической подписи для почты, идентифицируемой DomainKeys (DKIM) . IETF . дои : 10.17487/RFC8463 . RFC 8463 .
  52. ^ «ОпенДКИМ» .
  53. ^ «Новые средства защиты Gmail для более безопасного и меньшего количества спама в почтовом ящике» . Google . 3 октября 2023 г.
  54. ^ «Новые требования к доставке электронной почты в Gmail — Valimail» . www.valimail.com . 3 октября 2023 г.
  55. ^ «Лучшие практики отправителей» . senders.yahooinc.com .

50. Зачем мне устанавливать DKIM, если мой DMARC может передавать только SPF?

Дальнейшее чтение

[ редактировать ]
  • RFC 4686 Анализ угроз, мотивирующих почту, идентифицированную с помощью DomainKeys (DKIM)
  • RFC 4871. Подписи почты, идентифицированные доменными ключами (DKIM). Предлагаемый стандарт.
  • RFC 5617 DomainKeys Identified Mail (DKIM) Авторские методы подписи домена (ADSP)
  • RFC 5585 (DKIM) Обзор службы доменной почты
  • RFC 5672 RFC 4871 Подписи почты, идентифицированные доменными ключами (DKIM) — обновление
  • RFC 5863 Разработка, развертывание и эксплуатация DKIM
  • RFC 6376. сигнатур электронной почты, идентифицируемой доменными ключами (DKIM). Проект стандарта
  • RFC 6377. Почта, идентифицированная DomainKeys (DKIM) и списки рассылки.
  • Обновление криптографического алгоритма и использования ключей RFC 8301 для почты, идентифицируемой DomainKeys (DKIM)
  • RFC 8463: Новый метод криптографической подписи для почты, идентифицируемой DomainKeys (DKIM)
[ редактировать ]
Retrieved from "https://en.wikipedia.org/w/index.php?title=DomainKeys_Identified_Mail&oldid=1224409242"
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: 158796cdd6f11d96faba53aad44c7000__1716004560
URL1:https://arc.ask3.ru/arc/aa/15/00/158796cdd6f11d96faba53aad44c7000.html
Заголовок, (Title) документа по адресу, URL1:
DomainKeys Identified Mail - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)