Привет всем, у нас возникла проблема с проверкой подписи DKIM в нашем ESA (Cisco C695 с AsyncOS 15.5.3 build 024). Проверка подписи завершается сбоем, если домен в d-теге DKIM-Header написан заглавными буквами. Например, электронное письмо с такими заголовками От: XXXXXX@GMX.DE
DKIM-подпись: v=1; a=rsa-sha256; c=relaxed/relaxed; d=GMX.DE;
s=s31663417; t=1765447896; x=1766052696; i=XXXXXX@gmx.de;
bh=3WkY40n5W/suCgsM+RiHzyMZm85PRGarESNZU1ADwm4=;
h=X-UI-Sender-Class:Message-ID:Date:MIME-Version:From:Subject:Кому:
Тип содержимого:Кодировка передачи содержимого:cc:
content-transfer-encoding:content-type:date:from:message-id:
mime-version:reply-to:subject:to;
b=hZhfnBcOm.... приводит к Результаты аутентификации: esa.example.net; dkim=permerror (несовпадение домена) header.i=none; spf=Pass smtp.mailfrom=XXXXX@gmx.de; dmarc=pass (p=quarantine dis=none) d=gmx.de Та же самая почта, отправленная с доменом в нижнем регистре в поле «От» и d-теге, была успешно проверена dkim: From: XXXXX@gmx.de
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.de;
s=s31663417; t=1765447864; x=1766052664; i=XXXXX@gmx.de;
bh=3WkY40n5W/suCgsM+RiHzyMZm85PRGarESNZU1ADwm4=;
h=X-UI-Sender-Class:Message-ID:Date:MIME-Version:From:Subject:Кому:
Тип содержимого:Кодировка передачи содержимого:cc:
content-transfer-encoding:content-type:date:from:message-id:
mime-version:reply-to:subject:to;
b=l6Ir7eQEZ... -> Результаты аутентификации: esa.example.net; spf=Pass smtp.mailfrom=XXXXX@gmx.de; dkim=pass (подпись проверена) header.i=XXXXX@gmx.de; dmarc=pass (p=quarantine dis=none) d=gmx.de Rspamd и Thunderbird DKIM-Plugin в обоих случаях подтверждают правильность подписи dkim. Я предполагаю, что проблема может быть связана с различиями в домене в i-теге и d-теге («d=GMX.DE» против «i=XXXXXX@gmx.de»). С уважением,
Харальд

]]>https://sla247.ru/forum/topic/2461/esa-проверка-подписи-dkim-не-удалась-если-домен-подписи-написан-заглавными-буквамиRSS for NodeFri, 15 May 2026 12:49:39 GMTMon, 02 Mar 2026 21:16:16 GMT60Привет, Кристиан, спасибо за информацию. Значит, Cisco поступает правильно, а GMX — неправильно... С уважением,
Харальд

]]>https://sla247.ru/forum/post/17236https://sla247.ru/forum/post/17236Mon, 02 Mar 2026 21:16:18 GMTЗдравствуйте, К сожалению, вы совершенно правы в отношении основной причины, и в настоящее время нет способа исправить это. Когда Cisco внедряла DKIM, она взяла RFC за основу и реализовала эту функцию в соответствии с RFC, в котором говорится, что «теги должны интерпретироваться с учетом регистра», см.
https://datatracker.ietf.org/doc/html/rfc6376
; В результате, в таких сценариях, как тот, который вы описали, даже если DKIM проходит проверку, из-за несовпадения регистра между тегами «i» и «d» окончательным решением является permerror / permfail. С моей точки зрения, Cisco проделала отличную работу, поскольку MUST в RFC является MUST, никаких интерпретаций и/или отклонений не должно быть; однако, как вы видите, иногда это создает проблемы в реальных ситуациях. Существует запрос на улучшение для этого конкретного случая использования, см.
https://bst.cisco.com/quickview/bug/CSCwr87318
; не путайте ослабленную/строгую конвенцию именования из этого запроса с другой ослабленной/строгой функциональностью в DKIM, которая имеет другой объем, см. здесь (
https://www.cisco.com/c/en/us/support/docs/security/email-security-appliance/213946-dmarc-architecture-identifier-alignmen.html
), и вы настроили ее как ослабленную. Одним из вариантов решения может быть настройка исключения DKIM для таких доменов до тех пор, пока в какой-то момент запрос на улучшение не будет реализован в производственной среде. Спасибо, Кристиан.

]]>https://sla247.ru/forum/post/17235https://sla247.ru/forum/post/17235Mon, 02 Mar 2026 21:16:17 GMT