У меня есть домен, который отправляет два разных типа электронных писем: те, которые создаются с помощью автоматических процессов, таких как уведомления, отправляемые пользователям, и те, которые генерируются из Request Tracker (система тикетов).
Некоторое время назад мы настроили DKIM, и я совершил ошибку, никогда не проверяя, работают ли оба типа писем, поэтому я никогда не проверял письма RT. Совсем недавно мы поняли, что иногда сообщения, сгенерированные в режиме RT, попадают в спам-фильтры, и кажется, что неудачные проверки DKIM могут сыграть свою роль.
RT добавляет к каждому сообщению несколько заголовков, например:
X-RT-Loop-Prevention: Support
RT-Ticket: Support #3165
Managed-by: RT 3.8.2 (http://www.bestpractical.com/rt/)
RT-Originator: xxx@xxx.com
X-RT-Original-Encoding: utf-8
Однако эти заголовки не отображаются в подписи DKIM. Например, вот строка с жесткой ошибкой из Gmail сегодня утром:
Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of www-data@mx1.xxx.com designates xxx.xxx.xxx.xxx as permitted sender) smtp.mail=www-data@mx1.xxx.com; dkim=hardfail header.i=@xxx.com
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xxx.com; s=mta;
h=Date:Content-Type:Content-Transfer-Encoding:MIME-Version:To:Message-ID:References:In-Reply-To:Reply-To:From:Subject; bh=GDIpYEyFTXB3RPUtFDKxW+iBpkOYngdUELnMw316Ohk=;
b=A6iZYrFUZ68gszu/KeTyMoUUE0jbGlZ+yxcz72gq7Bdxe+jAkcgFoExN+duxLPIZqJm87Gz+XCB9IwnQbKC5lsVKK8cwUzQTHZx6E8ZPyynkv0NvC8MStDgOswFnjdcy;
Как видите, заголовки RT не включаются в подпись DKIM. Когда письмо отправляется с сайта за пределами RT, Gmail правильно проверяет подпись.
Насколько я понимаю, "пользовательские" заголовки (X-xxxxxxxx) игнорируются DKIM, а другие нет, например RT-Ticket, Managed-by и RT-Originator выше.
Есть ли у кого-нибудь подробный опыт работы с этим или знает, где я могу найти DKIM для включения этих заголовков в подпись? Я немного перерыл поддержку RT и не нашел много. Я использую exim в качестве MTA, а система - Debian Lenny.
изменить: я могу лаять здесь неправильное дерево с полями заголовка, я не уверен. Я изменил конфигурацию exim, чтобы явно указать ему, какие заголовки смотреть, взяв список заголовков из RFC4871 (http://tools.ietf.org/html/rfc4871) и добавляя дополнительные заголовки, которые RT добавляет, например:
dkim_sign_headers = From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:Precedence:X-RT-Loop-Prevention:RT-Ticket:Managed-by:RT-Originator:X-RT-Original-Encoding
Это привело к тому, что все заголовки RT были правильно добавлены к подписи, однако Gmail по-прежнему сообщал об отказе подписи, когда она пришла через RT. Насколько я могу судить, RT использует exim так же, как и любую другую внешнюю программу, поэтому я затрудняюсь объяснить, почему эти сообщения не работают.
Я столкнулся с аналогичной проблемой, и я считаю, что это вызвано тем, что RT включил заголовок In-Reply-To, но не добавил значение. Это происходило только при открытии тикетов в веб-интерфейсе, а не при получении электронного письма.
Я вставил строку
dkim_sign_headers = from:sender:reply-to:subject:date:message-id:to:cc:mime-version:content-type:content-transfer:encoding:x-rt-ticket:x-rt-loop-prevention:x-rt-originator
и это, похоже, решило проблему. Я могу поиграться с заголовками, которые будут подписаны, но опустить заголовок «in-reply-to».
Exim все еще подписывается в расслабленном режиме.
Собираюсь опубликовать здесь полуответ на случай, если кто-нибудь когда-нибудь столкнется с подобной проблемой и найдет ее с помощью поиска.
Я не смог решить эту проблему при использовании ослабленной канонизации заголовка для подписи DKIM в exim. Я взял примеры сообщений, которые были сгенерированы моим RT и чьи подписи не работали как в Gmail, так и в почте Yahoo, а затем протестировал их следующим образом:
Я использовал PHP для реализации алгоритма подписи DKIM, как указано в документации (http://www.dkim.org/specs/rfc4871-dkimbase.html). Когда я пропустил свое сообщение в расслабленном / расслабленном режиме, я произвел тот же хэш тела, но другую подпись сообщения, чем создавал мой exim.
Я использовал PHP для реализации алгоритма проверки DKIM, затем взял источник сообщений, полученный Gmail и Yahoo Mail, и прогнал его, получив идентичные результаты. Я также просматривал сообщения, в которых не были сгенерированы моим трекером запросов, но прошли через мой exim, и они были правильно пройдены в моем проверочном тесте, как и в Gmail и Yahoo Mail (целью этого было доказать, что мои ключи и другая конфигурация работают должным образом вне контекста RT, какими они кажутся).
На этом этапе я понял, что есть ошибка или неправильная конфигурация в способе, которым мой exim обрабатывает подписку DKIM в расслабленном / расслабленном состоянии. Я загрузил исходный код библиотеки PDKIM, которую использует exim ([https://github.com/duncanthrax/pdkim]), скомпилировал его, а затем изменил примеры тестирования, чтобы они соответствовали моим ключам, настройкам и тестовым сообщениям. После запуска тестов я получил те же результаты, что и моя реализация PHP: те же хеши, те же подписи.
Это оставило меня с одним последним вариантом, который заключался в том, чтобы возиться с источником exim, чтобы попытаться определить, какой конкретный сценарий вызывает изменение подписи сообщения. Однако я как бы достиг своего предела в том, сколько времени я хотел бы потратить на это.
Простым решением было вернуть мою конфигурацию exim к простой канонизации, в результате чего Gmail и Yahoo Mail передавали проверку dkim для сообщений, сгенерированных моим отслеживателем запросов. Не то, что я хотел, но пока достаточно.