Le courrier électronique existe sous une forme ou une autre depuis les années 1960. Les gens se laissaient des messages les uns aux autres en utilisant un certain nombre de méthodes différentes sur les ordinateurs centraux, mais ce n'est qu'en août 1982, lorsque l'Information Sciences Institute a publié The Simple Mail Transfer Protocol (SMTP ; RFC 821), qu'une méthode normalisée d'envoi et de réception du courrier électronique a été proposée.
Le protocole SMTP s'est rapidement imposé sur l'ARPANET, remplaçant les anciennes méthodes plus complexes utilisées pour transférer le courrier d'un ordinateur central à un autre. Il a été pris en charge pour la première fois fin 1982 par Sendmail, l'un des premiers agents de transfert de courrier, dans la version 4.1c de BSD.
Depuis lors, le protocole a été révisé et étendu assez régulièrement, mais le principe de base de l'envoi de courriers électroniques est resté pratiquement inchangé.
Ce protocole est un protocole textuel qui, à l'origine, ne prenait pas en charge la transmission de données binaires. Cependant, son caractère textuel a facilité sa mise en œuvre et sa maintenance. Le protocole MIME (Multipurpose Internet Mail Extensions) s'est popularisé à la fin des années 80 pour l'encodage et l'envoi de données binaires via SMTP. Aujourd'hui, SMTP est le protocole dominant pour l'envoi et la réception d'e-mails sur Internet, et une bonne maîtrise de ce protocole est indispensable pour tout administrateur réseau.
Le protocole SMTP étant basé sur du texte, son apprentissage est nettement plus simple que celui de nombreux autres protocoles ; il suffit d'un programme capable d'envoyer des données ASCII via le port TCP/IP 25, tel que Telnet, pour communiquer directement avec un serveur SMTP.
Les e-mails sont envoyés via SMTP dans le cadre d'une transaction ; cela signifie que si l'envoi du message ne s'achève pas complètement et sans générer d'erreur, le message est abandonné. La norme RFC 821 décrit une transaction comme comportant trois étapes : spécifier un expéditeur, fournir un ou plusieurs destinataires, puis envoyer le message lui-même. Cependant, il est plus facile de considérer une transaction SMTP comme comportant 5 étapes :
- Poignée de main
- Indiquez l'adresse de réponse
- Envoyer aux destinataires
- Envoyer les données du message
- Terminer la transaction
Poignée de main
Lorsqu'il se connecte à un serveur SMTP sur le port 25, l'expéditeur d'un message doit attendre que le destinataire accepte la connexion et s'identifie selon le format suivant :
220 [domaine] [Informations sur le service]
Exemple : 220 example.com Prêt à l'emploi
L'expéditeur doit alors s'identifier auprès du destinataire à l'aide de la commande HELO.
HELO [domaine]
Exemple : HELO example.com
Les serveurs de messagerie attendront que chacun s'identifie à l'aide d'un nom de domaine, qui pourrait servir à vérifier l'identité du serveur en effectuant une recherche d'enregistrement MX ; toutefois, le serveur destinataire ne doit pas rejeter la connexion à ce stade, même si l'identité de l'expéditeur ne peut être vérifiée, et doit donc répondre par :
250 [Message]
Exemple : 250 example.com Bonjour Bob à example.com
Le code de réponse 250 est la réponse générique ‘ OK ’ envoyée par un serveur SMTP pour indiquer que la dernière opération s'est déroulée avec succès.
Adresse de réponse :
Une fois que les deux serveurs ont établi la connexion, la transaction SMTP est lancée et nous pouvons commencer à envoyer des commandes au serveur. Si vous souhaitez connaître les commandes prises en charge par le serveur, envoyez la commande HELP ; le serveur SMTP devrait alors vous renvoyer un message indiquant les commandes disponibles.
Pour pouvoir envoyer un message à un utilisateur sur ce serveur, nous devons toutefois commencer par définir une adresse de réponse. Cette adresse doit être indiquée au préalable afin que, en cas d'erreur lors de la transaction SMTP, celle-ci puisse être signalée à cette adresse. Pour ce faire, nous utilisons la commande ‘ MAIL FROM : ’ :
E-MAIL DE :
Exemple : EXPÉDITEUR :
Notez les caractères « inférieur à » et « supérieur à ». La norme RFC 821 exige qu'ils encadrent l'adresse e-mail elle-même. Si l'adresse est valide, le protocole SMTP renverra une réponse « 250 OK ».
Envoyer aux destinataires
Une fois l'adresse de réponse définie, le protocole SMTP nous permettra d'identifier les destinataires du message. Pour ce faire, nous utilisons la commande ‘ RCPT TO : ’ :
À L'ATTENTION DE :
Exemple : DESTINATAIRE :
Pour définir plusieurs destinataires, il suffit de répéter cette commande pour chaque destinataire. Si le destinataire accepte les messages destinés à cet utilisateur et est en mesure de recevoir le message à ce moment-là, il devrait renvoyer une réponse « 250 OK ». Toutefois, si le courrier n'est pas accepté pour cet utilisateur, une réponse d'échec 550 sera envoyée, ou le code d'erreur approprié. Si nous recevons une réponse 250 OK, nous pouvons poursuivre l'envoi des données du message.
Envoyer les données du message
L'envoi de données via SMTP est assez simple, mais les formats de message peuvent s'avérer assez complexes, en particulier lors de l'envoi de pièces jointes binaires. Pour commencer l'envoi de données, il faut envoyer la commande ‘ DATA ’, à laquelle le serveur doit répondre par un code 354 (réponse intermédiaire). Par exemple :
354 Saisissez votre message en terminant par un “ . ” sur une ligne à part
Le message le plus simple que l'on puisse envoyer est un message en texte brut, qui ne nécessite pas l'utilisation du format de message MIME multipart. Tous les messages, qu'ils soient en texte brut ou non, se terminent par l'envoi d'une ligne ne contenant qu'un point. De plus, avant d'envoyer un message, vous pouvez inclure certaines informations d'en-tête telles que la date, l'objet, les champs « À », « Cc » et « De ».
Exemple :
DONNÉES
354 Saisissez votre message en terminant par un “ . ” sur une ligne à part
Objet : Il s'agit de l'objet du SMS
Et voici le corps du message en texte brut.
En cas d'acceptation, le serveur SMTP renverra une réponse « 250 OK » ou un code d'erreur si la transaction a échoué ou n'a pas été menée à terme. Notez le point à la fin de la ligne du corps du message : ce n'est que lorsqu'un point apparaît seul sur une ligne que le serveur cesse d'attendre des données. Si le serveur expéditeur envoie un message susceptible de provoquer la fermeture prématurée de la session de données parce que le message contient un seul point sur une ligne, il doit ajouter un point supplémentaire à cette ligne.
Clôture de la transaction
Jusqu'à ce stade, tout ce qui a été envoyé au serveur SMTP destinataire est considéré comme jetable. Si la commande ‘ QUIT ’ n'est pas envoyée avant la fermeture de la connexion, le serveur de destination supprimera simplement toutes les données de message qui ont été stockées. Initialement utilisée comme un moyen élégant de fermer une connexion, elle est aujourd'hui couramment utilisée pour signaler qu'une transaction est terminée, de nombreux serveurs de messagerie attendant la commande QUIT avant de mettre le message en file d'attente pour que l'agent de transfert de messages (MTA) l'achemine. Une fois que vous avez envoyé la commande QUIT, le serveur de destination doit envoyer une réponse 221 pour confirmer que la transaction est terminée et que la connexion est en cours de fermeture.
Si vous vous familiarisez avec le protocole SMTP, il est recommandé de consulter les RFC 821, 2476 et 2554. N'oubliez pas, notamment lorsque vous lisez la RFC 821, que depuis 1982, les serveurs de messagerie ont considérablement évolué, en partie pour lutter contre les abus commis par les spammeurs.