FAQ

Quelle est l'échelle d'évaluation ?

En partant des plus faibles, les évaluations débutent à E (on est clairement dans le registre de la carte postale) pour progresser jusqu'à A, avec des sur-niveaux A+ et A++ (qui sont plus sécurisées que des LRAR - lettre recommandée avec accusé de réception). Sans autre investissement que dans le soin dans les réglages, il est rapidement possible de progresser jusqu'à B. On observe que de petites entreprises sont capables d'atteindre A++ tandis que des multinationales échouent en bas de l'échelle. C'est donc un indicateur de qualité plus que de richesse en ressources.

A partir D et en dessous, les utilisateurs peuvent alerter leur management et les équipes techniques sur le manque de considération pour la messagerie électronique.

Pourquoi la label est entouré de [ ] avec un score technique négatif ?

Certains domaines sont dédiés à l'émission de courriels, et l'organisation traite ses courriels entrants sur un autre domaine ou sous-domaine. Le moteur d'analyse essaie de détecter ces cas et le mentionne comme remarque dans les détails d'analyse. Le label synthétique prend alors des crochets (le score technique négatif est actuellement un artefact de la manière interne de procéder).

Quels sont les facteurs d'évaluation ?

Le score technique transforme en points les informations techniques détaillées dans une fiche d'analyse.

Par exemple, l'emploi de DNSSEC est un facteur qui intervient comme multiplicateur d'autres scores, parce que sans sécurité du DNS, les informations SPF, etc. peuvent être corrompues. DNSSEC ne résout pas tous les problèmes de sécurité du DNS mais c'est un début.

Les MX désignent les serveurs qui reçoivent les courriels du domaine analysé. Il est vérifié qu'ils proposent tous le chiffrement opportuniste (STARTTLS). Une erreur fréquente est qu'un serveur « de secours » soit configuré différemment et ne propose pas cette mesure de confidentialité.

La localisation des serveurs est également un facteur. L'évaluation se place du point de vue d'un internaute français. Dans ce contexte, quand on transmet un courriel à un serveur hébergé et donc géré par une organisation française (la localisation est induite par le pays de rattachement de l'opérateur télécom), les communications se font dans un cadre judiciaire unique (par exemple pour les interceptions légales) et directement opérationnel. L'Union Européenne fournit un cadre réglementaire (RGPD mais aussi des coopérations entre états membres avec des disparités. L'Amérique du Nord (USA et Canada), du fait de leur prédominance dans les services en ligne, font aussi l'objet d'accord internationaux.

Le principe du SPF consiste à identifier les adresses IP légitimes pour émettre au nom d'un domaine. Cette déclaration perd de son pouvoir restrictif en fonction du nombre d'adresses déclarées. Par exemple, pour un opérateur Cloud qui a des millions de clients (dont certains gratuits et connus au mieux par une adresse de courriel auto-déclarée), spécifier leurs blocs complets d'adresses IP ne limite pas beaucoup un attaquant.

DKIM est à la fois une autre façon d'adresser les limites de SPF et d'apporter des garanties beaucoup plus fortes sur le contenu du courriel selon le principe bien connu de signature numérique. L'authentification fiable est la base de toute sécurité durable.

DMARC vient couronner les standards SPF et DKIM. Sa valeur dépend donc de la force des éléments précédents. Les points dépendent également du stade d'implémentation : reporting, quarantaine, rejet.

L'analyse de l'autoconfig essaie de détecter les faiblesses de configurations des clients de messageries. En effet, il y a de fortes chances que l'utilisateur suive un assistant dans la création de son compte de messagerie. Si celui-ci ne le conduit pas par défaut à employer des communications chiffrées avec les serveurs (STARTTLS et mieux SSL/TLS), même s'ils sont disponibles sous forme d'options avancées, alors la confidentialité est pratiquement compromise dès le premier maillon de transmission.

Pourquoi l'évaluation varie entre tests à quelques secondes d'intervalle?

Le téléservice procède à une nouvelle analyse à chaque demande. Outre que les administrateurs systèmes peuvent avoir changé une configuration précisemment entre deux requêtes (cela s'est déjà vu), la principale raison survient en pratique quand des serveurs MX sont regroupés derrière un répartiteur de charges, et que tous n'ont pas la même configuration. En particulier, si un serveur ne propose pas STARTTLS, il met en péril la confidentialité des communications, et impacte le score technique dès qu'il est détecté.

Que faire si il y a une erreur d'évaluation ?

La diversité d'Internet fait que les configurations testent toutes les limites possibles. Le moteur d'analyse essaie de coller au plus près des RFC mais prend quelques raccourcis. Malgré les efforts, il est possible que l'évaluation se trompe. N'hésiter pas à le signaler pour améliorer l'outil. Mais avant, vérifier bien les informations techniques avec d'autres outils (mxtoolbox.com, hardenize.com) car il est fréquent découvrir une erreur de configuration (les enregistrements SPF, etc suivent un syntaxe bien précise et à l'instant où sont écrites ces lignes, 2 sociétés du CAC40 ont des erreurs vérifiables dans leur enregistrement).

Mentions légales

Ce téléservice est conçu et exploité par le Service du Haut Fonctionnaire de Défense et de Sécurité des ministères économiques et financiers (plus d'information).

Le téléservice est hébergé sur un serveur de la société OVH. Il n'utilise aucun cookie et ne recueille que des informations déjà publiques sur Internet. Il a fait l'objet d'une homologation par le HFDSA des MEF.

Accessibilité

Ce téléservice est conforme au RGAA. Ses pages ont été testées avec WebAIM.