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