Technologie Internet: Protocoles du courrier électronique

Technologie Internet - Université de Genève, CUI ©

Protocoles du courrier électronique

SMTP (Simple Mail Transfer Protocol)
- RFC 2821 (vient récemment de remplacer les RFC 821, 974 et 1869)
- permet à des MTA (Mail Transfer Agents) de "véhiculer" des messages à travers le réseau
- port par défaut: 25
- en utilisation typique, les commandes suivantes sont utilisées: helo, mail, rcpt, data et quit
- exemple d'utilisation typique
- plusieurs récipiendaires peuvent être mentionnés en utilisant plusieurs fois la commande rcpt.
- certains serveurs SMTP ne regardent pas du tout le contenu de l'en-tête d'un message tel qu'il est fourni à la commande data.
- le protocole est synchrone, c-à-d. que le client doit attendre la réponse du serveur à la commande précédente avant d'envoyer une nouvelle commande. Le RFC 2920 (en remplacement du RFC 2197) décrit une extension permettant le "pipelining" de commandes.
- chaque ligne de la réponse d'un serveur SMTP commence toujours par un nombre de trois chiffres indiquant l'état du système, suivi par un texte explicatif. Le nombre est destiné au traitement automatisé et le texte à un être humain. Si la ligne courante est la dernière ligne du message, le quatrième caractère est un espace, sinon c'est un '-'.
- la section 4.2 du RFC 2821 donne le détail des codes de réponse
IMAP (Internet Message Access Protocol)
- RFC 2060
- port par défaut: 143
- les messages sont archivés sur le serveur IMAP et l'UA (User Agent) se contente d'en faire l'affichage.
- le fait que les messages soient archivés sur le serveur fait que l'utilisateur peut accéder à tous ses messges depuis n'importe où sur le réseau et que l'administrateur peut facilement faire des copies de sauvegarde..
- le protocole comporte des commandes pour gérer des boites aux lettres, gérer des messages, rechercher dans le contenu des messages et transférer de manière sélective des messages vers l'UA.
- intègre l'extension MIME, permettant, par exemple, à l'UA de ne demander le transfert que d'une partie d'un message qui aurait de volumineuses annexes.
- particulièrement bien adapté à l'accès à travers des connexions lentes.
- facilite le partage d'une boite aux lettres par plusieurs personnes; p.ex. plusieurs personnes assurant le support aux utilisateurs et atteignables par une seule adresse.
POP (Post Office Protocol)
- RFC 1939
- port par défaut: 110
- protocol synchrone.
- le serveur POP ne conserve normalement que les messages nouvellement arrivés qui n'ont pas encore été transférés vers l'UA.
- les messages sont archivés par l'UA sur la machine de l'utilisateur.
- Lorsque le transfert vers l'UA est terminé, c'est l'UA qui demande la destruction des messages sur le serveur POP.
- Lorsque la connexion est établie entre le client et le serveur, la session passe par différentes phases (états):
  - Phase d'autorisation: la commande user permet de fournir le login de l'utilisateur puis la commande pass permet de fournir le mot de passe. La commande quit permet de clore la session.
  - Si la phase d'autorisation se termine correctement, le serveur POP verrouille la boîte aux lettres de l'utilisateur (maildrop)
  - Si le verrou a pu être mis, la session entre en phase de transaction.
  - Phase de transaction: les messages sont automatiquement numérotés de 1 à n (où n est le nombre de messages en attente). Les commande utilisables dans cette phase sont: stat (fournit des informations sur le contenu de la boîte aux lettres), list ou list i (donne des informations sur chaque message, ou sur le message numéro i), retr i (demande l'envoi du message numéro i: une première ligne est envoyée pour indiquer si le demande est acceptée, suivie par les lignes du message, puis par une ligne de terminaison), dele i (marque comme supprimé le message i de la boîte aux lettres, la suppression n'ayant lieu qu'à la phase de mise-à-jour), rset (annulle toute suppression), quit (termine la phase de transaction pour entrer en phase de mise-à-jour)
  - Phase de misa-à-jour: quit (supprime tous les messages marqués et clôt la session)
- Certaines commandes ne sont pas nécessairement implantées (optionnelles): top i j (envoie l'entête et les j premières lignes du corps du message numéro i), uidl i (fournit l'identificateur du message numéro i)
- Pour éviter que le nom et le mot de passe de l'utilisateur circulent en clair sur le réseau (potentiellement à intervalles réguliers), certains serveurs POP acceptent une identification par usage de l'algorithme MD5 (Message Digest 5 - RFC 1321): le serveur envoie au début de la session un identificateur unique (timestamp) et le client utilise la commande apop suivie du nom de l'utilisateur et du résultat de l'algorithme MD5 appliqué à l'identificateur reçu du serveur auquel est appondu un secret partagé par le client et le serveur (p.ex. mot de passe).

Remarques:

Il est à noter que les adresses pour le courrier électronique n'utilisent pas les mêmes bases de données (MX) que les adresses de machines (A) dans les DNS. Par exemple "

nslookup -q=MX
    cui.unige.ch.

" donnera:

Server:  dns93.unige.ch
Address:  129.194.4.6

cui.unige.ch    preference = 10, mail exchanger = uni2b.unige.ch
cui.unige.ch    preference = 5, mail exchanger = cuimail.unige.ch
unige.ch        nameserver = uni2b.unige.ch
unige.ch        nameserver = dns93.unige.ch
unige.ch        nameserver = sns2-tss2.unige.ch
unige.ch        nameserver = scsnms.switch.ch
uni2b.unige.ch  internet address = 129.194.4.32
cuimail.unige.ch        internet address = 129.194.69.50
dns93.unige.ch  internet address = 129.194.4.6
sns2-tss2.unige.ch      internet address = 129.194.8.7
scsnms.switch.ch        internet address = 130.59.1.30
scsnms.switch.ch        internet address = 130.59.10.30

alors que "nslookup -q=A cui.unige.ch." donnera:

Server:  dns93.unige.ch
Address:  129.194.4.6

Name:    cui.unige.ch
Address:  129.194.70.1

La raison en est que cela permet d'éviter que chaque machine ait son propre serveur SMTP. Il suffit, pour chaque machine ayant des utilisateurs susceptibles de recevoir du courrier électronique d'avoir une entrée de type MX dans le DNS local indiquant sur quelle machine se trouve le serveur SMTP gérant la boite aux lettres de ces utilisateurs.

Pour envoyer un message de courrier électronique, il n'est pas nécessaire de s'adresser directement au serveur SMTP correspondant à l'adresse du destinataire. N'importe quel serveur SMTP contacté se chargera de transmettre vers un autre serveur SMTP tout message qui comporterait une adresse de destinataire (rcpt) qui ne lui est pas locale.
Il faut garder à l'esprit la distinction entre enveloppe et entête d'un message. L'enveloppe est constituée des informations fournies au serveur SMTP à l'aide des commandes "Mail From:" et "Rcpt To:", alors que l'entête est constituée de données destinées au "client". Ainsi, l'adresse mentionnée dans la commande "Mail From:" ne sera pas nécessairement la même que celle de la ligne d'entête "From:" et l'adresse mentionnée dans la commande "Rcpt To:" ne sera pas nécessairement la même que celle de la ligne d'entête "To:". L'enveloppe sert au routage du message alors que l'entête sert à fournir des informations au récipiendaire et à son logiciel de courrier électronique.
Un systèmes de listes de distribution devrait mettre dans l'entête "From:" l'adresse de la personne qui aura initialement rédigé le message, alors que l'enveloppe mentionnera dans la commande "Mail From:" l'adresse du responsable de la liste de distribution. Ainsi, les messages d'erreur annonçant qu'une des adresses d'abonnés n'est plus correcte seront reçus par le gestionnaire de la liste, qui pourra alors retirer cette adresse obsolète de la liste de distribution, plutôt que par les personnes envoyant un message à la liste et qui ne peuvent rien faire pour mettre à jour la liste. D'une manière similaire, le systèmes de listes de distribution devrait mettre dans l'entête "To:" l'adresse de la liste de distribution plutôt que l'adresse de l'abonné, de façon à permettre à la personne recevant le message de voir que ce message ne lui est pas destiné personnellement, mais a en fait été envoyé à une des listes auxquelles elle est abonnée.
Bien entendu, tout logiciel de traitement de messages situé en amont de l'utilisateur (filtrage, annonce de vacances, notification de virus, etc.) devrait agir de la même manière pour éviter d'ennuyer inutilement les utilisateurs. Il est même communément admis qu'un tel logiciel devrait s'abstenir d'envoyer de messages d'erreur si le message semble provenir d'une liste de distribution (p.ex. si l'adresse du champs "To:" n'est pas la même que celle indiquée dans la commande "Rcpt To:". Par exemple, le logiciel qmail-vacation ne génère pas de réponse si une des conditions suivantes est satisfaite:
- le message provient d'une adresse contenant "-REQUEST@"
- le message provient de la personne pour laquelle ce logiciel fonctionne
- le nom de la personne envoyant le message est daemon, postmaster, mailer-daemon, mailer, ou root.
- le message provient d'une adresse qui satisfait les critères mentionnés dans les fichiers ~/.vacation.aliases ou ~/.vacation.noreply
- l'entête du message contient une ligne "Precedence: bulk" ou "Precedence: junk" ou "Mailing-List: ..."
- l'adresse du récipiendaire n'apparaît ni dans le champs "To:", ni dans le champs "Cc:".
- une réponse automatique a déjà été envoyée à la même adresse dans la semaine qui précède

The Spec's in the Mail (copie locale), par Rohit Khare
Internet Draft: E-mail addressing: the worst of all worlds? (February 1997)
RFC 2197: SMTP Service Extension for Command Pipelining
RFC 2852: Deliver By SMTP Service Extension
Internet Draft: Anti-Spam Recommendations for SMTP MTAs

Dernière modification: 27.04.01

Site Hosting: Bronco