Développement d'un plugin Thunderbird pour le signalement des spams non détectés

 
CONTINUER À LIRE
Développement d'un plugin Thunderbird pour le signalement des spams non détectés
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
Développement d'un plugin Thunderbird pour le signalement des spams non détectés
Rapport de stage - Hervé LASCAUX | IUT Vannes   Page   1
Développement d'un plugin Thunderbird pour le signalement des spams non détectés
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
Développement d'un plugin Thunderbird pour le signalement des spams non détectés
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
Développement d'un plugin Thunderbird pour le signalement des spams non détectés
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