Même si en 2022 cela vous semble trivial d’envoyer un mail : on lance un client Outlook ou un Webmail dans un navigateur, on tape l’adresse du destinataire, un sujet et un texte, éventuellement une pièce jointe et on clique sur « envoyer »…hop le mail et parti et reçu quelques secondes après.
Il faut savoir que ce qui se passe derrière est très réglementé et malgré un protocole simplissime, tout est heureusement relativement sécurisé.
Le fondement du protocole
Le SMTP (Simple Mail Transfer Protocol) est le mode normalisé d’échange de mails. Même s’il existe des versions plus évoluées, vous devez toujours être en mesure d’utiliser sa version originale.
En effet, il s’agit s’un dialogue entre deux machines et il est impératif de pouvoir se mettre au niveau de la moins évoluée, donc envoyer à un serveur SMTP quelconque :
Hello
Mail from : monmail@mondomaine.fr
Rcpt to : destinataire@domainecible.fr
Data : blabla….
.
Tout cela suffit pour écrire et envoyer un mail.
J’image que vous voyez les limites du système : je me fais passer pour n’importe qui et j’envoie 1 ou 100 000 emails à n’importe qui.
Alors voyons donc comment on a amélioré cela. Pour simplifier, Il n’existe que deux modes d’échanges pour envoyer un mail :
- du client vers un serveur
- d’un serveur vers un autre serveur.
Le client de votre serveur
C’est ce que vous êtes lorsque vous envoyez un email : vous êtes authentifié vis-à-vis de votre serveur, votre email est validé et vous avez un mot de passe, tout est clair !
Votre serveur va donc accepter que vous envoyiez des emails à qui bon vous semble, de plus, en règle générale, le client et le serveur sont de la même source logicielle, et vous aurez donc probablement accès à un protocole sécurisé et chiffré qui n’a pas de raison de s’appuyer sur SMTP.
Reste que votre email est potentiellement destiné une personne externe et que donc, il va falloir que votre serveur le transfère.
Le transfert serveur à serveur
Tout d’abord, sachez que rien ne vous empêche de faire passer votre client pour un serveur et de l’utiliser pour se connecter à un serveur distant. Néanmoins, outre le fait que vous ne pourrez évidemment pas vous authentifier, le serveur distant risque fort de vous rejeter en interrogeant les serveurs DNS. En procédant ainsi, il peut vérifier que votre adresse IP est légitime pour envoyer des mails au nom du domaine dont vous prétendez être le serveur, en lisant ce que l’on appelle un enregistrement SPF (Sender Policy Framework).
Maintenant votre serveur (qui lui, est légitime pour envoyer des emails) va obtenir l’adresse du serveur distant en utilisant une propriété DNS du domaine cible : un des enregistrements MX (Mail Exchange).
L’échange est donc traité point à point entre chaque domaine. En règle générale l’utilisation de serveurs relais (pour envoyer d’un domaine A à un domaine C en passant par un domaine B) est bannie car elle ne permet plus de vérifier la légitimité des serveurs au long de la chaîne de transfert.
Autre point particulier du protocole, si le serveur distant est temporairement inaccessible, la RFC (Request For Comments) suggère un système de ré-essais normalisé avec des intervalles de plus en plus longs et un nombre maximum de tentatives. Cela explique les délais pour envoyer des mails et ceux pour savoir que l’on s’est trompé d’adresse.
Le concept est tellement ancien que les mails sont forcément envoyés au format texte et sur 7bits, alors pour s’adapter il a fallu utiliser un codage spécial, le format base64 capable de transformer des flux binaires en un texte pour respecter la norme.
Vous voyez les emails ce n’est pas si compliqué ! Sur ce, je vous parlerai à l’occasion des techniques plus ou moins couronnées de succès pour lutter contre les emails illégitimes : les SPAMS.
Ces articles pourraient vous intéresser :
Olivier Piochaud, PDG d’Apsynet
