Technique Archives - DeliverNow

La présences d’un entête List-Unsubscribe est un facteur critique pour la délivrabilité des emails

Régulièrement, nous voyons encore des emails ne contenant pas d’entête List-Unsubscribe. Ceci nous amène à publier un nouvel article de BLOG sur ce sujet important. Par ailleurs, nous avons créé un module additionnel à destination des utilisateurs de PowerMTA afin de leur faciliter le traitement des requêtes MAILTO unsubscribe.

Qu’est ce exactement qu’un entête List-Unsubscribe ?

Quand des abonnés veulent se désinscrire d’une liste de diffusion et que le processus de désinscription est trop complexe, ces abonnés vont souvent utiliser le bouton de mise en SPAM pour se désinscrire. L’utilisation de ce bouton de mise en SPAM va impacter négativement la réputation de l’expéditeur et réduire sa capacité à atteindre la boîte de réception à moins que List-Unsubscribe ne soit utilisé. Cette fonctionnalité ajoute un moyen supplémentaire de traiter les désinscriptions. Le nombre total de clics sur le bouton de mise en SPAM est donc réduit.

Dans GMAIL, la fonctionnalité List-Unsubscribe apparaît comme suit pour les utilisateurs:

Dans les deux paragraphes suivants, nous allons expliquer quelles sont les bonnes pratiques pour la mise en place de l’entête List-Unsubscribe et nous partagerons une étude cas sur la situation avant et après l’implémentation de l’entête List-Unsubscribe avec le lien mailto:

Bonnes pratiques pour la mise en place de l’entête List-Unsubscribe

List-Unsubscribe est un entête additionnel ajouté par les applications d’email. Il fournit aux receveurs deux mécanismes pour désinscrire les destinataires d’une liste de diffusion:  

  1. en suivant un lien http://
  2. via un lien mailto: dans l’email.

List-Unsubscribe est un standard défini dans la RFC 2369.

Le format de l’entête List-Unsubscribe est:

List-Unsubscribe: <mailto:unsubscribe-espc-tech-12345N@domain.com>,

<http://domain.com/member/unsubscribe/?listname=espc-tech@domain.com?id=12345N>

Veuillez noter que le lien de désinscription (lien http://) ne doit pas nécessiter d’entrée supplémentaire de la part de l’utilisateur et que la demande doit être traitée après réception de la requête POST. Le désinscription doit se faire en un clic comme décrit dans la RFC 8058 ci-dessous:

List-Unsubscribe: <https://example.com/unsubscribe/opaquepart>

List-Unsubscribe-Post: List-Unsubscribe=One-Click

Resulting POST request

POST /unsubscribe/opaquepart HTTP/1.1

Host: example.com

Content-Type: application/x-www-form-urlencoded

Content-Length: 26

List-Unsubscribe=One-Click.

Notez aussi que la partie locale de l’adresse du lien mailto: ne doit pas dépasser 64 caractères.

De l’importance du lien mailto: !

Hotmail ne supporte que le lien mailto:. Quand un utilisateur clique sur le bouton de désinscription dans Hotmail, Hotmail essaye de lire le lien mailto: de l’entête List-Unsubscribe. Si ce lien est manquant, le message est déplacé vers la boîte SPAM. Tous les futurs messages de cet expéditeur seront mis en SPAM sans notification de celui-ci via les plaintes JMRP. Pour plus d’informations, veuillez lire ce document : Hotmail Email Sender Guidelines.

Gmail supporte à la fois le lien http:// et le lien mailto:. Mais, quand un utilisateur signale un email comme ‘SPAM’, Gmail essaye en premier lieu d’effectuer la désinscription en envoyant un message vide vers l’adresse de List-Unsubscribe (mailto:). Par la suite, la probabilité que Gmail classe les nouveaux emails de cet expéditeur en SPAM augmente. Pour plus d’informations, veuillez lire ce document :  Gmail Email Sender Guidelines.

Le lien mailto: est supporté par Gmail, Hotmail, Yahoo, AOL, ATT, Time Warner et Comcast; les FAIs européens tels que GMX, Libero, Ziggo, Orange, BTInternet; russes tels que mail.ru and Yandex;  et les domaines chinois qq.com, naver.com etc. La plupart des FAIs supportent (et préfèrent) l’utilisation des liens mailto:.

Etude de cas: les bienfaits de l’implémentation du lien mailto:

Un des clients de Postmastery a mis en place l’entête List-Unsubscribe, mais sans lien mailto:. Dès que le lien mailto: a été ajouté, le MTA a reçu 55 000 demandes de désinscription via ce lien sur une période de 30 jours ( 150 millions de messages ont été envoyés dans cette même période, mais il s’agit quand même d’un volume significatif de désinscription). Parmi celles-ci :

  • 20 000 demandes de désinscription ont été recues de gmail.com (en excluant les domaines GSuite),
  • 14 000 provenaient de domaines liés à Yahoo,
  • 3 500 provenaient de domaines liés à Hotmail,
  • 3 500 provenaient de domaines liés à Apple tel que icloud.com etc.,
  • les autres provenaient de divers FAIs.

Module additionnel de traitement des ‘unsubmails’ pour PowerMTA

Postmastery a développé un Webhook (codé en GoLang) appelé ‘unsubmail’ qui est contrôlé par PowerMTA. Il reçoit les emails directement de PowerMTA (via pipe queue) et les convertit en appels vers une URL tout en mappant les paramètres de la partie locale du lien mailto:. Pour plus de détails, suivez ce lien.

Plus d’informations :Si vous souhaitez en savoir plus sur la façon dont nous pouvons vous aider à résoudre vos problèmes de délivrabilité, laissez nous un message via notre page de contact

Utiliser un encodage MIME correct permet d’éviter les échecs DKIM dans Outlook

Postmastery / DeliverNow travaille pour de nombreux routeurs et marques en leur permettant d’optimiser leur délivrabilité.
Récemment, un de nos clients a été confronté à un problème mystérieux d’échec DKIM lors de ses envois vers les domaines d’Outlook.com. (Une description générale de DKIM et de son fonctionnement est disponible sur dkim.org.)

Analyse des entêtes SMTP

La première chose que nous avons faite a été d’analyser les entêtes email du client en envoyant un message échantillon vers l’outil gratuit de Postmastery EmailAudit.com.
Nous avons alors trouvé une première indication dans ces entêtes.

Authentication-Results: spf=pass (sender IP is xxxx) smtp.mailfrom=cebounce.domain.com; Hotmail.com; dkim=fail (body hash did not verify) header.d=domain.com;Hotmail.com; dmarc=pass action=none header.from=domain.com

DKIM est basé sur le hachage de certaines parties de l’email. Le ‘body hash’ est une chaîne de caractères générée par l’algorithme de hachage à partir de corps du message.

A la vue de cette erreur, nous avons constaté que la canonicalisation du corps du message était paramétrée en mode relâché (relaxed), ce qui devrait permettre d’éviter les erreurs de hachage du corps du message. C’est le paramétrage recommandé si vous souhaitez minimiser les problèmes avec DKIM.

Analyse des rapports DMARC pour vérifier la validation DKIM

Logiquement, l’étape suivante était l’analyse des rapports DMARC afin de vérifier la validation DKIM pour tous les messages. Malheureusement, vers la fin d’avril de cette année (2018), Hotmail.com a temporairement stoppé l’envoi des rapports DMARC, nous ne pouvions donc pas effectuer ces contrôles en nous basant sur ces rapports. La seule solution restante était de vérifier la validation DKIM en se basant sur les emails reçus sur nos propres boîtes de messagerie.

Nous avons d’abord extrait le contenu des emails échantillons et nous avons essayé d’envoyer exactement les mêmes messages directement vers le MTA. Nous avons utilisé l’encodage suivant pour le paramétrage de nos tests:

–add-header “MIME-Version: 1.0” –add-header “Content-Type: text/html” –add-header “Content-Transfer-Encoding: quoted-printable”

DKIM étant correctement validé pour tous nos tests. Nous avons à nouveau vérifié les emails que nous avait transmis notre client. La solution commençait à se rapprocher. Nous avons continué à collecter des données en envoyant quelques emails tout en loggant la totalité des données de transaction SMTP. En faisant cela, nous espérions découvrir quelque chose dans le contenu qui soit modifié ou qui provoque l’échec de la validation DKIM par Microsoft.

Ce fut un succès. En comparant le données binaires du client avec les nôtres, nous avons fini par trouver le coupable. L’application de notre client n’encodait pas correctement les caractères NON-ASCII dans la partie TEXT/PLAIN.

Il y avait dans le contenu des messages des caractères UTF-8 non compris dans le jeu de caractères ASCII alors que les entêtes MIME annonçaient du contenu ASCII. A la place, elles auraient dû spécifier UTF-8. Bien que ce paramétrage puisse ne pas fonctionner avec certains receveurs qui ne supportent pas 8BITMIME, il est préférable d’utiliser l’encodage ‘quoted-printable’ pour le ‘transfer encode’ UTF-8

Conclusion

Il faut utiliser le bon encodage et toujours effectuer des tests pour vérifier les entêtes des messages pour de nombreux receveurs comme Outlook, Gmail et Yahoo. Nous conseillons d’utiliser Quoted-Printable pour le transfer encoding afin d’obtenir des résultats optimaux.

Plus d’informations

Si vous souhaitez en savoir plus sur la façon dont nous pouvons vous aider à résoudre vos problèmes de délivrabilité, laissez nous un message via notre page de contact

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.