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éeIUT 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 2Remerciements 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 43.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 5Chapitre 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 62) 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 74) 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 8II) 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 9soit 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 10option 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 113) 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 12III) 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 13Ensuite 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 14Chapitre 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 15II) 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 16Figure 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 17suite. 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 18III) 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 19Le 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 20Il 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 212) 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 222.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 24Figure 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 25plusieurs 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 263) 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 27IV) 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 28Chapitre 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 292) 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 30Vous pouvez aussi lire