Partager via

Gestion du répertoire de relecture

  • Article

 

S’applique à : Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

Dernière rubrique modifiée : 2007-02-22

Par défaut, le répertoire de relecture est disponible sur chaque ordinateur Microsoft Exchange Server 2007 sur lequel le rôle serveur de transport Hub ou Edge est installé. Les fichiers de messages correctement formatés que vous copiez dans le répertoire de relecture sont déposés pour remise. Le répertoire de relecture reçoit des messages de serveurs de passerelle étrangers et resoumet les messages exportés par les administrateurs à partir des files d'attente des serveurs Exchange 2007.

Utilisez la cmdlet Set-TransportServer pour toutes les tâches de configuration du répertoire de relecture. Cette cmdlet permet d'effectuer les changements de configuration du répertoire de relecture suivants :

  • activation ou désactivation du répertoire de relecture ;

  • spécification de l'emplacement du répertoire de relecture ;

  • spécification d'une vitesse maximale pour le traitement des fichiers de messages en messages par minute.

Mode de traitement des messages par le répertoire de relecture

Un fichier de message .eml correctement formaté copié dans le répertoire de relecture est traité pour dépôt au cours des étapes suivantes :

  1. L'arrivée de nouveaux fichiers de messages est vérifiée toutes les 5 secondes dans le répertoire de relecture. Il n'est pas possible de modifier cette fréquence d'interrogation. Vous pouvez régler la vitesse de traitement des fichiers de messages à l'aide du paramètre PickupDirectoryMaxMessagesPerMinute avec la cmdlet Set-TransportServer. La valeur par défaut est 100 messages par minute. Les fichiers qui ne peuvent pas être ouverts sont conservés dans le répertoire de relecture et réévalués lors de l'interrogation suivante.

  2. Le fichier est renommé de <nom_fichier>.eml en <nom_fichier>.tmp. Si le fichier *<nom_fichier>.*tmp existe déjà, le fichier est renommé en <nom_fichier><datetime>.tmp. En cas d'échec de l'attribution d'un nouveau nom au fichier, une erreur du journal des événements est générée et le processus de relecture passe au fichier suivant.

  3. Une fois le fichier .tmp converti en message électronique, une commande de « suppression à la fermeture » est générée pour le fichier .tmp. Le fichier .tmp semble être conservé dans le répertoire de relecture mais personne d'autre ne peut ouvrir le fichier.

  4. Une fois le message placé en file d'attente pour remise, une commande de « fermeture » est émise et le fichier .tmp est supprimé du répertoire de relecture. En cas d'échec de la suppression, une erreur du journal des événements est générée. En cas de redémarrage du service de transport Microsoft Exchange lorsque le répertoire de relecture contient des fichiers .tmp, ceux-ci sont renommés en fichiers .eml et retraités. Cela pourrait aboutir au transfert de messages en double.

Anatomie d'un fichier de message électronique

Un message électronique SMTP standard est constitué d'une enveloppe de message et d'un contenu de message. L'enveloppe de message contient les informations requises pour la transmission et la remise du message. Le contenu du message comporte les champs d’en-tête de message communément appelé l' en-tête de message et le corps du message. L’enveloppe de message est décrite dans RFC 2821 et l'en-tête de message est décrit dans RFC 2822.

Lorsqu'un expéditeur rédige un message électronique et le dépose pour remise, le message contient les informations de base requises pour la conformité avec les normes SMTP, telles qu'un expéditeur, un destinataire, la date et l'heure de rédaction du message, une ligne d'objet facultative et un corps de message facultatif. Ces informations sont contenues dans le message et, par définition, dans l'en-tête de message. Le serveur de messagerie de l'expéditeur génère une enveloppe de message à l'aide des informations sur l'expéditeur et le destinataire disponibles dans l'en-tête et transmet le message à Internet pour remise. Les destinataires ne voient jamais l'enveloppe qui est ci générée par le processus de transmission du message et ne fait pas partie du message. Chaque serveur impliqué dans la transmission du message peut insérer des champs d'en-tête en relation avec le rôle du serveur dans la remise ou d'autres champs d'en-tête spécifiques aux applications. Lorsque le destinataire ouvre le message à l'aide d'un client de messagerie, ce dernier affiche certaines des informations les plus pertinentes de l'en-tête de message, telles que l'expéditeur, les destinataires et l'objet.

Pour expliquer la relation entre l'enveloppe de message et l'en-tête de message, il est possible de faire un parallèle avec l'envoi d'un courrier classique dans une grande société. Vous rédigez une lettre commerciale formelle indiquant l'adresse de votre société et l'adresse du destinataire dans la partie supérieure de la lettre. Vous transmettez la lettre au service courrier de votre société pour traitement. Le personnel du service courrier crée une enveloppe en utilisant les informations sur le destinataire mentionnées dans la lettre, insère la lettre dans l'enveloppe et referme l'enveloppe, puis dépose le courrier dans une boîte aux lettres pour remise. Le service postal remet l'enveloppe à la société du destinataire sur la base de l'adresse indiquée sur l'enveloppe. Le personnel du service courrier de la société du destinataire reçoit l'enveloppe, identifie le destinataire sur la base de l'enveloppe, ouvre l'enveloppe et place la lettre dans la boîte aux lettres personnelle du destinataire. Lorsque le destinataire récupère votre lettre dans sa boîte aux lettres personnelle, il sait, d'après les informations disponibles dans la partie supérieure de la lettre, que vous avez rédigé la lettre et qu'elle lui ait destinée.

Configuration requise pour les fichiers de messages dans le répertoire de relecture

Le répertoire de relecture est utilisé pour redéposer les messages Exchange exportés et recevoir les messages de serveurs de passerelle étrangers. Ces messages sont déjà formatés dans le répertoire de relecture. Il n'est pas vraiment utile qu'un administrateur ou une autre application rédige et dépose les nouveaux fichiers de messages via le répertoire de relecture. Le répertoire de collecte doit être utilisé pour créer et déposer les nouveaux fichiers de messages.

Les messages du répertoire de relecture sollicitent beaucoup les en-têtes X. Les en-têtes X sont définis par l’utilisateur, les champs d’en-tête de message non officiel existant dans l’en-tête de message. Les en-têtes X ne sont pas spécifiquement mentionnées dans RFC 2822, mais l’utilisation d’un champ d’en-tête de message non défini commençant par « X » est à présent une méthode approuvée d’ajout de champs d’en-tête de message non officiel à un message. Les en-têtes X spécifiques d’Exchange 2007-utilisées dans les fichiers de messages du répertoire de relecture définissent réellement les informations de remise existant normalement dans l’enveloppe de message. Cette fonctionnalité permet de préserver les informations originales du message dans le cadre de l'utilisation du répertoire de relecture pour traiter les messages exportés à partir d'un autre serveur Exchange.

Un fichier de message copié dans le répertoire de relecture doit remplir les conditions suivantes pour être remis :

  • Le fichier de message doit être un fichier texte conforme au format de message SMTP de base. Les champs d'en-tête et le contenu de message MIME (Multipurpose Internet Mail Extensions) sont pris en charge.

  • Le nom du fichier de message doit avoir une extension .eml.

  • Les en-têtes X doivent apparaître devant les autres champs d'en-tête standard.

  • Il doit y avoir une ligne vide entre les champs d'en-tête et le corps du message.

Les champs d'en-tête X décrits dans la liste suivante sont obligatoires pour les messages dans le répertoire de relecture :

  • X-Sender:   Ce champ d'en-tête X remplace l'exigence du champ d'en-tête de message From: dans un message SMTP classique. Il doit y avoir un champ X-Sender: contenant une adresse de messagerie. Le répertoire de relecture ignore le champ d'en-tête de message From: s'il est présent, même si le client de messagerie du destinataire affiche la valeur du champ d'en-tête de message From: comme expéditeur du message. Il existe généralement d'autres paramètres dans le champ X-Sender: comme le montre l'exemple suivant :

    X-Sender: <bob@fabrikam.com> BODY=7bit RET=HDRS ENVID=12345ABCD auth=<someAuth>
    noteRemarque :
    Ces paramètres sont des valeurs d'enveloppe de message habituellement générées par le serveur d'envoi. Les fichiers de messages exportés contiennent des paramètres semblables.
    RET= indique si le message entier ou seulement les en-têtes doivent être renvoyés à l'expéditeur si le message ne peut pas être remis. RET= peut avoir la valeur HDRS ou FULL.
    ENVID= est un identifiant d'enveloppe de message. BODY= spécifie le codage de texte du message. AUTH= spécifie un mécanisme d'authentification au serveur de messagerie, comme décrit dans RFC 2554.

  • X-Receiver:   Cet en-tête X remplace l'exigence du champ d'en-tête de message To: dans un message SMTP classique. Il doit y avoir au moins un champ X-Receiver: contenant une adresse de messagerie. Plusieurs champs d'en-tête X-Receiver: sont autorisés pour plusieurs destinataires. Le répertoire de relecture ignore les champs d'en-tête de message To: s'ils sont présents, même si le client de messagerie du destinataire affiche les valeurs des champs d'en-tête de message To: comme expéditeurs du message. Il peut y avoir d'autres paramètres facultatifs dans les champs X-Receiver: comme le montre l'exemple suivant :

    X-Receiver: <mary@contoso.com> NOTIFY=NEVER ORcpt=mary@contoso.com

    Notes

    Ces paramètres sont des valeurs d'enveloppe de message habituellement générées par le serveur d'envoi. Les fichiers de messages exportés contiennent des paramètres semblables. Ces paramètres sont liés aux messages de notification d'état de remise, comme décrit dans RFC 1891. NOTIFY= peut avoir la valeur NEVER, DELAY ou FAILURE. ORcpt= permet de préserver le destinataire original du message.

Les champs d'en-tête X décrits dans la liste suivante sont facultatifs pour les fichiers de messages dans le répertoire de relecture :

  • X-CreatedBy:   Si ce champ d'en-tête X existe, il ne peut pas être vide. Si le champ X-CreatedBy: n'existe pas, il est ajouté avec la valeur Unspecified. En général, la valeur de ce champ est MSExchange12, mais elle peut également contenir le type d’espace d’adresse non-SMTP défini sur un connecteur d’envoi, tel que Notes. Ce champ d'en-tête de message est utilisé pour la fonctionnalité de pare-feu d'en-tête.

  • X-EndOfInjectedXHeaders:   Taille en octets de tous les en-têtes X présents. Cet en-tête X doit être utilisé comme marqueur pour indiquer le dernier en-tête X avant le début des champs d'en-tête de message normaux.

  • X-ExtendedMessageProps:   Propriétés de message étendues du message.

  • X-HeloDomain:   Chaîne de domaine HELO/EHLO présentée au cours de la conversation de protocole SMTP initiale.

  • X-LegacyExch50:   Permet de préserver les propriétés personnalisées générées par Exchange Server 2003 si des serveurs Exchange 2003 sont présents.

  • X-Source:   Si la valeur de cette en-tête X n’est pas spécifiée, la valeur de Replay est utilisée. Ce champ d'en-tête X est utilisé par l'Afficheur des files d'attente dans la colonne MessageSourceName. Les autres valeurs possibles pour cet en-tête X sont Smtp Receive Connector et Smtp Send Connector.

  • X-SourceIPAddress:   Adresse IP du serveur d'envoi. La valeur de ce champ est 0.0.0.0 si aucune adresse IP n'est spécifiée.

Voici un exemple de message en texte brut utilisant un formatage valide pour le répertoire de relecture :

X-Receiver: <mary@contoso.com> NOTIFY=NEVER ORcpt=mary@contoso.com
X-Sender: <bob@contoso.com> BODY=7bit ENVID=12345AB auth=<someAuth>
Subject: Optional message subject

This is the body of the message.

Le contenu MIME est également pris en charge pour les fichiers de messages du répertoire de relecture. Le système d'encodage MIME définit une part importante du contenu du message, notamment les langues qui ne peuvent pas être représentées sous forme de texte ASCII 7 bits, HTML ou d'autre contenu multimédia. La présente rubrique ne vise pas à donner une description détaillée du système d'encodage MIME et de ses spécifications. Voici un exemple de message MIME simple utilisant un formatage valide pour le répertoire de relecture :

X-Receiver: <mary@contoso.com> NOTIFY=NEVER ORcpt=mary@contoso.com
X-Sender: <bob@contoso.com> BODY=7bit ENVID=12345ABCD auth=<someAuth>
To: mary@contoso.com
From: bob@contoso.com
Subject: Optional message subject
MIME-Version: 1.0
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

<HTML><BODY>
<TABLE>
<TR><TD>cell 1</TD><TD>cell 2</TD></TR>
<TR><TD>cell 3</TD><TD>cell 4</TD></TR>
</TABLE>

</BODY></HTML>

Modifications d'en-tête de message apportées aux fichiers de messages du répertoire de relecture

Le répertoire de relecture supprime le champ d'en-tête de messageBcc: du fichier de message.

Le répertoire de relecture ajoute son propre champ d'en-tête de message Received: à un message dans le cadre du processus de dépôt. Le champ d'en-tête de message Received: est appliqué selon le format suivant :

Received: from <ReceivingServerName> by Replay with <ExchangeServerVersion><DateTime>

Le répertoire de relecture modifie les champs d'en-tête de message suivants dans l'en-tête de message :

  • Message-ID:   Si le champ d'en-tête de message est manquant ou vide, le répertoire de relecture ajoute un champ d'en-tête Message-ID: en utilisant le format <GUID>@<defaultdomain>.

  • Date:   Si ce champ d'en-tête de message est manquant ou mal mis en forme, le répertoire de relecture ajoute le champ d'en-tête Date: en utilisant la date et l'heure auxquelles le message a été traité par le répertoire de relecture.

Défaillances dans le traitement des messages du répertoire de relecture

En cas de problème de conversion d'un fichier de message en message électronique, le répertoire de relecture considère le message comme non remis (message incorrect). Un fichier de message incorrect présente des problèmes graves, tels qu'un expéditeur manquant, des destinataires manquants ou des problèmes de formatage. Les fichiers de messages identifiés comme messages incorrects sont conservés dans le répertoire de relecture et sont renommés de <nom_fichier>.eml en <nom_fichier>.bad. Si le fichier <nom_fichier>.bad existe déjà, le fichier est renommé en <nom_fichier><datetime>.bad. S'il y a des messages incorrects dans le répertoire de relecture, une erreur du journal des événements est générée mais les mêmes messages incorrects ne génèrent pas d'erreurs du journal des événements répétées.

Problèmes de sécurité du répertoire de relecture

Exchange Server 2003 utilise un répertoire de collecte unique pour la création et le dépôt des fichiers de messages. Exchange 2007 fractionne cette fonctionnalité en répertoires de collecte et de relecture distincts. Le répertoire de collecte est destiné aux utilisateurs ou applications afin de créer manuellement des fichiers de messages. Le répertoire de relecture est destiné au nouveau dépôt des messages électroniques Exchange exportés et à la réception des messages des connecteurs non-SMTP. Cette séparation des tâches permet d'appliquer le niveau de sécurité approprié à un répertoire sans affecter les fonctions de l'autre répertoire.

La liste suivante décrit les problèmes de sécurité courants relatifs au répertoire de collecte et au répertoire de relecture :

  • Les contrôles de sécurité configurés sur un connecteur de réception, tels que les opérations de blocage du courrier indésirable et des virus, ou de filtrage des expéditeurs et des destinataires, ne sont pas exécutés sur les messages déposés via le répertoire de collecte et le répertoire de relecture lors du dépôt du message.

  • Un répertoire de collecte ou un répertoire de relecture compromis peut agir comme un relais ouvert. Cela permet aux messages d'être déposés de nouveau ou « relayés » à l'aide d'un autre serveur pour masquer la véritable source des messages.

La liste suivante décrit les autres problèmes de sécurité s'appliquant au répertoire de relecture :

  • Les champs d'en-tête X utilisés par le répertoire de relecture permettent la création manuelle de l'enveloppe de message. Les informations des champs X-Sender: et X-Receiver: peuvent être totalement différentes de celles des champs d'en-tête de message To: ou From: affichées par les clients de messagerie. L'emprunt d'identité d'un expéditeur et d'un domaine est souvent appelée usurpation. Un message électronique falsifié est un message électronique dont l'adresse d'expéditeur a été modifiée pour qu'il semble provenir d'un expéditeur autre que l'expéditeur réel du message.

  • Si la valeur du champ X-CreatedBy: est MSExchange12, la destination est considérée comme fiable et aucun pare-feu d'en-tête n'est appliqué. Un pare-feu d'en-tête est un dispositif permettant à Exchange de préserver les en-têtes X dans les messages transmis entre des serveurs Exchange 2007 approuvés ou de supprimer les en-têtes X susceptibles de divulguer des informations des messages transmis aux destinations non approuvées en dehors de l'organisation Exchange. Ces en-têtes X peuvent être utilisés pour partager des informations Exchange 2007, telles que le seuil de probabilité de courrier indésirable (SCL), la signature des messages ou le chiffrement entre des serveurs Exchange 2007 autorisés. La divulgation de ces informations à des sources non autorisées peut constituer un risque pour la sécurité.

La séparation du répertoire de collecte et du répertoire de relecture vous permet d'appliquer des niveaux de sécurité différents à chaque répertoire. Une sécurité renforcée doit être appliquée au répertoire de relecture en raison des risques pour la sécurité supplémentaires associés au répertoire de relecture. Les utilisateurs ou applications devant générer et déposer de nouveaux messages peuvent être autorisés à accéder au répertoire de collecte mais n'ont pas besoin d'accéder au répertoire de relecture.

Autorisations pour le répertoire de relecture

Les autorisations suivantes sont obligatoires sur le répertoire de relecture :

  • Administrateur : Contrôle total

  • Système : Contrôle total

  • Service réseau : Lecture, écriture et suppression des sous-dossiers et fichiers

Par défaut, le service de transport Microsoft Exchange utilise les informations d'identification de sécurité du compte d'utilisateur de service réseau pour gérer l'emplacement et les autorisations du répertoire de relecture. Le compte de service réseau doit disposer de ces autorisations sur le répertoire de relecture de façon à ce que les fichiers .eml puissent être ouverts, renommés en fichiers .tmp et supprimés, ou renommés en fichiers .bad si le message est classé comme message incorrect.

Vous pouvez déplacer le répertoire de relecture à l'aide du paramètre ReplayDirectoryPath avec la cmdlet Set-TransportServer. Le déplacement effectif du répertoire de relecture dépend des droits attribués au compte de service réseau sur le nouveau répertoire de relecture et de l'existence du nouveau répertoire de relecture. Si le nouveau répertoire de relecture n'existe pas déjà et que le compte de service réseau dispose des droits nécessaires à la création de dossiers et à l'application d'autorisations au nouvel emplacement, alors le nouveau répertoire de relecture est créé et les autorisations appropriées lui sont appliquées. Si le nouveau répertoire de relecture existe déjà, les autorisations existantes sur les dossiers ne sont pas vérifiées. Chaque fois que vous déplacez le répertoire de relecture à l'aide du paramètre ReplayDirectoryPath avec la cmdlet Set-TransportServer, il est toujours recommandé de vérifier que le nouveau répertoire de relecture existe déjà et que les autorisations appropriées lui sont appliquées. En cas d'échec du déplacement du répertoire de relecture, vous pouvez créer le répertoire de relecture et lui appliquer les autorisations appropriées avant d'utiliser le paramètre ReplayDirectoryPath avec la cmdlet Set-TransportServer.

Pour plus d'informations

Pour plus d'informations, consultez les rubriques suivantes :