DMARC - понимание сводных отчетов


8

TL; DR
Я получаю много отзывов от DMARC от учетных записей / веб-сайтов, с которыми у меня нет контактов, и мне нужна некоторая ясность в отношении того, следует ли мне предпринимать какие-либо действия или эти отчеты обратной связи содержат информацию о каких-либо серьезных проблемах?

Я запускаю WHM-сервер и использую SPF и DKIM (и _DMARC), все электронные письма отправляются с одного сервера домена.

Пример настройки DNS для моего _DMARC (и DKIM и SPF):

mydomain.co.uk     14400 IN TXT "v=spf1 mx a ip4:11.22.33.44 ip4:11.22.33.55 ~all"

default._domainkey 14400 IN TXT "v=DKIM1; k=rsa; p=<code>;

_dmarc             14400 IN TXT "v=DMARC1; p=quarantine; sp=none; 
                                rua=mailto:me@mydomain.co.uk!90m; 
                                ruf=mailto:me@mydomain.co.uk; 
                                rf=afrf; pct=100; ri=86400"

и, насколько я могу судить, это настроено и работает, как ожидалось.

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

Например, сегодня утром я получил сводный отчет DMARC от Comcast, в котором говорилось:

<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
    <version>1.0</version>
    <report_metadata>
        <org_name>comcast.net</org_name>
        <email>dmarc-admin@alerts.comcast.net</email>
        <report_id>v1-1483425166-mydomain.co.uk</report_id>
        <date_range>
            <begin>1483315200</begin>
            <end>1483401600</end>
        </date_range>
    </report_metadata>
    <policy_published>
        <domain>mydomain.co.uk</domain>
        <adkim>r</adkim>
        <aspf>r</aspf>
        <p>quarantine</p>
        <sp>none</sp>
        <pct>100</pct>
        <fo>0</fo>
    </policy_published>
    <record>
        <row>
            <source_ip>72.167.218.164</source_ip>
            <count>1</count>
            <policy_evaluated>
                <disposition>none</disposition>
                <dkim>fail</dkim>
                <spf>fail</spf>
            </policy_evaluated>
        </row>
        <identifiers>
            <header_from>mydomain.co.uk</header_from>
        </identifiers>
        <auth_results>
            <spf>
                <domain>bounce.secureserver.net</domain>
                <scope>mfrom</scope>
                <result>pass</result>
            </spf>
        </auth_results>
    </record>
</feedback>

Нет, я не узнаю никаких подробностей, изложенных здесь, за исключением моего домена, IP-адрес <source_ip>не является моим IP-адресом, и я вообще не знаю о каких-либо контактах с Comcast.

По сути, я получаю довольно много таких уведомлений и не могу найти какой-либо обратной связи, чтобы сказать мне, являются ли они просто информативными и о которых можно забыть (в каком случае их смысл?) Или могу ли я что-то сделать с моим сервером, чтобы исправить ошибки, о которых уведомляет меня.

ТАК:

  • Являются ли эти отчеты чем-то, что может быть обработано?
  • Как должны действовать отчеты DMARC, подобные этим, с моей стороны?
  • Являются ли эти отчеты показателями любой формы компрометации аккаунта?
  • Может / количество этих отчетов [потенциально] плохо отражается на моем доменном имени для остальной части сети?

Возможно, стоит отметить, что я подозреваю, что ответ на последние две пули будет «Нет», но я не эксперт по этим вопросам.


Я уже прочитал этот пост, а также часто задаваемые вопросы по DMARC и эту тему , но там не так много информации. о том, как мы должны реагировать на сводные отчеты. Я знаю, что «неудачные» отчеты DMARC могут быть вызваны программами пересылки почты, хотя я надеюсь отрицать эту возможность с моим SPF ~all.

В целом, я думаю, что мне не нужно беспокоиться об этих отчетах, но мне хотелось бы получить второе мнение из-за того, что я воспринимаю как регулярность и ( я думаю ) относительно значительное количество сводных отчетов, которые я получаю.

Ответы:


6

Являются ли эти отчеты чем-то, что может быть обработано?

Да, но большая часть информации будет подтверждать, что все в порядке с вашей конфигурацией.

Как должны действовать отчеты DMARC, подобные этим, с моей стороны?

Обычно эти отчеты обрабатываются автоматизированной системой, которая превращает эти данные в красивые отчеты с графиками, статистикой и проблемами, требующими внимания. Если вы еще не видели систему такого типа, то, возможно, вам следует проверить dmarcian.com, который предоставляет бесплатную базовую услугу, которая поможет вам начать работу и понять, что вы можете, а что не можете делать или видеть. Чтобы это работало, вы должны будете использовать адрес электронной почты, который они предоставляют вам в вашей записи DMARC.

Являются ли эти отчеты индикаторами какой-либо формы компрометации аккаунта?

Нет, это просто отчеты обо всех действиях серверов с поддержкой DMARC, которые обработали сообщения, утверждающие, что они принадлежат вашему доменному имени, по сути, сообщая вам, что они получили сообщение, откуда оно пришло и что они с ним сделали и почему.

Может / количество этих отчетов [потенциально] плохо отражается на моем доменном имени для остальной части сети?

Нет, эти отчеты отправляются только на адрес электронной почты, указанный в записи DMARC, и не публикуются в Интернете. Единственный реальный потенциал для негативного воздействия - это если вы неправильно настроили SPF и / или DKIM и в конечном итоге получили много сообщений, отклоненных / заблокированных, но тогда, по крайней мере, с DMARC вы узнаете об этом.


Спасибо за заверение там. С тех пор у меня есть настроенный (бесплатный) аккаунт, dmarcian.comно я не сразу понял , почему это было бы полезно как таковое, но я предполагаю, что он суммирует данные обратной связи, которые отчеты дают мне.
Мартин

1
Это просто на глаз, особенно когда количество данных в отчетах, а также частота их получения могут быть значительными. Отчеты DMARC предназначены для обработки компьютерами, интерфейс dmarcian.com предназначен для чтения людьми. Вы всегда можете придумать собственное решение для автоматической обработки, если вы не являетесь поклонником интерфейса dmarcian.com. Существуют и другие, которые вы можете исследовать, но это единственная бесплатная версия, о которой я знаю. Надеюсь это поможет.
richhallstoke

2

В качестве ответа на ваш пример: многие сбои DMARC можно отследить до списков пересылки и рассылки, например, с помощью Google Groups for Business. Однако в отчете показано, что электронное письмо было отправлено с узла, являющегося частью secureserver.net. SPF был проверен на пути возврата bounce.secureserver.netи пройден.

Скорее всего, это было сообщение об отказе от вашей анти-СПАМ или входящей SMTP-службы, отправленное обратно исходному отправителю электронной почты, которое пыталось отправить вам электронное письмо. Отскок будет отправлен от вашего имени с измененным путем возврата. SecureServer.net является частью GoDaddy, вы хостинг с GoDaddy или филиал?

В ответ на ваше заявление:

Я знаю, что «неудачные» отчеты DMARC могут быть вызваны программами пересылки почты, хотя я надеюсь отрицать эту возможность с моим SPF ~all.

DMARC будет оценивать Pass только в том случае, если проверки SPF или DKIM приводят к передаче в соответствии с вашим Fromадресным доменом. Так что я не уверен, что вы имеете в виду, что ~allотрицает проблему.

Серверы пересылки обычно переписывают return-pathсвой собственный адрес возврата, что приводит к невозможности его выравнивания с исходным доменом. ЧТ ARC протокол еще в проекте, но следует свести на нет этой проблемы пересылки для выравнивания SPF с DMARC для доверенных экспедиторов. Кроме того, подписи DKIM чаще всего остаются в такте, если только подписанные поля не изменены экспедитором. Таким образом, DMARC все еще может пройти на основе DKIM.

Одна последняя вещь:

В вашей политике DMARC вы публикуете sp=noneполитику для всех поддоменов, которая в противном случае наследовала бы p=quarantineполитику. Это приводит к тому, что любой, кто подделывает ваш домен, может просто выбрать любой субдомен для использования, например app.mydomain.co.uk. Возможно, это желаемая настройка, но я просто хотел указать на это.


Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.