DKIM: Могу ли я просто изменить ключ RSA, используемый в DKIM, не меняя селектора DKIM ?

OpenDKIM, OpenDMARC, Rspamd, ClamAV

Я полагаю, у вас есть OpenDMARC, настроенный на сам SPF? Вы также захотите отключить проверку SPF / DKIM / DMARC в Rspamd.

• вам нужен openDKIM перед openDMARC, чтобы проверка DMARC могла выполняться на основе заголовка Auth-Results:, установленного openDKIM.
• Вы нужно, чтобы openDMARC был перед Rspamd, чтобы он мог отправлять отчеты DMARC по всем сообщениям, а не только по тем, которые прошли Rspamd.
• Вы хотите, чтобы Clam был последним, чтобы избежать сообщений сканирования AV, которые может блокировать первым другой метод фильтрации содержимого. 121 --- 104470-

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

  Кроме того, в Википедии термины:" ... Принимающий SMTP-сервер использует доменное имя и селектор для выполнения поиска в DNS [...] селектор является простым метод, позволяющий подписывающим сторонам добавлять и удалять ключи, когда они пожелают ... "

  Другими словами, если вы отправляете электронное письмо, подписанное DKIM, вы должны сообщить внешним почтовым серверам [113707] 8] КАК они могут получить ваш ключ RSA для проверки действительности вашей электронной почты. RSA-ключ опубликован в вашем DNS, но ГДЕ ? Какой DNS-запрос его получит? Как они узнают, какой DNS-запрос / запись разрешает? Здесь селектор играет свою роль: если вы отправляете почту с домена example.com и в своей почте вы объявляете независимо от в качестве селектора, тогда:

  • в заголовок исходящей почты, вам необходимо указать ваш домен и соответствующий селектор, например:

  DKIM-Signature [...] d = example.com; [...] s = любой

  • в вашем DNS, вы должны предоставить запись TXT для something._domainkey.example.com публикации вашего ключа RSA, например:

  something._domainkey.example.com IN TXT "k = rsa \; t = s \; p = MIGfMA [...] AQAB"

  Как видите, DNS-запрос имеет вид ._domainkey.

  Исходя из этого, мы можем сказать, что:

  1. RSA-ключ может быть заменен / обновлен без какого-либо воздействия на селектор. Очевидно, что очень важно, чтобы при обновлении одной стороны ключа (общедоступной, опубликованной в DNS) вы изменили и другую сторону (ту, которая используется для «подписи» исходящей почты);

  2. если вы оставите селектор не изменился при обновлении ключа RSA, побочным эффектом является то, что .... удаленные клиенты (не серверы; я говорю о MUA ), которые по тем или иным причинам хотят проверить включенную DKIM-подпись в своих старых / заархивированных электронных письмах не пройдут процесс проверки (поскольку заархивированное электронное письмо было подписано закрытым ключом, открытый ключ которого, опубликованный в DNS, был обновлен и теперь отличается!) .

  Я хочу добавить, что по своему опыту я привык думать, что DKIM-подпись / проверка - это процесс, нацеленный на транспортировку электронной почты, а не на клиентскую сторону проверки. Так что я готов поспорить, что обновлять KEYs, оставляя селектор нетронутым, вполне безопасно.

  Я также думаю, что .... если вы собираетесь обновить KEY, то вам нужно изменить оба кода подписи. (который должен указывать на новый закрытый ключ) и DNS (чтобы опубликовать новый открытый ключ в записи TXT). Так почему бы не изменить и селектор (опять же, с обеих сторон?). В итоге вы получите ДВА селектора, опубликованных в DNS, один из которых указывает на старый ключ, а другой - на новый. Таким образом, все будет в порядке во время передачи SMTP, а также MUA смогут проверять старые / заархивированные электронные письма, поскольку старый ключ, связанный со старым селектором, все еще доступен.

Могу ли я просто изменить ключ RSA, используемый в DKIM (запись DNS TXT), не меняя селектор DKIM, или это приведет к каким-либо проблемам?

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

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

• Изменения DNS могут занять некоторое время, чтобы размножаются. Если селектор повторно используется после смены ключа, это может привести к сбою проверки для электронных писем, отправленных вскоре после смены ключа.
• Вы не знаете, сколько времени пройдет между отправкой и проверкой. Это может привести к тому, что старые сообщения не пройдут проверку после смены ключа. Возможная причина задержки:
  • Сообщение застревает во время передачи.
  • Хотя я думаю, что это очень редко, проверка также может происходить внутри MUA ( существует надстройка для Thunderbird, которая делает это )
• Из RFC : "Повторное использование селектора с новым ключом (например, изменение ключа, связанного с именем пользователя) делает невозможным отличить сообщение, которое не подтвердил, потому что ключ уже недействителен и сообщение это фактически подделано. По этой причине Подписанты опрометчивы повторно использовать селекторы для новых ключей. Лучшая стратегия - назначить новые ключи к новым селекторам ».

Какова цель селектора DKIM?

« Для поддержки нескольких одновременных открытых ключей для каждого домена подписи ». Вот некоторые варианты использования параллельных ключей:

• « Помимо удобства администрирования , селекторы позволяют беспрепятственно заменять открытые ключи на регулярной основе ».
• Разрешите различным организациям подписывать ваши электронные письма (с другим ключом и селектором) без необходимости совместного использования закрытого ключа. Это полезно для:
  • делегирование подписи внешней организации
  • административно распределенные организации
• Сделать возможным явный отзыв ключа (оставив данные открытого ключа (тег «p =») пустыми).

Все цитаты взяты из RFC 6376 .

Вы можете сделать это. Однако это не обязательно BCP.

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

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

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

(Полагаю, вы на самом деле не имеете в виду ключ 20120113._domainkey.gmail.com буквально? Если вы действительно говорите о Gmail , остановитесь и поговорите с Джоном Р.Г., прежде чем что-либо менять.)