Cet article est dans la suite des articles consacrés à postfix, je vais détailler la gestion des mails pour une infrastructure conséquente, sans toutefois rentrer dans la HA. Il y a 2 types de flux à traiter : ceux en interne de nos serveurs vers notre relais SMTP postfix et le flux mail qu’il faut sécuriser vers M365.

L’utilisation d’un relais tel que Microsoft 365 facilite la sécurisation de nos échanges mails, car une intégration de DKIM et DMARC est déjà gérée nativement! Si vous avez déjà vos mails ou l’ensemble de votre active directory, c’est dans cette direction qu’il faut se diriger pour une mise en place efficace.

Je suppose qu’il est possible de faire cela également avec Infomaniak pour ceux disposant de comptes pro chez eux. Avec mon compte perso je n’ai pas vu cette option. Avec OVH, oubliez directement! Du temps où j’étais encore client chez eux, j’avais parlé DKIM DMARC au support, et on m’a posés des questions pour savoir pourquoi je veux ces fonctions etc. Vraiment comme si j’étais un extraterrestre! On était tout de même en 2020… Rien n’était fait pour le mail mutualisé donc… Longtemps client perso et pro je suis passé chez Infomaniak pour la partie mutualisée en partie pour cela. J’arrête le OFF là 🙂

Configuration dans l’Exchange 365

Il faut créer un connector dans mail flow > connectors > Add a connector :

connectors exchange

L’authentification est faite par adresse IP ou certificat valide. Il faut savoir que votre serveur relais interne postfix va lui-même se connecter sur VOTRE_DNS.mail.protection.outlook.com et celui-ci présente un certificat valide. Votre « client » va donc authentifier le serveur de Microsoft comme valide (notre serveur relais est client par rapport au relais M365).

L’authentification par IP est déjà suffisante en soit. Mais vous pouvez décider que les serveurs relais de Microsoft n’acceptent QUE les mails si le serveur client (votre relais SMTP) présente le bon certificat client. Ce qui fait qu’il y a une identification et authentification de part et d’autre!

  • Configurer une restriction par votre IP publique de sortie :
  • Configurer une restriction par un certificat valide : dans ce cas cela ne doit pas forcément être le certificat *.votredomain.tld, cela peut très bien être monrelais.mondomainetechnique.tld. La seule règle étant que ce certificat soit émis par une autorité de certification reconnue.

Mettre un certbot avec let’s encrypt sur votre serveur est envisageable si vous utilisez une vérification let’s encrypt par dns.

Si vous souhaitez plus d’infos, la documentation Microsoft est bien faite.

Remarque : Les limites d’envoie pour M365 sont larges et dépendent de votre licence.

Un mot sur le serveur Postfix

Il faut tout de suite savoir que Postfix est à la fois un serveur et un client. Il faut donc bien distinguer les directives. Veillez donc bien au début qui peut être :

  • smtp_tls_xxx en tant que client
  • smtpd_tls_xxx en tant que serveur

Notre serveur relais est serveur par rapport à nos serveurs internes. Il est client par rapport à Microsoft 365.

Configuration de notre relais mail Postfix

J’ai distingué les directives serveurs et clients pour que la configuration soit lisible.

Pour le comportement serveur du relais SMTP :

  • smtpd_tls_security_level=may permet de spécifier que notre serveur accepte une liaison client en TLS mais également en clair. Il faut penser aux copieurs ou autre matériel ne gérant pas le TLS interne à notre réseau
  • smtpd_tls_loglevel permet d’avoir une trace des connexions TLS dans les logs avec les ciphers pris en compte, pratique pour voir quel client envoie encore en clair et s’il peut être modifié
  • smtpd_tls_cert_file et smtpd_tls_key_file renseignent le certificat et la clé utilisé en interne
  • smtpd_tls_chain_files est le nouveau format pour pouvoir contenir plusieurs clés et certificats pour différents noms de domaine. Il faut toujours la clé et puis la chaîne de certificat et le certificat final
  • smtpd_tls_session_cache_database permet d’avoir un peu de performance quand beaucoup de mails sont envoyés
### SERVER ###
smtpd_tls_security_level=may
smtpd_tls_loglevel = 1

smtpd_tls_cert_file=/etc/xxx.crt
smtpd_tls_key_file=/etc/xxx.key
#alternative
#smtpd_tls_chain_files=/etc/your-key-and-local-crt-and-chain-with-your-local-ca-combined.all

#optionel
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache



### CLIENT ###
relayhost = your-domain.mail.protection.outlook.com
smtp_tls_security_level = encrypt # optionnel : secure
smtp_tls_mandatory_ciphers = high
smtp_tls_loglevel = 1
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
#optionnel
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtp_tls_chain_files = /etc/xxx.all

Pour le comportement client du relais SMTP :

  • relayhost on vient mettre le DNS de notre tenant M365
  • smtp_tls_security_level le niveau de securité minimal accepté en TLS. Je vous conseille secure
  • smtp_tls_mandatory_ciphers high contient un « bundle » de ciphers satisfaisant
  • smtp_tls_loglevel permet d’avoir une trace des connexions TLS
  • smtp_tls_CAfile permet de spécifié le fichier des CA faisant autorité. Un fichier du système contient déjà les CA connus du monde
  • smtp_tls_session_cache_database permet d’avoir un peu de performance quand beaucoup de mails sont envoyés
  • smtp_tls_chain_files spécifiez la chaine de certificats client qui est utiliser si vous aviez choisi une restriction par un certificat client pour votre connector M365. L’ordre dans la chaine est importante : votre clé privée, suivie de votre certificat, ensuite le certificat intermédiaire et pour finir le certificat du CA

Par défaut en niveau de sécurité encrypt ou verify ou secure vont authoriser le trust du nom de domaine lui-même et de son dns parent. Respectivement nexthop et dot-nexthop. M365 n’émettant un certificat que pour mail.protection.outlook.com et pas your-domain.mail.protection.outlook.com.
Ce comportement peut être changer via le paramètre smtp_tls_secure_cert_match.

S’il y a un problème d’accès au relais M365 dans les logs postfix comme ci-dessous, vérifier que l’IP de sortie ou le certificat sont ok : 

host xxx.mail.protection.outlook.com[104.47.2.7] said: 550 5.4.1 Recipient address rejected: Access denied. AS(201776281) [AB4EUR01RT057.eop-EUR01.prod.protection.outlook.com] (in reply to RCPT TO command)

En cas de succès avec un certificat client vous aurez : 

postfix/smtp[71318]: your-domain.mail.protection.outlook.com[104.47.0.36]:25: matched peername: *.mail.protection.outlook.com
postfix/smtp[71318]: your-domain.mail.protection.outlook.com[104.47.0.36]:25: subject_CN=mail.protection.outlook.com, issuer_CN=DigiCert Cloud Services CA-1, fingerprint=6A:DD:32:6D:2A:0C:C5:3A:9E:D7:E7:91:3D:6F:5C:F4, pkey_fingerprint=20:78:41:CD:EC:4F:19:7A:E0:B2:01:4F:3C:3D:1C:EE
postfix/smtp[71318]: Verified TLS connection established to your-domain.mail.protection.outlook.com[104.47.0.36]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

Fichier main.cf d’un relais SMTP Postfix complet :

myorigin = /etc/hostname
mydomain = your-local-domain
mydestination = $myhostname, $myorigin, localhost.localdomain, localhost, localhost.your-local-domain

# Backward compatibility off
compatibility_level = 3.6
relay_domains = $mydestination
append_dot_mydomain = yes
smtputf8_enable=yes
smtpd_banner = $myhostname ESMTP
biff = no
readme_directory = no

# TLS parameters server
smtpd_tls_chain_files=/etc/your-key-and-local-crt-and-chain-with-your-local-ca-combined.all
#alternative
#smtpd_tls_cert_file=/etc/xxx.cer
#smtpd_tls_key_file=/etc/xxx.key
smtpd_tls_security_level=may
smtpd_tls_loglevel = 1
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache

# TLS parameters client
relayhost = xxx.mail.protection.outlook.com
smtp_tls_security_level = secure
smtp_tls_mandatory_ciphers = high
smtp_tls_loglevel = 1
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt

# Client certificat to be identified by M365
#smtp_tls_chain_files = /etc/xxx.all

smtpd_client_restrictions = permit_mynetworks reject
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination

alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases

mynetworks = 10.0.0.0/22,xxx
mailbox_size_limit = 0
message_size_limit = 29480000
recipient_delimiter = +
inet_interfaces = all
inet_protocols = ipv4

header_checks = regexp:/etc/postfix/header_checks_regexp
smtp_header_checks = regexp:/etc/postfix/replace_header_checks_regexp

sender_canonical_maps = regexp:/etc/postfix/sender_canonical_regexp

Configuration d’un serveur client interne linux

Voici la partie TLS d’un fichier main.cf d’un postfix « satellite » qui se connecte à notre relais interne. Il dois évidement avoir le certificat serveur de notre relais ou notre CA interne de configuré dans les certificats du système ou via la directive smtp_tls_CAfile.

smtp_tls_security_level = may
smtp_tls_loglevel = 1
#optionnel
smtp_tls_security_level = secure
smtp_tls_mandatory_ciphers = high
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

Articles relatifs :

Summary
Relais mail Postfix - envoyer ses mails sécurisés vers M365
Article Name
Relais mail Postfix - envoyer ses mails sécurisés vers M365
Description
Configuration TLS de Postfix comme relais mail sécurisé vers Microsoft 365, y compris la sécurisation du réseau interne des échanges avec nos serveurs linux
Author