Gestion du répertoire de collecte

  • 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 collecte est disponible sur chaque ordinateur Microsoft Exchange Server 2007 sur lequel le rôle serveur de transport Hub ou de transport Edge est installé. Les fichiers de messages correctement formatés que vous copiez dans le répertoire de collecte sont déposés pour remise. Le répertoire de collecte est utilisé par des administrateurs pour tester le flux de messagerie ou par des applications qui doivent créer et soumettre leurs propres messages.

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

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

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

  • spécification d'une taille maximale d'en-tête de fichier de message accepté par le répertoire de collecte ;

  • spécification d'un nombre maximal de destinataires dans un fichier de message accepté par le répertoire de collecte ;

  • 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 collecte

Un fichier de message .eml correctement formaté copié dans le répertoire de collecte 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 collecte. 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 collecte et réévalués lors de l'interrogation suivante.

  2. Certaines limites imposées aux fichiers de messages dans le répertoire de collecte, telles que la taille maximale d'en-tête et le nombre maximal de destinataires, sont vérifiées. Par défaut, la taille maximale d'en-tête est 64Ko et le nombre maximal de destinataires est 100. Vous pouvez modifier ces limites à l'aide de la cmdlet Set-TransportServer.

  3. 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 collecte passe au fichier suivant.

  4. 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 collecte mais personne d'autre ne peut ouvrir le fichier.

  5. 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 collecte. 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 collecte 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 pour le message à l'aide des informations sur l'expéditeur et le destinataire disponibles dans l'en-tête de message et transmet le message à Internet pour remise au serveur de messagerie du destinataire. 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 du message ou d'autres champs d'en-tête de message 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 avec le corps du message.

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 collecte

Un fichier de message copié dans le répertoire de collecte 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.

  • Il doit exister au moins une adresse de messagerie dans les champs d’en-tête de message Sender ou From:. S'il n'y a qu'une seule adresse de messagerie dans les champs Sender et From:, l'adresse de messagerie figurant dans le champ From: est utilisée comme origine du message dans l'enveloppe de message.

  • Il ne peut y avoir qu'une seule adresse de messagerie dans le champ Sender. Les adresses de messagerie multiples ne sont pas autorisées. Le champ Expéditeur est facultatif s'il n'y a qu'une seule adresse de messagerie dans le champ From:.

  • Plusieurs adresses de messagerie sont autorisées dans le champ From:, mais il ne peut y en avoir qu'une seule dans le champ Sender. L'adresse figurant dans le champ Sender est utilisée comme expéditeur du message dans l'enveloppe de message.

  • Au moins une adresse de messagerie doit figurer dans les champs To:, Cc: ou Bcc:.

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

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

To: mary@contoso.com
From: bob@fabrikam.com
Subject: 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 collecte. 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 collecte :

To: mary@contoso.com
From: bob@fabrikam.com
Subject: 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 collecte

Le répertoire de collecte supprime les champs d'en-tête de message suivants du fichier de l'en-tête de message :

  • Received:

  • Resent-*:

  • Bcc:   Toutes les adresses de messagerie figurant dans les champs d'en-tête de message Bcc: facultatifs de l'en-tête de message sont correctement traités. Une fois les destinataires Bcc: promus comme destinataires de l'enveloppe de message invisibles, ils sont supprimés de l'en-tête de message afin de protéger leur identité. Si un message ne contient que des destinataires Bcc:, la valeur « Undisclosed Recipients » est ajoutée au champ To: dans l'en-tête de message.

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

Received: from localhost by Pickup with Microsoft SMTP Server id <ExchangeServerVersion><datetime>

Le répertoire de collecte modifie les champs d'en-tête de message suivants s'ils sont manquants ou incorrects :

  • Message-Id   Si le champ Message-Id est manquant ou vide, le répertoire de collecte ajoute un champ Message-Id en utilisant le format <GUID>@<defaultdomain>.

  • Date:   Si le champ Date est manquant ou incorrect, le répertoire de collecte ajoute la date et l'heure auxquelles le message a été traité par le répertoire de collecte.

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

Un fichier de message copié dans le répertoire de collecte n'a peut-être pas été placé en file d'attente de remise avec succès. Les catégories suivantes d'erreur de remise de messages peuvent se présenter :

  • Échecs de remise   Un fichier de message correctement mis en forme et associé à un expéditeur valide qui ne peut pas être remis avec succès par le répertoire de collecte génère une notification d'échec de remise. Un contenu incorrect ou des violations de restriction de message de répertoire de collecte peuvent également entraîner la génération d'un rapport de non-remise par le répertoire de collecte. En cas de génération d'un rapport de non-remise durant le traitement d'un message de répertoire de collecte, le fichier de message original est joint au message de rapport de non-remise et le fichier de message est supprimé du répertoire de collecte.

    Notes

    Un message correctement mis en forme soumis par le répertoire de collecte peut rencontrer ensuite un échec de remise et être renvoyé à l'expéditeur avec un rapport de non-remise. Ce type de défaillance peut être dû à des problèmes de transmission sans relation avec le répertoire de collecte, tels que des défaillances du serveur de messagerie ou des problèmes de routage sur le chemin de remise du message.

  • Message incorrect   Un message classifié comme incorrect présente des problèmes sérieux qui empêchent le répertoire de collecte de soumettre le message pour remise. L'autre condition à l'origine d'un message incorrect est quand le message est correctement mis en forme mais que les destinataires ne sont pas valides et qu'un message de rapport de non-remise ne peut pas être envoyé à l'expéditeur car ce dernier n'est pas valide.

    Les fichiers de messages identifiés comme messages incorrects sont conservés dans le répertoire de collecte 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 collecte, 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.

Notes

Composez et enregistrez toujours les fichiers de messages dans un autre emplacement avant de les copier dans le répertoire de collecte pour remise. Le répertoire de collecte analyse les nouveaux messages toutes les 5 secondes. C'est pourquoi, si vous tentez de composer et d'enregistrer les fichiers de messages dans le répertoire de collecte proprement dit, ce dernier peut essayer de traiter les fichiers de messages avant que vous n'acheviez de les composer.

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

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 serveurs de passerelle étrangers.

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 ou le répertoire de relecture.

  • 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 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 des 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.

Le répertoire de collecte et le répertoire de relecture sont activés par défaut sur tous les serveurs de transport Hub et de transport Edge. Si le répertoire de collecte ou le répertoire de relecture ne sont pas requis sur un serveur de transport Hub ou de transport Edge spécifique dans votre organisation, vous pouvez désactiver le répertoire de collecte ou le répertoire de relecture sur ce serveur. Pour plus d'informations, consultez les rubriques suivantes :

Autorisations pour le répertoire de collecte

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

  • 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 collecte. Le compte de service réseau doit disposer de ces autorisations sur le répertoire de collecte 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 collecte à l'aide du paramètre PickupDirectoryPath avec la cmdlet Set-TransportServer. Le déplacement effectif du répertoire de collecte dépend des droits attribués au compte de service réseau au nouvel emplacement du répertoire de collecte et de l'existence du nouveau répertoire de collecte. Si le nouveau répertoire de collecte 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 collecte est créé et les autorisations appropriées lui sont appliquées. Si le nouveau répertoire de collecte 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 collecte à l'aide du paramètre PickupDirectoryPath avec la cmdlet Set-TransportServer, il est toujours recommandé de vérifier que le nouveau répertoire de collecte existe déjà et que les autorisations appropriées lui sont appliquées. En cas d'échec du déplacement du répertoire de collecte, vous pouvez créer le répertoire de collecte et lui appliquer les autorisations appropriées avant d'utiliser le paramètre PickupDirectoryPath avec la cmdlet Set-TransportServer.

Pour plus d'informations

Pour plus d'informations, consultez les rubriques suivantes :