Yakov Shafranovich publicó en abril de 2005 [1] un borrador que describe un formato estándar para informes de bucle de retroalimentación (FBL) y evolucionó hasta el actual RFC 5965 . [2] AOL , que fue pionera en el campo en 2003, inicialmente usó un formato diferente y se convirtió a este estándar de facto en 2008. [3] Los bucles de retroalimentación no tienen que usar ARF, pero la mayoría lo hace.
En enero de 2010, el IETF fundó [4] un nuevo grupo de trabajo que trabaja con el objetivo de estandarizar el formato ARF. El Grupo de Trabajo se denominó Formato de Informe de Abuso de Mensajes WG o MARF, que produjo el RFC 5965 . En 2012 fue ampliado por RFC 6591 y RFC 6692 para definir informes de fallas , para informar fallas de autenticación de correo electrónico . En 2015, el RFC 7489 amplió aún más este último tipo de informe para definir los informes de fallas de DMARC .
El formato ARF está diseñado para ser extensible, proporcionando informes de spam genéricos, por ejemplo, de los usuarios a algún centro antispam o mesa de ayuda, o para operaciones de exclusión voluntaria. El formato define un nuevo tipo MIME que se incluirá en un multipart/reportarchivo adjunto e incluye al menos los encabezados del mensaje infractor. Aunque el borrador de la descripción reconoce que algunos operadores pueden optar por modificar o redactar esa parte por motivos legales o de privacidad, recomienda que se adjunte todo el mensaje de correo electrónico original, incluida la dirección del destinatario sin modificar.
Un informe FBL encapsulado en ARF viene con el mismo asunto que el mensaje infractor. Al igual que los mensajes de rebote , un informe de abuso consta de una parte legible por humanos, seguida de una parte legible por máquina y el mensaje original. El tipo de pieza legible por máquina es message/feedback-report, cuya definición es el núcleo del borrador. La extensibilidad se logra al incluir un campo de Tipo de retroalimentación que caracteriza el informe. Los posibles valores de este campo son:
Se proporciona un registro IANA para Feedback-Type , así como para los otros nombres de campo. [6] Cada nombre de campo puede ser relevante para cualquier tipo de retroalimentación o solo para un tipo específico. Algunos campos pueden aparecer varias veces. Por ejemplo, el campo Source-IP , que contiene la dirección IP desde la que se recibió el mensaje original, puede aparecer en cualquier tipo de informe FBL, pero solo una vez; el campo Destinatario de eliminación , que indica las direcciones de correo electrónico que se eliminarán, solo puede aparecer en los informes de exclusión , pero una o más veces. Además, existe un subtipo DKIM-Failure , con su propio registro IANA.
Un ejemplo de informe de abuso de correo electrónico es el siguiente. (Tenga en cuenta que solo se requieren las primeras tres líneas de la parte legible por máquina).