RFC 6430 : Email Feedback Report Type Value : not-spam
http://www.bortzmeyer.org/6430.html
----------------------------
Auteur(s) du RFC: K. Li (Huawei), B. Leiba (Huawei)
Chemin des normes
----------------------------
Il existe un format standard pour la transmission de rapports d'abus
entre acteurs de l'Internet qui permet, par exemple, à des opérateurs
de serveurs de messagerie de signaler un spam, et de traiter
automatiquement ces rapports. Ce format se nomme ARF et est normalisé
dans le RFC 5965. Chaque rapport ARF indique un type d'abus et ce
nouveau RFC 6430 ajoute le type "not spam", qui permet d'attirer
l'attention sur un message classé à tort.
Le format ARF est conçu pour de gros opérateurs, traitant des millions
de messages et d'innombrables rapports d'abus (spam mais aussi
hameçonnage, distribution de logiciel malveillant, etc). Avec de tels
volumes à traiter, l'automatisation est nécessaire et c'est ce que
permet ARF. Le type abuse, documenté en section 7.3 du RFC 5965, permet
de signaler un message comme n'étant pas désiré. Mais on a parfois
besoin de l'inverse, signaler qu'un message n'est pas du spam, pour que
le destinataire du rapport ajuste ses filtres. C'est ce qu'introduit
notre RFC, suite à une demande de l'OMA (« "Mobile Spam Reporting
Requirements" », OMA-RD-SpamRep-V1_0 20101123-C).
Bien sûr, le destinataire du rapport est libre de l'action à
entreprendre. Il peut par exemple attendre d'avoir plusieurs rapports
équivalents, Si l'opérateur accepte des rapports envoyés directement
par les utilisateurs (ceux-ci ne vont pas taper du ARF à la main mais
ils peuvent avoir un MUA muni d'un bouton "Report as non-spam" qui le
fait pour eux), il doit tenir compte du fait que les utilisateurs
peuvent se tromper (cliquer trop vite) ou même tenter d'influencer le
système (mais non, cette publicité n'est pas du spam, laissez-là
passer...). La section 4 rappelle donc de traiter avec prudence ces
rapports.
Les détails de syntaxe figurent en section 3 du RFC. Voici un exemple
de rapport avec le Feedback-Type: à not-spam. abused...@example.com
signale à ab...@example.net que le message de some...@example.net n'est
*pas*, en dépit des apparences, du spam (mettons qu'il ait été envoyé
en réponse à une sollicitation d'un médecin) :
From: <abused...@example.com>
Date: Thu, 8 Mar 2005 17:40:36 EDT
Subject: FW: Discount on pharmaceuticals
To: <ab...@example.net>
Message-ID: <20030712040037.46341.5...@example.com>
MIME-Version: 1.0
Content-Type: multipart/report; report-type=feedback-report;
boundary="part1_13d.2e68ed54_boundary"
--part1_13d.2e68ed54_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
This is an email abuse report for an email message received
from IP 192.0.2.1 on Thu, 8 Mar 2005 14:00:00 EDT.
For more information about this format please see
http://tools.ietf.org/html/rfc5965
Comment: I sell pharmaceuticals, so this is not spam for me.
--part1_13d.2e68ed54_boundary
Content-Type: message/feedback-report
Feedback-Type: not-spam
User-Agent: SomeGenerator/1.0
Version: 1
--part1_13d.2e68ed54_boundary
Content-Type: message/rfc822
Content-Disposition: inline
Received: from mailserver.example.net
(mailserver.example.net [192.0.2.1])
by example.com with ESMTP id M63d4137594e46;
Thu, 08 Mar 2005 14:00:00 -0400
From: <some...@example.net>
To: <Undisclosed Recipients>
Subject: Discount on pharmaceuticals
MIME-Version: 1.0
Content-type: text/plain
Message-ID: 8787kjkj3k4j3k4j3k4j3.m...@example.net
Date: Thu, 02 Sep 2004 12:31:03 -0500
Hi, Joe. I got a lead on a source for discounts on
pharmaceuticals, and I thought you might be interested.
[...etc...]
--part1_13d.2e68ed54_boundary--
Le type not-spam fait donc désormais partie du registre des types de
rapport ARF
<http://www.iana.org/assignments/marf-parameters/marf-parameters.xml#mar
f-parameters-2>.
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
