Cours sur SMTP le Simple Mail Transfer Protocol

Extrait du cours simple mail transfer protocol

1. INTRODUCTION
Le but du protocole de courrier Simple Mail Transfer Protocol (SMTP) est de transférer du courrier électronique selon un procédé efficace et fiable. SMTP est indépendant de tout sous-système de transmission et ne nécessite qu’un canal de transmission fiable et ordonné. Les Appendices A, B, C, et D décrivent l’utilisation de SMTP sur diverses couches transport. Une fonctionnalité importante de SMTP est sa capacité à relayer des courriers dans des environnements de service de transport. Un service de transport dispose d’un environnement de communication inter-processus (IPCE). Un IPCE peut avoir une portée limitée à un seul réseau, étendue à plusieurs réseaux, ou réduite à un sous ensemble d’un réseau. Il est fondamental de comprendre que les environnements de communication inter-processus (ou IPCE) ne sont pas nécessairement corrélés à un réseau. Un processus peut communiquer directement avec un autre processus à travers toute paire d’IPCE se reconnaissant l’une l’autre. Le courrier électronique est une application, ou simplement une utilisation des mécanismes de communication inter-processus. Le courrier peut être transmis entre deux processus par différents IPCE et éventuellement en étant relayé par un autre processus connecté à au moins deux (ou plus) IPCE. Plus généralement, le courrier peut être relayé entre hôtes sur des systèmes de transport différents.
2. LE MODELE SMTP
Le design de SMTP est basé sur le modèle suivant de communication : suite à une requête de l’utilisateur du courrier user, L’émetteur SMTP établit une communication bidirectionnelle vers un récepteur-SMTP. Celui-ci peut être soit la destination finale, soit seulement un intermédiaire. Les commandes SMTP sont générées par l’émetteur SMTP et sont émises vers le récepteur SMTP. Les réponses SMTP sont envoyées par le récepteur-SMTP à l’émetteur-SMTP en réponse aux commandes.Une fois le canal de transmission établi, l’émetteur SMTP envoie une commande MAIL mentionnant l’émetteur d’un courrier. Si le récepteur SMTP peut accepter le courrier, il répondra par un message OK. L’émetteur-SMTP envoie alors une commande RCPT identifiant un récipiendaire pour ce courrier. Si le récepteur-SMTP peut accepter un courrier pour ce récipiendaire, alors il répondra par un message OK ; sinon, il répond par un message refusant le courrier pour ce récipiendaire (mais n’annulant totalement pas la transaction de courrier). L’émetteur SMTP et le récepteur SMTP pourront négocier plusieurs récipiendaires. Une fois cette négociation effectuée, l’émetteur SMTP envoie le contenu du courrier, en le terminant par une séquence spéciale. Si le récepteur SMTP traite avec succès la réception du contenu du courrier, il répondra par un message OK. Le dialogue est volontairement un dialogue pas à pas, à étapes verrouillées.
3. LES PROCEDURES SMTP
Cette section présente en plusieurs étapes les procédures utilisées par SMTP. Tout d’abord est analysée la procédure de base définie comme une transaction de transfert de courrier. Suite à ceci seront décrits la façon de réemettre un courrier, vérifier des noms de boîtes aux lettres et expanser des listes de diffusion, d’émettre vers de terminaux plutôt que (ou conjointement) vers des boîtes aux lettres, ainsi que les procédures d’ouverture et de fermeture des échanges. Vous trouverez à la fin de cette section des commentaires sur le principe de relais, une note sur les domaines de courrier, et une discussion sur l’échange des rôles. Tout au long de cette section seront donnés des exemples de séquences partielles de commandes et réponses, des scénarios complets de transactions sont proposés dans l’Appendice F.
3.1. Emission de courrier
Une transaction de courrier SMTP se déroule en trois étapes. La transaction est initiée par une commande MAIL donnant l’identification de l’émetteur. Une série contenant une ou plusieurs commandes RCPT suit, donnant les informations sur les destinataires. Puis une commande DATA passe le contenu du message. Dans cette troisième phase, la marque de fin de données à transmettre marque la fin de la transaction.
La première étape de la procédure est donc la commande MAIL. L’argument <route-inverse> contient le nom de la boîte aux lettres de l’émetteur.
MAIL <SP> FROM:<reverse-path> <CRLF>
Cette commande indique au récepteur SMTP qu’une nouvelle transaction de courrier débute et lui demande de réinitialiser ses tables d’états et ses tampons, y compris ses boîtes de réception et toute donnée de courrier latente. Elle lui donne le chemin inverse qui pourra être utilisé en cas de rapport d’erreur à transmettre. Si l’émetteur accepte la commande, un code 250 OK est renvoyé à l’émetteur. L’argument <route-inverse> peut contenir plus d’une boîte aux lettres. On peut y inscrire une liste de plusieurs boîtes aux lettres dans des hôtes différents. La première boîte inscrite dans l’argument <route-inverse> doit néanmoins être celle désignant l’émetteur du message.La deuxième étape de la procédure est l’émission des commandes RCPT.
3.2. Réémissions (ou redirections)
Il existe certains cas où l’information concernant un destinataire donnée dans la <route-directe> est incorrecte,mais le récepteur-SMTP connaît la destination exacte. Dans un tel cas, l’une des réponses suivantes pourra être émise pour permettre à l’émetteur de contacter la bonne destination.
251 User not local; will forward to <route-directe>
Cette réponse indique que le récepteur-SMTP sait que la boîte-aux-lettres du destinataire est hébergée sur un autre hôte et indique le chemin d’accès correct de cette boîte aux lettres pour des messages futurs. Notez que l’hôte, ou l’utilisateur ou les deux peuvent être différents de ceux de la requête originale. Le récepteur prend dans ce cas la responsabilité de délivrer le message actuel à la bonne destination.
551 User not local; please try <route-directe>
Cette réponse indique que le récepteur-SMTP sait que la boîte-aux-lettres du destinataire est sur un autre hôte et signale le chemin d’accès correct à utiliser pour joindre cette boîte-aux-lettres. Notez que l’hôte, ou l’utilisateur ou les deux peuvent être différents de ceux de la requête originale. Dans ce cas, le récepteur refuse d’accepter des messages pour cet utilisateur, et l’émetteur devra soit rediriger explicitement son courrier conformément à l’information fournie ou arrêter la transaction et retourner un message d’erreur à son utilisateur.