Planification de la réécriture d'adresses

 

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

Dernière rubrique modifiée : 2007-11-08

Dans Microsoft Exchange Server 2007, la réécriture d'adresses permet de modifier les adresses d'expéditeurs et de destinataires sur les messages entrants et sortants de votre organisation Exchange 2007.

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 2007. 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 2007 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é.

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 (Simple Mail Transfer Protocol) 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 dans 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 à exploiter 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.

    CautionAttention :
    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.

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 1 montre les champs d'en-tête SMTP réécrits sur les messages sortants et entrants.

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

Champ d'en-tête SMTP Sortant Entrant

Enveloppe De (MAIL FROM)

Réécrit

Non réécrit

Enveloppe À (RCPT TO)

Non réécrit

Réécrit

Corps To

Réécrit

Non réécrit

Corps Cc

Réécrit

Non réécrit

Corps From

Réécrit

Non réécrit

Corps Sender

Réécrit

Non réécrit

Corps Reply-To

Réécrit

Non réécrit

Corps Return-Receipt-To

Réécrit

Non réécrit

Corps Disposition-Notification-To

Réécrit

Non réécrit

Corps Resent-From

Réécrit

Non réécrit

Corps Resent-Sender

Réécrit

Non réécrit

Adresse que les agents de réécriture d'adresses ne réécrivent pas

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 ne sont pas modifiés par les agents de réécriture d'adresses :

  • Return-Path

  • Reçu

  • Identificateur du message

  • X-MS-TNEF-Correlator

  • Content-Type Boundary=string

  • En-têtes situés à l'intérieur de parties de corps MIME

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.

importantImportant :
Les demandes de réunion envoyées aux domaines distants ne prenant pas en charge TNEF sont envoyées en tant que pièces jointes iCalendar. Les agents de réécriture d’adresses ne modifiant pas les champs d’en-tête des messages incorporés, les adresses associées à ces demandes de réunion ne sont pas modifiées.

Considérations en relation avec l'utilisation de la réécriture d'adresses Outbound-Only

Quand un message électronique sort de l'organisation Exchange 2007, la réécriture d'adresses outbound-only 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 outbound-only :

  • Les adresses qui en résultent doivent être uniques au sein de l'organisation. Par exemple, si les adresses de messagerie uniques ted@sales.contoso.com et ted@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 ted@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 Outbound-only 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.

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.

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.

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. Si la réécriture d'adresses est susceptible d'invalider une signature, de rendre un message chiffré ou protégé illisible ou de modifier l'état de sécurité de tels messages, 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

Pour plus d'informations

Pour plus d'informations sur la réécriture d'adresses, consultez les rubriques suivantes :