ОРИГИНАЛЬНАЯ СТАТЬЯ
ПЕРЕВЕДЕНО СПЕЦИАЛЬНО ДЛЯ xss.pro
$600 на SSD для Jolah Milovski ---> 0x5B1f2Ac9cF5616D9d7F1819d1519912e85eb5C09 для поднятия ноды ETHEREUM и тестов
DMARC может предотвратить попадание поддельного спама и фишинга к вам и вашим клиентам, защищая вашу информационную безопасность и ваш бренд. Однако сложность и заблуждения удерживают многие организации от его развертывания. Отчасти развенчание мифов, отчасти руководство по внедрению, в этом посте объясняются недостатки SPF и DKIM, что такое DMARC, как правильно развертывать DMARC и как реагировать на отчеты DMARC — и все это без необходимости в дополнительном поставщике , благодаря программному обеспечению с открытым исходным кодом!
Современная проверка подлинности электронной почты основана на сочетании трех стандартов: SPF, DKIM и DMARC. Эти стандарты помогают гарантировать, что сообщение пришло с сервера, связанного с владельцем домена, и не было подделано.
Структура политики отправителей (SPF)
SPF был первым широко принятым стандартом для борьбы с спуфингом электронной почты. Несмотря на его ограничения в предотвращении спуфинга, большинство получателей электронной почты ожидают, что вы развернете его в своем домене. Например, Gmail/G-Site/Google будут блокировать входящие электронные письма с доменов, не имеющих действительной записи SPF.
Как работает SPF
SPF определен в RFC 7208. Он работает, проверяя специально отформатированную DNS-запись TXT в домене заголовка почты в транзакции SMTP. Эта запись SPF описывает, какие серверы авторизованы для отправки в качестве этого домена, используя механизмы для определения авторизованных IP-адресов и имен хостов или даже включая записи SPF других доменов.
Каждая запись SPF — это запись TXT в корне домена или поддомена, начинающаяся с v=spf1. От этого и пляшут механизмы разрешающие и запрещяющие отправлять электронную почту в качестве этого домена или поддомена. Домен или субдомен может иметь только одну запись SPF, но каждый субдомен может иметь свою собственную запись SPF. Некоторые механизмы, такие как a, mx, include и redirect, используют для работы дополнительные запросы DNS. SPF имеет максимальное ограничение поиска DNS, равное 10, включая любые включенные записи. Любая запись SPF, для разрешения которой требуется более 10 DNS-запросов, недействительна! Это распространенная ошибка при развертывании SPF. Чтобы обойти это ограничение, отправляйте электронную почту с разных поддоменов. Каждому поддомену нужна своя запись SPF и свой набор ограничений для этой записи. Например, вы можете отправлять информационные бюллетени с сайта news.example.com и счета с сайта billing.example.com.
В любом случае вам может даже не понадобиться включать каждого поставщика в свои записи SPF. Если поставщик поддерживает подпись DKIM, вы можете положиться на нее для прохождения DMARC, даже если отправитель не указан в вашей записи SPF. Просто убедитесь, что вы используете ~all в своей записи SPF .
| Механизм | Описание | ||||
|---|---|---|---|---|---|
| ip4 | Описывает адрес ipv4 или блок адресов CIDR. | ||||
| ip6 | Описывает адрес ipv6 или блок адресов. | ||||
| МХ | Описывает серверы, перечисленные в mx-записи домена. Учитывается ограничение на поиск DNS.
| ||||
| а | Описывает серверы, перечисленные в записях A и/или AAAA домена. Учитывается ограничение на поиск DNS.
| ||||
| включают | Включает запись SPF из домена после двоеточия (не включает модификатор all, если он есть) Учитывается ограничение на поиск DNS. | ||||
| перенаправить | Прекращает обработку записи SPF и продолжает обработку записи SPF указанного домена (включая модификатор all!) Учитывается ограничение на поиск DNS. | ||||
| существуют | Этот механизм используется для создания произвольного доменного имени, используется для запроса записи DNS A. Позволяет создавать сложные схемы. с участием произвольных частей почтового конверта, чтобы определить, что разрешенный. Учитывается ограничение на поиск DNS. существует = «существует» «:» спецификация домена <domain-spec> расширяется . Полученное доменное имя используется для поиска DNS A RR (даже если тип соединения IPv6). Если какая-либо запись A возвращается, этот механизм соответствует. Домены могут использовать этот механизм для указания произвольно сложных запросов. Например, предположим, что example.com публикует запись: v=spf1 существует:%{ir}.%{l1r+-}._spf.%{d} -все <target-name> может расширяться до «1.2.0.192.someuser._spf.example.com». Это делает мелкозернистым решения возможны на уровне пользователя и IP-адреса клиента. |
Механизмы, перечисленные в записи SPF, имеют перед собой квалификатор неявного прохода (т. е. +). Возможные квалификаторы:
| Модификатор | Имя | Описание |
|---|---|---|
| + | проходить | Результат «прошел» означает, что клиент имеет право вводить почту с данным идентификатором. Домен теперь может в смысле репутации считаться ответственным за отправку сообщения. Дальнейшие проверки политик теперь могут выполняться с уверенностью в законном использовании удостоверения. |
| ? | нейтральный | «Нейтральный» результат указывает на то, что хотя политика для идентификации была обнаружена, нет определенного утверждения (положительного или отрицательного) о клиенте. «Нейтральный» результат ДОЛЖЕН рассматриваться точно так же, как и результат «нет»; различие существует только для информационных целей. Более жесткое обращение с «нейтральным», чем с «отсутствием», отпугнуло бы администраторов домена от тестирования использования записей SPF. При результате «нет» верификатор SPF вообще не имеет информации о разрешении или отсутствии такового у клиента на использование проверенного удостоверения или удостоверений. Функция check_host() завершилась без ошибок, но не смогла сделать никаких выводов. |
| ~ | софтфейл | Результат «softfail» следует рассматривать как нечто среднее между «fail» и «нейтральный»/«none». Менеджер домена считает, что хост не авторизован, но не желает делать строгое заявление о политике. Программному обеспечению-получателю НЕ СЛЕДУЕТ отклонять сообщение только на основании этого результата, но МОЖЕТ подвергать сообщение более тщательной проверке, чем обычно. |
| – | потерпеть неудачу | Результат «сбой» — это явное заявление о том, что клиент не авторизован для использования домена с данным идентификатором. Удаление сообщений об ошибках SPF определяется локальной политикой. |
Большинство записей SPF (за исключением тех, которые предназначены для включения в другие записи SPF) заканчиваются модификатором all. Модификатор all состоит из слова all с квалификатором перед ним. Модификатор all указывает, как следует обрабатывать электронные письма, которые не соответствуют ни одному из перечисленных механизмов.
Слабость SPF: полагаться на заголовки SMTP
Это распространенное заблуждение, что SPF предотвращает спуфинг электронной почты. В лучшем случае это немного усложняет задачу злоумышленнику.
Помните, что SPF проверяет запись SPF в домене в заголовке mail from в транзакции SMTP (также известном как конверт from), а не в заголовке сообщения from, который видит принимающий почтовый клиент. Транзакция SMTP не видна до конца client, даже при просмотре заголовков сообщений.
Это означает, что злоумышленник может использовать заголовки SMTP, чтобы направить почтовый сервер цели на проверку домена, контролируемого злоумышленником, который содержит механизм авторизации для почтового сервера, который использует злоумышленник, при этом подделывая совершенно другой домен, чтобы цель могла видеть в нем. сообщение из шапки!
На приведенном ниже примере снимка экрана telnet злоумышленник может заставить принимающий почтовый сервер проверить SPF-запись домена, который контролирует злоумышленник (например, infosecspeakeasy.org), при этом подделывая собственный домен цели (например, cincykitchenandbath.com) в сообщение из заголовка, который является адресом отправителя, который увидит целевой пользователь.
Такого рода несоответствие домена возникает вполне законно, когда правило почтового ящика пересылает сообщение из другого домена. Сообщение от домена останется прежним, но заголовок SMTP mail from будет содержать домен пересылающего почтового сервера.
Подписи DKIM, с другой стороны, являются частью заголовков сообщений и сохраняются при пересылке сообщений. Поэтому выравнивание DKIM гораздо важнее, чем выравнивание SPF.
Примеры записей SPF
Как только вы точно узнаете, какие почтовые службы законно отправляют в качестве домена (отчеты DMARC сообщат вам об этом), соответствующим образом обновите запись SPF и измените модификатор ?all на -all.
Запись SPF для доменов, которые отправляют электронные письма со своих входящих шлюзов и для которых отсутствуют записи SPF.
Код:
v=spf1 mx ?allЭта запись явно авторизовала любые серверы, перечисленные в записи MX домена, при этом все остальные рассматривались как нейтральные. Это хорошая временная запись SPF для новых доменов или недавно приобретенных доменов, у которых еще нет записи SPF.
Вот несколько хороших примеров записей SPF для распространенных провайдеров облачной электронной почты:
Офис 365
Код:
v=spf1 includeвключает:spf.protection.outlook.com?allG-люкс
Код:
v=spf1 includeвключает:_spf.google.com ?allProofpoint Essentials
Код:
[CODE]v=spf1 a:dispatch-us.ppe-hosted.com a:dispatch-eu.ppe-hosted.com ?allЗапись SPF для доменов, которые не отправляют электронную почту
Код:
v=spf1 -allВ этой записи явно указано, что никакие почтовые серверы не имеют права отправлять электронную почту от имени этого домена.
Это должно быть добавлено ко всем доменам, которые не отправляют электронную почту, вызывая припаркованные домены.
Идентифицированная почта DomainKeys (DKIM)
DomainKeys Identified Mail (DKIM) — это стандарт аутентификации сообщений электронной почты, определенный в RFC 6376 . Поскольку DKIM аутентифицирует заголовки сообщений, а не заголовки SMTP, аутентификация DKIM остается неизменной при прямой пересылке сообщения (например, с помощью правила почтового ящика).
Заголовки сообщений DKIM
Код:
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=s1; c=relaxed/simple; l=1234; t=1117574938; x=1118006938; h=from:to:subject:date; bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=;b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZVoG4ZHRNiYzRОбязательные теги
| Tag | Значение |
|---|---|
| v | Версия подписи |
| a | Алгоритм подписи (следует использовать rsa-sha256) |
| d | Домен, в котором можно найти открытый ключ |
| s | Селектор, указывающий на открытый ключ в домене (произвольная строка) |
| h | Список заголовков, разделенных двоеточием, для объединения при проверке подписи заголовка. |
| b | Хэш подписи в кодировке base64 для заголовков, перечисленных в теге h. |
| bh | Хэш подписи тела сообщения в кодировке base64 |
Необязательные теги
| Tag | Значение |
|---|---|
| т | Отметка времени подписи в формате отметки времени UNIX (т. е. количество секунд с 00:00:00 1 января 1970 г. в часовом поясе UTC) |
| x | Отметка времени истечения срока действия подписи в формате отметки времени UNIX (т. е. количество секунд с 00:00:00 1 января 1970 г. в часовом поясе UTC) |
| с | Алгоритм канонизации: определяет, должен ли и каким образом принимающий почтовый сервер нормализовать сообщение, чтобы учесть небольшие различия в пробелах и разрывах строк, которые в противном случае могут сделать подпись недействительной. Настоятельно рекомендуется расслабленный режим для канонизации заголовков и тела (т. е. c=расслабленный/расслабленный). |
| i | Идентификация / пользовательский агент подписавшего |
| l | Количество символов от начала тела, используемое при расчете подписи тела ( не рекомендуется, поскольку кто-то может добавить вредоносное содержимое ) |
| С | Не четко определен |
Принимающий почтовый сервер использует теги selector (s=) и domain (d=) для поиска открытого ключа в виде записи DNS TXT по адресу
Код:
<селектор/s=>._domainkey.<домен/d=>В приведенном выше примере подписи принимающий сервер будет искать ключ DKIM по адресу:
Код:
TXT s1._domainkey.example.comЗаписи открытого ключа DKIM
Записи открытого ключа DKIM имеют следующий формат:
Код:
v=DKIM1; k=rsa; p=<public key>;Строки в записях DNS TXT усекаются до 256 символов. Если запись длиннее, она должна быть разделена на отдельные строки в той же записи, чтобы быть действительной.
Записи открытого ключа DKIM можно проверить на синтаксис с помощью инструмента поиска записей DKIM на MX Toolbox.
Рекомендуемые теги
| Tag | Значение |
| v | Согласно RFC, этот тег рекомендуется, но не обязателен, с неявным значением по умолчанию DKIM1. Однако на практике некоторые получатели не полностью следуют RFC и требуют, чтобы этот тег использовался в любом случае. Это должен быть первый тег, если он используется. Записи открытого ключа DKIM должны начинаться с v=DKIM1; |
| n | Примечания: удобочитаемые примечания для администраторов, просматривающих записи DNS. Полезно для того, чтобы отметить, какая служба использует селектор и ключ. |
Обязательные теги
| Tag | Значение |
| p | Данные открытого ключа закодированы в base64. Ключи должны иметь длину не менее 1024 байт. Настоятельно рекомендуется длина 2048 бит. |
Необязательные теги
| Tag | Значение | ||||||
| k | Тип ключа: по умолчанию rsa. Нераспознанные типы ключей следует игнорировать. | ||||||
| h | Приемлемые алгоритмы хэширования: Список алгоритмов хеширования, разделенных двоеточиями, которые могут использоваться. По умолчанию разрешены все алгоритмы. Нераспознанные алгоритмы следует игнорировать. Обратитесь к Разделу 3.3 для обсуждения алгоритмов хеширования, реализованных подписывающими сторонами и верификаторами. Набор алгоритмов, перечисленных в этом теге в каждой записи, является операционным выбором подписывающей стороны. | ||||||
| с | Тип службы: по умолчанию * Разделенный двоеточиями список типов услуг, к которым относится эта запись. Верификаторы для данного типа службы должны игнорировать эту запись, если соответствующий тип не указан в списке. Нераспознанные типы служб следует игнорировать. Этот тег предназначен для ограничения использования ключей для других целей, если использование DKIM будет определено другими службами в будущем. В настоящее время определены следующие типы услуг:
| ||||||
| t | Флаги: список флагов, разделенных двоеточиями. По умолчанию нет флагов
|
Примечания в записях ключей DKIM
Селектор DKIM (субдомен) выбирается поставщиком и часто не является описательным. Вы можете использовать произвольную строку в теге n (т.е. notes) в записи DKIM, чтобы отметить имя поставщика, чтобы вы знали, какой ключ DKIM используется каким поставщиком, когда вы проверяете свои записи DNS.Например, если «matketingco» попросил вас опубликовать следующую запись DKIM TXT
Код:
randomselector._domainkey.example.com TXT "p=base64Key"Вместо этого вы должны создать запись следующим образом:
Код:
randomselector._domainkey.example.com TXT "v=DKIM1; n=marketingco; k=rsa; p=base64Key"Ротация ключей DKIM
Обычно рекомендуется менять ключи DKIM один раз в месяц или, по крайней мере, после того, как вы подозреваете, что закрытый ключ DKIM был скомпрометирован. Большинство почтовых/маркетинговых сервисов будут выполнять смену ключей для вас, когда вы настраиваете свои домены для DKIM, но некоторые почти никогда не меняют свои ключи.
В отличие от веб-сертификатов и сертификатов электронной почты, домен/адрес электронной почты не являются частью PKI. DKIM не использует сертификаты. Домен указан в теге заголовка d=. Поэтому вам не нужна отдельная пара открытого/закрытого ключа для каждого домена.
Вы должны создать две пары ключей и хранить открытые ключи под двумя разными селекторами, например:
Код:
s1._domainkey.example.com TXT "v=DKIM1; k=rsa; p=<public key>;"
s2._domainkey.example.com TXT "v=DKIM1; k=rsa; p=<a different public key>;"С записями CNAME другие ваши домены могут использовать те же селекторы и ключи:
Код:
s1._domainkey.example.net CNAME s1._domainkey.example.com.
s2._domainkey.example.net CNAME s2._domainkey.example.com.Сторонние службы часто заставляют вас авторизовать их ключи DKIM на ваших доменах с помощью записей CNAME, а затем проверяют существование этих записей перед подписанием электронной почты, чтобы они могли обрабатывать изменения ключей для вас. Если вы используете свои собственные ключи, вы должны управлять ими, желательно в автоматическом режиме. Начните с подписи всех ваших электронных писем с помощью первого селектора. Когда придет время сменить ключи, подпишите всю исходящую электронную почту, используя сектор s2. После недели неиспользования ключа на селекторе s1 замените ключ на селекторе s1. Когда придет время снова сменить ключи, начните использовать исключительно селектор s1, подождите неделю, затем замените ключ на селекторе s2 новым ключом, чтобы он был готов к следующей ротации. Если известно, что ключ не был скомпрометирован, важно подождать неделю (т. е. 7 дней), прежде чем заменять его, так как некоторые принимающие почтовые серверы будут кэшировать открытый ключ в заданном селекторе на срок до недели.
Используя эту схему ротации ключей пинг-понга, вы гарантируете, что электронная почта всегда будет подписана действительным безопасным ключом.
- Начать эксклюзивную подпись с другим селектором
- Подождите 7 дней
- Замените ключ на старом селекторе, чтобы он был готов к следующему вращению.
- Перейти к шагу 1
Слабость DKIM: произвольные значения d= values
Без DMARC значение d= в заголовке подписи DKIM не обязательно должно соответствовать тому же домену, который пользователь видит в заголовке From сообщения. Злоумышленник может поместить действующий заголовок подписи DKIM в электронное письмо со значением ad=, которое указывает на домен, контролируемый злоумышленником, позволяя пройти DKIM, продолжая подделывать адрес пользователя.
Аутентификация, отчетность и соответствие сообщений на основе домена (DMARC)
Аутентификация, отчетность и соответствие сообщений на основе домена (DMARC) определены в RFC 7489 . DMARC гарантирует, что механизмы аутентификации SPF и DKIM действительно аутентифицируются в том же базовом домене, который видит конечный пользователь. Чтобы быть полезной, DNS-запись DMARC должна быть опубликована владельцем домена, и получатели электронной почты должны соблюдать эту запись, включая ее политику принудительного применения, и, по крайней мере, отправлять сводные отчеты по запросу владельца домена.
Сообщение проходит проверку DMARC, передавая DKIM или SPF, если соответствующие индикаторы также совпадают с адресом отправителя сообщения .
| DKIM | SPF | |
|---|---|---|
| Passing | Подпись в заголовке DKIM проверяется с помощью открытого ключа, который публикуется в виде DNS-записи доменного имени, указанного в подписи. | IP-адрес почтового сервера указан в SPF-записи домена в заголовке SMTP-конверта mail from. |
| Alignment | Домен подписи совпадает с базовым доменом в заголовке сообщения from. | Домен в заголовке письма из конверта SMTP совпадает с базовым доменом в заголовке сообщения из. |
Согласование DKIM важнее, чем SPF, потому что только DKIM остается когда сообщение пересылается через правило почтового ящика.
Отчеты DMARC
DMARC имеет два типа отчетов: совокупный и криминалистический. получатели электронной почты, соблюдающие DMARC, отправляют эти отчеты обратно владельцам доменов в электронных письмах, отправленных на адреса, указанные в записи DMARC домена. Эти отчеты содержат очень полезную информацию для отладки выравнивания сообщений и выявления вредоносных кампаний по спуфингу.
| Тип отчета | Описание |
|---|---|
| Aggregate (rua) | Сжатые XML-файлы, отправляемые доменами-получателями не реже одного раза в день на URI, указанные в теге DMARC rua. Записывает количество сообщений, отправленных с IP-адреса, а также статус SPF и DKIM. Эти отчеты отправляются независимо от успеха или неудачи, поэтому владельцы доменов иметь представление обо всей почтовой аутентификации сообщений, кажущихся отправленными из их домена |
| Failure/Forensic (ruf | Электронное письмо с прикрепленным письмом, не прошедшим проверку DMARC (формат RFC 822/.eml), отправленным на URI, указанные в теге DMARC ruf. Это может быть очень полезно для устранения неполадок DMARC и расследований фишинга. Однако большинство получателей электронной почты не отправляют аналитические отчеты или могут предоставлять только заголовки сообщений из соображений конфиденциальности. |
Политики DMARC
DMARC требует, чтобы владельцы доменов установили тег политики (p=) в своей записи DMARC. Эта политика сообщает получателям, как они должны реагировать на электронное письмо, которое, как представляется, пришло из этого домена на основе сообщения из заголовка, но не проходит выравнивание DMARC.| Политика | Описание |
|---|---|
| none | Владелец домена просит не предпринимать никаких конкретных действий в отношении доставки сообщений. Используйте это в первую очередь, чтобы убедиться, что ваши сообщения соответствуют требованиям DMARC, прежде чем переключаться на карантин или отклонять. |
| quarantine | Владелец домена хочет, чтобы электронная почта, не прошедшая проверку механизма DMARC, рассматривалась получателями почты как подозрительная. В зависимости от возможностей Mail Receiver это может означать «поместить в папку со спамом», «проверить с дополнительной тщательностью» и/или «пометить как подозрительное». |
| reject | Владелец домена желает, чтобы получатели почты отклоняли электронную почту, не прошедшую проверку механизма DMARC. Отклонение ДОЛЖНО происходить во время транзакции SMTP. |
Даже если в домене для политики DMARC задано значение p=none, почтовые службы могут по-прежнему отображать предупреждения для своих пользователей в случае сбоя DMARC, как показано на этом снимке экрана действительного электронного письма от розничной кредитной службы, отображаемого в ProtonMail и Gmail.
Заголовки результатов аутентификации
Когда шлюз электронной почты оценивает SPF, DKIM и DMARC, он добавляет в электронное письмо заголовки Message-Authentication. Пользователи и администраторы могут использовать эти заголовки, чтобы определить, какие проверки прошли или не прошли и почему.
В приведенном выше примере почтовый сервер mail17i.protonmail.ch добавил к письму следующие заголовки:
Код:
Authentication-Results: mail17i.protonmail.ch; dmarc=fail (p=none dis=none) header.from=[redacted].com
Authentication-Results: mail17i.protonmail.ch; spf=pass smtp.mailfrom=noreply_[redacted]_portal=[redacted].com__0-28eb251z589s1s@zihu5s1p6odwjt9p.s3cycftqbacrhjk9.hf76qay.3-1ffzneao.na45.bnc.salesforce.com
Authentication-Results: mail17i.protonmail.ch; dkim=noneЗаголовки электронной почты добавляются и читаются снизу вверх.
Во-первых, сервер отмечает, что сообщение не было подписано DKIM.
Затем проверяется SPF со значением заголовка SMTP mail from noreply_[redacted]_portal=[redacted] .com__0-28eb251z589s1s@zihu5s1p6odwjt9p.s3cycftqbacrhjk9.hf76qay .3-1ffzneao.na45.bnc.salesforce.com, и SPF пройден. Был использован адрес salesforce.com, чтобы Salesforce могла отслеживать возвраты и избегать отправки на недействительные адреса электронной почты в будущем.
Наконец, проверяется DMARC, но это не удается, поскольку сообщение не подписано DKIM, а база SMTP-почты с домена, используемого SPF (salesforce.com), не соответствует базовому домену домена в сообщении из заголовка ([отредактировано] .com). dis=none (сокращение от message disposition) указывает, что сообщение все же было доставлено, так как почтовый сервер отметил, что [redacted].com имеет политику DMARC p=none.
Примечание. Если вы перенаправляете входящую электронную почту из одной службы шлюза в другую, например из IronPort в Office 365, к тому времени, когда электронная почта достигает почтового ящика пользователя, информация из Office 365 в заголовке Authentication-Results всегда будет показывать, что SPF и DMARC, так как IronPort авторизован для отправки в качестве ваших доменов, когда сообщения пересылаются в Office 365. Результаты исходной проверки IronPort, которая происходит до того, как сообщение достигает Office 365, сохраняются в заголовке Authentication-Results-Original.
Записи политики
Записи политики DMARC размещаются в записи TXT в субдомене _dmarc. Субдомены TLD/базового домена автоматически наследуют эту запись политики DMARC или могут иметь собственную запись в собственном поддомене _dmarc.
Вот пример записи политики DMARC
Код:
_dmarc.example.com TXT "v=DMARC1; p=none; street=mailto: dmarc@example.com ; ruf=mailto: dmarc@example.com "Обязательные теги
| Tag | Описание |
|---|---|
| v | Версия DMARCv=DMARC1 |
| п | политика DMARC |
Рекомендуемые теги
Эти теги сообщают получателям, куда и как отправлять отчеты.| Tag | Описание | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| rua | Разделенный запятыми список адресов mailto: для отправки сводных отчетов. | ||||||||||
| ruf | Разделенный запятыми список адресов mailto: для отправки судебных отчетов. Возможно, вы не захотите включать этот тег, если вы работаете в отрасли, которая отправляет конфиденциальную информацию, особенно если вы автоматически обрабатываете отчеты. Это может привести к тому, что конфиденциальные электронные письма будут сохранены в ELK или других областях хранения, если сообщения не пройдут проверку DMARC. Если получатель получает конфиденциальное электронное письмо, которое не соответствует требованиям DMARC, это электронное письмо может быть отправлено обратно в ваш почтовый ящик для отчетов и заархивировано в вашем инструменте обработки отчетов DMARC. | ||||||||||
| fo | По умолчанию 0 Предоставляет запрошенные параметры для создания отчетов об ошибках. Генераторы отчетов МОГУТ придерживаться запрошенных опций. Содержимое этого тега ДОЛЖНО игнорироваться, если также не указан тег «ruf». Значение этого тега представляет собой список символов, разделенных двоеточиями, которые указывают параметры сообщения об ошибках.
|
Получатели обязаны отправлять отчеты только на первые два адреса rua и ruf. Они могут не отправлять на какой-либо дополнительный адрес из списка.
Не рекомендуемые теги
| Tag | Описание |
|---|---|
| sp | Значение по умолчанию отражает значение тега p. Устанавливает политику для всех поддоменов. Установка этого тега может позволить спуфинг любого произвольного субдомена. Вместо этого добавьте отдельную запись политики для каждого поддомена по мере необходимости. |
| pct | По умолчанию 100 Устанавливает процент почты, к которой применяется политика DMARC. Вместо этого установите p=none при тестировании, чтобы убедиться, что вся почта обрабатывается одинаково. |
| adkim | По умолчанию расслаблен (r) В упрощенном режиме организационные домены как домена подписи с проверкой подлинности DKIM (взятого из значения тега «d=» в подписи), так и домена RFC 5322 From должны совпадать, если идентификаторы считаются выровненными. . |
| aspf | По умолчанию расслаблен (r) В упрощенном режиме домен с проверкой подлинности SPF и домен RFC5322 From должны иметь один и тот же домен организации. В строгом режиме считается, что только точное совпадение домена DNS обеспечивает выравнивание идентификатора. |
| rf | Список, разделенный двоеточием, одного или нескольких форматов отчетов по запросу владельца домена, который будет использоваться, когда сообщение не проходит тесты SPF и DKIM, чтобы сообщить подробности об отдельной ошибке. В настоящее время в стандарте DMARC поддерживается только «afrf» (тип отчета об ошибке аутентификации). |
| ri | По умолчанию 86400 Указывает на запрос к получателям о создании сводных отчетов, разделенных не более чем запрошенным числом секунд. Реализации DMARC ДОЛЖНЫ предоставлять ежедневные отчеты и ДОЛЖНЫ предоставлять ежечасные отчеты по запросу. Однако считается, что все, кроме ежедневного отчета, должно быть выполнено по мере возможности. |
Записи авторизации
Если адрес электронной почты в rua или ruf имеет базовый домен, отличный от домена записи политики, запись авторизации должна быть добавлена к базовому домену адреса электронной почты, чтобы указать, что он принимает отчеты об этом домене. Например, если dmarc@example.com также должен принимать отчеты для example.net, полигональная запись для example.net будет выглядеть так:
Код:
_dmarc.example.net TXT "v=DMARC1; p=none; street=mailto: dmarc@example.com ; ruf=mailto: dmarc@example.com "Поскольку example.net — это другой базовый домен, чем example.com, необходимо добавить следующую запись в example.com, чтобы указать, что он принимает отчеты о example.com:
Код:
example.net._report._dmarc.example.com TXT "v=DMARC1"Шаги развертывания
- Настройте почтовые шлюзы для учета записей DMARC и отправки сводных отчетов DMARC.
- проверка доменов
- Развернуть SPF
- Развернуть DKIM
- Настройте почтовый ящик для получения отчетов DMARC
- Разверните DNS-записи DMARC
- Мониторинг входящих отчетов DMARC
- При необходимости настройте политики SPF, подписи DKIM и DMARC.
События календаря из доменов, защищенных DMARC, пересылаемые посторонними с помощью Outlook, не пройдут проверку DMARC. К сожалению, в отличие от обычной пересылаемой электронной почты, события календаря, пересылаемые с помощью Outlook, «отправляются от имени» организатора собрания. Вместо того, чтобы использовать адрес человека, который переслал электронное письмо в заголовке «От», Outlook использует адрес организатора собрания. Адрес того, кто делал переадресацию, помещается в заголовок Sender, который DMARC не использует.
Это известная проблема с Outlook, которую Microsoft до сих пор не решила. А пока скажите всем, кто хочет переслать события календаря, сделать это, щелкнув три точки и выбрав «Переслать как вложение» вместо нажатия обычной кнопки «Переслать».
Как я могу проверить подпись DKIM?
Отправьте электронное письмо на учетную запись Gmail. У них приятный пользовательский интерфейс, который показывает статус DKIM сообщения.
Что делать, если сторонний отправитель не поддерживает DMARC?
- Некоторые поставщики еще не знают о DMARC; спросите об аутентификации SPF и DKIM/электронной почты.
Проверьте, могут ли они отправлять сообщения через ваши ретрансляторы электронной почты вместо своих. - Им действительно нужно подделать ваш домен? Почему бы вместо этого не использовать отображаемое имя?
- В худшем случае пусть этот поставщик отправляет электронную почту как определенный субдомен вашего домена (например , noreply@news.example.com ), а затем создает отдельные записи SPF и DMARC на news.example.com и устанавливает p=none в этой записи DMARC. .
Не изменяйте значения p или sp записи DMARC в домене верхнего уровня (TLD) — это сделает вас уязвимым для подмены вашего TLD и/или любого субдомена .
Дальнейшее чтение по этой проблеме.
Как я могу получить больше forensic отчетов
Часто вы найдете службу, которая отправляет электронную почту, которая проходит яерез SPF, но не через DKIM, но вы можете не знать, в каком рабочем процессе электронной почты возникла проблема, потому что вы не получите много аналитических отчетов, так как в SPF выравнивается. Попробуйте установить fo=1 в записи политики DMARC. По умолчанию для fo неявно установлено значение 0. Отчеты об ошибках/криминалистических отчетах DMARC отправляются только в том случае, если все механизмы аутентификации (т. е. SPF и DKIM) не дают согласованного результата «пройдено». Если задать fo=1 в записи политики DMARC, в случае сбоя какого -либо механизма проверки подлинности будут предоставляться отчеты о криминалистическом анализе/отказе.Это шумно, но очень полезно для устранения неполадок DKIM при прохождении SPF. Удалите тег fo или установите для него значение 0 после завершения устранения неполадок.
А как насчет списков рассылки
Когда вы развертываете DMARC в своем домене, вы можете обнаружить, что сообщения, ретранслируемые списками рассылки, не проходят проверку DMARC, скорее всего, из-за того, что список рассылки подделывает ваш адрес отправителя и изменяет тему, нижний колонтитул или другую часть сообщения, тем самым нарушая DKIM-подпись.
Лучшие практики списка рассылки
В идеале список рассылки должен пересылать сообщения без изменения заголовков или содержимого тела. Джо Нельсон проделывает фантастическую работу, объясняя, что именно должны и не должны делать списки рассылки, чтобы быть полностью совместимыми с DMARC. Вместо того, чтобы повторять его прекрасную работу, вот краткое изложение:МОЖНО
- Сохранить заголовки из исходного сообщения
- Добавьте заголовки RFC 2369 List-Unsubscribe к исходящим сообщениям вместо добавления ссылок для отмены подписки в тело. Список-отписка: <https://list.example.com/unsubscribe-link>
- Добавьте заголовки RFC 2919 List-Id вместо изменения темы Идентификатор списка: Пример списка рассылки <list.example.com>
Не МОЖНО
- Удалите или измените любые существующие заголовки из исходного сообщения, включая «От», «Дата», «Тема» и т. д.
- Добавляйте или удаляйте контент из тела сообщения, включая традиционные заявления об отказе от ответственности и нижние колонтитулы для отказа от подписки.
Эта конфигурация не только соответствует требованиям DMARC, но и гарантирует, что действия «Ответить» и «Ответить всем» будут работать так же, как и с любым сообщением электронной почты. Ответить отвечает отправителю сообщения, а Ответить всем отвечает отправителю и списку.
Даже без префикса темы или нижнего колонтитула пользователи списка рассылки все равно могут сказать, что сообщение пришло из списка рассылки, потому что сообщение было отправлено на почтовый адрес списка рассылки, а не на их адрес электронной почты.
Шаги настройки для распространенных платформ списков рассылки перечислены ниже.
Mailman2
Перейдите к общим настройкам и настройте параметры ниже.
| Параметр | Значение |
| subject_prefix | |
| from_is_list | Нет |
| first_strip_reply_to | Нет |
| answer_goes_to_list | Poster |
| include_rfc2369_headers | Да |
| include_list_post_header | Да |
| include_sender_header | Нет |
Перейдите к параметрам без дайджеста и настройте параметры ниже.
| Параметр | Значение |
| msg_header | |
| msg_footer | |
| scrub_nondigest | Нет |
Перейдите в «Параметры конфиденциальности»> «Фильтры отправки» и настройте параметры ниже.
| Параметр | Значение |
| dmarc_moderation_action | Принимать |
| dmarc_quarentine_moderation_action | Да |
| dmarc_none_moderation_action | Да |
Mailman 3
- Перейдите в «Настройки»> «Идентификация списка».
- Сделайте префикс темы пустым.
- Перейдите в «Настройки»> «Изменить сообщения».
- Настройте параметры ниже
| Параметр | Значение |
| Преобразование HTML в обычный текст | Нет |
| Включить заголовки RFC2369 | Да |
| Включить заголовок сообщения списка | Да |
| Явный адрес для ответа | |
| Ответ на первую полосу | Нет |
| Ответ попадает в список | Нет |
Перейдите в «Настройки»> «Смягчение DMARC».
Настройте параметры ниже
| Параметр | Значение |
| Действия по смягчению последствий DMARC | Отсутствие смягчения последствий DMARC |
| DMARC смягчает безоговорочно | Нет |
Создайте пустой шаблон нижнего колонтитула для списка рассылки, чтобы удалить нижний колонтитул сообщения. К сожалению, пользовательский интерфейс администратора списка рассылки Postorius не позволит вам создать пустой шаблон, поэтому вместо этого вам придется создать его с помощью командной строки системы, например:
Код:
touch var/templates/lists/list.example.com/en/list:member:regular:footerГде list.example.com идентификатор списка и en это язык.
Затем перезапустите ядро mailman/
Обходные пути
Если список рассылки должен идти вразрез с передовой практикой и изменять сообщение (например, добавлять обязательный юридический нижний колонтитул), администратор списка рассылки должен настроить список таким образом, чтобы адрес отправителя сообщения был заменен (также известный как подмена) адресом отправителя. список рассылки, поэтому они больше не подделывают адреса электронной почты с доменами, защищенными DMARC.
Шаги настройки для распространенных платформ списков рассылки перечислены ниже.
Mailman 2
Перейдите в «Параметры конфиденциальности»> «Фильтры отправки» и настройте параметры ниже.| Параметр | Ценность |
| dmarc_moderation_action | Mung from |
| dmarc_quarentine_moderation_action | Да |
| dmarc_none_moderation_action | Да |
Примечание
Вместо этого в качестве действия по смягчению последствий DMARC можно использовать упаковку сообщений. В этом случае исходное сообщение добавляется в качестве вложения к сообщению списка рассылки, но это может помешать поиску во входящих или мобильным клиентам.
С другой стороны, замена Fromадрес может привести к тому, что пользователи случайно ответят всему списку, когда они намеревались ответить только первоначальному отправителю.
Выберите вариант, который лучше всего подходит для вашего сообщества.
Mung - это компьютерный жаргон, обозначающий серию потенциально деструктивных или безвозвратных изменений в части данных или файле. Иногда он используется для нечетких шагов преобразования данных, которые еще не понятны докладчику
Mailman 3
На вкладке DMARC Mitigations страницы настроек настройте параметры ниже
| Параметр | Значение |
| Действия по смягчению последствий DMARC | Заменить от: на список адресов |
| DMARC смягчает безоговорочно | Нет |
Примечание
Вместо этого в качестве действия по смягчению последствий DMARC можно использовать упаковку сообщений. В этом случае исходное сообщение добавляется в качестве вложения к сообщению списка рассылки, но это может помешать поиску во входящих или мобильным клиентам.
С другой стороны, замена Fromадрес может привести к тому, что пользователи случайно ответят всему списку, когда они намеревались ответить только первоначальному отправителю.
Выберите вариант, который лучше всего подходит для вашего сообщества.