Et non, ce n'est pas une déclaration ! J'ai longtemps été in love avec Microsoft, mais comme on le sait, les histoires d'amour finissent souvent mal ! Blague à part, en imposant d'abord Exchange dans les entreprises, Microsoft telle une pieuvre avait bien préparé le terrain afin que celles-ci migrent vers Exchange Online, une des briques de la méga suite 365. Le résultat est qu'aujourd'hui la domination est quasi totale, domination que les autres acteurs ont bien du mal à concurrencer. Bien ou pas, ce n'est pas l'objet de cet article, par contre cette domination devrait imposer un devoir d'exemplarité, et force est de constater que ce n'est pas toujours le cas, loin s'en faut !

En devenant l'acteur majeur de la messagerie d'entreprise, Microsoft est également devenu un acteur majeur du spam. Face à cette déferlante certains acteurs moins conséquents n'ont d'autre choix que d'imposer régulièrement le blocage des adresses IP de Microsoft, une pratique certes discutable, mais également adoptée par Microsoft lui même pour son service grand public Hotmail (comme on peut le lire 1 | 2 | 3 )

Dans la pratique on se retrouve avec une messagerie professionnelle incapable d'envoyer des messages vers certaines destinations, @free.fr et @orange.fr par exemple, mais pas que. La situation peut se débloquer toute seule et alors les messages prennent du retard, ou sont simplement renvoyés à l'expéditeur via un NDR.

L'un de nos collègue, Marc, a eu l'opportunité d’échanger avec le responsable de la messagerie chez Free et il lui a posé la question :

Pensez vous qu’il puisse être envisageable d’exploiter d’autres mécanismes permettant un filtrage avec une granularité plus fine (genre trio DKIM, SPF, DMARC) ?

• • Non, pas à ce jour et probablement pas dans un futur proche.
  • Le premier problème est que la situation dans laquelle vous êtes ne concerne qu'Office365 et aucun autre hébergeur de messagerie. Il y a bien des problèmes avec Gmail mais les solutions techniques mises en place chez eux n'ont rien à voir avec celles d'Office365 et les dommages collatéraux en sont drastiquement réduits.
  • Le second problème est que si nous devions basculer sur une réputation par domaine en nous basant sur les signatures DKIM, il nous faudrait également prendre en compte les sceaux ARC (signature de l'intermédiaire technique) et qu'ici, il y a un sceau ARC sur microsoft.com sur les mails sortant d'Office365 et qu'il y a un risque conséquent pour que ce soit toute la plateforme Office365 qui se retrouve bloquée.
  • Le troisième problème est que nous avons pu constater ces dernières années des campagnes de spams expédiées au travers de comptes compromis. Sur certaines journées en décembre dernier, c'est plus de 1500 domaines qui participaient ainsi aux envois rien que pour Office365. Il est délicat de mettre en place une whiteliste concernant un domaine ou un compte car cela revient à retirer toutes nos protections alors que nous gérons pas ce domaine ou ce compte.

Dans ces conditions et puisque Microsoft ne réagit pas plus, il faut trouver un contournement qui va nous permettre de rerouter les messages destinés aux domaines qui pratiquent de tels blocages. D’aucuns diront que continuer à utiliser en 2022 un compte de messagerie chez un FAI n’est pas une bonne idée, mais peu importe, dans le cadre d’une relation commerciale on ne commence pas par expliquer la vie au client, mais à entretenir la relation avec lui et ainsi lui apporter des solution viable. On est tous d'accord, on ne devrait pas avoir à apporter une telle solution !

Contournement

Sur Microsoft 365, Exchange Online plus précisément, nous allons utiliser une règle et un connecteur pour dérouter les messages destinés au domaine free.fr  et orange.fr vers un serveur SMTP externe qui va servir de relais. S’il existe bien des services de relai SMTP sur Internet, ces services nécessitent soit une authentification, soit une restriction sur une adresse IP. Problème, il n’est pas possible de s’authentifier sur un connecteur sortant, et Microsoft utilise une multitude d’adresses IP sur ses serveurs SMTP.

*.protection.outlook.com : 40.92.0.0/15, 40.107.0.0/16, 52.100.0.0/14, 52.238.78.88/32, 104.47.0.0/17

Il va donc nous falloir monter un serveur SMTP externe sur lequel on va autoriser le relai depuis ces blocks d’adresses IP. Il existe toutefois un petit risque que d’autres administrateurs trouvent la faille et se servent de notre serveur. Ce risque est faible, et au pire on changera notre adresse IP.

Le relai

Ou relais, une fois de plus les anglais font plus simple avec relay, smtp-relay. Bref, pour monter un tel serveur il existe certainement plusieurs produits possibles, pour peu que ces logiciels soient capable de gérer de multiples plages d’adresses IP sources à relayer. J’ai utilisé HMailServer sous Windows car je le connais bien, mais on doit pouvoir faire ça sous Linux à moindre frais. Quant à la restriction au niveau des IP sources, ça peut aussi se faire au niveau du firewall.

Dans HMailServer (IP Ranges) on va déclarer nos adresses IP autorisés sans authentification, celle des serveur Microsoft 365 :

On répète ça pour chaque plage d’IP et ensuite de la même façon on va déclarer nos relais autorisés, les mêmes IP :

C'est un peu fastidieux et ce serait plus simple de déclarer 107.47.0.0/17, mais ici c’est ainsi.

Ensuite on s’assurera que notre serveur est correctement installé (il n’accepte rien d’autre) et est correctement déclaré et configuré (SPF, reverse IP, etc...) pour les domaines pour lesquels il devra assurer le transit. On fait un Telnet sur mx1.free.fr afin de s’assurer que l’on peut bien les joindre et  que notre IP publique n'est pas elle aussi blacklistée.

A ce stade on se connecte à l’administration Exchange de Microsoft 365 dans laquelle on va faire en sorte que tous les mails à destination de Free et Orange devront transiter via l’IP de notre serveur relai.

Exchange Online

Pour ce faire on va commencer par créer un connecteur qui s'appliquera aux messages sortant d'Exchange Online vers ce qui s'appelle ici Organisation Partenaire :

Le choix suivant est important :

1. Soit on décide que ce connecteur s'applique à tous les messages à destination de Free et Orange, auquel cas on configure simplement ces domaines. C'est la solution la plus simple pour un tenant qui ne gère qu'un seul domaine.
2. Soit on décide que ce connecteur ne s'applique qu'au messages qui ont été redirigés par une règle. On utilisera cette option dans le cas ou on souhaite rediriger uniquement certains mails, expéditeurs ou domaines sources, qui seront le fruit d'une règle à créer.

Ensuite se pose la question de la validation du connecteur ou l'on utilisera une adresse @free.fr par exemple. Dans la pratique validé ou pas le connecteur fonctionne tout de même....

Si l'on a fait le choix 2 il va nous falloir créer une règle pour que cela fonctionne. Dans cette règle on va demander à ce que :

• le destinataire soit sur le domaine free.fr
• le domaine de l'expéditeur
• Et enfin que ce trafic transite via le connecteur précédemment créé.

Cela va nous permettre de ne dérouter vers notre MTA premise uniquement les domaines sources qui y seront configurés. Ce cas est spécifique à des tenant "partagés" ou plusieurs domaines coexistent, mais cela peut également permettre d'utiliser plusieurs serveurs relais en fonction des domaines sources.

Il est bien sur possible de faire ceci en PowerShell, vous trouverez les détails dans cet excellent article.