2 ans 6 mois 19 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées, les commandes ne sont peut-être plus valides. Cet article a été publié il y a, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées, les commandes ne sont peut-être plus valides.

Genma m’a lancé un « appât » sur Twitter récemment, sur un petit retour d’expérience d’un point de vue professionnel « sur les mails ». Sujet plutôt large en fonction qu’on doive en envoyer ou en recevoir. J’avais déjà pu évoquer que ce n’était pas évident notamment avec des acteurs privés majoritaires faisant leur loi au mépris des standards et de l’universalité, spoiler alert, c’est de pire en pire.

J’ai cherché le meilleur moyen de découper cet état des lieux, on va le faire en deux grands chapitres, l’envoi d’abord, la réception ensuite, car les deux aspects ne sont pas strictement identiques en termes de problématiques à gérer. Par contre, à me relire, prenez un seau de popcorn, ça va être un peu long.

L’envoi, le cas que je traite le plus

En tant qu’hébergeur et infogérant de plate-forme Web, naturellement je vois plus de mails sortants qu’entrants, d’autant plus qu’on a décidé d’arrêter le service de boite mail qu’on proposait en fin d’année 2017. Il est donc tout naturel que je vous parle d’abord de l’envoi.

La théorie qu’on trouve dans les tutos

Quand un serveur doit envoyer un mail, il doit indiquer une adresse mail d’expéditeur, un site Web va typiquement choisir une boîte sur son domaine. La première étape consiste donc à utiliser du SPF, c’est à dire une directive au niveau DNS comportant la liste des entités autorisées à émettre des mails « depuis » le domaine en question.

La deuxième étape consiste à ajouter une signature cryptographique, le DKIM, au minimum à l’enveloppe. Ce système là aussi repose sur le DNS, qui contiendra la clé publique de la signature, le mail étant de son côté signé avec la clé privée. À la réception la signature est comparée à la clé présente dans le domaine et si ça match, c’est que le mail provient à priori d’une source fiable.

Mais apparemment ça ne suffit pas car les opérateurs majeurs poussent à l’adoption supplémentaire du DMARC, qui repose là aussi sur un champ DNS et permet de définir une politique d’acceptation ou de refus en fonction des résultats SPF et DKIM, et d’indiquer une adresse où envoyer un rapport de ce qui a été accepté ou refusé.

Quand on arrive à la pratique…

En pratique, ne jamais lancer un service sans avoir fait un minimum de vérifications avec des services comme mxtoolbox, mail-tester, isnotspam. Vous risquez alors de découvrir tout ce qu’on ne vous dit pas dans les tutos. A commencer par la réputation de l’adresse IPv4 émettrice (ou plusieurs si vous n’utilisez pas de relai). En effet, de par son aspect majeur, la pratique de l’envoi massif de spam a été pratiqué sur pratiquement toutes les plages d’adresses de la planète. Avec les redécoupages multiples des blocs d’adresses afin de tenter de retarder un peu plus l’inévitable pénurie (vu que personne ne se bouge pour l’IPv6 — oui je sais, moi c’est pas que je veux pas c’est que ça marche quand ça veut bien), il est fréquent, sur une plateforme toute neuve, de se voir attribué une adresse au passé malheureusement trouble, et c’est à vous de faire le nécessaire pour prouver que vous n’êtes pas le responsable du « casier judiciaire » auprès de toutes les listes noires chez qui vous êtes référencé.

Les outils que j’ai mentionné permettent également de comprendre si le contenu de votre mail est litigieux (plusieurs liens, html only, toussa). Ah oui, vous vous offusquez quand on vous dit que Google lit vos mails pour y ajouter de la pub ? Ça fait longtemps qu’ils sont inspectés pour savoir s’ils sont propres, et là, les critères sont complètement arbitraires, même si parfois les infos peuvent se trouver dans les enveloppes, les entêtes du filtrage antispam étant possiblement explicites ou à tout le moins documentés. Parfois, on saura même si une bêtise dans la configuration de votre agent de transport (Postfix, Exim) s’est glissée dans l’enveloppe (reverse DNS pas bon, hostname pas identifiable, ça nous est arrivé plus d’une fois). D’ailleurs si y’a un problème de reverse dans l’enveloppe, Microsoft va vous bouncer et le mail part donc direct à la poubelle (contrairement à Deferred où y’a une chance de rectifier le tire et renvoyer, puisqu’il reste en file côté expéditeur, contrairement au bounce). Joie dans la demeure, parce qu’alors on a que le message d’erreur envoyé par Microsoft sans pouvoir analyser le mail litigieux qui est déjà détruit. Quand je vous disais que c’était des connards…

Vous pensiez que le tableau était déjà noir ? C’est parti pour l’enfer de la gestion « propriétaire » des mails. On va commencer par les outils d’antispam reposant sur leurs propres règles, ceux proposés par des éditeurs de solutions classiques de sécurité (F-Secure, McAfee, Bitdefender et consorts), qui peuvent décider que le mail ne leur plaît pas sur des critères arbitraires. Et s’adresser à eux pour faire lever ce délit de sale gueule sera une vraie chienlit : support à l’étranger, réponse pas systématique… Bon courage avec ceux-là, d’autant que les règles de filtrages peuvent être diffusées à plusieurs de leurs clients, avec donc des effets de bords.

Et c’est juste la partie émergée de l’Iceberg. La nouvelle mode est à l’antispam avec apprentissage machine (ouais une fois les buzzword traduits ça fait moins marketing hein), reposant en partie sur les « retours utilisateurs », ou sur d’autres critères nécessairement flous parce que leur intérêt repose dans l’aspect propriétaire et donc fermé de leur fonctionnement. Là aussi, quand vous êtes un bon élève et qu’on vous envoie en colle sans vous expliquer pourquoi, c’est frustrant, et obtenir les informations pour réparer le tort est toujours pénible, pour les mêmes raisons que dans la partie précédente. Microsoft est devenu le roi à ce petit jeu là, et son autisme quand il s’agit de savoir pourquoi c’est arrivé et comment s’en prémunir est vraiment une purge, bon courage.

Ce que j’ai pu apprendre d’expérience, c’est que si vous n’êtes pas déjà un acteur reconnu opérant du mass mailing, un envoi important simultané sur une destination unique (un Microsoft ou un Google, au hasard, vu les milliards de boites mails qu’il gèrent au quotidien), peut augmenter votre score définissant si vous êtes un spammeur ou pas, quand bien même toutes les adresses de destination ont été volontairement indiquées par leurs utilisateurs. La magie étant de savoir comment vous allez pouvoir être reconnu si vous ne pouvez pas envoyer de mail, du moins pas de ceux que verrons les utilisateurs pour juger d’eux-même si c’est vraiment un spam ou pas, puisqu’ils seront classés par défaut (un renversement de preuve qu’on retrouve dans la loi Hadopi au passage, où vous êtes coupable tant que vous n’avez pas prouvé le contraire). Un prestataire de mass mailing d’un client, lors d’une conférence téléphonique finalement destinée à apprendre au client que les seuls à faire la loi, c’était Microsoft, Google, AOL, Yahoo, nous indiquait que lorsqu’il devait ajouter de nouvelles machines à sa plateforme (et donc de nouvelles adresses IP), il devait les « chauffer », c’est à dire commencer par lui faire envoyer de très petites quantités, et les augmenter au fur et à mesure. Et qu’il passait un temps fou à surveiller le statut de chaque machine de sa ferme d’envoi pour éviter le moindre problème. Regardez comment semble fonctionner Microsoft, les commentaires sont tout aussi édifiants, et encore, ça parle d’auto-hébergement, et ça ne parle pas de la nouvelle boite de réception « prioritaire » censé fonctionner en analysant votre utilisation de la boite fournie (mais qui fout en nom prioritaire des mails sur une boite neuve, sans utilisation…). Dernièrement FAIMaison, un fournisseur d’accès à Internet associatif proposant parmi ses services des boites mail, recommande aussi de quitter Microsoft parce que de moins en moins de plateformes peuvent leur envoyer des mails sans être emmerdés.

Dernièrement, j’ai appris que les plateformes de mail ne voulaient plus de courrier provenant de clouds publics. En tout cas dans l’immédiat, les IP « élastiques » attachées à des instances EC2 sont considérées comme dynamique et à les entendre, c’est le mal; j’imagine que les autres plateformes proposant des instances à la seconde sont dans la même situation. Donc c’est raté si vous voulez vous auto-héberger également hein, les IP ADSL c’est pas bien non plus, même si c’est fixe (déjà quand l’opérateur ne vous interdit pas cette possibilité, n’est-ce pas Orange ?), parce qu’on s’est tapé pendant des années, « grâce » à Microsoft d’ailleurs, des armées de PC Zombies dans les chaumières proposant des pilules bleues de la joie. En soi je peux comprendre ce point, il est vrai que le cout très faible et la très grande facilité de déploiement rend évidemment difficile d’établir une réputation stable pour l’adresse IP, mais c’est toujours dommageable, surtout quand vous avez une instance debout depuis trois ans et que d’un coup on vous dit « non t’es plus en odeur de sainteté » alors que t’as toujours été un bon soldat du mail propre. Ceci dit les solutions existent, chez Amazon une des options est de passer par leur service SES, mais qui a un coût supplémentaire à intégrer dans votre activité évidemment. Vous vous retrouvez donc à payer plus pour pouvoir rendre le même service, on se croirait dans les négociations TF1-diffuseurs en ce moment.

Un dernier point qui échappe à beaucoup de monde tant qu’on s’intéresse pas aux protocoles eux-même, l’échange en clair. Eh oui, le mail est né avant le DNS qui lui date du début des années 80, et tout comme le HTTP, le FTP, et d’autres protocoles historiques, tout est transmis en clair par défaut, donc un intermédiaire peut lire le contenu au passage sans difficulté. Google a commencé en 2017 à marquer et alerter ses utilisateurs quand un courrier a été envoyé en clair, et prévoit cette année d’intégrer ce point dans le calcul de SPAM; j’imagine qu’il ne va pas être le seul à opérer ce changement. Fort heureusement, une fois n’est pas coutume les solutions sont simples à mettre en place, pour ma part j’ai fait pousser 4 lignes sur les serveurs CentOS 6 et 7 de tous nos clients pour utiliser le TLS quand c’est disponible, et ça fait admirablement le boulot à peu de frais, je vous recommande donc de le faire aussi (d’ailleurs faut que je jette un œil à mes serveurs également). C’est même devenu une RFC, autrement dit un standard dans l’univers d’Internet, autant dire que là, personne n’a plus d’excuse d’autant que c’est simple à mettre en place. Car oui, le TLS ne sert pas qu’au web.

Et je pourrais probablement continuer longtemps si ma mémoire n’était pas aussi défaillante. On pourrait évoquer le fait que certains serveurs de mails de destination s’affichent hors-ligne plutôt que de vous dire que vous êtes blacklistés–ou plutôt un filtrage réseau est effectué sur la base des blacklist–, d’autres ne mentionnant pas la raison des refus dans leur réponse (à part juste un « 550 » sans plus de détails, ce code pouvant regrouper plusieurs types d’erreurs, que je vous invite à découvrir ici–en écartant très vite l’horrible message demandant de s’inscrire à une mailing list, ahah).

La réception, l’herbe est-elle plus verte ?

Admettons que vous choisissiez d’héberger et opérer un serveur de réception. Une partie de la théorie est commune avec le paragraphe précédent, car généralement un serveur de réception est aussi utilisé pour répondre, et donc en envoyer (mais d’utilisateur à utilisateur, alors que je présentes les chose plutôt de plateforme web à utilisateur). SPF, DKIM, DMARC, les deux derniers étant un poil plus trickys à mettre en place si plusieurs domaines sont hébergés sur la même plateforme. Idem pour la réputation de l’adresse, ou le chiffrement des communications entrantes et sortantes.

Je ne m’attarderai pas sur les solutions techniques à utiliser, tant qu’il est possible de faire à peu près tout ce que je viens de dire, le choix des outils vous appartient. Là où ça va commencer à être la joie, c’est que par définition, vous allez moins contrôler le contenu du message, ni la sécurité des comptes installés.

On démarre avec les comptes utilisateurs, et la gestion déplorable de leur sécurité. Très souvent, attendez-vous à entendre qu’une boite « s’est fait pirater » pour découvrir que le mot de passe faisait à peine trois caractères, autant dire que soit par un moyen tiers soit par bruteforce ça ne tient longtemps. Dans tous les cas, en dessous de dix caractères c’est pas la peine d’envisager qu’un utilisateur aura construit un mot de passe robuste et unique. Même moi je ne suis pas encore un bon élève de la gestion de mes mots de passes sur les différents services (j’en ai identifié plus de quarante). Si jamais le compte se fait trouer pour procéder à des envois massifs, préparez-vous à devoir gérer le blacklistage de l’adresse du serveur. Je conseille alors d’avoir plusieurs adresses, et de basculer sur une autre (une ligne dans un master.cf de postfix) le temps de faire les démarches auprès des gestionnaires de blacklists une fois les accès sécurisés. Imposer un minimum en termes de taille ou de complexité de mot de passe est toujours compliqué, et je n’ai pas de conseil définitif à apporter à ce sujet pour l’instant. D’autant que si pour les webmails ont peut toujours mettre en place de la double authentification, c’est beaucoup plus compliqué sur SMTP et IMAP qui ne sont pas prévus pour.

Si votre serveur doit héberger un nombre significatif de boites, il faudra probablement mettre des limites de nombres de mails à envoyer en simultanés, pour s’éviter le problème de refus évoqué plus haut en termes de mass mailing. Vous pensez que je délire ? Orange m’a déjà retardé pour la livraison d’un seul mail, en me demandant de réduire la cadence. Un seul. Pareil, pour faire bouger Orange, je vous souhaite bon courage.

Qui dit utilisateurs dit, et je suis désolé de le dire comme ça, incompétence totale. J’ai déjà commencé à aborder le sujet avec la gestion des mots de passe, c’est que le début. Vous aurez à régler les problèmes de quota (parce qu’ils ne sauront pas d’eux-même faire le ménage dans leurs anciens mails), les soucis de flux liés au fait qu’ils sont sur des réseaux bien filtrés de partout, avec leur appareil, le combo étant le wifi ouvert non chiffré avec portail captif, genre celui de la cité des sciences que je déconseille fortement. Ne pas évoquer les soucis de configuration des différents clients serait grossier de ma part, vous allez devenir un expert sur la plupart des logiciels du marché tous OS confondus, même ceux des plateformes que vous voulez éviter comme la peste, afin que votre service soit rendu. Prévoyez une interface la plus facile d’accès et la plus automatique possible pour la réinitialisation de mot de passe, parce que ceux qui ne l’auront pas stocké quelque part (sur un post-it évidemment), l’oublieront en permanence s’il n’est pas déjà utilisé sur la tétrachiée d’autre services sur lesquels ils sont inscrits vendus. Dans les éléments magiques aussi, on retrouve la gestion des mails en queue mais impossible à expédier parce que l’adresse saisie n’est pas valide (une fondation a des comptes sur son site dont plusieurs adresses mails sont en encore en voila.fr, service fermé il y a déjà plusieurs années maintenant, ou des gens qui pensent qu’il est possible d’avoir une boite mail en google.fr).

D’un côté plus technique, blindez le serveur que ce soit au niveau pare-feu ou protections supplémentaires. Je ne sais pas si c’est facile à mettre en place, mais par exemple si vous pouvez détecter une tentative de bruteforce sur un compte, il sera plus prudent de le verrouiller le temps de prendre des mesures à l’encontre de l’attaquant, tant pis pour la dégradation pour un client, vous avez tout le reste qui en dépend. Les attaques distribuées se multiplient (remember les instances publiques jetables), mais un moyen, typiquement fail2ban, de bannir temporairement l’adresse d’un attaquant permettra de réduire l’efficacité de celui-ci. Il y a d’ailleurs un point à surveiller : gérer un flot d’attaques demande des ressources, parfois musclées si le nombre de boites est important. Pensez aussi à redonder votre plateforme, afin de garantir une plus haute disponibilité. Je n’ai jamais eu à le faire, donc je ne connais pas bien les techniques exploitables pour ça, je vous laisse chercher si vous êtes concernés.

Et c’est sans doute pas tout 🙁

Je pense que c’est déjà un super pavé, et je vous suis reconnaissant si vous avez tenu jusqu’au bout. Malheureusement, je suis à peu près certains qu’il reste encore des choses à dire, des cas ou des spécificités que je n’ai pas pu traiter car je ne les ai pas encore rencontrés dans le cadre de mon travail, ou même à titre personnel (je n’héberge pas ma boite principale, je laisse ça à OVH, mais les boites clantoc.org oui). Donc si vous avez lu d’autres retours comme celui-ci, ou que vous souhaitez partager, compléter ou corriger des points abordés ici, faites-vous plaisir en commentaires. Moi je retourne à d’autres bricoles dont je vous parlerai bientôt 😉