Rechercher un article

Installer un proxy SMTP transparent

Il y a quelques temps. j'expliquais que des applications métiers qui envoient du mail n'arrivaient plus à ouvrir de connexion vers les serveurs SMTP de Microsoft : Microsoft 365 - Problème de connexion aux serveurs SMTP.
La solution de contournement avait été de placer en liste verte la plage IP des serveurs qui hébergent ces applications.

Deux mois et demi sont passés et ça ne fonctionne plus. Évidemment, toujours pas d'explication du pourquoi du comment. Je travaille avec Microsoft depuis 5 ans et je ne m'y suis toujours pas habitué 🤬

Après quelques heures de tests et de bidouilles, j'ai décidé d'installer un proxy qui fera l'intermédiaire entre les applications bloquées et Microsoft. Pour ne pas avoir à gérer d'avantages d'accès, ce proxy sera totalement transparent.

Il n'existe (à priori) pas beaucoup de logiciels qui font ça et s'ils le font, ils ne sont plus maintenus. On retrouve beaucoup d'articles sur Nginx et Haproxy mais ils ne conviennent pas. Nginx n'est pas un proxy SMTP transparent et mes tests avec Haproxy ont échoués.
J'ai réussi à dénicher tuck1s/go-smtpproxy. Bien qu'il n'est pas reçu de mise à jour depuis 2 ans, il ne fait qu'utiliser une librairie qui elle a un développement actif : emersion/go-smtp.

Contexte / Prérequis :

  • Le serveur tourne avec Debian 11
  • Nom de domaine du proxy : relais-smtp.exemple.com
  • Il y a un certificat SSL généré par Let's Encrypt
  • Le serveur va écouter sur le port 587 avec la couche STARTTLS

Pour compiler le projet, il suffit d'installer Go, récupérer les sources et lancer le build. À l'issue du build, le binaire proxy sera généré dans le répertoire go/src/github.com/tuck1s/go-smtpproxy.

apt update
apt install golang
go get github.com/emersion/go-smtp-proxy
go get gopkg.in/natefinch/lumberjack.v2
go get github.com/tuck1s/go-smtpproxy
cd go/src/github.com/tuck1s/go-smtpproxy
./build.sh

Il ne reste plus qu'à lancer le proxy :

./proxy
  -certfile /etc/letsencrypt/live/relais-smtp.exemple.com/fullchain.pem \
  -privkeyfile /etc/letsencrypt/live/relais-smtp.exemple.com/privkey.pem \
  -in_hostport 0.0.0.0:587 \
  -insecure_skip_verify \
  -out_hostport smtp.office365.com:587 \
  -verbose

Coté application, le serveur SMTP change de smtp.office365.com à relais-smtp.exemple.com. Si on envoie un mail, le proxy va afficher du log et on pourra s'assurer que ça fonctionne. Il faut également améliorer tout ça avec un compte utilisateur dédié au proxy, gérer son démarrage avec un service Systemd/SysvInit/OpenRC/Whatever, etc.

On verra combien de temps ça dure 🧐


Microsoft 365 - Problème de connexion aux serveurs SMTP

Quand Microsoft change de nom (Office 365 → Microsoft 365), les devops doivent aussi en profiter pour la changer configuration de leurs serveurs de mail…et rien de plus normal que de bloquer les connexions des applicatifs qui ne sont pas estampiller Microsoft.

Depuis plusieurs semaines, j'ai en effet détecté de grandes difficultés à émettre des mails depuis des applicatifs non Microsoft. Les connexions vers les serveurs SMTP d'Office 365 (smtp.office365.com) échouaient très souvent jusqu'à être complétement bloquées sur une 40ène de bureaux à distance où se trouve une application métier.

Pour contourner ce problème (intolérable selon moi), une des solutions est de placer en liste verte les IP depuis lesquelles on se connecte. C'est stupide mais rien de surprenant venant de Microsoft.

Pour réaliser cette opération, je me suis dirigé vers le Centre d'administration Exchange accessible depuis le portail d'administration.

Centre d'administration Exchange

J'ai complété cette configuration par l'édition de la Stratégie de filtre de connexion qu'on retrouve dans les Paramètres anti-courrier indésirable.

Stratégie de filtre de connexion

Après un moment, les envois de mail on pu reprendre et je n'ai pas encore eu de retour qui indiqueraient de nouvelles difficultés de connexion.