Cet article décrit la configuration d’un compte email Office 365 avec ses identifiants SMTP comme smarthost d’émission Exim 4 sur un serveur Debian 10. Vous pourrez donc émettre des emails depuis un compte Office 365. Si votre adresse IP a été bannie par les serveurs de Microsoft, ce qui vous empêche d’émettre le courrier directement depuis votre IP, utiliser un compte Office 365 vous permettra de contourner le bannissement IP. De même, depuis une box internet grand public, il est interdit par la plupart des sentinelles anti-spam d’émettre des emails en direct. Si vous souhaitez plutôt utiliser un compte email OVH comme tel, l’explication est dans cet article.

Les mainteneurs de distributions comme Debian font un travail fantastique pour proposer une logique de configuration (cf. article Travailler avec Exim4 sur Debian), mais il faut avouer que la configuration d’Exim pour ce genre d’opérations est toujours délicate.

Sommaire

Les identifiants de connexion

Pour commencer, le compte email Office 365 pressenti dans cet exemple est supposé fonctionner avec les réglages suivants :

  • Serveur : smtp.office365.com
  • Port : 587
  • Sécurité : SSL/TLS
  • Identifiant : adresse@domaine.fr
  • Mot de passe : password

En réalité il semblerait que Mictosoft utilise STARTTLS sur le port 587 et non pas SSL/TLS.

Tester le protocole de chiffrement de la connexion

Un outil très sympathique pour débugger les problèmes de connexion avec un serveur SMTP sécurisé SSL ou TLS est smtptest dans le paquet Debian cyrus-clients . Je l’ai découvert dans cette mailing-list.

La tentative suivante (SSL) échoue :

La tentative suivante (TLS) fonctionne :

La configuration Exim

Pour commencer, il faut configurer le fichier update-exim4.conf.conf comme ceci, soit par une édition en mode texte, soit par la commande dpkg-reconfigure exim4-config  :

Je ne connais pas la signification du double deux-points dans smtp.office365.com::587. Avec un seul, cela semble fonctionner également. En outre l’adresse localhost en IPv6 a été retirée comme une tentative non fructueuse d’empêcher toute connexion IPv6 aux autres serveurs email.

Au tour du fichier exim4.conf.template, parce qu’ici la configuration se fait dans un fichier unique (ligne  dc_use_split_config='false'  du précédent fichier). La ligne 1705 protocol = smtps  a été commentée car elle se réfère au chiffrement SSL et qu’elle empêche l’établissement normal des connexions STARTTLS avec les serveurs de Microsoft.

J’ai tenté de configurer le fichier exim4.conf.localmacros avec les macros  REMOTE_SMTP_SMARTHOST_HOSTS_REQUIRE_TLS  (valeur *) et  TLS_ON_CONNECT_PORTS  (valeur 587) mais cela s’est avéré non-nécessaire.

Pour terminer, les identifiants de connexion ont été configurés comme ceci dans passwd.client :

A noter qu’avec le signe étoile, ces identifiants seront utilisés pour tous les serveurs smarthost. Cela est nécessaire pour matcher avec tous les reverse DNS (rDNS) utilisés par Microsoft sur les domaines office365.com, office.com, etc. Ici, aucun problème car nous avons configuré un seul et unique compte smarthost.

A l’utilisation

Limitation dans l’adresse d’expédition

Il semblerait que les comptes Office 365 disposent d’une sécurité qui empêche d’émettre un email sous une adresse différente de l’adresse officielle et utilisée comme identifiant. C’est une sécurité bienvenue dans un monde où le SPAM sévit, mais qui peut limiter l’utilisation du compte en tant que smarthost.

Exemple de log si on cherche à utiliser le compte adresse@domaine.fr pour émettre en tant que autre-adresse@autre-domaine.fr. Chercher SMTP error from remote mail server after end of data: 554 5.2.0 STOREDRV.Submission.Exception:SendAsDeniedException.MapiExceptionSendAsDenied; Failed to process message due to a permanent exception with message Cannot submit message.

Pour reproduire ce comportement il vous suffit de tenter d’émettre depuis une adresse différente de celle du compte O365. Par exemple en exécutant ce script Bash :

En argument derrière -v, on trouve l’adresse à laquelle le message sera envoyé. Derrière le champ to: on trouve l’adresse de destination qui sera affichée dans le logiciel de messagerie. Dans la plupart des cas ces deux adresses seront identiques.

La solution semble être de configurer l’ensemble des applications ou sites internet pour émettre en tant que l’adresse officielle du compte, dans cet exemple adresse@domaine.fr.

Une réécriture d’adresse email pour contourner cette limitation

Etant donné qu’il n’est pas toujours simple de modifier les applications émettrices d’email pour configurer un champ d’émetteur From: personnalisé, je vous propose de configurer Exim 4 pour mettre en place une réécriture d’adresse email à la volée.

Toujours dans le fichier de configuration, ici exim4.conf.template , ligne 1801 :

La réécriture consiste à remplacer toutes les adresses d’expédition (ici *) en adresse@domaine.fr. La troisième colonne « Ffrs » concerne les flags de configuration Exim pour traiter les champs suivants :

  • F : champ enveloppe From:
  • f : champ From:
  • r : champ Reply-To:
  • s: champ Sender:

Les différents flags possibles dans la configuration sont décrits ici.

Après un redémarrage du service Exim, la configuration d’un compte SMTP Office 365 devrait fonctionner correctement.