Mon blog

Le protocole de transfert de courrier électronique SMTP, normalisé dans le RFC 5321, est prévu pour des cas où la connexion est la règle et l'absence de connexion une exception. S'il ne peut joindre le serveur suivant, le MTA SMTP réessaie de temps en temps, pendant trois à cinq jours puis renonce. Ce mécanisme ne marche pas lorsque le serveur suivant n'a pas d'adresse IP fixe, ce qui est fréquent, ou bien lorsqu'il est fréquemment déconnecté (tellement fréquemment que les périodes où l'envoyeur essaie ont de fortes chances de ne pas coïncider avec celles où le receveur est connecté). Il existe plusieurs solutions à ce problème et notre RFC normalisait ODMR (On-demand mail relay), également appelé ATRN (Authenticated TURN). Il n'a pas été un succès et reste très peu déployé aujourd'hui.

Parmi les concurrents de ODMR, une autre extension de SMTP, ETRN, normalisée dans le RFC 1985. Mais ETRN nécessitait une adresse IP fixe. Au contraire, le principe de ODMR, une extension de SMTP, est simple : le receveur contacte l'envoyeur en SMTP, sur le port 366, à son choix, à l'heure qu'il veut, s'authentifie, et envoie une commande SMTP, ATRN qui prend en paramètre un ou plusieurs noms de domaine. L'envoyeur expédie alors, toujours en SMTP, le courrier de ce domaine (section 4 du RFC). Voici un exemple, pris dans la section 6, où le receveur est example.org et son fournisseur de courrier, qui lui garde en attendant la connexion de son client, est example.net :

P:  220 EXAMPLE.NET on-demand mail relay server ready
C:  EHLO example.org
P:  250-EXAMPLE.NET
P:  250-AUTH CRAM-MD5 EXTERNAL
P:  250 ATRN
C:  AUTH CRAM-MD5
P:  334 MTg5Ni42OTcxNzA5NTJASVNQLkNPTQo=
C:  Zm9vYmFyLm5ldCBiOTEzYTYwMmM3ZWRhN2E0OTViNGU2ZTczMzRkMzg5MAo=
P:  235 now authenticated as example.org
C:  ATRN example.org,example.com
P:  250 OK now reversing the connection
C:  220 example.org ready to receive email
P:  EHLO EXAMPLE.NET
C:  250-example.org
C:  250 SIZE
P:  MAIL FROM: <Lester.Tester@dot.foo.bar>
C:  250 OK
P:  RCPT TO: <l.eva.msg@example.com>
C:  250 OK, recipient accepted
...
P:  QUIT
C:  221 example.org closing connection

La machine à états complète d'ODMR est présentée en section 5. Notez que l'authentification est obligatoire (section 5.1.2). Pour réclamer le courrier de example.org, il faut prouver qui on est ! Dans l'exemple ci-dessus, l'authentification se fait en CRAM-MD5, la seule méthode que tous les clients et serveurs ODMR doivent mettre en œuvre. ATRN lui-même est décrit en section 5.2.1. Comme dans l'exemple ci-dessus, il peut prendre plusieurs noms de domaine comme paramètre. Le « retournement » de la session SMTP est dans la section 5.3 (le serveur ODMR devient client SMTP et réciproquement). Les codes de réponse ODMR sont en section 7. Par exemple, un ATRN lorsqu'il n'y a pas eu authentification renvoie 530 Authentication required.

Comme indiqué plus haut, ODMR nécessite un accord préalable avec un fournisseur de messagerie (qui peut être n'importe où sur l'Internet et n'est pas forcé d'être le FAI). Les enregistrements MX du domaine du récepteur, mettons example.org, sont alors pointés vers le serveur ODMR du fournisseur. Je ne trouve pas de liste de fournisseurs gérant ODMR, probablement parce que cette technique n'est quasiment plus utilisée.

Le fournisseur, outre l'exigence d'authentification, peut prendre d'autres précautions comme de restreindre l'accès au port 366 à certaines adresses IP (section 8).

J'ai indiqué qu'ODMR semble abandonné. Quelles sont les alternatives ? On trouve des solutions spécifiques d'un fournisseur, avec un protocole privé tournant sur un port donné, sur lequel le client est censé se connecter pour annoncer sa disponibilité. Aujourd'hui, comme hier, UUCP semble nettement dominer ce domaine d'application.

Il ne semble pas exister beaucoup d'implémentations activement maintenues de ODMR. Le démon odmr semble fonctionner avec le MTA Postfix. Brian Candler avait écrit un odmrd pour Courier, démon qui ne semble plus exister. Un plan détaillé de mise en œuvre dans Postfix avait été écrit mais ne semble pas avoir été mené à bout.

Côté client (le receveur de courrier), fetchmail gère ODMR, on peut utiliser l'option --protocol ODMR.