RFC 5965: ARF — Formato de Informe de Abuso
Por Qué Existe
Los proveedores de buzones (Gmail, Yahoo, Outlook, etc.) permiten a los usuarios reportar correos no deseados como spam. Los remitentes responsables necesitan esta retroalimentación para eliminar denunciantes de sus listas e identificar problemas con su envío. Sin un formato estándar, cada proveedor usaría un formato de denuncia diferente, haciendo imposible el procesamiento automatizado.
ARF proporciona el estándar. Los proveedores de buzones lo usan para enviar reportes de bucle de retroalimentación (FBL), y los remitentes analizan estos reportes para:
- Suprimir inmediatamente al destinatario denunciante
- Rastrear tasas de denuncia por campaña, IP o dominio de envío
- Detectar cuentas comprometidas o envíos inesperados
- Reportar fallos de autenticación y otros tipos de abuso
Cómo Funciona
Un reporte ARF es un mensaje MIME multipart/report con report-type=feedback-report. Contiene tres partes:
-
Descripción legible por humanos (
text/plain) — resumen para revisores humanos. -
Reporte legible por máquinas (
message/feedback-report) — campos estructurados definidos por esta RFC. -
Mensaje original (
message/rfc822otext/rfc822-headers) — el correo que fue reportado.
Ejemplo de Reporte ARF
From: feedback@isp.example.com To: abuse@sender.example.com Subject: FBL report - complaint from user MIME-Version: 1.0 Content-Type: multipart/report; report-type=feedback-report; boundary="ARF-BOUNDARY-001" --ARF-BOUNDARY-001 Content-Type: text/plain This is an abuse report for a message received from IP 203.0.113.10 on Wed, 11 Mar 2026 09:15:00 -0500. --ARF-BOUNDARY-001 Content-Type: message/feedback-report Feedback-Type: abuse User-Agent: ISP-FBL/1.0 Version: 1 Original-Mail-From: campaign@sender.example.com Arrival-Date: Wed, 11 Mar 2026 09:15:00 -0500 Source-IP: 203.0.113.10 Reported-Domain: sender.example.com Authentication-Results: isp.example.com; dkim=pass header.d=sender.example.com; spf=pass smtp.mailfrom=sender.example.com --ARF-BOUNDARY-001 Content-Type: message/rfc822 From: campaign@sender.example.com To: user@isp.example.com Subject: Weekly Newsletter #42 Message-ID: <news-42@sender.example.com> List-Unsubscribe: <https://sender.example.com/unsub?id=xyz> [original message body] --ARF-BOUNDARY-001--
Detalles Técnicos Clave
Valores de Feedback-Type
| Tipo | Significado |
|---|---|
abuse |
El usuario reportó el mensaje como spam (el tipo más común) |
fraud |
El mensaje parece ser phishing o una estafa |
virus |
El mensaje contenía malware |
other |
Categoría general para reportes que no encajan en otras categorías |
not-spam |
El usuario indicó que esto NO es spam (corrección de falso positivo) |
auth-failure |
La verificación de autenticación falló (RFC 6591 extiende esto) |
Campos Requeridos y Opcionales
| Campo | Requerido | Descripción |
|---|---|---|
Feedback-Type |
Sí | El tipo de reporte (ver arriba) |
User-Agent |
Sí | Nombre y versión del software generador |
Version |
Sí | Siempre 1 para esta RFC |
Original-Mail-From |
No | El remitente de sobre (MAIL FROM) del mensaje reportado |
Arrival-Date |
No | Cuándo llegó el mensaje reportado |
Source-IP |
No | La IP que envió el mensaje reportado |
Reported-Domain |
No | El dominio asociado con el mensaje reportado |
Authentication-Results |
No | Resultados de autenticación según RFC 8601 |
Reported-URI |
No | URIs encontradas en el mensaje reportado (repetible) |
Original-Rcpt-To |
No | El destinatario de sobre del mensaje reportado |
Consideraciones de Privacidad
Muchos proveedores de buzones ocultan la dirección del destinatario del mensaje original incluido para proteger la privacidad del usuario. La denuncia puede incluir solo encabezados, no el cuerpo completo. Algunos proveedores (notablemente Yahoo) incluyen el mensaje original completo; otros (como Microsoft) envían solo encabezados. Tu analizador ARF debe manejar ambos casos.
Errores Comunes
- No registrarse para bucles de retroalimentación. La mayoría de los grandes proveedores de buzones requieren que registres tus IPs o dominios de envío en su programa FBL. Sin registro, nunca recibirás reportes ARF.
- Ignorar la tasa de denuncia. Los proveedores de buzones rastrean tasas de denuncia (denuncias / mensajes entregados a la bandeja de entrada). Exceder 0.1% es una advertencia; exceder 0.3% típicamente activará filtrado o bloqueo. Analiza reportes ARF y actúa rápido.
-
No suprimir denunciantes inmediatamente. Cuando recibas un reporte ARF con
Feedback-Type: abuse, suprime inmediatamente ese destinatario. Continuar enviando a alguien que se quejó es un camino rápido a la lista negra. - Analizar solo formatos FBL específicos. Diferentes proveedores pueden incluir campos opcionales diferentes o variar el contenido del mensaje original. Construye un analizador robusto que maneje campos faltantes con elegancia.
-
Confundir ARF con DSN. Los DSN (RFC 3464) reportan estado de entrega (rebote/retraso/éxito). Los reportes ARF reportan denuncias de usuarios. Usan estructura
multipart/reportsimilar pero valores dereport-typediferentes y sirven propósitos diferentes.
Impacto en Entregabilidad
- La tasa de denuncia es una señal de reputación principal. Gmail, Yahoo y Microsoft usan tasas de denuncia para decidir si entregar tu correo a la bandeja de entrada, carpeta de spam o rechazarlo completamente. El procesamiento de ARF no es opcional para ningún remitente serio.
- Los datos FBL impulsan la higiene de listas. Los reportes ARF te dicen exactamente qué destinatarios no quieren tu correo. Esto es más procesable que los rebotes porque la dirección es válida — el humano simplemente no quiere tus mensajes.
-
Diagnóstico de campañas. Al correlacionar reportes ARF con el
Message-IDu encabezados personalizados en el mensaje original, puedes identificar qué campañas, líneas de asunto o contenido provocaron denuncias. - Detección de compromiso de cuentas. Un pico repentino en reportes ARF puede indicar que la cuenta o clave API de un cliente ha sido comprometida y se está usando para enviar spam.