Интерпретация DMARC в разрезе DKIM
Технологии DKIM и DMARC предназначены для управления политиками доставки электронной почты, но подходят к этой задаче с разных сторон. DKIM (DomainKeys Identified Mail) – позволяет сопроводить сообщение электронной почты некоторым доказательством, что отправляющий сервер имеет отношение к домену, который указан в качестве источника сообщения, что этот сервер знает некоторый секретный ключ. Для предоставления доказательств используется цифровая подпись и публикация в DNS соответствующих открытых ключей для проверки подписи. Нужно учитывать, что это “техническая” подпись: она может, косвенно, подтверждать подлинность сервера-источника сообщения, целостность каких-то технических элементов сообщения (в том числе, целостность полезного содержания), однако используется в контексте серверов, то есть, это не подтверждение для конкретного адреса отправителя или пользователя почтовой системы.
DKIM предложили в целях борьбы с нежелательной рассылкой сообщений, когда почтовый адрес отправителя подделывается (в e-mail не предусмотрено защиты от этого). Сейчас почтовый сервер без DKIM для отправляемых сообщений держать не принято – могут быть проблемы с доставкой, некоторые серверы на стороне получателя автоматически классифицируют входящие сообщения без DKIM как спам.
Логика работы DKIM такая: отправляющий сервер, используя секретный ключ, вычисляет подпись для некоторых технических элементов, составляющих сообщение электронной почты, встраивает значение подписи и вспомогательные сведения в состав сообщения (в так называемый “технический конверт”, который не виден для обычных пользователей), отправляет получившееся сообщение. Принимающий (или промежуточный) почтовый сервер, получив письмо, может использовать данные, переданные в DKIM-параметрах, для извлечения из DNS открытого ключа и, собственно, проверки подписи на сообщении. Если сообщение было отправлено сервером, который не имел доступа к нужному ключу, то этот сервер не может вычислить корректную подпись DKIM. В общем-то – всё. Именная принадлежность ключей и других параметров определяется на основании домена-источника. В самом простом случае – это домен почтового адреса, указанного в качестве отправителя письма. Тут, впрочем, есть технические тонкости, опять же, невидимые для типичного пользователя, но их сейчас можно пропустить: будем считать, что если в письме нужным способом указан адрес отправителя user@test.ru, то домен-источник – test.ru, для него и публикуются ключи в DNS (они публикуются в TXT-записях для специального имени-селектора).
Заметьте, что наличие или отсутствие DKIM не вводит каких-то технических обязательств на принимающей стороне: технически, DKIM – это дополнительные поля (заголовки) в не менее техническом конверте, сообщение всё равно приходит на принимающий сервер обычным способом, а этот принимающий сервер прекрасно может игнорировать заголовки DKIM. То есть, включение DKIM вовсе не влияет на базовые механизмы доставки почты, это протокол уровня политик, в его работе всё зависит от настроек, используемых сторонами.
Для того, чтобы администратор почтового домена мог типовым машиночитаемым способом опубликовать рекомендации по обработке поступающих сообщений другими серверами – придумана спецификация DMARC (Domain-based Message Authentication, Reporting, and Conformance). Опять же, это спецификация, описывающая способы публикации политик обработки почты, формат записи и принципы интерпретации. DMARC – это текстовая строка определённого формата, опубликованная в TXT-записи. DMARC предназначается для использования вместе с DKIM и SPF (Sender Policy Framework – здесь не рассматривается). Но, каким бы странным это ни показалось: публикация DMARC никак не зависит от DKIM, и наоборот. Внедрение DKIM на сервере-отправителе, отправка сообщений с DKIM – возможны без публикации DMARC, а публикация DMARC и эффективное использование – возможны без соответствующего по именам внедрения DKIM (пример – см. ниже). Естественно, DMARC и DKIM рекомендуется применять вместе: если вы настроили DKIM, то очень неплохо будет опубликовать и сведения политики в DMARC, поскольку эти сведения могут подсказать принимающему серверу, что ему делать с полученными из вашего домена письмами. Тем не менее, проверка DKIM не требует извлечения сведений DMARC. А DMARC может применяться без фактической поддержки DKIM.
Пример, хорошо иллюстрирующий ситуацию: администратор домена не планирует использовать этот домен в качестве почтового, поэтому требуется устроить так, чтобы принимающие серверы, поддерживающие DMARC (важная оговорка!), отбрасывали все сообщения с адресами из данного домена. В таком случае, администратор просто публикует строгую политику обработки DMARC (“reject”), но вовсе не размещает в DNS ключи DKIM и даже не настраивает почтовый сервер. То есть, администратор домена не предполагает отправки сообщений с адресами в этом домене, а такая конфигурация DMARC означает, что если какой-то другой сервер отправит такое сообщение, то оно может быть отброшено на принимающей стороне.
Ключевым моментом эффективности DMARC является не состав политики, а то, поддерживается ли DMARC принимающим сервером, а если поддерживается, то как именно. Сама по себе публикация сведений DMARC не обязывает принимающий сервер не только следовать опубликованным политикам, но даже и запрашивать их из DNS: для приёма и обработки сообщений это не требуется (как не требуется и возможность обработки DKIM). Конечно, грамотно настроенный сервер должен обрабатывать и DKIM, и DMARC, однако такая настройка вовсе не обязательно означает, что письмо без DKIM будет молчаливо отброшено, если принимающий сервер обнаружит политику reject в DMARC. Другими словами: DMARC носит более чем рекомендательный характер, поэтому целиком полагаться на указание политики обработки нельзя.
Адрес записки: https://dxdt.ru/2023/05/30/10203/
Похожие записки:
- TLS: выбор сертификата по УЦ в зависимости от браузера
- Скорость из OBD и программы-навигаторы
- Реплика: уточнение о языках программирования
- "Почти что коллизия" и хеш-функции
- Агенты ИИ, действующие через скриншоты
- Подмена хостнейма WHOIS-сервиса .MOBI
- Реплика: интернет-названия
- Срок действия сертификатов и компрометация ключей
- Encrypted Client Hello и браузеры Google
- Автомобили-роботы из "обязательной" сети такси
- TLS для DevOps
Написать комментарий