OpenSMTPd : concis ou taiseux ?
===============================

Date: 2017-07-19 16:36
Author: jdn06
Category: 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 ([email protected]).  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[1] à  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[2] 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.

[1] https://forums.freebsd.org/threads/60005/
[2] https://www.mail-archive.com/misc@opensmtpd.org/msg02833.html