Abuse Reporting Format (ARF): как устроены отчёты о жалобах на email
Abuse Reporting Format (ARF) — стандартизированный формат email-отчётов о нежелательных или подозрительных письмах. Почтовые провайдеры и другие участники обмена используют ARF, чтобы передавать отправителю сведения об инциденте в машиночитаемом виде. Отправляющая система может сопоставить отчёт с конкретным письмом и прекратить коммуникацию с пожаловавшимся получателем.
Как ARF связан с Feedback Loop
ARF описывает структуру отчёта, но не определяет, кто и по какому адресу должен его отправлять. Доставку отчётов о пользовательских жалобах обычно организуют через Feedback Loop — FBL, или петлю обратной связи.
Процесс выглядит так:
- Получатель отмечает письмо как спам.
- Почтовый провайдер регистрирует жалобу.
- Если отправитель подключён к FBL, провайдер формирует ARF-отчёт и направляет его на зарегистрированный адрес.
- Система отправителя разбирает отчёт, находит письмо и получателя, фиксирует жалобу и останавливает дальнейшие отправки по соответствующей подписке.
Таким образом, FBL — это механизм передачи жалоб, а ARF — формат передаваемых данных. Эти понятия связаны, но не равнозначны. ARF и его расширения также применяются для сообщений о фишинге, вирусах и сбоях email-аутентификации. Актуальный реестр IANA содержит типы abuse, auth-failure, fraud, not-spam, other и virus.
Жалоба влияет на репутацию отправителя независимо от того, подключён ли FBL. Без обратной связи отправитель просто не получит данных, по которым можно исключить пожаловавшегося подписчика из следующих рассылок.
Из чего состоит ARF-отчёт
Спецификация ARF зафиксирована в RFC 5965. Отчёт представляет собой email с MIME-типом multipart/report и параметром report-type=feedback-report. Внутри находятся три части.
| Часть | Формат | Содержание |
|---|---|---|
| Описание для человека | Обычно text/plain | Краткое пояснение причины отправки отчёта и сведения о его источнике |
| Машиночитаемые данные | message/feedback-report | Тип обратной связи, версия формата, данные генератора отчёта и дополнительные поля |
| Исходное письмо | message/rfc822 или text/rfc822-headers | Полная копия письма либо его заголовки |
Во второй части обязательны три поля, каждое из которых должно присутствовать один раз:
Feedback-Type— тип отчёта, напримерabuseпри жалобе на нежелательное письмо.User-Agent— название и версия программы, которая сформировала отчёт.Version— версия спецификации ARF; для RFC 5965 используется значение1.
Другие поля необязательны. Опционально провайдер может передать адрес SMTP-отправителя и получателя, IP-адрес источника, дату получения письма, результаты аутентификации, домены и URI, связанные с инцидентом. Актуальный перечень зарегистрированных полей опубликован в реестре MARF Parameters.
Пример машиночитаемой части:
Feedback-Type: abuse
User-Agent: Example-FBL/1.0
Version: 1
Original-Mail-From: <bounce@example.com>
Original-Rcpt-To: <recipient@example.net>
Arrival-Date: Tue, 27 Oct 2026 10:15:00 +0000
Source-IP: 192.0.2.10
Конкретный отчёт может содержать только обязательные поля. Почтовые провайдеры также вправе скрывать адрес получателя или удалять часть исходного сообщения из соображений конфиденциальности.
Поля машиночитаемой части нельзя считать безусловно достоверными. Спецификация рекомендует в первую очередь анализировать приложенное исходное письмо, а затем дополнительные сведения из message/feedback-report.
Какие данные нужны отправителю
Для обработки обычной жалобы с Feedback-Type: abuse отправляющая система должна решить две задачи: определить, какое письмо вызвало жалобу, и найти соответствующую подписку.
Для этого используются:
- адрес получателя — если провайдер не скрыл его;
- заголовки исходного письма — в них могут находиться идентификаторы сообщения, рассылки и отправляющей системы;
- дата и время — нужны для сопоставления отчёта с журналом отправок;
- SMTP-отправитель и Source IP — указывают на поток или сервер, откуда пришло письмо;
- тип отчёта — отделяет жалобу на спам от сообщения о фишинге, вирусе или ошибке аутентификации.
Если провайдер скрывает получателя, идентификация зависит от данных, которые отправляющая система заранее добавила в письмо и сохранила в журнале. Поэтому крупным отправителям важно поддерживать однозначную связь между сгенерированным сообщением, кампанией и подпиской.
По общему правилу один ARF-отчёт относится к одному исходному письму. При этом необязательное поле Incidents позволяет указать число представленных отчётом однотипных инцидентов.
Получатель отмечает письмо как спам, после чего почтовый провайдер передаёт отправителю ARF-отчёт через Feedback Loop
Чем ARF отличается от других email-отчётов
ARF часто путают с возвратами и DMARC-отчётами. У них разные причины формирования и задачи.
| Отчёт | Что произошло | Формат и содержание |
|---|---|---|
ARF с типом abuse | Получатель или антиспам-система сообщили о нежелательном письме | Данные об одном письме или однотипных инцидентах, обычно переданные через FBL |
| DSN, или сообщение о недоставке (bounce) | Почтовый сервер не смог доставить письмо | Статус, код и причина недоставки |
| Агрегированный DMARC-отчёт | Провайдер проверил поток писем от имени домена | Сводные данные об аутентификации в XML |
| DMARC failure report | Отдельное письмо или группа схожих писем не прошли проверку аутентификации | Расширенный ARF с типом auth-failure |
Нажатие на кнопку «Спам» не считается возвратом: письмо уже было доставлено. Агрегированный DMARC-отчёт тоже не содержит пользовательскую жалобу и описывает поток сообщений за отчётный период. Индивидуальные DMARC failure reports используют расширение ARF, но сигнализируют об ошибке аутентификации, а не о недовольстве получателя.
Ограничения и безопасность обработки
ARF может содержать адрес получателя, заголовки и полную копию исходного письма. В отчёт способны попасть персональные данные, коммерческая информация или вредоносное вложение. Доступ к почтовому ящику FBL и архиву отчётов следует ограничить, а сроки хранения — согласовать с внутренними правилами обработки данных.
Отчёты также могут быть подделаны или повреждены. При автоматической обработке стоит:
- принимать сообщения только от ожидаемых источников и проверять доступные признаки подлинности;
- не менять статус подписки только по адресу, указанному в необязательном поле, без сопоставления с историей отправок;
- защищать обработчик от вредоносных и некорректных MIME-вложений;
- исключать повторную обработку одного отчёта;
- сохранять журнал действий на случай ошибочной блокировки.
Как жалобы обрабатываются в Altcraft
Для получения ARF-отчётов необходимо настроить FBL/CFL у поддерживающих эту технологию провайдеров и организовать приём входящей почты на адрес отправляющего домена. Схема приёма таких сообщений через сервер входящей почты AKMTA описана в документации.
При настроенной обратной связи платформа регистрирует жалобы как события email-рассылок. Их количество и доля доступны в отчёте по каналам — доля рассчитывается по формуле (Жалобы / Доставки) × 100%. Связанная подписка получает статус «Жалобщик» и больше не используется для отправок.
Хотите отслеживать жалобы, доставки и другие события email-рассылок в одной системе? Зарегистрируйтесь в Altcraft, чтобы познакомиться с отчётами и историей действий подписчиков.
Заключение
Abuse Reporting Format задаёт единую структуру отчёта о нежелательном или подозрительном письме. В email-маркетинге ARF чаще всего используется внутри Feedback Loop: провайдер передаёт жалобу, а система отправителя сопоставляет её с рассылкой и прекращает коммуникацию с пожаловавшимся получателем.
ARF не следует путать с самим FBL, возвратами и агрегированными DMARC-отчётами. Для корректной обработки нужны настроенный канал получения отчётов, связь сообщений с подписками и защита от поддельных, повторных и содержащих конфиденциальные данные сообщений.
Читайте по теме
