Authentification du client

Pour éviter le relayage par des spammeurs (voir 1.10, page ), une RFC en préparation, basée sur un mécanisme général décrit dans la RFC 2222, a pour but de permettre au client de s'authentifier auprès du serveur. Si le client ne s'authentifie pas, le serveur peut décider de ne pas relayer le message.

L'extension AUTH nécessite un nouveau mot-clef AUTH à l'initiative du client. Celui-ci précise un mécanisme d'authentification parmi ceux admis par le serveur (annoncés lors de la réponse à EHLO). Le serveur répond ensuite avec une ou plusieurs questions (challenges) encodées en base 64. Le client doit répondre à ces questions. S'il y répond correctement, l'authentification est réussie. Sinon, toute la suite du dialogue SMTP se déroule comme s'il n'y avait pas eu d'authentification. Lorsque l'échange nécessite une identification du client, celle-ci commence directement avec le mot-clef AUTH.

220 soleil.uvsq.fr ESMTP Sendmail 8.12.1/jtpda-5.4 ready at Fri, 23 Nov 2001 09:30:15 (GMT)
EHLO shiva.jussieu.fr
250-soleil.uvsq.fr Hello shiva.jussieu.fr, pleased to meet you
250 AUTH=SKEY
AUTH SKEY c21pdGg=
334 OTUgUWE1ODMwOA==
BsAY3g4gBNo=
235 S/Key authentication successful
...

De plus, la commande MAIL admet un paramètre optionnel supplémentaire afin de propager l'identité réelle de l'émetteur, si tant est que tous les serveurs sur le chemin acceptent l'authentification :

MAIL FROM: <jean@jussieu.fr> AUTH=jean@jussieu.fr
250 <jean@jussieu.fr>... Sender ok
...

Cette extension n'est pas supportée par la version actuelle de sendmail.