Mémoire de fin d'études - Supinfo 2010 - La gestion du spam dans un système de marketing par...

LA GESTION DU SPAM DANS UN SYSTÈME

DE MARKETING PAR COURRIEL

Mémoire de fin d’études

SUPINFO Institute of Information Technology

Année académique 2009‐2010

Michaël Massé

Mémoire présenté en vue de

l’obtention du Titre SUPINFO.

[LA GESTION DU SPAM DANS UN SYSTÈME DE MARKETING PAR COURRIEL] 31 octobre 2010

Michaël Massé | Remerciements 2

REMERCIEMENTS

Je tiens à remercier mon responsable de stage Pascal Jarry, pour m’avoir permis

d’effectuer mon stage de fin d’études dans leur entreprise HPJ Solutions. Malgré tout le

travail qui l’occupait, il m’a encadré et apporté une aide aussi bien organisationnelle

que technique pendant toute la durée de mon stage.

Je remercie aussi tout le personnel de l’entreprise pour son accueil et plus

particulière Étienne Borel pour son aide et ses conseils durant ces six derniers mois.

Je souhaite aussi adresser mes remerciements Saïd Hini et à Pascal Lépine qui

m’ont permis de développer mes compétences et connaissances au sein de leurs

entreprises respectives Loyer Express et Atypic.

Enfin, je tiens à remercier l’ensemble des professeurs et intervenants de

SUPINFO, International University. Ils m’ont apporté les connaissances aussi bien

techniques qu’humaines nécessaires à l’élaboration et au bon déroulement de mon

stage.


Michaël Massé | Table des matières 3

TABLE DES MATIÈRES

INTRODUCTION 5

ENVIRONNEMENT DE TRAVAIL 7

Le secteur des Technologies de l’Information à Montréal 7

Présentation, Historique et Activités d’HPJ Solutions 8

Principaux clients 9

Ivanhoe Cambridge 9

Ordre des ingénieurs du Québec 9

Association des Employeurs Maritime 10

Le Groupe Vivavision 11

Société québécoise de la Schizophrénie 11

L’équipe 11

Quelle direction pour HPJ Solutions ? 13

Environnement technique 14

HPJCC ET LA GESTION DU SPAM 15

Pourquoi avoir choisi ce sujet ? 15

HPJCC, UNE SOLUTION DE MARKETING PAR COURRIEL 16

Description du projet et analyse du contexte 16

HPJCC, l’Interface 16

Le MailCenter 17

HPJCC VS MailChimp 17

Quelques points particuliers du projet 19

Sortie d’Hibernate du MailCenter 19

Analyse du problème 19

Choix et mise en œuvre de la solution 19

Bilan de la phase de mise en œuvre 20

Gestion du spam dans un système de marketing par courriel 20

Analyse du problème 20

Création de la liste de contrôle et sa mise en œuvre 20

Qu’est‐ce que le spam ? 20

Une législation longue à se mettre en place. 21

Préalables à une solution de marketing par courriel 27

Modifications de l’application et extensions envisagées 34

L’architecture physique 37

Gestion des listes de contacts 44

Surveillance et gestion des exceptions 48


Michaël Massé | Table des matières 4

Bilan post‐campagne 57

Bilan de la phase de mise en œuvre 61

BILAN 63

D’un point de vue Organisationnel 63

D’un point de vue Informatique 63

D’un point de vue Personnel 64

D’un point de vue Social 64

CONCLUSION 66

BIBLIOGRAPHIE 67

ILLUSTRATIONS 69

ANNEXES 78

Listes noires majeures et mineures 78


Michaël Massé | Introduction 5

INTRODUCTION

« Apprendre, c’est déposer de l’or dans la banque de son esprit » – Shad Helmstetter,

Le Pouvoir de motivation intérieure.

Un but précis à atteindre avant une date buttoir en suivant les exigences énoncées

entraînant un droit à l’erreur moindre. Cela pourrait qualifier un stage en entreprise

mais, comme l’illustre parfaitement cette citation, ce qui est à retenir, c’est surtout

l’enrichissante expérience acquise tout au long de cette période. En effet, un stage de

fin d’études est surtout un investissement pour le futur du stagiaire où il doit

compléter sa formation grâce à une intégration dans le monde du travail, et non pas

seulement la conclusion d’un cycle d’études.

Chaque étudiant inscrit au cursus Master 2 doit réaliser un stage de 6 mois en

entreprise du secteur informatique ou dans le service informatique d’une grande

entreprise. L’étudiant est sorti du cocon scolaire afin de lui permettre de prendre

s’immerger avec le secteur professionnel où il se destine à travailler pour

possiblement un grand nombre d’années mais également de tester ses possibilités

d’adaptation, de mettre en pratique les connaissances acquises durant la formation

qu’il a reçu et d’en rendre compte sous la forme d’une mémoire écrit et d’une

soutenance orale.

Pour ma part, j’ai réalisé mon stage au sein de la société HPJ Solutions, société située

au cœur de Montréal. Comme vous l’avez pu le remarquer mon stage s’est déroulé sur

5 mois du 31 Mai au 31 Octobre 2010. Cette durée vient du fait qu’au départ, j’aurais

dû effectuer mon stage de fin d’études au sein de Loyer Express mais les impératifs

économiques étant ce qu’ils sont en Amérique du Nord, j’ai dû changé d’entreprise car

celle‐ci ne pouvait plus me rémunérer. J’ai passé deux mois chez Loyer Express où j’ai

occupé le poste de chef de projet.

Au cours des prochaines pages, je vais vous présenter l’entreprise et une partie des

tâches que j’ai pu y effectuer.

Je commencerais par décrire mon environnement de travail avec une présentation

succincte du secteur des Technologies de l’Information et Communications (TIC) à

Montréal.

Par la suite, je vous parlerais plus précisément de l’entreprise avec entre autre son

historique, le diagramme de l’équipe et une description des principaux clients de celle‐

ci.

Ma principale tâche à HPJ Solutions est liée au projet interne de l’entreprise HPJCC qui

est une solution de marketing par courriel permettant à ses utilisateurs de rejoindre


Michaël Massé | Introduction 6

facilement leur clientèle tout en mesurant le résultat de leurs infolettres. J’ai eu

comme mission de reprendre le développement de cet outil mais plus particulièrement

de gérer l’aspect spam de ce projet. Je vous exposerais donc ce que j’ai mis en place et

ce qui sera mis en place dans un avenir proche afin de lutter contre le spam et de se

conformer aux lois en vigueur pour ce domaine. Effectivement, toutes les procédures

et outils n’ont pu être mise en place au cours de ces 5 mois car techniquement cela

n’était pas possible du fait qu’à chaque étape un moment de monitoring et de suivi

doit être observé afin de déterminer l’impact des modifications et les ajuster en

fonction de notre cahier des charges.

Pour terminer, j’effectuerais un bilan de mon expérience à HPJ Solutions avant de

conclure. Ce bilan portera sur quatre points de vue : organisationnel, informatique,

personnel et social.


Michaël Massé | Environnement de travail 7

ENVIRONNEMENT DE TRAVAIL

LE SECTEUR DES TECHNOLOGIES DE L’INFORMATION À MONTRÉAL

S’il est un secteur qui est important pour Montréal, c’est bien celui des Technologies

de l’Information et des communications (TIC).

Avec près de 120 000 emplois et plus de 5 000 entreprises privées, Montréal constitue

un chef de file mondiale de l’industrie des TIC. Le Grand Montréal possède de

nombreux atouts pour les entreprises qui souhaitent y faire des affaires :

Proximité du bassin technologique nord‐américain,

Accès à une main‐d’œuvre compétente et hautement qualifiée,

Qualité des infrastructures industrielles,

Important réseau d’universités et de centres de recherche,

Mesures fiscales qui favorisent la recherche et le développement,

Coûts d’exploitation avantageux.

Le fait que des acteurs majeurs internationaux comme IBM, Ericsson, Autodesk, DMR

Fujitsu, Electronic Arts, SAP ou Ubisoft soient établis dans le Grand Montréal montrent

bien l’attractivité de cette région.

Ces entreprises profitent des coûts d’exploitation parmi les plus concurrentiels et

avantageux en Amérique du Nord, d’un taux d’imposition des sociétés se situant dans

les plus bas en Amérique du Nord. De plus, la Recherche & Développement est

fortement soutenue grâce à de nombreux incitatifs fiscaux comme le Crédit d’Impôt

Recherche Scientifique et Développement expérimental (RS&DE).

Enfin, le secteur des TIC est également avantagé par la compétence de la main‐

d’œuvre québécoise.

C’est pour toutes ses raisons que le Québec et plus particulièrement le Grand

Montréal est un carrefour technologique de premier plan.

Économiquement, ce secteur est très lucratif pour l’ensemble des acteurs que ce soit

les employés, les entreprises ou le gouvernement.

En effet, le secteur des TIC a contribué en 2008 à hauteur de 12 milliards de dollars au

PIB du Québec. Plus de 5 milliards d’exportation ont également été fait.



La récession ?

Alors que de nombreux secteurs ont dû imposer un gel ou une diminution des salaires,

c’est tout le contraire qui s’est produit dans le secteur des TI.

D’après TECHNOCompétences, entre 2008 et 2010, les salaires ont connu une hausse

moyenne pour atteindre 8% cette année comparée aux 6 % des autres secteurs de la

province.

La pénurie de main‐d’œuvre en TIC exerce une énorme pression sur les salaires ce qui

fait que le salaire moyen à Montréal pour un analyste‐programmeur s’élève à 60 500 $.

Toujours selon TECHNOCompétence, cette situation d’augmentation de salaire devrait

perdurer au cours des prochaines années du fait de cette rareté de travailleurs

spécialisés.

Les étudiants québécois boudant le domaine de l’informatique, le secteur des

Technologies de l’Information et des Communications reste, et cela pour encore de

nombreuses années, un secteur plein de promesses pour tous les étudiants en

Informatique dont ceux de Supinfo.

PRÉSENTATION, HISTORIQUE ET ACTIVITÉS D’HPJ SOLUTIONS

Située à Montréal dans le Mile‐End (Figure 9 ‐ Localisation d'HPJ Solutions), HPJ

Solutions est une entreprise spécialisée dans le développement Web. Elle possède une

solide expertise dans le domaine du Web qui lui permet de se positionner comme un

acteur important dans le domaine.

Le Mile‐End est un quartier en perpétuel changement qui fait partie de

l’arrondissement Plateau Mont‐Royal. Les dernières années ont marqués un tournant

pour ce quartier avec l’arrivée de grandes compagnies tel qu’Ubisoft. Le quartier a

connu un rajeunissement accéléré se traduisant par une revitalisation d’une majorité

des anciennes usines et entrepôts textiles et une hausse de la valeur des

appartements, condominiums et bureaux.

Pascal Jarry a fondé HPJ Solutions en 2006 parce qu’il avait besoin d’un nouveau défi à

ce moment‐là.

Après avoir passé plus de 15 années de sa vie dans des sociétés BNP Paribas, IMR ou

CN Rail où il a occupé des postes d’analyste programmeur, de consultant et chef de

projet, d’architecte technique, Pascal s’est lancé dans l’aventure entrepreneuriale.

Juste avant la fondation de la société, Pascal fit le bilan de son activité et de demanda

ce qu’il souhaitait pour lui et sa famille. Un des sentiments qui retirait de son passé



salarial était qu’il avait beaucoup donné en construisant tour à tour pour ses

employeurs respectifs des équipes, des infrastructures ou encore des services. Pour lui,

c’était le moment où il souhaitait pouvoir bénéficier d’un retour sur investissements

plus substantiel et ainsi s’assurer d’être capable d’assumer la qualité de vie à laquelle

il aspire.

Au cours des 3 dernières années, la société a construit des dizaines de sites Web. La

principale raison de sa réussite est sa compréhension des technologies et sa volonté

de livrer des projets de très haute qualité. De plus, leur compétence en technologies

de l'information passe avant tout par leur expérience en architecture de système et de

programmation de systèmes informatiques dans le milieu bancaire. Cette expertise

technique conjuguée à leur connaissance de l'industrie leur permet de donner accès à

ses clients aux dernières évolutions techniques à un coût abordable.

La stratégie de l’entreprise, afin de proposer des services attractifs dans le secteur

ultra compétitif du Web et des technologies de l’information, est de s’appuyer sur des

logiciels / composants Open Source. En dehors de l’avantage certain que ces logiciels

sont gratuits, ils sont généralement créés et maintenus par des communautés très

actives, accessibles et toujours tournées vers l’avenir, qui proposent constamment de

nouvelles évolutions ou des solutions originales à des problèmes rencontrés par

d’autres utilisateurs.

PRINCIPAUX CLIENTS

IVANHOE CAMBRIDGE

Filiale immobilière de la Caisse des Dépôt, Ivanhoé Cambridge se spécialise dans le

créneau des centres commerciaux en milieu urbain.

HPJ Solutions a développé pour cette société un système de carte de vœux

électronique (Figure 10 ‐ Ivanhoé Cambridge).

ORDRE DES INGÉNIEURS DU QUÉBEC

Pour l’ordre des ingénieurs du Québec, HPJ Solutions a effectué différents mandats :

Création de bulletins.oiq.qc.ca permet à l’ordre d’éditer un bulletin régulier à

destination de ses membres (http://www.bulletinsoiq.qc.ca).

Une version d’HPJCC spéciale pour l’OIQ pour répondre à leur besoin d’envois

d’infolettres à leurs membres.



Des microsites répondants aux besoins de l’Ordre.

ASSOCIATION DES EMPLOYEURS MARITIME

L’Association recherchait une firme en mesure de produire un site Web qui puisse

interagir avec les systèmes d’authentification existants, ce qui suppose de connaître le

langage Java, mais aussi les technologies du Web permettant d’interfacer un site avec

des systèmes de sécurité et d’authentification reposant sur le Java. Son choix s’est

tourné vers HPJ Solutions, qui a bien écouté les besoins de l’association et a proposé

de faire une étude comparative des principaux CMS du marché.

L’Association des employeurs maritimes a été créée en 1969 lorsque l’industrie

maritime a réalisé qu’elle devait trouver un moyen pour mieux gérer ses relations du

travail avec les employés qui chargent et déchargent les navires dans l’est du Canada.

Les arrivées et les départs des navires ne suivent pas un horaire fixe et les débardeurs

doivent travailler pour différents employeurs durant l’année. Pour cette raison,

l’industrie avait besoin qu’une association commune soit conçue pour agir en son nom

auprès de ces employés. La mission de l’A.E.M. est de contribuer au succès florissant

des ports sous sa juridiction en fournissant une main‐d’œuvre qualifiée, et avec la

collaboration de ses partenaires syndicaux, par la mise en place et l’administration

efficace des conventions collectives.

L’A.E.M. compte une trentaine de membres de catégorie I (propriétaires ou exploitants

et/ou agents de navires faisant affaire dans un port où l’Association est le

représentant patronal) et une douzaine de membres de catégorie II (employeurs de

main‐d’œuvre appartenant à des syndicats à l’égard desquels l’Association est le

représentant patronal désigné). L’Association, dont le siège social est situé à la Cité du

Havre à Montréal, compte un centre de formation et un centre de déploiement à

Montréal ainsi que des bureaux à Trois‐Rivières et Hamilton, en Ontario.

En 2007, sous l’égide de Jean Bédard, nouvellement élu président et chef de la

direction, l’A.E.M. s’est lancé dans un virage technologique important. L’Association a

voulu se donner une plus grande visibilité tant pour ses employés que pour ses

membres en faisant une refonte de son site Internet, qui était jusque‐là

essentiellement un outil interne. Tous les directeurs de département ont été mis à

contribution pour développer les contenus. Plus qu’une refonte du site Web, il

s’agissait de mettre en place un portail, une porte d’accès vers les différentes

applications de l’Association. De cette réflexion sont nées d’autres possibilités.



Une des particularités de l’A.E.M. est que ses quelque 1300 employés à temps plein et

4000 à temps partiel dans les ports de Hamilton, Toronto, Montréal et Trois‐

Rivières/Bécancour doivent travailler dans différents lieux de chacun de ces ports.

L’organisation voulait qu’ils puissent accéder rapidement à leurs affectations

quotidiennes.

HPJ Solutions a donc été en charge de d’effectuer la refonte du site web pour en faire

un portail en utilisant le CMS Joomla en plus de technologies comme Java, des Web

services et MySQL (Figure 11 ‐ AEM / MEA).

LE GROUPE VIVAVISION

HPJ Solutions a été mandaté en 2009 pour la refonte du site web de la société

canadienne de production télévisuelle (http://www.vivavision.ca).

SOCIÉTÉ QUÉBÉCOISE DE LA SCHIZOPHRÉNIE

HPJ Solutions est entrain de refondre le site de la société québécoise de la

schizophrénie qui a pour mission de contribuer à l’amélioration de la qualité de vie des

personnes touchées par la schizophrénie et les psychoses apparentées, par le biais

d’activités éducatives et de soutien, de participation aux politiques gouvernementales

et de contributions à la recherche.

Le site web est dans la dernière phase de réalisation et devrait être rapidement livré.

L’ÉQUIPE

Rapidement après sa création, HPJ Solutions s’est vite organisé en différents pôles

pour une meilleure productivité et une division efficaces des tâches.

On compte trois pôles différents :

Pôle Web et Commerce électronique,

Pôle Développement,

Pôle Référencement.

An moment de mon arrivée au sein de de la société, nous étions onze personnes :

Pascal Jarry (Président),

Mathieu Gagnon (Responsable du Pôle Web et Commerce électronique),

Thomas Farrié (Responsable du Pôle Référencement et Chef de projet Web),

Étienne Borel (Responsable du Pôle Développement),



Jane Fortier (Directrice Artistique),

Michèle Delisle (Intégratrice et Conceptrice Web),

Sandrine Panel (Support Client et Administration),

Jan‐Sébastien Proulx (Analyste et Programmeur Java),

Sébastien Raffard (Développeur Web),

Mickael Burget (Développeur Web),

Harriet Kerr (Directrice Administrative),

Et moi‐même (Analyse‐Programmeur).

Au cours de ces cinq derniers mois, l’équipe a subi un certain nombre de modifications

avec les départs de Sandrine et Sébastien et les arrivées de Tarek Chaaban en tant

qu’analyste‐programmeur, Guy Lambert et Pierre Moreau comme Intégrateur et

Designer Web, Lorena Garcia et Lamine N’Dao au poste de Graphiste.

Le diagramme ci‐dessous illustre la situation de l’équipe au jour d’aujourd’hui



QUELLE DIRECTION POUR HPJ SOLUTIONS ?

Pascal dit souvent : « conquérir le monde ». Bien entendu, ceci est une boutade mais

elle démontre bien l’ambition qu’il possède pour développer l’entreprise et de faire

fructifier ses efforts.

Différents objectifs ont été fixés, le premier étant lié au chiffre d’affaire de

l’entreprise.

En effet, Pascal souhaite doubler son chiffre d’affaire tous les ans pour atteindre la

barre symbolique du million de chiffre d’affaire. L’année dernière la société était à

700 000 $ mais il est déjà établi que cette année le CA de l’entreprise ne sera pas

doublé car le million reste quand même un palier important et qu’il vaut mieux

temporiser quelques temps que de se précipiter vers cette objectif sans assurer ses

arrières.

Le second objectif est que HPJ Solutions possède 50 employés. Au 1er Décembre de

cette année, nous serons treize personnes. On peut donc dire que nous sommes à un

peu plus du quart de l’objectif en quatre ans.

Au niveau stratégique, Pascal a déjà bien en tête ce qu’il souhaite faire pour la société

et voit dès maintenant comment elle serait dans quelques années.

Alors qu’au commencement de l’entreprise, la direction prise était de créer du

récurrent avec les forfaits Accès Web, HPJCC et d’autres services web.

Rapidement, la réflexion de comment toucher les plus grosses entreprises s’est posée.

La solution pour atteindre cet objectif a été de créer des sites web en développant

l’entreprise en pôles.

Aujourd’hui, l’emphase est mise sur le pôle Développement où on développe de plus

en plus des solutions spécifiques demandées par les clients.

Dans l’avenir, Pascal souhaite ajouter un volet supplémentaire à ses compétences.

Effectivement, il a envie de développer la partie communication d’HPJ Solutions. C’est

le pôle Web qui serait petit à petit transformé pour créer deux entités HPJ. La

première s’occuperait du développement des applications alors que l’autre unité se

chargera des plans de communications et de la vente des services.

Au niveau technologique, Pascal veut garder son cœur de métier qui est PHP et Java

mais il aspire à étendre les compétences d’HPJ Solutions vers le .Net et Sharepoint.



ENVIRONNEMENT TECHNIQUE

HPJ Solutions possèdent une infrastructure d’hébergement gérée par la société

Plutoniq basée à Brossard. Cette infrastructure est composée de cinq serveurs dédiés :

quatre sous Linux CentOS et un sous Windows Server 2008. En plus de ceux‐là, deux

autres serveurs Windows, présents dans les locaux d’HPJ Solutions, sont utilisés à des

fin de backup des postes des employés, de serveur de courriel Exchange, de serveur de

fichiers, de service d’annuaire LDAP Active Directory et dans le but d’héberger les

outils de gestion de projet comme Atlassian Jira, système de suivi de bugs, de gestion

des incidents et de gestion de projets et Atlassian Confluence (moteur de wiki).

Un des serveurs Linux est spécialement dédié à HPJCC où est installé un serveur web

Apache Tomcat, bientôt remplacé par un serveur d’applications Glassfish, en plus d’un

serveur HTTP Apache.


Michaël Massé | HPJCC et la gestion du spam 15

HPJCC ET LA GESTION DU SPAM

Comme j’ai pu l’indiquer précédemment dans l’introduction, à mon arrivée à HPJ

Solutions on m’a confié la tâche de mettre en place une politique de gestion du spam

dans un système d’envoi d’infolettres existants car celle‐ci était pratiquement

inexistante malgré le fait que ce soit une partie très importante d’un tel système.

Il a donc fallu que je mette en place les diverses procédures et méthodes, après

mettre documenté, par rapport à tous les aspects de gestion du spam dans HPJCC. Je

devais tenir compte du fait que le projet était très avancé dans son développement et

qu’il était en phase de pré‐production auprès d’un certain nombre de clients dans le

cadre d’une version de test.

La problématique au cours de ses derniers mois est donc la suivante : faire en sorte

que le système HPJCC soit conforme aux différentes lois en vigueur concernant le

spam en mettant des procédures en place et un monitoring efficace. Ceci devant être

effectué en gardant en tête que je devais assurer les différentes demandes qui

m’étaient affectées comme la gestion de l’infrastructure d’HPJ Solutions, des tâches

de développement web ou de gestion de projet.

POURQUOI AVOIR CHOISI CE SUJET ?

Par le passé, j’ai eu l’occasion de travailler sur un système équivalent à Atypic où cette

fois‐ci j’ai dû m’occuper entièrement du développement de la plateforme.

À ce moment‐là, j’ai découvert un domaine très intéressant du fait de la diversité des

compétences nécessaire pour couvrir toutes les procédures et méthodes à mettre en

place. En effet, la gestion du spam dans un système d’infolettres fait appel à des

connaissances d’administration réseau pour, par exemple, l’implémentation des

normes d’authentification DKIM, SPF ou SenderID en plus des connaissances en

développement web mais également à des notions de programmation pour, par

exemple, la mise en place des headers nécessaires dans les courriels.

Aussi, ce sujet est réellement d’actualité du fait qu’il est vécu par tous, tous les jours.

L’étude « Internet Threats Trend Report » (Commtouch, 2010) parue le 23 septembre

2010 fait état qu’en moyenne 183 milliards de courriels envoyés par jour sont du spam.

Enfin, le fait d’avoir travaillé par le passé sur des systèmes d’envoi d’infolettres m’a

permis d’acquérir un certain nombre de connaissances dans ce domaine qui je pense

peuvent être mise par écrite avec l’espoir que cela puisse servir à d’autres.


Michaël Massé | HPJCC, une solution de marketing par courriel 16

HPJCC, UNE SOLUTION DE MARKETING PAR COURRIEL

DESCRIPTION DU PROJET ET ANALYSE DU CONTEXTE

HPJCC est une solution de marketing par courriel ou « Email marketing software » en

anglais développée par HPJ Solutions. Il s’agit d’un service qui s’intègre dans la

stratégie globale de la société qui propose des sites Web clé en main assortie d’une

campagne de référencement. L’utilisation d’infolettres est un outil indispensable pour

optimiser le nombre de visiteurs pour un site web.

Le système se compose de deux parties distinctes et autonomes :

HPJCC, l’interface web développée avec Zend Framework,

MailCenter, développé en Java, cette partie se charge de la génération des

courriels et de l’envoi de ceux‐ci.

Ces deux parties utilisent des bases de données MySQL mais une migration vers Oracle

est prévue pour plus de robustesse.

HPJCC, L’INTERFACE

Le système est construit autour d’un référentiel unique par client. L’accent est mis sur

le contact et non sur des listes comme d’autres systèmes de marketing par courriel.

Une notion d’attributs et de filtres sur ceux‐ci permet de cibler quels contacts sont

concernés par les newsletters.

Pour importer les contacts dans le référentiel, les utilisateurs ont de multiples choix :

Les Connecteurs,

Un formulaire affiché sur votre site web.

Les connecteurs permettent l’importation de contacts à partir d’un fichier Excel ou de

systèmes externes comme une base de données de membres via un service web.

La création de campagne est facilité grâce à un éditeur WYSIWYG et à l’utilisation de

gabarit que le client peut importer lui‐même.

Aussi, les clients peuvent facilement personnaliser leur message grâce à l’utilisation de

mots‐clés.

En le suivi statistique de la campagne est assuré. Pour chaque envoi, les clients ont

accès au taux d’ouverture et au taux de rebond. De plus, chaque lien de l’infolettre est

surveillé et ainsi le client peut savoir qui a cliqué sur quel lien.



LE MAILCENTER

Cette partie de l’application est le cœur de celle‐ci car chargée de la génération du

contenu HTML et texte des courriels ainsi que de l’envoi de ceux‐ci.

Construit autour des technologies Java, ce moteur d’envoi fonctionne de manière

asynchrone de l’interface HPJCC.

Ainsi, si l’interface rencontre un problème, celui‐ci ne peut pas provoquer un arrêt de

l’envoi des courriels.

Une API a été conçue pour permettre la communication entre HPJCC et MailCenter.

HPJCC VS MAILCHIMP

MailChimp est né des besoins des clients d’une société de développement américaine

basée à Atlanta, Rocket Science Group. Son fondateur et CEO, Ben Chestnut a décidé

de créer une solution industrielle afin de faire profiter à tous leurs clients d’un service

de courriel marketing de qualité. Fort du succès rencontré, la société s’est concentrée

sur cette activité et s’autofinance intégralement maintenant.

Il est inutile d’avoir la moindre connaissance en HTML car les utilisateurs de

MailChimp composent directement leur campagne soit en partant des templates

proposés soit via l’éditeur fourni soit en important votre fichier HTML réalisé

auparavant.

Chaque courriel pourra être personnalisé en utilisant différents mots‐clés permettant

d’aller chercher les informations dans la base de données de vos contacts.

MailChimp propose en option un système permettant de tester sur 25 différents

clients mail la campagne qui va être envoyée.

Le système permet de gérer les abonnés que ce soir via un fichier csv, mais des liaisons

avec Salesforce, HighRise, GoogleDocs, ZenDesk, Zoho ou avec un simple copié‐collé à

partir d’Excel.

Une API a également été développée qui permet d’interfacer n’importe quelle base

avec leur service.

Des formulaires d’abonnements et de désabonnements aux listes d’envois sont

proposés par le système.



MailChimp étant un des acteurs reconnu du secteur d’envoi de courriels marketing, le

système est interfacé avec les principaux FAI pour recevoir les rapports d’abus et de

rebonds afin de nettoyer les listes de ses utilisateurs.

De plus, le système établit un score de fiabilité pour chacune des listes des utilisateurs

qui repose sur la qualité des contacts et les interactions qui peuvent se produire. Ce

score détermine le serveur qui enverra les courriels.

Enfin, le service de Rocket Science Group intègre les différents types

d’authentifications actuels qui sont DKIM, Domain Keys, SPF et Sender ID.

MailChimp assure également le tracking des campagnes en récoltant les informations

suivantes : nombre d’envois, taux d’ouverture, adresses inactives, taux de clic.

L’intégration de Google Analytics est entièrement possible.

Comparé à un ténor de l’envoi de courriel marketing comme MailChimp, HPJCC fait

office de petit poucet du fait de son jeune âge.

Cependant, HPJCC se démarque sur un certains nombres de points.

La première différence flagrante est l’axe pris par HPJCC qui s’est plutôt centré sur un

référentiel unique dans lequel on crée des listes en fonction d’un couple attributs /

filtres.

Ainsi, on peut effectuer une segmentation beaucoup plus poussée et aisée que dans

un système comme MailChimp.

Deuxièmement, HPJCC est clairement tourné vers les entreprises alors que MailChimp

se veut être accessible à tous. Ceci implique une philosophie de développement des

fonctionnalités différentes car les entreprises n’ont pas les mêmes besoins que les

particuliers.

En parlant des fonctionnalités, il est vrai qu’il en manque un certain nombre à HPJCC

par rapport à MailChimp mais ces différences vont considérablement se réduire avec

le temps du fait des améliorations qui sont apportés tous les jours au système. Par

exemple, l’envoi différé est prévu pour la prochaine version.

L’avantage que possède HPJCC sur MailChimp c’est sa taille qui lui permet pour le

moment de répondre exactement aux demandes des clients.

Toujours au rayon des différences, l’une des prochaines grosses évolutions est la mise

en place d’un workflow de validation couplé à une édition de rapport quotidien

récapitulant tout ce qui s’est passé au cours des 24 dernières heures. Cette demande

émane de plusieurs entreprises qui souhaitent mettre en place un système de

validation des infolettres avant envoi.



QUELQUES POINTS PARTICULIERS DU PROJET

Dans les parties suivantes, je vais détailler certaines tâches que j’ai pu effectuer dans

le projet HPJCC.

Même si j’ai eu une multitude de tâches à faire chez HPJ Solutions entre la gestion de

l’infrastructure, les projets de développement web, HPJCC et le support client, je

pense que ces points sont assez significatifs de mon travail et méritent d’être détaillé.

SORTIE D’HIBERNATE DU MAILCENTER

ANALYSE DU PROBLÈME

Un des premiers développements à faire sur ce projet fut d’améliorer les

performances de la partie MailCenter. En effet, celle‐ci ne supportait pas forcement la

charge lorsque l’on demandait au système d’effectuer un important envoi.

On a déterminé que ces problèmes de performance pouvaient provenir de différentes

causes :

Erreur lors du développement,

Problème du côté du serveur MySQL avec des requêtes trop lentes,

Problème avec l’API de gestion des courriels JavaMail.

Après avoir vérifié l’ensemble des lors du serveur, il s’est avéré que le principal

problème était la surcouche Hibernate qui gérait la persistance des objets en base de

données. Cependant, l’un des problèmes connus d’Hibernate est sa lenteur malgré une

robustesse et une vitesse de développement élevée.

CHOIX ET MISE EN ŒUVRE DE LA SOLUTION

La première piste étudiée afin de régler ce problème a été de remplacer Hibernate par

JPA (Java Persistance API). Cependant cette piste a rapidement été abandonnée du fait

des coûts engendrés par les développements nécessaire pour adapter le MailCenter à

cette spécification.

Le second choix et celui qui a été retenu au final fut le suivant : remplacer la couche

Hibernate par une couche de persistance entièrement écrite avec JDBC (Java DataBase

Connectivity) seulement. Cette décision a été motivée par le fait que les performances

ne peuvent pas être plus élevées qu’en utilisant seulement JDBC malgré le fait que le

temps de développement soit un peu plus important.



Pour mettre en œuvre cette solution, j’ai donc du réécrire toute la couche persistance

du MailCenter en m’inspirant de ce qui avait été fait avec Hibernate.

BILAN DE LA PHASE DE MISE EN ŒUVRE

Au final, le MailCenter est doté d’une couche persistance optimisée pour la

performance qui a permis d’augmenter le nombre de courriels envoyés par minutes

tout en diminuant les ressources nécessaires pour ces envois.

GESTION DU SPAM DANS UN SYSTÈME DE MARKETING PAR COURRIEL

ANALYSE DU PROBLÈME

Mon principal mandat à HPJ Solutions a été de gérer tous les aspects du spam dans un

système de marketing par courriel.

Au moment de mon arrivée, le seul élément développé concernant la gestion du spam

était le lien de désinscription permettant aux destinataires des infolettres de se

désabonner de tous ou d’une partie des envois de l’émetteur.

Les problèmes découlant d’une mauvaise gestion du spam dans un tel système ne

doivent absolument pas être pris à la légère car la réputation du serveur et même du

nom de domaine émetteur en dépendent grandement.

En effet, plus il y a de rebonds ou de plaintes générés par une ou des infolettres

envoyées via votre serveur, plus la réputation de celui‐ci s’effondrera.

Hors, la réputation est désormais le nerf de la guerre dans la gestion du spam.

J’expliquerais plus en détail ce principe de réputation par la suite.

Ma tâche a donc été de déterminer les actions à mettre en œuvre pour améliorer la

prise en charge des pourriels dans un tel système. Par la suite, je devais implémenter

ces actions et surveiller leurs résultats.

CRÉATION DE LA LISTE DE CONTRÔLE ET SA MISE EN ŒUVRE

Avant de commencer la liste des tâches à mettre en place, il m’a fallu définir

clairement ce qu’est un spam et me documenter sur les lois en vigueur.

QU’EST‐CE QUE LE SPAM ?

Ce mot, appliqué aux courriels, signifie courriel non sollicité envoyé massivement.



Non‐sollicité désigne un destinataire qui n’a pas donné son explicite et vérifiable

accord pour que le message lui soit envoyé. Massif signifie quant à lui que le courriel

en question n’est qu’une partie d’un vaste envoi au contenu identique.

Il s’agit de spam seulement et seulement si le courriel est à la fois non sollicité et

envoyé de manière massive.

LE PROBLÈME SPAM

Le spam est un véritable fléau de nos jours.

En plus de coûter une fortune aux entreprises ‐ environ 130 milliards par an (Jennings,

2009), les pourriels ont un impact significatif sur l’environnement et n’est pas qu’une

pollution visuelle.

Le spam génère indirectement une importante hausse de la consommation électrique

des réseaux et serveurs informatiques.

Par an, on estime que les spam utilisent 33 milliards de KWh soit l’équivalent de la

puissance fournie par quatre grandes nouvelles centrales électriques au charbon. (ICF

International & McAfee, Avril 2009)

PERMISSION, PERMISSION, PERMISSION …

Le spam est avant tout un problème de consentement que de contenu. Que ce soit une

publicité, une escroquerie, de la pornographie, une offre de repas gratuit, le contenu

n’est pas pertinent pour déterminer s’il s’agit d’un spam ou non. Si le message a été

envoyé massivement et de manière non sollicité alors c’est un spam.

Le maître mot de l’histoire est donc permission ou autorisation ou tout autre mot

désignant que le destinataire veut bien recevoir, en l’exprimant clairement, des

courriels de votre part.

La distinction entre consentement et contenu est importante parce que les législateurs

ont passés énormément de temps à tenter de réglementer le contenu des spam et ce

faisant, ils se sont heurtés à des questions de libertés d’expressions sans se rendre

compte que le problème du spam est seulement lié au mode de livraison.

UNE LÉGISLATION LONGUE À SE METTRE EN PLACE.

Historiquement, on considère que le premier spam électronique a été envoyé en 1978

à 600 personnes qui utilisaient ARPANET. En 2002, nous avions déjà 2,4 milliards.

Il a fallu attendre 2003 pour voir des actions législatives concrètes avec le « CAN‐SPAM

Act 2003 » aux États‐Unis ou la loi « Privacy and Electronic Communications (EC

Directive) Regulations 2003 » en Grande‐Bretagne.



Le Canada, dernier pays du G8 à se doter de mesures législatives spécifiques anti‐spam,

avait fait un grand pas avec le projet de loi Bill C‐27 qui avait pour titre abrégé : « Loi

sur la protection du commerce électronique » déposé en 2009.

Cependant, le 30 Décembre 2009, en raison de la prorogation du Parlement alors que

le projet de loi était en deuxième lecture au Sénat, ce dernier fut abandonné.

Le gouvernement canadien a alors déposé, le 25 Mai 2010, un nouveau projet de loi

appelé C‐28 : Loi visant à promouvoir l’efficacité et la capacité d’adaptation de

l’économie canadienne par la réglementation de certaines pratiques qui découragent

l’exercice des activités commerciales par voie électronique et modifiant la Loi sur le

Conseil de la radiodiffusion et des télécommunications canadiennes, la Loi sur la

concurrence, la Loi sur la protection des renseignements personnels et les documents

électroniques et la Loi sur les télécommunications. En abrégé, son nom est le suivant :

LEPI soit Loi visant l’élimination des pourriels sur les réseaux Internet sans fil

(Ministère de l'Industrie du Canada, 2010).

Ce projet de loi reprend le projet C‐27 avec certains éléments qui avait été ajoutés à

ce dernier à titre d’amendements.

La LEPI est l’aboutissement d’un processus amorcé en 2004 par le gouvernement du

Canada : le Plan d’action anti‐pourriel pour le Canada.

En plus d’établir un cadre législatif et réglementaire pour lutter contre le pourriel au

Canada, ce projet de loi vise à accorder à des organismes comme le Bureau de la

concurrence, le Commissariat de la protection de la vie privée et le CRTC le pouvoir de

communiquer de l’information et des éléments de preuve à leurs homologues à

l’étranger afin de lutter contre le spam provenant de l’extérieur du Canada.

Il est à noter que la législation anti‐spam au Canada va plus loin que celle existante

aux États‐Unis. Il existe cinq principales différences :

Une autorisation préalable est nécessaire à l’envoi,

L’autorisation est requise pour l’envoi de messages SMS,

Les liens de désabonnement doivent rester actifs pendant 60 jours,

Les demandes de désinscription doivent être honorées dans les 10 jours,

Les individus ont le droit de poursuivre les spammeurs.

COMMENT ÊTRE CONFORME AVEC LES LOIS EN VIGUEUR ?

Tout bonne société ou individuel qui ont pour mandat d’envoyer massivement des

courriels commerciaux se doivent de connaître les législations en vigueur.



Au Canada, la loi énonce les règles qui doivent être suivi mais il est également

important de suivre les directives de la CAN‐SPAM afin de pouvoir se protéger contre

d’éventuelles plaintes.

À QUI DES COURRIELS PEUVENT ÊTRE ENVOYÉS ?

Des courriels peuvent être envoyés à tout le monde à partir du moment où l’émetteur

possède une autorisation explicite de le faire. Par contre, il n’est pas permis de

renvoyer des courriels à des personnes qui ont demandé à être désinscrit de la liste

d’envoi.

La segmentation des listes de contacts en se basant sur les préférences exprimées, les

comportements observés, la démographie ou tous autres critères pertinents permet

de diminuer le taux de plaintes par rapport aux infolettres envoyées.

Pour assurer le consentement explicite des personnes cibles des infolettres, la

méthode du double opt‐in est particulièrement conseillée. Je développerais cette

méthode dans un chapitre suivant.

QUAND LES COURRIELS PEUVENT‐ILS ÊTRE ENVOYÉS ?

Un peu dans le même ordre d’idée que le qui, les courriels peuvent être envoyés à

n’importe quel moment de la journée tant qu’encore une fois l’émetteur possède les

autorisations pour le faire. Par contre, une personne ne peut être contactée que

pendant dix‐huit mois après avoir obtenu son aval. Cela signifie qu’un système de

rappel doit être mis en place pour être en phase avec la loi Canadienne.

Des études ont montré que certains jours de la semaine sous plus propice à l’envoi

d’infolettres (Bezier, 2008). Cependant, il ne faut pas absolument chercher la journée

idéale pour envoyer les communications mais il faut les envoyer seulement lorsque le

contenu est suffisant et pertinent.

En utilisant des options de préférences pour faire en sorte que vos abonnés puissent

choisir le moment et la fréquence avec laquelle ils reçoivent les courriels permettent

de limiter les faux positifs par rapport aux plaintes pour spam.

Enfin, une dernière astuce concernant le « quand », mettre en place un système

d’aide‐mémoire qui permettra ainsi à la fois d’avoir une preuve du consentement

explicite des abonnés mais aussi de rester en contact régulier avec eux afin d’éviter

des clics intempestifs sur le bouton spam / courrier indésirable.

QUELS ÉLÉMENTS DOIVENT‐ÊTRE PRÉSENTS DANS TOUS LES COURRIELS ?

Certaines informations doivent se retrouver sur tous les envois. En voici ci‐dessous

une liste non exhaustive :



L’adresse courriel présente dans le « From » doit être explicitement liée à

l’entreprise émettrice.

Le nom de la compagnie émettrice.

L’adresse postale de la société émettrice.

Les informations de contact de l’entreprise : courriel, téléphone, télécopieur,

etc. …

Le sujet du courriel doit refléter le contenu de celui‐ci.

Un lien de désinscription.

En plus de cela, il faut s’assurer que les informations DNS concordent avec le nom de

la compagnie émettrice.

Aussi, il ne faut pas se limiter aux informations basiques de contacts mais en mettre

un maximum afin que les abonnés puissent avoir l’embarras du choix pour se

désinscrire ou contacter l’émetteur en cas question. Cela inclus aussi le fait de mettre

les bonnes informations dans les bons headers du courriel.

QU’EST‐CE QUI DOIT ÊTRE FAIT LORSQU’UN DESTINATAIRE NE SOUHAITE PLUS RECEVOIR LES

COURRIELS ?

Les lois sont très claires sur ce point : les sociétés responsables des envois doivent

maintenir des procédures de désabonnement claires et visibles.

De plus, elles s’engagent à effectuer le désabonnement dans les 10 jours suivant la

demande et quel que soit sa forme.

Ensuite, toutes les boites de courriels entrantes doivent être surveillées afin de

répondre à toutes les questions et doléances des abonnées.

Les abonnées doivent facilement pouvoir communiquer avec la personne responsable

de l’envoi. Pour cela, l’entreprise s’engage donc de mettre en place des méthodes

pour qu’elle soit accessible pendant 60 jours à parti de l’envoi.

Suite à ces réflexions, il a été décidé de développer les options suivantes dans un futur

proche :

Proposer diverses possibilités pour se désabonner : adresse courriel, page web,

utilisation des headers,

Utiliser un centre de préférence pour les abonnés puissent choisir de se

désabonner de certaines campagnes plutôt que de toutes les campagnes à la

fois,

Demander aux abonnées pourquoi ils se désinscrivent ainsi on pourra ce qu’il

ne va pas dans les campagnes envoyées,

Acheminer des rapports de désinscription vers un représentant du service

client de l’entreprise émettrice afin qu’ils puissent être examinés plutôt que de

rester dans une boîte courriel sans surveillance.



QUELS SONT LES RISQUES EN CAS D’INFRACTIONS ?

Au Canada, la peine maximale dans le cas d’une violation de la loi est de un million de

dollars pour une personne et de dix millions de dollars pour une société ou autre

organisation. Ces amendes sont imposées pour chaque violation, et la réglementation

peut considérer certains types de violations comme étant distinctes pour chaque jour

où la contravention se continue, de sorte que les montants maximaux pour ces

violations pourraient être imposés pour chaque journée où l’on a constaté une

violation. Par exemple, une société qui enverrait des pourriels pendant dix jours

pourrait être tenue de payer jusqu’à 100 millions de dollars.

Il est important de noter que les personnes individuelles et l’État fédéral peuvent

assigner séparément l’émetteur en justice.

IL N’Y A PAS QUE LA LOI

CE QUE LES UTILISATEURS DISENT …

Chaque enquête sur les comportements des utilisateurs de courriels révèle que leur

définition de spam ou pourriel est maintenant beaucoup plus qu’un simple « courriel

commercial non sollicité ».

Les spams comprennent maintenant tout courriel qui n’est plus souhaité même si le

destinataire a bien donné son consentement précédemment.

Return Path a demandé à 1 695 consommateurs en 2008 en leur posant la question

suivante : « que faites‐vous généralement lorsque vous ne souhaitez plus recevoir de

courriels de la part d’une compagnie ? »

La réponse : j’utilise parfois le bouton courrier indésirable ou à chaque fois a été

choisie par 50,9%.

Toujours en 2008, Silverpop a demandé à 400 de ses usagers ce que le mot spam

voulait dire pour eux :

40 % a répondu : courriel que je ne veux pas recevoir.

35 % ont dit : courriel en provenance de toute entité commerciale.

Dans la même étude, les répondants ont été interrogés pourquoi ils ont reporté ce

courriel comme spam :

7 % ont dit que c’est à cause du fait qu’ils ont reçu trop de courriels de la part

de l’émetteur.

7 % ont répondu que c’est lorsqu’ils ont perdu l’intérêt dans les courriels où ils

ont souscrits.



En 2007, Epsilon a sondé 119 personnes qui ont utilisé le bouton courrier indésirable.

Il en ressort que 65% d’entre eux ont assimilé ce bouton à l’action de se désabonner

des courriels de l’expéditeur.

CE QUE LES FOURNISSEURS INTERNET DISENT …

YAHOO! MAIL

« Sur le plan opérationnel, nous définissons comme spam les courriels dont les usagers ne veulent plus dans leur boite de réception. » AOL

« C’est vraiment ce que veut l’usager, même s’ils ont demandé à recevoir le courriel. S’il ne possède pas une bonne valeur ajoutée alors ce n’est pas un bon courriel marketing. Nous voulons nous assurer que nos clients soient heureux. » GMAIL

« La façon dont Gmail classifie les courriels comme spam dépend grandement des rapports des utilisateurs. Pour augmenter votre taux de livraison, assurez‐vous que tous les bénéficiaires de vos listes veulent réellement recevoir vos courriels. »

En résumé, le fait d’être conforme à la loi ne garantit pas que les courriels soient bien

délivrés. Rien n’oblige les fournisseurs de service Internet de délivrer les courriels et

ceux‐ci peuvent refuser de le faire pour n’importe quelle raison.

En fin de compte, il ne faut pas seulement être conforme à la loi. Il faut s’assurer

d’avoir le droit de contacter les destinataires mais surtout s’assurer qu’ils souhaitent

bien continuer de recevoir vos courriels.

Une fois que le terme spam fut clairement défini, j’ai pu m’atteler à créer une listes

des tâches à effectuer afin de gérer tous les aspects du spam dans un outil de

marketing par courriel.

Après avoir étudié comment les différents concurrents d’HPJCC gère le problème du

spam et m’être documenté, j’ai déterminé qu’il fallait que je suive la liste suivante :

Préalables à une solution de marketing par courriel.

Modifications de l’application et analyse d’extensions possibles.

Adaptation de l’architecture physique.

Gestion des listes de contacts.

Monitoring et gestion des exceptions.

Checklist post‐campagne.



PRÉALABLES À UNE SOLUTION DE MARKETING PAR COURRIEL

Avant de se lancer tête baissé dans la mise en place d’un système de marketing par

courriel ou de modifier celui‐ci pour mettre en place une politique de gestion du spam,

il y a un certain nombre de choses à vérifier et d’actions à effectuer.

LA RÉPUTATION

Un des aspects qui prend de plus en plus d’importance dans la gestion du spam dans

un système de marketing par courriel est la réputation du serveur et de l’expéditeur.

Une étude de Return Path a démontré que 77% des problèmes de délivrabilité sont liés

à la réputation de l’émetteur. Le contenu du courriel arrive seulement en deuxième

position. (Return Path, 2008)

Cette notion de réputation est déterminante dans le résultat d’une campagne d’e‐

mailing. En effet, une mauvaise réputation engendre de graves difficultés en termes de

délivrabilité des courriels puisque ceux‐ci seront plus facilement marqués comme

spam.

Divers indicateurs sont donc à surveiller de près : nombre de plaintes, de rebonds, de

désabonnements, etc. … Ces facteurs et d’autres permettent aux FAI de déterminer la

réputation du serveur. Ainsi, la réputation de l’expéditeur indique aux fournisseurs

d’accès de la fiabilité de l’émetteur du courriel.

Les facteurs utilisés varient d’un FAI à l’autre. Donc pour bâtir une forte réputation, il

faut se familiariser avec tous les indicateurs dont se servent les FAI :

Les « spam traps » : il s’agit d’une adresse courriel qui semble être valide mais

qui en fin de compte est utilisée par les FAI pour détecter et attraper les

spammeurs. Ces derniers scannent des millions de pages web afin de trouver

des adresses courriels. Les FAI utilisent de vieilles adresses courriels recyclées

en les laissant accessibles sur des forums par exemple. Si un de ces courriels

est utilisé, la réputation de l’émetteur chute radicalement et peut même se

retrouver bloqué.

Une bonne gestion des listes et contacts permet d’éviter ce genre de problème.

L’authentification de l’émetteur : l’utilisation de diverses méthodes

d’authentification comme SPF, Sender ID, DKIM ou Domain Keys aident les FAI

à distinguer les émetteurs légitimes et les spammeurs.

L’adresse IP : l’adresse IP doit avoir un faible taux de plaintes, une gestion

parfaite des désinscriptions ainsi qu’une configuration exacte du domaine

associé. On ne connait généralement pas l’histoire de son adresse IP avant de



l’avoir. Il est donc important de vérifier la réputation de son adresse IP au

moment de son obtention.

Le nom de domaine : l’âge de celui‐ci est un facteur important. En effet, les

domaines enregistrés récemment sont suspicieux pour les FAI car généralement

les spammeurs utilisent souvent de jeunes domaines.

Respect des standards : en respectant les RFC en vigueur (RFC 281 et RFC 282),

la réputation du serveur est améliorée.

Reverse DNS : cette méthode est utilisée pour identifier un nom de domaine

associé à une adresse IP. L’adresse IP est un des seuls éléments non falsifiable

et ne pas avoir ce système est en violation avec les normes RFC et est une

exigence pour de nombreux FAI.

Gestion des rebonds : les adresses qui ne sont plus valides doivent être

rapidement retirées des contacts du système car celles‐ci entrainent une

hausse du taux de rebonds et par conséquent, une baisse de la réputation.

Le meilleur moyen pour améliorer le taux de délivrabilité est d’être certifié ou

accrédité par un organisme reconnu comme GoodMail Systems, Sender Score Certified,

Habeas ou SuretyMail. De cette manière, les courriels ont beaucoup plus de chances

d’arriver à destination.

On pourrait croître que pour résoudre les problèmes de réputation, il suffit d’en

changer. Cependant, une nouvelle IP n’est absolument pas gage d’une bonne

réputation.

Les nouvelles adresses IP sont considérées avec méfiance par les FAI car ils n’ont

aucune information sur l’adresse IP utilisée pour envoyer les courriels. On pourrait

comparer la réputation d’une adresse IP à un dossier de crédit.

Il existe des services web permettant de vérifier la réputation d’une adresse IP ou d’un

nom de domaine :

Sender Score (http://www.senderscore.com),

Microsoft Smart Network Data Services (https://postmaster.live.com/snds/),

TrustedSource (http://www.trustedsource.org/),

AOL Postmaster (http://postmaster.aol.com/cgi‐bin/plugh/check_ip.pl).

J’ai donc appliqué ce que j’ai pu annoncer ci‐dessus à HPJCC et il s’est avéré que la

réputation du serveur est bonne voir très bonne avec un Sender Score de 95 (FIGURE 1

‐ SENDER SCORE POUR HPJCC).



Ce score reflète la réputation d’une adresse IP utilisée dans le cadre de marketing par

courriel sur une échelle de 1 à 100 (100 étant la meilleure note possible). Il peut

fluctuer dans le temps, un peu comme votre côte de crédit, et mesure la crédibilité

d’un émetteur de courriels. Ce service est géré par la société Return Path et est de

plus en plus utilisé par les filtres anti‐spam afin de déterminer si nos courriels seront

acceptés ou non. S’ils sont acceptés, ce score va aider les mécanismes de filtrage à

déplacer les courriels dans la boite de réception ou dans le dossier spam.

Sender Score est une sorte de classement de l’adresse IP par rapport à toutes les

autres adresses IP suivies par le service dans le monde. Calculé tous les 30 jours en

moyenne, ce score est basé sur une variété de facteurs donc le volume de courriels

envoyés, le nombre de plaintes, le taux d’utilisateurs inconnus, le nombre de « spam

traps » rencontrés et l’infrastructure en place. Par contre, l’algorithme utilisé pour

calculer le score est complétement secret dans le but d’éviter aux spammeurs de

falsifier les résultats et de se faire passer pour de bons élèves.

Cette mesure est très importante pour toutes les sociétés qui effectuent du marketing

par courriel pour la simple et bonne raison que toutes souhaitent que leurs

communications atteignent bien la boite de réception de leurs contacts. Sender Score

est devenu depuis quelques années un élément clé des mécanismes de filtrage utilisé

par les FAI et les sociétés fournissant des solutions anti‐spam (Return Path).

Pour HPJCC, il s’avère que le faible volume et le taux d’utilisateurs inconnu sont les

deux facteurs qui empêchent le système d’avoir un meilleur score. Pour le volume, il

est difficile de mettre en place une quelconque action car cela dépend entièrement du

nombre de fois que les clients vont utiliser HPJCC. Cependant, d’après les ententes

récentes avec nos clients et le fait que le projet passe en phase de commercialisation,

le volume ne devrait rapidement plus être un facteur négatif sur le score.

Par contre, l’autre point faisant pression sur notre Sender Score est une chose à

laquelle on peut apporter des améliorations car le taux d’utilisateurs inconnus mesure

le nombre de tentative d’envois à une adresse courriel qui n’existe pas du système.

Ainsi, une bonne politique de gestion des rebonds permet d’augmenter le score de ce

critère. J’aborderais cette partie de la gestion du spam dans un système de marketing

par courriel plus loin car ceci a été une de mes plus importantes tâches au cours de ses

derniers mois.

Un autre point important dans un rapport Sender Score, c’est le taux d’acceptation

(« Accepted Rate »). Ce taux exprime essentiellement le nombre de courriel qui n’ont

pas été rejetés par les FAI qui sont surveillés par Return Path. Plus ce taux est élevé,

plus cela signifie que vos courriels arrivent à leurs destinataires.



HPJCC possède un bon taux de d’acceptation mais celui‐ci pourrait encore être

amélioré en mettant en place un certain nombre de mesures : authentification des

courriels avec DKIM, SPF ou Sender ID, inscription à des listes blanches et s’assurer

qu’on est présent sur aucune listes noires, gestion des Feedback Loop pour déterminer

si un des clients est un spammeur, … Toutes ces mesures seront abordées par la suite

dans ce document.

J’ai également utilisé un autre service pour vérifier la réputation d’HPJCC car, même si

le service fourni par Return Path est largement utilisé par les FAI et sociétés

fournissant des solutions anti‐spam, avoir plusieurs sources de données est toujours

une bonne chose pour améliorer son service.

Ainsi, j’ai utilisé TrustedSource Internet Reputation Monitor afin de m’aider à

déterminer les points à améliorer afin d’augmenter la réputation du serveur et ainsi

faire en sorte que plus de courriels arrivent dans la boite de réception (Figure 2 ‐

rapport Trustedsource pour HPJCC).

Encore une fois, les résultats montrent que la réputation du serveur est très bonne du

fait que nous sommes au niveau minimum de risque.

Le volume est également régulier mis à part un pic d’utilisation. Certains de nos clients

possèdent un référentiel très important et parfois effectuent des envois à tous leurs

contacts.

En résumé et après ces vérifications, il s’avère que le serveur possède une très bonne

côte auprès de société fournissant des services de monitoring de réputation comme

Return Path ou TrustedSource.

Ma conclusion a été la suivante : malgré le fait que le serveur soit bien vu, il nous

fallait améliorer les points suivants : le volume et la gestion des rebonds.

LE « WHITELISTING »

Une fois que la réputation du serveur a été vérifiée, j’ai pu m’atteler à l’inscrire sur

différentes listes blanches toujours dans le but d’améliorer le taux de livraison des

courriels envoyés par le système.

Au commencement de mes recherches sur la gestion du spam dans les systèmes de

marketing par courriel, je pensais qu’il fallait s’inscrire sur un maximum de liste

blanche.

Cependant, je me suis rendu compte qu’aujourd’hui il existe beaucoup de confusions

et d’incompréhensions dans le « whitelisting » et particulièrement sur son effet et son



fonctionnement. Comme un grand nombre de choses dans le marketing par courriel, la

situation a évolué.

Le système de liste blanche existe depuis le début du marketing par courriel où le

filtrage du spam était plus simple. Le blocage était généralement effectué

manuellement sur une base site par site ou par l’utilisation de listes DNS noires. Une

liste noire étant une liste d’expéditeurs qui ont été exclus ainsi les courriels ne sont

pas livrés. À l’opposé, la liste blanche est en quelque sorte un laissez‐passer pour les

expéditeurs. En général, les listes blanches n’étaient pas aussi largement utilisés que

les listes noires. Elles n’étaient là que pour traiter les exceptions et les échecs de

filtrage, comprenant les faux positifs des listes DNS noires.

Dans les années 90, certains FAI ont commencé à utiliser le « whitelisting » pour le

marketing par courriel. Le volume grandissant et la terminologie du marketing par

courriel se développant, de nombreux courriels se sont retrouvés pris par les systèmes

de filtrage du spam, relativement simple à l’époque. Ces listes blanches étaient

souvent gardées secrètes par crainte que les spammeurs les découvrent.

Aujourd’hui, ces listes se sont radicalement sophistiquées et font partis de

l’infrastructure de filtrage d’un FAI. Toujours basées sur des listes d’adresses IP ou

courriels, ces listes ne sont plus un laissez‐passer direct pour une bonne livraison. Par

contre, souvent, ces listes donnent un traitement préférentiel variant d’un fournisseur

d’accès à l’autre. Encore que tous les FAI ne possèdent pas de listes blanches comme

Hotmail et Gmail.

Ainsi, les listes sont désormais plus utilisé d’une manière réactive plutôt que proactive

et les FAI les utilisent comme dernier recours pour le filtrage des problèmes au lieu

d’une procédure standard pour les expéditeurs à haut volume.

En résumé, les listes blanches sont des outils importants, utiles et parfois nécessaires

dans certains cas mais cela ne remplacent pas de bonnes pratiques de gestion des

listes et le respect des normes et lois. Être présent dans des listes blanches n’est pas

une assurance de bonne livraison des courriels envoyés par le système.

Une fois cette mise au point faite, j’ai pu commencer à inscrire HPJCC sur les listes

blanches de différents FAI.

Après avoir recherché quels sont les FAI qui proposent des listes blanches où s’inscrire,

il s’est avéré que seulement AOL et Yahoo en propose. Hotmail et Gmail n’en

proposent pas. Je n’ai pas pu trouver l’information pour Bell et Videotron (Word To

Wise, 2010).



Pour pouvoir s’inscrire à la liste blanche d’AOL (http://postmaster.aol.com/cgi‐

bin/whitelist/whitelist_guides.pl), il faut respecter les critères suivants :

Paramétrer la Feedback Loop d’AOL et donc ses critères (j’expliquerais ce

terme plus loin dans le document) :

o Avoir les adresses courriel [email protected] et

[email protected] paramétrées et valide.

o Avoir un enregistrement DNS WHOIS valide pour le domaine en question.

o Enregistrer l’adresse abuse auprès du service AOL pour qu’ils puissent

envoyer les plaintes des utilisateurs vers [email protected].

o Confirmer la paternité sur l’adresse IP.

Les courriels provenant de l’adresse IP qui sera dans la liste blanche doivent

être conforme avec la loi CAN‐SPAM. D’où la nécessité de connaître cette lois

même si on ne commerce pas à partir des États‐Unis.

Posséder les preuves pour prouver à AOL que les courriels envoyés ont bien été

sollicité par les destinataires dans le cas où AOL demande des justifications.

Ces preuves peuvent être la date et l’heure à laquelle l’adresse courriel a été

obtenue et comment l’adresse a été obtenue.

De posséder une bonne gestion des rebonds afin d’éviter de renvoyer plusieurs

fois un courriel à une adresse qui n’existe plus.

Cependant, il est indiqué clairement qu’en aucun cas le respect de ses exigences ou la

présence dans la liste blanche, n’assurera que les courriels seront bien délivrés dans

tous les cas.

Premier constat pour pouvoir nous inscrire sur la liste blanche d’AOL, à ce stade, il

nous manque :

Les adresses courriels [email protected], [email protected] et [email protected]

doivent être crées,

Une gestion complète des rebonds.

Ces adresses courriels seront utilisées pour gérer l’aspect livraison des courriels.

L’adresse abuse@ est absolument nécessaire car elle est utilisée par les FAI pour

traiter les plaintes directes des abonnées ou d’autres problèmes liés à

l’authentification.

Le courriel débutant par fbl@ est utilisé dans le cadre de la mise en place des

procédures traitant les plaintes pour spam émises par les destinataires des courriels.

La boite alerts@ va servir à gérer les diverses erreurs et alertes qui peuvent être

déclenchées par le moteur d’envoi de courriel par exemple.



Donc même si on possède une check‐list des actions à mener pour mettre en place une

gestion complète du spam dans un système de marketing par courriel, j’ai pu me

rendre compte qu’on ne peut pas effectuer toutes ses tâches de manière linéaire mais

on doit en effectuer une majorité en parallèle.

J’ai tout de même regardé les critères d’inscription à la liste blanche chez Yahoo

(http://help.yahoo.com/l/us/yahoo/mail/postmaster/bulkv2.html). La procédure

consiste à remplir un formulaire qui sera traité par les équipes de Yahoo. Par contre,

eux aussi possèdent une liste de critères qui m’a empêché d’inscrire HPJCC dans leur

liste blanche :

Utilisation de DKIM et/ou DomainKey pour signer les courriels sortant du

serveur.

Gestion précises des rebonds : combien de fois une adresse courriel doit être

reconnue comme « soft bounce » pour être retirées de la liste ? Combien de

fois pour une adresse courriel qui « bounce en hard » ?

Deuxième constat, ici aussi on a besoin d’une gestion des rebonds déjà mise en place

pour pouvoir s’inscrire à leur liste. Mais nous voyons également un critère

supplémentaire lié à l’authentification des courriels sortants en obligeant au moins

l’utilisation de DKIM.

Une fois le nombre de listes blanches de FAI épuisé, je me suis dirigé vers DNSLW qui

est un service de « whitelisting » utilisé entre autre par la solution anti‐spam

SpamAssasin. Ce service, leader dans ce segment avec 50 000 organisations qui l’utilise

dans le monde, contient près de 100 000 entrées de bons serveurs mails. En provenant

de l’un des quatre niveaux de confiance de filtrage de DNSLW, les courriels ont plus de

chances d’arriver à bon port. Ces quatre niveaux sont les suivants : aucun, faible,

moyen et haute confiance (Figure 3 ‐ Niveau de Confiance chez DNSWL.org). Le

passage d’un niveau à un autre dépend en autres de la réputation du serveur d’envoi

et du nombre de plaintes reçus. C’est une confiance qui se met en place sur le long

terme.

Pour conclure sur le « whitelisting », il faut dans la plupart des cas que l’application

soit développée ou particulièrement bien avancée dans son développement pour

pouvoir s’inscrire à une liste blanche.

En résumé, il faut que l’application possède une gestion complète des rebonds,

l’authentification des courriels sortants avec DKIM et les Feedback Loop misent en

place.



Deux dernières choses à faire dans les préalables à mettre en place pour un système

de marketing par courriel :

Créer des adresses courriels dans les FAI majeurs,

S’enregistrer auprès du service Abuse.net.

Après mes différentes recherches, je conseillerais de créer deux types de comptes

dans tous les FAI majeurs. En effet, un compte sera utilisé à des fins de tests tandis

que l’autre courriel sera utilisé pour le support, outils et tous ce qui est liés au

transport des courriels au niveau des FAI.

Par exemple, Windows Live SNDS nécessite un compte courriel Windows Live (ex.

Hotmail) afin de s’inscrire à leur service. AOL, eux, demandent des adresses courriels

fbl@ et abuse@.

Autre conseil, ne pas utiliser de compte personnel pour cela, imaginons que la

personne propriétaire du compte quitte votre société. Un transfert de paternité peut

s’avérer difficile.

Abuse.net est un service qui permet aux utilisateurs de consulter une base de données

qui leurs permettra d’entrer en contact avec la personne responsables des courriers

considérés comme indésirables par les destinataires. En quelque sorte, on pourrait

comparer ce service à un Pages Jaunes des adresses courriels abuse@ en fournissant

une adresse IP ou un nom de domaine.

MODIFICATIONS DE L’APPLICATION ET EXTENSIONS ENVISAGÉES

Dans cette section, je vais aborder ce qu’il faut voir apparaître dans un courriel envoyé

par un système de marketing par courriel, quelles sont les informations à rajouter dans

les header afin de combattre le spam et avoir des données pour les statistiques. Enfin

j’aborderais des extensions possibles à l’application actuelle afin de toujours amélioré

le service et automatiser certaines actions.

D’après les lois en vigueur, un certain nombre d’informations doivent être présente

dans le courriel. Ces informations ont plusieurs buts : informer pourquoi le

destinataire reçoit le courriel, montrer l’identité de l’émetteur et permettre au

destinataire de ne plus recevoir vos communications.

Nous devons donc nous assurer que lors d’un envoi les informations suivantes soient

présentes :

Nom de l’émetteur,

Adresse postale physique de l’émetteur,



Courriel de l’émetteur,

Téléphone de l’émetteur,

Un aide‐mémoire expliquant pourquoi le destinataire a reçu le courriel

Un lien de désinscription.

Un aide‐mémoire va aider les destinataires à se souvenir pourquoi vous leur envoyer

ce courriel. De plus, cela permet généralement d’éviter que votre courriel soit reporté

comme un spam.

Un bon aide‐mémoire pourrait être un message comme celui‐ci :

« Dans le passé, vous avez fournis à HPJ Solutions votre adresse courriel

[email protected].

Parfois, vous recevrez des annonces publicitaires au sujet des spéciaux. Si vous ne

souhaitez plus recevoir ces annonces, s’il vous plaît cliqué sur le lien de désinscription

pour annuler votre abonnement.

Si vous avez besoin d’aide, n’hésitez pas à nous contacter par courriel à l’adresse

suivante [email protected] ou en nous envoyant une lettre à l’adresse

suivante : HPJ Solutions Service à la clientèle, 5605 avenue de Gaspé, Local 508,

Montréal (QC) H2T 2A4. »

En arrivant à HPJ Solutions, une partie de ses informations étaient déjà présentes la

plupart du temps mais sans vérification automatique et blocage en cas de manque.

Une de mes tâches a donc été d’améliorer le système pour faire en sorte qu’au

moment de l’envoi, une vérification sur la présence de ces informations nécessaires

soit bien faite. Dans le cas où cela ne l’était pas, je devais bloquer l’envoi en informant

le client du pourquoi.

Une fois cette étape faite, il a fallu que je m’attèle à mettre en place tous les headers

nécessaires pour le suivi et la lutte contre le spam, les désinscriptions, les feedback

loop et pleins d’autres données qui maintenant se retrouve dans les headers.

Les modifications à apporter au système ont été à faire dans le MailCenter car c’est

cette partie de l’application qui est responsable de l’envoi des courriels.

Voici donc la liste des headers que j’ai ajoutés lors de l’envoi des courriels :

Gestion des désinscriptions :

o X‐Unsubscribe‐To : une adresse courriel valide qui peut être utilisée

pour se désinscrire,

o X‐Unsubscribe‐URL : une URL complète utilisée pour le désabonnement

automatique. Une demande envoyée à cette URL doit désinscrire le

destinataire,



o List‐Unsubscribe : header utilisé par Windows Live, CloudMark et

bientôt Outlook pour générer un bouton Se désabonner. Ce header se

compose de la manière suivante : <mailto:[email protected]>,

<http://hpjcc.com/member/unsubscribe/>. Il a été défini dans la RFC

2369 en Juillet 1998 (Baer, 2006).

Gestion des plaintes :

o X‐Abuse‐To : adresse courriel vers laquelle les FAI ou autres opérateurs

doivent faire parvenir les rapports d’abus pour un expéditeur donné,

o X‐Abuse‐URL : il s’agit d’une URL utilisée pour le signalement d’abus de

manière automatisée. Une demande envoyée à cette URL doit signaler

un cas de spam pour tel destinataire et tel campagne,

o X‐Abuse‐Copy : adresse courriel générique où une copie de tous les

rapports d’abus devrait être envoyée.

o X‐Report‐Abuse : Message avec un lien vers une page permettant de

reporter un abus. Cet header est similaire à X‐Abuse‐URL.

Gestion des bounces :

o Return‐Path : adresse courriel vers laquelle les rebonds doivent être

envoyés pour une bonne gestion des contacts.

Données :

o X‐Message‐ID : identifiant unique permet de retrouver la campagne, la

newsletter et le contact correspondant à un courriel car il est important

de noter que les courriels des destinataires ne sont pas forcément

indiquer dans les bounces ou autres rapports. De plus, cet header ne

doit pas afficher clairement les données pour des questions de sécurité.

Une fois les informations obligatoires mise en place et les headers ajoutés, j’ai pu

réfléchir sur certaines extensions au projet qui pourraient être bénéfique à HPJCC.

En premier lieu, j’ai pensé qu’une option permettant aux clients de visualiser le

contenu de leur courriel dans les principaux clients mails (Gmail, Outlook, Mail, Yahoo

Mail, …).

En plus de ces options, il serait bien que les courriels passent un outil de test dans les

principaux anti‐spams afin de déterminer ce qui doit être changé dans le courriel afin

d’avoir le meilleure score possible par rapport aux solutions anti‐spam.

Des sites web comme Email on Acid (http://www.emailonacid.com/) fournissent déjà

ce genre de prestations avec en plus dans ce cas‐là, une API accessible. Cette idée est

en cours de réflexion pour une implémentation future dans le système.



Enfin, on pourrait vérifier de manière proactive l’existence des courriels ajoutés au

référentiel via un outil de test des courriels.

Autre projet qui apportera un plus aux clients du système serait un outil de

suggestions de sujets des newsletters. Couplé à une vérification anti‐spam et en

fonction des courriels déjà envoyés, on pourrait fournir un service qui aiderait les

clients à optimiser les sujets de leur communication marketing.

Deux derniers outils qui faciliteraient la vie aux clients seraient :

Outil de transformation de l’HTML vers une version texte car il est nécessaire

qu’une version texte des courriels soit présente dans le cas que le destinataire

utilise un client mail incapable de lire les courriels HTML.

Outil de transformation du CSS pour le mettre en « inline » car de nombreux

clients mails n’interprète pas le CSS qui se trouve dans une balise style par

exemple.

En conclusion à cette partie, le fait d’avoir obligé la présence de certaines

informations a permis de diminuer le nombre de plaintes pour spam car les

destinataires se sont rappelés pourquoi ils ont reçu les courriels. De plus,

l’implémentation des différents headers a donné la possibilité aux destinataires

d’avoir différents moyens de reporter un abus, de se désinscrire en plus du fait que

ces headers ont permis de faire un suivi.

Enfin, même si le développement de l’application HPJCC est bien avancé, un certain

nombre d’outils pourraient faire une grosse différence avec la majorité des

concurrents car peu de ceux‐ci proposent des outils similaires.

L’ARCHITECTURE PHYSIQUE

Choisir la bonne infrastructure est une grande partie de la conception d’un système de

marketing par courriel. Au moment des choix, on doit garder un certain nombre de

choses à l’esprit. Tout d’abord, il est fortement déconseillé d’utiliser un

environnement de Cloud Computing comme Amazon car ceux‐ci ne sont aucunement

adaptés pour l’envoi de courriel. Ces environnements sont également de plus en plus

utiliser par les spammeurs.

D’après moi, l’architecture physique d’un tel projet est plus important que le

développement en lui‐même. En effet, vous pouvez avoir la meilleure application qu’il

est possible de faire mais si votre infrastructure ne supporte pas la charge qu’un tel

système génère, l’application devient inutile.



Lors de la mise en place de l’architecture physique d’un tel projet, on doit décider d’un

certain nombre de points comme : quel MTA va‐t‐on utiliser ? Va‐t‐on mettre en place

une authentification des courriels ? Est‐ce que j’envoie à partir d’une seule IP ou à

partir d’un pool d’IP ?

Commençons avec les questions suivantes : est‐ce que je dois envoyer mes courriels à

partir d’une adresse IP dédiée ? Dois‐je utiliser un pool d’adresses IP ?

IP DÉDIÉE OU IP PARTAGÉE ?

La réponse à la première question revient à la notion de réputation expliquée

précédemment. En effet, dans le cas de l’utilisation d’une nouvelle adresse IP dédiée,

cette dernière ne possède pas encore de réputation. Du coup, les systèmes de filtrage

du spams se montrent suspicieux envers cette nouvelle adresse IP et peuvent aller

jusqu’à bloquer l’adresse IP en question tant que celle‐ci n’aura pas une réputation au

moins normale.

Il est donc important de faire très attention à la réputation de son adresse IP en

surveillance celle‐ci grâce aux outils abordés dans la section préalables à une solution

de marketing par courriel.

Idéalement, un système de marketing par courriel devrait utiliser différentes gammes

d’adresses IP :

Partagée : pour les comptes gratuits et les nouveaux clients,

Confiance : pour les clients de longue date avec de bonnes statistiques,

Double opt‐in : pour les utilisateurs qui n’importent jamais de contacts dans

leur référentiel autrement que via un formulaire web,

Dédiée : pour les clients à haut‐volume qui ont acheté et configuré une IP

dédiée à leur compte.

L’utilisation d’un pool d’IP s’avère nécessaire à partir du moment où le système

possède un volume d’envoi acceptable car envoyer trop de courriels à partir d’une

même adresse IP peut s’avérer problématique lorsque par exemple un client effectue

un envoi avec un important taux de plaintes. Dans ce cas, l’adresse IP sera bloquée

pour tous les clients l’utilisant.

Cependant, le problème inverse existe : si l’adresse IP n’a pas assez de trafic, sa

réputation restera basse et par la même occasion pourra être bloquée.

Aussi, les solutions de gestion des spams s’équipent de plus en plus de pare‐feu et

l’utilisation d’un pool permet de facilement gérer le fait qu’une des adresses du pool

se retrouve bloquée.



Au niveau de la dénomination du pool, il ne faut pas utiliser de noms de domaine mais

il est préférable d’utiliser le schéma suivant : xx1.hpjcc.com.

Il faut donc trouver un juste milieu entre nombre d’adresses IP et le volume généré

par le système.

Pour HPJCC, la décision a été d’utiliser une adresse IP pour tous les clients le temps

que le volume d’envois soit assez important pour en utiliser une deuxième.

QUEL MTA UTILISER ?

Une fois que le nombre et type d’adresse IP a été déterminé, il faut choisir quel Mail

Transfert Agent (MTA) utiliser.

Un MTA est un logiciel pour serveur de transmissions de courriels ayant pour rôle de

redistribuer les courriels qu’il reçoit par les clients de messagerie (MUA) ou par

d’autres MTA vers des Mail Delivery Agent ou vers d’autres MTA.

Il existe un grand nombre de MTA sur le marché qu’ils soient gratuits ou payants. Les

plus populaires sont aujourd’hui : qmail, postfix, sendmail, exim ou Power MTA. Les

produits commerciaux ont de multiples avantages sur les produits gratuits comme la

surveillance et la configuration des interfaces utilisateurs, la configuration des

administrateurs ou encore la facilité générale d’utilisation.

Cependant, ils ont un coût qui n’est pas envisageable pour beaucoup d’entreprises se

lançant dans ce type de projet.

Pour HPJCC, le choix s’est porté sur postfix pour les raisons suivantes :

Supporte la charge et est adapté à de gros envois,

Simple à configurer,

Possède de bonnes performances.

Toujours par rapport à l’architecture, il faut s’assurer que l’enregistrement Whois du

domaine est entièrement complété avec toutes les informations dont celles pour le

rapport d’abus. Il faut s’assurer l’adresse physique soit inscrite ainsi que le nom de

l’organisation qui est associé au courriel. Il faut effectuer cela pour tous les domaines

et adresses IP des clients utilisant le service HPJCC.

Les informations du WHOIS sont importantes dans le cadre des inscriptions aux listes

blanches, feedback loop et d’autres processus d’enregistrement. Par exemple, si les

informations présentent dans le Whois ne correspondent pas à la société émettrice,

une demande à Microsft SDNS pourrait échouer.



De plus, il est important de configurer les reverses DNS pour vos domaines et adresses

IP. Il faut s’assurer que les enregistrements MX soient correctement configurés.

Aussi, je conseillerais aussi de ne pas envoyer les courriels transactionnels comme les

inscriptions ou les désinscriptions via la même adresse IP que les communications

marketing envoyés par le système.

Enfin, une des bonnes pratiques est de publier l’adresse IP du serveur d’envoi de

courriel. Cette publication servira de référence et permettra aux gens de vous

« whitelister » ou « blacklister ».

L’AUTHENTIFICATION DES COURRIELS

Si vous comptez envoyer des courriels marketing, il est nécessaire d’utiliser une forme

d’authentification. L’authentification n’est absolument pas facultative et il est

fortement recommandé d’implémenter toutes les formes d’authentification possibles.

Certains FAI commencent à ne plus délivrer les courriels si ces derniers ne sont pas

envoyés avec leur méthode d’authentification recommandée. Du coup, en configurant

votre système de courriel marketing pour qu’il envoi des courriels authentifiés, ces

derniers passeront certains filtres sans problèmes ce qui leur donnent plus de chances

d’arrivée dans la boite de réception de vos contacts.

De plus, certains FAI comme Yahoo! et Windows Live Mail marque vos courriels

comme authentifiés (Figure 6 ‐ Différence entre un courriel authentifié ou pas dans

Yahoo! Mail) si tel est le cas, ce qui contribue à renforcer la confiance entre l’émetteur

et le destinataire et améliore les chances d’ouvertures de vos courriels.

À l’heure actuelle, il existe deux branches dans les types d’authentifications :

SPF et SenderID qui reste relativement simple à mettre en place, requiert un

enregistrement TXT dans votre DNS,

DKIM et Domain Keys est directement intégré dans le code du courriel. Cette

méthode est par contre plus compliquée à mettre en place mais est plus

sécurisé dans le sens où il y a plus de chances de ne pas recevoir de spam.

Le problème du moment est qu’il n’existe aucune norme du coup les FAI ne sont en

aucun obligés d’utiliser toutes les méthodes d’authentifications.

La Figure 4 ‐ Méthodes d'authentification chez les principaux ISP montre quelles sont

les méthodes qu’utilisent les différents FAI et on voit clairement qu’en quelque sorte,

chacun fait un peu ce qu’il veut. L’exemple le plus flagrant est la décision de Microsoft

de créer sa propre méthode d’authentification Sender ID qui est une déclinaison de

SPF.



Sender ID fonctionne sur la vérification via une entrée TXT dans l’enregistrement DNS

du nom de domaine. En théorie, il suffit d’ajouter un enregistrement dans la

configuration DNS du domaine pour que celui‐ci soit accepté par les services de

Microsoft.

Techniquement, le système envoi un courriel reçu par le serveur de courriel du

destinataire qui appel son Sender ID Framework. Ce dernier vérifie l’enregistrement

SPF du domaine utilisé par l’expéditeur. Enfin, le MTA détermine si l’adresse IP du

serveur sortant correspond à une des adresses qui sont autorisés à envoyer des

courriels pour l’utilisateur (Figure 5 ‐ Fonctionnement du SPF).

Microsoft fourni un générateur de SPF / Sender ID permettant de générer

l’enregistrement TXT à mettre dans la configuration DNS du domaine expéditeur.

Pour HPJCC, la ligne qui a été rajouté est la suivante : v=spf1 a mx

ip4:207.253.240.141 –all

Un champ SPF est sous la forme : domain.tld. IN TXT « v=spf1 ptr [a[:mail.mon‐

domaine.fr,mail2.mon‐domaine.fr]] [mx[:mon‐domaine.fr]]

[ip4:11.12.13.14,15.16.17.18] [include:example2.com] ~all »

Cet enregistrement signifie que sont autorisés à envoyer des courriels les serveurs :

a : Qui sont spécifiés dans les enregistrements A du domaine,

a :mail.domain.tld : Les serveurs spécifiés après a :,

mx : Qui sont spécifiés dans les enregistrements MX du domaine,

mx:domain.tld : Serveurs du domaine spécifiés,

ip4:liste_ip : Les ips de serveurs,

include:domain.tld : Inclus l’enregistrement SPF du ou des domaine(s) listé(s)

Cependant, l’ajout de cette entrée dans la configuration DNS ne suffit généralement

pas. Si après plus de 48h d’attente, vos courriels sont toujours refusés par les serveurs

de Microsoft, un formulaire est mis à disposition par Microsoft pour forcer les filtres à

accepter les courriels envoyés par votre système de marketing par courriel. Le

formulaire est disponible à l’adresse suivante :

https://support.msn.com/default.aspx?productKey=senderid&locale=en‐

us&st=1&wfxredirect=1

Une fois le formulaire soumis vous recevrez au bout de un ou deux jours une réponse

de la part des services de Microsoft.



DomainKeys est une technologie développé par Yahoo qui repose sur le principe de

signer tous les courriels émis avec une clef privée et de diffuser la clef publique

correspondante via une entrée DNS afin que les serveurs destinataires puissent

vérifier l’authentification du courriel.

Les courriels envoyés contiennent un header supplémentaire nommé : « DomainKey‐

Signature » spécifiant différents éléments, dont l’algorithme de chiffrement utilisé (a),

le domaine concerné (d), un sélecteur (s) et la signature du message elle‐même (b). Le

sélecteur permettant de travailler avec plusieurs clefs.

Le header pourrait par exemple être le suivant : DomainKey‐Signature: a=rsa‐sha1;

q=dns; c=nofws; s=s1024; d=yahoo.com; h=X‐YMail‐

OSG:Received:Date:From:Subject:To:Message‐ID; b=cuXRK(...)vazo=

Une requête DNS de type TXT sur l’entrée du sélecteur défini dans

l’email : « s1024._domainkey.yahoo.com » permet de retrouver les informations

nécessaires sur la clef publique du domaine et vérifier l’authenticité du mail : « k=rsa;

t=y; p=MIGADCBiQKBgQD(...)B; n=A 1024 bit key; »

DomainKeys Identified Mail (DKIM) est un draft (au send IETF) issu de la fusion de

DomainKey crée par Yahoo et d’Identified Internet Mail crée par Cisco. Tout comme

DomainKeys, DKIM spécifie comment signer les messages en utilisant un chiffrement

asymétrique, en publiant les clefs publiques via une entrée TXT de la configuration

DNS et en confiant le processus de signature au serveur de messagerie. La différence

entre DomainKeys et DKIM réside dans le fait que le signataire peut être différent de

l’auteur et de l’émetteur, le champ de signature est auto‐signé et la signature peut

inclure un délai de validité.

Vous pourrez retrouver comment fonctionne DKIM dans la Figure 7 ‐ Fonctionnement

de DKIM (Yahoo! Inc.).

Pour HPJCC, nous avons utilisé l’implémentation « milter » de DKIM.

Pour cela, on a tout d’abord installé DKIM‐milter.

L’étape suivante fut de générer les clefs avec la commande suivante :

sh /usr/share/doc/dkim-milter-2.8.2/dkim-genkey.sh -r -d hpjcc.com

Cette commande permet de créer deux fichiers :

default.txt : qui contient la clé publique que nous devons publier via une entrée

TXT de la configuration DNS du domaine.

default.private : la clé privée utilisée pour signer les courriels.



On doit ensuite déplacer la clé privée vers le dossier de dkim‐milter et sécuriser le

fichier.

Pour cela, il a fallu faire :

mv default.private /etc/mail/dkim/default.key.pem chmod 600 /etc/mail/dkim/default.key.pem chown dkim-milt.dkim-milt /etc/mail/dkim/default.key.pem

Ensuite, il a fallu publier la clé publique dans l’enregistrement DNS du domaine. Cette

clé sera utilisée pour vérifier la signature des courriels.

L’enregistrement a inséré est le suivant :

HPJCC._domainkey.hpjcc.com IN TXT "k=rsa\; p=MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBAMBWBJrpUWdEHsoV79XlhnoAs7FLjQ0T61HKiow0CAKKjMQZYd0ThxEM/g0FPMPTCzsAvobexk63+P8z4EN7qQsCAwEAAQ=="

Un autre enregistrement est à ajouter :

_domainkey.hpjcc.com IN TXT "t=y; o=~;"

On passe ensuite à la phase de configuration en créant le fichier dkim‐milter dans le

dossier /etc/sysconfig/ en mettant le contenu suivant :

USER="dkim-milt" PORT="inet:20209@localhost" SIGNING_DOMAIN="hpjcc.com" SELECTOR_NAME="default" KEYFILE="/etc/mail/dkim/default.key.pem" SIGNER=yes VERIFIER=yes CANON=simple SIGALG=rsa-sha1 REJECTION="bad=r,dns=t,int=t,no=a" EXTRA_ARGS="-h -l -D"

Dans postfix, nous devons rajouter deux options pour qu’il utilise dkim‐milter.

smtpd_milters = inet:localhost:20209 non_smtpd_milters = inet:localhost:20209

Une fois tout cela fait, il faut lancer le service de dkim‐filter et redémarrer postfix.

Une fois ces types d’authentifications configurés, il faut les tester afin de vérifier leur

bon fonctionnement. Pour cela, il existe des services comme celui offert par Port 25.

Son fonctionnement est des plus simples, Il suffit d’envoyer un courriel à check‐

[email protected] pour obtenir le récapitulatif des résultats (Figure 8 ‐

Résultats de verifier.port25).



GESTION DES LISTES DE CONTACTS

Dans cette semaine, je vais aborder un point qui est encore un point réellement

important dans un système marketing par courriel comme HPJCC.

J’ai précédemment montré l’importance de la réputation pour un système de

marketing par courriel. Mais il y a un préalable à cette réputation, c’est une bonne

gestion des contacts de son système. Cette bonne gestion peut se résumer en un seul

mot : permission.

Ci‐dessous vous retrouverez quatre exemples de mauvaises habitudes de la part de

personnes effectuant des envois marketing :

Le responsable marketing a légitimement collecté des courriels à travers un

formulaire opt‐in affiché sur leur site web mais a mis beaucoup de temps pour

contacter ses contacts. Les destinataires reçoivent une newsletter de sa part

mais ne se souviennent plus de cette société car ils se sont enregistrés il y a

deux ans.

Une société possède une boutique en ligne. Elle possède des milliers d’adresses

courriels appartenant à ses clients qui ont acheté des produits par le passé.

Maintenant, cette compagnie souhaite envoyer une newsletter à clients. Au

lieu de demander aux clients de se joindre à leur liste d’envoi, la société a juste

commencé à envoyer ses newsletters.

Un commerçant possède un stand à une foire commerciale. L’organisation du

salon a fourni au commerçant la liste des participants avec leurs adresses

courriels. Au lieu d’envoyer un courriel à ces personnes pour les inviter à

rejoindre sa liste de diffusion en leurs expliquant comment il a obtenu leurs

adresses courriels, le commerçant a supposé qu’ils ont donnés leur permission

pour être contacter par les commerçants présents à la foire et leurs a envoyé

des courriels commerciaux et promotionnels.

Acheter une liste d’adresses courriels à une organisation, ajouter cette liste à

ses contacts et commencer à leur envoyer des communications marketing sans

obtenir leur permission préalablement.

Il y a un point commun ici. Dans tous les exemples, l’élément manquant est la

permission. Les responsables des envois sont bien en phase avec les lois en vigueur

cependant ils leur manquent une chose : la permission.

Dans ces cas‐ci, la définition du mot permission est que le propriétaire de l’adresse

courriel a accordé aux propriétaires de la liste d’envoi des droits pour envoyer un

courriel dans un but précis. Le respect de la spécificité du but est réellement

important. Lorsqu’une personne s’abonne à vos envois commerciaux c’est pour avoir



des informations précises. Vous devez donc être prudent car le respect de cette

permission donnée est un élément important dans le renforcement de la confiance

entre l'émetteur et ses contacts. Plus la confiance sera élevée plus la relation d’affaire

sera intéressante et productive.

Au moment où un contact donne la permission de lui envoyer des courriels, un certain

nombre d’informations doit être spécifiées :

Nature des envois : la demande d’autorisation doit préciser la nature des

envois qui seront effectués, par exemple newsletter, promotion, etc. …, Si une

personne a accordé sa permission pour recevoir un bulletin d’informations

professionnelles, cela ne signifie pas qu’ils ont également convenue de recevoir

des offres promotionnelles.

Fréquence des envois : vous devez indiquer la fréquence moyenne des envois

au cours du processus d’abonnement. Une personne pourrait être intéressée

par un bulletin hebdomadaire mais pas forcément par un bulletin quotidien.

Permission non transférable : les autorisations recueillis sont non transférables.

Si la permission d’utiliser une adresse courriel a été obtenue par la société X,

cette adresse ne peut ni être transférée ni être donné ni être vendu à la société

Y. Dans le même contexte, si un abonné a donné son autorisation au

département X, marque Y, Z ou de la division, cette liste ne devrait pas être

partagée avec d’autres ministères, marques ou divisions de la même société.

Retrait de l’autorisation : le propriétaire de l’adresse courriel doit avoir le droit

de retirer l’autorisation quand il le souhaite. Il est de la responsabilité du

propriétaire de la liste d’offrir aux membres de celle‐ci des moyens simples de

mettre fin à la réception des courriels en cas de besoin et de supprimer leur

courriel des listes de diffusions. Il est également important pour les

propriétaires des listes de réagir rapidement à ces demandes de retrait.

Pour être sûr d’avoir la permission de la part d’un contact de lui envoyer des courriels,

il n’existe qu’une seule méthode qui a déjà largement démontré son efficacité.

Cette méthode se nomme « double opt‐in ».

Qu’est‐ce que le double opt‐in ? Il s’agit d’une méthode de vérification des adresses

courriels.

Le processus est assez simple :

1. Une personne remplis un formulaire et clique sur soumettre,

2. Le système génère par la suite un courriel de confirmation qu’il envoi à cette

personne,

3. Le nouveau contact doit ensuite cliquer sur un lien pour valider son adresse

courriel et ainsi compléter le processus de double opt‐in.



Pourquoi doit‐on suivre cette méthode ? Tout simplement parce que cette méthode

réduit considérablement les plaintes relatives au spam étant donné qu’il n’y a aucun

cas de fausses adresses courriels dans votre référentiel. De plus, personne ne peut

s’inscrire à votre système de marketing par courriel avec une adresse courriel autre

que la sienne.

En conséquence, les plaintes pour spam reçu plus tard sont réfutables et proviennent

généralement d’une personne qui souhaite se désinscrire. Les autres possibilités sont

que la personne a oublié qu’elle s’était enregistrée ou qu’elle a souhaité généré

volontairement un rapport d’abus.

Avec la méthode de double opt‐in et les données associées à l’inscription, vous pouvez

prouver aux FAI et organismes mandatées dans la lutte contre le spam que le courriel

a été sollicité et que celui‐ci n’est pas du spam.

De nos jours, il existe trois principales raisons pour que les FAI bloquent vos courriels :

1. Vous avez envoyés un courriel à un adresse courriel dîtes « spam trap ». Cette

technique déjà abordé dans la partie traitant de la réputation est utilisée par

les FAI pour déterminer les compagnies ou individuels qui utilisent de vieille

liste de courriels. L’envoi d’un courriel à ces adresses peut parfois empêcher

vos courriels d’atteindre entièrement le FAI en question.

2. Trop de courriels envoyés rebondissent. La majorité des FAI vérifient et avisent

l’émetteur si un trop grand nombre de vos courriels ne sont pas livrables. Le

raison suivi par les autorités est qu’un référentiel sain doit être nettoyé des

mauvaises adresses qui ont rebondis et que le responsable du référentiel aurait

dû empêcher que ces adresses se retrouvent dans son référentiel.

3. Trop de rapport d’abus générés par vos courriels. Tous les FAI et gestionnaire

de messagerie Web suivent de près les statistiques relatives au clique par les

destinataires sur le bouton « ceci est un spam ». Ces mesures leur permettent

de déterminer les expéditeurs de courriers indésirables et ainsi de les bloquer.

Le double opt‐in réduit considérablement ces trois problèmes :

1. Les adresses « spam trap » ne sont pas dans votre référentiel car elles ne sont

pas des adresses de personnes réelles et donc qui ne peuvent pas cliquer sur le

lien de confirmation reçu.

2. Le taux de rebond va diminuer parce qu’en confirmant les adresses, vous

vérifiez leur validité avant de les ajouter au référentiel.

3. Le nombre de plaintes pour spam sera minimum du fait que vous vérifiez le

consentement des personnes avant de les ajouter au référentiel.



Après avoir pris conscience de ce principe de double opt‐in, j’ai pensé à des garde‐fous

qui devront être mis en place pour éviter un certain nombre de problèmes.

Tout d’abord concernant le processus de traitement du formulaire, il faudra

implémenter quelques limitations :

1. Inclure une fonction limitant le nombre d’envoi quotidien de demande d’opt‐in

pour une adresse courriel. Cela permet d’éviter que le système soit détourné

par un tiers et utilisé pour effectuer des attaques de types « mail bomber ».

2. Une option de suppression d’adresses courriels devra être mise en place pour

que lorsqu’un destinataire demande qu’on arrête de lui envoyer des courriels

de confirmation, on puisse le faire. On pourra également arrêter les envois

pour tout un FAI à la fois. Ceci permet de ne pas faire augmenter le risque de

bloquer nos courriels à cause de demande de confirmation.

3. On bloquera l’utilisation de certaines adresses courriels du type

[email protected], [email protected] ou [email protected]. Avec

cela, on incite les personnes à utiliser leur adresse courriel pour s’inscrire au

lieu d’une adresse qui peut être liée à une liste de diffusion. De plus, on évite

d’avoir de générer des rapports d’abus alors que l’inscription est légitime. En

effet, une personne utilise l’adresse info@ de son entreprise pour s’inscrire à

une liste de diffusion. Les courriels arrivant à cette adresse sont redirigés vers

19 autres personnes. Que vont‐elles penser ou faire lorsqu’elles vont recevoir

vos communications marketing ? Dans la majorité des cas, elles vont

simplement penser qu’il s’agit d’un spam et cliquer sur le bouton « ceci est un

spam ».

4. La page suivant la soumission indiquera clairement que le courriel envoyé doit

être lu et qu’il doit également agir à propos de ce courriel en cliquant sur le

lien présent pour valider l’inscription.

Ensuite au niveau du courriel de confirmation, nous mettrons les actions suivantes en

place :

1. Cryptage des informations vitales comme l’adresse courriel et l’action à

effectuer. Cela évitera qu’une personne mal attentionnée abuse de cela et

essaye d’inscrire d’autres personnes.

2. On a déterminé qu’il ne fallait pas inclure le lien de confirmation au sein d’une

image pour la raison que de plus en plus de clients mails bloquent les images

par défaut.

3. Pour contrer le fait que certains FAI bloquent les liens, on affichera l’url

complète pour que le destinataire puisse faire un copié‐collé.



Au niveau de la gestion des logs, il est important de bien stocker toutes les tentatives

d’inscriptions en collectant les adresses courriels, date, heure et adresse IP. Les clics

sur les liens de confirmation doivent être également enregistrés. Ces données

pourraient être très utiles en cas de plainte.

Nous allons aussi mettre en place un système nettoyant la base de données des

inscriptions non validées. La durée de présence maximale sans validation a été fixée à

30 jours.

En conclusion de cette section, il est important de se souvenir que les deux choses à

retenir son permission et double opt‐in. Ces deux expressions permettront à votre

système de marketing par courriel d’éviter un grand nombre de problème en

diminuant le nombre de rapport d’abus et en fournissant des moyens techniques pour

prouver que les courriels envoyés ont été sollicités.

SURVEILLANCE ET GESTION DES EXCEPTIONS

Une fois l’envoi effectué, il est important de faire un suivi et de gérer les exceptions

générées par le système. Cela permettra de vérifier la santé de l’infrastructure en

place.

La première étape à un bon monitoring des exceptions est la gestion des rebonds suite

à un envoi.

Autre procédure à mettre en place, les « feedback loop » (FBL) qui permettent de

recevoir un rapport dans le cas où un FAI émet un rapport d’abus par rapport à un des

envois du serveur.

Ensuite, il faut garder un œil sur les différents logs disponibles sur le serveur.

Pour finir, il reste des points à surveiller comme la réputation, la présence sur des

listes noires, le fait d’être bloqués par des filtres anti‐spam et le fonctionnement des

pare‐feu pour courriels.

GESTION DES REBONDS

La gestion des rebonds est un facteur essentiel dans le processus de livraison dans

l’infrastructure d’un système de marketing par courriels. Lorsque l’on envoie un

courriel à une mauvaise adresse ou que la boite de réception de celle‐ci est pleine, le

serveur de réception retournera un message avec la raison du rebond et donc de la

non livraison du courriel. Le message du rebond contiendra un entête « Diagnostic‐

Code » qui donnera le code du rebond, la raison de celui‐ci et toutes autres



informations qui peuvent être pertinente au rebond. Non seulement ces informations

sont nécessaires pour nettoyer le référentiel des contacts qui rebondissent mais vu

qu’il existe plusieurs types de bounces, le traitement est différents en fonction du type.

Il existe deux catégories principales : les hard bounces et les soft bounces.

Un hard bounce est un courriel qui est retourné à l’expéditeur parce que l’adresse du

destinataire n’est plus valide. Un rebond pourrait se produire parce que le domaine

n’existe plus ou parce que le destinataire est inconnu.

Il faut absolument traiter au plus vite les adresses courriels qui ont rebondis de

manière hard. Une adresse courriel qui a rebondis une fois en hard ne doit plus être

recontactée car pour les FAI cela pourrait signifier que le système utilise une vieille

liste et ainsi une mauvaise politique de gestion du spam.

Un soft bounce est un message qui est retourné à l’expéditeur parce que, par exemple,

la boite aux lettres est pleine ou quelle est momentanément indisponible.

En général, il est conseillé de traiter les adresses courriels qui ont rebondis X fois en

soft. Le nombre de fois doit être configurable dans le système.

Par contre, il est important de se rappeler qu’un rebond de type soft peut être un

problème temporaire et qu’il est possible que l’adresse soit valide.

Un système de marketing par courriels se doit de posséder un traitement automatisé

des rebonds. Cependant, cela peut rapidement devenir compliqué du fait que les

messages de rebonds peuvent être personnalisés par les administrateurs réseaux

récepteurs et les différents MTA du marché n’ont pas le même message pour le même

rebond.

Pour HPJCC, la première chose qui a été faite a été de fixer une adresse de retour

unique via l’en‐tête Return Path. Cette modification a été faite dans le MailCenter car

celui‐ci est responsable de la génération des courriels donc entre autre de la

modification des headers pour chaque courriel envoyé.

Ensuite, il a fallu déterminer comment nous allions traiter chaque courriel qui a

rebondis.

Deux choix se présentaient :

Créer une solution complète qui effectuerait toutes les étapes du traitement.

Trouver une solution existante qui fait toutes les étapes ou une partie de

celles‐ci.



Du fait des impératifs de temps et financiers liés au projet, j’ai me suis mis à la

recherche d’une solution permettant de traiter les bounces ou du moins qui permet

d’effectuer une partie du traitement.

Après avoir testé quelques solutions, mon choix s’est porté sur celle édité par la

société Worx International, PHPMailer‐BMH (Bounce Mail Handler).

Cette solution a l’avantage de proposer un ensemble de méthode permettant de :

Se connecter à une boite de réception d’une adresse courriel via le protocole

IMAP,

Lire les courriels de cette boite de réception,

Déterminer le type de bounces en fonction de règles préétablies.

De plus, l’autre avantage important de cette solution est qu’on peut ajouter nos

propres règles afin d’améliorer la détermination du type de rebond.

Pour finaliser le système de traitement des rebonds, il me restait à écrire la méthode

dite callback qui traite chaque courriel. Dans cette méthode, je recherche quel contact,

quelle newsletter et quelle compagnie sont concernés par le rebond.

Pour cela, j’ai fait en sorte que le système recherche le header X‐Message‐ID ajouté au

moment de l’envoi dans les différents headers et pièces jointes du courriel de rebond.

J’ai dû modifier le système afin d’ajouter une méthode permettant de récupérer de

manière récursive les différentes en‐têtes contenu dans le courriel. Il faut savoir qu’il

n’existe pas réellement de standard dans les courriels de rebonds donc on trouve une

multitude de format. C’est pourquoi il faut une méthode permettant la récupération

de tous les headers du courriel.

Une fois le script terminé, j’ai mis en place un cron s’exécutant toutes les nuits afin de

traiter les courriels arrivés dans la boite de réception avec un rapport d’exécution

nous informant de combien de bounces ont été traités en les classant par type et par

compagnie.

Ce système est maintenant en place depuis plusieurs mois car il s’agissait d’une tâche

prioritaire à mon arrivée.

Il a permis de nettoyer les listes des clients du système mais également de prévenir un

des clients d’arrêter d’utiliser des listes achetées de courriels.

LES FEEDBACK LOOP

Une fois que cette étape de gestion des rebonds est mise en place et fonctionnelle. Il

est conseillé de s’occuper des plaintes des utilisateurs.



Les Feedback loops ou FBL permettent en tant qu’expéditeur d’obtenir des rapports de

la plupart des FAI lorsque quelqu’un reporte votre envoi comme spam.

En résumé, il faut s’inscrire auprès des FAI pour faire partie du processus de FBL et

lorsque que quelqu’un clique sur « Signaler comme spam », le FAI va envoyer un

message formaté au format ARF dès lors que le taux de plainte pour votre newsletter

dépasse la limite fixée par le FAI en question. Par exemple, pour AOL, le taux de

plaintes ne doit pas dépasser les 0,1 pour 100 soit une plainte pour 1 000 envois

(ClickZ, 2006).

Un rapport ARF est un message MIME composé de trois sections : une description

lisible par un humain, les métadonnées lisibles par une machine et une copie du

courriel d’origine.

Ce rapport qui est envoyé doit être traité en priorité et le contact en question doit

être retiré de la liste immédiatement.

Pourquoi les personnes cliquent sur le bouton spam au lieu de simplement se

désabonner ? Par ce que généralement il y a un problème de permission lors de l’envoi

ou que l’émetteur a mis beaucoup trop de temps avant d’envoyer ses communications

marketing.

Il y a un certain nombre de bonnes pratiques à adopter pour prévenir les rapports

d’abus.

Tout d’abord, l’utilisation de la méthode de double opt‐in expliquée précédemment

vous permet de posséder une preuve que tous les contacts du référentiel ont donné

leur permission de leur envoyer des courriels.

Même s’il s’agit de vos clients, il ne faut pas envoyer de promotions sans leur

consentement. Il faut obtenir leur permission avant de les rajouter à la liste d’envoi.

Pour cela, vous pouvez leur dire que vous êtes sur le point de lancer un bulletin

électronique et donner leur des raisons pour qu’ils s’inscrivent.

Ensuite, il ne faut absolument pas utiliser de listes achetées. C’est un gaspillage de

d’argent et ces listes sont généralement truffées de fausses adresses courriels.

Il ne faut pas masquer le lien de désinscription. Au contraire, il vaut mieux qu’il soit

visible car qu’est‐ce qui est le pire entre un clic sur le lien de désinscription ou sur le

bouton spam ?

Il faut également s’assurer que les courriels envoyés paraissent digne de confiance. Si

votre courriel ne semble pas professionnel, qui ferait confiance à votre lien de

désabonnement ?



Il est important de mentionner que les headers jouent un rôle important dans le

traitement des FBL. L’information est vitale car tous les FAI fournissent un rapport

standard de format ARF comprenant les headers personnalisés indiquant compte,

courriel, etc. … Ils n’ont aucune obligation d’inclure le destinataire du courriel et ils

peuvent en parti couper certains headers. Il faut s’assurer que le processus de

traitement des FBL soit capable de traiter les headers multiples et qu’il alerte une

personne dans les cas où le traitement automatisé échoue.

Étant donné que l’adresse du destinataire du courriel peut ne pas apparaitre dans le

rapport, il faut donc faire en sorte d’intégrer un identifiant dans les headers du

courriel envoyé d’où la présence du header X‐Message‐ID.

Tout comme les rebonds de type hard, les rapports d’abus doivent être traités en

priorité car si on continu d’envoyer des courriels à une personne qui s’est déjà plainte,

les FAI peuvent assez facilement vous placer en liste noire. Cela affectera grandement

votre capacité de livraison des courriels et votre réputation.

Ces données doivent être gardées dans le but de pouvoir afficher les statistiques

d’abus pour chaque newsletter envoyées et elles pourront également servir dans le

cadre d’une procédure de suspension du compte d’un de vos clients si celui‐ci a bien

envoyé du spam.

HPJCC va être inscrit à différentes Feedback Loop.

Le premier programme auquel HPJCC a été inscrit est celui de MSN / Windows Live, le

programme Junk Mail Reporting Partner Program (Microsoft Corporation).

Ce service gratuit permet de fournir les rapports sur les problèmes de courrier

indésirable signalés par les utilisateurs de Windows Live Hotmail.

L’inscription consiste à remplir un formulaire où il vous sera demandé de fournir les

adresses IP à partir desquelles des courriels seraient envoyés, un lien de

désabonnement pour toutes les listes ou un lien vers la politique de vie privée du

service et une adresse courriel vers laquelle les plaintes doivent être transférées.

Une fois le formulaire soumis, on reçoit un courriel nous informant que pour valider

l’inscription il suffit de prouver que nous possédons des droits exclusifs sur les

adresses IP utilisées par le service.

Une fois que cela est fait, Microsoft nous envoie un courriel permettant de finaliser

l’inscription avec la signature d’un contrat numérique.



Enfin, pour finir, un mail de confirmation est envoyé pour nous informer que nous

allons désormais recevoir les rapports d’abus générés par les utilisateurs de Windows

Live Messenger.

Le processus d’inscription est assez long du fait des temps d’attente qui peuvent aller

jusqu’à une semaine entre chaque étape.

J’ai pu terminer cette inscription peu de temps avant la finalisation du mémoire.

Il reste deux autres programmes auxquels on souhaite inscrire HPJCC.

Le service de Feedback loop d’AOL (AOL) permet comme pour le service de Windows

Live Messenger de recevoir une copie de chaque plainte générée lorsqu’un utilisateur

des services de messagerie d’AOL reporte comme spam un des courriels envoyés par

votre système de marketing par courriel.

Le processus d’inscription ressemble à celui du programme JMR Partner de Microsoft.

La première chose demandée pour s’inscrire est une adresse courriel qui recevra les

plaintes. AOL va vérifier que nous possédons le courriel fourni via un lien de

confirmation présent dans le mail envoyé à cette adresse.

La deuxième étape consiste en la vérification de la propriété de l’adresse IP.

Une fois cette étape validée, l’adresse IP sera ajouté à la feedback loop d’AOL.

Le dernier programme est celui proposé par Yahoo! : Yahoo! Complaint Feedback Loop

(Yahoo!).

Pour pouvoir s’inscrire à leur service, il faut absolument le faire à partir d’une adresse

Yahoo et avoir les informations de l’authentification DKIM de votre système de

marketing par courriel.

SURVEILLANCE DES LISTES NOIRES

Il existe plusieurs outils qui peuvent aider à découvrir si le système est présent dans

une ou plusieurs listes noires.

Cependant, il n’existe pas un outil qui couvre toutes les listes noires (Annexe – Listes

noires majeures et mineures) et tous ne sont pas en temps réel alors que c’est une

option nécessaire pour un bon monitoring.

De plus, certaines entreprises utilisent leur propre liste noire.

Par contre, il a été déterminé qu’il est important de rester à l’écart de certaines listes

noires qui sont largement utilisées :

Spamhaus,



SpamCop,

UCEPROTECT,

Barracuda,

Lashback,

SURBL,

URIBL.

Il faut garder à l’esprit que ce n’est pas seulement l’adresse IP qui risque d’avoir des

problèmes en cas de présence sur une de ses listes mais aussi le nom de domaine

émetteur.

J’utilise donc les outils suivants pour régulièrement vérifier que le serveur n’est pas

présent sur des listes noires :

Spamhaus Lookup : http://www.spamhaus.org/lookup.lasso,

SpamCop Blocking List : http://www.spamcop.net/bl.shtml,

SenderBase Lookup :

http://www.senderbase.org/senderbase_queries/detail_lookup,

URIBL Lookup : http://lookup.uribl.com/

Pour le moment j’effectue ces vérifications manuellement toutes les semaines mais le

développement d’un outil automatisé permettant d’effectuer ces vérifications est en

cours d’analyse afin de m’aider dans le monitoring du serveur.

FILTRE ANTI‐SPAM

Dans cette section, je vais vous montrer comment les filtres anti‐spam fonctionnent et

comment ils « pensent ».

Je vais également fournir quelques conseils pour savoir si les courriels envoyés sont

filtrés par l'anti‐spam.

Pour finir, je parlerais des moyens possibles pour vérifier si vos courriels pourraient

passer les filtres anti‐spam.

Les filtres anti‐spam sont désormais utilisés par tous les FAI. Si ce n’est pas Spam

Assassin qui est utilisé, c’est une autre solution commerciale qui sera en place. Dans

de nombreux cas, ces filtres arrêtent la majorité des spam mais par forcément tous.

Cependant, ils sont de plus en plus agressifs.

En effet, en moyenne entre 10 et 20 % des courriels valides envoyés se perdent du fait

de filtres anti‐spam un peu trop sévère. Il n’est pas nécessaire d’être un spammeur

pour être bloqué par un anti‐spam.



Il n’existe malheureusement pas de solution miracle et la seule solution pour éviter les

filtres anti‐spam est de comprendre comment ils fonctionnent.

De manière générale, les filtres se basent sur une liste préétablie de critères

permettant de juger si oui ou non le courriel est indésirable. À chaque critère est

attribué un certain nombre de points.

Si le total de points du courriel dépasse un certain seuil, alors votre courriel peut soit

être marqué comme spam, soit être déplacé dans le dossier courrier indésirable, soit

être bloqué. Le problème est que le seuil est déterminé lors de l’installation du filtre

anti‐spam et peut être modifié en fonction de la boite courriel.

La liste des critères est sans cesse en croissance que les filtres anti‐spam apprennent

en fonction des courriels qu’ils reçoivent et des actions prises par les utilisateurs. Ainsi,

si vous déplacer un courriel vers le dossier de courrier indésirable, le système anti‐

spam va scanner le courriel pour que les prochains courriels du même type soient

bloqués.

En plus de cet apprentissage constant, les filtres partage entre eux ce qu’ils ont appris.

Les FAI utilisent différents systèmes ou solutions anti‐spam. Il est bon de connaître

quels sont les produits qui sont utilisés pour déterminer leur fonctionnement.

Yahoo utilise un spam filtre breveté appelé SpamGuard, MSN et Live utilise BrightMail,

Gmail utilise Postini, AOL utilise les plaintes de ses utilisateurs pour filtrer les courriels.

D’autres filtres sont couramment utilisés au niveau des entreprises : MessageLabs,

Barracuda, Forefront et Cloudmark.

Mais comment savoir si les courriels envoyés par le système de marketing par courriel

sont bloqués par un anti‐spam ?

Pour commencer, il faut vérifier le taux d’ouverture de la newsletter car si ce taux

chute brutalement par rapport à un envoi précédent c’est qu’il y a possiblement un

problème de filtre anti‐spam.

Un taux de rebond anormalement élevé est un autre indicateur. Il faut vérifier les

réponses SMTP car parfois les filtres anti‐spam indiquent dans le message de retour

que le courriel a été bloqué parce qu’il est considéré comme du spam.

Enfin, les Feedback loop sont le moyen le plus sûr de savoir si votre système rencontre

un problème avec un anti‐spam.



Le meilleur moyen de savoir si vos courriels peuvent passer les configurations de bases

des filtres anti‐spam est de directement testé sur la solution en question.

Ainsi il est assez aisé de mettre en place et configurer un Spam Assassin et de tester

son propre contenu à travers avant d’effectuer un envoi.

Sinon des services comme Email On Acid proposent d’analyser vos courriels afin de

déterminer s’ils passeraient ou pas les filtres anti‐spam des FAI majeurs ainsi que

d’Outlook et Spam Assassin.

PARE‐FEU POUR COURRIELS

De nos jours, les spammeurs savent qu’il ne faut pas utiliser un certain nombre de

phrases comme « GRATUIT! CLIQUER MAINTENANT! » car sinon le filtre anti‐spam

bloquera le courriel.

Mais une couche supplémentaire s’est ajoutée avant les filtres anti‐spam : il s’agit

d’un pare‐feu spécialement conçu pour traiter les courriels.

Les anti‐spam doivent maintenant avoir leur propre anti‐spam pour les aider.

La majorité des FAI utilisent ces systèmes mais pas seulement puisque les grandes

entreprises ont largement adopté le principe et que les plus petites sociétés

commencent à s’équiper.

En communiquant entre eux, ses systèmes apprennent ce qui est spam et ce qui ne

l’est pas et par conséquent ce qui doit être bloqué.

Si le système pense que votre courriel n’est pas un spam, alors il lui permettra de

continuer son chemin vers le filtre anti‐spam.

Plus précisément, un système de pare‐feu courriel utilise des filtres de réputation pour

déterminer si le courriel qu’il a reçu est légitime ou non. Si estime que non, une

deuxième couche permet d’effectuer une analyse basée sur le contexte : qui est

l’émetteur ? Quel est le contenu ? Où vont les hyperliens ? Comment le courriel est

construit ?

Pour que ces systèmes déterminent que le courriel traité est un spam ou pas, ces pare‐

feu consulte des services comme SenderBase pour connaître votre réputation. Celle‐ci

étant affectée par les plaintes des personnes qui vous ont signalés comme spammeur à

des services comme SpamCop ou directement à SenderBase.

Ainsi, il faut apporter la plus grande attention à la réputation du serveur et pour cela :

Ne jamais envoyer de spam. Cela paraît évident mais de nombreuses personnes

ne savent pas qu’ils envoient du spam par méconnaissance de la définition de

ce mot.



Ne pas acheter de listes et ne pas utiliser des listes que d’autres vous ont

donnés.

Envoyer seulement des courriels aux personnes qui vous connaissent et qui ont

demandé des courriels de votre part. Sinon, si vous souhaitez les informer sur

votre entreprise, il faut prendre le téléphone et les appeler, prendre un stylo et

leur écrire ou leur envoyer un courriel (un par un) à partir de votre propre

client de messagerie.

Toujours indiquer pourquoi vous contacter le destinataire et comment vous

avez obtenu son adresse courriel.

Le design du courriel doit avoir l’air professionnel sinon les destinataires

n’auront pas confiance dans le lien de désabonnement, celui‐ci devant toujours

être présent.

Penser à garder un lien constant avec vos contacts afin qu’ils ne vous oublient

pas.

Surveiller votre réputation avec les différents outils mentionnés auparavant.

Aujourd’hui, Cisco est un des leaders sur le marché avec son produit IronPort en

mesurant plus de 25 % du trafic courriel mondial (Figure 12 ‐ SenderBase dans le

monde). De plus, les sociétés SpamCop et SenderBase appartiennent à Cisco d’où la

communication facilitée et le partage d’informations entre ces services.

Cependant d’autres produits existent comme :

Barracuda Networks,

Postini,

MessageLabs,

BrightMail (utilisé par 9 des 12 FAI américains).

BILAN POST‐CAMPAGNE

Une fois toutes les étapes précédentes faites, il en reste une qui est au moins aussi

importante que les autres : faire le bilan de votre campagne d’envoi.

Ce bilan peut être divisé entre trois étapes :

Évaluer les statistiques de la campagne,

Déterminer si les résultats sont normaux.

ÉVALUATION DES STATISTIQUES

Avant d’évaluer les statistiques il faut les récolter.



Pour les bounces, il n’y a pas d’autres moyens de connaître le nombre de courriel

invalide dans le référentiel qu’en mettant en place une gestion des rebonds comme

expliquée précédemment.

Une fois que le système aura récupéré les données, il va falloir vérifier le nombre de

courriel qui ont bien été livré aux contacts du référentiel. Si un nombre anormalement

élevé de courriels ont rebondis, il faut déterminer la raison de ces rebonds.

Pour cela, les en‐têtes du courriel peuvent nous aider à trouver la raison.

Lorsque vous envoyez un courriel à quelqu’un et que ce dernier rebondit, le serveur

qui transmet le rebond inclus généralement un message, dans l’entête du courriel,

appelé « réponse SMTP ».

Le système de gestion des rebonds va lire tous les courriels et récupérer toutes les

« réponses SMTP » afin de classer les courriels comme « hard » ou « soft » bounce.

Cependant, le système n’est pas parfait et certains serveurs de messagerie envoi des

réponses SMTP mal formatées ou qui n’utilisent pas les codes standards. De plus,

certaines informations présentes dans les headers peuvent être contradictoires et il

est à noter qu’il faut plutôt faire confiance au header : « Diagnostic‐Code ».

Un rebond n’est pas fiable à 100 % car la réponse dépend d’un grand nombre de

facteur comme comment le serveur de réponse est configuré. Ainsi, un serveur mal

configuré pourrait retourner un code d’erreur de type hard alors qu’il s’agit

simplement d’une boite courriel pleine.

Dans la majorité des cas, la différenciation du type de bounce est précise et correcte

mais rien n’est absolument sûr et il est important de garder une trace de tous les

rebonds que le système de marketing par courriel à rencontrer.

Aussi, un système de détection des faux positifs doit être mis en place afin de ne pas

supprimer un courriel qui a rebondi mais qui est tout à fait valider au final.

Par contre, cette mesure permet souvent de détecter un problème lié à des filtres

anti‐spam refusant les courriels envoyés.

Le taux de clics sur les liens contenus dans les newsletters permet de connaître si

votre communication marketing a intéressé vos contacts ou non.

Pour récolter ces données, le système d’envoi doit transformer tous les liens pour que

lorsqu’un destinataire clique sur l’un de ses liens, il passe par un script comptabilisant

son clic puis qui le redirige vers le lien d’origine.

L’utilisation d’un script de tracking des liens hypertextes implique que les documents

et images doivent être uploadé vers le serveur d’envoi afin d’éviter d’avoir un lien



pointant vers le serveur d’envoie avec une image imbriquée qui a pour source un autre

domaine. Les filtres anti‐spam n’aiment pas ce mélange.

Si aucun de vos contacts ne clique sur les liens, il faut alors déterminer pourquoi. Les

raisons peuvent être multiples dépend du taux de rebonds par exemple. Mais on peut

se poser les questions suivantes : est‐ce que les liens sont assez visibles ? Est‐ce que

mes liens sont dans une image ? Les informations alternatives sont‐ elles bien

renseigner (balises alt et title) ? Les liens sont‐ils pertinents par rapport au contenu du

courriel ?

Combien de personnes se sont désinscrit suite à mon envoi ? C’est une de question

que tout responsable d’envoi doit se poser après avoir effectué sa communication

marketing.

En effet, cette mesure montre comment vos contacts ont accueillis la newsletter. Un

taux anormalement haut peut signifier que les destinataires se sont lassés de vos

communications. Pourquoi se sont‐ils lassés ? Votre contenu est‐il trop redondant ou

pas assez régulier ?

En mettant en place un calendrier des envois vous permettra d’anticiper les

prochaines communications et donc de proposer un contenu pertinent et complet. De

plus, l’étude préalable à la mise en place du calendrier vous aidera à déterminer les

pics et les creux dans votre activité.

Une des bonnes pratiques pour connaître la raison du désabonnement de vos contacts

est d’insérer un formulaire dans la page de confirmation de désinscription. En traitant

les résultats fournis par ce système vous pourrez améliorer votre prochaine campagne.

Le taux d’ouverture est une indication importante de la réussite d’une campagne ou

non. Pour récolter cette donnée, le système intègre une image d’un pixel sur un pixel

dans un coin de du courriel qui appel un script du serveur d’envoi. Ce script sert à

comptabiliser qui a ouvert quelle campagne.

Il existe un certains nombres de trucs pour améliorer le taux d’ouverture de vos

courriels.

Le taux moyen d’ouverture se situe autour de 20 et 30 pourcent mais dépend

énormément de la liste d’envoi, du contenu et de la fréquence d’envoi.

Un sujet inefficace peut être à l’origine d’un faible taux d’ouverture. Le sujet est l’un

des éléments les plus importants dans une campagne marketing par courriel. Il faut

que celui‐ci soit à la fois pertinent et convaincant pour tous les destinataires. Un



temps significatif doit être accordés à la rédaction du sujet car les destinataires

reçoivent une multitude de courriels par jour et pourquoi devraient‐ils ouvrir le vôtre

plus qu’un autre ?

Votre sujet doit rester simple et identifier clairement l’émetteur du courriel. Il doit

également décrire le contenu et non le vendre. Les meilleurs sujets sont ceux qui

disent ce qu’il y a dans le courriel, les pires étant ceux qui vendent leur contenu.

Un mauvais timing pourrait faire en sorte que votre courriel se retrouver noyer dans le

trafic matinal. Aussi, il paraitrait logique que la promotion d’un évènement de fin de

semaine obtiendrait de meilleurs résultats avec un envoi le jeudi par rapport au lundi.

Le blocage des images par les clients de messagerie biaise le taux d’ouverture des

campagnes. Il se peut très bien que vos destinataires ouvrent vos courriels mais que

les images soient bloquées afin de protéger leur vie privée. Si le taux de clics est très

important alors que le taux d’ouverture est faible, vous pourrez en conclure que vos

destinataires ont les images bloquées par défaut. Il est donc important de ne pas

utiliser une seule image pour vos campagnes. Un courriel doit rester compréhensible

et lisible avec les images et le CSS désactivés.

Il est possible qu’une trop haute fréquence d’envoi puisse fatiguer vos contacts. En

diminuant le nombre d’envoi ou en proposant différentes fréquences, vous pourrez

régler ce problème.

En utilisant des listes de mauvaise qualité ou vieille, vous pourrez vous retrouver avec

un faible taux d’ouverture puisqu’un grand nombre d’adresses courriels présentes sur

la liste ne sont certainement plus valides.

Un dernier point à vérifier est de voir si vos destinataires continuent d’ouvrir et de

cliquer ou si l’activité autour de l’envoi s’est complètement arrêtée. Ces données

pourront vous aider à déterminer les habitudes de vos destinataires et ainsi vous aider

à établir votre calendrier d’envoi.

RÉSULTATS NORMAUX ?

Une fois toutes ses données récoltées et évaluées, il est nécessaire de vérifier si ces

résultats sont normaux.



Pour cela, une des choses à faire est de comparer avec les envois précédents. Si les

résultats sont semblables cela signifie qu’il n’y a pas eu de problèmes durant l’envoi

de la campagne.

MailChimp a effectué une étude des campagnes qui ont été envoyé via leur système

(Figure 13 ‐ Étude de MailChimp sur les taux d'ouverture, de clic, de rebond, de plainte

et de désinscription par industrie). Ils ont ainsi scanné plus de 570 millions de courriels

et ont calculé les moyennes de taux d’ouverture, de clics uniques, de soft bounce, de

hard bounce et de plaintes par industrie.

Toute industrie confondue, le taux d’ouverture moyen est de 19,40 %, le taux de clics

est de 3,74 %, le taux de soft bounce est de 1,58 %, celui du hard bounce est de 2,18 %.

Le taux de plaintes est de 0,07 % et celui de désinscription est de 0,27 %.

BILAN DE LA PHASE DE MISE EN ŒUVRE

Au jour d’aujourd’hui, la mise en place de la gestion du spam dans le système de

marketing par courriel HPJCC est bien avancé.

La gestion des bounces a été mise en place, l’authentification des courriels est en

cours ainsi que l’inscription dans les listes blanches et dans les Feedback Loop des

principaux FAI proposant ce type de service.

La mise en place d’outils de monitoring centralisé reste encore à développer.

Cependant il reste encore des challenges importants avant que la gestion du spam

dans HPJCC soit entièrement complétée.

En effet, la mise en place d’un système de double opt‐in efficace et obligatoire va

nécessiter de nombreux changements dans l’application mais également dans la

mentalité des personnes.

De plus, je n’ai pas réussi à savoir si les opérateurs locaux comme Vidéotron ou Bell

fournissent un programme de Feedback Loop ou de Whitelising. Leurs services restant

muet à mes demandes.

Enfin, lorsque le volume d’envoi sera suffisant, il va falloir se pencher sur l’utilisation

d’un pool IP au lieu d’une seule partagée entre tous les clients.

Un de mes plus grands challenges au cours des derniers mois mais qui est maintenant

l’un de mes fiertés s’est révélé être de faire comprendre ce qu’est réellement un spam

et ce qu’on doit faire pour être phase avec la loi mais aussi avec les règles tacites

émises par les FAI.



En effet, rien n’oblige les fournisseurs de services de marketing par courriels

d’authentifier leur courriel avec DKIM, SPF ou SenderID.

Mais étant donné que pour avoir accès aux boites de réception de leurs clients il est

fortement conseillé d’implémenter une voir plusieurs de ces techniques, les systèmes

d’envois se doivent de les implémenter.

On a estimé que les étapes restantes prendront encore environ six mois pour être

complétées sans comptées les développements envisagées comme l’outil de

vérification du rendu des campagnes dans les différents services de messagerie et de

test anti‐spam.


Michaël Massé | Bilan 63

BILAN

Ce stage de fin d’étude au sein d’HPJ Solutions s’est révélé extrêmement enrichissant

et positif sur le plan humain, professionnel et social.

Au cours de ses six derniers mois, j’ai énormément appris et j’estime que cette

expérience ne sera que bénéfique pour la suite de ma carrière.

Ce stage a été bénéfique sur différents points de vue :

D’UN POINT DE VUE ORGANISATIONNEL

Je me suis rendu compte que je pouvais respecter une certaine rigueur afin de

développer les améliorations du système d’envois tout en respectant les échéanciers

décidés en parallèle des contrats remportés par l’entreprise où j’ai été impliqué.

De plus, en travaillant de façon autonome, j’ai réussi à m’organiser pour rechercher les

informations dont j’avais besoin pour gérer mon temps de travail.

Au final, j’ai pu améliorer mes compétences organisationnelles grâce à l’infrastructure

de gestion de projet déjà en place depuis longtemps au sein d’HPJ Solutions : système

de time‐tracking, gestionnaire de projet et wiki.

D’UN POINT DE VUE INFORMATIQUE

Le fait d’avoir travaillé dans cette entreprise m’a sensibilisé aux problèmes et aux

contraintes liées au développement d’application web. En effet, les exigences du client

ou des chefs de projets sont parfois en contradiction avec mes méthodes de travail,

pourtant il faut s’adapter afin qu’ils soient satisfaits.

De plus, l’immersion dans cette société m’a permis d’avoir une vision du monde

informatique différente de celle rencontrée au cours de mes études.

En effet, je me suis vite rendu compte que les impératifs économiques et de

rentabilités rentrent grandement en compte lors du choix de solutions ou de la mise

en place de fonctionnalités.

En cours, nous apprenons à bien développer mais en nous laissant généralement une

grande latitude alors qu’en entreprise on doit le faire vite et bien.

Plus techniquement, ce stage m’a apporté un très grand nombre de connaissances et

m’a permis de mettre en application la majorité des savoirs que j’ai pu acquérir au



cours de ma formation du fait qu’il m’a été demandé d’aussi bien faire de

l’administration réseau à la programmation Web avec PHP, Java ou encore .Net en

passant par du support client et de la gestion de projets.

Ce stage m’a également permis de me former dans le développement autour du CMS

Joomla qui est largement utilisé par HPJ Solutions.

D’un point de vue informatique, ce stage ne peut être que positif vu que j’ai pu

développer toutes les facettes d’un ingénieur en informatique : administration réseau,

développement, gestion de projets et d’équipes et support clients.

D’UN POINT DE VUE PERSONNEL

Ma capacité de communication s’est vue améliorée grâce à ce stage car il a fallu

trouver les mots justes pour expliquer un problème pouvant se révéler complexe ainsi

que ses éventuelles solutions et malgré le fait qu’en face de moi je n’avais pas

forcément une personne qui possède des aptitudes informatiques.

De plus, j’ai dû m’adapter à chaque situation afin de pouvoir satisfaire les demandes

exigées par l’entreprise ou par les clients. En effet, les demandes émises rentrent

parfois en contradiction avec ce qui devrait idéalement être fait. Mais, il a fallu que

j’apprenne à intégrer les dimensions économiques d’un projet, chose que je n’avais

pas forcement toujours fait jusque‐là.

Enfin, le contact régulier avec le client m’a permis de combattre un trait de ma

personnalité, la timidité, qui n’est pas forcément compatible avec le cheminement de

carrière que je souhaite avoir. J’ai pu me rendre compte au fil des mois que je suis de

plus en plus à l’aise au téléphone avec une personne.

D’UN POINT DE VUE SOCIAL

J’ai pu découvrir la vie sociale d’une entreprise nord‐américaine de taille moyenne

ainsi que son environnement.

Ces derniers mois m’ont permis de prendre conscience que tout va plus vite dans le

marché du travail nord‐américain.

Dans notre secteur, autant il est assez simple et rapide de trouver un emploi, autant il

est tout aussi rapide de le perdre.



J’ai connu cette situation de licenciement et ce ne fut pas une expérience très

agréable mais qui au final s’est révélée très formatrice et bénéfique.

J’ai donc pu me rendre compte de la polyvalence qu’un ingénieur en

informatique doit posséder afin d’effectuer correctement son

travail.


Michaël Massé | Conclusion 66

CONCLUSION

Pour conclure, j’aimerais faire un point sur l’objectif premier du stage et sur les

difficultés rencontrées au cours de celui‐ci.

En arrivant à HPJ Solutions, il m’a été confié la tâche de finir la mise en place de la

gestion du spam dans le système de marketing par courriel HPJCC. Je devais également

m’occuper des différents serveurs de la société. Enfin, les développements spéciaux,

c’est‐à‐dire non Joomla, m’ont été confié.

Tout en ayant des journées plutôt occupées et avec des impératifs de productivité

assez élevés, j’ai pu amener à bien la majorité de la gestion du spam dans HPJCC étant

donné que pratiquement l’ensemble des tâches présentent dans ma check‐list ont été

effectué.

La principale tâche restante à l’heure d’aujourd’hui serait de mettre en place un

système de double opt‐in pour l’ajout de contact dans le référentiel.

Par contre, ce stage m’a permis de grandement améliorer mes compétences

d’administration réseau du fait qu’il a bien fallu que je trouve des solutions lorsque

l’un problème survenait sur l’un des serveurs ou poste de l’entreprise.

Au niveau des difficultés rencontrées, j’ai pratiquement pu surmonter toutes les

surmontées grâce à la formation que j’ai pu recevoir au cours de ma scolarité. Les

difficultés étaient de l’ordre de l’organisation au début du stage car même si je savais

que j’avais les capacités pour gérer plusieurs tâches à la fois, j’ai mis plus de temps

que je ne l’aurais pensé à me mettre dans le rythme de l’entreprise.

Enfin, au niveau de l’administration réseau, je me suis rapidement rendu compte que

la réalité de l’entreprise et assez éloigné de ce qu’on nous apprend en cours. En effet,

la majorité des connaissances qui m’était nécessaire pour m’occuper des serveurs de

l’entreprise ont été acquises au cours de stage par moi‐même ou grâce à Étienne Borel.

Pour finir, j’aimerais rajouter que je continuerais à travailler à HPJ Solutions. Nous

sommes en train d’effectuer les démarches pour que je puisse obtenir un permis de

travail d’une durée de deux ans.


Michaël Massé | Bibliographie 67

BIBLIOGRAPHIE

AOL. (s.d.). Feedback Loop Information. Consulté le Septembre 15, 2010, sur AOL

Postmaster: http://postmaster.aol.com/Postmaster.FeedbackLoop.php

Baer, J. (2006, Septembre 03). List‐Unsubscribe: What is it? Consulté le Octobre 14,

2010, sur List‐Unsubscribe, a simple plan for trusted unsubscribe:

http://www.list‐unsubscribe.com/2006/09/what_is_it.html

Bezier, M.‐C. (2008, Mars 10). Quand envoyer une campagne de marketing par courriel ?

Consulté le Octobe 19, 2010, sur Blogue de Axial Développement:

http://www.axialdev.com/blogue/2008/03/quand‐envoyer‐une‐campagne‐de‐

marketing‐par‐courriel/

ClickZ. (2006, Septembre 7). Getting in the Feedback Loop. Consulté le Octobre 15,

2010, sur ClickZ ‐ Marketing News & Expert Advice:

http://www.clickz.com/clickz/column/1690910/getting‐feedback‐loop

Commtouch. (2010, Septembre 23). Q1 2010 Internet Threats Trend Report. Consulté le

Septembre 30, 2010, sur Commtouch ‐ Messaging and Web Security Technology:

http://www.commtouch.com/download/1679

ICF International & McAfee. (Avril 2009). The Carbon Footprint of Email Spam Report.

Jennings, R. (2009, Janvier 28). Cost of Spam is Flattening. Consulté le Août 2010, sur

Ferris Research: http://www.ferris.com/2009/01/28/cost‐of‐spam‐is‐flattening‐

our‐2009‐predictions/

Microsoft Corporation. (s.d.). E‐mail Support. Consulté le Septembre 05, 2010, sur

MSN Support:

https://support.msn.com/eform.aspx?productKey=edfsjmrpp&page=support_h

ome_options_form_byemail&ct=eformts&scrx=1&st=1&wfxredirect=1

Ministère de l'Industrie du Canada. (2010, Mai 25). C‐28. Consulté le Octobre 28, 2010,

sur Parliament of Canada Web Site:

http://www2.parl.gc.ca/HousePublications/Publication.aspx?DocId=4547728&L

anguage=e&Mode=1

Return Path. (2008). Your reputation holds the key to deliverability. Consulté le

Octobre 20, 2010, sur Return Path:

http://www.returnpath.net/downloads/resources/deliverability_081508.pdf


Michaël Massé | Bibliographie 68

Return Path. (s.d.). Return Path Certification Footprint : VIP Access to 1.8 billion

Inboxes. Consulté le Octobre 23, 2010, sur Return Path:

http://www.returnpath.net/commercialsender/certification/footprint/

The Spamhaus Project Ltd. (s.d.). The Definition of Spam. Consulté le Aout 2010, sur

The Spamhaus Project: http://www.spamhaus.org/definition.html

Word To Wise. (2010, March 1). ISP Summary Information. Consulté le Octobre 24,

2010, sur Word To Wise Wiki:

http://wiki.wordtothewise.com/ISP_Summary_Information

Yahoo! Inc. (s.d.). Yahoo! Mail ‐ Filtre Anti‐spam ‐ DomainKeys. Consulté le Octobre 25,

2010, sur Yahoo! Centre Anti‐Spams:

http://fr.docs.yahoo.com/mail/spamguard_domainkeys.html

Yahoo! (s.d.). Yahoo! Complaint Feedback Loop. Consulté le Septembre 15, 2010, sur

Yahoo!: http://feedbackloop.yahoo.net


Michaël Massé | Illustrations 69

ILLUSTRATIONS

FIGURE 1 ‐ SENDER SCORE POUR HPJCC LE 19 OCTOBRE 2010 70

FIGURE 2 ‐ RAPPORT TRUSTEDSOURCE POUR HPJCC 71

FIGURE 3 ‐ NIVEAU DE CONFIANCE CHEZ DNSWL.ORG 72

FIGURE 4 ‐ MÉTHODES D'AUTHENTIFICATION CHEZ LES PRINCIPAUX ISP 72

FIGURE 5 ‐ FONCTIONNEMENT DU SPF 73

FIGURE 6 ‐ DIFFÉRENCE ENTRE UN COURRIEL AUTHENTIFIÉ OU PAS DANS YAHOO! MAIL

73

FIGURE 7 ‐ FONCTIONNEMENT DE DKIM 74

FIGURE 8 ‐ RÉSULTATS DE VERIFIER.PORT25 74

FIGURE 9 ‐ LOCALISATION D'HPJ SOLUTIONS 75

FIGURE 10 ‐ IVANHOÉ CAMBRIDGE 75

FIGURE 11 ‐ AEM / MEA 76

FIGURE 12 ‐ SENDERBASE DANS LE MONDE 76

FIGURE 13 ‐ ÉTUDE DE MAILCHIMP SUR LES TAUX D'OUVERTURE, DE CLIC, DE REBOND,

DE PLAINTE ET DE DÉSINSCRIPTION PAR INDUSTRIE 77



FIGURE 1 ‐ SENDER SCORE POUR HPJCC LE 19 OCTOBRE 2010



FIGURE 2 ‐ RAPPORT TRUSTEDSOURCE POUR HPJCC



FIGURE 3 ‐ NIVEAU DE CONFIANCE CHEZ DNSWL.ORG

FIGURE 4 ‐ MÉTHODES D'AUTHENTIFICATION CHEZ LES PRINCIPAUX ISP



FIGURE 5 ‐ FONCTIONNEMENT DU SPF

FIGURE 6 ‐ DIFFÉRENCE ENTRE UN COURRIEL AUTHENTIFIÉ OU PAS DANS YAHOO! MAIL



FIGURE 7 ‐ FONCTIONNEMENT DE DKIM

FIGURE 8 ‐ RÉSULTATS DE VERIFIER.PORT25



FIGURE 9 ‐ LOCALISATION D'HPJ SOLUTIONS

FIGURE 10 ‐ IVANHOÉ CAMBRIDGE



FIGURE 11 ‐ AEM / MEA

FIGURE 12 ‐ SENDERBASE DANS LE MONDE



FIGURE 13 ‐ ÉTUDE DE MAILCHIMP SUR LES TAUX D'OUVERTURE, DE CLIC, DE REBOND, DE PLAINTE ET DE

DÉSINSCRIPTION PAR INDUSTRIE


Michaël Massé | Annexes 78

ANNEXES

LISTES NOIRES MAJEURES ET MINEURES

AHBL, ANT, Backscatter.org, BARRACUDA, BURNT-TECH, CASA-CBL, CASACBL+, CASA-CDL, CBL, CYBERLOGIC, DEADBEEF, DNSBLINFO, DULRU, EMAILBASURA, FABELSOURCES, FIVETEN, GIRL, GRIP, HIL, HILLI, ICMFORBIDDEN, IMP-SPAM, IMP-WORM, INTERSIL, ivmSIP, ivmSIP/24, KEMPTBL, KUNDENSERVER, LASHBACK, LNSGBLOCK, LNSGBULK, LNSGDUL, LNSGMULTI,

LNSGOR, LNSGSRC, MSRBL-Combined, MSRBL-Images, MSRBLPhising, MSRBL-Spam, MSRBL-Viruses, NERD, NETHERRELAYS, NETHERUNSURE, NIXSPAM, NJABL, NJABLDUL, NJABLFORMMAIL, NJABLMULTI, NJABLPROXIES, NJABLSOURCES, NLKUNBLACKLIST, NLKUNWHITELIST, NOFALSEPOSITIVE, NOMOREFUNN, ORID, OSPAM, PDL, PSBL, RANGERSBL, RATS-Dyna, RATS-NoPtr, RATS-Spam, REDHAWK, RRBL, SCHULTE, SDERB,

SENDERBASE, SERVICESNET, SOLID, SORBS-BLOCK, SORBS-DUHL, SORBSHTTP, SORBS-MISC, SORBS-SMTP, SORBS-SOCKS, SORBS-SPAM, SORBS-WEB, SORBS-ZOMBIE, SPAMCANNIBAL, SPAMCOP, Spamhaus-ZEN, SPAMSOURCES, SPEWS1, SPEWS2, SWINOG, TECHNOVISION, TRIUMF, UCEPROTECTL1, UCEPROTECTL2, UCEPROTECTL3, VIRBL, WPBL, WSFF, ZONEEDIT, CSMA, DUINV, ORVEDB, RSBL, SPAMRBL.

Mémoire de fin d'études - Supinfo 2010 - La gestion du spam dans un système de marketing par...

Technology

Transcript of Mémoire de fin d'études - Supinfo 2010 - La gestion du spam dans un système de marketing par...