Questions et réponses sur la file d'attente ExchangeProtocoles de courrier électronique sécurisés, courrier indésirable mystérieux, et bien plus encore

Nino Bilic and Scott Landry

Cette chronique est partiellement basée sur une version bêta de Windows Server 2008. Toutes les informations contenues dans cet article sont susceptibles d’être modifiées.

Q Je veux utiliser le protocole SMTP sécurisé. Comment faire pour qu'Exchange Server écoute SMTP sur le port 465 ?

R Je suis désolé, mais c'est impossible. Oui, vous pouvez faire en sorte que n'importe quel serveur virtuel SMTP ou connecteur de réception écoute sur le port 465, mais vous n'atteindrez pas votre objectif de SMTP sécurisé (SMTPS).

Pourquoi ? Bon, remontons quelque peu aux origines pour comprendre la situation. Il existe deux types de SSL : explicite et implicite. Au début, la plupart du trafic SSL était implicite, c'est-à-dire qu'un port dédié à SSL était utilisé. Par exemple, HTTP est sur le port 80 par défaut, mais HTTPS (HTTP avec SSL) est sur le port 443. Il y a plusieurs années, la communauté Internet a décidé qu'il n'était pas nécessaire d'utiliser un port dédié pour SSL. C'est ainsi que le SSL explicite est né.

Netscape avait déjà choisi 465 comme port SMTPS, mais Exchange Server ne disposait pas de la fonctionnalité SSL dans SMTP. Cependant, l'équipe d'Exchange a compris l'avantage du SSL explicite (à savoir qu'il pouvait être utilisé de la même façon par les clients et les serveurs) et a choisi de prendre en charge le SSL explicite pour SMTP.

Dans le cas du SMTP, le SSL explicite utilise la commande STARTTLS ESMTP pour signaler que le socket existant est sur le point d'être sécurisé. La plupart des autres fournisseurs de serveurs et clients SMTP ont également implémenté la commande STARTTLS, si bien qu'il n'a pas vraiment été nécessaire de prendre en charge le port 465 qui, de toute façon, n'était pas une norme Internet officielle.

Aujourd'hui encore, aucune version d'Exchange Server ne prend en charge le SSL implicite pour SMTP. Demander à un connecteur de réception Exchange ou à un serveur virtuel SMTP d'écouter sur le port 465 ne modifie pas cet état de chose. Vous devez donc utiliser un client qui prend en charge STARTTLS sur le port 25. Si vous ne pouvez pas utiliser le port 25, le choix logique suivant est 587, qui est le port standard pour les soumissions SMTP des clients. La plupart des clients modernes prennent en charge STARTTLS sur 25, c'est pourquoi l'ajout de la prise en charge du SSL implicite n'a pas été nécessaire.

À propos, les protocoles Exchange POP3 et IMAP4 ont toujours pris en charge le SSL implicite. Mais dans Exchange Server 2007, une prise en charge du SSL explicite a également été ajoutée pour ces deux protocoles. Dans la mesure où peu de clients prennent actuellement en charge cette toute nouvelle norme, le SSL implicite continuera d'être utilisé pendant un certain temps encore.

Q J'ai une grande quantité de courrier en file d'attente dans un certain nombre de domaines et aucun de mes utilisateurs n'a envoyé ce courrier. Comment cela se fait-il et comment empêcher que cela ne se reproduise ?

R Vous n'êtes pas le seul dans ce cas. Quiconque possède un serveur sur Internet est susceptible de rencontrer ce problème. En fait, il existe deux causes possibles. La première est que vous avez ouvert vous-même votre serveur en tant que relais (reportez-vous à support.microsoft.com/kb/304897). Mais bien sûr vous ne feriez pas cela, n'est-ce pas ? (Les relais ouverts sont désactivés par défaut depuis Exchange Server 2000.) Il est donc plus probable que vous soyez confronté à du courrier indésirable sous forme de rapport de non-remise (NDR). Dans le processus d'envoi de courrier publicitaire non sollicité (UCE), les expéditeurs de courrier indésirable envoient souvent leurs messages à des adresses inexistantes dans votre domaine. Votre serveur essaie de faire comprendre à l'expéditeur de courrier indésirable que les utilisateurs n'existent pas, mais bien sûr, l'expéditeur de courrier indésirable a trafiqué l'adresse de retour. L'expéditeur de courrier indésirable peut trafiquer une adresse non valide (dans ce cas le rapport de non-remise est en instance jusqu'à l'expiration du délai) ou peut essayer de faire envoyer par votre serveur un courrier indésirable à un autre domaine, en tant que pièce jointe du rapport de non-remise généré par votre serveur.

Vous pouvez désactiver les rapports de non-remise, mais si un utilisateur légitime fait une faute de frappe dans une adresse par erreur, votre serveur ne l'informera jamais de la non-remise du message électronique et des messages importants risquent d'être perdus. Voici une meilleure solution.

Vérifiez tout d'abord que vous n'avez pas ouvert le relais. (Il fallait que je le dise, car on ne sait jamais.) Activez ensuite un type de filtrage anti-courrier indésirable quelconque, tel que le filtre de message intelligent ou le filtre de contenu d'Exchange Server 2007, ainsi que quelques listes rouges en temps réel. Ces éléments peuvent se trouver soit dans le rôle serveur de transport Edge, soit dans le rôle serveur de transport Hub. Quoi qu'il en soit, cette opération doit s'effectuer au niveau du tout premier tronçon, car plus de 90 % du volume de courrier est vraisemblablement indésirable et vous ne voulez pas encombrer vos serveurs avec ce courrier indésirable).

Enfin, activez le filtrage du destinataire sur le premier serveur Exchange Server qui accepte la réception du courrier dans votre environnement. Votre serveur peut ainsi rejeter un message avant qu'il ne pénètre dans votre réseau. Les fautes de frappe dans l'adresse légitimes feront l'objet d'un rapport de non-remise, mais qui sera généré par le serveur de l'expéditeur.

Q J'utilisais un serveur exécutant Exchange Server 2000 et un autre exécutant Exchange Server 2003. Les deux parvenaient à envoyer du courrier via Internet. J'ai ensuite installé Exchange Server 2007 et maintenant, les boîtes aux lettres sur chaque serveur ne parviennent plus à envoyer le courrier.

R Si vous n'aviez qu'un seul serveur Exchange Server par le passé, vous ne connaissez peut-être pas le concept des connecteurs. Les connecteurs d'échange sont des objets de configuration de routage logiques qui indiquent à Exchange où diriger le message électronique. Lorsque vous introduisez Exchange Server 2007 dans une organisation existante, pour acheminer le courrier, vous devez absolument disposer de connecteurs de groupe de routage et d'un connecteur SMTP.

Vous avez besoin de deux connecteurs de groupe de routage, un allant du groupe de routage Exchange Server 2007 vers le groupe de routage Exchange Server 2003 et vice-versa. Vous pouvez effectuer cette configuration dans le cadre du processus d'installation, mais si vous ne l'avez pas fait ou si vous n'en êtes pas sûr, vous pouvez vérifier en utilisant Exchange Management Shell d'où vous pouvez corriger le problème. À défaut, vous ne pourrez pas envoyer de courrier entre vos serveurs. Les messages finiront dans des files d'attente de destination inaccessibles.

Pour acheminer le courrier Internet, vous n'avez besoin que d'un seul connecteur SMTP, également appelé « connecteur d'envoi » dans Exchange Server 2007. Vous devez en avoir un dans Exchange Server 2000 et Exchange Server 2003, mais vous n'avez peut-être jamais eu à vous en servir. L'espace d'adresse doit être SMTP:* pour tous les domaines et vous pouvez spécifier l'utilisation d'un hôte intelligent ou d'un DNS pour la remise du courrier. Vous choisissez si vous souhaitez que le courrier Internet sortant soit géré par le serveur Exchange Server 2007 ou le serveur plus ancien, ou vous pouvez en créer un sur les deux groupes de routage si vous voulez que chaque serveur gère son propre courrier. Vous pouvez également créer l'un des connecteurs dans le cadre du processus Edgesync si vous avez installé un rôle de serveur de transport Edge.

Si vous avez précédemment installé un hôte intelligent sur le serveur virtuel SMTP, c'est le moment de le supprimer. Il ne doit se trouver que sur le connecteur SMTP, jamais sur le serveur virtuel car cela bloque le connecteur de groupe de routage.

Vous devez également savoir que le courrier électronique entrant est contrôlé par votre enregistrement MX ou par l'IP vers laquelle le pare-feu effectue le transfert. Côté Exchange, la configuration est minime, mais ce document devrait vous aider si vous rencontrez des problèmes : msexchangeteam.com/archive/2006/11/17/431555.aspx.

Q Pourquoi est-ce que j'obtiens plusieurs rapports de journal pour le même message dans Exchange Server 2007 ?

R L'agent de journalisation de transport Exchange Server 2007 effectue une journalisation des messages après catégorisation. Il existe de nombreuses raisons pour lesquelles le catégoriseur peut faire bifurquer un message (c'est-à-dire copier le corps du message et mettre différents destinataires d'enveloppe sur les différentes copies). Voici un exemple : dans la mesure où la journalisation peut maintenant vous indiquer l'appartenance d'un groupe de distribution à l'heure où le message a été envoyé, dans le cas d'un groupe de distribution imbriqué, vous pouvez obtenir plusieurs rapports.

Grâce à cette fonctionnalité supplémentaire de la création des rapports, vous pouvez obtenir plusieurs copies du même message, chacune avec un rapport unique. Cela ne garantit pas de façon certaine que tous les rapports correspondant à un message sont arrivés, mais si vous faites de l'archivage, vous devrez collaborer avec votre fournisseur d'archives pour vous assurer qu'il est conscient des modifications.

Q Où est passée la fonction de transfert des messages non résolus vers l'hôte dans Exchange Server 2007 ? Que dois-je faire maintenant ?

R Elle a disparu.

En fait, cette fonction spécifique ne fonctionnait pas correctement lorsque vous disposiez de plusieurs serveurs Exchange Server. Exchange disposait déjà une autre méthode beaucoup plus puissante pour accomplir la même tâche. En particulier, vous avez la possibilité de partager des domaines SMTP individuels avec autres systèmes. Donc la fonction « transfert non résolu » a été abandonnée et le concept de domaine partagé a été implémenté et simplifié. Dans Exchange Server 2007, il vous suffit d'accéder à Organisation | Transport Hub | Domaines acceptés et de modifier le type de domaine de Faisant autorité à Relais interne. C'est en fait un peu plus complexe que cela pour certains environnements et nous travaillons à la mise à jour de la documentation. Mais ceci devrait vous aider entre temps.

Q J'essaie de préparer mon domaine racine pour l'installation d'Exchange Server 2007. Le serveur à partir lequel j'essaie d'exécuter l'installation d'Exchange Server 2007, est déjà équipé du Gestionnaire système Exchange d'Exchange Server 2003 et l'installation échoue. Quel est le problème ?

En résumé, l'exécution de toute partie de l'installation d'Exchange Server 2007 sur une machine sur laquelle sont installés des composants Exchange Server 2000 ou 2003 n'est pas prise en charge. Comme le Gestionnaire système Exchange d'Exchange Server 2003 est installé, l'installation d'Exchange Server 2007 le voit et la vérification préalable à l'installation échoue. Le message suivant s'affiche : « Une version précédente d'Exchange Server est déjà installée sur cet ordinateur. Exécutez le programme d'installation Exchange 2007 depuis un autre ordinateur ou supprimez la version précédente d'Exchange Server ».

La façon la plus simple de contourner ce problème consiste probablement à exécuter l'installation Exchange Server 2007 à partir d'un autre serveur dans le domaine racine et de préparer votre domaine de cette façon. Si ce n'est pas possible, vous devez désinstaller le composant Exchange Server 2003 avant de poursuivre l'installation d'Exchange Server 2007.

N'oubliez pas que vous pouvez utiliser la version 32 bits d'Exchange Server 2007 pour préparer le domaine. Ainsi vous pouvez utiliser n'importe quel serveur 32 bits dans le domaine racine. Pour plus d'informations, consultez l'article à l'adresse technet.microsoft.com/library/bb232170.aspx.

À propos, cela signifie que vous ne pouvez pas installer le Gestionnaire système Exchange d'Exchange Server 2003 et la console de gestion Exchange d'Exchange Server 2007 sur le même ordinateur. En effet, la coexistence des outils de gestion d'Exchange Server 2003 et Exchange Server 2007 sur le même ordinateur n'est pas prise en charge. Exchange Server 2007 bloque l'installation si vous tentez de l'installer sur un ordinateur sur lequel un composant Exchange Server 2000 ou Exchange Server 2003 est installé.

Notez enfin que vous ne devez pas essayer d'installer d'abord les outils de gestion Exchange Server 2007, puis les outils Exchange Server 2003 sur le même ordinateur. Cette méthode vous place dans une configuration qui n'a pas été testée et qui peut donner des résultats imprévus lorsque vous essayez de gérer vos serveurs. Si vous voulez gérer les deux versions de serveur à partir d'un seul ordinateur, vous pouvez utiliser le bureau à distance pour vous connecter à une version, ou utiliser une machine virtuelle pour héberger une version différente des outils de gestion dans un environnement isolé.

Q Quand donc pourrai-je enfin exécuter les outils de gestion d'Exchange Server 2007 sur mon poste de travail Windows Vista® ?

R La prise en charge officielle des outils de gestion d'Exchange Server 2007 sur Windows Vista est prévue dans le Service Pack 1 d'Exchange Server 2007. Un package contenant les outils de gestion d'Exchange Server 2007 SP1 pourra être téléchargé dès la commercialisation d'Exchange Server 2007 SP1.

Q Qu'en est-il du Gestionnaire système Exchange d'Exchange Server 2003 sur Windows Vista ou Windows Server 2008 ? Pourrai-je également les exécuter ?

R Non, malheureusement cela ne fonctionnera pas. Les outils de gestion de toute version d'Exchange Server antérieure à Exchange Server 2007 SP1 ne seront pas pris en charge par Windows Vista ou Windows Server 2008. En d'autres termes, même après la commercialisation de Windows Server 2008, l'installation du Gestionnaire système Exchange d'Exchange Server 2003 sur ce logiciel ne sera pas prise en charge. La gestion des serveurs Exchange Server 2003 doit s'effectuer à partir de stations de travail Windows Server 2003 ou de postes de travail de Windows XP. Sinon, vous pouvez également utiliser la connexion Bureau à distance de n'importe quel système d'exploitation.

Q J'exécute plusieurs serveurs Exchange Server 2003 dans mon domaine. Pourrai-je mettre à niveau mes contrôleurs de domaine vers des contrôleurs de domaine Windows Server 2008 ?

R Oui, tout à fait. L'exécution d'Exchange Server 2003 SP2 dans un domaine possédant des contrôleurs de domaine Windows Server 2008 est prise en charge. Veuillez noter qu'Exchange Server ne peut pas utiliser les contrôleurs de domaine en lecture seule (RODC) ou les serveurs de catalogue global en lecture seule (ROGC) de Windows Server 2008. Si vous spécifiez manuellement (par codage en dur) à Exchange Server d'utiliser les RODC/ROGC de Windows Server 2008, vous risquez d'être confronté à un comportement imprévu.

Nino Bilic, responsable du programme de capacité de prise en charge pour Exchange Server, consacre ses loisirs à la découverte de la beauté de la communication de serveur à serveur en lisant une tonne d'analyses Netmon le soir avant de s'endormir.

Scott Landrytechnicien de support de gestion pour Exchange Server, ne se déplace jamais sans sa serviette, un exemplaire du Guide et son fidèle téléphone mobile Windows

© 2008 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.