Сегодня речь пойдет о своего рода электронной подписи в сообщениях электронной почте, а именно о DKIM подписи. Мои читатели, возможно, уже знают о том, что такое электронная подпись и о том, как она работает, поэтому людям знакомым с этой технологией будет проще разобраться в сегодняшней теме. Итак, пожалуй начнем.
DKIM подпись, как следует из аббревиатуры DomainKeys Identified Mail, это метод e-mail аутентификации, основанный на инфраструктуре открытых ключей, подобно квалифицированной электронной подписи, суть которого заключается в подписании хэш-функции заголовков отправляемого сообщения электронной почты закрытым ключом. Однако, в данном случае подписантом выступает не лицо, отправляющее сообщение, а сам почтовый сервер, открытый ключ которого хранится в специальной TXT-записи зоны DNS. Это позволяет получателю сообщения удостовериться в том, что полученное сообщение действительно отправлено тем сервером, который ответственен за домен отправителя. Именно по этой причине для каждого обслуживаемого домена электронной почты должна существовать своя подпись DKIM, а еще лучше не просто для каждого домена, а вообще для каждого отправляющего почту сервера.
Идея заключается в том, что получатель сообщения электронной почты производит проверку DKIM подписи с использованием открытого ключа, хранящегося в DNS-зоне домена на ряду с другими записями, такими как SPF и MX, например. Аналогично уже описываемой мною электронной подписи, почтовый сервера получателя используя открытый ключ расшифровывает хранящийся в заголовке DKIM Signature сообщения хэш заголовков этого сообщения, сверяя его с вычисленным значением хэш-суммы заголовков полученного сообщения.
Важно отметить, что используется именно хэш-функция заголовков сообщения, а не все сообщение целиком. А к заголовкам, в частности, относится например поле MAIL FROM, указывающее на email-адрес отправителя. Что, как раз таки и нужно при защите от сообщений, отправляемых от имени какого-то конкретного домена.
На ниже представленном рисунке приведена блок-схема проверки (верификации) DKIM подписи сообщения:
Исходя из представленного алгоритма следует, что сообщение содержащее некорректную DKIM-подпись или вовсе не подписанное отклонялось сервером получателя, однако результат проверки подписи влияет на то, какая оценка вероятности спама будет присвоена сообщению. Однако, поведение сервера получателя, в зависимости от результатов проверки SPF записи домена и DKIM-подписи может определить и администратор почтового сервера отправителя разместив в своей DNS-зоне TXT-запись политики DMARC. Так, политика DMARC может определять поведение сервера при неудачной проверке SPF и (или) DKIM предлагая, в частности, сразу отклонить сообщение, либо продолжить его проверку.
Однако, на случай аварийных ситуаций или смены ключей DKIM, я бы все-таки посоветовал не настраивать в политике DMARC отклонение сообщения в случае ошибки при проверке подписи, равно как и при ее отсутствии. Надо иметь ввиду, что те же уведомления о доставке сообщения, отправляемые сервером получателя, могут оказаться и не подписанными, как это происходит, например на сервере MS Exchange Server с установленным транспортным агентом Exchange-DKIM Signer.
В тоже время стоит отметить, что не все почтовые системы на настоящий момент используют DKIM, в частности уведомления и рассылки от некоторых сервисов, например "Вконтакте" не содержат DKIM подписи.
Все это наводит меня на мысль о том, что вводить обязательную проверку подписи DKIM преждевременно, во всяком случае до тех пор, пока абсолютно все почтовые системы не начнут использовать подписание всех исходящих сообщений. А вот настроить подписание отправляемых с вашего почтового сервера сообщений стоит, ведь наличие DKIM подписи можно сейчас считать "правилом хорошего тона". Ибо администратору почтового сервера нужно думать не только о защите от спама, но и о том, чтобы избежать случаев потери сообщений, что неразрывно связано с работой средств защиты от спама. А вводя на своей стороне строгое требование DKIM, например, администратор фактически диктует свою волю другим, что на мой взгляд недопустимо.
Кстати, мне хотелось бы еще отметить основываясь на собственном опыте и тот факт, что злоумышленники зачастую не могут обойти и проверку SPF, по причине того что для обхода корректных записей, не содержащих уязвимостей, нужно использовать такие сложные техники, как подмена IP адреса. И этим можно и нужно пользоваться в борьбе со спамом и фишингом. На мой взгляд, к доменам, содержащим в своих SPF записях квалификатор "~" нужно относиться с особым вниманием, ведь это оставляет возможность для рассылки спама от имени этого домена. Поэтому я бы очень хотел призвать всех администраторов почтовых систем проверить свои SPF записи, избавиться от неактуальных CNAME записей, а также от квалификаторов "~" в SPF.