Schéma de réécriture de l’expéditeur (SRS) dans Microsoft 365
Remarque
En août 2023, une modification sera déployée pour les messages SMTP ou transférés aux boîtes aux lettres. À l’avenir, SRS sera utilisé pour réécrire ces messages au lieu de la boîte aux lettres de transfert. Cela consolidera les méthodes de transfert pour que toutes utilisent SRS dans Exchange Online. Bien que SRS soit conçu pour éviter les interruptions des messages transférés, certains cas spéciaux peuvent rencontrer des problèmes. L’un des cas de cette modification est que les messages relayés vers Internet via des serveurs locaux ne seront pas réécrites avec SRS. Pour éviter ce changement de comportement, consultez le nouveau paramètre abordé ici : Modèle de réécriture de l’expéditeur Modifications à venir.
La fonctionnalité de pool de relais a été introduite dans Microsoft 365, qui affecte le comportement de réécriture SRS. Les messages éligibles pour ce pool de relais ne sont pas réécrits par SRS et sont envoyés à partir d’adresses IP qui ne font pas partie de l’enregistrement SPF Microsoft 365. Cela affecte principalement les messages qui échouent aux vérifications SPF lorsqu’ils entrent dans Exchange Online afin que SRS ne corrige pas ces échecs. Pour plus d’informations, consultez la documentation du pool de relais ici : Pools de remise sortants.
La fonctionnalité de schéma de réécriture de l’expéditeur (SRS) a été ajoutée à Microsoft 365 pour résoudre un problème dans lequel le transfert automatique était incompatible avec SPF. La fonctionnalité SRS réécrit l’adresse de départ P1 (également appelée adresse d’enveloppe de départ) pour tous les messages applicables envoyés en externe à partir de Microsoft 365.
Remarque
L’en-tête De , également connu sous le nom d’adresse d’affichage de partir ou adresse de départ P2, qui est affiché par les clients de messagerie reste inchangé.
La fonctionnalité SRS améliore la remise des messages applicables qui passent les vérifications SPF (Sender Policy Framework) lorsqu’ils arrivent de l’expéditeur d’origine, mais échouent aux vérifications SPF à la destination externe finale après leur transfert.
SRS réécrit l’adresse P1 From dans les scénarios suivants :
- Messages dans Microsoft 365 qui sont redirigés automatiquement (ou redirigés) vers un destinataire externe à l’aide de l’une des méthodes suivantes :
- Transfert SMTP
- Redirection de règle de boîte aux lettres (ou règle de boîte de réception)
- Redirection des règles de flux de courrier (transport)
- Groupes ou DLL qui ont des membres externes
- Transfert de contact de messagerie
- Transfert de l’utilisateur de messagerie
- Messages qui sont redirigés automatiquement (ou redirigés) à partir de l’environnement local d’un client et relayés via Exchange Online.
Il est important de noter que la réécriture SRS est utilisée pour empêcher l’usurpation de domaines non vérifiés. Vous devez envoyer des messages uniquement à partir de domaines dont vous êtes propriétaire et pour lesquels vous avez vérifié votre propriété via la liste Domaines acceptés. Pour plus d’informations sur les domaines acceptés dans Microsoft 365, consultez Gérer les domaines acceptés dans Exchange Online.
Remarque
La réécriture SRS ne résout pas le problème de passage de DMARC pour les messages transférés. Bien qu’une vérification SPF réussisse désormais en raison de l’adresse P1 From réécrite, DMARC nécessite également une vérification de l’alignement pour que le message réussisse. Pour les messages transférés, DKIM échoue toujours, car le domaine DKIM signé ne correspond pas au domaine d’en-tête From . Si un expéditeur d’origine définit sa stratégie DMARC pour rejeter les messages transférés, les messages transférés sont rejetés par les agents de transfert de messages (MDA) qui respectent les stratégies DMARC. La norme ARC a été développée pour résoudre les problèmes de transfert de DKIM et a été implémentée dans notre service pour résoudre ces problèmes.
Ce scénario d’échec, ainsi que d’autres échecs de remise, entraîne le retour des rapports de non-remise (NDR) à Exchange Online plutôt qu’à l’expéditeur d’origine lorsque la réécriture SRS n’est pas utilisée. Par conséquent, une partie de l’implémentation de SRS consiste à rediriger les NDR retournés vers l’expéditeur d’origine si un message ne peut pas être remis.
Les sections suivantes présentent différents scénarios de transfert automatique et des informations sur la façon dont SRS les gère.
Envoi automatique d’e-mails pour une boîte aux lettres hébergée sur Microsoft 365
Pour un message envoyé à une boîte aux lettres hébergée et transmis automatiquement à l’aide de mécanismes tels que le transfert SMTP, la redirection de règle de boîte aux lettres ou la redirection de règle de transport, l’adresse P1 From est réécrite avant que le message quitte Exchange Online. L’adresse est réécrite en utilisant le modèle suivant :
<Forwarding Mailbox Username>+SRS=<Hash>=<Timestamp>=<Original Sender Domain>=<Original Sender Username>@<Forwarding Mailbox Domain>
Dans l’exemple suivant, un message est envoyé de Bob (bob@fabrikam.com) à la boîte aux lettres de John dans Exchange Online (john.work@contoso.com). John a configuré le transfert automatique de cette boîte aux lettres vers son adresse e-mail (john.home@example.com). Notez que l’adresse P1 From est réécrite par SRS.
Message d’origine | Message redirigé automatiquement | |
---|---|---|
Destinataire | john.work@contoso.com |
john.home@example.com |
P1 à partir de | bob@fabrikam.com |
john.work+SRS=44ldt=IX=fabrikam.com=bob@contoso.com |
À partir de l’en-tête | bob@fabrikam.com |
bob@fabrikam.com |
Lorsque SRS réécrit l’adresse P1 From , la longueur de la partie nom d’utilisateur de l’adresse e-mail augmente. Toutefois, l’adresse e-mail est limitée à 64 caractères. Par conséquent, si la longueur de l’adresse e-mail réécrite dépasse 64 caractères, elle prend la forme suivante :
bounces+SRS=<Hash>=<Timestamp>@<Default Accepted Domain>
où <Default Accepted Domain>
est le nom du domaine accepté par défaut configuré pour le locataire.
Relais à partir du serveur local d’un client
Lorsqu’un message provenant d’un domaine non vérifié est relayé à partir du serveur local d’un client ou d’une application via Exchange Online, l’adresse P1 From est réécrite avant de quitter Exchange Online. L’adresse est réécrite en utilisant le modèle suivant :
bounces+SRS=<Hash>=<Timestamp>@<Default Accepted Domain>
Dans l’exemple suivant, un message est envoyé de Bob (bob@fabrikam.com) à la boîte aux lettres de John (john.onprem@contoso.com), qui se trouve sur le serveur de son entreprise qui exécute Exchange Server. John a configuré le transfert automatique de cette boîte aux lettres vers son adresse e-mail (john.home@example.com). Notez que l’adresse P1 From est réécrite par SRS dans ce scénario. Les clients sont encouragés à définir le domaine accepté par défaut sur l’un de leurs propres domaines.
Type | Message d’origine | Message relayé reçu par Exchange Online | Message relayé envoyé à partir d’Exchange Online |
---|---|---|---|
Destinataire | john.onprem@contoso.com |
john.home@example.com |
john.home@example.com |
P1 à partir de | bob@fabrikam.com |
bob@fabrikam.com |
bounces+SRS=44ldt=IX@contoso.com |
À partir de l’en-tête | bob@fabrikam.com |
bob@fabrikam.com |
bob@fabrikam.com |
Dans certains cas, les messages relayés qui sont réécrites par SRS peuvent ne pas être remis et une remise peut être générée.
Pour recevoir ces NDR, l’administrateur client doit créer une boîte aux lettres nommée « rebonds » hébergée sur Exchange Online ou localement. Le domaine de cette boîte aux lettres doit être défini sur le domaine accepté par défaut pour le locataire.
Messages transférés envoyés au serveur local d’un client
Par conception, SRS considère que les serveurs locaux se trouvent dans la limite d’approbation et ne réécrit pas les messages transférés qui sont liés à l’environnement local. Toutefois, pour les configurations de routage complexes qui utilisent des serveurs locaux pour acheminer les messages vers Internet, les messages transférés sans réécriture SRS sont sujets à des rejet en raison d’une défaillance de SPF. Pour résoudre ce problème, les administrateurs peuvent activer SRS pour le trafic transitant par un connecteur sortant local. Le paramètre SenderRewritingEnabled peut être utilisé pour ce faire et est configurable à l’aide des applets de commande New-OutboundConnector ou Set-OutboundConnector.
Ce paramètre ne s’applique pas aux connecteurs partenaires qui gèrent les messages aux destinataires externes et il est obligatoire que srs soit appliqué à ces messages si nécessaire. Le paramètre SenderRewritingEnabled affiche la valeur true pour les connecteurs partenaires et une erreur est retournée pour toute tentative de définition de sa valeur.
Messages redirigés par le flux de messagerie (transport)
Étant donné qu’un message peut être redirigé par une règle pour n’importe quelle raison, pas seulement en raison d’un certain destinataire, il n’existe aucun concept de boîte aux lettres de transfert. Dans cette optique, l’adresse srs réécrite prend la forme suivante :
bouncesEtr+SRS=<Hash>=<Timestamp>=<OrigSenderDomain>=<OrigSenderUser>@<Default Accepted Domain>
Pour recevoir des NDR, votre locataire doit être en mesure de recevoir des messages adressés à un utilisateur nommé « bouncesETR » afin que nous puissions rediriger le message vers l’expéditeur d’origine. Par exemple, Directory-Based blocage edge peut interférer avec le retour des NDR si aucune boîte aux lettres de ce type n’existe dans votre locataire.
Pool de relais et ignorer SRS
La fonctionnalité de pool de relais a été introduite dans Microsoft 365, qui affecte le comportement de réécriture SRS. Les messages éligibles pour ce pool de relais ne sont pas réécrits par SRS et sont envoyés à partir d’adresses IP qui ne font pas partie de l’enregistrement SPF Microsoft 365. Cela affecte principalement les messages qui échouent aux vérifications SPF lorsqu’ils sont envoyés pour la première fois à Exchange Online, car SRS ne doit pas corriger ces échecs avec sa réécriture. Pour plus d’informations, consultez la documentation du pool de relais ici : Pools de remise sortants