La commande XFORWARD règle le problème suivant :
Journalisation après filtrage de contenu basé sur SMTP. Avec le déploiement d'applications de filtrage de contenu type Internet->MTA1->filtre->MTA2, la journalisation des informations d'identification des clients et messages change lorsque le MTA1 donne le message au filtre de contenu. Pour simplifier l'interpretation des journaux du MTA2, il serait souhaitable que le MTA1 transfert les informations d'identification du client distant et/ou du message au MTA2 au travers du filtre de contenu, ainsi les informations peuvent être enregistrées comme faisant partie de la même transaction de message.
Cette extension est implementée en tant que commande ESMTP séparée et peut être utilisée pour transmettre les attibuts du client ou du message successivement. Elle n'est pas implementée en passant des paramètres additionnels via la commande MAIL FROM, car faire ainsi pourrait imposer d'étendre la limite de longueur de la commande MAIL FROM de plus de 600 caractères au delà de l'espace déjà nécessaire au support des autres extensions telles AUTH.
Un exemple de conversation client-serveur est présenté à la fin de ce document.
Dans les réponses EHLO du serveur ESMTP, le mot-clef associé à cette extension est XFORWARD. Ce mot-clef est suivi des noms des attributs que l'implémentaion de XFORWARD supporte.
Le client peut envoyer la requête XFORWARD à tout moment excepté au milieu d'une transaction de livraison de message (i.e. entre MAIL et POINT). La commande peut être enchaînée lorsque le serveur supporte l'enchaînement des commandes ESMTP.
La syntaxe des requêtes XFORWARD 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.
xforward-command = XFORWARD 1*( SP attribute-name"="attribute-value )
attribute-name = ( NAME | ADDR | PROTO | HELO | SOURCE )
attribute-value = xtext
Les valeurs d'attribut sont encodées au format xtext défini par la RFC 1891.
L'attribut NAME indique le nom de machine, ou [UNAVAILABLE] lorsque cette information n'est pas disponible. Le nom de machine peut être un nom de machine non-DNS.
L'attribut ADDR indique l'adresse résseau, ou [UNAVAILABLE] lorsque cette information n'est pas disponible. Cette information n'est pas encadrée par []. L'adresse peut être une adresse non-IP.
L'attribut PROTO indique le protocole de réception du message depuis le client extérieur. Ce peut être un nom de protocole SMTP ou autre d'au plus 64 caractères ou [UNAVAILABLE] lorsque cette information n'est pas disponible.
L'attribut HELO indique the nom de machine annoncé par le client extérieur lui-même (pas nécessairement via la commande SMTP HELO), ou [UNAVAILABLE] lorsque cette information n'est pas disponible. Le nom de machine peut ne pas être un nom DNS.
L'attribut SOURCE indique LOCAL lorsque le message est issu d'une source locale, REMOTE pour les autres ou [UNAVAILABLE] lorsque cette information n'est pas disponible. Le MTA aval peut décider d'activer le traitement des en-têtes et la qualification des adresses avec les messages des sources locales.
Note 1 : les valeurs des attributs ne peuvent dépasser 255 caractères (certains attributs peuvent imposer des longueurs plus courtes). Après décodage xtext, les valeurs d'attributs ne doivent pas contenir de caractères de contrôle, non-ASCII, des espaces, ou d'autres caractères particuliers aux en-têtes de message.
Note 2 : les noms de machines DNS peuvent atteindre 255 caractères au plus. L'impémentation XFORWARD cliente ne doit pas envoyer de commandes XFORWARD excédant les 512 caractères, limite des commandes SMTP.
Note 3 : [UNAVAILABLE] peut être indiqué en majuscules, minuscules ou casse mixte.
Note 4 : l'implémentation XFORWARD serveur ne doit pas mélanger les informations de la session SMTP courante avec les inforamtions transmises depuis la session amont.
Note 5 : Les implémentations Postfix antérieures à la version 2.3 n'encodent pas les valeurs d'attribut au format xtext. Les serveurs qui doivent interopérer avec ces anciennes implémentations doivent être préparés à recevoir des informations non encodées.
Code Signification 250 succès 421 traitement impossible, déconnexion 501 syntaxe incorrecte 503 transaction de message en cours 550 autorisation insuffisante
Dans l'exemple suivant, les informations envoyées par le client sont montré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-XFORWARD NAME ADDR PROTO HELO 250 8BITMIME XFORWARD NAME=spike.porcupine.org ADDR=168.100.189.2 PROTO=ESMTP 250 Ok XFORWARD HELO=spike.porcupine.org 250 Ok 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 3CF6B2AAE8 QUIT 221 Bye
La commande XFORWARD change les traces d'audit. L'utilisation de cette commande doit être restreinte aux clients autorisés.
Le cache des connexions SMTP permet de livrer de multiples messages dans la même session SMTP. Les attributs XFORWARD sont remis à zéro après chaque accomplissement d'une commande MAIL FROM, ainsi il n'y a pas de risque de mélange d'informations.
traduction par Xavier Guimard - Retour au menu