Uv réseau – tp5 Un protocole applicatif : smtp

UV Réseau – TP5 Un protocole applicatif : SMTP

Introduction

L’objectif est d’étudier un protocole applicatif omni-présent : SMTP.
Ce protocole définit la dynamique des échanges ainsi que le contenu de chaque message pour envoyer un courrier électronique. On parle de push protocol, car le transfert est initialisé par l’expéditeur. Les serveurs SMTP les plus courants sont sendmail, qmail, smail (smail est installé par défaut sur la distribution KNOPPIX).
La technique pour le relevé de courrier (pull protocol, le destinataire initialise le transfert) dépend de la distance entre la machine de consultation et le disque stockant les fichiers représentatifs des courriels reçus :

• 
  sur le disque local, on peut utiliser une application (tel que mutt¹, pine) capable de lire l’organisation² de fichiers alimentée par le serveur SMTP ;
  
• 
  sur un disque distant, on utilise un client échangeant avec un serveur de courrier mettant en œuvre le protocole POP ou IMAP (le plus courant sur les distributions Linux est UW IMAP).
  

Pour ne pas cumuler les risques de dysfonctionnement, une consultation sur disque local par mutt est préconisée dans ce TP.
La configuration est la suivante

Les machines A et B ont un serveur de messagerie opérationnel.

La machine C dispose d’un client de messagerie.

Vérifier qu’un serveur telnet est opérationnel sur les machines A et B pour pouvoir réaliser toutes vos consultations depuis la machine C.

Quelques questions ou suggestions

• 
  Veiller à ce que les interfaces connectées au concentrateur (partageant la même liaison) appartiennent au même réseau (au sens couche 3).
  
• 
  Faites un schéma rapide indiquant les noms et adresses IP des machines jouant le rôle de A, B et C.
  
• 
  Noter le serveur de messagerie utilisé ainsi que le client de messagerie.
  
• 
  En l’absence de serveur DNS, quels sont les fichiers utilisé pour établir le lien entre une URL et une adresse IP ?
  

Mode opératoire

Mission 1 : Simuler un client de messagerie

• 
  S’installer sur la machine C.
  
• 
  Activer une capture Ethereal.
  
• 
  Composer avec mutt un courriel depuis la machine C à destination du compte root de la machine A.
  
• 
  Envoyer ce courriel.
  
• 
  Vérifier que ce courriel est arrivé à destination en ouvrant un client de messagerie en tant que root sur la machine A.
  
• 
  Observer la trace sur C.
  
• 
  Envoyer un courriel en ouvrant depuis C une connexion telnet sur A via le port qu’utilisait le client de messagerie. Il suffit pour ce faire de simuler le comportement d’un client de messagerie en reproduisant les commandes que ce dernier a envoyé au serveur SMTP.
  
• 
  Vérifier que ce courriel est bien parvenu à la machine A.
  

Mission 2 : Quelques subtilités dans le protocole SMTP

• 
  Composer avec telnet un deuxième message dont la dernière ligne comporte deux points (correspondant à deux occurrences du caractère ASCII 46³).
  
• 
  Observer le message à l’arrivée. Combien a-t-il de point. Ce mécanisme ne vous rappelle-t-il pas une technique liée à la détection des fanions dans les couches de niveau 1 ? Donner le nom de cette technique.
  
• 
  En jouant sur les commandes, continuer à composer des courriels avec telnet et essayer d’obtenir quelques-unes des erreurs listées dans l’annexe « Extraits choisis de la RFC 821 ». Soyez astucieux !
  
• 
  A partir de vos observations, réaliser un diagramme d’états-transitions représentant le comportement d’un client messagerie face aux événements que constituent les commandes entrées par l’utilisateur et les retours reçus du serveur SMTP.
  

Annexe : Extraits choisis de la RFC 821

4.2.2. CODES REPONSE PAR ORDRE NUMERIQUE

• 
  211 Etat système, ou réponse d'aide système
  
• 
  214 Message d'aide [Informations sur l'utilisation d'un récepteur ou signification d'une commande non standard particulière; en clair pour un opérateur humain]
  
• 
  220 Service disponible
  
• 
  221 Canal de transmission en cours de fermeture
  
• 
  250 Action de messagerie effectuée, succès
  
• 
  251 Utilisateur non local ; réémission vers (avec relais automatique)
  

• 
  354 Début de message ; arrêt par .
  

• 
  421 Service non disponible, canal en fermeture [Réponse à émettre sur tous les canaux lorsque le système exécute une séquence d'arrêt]
  
• 
  450 Action non effectuée : boîte-aux-lettres non disponible [Ex., bloquée par un autre utilisateur]
  
• 
  451 Action arrêtée : erreur de traitement
  
• 
  452 Action non effectuée : manque de ressources système.
  

• 
  500 Erreur de syntaxe, commande non reconnue [y compris des erreurs de type "ligne de commande trop longue"]
  
• 
  501 Erreur de syntaxe dans des paramètres ou arguments
  
• 
  502 Commande non implémentée
  
• 
  503 Mauvaise séquence de commandes
  
• 
  504 Paramètre de commande non implémenté
  
• 
  550 Action non effectuée : boîte-aux-lettres non disponible [Ex., boîte-aux-lettres non trouvée, pas d'accès]
  
• 
  551 Utilisateur non local ; essayer (sans relais automatique)
  
• 
  552 Action arrêtée : manque de ressources de stockage
  
• 
  553 Action non effectuée : nom de boîte-aux-lettres non autorisé [Ex., erreur de syntaxe dans le nom de boîte]
  
• 
  554 Transaction échouée.
  

4.5.3. TAILLES

Un certain nombre d'objets de données ont des tailles minimales et maximales définies. C'est-à-dire, toute implémentation doit s'attendre à recevoir des objets d'au moins la taille minimale, mais ne doit elle-même pas envoyer d'objets d'une taille supérieure à la taille maximale.

****************************************************

* *

* POUR UNE ADAPTABILITE OPTIMALE, LES TECHNIQUES *

* D'IMPLEMENTATION QUI N'IMPOSENT PAS DE LIMITES *

* SUR LA TAILLE DE CES OBJETS SONT PREFEREES. *

* *

****************************************************

Nom d'utilisateur

La longueur totale maximale d'un nom d'utilisateur est de 64 caractères.

Nom de domaine

La longueur totale maximale d'un nom de domaine est de 64 caractères.

Routes

La longueur maximale des routes et routes inverses est de 256 caractères chacune (y compris la ponctuation et les séparateurs d'éléments).

Ligne de commande

La longueur totale maximale de la ligne de commande, incluant le code de commande et le final est de 512 caractères.

Ligne de réponse

La longueur totale maximale de la ligne de réponse, incluant le code de réponse et le final est de 512 caractères.

Ligne de texte (corps de message)

La longueur maximale d'une ligne de texte y compris le final est de 1000 caractères (le point dupliqué en tête de ligne pour assurer le principe de transparence n'est pas compté).

Tampon des récipiendaires

Le nombre maximal de récipiendaires à enregistrer pour une transaction est fixé à 100.

****************************************************

* *

* POUR UNE ADAPTABILITE OPTIMALE, LES TECHNIQUES *

* D'IMPLEMENTATION QUI N'IMPOSENT PAS DE LIMITES *

* SUR LA TAILLE DE CES OBJETS SONT PREFEREES. *

* *

****************************************************
Source :

Crédits : J. Postel / ISI

Traduction : Valéry Frémaux / EISTI
Edition originale : Août 1982. Version FR : Avril 1998
Remplace : RFC 788, 780, 772

http://www.salemioche.com/smtp/821-4.php#4.4

1 Mutt peut en option être compilé pour communiquer avec un serveur POP (distant). Le fichier d’initialisation aura alors une commande de la forme mailboxes = pop://username@popserver[:port]/

2 Il existe plusieurs formats de stockage sur disque du courrier (en attente de lecture par leur destinataire) : le plus courant est mbox. On trouve éventuellement maildir, …

3 Et non pas une occurrence du caractère ASCII 56 ‘:’