Technique Archives - DeliverNow

Gmail fait un pas de plus vers la généralisation de TLS

Gmail a toujours été à la pointe sur les questions d’authentification (SPF, DKIM, DMARC) et de cryptographie. Depuis la mise en place de Google Postmaster (lire notre article sur le sujet), il est par exemple possible de suivre le pourcentage d’email entrant et sortant de chez Gmail utilisant ou non TLS.

L’annonce qui a été faite par Google la semaine dernière concerne directement TLS. Pour rappel, TLS (Transport Layer Security) est le successeur de SSL (Secure Sockets Layer) et permet de garantir l’authenticité, la confidentialité et l’intégrité des données échangées sur les réseaux. Pour autant que deux serveurs emails puissent se parler dans ce langage, il est d’ailleurs possible d’utiliser cette technologie pour sécuriser les échanges d’email.

Des repères visuels pour les utilisateurs

Si Gmail supporte TLS depuis plusieurs années, la grande nouveauté vient du fait que la firme de Mountain View met maintenant en avant l’absence de cette technologie. En effet, lorsqu’un email arrive dans le webmail de Google sans avoir été chiffré par TLS, celui-ci présente un cadenas rouge à l’utilisateur.

cadenas

De la même manière, si un utilisateur est en train d’envoyer un email à un domaine ne supportant pas TLS, il sera averti par ce même cadenas rouge.

La volonté de booster l’utilisation du chiffrement TLS

En agissant de la sorte, Google veut clairement booster l’adoption de TLS pour l’ensemble des emails échangés. L’indication visuelle devrait inciter les annonceurs qui ne chiffrent pas encore leurs emails en sortie à le faire, par crainte d’une baisse de confiance de la part de leurs clients et prospects.

Continuer à mettre en avant l’authentification SPF et DKIM

L’autre changement mis en avant par Gmail est la modification de l’icône expéditeur lorsqu’il y a un problème avec l’authentification des emails (SPF et DKIM). Par contre, vu la sévérité de Gmail concernant les soucis d’authentification, nous risquons de rencontrer assez rarement cette icône en point d’interrogation, les emails mal authentifiés finissant rapidement en boîte spam.

auth

DeliverNow est en train de migrer tous ses clients vers TLS

Chez DeliverNow, nous avons pris acte de ces changements depuis plusieurs semaines et sommes en train de migrer nos clients PowerMTA afin que l’ensemble de leurs emails soient compatibles avec TLS. N’hésitez pas à nous contacter si vous désirez être accompagné sur le sujet.

DMARC, trois ans et demi plus tard, où en sommes-nous ?

DMARC-2015-logo-small-202x110Cela fera bientôt quatre ans que les spécifications de DMARC ont été dévoilée et que nous publions notre premier article sur le sujet. Pour rappel, DMARC est un système de validation destiné à lutter contre le Spoofing. Basé sur les technologies SPF et DKIM, il permet aux émetteurs d’emails de déclarer au serveurs de réception ce qu’il faut faire en cas de non-conformité de l’authentification. DMARC permet en outre à l’émetteur d’origine d’être tenu au courant de tout échec des mécanismes d’authentification SPF et DKIM.

Si vous désirez en savoir plus sur le fonctionnement de DMARC, n’hésitez pas à lire notre article de 2012 qui vous expliquera tous les détails techniques sur le sujet.

Utilisation de DMARC par les FAI

Avant de nous focaliser sur les pratiques des annonceurs, il est intéressant de nous pencher sur les pratiques des FAI et des Webmails. Chez ces acteurs, nous pouvons séparer deux problématiques très différentes.

D’une part, il y a l’utilisation de DMARC pour les emails en sorties des FAI et des Webmails. En avril 2014, en changeant sa politique DMARC pour la passer en policy « Reject » (p=reject), Yahoo! Décidait qu’il n’était plus possible d’émettre des emails ayant une adresse @yahoo.com depuis un serveur SMTP non autorisé.

Cette décision a fait couler beaucoup d’encre dans la mesure où de nombreux utilisateurs d’adresses Yahoo! expédiaient leurs emails depuis un client email comme Outlook ou Thunderbird en utilisant le relais SMTP de leur fournisseur d’accès internet. De la même manière de nombreuses newsletters envoyées par des petits annonceurs depuis une plateforme de routage de pouvaient plus utiliser une adresse @yahoo.com.

Quelques jours plus tard, c’était AOL qui s’y mettait et d’autres ont suivi.

Si nous faisons une petite analyse des domaines grand public les plus rencontrés en France, voici les conclusions que l’on pourrait en tirer :

  • Gmail.com – v=DMARC1; p=none; rua=mailto:mailauth-reports@google.com – Pas de rejet, seulement de l’écoute des erreurs.
  • Hotmail.com – v=DMARC1; p=none; pct=100; rua=mailto:d@rua.agari.com; ruf=mailto:d@ruf.agari.com; fo=1 – Pas de rejet, seulement de l’écoute des erreurs.
  • Orange.fr – Aucun enregistrement DMARC
  • Sfr.fr – Aucun enregistrement DMARC
  • Free.fr – Aucun enregistrement DMARC
  • LaPoste.net – v=DMARC1; p=quarantine; rua=mailto:dmarc.agg@laposte.net,mailto:dmarc_agg@auth.returnpath.net; ruf=mailto:dmarc.afrf@laposte.net,mailto:dmarc_afrf@auth.returnpath.net; rf=afrf; – Mise en quarantaine des erreurs et écoute de celles-ci.

On le voit, en France, sur les emails sortants, c’est Laposte.net qui est le plus en avance puisqu’il demande aux serveurs recevant des emails dont DKIM et SPF ne sont pas validés de les mettre en quarantaine. Nous sommes toutes fois encore loin de la demande de rejet de Yahoo! et AOL.

L’envers du décor (qui est plus difficile à mesurer), c’est la gestion de DMARC en entrée. S’il est évident que le domaine paypal.com aura une policy « reject », encore fait-il que les webmails et les FAI recevant des emails frauduleux analysent correctement les instructions données par Paypal et rejettent les emails.

Voici ce que l’on sait des différents opérateurs cités :

  • Gmail : Les emails sont correctement filtrés sur base des déclarations DMARC
  • Hotmail/Outlook.com : Les emails sont correctement filtrés sur base des déclarations DMARC
  • Orange : Aucune action
  • SFR : Aucune action
  • Free : Aucune action
  • LaPoste.net : Aucune action

Le bilan est donc très mitigé et sur le marché français, on ne peut pas dire que les différents fournisseurs de messageries grand public soient en avance. A part quelques expérimentation chez LaPoste.net, il y a encore un travail majeur à fournir.

DMARC s’est-il imposé chez les annonceurs ?

Parmi les entreprises à la base de DMARC, on retrouve des sociétés comme Bank of America, JPMorganChase, PayPal et encore LinkedIn ou Facebook. En tant que victimes classiques de tentatives de Spoofing et de Phishing, il est normal que l’on retrouve dans cette liste les plus grands noms de la finance et les réseaux sociaux majeurs.

Mais qu’en est-il en France ? Est-ce que nos institutions publiques (qui n’a jamais reçu d’email de la CAF ou des impôts vous promettant un remboursement) ont passé le cap ? Est-ce que les grandes banques françaises ont pris la mesure de ce risque ?

Pour en avoir une petite idée, voici quelques acteurs que nous avons analysé :

  • Crédit Agricole – Aucun enregistrement DMARC
  • Ameli.fr – Aucun enregistrement DMARC
  • CAF.fr – Aucun enregistrement DMARC
  • Impots.gouv.fr – Aucun enregistrement DMARC (pas d’enregistrement non plus pour gouv.fr)
  • Caisse-epargne.fr : Aucun enregistrement DMARC
  • Societegenerale.fr – Possède un enregistrement DMARC en policy « none ».
  • bnpparibas.com – Aucun enregistrement DMARC

Nous avons analysé un grand nombre de domaines, mais malheureusement, dans le secteur publique ou dans la banque-assurance, très peu de domaines sont protégés. Cela pose un constant interpellant, est-ce que ces acteurs, cibles privilégiées des attaques de phishing, ont bien pris la mesure du problème ? D’autre part, les FAI constituent eux-même des annonceurs à haut risque concernant ces attaques de phishing, et de leur côté, pas grand chose n’a été mis en place concernant DMARC.

Pourtant, DMARC n’est pas si compliqué à mettre en place. Si l’utilisation d’une policy en mode « reject » ou « quarantine » peut faire peur, il n’est pas indispensable de l’adopter dans un premier temps. La plupart des entreprises intègrent d’abord une policy « none » afin de mettre en place le monitoring des alertes et c’est seulement après analyse durant plusieurs semaines qu’ils décident de la bonne policy à mettre en place.

DeliverNow, a intégré DMARC dans sa suite de monitoring email. De cette manière, les rapports d’erreur envoyés par les fournisseurs sont analysés et disponibles dans nos tableaux de bord délivrabilité. Par ce biais, nous recevons des informations relatives aux adresses IP non-autorisées à émettre des emails pour les noms de domaine de nos clients. Nous pouvons aussi de cette manière détecter d’éventuels problèmes d’authentification sur des emails légitimes. Un système d’alertes permet d’être averti en temps réel de tout problème significatif.

Quelques informations de dernière minute concernant DMARC

À l’occasion du 35ème General Meeting du M³AAWG, nous avons reçu quelques informations concernant des changements DMARC chez certains opérateurs :

  • Début novembre, Yahoo! va étendre sa policy « reject » aux domaines ymail.com et rocketmail.com avant d’autres domaines dans les prochains mois.
  • Google a annoncé qui allait lui aussi bouger et devenir plus stricte afin de protéger ses noms domaines. Gmail.com devrait passer en policy « reject » à partir de juin 2016.

Exemple de rapport DMARC dans la suite de monitoring délivrabilité de DeliverNow :

dms-dmarc

Délivrabilité SFR : explications sur les codes d’erreur (GU_EIB) et sur les seuils utilisés

logo_SFRAvant d’entrer dans le vif du sujet, il est important de rappeler quelque faits historiques à propos de SFR. Si SFR s’est toujours appelé comme ça depuis sa création en 1987, les différentes activités du groupe ont, par contre, pris différents noms au cours de l’histoire. Ces dix dernières années, SFR a aussi fait l’acquisition d’autres fournisseurs d’accès internet (ou réintégré des filiales), ce fut le cas de Neuf Telecom, de Club Internet, …

C’est important à savoir car cela va vous permettre de regrouper tous les noms de domaine qui utilisent l’infrastructure de SFR pour leurs emails. Certains sont bien connus, d’autres moins.

Voici la liste des noms de domaine utilisant le service email de SFR (et donc aussi les mêmes technologies de filtrage) :

  • @sfr.fr
  • @neuf.fr
  • @9online.fr
  • @9business.fr
  • @cegetel.net
  • @club-internet.fr
  • @cario.fr
  • @guideo.fr
  • @mageos.com
  • @fnac.net
  • @waika9.com

Explications des codes d’erreur délivrabilité utilisés par SFR : GU_EIB_02 et GU_EIB_04

Notre experience, croisée avec une analyse fine des logs SMTP de routage, permettent aujourd’hui à DeliverNow d’avoir une vue plus claire sur la configuration d’un MTA afin de délivrer au mieux les emails chez SFR.

Lorsque votre adresse IP est bloquée, vous avez l’occasion de trouver la raison du blocage dans les bounces que les serveurs de SFR vont vous faire parvenir. Voici ci-dessous, les deux exemples qui nous concernent :

  • GU_EIB_02 : « 5.7.1 <example.com[xxx.xxx.xxx.xxx]>: Client host rejected: Abus detecte GU_EIB_02 »
  • GU_EIB_04 : « 5.7.1 <example.com[xxx.xxx.xxx.xxx]>: Client host rejected: Abus detecte GU_EIB_04 »

Différents indicateurs

On peut distinguer 2 grands indicateurs analysés par SFR afin de décider s’il faut ou non bloquer une adresse IP.

Le premier est le taux de spam (GU_EIB_04), si un trop grand nombre d’emails sont détectés en « spam », il est possible que vos adresses IP se retrouvent bloquées pendant un certain temps. Il est intéressant de savoir que SFR (tout comme Orange et Free) utilise les technologies de filtrage de l’entreprise française Vade Retro afin de faire le tri entre ce qui est du spam ou un email légitime.

Le second indicateur est le taux d’adresses invalides (GU_EIB_02) que vos envois génèrent. Cet indicateur prend donc en compte la qualité de votre gestion des données. Le maintien d’une liste propre est un pré-requis à une bonne délivrabilité qui se vérifie encore ici.

Une question de seuils

Pour que vos messages soient rejetés, il faut évidemment que le taux d’adresses invalides ou le taux de spam soient anormaux. Dans les deux cas, à partir d’une vingtaine de messages envoyés, SFR défini le seuil à 25%. Si l’on considère ce seuil vis à vis des taux d’adresses invalides considérés comme bons dans l’industrie (moins de 3 à 4%), on voit clairement que le seuil émis par SFR ne risque pas de toucher les expéditeurs ayant de bonnes pratiques en matière d’hygiène de liste.

Durée

Deux types de durées sont à prendre en compte.

La fenêtre d’échantillonnage : Cette durée est d’environ 5 minutes. C’est à dire que si vous dépassez 25% de mises en spam ou de bounces pendant plus de 5 minutes, vos envois seront temporairement bloqués.

La durée du blocage : Chaque fois que vous atteignez le seuil fatidique, vos envois sont bloqués pour une durée d’une vingtaine de minutes. Évidemment, si après ces 20 minutes vos envois ne remplissent toujours pas les critères, vous serez de nouveau bloqué pour 20 minutes … et ainsi de suite. Cela peut donc ralentir vos envois de manière significative.

Récapitulatif

  • GU_EIB_02
    • Indicateur : Taux d’adresses invalides
    • Seuil : 25%
    • Fenêtre d’échantillonnage : 5 minutes
    • Durée du blocage : 20 minutes
  • GU_EIB_04
    • Indicateur : Classement en spam
    • Seuil : 25%
    • Fenêtre d’échantillonnage : 5 minutes
    • Durée du blocage : 20 minutes

Mise en œuvre technique

Afin de gérer finement ce genre de cas, il est important d’utiliser un serveur SMTP capable de détecter ce type de retour (les codes GU_EIB_02 et GU_EIB_04) et capable de s’adapter en temps réel.

Malheureusement, les serveurs opensource de type Postfix, Qmail ou Sendmail ne sont pas capables de gérer nativement ce type de comportement. C’est pourquoi chez DeliverNow, nous recommandons activement d’utiliser PowerMTA. Celui-ci propose un mode backoff et une gestion fine de la connectivité. Si vous désirez en savoir plus, n’hésitez pas à contacter DeliverNow.

Remarques

Vous êtes touché par GU_EIB_02 alors que vous avez une bonne hygiène de liste ?

Dans ce cas, il est fort probable que vous ne soyez pas le seul à utiliser l’adresse IP bloquée. C’est par exemple le cas si vous utilisez votre serveur web pour expédier vos emails. La seule solution est d’utiliser une adresse IP dédiée ou un relais SMTP spécialisé. N’hésitez pas à contacter DeliverNow si vous désirez mettre en place une solution SMTP sur mesure.

Quid de Numéricable ?

Comme vous le savez sans doute, SFR a récemment été racheté par Numericable. Pour l’instant, il n’y a encore aucun impact au niveau délivrabilité. SFR et Numericable continuent à utiliser les mêmes serveurs MX que précédemment. DeliverNow vous tiendra informé s’il y a le moindre changement sur ce dossier.

Le Big Data au service de votre délivrabilité : DeliverNow choisit Splunk

splunkCe n’est un secret pour personne, envoyer des emails génère de très nombreuses données. Ce volume est d’ailleurs en train de gonfler en même temps que l’évolution de la sophistication des stratégies email marketing. En plus des données issues du tracking des clics et des ouvertures, on peut par exemple évoquer les données générées par la géolocalisation, l’analyse comportementale, … Mais le plus grand générateur de données en email marketing reste le protocole SMTP lui-même. Chaque connexion SMTP étant constituée d’un dialogue entre deux serveurs SMTP distants, les étapes de ce dialogue génèrent une quantité de « traces » impressionnante.

Pour correctement analyser et suivre l’évolution de la délivrabilité, l’utilisation des données internes n’est pas suffisante. Il faut savoir exploiter et réintégrer les données issues de systèmes externes, par exemple :

  • Le traitement et l’analyse des données issues des boucles de rétroaction (le nombre de plaintes par adresse IP) ;
  • Les données issues du monitoring des listes noires ;
  • Les informations concernant le nombre de spamtraps touchés ;
  • Les données proposées par les « fournisseurs » de réputation comme Senderscore de ReturnPath ou Senderbase de Cisco ;

La complexité de l’analyse de toutes ces données réside dans la multitude de formats, de codes, … rien que les codes d’erreur SMTP peuvent être différents d’un FAI à un autre pour un même événement. Sans parler de la multitude de technologies et de formats utilisés par les différentes boucles de rétroaction.

Il est donc indispensable d’agréger et de recouper ces différentes données afin de générer des rapports pertinents qui vous permettront de contrôler tous les paramètres de votre délivrabilité. C’est là qu’entre en jeu le Big Data.

DeliverNow fait le choix de Splunk

On peut parler de Big Data lorsque la masse et la diversité des données générées commencent à poser des problèmes de traitement avec les outils classiques. En matière de délivrabilité email, comme nous l’avons vu dans cet article, il devient rapidement compliqué de gérer, d’agréger et d’exploiter toutes ces données.

C’est pourquoi DeliverNow a décidé de s’appuyer sur les services de Splunk en devenant revendeur agréé. Splunk est un moteur de collecte, d’indexation et d’exploitation des données générées par les différents composants d’une infrastructure informatique. L’outil permet de déployer des solutions de monitoring permettant de détecter et de diagnostiquer tout incident pouvant survenir dans l’exploitation d’une infrastructure informatique.

Sur base de Splunk, DeliverNow a développé une solution clé en main (lié à l’utilisation de PowerMTA de Port25 ou à d’autres MTA) vous permettant d’avoir une maîtrise complète de votre délivrabilité. Grace à la Big Data, nous sommes capables monitorer l’ensemble des paramètres constituant votre délivrabilité et de détecter dans un temps record tout incident ou toute fluctuation majeure de votre réputation d’expéditeur.

En matière de délivrabilité, il est indispensable de réagir le plus rapidement possible à tout incident afin de limiter les dégâts, et aujourd’hui, l’exploitation de la Big Data est indispensable.

Pour plus d’informations sur nos outils, n’hésitez pas à nous contacter.

Pourquoi faire le choix de PowerMTA pour l’internalisation de votre délivrabilité email ?

client03Si vous faites le choix d’internaliser votre délivrabilité (voir notre article sur le sujet), un autre choix est indispensable : Quelle solution d’envoi choisir ?

Chez DeliverNow, nous avons fait le choix de privilégier PowerMTA (et de devenir revendeur et intégrateur agréé), une solution éditée depuis 1999 par Port25. PowerMTA équipe aujourd’hui la majeure partie des grands routeurs internationaux (voir l’infographie “Port25 par les chiffres”) , c’est une solution qui a fait ses preuves et dont la robustesse n’est plus à prouver.

Si nous avons fait le choix de l’intégration de PowerMTA (nous aurions pu choisir une solution libre comme Postfix), c’est pour faire profiter à nos clients de son incroyable richesse en matière de gestion de la délivrabilité. Port25 met un point d’honneur à suivre les dernières tendances en matière de délivrabilité et d’être à la pointe de l’innovation.

Authentification et gestion des flux

L’authentification des vos emails à l’aide des DomainKeys et de la norme DKIM est devenue indispensable afin d’assurer l’intégrité de vos emails durant l’envoi de ceux-ci. Avec PowerMTA, vous êtes certain de la qualité des emails sortant. Avec le mode “Guaranteed Authentic”, la conformité des signatures de vos emails en queue est analysée et en cas d’échec, des alertes sont déclenchées.

À côté de la gestion de l’authentification, le MTA édité par Port25 vous permet aussi de gérer un nombre illimité d’adresses IP réparties dans différents MTA virtuels. Cette souplesse vous offre la possibilité de gérer le plus finement possible la granularité de votre infrastructure d’envoi. Par exemple, si vous devez gérer un flux d’email hétérogène, vous aurez l’occasion d’allouer différentes ressources (adresses IP, vitesse d’envoi, connexion simultanées, bande passante, …) en fonction de l’importance accordée à chaque type de message.

powermta_virtualmta

Gestion de la connectivité

La délivrabilité n’est pas une science simple. Chaque destination (FAI ou Webmail) requiert des réglages différents. Que ce soit le nombre d’emails envoyés chaque minute, le nombre de connexions simultanées, la vitesse de montée en réputation, … ils ont chacun leurs pratiques propres. Pour cette raison, PowerMTA vous offre la possibilité d’atteindre un niveau extrêmement précis de réglage de votre connectivité.

Vous pouvez, par exemple, adapter ces différents paramètres par domaine/destination :

  • Le nombre de connexions simultanées ;
  • Le nombre de messages envoyés par connexion ;
  • Le nombre de tentatives d’envoi par heure ;
  • La durée maximale des “retry” ;
  • Les méthodes d’authentification à utiliser.

Comme nous l’avons vu au point précédent, tous ces paramètres sont évidemment configurables au niveau des MTA’s virtuels. Par exemple, pour la destination AOL, vous aurez l’occasion d’offrir deux fois plus de connexions simultanées pour vos emails transactionnels, ce qui vous garantira une livraison plus rapide de vos emails de confirmation (qui sont toujours critiques pour votre business) que de vos newsletters.

Suivi de la délivrabilité

Le premier point concernant le suivi de la délivrabilité via PowerMTA est que celui-ci vous offre la possibilité d’explorer un fichier de log SMTP complet. C’est un point essentiel qui vous permettra avec un peu d’expertise de vérifier précisément la source de tout incident de délivrabilité pouvant survenir.

D’autre part, PowerMTA vous fournira un ensemble d’outils permettant de suivre l’évolution de votre délivrabilité, par destination, par campagne ou par MTA virtuel :

  • Catégorisation en temps réel des bounces ;
  • Outils d’analyse des statistiques en ligne de commande ;
  • Accès aux statistiques via une interface web ;
  • Gestion des exports des logs dans différents formats (XML, CSV, HTML, …) ;
  • Une API permettant de brancher vos logs sur votre propre système d’analyse.

La solution n’oublie évidemment pas d’intégrer nativement les principales boucles de rétroaction afin de pouvoir gérer le plus efficacement possible les plaintes spam de internautes.

Intégration et personnalisation

Au delà de la délivrabilité de vos messages, PowerMTA vous offre de nombreuses solutions afin de gérer les envois comme bon vous semble. En plus du classique relais SMTP et du dépôt de fichiers dans un répertoire, des API ont été développées, ce qui vous permettra de soumettre vos messages à l’envoi quelque soit le langage de programmation utilisé (C, C++, C#, Java, Perl, …).

À cette souplesse sur les méthodes d’envoi des messages vers PowerMTA s’ajoute de puissantes fonctionnalités de fusion des données afin de personnaliser vos messages et d’être au plus proche des attentes des membres de vos programmes marketing.

Tester gratuitement PowerMTA avec une licence gratuite de 30 jours

Niveau performance, PowerMTA se commercialise en 2 licences : standard et entreprise. La version standard permet d’envoyer 100 000 emails par heure tandis que la version entreprise peut monter jusqu’à 1 000 000 emails par heure.

DeliverNow vous propose de tester gratuitement PowerMTA pendant 30 jours. Cela vous permettra de juger de la puissance et de la souplesse de l’outil avant de prendre une décision sur son intégration.

D’autre part, si vous désirez en savoir plus sur les modèles de licence et sur les services d’intégration (installation, configuration, mise en route, …) proposés par DeliverNow, n’hésitez pas à nous contacter.

Internaliser ou externaliser le routage des emails : avantages et inconvenients

slideshow-01La délivrabilité a toujours été un élément stratégique pour toute entreprise exploitant l’email marketing. Ces dernières années, le sujet est devenu de plus en plus complexe à appréhender : augmentation du phishing, plus grand agressivité des filtres anti-spam, boîtes email intelligentes, internationalisation des listes d’email, … Par chance, les responsables techniques, mais aussi marketing sont de plus en plus sensibilisés à ces question.

Mais même s’ils sont de plus en plus sensibilisés à la délivrabilité, les annonceurs sont bien souvent démunis devant certaines questions cruciales. L’une de ces interrogations : Faut-il internaliser ou externaliser le routage pour garder la maîtrise de la délivrabilité ?

Dans cet article, nous allons tenter d’aborder les avantages et les inconvénients du routage externalisé versus un routage en interne.

Externaliser votre routage, moins de travail, mais aussi moins de contrôle

Commençons d’abord par les avantages de la délivrabilité externalisée.
Le plus important est certainement l’expertise, l’objectif d’un routeur étant d’envoyer vos emails, toute l’organisation de celui-ci devrait être tournée vers cet objectif. Cela veut dire que l’infrastructure du routeur évoluera en même temps que le marché et qu’il mettra celle-ci aux normes plus rapidement que si vous deviez le faire vous-même.

Un exemple concret est le récent changement de Gmail dans l’affichage des images, qui avait “cassé” le tracking des ouvertures de certains routeurs. Dans ce cas, il n’aura fallu que quelques jours pour que ceux-ci mettent à jour leur infrastructure. Il n’en sera peut-être pas de même si vous gérez ces aspects en interne !

Pour autant, externaliser le routage chez un tiers comporte aussi des inconvenients. Le premier, et certainement le plus important, est la rareté des spécialistes. Chez chaque routeur on peut compter entre un et trois (rarement plus) « deliverability managers”, c’est à dire des personnes dediées à la mise en place, gestion, surveillance et analyse de la délivrabilité. En faisant un calcul simple, suivant le nombre de clients de votre routeur, essayez de deviner combien de temps un deliverability manager aura l’occasion d’accorder à chaque client ? En général, ce sera beaucoup moins d’une heure par mois autant dire pas grand chose, surtout en cas d’incident majeur.

Quand vous exploitez une base de donnée à des fins marketing, celle-ci constitue votre principale richesse. Le temps passé et les moyens investis afin d’établir une relation de confiance avec vos clients sont inestimables. Pour cette raison, vous devriez toujours être méfiant quand il s’agit de confier votre base de donnée à un tiers, même si c’est bien souvent pour une très bonne raison. Avec l’externalisation de votre délivrabilité, c’est non seulement votre liste d’email que vous confiez à un tiers, mais c’est aussi l’ensemble de vos messages et des données comportementales générées par ceux-ci. Et c’est bien cela qui fait la valeur d’une entreprise.

Un changement de pratique de la part des annonceurs : le multiroutage

Confrontés à de plus en plus d’incidents de délivrabilité (gérés de manière très inégale selon les routeurs), les annonceurs tentent de reprendre le contrôle de leur délivrabilité de plusieurs manières différentes. La première, c’est de s’informer et de se former. De plus en plus d’expéditeur essayent de gagner en connaissance afin de décrypter les informations qu’ils reçoivent de la part de leurs routeurs.

Malheureusement, la formation des équipes n’est pas toujours suffisante, ce qui les pousse à expérimenter eux-mêmes des parades. L’une d’elle est la pratique du multiroutage, qui consiste à utiliser plusieurs routeurs en parallèle. Que ce soit afin d’avoir une roue de secours en cas d’incident chez leur routeur principal ou en mutualisant plusieurs plateformes. On voit donc émerger des annonceurs qui utilisent 2 ou 3 routeurs en simultané, voir parfois beaucoup plus.

Mais est-ce que le multiroutage améliore réellement la délivrabilité ? En fait, le multiroutage est loin d’être une solution pérenne. Au lieu de résoudre les incidents de délivrabilité à la source, il s’agit d’une fuite en avant qui va au mieux améliorer temporairement la délivrabilité au pire réduire durablement votre réputation d’expéditeur.

L’internalisation : un investissement pour l’avenir ?

La dernière solution est l’internalisation des processus de délivrabilité. Ici, on retrouve en partie l’un des inconvénients de l’externalisation : le marché manque de spécialistes. Mais les budgets qui étaient précédemment dédiés à payer une solution externalisée (licence, coût de l’envoi, coût d’intégration) pourront être utilisés afin de former vos responsables techniques pour que ceux-ci deviennent de vrais experts de la délivrabilité.

L’un des inconvénients majeur de l’internalisation est aussi l’un de ses avantages. En internalisant, vous serez aussi obligé d’internaliser toutes les questions de sécurité des données et de gestion des adresses email. Si cela peut sembler un chantier considérable, c’est aussi un avantage important parce que vous avez l’occasion de réduire le nombre d’intervenants dans vos process.

Internaliser la délivrabilité, cela veut dire ne pas dépendre de la réputation globale d’un routeur ou même de la réputation des autres clients de ce routeur. En utilisant votre propre infrastructure, votre propre range d’adresses IP, votre propre nom de domaine, … vous êtes certain que votre réputation d’expéditeur dépend à 100% de vos pratiques. Aucun élément externe ne viendra perturber celle-ci.

Concernant les éventuels incidents de délivrabilité, l’internalisation vous permet d’avoir toutes les cartes en main. Pour être un peu technique, l’envoi d’un email est un dialogue SMTP entre 2 serveurs : HELO, MAIL FROM, RCPT TO, DATA. À chaque étape du dialogue SMTP, un blocage ou une erreur peut survenir, et la réponse est souvent très explicite. Maitriser son serveur SMTP permet de connaitre les raisons exactes des problèmes pour pouvoir ensuite les résoudre. C’est un avantage par rapport à un routeur qui regroupera souvent les différents codes SMTP dans des catégories beaucoup moins explicites : hardbounces, softbounces et spam filter.

De plus, en effectuant un monitoring en temps réel de votre délivrabilité, vous aurez l’occasion d’être beaucoup plus réactif afin de résoudre les différents incidents de délivrabilité. Être dépendant d’un tiers en cas d’incident ralenti inévitablement le processus surtout si vous n’avez pas les outils pour détecter ces incidents vous-même.

L’internalisation n’est pas une recette magique qui vous évitera tous les problèmes. Mais si la délivrabilité est stratégique pour votre activité, vous avez tout intérêt à impliquer vos équipes internes dans sa maîtrise. Moins il y aura d’intervenants externes, moins il vous faudra de temps pour résoudre vos problèmes.

SFR implémente DKIM pour authentifier les messages entrants

Depuis vendredi 30 novembre dernier, SFR authentifie les messages entrants grâce à la technologie DKIM. Pour le moment, les messages non-authentifié ou mal authentifié ne subissent pas de traitement particulier.

En regardant les en-têtes des messages envoyés à SFR, on constate l’apparition de l’en-tête Authentication-Results comprenant le résultat du test d’authentification ainsi que l’analyse de la politique ADSP publié par le propriétaire du domaine.

Je rappelle que l’authentification DKIM est basé sur une technologie de chiffrement des en-tête grâce à un système de clé privée / clé publique, la clé privé étant utilisée par le MTA de l’expediteur pour signer le message lors de l’envoi et la clé publique diffusée dans un enregistrement DNS et utilisée pour authentifier le message lors de sa réception.

Exemple d’enregistrement clé publique DKIM pour le domaine facebookmail.com :

dlnw$ dig s1024-2011-q2._domainkey.facebookmail.com TXT +short
"k=rsa; t=s; h=sha256; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDLWnmo7aFBKfL4+mogTe/cXx6D4M
UF7VUM9O+nmXAcUP6jJh1RDgZuSJ/KKxo+KMpDiF5xnawr4p3N4eFruSZWFB1vtHgDiy3iPk
e/u0lmXB2PDQphFRJU4Raghm9e2duPfuSExbvSu9COWIoaz1vH/T+8zc0vuonClGuPfxoqhQID
AQAB"

ADSP est aussi un enregistrement DNS, placé sous l’enregistrement DKIM du domaine, et destiné à communiquer publiquement la politique de signature du domaine en question.

L’enregistrement ADSP peut prendre 3 valeurs :

  • all : tout les emails envoyés pour ce domaine sont signés.
  • discardable : tout les emails envoyés pour ce domaine sont signés, et si un message arrive non signés ou avec une signature non valide, le propriétaire du domaine encourage le destinataire à rejeter celui-ci.
  • unkown : tout ou partie des messages envoyés par ce domaine sont signés.

Etant donné l’actualité agité autour de DKIM, il est important de préciser que SFR authentifie tous les messages signés, quelque soit l’algorithme utilisé pour le cryptage et la longueur de la clé.

Pour le moment, l’authentification DKIM chez SFR est en mode écoute, cela signifie qu’aucune politique de filtrage n’est appliqué aux messages non-authentifié. Au début de l’année prochaine, SFR tiendra compte de la signature ADSP et appliquera ça propre politique aux messages non signés.

Mais concrètement, qu’est ce que cela apporte à l’écosystème email ?

Pour les marques, une signature DKIM valide et une politique ADSP stricte aura pour effet de protéger les domaines de la marque du phishing.

Pour les expéditeurs d’emails, cela signifie que DKIM prend une place un peu plus importante et qu’il est aujourd’hui indispensable de proposer à  ses clients d’authentifier ses emails grâce à cette norme.

Pour SFR, c’est une façon de rendre les boites aux lettres de leurs abonnés plus sûre, en utilisant les possibilités technologiques modernes tout en s’affichant comme un ISP responsable et coopératif dans l’écosystème email.

Authentification des emails entrants chez SFR

Avec la montée en puissance des campagnes de phishing, l’authentification des messages entrants pour un FAI est un enjeu important pour protéger ces utilisateurs.

Comme évoqué précédemment, il existe différentes normes pour authentifier les messages sortant. Depuis septembre 2011, SFR a décidé de vérifier l’authenticité des emails entrants grâce à la norme SPF et étudierai l’implémentation prochaine de DKIM.

La norme SPF permet aux propriétaires de domaine d’indiquer, grâce à un enregistrement DNS, quelles sont les serveurs autorisés à utiliser ce domaine pour expédier des emails.

Voyons, grâce à deux exemples concrets, comment SFR traite et filtre les emails entrants grâce à SPF :

  • Dans un premier temps, essayons d’envoyer un email à SFR à partir de l’IP 82.165.131.171 avec le domaine dlnw01.com pour lequel on aurait paramétré l’enregistrement SPF strict suivant v=spf1  ip4:82.165.131.172  -all

    Le résultat est un refus de livraison a cause du SPF hardfailed : 

    HELO dlnw01.com
    250 msfrf2207.sfr.fr
    MAIL FROM:<dlnw@dlnw01.com>
    554 5.7.1 <dlnw@dlnw01.com>:  Sender address rejected: Please%see%http://spf.pobox.com/why.html?sender=dlnw%40dlnw01.com&ip=82.165.131.171&receiver=msfrf2207 : Reason: mechanism
  • Maintenant, voyons une tentative d’envoi d’un email à SFR à partir de l’IP 82.165.131.171 avec le domaine dlnw01.com pour lequel on aurait paramétré l’enregistrement SPF souple suivant v=spf1  ip4:82.165.131.172  ~all

    Le résultats est la livraison du mail en boite spam avec dans l’entête le header suivant : 

    X-tag-spam: SPF SoftFail

Pour protéger son identité, il est important pour un annonceur d’authentifier ces domaines, mais l’exemple si dessus montre qu’il est nécessaire de le faire correctement pour éviter un rejet de connexion ou une livraison en boite spam.

De plus, l’authentification a pour but d’assurer l’authenticité de l’expéditeur et même authentifier correctement, les emails ne sont pas assurés d’arriver en boite de réception principale.

DMARC: un nouveau standard pour la protection des domaines

Le protocole SMTP est vieux et simple d’utilisation.
Il a été inventé avant 1980 pour permettre d’envoyer des courriers électroniques sur des réseaux privés.
Grâce au protocole SMTP natif, il est possible d’envoyer un email en utilisant l’adresse email expéditrice que l’on veut, cette possibilité a engendré des problèmes de fiabilité des communications électroniques avec notamment, l’apparition des campagnes de phishing. Pour remédier à cela, les opérateurs ont mis au point un concept permettant aux expéditeurs d’emails d’authentifier leurs messages.

L’authentification des emails a pour but  d’assurer aux destinataires que l’expéditeur est bien celui qu’il dit être.

Dans la pratique, cela a donné 4 normes :

  • SPF et SenderID, dont le principe est de placer un enregistrement TXT dans le DNS du domaine pour spécifier les IPs autorisées à émettre des emails depuis ce domaine. La norme SPF étant la norme commune basée sur le MAIL FROM du dialogue SMTP et dans le domaine des ReverseDNS des IPs expéditrices. Le SenderID est la déclinaison de Microsoft, qui elle est basée sur le domaine de l’adresse « PRA » dont Microsoft a breveté l’algorithme, ce qui limite donc son utilisation.
  • DomainKeys et DKIM, dont le principe est basé sur un système de cryptage clé publique / clé privée appliqué sur certains champs de l’entête du mail.  DomainKeys a été inventé par Yahoo et DKIM par la communauté internet, comme dans le cas précédent, c’est DKIM tend à s’imposer.

Mais il manquait une chose à ces dispositifs, une chose qui permettrait aux expéditeurs qui authentifient correctement leurs emails d’informer les destinataires afin que ceux-ci filtrent plus strictement les messages non-authentifiés qui, bien souvent, seraient du phishing. Un groupement d’acteurs importants tel que Google, Facebook, Microsoft, Yahoo et AOL se sont regroupés pour développer un nouveau dispositif qui permettrait de remédier à cela en créant la norme DMARC et en tentant de la standardiser auprès de l’IETF.

DMARC signifie littéralement « Domain-based Message Authentication, Reporting & Conformance » et permet aux annonceurs de protéger leur marque et leur domaine en spécifiant précisément aux FAI les traitements à réaliser aux messages non-authentifiés.


DMARC permet aux annonceurs de protéger leurs domaines en indiquant clairement aux FAI  la politique à adopter envers les emails dont les signatures SPF et/ou DKIM seraient en erreur. Ce qui, dans le cas, d’une implémentation parfaite, permet définitivement d’empêcher le phishing sur le domaine de l’annonceur. A mon sens, c’est une avancée considérable en terme de protection des domaines et de lutte contre le phishing. Une autre possibilités intéressante de DMARC pour un annonceur est la possibilité de recevoir des rapports de la part des FAI pour connaitre la proportion de messages authentifié et non-authentifié sur son domaine. Ce qui permet d’avoir une idée de phishing sur son domaine.

En tant qu’expéditeur, pour implémenter DMARC, il faut s’assurer d’abord d’avoir implémenter correctement SPF et DKIM puis publier un enregistrement DMARC dans le DNS en tant qu’enregistrement TXT pour la zone _dmarc.mondomain.com

Exemple pour le domaine delivernow.eu :

Domain                                  Type                       Record

_dmarc.delivernow.eu   TXT                         « v=DMARC1; p=none; sp=none; pct=100; rua=mailto:admin@delivernow.eu; ruf=mailto:failure@delivernow.eu; »

p= politique de traitement à appliquer aux emails dont l’authentification est en erreur, basé sur le domaine. valeurs possible : none, quarantaine ou reject

sp= politique de traitement à appliquer aux emails dont l’authentification est en erreur, basé sur les sous-domaine. valeurs possible : none, quarantaine ou reject

pct= pourcentage des mails à filtrer

rua= adresse qui recevra les rapports agrégés de la part du FAI

ruf= adresse qui recevra les rapports d’erreurs d’authentification au fil de l’eau (AFRF)

Il existe des attributs supplémentaire pour l’enregistrement DMARC, disponible dans les spécifications détaillé.

 

Aujourd’hui, seulement Gmail utilise DMARC pour protéger les messages entrant mais il faut s’attendre à d’autres implémentation dans l’année dont certainement Yahoo, AOL et Microsoft.

Visiter le site de DMARC :
http://dmarc.org/

Voir les specifications completes de DMARC :
http://www.dmarc.org/draft-dmarc-base-00-01.html

Voir un slide de présentation simplifié sur DMARC :
http://dmarc.org/presentations/DMARC_general_overview_20120130.pdf

 

List-Unsubscribe : un standard pour gérer le désabonnement

unsubscribLa commande List-Unsubscribe est défini par la RFC 2369. Lors de l’envoi d’un email en SMTP, elle défini une commande à ajouter dans l’entête de celui-ci afin de spécifier les procédures de désabonnements au client de messagerie.

Il y a 2 façons d’implémenter cette procédure de désabonnement : soit en précisant une URL pour la désinscription, soit en précisant une adresse email.

Voici quelques exemples d’implémentation :

List-Unsubscribe: <mailto:list@host.com?subject=unsubscribe>
List-Unsubscribe: <mailto:list-manager@host.com?body=unsubscribe%20list>
List-Unsubscribe: <mailto:list-off@host.com>
List-Unsubscribe: <http://www.host.com/list.cgi?cmd=unsub&lst=list>,<mailto:list-request@host.com?subject=unsubscribe>

L’année dernière, Microsoft a implémenté cette fonctionnalité dans son webmail pour les adresses hotmail, msn et live et intègre le lien de désinscription dans son interface à partir du moment ou l’utilisateur demande l’affichage des images.

Cet été, c’est au tour de Gmail d’intégrer cette fonctionnalité dans son interface de messagerie.

Selon diverses études, les internautes utilisent le bouton de report pour spam pour se désabonner des emails qu’ils reçoivent, les formulaires de désabonnement classique n’inspirent plus confiance aux internautes.

D’autre part, les reports pour spam via le bouton prévu a cet effet sont aujourd’hui le principal facteur de la délivrabilité chez les principaux webmail (gmail, hotmail, yahoo, aol) en influant sur la réputation de l’expéditeur.

Il est donc important d’utiliser cette fonctionnalité afin de minimiser les reports pour spam qui aurait pour but une désinscription.