J. Klensin (AT&T Laboratories)April20012006-01-132008-10-01
Ce RFC mettait à jour le vieux
qui a été pendant dix-neuf ans (!) la spécification du protocole
SMTP, le principal protocole de transport de
courrier électronique, l'application qui a
assuré le succès de l'Internet. Il a depuis été remplacé par le .
Compte-tenu de l'immense succès de ce service et du protocole SMTP,
on comprend que beaucoup ont reculé devant la mise à jour de
SMTP. Elle était pourtant nécessaire puisque le protocole avait été
étendu, notamment par l'invention de ESMTP (originellement dans le
, une version améliorée - E signifie
Extended - qui permettait au client et
au serveur SMTP de négocier des options (comme le transport du
courrier sur 8 bits). Cette modification, et beaucoup d'autres,
rendait très difficile de déterminer le comportement normal d'un
serveur SMTP.
Remettre à plat le protocole et en donner une
description à jour et normative était donc une tâche utile, mais
ingrate ; il n'y a pas de prestige à gagner dans de telles tâches de
ménage (on notera d'ailleurs que le DNS souffre
terriblement de ce problème, plusieurs dizaines de RFC étant désormais
nécessaires pour le programmer correctement ; l'incapacité de
l'IETF à faire pour le DNS ce qui a été fait
pour SMTP est un sérieux problème). En outre, il fallait le prestige
et la compétence de John Klensin, auteur de nombreux
RFC, pour mener cette tâche à bien.
Le nouveau RFC décrit donc le modèle de SMTP, les entités qui
participent à l'envoi d'un message, les commandes qu'elles peuvent
échanger. On notera que le format des messages n'est pas décrit dans ce RFC
mais dans son compagnon, le . Le ne décrit que le protocole de transport, pas ce qui est
transporté.
Ce nouveau RFC intègre donc les modifications des vingt dernières
années, comme ESMTP. Il n'entraine aucun changement dans les serveurs
de messagerie, se contentant de tout décrire de manière
homogène. Signe des temps, notre RFC a aussi une longue section
consacrée à la sécurité, complètement absente du . La
question de l'usurpation d'identité est traitée mais pas résolue : si
SMTP n'authentifie pas l'émetteur, ce n'était pas par paresse ou
étroitesse de vue de la part de Jon Postel, l'auteur du . C'est tout simplement parce qu'il n'existe aucun
fournisseur d'identité sur l'Internet, réseau décentralisé et sans
commandement unique. Aucun protocole ne peut combler ce manque.
Mon expérience du courrier électronique remontant à quelques années
(bien après le mais bien avant le ),
je me souviens avec amusement des tentatives d'autres protocoles
(notamment le ridicule X.400) de s'imposer, par
des mesures bureaucratiques ou par du simple FUD, portant
souvent sur des questions de sécurité. La vérité est qu'aucun des
concurrents n'avait fait mieux que SMTP, dans un réseau ouvert : tous
n'ont été déployés que dans des petits réseaux fermés, où la question
de l'authentification est évidemment plus simple.
Comme notre RFC ne change pas le protocole, les principes de SMTP
demeurent : un protocole simple, efficace, relativement facile à
implémenter et n'utilisant que des commandes textes, ce qui permet de
déboguer aisément avec des outils comme
telnet. Ces principes sont à la base de la
révolution du courrier électronique qui fait qu'on n'imagine plus
aujourd'hui une carte de visite sans une adresse électronique.
Mais l'Internet continuant d'évoluer, des limites de notre RFC
apparaissent déjà. Par exemple, les nombreux efforts pour apporter des
mécanismes d'authentification de l'émetteur (par exemple pour lutter
contre le spam) ont souvent buté sur des
problèmes de vocabulaire : le ne décrit
qu'imparfaitement l'architecture du courrier et le vocabulaire, pour
des actions aussi simples que l'envoi d'un message à une liste de
diffusion ou que la réécriture des adresses en cas de
forwarding (faire suivre automatiquement un
message), reste flou et mal standardisé. Il est donc difficile
d'affirmer si telle ou telle nouvelle technique est contraire aux
principes du courrier Internet, ceux-ci n'étant pas formellement
écrits.