Envoyer des emails en IPv6

Si vous prévoyez d’envoyer des emails en IPv6, attendez-vous à ce que les serveurs de réception appliquent des règles plus strictes qu’en IPv4 : un enregistrement PTR et une authentification réussie sont de fait obligatoires. Ces règles s’appuient sur un document du Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG), M3AAWG Policy Issues for Receiving Email in a World with IPv6 Hosts (M3AAWG084, septembre 2014).

Tenez compte de son âge. C’est un document de position et d’exigences de 2014, rédigé comme « une première liste d’exigences pour de futurs services », et non un guide opérationnel. Ses principales prédictions se sont vérifiées : les grands serveurs de réception, Gmail en tête, exigent bien un PTR valide et une authentification réussie sur les connexions IPv6. Considérez comme historiques ses références précises à des institutions, par exemple le groupe de travail WEIRDS de l’IETF, dont les travaux ont depuis abouti à RDAP.

Le problème de fond : la réputation par IP ne passe pas à l’échelle d’IPv6

• La lutte contre les abus en IPv4 repose sur la réputation de chaque adresse (/32) : limitation de débit, listes de blocage et évaluation de la réputation. C’est moins stable et moins fiable qu’on ne le souhaiterait, mais cela fonctionne, et « la plupart des systèmes antispam ne pourront pas fonctionner si l’efficacité de ces mécanismes est dégradée ».
• Les adresses /128 d’IPv6 cassent ce modèle. Suivre chaque /128 est irréaliste à grande échelle, et un expéditeur capable d’envoyer chaque email depuis un /128 unique rend inefficaces les mécanismes fondés sur une seule adresse.
• IPv6 rend donc indispensable la réputation fondée sur le domaine (associée ou non à une IP), ainsi que de meilleurs mécanismes d’agrégation des adresses.

Le M3AAWG a fixé trois objectifs pour l’email en IPv6 : agréger l’espace d’adresses en attributions qu’il est possible de suivre ; exiger des opérateurs qu’ils identifient les hôtes destinés à servir d’agents de transfert de messages (MTA) sortants ; et exiger un identifiant valide fondé sur l’authentification du domaine pour évaluer la réputation.

Recommandation 1 : suivre les attributions agrégées et agir sur elles, pas sur les /128

• Les mécanismes fondés sur l’IP (limitation du débit des connexions, listes de blocage) doivent traiter une plage IPv6 suffisamment large comme une seule entité pour rester efficaces. Une plage trop large provoque des faux positifs, car elle mélange les MTA d’acteurs sans rapport entre eux.
• Idéalement, les fournisseurs d’accès à Internet publieraient la taille de leurs agrégats via un service ouvert et standard que les mécanismes antispam pourraient interroger. À défaut, des conventions sur des frontières d’agrégation communes suffisent.
• Heuristique initiale : prenez le /64 comme taille d’attribution minimale par défaut. Selon la RFC 4291, les 64 premiers bits identifient le préfixe de routage et le sous-réseau, et les 64 suivants identifient l’interface, et il est peu probable qu’une seule interface héberge les MTA de plusieurs acteurs au volume significatif. Les opérateurs peuvent agir sur des plages plus larges ou plus étroites lorsque c’est pertinent, et les éditeurs antispam sont censés collecter des données sur la taille des attributions dans le cadre de leurs services.

Ce que cela implique pour les expéditeurs : tout le /64 (ou le bloc plus large) partage le même sort. Les dégâts de réputation causés par un hôte, ou par un client d’un fournisseur de services email (ESP), peuvent faire inscrire l’agrégat entier sur une liste de blocage. Segmentez l’envoi en IPv6 en attribuant un /64 distinct à chaque flux ou à chaque catégorie de clients, comme dans la pratique d’allocation des adresses IP.

Recommandation 2 : rejeter les emails des hôtes non identifiés comme MTA sortants

• Les botnets envoient des abus depuis des hôtes compromis dont les propriétaires n’ont jamais voulu en faire des MTA, donc n’accepter les emails que de sources explicitement autorisées réduit fortement la valeur des hôtes compromis. La gestion du port 25 sortant (la recommandation Port 25 du MAAWG) aide, mais elle n’est pas appliquée partout, et l’Internet des objets (IoT) va considérablement augmenter le nombre d’appareils vulnérables.
• Il n’existait aucune norme permettant aux opérateurs de déclarer quels hôtes sont destinés à servir de MTA sortants. SPF identifie les MTA sortants autorisés d’un domaine, mais « permet aussi à des propriétaires de domaines malveillants de désigner de grandes plages d’adresses IP qui ne leur appartiennent pas ». Le M3AAWG demandait une méthode standardisée, indexée par adresse IP, qui puisse être interrogée automatiquement. Rien de tel n’a été largement adopté depuis.
• Le mécanisme provisoire est le DNS inverse. De nombreux opérateurs rejettent déjà les connexions IPv4 sans enregistrement PTR, ou les jugent très suspectes. En IPv6, c’est un filtre passe-haut encore plus efficace, car les opérateurs ne publieront pas d’enregistrements PTR pour l’immense majorité de leur espace IPv6 (le bénéfice est faible, et c’est fastidieux à cette échelle), alors qu’il est tout à fait possible de maintenir des enregistrements PTR pour le petit nombre d’hôtes relais dédiés.
• « En l’absence d’un mécanisme plus approprié […], le M3AAWG recommande de rejeter les emails provenant d’adresses IPv6 d’hôtes dépourvues d’enregistrements DNS inverse », jusqu’à ce qu’une meilleure norme existe (aucune ne l’a remplacée).

Ce que cela implique pour les expéditeurs : chaque adresse IPv6 d’envoi doit avoir un enregistrement PTR et, comme les serveurs de réception l’attendent en général, une confirmation directe concordante. Un PTR absent en IPv6 justifie un rejet pur et simple, et pas seulement de la méfiance.

Recommandation 3 : rejeter les emails sans authentification de domaine valide

• Le besoin d’identifiants de réputation stables et exacts est encore plus grand en IPv6 qu’en IPv4, et les noms de domaine sont nettement plus stables que les adresses IP, même en IPv4.
• DKIM et SPF fournissent le domaine authentifié qui permet d’imputer la responsabilité : la valeur d= de DKIM, et le domaine MAIL FROM de l’enveloppe pour SPF (ou le domaine EHLO ou HELO pour les rebonds). Les grands fournisseurs avaient déjà déployé la réputation de domaine en complément de la réputation d’IP.
• « Le M3AAWG recommande donc d’évoluer vers le rejet des emails qui ne contiennent pas de signature DKIM valide ou qui ne réussissent pas les vérifications SPF », ce qui permet une réputation cohérente et fiable, fondée sur le domaine authentifié, pour les décisions de livraison.

Ce que cela implique pour les expéditeurs : en IPv6, un email non authentifié n’est pas seulement pénalisé ; la position du secteur est qu’il doit être rejeté. C’est exactement ce que Gmail et les autres grands fournisseurs ont adopté pour les connexions IPv6 (voir Exigences de Gmail envers les expéditeurs : la livraison en IPv6 exige un enregistrement PTR et la réussite de SPF ou de DKIM). N’envoyez jamais en IPv6 depuis un flux dont SPF et DKIM ne sont pas parfaitement en ordre. Lorsque vous activez IPv6 sur un MTA, vérifiez d’abord l’authentification, sinon attendez-vous à des rebonds définitifs que le même flux ne subirait pas en IPv4.

Domaines responsables

Des informations WHOIS exactes sont « un élément essentiel de la réputation d’un domaine ». Des enregistrements WHOIS complets devraient être obligatoires pour les domaines qui agissent comme clients SMTP, avec des contacts abuse fonctionnels. (Le document renvoie au remplaçant du WHOIS étudié par le groupe de travail WEIRDS de l’IETF, qui a abouti à RDAP.)

Synthèse pratique pour un ESP (le document de 2014 et la pratique actuelle)

IPv6 ne laisse presque aucune tolérance aux erreurs d’authentification, et la livraison en double pile rend les échecs intermittents (les messages passent tantôt par IPv6, tantôt par IPv4). Pour ces raisons, de nombreux ESP préfèrent encore délibérément IPv4 pour les emails marketing sortants, ou n’activent IPv6 que sur des flux dont l’authentification est éprouvée.

Voir aussi

• Pratiques d’infrastructure d’envoi
• SPF
• DKIM