Технология DKIM для почтового сервера

Егор Васильев Mail Servers , , , 0 Комментариев

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

Если вам интересна тематика почтовых серверов, рекомендую обратиться к соответствующей рубрике на моем блоге – Mail Servers.

Технология DKIM для почтового сервера

Эта статья лишь кратко освещает некоторые нюансы технологии DKIM. Если вы хотите получить более подробную информацию из первоисточника, обратитесь к RFC 6376.

Рекомендую к прочтению перечень статей ниже:

Начинаем разбираться с DKIM.

Введение

DKIM – DomainKeys Identified Mail – технология, позволяющая обнаружить подделку сообщений и, таким образом, защититься от спуфинга. Но обо всем по порядку.

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

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

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

А теперь подробнее о самих заголовках.

Заголовки сообщения

Они бывают двух типов – заголовки самого сообщения и заголовки конверта.

Заголовки сообщения устанавливает его автор (вернее программа, в которой он пишет письмо), например:

С точки зрения передачи сообщения серверу-получателю эти заголовки не имеют никакого смысла и во время передачи не используются (как так, спросите вы? А вот…). Важны лишь заголовки MAIL FROM и RCPT TO (и другие), которые сервер-отправитель объявляет серверу-получателю во время SMTP-сессии, но для пользователя они скрыты. Эти заголовки называются заголовками конверта. Впоследствии, во время цикла передачи сообщения между серверами, информация внутри этих заголовков “замаскируется” в заголовках Received, которых обычно имеется по несколько штук в каждом сообщении (они показывают всю цепочку движения сообщения):

Примечание: чтобы лучше понимать назначение заголовков и принцип их обработки, советую почитать отличную статью Все о заголовках электронных писем. Не обращайте внимания на её дату, она все также актуальна, ведь фундаментальных изменений в SMTP с того времени не случилось и в нем царит все та же анархия.

Более того, заголовок MAIL FROM (его другие название – Return-Path или Envelope From) может вообще содержать адрес, отличный от содержимого заголовка From. В некоторых случаях это не будет являться признаком недобросовестных отправителей (например когда отчет о недоставке сообщения нужно отправить на другой адрес 1 или когда используется переадресация).

Вот такая интересная ситуация. Неудивительно, что для устранения такого “беспорядка” понадобился отдельный стандарт – DKIM, о котором пришло время рассказать подробнее.

Базовые понятия

В основе DKIM лежит ассиметричный алгоритм шифрования RSA 2. Сообщения подписываются закрытым ключом, который хранится у отправляющего (подписывающего) сервера, а открытый публикуется в TXT-записи на серверах DNS. Для извлечения открытого ключа из публичной записи необходимо “собрать” доменное имя. Оно состоит из вашего домена, обязательной части технологии DKIM – _domainkey – и имени селектора:

Как только доменное имя получено, извлекается TXT-запись, например:

Примечание: длина подписи DKIM может варьироваться, но очень часто она будет превышать 255 символов. У некоторых регистраторов админки не позволяют добавлять записи > 255 символов и это может быть проблемой. Обходное решение – разделить 3 всю запись на несколько кусков, каждый из которых не будет выходить за максимальные рамки длины. В этом случае ваша запись будет выглядеть примерно вот так:

mail._domainkey IN TXT ( “v=DKIM1; h=sha256; k=rsa; ” “p=<first_part>” “<another_part>” ) ; —– DKIM key mail for bq-srv.ru

Если и при таком подходе возникают сложности, то у вас не остается вариантов, кроме как обратиться в техподдержку регистратора. Также, не забывая о длине ключей, стоит разрешить для ваших DNS-серверов доступ по порту 53 TCP.

Пример DKIM-подписи 4 из реального сообщения:

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

  • v= – версия DKIM. Всегда имеет значение 1;
  • a= – алгоритм, используемый для генерации подписи;
  • c= – тип канонизации заголовка/тела сообщения. Перед подписью сообщение необходимо привести его к стандартному (канонизированному), чтобы не возникло проблем при проверке на принимающей стороне, ведь промежуточные серверы могут незначительно модифицировать сообщение. Это достаточно важный параметр, стоит обратить на него особое внимание;
  • d= – домен, который будет просматриваться на предмет наличия публичного ключа;
  • s= – селектор. Позволяет взять публичный ключ из нужной TXT-записи, если их вдруг несколько (а такое вполне может быть, если подписывающих серверов больше одного);
  • t= – отметка времени создания подписи;
  • bh= – хэш канонизированного тела сообщения;
  • h= – подписанные поля заголовков (список заголовков может варьироваться. Наличие тех или иных заголовков в подписи может защитить вас от некоторых потенциальных уязвимостей DKIM);
  • b= собственно, сама подпись.

Информация выше дана лишь для справки. Ключи подписи DKIM подробно описаны в RFC 4871, советую обратиться именно к этому документу для лучшего понимания. К тому же это не все заголовки, их бывает и больше.

Сколько селекторов надо для счастья

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

С точки зрения администрирования это обеспечивает следующие преимущества:

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

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

Тем не менее, факты говорят о том, что даже очень крупные публичные сервисы используют один и тот же ключ как минимум на нескольких серверах одновременно:

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

Дополнительные записи

Помимо DNS-записи с селектором существуют и другие. Одна из них – запись политики 5 DKIM, другая – _adsp-запись.

Первая (запись политики) используется для информирования принимающих серверов о том, должны ли все письма домена быть подписаны (o=-) или нет (o=~), а также имеет ряд дополнительных опций (например адрес для обратной связи). Запись может выглядеть вот так:

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

Следующая запись – _adsp – на момент написания статьи вообще является устаревшей 6 7. Вывод: дополнительные записи DKIM на данный момент не актуальны, используйте DMARC.

Также не забывайте, что конечная цель DKIM – не заставить принимающие серверы сразу отклонять сообщения с битой подписью, а просто предоставить ещё один механизм удостоверения отправляющей стороны 8:

Thus, DKIM specifies that an assessing site is not to take a message that has a broken signature and treat it any differently than if the signature weren’t there.

Принимающая сторона должна принимать решение о блокировке сообщений на основе множества факторов и оценок (например статус проверки DKIM может быть fail, но статус DMARC – pass. Но это уже совсем другая история).

Внедрение DKIM

Несмотря на исключительную пользу стандарта, в большинстве случаев внедрить его возможно только путем установки дополнительных компонентов.

Exchange Server

Exchange на сегодняшний момент является самым распространенным корпоративным почтовым сервисом и насчитывает десятки лет истории. Несмотря на это, вот уже и в Exchange Server 2019 9 функционала DKIM не предвидится.

Примечание: тем не менее, все же существуют варианты поднять DKIM на эксче с помощью DKIM Signing Agent for Microsoft Exchange Server 10. Несмотря на отсутствие поддержки со стороны Microsoft, решение все же распространено достаточно широко и в интернете есть много гайдов по настройке 11.

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

Postfix

Postfix всего лишь MTA (агент пересылки почты) и в его функционал DKIM также не включен, но зато он реализуется с помощью пакета OpenDKIM.

В одной из ближайших статей я планирую рассказать как настроить связку Postfix + OpenDKIM, а также как её использовать в качестве релэя для Exchange Server.

UPD 19.08.2018:

А вот и статья про настройку DKIM на Postfix: Настройка DKIM на Postfix.

Notes:

  1. Legitimate reasons SMTP “MAIL FROM:” will not match “From:” Header in DATA ↩
  2. Иллюстрация работы RSA на примере ↩
  3. How to Split DNS DKIM Records Properly ↩
  4. Structure of the DKIM-Signature header ↩
  5. What is the policy record used by DomainKeys? ↩
  6. DKIM — это просто ↩
  7. DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP) ↩
  8. DomainKeys Identified Mail (DKIM) Service Overview ↩
  9. Exchange Server 2019 Public Preview ↩
  10. DKIM Signing Agent for Microsoft Exchange Server ↩
  11. Реализация DKIM для Exchange Server 2013 ↩
  12. Creating transport agents for Exchange 2013 ↩

Похожие статьи:

Яндекс.Метрика