tendances en matière de courriel

tendances en matière de courriel


Sujets abordés dans ce domaine :

Directives d'authentification des courriels

Instructions pour la configuration des protocoles SPF, DKIM et DMARC pour l'authentification des e-mails

une bonne alternative aux e-mails BCC

Liste « unidirectionnelle » Mailman, une configuration spéciale pour les newsletters ou les annonces

proxy inverse pour serveurs SMTP

Comment améliorer la sécurité, les performances et l'évolutivité de votre serveur SMTP

Comment extraire les adresses e-mail

Vous pouvez obtenir les données souhaitées à l'aide d'expressions régulières

Comment protéger les domaines « NO-MAIL » ?

une méthode simple pour protéger les domaines qui n'envoient pas d'e-mails contre les abus

Pourquoi les entreprises utilisent-elles les SMS ?

Pourquoi les entreprises utilisent-elles les SMS ?

Comment gérer les e-mails rejetés

Comment gérer les courriels retournés pour éviter d'en subir les conséquences négatives

Comment vérifier si mon serveur SMTP est sécurisé ?

Comment vérifier si mon serveur SMTP est sécurisé ?

Paramètres DNS pour l'envoi d'e-mails

Quels paramètres DNS de domaine sont nécessaires pour envoyer des e-mails ?

comment gérer les listes de diffusion

comment gérer les listes de diffusion avec prévoyance

comment envoyer des newsletters

Comment envoyer des newsletters tout en préservant la qualité de sa liste et l'intérêt de ses destinataires ?

comment envoyer des e-mails privés

Comment envoyer des e-mails privés et chiffrés

Comment envoyer et limiter les e-mails en copie cachée (BCC)

Comment envoyer et limiter les e-mails en copie cachée (Bcc) : avantages, inconvénients et conclusions

mesurer le marketing par e-mail

comment mesurer la performance de vos campagnes de marketing par e-mail

ce qui est considéré comme du SPAM

Quels utilisateurs et serveurs de messagerie sont considérés comme des courriels indésirables ?

Clients de messagerie open source

Comment reprendre le contrôle de sa messagerie grâce à des clients de messagerie open source prêts à l'emploi ?

Courriel professionnel et confidentialité

Courriels des employés : peuvent-ils être lus ? peuvent-ils être sauvegardés ? peuvent-ils être archivés ?

Protéger les courriels contre le spam

Comment protéger ses courriels professionnels contre le spam

Fonctionnement de DMARC - mise à jour

Fonctionnement de DMARC avec Gmail et Office 365 - Mise à jour

Domaine DKIM pour DMARC

Comment l'alignement du domaine DKIM affecte l'authentification DMARC

fournisseurs de messagerie électronique les plus populaires

Quels sont les fournisseurs de messagerie électronique les plus populaires en 2020 ?

Comment fonctionne DMARC

Comment DMARC fonctionne avec Gmail et Office 365

Sous-sections des tendances en matière de courriel

Directives d'authentification des courriels

Logo de l'ACN (Agence nationale de cybersécurité)

ATTENTION !! Ce document a été traduit automatiquement de l'italien

Lignes directrices

Configuration du service de messagerie pour l'authentification

L'Agence nationale italienne de cybersécurité a publié les lignes directrices pour la configuration du service de messagerie électronique en vue de l'authentification, dans le but de renforcer la fiabilité du service de messagerie pour toutes les organisations intéressées et d'accroître son niveau global de sécurité.

Contrôle de version

VERSION DATE DE PUBLICATION NOTES
1.0 Avril 2026 Première publication.

INDICE

1. Introduction 1
1.1. Prémisse 1
1.2. Règlement de référence 1
1.3. Documents de référence 2
2. Contexte réglementaire 3
3. Architecture du service de messagerie électronique 4
4. Menaces 5
4.1. Usurpation d'identité de l'expéditeur 5
4.2. Hameçonnage 6
4.3. Falsification de messages 6
5. Contre-mesures 8
5.1. FPS 8
   5.1.1. Enregistrement SPF 9
   5.1.2. Processus d'authentification 11
5.2. DKIM 11
   5.2.1. Signature DKIM 12
   5.2.2. Enregistrement DKIM 13
   5.2.3. Processus d'authentification 13
   5.2.4. Aspects cryptographiques 14
5.3. DMARC 14
   5.3.1. Enregistrement DMARC 16
   5.3.2. Politiques DMARC 16
   5.3.3. Processus de vérification et d'application des polices d'assurance 17
6. Conclusions 18
Annexe A : Mesures de sécurité 20
Bibliographie 22

1. Introduction

1.1. Prémisse

Le courrier électronique représente aujourd'hui l'un des services les plus essentiels dans le contexte numérique, car il figure parmi les principaux canaux utilisés par les organisations et les utilisateurs pour la communication et l'échange d'informations1.

Le fonctionnement du service de messagerie, et notamment la transmission des messages, repose sur le protocole SMTP qui, cependant, n'intègre pas nativement de mécanismes adéquats pour l'authentification de l'expéditeur et la protection de la confidentialité et de l'intégrité des messages. Ces vulnérabilités l'exposent à des risques d'attaques telles que l'usurpation d'identité, le phishing, la falsification et l'interception des messages en transit.

Pour atténuer les faiblesses du protocole SMTP et ainsi réduire le risque lié aux attaques susmentionnées, des mécanismes d'authentification de l'expéditeur et de protection de l'intégrité des messages ont été développés au fil du temps, tels que SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail) et DMARC (Domain-based Message Authentication, Reporting and Conformance).

Ces lignes directrices illustrent ces mécanismes dans le but de renforcer la fiabilité du service de messagerie électronique et d'accroître son niveau global de sécurité, en particulier en référence aux menaces décrites au chapitre 4.

Les contre-mesures et les protocoles nécessaires à la protection de la confidentialité des messages électroniques (tels que S/MIME et OpenPGP qui concernent le chiffrement des messages) ne font pas l'objet des présentes directives.

1.2. Règlement de référence

RÈGLEMENT DESCRIPTION
Périmètre national de cybersécurité (PSNC) Décret-loi du 21 septembre 2019, n° 105. Dispositions urgentes concernant le périmètre national de cybersécurité et la discipline des pouvoirs spéciaux dans les secteurs d'importance stratégique.
Réglementation du cloud pour l'administration publique Décret directeur ACN n° 21007/24 du 27 juin 2024.
Décret législatif du 4 septembre 2024, n° 138 Décret législatif du 4 septembre 2024, n° 138. Transposition de la directive (UE) 2022/2555 relative aux mesures visant à assurer un niveau élevé et commun de cybersécurité dans l’ensemble de l’Union, modifiant le règlement (UE) n° 910/2014 et la directive (UE) 2018/1972 et abrogeant la directive (UE) 2016/1148.

1.3. Documents de référence

TITRE ET ADRESSE DE PUBLICATION
Note technique n° 1945 du NIST.
https://nvlpubs.nist.gov/nistpubs/TechnicalNotes/NIST.TN.1945.pdf
NIST SP 800-177 R1
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-177r1.pdf
ACN. Cadre d'authentification des courriels.
https://www.acn.gov.it/portale/w/framework-di-autenticazione-per-la-posta-elettronica
RFC 5321 – Protocole de transfert de courrier simple
https://datatracker.ietf.org/doc/html/rfc5321
RFC 5322 – Format des messages Internet
https://datatracker.ietf.org/doc/html/rfc5322
RFC 7208 – Cadre de politique d'expéditeur (SPF) pour l'autorisation d'utilisation des domaines dans les courriels, version 1
https://datatracker.ietf.org/doc/html/rfc7208
RFC 6376 – Signatures de courrier électronique identifiées par DomainKeys (DKIM)
https://datatracker.ietf.org/doc/html/rfc6376
RFC 7489 – Authentification, rapport et conformité des messages basés sur le domaine (DMARC)
https://datatracker.ietf.org/doc/html/rfc7489

» Retour en haut de page

2. Contexte réglementaire

Afin de protéger les actifs numériques du pays, notamment les services de messagerie électronique et les infrastructures qui les hébergent, un large éventail de mesures de sécurité, issues de la législation en vigueur, est en place et fait l'objet de mises à jour constantes.

Le plus haut niveau de protection des services les plus critiques du pays, liés à la protection de la sécurité nationale, est assuré par le Périmètre national de cybersécurité, établi par le décret-loi n° 105 du 21 septembre 2019, modifié par la loi n° 133 du 18 novembre 2019. Ce périmètre prévoit des mesures de sécurité à très haut niveau de protection, détaillées à l'annexe B du décret du Premier ministre n° 81 du 14 avril 2021, qui s'appliquent aux réseaux, systèmes d'information et services informatiques des entités publiques et privées dont dépend l'exercice d'une fonction essentielle de l'État ou la fourniture d'un service essentiel au maintien des activités civiles, sociales ou économiques fondamentales pour les intérêts de l'État, et dont la compromission pourrait porter atteinte à la sécurité nationale.

Par ailleurs, les services de messagerie électronique, comme tous les services numériques de l'administration publique, sont soumis aux dispositions du Règlement sur le cloud, adopté en application de l'article 33-septies du décret-loi n° 179 du 18 octobre 2012 et mis à jour par l'Agence nationale de la cybersécurité (ACN) par le décret directeur n° 21007 du 27 juin 2024. Conformément à ce Règlement, toutes les administrations publiques sont tenues de classer leurs données et services numériques en trois catégories : ordinaires, critiques ou stratégiques, selon le modèle établi par l'ACN. Cette démarche vise à garantir que les données et services numériques de l'administration publique soient traités et fournis via des infrastructures numériques et des services cloud conformes aux exigences, notamment de sécurité, adaptées aux risques liés au niveau de classification correspondant, tel que défini par le Règlement.

Le décret législatif du 4 septembre 2024, n° 138 (dit décret NIS) transposant la directive (UE) 2022/2555 a également établi – par le biais des annexes 1 et 2 de la décision ACN 379907/2025 – les mesures de sécurité de base que les entités essentielles et importantes doivent adopter aux fins des obligations prévues aux articles 23 et 24 du décret NIS, définissant un cadre de sécurité pour renforcer la protection des réseaux et des systèmes d’information, y compris les services de messagerie électronique.

» Retour en haut de page

3. Architecture du service de messagerie électronique

Comme indiqué dans le préambule, le fonctionnement du service de messagerie électronique repose sur le protocole SMTP qui régule la transmission des messages électroniques de l'expéditeur au destinataire.

Le protocole SMTP a été initialement défini en 1982comme un protocole de stockage et de retransmission. L'expéditeur génère un message via son client de messagerie (également appelé agent utilisateur de messagerie ou MUA), qui l'envoie au serveur de messagerie de l'expéditeur. Ce dernier, par l'intermédiaire d'un composant appelé agent de transfert de messagerie (MTA), transmet le message, éventuellement via un ou plusieurs MTA intermédiaires, pour le livrer au MTA du serveur de messagerie de destination. Le destinataire accède ensuite au message via son client de messagerie (MUA)[1].

Le MTA est donc un composant du service de messagerie qui gère la transmission des messages électroniques de l'expéditeur au destinataire. Les composants MTA sont présents sur les serveurs de messagerie de l'expéditeur et du destinataire, et des MTA intermédiaires peuvent également être configurés, par exemple pour gérer les listes de distribution.

Diagramme illustrant l'architecture générale du service de messagerie électronique

Figure 1. Architecture générale du service de messagerie.
Cette figure ne représente que les composants pertinents pour les présentes recommandations.

Bien que le terme MTA désigne un composant spécifique des serveurs de messagerie3, étant donné que, dans le cadre de ce document, on se réfère principalement à ces derniers dans leur fonction de MTA, là où il n'y a pas d'ambiguïté, par souci de simplicité, le terme serveur de messagerie sera souvent utilisé à la place du terme plus spécifique MTA.

Ce guide porte sur la configuration des protocoles SPF, DKIM et DMARC afin de permettre aux serveurs de messagerie de vérifier l'authenticité et l'intégrité des messages électroniques.

» Retour en haut de page

4. Menaces

Le protocole SMTP présenté au chapitre précédent a été initialement conçu pour fonctionner au sein d'un réseau académique relativement restreint et ne prenait pas en compte les aspects liés à la sécurité des messages transmis ni à l'authentification de l'expéditeur [1].

La diffusion croissante du courrier électronique et les faiblesses intrinsèques du protocole SMTP ont favorisé, au fil du temps, l'émergence d'attaques dont les principaux types sont brièvement illustrés dans les paragraphes suivants.

4.1. Usurpation d'identité de l'expéditeur

L'usurpation d'identité est une technique de cyberattaque utilisée pour falsifier l'adresse de l'expéditeur d'un message et faire croire que ce dernier provient d'une adresse fiable (comme celle d'un collègue, d'une connaissance ou de sa propre banque), incitant ainsi le destinataire à effectuer des actions potentiellement dangereuses, comme ouvrir une pièce jointe ou cliquer sur des liens contenus dans le message.

Ce type d'attaque est relativement simple à réaliser, car le protocole SMTP ne comprend pas de mécanismes d'authentification de l'expéditeur et, par conséquent, il est possible, via le client de messagerie, de configurer n'importe quelle adresse d'expéditeur lors de l'envoi du message.

Adresse e-mail de l'expéditeur : envelope-from et message-from

Le format des messages électroniques prévoit deux champs distincts pour indiquer l'adresse électronique de l'expéditeur. Ces champs sont nommés envelope-from et message-from : le premier (également appelé chemin de retour car il spécifie l'adresse électronique à laquelle doivent être envoyés les messages d'erreur générés lorsqu'un message n'atteint pas son destinataire) est l'adresse utilisée pour acheminer correctement le message ; le second est l'adresse affichée par le destinataire dans l'en-tête du message reçu.

Par analogie avec l'envoi d'une lettre sous enveloppe par voie postale traditionnelle, l' de l'expéditeur figurant sur l'enveloppe de la lettre correspond à l'en-tête de la lettre indiquant qui a écrit au destinataire.

Il est important de noter que les deux adresses peuvent ne pas correspondre. Cette distinction permet de gérer des situations telles que, par exemple, le transfert de messages provenant de services tiers, la distribution via des listes de diffusion ou les réponses automatiques par courriel.

Il est en effet possible d'indiquer n'importe quel expéditeur à la fois au de l'expéditeur du message (adresse électronique de l'expéditeur affichée par le destinataire dans l'en-tête du message reçu) et au niveau de l'expéditeur de l'enveloppe (adresse électronique de l'expéditeur utilisée pour la transmission du message).

Pour contrer ces menaces, il est donc essentiel de mettre en place des mécanismes permettant d'authentifier de manière fiable l'expéditeur et de vérifier que la personne qui a envoyé le message est effectivement autorisée à le faire.

4.2. Hameçonnage

L’hameçonnage est une technique de cyberattaque visant à l’acquisition frauduleuse d’informations (telles que, par exemple, des identifiants de connexion, des numéros de carte de crédit ou d’autres données sensibles), généralement en envoyant des messages trompeurs qui simulent une origine provenant d’expéditeurs fiables3.

L’usurpation d’identité, examinée dans le paragraphe précédent, est l’une des principales techniques utilisées par un attaquant pour falsifier l’identité de l’expéditeur et faire croire que le message provient d’un utilisateur ou d’un domaine légitime.

Alternativement, une adresse/un domaine d'expéditeur similaire à celui que le destinataire peut reconnaître peut être utilisé, en modifiant, par exemple, le nom d'affichage4 afin de renforcer l'authenticité apparente du message.

Pour envoyer des messages d'hameçonnage, il est également possible d'utiliser des comptes légitimes préalablement compromis par l'attaquant.

Un message d'hameçonnage contient généralement un contenu conçu pour générer un sentiment d'urgence, d'inquiétude ou d'intérêt économique chez le destinataire, créant ainsi des situations qui l'incitent à réagir impulsivement et à effectuer des actions spécifiques telles que l'ouverture de pièces jointes malveillantes ou le clic sur des liens qui redirigent vers des sites Web apparemment légitimes, mais qui ont en réalité été créés par l'attaquant dans le but de voler des informations et/ou d'installer des logiciels malveillants.

Les attaques de phishing consistent généralement à envoyer le même message électronique à un grand nombre de victimes, sans adapter le texte au profil spécifique de chacune.

Une variante du phishing est ce qu'on appelle le spear phishing, dans lequel l'attaquant connaît et cible spécifiquement le profil de la victime.

Contrairement à un courriel d'hameçonnage générique, un message d'hameçonnage ciblé utilise des informations contextuelles plus précises pour convaincre l'utilisateur qu'il interagit avec un expéditeur fiable [2].

4.3. Falsification de messages

Le contenu d'un message électronique, comme toute autre communication transitant sur le réseau Internet qui n'utilise pas de techniques de chiffrement de bout en bout (E2EE), peut être intercepté et modifié pendant son transit entre l'expéditeur et le destinataire (un type de menace communément appelé attaque de l'homme du milieu).

Par conséquent, outre la perte de confidentialité, le message reçu pourrait ne pas correspondre à celui initialement rédigé par l'expéditeur.

Un attaquant pourrait, par exemple, manipuler le contenu du message pour lui faire croire qu'il provient d'un expéditeur fiable, modifier le texte ou les liens et/ou pièces jointes présents dans le message, ou encore insérer un code malveillant.

Le destinataire, se fiant à l'authenticité apparente du message, peut ainsi être amené à effectuer des actions potentiellement nuisibles, telles que la communication d'identifiants de connexion, l'autorisation de paiements ou l'ouverture de fichiers malveillants.

Pour contrer ces menaces, il est donc essentiel d'adopter des mécanismes garantissant l'intégrité et l'authenticité du message, en s'assurant que le contenu reçu n'a pas été modifié et que l'expéditeur est bien celui qu'il prétend être.

» Retour en haut de page

5. Contre-mesures

Le chapitre 2 a rappelé la réglementation relative aux mesures de sécurité applicables à la protection des services de messagerie électronique. Le présent document vise principalement à fournir un guide pour la mise en œuvre des mesures de sécurité prévues par cette réglementation et présentées à l'annexe A, qui concernent également la configuration des services de messagerie électronique, afin d'atténuer les risques liés aux menaces abordées au chapitre 4.Il convient toutefois de noter que les indications contenues dans ces lignes directrices s'adressent également aux personnes non soumises à la réglementation susmentionnée.

Les mesures de sécurité en question ne concernent pas explicitement la configuration du service de messagerie, mais – selon la réglementation applicable – la configuration des systèmes informatiques et des systèmes de contrôle industriel (PSNC et réglementation sur le cloud) ou des systèmes d'information et de réseau (NIS2). Les services de messagerie visés par ces lignes directrices relèvent de ces deux types de systèmes.

En particulier, les SPF, DKIMet DMARC sont illustrés ci-dessous ; ils fournissent des mécanismes de sécurité conçus dans le but de renforcer la sécurité globale du service de messagerie électronique et notamment l’authentification de l’expéditeur et le contrôle de l’intégrité des messages.

5.1. FPS

SPF – Sender Policy Framework est un protocole d'authentification, formalisé par la RFC 7208, qui permet à un propriétaire de domaine de spécifier quelles adresses IP sont autorisées à envoyer des messages électroniques en son nom et d'établir les politiques que le destinataire doit appliquer si l'adresse IP associée au domaine5 de l'adresse électronique de l'expéditeur ne figure pas parmi celles explicitement autorisées.

Les adresses IP autorisées sont répertoriées dans un enregistrement DNS TXT relatif au domaine de l'expéditeur, appelé enregistrement SPF et illustré dans la section suivante de ce paragraphe.

De cette manière, le serveur de messagerie du destinataire6, lorsqu'il reçoit un message d'un domaine donné, peut interroger l'enregistrement SPF correspondant et authentifier son origine en vérifiant que l'adresse IP à partir de laquelle le message a été reçu figure parmi celles autorisées à envoyer des messages au nom du domaine.

Il est important de noter que le domaine vérifié au niveau SPF est celui de l'expéditeur (enveloppe). Par conséquent, l'adoption du protocole SPF seul ne suffit pas à contrer l'usurpation d'identité, car ce type d'attaque peut être mené au niveau de l'expéditeur (message)7.

Si une organisation externalise, en tout ou en partie, son service de messagerie auprès d'un tiers, tel qu'un fournisseur de services cloud, elle doit s'assurer que les messages envoyés par ce fournisseur passent les contrôles SPF. À cette fin, l'organisation doit inclure dans son enregistrement SPF les adresses IP à partir desquelles les fournisseurs envoient des courriels au nom de son domaine.

Dans le cas du transfert automatique de courriels, les messages étant généralement redirigés par un serveur intermédiaire, l'adresse IP effectuant la livraison finale ne correspond plus à celle initialement autorisée par le domaine de l'expéditeur. Dans ce cas, afin d'éviter l'échec de la vérification SPF, il est nécessaire d'autoriser également les serveurs de transfert intermédiaires, ou de recourir à des mécanismes tels que SRS (Sender Rewriting Scheme) ou ARC (Authenticated Received Chain), qui peuvent s'avérer plus efficaces, notamment en présence de nombreux serveurs de transfert intermédiaires.

Il convient de souligner que, pour que le protocole SPF soit véritablement efficace, il doit être correctement configuré non seulement par l'expéditeur, mais aussi par le destinataire. En particulier :

  • L' expéditeur doit publier l'enregistrement SPF sur le serveur DNS concerné déclarant les adresses autorisées à envoyer des courriels en son nom ;
  • Le destinataire doit configurer son propre serveur de messagerie afin qu'il exécute la vérification SPF sur les messages reçus et applique de manière cohérente les politiques qui en résultent.
5.1.1. Enregistrement SPF

Un enregistrement SPF est un enregistrement DNS de type TXT dont le nom correspond au domaine de l'expéditeur et dont le contenu est constitué8 par la section indiquant la version9 et une série de directives qui indiquent le comportement du serveur de messagerie du destinataire lorsqu'il y a correspondance entre l'adresse IP du domaine de l'expéditeur et une directive.

Les directives sont formées par un mécanisme précédé d'un qualificateur. Les principaux mécanismes utilisés dans les enregistrements SPF sont : [2]:

  • ip4, liste les adresses IPv4 autorisées ;
  • ip6, liste les adresses IPv6 autorisées ;
  • a, autorise les adresses IP présentes dans l'enregistrement A du domaine ;
  • mx, autorise les adresses IP liées aux enregistrements MX du domaine ;
  • include, autorise les adresses IP présentes dans l'enregistrement SPF d'un autre domaine ;
  • « all» représente toutes les adresses IP qui n'ont pas été explicitement autorisées par d'autres mécanismes.

En particulier, le « all » permet d'établir des politiques pour les messages provenant d'adresses IP qui n'ont pas été déclarées par les mécanismes précédents.

De plus, SPF fournit les qualificateurs suivants à associer aux mécanismes :

  • + (pass) indique que les adresses IP correspondant au mécanisme associé sont autorisées. Il s'agit du qualificateur par défaut si aucun autre n'est spécifié ;
  • - (échec) indique que les adresses IP correspondant au mécanisme associé ne sont pas autorisées ;
  • ~ (softfail) indique que les adresses IP correspondant au mécanisme associé ne sont probablement pas autorisées. Cette déclaration est plus incertaine que la précédente. Dans ces cas, le message doit être accepté mais marqué pour une analyse plus approfondie ; il est utilisé par exemple dans les cas de débogage ou lorsqu'il est prévu que la vérification SPF pourrait échouer ;
  • ? (Neutre) indique qu'aucune indication n'est donnée pour les adresses IP correspondant au mécanisme associé. Le comportement par défaut consiste à accepter le message.

Il est important de souligner qu'en pratique, l'enregistrement SPF est composé de manière à spécifier les adresses IP autorisées, puis à utiliser la directive `-all` pour indiquer que toutes les autres adresses ne sont pas autorisées (voir les exemples ci-dessous). Cette configuration est recommandée car elle permet d'indiquer explicitement les adresses IP autorisées et d'exclure toutes les autres.

En tout cas, il est recommandé de ne jamais utiliser la directive +all (ou son équivalent all) car elle correspondrait à l'autorisation de toutes les adresses IP.

Exemples d'enregistrements SPF

Autoriser une adresse IP spécifique

v=spf1 ip4:203.0.113.0 -all

L'enregistrement SPF ci-dessus utilise la version 1 et autorise l'adresse IP 203.0.113.0 via le mécanisme ip4 (en réalité, aucun qualificateur n'étant spécifié pour ce mécanisme , le qualificateur par défaut « + » est utilisé implicitement). La directive « -all » , formée par le mécanisme « all » et le qualificateur « - » (échec), indique que toutes les autres adresses ne sont pas autorisées.

Autoriser un espace d'adressage IP spécifique

v=spf1 ip4:203.0.113.0/24 -all

L'enregistrement SPF présenté ci-dessus est analogue au précédent, mais autorise toutes les adresses IP de l' 203.0.113.0/24 .

Autoriser plusieurs adresses IP

v=spf1 ip4:203.0.113.22 ip4:203.0.113.44 -tous

L'enregistrement SPF indiqué ci-dessus autorise exclusivement les adresses IPv4 203.0.113.22 et 203.0.113.44.

Autoriser les adresses d'enregistrement MX et un domaine spécifique

v=spf1 mx include:spf.emailprovider.it -all

L'enregistrement SPF présenté ci-dessus autorise exclusivement les adresses IP des enregistrements MX du même domaine que l'enregistrement SPF et celles autorisées du domaine spf.emailprovider.it (par exemple, le domaine d'un fournisseur de services de messagerie).

5.1.2. Processus d'authentification

Si la vérification SPF est correctement configurée, le serveur de messagerie du destinataire, à la réception d'un nouveau message, récupère l'enregistrement SPF du domaine de l'expéditeur en interrogeant le serveur DNS qui contient les enregistrements de ce domaine, à partir de l'adresse indiquée dans le champ « De ». Par exemple, si l'adresse indiquée dans le champ « De » est alice@example.com, le serveur de messagerie du destinataire récupère l'enregistrement SPF du domaine example.com.

Diagramme illustrant le processus de vérification SPF

Figure 2. Mécanisme de fonctionnement de la vérification SPF.

Le serveur de messagerie du destinataire effectue ensuite la vérification SPF, en analysant l'enregistrement SPF pour déterminer si l'adresse IP d'où provient le message est autorisée à envoyer des courriels pour le example.com . Si le message est validé par la vérification SPF, il est remis au destinataire.

Par exemple, si l'enregistrement SPF du domaine example.com était v=spf1 ip4:203.0.113.22 -all, la vérification ne réussirait que si l'adresse IP du serveur expéditeur était 203.0.113.22 , tandis qu'elle échouerait pour toute autre adresse.

» Retour en haut de page

5.2. DKIM

DKIM – DomainKeys Identified Mail est un protocole d'authentification, formalisé par la RFC 6376, qui permet à un propriétaire de domaine de garantir l'authenticité des messages électroniques envoyés en apposant une signature numérique (signature DKIM) générée par le serveur de messagerie via des algorithmes de cryptographie publics et insérée dans les en-têtes du message à transmettre.

Pour permettre au destinataire de vérifier que le message n'a pas été modifié pendant la transmission, la clé publique associée à la signature DKIM est conservée dans un enregistrement TXT du DNS public du domaine de l'expéditeur, appelé enregistrement DKIM, qui est interrogé par le serveur de messagerie du destinataire lors de la réception du message.

La signature et l'enregistrement DKIM sont illustrés dans les sections suivantes de ce paragraphe.

Comme pour SPF, DKIM doit également être correctement configuré par l'expéditeur et le destinataire, et en particulier :

  • L'expéditeur doit configurer son serveur de messagerie pour générer des signatures DKIM et publier l'enregistrement DKIM sur le serveur DNS correspondant ;
  • Le destinataire doit configurer son serveur de messagerie afin qu'il effectue une vérification DKIM sur les messages reçus.
5.2.1. Signature DKIM

La signature DKIM est générée à partir d'éléments désignés du corps et des en-têtes du message et se compose d'une série de paires clé-valeur qui spécifient des éléments parmi lesquels :

  • v: version du protocole10;
  • a: algorithme de chiffrement utilisé11;
  • d: domaine de signature déclarant l'authenticité du message12;
  • s: sélecteur indiquant quelle clé publique DKIM rechercher dans l'enregistrement DNS13;
  • h: liste des en-têtes d'e-mail inclus dans la signature14;
  • bh: hachage du corps du message encodé au format base6415;
  • b: signature numérique réelle générée avec la clé privée et encodée au format base6416;
  • x: date de validité de la signature ;
  • c: type de canonisation.

La canonisation est le processus de normalisation des éléments d'un message avant sa signature numérique, afin de réduire l'impact des petites modifications pouvant survenir lors de sa transmission, telles que les espaces ou les sauts de ligne répétés. Il existe deux types de canonisation : la canonisation simple, qui exige une correspondance exacte entre le message original et le message reçu, et assouplie, qui applique des normalisations comme la suppression des espaces, la conversion des majuscules en minuscules dans les en-têtes et la réduction du nombre de lignes vides consécutives dans le corps du message.

5.2.2. Enregistrement DKIM

L'enregistrement DKIM est stocké dans un enregistrement DNS de type TXT dont le nom suit la structure selector._domainkey.domain, où _domainkey est une étiquette indiquant qu'il s'agit bien d'un enregistrement DKIM. Le contenu de l'enregistrement DKIM est constitué d'une série de paires clé-valeur spécifiant des éléments parmi lesquels :

  • v: version du protocole ;
  • k: type de clé, qui par défaut est RSA ;
  • p: clé publique encodée au format base64.
Exemple d'enregistrement DKIM

Nom : s1._domainkey.example.com
Valeur : v=DKIM1 ; k=rsa ; p=Y2hpYXZ1cHViYmxpY2FkaWVzZW1waW8h...

L'enregistrement DKIM d'exemple est associé au sélecteur s1 du example.com , utilise la version 1 et contient la clé publique RSA encodée au format base64 (Y2hpYXZ1cHViYmxpY2FkaWVzZW1waW8h...).

5.2.3. Processus d'authentification

Si le protocole DKIM est correctement configuré sur les serveurs de messagerie de l'expéditeur et du destinataire, le processus d'authentification et de vérification DKIM prévoit que le serveur de messagerie de l'expéditeur crée la signature DKIM du message, comme décrit au paragraphe 5.2.1, et l'ajoute au message lui-même. Plus précisément, la signature DKIM contient dans le champ « d » le domaine de signature et dans le champ « b » la signature numérique du message, générée avec la clé privée de ce domaine.

Diagramme illustrant le mécanisme de vérification DKIM

Figure 3. Mécanisme de fonctionnement de la vérification DKIM.

À la réception d'un message, le serveur de messagerie du destinataire récupère l'enregistrement DKIM du domaine signataire (d de la signature DKIM) auprès du serveur DNS contenant les enregistrements de ce domaine. Il utilise ensuite la clé publique contenue dans l'enregistrement DKIM pour vérifier la signature numérique (b ) de la signature DKIM. Si la vérification est concluante, le message est remis au destinataire.

5.2.4. Aspects cryptographiques

Sur le plan cryptographique, DKIM a historiquement utilisé l' algorithme RSA , en particulier dans la variante rsa-sha256 , considérée comme la norme depuis 2007. La nouvelle alternative, introduite par la RFC 8463 , est Ed25519-SHA256 , une forme moderne de signature numérique basée sur des courbes elliptiques qui garantit une plus grande efficacité et des clés beaucoup plus compactes.

Sur le plan technique, RSA, avec une longueur de clé de 2048 bits, demeure la norme universelle, mais les clés sont longues et les signatures relativement volumineuses. Ed25519, quant à lui, offre des clés neuf fois plus courtes et des signatures quatre fois plus petites, avec des performances de signature jusqu'à trente fois supérieures à celles de RSA 2048. Malgré ces avantages, son adoption en production reste limitée : en 2026, Ed25519 n'est vérifié que par quelques fournisseurs, tandis que certains opérateurs majeurs ne prennent pas en charge de manière fiable la signature ni la vérification, ce qui le rend inadapté comme solution unique en production.

Pour cette raison, malgré sa supériorité technique, l'utilisation d' Ed25519 n'est pas recommandée , au moment de la rédaction du présent document, sauf en combinaison avec RSA , via une double signature , à titre expérimental et comme mesure de compatibilité future. Tant que les principaux fournisseurs n'auront pas pleinement mis en œuvre sa vérification, RSA demeure essentiel pour garantir une fiabilité maximale de la livraison des messages.

En ce qui concerne la sécurité à long terme, il est important de rappeler que ni RSA ni Ed25519 ne sont résistants aux attaques des futurs ordinateurs quantiques [3], et la transition vers des algorithmes post-quantiques nécessitera de nouvelles normes DKIM qui n'existent pas actuellement, ce qui rend essentiel de surveiller les développements de la cryptographie de nouvelle génération et les futures recommandations de l'ACN dans ce domaine.

En ce qui concerne la gestion des clés cryptographiques, la clé privée DKIM doit être protégée par des mesures de sécurité rigoureuses, en la conservant sur des systèmes isolés accessibles uniquement aux services autorisés, en adoptant des permissions restrictives, une rotation périodique et une surveillance constante pour empêcher tout accès non autorisé ou toute compromission.

» Retour en haut de page

5.3. DMARC

DMARC – Domain-based Message Authentication, Reporting and Conformance est un protocole d'authentification, formalisé par la RFC 7489, qui intègreles mécanismes SPF et DKIM permettant à un propriétaire de domaine de spécifier, aux destinataires des messages transmis à partir de ce domaine, les politiques de gestion des messages qui échouent aux vérifications SPF et DKIM.

Plus précisément, DMARC introduit un mécanisme d'authentification, appelé alignement, qui vérifie la correspondance entre les domaines authentifiés par SPF et DKIM et le domaine associé au « de » du message reçu. Il est important de noter que la vérification d'alignement entre le « de » et le domaine SPF/DKIM échoue systématiquement si la vérification SPF/DKIM correspondante échoue (voir figure 4).

Diagramme illustrant le mécanisme de vérification DMARC

Figure 4. Mécanisme de vérification DMARC.

L'alignement peut être vérifié en strict , où une correspondance exacte est requise entre les domaines authentifiés par SPF/DKIM et celui relatif au message-from , ou en mode souple, où il suffit que les domaines principaux correspondent, même si les sous-domaines peuvent être différents.

Par exemple, en permissif , pour les domaines sub1.example.com et sub2.example.com, un alignement serait trouvé à des fins de vérification DMARC (puisque le domaine principal, example.com, est identique). En strict , en revanche, la vérification d'alignement DMARC échouerait en raison de l'absence de correspondance exacte entre les domaines.

Grâce à la vérification d'alignement, même si un attaquant réussissait à passer les contrôles SPF et/ou DKIM en utilisant un message provenant d'une enveloppe différente de celle authentifiée par SPF et/ou du domaine de signature authentifié, DMARC détecterait toujours la divergence, assurant une vérification cohérente et fiable de l'identité de l'expéditeur [2] .

Les politiques de gestion des messages qui échouent19 sont spécifiées dans un enregistrement TXT du serveur DNS relatif du domaine de l'expéditeur appelé enregistrement DMARC et illustrées dans la section suivante de ce paragraphe.

DMARC permet également d'indiquer aux destinataires d'envoyer des rapports aux propriétaires des domaines expéditeurs concernant les messages prétendant provenir de ce domaine. Ainsi, le propriétaire du domaine peut vérifier si son domaine est utilisé de manière non autorisée et dans quelle mesure, en analysant, par exemple, le nombre de messages qui lui sont effectivement attribués parmi l'ensemble des messages revendiquant son origine.

Comme pour SPF et DKIM, DMARC doit également être correctement configuré par l'expéditeur et le destinataire, et en particulier :

  • l'expéditeur doit publier l'enregistrement DMARC dans son DNS spécifiant les politiques selon lesquelles gérer les messages ne passant pas la vérification DMARC ;
  • Le destinataire doit configurer son serveur de messagerie pour exécuter la vérification DMARC sur les messages reçus.
5.3.1. Enregistrement DMARC

Le nom de l'enregistrement DMARC a la structure _dmarc.domaine, où _dmarc est une étiquette utilisée pour indiquer que l'enregistrement DNS est un enregistrement DMARC et domaine est le domaine auquel la politique fait référence.

L'enregistrement DMARC se compose d'une série de paires clé-valeur spécifiant des éléments parmi lesquels :

  • v: Protocole DMARC version20;
  • p: politique à appliquer aux messages échouant à la vérification DMARC, peut prendre l'une des valeurs suivantes : aucune, quarantaine, rejet;
  • aspf: mode d'alignement à appliquer à la vérification SPF (peut être relâché, valeur par défaut ou strict) ;
  • adkim: mode d'alignement à appliquer à la vérification DKIM (peut être relâché, valeur par défaut ou strict) ;
  • rua: adresses électroniques auxquelles envoyer des rapports agrégés contenant des informations statistiques et récapitulatives sur les messages reçus du domaine de l'expéditeur ;
  • ruf: adresses e-mail auxquelles envoyer des rapports détaillés sur les messages individuels reçus du domaine de l'expéditeur qui ont échoué à la vérification DMARC.
Exemple d'enregistrement DMARC

Nom :
_dmarc.example.com
Valeur :
v=DMARC1 ; p=reject ; rua=mailto:dmarc-reports@example.com ; ruf=mailto:dmarc-fail@example.com ; adkim=s ; aspf=s

L'enregistrement DMARC d'exemple est associé au domaine example.com , utilise la version 1 et spécifie la politique de rejet des messages échouant à la vérification DMARC, demandant le mode strict pour la vérification de l'alignement des domaines SPF et DKIM et pour transmettre des rapports agrégés à l'adresse électronique dmarc-reports@example.com et des rapports d'échec à l'adresse dmarc-fail@example.com .

5.3.2. Politiques DMARC

Comme indiqué dans le paragraphe précédent, l'enregistrement DMARC indique la politique que le serveur de messagerie du destinataire doit appliquer aux messages qui ne réussissent pas la vérification DMARC. Les politiques possibles sont les suivantes :

  • aucun: le domaine de l'expéditeur ne donne aucune indication concernant la livraison des messages dont la vérification DMARC a échoué ;
  • mise en quarantaine: le domaine de l'expéditeur indique que les messages ne passant pas la vérification DMARC doivent être considérés comme suspects (par exemple, soumis à un examen plus approfondi, traités comme spam ou étiquetés comme suspects) ;
  • rejeter: le domaine de l'expéditeur indique que les messages ne passant pas la vérification DMARC doivent être rejetés.
5.3.3. Processus de vérification et d'application des polices d'assurance

Si le protocole DMARC est correctement configuré sur les serveurs de messagerie de l'expéditeur et du destinataire, à la réception du message, le serveur de messagerie du destinataire récupère les enregistrements SPF et DKIM pour effectuer les vérifications correspondantes, ainsi que l'enregistrement DMARC (détaillé au début du paragraphe 5.2.4). Si le message échoue à la vérification DMARC, la politique indiquée dans l'enregistrement DMARC (aucune, mise en quarantaine ou rejet) est appliquée.

Diagramme illustrant le processus de vérification DMARC et d'application des polices d'assurance

Figure 5. Processus de vérification et d'application des politiques DMARC.

Il convient de noter que chaque serveur de messagerie peut adopter des heuristiques et des politiques locales pour déterminer la distribution ou non d'un message, en tenant compte également du résultat des vérifications SPF, DKIM et DMARC. Par conséquent, un processus de décision supplémentaire (« Filtre standard » dans la figure 5) intervient généralement en aval des vérifications susmentionnées et peut inclure des contrôles complémentaires (tels que des filtres anti-spam et anti-malware).

De plus, le serveur de messagerie du destinataire peut transmettre :

  • aux adresses indiquées dans le rua de l'enregistrement DMARC, des rapports agrégés contenant des informations statistiques et récapitulatives sur les messages reçus du domaine de l'expéditeur ;
  • aux adresses indiquées dans le ruf de l'enregistrement DMARC, des rapports détaillés sur les messages individuels reçus du domaine de l'expéditeur qui n'ont pas passé la vérification DMARC.

» Retour en haut de page

6. Conclusions

Comme indiqué dans le chapitre précédent, afin de contrer au mieux les menaces liées à l'usurpation d'identité du domaine de l'expéditeur, il est nécessaire que les trois protocoles examinés soient mis en œuvre conjointement et, en particulier, que [3]:

  • le domaine de l'expéditeur publie correctement les enregistrements SPF, DKIM et DMARC dans le DNS ;
  • Le serveur de messagerie de l'expéditeur est configuré pour signer les messages avec DKIM ;
  • Le serveur de messagerie du destinataire est configuré pour effectuer les vérifications SPF et DKIM et appliquer les politiques DMARC.

En ce qui concerne la mise en œuvre du protocole, les recommandations suivantes sont également formulées [2]:

  • Configurez le SPF en spécifiant quelles adresses IP sont autorisées à envoyer des e-mails au nom du domaine ; pour les domaines non utilisés pour la transmission d’e-mails, par exemple ceux destinés exclusivement aux sites Web, un enregistrement SPF doit tout de même être créé pour indiquer explicitement qu’il n’existe aucun expéditeur d’e-mails valide pour ce domaine ;
  • utiliser des protocoles et algorithmes de chiffrement de pointe considérés comme sûrs pour les clés DKIM ; à la date de rédaction de ce document, le RSA 2048 bits est recommandé ;
  • protéger adéquatement la clé privée DKIM stockée sur le serveur de messagerie, en adoptant des autorisations d'accès restrictives, et s'assurer que seul le logiciel du serveur de messagerie dispose de privilèges de lecture sur la clé ;
  • configurer chaque serveur de messagerie avec une paire de clés et un sélecteur uniques, afin de réduire l'impact d'une éventuelle compromission de clé privée ;
  • protéger la clé privée contre toute divulgation accidentelle et contre les tentatives d'accès ou de modification par un attaquant ;
  • veiller à ce que les logiciels relatifs aux listes de diffusion vérifient les signatures DKIM sur les messages entrants et apposent de nouvelles signatures DKIM sur les messages sortants ;
  • utiliser des paires de clés DKIM uniques pour chaque tiers envoyant des courriels au nom de l'organisation ;
  • faire tourner périodiquement les paires de clés DKIM (au moins tous les six mois) afin d'atténuer l'impact d'une éventuelle compromission ;
  • révoquer immédiatement les clés en cas de suspicion de compromission ;
  • Surveillez les rapports DMARC pour identifier toute erreur de configuration ou tentative d'abus.

Pour plus de détails, veuillez vous référer aux ressources énumérées dans les documents de référence.

Il est à noter que, pour assurer une protection adéquate de la sécurité des courriels, outre les protocoles d'authentification examinés ici, il existe d'autres protocoles – qui ne font pas l'objet de ces directives – tels que, par exemple, TLS – Transport Layer Security qui garantit le chiffrement du canal de transmission et SMIME et OpenPGP qui concernent le chiffrement de bout en bout et l'authentification des messages.

Il est également à noter que, bien qu'il ne s'agisse pas d'un protocole de sécurité de messagerie au sens strict, la mise en œuvre de DNSSEC (Domain Name System Security Extensions) est recommandée pour la sécurité des services de messagerie. DNSSEC ajoute des signatures cryptographiques aux enregistrements DNS afin de garantir l'intégrité et l'authenticité des requêtes DNS. Grâce à DNSSEC, par exemple, les informations relatives aux enregistrements SPF, DKIM et DMARC sont protégées lors de leur transmission, réduisant ainsi le risque d'altération et renforçant la sécurité des services de messagerie.

» Retour en haut de page

Annexe A : Mesures de sécurité

Périmètre national de cybersécurité (PSNC)

PR.IP-1 : Des pratiques de référence (appelées bases de référence) sont définies et gérées pour la configuration des systèmes informatiques et des systèmes de contrôle industriels qui intègrent des principes de sécurité (par exemple, le principe de moindre fonctionnalité).

  1. Il existe un document détaillé et mis à jour indiquant, également en ce qui concerne la catégorie ID.AM, au moins :
    • a) les politiques de sécurité adoptées pour le développement des configurations des systèmes informatiques et de contrôle industriel et le déploiement des seules configurations adoptées ;
    • b) la liste des configurations des systèmes informatiques et de contrôle industriel utilisées et la référence aux pratiques de référence relatives ;
    • c) les processus, méthodologies et technologies utilisés qui contribuent au respect des politiques de sécurité.

Réglementation du cloud – Infrastructures et services numériques pour l’administration publique

PR.IP-01 : Des pratiques de référence (appelées bases de référence) sont définies et gérées pour la configuration des systèmes informatiques et des systèmes de contrôle industriels qui intègrent des principes de sécurité (par exemple, le principe de moindre fonctionnalité).

  1. Des politiques et des procédures sont définies en référence à la sécurité des applications afin de fournir un soutien adéquat pour la planification, la mise en œuvre et le maintien des fonctionnalités de sécurité des applications, lesquelles doivent être revues et mises à jour au moins une fois par an.
  2. Il existe un document détaillé et mis à jour indiquant, également en ce qui concerne la catégorie ID.AM, au moins :
    • a) les politiques de sécurité adoptées pour le développement des configurations des systèmes informatiques et de contrôle industriel et le déploiement des seules configurations adoptées ;
    • b) la liste des configurations des systèmes informatiques et de contrôle industriel utilisées et la référence aux pratiques de référence relatives ;
    • c) les processus, méthodologies et technologies utilisés qui contribuent au respect des politiques de sécurité.
  3. Les exigences de base en matière de sécurité des différentes applications sont définies et documentées.
  4. Des indicateurs techniques, utiles pour surveiller le niveau de respect des exigences de sécurité et des obligations de conformité définies, sont définis et mis en œuvre.
  5. Il existe un processus d'atténuation et de récupération des vulnérabilités des applications pour la sécurité des applications, automatisant la correction lorsque cela est possible.
  6. Il existe une procédure pour valider la compatibilité des appareils avec les systèmes d'exploitation et les applications.
  7. Il existe un système de gestion des variations en termes de système d'exploitation, de correctifs et/ou d'applications.
Réglementation du cloud – Services cloud pour l’administration publique

PR.IP-01 : Des pratiques de référence (appelées bases de référence) sont définies et gérées pour la configuration des systèmes informatiques et des systèmes de contrôle industriels qui intègrent des principes de sécurité (par exemple, le principe de moindre fonctionnalité).

  1. Les politiques et les procédures sont définies en référence à la sécurité des applications afin de fournir un soutien adéquat pour la planification, la réalisation et le maintien des fonctionnalités de sécurité des applications, qui doivent être revues et mises à jour au moins une fois par an [IaaS, SaaS].
  2. Il existe un document détaillé et mis à jour indiquant, également en ce qui concerne la catégorie ID.AM, au moins :
    • a) les politiques de sécurité adoptées pour le développement des configurations des systèmes informatiques et de contrôle industriel et le déploiement des seules configurations adoptées ;
    • b) la liste des configurations des systèmes informatiques et de contrôle industriel utilisées et la référence aux pratiques de référence relatives ;
    • c) les processus, méthodologies et technologies utilisés qui contribuent à la conformité aux politiques de sécurité [SaaS].
  3. Les exigences de base en matière de sécurité des différentes applications sont définies et documentées.
  4. Des indicateurs techniques, utiles pour surveiller le niveau de respect des exigences de sécurité et des obligations de conformité, sont définis et mis en œuvre. 5. Un processus d'atténuation et de récupération des vulnérabilités applicatives est en place pour la sécurité des applications, avec automatisation des corrections lorsque cela est possible.
  5. Il existe un processus pour valider la compatibilité des appareils avec les systèmes d'exploitation et les applications [PaaS, SaaS].
  6. Il existe un système de gestion des variations en termes de système d'exploitation, de correctifs et/ou d'applications [PaaS, SaaS].
NIS 2

PR.PS-01 : Les pratiques de gestion de la configuration sont établies et appliquées.

  1. Pour au moins les systèmes d'information et de réseau pertinents, leurs configurations de base sécurisées (renforcées) sont définies et documentées dans une liste mise à jour.
  2. Conformément aux politiques mentionnées dans la mesure GV.PO-01, des procédures sont adoptées et documentées en relation avec le point 1.

» Retour en haut de page

Bibliographie

[1] NIST, « Note technique 1945 ».
[2] NIST, « Publication spéciale NIST 800-177, révision 1 ».
[3] Agence nationale de cybersécurité, « Cryptographie post-quantique et quantique : préparation à la menace quantique ».
[4] Agence nationale de cybersécurité, « Cadre d’authentification du courrier électronique ».

» Retour en haut de page


  1. Données Eurostat 2026, https://ec.europa.eu/eurostat/databrowser/view/tin00094/default/table?lang=en&category=f_isoc_t_isoc_i_t_isoc_iu ↩︎

  2. RFC 821 ultérieurement mis à jour par RFC 5321 de 2008. ↩︎

  3. En général, les serveurs de messagerie incluent en effet des modules supplémentaires qui effectuent des tâches autres que celles du MTA, comme par exemple le stockage local des messages et l'accès du client à sa boîte mail. ↩︎ ↩︎

  4. Le nom d'affichage est le champ texte associé à l'adresse électronique de l'expéditeur et affiché au destinataire par le client de messagerie dans l'en-tête du message. Il est distinct de l'adresse électronique et permet d'identifier l'expéditeur de manière claire et reconnaissable. ↩︎

  5. Une adresse électronique possède une structure de type partie-locale@partie-domaine, où la partie-locale identifie l'utilisateur spécifique au sein du système ou du serveur de messagerie associé à la partie-domaine , qui correspond quant à elle au nom de domaine du système ou du service hébergeant le compte de l'utilisateur identifié par la partie-locale [2] .

  6. En l'absence d'ambiguïté, et par souci de fluidité du texte, le terme « serveur de messagerie » sera utilisé à la place de MTA, qui désigne le composant du serveur de messagerie gérant le transfert des messages de l'expéditeur au destinataire. ↩︎

  7. Pour la distinction entre l'expéditeur de l'enveloppe et l'expéditeur du message, veuillez vous référer à l'encadré détaillé « Adresse e-mail de l'expéditeur : expéditeur de l'enveloppe et expéditeur du message » au paragraphe 4.1. ↩︎

  8. Des modificateurs peuvent également être présents pour spécifier des informations supplémentaires, des exceptions aux règles et des variations par rapport aux valeurs par défaut. ↩︎

  9. Pour le moment, il n'existe qu'une seule version du protocole (v=spf1.

  10. Pour le moment, il n'existe qu'une seule version du protocole (v=1.

  11. L'algorithme par défaut est rsa -sha256 .

  12. Le domaine de signature garantit l'authenticité du message par signature numérique et sert de référence aux destinataires pour récupérer la clé publique DKIM auprès du DNS et vérifier la signature. Il ne doit pas nécessairement correspondre au domaine d'envoi du message et/ou au domaine d'enveloppe, mais les politiques DMARC peuvent exiger son alignement (voir le paragraphe DMARC à ce sujet). ↩︎

  13. Le sélecteur permet d'identifier de manière unique la paire de clés cryptographiques utilisée pour créer la signature. Pour un domaine donné, plusieurs paires de clés peuvent être générées afin de permettre aux MTA du même domaine d'utiliser des clés différentes ou de permettre une rotation périodique efficace des clés. ↩︎

  14. En particulier, certains en-têtes de message sont signés (tels que De, À, Objet, Date) et ne sont pas modifiés lors de la transmission du message. ↩︎

  15. Le hachage du message est généralement calculé sur l'intégralité de son contenu. Pour gérer les cas où le message est modifié pendant sa transmission, par exemple par l'ajout d'éléments tels que des pieds de page ou des mentions légales (comme dans le cas des listes de diffusion ou du transfert automatique), il est possible de ne considérer, pour la signature, qu'une partie du message. Cependant, cette pratique présente des risques car elle ne garantit pas l'intégrité totale du message reçu. ↩︎

  16. La signature numérique est obtenue à partir des en-têtes listés dans h et du hachage du corps du message dans bh .

  17. Comme déjà indiqué au paragraphe 5.2.1, en général le domaine de signature ne peut pas coïncider avec le domaine du message et/ou de l'enveloppe, mais les politiques DMARC peuvent exiger son alignement (comme décrit dans le paragraphe DMARC). ↩︎

  18. Pour que DMARC fonctionne, il est nécessaire d'implémenter au moins l'un des protocoles SPF ou DKIM. Ce guide recommande, comme indiqué au chapitre 5, l'implémentation conjointe des trois protocoles. ↩︎

  19. Pour réussir la vérification DMARC, il est nécessaire qu'au moins l'un des deux alignements (SPF ou DKIM) soit valide. ↩︎

  20. Pour le moment, il n'existe qu'une seule version du protocole (v=DMARC1.

une bonne alternative aux e-mails BCC

GNU Mailman

Dans un article précédent, nous avons expliqué les avantages et les inconvénients de l'utilisation des e-mails en copie cachée (BCC),
voir : «Comment envoyer et limiter les e-mails en copie cachée (BCC) ».

Dans les conclusions, nous avons notamment déclaré :

Utilisez des applications dédiées pour l'envoi de courriels en masse. Les systèmes professionnels disposent d'un processus d'approbation et d'un contrôle étape par étape, conçus pour éviter les erreurs.

Résumé de cet article :

Comment ça marche

Les plateformes de marketing par e-mail peuvent être difficiles à apprendre et à prendre en charge (si vous les proposez à vos clients).

Nous vous proposons ici d'utiliser le logiciel libre « GNU Mailman » pour l'envoi de vos mailings en masse.
Cette suggestion s'appuie sur notre expérience avecl'application « copymail », simple d'utilisation.

Une liste « unidirectionnelle » Mailman est une configuration pour les newsletters ou les annonces
où seuls les modérateurs autorisés peuvent publier, et où les membres ne peuvent pas répondre à la liste.

Voici comment ça fonctionne :

  1. L'utilisateur envoie le message depuis son client de messagerie ou depuis le webmail à l'adresse électronique de la liste.
    Il doit ensuite approuver la distribution, qui sera effectuée côté serveur et transmise à tous les abonnés.

  2. Le système gère automatiquement les retours d'e-mails et, si nécessaire, les désabonnements.
    Les abonnements doivent être enregistrés manuellement.

  3. Ce service est extrêmement fiable et peut gérer des milliers d'adresses sans difficulté.
    L'envoi s'effectue via les serveurs SMTP de RealSender ou d'autres serveurs existants.

Retour en haut de page


Liste « unidirectionnelle » de GNU Mailman

GNU Mailman est un logiciel largement utilisé et proposé par la plupart des fournisseurs d'accès à Internet.
On trouve sur Internet plusieurs guides expliquant comment le configurer et l'utiliser pour l'envoi de courriels en masse.

  • Les membres s'inscrivent en remplissant un formulaire sur votre site web (et en répondant à l'e-mail de confirmation)
  • Ils recevront un message de bienvenue qui ne mentionne pas comment publier sur la liste
  • Ils recevront vos newsletters, avec un pied de page contenant des instructions simples pour se désabonner
  • Seules les personnes autorisées peuvent publier sur la liste (envoyer les newsletters)

La principale référence est ce document tiré de deux messages de Barry Warsaw à la liste mailman-users :
Comment créer une newsletter/annonce/liste unidirectionnelle ?

Le texte explique en détail les points principaux :

  • Comment créer un message de bienvenue personnalisé et une page d'informations sur la liste qui n'indiquent pas comment y publier un message ?
  • Comment minimiser les problèmes de mot de passe et de désabonnement fréquemment rencontrés sur ce type de liste ?
  • Comment restreindre la liste pour que seules les personnes autorisées puissent publier ?
  • Comment configurer une liste d'annonces pour répondre à une adresse de contact ?
  • Comment publier sur la liste d'annonces

Un autre article de l'université de Stanford explique comment
utiliser Mailman pour créer une liste « d'annonces uniquement » :
Comment créer une liste d'annonces ou de newsletters « unidirectionnelle » - Article de la base de connaissances KB00010792

Retour en haut de page


Quelques informations historiques sur GNU Mailman

Les listes de diffusion peuvent être axées sur la discussion ou sur l'annonce. Le logiciel Mailman est écrit en Python ; avant sa sortie, la communauté Python utilisait Majordomo, un gestionnaire de listes de diffusion basé sur Perl.

Aujourd'hui, Mark Sapiro maintient la branche stable 2.1,
tandis que Barry Warsaw se concentre sur la nouvelle version 3.X.

Deux principes fondamentaux qui sont essentiels à la réussite continue de Mailman :

  • Aucun message ne devrait jamais être perdu
  • Un message ne devrait jamais être délivré plus d'une fois

Dans Mailman 2, les développeurs ont repensé le système de gestion des messages afin de garantir que ces deux principes demeurent toujours primordiaux. Cette partie du système est stable depuis au moins dix ans et constitue l'une des principales raisons du succès fulgurant de Mailman.

Retour en haut de page


Gestion des rebonds VERP

VERP signifie « Variable Envelope Return Path). Il s'agit d'une technique courante utilisée par les listes de diffusion pour identifier sans ambiguïté les adresses des destinataires dont le message d'erreur est retourné. Lorsqu'une liste de diffusion reçoit un message d'erreur, elle peut prendre des mesures utiles, comme désactiver l'adresse concernée ou la supprimer de la liste.

Il existe un format standard pour les messages d'erreur, appelés notifications d'état de livraison. Mailman utilise une bibliothèque contenant des dizaines d'heuristiques de formatage de messages d'erreur, toutes ayant été rencontrées en conditions réelles au cours des vingt années d'existence de Mailman.

VERP exploite une exigence du protocole SMTP fondamental pour assurer une détection claire des messages de retour, en renvoyant ces messages à l'expéditeur. Il ne s'agit pas du « De » dans le corps du message, mais bien de la MAIL FROM définie lors de l'échange SMTP. Cette valeur est conservée tout au long du parcours de livraison, et le serveur de messagerie destinataire final est tenu, conformément aux normes, d'envoyer les messages de retour à cette adresse.

Si le serveur Mailman est mylist@example.org, l'expéditeur de l'enveloppe VERP pour un message envoyé à anne@example.com sera : mylist-bounce+anne=example.com@example.org. Les courriels en attente de retour sont envoyés à l'adresse du destinataire encodée en VERP. Mailman peut alors analyser l' « À » pour décoder le destinataire initial : anne@example.com.

L'utilisation de VERP exige que Mailman envoie une seule copie du message par destinataire. VERP requiert un champ MAIL FROM pour chaque destinataire, et la seule façon d'y parvenir est d'envoyer une copie unique du message. Cette méthode permet également d'éviter que le message ne soit considéré comme du spam.

Retour en haut de page


Alignement des adresses « De » et « Expéditeur »

Durant la période d'essai, la configuration par défautde l'application « copymail » utilise un domaine fourni par nos soins comme d'envoi (également appelée adresse de retour), c'est-à-dire l'adresse à laquelle les courriels en erreur sont renvoyés. Ce d'envoi est différent du de adresse d'expéditeur (l'adresse visible par les destinataires).

Avant la mise en production, certaines modifications DNS sont nécessaires pour authentifier les messages envoyés avec le « De » . Les dernières normes de messagerie permettent d'envoyer des e-mails authentifiés en utilisant un sous-domaine comme d'expéditeur (par exemple, email.votre_domaine_de_messagerie.com) tout en conservant la possibilité d'utiliser le domaine principal comme d'expéditeur (par exemple, info@votre_domaine_de_messagerie.com). Pour plus d'informations, consultez la relative à l'authentification avancée des e-mails .

La même situation peut se produire dans d'autres environnements. Nous vous recommandons de vérifier ce point auprès de votre fournisseur d'accès à Internet.

Retour en haut de page

proxy inverse pour serveurs SMTP

Un proxy inverse est un serveur placé devant un ou plusieurs serveurs web
pour traiter les requêtes des clients, améliorant ainsi la sécurité, les performances et l'évolutivité.

diagramme de proxy inverse

Au lieu de communiquer directement avec les serveurs,
les clients envoient leurs requêtes au proxy inverse,
qui les achemine vers les serveurs appropriés
agissant comme un point d'accès unique et sécurisé.

Principaux avantages :

  • Sécurité : Il peut bloquer les requêtes malveillantes, chiffrer le trafic
    et protéger les serveurs backend contre les attaques directes.
  • Performances : Il répartit le trafic entrant sur plusieurs serveurs, évitant ainsi la surcharge
    d'un seul serveur et garantissant une plus grande disponibilité.
  • Évolutivité : Elle vous permet d'ajouter ou de supprimer des serveurs backend sans interruption de service,
    offrant ainsi la possibilité de gérer un trafic croissant.

Proxy inverse HTTP uniquement (couche 7)

Plusieurs outils sont disponibles sur Internet ; après des recherches, nous avons initialement écarté ceux qui ne prennent en charge que le protocole HTTP (couche 7) :

Apache
: « Oh là là ! Prenez le temps de vous renseigner sur les technologies que vous utilisez. La messagerie électronique utilise le protocole SMTP. Apache utilise le protocole HTTP. Apache ne connaît absolument rien au protocole SMTP. Si vous souhaitez gérer des messages électroniques, vous aurez besoin d'une technologie compatible SMTP. » – Commentaire de l'EEAA, le 18 août 2016 à 2 h 49

Caddy n'est pas
compatible avec le protocole TCP. « Caddy ne prend pas en charge le proxy TCP, seulement le HTTP sur TCP. Utilisez un proxy inverse capable de gérer le proxy TCP comme Traefik, Nginx ou HAProxy, ou utilisez ce plugin expérimental. » – ElevenNotes, commentaire du 24 septembre 2024


Nous nous sommes ensuite concentrés sur les trois recommandés dans les commentaires : « Traefik, NginX ou HAProxy », en les installant et en les testant un par un.

Traefik était le premier choix.

La plupart des tutoriels commençaient par Docker, une plateforme que je voulais éviter, et j'optais pour une solution simple, éventuellement basée sur l'un des gestionnaires de paquets Linux, comme YUM pour les distributions basées sur RPM comme Fedora et CentOS, ou APT (Advanced Package Tool), qui est utilisé sur les distributions basées sur Debian comme Ubuntu et Debian.

Après une longue recherche, nous avons trouvé cet article récent, qui décrit le type d'installation que nous recherchions : Configurer Traefik en tant que service systemd.

Remarque : vous devez modifier les paramètres SELinux de « Applicatif » à « Permissif »

Après avoir essayé deux formations sur Udemy, nous avons trouvé cette excellente formation : Traefik Crash Course (sans Docker). Nous sommes parvenus à la faire fonctionner en reproduisant les exemples fournis. Vers la fin de la vidéo, l'excellent formateur a exprimé son désaccord total avec cet outil : Traefik Crash Course - 53:50 Summary.
Cela nous a découragés de poursuivre nos tests et nous a conduits à essayer autre chose.

NginX était le deuxième choix

Dans ce cas, l'installation était plus simple, utilisant YUM en résumé :
`yum install epel-release nginx nginx-mod-stream nginx-mod-mail`.
Remarque : sous SELinux, il est nécessaire d'activer le relais :
`setsebool -P httpd_can_network_relay 1`.

Pour la formation, nous avons opté pour la prudence en choisissant le même formateur que pour le cours précédent : « Initiation à NginX » (la première partie dure environ une heure et vingt minutes). Le formateur n'est pas non plus convaincu par cette application, notamment par le fait qu'elle fasse office à la fois de serveur web et de proxy inverse : « Initiation à NginX - Résumé 1:20:10 ».
Le rapport conclut : « Je préfère HAProxy à NginX », nous avons donc décidé de tester HAProxy également.

Enfin, nous avons également essayé HAProxy.

L'installation s'est avérée d'une simplicité enfantine, car il s'agit d'une application très courante, disponible dans tous les gestionnaires de paquets Linux, par exemple : `yum install haproxy`

Nous avons également consulté notre formateur de confiance : HAProxy Crash Course.

Cela fonctionne, mais malheureusement, ce n'est PAS adapté à l'authentification SMTP :
« Il est impossible de configurer HAProxy de cette manière, car HAProxy ne prend pas du tout en charge SMTP. »
lukastribus, commentaire du 17 août 2023


Un serveur SMTP standard en tant que proxy inverse

Au terme de deux semaines de tests, nous avons réalisé qu'il
était préférable d'utiliser un serveur SMTP standard comme proxy inverse pour d'autres serveurs SMTP.

Il remplit sa fonction, utilisant uniquement le protocole SMTP, authentifie correctement les connexions
et peut transférer les requêtes vers d'autres serveurs SMTP via la fonction « smarthost ».

Dans Postfix, dans main.cf, sous
relayhost = [smarthost_address]:port

Dans Sendmail, dans sendmail.mc, comme
define(`SMART_HOST',`mail.example.com')


Retour en haut de page

Comment extraire les adresses e-mail

Il arrive que vous exportiez des données de votre site web ou de votre logiciel de gestion,
contenant des informations sur les commandes ou les coordonnées des clients.
Vous n'aviez peut-être besoin que de l'adresse e-mail et de la date de la commande.

Une solution consiste à importer toutes les données dans Excel, à supprimer les colonnes indésirables
et à exporter les colonnes restantes.

Cela risque de ne pas fonctionner correctement si le champ e-mail contient également la description de l'adresse e-mail,
par exemple : « Dave Martin ».

Cela peut s'avérer fastidieux si vous devez répéter la tâche plusieurs fois
ou si vous devez expliquer toutes les étapes à quelqu'un d'autre.


Extraire les données souhaitées à l'aide d'expressions régulières

Une expression régulière (abrégée en « regex » ou « regexp »)
est une séquence de caractères qui spécifie un modèle de correspondance dans un texte.

Un cas très simple consiste à localiser un mot orthographié de deux manières différentes dans un éditeur de texte ;
l’expression régulière seriali[sz]e correspond à la fois à « serialise » et à « serialize ».

La syntaxe permettant d'identifier le texte constitue une situation plus complexe


Tutoriel sur les expressions régulières (Regex)

Vidéo YouTube recommandée
« 38 minutes bien investies, ça vaut vraiment le coup » :

Comment faire correspondre n'importe quel modèle de texte
(à partir de la minute 25, la syntaxe pour extraire les adresses e-mail est expliquée)

Aide-mémoire pour l'utilisation des expressions régulières


Outil en ligne RegExr

Les expressions régulières sont généralement acceptées
dans les éditeurs de texte avancés comme Notepad++ ou Atom.

Des outils en ligne gratuits sont également disponibles, dont un :
https://regexr.com – un service en ligne pour apprendre, créer et tester des expressions régulières.

Explication de l'interface web :
« Expression » est le champ contenant la syntaxe de l'expression régulière.
« Texte » correspond au contenu à analyser.
« Outils > Liste » affiche les résultats de l'extraction.


Exemple 1 : extraire uniquement l’adresse e-mail

Expression :
[a-zA-Z0-9._-]+@[a-zA-Z0-9._-]+\.[a-zA-Z0-9_-]+

Texte:

Dave Martin 615-555-7164 173 Main St., Springfield RI 55924 davemartin@bogusemail.com Charles Harris 800-555-5669 969 High St., Atlantis VA 34075 charlesharris@bogusemail.com Eric Williams 560-555-5153 806 1st St., Faketown AK 86847 laurawilliams@bogusemail.com

Outils > Liste :
$&\n

Résultat:

davemartin@bogusemail.com charlesharris@bogusemail.com laurawilliams@bogusemail.com

Exemple 2 : extraire l’adresse e-mail et la date

Expression :
","(.*?)([a-zA-Z0-9._-]+@[a-zA-Z0-9._-]+\.[a-zA-Z0-9_-]+)(.*?)",".*",(\d{2}\.\d{2}\.\d{4})

Texte:

"lorem ipsum dolor sit amet", Robert Farrell<rmfarrell@bogusemail.com> ","",02.01.2024, ,5379, "consectetur adipiscing elit","""Mesa, René<rmesa@bogusemail.com> ""","",04.01.2024, ,20826, "sed do eiusmod tempor incididunt","Antonio Bugan<antonio@bogusemail.com> ","",04.01.2024, ,2856, "ut labore et dolore magna aliqua","Crawley Down Tennis Club<hello@bogusemail.com> ","",05.01.2024, ,4453,

Outils > Liste :
$2, $4\n

Résultat:

rmfarrell@bogusemail.com, 02/01/2024 rmesa@bogusemail.com, 04/01/2024 antonio@bogusemail.com, 04/01/2024 hello@bogusemail.com, 05/01/2024

Aide-mémoire pour l'utilisation des expressions régulières
. - Tout caractère sauf un saut de ligne \d - Chiffre (0-9) \D - Caractère autre qu'un chiffre (0-9) \w - Caractère alphabétique (az, AZ, 0-9, _) \W - Caractère autre qu'un caractère alphabétique \s - Espace (espace, tabulation, saut de ligne) \S - Caractère autre qu'un espace (espace, tabulation, saut de ligne) \b - Limite de mot \B - Caractère autre qu'une limite de mot ^ - Début d'une chaîne $ - Fin d'une chaîne [] - Correspond aux caractères entre crochets [^ ] - Correspond aux caractères hors crochets | - Soit l'un, soit l'autre ( ) - Quantificateurs de groupe : * - 0 ou plus + - 1 ou plus ? - 0 ou 1 {3} - Nombre exact {3,4} - Plage de nombres (minimum, maximum)

Source : extraits de code GitHub


Retour en haut de page

Comment protéger les domaines « NO-MAIL » ?

La plupart des entreprises et des organismes publics enregistrent plusieurs noms de domaine.
Les entreprises achètent souvent plusieurs domaines pour se prémunir contre les erreurs d'utilisation et protéger leur image de marque,
ou encore pour promouvoir des événements ou des projets qui méritent une visibilité particulière.

Le nombre de domaines concernés peut varier de quelques dizaines à plusieurs centaines pour une seule activité.
Il va d'environ deux cents dans une municipalité d'une grande ville, jusqu'aux milliers de domaines comme Ferrari et Goldman Sachs.

Des chiffres vertigineux si l'on prend en compte le nombre total de domaines enregistrés, qui atteignait 350 millions de noms de domaine fin 2022 , selon Verisign.

Nombre de ces domaines servent de vitrine. Aucune adresse électronique n'est indiquée sur le site web.
Les demandes de contact sont généralement redirigées vers des formulaires à remplir ou vers les réseaux sociaux.

Domaine NO-MAIL

La gestion des envois d'emails, avec les authentifications nécessaires (SPF, DKIM, DMARC, etc.), devient de plus en plus complexe.
C'est pourquoi, généralement, un seul domaine est utilisé pour les communications externes officielles par email.

Cependant, l'idée de protéger sa présence en ligne peut se révéler à double tranchant.
Des « domaines vitrine » mal configurés peuvent facilement être exploités par des personnes malveillantes.

Ils abusent souvent du nom bien connu de l'expéditeur pour gagner la confiance des destinataires et exiger des actions
qui divulguent des informations confidentielles ou l'ouverture de liens et de pièces jointes.

Les destinataires risquent de compromettre la sécurité de leurs systèmes,
permettant ainsi à des bandes de cybercriminels d'y accéder de l'extérieur.

logo DMARC

Les systèmes d'authentification complexes mentionnés ci-dessus présentent également des avantages.
Le protocole DMARC a été conçu pour lutter contre les courriels frauduleux et
empêcher les personnes ou organisations non autorisées d'utiliser nos services d'envoi.

Une configuration rapide permet de déclarer qu'un domaine donné n'est pas utilisé,
avertissant ainsi les destinataires de rejeter tout courriel provenant de ce domaine.
Il suffit d'insérer un enregistrement (une seule ligne) dans le DNS du domaine avec cette indication :

_dmarc.yourdomain.com. TXT "v=DMARC1; p=reject"

courrier retourné

L'application de cette règle dépend du système qui reçoit les messages.
Heureusement, le protocole DMARC est une norme IETF depuis mars 2015.
La plupart des services de messagerie en ligne l'utilisent pour protéger leurs utilisateurs.

Les messages provenant de domaines « NO-MAIL » seront automatiquement rejetés.

De cette manière, en plus de protéger votre entreprise contre les abus, vous empêcherez que des « anciens » domaines,
qui ne sont plus autorisés à envoyer de messages ni authentifiés, ne soient utilisés par erreur.

Pourquoi les entreprises utilisent-elles les SMS ?

Le problème : courriels non lus, appels sans réponse

La boîte de réception des courriels regorge d'offres concurrentes pour capter l'attention du consommateur,
ce qui rend d'autant plus difficile pour les entreprises de se faire remarquer par leurs clients et prospects.

Il devient de plus en plus difficile d'amener quelqu'un à lire un courriel important (ou même à décrocher un appel téléphonique)

Pourquoi vos clients ne lisent-ils plus vos e-mails ?

48 % des consommateurs ont plus de 50 messages non lus dans leur boîte de réception.
La plupart d'entre eux ne les consultent pas, ce qui explique l'accumulation constante des e-mails.
– Source : ZipWhip, « Pourquoi vos clients ne lisent plus vos e-mails » (pdf 15 Mo)

Certaines mises à jour sont urgentes et peuvent être cruciales. Leur transmission par courriel comporte le risque
que le message ne soit pas lu ou atterrisse dans le dossier des courriers indésirables.

À la question « Combien de comptes de messagerie possédez-vous ? », 77 % ont répondu « deux ou plus ».
Généralement, un seul est configuré sur le smartphone.

Pourquoi vos clients ne répondent plus au téléphone ?

Il est de plus en plus fréquent d'appeler des clients et de ne pas obtenir de réponse, ou de voir l'appel aboutir sur une messagerie vocale

97 % des consommateurs admettent ignorer les appels d'entreprises et de numéros inconnus.
– Source : ZipWhip, « Pourquoi vos clients ne répondent plus au téléphone » (pdf 15 Mo)

La solution : envoie-moi un SMS

La COVID-19 a accru l'utilisation des appareils électroniques ;
64 % des personnes interrogées ont déclaré : « Je passe plus de temps sur mon téléphone ».

État des lieux des SMS en 2021

58 % des consommateurs affirment que les SMS constituent le moyen le plus efficace pour les entreprises de les joindre rapidement.
– Source : ZipWhip, État des lieux des SMS 2021 (pdf 21 Mo)

Même dans le commerce électronique, où l'adresse électronique est généralement requise pour l'inscription,
certaines grandes entreprises, dont Amazon, offrent la possibilité de s'inscrire via le numéro de téléphone mobile.

Explication : cinq bonnes raisons d’envoyer des SMS
  1. systématiquement
    lus, généralement quelques secondes après leur réception.
    Le taux d'ouverture dépasse les 95 % (dont 90 % dans les trois minutes suivant l'envoi).
    Courts et concis, les SMS permettent une communication essentielle et immédiate.

  2. C'est simple :
    ils n'ont pas besoin de connexion internet pour atteindre leur destinataire.
    Cela permet à votre marque de toucher des publics peu à l'aise avec la technologie.
    Son utilisation est similaire à celle du contenu vidéo (rapide, instantané, résumé en 160 caractères).

  3. Le SMS est omniprésent
    et compatible avec tous les téléphones mobiles du monde, sans nécessiter l'installation d'applications supplémentaires.
    Le smartphone (ou le téléphone mobile plus ancien) est toujours à portée de main, comme le portefeuille et les clés de la maison.
    Il offre la possibilité d'interagir avec un client où qu'il soit, via un canal fiable.

  4. sont économiques :
    leur envoi coûte peu cher.
    La longueur moyenne des messages envoyés ne dépasse pas 155 caractères (la limite étant de 160 caractères par message).
    Utiliser les SMS en complément des appels téléphoniques ou des e-mails permet de gagner du temps lors des échanges avec les clients.

  5. La communication est interactive
    et se déroule via un canal fluide et sans pression.
    Les SMS sont perçus comme plus importants et sont donc plus susceptibles d'être ouverts et lus. Ils reçoivent également plus souvent une réponse.
    Le langage simple des SMS favorise l'interaction et permet d'atteindre des taux de réponse jusqu'à 45 %.

Comment gérer les e-mails rejetés

Les courriels de retour, ou simplement « rebonds », sont des courriels envoyés automatiquement
par un MTA (agent de transfert de courrier) à l'expéditeur
pour l'informer que le message n'a pas été correctement reçu par le destinataire.

L’objet est généralement « Courrier retourné : voir la transcription pour plus de détails ».
Les informations de retour, un code accompagné d’une description, se trouvent dans le contenu.

Le « code d’état » doit clairement identifier le type d’erreur ayant provoqué le retour,
mais souvent, les codes et descriptions utilisés par chaque fournisseur de services de messagerie
doivent être analysés et interprétés pour classer correctement le rebond.


Quels sont les risques liés aux e-mails non distribués ?

L'envoi de courriels à des destinataires erronés ou inactifs est considéré comme un « comportement de spammeur ».

vous ne pouvez pas les ignorer

Si vous souhaitez atteindre le reste de votre liste, il est préférable d'arrêter d'envoyer des messages aux personnes ayant des problèmes de qualité.
On parle parfois de « nettoyage de liste ».

vous devriez comprendre leur signification

Il existe trois types de notifications d'état de livraison (DSN) : Succès - L'e-mail a été livré (la notification est envoyée uniquement à la demande de l'expéditeur).
Rejet permanent - Une erreur permanente s'est produite.
Rejet temporaire - Une erreur temporaire s'est produite.

Rejet permanent (code d'état 5.XXX.XXX) : l'adresse e-mail a généré une erreur permanente
telle que « 550 5.1.1 … Utilisateur inconnu » ou « 5.1.2 … Hôte inconnu ».
Une erreur permanente signifie que vous ne devez plus jamais envoyer d'e-mail à ce destinataire.
Un seul message rejeté doit entraîner le blocage de l'adresse e-mail.

Rejet temporaire (code d'état 4.XXX.XXX) : l'adresse e-mail a généré une erreur temporaire
telle que « 452 4.2.2 … Boîte aux lettres pleine ».
Une erreur temporaire signifie que vous pouvez réessayer la livraison ultérieurement.
Au moins trois messages rejetés à quelques jours d'intervalle doivent entraîner le blocage de l'adresse e-mail.

Vous devriez savoir comment fonctionne la gestion des rebonds (et comment la paramétrer)
  • Tous les messages de retour sont téléchargés par une application
    et mis à disposition pour une vérification humaine, soit via l'interface de l'application, soit via un fichier JSON.

    rebond dur
  • La classification suit certaines règles, qui peuvent être modifiées

    catégories de rebond dur
  • Les options définissent à quel moment les rebonds souples seront « améliorés » en rebonds durs

    options de rebond

» Retour en haut de page


Vérifiez le nombre de rebonds

Parfois, une erreur de configuration, tant du côté de l'expéditeur que du côté du destinataire,
peut provoquer un rebond temporaire, voire un rebond définitif.

Il est judicieux de vérifier régulièrement le nombre de messages rejetés la semaine précédente
afin de comparer les valeurs et de déceler d'éventuelles anomalies.
En cas de problème, vous le remarquerez immédiatement. L'analyse détaillée des rejets vous permettra d'en identifier la cause.

Certains systèmes permettent de définir le nombre de jours (par exemple 180)
après lesquels les informations de rebond d'un abonné sont supprimées.
Le serveur SMTP tentera alors de contacter à nouveau ce destinataire.

Les blocs activés par erreur seront automatiquement supprimés,
mais la réputation du serveur SMTP peut en pâtir.

» Retour en haut de page


En une phrase : mieux vaut prévenir que guérir.

processus d'envoi d'e-mails

Pour éviter de nuire à la réputation de leurs serveurs SMTP,
de plus en plus d'ESP (fournisseurs de services de messagerie) utilisent une «liste de suppression d'emails»
qui agit avant que les messages n'atteignent la boîte aux lettres du destinataire.

Lorsqu'un client envoie un courriel qui génère une erreur de rejet définitive,
l'adresse courriel à l'origine de cette erreur est ajoutée à la liste de suppression.

La liste d'exclusion s'applique à tous les clients. Autrement dit,
si un client tente d'envoyer un courriel à une adresse figurant sur cette liste,
le serveur SMTP ne l'enverra pas, car l'adresse est exclue.

L'utilisation de serveurs SMTP avec une adresse IP dédiée permet d'éviter certains problèmes liés au partage de réputation.
Par exemple, la liste de blocage des e-mails peut être limitée à votre seule adresse IP ;
ainsi, si un autre client fait blacklister le serveur SMTP et génère des erreurs de distribution,
vos envois ne seront pas affectés.

» Retour en haut de page


Codes d'état des messages renvoyés

Les codes d'état utilisés pour identifier les rejets définitifs et les rejets temporaires ont la syntaxe suivante :
code-état = classe « . » sujet « . » détail

Les codes d'état sont composés de trois champs numériques séparés par un point (« . »)

  • Le premier sous-code (classe) indique si la tentative de distribution a réussi
  • Le deuxième sous-code (sujet) indique la source probable de toute anomalie de livraison
  • Le troisième sous-code (détail) indique une condition d'erreur spécifique

Le sous-code (classe) fournit une classification générale du statut.
Les valeurs listées pour chaque classe sont définies comme suit dans les RFC 3463 et RFC 6522 :

2.XXX.XXX Succès (NON envoyé sauf à la demande de l'expéditeur) Le succès indique que le DSN signale une action de livraison positive. Des sous-codes de détail peuvent fournir des informations sur les transformations nécessaires à la livraison. 4.XXX.XXX Échec transitoire persistant Un échec transitoire persistant se produit lorsque le message envoyé est valide, mais qu'une condition temporaire persistante a entraîné l'abandon ou le retard des tentatives d'envoi. Si ce code accompagne un rapport d'échec de livraison, les envois ultérieurs pourront réussir. 5.XXX.XXX Échec permanent Un échec permanent est un échec qui ne peut être résolu par le renvoi du message sous sa forme actuelle. Une modification du message ou de sa destination est nécessaire pour une livraison réussie.

Quelques exemples de code et de description :

2.0.0 : Envoyé (Message accepté pour livraison) 4.2.2 : Quota dépassé 4.4.5 : Espace disque insuffisant 5.0.0 : Nom de domaine invalide 5.1.1 : Utilisateur inconnu 5.7.1 : Contenu du message rejeté

» Retour en haut de page

Comment vérifier si mon serveur SMTP est sécurisé ?

Avec la multiplication des attaques de rançongiciels dans les années 2020
, le courrier électronique, notre principal canal de communication sur Internet, est-il sûr ?

Les serveurs SMTP constituent une infrastructure particulièrement sensible.
Ils peuvent diffuser des courriels en notre nom,
que nos interlocuteurs acceptent comme provenant d'expéditeurs de confiance
car ils sont correctement authentifiés par le serveur d'envoi.

Les serveurs SMTP constituent une infrastructure particulièrement sensible.
Ils acheminent les courriels en notre nom,
que nos interlocuteurs acceptent comme provenant d'expéditeurs de confiance
car ils sont correctement authentifiés par le serveur SMTP de l'expéditeur.

Que se passe-t-il si quelqu'un d'autre utilise votre serveur SMTP ?
Comment vérifier si mon serveur SMTP est sécurisé ?


L'utilisation d'infrastructures sensibles sur Internet
exige un niveau élevé de protection afin de prévenir les abus.

Alerte de sécurité critique

Si vous tentez d'envoyer des messages via smtp.gmail.com,
vous serez bloqué et recevrez cette « alerte de sécurité critique » :

Application non sécurisée bloquée. Google a bloqué l'application que vous essayiez d'utiliser car elle ne respecte pas nos normes de sécurité. [...]

La seule alternative est d'utiliser OAuth2, un protocole qui ne partage pas les données de mot de passe
mais utilise à la place des jetons d'autorisation pour prouver l'identité.


Les serveurs de messagerie les plus utilisés sur Internet (données d'août 2021) sont :
Exim (58 %), Postfix (35 %), Sendmail (4 %).

Pour continuer à utiliser votre propre serveur de messagerie
tout en réduisant le risque de piratage, voici les exigences minimales à vérifier :

  1. Seule une authentification sécurisée est acceptée :
    le nom d’utilisateur et le mot de passe doivent être transmis via une connexion sécurisée,
    généralement le port 587+TLS , le port 25+TLS ou le port 465+SSL.
    La communication de données sensibles en clair est désactivée.

  2. Il doit y avoir une vérification de l'adresse « Mail-From » (l'expéditeur) ;
    seules les personnes que vous avez autorisées pourront accéder au courrier.

  3. Configurez Fail2ban pour bloquer toutes les attaques externes
    afin d'empêcher toute tentative de contournement de vos protections.
    Fail2ban doit notamment bloquer toutes les tentatives répétées.

  • se connecter avec un nom d'utilisateur ou un mot de passe incorrect
  • envoyer des courriels avec un expéditeur non autorisé
  • interrompre la connexion SMTP pendant le processus d'authentification
    (plusieurs connexions interrompues rendent le service SMTP indisponible pour les utilisateurs légitimes)

Le blocage intervient généralement entre trois et dix tentatives
et bannit l'adresse IP source pendant trois à vingt-quatre heures.

Il est assez facile de tester ces points et de déterminer si
votre infrastructure SMTP nécessite ou non une mise à niveau de sécurité.


Fail2ban protège votre serveur contre les attaques par force brute/DDoS.
Le principe est le suivant : lorsqu’un inconnu frappe à la porte,
après un certain nombre de coups, la porte disparaît.

Logo Fail2ban

Un témoignage de Hacker News:

Je gère mon propre serveur de messagerie depuis plusieurs années et je pense que beaucoup d'autres ici utilisent des solutions comme Mail-in-a-box, Mailcow, Mailu, etc. Jusqu'à la pandémie, je n'avais jamais eu de gros problèmes avec mon serveur, mais ces dernières semaines, j'ai enregistré un afflux massif de trafic entrant, trop important pour mon serveur. J'ai dû le redémarrer manuellement à chaque fois… [...] Edit : J'ai modifié mes paramètres Fail2ban et j'ai constaté que j'étais principalement la cible d'attaques par force brute, contre lesquelles je devrais pouvoir me protéger avec des outils comme Fail2ban

Fail2ban est une application d'analyse de journaux qui surveille les journaux système
à la recherche des symptômes d'une attaque automatisée.

Lorsqu'une tentative d'abus est détectée,
Fail2ban ajoute, grâce aux paramètres définis, une nouvelle règle au pare-feu (iptables ou firewalld)
afin de bloquer l'adresse IP de l'attaquant, soit temporairement, soit définitivement.
Fail2ban peut également vous alerter par e-mail en cas d'attaque.

Fail2ban est principalement axé sur les attaques SSH, bien qu'il puisse être configuré
pour fonctionner avec tout service utilisant des fichiers journaux et susceptible d'être compromis.

Il est largement utilisé. Une simple recherche sur Google permet de trouver facilement
des exemples de configuration pour la protection des serveurs de messagerie.

Paramètres DNS pour l'envoi d'e-mails

Quels paramètres DNS de domaine sont nécessaires pour envoyer des e-mails ?

Les fournisseurs de services de messagerie exigent généralement que vous vérifiiez le domaine de l'expéditeur
avant d'utiliser leurs serveurs SMTP. Il y a deux raisons à cela :

  1. Prouvez que vous êtes propriétaire du domaine
    en gérant le DNS ; vous prouvez ainsi que vous contrôlez le domaine de l’expéditeur
    et que vous n’utilisez pas le domaine de quelqu’un d’autre (usurpation d’identité).

  2. En activant l'authentification SPF et DKIM, vos e-mails sont authentifiés et reconnus par les destinataires comme provenant d'un expéditeur légitime. Si votre domaine et votre fournisseur SMTP jouissent d'une bonne réputation, les messages devraient parvenir dans la boîte de réception des destinataires.



Résumé:

Fournisseurs de services de messagerie électronique : exigences relatives aux expéditeurs vérifiés

Vous trouverez ci-dessous, par ordre alphabétique, quelques-uns des principaux fournisseurs que nous avons vérifiés.
Fin juillet 2021, nous avons testé les paramètres de base nécessaires à l'envoi d'e-mails.
Le domaine vérifié était « emailperfect.com ». Enregistré en 2012, il n'avait jamais servi à l'envoi d'e-mails auparavant.

Nom du fournisseur Alignement du domaine « From » DKIM
Alignement du domaine « Mail-From » SPF
Notes
Amazon SES oui (3 enregistrements CNAME) NON (@amazonses.com)
Mailgun oui (enregistrement TXT) oui (enregistrement TXT) Vérification de la livraison Hotmail et Yahoo*
Mailjet oui (enregistrement TXT) NON (@mailjet.com) Vérification de la livraison Hotmail et Yahoo*
RealSender oui (2 enregistrements CNAME) oui (enregistrement TXT) adresse IP dédiée
Sendgrid oui (2 enregistrements CNAME) oui (enregistrement CNAME) Vérification de livraison Hotmail*
Sendinblue NON (sendinblue.com) NON (@aa.d.sender-sib.com) Aucune vérification de l'expéditeur requise
Smtp2go oui (1 enregistrement CNAME) oui (enregistrement CNAME)

* = Nous avons envoyé un message à chacune des boîtes mail suivantes et noté si un élément justifiait une nouvelle vérification :
Gmail, Hotmail, Yahoo, GMX, Aruba, Tiscali, Exchange Online

Pourquoi un expéditeur vérifié est-il si important ?

En 2021, nous considérons comme obligatoire l'authentification du domaine de l'expéditeur
afin que le destinataire puisse vérifier que l'adresse électronique de l'expéditeur n'a pas été falsifiée.
Ce contrôle d'authentification préventif réduit également considérablement le risque d'utilisation abusive des systèmes d'envoi.

Pour cette raison, nous avons « supprimé » un fournisseur de la liste :
il n’exige pas la validation du domaine avant de l’autoriser à envoyer des messages.

Qu'est-ce que l'alignement de domaine ?

Lors de l'envoi d'un message, nous avons affaire à deux domaines :

  1. dans l'adresse de l'expéditeur, qui est visible par les destinataires
  2. dans l'adresse Mail-From (également appelée « expéditeur de l'enveloppe » ou « chemin de retour »),
    qui est cachée et gérée directement par le fournisseur de services de messagerie (ESP) pour recevoir les courriers non retournés

L’exigence d’« alignement de domaine » est résumée dans cette phrase :
« lorsqu’un expéditeur authentifie son courriel à l’aide de SPF et/ou DKIM,
au moins l’un des domaines doit correspondre au domaine d’envoi ».

Enregistrement CNAME ou enregistrement TXT, lequel est le meilleur ?

Pour l'authentification DKIM, un enregistrement CNAME est plus simple à mettre en œuvre.
On peut obtenir le même résultat en ajoutant un enregistrement TXT de 2048 bits, mais c'est plus complexe.
De plus, la délégation de l'enregistrement DKIM via CNAME permet à votre fournisseur
de modifier sa clé si nécessaire pour des raisons de sécurité.

Pour l'authentification SPF via un enregistrement CNAME, l'adresse d'envoi (Mail-From)
sera un sous-domaine géré par votre fournisseur de messagerie, par exemple : bounce.votre-nom-d'entreprise.org.
Ce fournisseur se chargera de l'authentification SPF et du traitement des messages de retour.

L'enregistrement TXT pour l'authentification SPF est la solution optimale avec les serveurs de messagerie tels que Zimbra ou Exchange,
où chaque expéditeur reçoit directement les messages d'erreur.
L'authentification de domaine ne nécessite qu'un seul enregistrement TXT,
ce qui peut compliquer sa gestion si vous administrez plusieurs serveurs SMTP.

Qu'est-ce qu'une adresse IP dédiée ?

L’« adresse de protocole Internet » ou « adresse IP »
est similaire à un numéro de téléphone sur votre téléphone fixe ou votre appareil mobile.

La plupart des services SMTP fournissent des adresses IP « partagées » à leurs clients.
Chaque envoi de courriel se voit attribuer une adresse IP différente.

Une « adresse IP dédiée » signifie que votre adresse IP d'envoi d'e-mails restera la même.
Cela vous permet de maîtriser parfaitement votre réputation d'expéditeur, qui ne risque pas d'être compromise par l'utilisation d'adresses IP tierces.

Devrions-nous gérer directement les paramètres DNS du domaine de l'entreprise ?

Pas nécessairement, car cela requiert certaines compétences techniques.

La direction de l'entreprise doit être consciente que quelques modifications des paramètres DNS
peuvent entraîner de graves conséquences, telles que :

  • rediriger les visiteurs du site web vers un autre serveur web
  • rediriger les messages entrants vers un autre serveur de messagerie
  • Enrayer l'authentification des e-mails afin que les messages soient considérés comme du spam ou rejetés

» Retour en haut de page

comment gérer les listes de diffusion

Comment gérer ses listes de diffusion avec prévoyance ?

  1. Tout d'abord : pourquoi utiliser un gestionnaire de listes de diffusion ?

    Les systèmes CRM (comme Salesforce et Microsoft CRM)
    et les messageries professionnelles (comme Office 365 et Google Apps Gmail)
    ne sont pas adaptés aux envois de masse.

    Ils ont été conçus pour la communication individuelle
    et imposent souvent des limites d'envoi quotidiennes afin d'éviter les abus. Or,

    les entreprises doivent fréquemment envoyer des e-mails à la plupart de leurs contacts ou à des groupes spécifiques.
    Les envois en masse nécessitent alors des systèmes dédiés,
    capables de traiter de gros volumes de messages et de gérer les désabonnements automatiques.

  2. Deuxième étape : où trouver ces solutions ?

    La réponse la plus simple est de se tourner vers les offres SaaS
    (Mailchimp est le système le plus connu, Inxmail, moins répandu, est utilisé par les grandes entreprises).

    Le choix entre installation locale et services cloud est toujours crucial.
    Nous pensons que l’option locale permet de « reprendre le contrôle de ses emails », ce que nous préconisons.

    Même si vous optez pour une application auto-hébergée dans le cloud,
    vous pourrez facilement changer de fournisseur tout en conservant la même solution.

  3. Trois solutions méritent d'être mentionnées :

  • Sendy est une solution mature mais « à code source fermé » et payante.

  • Listmonk est un logiciel libre. La première version est sortie en 2021. Développé en Go,
    il est distribué sous forme de binaire autonome et sa seule dépendance est une base de données PostgreSQL. Sur GitHub, il compte 5 400 étoiles.

  • Mailtrain est également un logiciel libre. La première version est sortie en 2016, la deuxième en 2021.
    Il utilise une base de données MySQL. Sur GitHub, il compte 4 800 étoiles.

À la recherche d'une interface épurée, d'une solution centrée sur les listes, facile à maintenir
et à restaurer en cas de problème, nous avons considéré Listmonk comme le meilleur choix.

Listmonk est un gestionnaire de listes de diffusion et de newsletters auto-hébergé et performant. Il est fourni sous forme de fichier binaire autonome et sa seule dépendance est une base de données Postgres.

Tableau de bord Listmonk


Premières étapes de la demande

Voici l'annonce originale sur Hacker News:

knadh, le 12 juillet 2019 [–] Auteur ici. Pour expliquer pourquoi Listmonk a été créé, dans le cadre de notre activité (secteur financier réglementé), nous devons envoyer régulièrement des e-mails, principalement des mises à jour importantes, à plus de 1,5 million de clients. Nous avons longtemps utilisé phpList, puis testé MailTrain et Sendy, avant de finalement opter pour une solution radicalement différente suite à de nombreux problèmes, dont certains importants sont mentionnés ci-dessous. - Performances : Les délais d'envoi des e-mails étaient excessivement longs. Avec phpList, le traitement d'une campagne pouvait prendre plusieurs jours. Listmonk peut lancer un grand nombre de goroutines (ou threads) et envoyer des e-mails à plusieurs serveurs SMTP. Sur une instance EC2 standard, nous pouvons envoyer plus de 1,5 million d'e-mails en quelques heures. - L'importation des abonnés était extrêmement lente. L'intégration directe pour synchroniser les abonnés avec les CRM externes était complexe. Les insertions directes dans la base de données étaient complexes en raison de la complexité des structures de tables. Listmonk importe 10 000 enregistrements/seconde dans une base de données PostgreSQL sur une instance EC2 standard. – Segmentation : nous devons souvent segmenter rapidement les utilisateurs selon des attributs et des conditions personnalisés, puis leur transmettre une mise à jour. Listmonk prend en charge les expressions SQL pour segmenter les utilisateurs selon leurs attributs définis comme des dictionnaires JSON arbitraires (grâce au type JSONB de PostgreSQL). – Absence de modèles dynamiques : les modèles Listmonk prennent en charge les expressions de modèles Go, ce qui permet d’intégrer une logique dans les messages pour les rendre dynamiques.

Kailash Nadhest un développeur très actif dans le domaine des logiciels libres et open source (FOSS).
Il travaille chez Zerodha, le plus grand courtier en bourse d'Inde.
Le blog de l'équipe technique de Zerodha est publié à l' adresse zerodha.tech.


Les détails

Listmonk est bien documenté pour une utilisation standard (via une interface web) et pour les développeurs (via une API).

Documentation de listmonk

Cette solution convient aussi bien aux grandes listes (jusqu'à des millions d'abonnés) qu'aux petits groupes. Grâce à sa fonction d'interrogation et de segmentation des abonnés , elle permet d'interroger et d'exporter une sélection d'abonnés en fonction de leurs profils et attributs. Les données extraites peuvent ensuite être facilement importées dans une nouvelle liste de diffusion ciblée.


Il lui manque certaines fonctionnalités importantes, comme la gestion des retours d'e-mails.
Mais elles devraient être disponibles dans la prochaine version majeure :
Traitement des retours #166.
Aperçu de la capture d'écran du traitement des retours.


Considérations techniques

Nous avons déjà utilisé une autre application Go : RealSender - DMARC REPORTS.
Source : dmarc-report-converter. Elle a fonctionné immédiatement et sans problème.

« Le système de gestion de bases de données PostgreSQL, fruit de plus de vingt ans de développement, est aujourd'hui la base de données open source la plus avancée au monde. » – Une brève histoire de PostgreSQL - https://www.postgresql.org/docs/9.3/history.html

Nous avions déjà eu un peu d'expérience en la matière lors de l'installation du serveur Inxmail Professional.
En 2017, Inxmail GmbH a annoncé qu'elle ne prendrait plus en charge que PostgreSQL, abandonnant toutes les autres bases de données.

À compter du 1er janvier 2019, nous nous concentrerons sur une infrastructure technique optimale et cesserons la prise en charge des serveurs Windows ainsi que des bases de données MySQL, Oracle et MS SQL Server. Par conséquent, nous n'offrirons plus de support que pour Inxmail Professional installé sur des serveurs Linux et utilisant PostgreSQL. -- Solution de licence Inxmail Professional : Modifications apportées à notre support système https://www.inxmail.de/files/files/de/downloads/Inxmail-Professional-licence-solution-EN.pdf

C'est assurément un bon choix et un investissement judicieux pour les débutants souhaitant acquérir de précieuses connaissances.
Les cours en ligne Udemy peuvent faciliter l'installation et la maintenance initiales de PostgreSQL.

L'open source comporte des risques : un projet récent, lancé en 2019, sera-t-il maintenu à l'avenir ?
Nul ne le sait. Dans le pire des cas, un autre développeur prendra peut-être le relais, mais…

  • Elle semble essentielle de par ses caractéristiques ; si elle est trop complexe, elle devient difficile à maintenir
  • Nous avons soumis un rapport de bug pour listmonk et avons reçu une réponse du développeur en moins de deux heures.
  • L'auteur travaille dans une grande entreprise qui l'utilise en interne

délivrabilité des e-mails

Délivrabilité des e-mails, questions et réponses :

hemancuso, le 12 juillet 2019 [–] Des projets comme celui-ci semblent être une excellente idée, mais la délivrabilité paraît être un point crucial, difficile à évaluer sans une expérience significative. Quelles sont les bonnes pratiques pour utiliser/choisir un fournisseur de services de messagerie (ESP) dans le cadre d'un projet de ce type, afin de garantir une délivrabilité satisfaisante ? knadh, le 12 juillet 2019 [–] Je suis l'auteur. Nous utilisons Listmonk en production dans notre entreprise (secteur financier réglementé) depuis plus de six mois pour la diffusion de mises à jour par e-mail, y compris les communications réglementaires. Nous hébergeons nos propres instances SMTP avec Postal sur des instances EC2 et n'avons jamais rencontré de problèmes de délivrabilité. S'il s'agit d'e-mails légitimes, je ne pense pas que ce soit un problème majeur.

Nous convenons que l'envoi régulier des communications attendues aux clients devrait permettre d'éviter la plupart des problèmes de distribution.
D'après notre expérience, plus le nombre de destinataires est important, plus le risque de problèmes est élevé.
Les serveurs AWS EC2 sont souvent blacklistés par Gmail ; tous les messages envoyés sont alors automatiquement classés comme spam.

RealSender propose des serveurs SMTP IP dédiés,
fonctionnant dans un environnement fiable et constamment surveillé.


À propos du nom

logo de listmonk

goberoi le 13 juillet 2019 [–] Question totalement aléatoire : comment avez-vous choisi le nom ? knadh le 13 juillet 2019 [–] Je ne me souviens plus très bien, mais je crois que l’idée était de créer une « gestion de liste simple et paisible ».

Essayons-le

Vous pouvez obtenir une installation de démonstration fonctionnelle en quelques minutes grâce à l'image Docker.
Sinon, demandez un compte de démonstration Listmonk.

» Retour en haut de page

comment envoyer des newsletters

Après la mise sur liste noire, le service client d'un grand service anti-spam répond souvent :
« Veuillez vérifier la qualité de votre liste afin de garantir l'intérêt des destinataires pour vos envois ».

Les notions d’« hygiène des listes » et d’« intérêt des destinataires » présentent de nombreuses facettes :

A - côté MACHINE - « liste d'hygiène »

  1. Pour une gestion efficace des abonnements et des désabonnements,
    l'abonné doit avoir validé son adresse électronique (double opt-in) et
    les destinataires doivent pouvoir se désabonner facilement et avec certitude (opt-out).

  2. N’envoyez des messages qu’aux destinataires actifs et pleinement engagés.
    d’envoyer des messages à répétition aux destinataires inactifs ou dont la boîte de réception est pleine.
    Cessez d’envoyer des messages aux destinataires inactifs ; leur absence d’interaction est un signe clair de désintérêt.

  3. Le contenu doit être bien paginé (pas une seule image) et adaptatif, afin d'être lisible sur plusieurs appareils.
    Dans le cas contraire, les filtres anti-spam risquent de bloquer le message avant qu'il n'atteigne la boîte de réception du destinataire.

  4. Assurez-vous que les machines reconnaissent l'expéditeur
    des e-mails ; l'authentification permet aux serveurs de messagerie de destination d'identifier les messages comme provenant d'expéditeurs de confiance.

B - du côté HUMAIN - « l'intérêt des bénéficiaires »

  1. Les abonnés doivent s'attendre à recevoir un contenu de qualité ;
    les destinataires doivent avoir hâte de recevoir votre message et l'apprécier.

  2. Il est important de gérer les réponses des utilisateurs.
    Il arrive parfois qu'un problème survienne ou qu'un destinataire ait simplement besoin de communiquer avec vous,
    par exemple pour vous informer qu'il ne souhaite plus recevoir de messages, même si un lien de désabonnement est présent.


Côté machine - « liste d'hygiène »

Les points mentionnés ci-dessus sont facilement gérables pour les petites listes, comptant quelques centaines de destinataires.
Souvent, l'expéditeur les connaît individuellement, car ce sont des clients ou des membres d'une association.

La situation se complique lorsque la liste s'allonge, avec des milliers de destinataires
et davantage de personnes travaillant sur les envois.
Dans ce cas, l'utilisation d'outils professionnels est indispensable.

Sur Internet, il existe de nombreuses solutions professionnelles pour le marketing par e-mail,
la plus connue internationalement étant MailChimp.
De nombreux sites Web répertorient également des alternatives à MailChimp.

La mission d'EmailTrends est de « reprendre le contrôle de vos emails »,
c'est pourquoi nous proposons une solution alternative.

Selon W3Techs, WordPress alimente 40 % de tous les sites web sur Internet
et c'est la technologie la plus populaire sur l'ensemble d'Internet dans la catégorie des logiciels libres.

WordPress MailPoet

Avec plus de 200 000 installations actives, Mailpoet
est l'un des plugins WordPress les plus utilisés pour les newsletters.

MailPoet est un logiciel libre et, depuis fin 2020,
fait partie des entreprises liées à Automattic, la société mère de WordPress.

Quelques captures d'écran peuvent vous donner une idée de la manière dont les différents points sont abordés :

abonnements et désabonnements

Confirmation d'inscription

destinataires pleinement engagés

Cessez d'envoyer des envois aux abonnés inactifs

modifier le statut de l'abonné en « Rejeté »

Gestion des rebonds

modèles d'emails responsifs

Aperçu de la newsletter

Mailpoet propose un modèle économique « freemium », qui vous permet de choisir l'option :
« Je veux juste la version Premium sans envoi ».

Le serveur SMTP dédié de RealSender peut être configuré via l'option « Envoyer avec… > Autre ».
Le plugin « Bounce Handler MailPoet », associé aux boîtes mail de newsletter fournies par RealSender,
garantit l'authentification correcte des emails envoyés.

» Retour en haut de page


Côté humain - « l'intérêt des bénéficiaires »

L'aspect humain est plus difficile à atteindre,
et c'est aussi ce qui fait la différence
lorsque la gestion technique n'est pas parfaite.

yin yang

« SOYEZ PERTINENT »
est un slogan utilisé il y a quelques années dans le marketing par courriel.

Lorsque vous envoyez des informations importantes à des personnes
que vous connaissez bien après avoir longuement discuté avec elles,
peu importe la qualité de la mise en page
ou si le message atterrit dans le dossier spam.

Ils pardonneront toujours les imperfections techniques,
ils attendront vos courriels, les liront
et cliqueront sur le bouton « non-spam » si nécessaire.

» Retour en haut de page

comment envoyer des e-mails privés

Comment envoyer des e-mails privés et cryptés ?

Le courrier électronique n'est ni privé ni sécurisé.
Il n'a pas été conçu dans le respect de la confidentialité et de la sécurité.

Toute personne qui manipule vos courriels pendant leur transit peut les lire,
y compris votre fournisseur d'accès Internet, un pirate informatique ou la NSA (Agence nationale de sécurité des États-Unis).

Résumé:

Que se passe-t-il aujourd'hui ?

Les agences de surveillance lisent les courriels

« La valeur d'une information ne se révèle que lorsqu'on peut la relier
à un autre élément qui arrivera plus tard.
Puisqu'on ne peut relier des points que l'on ne possède pas, cela nous pousse
fondamentalement à tout collecter et à le conserver indéfiniment. »

« Ils disent que ce ne sont que des métadonnées, que des métadonnées, […]
avec qui vous parlez, quand vous leur parlez, où vous avez voyagé.
Ce sont tous des événements de métadonnées.
PRISM concerne le contenu. […] Ils peuvent tous le voir car il n'est pas chiffré. »

Des dizaines d'études psychologiques prouvent
que lorsqu'une personne sait qu'elle est potentiellement surveillée,
son comportement devient beaucoup plus conformiste et docile.
[…] La surveillance de masse crée une prison mentale […]

du côté « illégal »

Les escrocs peuvent également utiliser des logiciels malveillants pour infiltrer le réseau informatique d'une entreprise
et accéder aux échanges de courriels concernant des questions financières.

L’escroquerie au faux ordre de virement (BEC), également appelée compromission de compte de messagerie (EAC),
est l’un des crimes en ligne les plus coûteux.
Dans une escroquerie BEC, les criminels envoient un courriel qui semble provenir d’une source connue et
qui formule une demande légitime […]

Retour en haut de page

les défis

Anonymat et confidentialité

L'anonymat est différent de la confidentialité
[…] nous chiffrons les messages
afin que, même si l'on voit que nous avons envoyé un message,
on ne puisse pas le lire ;
mais parfois, nous ne voulons même pas que l'on voie que nous avons envoyé un message.

L'anonymat sur Internet est difficile à atteindre.
Il exige une connaissance approfondie des outils que l'on choisit d'utiliser.

Ce guide vous donnera peut-être une idée de sa complexité :
Fournisseurs de messagerie privée


La confidentialité est plus facile à obtenir.

Même si vous n'avez rien à cacher, l'utilisation du chiffrement
contribue à protéger la vie privée des personnes avec lesquelles vous communiquez
et complique la tâche des systèmes de surveillance de masse.

Si vous avez quelque chose d'important à cacher, vous êtes en bonne compagnie ;
ce sont les mêmes outils que les lanceurs d'alerte utilisent pour protéger leur identité
tout en mettant en lumière les violations des droits de l'homme, la corruption et autres crimes.

La première étape essentielle consiste à se protéger
et à rendre la surveillance de ses communications aussi difficile que possible.

Chiffrement de bout en bout

Le chiffrement de bout en bout (e2ee) des courriels peut être utilisé pour garantir
que seuls l'expéditeur et les destinataires d'un message peuvent en lire le contenu.

Sans cette protection, il est facile pour les administrateurs réseau,
les fournisseurs de messagerie et les agences gouvernementales de lire vos messages.

La mise en œuvre du chiffrement de bout en bout (E2EE) exige une vigilance constante de la part de l'expéditeur et du destinataire.
Une simple erreur de l'une des parties concernées peut suffire à compromettre la sécurité du chiffrement E2EE.

Les métadonnées des courriels, telles que l'adresse de l'expéditeur, celle du destinataire, la date et l'heure, ne peuvent être protégées par le chiffrement de bout en bout.
L'objet du courriel peut également rester vulnérable et facilement lisible, même avec le chiffrement de bout en bout.

Retour en haut de page

les solutions

Les courriels chiffrés sont illisibles

< technique > Pretty Good Privacy - également connu sous le nom de PGP

Le logiciel PGP suit la norme de chiffrement OpenPGP
(RFC 4880) pour le chiffrement et le déchiffrement des données.

PGP chiffre le corps de votre courriel en un code
que seule la personne autorisée peut lire.

PGP fonctionne sur quasiment tous les ordinateurs et smartphones.
Sa licence est libre et son utilisation est gratuite.

Chaque utilisateur possède une clé publique et une clé privée uniques,
qui sont des chaînes de chiffres aléatoires.

Votre clé publique n'est pas une clé physique, car elle se trouve dans un répertoire en ligne où chacun peut la télécharger.
On utilise votre clé publique, associée à PGP, pour chiffrer les courriels qu'on vous envoie.

Votre clé privée est comparable à une clé physique, car vous la conservez sur votre ordinateur.
Vous utilisez PGP et votre clé privée pour déchiffrer les courriels chiffrés que d'autres personnes vous envoient.

Si un courriel chiffré avec PGP tombe entre de mauvaises mains, il sera totalement illisible.
Sans la clé privée du destinataire légitime, il est quasiment impossible de le lire.

Pour nous protéger de la surveillance, nous devons apprendre quand utiliser PGP
et commencer à partager nos clés publiques chaque fois que nous partageons des adresses électroniques.

< technique > Comment utiliser le chiffrement PGP

Pour utiliser PGP, vous aurez besoin d'une clé publique et d'une clé privée (appelées ensemble paire de clés).
Chacune est une longue chaîne de chiffres et de lettres générée aléatoirement et qui vous est propre.
Vos clés publique et privée sont liées par une fonction mathématique spécifique.

Une application permettant de gérer les clés et le chiffrement/déchiffrement des messages est nécessaire ;
voici une sélection des plus populaires :

Alternatives faciles au chiffrement PGP

PGP est la meilleure solution pour sécuriser les communications avec un partenaire qui l'utilise déjà.
Demander à votre interlocuteur de passer à PGP peut s'avérer difficile.

Les services qui permettent de partager un secret une seule fois constituent une alternative.

Lorsqu'il s'agit d'envoyer un message unique, il existe des applications web open source
qui permettent de saisir des informations qui ne peuvent être consultées qu'une seule fois.

Une fois la page ouverte par le destinataire, les informations sont supprimées
et il ne reste plus qu'un lien brisé dans vos journaux de discussion ou vos e-mails.

Ce n'est pas aussi fiable que l'utilisation de PGP par toute l'équipe, mais c'est beaucoup plus simple à configurer et à expliquer.
Nous avons pu l'utiliser pour envoyer des informations de connexion à des personnes peu versées en informatique, et elles l'ont trouvé facile à utiliser.

Exemple (sans ajouter de mot de passe) :

Imaginons que vous ayez un mot de passe. Vous voulez le communiquer à votre collègue, Jane. Vous pourriez le lui envoyer par courriel, mais il se retrouverait alors dans sa boîte de réception, qui est peut-être sauvegardée, et probablement stockée sur un dispositif contrôlé par la NSA. Si Jane reçoit un lien vers le mot de passe et ne le consulte jamais, le mot de passe est perdu. Si la NSA s'empare du lien et consulte le mot de passe… eh bien, elle l'obtient. Jane ne peut plus récupérer le mot de passe, mais elle sait désormais que quelqu'un consulte non seulement sa messagerie, mais aussi les liens qu'elle clique.

Certains de ces services, tous gratuits et open source, sont listés ci-dessous.
Vous pouvez également choisir d'héberger une instance sur votre propre serveur web.

PrivateBin (une version sécurisée de Pastebin) est développé en PHP.
Son code source est disponible sur GitHub (3100 étoiles).
Les instructions d'utilisation sont disponibles sur un autre site web.

OneTimeSecret est développé en Ruby.
Le code et les instructions de OneTimeSecret sont publiés sur GitHub - 1200 étoiles

SnapPass est écrit en Python. Il a été initialement développé par Pinterest.

Le code et les instructions SnapPass sont publiés sur Github - 600 étoiles

Retour en haut de page

Comment envoyer et limiter les e-mails en copie cachée (BCC)

Comment envoyer et limiter les e-mails en copie cachée (Bcc) ?

« Cc » signifie « Copie carbone » au sens (ancien) de faire une copie
sur une machine à écrire en utilisant du papier carbone.

Le champ « Cci » des courriels (Cci signifiant « Copie carbone invisible »)
contient les adresses des destinataires du message
qui ne doivent pas être divulguées aux autres destinataires.
– IETF RFC 2822 « Format des messages Internet »

La différence entre Cci et Cc réside dans la confidentialité du destinataire.
Avec la fonction Cc, les adresses électroniques figurant dans le champ Cc
sont visibles par tous les destinataires du courriel.

Un destinataire en copie cachée (Bcc) peut voir le destinataire direct (À :), mais
il ne pourra pas savoir qui d'autre a été mis en copie cachée dans le courriel.

La fonction Cci est souvent perçue comme un système d'envoi massif d'e-mails facile à utiliser. Vous
trouverez ci-dessous une brève analyse des avantages et des inconvénients de son utilisation.
En fin de page, les conclusions et quelques suggestions sont présentées.

AVANTAGES

C'est facile : tout le monde peut l'utiliser.

  • C'est un moyen facile de contacter plusieurs destinataires par e-mail
  • Toute personne disposant d'un client de messagerie peut l'utiliser
  • Utilisée correctement, elle respecte la vie privée des destinataires en ne divulguant pas leurs adresses électroniques

Retour en haut de page

CONS

Le courrier électronique est un moyen d'envoi sans vérification préalable.
La copie cachée (Bcc) permet d'atteindre des centaines, voire des milliers de contacts.

La fonction Cci doit être considérée comme un
outil de communication à haut risque, potentiellement dangereux.

  • C'est un processus sujet aux erreurs, les risques sont les suivants :
    • L'ajout par erreur de destinataires en copie cachée (Bcc) dans le champ copie (Cc)
      nuit généralement gravement à l'image de marque.
      Un nouveau message d'excuses est la solution la plus courante
      . Les noms de tous les destinataires sont rendus publics
      . L'utilisation involontaire (et parfois intentionnelle) de la fonction « Répondre à tous »
         génère des chaînes d'e-mails incontrôlables
      . Une personne pourrait signaler un incident de confidentialité au regard du RGPD
         si l'objet ou le corps du message contient des données personnelles appartenant à des « catégories particulières »
         (par exemple, maladie, orientation sexuelle ou convictions).
    • ajouter par erreur une personne comme destinataire principal (visible)
    • oublier d'ajouter quelqu'un ou ajouter quelqu'un qui ne devrait pas recevoir le message

  • Il y a une forte probabilité que votre message soit classé comme spam
    • Le problème, c'est que la plupart des spammeurs utilisent la copie cachée (Bcc) pour envoyer
      des messages, or les serveurs de messagerie de destination sont prudents quant à l'acceptation de ces messages.
    • Si je vous envoie un message en utilisant la copie cachée (Bcc),
      vous recevez un courriel qui ne vous est pas destiné ;
      cela constitue un élément défavorable pour l’évaluation du spam.
    • Le même message sera envoyé
      simultanément à plusieurs adresses électroniques appartenant au même domaine ; il est donc facile de les compter et de les bloquer.

  • Il n'y a aucun contrôle sur les adresses erronées
    • Il peut y avoir plusieurs adresses e-mail enregistrées pour un même destinataire ;
      cela affecte l'envoi de courriels à ce destinataire, même si une ou plusieurs adresses sont correctes.
    • Les adresses syntaxiquement incorrectes sont acceptées sans avertissement
      , par exemple si le symbole @ est absent ou s'il y a des espaces.

  • Aucune personnalisation / faible impact / peu ou pas de réactions
    • Le message sera nécessairement standard et « anonyme » ;
      aucune communication individuelle n’est possible, pas de formule de politesse comme « Cher Monsieur/Madame… »
    • Vos destinataires en copie cachée recevront un message adressé à une autre personne
      à laquelle ils ne prêteront probablement pas attention ni ne réagiront.

  • Il est très probable qu'il y ait des problèmes techniques
    • Toute action abusive de la part de spammeurs ou de pirates informatiques peut rapidement impacter de nombreux destinataires
      et compromettre la réputation du serveur SMTP (c.-à-d. mise sur liste noire du serveur).
    • La boîte mail de l'expéditeur peut être saturée de messages d'erreur (expéditeur inconnu, boîte mail pleine, etc.),
      leur nombre pouvant varier entre 5 % et 20 % des emails envoyés.
    • L'envoi peut avoir un impact négatif sur les systèmes de messagerie (serveurs SMTP), par exemple :
      de nombreuses réponses « veuillez réessayer plus tard », un grand nombre de messages dans la file d'attente, voire un plantage du système.

Retour en haut de page

CONCLUSIONS

  1. Fixez les limites
  • Vérifiez le nombre de destinataires autorisé par votre fournisseur de messagerie.
    Pour être sûr à 100 %, faites le test vous-même.

    RealSender met à votre disposition une liste de 300 adresses @bogusemail.net pour les tests.
    Les messages arriveront sur un serveur de messagerie « trou noir » :
    bogusemail-test.txt

  • Limiter le nombre de destinataires d'un même message à un petit nombre, par exemple 20,
    permet d'envoyer facilement des messages
    à des milliers d'adresses électroniques, en les divisant simplement en petits groupes, par exemple, lorsqu'il y
  1. Passez au niveau professionnel
  • autoriser uniquement l'envoi massif d'emails via différents canaux

  • Utilisez une adresse d'expéditeur différente pour l'envoi de nombreux messages
    , par exemple un autre sous-domaine comme @news.nomdelentreprise.com.
    Seules les personnes autorisées y auront accès
    et la traiteront avec plus de précaution.

  • Dans les bureaux structurés, où de nombreuses personnes utilisent la messagerie électronique et
    des applications dédiées pour l'envoi de courriels en masse,
    les systèmes professionnels disposent d'un flux d'approbation
    et d'un contrôle étape par étape, conçus pour éviter les erreurs.

Retour en haut de page

mesurer le marketing par e-mail

Comment mesurer la performance de vos campagnes d'emailing ?
Les informations suivantes sont issues de nos quinze années d'expérience
avec la plateforme d'emailing Inxmail.

Que sont les « campagnes de marketing par e-mail » ? Il s'agit d'e-mails envoyés en masse avec le consentement du destinataire , dont le contenu est généralement personnalisé en fonction de ses intérêts, et grâce auxquels l'expéditeur peut obtenir des données de retour d'information basées sur le comportement des destinataires.


Les réponses, ou « données de retour d’information », constituent la base des indicateurs
de performance des rapports sur les campagnes d’emailing.
Voici en détail ce qu’ils sont et comment ils sont mesurés :

Les meilleurs outils techniques sont inutiles si les messages n'atteignent pas la boîte de réception du destinataire.
C'est là que la « délivrabilité des e-mails » entre en jeu :

campagnes de marketing par e-mail

marketing basé sur l'autorisation

Le marketing basé sur l'autorisation, également appelé « marketing dialogique »,
est un concept introduit par Seth Godin en 1999 dans son best-seller « Permission marketing ».

Dans l'ouvrage, il est défini comme l'opposé du « marketing d'interruption »
généralement utilisé dans les médias de masse traditionnels tels que la télévision et les journaux.

Elle vise à créer une communication personnelle et directe,
une relation entre les deux parties et à activer un dialogue « humain »
dont l’expérience soit utile et enrichissante pour les deux.

Retour en haut de page

suivi des réactions des utilisateurs

En fonction des autorisations de confidentialité recueillies, l'expéditeur peut enregistrer :

  • données agrégées
  • données de l'utilisateur individuel (par exemple, qui a ouvert l'e-mail, qui a cliqué)

Les données agrégées
permettent de recueillir des commentaires et des informations à l'échelle mondiale sur les tendances générales
(par exemple, le nombre de personnes ayant ouvert l'e-mail, le nombre de personnes ayant cliqué).

Les données individuelles
permettent d'obtenir des informations personnalisées
en collectant des données personnelles, puis d'envoyer des messages personnalisés,
basés sur les interactions précédentes et le comportement de l'utilisateur.

Retour en haut de page

Comment fonctionne le suivi des utilisateurs

Le suivi des liens consiste à remplacer l'URL finale d'un site web
par une adresse fictive, ce qui enregistre la visite et redirige l'utilisateur vers la page de destination.

Dans les e-mails, seuls les clics sur les liens peuvent être suivis.
Les images externes, celles pour lesquelles le client de messagerie demande une confirmation avant téléchargement,
sont traitées comme des liens ; il suffit donc de suivre l’URL d’une image externe
pour connaître le taux d’ouverture des e-mails.

Le suivi n'enregistre généralement que l'« identifiant du courrier »,
un identifiant unique du courrier envoyé.

Le suivi personnalisé est réalisé en ajoutant aux pages visitées
un ou plusieurs paramètres générés par le logiciel,
tels que : example.com/test.html?id=54725788327466628654
le paramètre « id » fait référence à un utilisateur spécifique et à un lien particulier dans le message.

Les informations obtenues peuvent
mettre à jour automatiquement les données du destinataire dans l'application de marketing par courriel
ou transmettre les détails de l'origine du clic à la plateforme d'analyse Web.

Par exemple, une agence de voyages pourrait mesurer
le nombre de clics d'un utilisateur sur des actualités concernant la mer ou la montagne,
en incrémentant un compteur au fil du temps.
Les données recueillies indiqueront la destination préférée du destinataire.

Retour en haut de page

Comment fonctionne la mesure du taux d'ouverture ?

Les taux d'ouverture sont mesurés en combinant les données des clics sur les liens suivis
et les « clics cachés » générés par les images suivies qui ont été téléchargées.

Si un message est ouvert dans l'aperçu du client de messagerie,
sans télécharger les images ni cliquer sur aucun lien,
il est impossible de savoir qu'il a été ouvert.

Depuis 2003, Outlook, puis la plupart des clients de messagerie, ont commencé à bloquer le téléchargement automatique des images, afin de protéger la vie privée de leurs utilisateurs . Ce blocage permettait de suivre la lecture de chaque courriel.


Depuis 2013, les images s'affichent automatiquement par défaut dans Gmail.
Le téléchargement est effectué par un serveur tiers, appelé « proxy »,
qui masque le terminal de l'utilisateur tout en permettant aux opérateurs marketing
de savoir que l'image a été téléchargée et le message ouvert.
Pour plus d'informations, consultez :
Comment fonctionne le nouveau proxy d'images Gmail et quelles sont ses conséquences pour vous ?

L'enregistrement des taux d'ouverture n'est pas précis et
affiche une valeur inférieure au nombre réel d'ouvertures.
Il est néanmoins judicieux de les mesurer,
ne serait-ce que pour comparer les résultats de différentes campagnes.

Retour en haut de page

délivrabilité des e-mails

emails de semences

Il faut tout d'abord vérifier si les courriels arrivent dans les boîtes aux lettres
des principaux domaines de messagerie gratuite présents dans votre liste
, ainsi que dans la boîte de réception des deux principaux fournisseurs de boîtes aux lettres d'entreprise :
Google Apps et Office 365.

Les filtres anti-spam activés par le contenu sont généralement déclenchés par les domaines présents dans les URL (http…).
donc conseillé d'utiliser un seul domaine dans les liens de vos messages.
Ce domaine doit être identique à celui de l'adresse de l'expéditeur ;
cette pratique, appelée « alignement de domaine », réduit les risques liés aux filtres anti-phishing.
Pour la même raison, si les liens sont suivis, ils doivent utiliser un sous-domaine
du domaine de l'adresse de l'expéditeur.

Pour réaliser des tests concrets, il suffit de créer une boîte mail « test » chez chaque fournisseur de messagerie,
puis d'activer le transfert des messages vers votre adresse mail.
Envoyez à chaque boîte mail un message dont l'objet est « Message de test »
et le contenu « Message de test » suivi du lien vers votre domaine.
Si le message passe les filtres anti-spam, vous devriez le recevoir dans votre boîte de réception.

Retour en haut de page

taux de rebond

Il est normal de recevoir des courriels non distribués.
Cela peut être dû à la présence d'adresses inactives,
de boîtes aux lettres pleines ou à d'autres problèmes techniques.

En fonction de la « qualité » de votre liste,
le taux de rebond peut varier entre 5 % et 20 %.

Face à l'augmentation du nombre d'emails non distribués, la gestion manuelle devient impossible.
Les applications d'email marketing intègrent une fonctionnalité appelée « gestionnaire de rebonds »
qui télécharge automatiquement les messages rejetés,
les analyse et les classe selon leur contenu.

L'adresse e-mail de destination est automatiquement désactivée
après un certain nombre de « rebonds permanents », erreurs persistantes telles que « utilisateur inconnu » et « hôte inaccessible »,
ou après un plus grand nombre de « rebonds temporaires », erreurs transitoires telles que « boîte aux lettres pleine ».

Il est important de surveiller le taux de rebond (messages rejetés)
ou le taux de distribution (messages acceptés). Leur somme est égale à 100 %.
Toute variation de cette valeur est un signe qui doit faire l'objet d'une investigation.

Retour en haut de page

indicateurs de performance en marketing par e-mail

Les principales plateformes de marketing par e-mail publient des chiffres de référence
basés sur les données collectées auprès de tous leurs clients.

Termes techniques utilisés dans les rapports :

  • Ouvertures : nombre de destinataires ayant cliqué
    sur au moins un lien suivi ou ouvert au moins une image suivie
  • Taux d'ouverture : Ouvertures / Nombre de destinataires (après déduction des rebonds)
  • Clics uniques : nombre de destinataires ayant cliqué au moins une fois sur un lien
  • Taux de clics (CTR) : Clics uniques / Nombre de destinataires (après déduction des rebonds)
  • Taux de clics par ouverture (CTOR) : Clics uniques / Ouvertures

Voici une courte liste, la plupart des exemples concernent les États-Unis :

Retour en haut de page

ce qui est considéré comme du SPAM

Quels utilisateurs et serveurs de messagerie sont considérés comme des spams ?

En nous appuyant sur notre expérience avec RealSender,
nous avons essayé de résumer les principaux points susceptibles d'affecter la délivrabilité des e-mails en boîte de réception.


Il est inutile d'évaluer les autres points
si les messages ne sont pas attendus/souhaités par leurs destinataires.

Réactions des utilisateurs

L'expéditeur doit se mettre à la place du destinataire et tenter d'anticiper la réception du message.
Les plaintes des utilisateurs peuvent entraîner le blocage du serveur SMTP ou du nom de domaine, ce qui compromet la distribution des messages ultérieurs.

  • Les utilisateurs peuvent généralement gérer leur boîte de réception : tout ce que chaque utilisateur considère comme du spam est considéré comme tel.
    * = de nombreux fournisseurs de messagerie gratuite ne proposent pas la possibilité de se désinscrire de leur « publicité interne ».
  • L'utilisateur exprime son choix en cliquant sur le bouton « Signaler comme spam » (dans Gmail)
    ou sur le bouton « Courrier indésirable » (dans Outlook/Hotmail).
  • Les filtres anti-spam des serveurs de messagerie modernes sont tous liés aux signalements des utilisateurs. Après un certain nombre de clics sur « Signaler comme spam »,
    tous les messages au contenu similaire seront directement placés dans le dossier Spam.

Des paramètres techniques de base sont nécessaires pour que les messages électroniques soient acceptés.

de l'adresse IP et de la classe d'adresses IP

  • Pour bloquer l'adresse IP de votre serveur SMTP, vous trouverez de nombreux outils en ligne en recherchant « vérification de liste noire » sur Google
  • Réputation de classe des adresses IP des serveurs SMTP : consultez notre article de blog pour plus d’informations. L’importance de la réputation des adresses IP SMTP.
  • Si les messages sont envoyés depuis un ordinateur personnel, la réputation de l'adresse IP publique de la connexion Internet doit également être vérifiée
    (certains fournisseurs de serveurs SMTP masquent l'adresse IP de la connexion Internet, de sorte que le système du destinataire ne voit que sa propre adresse IP).

Configuration correcte du serveur SMTP

  • Utilisez le DNS inverse
    pour vous assurer que l'adresse IP de votre serveur de messagerie pointe vers le nom de domaine que vous utilisez pour envoyer des e-mails.
  • L'agent de transfert de courrier, l'application qui achemine et distribue les courriels,
    doit être correctement configuré conformément à la dernière RFC publiée par l'IETF (
    voir par exemple : « Making Postfix RFC Compliant »)

AUTHENTIFICATION correcte de l'email

Utilisez des méthodes d'authentification comme SPF et DKIM pour prouver que vos adresses e-mail et votre nom de domaine sont bien associés.
De plus, vous contribuez ainsi à empêcher l'usurpation de votre domaine de messagerie.

  • SPF est un protocole d'authentification de courriel basé sur le chemin d'accès qui permet aux destinataires de déterminer si l'expéditeur est autorisé à utiliser les domaines figurant dans l'en-tête du message. Pour ce faire, SPF évalue l'adresse IP du serveur de messagerie sortant (MTA) de l'expéditeur à partir des informations publiées par ce dernier dans les enregistrements DNS TXT. SPF est défini dans la RFC 4408 de l'IETF.
  • DKIM est un protocole d'authentification des e-mails qui permet à l'expéditeur d'utiliser la cryptographie à clé publique pour signer les e-mails sortants de manière à ce que le destinataire puisse les vérifier. DKIM est défini dans la RFC 4871 de l'IETF. La norme DKIM est adoptée par Gmail et d'autres grandes entreprises afin d'éliminer complètement le phishing et l'usurpation d'identité dans les e-mails.
  • DMARC s'appuie sur les normes SPF et DKIM établies pour l'authentification des courriels. Les serveurs de messagerie destinataires traitent les courriels non authentifiés en fonction de la politique DMARC de l'expéditeur et lui communiquent le résultat. DMARC est défini dans la RFC 7489, document publié par l'IETF (Internet Engineering Task Force).

Vérification SPAMASSASSIN

  • SpamAssassin est un logiciel serveur utilisé pour filtrer les courriels indésirables. Il emploie diverses techniques de détection de spam.
    Chaque test est associé à un score, positif ou négatif : positif pour « spam », négatif pour « ham » (courrier légitime).
    Le seuil de score par défaut pour le destinataire est de 5. Si le score d'un courriel dépasse ce seuil, il est considéré comme du spam.
    Son utilisation est si répandue que la vérification du score avant l'envoi de courriels devrait être obligatoire.
  • Deux outils en ligne peuvent vous aider à vérifier votre score SpamAssassin : n'est pas du spam et testeur de courrier
    1. Vous devez envoyer le message à l'adresse électronique fournie
    2. Après quelques secondes, cliquez sur les boutons « Afficher votre rapport » ou « Vérifier votre score ».

Le seul moyen infaillible de savoir si un courriel est classé comme spam est…
de l’envoyer et de voir comment il apparaît à destination.

Essayez et voyez ce qui se passe

  • Si vous recevez un message d'erreur, les dernières lignes peuvent s'avérer très utiles, car elles décrivent généralement le problème à l'origine du rejet.
    Si l'explication est incompréhensible, essayez d'envoyer un message avec pour objet « Message de test » et vérifiez s'il est accepté.
    Dans ce cas, envoyez le même message plusieurs fois en réduisant progressivement son contenu, jusqu'à identifier la partie qui déclenche le filtre anti-spam.
  • Disposer d'un journal d'envoi détaillé peut vous aider à vérifier si les messages sont acceptés ou rejetés.
    Des exemples d'informations sont disponibles dans le journal.
  • Dans certains cas (rares), une sorte de « liste blanche » est nécessaire.
    Certains systèmes anti-spam apprennent des interactions des utilisateurs avec les messages reçus.
    Si le destinataire signale un courriel comme non indésirable,
    le système en déduira qu'il s'agit d'un message légitime et le déposera dans le dossier « Boîte de réception » plutôt que dans le dossier « Courrier indésirable ».
    L'autre solution consiste à ce que l'expéditeur figure dans le carnet d'adresses du destinataire ou que ce dernier ait déjà échangé des courriels avec lui.

Clients de messagerie open source

Comment reprendre le contrôle de ses e-mails grâce à des clients de messagerie open source prêts à l'emploi ?

Au cours de la dernière décennie, nous avons assisté à un changement quasi complet des boîtes aux lettres d'entreprise,
passant des serveurs de messagerie sur site aux services cloud comme Exchange Online (Office 365) ou Gmail pour les entreprises (Google Apps).

Les principales raisons sont les suivantes :

  • la nécessité d'accéder aux courriels depuis des interfaces mobiles et Web
  • la nécessité de protéger les boîtes aux lettres contre les spams et les logiciels malveillants

Ainsi, la vie des professionnels de l'informatique s'est trouvée simplifiée grâce au transfert
de la responsabilité de la gestion de l'infrastructure de messagerie aux « géants de la tech ».

Le risque d'abandonner les compétences de base en matière de messagerie électronique peut nous amener à considérer la messagerie électronique
comme quelque chose qui fonctionne comme par magie, simplement parce que Microsoft et Google s'en occupent.

Nous pouvons reprendre le contrôle de nos e-mails en décomposant les composants de la messagerie et en les gérant individuellement :

  • le serveur de courrier entrant
  • le client de messagerie
  • le serveur de messagerie sortante

Cela permet d'isoler et de segmenter les services, ce qui améliore considérablement la sécurité.
Par conséquent, la réduction de la surface d'attaque par l'isolation et la segmentation est considérée comme une bonne pratique.
De plus, cela accroît l'évolutivité et la stabilité.


Les clients de messagerie constituent l'interface principale des boîtes aux lettres. Il s'agit d'un logiciel complexe qui interagit avec les utilisateurs.

De nombreuses solutions sont disponibles sur le marché ; nous les avons sélectionnées en fonction de deux critères :

  • projets multiplateformes, activement gérés et open source
  • prêts à l'emploi, afin que les administrateurs système puissent les gérer facilement

Nous avons retenu deux options :

  1. Mozilla Thunderbird Mozilla Thunderbird est un client de messagerie open source et multiplateforme pour ordinateurs personnels. Développé par la Fondation Mozilla,
    il prend en charge les protocoles IMAP et POP (stockage local des courriels sur votre disque dur pour un accès hors ligne).
    Il offre d'excellentes fonctionnalités de filtrage et de gestion du courrier.

    Thunderbird gère efficacement plusieurs comptes et identités, notamment grâce à la signature automatique.
    Des versions prêtes à installer sont disponibles pour Windows, macOS et Linux. Pour y accéder à distance, les utilisateurs doivent se connecter à leur ordinateur.

  2. La nouvelle fourche Rainloop La nouvelle version dérivée de Rainloopest un client de messagerie web simple, moderne, léger et rapide.
    Elle peut gérer un grand nombre de comptes de messagerie sans nécessiter de connexion à une base de données.
    Elle prend en charge les protocoles SMTP et IMAP pour envoyer et recevoir des e-mails facilement et sans problème.

    En 2020, le projet SnappyMail a été publié sur GitHub.
    Il s'agit d'une version considérablement améliorée et sécurisée de RainLoop Webmail Community Edition.
    Voici une démonstration du client de messagerie SnappyMail. Si vous souhaitez essayer l'interface d'administration, contactez-nous.

Courriel professionnel et confidentialité

Avertissement : ce sujet a d’importantes implications juridiques. Veuillez contacter des consultants qualifiés pour vérifier la réglementation et son application.

La messagerie professionnelle est un outil de travail
qui contient une quantité impressionnante d'informations liées à l'activité professionnelle.

Les entreprises peuvent faire ce qu'elles veulent des courriels,
qui sont un outil de travail professionnel, mais sont-ils rédigés et lus par les employés ?
Peuvent-ils les lire ? Peuvent-ils les sauvegarder ? Peuvent-ils les archiver ?

Résumé:

Adresses e-mail professionnelles génériques, sans contraintes

La boîte mail professionnelle a un caractère ambivalent :
c'est un outil appartenant à l'employeur, mais utilisé par l'employé.

Il convient de faire la distinction entre deux types différents d'adresses électroniques professionnelles :

  • boîte mail personnelle de l'entreprise, par exemple nom.nom@nomdelentreprise.com
  • boîte mail générique de l'entreprise, comme les boîtes aux lettres d'information, d'assistance, de vente, de marketing, de facturation, etc.,
    c'est-à-dire toutes celles qui ne sont PAS liées à une seule personne.

Les boîtes mail génériques de l'entreprise ne posent aucun problème ;
l'entreprise les consulte, lit tous les messages et n'a aucune contrainte.

boîte aux lettres personnelle de l'entreprise, comme les voitures de société

Les boîtes mail personnelles, telles que nom.prénom@nomdelentreprise.com,
peuvent contenir des données personnelles de l'employé que l'employeur doit protéger.

Si nous choisissons d'utiliser ce type de boîte aux lettres,
en tant qu'employeur, nous devons savoir quelles normes techniques adopter
et quels outils utiliser pour pouvoir traiter correctement les données.

La boîte aux lettres peut être comparée à la voiture de fonction :
elle est mise à la disposition de l'employé pour un usage dans le cadre de ses tâches professionnelles.

L’employeur peut par exemple vérifier le kilométrage parcouru afin de s’assurer que le salarié
n’a pas fait un usage abusif de cet outil de travail à des fins personnelles.

L’employeur ne peut toutefois pas surveiller systématiquement et sans raisons spécifiques
ce que fait l’employé à l’intérieur du véhicule de l’entreprise.

La boîte aux lettres est l'équivalent de la voiture de fonction, un outil de travail appartenant à l'entreprise,
mis à la disposition de l'employé pour son travail, afin d'accomplir ses tâches.

Ce que l'employé envoie et reçoit, même pendant les heures de travail, est comparable à ce qui se passe
dans le cockpit d'une voiture de fonction et est assimilé à une correspondance privée.

Retour en haut de page

lecture uniquement sous certaines conditions

L'entreprise ne peut pas lire le contenu des courriels ;
cela ne peut se faire de manière systématique et sans raison précise.
Même en cas de motivation particulière, cela n'est possible que sous certaines conditions.

Trois intérêts différents sont en jeu et doivent être équilibrés :

  • l'intérêt de l'employeur à accéder à ce contenu
    pour des raisons organisationnelles/de production, de sécurité au travail ou autres

  • l'attente légitime des employés
    qui considèrent ce contenu comme confidentiel

  • Les tiers qui écrivent à cette entreprise
    peuvent ignorer que le contenu de leur correspondance n'est PAS privé et confidentiel.
    (La mention légale standard en bas des courriels avertit généralement que le contenu peut être lu par d'autres personnes.)

informer l'employé

Le salarié doit être informé, par une communication écrite adéquate, que les messages électroniques
ne peuvent être utilisés qu'à des fins liées à la relation de travail, par exemple en interdisant toute utilisation personnelle.

Le document doit contenir les instructions d'utilisation des outils de l'entreprise,
notamment la messagerie électronique, et préciser que, conformément à la réglementation sur la protection des données :

  • Les messages électroniques seront archivés afin de se conformer à la loi et de protéger les actifs de l'entreprise
  • L'entreprise peut, dans certains cas, effectuer des vérifications du contenu de la boîte aux lettres de l'employé

Les contrôles massifs sont interdits

Les contrôles dits « massifs » sont interdits,
comme par exemple la lecture systématique du contenu de la boîte aux lettres d'un employé.

Les limites du contrôle de l'employeur reposent sur trois principes fondamentaux :

  • L'une d'elles est la bonne foi, qui permet à l'employeur de vérifier
    la boîte mail professionnelle de l'employé uniquement s'il existe un motif légitime
    , par exemple pour protéger les actifs de l'entreprise susceptibles d'être compromis ou mis en danger par un virus ;
    ou, en cas de suspicion d'infidélité de la part de l'employé, pour effectuer des contrôles préventifs.

  • Les autres sont la proportionnalité dans le contrôle et la limitation dans le temps et dans l'objet de la recherche

Retour en haut de page

obligation d'archiver les messages électroniques

La réglementation exige que l'employeur prouve
avoir adopté des mesures de sécurité adéquates et efficaces
pour protéger les données de l'entreprise, telles que l'archivage des courriels d'entreprise.

obligation d'informer l'employé

Accès aux données par l'employeur
si cet accès est effectué en l'absence d'informations détaillées sur l'entreprise :

  • Cela constitue une violation très grave.

    Des données sensibles peuvent se trouver dans l'espace personnel de l'employé,
    par exemple des informations relatives aux tendances politiques, religieuses, sexuelles ou syndicales,
    qui doivent être garanties avec la plus grande confidentialité.

  • Il s'agit d'une infraction pénale ;

    il existe également un risque que toutes les données acquises illégalement
    soient inutilisables dans le cadre de toute procédure judiciaire.

obligation de supprimer les messages électroniques

La correspondance commerciale doit généralement être conservée pendant dix ans maximum,
afin de préserver le patrimoine de l'entreprise et de pouvoir se défendre en cas de litige.

La conservation et le traitement des données personnelles ne sont autorisés que pour une finalité spécifique.
Si cette finalité cesse d'exister après un certain délai, par exemple après dix ans, ces données doivent être supprimées.

obligation de désactiver les boîtes aux lettres

En cas de licenciement ou de démission d'un employé,
la boîte mail nom.prénom doit être désactivée dans un court délai.

L'entreprise peut activer une réponse automatique informant l'expéditeur que le compte a été désactivé et
l'invitant à écrire à une autre adresse électronique interne.

Les archives historiques des messages internes des employés licenciés
ne peuvent être conservées que si l'employé a été informé que ses messages étaient archivés.

Retour en haut de page

Protéger les courriels contre le spam

Comment protéger les courriels professionnels contre le spam ?

Il est presque impossible de parler de courrier électronique sans évoquer le problème du spam.
Nous avons tenté de résumer la situation actuelle et les stratégies à adopter :


Quel est le pourcentage de spams dans le trafic de courriels ?

Une source réputée est SenderBase, maintenant appelée Talos,
qui indique qu'environ 85 % des courriels étaient des spams et 15 % des courriels légitimes
par rapport au trafic de courriels enregistré en septembre 2020.

Ce pourcentage est resté stable, avec peu de variations au cours des douze derniers mois.

Trafic de spams par e-mail - Septembre 2020

Source : Données sur les courriels et les spams - Volume total mondial de courriels et de spams.

Retour en haut de page


Quels sont les coûts du spam ?

Parfois, les spams servent uniquement à des fins promotionnelles, et l'expéditeur
cherche simplement à attirer plus de clients,
ce qui engendre des distractions et une perte de temps. Ils peuvent saturer votre boîte de réception
au point qu'il devienne difficile de retrouver les courriels importants.

Tous les spams ne sont pas de simples courriels promotionnels.
Dans de nombreux cas, les intentions sont malveillantes et visent à endommager ou à pirater les systèmes des utilisateurs.
Les variantes les plus courantes de spams malveillants dans le monde incluent les chevaux de Troie, les logiciels espions et les rançongiciels.

Retour en haut de page


Quelles sont les dernières techniques anti-spam ?

Imaginez les boîtes mail de votre entreprise comme la porte de votre maison :
vous devez décider qui peut entrer et qui vous laissez sortir.

Aucune technique ne constitue une solution miracle au problème du spam.
Chacune présente des inconvénients, notamment le risque de rejeter à tort des courriels légitimes (faux positifs)
et celui de ne pas rejeter des spams (faux négatifs)
, ainsi que les coûts associés en temps, en efforts et en argent liés au blocage injustifié de courriels de qualité.

Les techniques anti-spam peuvent être divisées en deux domaines : la prévention et le traitement.

Prévention du spam (avant qu'il ne se produise)

Limitez la disponibilité de vos adresses électroniques afin de réduire les risques de recevoir des spams.

  • Soyez discret :

    ne communiquez pas votre adresse e-mail à tout le monde.
    Moins elle est connue, moins vous recevrez de spams.
    Dans la mesure du possible, utilisez une adresse e-mail différente pour vos inscriptions en ligne.

  • Les formulaires de contact

    ne publient pas votre adresse e-mail en ligne ;
    n’importe qui peut la voir. Les robots spammeurs les interceptent constamment
    pour vous contacter en ligne. Utilisez des formulaires web sécurisés* / des formulaires de contact.
    * = protégés contre les robots qui les remplissent automatiquement.

Solution contre le spam (pendant qu'il se produit)

Une fois que les spammeurs ont votre adresse e-mail, la lutte se déplace vers votre serveur de messagerie et votre boîte de réception.

  • Les systèmes de notation similaires à SpamAssassin

    utilisent plusieurs techniques de détection de spam, notamment les listes noires d'emails basées sur le DNS
    (communément appelées listes noires en temps réel, DNSBL ou RBL), l'analyse de texte et le filtrage bayésien.

    Chaque test attribue un score, positif ou négatif : un score positif indique un email « spam », un score négatif un email « ham » (non-spam).
    Le seuil de score par défaut pour le destinataire est de 5. Si le score d'un email dépasse ce seuil, il est considéré comme du spam.

    De nombreux tests de type « SpamAssassin » sont disponibles en ligne,
    permettant aux spammeurs de vérifier leurs messages avant de les envoyer.

  • Fonctionnant grâce à la contribution des utilisateurs,

    ces systèmes permettent de signaler les courriels entrants comme légitimes ou indésirables. Ces signalements sont enregistrés dans une base de données centrale.
    Lorsqu'un certain nombre d'utilisateurs signalent un courriel comme indésirable, le filtre le bloque automatiquement et l'empêche d'atteindre les boîtes de réception des autres membres de la communauté.

    Les retours des utilisateurs sont parfois intégrés à des contrôles automatisés, comme le nombre d'interactions avec le contenu des messages (
    clics sur les liens, téléchargements d'images, etc.) ou le nombre d'occurrences d'un même message dans plusieurs boîtes de réception.

    Lorsqu'un système de filtrage collaboratif repose sur une large base d'utilisateurs actifs,
    il peut bloquer rapidement une vague de spam, parfois en quelques minutes seulement.

    Ce type de filtre est difficilement contournable par les spammeurs.

  • L'authentification des e-mails

    (SPF, DKIM et DMARC) est une technique permettant de vérifier l'authenticité de l'expéditeur.
    Largement utilisées en 2020, ces techniques constituent un excellent moyen d'identifier les expéditeurs de confiance.

    Il est essentiel de connaître à l'avance le domaine exact d'origine des e-mails,
    car une simple modification d'une lettre peut facilement induire en erreur.

    Les spammeurs peuvent en effet contourner l'authentification des e-mails
    pour que leurs messages semblent provenir d'expéditeurs légitimes.

  • Expéditeurs autorisés, liste blanche.

    Une liste blanche permet de spécifier une série d'adresses ou de domaines de confiance.
    Au début, votre carnet d'adresses personnel et vos anciens e-mails seront d'une grande aide.

    Si un expéditeur figure sur cette liste, tous les contrôles sont ignorés et le message est reçu sans délai.
    Cette méthode est facile à mettre en œuvre et très efficace lorsqu'elle est associée à l'authentification des e-mails, afin d'éviter l'usurpation d'adresse électronique*.
    * = utilisation d'un faux expéditeur pour faire croire que le message provient d'une autre source.

    Une fois votre liste de contacts de confiance complétée, aucun expéditeur inconnu n'atteindra votre boîte de réception.
    Tous les messages indésirables peuvent être redirigés vers une autre boîte de réception à consulter une fois par jour, voire moins souvent.

    Les spammeurs auront du mal à identifier les expéditeurs de confiance de chaque destinataire.
    Et même s'ils y parviennent, les contrôles d'authentification des e-mails vous alerteront de toute utilisation frauduleuse.

Retour en haut de page

Fonctionnement de DMARC - mise à jour

Comment DMARC fonctionne-t-il avec Gmail et Office 365 ? (mise à jour)

Nous avons de nouveau testé l'impact de l'authentification des e-mails sur la livraison
vers les boîtes aux lettres Google Mail et Office 365, les fournisseurs de messagerie professionnelle les plus populaires.

Les résultats peuvent être divisés en deux groupes :

livraison des e-mails

(Impact de SPF, DKIM et DMARC sur la distribution des messages envoyés)
 
# Gmail : les e-mails sont toujours acceptés, l’authentification SPF ne semble pas être prise en compte.
   La signature DKIM n’est évaluée que si elle correspond à l’adresse e-mail de l’expéditeur et si l’enregistrement DMARC est configuré avec la règle « quarantaine » ou « rejet ».
 
# Office 365 : prend pleinement en charge SPF. Lorsqu’un message réussit le contrôle SPF, il arrive dans la boîte de réception.
   La signature DKIM n’est prise en compte que si elle correspond à l’adresse e-mail de l’expéditeur ; sinon, elle est ignorée.
 
   Remarque : durant la dernière semaine d’août, Office 365 a présenté un comportement étrange :
   seuls les messages signés avec DKIM (domaine de signature aligné sur l’adresse de l’expéditeur)
   et disposant d’un enregistrement DMARC (quelle que soit la règle) étaient distribués dans la boîte de réception.

protection contre l'usurpation d'identité

(Comment SPF, DKIM et DMARC protègent l'adresse e-mail de l'expéditeur contre l'usurpation d'identité*)
* = faire apparaître le message comme provenant d'une autre source que la source réelle.
 
# Google Mail : avec DMARC activé, les expéditeurs usurpés sont filtrés vers le dossier Spam (avec p=quarantine) ou rejetés (avec p=reject).
   Si la stratégie est définie sur « none » (p=none), aucun effet n'est produit ; dans ce cas, tous les messages arrivent dans la boîte de réception.
 
# Office 365 : un résultat « spf fail » ou « spf softfail » suffit à envoyer les faux expéditeurs dans le dossier Courrier indésirable.

 

exigences d'authentification

Les exigences suggérées en matière d'authentification des courriels sont résumées comme suit :

livraison des e-mails protection contre l'usurpation d'identité
Courriel Google mot de passe dkim (alignement de domaine) dmarc défini avec p=quarantine ou p=reject
Office 365 Passage SPF et passage DKIM (alignement de domaine) Ensemble SPF et ensemble DMARC (pour une sécurité accrue)

 

résultats des tests de distribution d'e-mails

Vous trouverez ci-dessous la liste complète des tests effectués

Courriel Google Gmail
(ensemble DMARC)
Office 365 Office 365
(ensemble dmarc)
Passe au SPF dkim aucun boîte de réception boîte de réception boîte de réception boîte de réception
échec du SPF dkim aucun boîte de réception courrier indésirable ordure ordure
échec logiciel SPF dkim aucun boîte de réception courrier indésirable ordure ordure
FPS aucun dkim aucun boîte de réception courrier indésirable ordure ordure
Passe au SPF dkim diff boîte de réception boîte de réception boîte de réception boîte de réception
échec du SPF dkim diff boîte de réception courrier indésirable ordure ordure
échec logiciel SPF dkim diff boîte de réception courrier indésirable ordure ordure
FPS aucun dkim diff boîte de réception courrier indésirable ordure ordure
Passe au SPF Passe dkim boîte de réception boîte de réception boîte de réception boîte de réception
échec du SPF Passe dkim boîte de réception boîte de réception boîte de réception boîte de réception
échec logiciel SPF Passe dkim boîte de réception boîte de réception boîte de réception boîte de réception
FPS aucun Passe dkim boîte de réception boîte de réception boîte de réception boîte de réception
Passe au SPF DKIM invalide boîte de réception boîte de réception boîte de réception boîte de réception
échec du SPF DKIM invalide boîte de réception courrier indésirable ordure ordure
échec logiciel SPF DKIM invalide boîte de réception courrier indésirable ordure ordure
FPS aucun DKIM invalide boîte de réception courrier indésirable ordure ordure

Remarques :

  • L'adresse de l'expéditeur (adresse visible de l'expéditeur) et l'adresse de retour (également appelée « adresse d'envoi » ou « adresse de retour ») sont identiques ; elles font référence au même domaine
  • « dkim pass » : le domaine de signature DKIM est identique à celui de l’adresse d’envoi (le domaine est aligné).
  • « dkim diff » : le domaine de signature DKIM est différent de celui de l'adresse d'envoi (le domaine n'est PAS aligné).

Domaine DKIM pour DMARC

Comment l'alignement du domaine DKIM affecte-t-il l'authentification DMARC ?

DMARC (Domain-based Message Authentication, Reporting and Conformance)
est une norme d'authentification des e-mails, développée pour lutter contre l'usurpation d'identité de domaine.

Dans le chapitre « 3.1. Alignement des identifiants », il est indiqué :

   Les technologies d'authentification du courrier électronique authentifient différents aspects (parfois disparates) d'un message. Par exemple, DKIM authentifie le domaine ayant apposé une signature au message, tandis que SPF peut authentifier soit le domaine figurant dans l'en-tête Mail-From (RFC 5321.MailFrom) du protocole SMTP, soit le domaine EHLO/HELO (RFC 5321.EHLO/HELO), soit les deux. Ces domaines peuvent être différents et ne sont généralement pas visibles pour l'utilisateur final. DMARC authentifie l'utilisation du domaine From (RFC 5322.From) en exigeant qu'il corresponde à un identifiant authentifié. -- https://tools.ietf.org/html/rfc7489#section-3.1

Cela signifie simplement :

   Lorsqu'un expéditeur authentifie son courriel à l'aide de SPF et/ou DKIM, au moins un des domaines doit correspondre au domaine d'envoi

Nous ne savions pas clairement si un message pouvait échouer au contrôle SPF ou DKIM
et réussir malgré tout l'authentification DMARC.

Nous l'avons testé à l'aide d'un outil accessible à tous : une boîte mail Gmail.
Pour voir le résultat, ouvrez le message et sélectionnez « Afficher l'original ».

Test 1 - message transféré : échec SPF, réussite DKIM (aligné)
échec spf dmarc-pass

Test 2 - clé DKIM défectueuse : échec DKIM, réussite SPF (aligné)
échec dkim passe dmarc

Le résultat est évident : le message réussit l’authentification DMARC si elle a lieu :
alignement SPF et de domaine <OR> DKIM et alignement de domaine

Pour réussir le contrôle DMARC, il est donc important dans certains cas de valider la signature DKIM :
le domaine de signature (d=example.com) doit être aligné avec le domaine From.

Exemples de résultats « DMARC-PASS » qui n'auraient pas fonctionné autrement :

Cas 1 - Le transfert interrompt l'authentification SPF

  • Échec SPF : Les contrôles d’authentification SPF échoueront majoritairement,
    car l’e-mail transféré provient d’une nouvelle entité, non incluse dans l’enregistrement SPF de l’expéditeur d’origine.

  • DKIM-PASS (aligné) : Le transfert d’e-mails n’affecte pas la signature DKIM

Résultat : L’alignement DKIM permet au message de passer le contrôle DMARC.

Cas 2 - Le domaine SPF fourni par le fournisseur de services de messagerie (ESP)
ne peut pas être aligné avec le domaine d'origine.

  • SPF~PASS (NON aligné) : L’authentification SPF échoue en raison d’un échec d’alignement de domaine,
    car le domaine utilisé par le fournisseur de services de messagerie (ESP) dans l’adresse Mail-From est différent de celui de l’expéditeur (From).

  • DKIM-PASS (aligné) : la signature DKIM utilise le même domaine que l’expéditeur

Résultat : L’alignement DKIM permet au message de passer le contrôle DMARC.

fournisseurs de messagerie électronique les plus populaires

Quels sont les fournisseurs de messagerie électronique les plus populaires en 2020 ?

Pour contrôler la délivrabilité des e-mails, il est important de savoir quels fournisseurs de messagerie utilisent vos destinataires.

Relations interentreprises

Dans le secteur B2B, nous ne disposons pas de chiffres précis. La plupart des messageries professionnelles migrent vers les suites bureautiques en nuage, où le marché se partage entre G Suite et Office 365.
Ensemble, elles représentent plus de 90 % des parts de marché mondiales de la messagerie professionnelle, selon les données de datanyze.com.

Il est assez facile de recueillir ces informations pour une entreprise.
À partir de l'enregistrement MX du domaine de l'entreprise, nous pouvons voir le fournisseur de messagerie utilisé :
aspmx.l.google.com pour « G Suite »
et mail.protection.outlook.com pour « Office 365 ».

Si votre entreprise opère dans le secteur B2B, il est recommandé de surveiller régulièrement la boîte mail de chacun de ces deux fournisseurs.

Un troisième acteur est Zoho (mx.zoho.com), sa part de marché est d'environ 2 % (source : ciodive.com).

Entreprise à consommateur

Dans le secteur B2C, l'analyse est plus complexe. Il n'existe pas de données publiques sur l'ouverture des e-mails basées sur le trafic internet.

Le seul moyen d'obtenir des informations sur les destinataires d'emails est de les extraire de notre liste de contacts ou de les récupérer auprès des principaux fournisseurs de services de messagerie. Certains d'entre eux publient des rapports annuels qu'ils partagent avec la communauté internet.

Les données ci-dessous présentent les trois principaux fournisseurs de messagerie électronique dans vingt-cinq pays ; ces informations proviennent de l’étude « 2019 Email Benchmark and Engagement Study » publiée par Sendgrid.

Pays

Argentine, Australie, Belgique, Brésil, Canada, Chili, Chine, Colombie, Danemark, France, Allemagne, Inde, Indonésie, Italie, Japon, Mexique, Nouvelle-Zélande, Russie, Arabie saoudite, Espagne, Afrique du Sud, Suède, Suisse, Royaume-Uni, États-Unis

Argentine

ISO Fournisseur n° 1 % Fournisseur n° 2 % Fournisseur n° 3 % Total
AR gmail.com 45.8% hotmail.com 33.7% yahoo.com.ar 8.2% 87.7%

Retour en haut de page

Australie

ISO Fournisseur n° 1 % Fournisseur n° 2 % Fournisseur n° 3 % Total
AU gmail.com 38.0% hotmail.com 18.7% bigpond.com 5.4% 62.1%

Retour en haut de page

Belgique

ISO Fournisseur n° 1 % Fournisseur n° 2 % Fournisseur n° 3 % Total
ÊTRE gmail.com 30.6% hotmail.com 23.0% telenet.be 9.8% 63.4%

Retour en haut de page

Brésil

ISO Fournisseur n° 1 % Fournisseur n° 2 % Fournisseur n° 3 % Total
BR gmail.com 52.9% hotmail.com 22.5% yahoo.com.br 6.1% 81.5%

Retour en haut de page

Canada

ISO Fournisseur n° 1 % Fournisseur n° 2 % Fournisseur n° 3 % Total
Californie gmail.com 38.6% hotmail.com 18.8% yahoo.com 4.5% 61.9%

Retour en haut de page

Chili

ISO Fournisseur n° 1 % Fournisseur n° 2 % Fournisseur n° 3 % Total
CL gmail.com 67.3% hotmail.com 18.2% Yahoo.es 1.7% 87.2%

Retour en haut de page

Chine

ISO Fournisseur n° 1 % Fournisseur n° 2 % Fournisseur n° 3 % Total
CN NetEase (126.com 163.com) n / A. Tencent (qq.com) n / A. Sina (sina.com) n / A. n / A.

Remarque : informations tirées de « Aperçu du pays : Chine » par ReturnPath

Retour en haut de page

Colombie

ISO Fournisseur n° 1 % Fournisseur n° 2 % Fournisseur n° 3 % Total
CO gmail.com 41.3% hotmail.com 38.7% yahoo.com 4.3% 84.3%

Retour en haut de page

Danemark

ISO Fournisseur n° 1 % Fournisseur n° 2 % Fournisseur n° 3 % Total
DK gmail.com 35.8% hotmail.com 14.0% live.dk 3.7% 53.5%

Retour en haut de page

France

ISO Fournisseur n° 1 % Fournisseur n° 2 % Fournisseur n° 3 % Total
FR gmail.com 36.0% hotmail.fr 9.8% orange.fr 8.2% 54.0%

Retour en haut de page

Allemagne

ISO Fournisseur n° 1 % Fournisseur n° 2 % Fournisseur n° 3 % Total
DE gmail.com 20.8% gmx.de 10.0% web.de 9.5% 40.3%

Retour en haut de page

Inde

ISO Fournisseur n° 1 % Fournisseur n° 2 % Fournisseur n° 3 % Total
DANS gmail.com 82.4% yahoo.com 3.4% yahoo.co.in 1.6% 87.4%

Retour en haut de page

Indonésie

ISO Fournisseur n° 1 % Fournisseur n° 2 % Fournisseur n° 3 % Total
IDENTIFIANT gmail.com 82.6% yahoo.com 7.1% yahoo.co.id 1.0% 90.7%

Retour en haut de page

Italie

ISO Fournisseur n° 1 % Fournisseur n° 2 % Fournisseur n° 3 % Total
IL gmail.com 46.8% libero.it 9.9% hotmail.it 7.2% 63.9%

Retour en haut de page

Japon

ISO Fournisseur n° 1 % Fournisseur n° 2 % Fournisseur n° 3 % Total
JP gmail.com 33.8% yahoo.co.jp 12.7% docomo.ne.jp 8.6% 55.1%

Retour en haut de page

Mexique

ISO Fournisseur n° 1 % Fournisseur n° 2 % Fournisseur n° 3 % Total
MX gmail.com 42.6% hotmail.com 31.5% yahoo.com.mx 4.0% 78.1%

Retour en haut de page

Pays-Bas

ISO Fournisseur n° 1 % Fournisseur n° 2 % Fournisseur n° 3 % Total
NL gmail.com 35.4% hotmail.com 19.5% live.nl 2.5% 57.4%

Retour en haut de page

Nouvelle-Zélande

ISO Fournisseur n° 1 % Fournisseur n° 2 % Fournisseur n° 3 % Total
Nouvelle-Zélande gmail.com 46.3% hotmail.com 10.9% xtra.co.nz 9.0% 66.2%

Retour en haut de page

Russie

ISO Fournisseur n° 1 % Fournisseur n° 2 % Fournisseur n° 3 % Total
RU mail.ru 34.8% gmail.com 22.7% yandex.ru 19.6% 77.1%

Retour en haut de page

Arabie Saoudite

ISO Fournisseur n° 1 % Fournisseur n° 2 % Fournisseur n° 3 % Total
SA gmail.com 47.0% hotmail.com 31.0% yahoo.com 7.8% 85.8%

Retour en haut de page

Espagne

ISO Fournisseur n° 1 % Fournisseur n° 2 % Fournisseur n° 3 % Total
ES gmail.com 50.2% hotmail.com 25.8% Yahoo.es 3.8% 79.8%

Retour en haut de page

Afrique du Sud

ISO Fournisseur n° 1 % Fournisseur n° 2 % Fournisseur n° 3 % Total
ZA gmail.com 65.5% yahoo.com 4.1% hotmail.com 2.9% 72.5%

Retour en haut de page

Suède

ISO Fournisseur n° 1 % Fournisseur n° 2 % Fournisseur n° 3 % Total
SE gmail.com 33.2% hotmail.com 21.0% live.se 3.0% 57.2%

Retour en haut de page

Suisse

ISO Fournisseur n° 1 % Fournisseur n° 2 % Fournisseur n° 3 % Total
CH gmail.com 25.5% bluewin.ch 14.6% hotmail.com 10.5% 50.6%

Retour en haut de page

Royaume-Uni

ISO Fournisseur n° 1 % Fournisseur n° 2 % Fournisseur n° 3 % Total
ROYAUME-UNI gmail.com 30.8% hotmail.com 10.4% hotmail.co.uk 9.2% 50.4%

Retour en haut de page

États-Unis

ISO Fournisseur n° 1 % Fournisseur n° 2 % Fournisseur n° 3 % Total
NOUS gmail.com 41.9% yahoo.com 15.1% hotmail.com 5.3% 62.3%

Retour en haut de page

Comment fonctionne DMARC

Comment DMARC fonctionne-t-il avec Google Mail et Office 365 en 2020 ?

Nous avons testé l'impact de l'authentification des e-mails sur la livraison
vers Google Mail et Office 365, les fournisseurs de messagerie professionnelle les plus populaires.

Les résultats peuvent être divisés en deux groupes :

  1. Distribution des e-mails
    (impact de SPF, DKIM et DMARC sur la réception des messages envoyés)
    Gmail : les e-mails sont toujours acceptés, l’authentification ne semble pas être prise en compte.
    Office 365 : répond généralement aux protocoles SPF et DKIM. Pour obtenir des résultats constants et une réception optimale dans la boîte de réception, il est nécessaire de les associer à DMARC.
     

  2. Protection contre l'usurpation d'identité
    (comment SPF, DKIM et DMARC protègent l'adresse e-mail de l'expéditeur contre l'usurpation*)
    * = faire apparaître le message comme provenant d'une autre source que la source réelle.
    Gmail : en combinant DMARC et SPF (qualificateurs « fail » ou « softfail »), les expéditeurs usurpés sont filtrés vers le dossier Spam ou rejetés (selon vos paramètres DMARC).
    Office 365 : SPF (qualificateurs « fail » ou « softfail ») suffit à envoyer les expéditeurs frauduleux dans le dossier Courrier indésirable.

 
Elles sont résumées comme suit :

livraison des e-mails protection contre l'usurpation d'identité
Courriel Google toujours accepté, l'authentification n'est pas du tout prise en compte dmarc + spf (échec ou échec logiciel)
Office 365 dmarc + passe spf ou dmarc + passe dkim spf (échec ou échec logiciel)

 
Vous trouverez ci-dessous la liste complète des tests effectués.

Courriel Google Office 365
Passe SPF - DKIM aucun boîte de réception boîte de réception
Échec du SPF - dkim aucun boîte de réception ordure
Échec logiciel SPF - dkim aucun boîte de réception ordure
FPS neutre - DKIM aucun boîte de réception boîte de réception
FPS aucun - DKIM aucun boîte de réception ordure
Passe SPF - Pass DKIM boîte de réception ordure*
Échec SPF - réussite DKIM boîte de réception ordure
Échec logiciel SPF - mot de passe DKIM boîte de réception ordure*
SPF neutre - Pass DKIM boîte de réception ordure*
SPF aucun - DKIM Pass boîte de réception ordure*
Mot de passe SPF - DKIM invalide boîte de réception ordure
Échec SPF - DKIM invalide boîte de réception ordure
Échec logiciel SPF - DKIM invalide boîte de réception ordure
FPS neutre - DKIM invalide boîte de réception ordure
SPF aucun - DKIM invalide boîte de réception ordure
spf Pass - dkim invalide - rejet de dmarc boîte de réception boîte de réception
Échec SPF - DKIM invalide - Rejet DMARC dsn=5.0.0, stat=Service indisponible ordure
Échec logiciel SPF - DKIM invalide - rejet DMARC dsn=5.0.0, stat=Service indisponible ordure
spf Neutre - dkim invalide - rejet de dmarc boîte de réception boîte de réception
SPF aucun - DKIM invalide - rejet DMARC dsn=5.0.0, stat=Service indisponible ordure
spf Pass - dkim pass - dmarc rejeter boîte de réception boîte de réception
Échec SPF - réussite DKIM - rejet DMARC boîte de réception boîte de réception
spf SoftFail - passe dkim - rejet de dmarc boîte de réception boîte de réception
spf Neutre - passe dkim - rejet de dmarc boîte de réception boîte de réception
spf aucun - passe dkim - rejet de dmarc boîte de réception boîte de réception
spf Pass - dkim diff - dmarc rejeter boîte de réception boîte de réception
Échec SPF - diff DKIM - rejet DMARC dsn=5.0.0, stat=Service indisponible ordure
Échec logiciel SPF - différence DKIM - rejet DMARC dsn=5.0.0, stat=Service indisponible ordure
spf Neutre - dkim diff - dmarc rejeter boîte de réception boîte de réception
spf aucun - dkim diff - rejet de dmarc dsn=5.0.0, stat=Service indisponible ordure

Remarques :

  • L'adresse de l'expéditeur (adresse visible de l'expéditeur) et l'adresse de retour (adresse de retour) proviennent du même domaine
  • « dkim pass » : le domaine de signature DKIM est identique à celui de l’adresse d’envoi.
  • « dkim diff » : le domaine de signature DKIM est différent de celui de l'adresse d'envoi
  • Les astérisques dans le deuxième groupe signifient que les résultats n'ont pas été constants au fil du temps