Envoyer des emails en IPv6

Source : M3AAWG Policy Issues for Receiving Email in a World with IPv6 Hosts (M3AAWG084, septembre 2014). Attention à l’âge du document : il s’agit d’un document de position et d’exigences de 2014, rédigé comme « une première liste d’exigences pour de futurs services » (an initial list of requirements for future services), et non d’un guide opérationnel. Ses principales prédictions se sont vérifiées (les grands récepteurs, Gmail en tête, exigent bien un PTR valide et une authentification réussie sur les connexions IPv6), mais considérez comme historiques les références institutionnelles précises (par exemple le groupe de travail WEIRDS de l’IETF, dont les travaux ont 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 par adresse (/32) : limitation de débit, listes de blocage, évaluation de la réputation. Moins stable et fiable qu’on ne le souhaiterait, mais praticable, et « la plupart des systèmes antispam ne pourront pas fonctionner si l’efficacité de ces mécanismes est dégradée » (most anti-spam systems will be unable to function if the effectiveness of these mechanisms are degraded).
• L’espace d’adresses /128 d’IPv6 casse ce modèle : suivre chaque /128 est irréaliste à grande échelle, et un expéditeur capable d’émettre chaque email depuis un /128 unique rend inefficaces les mécanismes par adresse.
• L’arrivée d’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.

Les trois objectifs du M3AAWG 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 de MTA sortants ; 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 regrouper une plage IPv6 suffisamment large en une seule entité pour rester efficaces ; une plage trop large provoque des faux positifs en mélangeant les MTA d’acteurs sans rapport entre eux.
• Idéalement, les fournisseurs d’accès 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 : prendre 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, les 64 suivants l’interface ; il est peu probable qu’une seule interface héberge les MTA de plusieurs acteurs à volume significatif). Les opérateurs peuvent agir sur des plages plus larges ou plus étroites lorsque c’est pertinent ; les éditeurs antispam sont censés collecter les données de taille d’attribution dans le cadre de leurs services.

Conséquence pour l’expéditeur : 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’ESP, peuvent faire inscrire l’agrégat entier sur une liste de blocage. Segmentez l’envoi IPv6 en attribuant des /64 distincts par flux ou par catégorie de clients, sur le modèle de la pratique d’allocation des IP.

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

• Les botnets émettent des abus depuis des hôtes compromis dont les propriétaires n’ont jamais voulu en faire des MTA ; limiter l’acceptation aux sources explicitement autorisées dévalue fortement les hôtes compromis. La gestion du port 25 sortant (recommandation Port 25 du MAAWG) aide, mais n’est pas appliquée partout, et l’IoT va considérablement augmenter la population d’appareils vulnérables.
• Il n’existait aucune norme permettant aux opérateurs de déclarer leurs MTA sortants prévus. 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 » (also permits malicious domain owners to identify large ranges of IP space that they do not actually own). Le M3AAWG demandait une méthode standardisée, interrogeable automatiquement et indexée par IP (rien de tel n’a été largement adopté depuis).
• Mécanisme provisoire : 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 de PTR pour l’immense majorité de leur espace IPv6 (peu d’intérêt, fastidieux à cette échelle), alors qu’il est tout à fait possible de maintenir des 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 » (In the absence of a more appropriate mechanism … M3AAWG recommends rejecting email from host IPv6 addresses without reverse DNS records), recommandation appelée à disparaître dès qu’une meilleure norme existera (aucune ne l’a remplacée).

Conséquence pour l’expéditeur : chaque adresse IPv6 d’envoi doit avoir un enregistrement PTR et (selon la pratique générale des récepteurs) une confirmation directe concordante. Un PTR absent en IPv6 justifie un rejet pur et simple, 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 ; 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/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 » (M3AAWG therefore recommends moving toward rejecting email that does not contain a valid DKIM signature or that does not pass SPF checks), afin de permettre une réputation cohérente et fiable du domaine authentifié dans les décisions de livraison.

Conséquence pour l’expéditeur : 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 le comportement adopté par Gmail et les autres grands fournisseurs pour les connexions IPv6 (voir Exigences de Gmail envers les expéditeurs : la livraison en IPv6 exige un PTR et la réussite de SPF ou de DKIM). N’envoyez jamais en IPv6 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 ou attendez-vous à des rebonds définitifs que le même flux ne subirait pas en IPv4.

Domaines responsables

L’exactitude du WHOIS est « un élément essentiel de la réputation d’un domaine » (a critical component of a domain’s reputation) ; un WHOIS complet devrait être obligatoire 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 (document de 2014, pratique actuelle)

Comme la tolérance d’IPv6 aux erreurs d’authentification est quasi nulle et que la livraison en double pile rend les échecs intermittents (les messages passent tantôt en v6, tantôt en v4), 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.