Alors que les experts prédisent régulièrement la fin des e-mails, nous en recevons toujours une tonne et nous parions que vous aussi. Le courrier électronique existe depuis très longtemps et à l’époque, c’était assez high-tech de pouvoir envoyer une note demandant à chacun où il voulait aller déjeuner. Ce que nous avions sur nos ordinateurs à l’époque était également très différent. Considérez que le premier e-mail sur ARPANET remonte à 1971. À l’époque, certaines personnes avaient des terminaux papier. Les graphiques étaient inhabituels et votre stockage principal était probablement une fraction du plus petit lecteur flash que vous avez actuellement sur votre bureau. Personne n’envoyait de photos, de vidéos ou de fichiers PDF géants.
Aujourd’hui, les choses sont différentes. Nos ordinateurs ont des gigaoctets de RAM et des téraoctets de stockage. Nous produisons et consommons des documents richement formatés, des photographies à haute résolution et même des vidéos. Naturellement, nous voulons partager ces fichiers avec d’autres, mais le courrier électronique est devenu terriblement court. Bien sûr, certains systèmes proposeront de stocker votre gros fichier dans le cloud et d’envoyer un lien, mais envoyer par e-mail une vidéo de plusieurs mégaoctets à votre ami à travers la ville est plus susceptible d’échouer. Pourquoi?
La vie d’un e-mail
Comme vous vous en doutez, une partie de cela est due à des artefacts historiques. Le système n’a pas été conçu pour gérer votre dernière vidéo de vacances. Plus important encore, le courrier électronique est censé être largement interopérable sur une grande variété de systèmes. Bien sûr, de nos jours, il est peu probable que vos e-mails transitent par une paire torsadée reliant deux avant-postes éloignés, mais il pourrait.
Pour comprendre la genèse des limites, il faut savoir comment un e-mail vit sa vie. C’est beaucoup plus compliqué que vous ne le pensez. Aujourd’hui, le courrier voyage à l’aide d’un protocole appelé SMTP – Simple Mail Transfer Protocol. Prenons d’abord les cas simples.
Supposons que nous ayons une adresse e-mail Hackaday.com et que nous gérons nos propres serveurs de messagerie (ce n’est pas le cas, mais suivez-moi une minute). Un utilisateur se connecte au serveur SMTP et envoie un e-mail à une autre adresse sur Hackaday.com. C’est facile. Le serveur reconnaît qu’il est la destination finale de l’e-mail, il l’accepte et le livre. Que signifie livrer ? Cela dépend, mais cela signifie généralement mettre un fichier que l’utilisateur vérifiera avec un programme de messagerie ou avec un autre type de serveur comme POP3 ou IMAP. Mais pour nos besoins, cela signifie que le courrier est placé quelque part où l’utilisateur peut le trouver.
Un cas un peu plus difficile est celui où quelqu’un de, disons, wd5gnr.com veut envoyer un e-mail à quelqu’un chez Hackaday (encore une fois, en supposant que le domaine gère son propre e-mail, ce qui n’est plus aussi courant qu’avant) . Dans ce cas, l’utilisateur se connecte à son propre serveur SMTP. Il se rend compte que @hackaday.com est une adresse e-mail étrangère (peut-être à plus d’un titre) et recherche le domaine dans le répertoire DNS. L’un des enregistrements du DNS (l’enregistrement MX) est l’adresse du serveur de messagerie du domaine. Le serveur SMTP sur wd5gnr.com enverra alors le courrier à hackaday.com qui effectuera la livraison.
Et alors…?
C’est tout ce qu’il y a à faire, n’est-ce pas? Pas exactement. De nos jours, cette entrée DNS pointe plus que probablement vers un service comme un serveur Gmail ou une autre société d’hébergement qui acceptera réellement l’e-mail. Il est probable que l’expéditeur se connecte également au serveur d’un fournisseur. Alors peut-être que l’expéditeur se connecte au serveur SMTP de Zoho qui se connecte ensuite au serveur Gmail pour livrer le courrier.
Encore plus compliqué, c’est quand vous entrez dans des réseaux privés. Si le réseau wd5gnr est derrière un pare-feu, il peut ne pas être possible de contacter directement le serveur Hackaday, où qu’il se trouve. Quoi alors ? Un serveur SMTP peut accepter le courrier sur une interface, puis le relayer vers un autre serveur. Cela pourrait durer un certain temps. Par exemple, le serveur wd5gnr peut tout relayer vers Gmail qui trouve ensuite le serveur Hackaday principal qui l’envoie ensuite au serveur de messagerie interne pour la partie du monde dans laquelle se trouve l’utilisateur particulier.
Cela peut sembler farfelu, mais cela arrive tout le temps. Par exemple, vous pourriez être sur un navire en mer avec une connexion intermittente à une liaison satellite. Un serveur peut collecter des e-mails et attendre une connexion au satellite. Ensuite, il envoie le courrier à un serveur via la liaison satellite qui se chargera de le diffuser sur le réseau réel.
Vous pouvez voir pourquoi le courrier électronique a été si mûr pour l’exploitation. Les premiers serveurs permettaient à n’importe qui de se connecter et pouvaient même tenter de relayer le courrier pour n’importe qui. Le spam a changé tout cela, bien sûr, et maintenant un relais ouvert est une rareté. Certains serveurs SMTP vont jusqu’à rejeter le courrier provenant de serveurs ouverts connus. Ceci est controversé dans certains cercles comme une forme de censure, mais la majorité des serveurs vous demanderont désormais de vous authentifier et n’accepteront que les e-mails destinés à certains domaines sans authentification. Il existe également une augmentation des serveurs qui vérifient un enregistrement SPF pour s’assurer qu’un serveur est connu pour gérer le courrier d’un domaine particulier. DKIM va plus loin et utilise une signature cryptographique.
Le poids de l’histoire
Ainsi, le fait que le courrier quitte rarement, de nos jours, le réseau ou passe par un relais ouvert, le fait est qu’il le peut. Pourquoi est-ce important? Revenons au problème du navire en mer. Le serveur du vaisseau devra peut-être encoder nos e-mails dans un format farfelu ou les compresser. La station satellite au sol peut uniquement envoyer des e-mails via UUCP, ce qui nécessite un traitement supplémentaire. Les e-mails volumineux sont donc plus qu’un simple problème de bande passante du réseau. Le serveur peut avoir à traiter et convertir des fichiers. Par conséquent, SMTP peut nécessiter ASCII 7 bits, ce qui est idéal pour le texte. Mais pour tout ce qui est plus fantaisiste, le message (y compris les pièces jointes) est encodé en utilisant quelque chose comme l’encodage en base 64 tel que spécifié par MIME (Multipurpose Internet Mail Extensions). Cela signifie également que votre pièce jointe est susceptible de devenir encore plus grande après l’encodage.
Même un hôte entièrement connecté peut vouloir traiter les messages électroniques. Par exemple, il est courant de vérifier les charges utiles de spam ou de virus. Ainsi, même avec une bande passante réseau infinie, il existe toujours une surcharge de traitement associée aux pièces jointes volumineuses.
Certes, la puissance de traitement ne manque pas non plus de nos jours, mais certains serveurs de messagerie peuvent ne pas être à la pointe de la technologie, tandis que d’autres peuvent être touchés par des millions d’e-mails, dont beaucoup sont des spams.
Demandez à Hackaday
Comment envoyez-vous des fichiers volumineux ? Le courrier électronique devrait-il accepter des fichiers plus volumineux ? Pensez-vous que le courrier électronique est en voie de disparition? Remplacé par quoi ? Comment pourrait-il être plus facile? Il existe des services comme WeTransfer et SendAnywhere, mais honnêtement, nous sommes plus susceptibles de simplement télécharger un fichier sur l’un de nos serveurs et d’envoyer un lien de cette façon. Ensuite, il y a toujours le stockage en nuage comme Dropbox, Drive ou iCloud.
Nous avons parcouru un long chemin depuis les pigeons voyageurs. Là encore, peut-être que votre courrier passe également sur ce réseau. Si vous souhaitez approfondir davantage le SMTP, regardez la vidéo de l’Iowa State University ci-dessous.
