Développement d'un plugin Thunderbird pour le signalement des spams non détectés
←
→
Transcription du contenu de la page
Si votre navigateur ne rend pas la page correctement, lisez s'il vous plaît le contenu de la page ci-dessous
IUT DE VANNES Hervé LASCAUX Département Informatique Groupe C BP 561 Enseignant tuteur : Didier Bogdaniuk 56017 VANNES CEDEX Développement d’un plugin Thunderbird pour le signalement des spams non détectés Stage au CRU (Comité Réseaux des Universités) Stage effectué du 04 avril 2011 au 16 juin 2011 en vue de l’obtention de du DUT Informatique, sous la responsabilité de : Serge Aumont – Membre de la cellule technique du CRU Au sein du service : CRU (Comité Réseau des Universités) Centre de Ressources Informatiques 263 Avenue du General Leclerc Campus Beaulieu 35042 Rennes CEDEX IUT Vannes – Département Informatique 2ème année
IUT DE VANNES Hervé LASCAUX Département Informatique Groupe C BP 561 Enseignant tuteur : Didier Bogdaniuk 56017 VANNES CEDEX Développement d’un plugin Thunderbird pour le signalement des spams non détectés Stage au CRU (Comité Réseaux des Universités) Stage effectué du 04 avril 2011 au 16 juin 2011 en vue de l’obtention de du DUT Informatique, sous la responsabilité de : Mr Serge Aumont – Ingénieur réseau au Comité Réseau des Universités Au sein du service : CRU (Comité Réseau des Universités) Centre de Ressources Informatiques 263 Avenue du General Leclerc Campus Beaulieu 35042 Rennes CEDEX Rapport de stage - Hervé LASCAUX | IUT Vannes Page 2
Remerciements Je tiens à remercier : -Tout d'abord, Monsieur Serge Aumont, mon maître de stage dans le service, pour l'encadrement qu'il m'a apporté et pour l'intégration dans le service. -Les autres membres de l'équipe, pour le soutient qu’ils m’ont fournit en répondant à mes questions et en m'aidant lorsque je rencontrais des difficultés ainsi que pour leur accueil au sein de l'équipe et leur aide pour m'intégrer. -Et enfin, mon tuteur de stage à l'IUT, Monsieur Didier Bogdaniuk, pour le suivi de mon stage durant ces deux mois et demie. Rapport de stage - Hervé LASCAUX | IUT Vannes Page 3
Table des matières Remerciements.....................................................................................................................3 Chapitre 1 : Introduction I) Présentation du service ..................................................................................................6 1) Histoire du CRU ..........................................................................................................6 2) Missions du CRU .........................................................................................................7 3) Les domaines d'activités du CRU ................................................................................7 4) Le projet de fusion dans RENATER..............................................................................8 II) Description du sujet de stage ........................................................................................9 1) Contexte et problème .................................................................................................9 2) Le sujet .................................................................................................................... 11 3) Evolution du sujet .................................................................................................... 12 III) Démarche adoptée pour atteindre les objectifs ....................................................... 13 Chapitre 2 : Développement du plugin I) Sujet, objectifs du plugin et déroulement du projet ................................................... 15 II) Les outils et langages de développements.................................................................. 16 1) Les outils ................................................................................................................. 16 2) Les langages ............................................................................................................ 17 III) Le déroulement du projet en détails ........................................................................ 19 1) Analyse du sujet et première approche du développement d’un plugin .................. 19 2) Développement du plugin ....................................................................................... 22 2.1) Envoi d’un mail et par la méthode POST .............................................................. 22 2.2) Fenêtre des préférences du plugin ...................................................................... 23 2.3) Récupération et actions sur les messages sélectionnés ....................................... 24 2.4) Ajout du feedback ............................................................................................... 25 3) Les tests et la finalisation du projet......................................................................... 27 Rapport de stage - Hervé LASCAUX | IUT Vannes Page 4
3.1) Les test ................................................................................................................ 27 3.2) La finalisation ...................................................................................................... 27 IV) Diffusion du plugin .................................................................................................. 28 1) Diffusion d’une version préconfiguré pour RENATER ........................................... 28 2) Dépôt sur le site des modules complémentaires de Mozilla .................................... 28 3) Présentation aux JRES .............................................................................................. 28 Chapitre 3 : Traitement des signalements I) Le sujet, les objectifs et le déroulement du projet ...................................................... 29 II) Les outils et langages de développement ................................................................... 29 1) Les outils ................................................................................................................. 29 2) Les langages ............................................................................................................ 30 III) Déroulement du développement en détails ............................................................. 30 1) La réception des messages ...................................................................................... 30 2) Tri des signalements ............................................................................................... 32 3) Récupération et escalade des signalements ............................................................ 34 4) Mise en place d'indicateurs...................................................................................... 36 Chapitre 4 :Conclusion I) Résultats ..................................................................................................................... 39 II) Projection dans l’avenir pour l’évolution de mon travail ............................................. 40 III) Bilan personnel ........................................................................................................ 40 I) Lexique ....................................................................................................................... 42 II) Table des figures ........................................................................................................ 43 III) Texte associé au poster proposé au JRES................................................................. 44 report-spam, un plugin Thunderbird pour escalader les anomalies de filtrage antispam ...................................................................................................................................... 44 Le plugin reportSpam ................................................................................................. 44 Traitement des signalements dans le cas de RENATER ............................................... 46 Rapport de stage - Hervé LASCAUX | IUT Vannes Page 5
Chapitre 1 : Introduction I) Présentation du service Le CRU (Comité Réseau des Universités) est une cellule technique dépendante du ministère de l’enseignement supérieur et de la recherche. Elle est chargée de missions nationales dans le domaine réseau. 1) Histoire du CRU Le CRU ou Comité Réseau des Université est basé à Rennes au Campus de Beaulieu. Le CRU est apparu en 1990 pour accompagner le démarrage de RENATER (REseau NAtional de Télécommunications pour la Technologie l'Enseignement et la Recherche) assurer des fonctions de veille et de formation ainsi que de représenter l'Enseignement Supérieur dans différentes instances. En 2011, l'effectif de l'équipe CRU est de 12 personnes. Les missions assurées se sont développées tout en restant finalement proches de celles définies lors de la création du CRU. Rapport de stage - Hervé LASCAUX | IUT Vannes Page 6
2) Missions du CRU Les principales missions du CRU sont : Le suivi des évolutions techniques du réseau RENATER, des réseaux de collecte et des réseaux de campus en termes d’architecture, de technologies déployées et de services innovants, adéquation du réseau aux besoins de ses utilisateurs ; La sécurisation et la fiabilisation des services réseau, ainsi que l’élaboration et la promotion des recommandations, formations à la sécurité, soutien aux correspondants RSSI et animation de leur réseau métier ; L’organisation de cycles de formation, de journées thématiques et de la conférence biennale JRES; La veille technologique notamment dans le domaine des logiciels et du Middleware (annuaires, fédération d’identité, gestion des authentifications, environnements pour la mobilité, etc.) avec animation de groupes de travail associant les établissements ; La promotion des usages émergents (vidéoconférence, outils de travail collaboratif, téléphonie sur IP, systèmes d’information interactifs, etc.); Le développement et la mise en œuvre de services réseaux reconnus d’intérêt commun et justifiant une mutualisation nationale ; De représenter les établissements d'enseignement supérieur français au niveau européen (TERENA) et international (notamment Internet2). Le CRU travaille donc en relation avec de nombreux organisme comme des partenaires du la communauté enseignement ou recherche tel que notamment RENATER précisé plus. Mais le CRU a également d’autres partenaires tels que le service du HFDS (Haut Fonctionnaire de Défense et de Sécurité) ou encore la CPU (Conférence des Présidents d’Université). 3) Les domaines d'activités du CRU Les différents domaines d’activités du CRU sont : Les services La veille La formation, le conseil Les produits Rapport de stage - Hervé LASCAUX | IUT Vannes Page 7
4) Le projet de fusion dans RENATER Les évolutions du ministère de tutelle mais aussi le passage à l'autonomie des établissements d'enseignement supérieur et recherche ont conduit à une réflexion sur le pilotage des activités du CRU et son rattachement à un opérateur de l'état pour développer et assurer la pérennité des actions du CRU. Techniquement, l'université de Rennes 1 reste l'établissement hôte des personnels basés à Rennes. Des conventions entre le ministère de la recherche, cette université et RENATER définissent la mission générale et les moyens qui y sont consacrés. Cette nouvelle étape pour le CRU doit être l'opportunité de déployer les services existants auprès de l'ensemble des bénéficiaires de RENATER et non seulement aux seuls établissements d'enseignement supérieur et de recherche. Rapport de stage - Hervé LASCAUX | IUT Vannes Page 8
II) Description du sujet de stage 1) Contexte et problème Le projet qui alimente mon stage est la création d’un plugin (cf. Annexe I) afin de signaler simplement les spams (cf. Annexe I) et les «faux positifs» (cf. Annexe I), pour Mozilla Thunderbird, un client de messagerie puissant et personnalisable. C’est un logiciel libre développé par Mozilla (qui développe également le navigateur web Firefox). Thunderbird supporte les protocoles IMAP et POP ainsi que le formatage des messages en HTML. Il possède également un filtre du courrier indésirable. Ce filtre implémenté dans le client de messagerie est insuffisant dans les grandes organisations telles qu’une université car il suppose un travail de configuration et de maintenance régulier sur chaque poste de consultation de la messagerie. En outre, il intervient après que les messages polluants aient pénétré dans l’infrastructure de l’établissement. Il est préférable de mutualiser le filtrage antispam au minimum au niveau du domaine de messagerie. Ainsi, une administration centralisée de cette fonction fondamentale du service de messagerie garantie une qualité identique à tous les utilisateurs. En bloquant une part importante des spams à la périphérie du domaine de messagerie, ce filtrage contribue à la protection de l’infrastructure de ce service. Cependant, il y a toujours des erreurs du système de filtrage. Des spam échappent aux différentes techniques de détection, plus grave certains messages licites (on les appelle « ham ») sont abusivement marqués comme étant des spams. On parle alors d’un "faux positif » Plus concrètement, en plus de la gestion des spam par Thunderbird, au CRU (et dans d’autres établissements tel que l’UBS), les messages reçus sont également filtrés par RENATER. Ce filtre agit de trois façons différentes : soit il bloque la connexion SMTP (cf. Annexe I) entrante directement par exemple parce qu’il reconnait une adresse IP qui est connue pour émettre des spams (utilisation de blacklists), Rapport de stage - Hervé LASCAUX | IUT Vannes Page 9
soit il effectue un traitement sur le contenu du message et détermine que le message est spam et le bloque (par exemple il reconnaît une publicité pour du Viagra). soit le message est transmis au destinataire. Dans ce cas, le service antispam marque certains messages comme des spams mais les transmets malgré tout car le traitement de ces messages n’est pas sur à 100%. Il offre donc la possibilité au destinataire de reconnaître le message tout en l’avertissant du caractère présumé de spam. Figure 1 – Schéma du fonctionnement du service antispam de RENATER Le problème qui alimente mon sujet de stage est donc comment améliorer ce filtrage afin de reconnaître le plus efficacement possible les spams des hams. La solution est de signaler au service antispam de RENATER les «faux négatifs» : spams qui n’ont pas été détectés et les «faux positifs» : messages indument marqués comme étant du spam. Ce signalement des erreurs de filtrage ne peut être fait que par les destinataires des messages seuls à même de relever les erreurs du processus automatique appliqué en protection de leur boite aux lettres. Cette boucle de retour est un élément indispensable du service sans lequel aucun indicateur de qualité ne peut être construit. La qualité du service dépend donc fortement de la coopération des utilisateurs. Il est donc indispensable que les signalements puissent être faits aussi facilement que possible. L’objectif de ce plugin est de permettre grâce à un simple bouton ou une Rapport de stage - Hervé LASCAUX | IUT Vannes Page 10
option dans le menu du clic-droit afin d’effectuer dans de bonne condition un signalement des « faux positifs » et des « faux négatifs ». 2) Le sujet Le sujet de mon stage était donc la création de ce plugin pour Thunderbird. Il était nécessaire que le plugin soit portable (fonctionne sous Windows, MacOs, et Linux). De plus ce plugin devait être simple d’utilisation et capable de s’adapter aux messages afin de signaler les spams et mes «faux positifs». Pour signaler ces spam non-détectés aussi appelés «faux négatifs», le premier objectif de ce plugin était d’envoyer un e-mail sous le format ARF (Abuse Report Format) contenant le message non-reconnu. En consultant les plugins déjà existant, une autre option de signalement est alors apparue comme une seconde possibilité afin de peut-être faciliter le traitement de ces messages contenant les spam non- reconnus. Celle-ci serait de transmettre les messages par la méthode POST vers un serveur web. L’interface souhaitée pour ce plugin est un bouton dans la barre d’outils séparant la liste des messages et le contenu d’un message (header toolbar) ainsi qu’une nouvelle option dans le menu du clic-droit qui permettrait de signaler plusieurs spams en même temps en sélectionnant tous les spams et en cliquant sur « Signaler le(s) message(s) comme spam ». Le second objectif de ce plugin était le signalement des «faux positifs». La première idée était de modifier le bouton de signalement de spams en fonction d’un en-tête dans le message qui est présent lorsqu’un message est détecté comme un spam, la seconde solution serait d’utiliser un système de pop-up selon que le message sélectionné soit marqué comme étant un spam ou non. Enfin la dernière solution était l’ajout d’un second bouton pour signaler les «faux positifs». Ainsi un message de signalement serait envoyé à une adresse différente de celle pour les signalements de spams. Rapport de stage - Hervé LASCAUX | IUT Vannes Page 11
3) Evolution du sujet - L’objectif du sujet était l’envoie d’un mail contenant en pièce jointes le message à signaler. Cependant en parcourant les plugins déjà existant, une autre manière de signaler ces messages était l’utilisation de la méthode http POST. C’est-à-dire l’envoie du message à signaler vers un serveur web. - Le sujet de stage a ensuite évolué vers une seconde partie, le traitement des signalements. C’est-à-dire la réception des messages, leur traitement en fonction de leur type (spams, «faux positifs» ou UCE (cf. Annexe I)) et l’escalade de ces messages vers le service antispam de RENATER. Mon stage a ainsi été découpé en 2 parties distinctes : le développement du plugin et le traitement des signalements reçus. Figure 2 - Le plugin et le traitement des signalements Ce schéma représente le placement du plugin ‘reportSpam’ et du traitement des signalements par rapport au service actuellement mis en place au CRU et dans de nombreux autres établissements. Rapport de stage - Hervé LASCAUX | IUT Vannes Page 12
III) Démarche adoptée pour atteindre les objectifs La première étape de cette démarche était d'étudier le logiciel Mozilla Thunderbird sur lequel portait le sujet du stage. Il fallait étudier le fonctionnement de celui-ci, le langage dans lequel il est écrit, afin de bien analyser la faisabilité des objectifs fixés. Il était également nécessaire de rechercher d'autres plugins et de me documenter sur le développement de ceux-ci pour savoir quels langages utiliser et quelle structure a un plugin pour Thunderbird. Une autre étape était de chercher des plugins dont les fonctions se rapproche de celles que je devais mettre en place dans le cadre de mon stage. Après ces deux étapes, une discussion avec mon maitre de stage était nécessaire afin d’évaluer les différents points qui nous semblaient réalisables en fonction des possibilités et du temps impartis pour le stage. L'étape suivante a été le début du développement du plugin avec pour commencer des tests d'utilisations de plugins. Ensuite le codage d'un plugin simple puis l’ajout des actions au plugin. Durant cette étape des nombreux échanges avec le tuteur de stage, mais également avec l'administrateur du service antispam de RENATER et d'une autre personne intéressée par ce projet, étaient nécessaires. En effet, les critiques étaient indispensables afin de faire avancer le projet, de corriger certains aspects et de l’améliorer. Après avoir déjà bien avancé le plugin, mon maître de stage m’a donné une seconde mission, le traitement des messages reçus. La première étape a été la création d’une machine virtuelle : report-spam crée par un autre membre de l’équipe et qui, avec mon maître de stage, m’a aidé à faire les premières configurations de la machine. La seconde étape était d’analyser et de modifier du code développé par le CRU qui permet de récupérer les messages et de les stocker dans un spool. Pour le traitement des messages il fallait donc pouvoir les réceptionner en fonction de l’adresse qui définit si le message signalé est un spam ou un ‘faux positif’. Rapport de stage - Hervé LASCAUX | IUT Vannes Page 13
Ensuite il a fallut exploiter le daemon (cf Annexe I) de Sympa qui prend les messages dans le spools, les traite et les déplace. En se basant sur ce code et en le nettoyant de toutes les parties inutiles pour le traitement à effectuer sur les signalements, nous avons obtenu un démon qui permet d’accéder aux messages du spool. L’étape suivante était de modifier le code afin de traiter chaque message et de vérifier la pertinence du signalement avant de le déplacer vers des folder IMAP utilisés pour escalader les anomalies du filtrage vers l’opérateur du service antispam de RENATER. La dernière étape était la validation du plugin sur le site de Mozilla add-on pour vérifier si il n’y avait pas d’erreur dans le plugin et pour finir la proposition du plugin sur le site afin qu’il soit rajouter la liste. Rapport de stage - Hervé LASCAUX | IUT Vannes Page 14
Chapitre 2 : Développement du plugin I) Sujet, objectifs du plugin et déroulement du projet Mon sujet de stage consiste donc dans le développement d’un plugin qui serait installé dans Thunderbird et diffusé dans les établissements utilisant le service antispam de RENATER, mais également sur le site de Mozilla add-on : https://addons.mozilla.org/fr/thunderbird/, afin que d’autres personnes, qui n’utilisent pas le même service antispam puissent s’en servir avec une configuration des adresses différents. La diffusion sur le site de Mozilla add-on permet aussi aux personnes qui voudraient l’améliorer de faire évoluer le plugin, afin que même après mon stage, le plugin ne cesse d’être améliorer. Les objectifs étaient donc de réaliser un plugin : simple d’utilisation qui permet de signaler les spams et «faux positifs» par mail au service antispam qui puissent s’adapter à un en-tête afin de changer le type de signalement qui permette l’automatisation de plusieurs moyens de gestion des spams utilisés par Thunderbird. C’est-à-dire, marquer le message comme indésirable ou déplacer le message dans la corbeille. Le développement de ce plugin était le sujet principal de mon stage. Ainsi, obtenir un plugin fonctionnel, efficace et répondant aux objectifs précédent était l’élément principal de mon stage et celui sur lequel j’ai passé le plus de temps. Le projet s’est déroulé en plusieurs étapes : Première étape : Préparation et analyse du sujet Deuxième étape : Première approche du développement de plugin pour Thunderbird Troisième étape : Développement du plugin Quatrième étape : Phase de test, résolution des problèmes et amélioration du plugin Cinquième étape : Finalisation du projet, diffusion du plugin Rapport de stage - Hervé LASCAUX | IUT Vannes Page 15
II) Les outils et langages de développements 1) Les outils Afin de développer ce plugin, mon maître de stage m’a installé à un poste de travail sous Linux possédant tous les outils nécessaires tels que l’éditeur de texte gedit ou encore emacs, ainsi que le navigateur web Mozilla Firefox et surtout le client de messagerie Mozilla Thunderbird pour lequel je devais développer le plugin. Un compte de messagerie m’a donc été créé pour le stage : herve.lascaux@cru.fr afin de pouvoir communiquer avec mon maître de stage, les autres membres de l’équipe et de pouvoir tester le plugin dans les conditions d’utilisations du CRU. Des identifiants et un mot de passe m’ont été attribués pour pouvoir accéder au wiki du CRU et ainsi pouvoir me créer une page pour le suivi de mon projet : https://www.cru.fr/activites/spam/stage/index. Nous avons ensuite créé un projet sur une forge : « SourceSup » afin que je puisse accéder à un serveur subversion pour déposer mon travail. Pour les outils propres au développement du plugin, aucun logiciel en particulier n’est nécessaire, un simple éditeur de texte tel que gedit ou emacs suffit. Il faut aussi un outil pour compresser les fichiers avec l’extension ‘.zip’. J’ai également trouvé un plugin pour Thunderbird, DOM Inspector, qui est un outil très pratique puisqu’il permet d’analyser la structure du logiciel, c'est-à-dire de visualiser et d’analyser les différents blocks du logiciel et leur code. Rapport de stage - Hervé LASCAUX | IUT Vannes Page 16
Figure 3 - DOM Inspector Sur cette image, on peut voir un cadre rouge en haut qui correspond à l’objet sélectionné dans le logiciel Thunderbird. La seconde fenêtre est la fenêtre du plugin DOM Inspector avec à gauche, la liste des éléments graphiques et leur emboitement. A droite, la liste des attributs de l’objet sélectionné. 2) Les langages Plusieurs langages sont nécessaires pour développer un plugin Thunderbird. Le premier est le XUL ou XML-Based User interface Language. C’est un langage de description d’interfaces graphiques fondé sur XML créé dans le cadre du projet Mozilla. XUL se prononce « zoul » en anglais. XUL comprend un ensemble de balises permettant de définir des boutons, des listes, des menus, ou encore des zones d’édition, en bref tous les éléments d’une véritable interface utilisateur. Une fenêtre XUL est conçue comme un emboîtement de « boîtes » rectangulaires. Une boîte contient des sous-éléments qui sont juxtaposés soit verticalement, soit horizontalement. Ces sous-éléments peuvent être des champs de type texte, des listes déroulantes, des champs affichant du code HTML, et ainsi de Rapport de stage - Hervé LASCAUX | IUT Vannes Page 17
suite. Ces sous-éléments peuvent aussi être des boîtes, qui elles-mêmes contiendront d’autres éléments. À l’intérieur de chaque boîte, divers paramètres permettent de paramétrer facilement l’alignement des sous-éléments (à gauche, en haut, centré…) ainsi que leur comportement en cas de redimensionnement de la fenêtre (taille fixe, taille proportionnelle…). On peut ainsi donner à une balise un ‘id’ ou une ‘class’ ce qui permet à l’affichage graphique d’être configuré en utilisant une feuille de style CSS. D’autre attribut comme ‘label’ ou ‘value’ permet de donner un texte à un élément. L’outil DOM Inspector présenté ci-dessus (cf. figure 2) permet ainsi de connaitre le type de balise utilisé pour un élément graphique et les valeurs des attributs de cette balise. Le second langage utilisé dans le développement d’un plugin pour Thunderbird est le JavaScript. En effet, afin de pouvoir associer aux éléments graphiques un événement (clic de souris, etc). Le JavaScript est un langage exécuté coté client. JavaScript est, à ce jour, un composant majeur des sites web utilisant du HTML dynamique et des interactions serveur en mode Ajax. Il est aussi utilisé pour les interactions dans les langages d'interfaces graphiques basés sur XML tels que XUL et XAML. On peut donc grâce à ce langage, donner une action aux éléments graphiques crées en XUL grâce à l’attribut ‘oncommand’ qui permet d’exécuter du script. Grâce à l’interface ‘Node’ on peut accéder à la structure d’un document HTML, XML et donc XUL, vu comme une arborescence d’éléments, et de modifier cette structure. Ainsi, ‘Node’ représente un nœud dans l'arborescence des éléments qui composent le document. On peut créer un nœud, lui ajouter des sous-éléments, et l'intégrer à un autre nœud de l'arborescence. On peut aussi accéder à un nœud quelconque de l'arborescence, grâce aux méthodes de document ‘getElementById()’ qui retourne un ‘Node’, ou ‘getElementsByTagName()’ qui retourne une liste de nœuds. Il est donc également possible de modifier les attributs d’un élément graphique en accédant au nœud grâce à son identifiant. Rapport de stage - Hervé LASCAUX | IUT Vannes Page 18
III) Le déroulement du projet en détails 1) Analyse du sujet et première approche du développement d’un plugin Après m’être installé à mon poste de travail et avoir configurer les différents outils de développement dont j’aurais besoin pour la suite du stage, j’ai débuté l’analyse du sujet de stage pour étudier la faisabilité des différents objectifs. Pour cela j’ai du me renseigner sur les différents plugins existants afin de trouver des plugins qui pourraient effectuer des fonctions qui m’intéressent comme envoyer un mail, déplacer un message vers la corbeille ou encore le marquer comme indésirable. J’ai donc trouvé plusieurs plugins dont je pourrais m’inspirer pour débuter le projet. J’ai ainsi pu confirmer la faisabilité de l’objectif principal du projet qui était d’envoyer un mail contenant en pièce jointe le message à signaler. J’ai ensuite commencé à travailler sur le développement du plugin en lui-même. Ainsi j’ai fait des recherches sur les langages de développement de plugin, leur structure et comment les installer. Les extensions pour Thunderbird sont des archives ‘.zip’ renommé en ‘.xpi’. Une fois extraite, l’archive contient différents fichiers et dossiers et donc une structure bien spécifique. Cette structure est de la forme : .xpi : /install.rdf /defaults /defaults/preferences/< NomDuPlugin>.js /chrome.manifest /chrome/ /chrome/content/ Figure 4 - Structure d'un plugin Rapport de stage - Hervé LASCAUX | IUT Vannes Page 19
Le fichier install.rdf contient toutes les informations concernant le plugin et nécessaires à son installation, c'est-à-dire, l’identifiant et le nom du plugin, le créateur, la version du plugin, l’application visé (pour celui-ci Thunderbird) avec la version minimum et la maximum de l’application pour lequel le plugin est adapté, une description du plugin, le lien vers l’icône du plugin, vers le fichier d’option du plugin et d’autres informations optionnelles. Le fichier chrome.manifest permet lui de définir des liens vers différents fichiers avec les fichiers de Thunderbird pour pouvoir créer les boutons par exemple. Il contient aussi un lien vers la feuille de style et vers d’autres fichiers importants de l’application. Le dossier defaults/preferences contient les préférences du plugin par défaut, c'est- à-dire les préférences utilisées lors de l’installation du plugin. Pour le dossier ‘chrome/’, celui-ci peut contenir d’autres dossiers que ‘content/’ qui serviront au style du plugin avec des fichiers .css exactement comme pour des pages html, ainsi que les images nécessaires pour les plugins comme l’icône du plugin et du bouton créer par le plugin. Il peut aussi contenir un dossier ‘locale/’ afin de gérer la langue du plugin. Le dossier chrome/content contient lui, tous les fichiers de code du plugin. En effet, on peut retrouver dans ce dossier des fichiers .xul et des fichiers .js. Pour installer le plugin il suffit de compresser l’ensemble des fichiers dans une archive au format .zip, de la renommer en .xpi et ensuite dans la gestion des modules complémentaires ou add-on de Thunderbird de cliquer sur ‘installer’ et de sélectionner l’archive. Une fois cette action faite il est nécessaire de redémarrer le programme pour pouvoir utiliser le plugin. Ensuite j’ai étudié le code de différents plugins afin de bien comprendre le fonctionnement de ceux-ci. Ainsi j’ai compris comment rajouter un bouton à une barre d’outils ou comment rajouter un objet dans le menu du clic-droit. Pour cela il faut créer un fichier .xul contenant un nœud ‘overlay’ et dans ce nœud les nœuds des objets que l’on souhaite rajouter. Par exemple, afin de créer un objet dans le menu du clic-droit sur un message, il est nécessaire de rajouter dans le fichier ‘chrome.manifest’ une ligne qui permet de charger l’élément au lancement de l’application. overlay chrome://messenger/content/messenger.xul chrome:///content/Exemple.xul Rapport de stage - Hervé LASCAUX | IUT Vannes Page 20
Il faut ensuite ajouter le code suivant dans le fichier ‘Exemple.xul’ : Figure 5 - Exemple de code pour l'ajout d’un objet dans le menu du clic-droit On voit ici que pour ajouter un objet à un élément graphique, il faut connaitre l’identifiant de cet élément. L’objectif était de placer un bouton dans la barre des tâches ‘header’, c'est-à-dire la barre se trouvant entre la liste des messages et le contenu du message et où apparait les boutons répondre, transférer, supprimer, etc. Pour cela, la balise à utiliser était : ‘toolbarbutton’. Il fallait alors trouver l’identifiant de cette barre dans laquelle placer le bouton. Je n’avais à ce moment là pas trouvé l’outil DOM Inspector, donc je n’avais aucun autre moyen de trouver le nom de cette barre des tâches que d’aller examiner le code source de Thunderbird. Grâce à cette analyse du code, j’ai pu bien comprendre comment était disposé les différents éléments. J’ai également réussi à trouver l’identifiant de la barre que je recherchais : ‘header-view-toolbar’. J’ai alors pu placer dans cette barre un bouton simple n’effectuant aucune action lors d’un clic un objet dans le menu du clic-droit. Figure 6 - Bouton et objet du clic-droit Rapport de stage - Hervé LASCAUX | IUT Vannes Page 21
2) Développement du plugin 2.1) Envoi d’un mail et par la méthode POST La suite de mon travail a alors été de donner une action à ce bouton. J’ai donc recherché dans les plugins qui existent déjà ceux qui pourraient m’être utiles afin de coder pour ce bouton une action qui se rapprocherait de la fonction souhaitée. J’ai alors trouvé dans ces plugins la façon d’ouvrir une fenêtre d’envoie de message avec un sujet, un destinataire et un corps de message. J’ai également trouvé dans un autre plugin une autre méthode afin de signaler les messages, celle-ci serait d’envoyer le signalement vers un serveur web grâce à la méthode http POST. J’ai donc commencé par mettre en place la fonction d’ouverture de fenêtre de composition de message. J’ai ensuite essayé d’envoyer un mail directement sans ouvrir la fenêtre de composition de message puisque le signalement doit pour l’utilisateur être réduit à un clic. Pour trouver le moyen d’effectuer cet envoie, j’ai consulté à nouveau le code de Thunderbird mais cette fois-ci la partie JavaScript. J’ai ainsi trouvé les fonctions JavaScript utilisé par Thunderbird pour envoyer un message : GenericSendMessage() et SendMsg(). Après avoir rencontré des problèmes pour récupérer des variables nécessaires pour utiliser ces fonctions, j’ai finalement réussi à m’envoyer un mail simple de test en cliquant sur le bouton. Cependant j’ai remarqué que certaines fonctions de Thunderbird ne fonctionnaient plus comme par exemple « supprimer un message » ou « enregistrer le message sous ». J’ai alors réussi à résoudre ce problème en redéfinissant une variable dans mon code et en supprimant l’appel au script qui contenait cette variable et les fonctions qui posaient problème. J’ai ensuite travaillé sur l’envoie par la méthode POST. Pour cette méthode je me suis principalement aidé d’un plugin : Signal-Spam, qui utilise cette technique et j’ai adapté la façon d’envoyer le message à nos besoins. Rapport de stage - Hervé LASCAUX | IUT Vannes Page 22
2.2) Fenêtre des préférences du plugin Ensuite j’ai travaillé sur la mise en place des préférences du plugin. Pour cela il ma fallu créer un autre fichier XUL : option.xul. Voici un extrait du code : Figure 7 - Extrait du code de option.xul Ici les balises utilisées sont d’abord ‘prefwindow’ qui permet la création de la fenêtre des préférences. Ensuite, les balises ‘preferences’ qui correspondent à toutes les préférences du plugin. On peut ainsi configurer plusieurs types de préférences : bool : Booléen qui prend la valeur vraie ou fausse (‘true’ ou ‘false’) int : Un entier string : Une chaine de caractère. Les balises ‘tabpanel’ permettent ensuite de créer des onglets. Par la suite on peut utiliser plusieurs éléments afin de récupérer les préférences de l’utilisateur comme des Rapport de stage - Hervé LASCAUX | IUT Vannes Page 23
‘checkbox’ pour les booléen ou des ‘textarea’ pour les chaines de caractères. Cette fenêtre d’options a évolué en fonction de l’évolution du plugin et des fonctions rajoutées afin de ressembler à la fenêtre suivante : Figure 8 - Fenêtre des préférences du plugin 2.3) Récupération et actions sur les messages sélectionnés Je me suis ensuite penché sur la façon de récupérer le ou les messages sélectionnés afin de les ajouter en pièces jointes au mail de signalement envoyé par le plugin. Voici le code qui permet la récupération des messages sélectionné et les ajoutent en pièces jointes : Rapport de stage - Hervé LASCAUX | IUT Vannes Page 24
Figure 9 - Code permettant de récupérer les messages et de les ajouter en pièces jointes Ici ‘gFolderDisplay’ est une variable de Thunderbird qui permet d’accéder au dossier courant. Ensuite ‘selectedMessageUris’ correspond aux URI (cf Annexe I) de tous les messages sélectionnés. On peut ensuite récupérer l’URL du message et ainsi créer un champ ‘attachment’ et l’ajouter au la variables ‘fields’ qui contiendra tous les champs du mail de signalement tel que le destinataire ‘To’ et le sujet du message ‘Subject’. Les messages sont ajoutés en pièces jointes avec le nom ‘reportSpam.eml’. Par la suite j’ai rajouté les fonctions qui permettaient de déplacer le ou les messages sélectionnés vers la corbeille ou de les marquer comme indésirables en réutilisant les fonctions de Thunderbird et en rajoutant le choix de ces préférences dans les options. 2.4) Ajout du feedback Après avoir fourni un plugin fonctionnel qui permettait de signaler les spams, on ma demandé de rajouter un feedback. En effet, dans sa première version, aucune information ne permet à l’utilisateur de savoir que son clic a été efficace et que le signalement est effectué. La réaction normale de l’utilisateur est de cliquer plusieurs fois sur le bouton de signalement. Mon choix a été de modifier le bouton de signalement afin de le rendre inactif après qu’un message ait été signalé. Le changement d’aspect du bouton informe et empêche de signaler le même message Rapport de stage - Hervé LASCAUX | IUT Vannes Page 25
plusieurs fois. Pour cela j’ai donc utilisé l’interface ‘Node’ qui permet d’accéder aux nœuds et ainsi de modifier leurs attributs : Figure 10 - Code permettant de modifier le bouton et l’objet du menu On rajoute ici dans les en-têtes locaux du message un en-tête ‘spamReported’ dont on met la valeur à ‘1’. Ensuite le plugin accède au bouton donc l’identifiant est ‘reportSpamButton’ et modifie ses attributs afin de le rendre inactif et de changer son texte, de même pour l’objet du menu du clic-droit. Ainsi lorsque l’on cliquera sur le message, un autre script pourra détecter si l’en-tête local existe et modifier le bouton. La dernière partie du développement du plugin a été la mise en place des signalements de «faux positifs». Pour cette fonctionnalité, je n’avais, la première fois que j’ai travaillé dessus, trouvé de moyens d’accéder aux en-têtes du message qui ne sont pas affichées. Cependant j’ai trouvé une préférence de Thunderbird qui me permettait de les récupérés lorsque le message est chargé : ‘mailnews.headers.extraExpandedHeaders’. J’ai ainsi pu rajouter dans les options du plugin la possibilité d’entrer le nom d’un en-tête et sa valeur ou une expression régulière contenu dans sa valeur. Puis le plugin modifie le bouton en fonction de si l’en-tête existe et que sa valeur contient l’expression régulière indiquée dans le plugin pour que l’utilisateur puisse signaler les «faux positifs». Rapport de stage - Hervé LASCAUX | IUT Vannes Page 26
3) Les tests et la finalisation du projet 3.1) Les test Durant le développement, j’ai réalisé de nombreux tests afin de tester chaque fonctionnalité du plugin que j’ai réalisé. Un des objectifs était que le plugin soit portable, c'est-à-dire qu’il fonctionne sur toutes les plateformes possédant Thunderbird. J’ai alors du tester ce plugin sur différents systèmes d’exploitation, principalement Linux qui était installé sur mon poste de travail, mais aussi sur Windows que je possède sur mon ordinateur personnel et sur MacOs. Pour ce dernier cas, un Mac m’a été prêté afin que je réalise ces tests. Une autre partie des tests était de diffuser le plugin, une fois que je possédais une première version fonctionnelle pour signaler les spams dans l’équipe du CRU, et en créant sur la page du wiki qui m’était attribué un tableau que les membres pourraient compléter avec les erreurs rencontrées et les améliorations possibles. Ces premiers tests m’ont été très utiles pour identifier les problèmes dès le début et pouvoir améliorer l’extension. Enfin, une dernière phase de test a eu lieu avec une version du plugin se rapprochant de la version final en le diffusant dans un groupe de personne intéressées par le plugin et qui utilise le service antispam de RENATER. Le plugin avait ainsi une configuration par défaut avec des adresses pour les signalements qui permettaient de recevoir les mails sur la machine virtuelle utilisée par la suite pour le traitement. 3.2) La finalisation La finalisation du plugin a été tout d’abord de rajouter l’anglais aux langues du plugin. Lors de l’installation d’un plugin, sa langue s’adapte à la version du Thunderbird sur laquelle il est installé. J’ai donc d’abord uniquement développé le plugin en français, puis j’ai rajouté la langue anglaise. Il est donc possible de rajouter d’autres langues au plugin. Afin de permettre une évolution du plugin j’ai rédigé une page d’administration qui explique comment rajouter une langue au plugin et comment produire une nouvelle version de celui-ci : https://www.cru.fr/activites/spam/stage/administration. Rapport de stage - Hervé LASCAUX | IUT Vannes Page 27
IV) Diffusion du plugin 1) Diffusion d’une version préconfiguré pour RENATER Pour la diffusion du plugin, le premier objectif était de le diffuser pour tous ceux qui utilisent le service antispam de RENATER. Ainsi le plugin sera diffusé avec une configuration par défaut compatible avec le service antispam de RENATER. 2) Dépôt sur le site des modules complémentaires de Mozilla Un autre objectif pour la diffusion de ce plugin était de le déposer sur le site de Mozilla add-on pour que celui-ci puisse être utilisé par d’autres utilisateurs. Mais également pour que le plugin puisse être amélioré par d’autres développeurs qui seraient intéressés. 3) Présentation aux JRES Le JRES, ou « journées réseaux », est une réunion de tous les acteurs qui contribuent au déploiement et à l’essor des nouvelles technologies de l’information et de la communication dans les établissements d’enseignement supérieur et de recherche. Site web de JRES : https://2011.jres.org/index Il est ainsi possible de proposés des contributions sous plusieurs formats : des présentations longues (35 mn) ; des présentations courtes (10 mn) ; des posters ; des démonstrations ; des tables rondes. Mon maître de stage a ainsi soumis un texte au comité de programme de JRES pour présenter le plugin sous la forme d’un poster dont je suis co-auteur. La proposition de poster a finalement été validée par le comité de programme de JRES. En annexe III, le texte associé au poster. Rapport de stage - Hervé LASCAUX | IUT Vannes Page 28
Chapitre 3 : Traitement des signalements I) Le sujet, les objectifs et le déroulement du projet Le sujet était d’automatiser le traitement des signalements effectués grâce au plugin par les personnes utilisant le service antispam de RENATER. Le but de cette automatisation est de permettre à l’administrateur du service de mettre à jour plus facilement la base de données. Les objectifs de ce traitement étaient : La réception des messages Le tri des signalements La récupération des pièces jointes et l’escalade des signalements vers le service antispam de RENATER La création d’indicateurs de qualité II) Les outils et langages de développement 1) Les outils Afin de développer l’automatisation des traitements des signalements, j’ai travaillé sur une machine virtuelle : report-spam, à laquelle je me connectais en ssh (cf Annexe I). Sur cette machine était alors installé sendmail afin de recevoir les mails. Ensuite pour le développement j’ai exploité le code de Sympa, un serveur de liste de diffusion développé par le CRU. Pour les outils de développement, j’ai utilisé l’éditeur de texte emacs afin d’écrire le code et l’interface web phpMyAdmin afin de gérer la base de données. Rapport de stage - Hervé LASCAUX | IUT Vannes Page 29
2) Les langages Les langages utilisés sont donc ceux utilisés dans le projet Sympa. Tout d’abord le langage C pour la réception et le stockage des messages. Le programme de réception des messages était déjà coder pour le projet Sympa. Il a alors fallu l’adapter pour recevoir les mails sur les deux adresses de signalements pour RENATER et nommer les fichiers en fonction de cette adresse. Le C est un langage de programmation impératif conçu pour la programmation système. Inventé au début des années 1970, le C est devenu un des langages les plus utilisés. De nombreux langages plus modernes comme C++, Java et PHP reprennent des aspects de C. Puis le Perl pour l’exploitation de ces messages. En effet, Sympa est développer en Perl. C'est un langage interprété, polyvalent, et particulièrement adapté au traitement et à la manipulation de fichiers texte, notamment du fait de l'intégration des expressions régulières dans la syntaxe même du langage. Le dernier langage utilisé a été le SQL pour les indicateurs. En effet, ceux-ci ont été stockés dans une base de données MySQL. Les modifications de cette base de données étaient effectuées en Perl à partir de ‘spam-report.pl’. III) Déroulement du développement en détails 1) La réception des messages Pour la réception des messages, j’ai donc reprit le code de ‘queue.c’, un programme permettant de recevoir des mails et de les ranger dans un spool (cf. Annexe I). Les modifications apportées sur le code ont principalement été une simplification et une modification du chemin du spool. Ainsi ce programme permet lorsqu’il reçoit un message de créer un fichier unique correspondant à ce message. Pendant la création du fichier, celui-ci commence par ‘T.’ afin de ne pas consommer les messages du spool qui sont en cours d’écriture durant le traitement. Ensuite les messages sont nommés de la forme Rapport de stage - Hervé LASCAUX | IUT Vannes Page 30
Vous pouvez aussi lire