De près ou de loin on connait tous SMTP. En 2022, l’énorme majorité des humains l’utilise quotidiennement sans bien sûr forcément le savoir. Vous pouvez l’avoir étudié et avoir oublié une bonne partie de son fonctionnement et comment il s'inscrit techniquement dans ses intéractions avec les autres technologies, ou alors vous ne l’avez jamais appris et vous avez une vague intuition du fonctionnement des e-mails.
C’est pareil pour tout le monde, y compris pour les SI de gigantesques sociétés contemporaines. Et c’est justement dans ce cadre que j’ai eu la chance de rejoindre une mission OCTO. Il m’a fallu me remémorer de lointains fondamentaux et pousser plus loin mes connaissances techniques du sujet, mais l’expérience qui a pu en être tirée est, j’ai envie de dire “évidemment”, plus intéressante.
On va faire ça ici : rappeler des fondamentaux techniques ; parler REX (Retour d'EXpérience).
Imaginez les villes, les maisons et les immeubles, tous interconnectés par des réseaux routiers de diverses tailles. Peu importe votre provenance, votre nationalité même. Peu importe votre véhicule, ou que vous soyez simplement à pied. Dans une certaine mesure, vous avez toute la liberté nécessaire pour vous déplacer d’une ville à une autre, d’une maison à une autre. Personne ne peut réellement vous empêcher de sonner chez quelqu’un ou de glisser une lettre dans sa boîte aux lettres si ce quelqu’un en a une (on peut toujours aussi passer une lettre par dessus une grille ou sous une porte).
Le SMTP, le “Simple Mail Transfer Protocol” (Simple Protocole de Transfert de Mel), c’est ça, mais sur Internet au lieu des routes, et sur des ordinateurs au lieu de centres postaux ou de boîtes aux lettres (même si on appelle ces dernières de la même manière).
Le SMTP c’est un peu ce protocole inarrêtable open-source de communication indirecte, gratuit et accessible à tous sur cet espace ouvert et presque totalement neutre qu’est Internet.
C’est paradoxalement un problème car il n’a pas ainsi été pensé dès le départ pour une utilisation “sécurisée”. Si je veux arpenter les rues et déposer une lettre chez quelqu’un en indiquant qu’elle provient d’Elon Musk, non seulement je le peux, mais il sera très difficile d’affirmer ou d’infirmer sa provenance (on ne parle pas de probabilités). Ça se comprend, et pour SMTP c’est pareil ! Pourtant depuis des millions de milliards d’e-mails sont passés sous les ponts TCP/IP et DNS, et SMTP s’est tellement démocratisé que des problèmes de réputations se sont posés.
De réputations, car l’usurpation d’identité est d’une facilité déconcertante. Ci-dessous, je donne un faux rendez-vous à Albert, de la part de Benjamin, en quelques lignes de commandes, dans le protocole SMTP :
Oui, il y a bien sûr des subtilités, car de l’eau à couler sous les ponts, donc. On peut voir en première ligne que je passe, en utilisant Telnet, par un serveur SMTP sur le port 25 de mon fournisseur d’accès Free, chez moi, avec mon IP publique (à priori, parce que je pourrais utiliser d’autres subterfuges…). Et puis on peut voir que le protocole ESMTP est utilisé avec un Postfix…
Et puis surtout, je n’ai pas validé l’envoi !
Je n’ai pas validé pour accentuer l’effet, mais je ne suis en réalité pas sûr à 100% que le mail ci-dessus passerait toutes les vérifications établies depuis. J’ai plutôt bien respecté le protocole SMTP (J’ai bien demandé à parler en SMTP avec la commande “HELO”).
La première réponse du serveur SMTP “220 smtp1-g21.free.fr ESMTP Postfix” m’indique à qui j’ai à faire, quelle langue il parle et en partie ce qu'il est capable de réaliser.
“220” m’indique que la connexion est opérationnelle
“smtp1-g21.free.fr” est son nom
“ESMTP” signifie qu’il comprend les commandes Extended SMTP
Parmi ses possibilités on retrouvera donc celle d’une connexion sécurisée par TLS
On ne se limite plus à du texte pur, on peut utiliser le format MIME
“Postfix” signifie enfin que l’on discute maintenant avec un serveur géré par le logiciel libre Postfix
Avant de prendre un peu de hauteur pour parler plus avant de son nom et du logiciel serveur, un point sur ESMTP. Il est intéressant de remarquer que SMTP est vraiment “simple”. Il est basé sur du texte et sur les courriers papiers, et sa structure sera reprise plus tard pour HTTP (HyperText Transfer Protocol) :
Une enveloppe
Elle contient l’adresse email de l’expéditeur (FROM)
Elle contient l’adresse email du destinataire (TO)
Un message (DATA)
Il contient d’abord des en-têtes (headers ; e.g. “Subject:”)
Une ligne vide ([CRLF])
Il contient ensuite le corps du message (body)
Un point “.” seul sur la dernière ligne, validé ([CRLF]; [.]; [CRLF])
En comparaison, une requête HTTP a la structure suivante :
Ligne de commande (une sorte d’enveloppe…)
En-tête (header)
Une ligne vide ([CRLF])
Corps de la requête (body)
Une ligne vide validée ([CRLF]; [CRLF])
Une réponse HTTP est similaire.
Chaque en-tête du message (partie DATA) figure sur une ligne sur un format “Clef: Valeur”. Suivant le serveur un certain nombre d’en-têtes seront obligatoires ou optionnels, cependant, si il n’y a ni expéditeur ni destinataire, on ne ferait pas du SMTP, donc ces champs sont toujours obligatoires (l’obligation pour l’expéditeur est bien sûr nuancée…).
Il est possible d’ajouter des en-têtes spécifiques personnalisés commençant par “X-”. Par exemple “x-microsoft-antispam:” dans un email OCTO interne.
Ces en-têtes personnalisables vont permettre tout un tas d’options suivant les applications qui les interpréteront. Des anti-spams, par exemple, comprenant notamment des outils qui décèlent des tentatives d’usurpations d’identités évoquées plus haut…
Mon email usurpant l’identité de Benjamin passerait-il ? Tout dépend donc en grande partie des paramétrages de mon fournisseur (Free) sur le Postfix de “smtp1-g21.free.fr”.
Pourquoi ai-je donc tenté de passer par le serveur SMTP de mon FAI ? Est-ce obligatoire ?
Essayons avec un serveur SMTP de Google. Pour cela je dois d’abord découvrir le nom du serveur SMTP. Auparavant, je connaissais déjà le serveur SMTP de mon FAI (smtp.free.fr). J’utilise donc la commande “host” dans le terminal pour avoir un peu plus d’informations (qui sont publiques). Enfin, j’essaye de reproduire mon usurpation :
Je pourrais attendre longtemps une réponse : Google attend de moi une connexion sécurisée et probablement une authentification. Et peut-être même que mon FAI via mon compte ou via ma box (ou les deux) filtre mes intéractions avec Telnet, le port 25 et Google…
Néanmoins, en passant à des niveaux supérieurs, notamment en sécurité, on devrait pouvoir se connecter chez Google et parler SMTP.
Je tente l’expérience avec OpenSSL pour parler TLS sur le port 587 :
C’est raté. En réalité “smtp.google.com” ne comprend rien à ce que je dis. Je passe les détails de syntaxe qui seraient nécessaires. Au final, il faut changer d’interlocuteur et utiliser “smtp.**gmail**.com” pour notre exemple (notons qu’un telnet ne fonctionne pas non plus et que TLS est toujours nécessaire) :
La réponse :
[...]
Tout cela n’est pas très digeste mais illustre que la connexion SMTP est possible à condition de réduire l’écart entre le SMTP de départ et tout ce qui a été mis en place depuis le début des années 80 :
Authentification sur des serveurs SMTP et par des FAI
Filtrage des serveurs SMTP et des FAI
Extension du protocole (ESMTP, MIME, ou encore RFC…)
Chiffrement des communications (SSL/TLS, Cryptographie Moderne (on peut voir SHA256, ECDSA, X25519 ou AES ci-dessus en capture par exemple))
Reste que le SPAM est toujours présent. Les questions de réputation demeurent !
Soyons plus légers et prenons de la hauteur. Un peu d’architecture pour se situer. Ci-dessous, voici un schéma de simplification utilisé en mission pour donner une perception des éléments à prendre en compte pour la migration à l’international de tout le système d’e-mails. Cette migration étant inscrite dans la migration globale du SI.
On notera que même si la mission ne portait que sur le SMTP, et donc la partie envoi d’emails, il était nécessaire de considérer la partie réception. D’autant plus que ce schéma permettait également de mettre en lumière la foule d’intéractions des emails avec toutes les parties du SI. Nous reviendrons sur ce point très important.
Soit une machine programmée pour, soit un humain, utilisera un programme (sous forme de script ou autres clients) pour s’exprimer en SMTP. Puis, on s'intéresse au premier serveur d’envoi (MTA ; Mail Transfer Agent), on passe par Internet de MTA en MTA (voir la section suivante) pour enfin arriver au serveur e-mail final, qui contient la boite e-mails du destinataire (humain ou machine…).
Sans même parler des modèles ou format de données, ce schéma simplifié de fonctionnement a aussi eu le mérite de démontrer le nombre vertigineux de combinaisons de cas possibles : chaque ressource du schéma (en dehors d’Internet) devant être conservée, supprimée ou modifiée… Et ce en envoi ou en réception…
C’est paradoxalement ce qui fût très difficile à faire appréhender au client malgré la relative “simplicité” d’SMTP.
Pour envoyer un mel avec SMTP, il est nécessaire d’utiliser la résolution DNS (Domain Name Service (ou Server)). Il est important d’en parler car c’est avec l’aide du protocole DNS qu’un e-mail trouve son chemin sur Internet pour sauter d’un MTA à un autre (“hop”), mais il permet également de maîtriser la réputation des noms de domaine utilisés dans les adresses mail, après le arobase “@” (e.g. : bob@octo.com).
Si j’envoie un email vers “bob@octo.com”, que se passe-t-il au niveau des MTA sur Internet ? Concrètement, ce n’est pas si facile à se représenter. C’est l’une des difficultés à laquelle j’ai été confronté, et qu’il m’était donc difficile d’exposer au client.
D’abord récapitulons les étapes de transmission de base :
J’utilise SMTP vers “bob@octo.com”, le réseau Internet doit donc conduire mon e-mail vers la boîte de réception correspondante, ce qui signifie que le mail doit être dirigé vers le serveur de réception correspondant. Il faut donc l’IP de ce serveur, car nous sommes sur Internet.
Au niveau local, mon programme (CLI Telnet, ThunderBird, Gmail…) contacte mon premier serveur DNS local : dans mon exemple, ma Freebox !
Dans une configuration par défaut, ma Freebox contacte ensuite un serveur DNS de Free (donc sur Internet)
Le DNS de Free connait peut-être déjà l’IP de “octo.com” grâce à un enregistrement DNS
Si oui, il renvoie directement l’IP vers moi et mon programme prend alors contact avec le serveur de réception
Si non, il interroge un serveur DNS “racine” (root) symbolisé par une adresse lisible sous la forme d’un point “.”. Exactement comme si on avait écrit “octo.com**.**”
Le serveur DNS racine qui répond (il y en a plusieurs) nous redirige vers un serveur DNS gérant les “.com**.**” avec son IP
Le serveur DNS qui gère des “.com**.**” nous redirige vers un serveur DNS gérant “octo.com**.**” avec son IP
Le serveur DNS gérant “octo.com**.**” nous indique le serveur gérant la réception des emails en “@octo.com**.**” et nous pouvons ainsi retrouver son IP
On devrait ici se poser une simple question : Comment un serveur DNS connait-il l’adresse IP d’un autre serveur DNS gérant une partie de nom de domaine ? Où sont donc mémorisées ces adresses IP ? Sous quel format ?
Ces adresses sont conservées sur chaque serveur dans un fichier texte : le fichier de zone.
Il ressemble vraiment à ce qui suit :
Seul un administrateur ayant accès au serveur peut modifier un tel fichier.
Et oui, il n’y a pas seulement un tableau de correspondance entre nom de domaine et adresses IP, le protocole permet bien plus à l’aide en particulier de lignes spécifiques que l’on appelle des “enregistrements DNS” (DNS records).
L’une de mes difficultés était de comprendre concrètement où se situent certains enregistrements DNS. Car si l’on comprend assez aisément où sont les fichiers pour une redirection lors d’une résolution DNS avec les étapes précédentes, il devient plus subtile de savoir sur quels serveurs peuvent être stockés les enregistrements DNS lorsque ceux-ci ont été introduits au fil des années en plus des chiffrements TLS ou des extensions SMTP pour maîtriser le SPAM et la réputation des noms de domaine.
Où place-t-on concrètement un enregistrement SPF ?
Où place-t-on concrètement un enregistrement DKIM ? La clef privée correspondante ? La clef publique ? Un sélecteur ?
Ces deux derniers enregistrements DNS évoqués sont les principaux avec lesquels il a fallu jongler durant la mission. Ils peuvent être utilisés indépendamment ou en même temps.
L’enregistrement SPF (Sender Policy Framework ; “Framework de Politique Expéditeur”) permet à un serveur DNS d’appliquer des règles de filtrage en fonction du champ “FROM” d’un e-mail en SMTP. Il n’y a qu’un seul enregistrement SPF possible dans un fichier de zone, et il est public. Par exemple, l’enregistrement SPF d’“octo.com” est visible avec la commande “host -t TXT octo.com” :
v=spf1 include:sendgrid.net include:servers.mcsv.net include:mailgun.org include:_spfa.exchange.accenture.com include:_spfb.exchange.accenture.com ip4:205.220.165.99 ip4:205.220.177.99 -all
On peut voir que “sendgrid.net” peut envoyer légitimement des emails en utilisant le nom de domaine “octo.com”. Attention, la notion de légitimité est extrêmement importante. On l’a vu, même ma Freebox peut tout à fait également envoyer un email en “octo.com”, mais pas du tout légitimement : mon adresse IP par exemple ne figure pas dans l’enregistrement SPF ci-dessus !
Si je continuais d’utiliser à tort et à travers un nom de domaine de façon illégitime, je pourrais être bloqué ou même nuire à la livraison des e-mails du nom de domaine utilisé (si justement il n’y avait pas ce type d'enregistrement).
A retenir ici, l’enregistrement unique SPF est relativement facilement exploitable et on peut le récupérer même sans administrateur. On notera tout de même que les informations peuvent être partielles : je ne sais pas du tout ici à quoi correspond l’IP “205.220.177.99”...
Plus “fort” que l’enregistrement SPF, l’enregistrement DKIM utilise la Cryptographie Asymétrique pour lier l’e-mail au nom de domaine par une signature électronique. Il permet en outre de protéger le contenu du mail contre l’altération au fil des hops (une modification du corps du mail modifie le hash de ce corps présent dans l’en-tête DKIM, par exemple). Un enregistrement DKIM ressemble à ceci :
v=DKIM1; k=rsa; t=s; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC1TaNgLlSyQMNWVLNLvyY/neDgaL2oqQE8T5illKqCgDtFHc8eHVAU+nlcaGmrKmDMw9dbgiGk1ocgZ56NR4ycfUHwQhvQPMUZw0cveel/8EAGoi/UyPmqfcPibytH81NFtTMAxUeM4Op8A6iHkvAMj5qLf4YRNsTkKAV;
Gardons en tête la longueur de la clef publique (“p”) pour la suite.
Cette fois, il peut y avoir plusieurs enregistrements DKIM pour un nom de domaine donné. Concrètement, cela veut dire que pour un même nom de domaine nous pouvons avoir plusieurs clefs publiques enregistrées : chaque enregistrement (clef publique) identifie une entité qui peut légitimement envoyer des emails avec le nom de domaine considéré. Chaque clef privée correspondante est (normalement) connue uniquement de chaque entité légitimée. Cette clef privée sert à signer chaque email émis par une entité légitime : chaque signature de chaque email est différente, on ne peut donc pas imiter une signature en la copiant d’un e-mail précédent.
Cependant, attention, dans le fichier de zone, il n’y a pas seulement une association entre nom de domaine et clef publique, il est aussi nécessaire de connaître le “sélecteur” (selector). Ce dernier permet de sélectionner la bonne clef publique à utiliser en réception (mais aussi la bonne clef privée en émission) : il faut bien comprendre qu’il peut y avoir plusieurs en-têtes DKIM, et donc plusieurs signatures, dans un même email, puisque nous pouvons avoir plusieurs entités légitimes ! Il peut y avoir également d’autres noms de domaine que celui du mail, mais ne compliquons pas plus.
Le sélecteur est arbitraire, il peut être n’importe quelle chaîne de caractères. On ne peut donc pas forcément le reconnaître… Il permet de constituer un nom de domaine de la forme :
selecteur._domainkey.octo.com
Et pour ce nom de domaine, on a une clef publique indiquée…
Nous venons de mettre le doigt sur ce qui m’a posé problème pendant la mission et mes enquêtes nécessaires pour faire un état des lieux SMTP. En effet, si j’ai pu écrire un script pour récupérer assez facilement les enregistrements SPF des noms de domaine utilisés par le client, c’est tout bonnement impossible de faire la même chose avec les enregistrements DKIM. Pourquoi ? Ces informations ne sont-elles pas publiques ? Si ! Pourtant, où se trouvent-ils ? On pourrait penser qu’il suffit d’utiliser la commande précédente “host -t TXT nom.de.domaine”, les enregistrements DKIM étant du type TXT. Essayons pour illustrer de récupérer les enregistrements DKIM d’octo.com :
Surprise ! Aucune clef DKIM ! On peut le vérifier facilement avec la longueur des chaînes de caractères, et de toute façon il manque des paramètres (la version, le protocole de chiffrement etc.).
Avez-vous l’explication ? La réponse est “simple”, ce n’est pas les enregistrements de type TXT d’octo.com qu’il faut chercher, mais les enregistrements TXT de “selecteur._domainkey.octo.com” ! Or, il n’y a pas de commande permettant de déterminer un sélecteur. Encore moins dans une liste d’environ 750 noms de domaine… Surtout quand cette liste n’arrive que 2 mois après le début de la mission, et qu’elle n’est ni certaine, ni complète.
Avec ce tour d’horizon, on perçoit mieux comment s’inscrivent les détails de cette communication inarrêtable SMTP dans le contexte d’une migration de système d’emails suite au rachat d’une gigantesque compagnie internationale par une autre tout aussi gigantesque. Imaginons un instant les volumes d’échanges, les différents cloud providers, les SaaS, et ce dans presque tous les pays…
Et bien ce n’est pas le pire.
Les emails dans un SI, et même sur Internet, ou le web, c’est un support. C’est même un support immense. Les e-mails fonctionnent tellement bien qu’ils sont source de confiance et même permettent d’obtenir des preuves ou des faisceaux de preuves dans le cadre légal. Bien évidemment, c’est parce que SMTP fonctionne très bien. Comme sans DNS ou TCP/IP, sans SMTP, beaucoup de choses s’écroulent. Si l’on prend du recul, les e-mails au sens large servent :
L’identification
Identifiant de compte
Création de compte
Récupération d’un mot de passe de compte
La communication dans l’entreprise
Interne
Externe
Par tchat ou vidéo-conférence
De preuves ou traces de communication
De système d’alertes
De coordonnées de contact avec l’Etat, les organismes, des clients, des vendeurs
La prise de rendez-vous
Présentiels
Distanciels
Dans un SI, les emails et SMTP sont donc liés :
À la sécurité
Aux VPN
Aux règles d’accès aux ressources
Aux badges d’accès physique au locaux
Aux alertes du réseau
Aux alertes des cloud providers
Sécurité
Coûts
Aux licenses logicielles ou autres
Aux sites web
Aux applications web
Aux achats de matériel
Aux ordinateurs des employés
Aux comptes bancaires
Aux salaires
Aux prestataires
Aux clients
Et en particulier pour finir :
En bref, SMTP est partout, même si tout le monde l’a oublié, même jusqu’à comment il fonctionne. Si SMTP ne peut fonctionner pour une quelconque raison technique ou non, un pan entier d’une migration de SI ne peut s’opérer correctement. Par exemple, comment fournir un accès VPN à un employé utilisant toujours son ancien e-mail sur une seule machine ? Est-ce par ailleurs son ancienne machine ?
Les raisons entravant le fonctionnement d’SMTP peuvent être entièrement juridiques ou légales. Une dimension absolument non-négligeable des adresses e-mail est le droit de propriété intellectuelle de la partie “nom de domaine” suivant le “@”.
Lors d’un rachat d’une compagnie par une autre comme dans le cadre de cette mission, la compagnie achetante n’ayant pas la possibilité d’acquérir l’intégralité des ressources de la compagnie acquise (il y aurait concurrence déloyale, surtout pour un monopole mondial), la compagnie absorbée conserve son existence et son image de marque, donc sa marque, son nom, et donc bien souvent son nom de domaine le plus représentatif.
Si la compagnie acheteuse n’obtient pas de droits d’usage sur ce nom de domaine, la totalité des systèmes qui utilisent des e-mails avec ce nom de domaine est à l’arrêt sous peine d’amendes conséquentes.
Légitimement, des clauses et des conditions sont données pour user de ces noms de domaine au moins pendant la migration, pour éviter une rupture violente du métier.
Un double problème se présente alors car les juristes éditant ces clauses et conditions, ainsi que les cabinets qui contrôlent le respect de celles-ci avant, pendant et après la migration, connaissent encore moins SMTP, ou DNS.
Ainsi la relative “simplicité” d’SMTP n’a plus d’importance. Ce qui est important, c’est où il s’inscrit dans l’architecture du SI et les workflows (du SI et de la migration).
Pour organiser une migration de SI, on aura une juste tendance à cloisonner certains sujets en isolant leur migration propre, en dédiant une équipe sur chaque sujet, puis à désigner des organisateurs plus globaux. Ces derniers recueillent, comme ce fût le cas pendant cette mission, diverses métriques afin d’exposer au client l’état d’avancement de chaque migration, puis consolident un état d’avancement global de toute la migration du SI.
Cependant, certains sujets comme le SMTP ou encore le réseau ne peuvent pas se cloisonner autant ou de la même manière, et avec les mêmes échelles de mesure. Ces sujets sont transverses et s'immiscent un peu partout, augmentant ainsi les délais.
Le cadre juridique donne des délais basés sur la complexité d’un petit ensemble de technologies sensées êtres “simples”, bien connues depuis longtemps, éprouvées. C’est parce qu’elles sont “simples” et utilisées depuis longtemps qu’elles servent justement de support à une grande quantité d’autres technologies et de fonctionnements transversaux.
Le cadre juridique n’est pas défini avec suffisamment de hauteur, et parfois les manques sont également au niveau technique juridique plus qu’informatique : pendant la mission, le cabinet juridique servant d’intermédiaire avec la compagnie achetée avait non seulement beaucoup de mal à identifier les informations que nous demandions (ne sachant pas vraiment à qui s’adresser par manque de distinction entre les différents types de données), mais avait même tronqué des informations — voire refusé de nous fournir ces informations — qui pourtant sont publiques, les considérant confidentielles ! Il s’agissait tout bonnement des noms de domaine que la compagnie acheteuse devait cesser d’utiliser…
Plusieurs mois se sont écoulés avant que nous ayons pu avoir une liste suffisante. Dans cet exemple, l’information est toujours suffisamment présente, mais dans bien des cas, elle s’est perdue parce que si tout fonctionne, on finit par l’oublier, ou parce que la personne en charge n’est plus là. Or, au même niveau de “magie noire” qu’opère SMTP, il y a le “shadow computing”, absolument nécessaire mais presque jamais documenté.
Comment faire un bon état des lieux dans ces conditions, quand il est même difficile de trouver et prendre contact avec le bon interlocuteur, le sachant ? On comprend bien maintenant que le problème n’est pas le fonctionnement du protocole SMTP, des emails ou de DNS, mais bien les processus dans lesquels il s’imbrique.
Si on omet une application quel que soit son type envoyant des emails par exemple vers des clients, on expose non seulement notre client à des amendes mais aussi à des ruptures business ayant diverses conséquences, parfois réellement désastreuses.
Par exemple, il peut s’agir d’un script bash sur un petit serveur Postfix dans un placard en Espagne qui réalise des translations d’adresses e-mails pour l’achat de billets d’avion, une fois par mois. Rien de grave.
Par contre, dans le contexte de la mission, un oubli d’une application web cruciale accessible derrière un nom de domaine devant être libéré a failli mettre en péril toute une zone géographique aux Etats-Unis, les prestataires utilisant cette application pour géolocaliser des ressources physiques indispensables non seulement pour la population locale, mais aussi pour assurer la continuité du métier. La solution, qui ne concernait pas la partie SMTP (la partie DNS et sites webs était cloisonnée dans un autre groupe de travail), fût juridique, en allongeant les délais d’utilisation du nom de domaine par dérogation expresse.
La taille du SI, la taille des entreprises, augmentent le nombre de paramètres, d’intéractions, et déstabilisent une hiérarchie classique en intensifiant l’effet “tour d’ivoire”, surtout face à une organisation en réalité très distribuée car disparate, et un protocole décentralisé comme SMTP (ou DNS).
Encore et toujours, pouvoir naviguer sur différents plans organisationnels et niveaux d’abstraction paraît ici tout aussi voire plus important que comprendre dans le détail comment fonctionne un protocole informatique.