Из Википедии, бесплатной энциклопедии
  (Перенаправлено из DKIM )
Перейти к навигации Перейти к поиску

Набор интернет-протоколов
Уровень приложения
Транспортный уровень
Интернет-уровень
Связующий слой
  • ARP
  • Пнр
  • OSPF
  • Туннели
    • L2TP
  • PPP
  • MAC
    • Ethernet
    • Вай фай
    • DSL
    • ISDN
    • FDDI
  • более...
  • v
  • т
  • е

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

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

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

Обзор [ править ]

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

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

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

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

Технические детали [ править ]

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

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

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

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 , метод запроса по умолчанию
  • t , отметка времени подписи
  • x , время истечения
  • h , поля заголовка - список подписанных
  • бх , хеш тела
  • b , подпись заголовков и тела

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

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

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

Подтверждение [ править ]

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

brisbane._domainkey.example.net

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

"k = rsa; t = s; p = MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDDmzRmJRQxLEuyYiyMg4suA2SyMwR5MGHpP9diNT1hRiwUd / mZp1ro7kIDTKS8ttkI6z6eTRW9e9dDOxzSxNuXmume60Cjbu08gOyhPG3GfWdg7QkdN6kR4V75MFlw624VY35DaXBvnlTJTgRg / EW72O1DiYVThkyCgpSYS8nmEQIDAQAB "

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

Ошибка проверки подписи не приводит к принудительному отклонению сообщения. Вместо этого, точные причины, по которым аутентичность сообщения не может быть доказана, должны быть доступны для последующих и вышестоящих процессов. Способы для этого могут включать отправку обратно сообщения FBL или добавление поля заголовка Authentication-Results к сообщению, как описано в 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 , за исключением того, что проверка на стороне получателя представляет собой незначительный объем работы, в то время как типичный алгоритм hashcash потребует гораздо больше работы.

Безотказность [ править ]

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

Слабые стороны [ править ]

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

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

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

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

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

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

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

Модификация содержания [ править ]

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

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

Аннотации по спискам рассылки [ править ]

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

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

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

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

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

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

История [ править ]

DKIM появился в 2004 году в результате слияния двух аналогичных проектов: «Расширенные ключи домена» от Yahoo и «Идентифицированная интернет-почта» от Cisco . [33] [34] Эта объединенная спецификация послужила основой для ряда спецификаций IETF, отслеживающих стандарты, и вспомогательных документов, которые в конечном итоге привели к созданию стандарта STD 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 года. Он добавляет алгоритм эллиптической кривой к существующему RSA . Добавленный тип ключа достаточно надежен, но имеет короткие открытые ключи, которые легче опубликовать в DNS. [48]k=ed25519

Развитие [ править ]

Оригинальные ключи 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 . [49]

См. Также [ править ]

  • Полученная цепочка с аутентификацией (ARC)
  • Авторские методы подписания доменов
  • Сообщение об отказе
  • Контекстная фильтрация
  • Доменная проверка подлинности сообщений, отчетность и соответствие (DMARC)
  • DomainKeys
  • E-mail аутентификация
  • OpenPGP
  • S / MIME
  • Структура политики отправителя
  • Поручиться по ссылке

Ссылки [ править ]

  1. ^ Тони Хансен; Дэйв Крокер; Филлип Халлам-Бейкер (июль 2009 г.). Обзор службы DomainKeys Identified Mail (DKIM) . IETF . DOI : 10,17487 / RFC5585 . RFC 5585 . Проверено 6 января +2016 . Получатели, успешно подтвердившие подпись, могут использовать информацию о подписывающей стороне как часть программы для ограничения спама, спуфинга, фишинга или других нежелательных действий. DKIM сам по себе не предписывает никаких конкретных действий получателя; скорее, это технология, позволяющая предоставлять услуги.
  2. ^ а б Дэйв Крокер; Тони Хансен; Мюррей С. Кучерави, ред. (Сентябрь 2011 г.). «Целостность данных» . Подписи электронной почты с идентификацией ключей (DKIM) . IETF . сек. 1.5. DOI : 10,17487 / RFC6376 . RFC 6376 . Проверено 6 января +2016 . Проверка подписи подтверждает, что хешированное содержимое не изменилось с момента подписания, и ничего не говорит о «защите» сквозной целостности сообщения.
  3. ^ Crocker, D .; Hansen, T .; Кучерави, М. «Подписи в почте с идентификацией ключей домена (DKIM)» . Редактор RFC . ISSN 2070-1721 . Проверено 30 марта 2020 . 
  4. ^ Jason P. Stadtlander (16 января 2015). «Спуфинг электронной почты: объяснение (и как защитить себя)» . HuffPost . Проверено 11 января +2016 .
  5. ^ Дэйв Крокер; Тони Хансен; Мюррей С. Кучерави, ред. (Июль 2009 г.). «Определите поля заголовка для подписи» . Подписи электронной почты с идентификацией ключей (DKIM) . IETF . сек. 5.4. DOI : 10,17487 / RFC6376 . RFC 6376 . Проверено 6 января +2016 . Поле заголовка From ДОЛЖНО быть подписано (то есть должно быть включено в тег "h =" результирующего поля заголовка DKIM-Signature).
  6. ^ Модули подписи используют частную половину пары ключей для подписи и публикуют общедоступную половину в записи DNS TXT, как описано в разделе «Проверка» ниже.
  7. ^ Обратите внимание, что нет ни центров сертификации, ни списков отзыва, участвующих в управлении ключами DKIM, а селектор - это простой метод, позволяющий подписавшимся добавлять и удалять ключи, когда они пожелают - долговременные подписи для архивных целей выходят за рамки DKIM.
  8. ↑ Джон Левин (июнь 2019). «DKIM и международная почта» . Проверка подлинности электронной почты для интернационализированной почты . IETF . сек. 5. DOI : 10,17487 / RFC8616 . RFC 8616 .
  9. ^ например, из командной строки: nslookup -q = TXT brisbane._domainkey.example.net
  10. ^ "Yahoo! DomainKeys Patent License Agreement 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. ↑ a b Falk, JD (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 . DOI : 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. DOI : 10,17487 / RFC4686 . RFC 4686 . Проверено 10 января +2016 .
  25. ^ Ned Freed (с согласия Джона Klensin ) (5 марта 2010). "secdir обзор draft-ietf-yam-rfc1652bis-03" . Список рассылки YAM . IETF . Проверено 30 мая 2010 года . DKIM WG предпочла простоту канонической формы канонической форме, устойчивой к изменениям кодировки. Это был их инженерный выбор, и они его сделали.
  26. ^ RFC 2045 позволяет значению параметра быть либо токеном, либо строкой в ​​кавычках, например, в {{{1}}} кавычки могут быть законно удалены, что нарушает подписи DKIM.
  27. ^ Kucherawy, Мюррей (28 марта 2011). «Отчет о реализации RFC4871» . IETF . Проверено 18 февраля 2012 года .
  28. ^ Мюррей С. Kucherawy (сентябрь 2011). Почта с идентификационными ключами домена (DKIM) и списки рассылки . IETF . DOI : 10,17487 / RFC6377 . RFC 6377 . Проверено 10 января +2016 .
  29. ^ Эрик Оллман; Марк Делани; Джим Фентон (август 2006 г.). «Действия диспетчера списков рассылки» . Правила подписи отправителя DKIM . IETF . сек. 5.1. ID draft-allman-dkim-ssp-02 . Проверено 10 января +2016 .
  30. ^ «Обзор аутентифицированной полученной цепочки» (PDF) . Дата обращения 15 июня 2017 .
  31. ^ "RFC 8617 - Протокол аутентифицированной полученной цепочки (ARC)" . datatracker.ietf.org . Дата обращения 17 июля 2019 .
  32. ^ Zetter, Ким (24 октября 2012). «Как электронная почта Google Headhunter раскрыла огромную дыру в сетевой безопасности» . Проводной . Доступ 24 октября 2012 г.
  33. ^ «Часто задаваемые вопросы DKIM» . DKIM.org . 16 октября 2007 . Дата обращения 4 января 2016 . DKIM был разработан отраслевым консорциумом в 2004 году. Он объединил и расширил DomainKeys от Yahoo! и «Идентифицированная интернет-почта» от Cisco.
  34. ↑ Джим Фентон (15 июня 2009 г.). «Почта, идентифицированная с помощью DomainKeys (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 . ID draft-fenton-identify-mail-00 . Проверено 6 января +2016 .
  38. ^ a b c Делани, Марк (22 мая 2007 г.). «Один маленький шаг для электронной почты, один гигантский скачок в безопасности в Интернете» . Yahoo! корпоративный блог. Делани считается главным архитектором, изобретателем DomainKeys.
  39. ^ «Yahoo Releases Specs for DomainKeys» . 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 . DOI : 10,17487 / RFC8301 . RFC 8301 .
  48. ^ Джон Левин (сентябрь 2018). Новый метод криптографической подписи для почты с идентификационными ключами домена (DKIM) . IETF . DOI : 10,17487 / RFC8463 . RFC 8463 .
  49. ^ "OpenDKIM" .

Дальнейшее чтение [ править ]

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

Внешние ссылки [ править ]

  • Почта с идентификационными ключами домена (DKIM)