Почта, идентифицированная с помощью DomainKeys - DomainKeys Identified Mail

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

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

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

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

Обзор

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

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

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

Все это не зависит от Простой протокол передачи почты (SMTP) аспекты маршрутизации в том смысле, что он работает на RFC 5322 сообщение - заголовок и тело транспортируемого письма, а не "конверт" SMTP, определенный в RFC 5321. Следовательно, подписи DKIM выдерживают базовую ретрансляцию через несколько MTA.

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

Подписание

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

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

DKIM-подпись:v = 1;а = rsa-sha256;d =example.net;s = брисбен;c = расслабленный / простой;q = dns / txt;t = 1117574938;х = 1118006938;h = от: до: тема: дата: ключевые слова: ключевые слова;bh = MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI =;b = dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav + yuU4zGeeruD00lszZВоГ4ЖРНиЫзР

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

  • v, версия
  • а, алгоритм подписи
  • d, домен
  • s, селектор
  • c, канонизация алгоритм (ы) для заголовка и тела
  • q, метод запроса по умолчанию
  • т, отметка времени подписи
  • Икс, Истекает время
  • час, поля заголовка - список подписанных
  • бх, хеш тела
  • б, подпись заголовков и тела

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

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

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

Проверка

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

brisbane._domainkey.example.net

Обратите внимание, что селектор и имя домена могут быть UTF-8 в интернационализированных сообщениях электронной почты.[8] В этом случае этикетка должна быть закодирована в соответствии с IDNA перед поиском. Данные, возвращаемые из запроса этой записи, также представляют собой список пар тег-значение. Он включает в себя открытый ключ вместе с другими ключевыми токенами и флагами использования;[9] как в этом примере:

"К = RSA; T = S; р = MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDDmzRmJRQxLEuyYiyMg4suA2SyMwR5MGHpP9diNT1hRiwUd / mZp1ro7kIDTKS8ttkI6z6eTRW9e9dDOxzSxNuXmume60Cjbu08gOyhPG3GfWdg7QkdN6kR4V75MFlw624VY35DaXBvnlTJTgRg / EW72O1DiYVThkyCgpSYS8nmEQIDAQAB"

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

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

Патент

Хотя DomainKeys покрывается Патент США 6,986,049 , Yahoo! лицензировала свои патентные заявки по схеме двойной лицензии: Патентное лицензионное соглашение DomainKeys v1.2,[10] или же Стандартная общественная лицензия GNU 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]

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

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

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

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

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

Безотказность

DKIM's неотречение эта функция не позволяет отправителям (например, спамерам) достоверно отрицать отправку электронного письма. Это оказалось полезным для источников новостей, таких как WikiLeaks, который смог использовать подписи тела DKIM, чтобы доказать, что просочившиеся электронные письма были подлинными и не были подделаны - например, окончательно опровергая такие утверждения Хиллари Клинтон с Президентские выборы в США 2016 напарник Тим Кейн, и DNC Стул Донна Бразиле.[21]

Недостатки

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

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

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

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

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

Произвольная пересылка

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

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

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

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

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

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

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

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

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

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

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

История

DKIM возник в 2004 году в результате слияния двух аналогичных усилий, «расширенных ключей домена» от Yahoo и "Идентифицированная интернет-почта" от Cisco.[33][34] Эта объединенная спецификация послужила основой для серии IETF стандарты отслеживают спецификации и вспомогательные документы, которые в конечном итоге привели к ЗППП 76, В данный момент RFC 6376.[35]«Идентифицированная интернет-почта» была предложена Cisco как стандарт аутентификации почты на основе подписи,[36][37]в то время как DomainKeys был разработан Yahoo[38][39] чтобы проверить Домен DNS из электронное письмо отправитель и целостность сообщения.

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

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

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

Разработка

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

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

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

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

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

  1. ^ Тони Хансен; Дэйв Крокер; Филлип Халлам-Бейкер (Июль 2009 г.). Обзор службы DomainKeys Identified Mail (DKIM). IETF. Дои:10.17487 / RFC5585. RFC 5585. Получено 6 января 2016. Получатели, успешно подтвердившие подпись, могут использовать информацию о подписывающей стороне как часть программы для ограничения спама, спуфинга, фишинга или других нежелательных действий. DKIM сам по себе не предписывает никаких конкретных действий получателя; скорее, это технология, позволяющая предоставлять услуги.
  2. ^ а б Дэйв Крокер; Тони Хансен; Мюррей С. Кучерави, ред. (Сентябрь 2011 г.). "Целостность данных". Подпись электронной почты с идентификацией ключей (DKIM). IETF. сек. 1.5. Дои:10.17487 / RFC6376. RFC 6376. Получено 6 января 2016. Проверка подписи подтверждает, что хешированное содержимое не изменилось с момента подписания, и ничего не говорит о «защите» сквозной целостности сообщения.
  3. ^ Crocker, D .; Hansen, T .; Кучерави, М. «Подписи электронной почты с идентификацией ключей домена (DKIM)». Редактор RFC. ISSN  2070-1721. Получено 30 марта 2020.
  4. ^ Джейсон П. Штадтландер (16 января 2015 г.). «Спуфинг электронной почты: объяснение (и как защитить себя)». HuffPost. Получено 11 января 2016.
  5. ^ Дэйв Крокер; Тони Хансен; Мюррей С. Кучерави, ред. (Июль 2009 г.). «Определите поля заголовка для подписи». Подпись электронной почты с идентификацией ключей домена (DKIM). IETF. сек. 5.4. Дои:10.17487 / RFC6376. RFC 6376. Получено 6 января 2016. Поле заголовка From ДОЛЖНО быть подписано (то есть должно быть включено в тег "h =" результирующего поля заголовка DKIM-Signature).
  6. ^ Модули подписи используют частную половину пары ключей для подписи и публикуют общедоступную половину в записи DNS TXT, как описано в разделе «Проверка» ниже.
  7. ^ Обратите внимание, что нет Центры сертификации ни списки отзыва, участвующие в управлении ключами DKIM, а селектор - это простой метод, позволяющий подписывающим сторонам добавлять и удалять ключи, когда они захотят - долговременные подписи для архивных целей выходят за рамки DKIM.
  8. ^ Джон Левин (июнь 2019). "DKIM и международная почта". Проверка подлинности электронной почты для интернационализированной почты. IETF. сек. 5. Дои:10.17487 / RFC8616. RFC 8616.
  9. ^ например из командной строки: nslookup -q = TXT brisbane._domainkey.example.net
  10. ^ "Патентное лицензионное соглашение Yahoo! DomainKeys v1.1". SourceForge. 2006. Получено 30 мая 2010. Yahoo! Патентное лицензионное соглашение DomainKeys v1.2
  11. ^ Левин, Джон Р. (25 января 2010 г.). «Раскрытие информации о правах интеллектуальной собственности, сбор вопросов по перефрахтованию». список рассылки ietf-dkim. Ассоциация взаимных интернет-практик. Получено 30 мая 2010. Ссылка на GPL мне кажется, что она охватывает только старую библиотеку Sourceforge DK, которую, я думаю, никто больше не использует. На патент, что очень важно, распространяется отдельная лицензия, которую написала Yahoo.
  12. ^ Чен, Энди (26 сентября 2011 г.). «Заявление Yahoo! Inc. о правах интеллектуальной собственности на RFC 6376». Раскрытие прав интеллектуальной собственности. IETF. Получено 3 октября 2011.
  13. ^ "История". dmarc.org.
  14. ^ а б Фальк, Дж.Д. (17 марта 2009 г.). «В поисках истины в DKIM». CircleID.
  15. ^ Барри Лейба (25 ноября 2013 г.). «Измените статус ADSP (RFC 5617) на Исторический». IETF. Получено 13 марта 2015.
  16. ^ "FAQ - DMARC Wiki". Стандарт DMARC заявляет в Разделе 6.7, «Соображения по применению политик», что если политика DMARC обнаружена, получатель должен игнорировать политики, объявленные с помощью других средств, таких как SPF или ADSP.
  17. ^ "Добавить запись DMARC - Справка администратора Google Apps".
  18. ^ "О DMARC - Справка администратора Google Apps". Ваша политика может быть строгой или расслабленной. Например, eBay и PayPal публикуют политику, требующую аутентификации всей их почты, чтобы она появлялась в чьем-либо почтовом ящике. В соответствии с их политикой Google отклоняет все сообщения от eBay или PayPal, которые не прошли проверку подлинности.
  19. ^ Тони Хансен; Дэйв Крокер; Филлип Халлам-Бейкер (июль 2009 г.). Обзор службы DomainKeys Identified Mail (DKIM). IETF. Дои:10.17487 / RFC5585. RFC 5585. Получено 1 июля 2013.
  20. ^ Ройс, Алессио (5 июля 2007 г.). «Штемпель: в борьбе со спамом» В архиве 17 июля 2011 г. Wayback Machine. Блог Microsoft Office Outlook.
  21. ^ «Проверка DKIM». www.wikileaks.org. 4 ноября 2016 г.. Получено 7 ноября 2016.
  22. ^ «Соображения безопасности», ietf.org
  23. ^ «Отчет IESG относительно» апелляции на решение о продвижении RFC6376"". IETF.org. IETF. Получено 26 декабря 2018.
  24. ^ Джим Фентон (сентябрь 2006 г.). «Воспроизведение выбранного сообщения». Анализ угроз, мотивирующих почтовое сообщение с идентификационными ключами домена (DKIM). IETF. сек. 4.1.4. Дои:10.17487 / RFC4686. RFC 4686. Получено 10 января 2016.
  25. ^ Нед Фрид (с согласия Джон Кленсин ) (5 марта 2010 г.). "secdir обзор draft-ietf-yam-rfc1652bis-03". Список рассылки YAM. IETF. Получено 30 мая 2010. DKIM WG предпочла простоту канонической формы канонической форме, устойчивой к изменениям кодировки. Это был их инженерный выбор, и они его сделали.
  26. ^ RFC 2045 позволяет значению параметра быть либо токеном, либо строкой в ​​кавычках, например в {{{1}}} кавычки могут быть удалены по закону, что нарушает подпись DKIM.
  27. ^ Кучерави, Мюррей (28 марта 2011 г.). «Отчет о реализации RFC4871». IETF. Получено 18 февраля 2012.
  28. ^ Мюррей С. Кучерави (сентябрь 2011 г.). Почта с идентификационными ключами домена (DKIM) и списки рассылки. IETF. Дои:10.17487 / RFC6377. RFC 6377. Получено 10 января 2016.
  29. ^ Эрик Оллман; Марк Делани; Джим Фентон (август 2006 г.). "Действия диспетчера списков рассылки". Порядок подписи отправителя DKIM. IETF. сек. 5.1. I-D draft-allman-dkim-ssp-02. Получено 10 января 2016.
  30. ^ "Обзор полученной цепочки с проверкой подлинности" (PDF). Получено 15 июн 2017.
  31. ^ "RFC 8617 - Протокол аутентифицированной цепочки приема (ARC)". datatracker.ietf.org. Получено 17 июля 2019.
  32. ^ Зеттер, Ким (24 октября 2012 г.). "Как электронная почта Google Headhunter раскрыла огромную дыру в безопасности сети". Проводной. Доступ 24 октября 2012 г.
  33. ^ «Часто задаваемые вопросы о DKIM». DKIM.org. 16 октября 2007 г.. Получено 4 января 2016. DKIM был разработан отраслевым консорциумом в 2004 году. Он объединил и расширил DomainKeys от Yahoo! и «Идентифицированная интернет-почта» от Cisco.
  34. ^ Джим Фентон (15 июня 2009 г.). "Почта с идентификационными ключами домена (DKIM) значительно растет". Cisco. Архивировано из оригинал 24 декабря 2014 г.. Получено 28 октября 2014.
  35. ^ "STD 76, RFC 6376 о подписях почты с идентификацией ключей домена (DKIM)". IETF. 11 июля 2013 г.. Получено 12 июля 2013. RFC 6376 был повышен до уровня Интернет-стандарта.
  36. ^ «Идентифицированная интернет-почта: сетевой подход к подписанию сообщений для борьбы с мошенничеством с электронной почтой». 26 апреля 2006 г. Архивировано с оригинал 27 апреля 2006 г.. Получено 4 января 2016.
  37. ^ Джим Фентон; Майкл Томас (1 июня 2004 г.). Идентифицированная интернет-почта. IETF. I-D draft-fenton-identify-mail-00. Получено 6 января 2016.
  38. ^ а б c Делани, Марк (22 мая 2007 г.). «Один маленький шаг для электронной почты, один гигантский скачок в безопасности в Интернете». Yahoo! корпоративный блог. Делани считается главным архитектором, изобретателем DomainKeys.
  39. ^ «Yahoo выпускает спецификации для ключей домена». DMNews.com.
  40. ^ RFC 4870 («Доменная аутентификация электронной почты с использованием открытых ключей, объявленных в DNS (DomainKeys)»; исключено RFC 4871 ).
  41. ^ RFC 6376 («Подписи электронной почты с идентификацией ключей домена (DKIM)»; устарело RFC 4871 и RFC 5672 ).
  42. ^ Тейлор, Брэд (8 июля 2008 г.). «Борьба с фишингом с помощью eBay и Paypal». Блог Gmail.
  43. ^ "У меня проблемы с отправкой сообщений в Gmail". Запись в справке Gmail с упоминанием поддержки DKIM при отправке.
  44. ^ Мюллер, Роб (13 августа 2009 г.). «Вся исходящая электронная почта теперь подписывается DKIM». Блог Fastmail.
  45. ^ "История группы DMARC". IETF.
  46. ^ «DKIM Crypto Update (dcrup)». IETF.
  47. ^ Скотт Киттерман (январь 2018 г.). Криптографический алгоритм и обновление использования ключей для почты с идентификацией ключей домена (DKIM). IETF. Дои:10.17487 / RFC8301. RFC 8301.
  48. ^ Джон Левин (сентябрь 2018 г.). Новый метод криптографической подписи для почты с идентификацией ключей домена (DKIM). IETF. Дои:10.17487 / RFC8463. RFC 8463.
  49. ^ «OpenDKIM».

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

  • RFC 4686 Анализ угроз, мотивирующих почтовое сообщение с идентификационными ключами домена (DKIM)
  • RFC 4871 Подпись электронной почты с идентификацией ключей домена (DKIM) Предлагаемый стандарт
  • RFC 5617 Почта с установленными ключами домена (DKIM) Авторские методы подписи доменов (ADSP)
  • RFC 5585 Обзор службы DomainKeys Identified Mail (DKIM)
  • RFC 5672 RFC 4871 DomainKeys Identified Mail (DKIM) Signatures - Update
  • RFC 5863 Разработка, развертывание и эксплуатация DKIM
  • RFC 6376 Подпись электронной почты с идентификацией ключей домена (DKIM) Проект стандарта
  • RFC 6377 Почта с идентификационными ключами домена (DKIM) и списки рассылки
  • RFC 8301 Криптографический алгоритм и обновление использования ключей для почты с идентификацией ключей домена (DKIM)

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