Published: mer. 19 juillet 2017
By jdn06
In Auto-hébergement .
tags: Mail OpenBSD OpenSMTPd
Je viens d’abandonner le vénérable Sendmail 8.15.2 pour un petit jeune, OpenSMTPd !
Pourquoi remplacer quelque chose qui marchait bien et m’a donné toute satisfaction ces sept dernières années ?
Les fichiers de configuration de Sendmail impressionnent et datent d’un autre âge, ce qui fait que toute modification de la configuration donne des sueurs froides.
Ceux d’OpenSMTPd semblent par opposition un modèle de clarté et de concision, et cela rassure beaucoup.
Sendmail peut tout faire, mais tout y est compliqué, même les choses simples, ce qui fait qu’on n’est jamais entièrement sûr que le programme fait vraiment ce qu’on lui demande.
Les projets issus d’OpenBSD m’ont toujours paru assez bien faits, notamment Packet Filter ; or sa syntaxe semble justement inspirer le serveur mail maison.
Il faut bien se fixer des challenges, et le mail, c’est toujours titanesque.
J’ai eu mon lot de déconvenues, au point que j’éprouve un peu de déception pour ce programme.
Commençons par les points positifs : la configuration de base est assez bien faite, si bien qu’on peut faire tourner un serveur complet avec signature DKIM avec un fichier de configuration de quinze lignes dans une syntaxe très claire et lisible !
Les valeurs par défaut permettent en effet d’obtenir une authentification SMTP sans programme extérieur en ajoutant le mot auth à la directive listen.
Comparé à Sendmail qui n’authentifie rien par défaut et doit s’adjoindre les services d’un élément externe comme cyrus-sasl, il n’y a pas photo !
Mais cette concision et cette clarté sont un peu trompeuses.
Ainsi, la syntaxe n’est pas aussi facile à comprendre que celle de Packet Filter, parce que les concepts utilisés restent un peu flous, comme par exemple le mot local qui manque de précision.
Il vaut probablement mieux utiliser à la place source { 192.168.1.0/24 } si on veut quelque chose de précis.
Mon premier pépin de configuration a concerné les alias.
J’ai voulu réutiliser le fichier qui servait à Sendmail, mais celui-ci mélangeait des noms d’utilisateurs seuls avec des noms d’utilisateurs suivis de leur domaine (utilisateur@domaine.fr).
Qu’OpenSMTPd ne veuille que des noms d’utilisateurs sans domaine, pourquoi pas ; après tout, il dispose d’un procédé équivalent par ailleurs.
Mais que lorsqu’OpenSMTPd ouvre un fichier aliases de ce genre, il le rejette purement et simplement sans produire d’erreur dans les logs, voilà qui est moins satisfaisant et rend la résolution du problème plus difficile.
OpenSMTPd n’est pas seulement concis, il est aussi laconique, voire taiseux !
Si taiseux qu’il avale même parfois les syllabes.
En effet, lorsque le nom d’un utilisateur dépasse les huit caractères, il ne conserve dans les logs que les huit premiers caractères.
Du coup, quand j’ai été confronté à un problème d’authentification sur un compte de ce type, j’ai d’abord cru que le rejet de l’authentification provenait d’un nom d’utilisateur tronqué, alors qu’il n’est tronqué que dans les logs.
Je ne suis apparemment pas le seul à avoir cru dans un premier temps que le problème venait de ces noms tronqués.
Plus ennuyeux encore, les erreurs de configuration ne pardonnent pas.
Si par exemple, on croit avoir traité avec une directive local le cas des courriels provenant des autres jails ou des autres serveurs locaux et qu’on ne vérifie pas que tout marche bien, on peut se retrouver avec de sérieux problèmes.
Si l’utilisateur local envoie à un autre utilisateur local un message qui n’est pas correctement traité par le fichier de configuration, il va se diriger vers le relay et former une boucle infinie que le serveur ne stoppe pas.
Il s’agit certes d’une erreur de configuration, mais elle est assez aisée à commettre par exemple avec root@localhost et peut devenir très problématique lorsque les jails ou les serveurs locaux envoient la nuit suivante des dizaines de messages de bilans journaliers, qui se retrouvent tous dans une boucle sans fin !
Enfin, le module DKIM fourni par le programme fonctionne très bien, mais sa configuration est rendue redoutable par un défaut non documenté qui oblige à coller les arguments des options sans espace.
Si l’on écrit filter dkim-sign dkim-signer "-D mondomaine.fr -s monsélecteur -p /chemin/vers/ma/clef.key", le serveur va refuser de démarrer parce qu’il ne trouve pas la clef et si on contourne le problème en utilisant l’emplacement de clef par défaut et en supprimant l’option "-p", le serveur démarrera mais ne validera pas correctement la signature DKIM.
Pourquoi ? Parce qu’il lit la configuration comme le domaine " mondomaine.fr" et le sélecteur " monsélecteur", en conservant l’espace initiale !
Il faut donc écrire la configuration ainsi : dkim-sign dkim-signer "-Dmondomaine.fr" "-smonsélecteur" "-p/chemin/vers/ma/clef.key"
Mais je n’ai trouvé aucune trace du problème dans la documentation assez pauvre du projet.
Il m’a fallu tomber sur cette page par hasard, après des heures de recherche, pour comprendre ce qui se passait !
Tout cela n’est pas bien grave, mais ne donne pas l’impression d’un programme aussi soigneusement écrit et documenté qu’on pourrait l’espérer.