OpenSMTPD : le serveur mail du futur

Description

Retrouvez ci-dessous la traduction EN → FR de l’article “OpenSMTPD Is The Mail Server For The Future”, écrit par Peter N.M. Hansteen.

© 2026 Peter N. M. Hansteen

Le serveur mail SMTP du 21ème siècle et bien après est OpenSMTPD, qui est développé en tant que partie intégrale d’OpenBSD, mais aussi disponible en version portable.

C’est une des choses que j’avais vraiment l’intention de faire, il y a des années, mais que je n’ai finalement mise en œuvre qu’une fois la date butoir précise fixée.

Le temps est venu, et puisqu’OpenBSD 7.9 laissera derrière lui le paquet exim, et les utilisateurs devront trouver un remplaçant avant la mise à niveau. Cet article décrit ma transition vers le serveur mail OpenSMTPD sous OpenBSD.

OpenBSD 7.9 laissera derrière lui le paquet exim, et les utilisateurs d’exim devront trouver un remplaçant avant la mise à niveau.

OpenSMTPD (smptd) est de base dans le système.

Quand OpenSMTPD a été introduit dans la base du système d’OpenBSD depuis OpenBSD 4.6 en Octobre 2009, je gérais déjà depuis des années un service mail.

À l’époque, je trouvais pratique de continuer à utiliser exim en tant que serveur de messagerie, protégé par la version spamd d’OpenBSD, au niveau du chemin d’entrée des messages et en combinaison avec spamassassin et clamav pour filtrer le contenu.

À l’époque, j’étais très tenté à tester ce nouveau serveur smptd, mais la version initiale de celui-ci n’était pas encore tout à fait prête pour être mise en service.

Note : Cet article est aussi disponible avec des traqueurs, mais joliment formaté ici.

Le rythme de développement a été assez frénétique au cours des premières années, et lorsque smtpd a remplacé le classique sendmail en tant que serveur mail par défaut dans OpenBSD avec la sortie en Novembre 2014 d’OpenBSD 5.6, je venais tout juste de terminer la troisième édition du livre “The Book of PF ; le sujet m’intéressait, mais la rédaction avait drainé mon énergie.

Bien sûr, je considérais que les configurations du serveur de messagerie, que j’utilisais pour mes besoins et mes amis, étaient suffisamment complexes pour que le passage vers une autre solution nécessite pas mal de préparations et de tests. J’ai donc décidé de remettre à plus tard l’étude sérieuse de ce nouveau logiciel de serveur de messagerie à un autre jour, qui fatalement arriverait, ce dont j’étais certain.

Une vieille installation, maintenue avec beaucoup d’amour et de soins

Il y a quelques indices sur ce que cette configuration faisait (et fait toujours) dans l’article de 2012 intitulé In The Name Of Sane Email: Setting Up OpenBSD’s spamd(8) With Secondary MXes In Play - A Full Recipe (aussi avec traqueurs et mis en forme) ; voici les principales fonctionnalités :

• Deux (originellement trois) sites séparés, chacun avec leur propre nom de domaine, où le(s) autre(s) site(s) assure(nt) une fonction de serveur MX secondaire pour les autres, chaque machine fonctionnant sous OpenBSD équipée de spamd ; ce qui constituait la partie de la configuration du service de messagerie exposée à Internet.
• Les machines sous OpenBSD assumaient le filte de liste et de piège “gris” de spamd, mais fournissaient aussi le filtrage de contenu pour le compte d’un autre ensemble de domaines disposant de leur propre serveurs de messageries, pas nécessairement exposés à Internet, qui recevaient les courriels filtrés transmis par les services de messagerie connectés à Internet.

Cette configuration, avec le filtrage greylisting et greytrapping d’OpenBSD spamd en première ligne et celui de contenu en suivant avant d’être relayé finalement vers les serveurs de mails protégés, fonctionnait si bien que nous avons simplement gardé les systèmes fonctionnels en effectuant au besoin les mises à jours système routinières, des paquets et les ajustements mineurs de configurations nécessaires.

En résumé, les domaines à gérer se sont succédés, mais la combinaison de spamd, exim, clamav+spamassassin est restée, sur la plateforme fiable d’OpenBSD.

Le temps de passer à autre chose, d’attendre et finalement…

Au fil des ans, de nombreuses épisodes de failles de sécurités moyennes à sévères ont été découvertes dans le code source d’exim, mais le paquet OpenBSD été généralement bien maintenu et les correctifs à apparaître dans un délai raisonnable.

De temps en temps, les développeurs d’OpenBSD discuter avec les gestionnaires de ports de la suppression du support d’exim et du système de paquets, ce qui s’est finalement produit durant l’année 2026.

OpenBSD 7.9 sera livrée sans un paquet exim officiel.

Il est ainsi venu le temps de passer à autre chose.

Et bien sûr, un faux départ

D’autres utilisateurs d’OpenBSD n’arrêtaient pas de me dire à quel point OpenSMTPD était devenu bon, alors j’ai maintenant décidé que c’était le temps de m’y mettre ; j’ai donc ressorti quelques vieilles notes et commencé l’expérimentation.

Ces vieilles notes se sont avérées totalement inutiles, et cela pour une raison : la version d’OpenSMTPD 6.4 était le résultat d’une refonte majeure du code, qui a modifié d’importants éléments de syntaxe du fichier smtpd.conf.

Malheureusement, la plupart des guides qui apparaissent en tête de résultat de recherche utilisent encore l’ancienne syntaxe et sont donc inutiles, du moins pour les utilisateurs d’OpenBSD, ou d’autres plateformes, qui ont maintenu à jour raisonnablement leur code. Une bonne règle à suivre est la suivante : si vous trouvez un guide d’OpenSMTPD datant d’avant 2020, faites vous une faveur et passez à un document plus récent.

Si vous trouvez un guide d’OpenSMTPD datant d’avant 2020, faites vous une faveur et passez à un document plus récent.

La tâche à gérer : l’Analyse

Revenons-en au problème : la configuration que je m’apprêtais à convertir devait pouvoir s’adapter à gérer :

• les courriels entrants des utilisateurs des domaines locaux, là où nous sommes le principal serveur de messagerie
• les courriels entrants des utilisateurs des domaines pour lesquels nous sommes serveur de messagerie secondaire
• les courriels entrants des utilisateurs des domaines là où nous sommes le principal serveur de messagerie avec l’extérieur, mais où actuellement nous ne faisons que relayer après le filtrage greylisting et de contenu.
• les courriels sortants venant des domaines locaux
• les courriels sortants venant des réseaux auxquels nous avons choisi de leur faire suffisament confiance pour les relayer

Les enregistrements du serveur de messagerie (MX) pour tous les domaines concernés étaient déjà en place, ainsi que d’autres informations DNS pertinentes, tels les enregistrements SPF, DKIM et DMARC. Les certificats TLS et le système permettant de les gérer étaient déjà en place, utilisant les outils LetsEncrypt.

Cette analyse convertit dans la logique de smtpd.conf devrait être :

• nous gardons le fichier existant /etc/mail/aliases, les formats étant compatibles
• OpenSMTPD gère des tables de manière très pratique, qui peuvent soit être une liste simple, soit une paire de clés-valeurs. Nos tables sont :
  • domains_local liste les domaines dont nous recevons les courriels à gérer localement.
  • relay-for_domains liste les domaines que nous filtrons seulement puis relayons
  • domain_relays est la liste des domaines et leurs serveurs de messageries de destination finale sous une forme de liste de paires de clés-valeurs.
  • relay_from_ips est la liste des adresses IP et des réseaux que nous nous autorisons à relayer

Voici l’actuelle implémentation

Ainsi je me suis mis au travail en partant de ce cahier des charges, et en fin d’après-midi, j’en suis arrivé à la conclusion que :

• paramètrer TLS était le plus simple, grâce aux instructions pki simples
• les instructions listen font maintenant leur travail dans un espace très restreint
• le routage vers la distribution locale et le transfert est facile grâce à une combinaison de règles action et match.
• concernant le filtrage, clamav n’a pas été très utile pour mes utilisateurs (aucun n’était utilisateur Windows) et les options de filtrage utilisées par spamassassin en arrière-plan étaient soit inopérantes, soit trop complexe pour avoir du sens à s’en servir.
  J’avais fini par tester un alternative moderne, rspamd, qui était disponible via le système de paquets d’OpenBSD.
• dkimproxy semblait être un bon candidat pour signer les messages sortants, je l’ai testé un temps, mais suite au conseil de Martijn van Duren, j’ai basculé sur dkimsign, aussi disponible sous OpenBSD en tant que paquet opensmtpd-filter-dkimsign.

En supplément de smtpd qui est déjà dans la base, cette configuration requière les paquets opensmtpd-filter-dkimsign and opensmtpd-filter-rspamd.

L’installation des deux paquets se fait via pkg_add qui installe toutes les dépendances requises.

Avec ces pré-requis en place,

disable and stop exim
doas rcctl disable exim && doas rcctl stop exim

disable and stop clamav
doas rcctl disable clamav && doas clamav stop clamav

disable and stop spamassassin
doas rcctl disable spamassassin && doas rcctl stop spamassassin

À ce stade, nous devons supprimer les paquets avec

doas pkg_delete packagename

et suivre les étapes affichées suite au message de suppression de paquet.

Ne supprimez pas la configuration d’exim, avant d’avoir copié les parties utiles dans votre nouveau fichier /etc/mail/smtpd.conf.

J’ai fini par obtenir cette configuration (modifié ici légérement par souci de concision) :

---- /etc/mail/smtpd.conf

table aliases file:/etc/mail/aliases

table domains_local {
"bsdly.com",
"bsdly.eu",
"bsdly.net",
"bsdly.no",
"bsdly.org",
"bsdly.se",
"nxdomain.no",
# plus a lot of other domains, elided here for brevity
}

table relay_for_domains {
"nuug.no",
"blug.linux.no"
# again more domains in the real smtpd.conf, left out here
}

table domain_relays {
"nuug.no" = "smtp://mx1.nuug.no",
"blug.linux.no" = "smtp://mail.lamasti.net"
# again more domains in the real smtpd.conf, left out here
}

table relay_from_ips {
127.0.0.1
::1
# The rest are fictional, RFC5737 and RFC3849
192.0.2.0/24
198.51.100.0/24
203.0.113.0/24
2001:DB8::/32
}

filter "rspamd" proc-exec "filter-rspamd"
filter dkimsign_rsa proc-exec "filter-dkimsign -d bsdly.net -s x -k /etc/mail/dkim/private.rsa.key" user _dkimsign group _dkimsign

pki skapet.bsdly.net cert "/etc/mail/certificate.pem"
pki skapet.bsdly.net key "/etc/mail/privkey.pem"

listen on socket

listen on all port 25 tls pki skapet.bsdly.net filter "rspamd"
listen on all port 465 smtps pki skapet.bsdly.net filter "rspamd"
listen on all port submission tls pki skapet.bsdly.net

action "local_mail" mbox alias <aliases>
action "relay_domain" relay domain <domain_relays> filter "rspamd"
action "outbound" relay filter dkimsign_rsa

match from local for local action local_mail
match from any for domain <domains_local> action local_mail
match from any for domain <relay_for_domains> action relay_domain
match from src <relay_from_ips> for any action outbound
match from local for any action outbound

Les noms de domaines et adresses IP spécifiques seront différents pour le site secondaire, comme ce sera votre cas, dans toute configuration que vous mettriez en place.

Après l’examen des journaux et des messages, j’ai également dû apporter de légères modifications à la configuration de rspamd.

---- /etc/rspamd/local.d/actions.conf

reject = 10; # final reject
discard = 15;
add_header = 6; # mark spam
greylist = null; # do not greylist, we have spamd for that

# Custom action (referenced by force_actions), no own threshold
phishing = {
flags = ["no_threshold"];
}

Voilà l’entière configuration. En tenant compte de la longue liste de domaines et de réseaux, la longueur totale de ma configuration est maintenant :

$ grep -vc \# /etc/mail/smtpd.conf
104

104 lignes, là où la précédente configuration pour exim, une fois les lignes de commentaires supprimées, était de :

$ grep -vc \# /etc/exim/configure
380

380 lignes.

Le fichier smtpd.conf est aussi lisible que celui de pf.conf, ayant de nombreuses fonctionnalités similaires.

Une fois les paquets installés et les anciens services désactivés, activez et lancez les nouveaux services.

Avant de (ré)activer smtpd en tant que serveur de messagerie par défaut après exim, exécutez :

$ doas /usr/local/sbin/exim-disable

pour restaurer le fichier /etc/mailer.conf à son état original.

Si tout cela échoue, vous pouvez facilement récupèrer une version intacte depuis le CVS d’OpenBSD.

Pour activer ces nouveaux services, exécutez

$ doas rcctl enable smptpd && doas rcctl start smtpd
$ doas rcctl enable redis && doas rcctl start redis
$ doas rcctl enable rspamd && doas rcctl start rspamd

Vous devriez constater une activité assez rapidement en surveillant le fichier /var/log/maillog, tel que :

$ tail -n 500 -f /var/log/maillog

Quand vous serez satisfait du flux de couriels entrants et sortants et qu’ils soient relayés là où vous le souhaitez, vous pourrez supprimer les paquets exim, clamav et spamassassin puis suivre les instructions retournées par les messages de pkg_delete pour libérer de l’espace disque.

Et, oui des configurations bien plus complexes sont possibles, tout particulièrement en matière de filtrage.

Mais j’ai été agréablement surpris à la fois par la simplicité de cette transition que par la perspective de disposer d’une configuration vraiment facile à entretenir et à améliorer.

Le processus de transition m’a montré qu’OpenSMTPD est un produit solide, à l’image d’OpenBSD. Faire le choix d’adopter OpenSMTPD en tant que serveur de messagerie par défaut est sans nul doute l’une des meilleures décisions prises par le projet OpenBSD, et les récents utilisateurs tel que moi ne peuvent qu’applaudir cette décision.

OpenSMTPD et OpenBSD sont caractéristiques tous deux par la capacité de leurs développeurs à non seulement tirer des leçons des versions précédentes du système d’exploitation et du serveur de messagerie inclus, mais aussi à venir proposer de nouvelles approches, parfois radicalement différentes, connues pour résoudre des problèmes, afin d’aboutir à un produit plus sûr et plus utilisable. À mon sens, c’est là le serveur de messagerie et le système d’exploitation pour l’avenir.

Si vous êtes intéressé par la configuration de smtpd avec plus de filtres ou d’autres options, il en existe un grand nombre, notamment opensmtpd-filter-dnsbl qui récupère les listes de blocage DNS à partir de sources que vous lui indiquez.

OpenSMTPD est disponible sur une grande variété de plateformes, incluant de nombreuses distributions Linux et BSD, tel FreeBSD via sa version portable.

J’ai opté pour une configuration plutôt minimaliste, principalement parce que d’expérience les fonctionnalités de greylisting et de greytrapping de spamd sont un bouclier très efficace et nécessitant très peu d’entretien pour tout service de messagerie. Si le greytrapping vous intéresse, l’article peu souvent mis à jour Eighteen Years of Greytrapping - Is the Weirdness Finally Paying Off? (et sa version avec traqueurs et paginée) fournit plus de lecture via de nombreux liens qui peuvent occuper raisonnablement plus d’une de vos soirées.

Si vous préférez un livre qui couvre plus de sujets réseaux sous OpenBSD et FreeBSD, qui consacre une place importante à spamd, le livre The Book of PF, maintenant dans sa quatrième édition, est à vous.

Bonne nuit, et bonne chance !

Je désire remercier Martijn van Duren pour son conseil précieux durant l’écriture de cet article.

OpenSMTPD is the Mail Server for the Future © 2026 Peter N. M. Hansteen (publié le 15/05/2026)

Vous pourriez être aussi intéressé par la lecture d’articles sélectionnés via That Grumpy BSD Guy: A Short Reading List (aussi ici).

FIN

Enjoy-ID!
Enjoy-IT!