La commande XCLIENT règle les problèmes suivants :
Tests de contrôle d'accès. Les règles d'accès au serveur SMTP sont difficiles à vérifier lorsque les décisions ne sont communiquées qu'au clients distants. Pour faciliter les tests de règles d'accès, un programme client de test client SMTP a besoin de surcharger ses informations de nom de machine, d'adresse réseau etc... perçues par le serveur SMTP pour toute le durée de la session SMTP :
Les logiciels clients qui téléchargent les messages d'un serveur de messagerie amont pour les injecter dans un MTA local via SMTP. Pour conserver les avantages des règles d'accès du serveur SMTP local, le logiciel client a besoin de surcharger les informations perçues par le serveur SMTP sur le nom du client, son adresse et autres informations. Ces informations peuvent typiquement être extraites de l'en-tête Received: du serveur amont.
Les journaux et contrôles d'accès post-filtrage. Avec des applications de filtrage de contenu type Internet->filter->MTA, le filtre peut être simplifié s'il peut déléguer les décissions concernant le relayage et autres contrôles d'accès du MTA. C'est particulièrement pratique lorsque le filtre agit comme proxy transparent pour les commandes SMTP. Ceci requiert que le filtre puisse surcharger les informations précitées.
Un exemple de conversation client-serveur est présentés à la fin de ce document.
Dans les réponses ESMTP EHLO du serveur, le mot-clef associé à cette extension est XCLIENT. Il est suivi des noms des attributs que l'implémentation XCLIENT supporte.
La commande XCLIENT peut être transmise à tout moment, sauf au lilieu d'une transaction de livraison de message (i.e. entre MAIL et POINT ou entre MAIL et RSET). La commande XCLIENT peut être enchaînée lorsque le serveur supporte l'enchaînement des commandes ESMTP.
La syntaxe des requêtes XCLIENT est descrite ci-dessous. Les majuscules et chaînes encadrées représentent les terminaisons, les chaînes en minuscules représentent des terminaisons meta, et SP est un espace. Bien que les noms des commandes et attributs sont montrés en majsucule, ils sont dans la réalité insensibles à la casse.
commande-xclient = XCLIENT 1*( SP nom-attribut"="valeur-attribut )
nom-attribut = ( NAME | ADDR | PROTO | HELO )
valeur-attribut = xtext
Les valeurs d'attribut sont encodées en xtext comme indiqué dans la RFC 1891.
L'attribut NAME indique un nom de machine client SMTP (pas une adresse client SMTP), [UNAVAILABLE] lorsque la résolution du nom de machine du client échoue en raison d'une erreur permanente, ou [TEMPUNAVAIL] lorsque l'erreur est temporaire.
L'attribut ADDR indique l'adresse réseau numérique IPv4 du client SMTP, une adresse IPv6 prefixée par "IPV6:", ou [UNAVAILABLE] lorsque cette information n'est pas disponible. Cette information n'est pas encadrée par [].
L'attribut PROTO indique SMTP ou ESMTP.
L'attribut HELO indique la valeur du paramètre SMTP HELO, ou la valeur [UNAVAILABLE] lorsque cette information n'est pas disponible.
Note 1 : les éléments de valeur d'attribut NAME et HELO syntaxiquement corrects ne peuvent dépasser 255 caractères. Le client ne doit pas envoyer de commandes XCLIENT excédant la limite de 512 caractères des commandes SMTP. Pour éviter le dépassement, le client peut envoyer l'inforamtion en plusieurs commandes XCLIENT par exemple, envoyez NAME et ADDR en premier, puis HELO et PROTO.
Note 2: [UNAVAILABLE], [TEMPUNAVAIL] et IPV6 : peuvent être indiqués en majuscules, minuscules ou casse mixée.
Note 3 : les implémentations Postfix antérieures à la version 2.3 n'encodent pas les valeurs d'attribut au format xtext. Les serveurs devant interopérer avec ces anciennes implémentations doivent être préparés à recevoir des informations non encodées.
À la réception d'une commande XCLIENT correctement composée, le serveur réinitialise la connexion à l'étape initiale du protocole SMTP. Selon les résultats des décisions d'accès éventuelles, le serveur répond 220 ou un code avec un code approprié de rejet.
Pour des raisons pratiques, il n'est pas toujours possible de réinitialiser l'état de la connexion à l'étape initiale du protocole SMTP :
Les informations de session TLS ne peuvent être réinitialisées pour ne pas se trouver dans un état indéterminé. En conséquence, le serveur n'annonce pas STARTTLS lorsque TLS est déjà actif et les décisions d'accès peuvent être influencées par le certificat client reçu avant la commande XCLIENT.
Le serveur SMTP ne réinitialise pas les attributs reçus avec la dernière commande XCLIENT. Ceci inclut les attributs HELO et ESMTP.
NOTE : les implémentations de Postfix antérieures à la version 2.3 ne retournent pas à l'étape initiale du protocole SMTP. Ces anciennes implémentations ne simuleront pas correctement les décisions d'accès de niveau connexion dans toutes les conditions possibles.
Code Signification 220 succès 421 traitement impossible, déconnexion 501 syntaxe incorrecte 503 transaction de message en cours 550 autorisation insuffisante autre connexion rejetée par une décision d'accès de niveau connexion
Dans cet exemple, le client simule un message issu d'un système en passant toutes les informations de session SMTP via la commande XCLIENT. Les information envoyées par le client sont affichées en gras.
220 server.exemple.com ESMTP Postfix client EHLO.exemple.com 250-server.exemple.com 250-PIPELINING 250-SIZE 10240000 250-VRFY 250-ETRN 250-XCLIENT NAME ADDR PROTO HELO 250 8BITMIME XCLIENT NAME=spike.porcupine.org ADDR=168.100.189.2 220 server.example.com ESMTP Postfix EHLO spike.porcupine.org 250-server.example.com 250-PIPELINING 250-SIZE 10240000 250-VRFY 250-ETRN 250-XCLIENT NAME ADDR PROTO HELO 250 8BITMIME MAIL FROM:<wietse@porcupine.org> 250 Ok RCPT TO:<user@exemple.com> 250 Ok DATA 354 End data with <CR><LF>.<CR><LF> . . .contenu du message. . . . 250 Ok: queued as 763402AAE6 QUIT 221 Bye
La commande XCLIENT change les traces d'audit et/ou les permissions d'accès du client SMTP. L'utilisation de cette commande doit être restreinte aux clients autorisés.
Les attributs XCLIENT persistent jusqu'à la fin de la session SMTP. Si une session est utilisée pour livrer du courrier de différents clients SMTP, les attributs XCLIENT ont besoin d'être réinitialisés si nécessaire avant chaque commande MAIL FROM.
L'encodage xtext est défini dans :
Moore, K, "SMTP Service Extension for Delivery Status Notifications", RFC 1891, Janvier 1996.
traduction par Xavier Guimard - Retour au menu