Je crois que j'avais déjà demandé ici mais sans avoir de réponse. Qui utilise le format ARF, en sortie pour envoyer des rapports ou en entrée pour les analyser ? Qui l'ouvre à ses utilisateurs en leur permettant d'envoyer du ARF (explicitement ou via un formulaire) ? L'ARCEP devrait-elle récolter de l'information sur l'utilisation d'ARF ?
Nouveau RFC 6650: Creation and Use of Email Feedback Reports: An Applicability Statement for the Abuse Reporting Format (ARF) : http://www.bortzmeyer.org/6650.html ---------------------------- Auteur(s) du RFC: J. Falk (Return Path), M. Kucherawy (Cloudmark) Chemin des normes ---------------------------- Le format ARF, normalisé dans le RFC 5965 permet à des acteurs de l'Internet (typiquemet des FAI et des gros hébergeurs de courrier comme Gmail) de s'envoyer des rapports structurés, produits et analysés automatiquement, au sujet des abus commis avec le courrier électronique, notamment du spam. Ce nouveau RFC du groupe de travail qui a conçu ARF expose comment et dans quelles circonstances utiliser ARF. L'idée de base d'ARF était qu'un message serait détecté comme abusif (par exemple par l'utilisateur cliquant un bouton « C'est du spam ! ») et que cette détection déclencherait l'envoi d'un rapport ARF au responsable (qui pourra le faire suivre, si nécessaire). En comparaison avec un rapport non structuré, l'avantage d'ARF est que les messages ARF seront analysables par des programmes, pour rendre leur traitement plus efficace. (Il existe des extensions à ARF pour des usages qui ne sont pas forcément des abus ou des erreurs d'authentification, comme l'extension du RFC 6430 mais elles sont encore peu déployées et pas étudiées ici.) Ce RFC 6650 est largement inspiré d'un document externe à l'IETF, le RFC 6449. En quelque sorte, il en est la version officielle. Les autres documents existants, comme la norme ARF (RFC 5965), sont purement techniques (définition d'un format) et ne répondent pas à des questions comme « à qui envoyer les rapports ? » ou « que faut-il mieux mettre dans un rapport ? », qui font l'objet de ce RFC. D'abord, faut-il un accord explicite du destinataire avant d'envoyer les rapports ARF ? La section 3 considère qu'il y a deux cas, celui de deux acteurs décidant entre eux de se transmettre des rapports ARF, relatifs à leurs clients. C'est le cas le plus fréquent aujourd'hui. Et le second cas est celui où des rapports non sollicités sont envoyés à quelqu'un dont l'expéditeur pense qu'il est concerné. En l'absence d'un accord préalable, ces rapports ne feront pas forcément l'objet de la même attention. La section 4 détaille le premier cas, les rapports attendus. En vrac, elle demande, entre autres : * Que l'accord entre les deux acteurs soit respecté, notamment dans le choix de l'adresse de destination (arf-feedb...@example.net, par exemple). * Que le rapport soit à la syntaxe ARF (évidemment) et que les éléments optionnels dans ARF soient inclus, s'ils sont disponibles (pas de rétention délibérée). Cela concerne Original-Mail-From, Arrival-Date, Source-IP, Original-Rcpt-To. * Pour relativiser la demande précédente, il peut y avoir occultation délibérée, pour préserver la vie privée, comme détaillé dans le RFC 6590. * Enfin, la section 4 demande (vœu pieux ?) que le récepteur *agisse* lorsqu'il reçoit des rapports qui le concernent (section 4.3 du RFC 6449). La section 5 s'attaque aux rapports inattendus, envoyés sans concertation préalable. Elle est bien plus longue puisqu'il s'agit d'embêter des gens qui n'ont rien demandé (dans le précédent cas, les deux parties ont pu se mettre d'accord sur tous ces points, qui doivent être explicités ici.) Les auteurs du RFC demandent, entre autres : * Que le destinataire ait un moyen de ralentir le rythme d'envoi des rapports, pour que son infrastructure ne s'écroule pas sous la charge (il n'existe pas de mécanisme standard pour cela, cela doit être fait « à la main »). * Que l'expéditeur s'assure que ses messages soient crédibles, pour diminuer le risque qu'ils soient jetés sans autre forme de procès. Cela implique notamment une authentification SPF et/ou DKIM correcte. * Que l'expéditeur soit bien conscient qu'un traitement effectif des rapports reçus a un coût pour le destinataire et qu'il fasse donc attention à produire des rapports techniquement corrects et factuellement sérieux. * Que l'expéditeur n'envoie pas automatiquement des rapports sur la base d'une analyse automatique. Les logiciels de classification peuvent se tromper et prendre pour du spam ce qui n'en est pas. Il serait anormal de générer un spam (le rapport ARF) en échange d'un message qui n'en est pas un. (Je vois au boulot pas mal de rapports violant cette règle, réalisés en format ARF ou pas, qui sont manifestement automatiquement émis par un logiciel, et un logiciel particulièrement débile en plus.) La section 5 de notre RFC recommande d'utiliser plutôt les messages identifiés comme spam par un humain, ou bien ceux reçus par un pot de miel. * Que le MUA, s'il fabrique des rapports ARF, les envoie au fournisseur de service de l'utilisateur, *pas* au supposé responsable du message abusif. Actuellement, il existe plusieurs logiciels qui automatisent partiellement l'envoi de messages de plainte et qui, pour trouver le destinataire, font des requêtes whois au petit bonheur la chance (par exemple pour tous les AS sur le chemin suivi), avant d'envoyer la plainte à dix ou quinze adresses dont la plupart ne sont en rien responsables du message abusif. La bonne pratique est donc d'envoyer à son fournisseur, charge à lui de faire suivre intelligemment. Pour cela, il devra compter sur diverses heuristiques mais, au moins, il sait les utiliser. * Que le rapport soit correctement rempli, indication du bon Feedback-TYpe: (RFC 5965, section 3.1), indication de toutes les informations pertinentes, etc. Par contre, pas besoin d'hésiter avant de choisir le format ARF : les rapports qui suivent ce format sont lisibles manuellement, même si le destinataire n'a pas de logiciel adapté. * Que le destinataire agisse, sur la base des rapports corrects. Il existe des tas de rapports incorrects (envoyés au mauvais destinataire, par exemple) et le format ARF permet d'automatiser une partie du triage. Par exemple, le FAI peut regarder l'en-tête Source-IP: du rapport et jeter sans autre forme de procès les rapports où ladite adresse IP source ne fait pas partie de ses préfixes IP. Malgré cela, il y a quand même des rapports corrects ce qui ne signifie pas qu'ils seront lus <http://www.bortzmeyer.org/abuse-ne-repond-pas.html>. Le RFC discute également de la délicate question de la réponse : faut-il signaler à l'envoyeur du rapport que son message a été lu et qu'on a agi ? (Actuellement, même si les rapports d'abus sont traités, l'utilisateur ne reçoit jamais de retour.) La conclusion est que ce serait souvent une bonne idée que de signaler à l'émetteur du rapport qu'il n'a pas travaillé pour rien. Les recommandations précédentes concernaient surtout les rapports envoyés en réponse à un message abusif, du spam par exemple. La section 6 couvre les rapports signalant un problème d'authentification, avec SPF ou DKIM. Ces rapports utiliseront le Feedback-Type: auth-failure (RFC 6591) et sont normalisés dans des documents comme le RFC 6652 et le RFC 6651. Les demandes pour cette section sont : * Qu'on n'envoie de tels rapports qu'à ceux qui les demandent, et aux adresses de courrier qu'ils ont indiqué, * Qu'on n'envoie pas de rapport ARF pour un problème d'authentification d'un rapport ARF (pour éviter les boucles). C'est aussi pour éviter ces boucles que le rapport doit être envoyé avec un MAIL FROM vide (plus exactement ayant la valeur <>), * Qu'on fasse attention aux attaques avec amplification. Il ne faut pas qu'un méchant fabrique un faux, juste pour que l'échec de l'authentification de ce faux déclenche l'émission d'un gros rapport ARF à destination d'un pauvre FAI qui n'y est pour rien. Quelques pièges de sécurité peuvent attendre les utilisateurs du format ARF. La section 8 en fait le tour. D'abord et avant tout, les rapports ARF peuvent être des faux, fabriqués de A à Z (afin, par exemple, de faire accuser un innocent). La confiance qu'on leur accorde doit dépendre de l'authentification de l'émetteur et de la confiance qu'on accorde à cet émetteur. (C'est un problème ancien, voir par exemple la section 4.1 du RFC 3464.) Le modèle originalement envisagé pour ARF était celui du rapport déclenché manuellement ; un utilisateur se plaint, il clique sur le bouton « Ceci est un spam », le message est transmis au fournisseur de messagerie qui fabrique un rapport ARF et l'envoie. Le rythme d'envoi des rapports restait donc limité. Au contraire, les évolutions récentes d'ARF, notamment pour le signalement de problèmes d'authentification, vont vers des rapports déclenchés automatiquement. Un message arrive, le test SPF échoue, paf, un rapport ARF est généré et envoyé. Cela peut mener à des rythmes d'envoi bien plus grands, qui peuvent dépasser les capacités de réception et de traitement du destinataire. C'est d'autant plus ennuyeux qu'un attaquant vicieux pourrait générer exprès des problèmes d'authentification, pour déclencher ces envois massifs. Il peut donc être raisonnable de limiter le débit d'envoi de tels rapports. Autre façon de traiter ce problème : ne pas envoyer un rapport par incident. Le format ARF prévoit (RFC 5965, section 3.2) d'indiquer dans le rapport combien d'incidents similaires il couvre (champ Incidents:). On peut donc choisir, par exemple, de n'envoyer qu'un rapport pour N incidents ou, mieux de faire une décroissance exponentielle (un rapport par incident pour les 10 premiers, un rapport par série de 10 incidents pour les 100 suivants, etc). --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
