Кратко

  • В исследовании Palisade, представленном Internet Society Pulse 1 сентября, действующие записи DMARC обнаружены у 58,1% из 99 300 наблюдавшихся доменов.
  • Среди доменов с DMARC у 20,7% не был указан адрес для агрегированных отчётов. Это не доказывает отсутствия любого мониторинга и не раскрывает обязательств почтового подрядчика.

После переноса почты работа с доменом не заканчивается. Появляется новая система выставления счетов, меняется сервис рассылок, служба поддержки начинает отправлять сообщения через другого поставщика. Кто учитывает эти законные источники, проверяет аутентификацию и разрешает изменение политики? Сам факт покупки почтовой услуги ответа не даёт.

Поводом для такого вопроса стала гостевая публикация Internet Society Pulse от 1 сентября. Её автор Samuel Chenard — CEO и сооснователь Palisade — рассказывает об исследовании своей компании. Internet Society отдельно предупреждает, что мнения гостей не обязательно совпадают с его позицией. Это не новое институциональное требование.

Что было измерено

Соответствующий сравнительный обзор Palisade основан на восьмиминутном сканировании 14 августа. Из 99 300 доменов действующие записи DMARC публиковали 57 732, или 58,1%. Среди этих издателей 36 938 запрашивали карантин или отклонение сообщений, то есть 64%, а 11 959 не указывали адрес агрегированных отчётов — 20,7%.

Последние две доли относятся только к доменам, публиковавшим DMARC. Это опубликованные исследователем результаты: мы не воспроизводили сканирование. В выборке находятся высокоранжированные веб-домены, а не все домены, используемые для деловой переписки.

Запись MX тоже имеет ограниченный смысл для сравнения поставщиков. Она показывает видимую инфраструктуру приёма; шлюз может скрывать расположенную за ним платформу почтовых ящиков. Поправка на группы веб-рейтинга не превращает наблюдение в причинное доказательство. По этим данным нельзя заключить, что выбор конкретного поставщика вызвал определённую политику или что договор клиента был нарушен.

Работу можно передать, но нужно назвать

Действующая спецификация DMARC, RFC 9989, связывает политику домена с согласованной аутентификацией, обратной связью и исправлением проблем законных отправителей. Определение Domain Owner включает поставщиков услуг, действующих от имени клиентов. Следовательно, такую работу можно делегировать; спецификация не устанавливает для внутренней команды непередаваемую юридическую обязанность.

Управляемая услуга как раз может быть полезна тем, что объединяет эти задачи. Однако эксплуатация ящиков, управление DNS, анализ отчётов и согласование изменений не обязательно входят в один договор. Наименование поставщика само по себе не определяет, где проходит граница.

Политика p=none также не означает автоматически бездействия. RFC 9989 рекомендует начинать с неё, чтобы обнаружить забытых законных отправителей и исправить аутентификацию до более строгих запросов. Редкие рассылки могут потребовать более длительного наблюдения.

Отсутствие адреса отчётов не доказывает отсутствия всех средств наблюдения. Наличие адреса, напротив, не доказывает получение и чтение отчётов: RFC 9990 предусматривает условия подтверждения внешних получателей и доставки. Снимок DNS не рассказывает, как организована ежедневная работа.

Общий протокол не распределяет договорные задачи

Lu Heng проводит различие между минимальной общей спецификацией и локальными решениями. Здесь это редакционная рамка анализа, а не дополнительное требование IETF. Единый язык протокола помогает взаимодействию, но не назначает исполнителя для каждого клиента.

Поэтому вывод не в том, чтобы вернуть всю почту внутрь организации. Стоит явно определить, включены ли учёт отправителей, разбор отчётов, изменения DNS и согласование политики в услугу, остаются ли они у клиента или поручены отдельно. Передача почты подрядчику может снизить нагрузку. Для этого надо знать, кому передана продолжающаяся работа.

Источники