Partager via


Présentation de la réécriture d'adresses

 

S’applique à : Exchange Server 2010 SP2, Exchange Server 2010 SP3

Dernière rubrique modifiée : 2015-03-09

Dans MicrosoftExchange Server 2010, la réécriture d’adresses permet de modifier les adresses des expéditeurs et des destinataires sur les messages entrants et sortants de votre organisation Exchange 2010.

Souhaitez-vous rechercher les tâches de gestion relatives à la gestion des serveurs de transport ? Voir Gestion des serveurs de transport.

Contenu de cette rubrique

Pourquoi utiliser la réécriture d’adresses ?

Scénarios de réécriture d’adresses

En-têtes de messages SMTP

Éléments non pris en charge par les agents de réécriture d’adresses

Considérations en relation avec l’utilisation de la réécriture d’adresses en sortie seulement

Considérations relatives à la réécriture d’adresses bidirectionnelle

Considérations relatives à la réécriture d’adresses dans plusieurs domaines

Définition des priorités des entrées de réécriture d’adresses

Messages signés, chiffrés et protégés numériquement

Pourquoi utiliser la réécriture d’adresses ?

Vous pouvez utiliser la réécriture d’adresses pour présenter un aspect cohérent aux destinataires externes de messages de votre organisation Exchange 2010. La fonction de réécriture d’adresses peut s’avérer précieuse si votre organisation utilise des fournisseurs tiers pour la prise en charge et d’autres services de messagerie électronique. Vos clients et partenaires s’attendent à ce que les messages électroniques proviennent de votre organisation, non d’un fournisseur tiers. De même, suite à une fusion ou une acquisition, il se peut qu’une organisation veuille que tous les messages électroniques semblent venir de la nouvelle organisation constituée. La fonction de réécriture d’adresses offre aux organisations la flexibilité nécessaire pour structurer leurs activités sur la base d’exigences commerciales plutôt que d’exigences ou de contraintes techniques.

Vous pouvez également utiliser la réécriture d’adresses pour permettre un routage approprié de messages entrants depuis l’extérieur de votre organisation Exchange 2010 vers des destinataires internes. La réécriture d’adresses permet que les réponses aux messages réécrits soient correctement routées vers l’expéditeur original du message réécrit.

Vous configurez les agents de réécriture d’adresses sur le connecteur de réception et le connecteur d’envoi d’un ordinateur sur lequel le rôle serveur de transport Edge est installé.

Retour au début

Scénarios de réécriture d’adresses

Les scénarios suivants montrent l’utilité de la réécriture d’adresses pour les organisations :

  • Consolidation de groupe   Certaines organisations segmentent leurs activités internes en domaines distincts en fonction d’exigences commerciales ou techniques. Toutefois, cette configuration peut avoir pour effet que les messages électroniques semblent provenir de groupes distincts, voire d’organisations différentes. Cette apparence n’est pas nécessairement souhaitable pour votre organisation.

    L’exemple suivant montre comment une organisation, Contoso, Ltd., peut masquer ses sous-domaines :

    • Les messages sortants des domaines Northamerica.contoso.com, Europe.contoso.com et Asia.contoso.com, sont réécrits pour se présenter comme s’ils provenaient tous d’un seul et même domaine Contoso.com. Tous les messages sont réécrits au fur et à mesure qu’ils transitent par les serveurs de transport Edge qui assurent la connectivité SMTP entre l’organisation et Internet.

    • Les messages entrant dans le domaine Contoso.com sont transférés par le serveur de transport Edge au rôle serveur de transport Hub qui détermine ensuite le destinataire approprié. Par exemple, les messages adressés à chris@contoso.com sont envoyés à un serveur de transport Hub interne qui détermine ensuite la boîte aux lettres à laquelle les envoyer, en utilisant l’adresse proxy configurée sur le compte de messagerie du destinataire.

  • Fusions et acquisitions   En cas de fusion ou d’acquisition d’organisations, il se peut que leur infrastructure technologique soit modifiée afin de répondre à diverses exigences commerciales et techniques. Une société acquise peut continuer à fonctionner comme une division distincte, mais l’administrateur de messagerie peut utiliser la réécriture d’adresses pour faire en sorte que les deux organisations semblent ne former qu’une seule et même organisation intégrée.

    L’exemple suivant montre comment Contoso, Ltd. pourrait masquer le domaine de messagerie de la société acquise, Fourth Coffee :

    • Contoso, Ltd. souhaite que tous les messages sortant de l’organisation Exchange de Fourth Coffee semblent provenir de Contoso.com. Tous les messages des deux organisations sont envoyés via les serveurs de transport Edge de Contoso, Ltd., où les messages électroniques sont réécrits de façon à ce qu’une adresse untel@fourthcoffee.com devienne untel@contoso.com.

    • Les messages entrants adressés à adam@contoso.com sont réécrits et routés vers son compte de messagerie adam@fourthcoffee.com. Les messages entrants qui utilisent son ancien domaine adam@fourthcoffee.com sont également acceptés car le domaine existe toujours. Les réponses entrantes aux messages électroniques qui ont été réécrits sont gérées par les serveurs de transport Edge chez Contoso, Ltd., où l’agent de réécriture d’adresses réécrit l’adresse du destinataire de façon à ce que les réponses soient correctement routées vers l’adresse de messagerie Fourthcoffee.com appropriée. Les réponses aux messages électroniques qui ont été envoyées, avant la fusion, à des adresses de messagerie Fourthcoffee.com sont routées directement vers des serveurs de messagerie de Fourth Coffee.

  • Partenaires   De nombreuses organisations utilisent des partenaires externes pour fournir des services à leurs clients, d’autres partenaires ou l’organisation proprement dite. Afin d’éviter toute confusion, l’organisation peut remplacer le domaine de messagerie de l’organisation partenaire par son propre domaine de messagerie.

    L’exemple suivant montre comment Contoso, Ltd. peut masquer le domaine de messagerie d’un partenaire :

    • Contoso, Ltd. apporte son soutien à une organisation de plus grande taille, Wingtip Toys. Wingtip Toys souhaite une expérience unifiée pour ses clients et que tous les messages en provenance du service de support technique de Contoso, Ltd. apparaissent comme s’ils étaient expédiés par Wingtip Toys. Tous les messages sortants concernant Wingtip Toys sont expédiés via leurs serveurs de transport Edge et toutes les adresses Contoso.com sont réécrites afin d’apparaître comme des adresses Wingtiptoys.com.

    • Les messages entrants à destination de support@wingtiptoys.com sont acceptés par les serveurs de transport Edge de Wingtip Toys, sont réécrits, puis routés vers l’adresse de messagerie support@contoso.com.

      AttentionAttention :
      Pour que les messages entrants soient mappés et routés de façon appropriée, vous devez vous assurer que la partie nom d’utilisateur de l’adresse est unique parmi toutes les organisations de messagerie susceptibles d’être affectées par la réécriture d’adresses.

Retour au début

En-têtes de messages SMTP

Les agents de réécriture d’adresses réécrivent les adresses de messagerie en réécrivant les en-têtes SMTP sur les messages électroniques échangés avec un serveur de transport Edge. Les agents de réécriture d’adresses réécrivent généralement les messages sortants car l’organisation souhaite masquer les domaines et sous-domaines internes le plus efficacement possible et présenter un domaine externe unique sur Internet. Les agents de réécriture d’adresses réécrivent généralement des messages entrants pour router ces messages vers les destinataires auxquels ils sont adressés. C’est pourquoi les agents de réécriture d’adresses réécrivent plusieurs champs d’en-tête SMTP sur les messages électroniques sortants. Les agents de réécriture d’adresses réécrivent un seul champ d’en-tête SMTP sur les messages électroniques entrants. Le tableau suivant montre les champs d’en-tête SMTP réécrits sur les messages sortants et entrants.

Champs d’en-tête SMTP réécrits sur les messages sortants et entrants

Champ d’en-tête SMTP Sortant Entrant

Envelope From (MAIL FROM)

Réécrit

Non réécrit

Envelope To (RCPT TO)

Non réécrit

Réécrit

Body To

Réécrit

Non réécrit

Body Cc

Réécrit

Non réécrit

Body From

Réécrit

Non réécrit

Body Sender

Réécrit

Non réécrit

Body Reply-To

Réécrit

Non réécrit

Body Return-Receipt-To

Réécrit

Non réécrit

Body Disposition-Notification-To

Réécrit

Non réécrit

Body Resent-From

Réécrit

Non réécrit

Body Resent-Sender

Réécrit

Non réécrit

Retour au début

Éléments non pris en charge par les agents de réécriture d’adresses

Les agents de réécriture d’adresses ne réécrivent pas plusieurs champs d’en-tête SMTP, car la réécriture d’adresses entraînerait une rupture de la fonctionnalité SMTP. Par exemple, la modification de ces en-têtes SMTP peut affecter la détection de boucle de message, invalider la signature ou rendre illisible un message protégé par des droits. Les champs d’en-tête SMTP suivants ne sont pas modifiés par les agents de réécriture d’adresses :

  • Return-Path

  • Received

  • Message-ID

  • X-MS-TNEF-Correlator

  • Content-Type Boundary=string

  • Headers located inside MIME body parts

Les agents de réécriture d’adresses ne réécrivent pas non plus les champs d’en-tête dans les messages électroniques qui contiennent des domaines pour lesquels le serveur de transport Hub ne fait pas autorité. La réécriture de tels domaines entraîne une forme incontrôlable de retard de message.

Les agents de réécriture d’adresses ne modifient pas non plus les champs d’en-tête de messages imbriqués dans un autre message. Les expéditeurs et les destinataires s’attendent à ce que les messages imbriqués restent intacts et soient remis sans modification, pour autant qu’ils ne déclenchent pas de règles de transport implémentées entre l’expéditeur et le destinataire.

Retour au début

Considérations en relation avec l’utilisation de la réécriture d’adresses en sortie seulement

Quand un message électronique sort de l’organisation Exchange 2010, la réécriture d’adresses en sortie seulement implique uniquement la modification de l’adresse SMTP de l’expéditeur. L’agent de réécriture d’adresses est configuré uniquement sur le connecteur d’envoi du serveur de transport Edge. La liste suivante présente les conditions requises pour configurer un agent de réécriture d’adresses en sortie seulement :

  • Les adresses qui en résultent doivent être uniques au sein de l’organisation. Par exemple, si les adresses de messagerie uniques ed@sales.contoso.com et ed@research.contoso.com sont incluses dans une règle visant à réécrire toutes les adresses en contoso.com, l’agent de réécriture d’adresses réécrit les deux adresses en ed@contoso.com et génère un conflit.

  • Une adresse proxy doit être configurée sur chaque boîte aux lettres correspondant à l’adresse de messagerie réécrite. Cela permet à ces boîtes aux lettres de recevoir des réponses à des messages électroniques dont les en-têtes sont réécrits.

  • Lorsque vous utilisez des caractères génériques, un point doit figurer entre le caractère générique et le nom de domaine.

  • Vous ne pouvez utiliser des caractères génériques que dans le domaine interne.

  • Aucun caractère ne peut être inséré devant le caractère générique.

  • La réécriture d’adresses en sortie seulement ne peut pas affecter la partie nom d’utilisateur ou nom complet de l’adresse.

  • Seules les chaînes littérales sont prises en charge.

Retour au début

Considérations relatives à la réécriture d’adresses bidirectionnelle

La réécriture d’adresses bidirectionnelle modifie l’adresse SMTP de l’expéditeur sur les messages électroniques sortant de l’organisation Exchange et l’adresse SMTP du destinataire sur des messages électroniques entrant dans l’organisation Exchange. Pour ce faire, configurez l’agent de réécriture d’adresses sur les connecteurs d’envoi et de réception sur le serveur de transport Edge.

La liste suivante présente les conditions requises lorsque vous créez un agent de réécriture d’adresses bidirectionnel :

  • Vous ne pouvez pas utiliser de caractères génériques.

  • Lorsque vous configurez une règle de réécriture d’adresses bidirectionnelle, vous devez utiliser des adresses SMTP complètes. Par exemple, l’adresse interne est chris@contoso.com et l’adresse externe, support@contoso.com.

  • Seules les chaînes littérales sont prises en charge.

  • L’adresse doit être unique au sein de l’organisation. Par exemple, si l’adresse de messagerie bob@contoso.com existe déjà, le mappage de robert@fourthcoffee.com sur bob@contoso.com a pour effet que les réponses aux messages en provenance de bob@contoso.com ne sont pas remises à leur destinataire.

Retour au début

Considérations relatives à la réécriture d’adresses dans plusieurs domaines

Avant de créer une entrée de réécriture d’adresses qui réécrit plusieurs domaines, vous devez préparer vos sous-domaines. En outre, avant d’exécuter la procédure de création d’une entrée de réécriture d’adresses pour plusieurs sous-domaines décrite dans la rubrique Créer une entrée de réécriture d’adresse, vous devez comprendre les conditions requises pour la réécriture d’adresses de messagerie dans plusieurs domaines vers un domaine unique et la préconfiguration appropriée pour les boîtes aux lettres et contacts concernés.

Considérations importantes

Lorsque vous regroupez des sous-domaines internes en un domaine externe unique, vous devez prendre en compte les aspects suivants (qui s’appliquent uniquement dans le cas où plusieurs sous-domaines sont réécrits) :

  • Des alias uniques sont requis   Tous les alias de messagerie (partie de l’adresse de messagerie à gauche du symbole @) doivent être uniques sur tous les sous-domaines. Par exemple, si l’adresse joe@sales.contoso.com existe, il n’est pas possible d’utiliser l’adresse joe@marketing.contoso.com.

  • Des adresses proxy sont requises   Une adresse proxy correspondant à l’adresse de messagerie produite par l’agent de réécriture d’adresses doit être configurée sur tous les comptes de messagerie appartenant aux sous-domaines réécrits. Par exemple, si l’adresse joe@sales.contoso.com est réécrite en joe@contoso.com, l’adresse de messagerie joe@contoso.com doit être ajoutée en tant qu’adresse proxy à la boîte aux lettres de Joe.

  • Des contacts peuvent être requis   Si vous réécrivez une adresse de messagerie à partir d’un système de messagerie autre qu’Exchange 2010, vous devez créer des contacts à extension messagerie Active Directory pour chaque adresse de messagerie réécrite ne fonctionnant pas avec Exchange 2010. Le contact à extension messagerie doit intégrer l’adresse de messagerie originale et l’adresse électronique réécrite. Par exemple, si l’adresse joe@unix.contoso.com est réécrite en joe@contoso.com, vous devez créer un contact à extension messagerie dans Active Directory avec joe@unix.contoso.com comme adresse SMTP cible et joe@contoso.com comme adresse proxy SMTP.

Il s’agit d’aspects importants car la réécriture d’adresses dans plusieurs sous-domaines entraîne une relation plusieurs-à-un entre les sous-domaines internes et le domaine visible en externe. En raison de cette relation plusieurs-à-un, l’agent de réécriture d’adresses ne peut pas déterminer le sous-domaine contenant le destinataire approprié lorsqu’un message adressé au domaine visible en externe est reçu.

ImportantImportant :
Assurez-vous que tous les alias de messagerie sur tous les sous-domaines sont uniques. Exchange 2010 ne vérifie pas l’unicité de tous les alias de messagerie pouvant être réécrits dans un domaine unique.

Suppression des adresses de messagerie en conflit

Pour créer une entrée de réécriture d’adresses qui réécrit plusieurs sous-domaines, vous devez d’abord vérifier que tous les alias de messagerie sont uniques sur tous les sous-domaines. Imaginons, par exemple, la configuration suivante :

Les utilisateurs suivants appartiennent aux sous-domaines sales.contoso.com, marketing.contoso.com et research.contoso.com :

  • maria@sales.contoso.com

  • chris@sales.contoso.com

  • david@marketing.contoso.com

  • brian@marketing.contoso.com

  • chris@research.contoso.com

  • adam@research.contoso.com

Chaque sous-domaine comprend deux utilisateurs et chaque utilisateur dispose d’une adresse de messagerie unique. Vous souhaitez toutefois réécrire les sous-domaines sales.contoso.com, marketing.contoso.com et research.contoso.com en un domaine unique nommé contoso.com. Le tableau suivant présente les adresses de messagerie originales et les adresses de messagerie réécrites correspondantes.

Adresses de messagerie originales et adresses de messagerie réécrites correspondantes

Adresse de messagerie originale Adresse de messagerie réécrite

maria@sales.contoso.com

maria@contoso.com

chris@sales.contoso.com

chris@contoso.com

david@marketing.contoso.com

david@contoso.com

brian@marketing.contoso.com

brian@contoso.com

chris@research.contoso.com

chris@contoso.com

adam@research.contoso.com

adam@contoso.com

Une fois les adresses de messagerie réécrites dans chaque sous-domaine, un conflit survient entre les adresses chris@sales.contoso.com et chris@research.contoso.com. Par conséquent, les deux adresses de messagerie sont réécrites en chris@contoso.com. Pour résoudre le problème, vous devez modifier l’adresse de messagerie de l’une des boîtes aux lettres du destinataire en une adresse n’entrant pas en conflit avec l’adresse de messagerie dans l’un des autres sous-domaines.

Application des adresses proxy aux boîtes aux lettres des destinataires

Pour que les boîtes aux lettres des destinataires internes puissent recevoir des réponses aux adresses réécrites, vous devez configurer les boîtes aux lettres de ces destinataires en utilisant une adresse proxy correspondant à l’adresse externe réécrite.

Par exemple, si une boîte aux lettres existe pour adam@research.contoso.com et que l’adresse externe réécrite est adam@contoso.com, la boîte aux lettres doit être configurée en utilisant l’adresse proxy définie pour adam@contoso.com.

Retour au début

Définition des priorités des entrées de réécriture d’adresses

La règle correspondant le mieux à la paire domaine interne/domaine externe est appliquée. La définition des priorités suivantes indique l’ordre précis de priorité décroissante des entrées de réécriture d’adresses :

  1. Adresses de messagerie individuelles   Par exemple, mappage de john@contoso.com sur support@contoso.com.

  2. Mappage de domaine ou de sous-domaine spécifique   Par exemple, mappage de Contoso.com sur Northwindtraders.com ou de Sales.contoso.com sur Contoso.com.

  3. Aplatissement de domaine   Par exemple, aplatissement de *.contoso.com en Contoso.com. Par exemple, les deux règles suivantes sont configurées sur le serveur de transport Edge :

    *.contoso.com maps to Contoso.com
    Japan.sales.contoso.com maps to contoso.jp
    

    Si masato@japan.sales.contoso.com envoie un message électronique, l’adresse est réécrite en masato@contoso.jp car cette règle correspond est celle qui correspond le mieux au domaine interne de l’expéditeur, même si la règle *.contoso.com est présente.

Retour au début

Messages signés, chiffrés et protégés numériquement

La réécriture d’adresses ne devrait pas affecter la plupart des messages signés, chiffrés et protégés par des droits. Si la réécriture d’adresses est susceptible d’invalider une signature, de rendre un message chiffré ou protégé par des droits illisible ou de modifier l’état de sécurité de ce message, elle n’est pas appliquée.

Les adresses et les informations dans les sections de message suivantes peuvent être réécrites car les informations de ces sections ne font pas partie de la signature, du chiffrement ou de la protection du message :

  • Champs d’enveloppe SMTP

  • En-têtes de corps de message de niveau supérieur

Les adresses et les informations dans les sections de message suivantes ne sont pas réécrites car les informations de ces sections font partie de la signature, du chiffrement ou de la protection du message :

  • En-têtes situés à l’intérieur de parties du corps MIME qui peuvent être signés

  • Paramètre de chaîne de limite du type de contenu MIME

Retour au début

 © 2010 Microsoft Corporation. Tous droits réservés.