Невозможно проверить хеш тела для DKIM - PullRequest
2 голосов
/ 23 апреля 2010

Я пишу валидатор C # DKIM и столкнулся с проблемой, которую не могу решить. Сейчас я работаю над вычислением хэша тела, как описано в Раздел 3.7 Вычисление хэшей сообщения . Я работаю с электронными сообщениями, которые я отправил с помощью измененной версии образца EdgeTransportAsyncLogging в SDK транспортного агента Exchange 2010. Вместо преобразования электронных писем при сохранении, он просто открывает файл на основе MessageID и выгружает необработанные данные на диск.

Я могу успешно вычислить хэш тела образца электронного письма, предоставленного в Раздел A.2 , используя следующий код:

SHA256Managed hasher = new SHA256Managed();
ASCIIEncoding asciiEncoding = new ASCIIEncoding();
string rawFullMessage = File.ReadAllText(@"C:\Repositories\Sample-A.2.txt");
string headerDelimiter = "\r\n\r\n";
int headerEnd = rawFullMessage.IndexOf(headerDelimiter);
string header = rawFullMessage.Substring(0, headerEnd);
string body = rawFullMessage.Substring(headerEnd + headerDelimiter.Length);
byte[] bodyBytes = asciiEncoding.GetBytes(body);
byte[] bodyHash = hasher.ComputeHash(bodyBytes);
string bodyBase64 = Convert.ToBase64String(bodyHash);
string expectedBase64 = "2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=";
Console.WriteLine("Expected hash: {1}{0}Computed hash: {2}{0}Are equal: {3}",
  Environment.NewLine, expectedBase64, bodyBase64, expectedBase64 == bodyBase64);

Выходные данные из вышеприведенного кода:

Expected hash: 2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=
Computed hash: 2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=
Are equal: True

Теперь большинство писем сталкиваются с настройкой c=relaxed/relaxed, которая требует от вас некоторой работы над телом и заголовком перед хэшированием и проверкой. И в то время как я работал над этим (не в состоянии заставить его работать), я наконец-то наткнулся на сообщение с c=simple/simple, которое означает, что вы обрабатываете все тело как минус любой пустой CRLF в конце тела. (Действительно, правила канонизации тела довольно ... простые .)

Вот реальная электронная почта DKIM (щелкните правой кнопкой мыши и сохраните ее, браузеры съедят окончание CRLF) с подписью, используя простой алгоритм (полностью без изменений). Теперь, используя приведенный выше код и обновляя хэш expectedBase64, я получаю следующие результаты:

Expected hash: VnGg12/s7xH3BraeN5LiiN+I2Ul/db5/jZYYgt4wEIw=
Computed hash: ISNNtgnFZxmW6iuey/3Qql5u6nflKPTke4sMXWMxNUw=
Are equal: False

Ожидаемый хеш - значение из поля bh= заголовка DKIM-Signature. Теперь файл, используемый во втором тесте, является прямым необработанным выводом от транспортного агента Exchange 2010. Если это так, вы можете просмотреть измененный EdgeTransportLogging.txt .

На данный момент, независимо от того, как я изменяю второе электронное письмо, изменяя начальную позицию или номер CRLF в конце файла, я не могу получить файлы для сопоставления. Что меня беспокоит, так это то, что я до сих пор не смог проверить любой хеш-код тела (простой или упрощенный) и что может быть неосуществимо обрабатывать DKIM через Exchange 2010.

1 Ответ

1 голос
/ 01 июня 2010

Я попытался сделать это в python-dkim, и у меня тоже получилось несоответствие хэша тела.

Я думаю, что, вероятно, Exchange 100 * *GetMimeReadStream не дает вам фактические байты, которые были переданыпоэтому хеш не совпадает.Возможно, он разбирает сообщение на части mime, а затем GetMimeReadStream дает правильное представление сообщения, но не того, с которым оно было отправлено изначально.

Возможно, существует другой API, который будетдать вам реальные необработанные байты?

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

Возможно, выпопробуйте перехватить сообщение, подписанное DKIM, отправив его на сервер, отличный от Exchange, и посмотрите, работает ли это с вашим кодом.GetContentReadStream может сработать?

В любом случае, что бы я сделал дальше, попытался найти API, который дает вам побайтное, что было отправлено.

...