OpenSMTPD un an et quelques mois après...

Cet article fait écho à celui de l'an dernier présentant la mise en place d'un serveur SMTP avec OpenSMTPD.

Dans cet article nous allons faire un bond en arrière d'un an pour suivre l'évolution du projet avec ses versions mineures & majeures.

Sommaire

• Rappel
• OpenSMTPD Aujourd'hui
  • Mars 2014 : OpenSMTPD 5.4.2
    • Nouveautés depuis la dernière version stable 5.4.1.
    • Expérimental
    • Limitations
  • Décembre 2014 : OpenSMTPD 5.4.4
  • Avril 2015 : OpenSMTPD 5.4.5
• Questions-Réponses avec Gilles Chehade
  • Quelles sont tes impressions sur l'année écoulée ?
  • Le nombres de contributeurs est-il en hausse ?
  • Quelle a été la fonctionnalité publiée la plus marquante cette année ?
  • Quelle est la feuille de route pour les prochaines versions d'OpenSMTPD ?
• OpenSMTPD demain

Rappel

OpenSMTPD est un service "jeune" qui a voulu reprendre la simplicité de compréhension et de configuration du firewall Packet Filter (PF) d'OpenBSD. Ce service est implémenté depuis OpenBSD 4.6 dans la branche "unstable" et depuis OpenBSD 5.3 en tant que stable. Une dépêche avait été publiée ici, fin 2009, à ce sujet.

OpenSMTPD Aujourd'hui

Nous étions le 17 février 2014 sous la version 5.4.1 d'OpenSMTPD. Nous sommes maintenant en juin 2015 sous la version 5.4.5.

Le 21 décembre 2014 la version 1.0.0 de lib-asr était publiée en dehors du projet car jugée assez mature. Le 20 mai 2015 c'est le premier snapshot d'opensmtpd-extras comprenant les tables et les filtres personnalisés (LDAP, SQL, redis, etc.).

OpenSMTPD est à présent un projet mature qui fait partie des choix possibles lorsque l'on réfléchit à quel MTA utiliser lors de la mise en place d'une infrastructure mail.

Voici les principaux changements entre les versions, il est à noter que la version 5.4.3 n'a pas été publiée comme telle, mais a été l'objet du support des nouveautés ou de réécriture des versions actuelles.

Mars 2014 : OpenSMTPD 5.4.2

Nouveautés depuis la dernière version stable 5.4.1.

• Introduction initiale du support des extensions DSN (Delivery Status Notification) :
  • NOTIFY=SUCCESS, NOTIFY=FAILURE, NOTIFY=DELAY, NOTIFY=NEVER ;
  • RET=HDRS, RET=FULL ;
• introduction initiale du support des extensions ENHANCEDSTATUSCODES :
  • le processus smtp retourne des codes de type ENHANCEDSTATUSCODES pour la plupart des commandes ;
  • les autres processus ont maintenant une API pour retourner des codes plus précis…
  • sera amélioré pour chaque version future ;
• smtpctl amélioré :
  • le mode « sendmail » supporte désormais les paramètres DSN ;
  • un couple adresse source -> adresse destination peut être mis en pause ;
  • on peut afficher le statut des processus avec smtpctl show status ;
• introduction du support SNI ;
• correction et améliorations de la documentation ;
• correction de plusieurs bugs mineurs et nettoyage interne du code !

Expérimental

Il est possible d'utiliser différents backends, pour le moment expérimentaux :

• Redis ;
• SQLite ;
• LDAP ;
• PostgreSQL ;
• SOCKETMAP.

Limitations

• pas de support de filtres ;
• pas de masquerading ou réécriture d'adresses.

Décembre 2014 : OpenSMTPD 5.4.4

Cette version présente beaucoup de nettoyages et de changements :

• la table API a été retravaillée pour être prête pour les filtres ;
• "enqueuer" a été retravaillé ;
• les privilèges du moteur RSA ont été séparés ;
• les processus liés ou secondaires ont été fusionnés en un seul ;
• le profilage du code a été désactivé par défaut, ce qui empêche le processus de se réveiller ;
• plusieurs bugs mineurs ont été corrigés ;
• l'ajout de domaine a été implémenté pour une meilleure interopérabilité avec d'autres MTA ;
• plusieurs documentations ont été améliorées.

Avril 2015 : OpenSMTPD 5.4.5

• Suppression d'un hack introduit il y a longtemps qui fait planter quand OpenSMTPD est compilé avec l'option «  FORTIFY » de gcc ;
• correction d'une erreur liée à getlogin() menant à un émetteur invalide quand une application met en attente des courriels au nom de l'utilisateur ;
• correction d'une erreur de logique dans le code SNI qui menait à un problème remonté par Edwin Torok  :
  • une possible déconnexion de certains clients ;
  • un possible mauvais certificat SNI présenté aux clients ;
  • un possible plantage du démon.

Questions-Réponses avec Gilles Chehade

Quelles sont tes impressions sur l'année écoulée ?

Alors, j'ai deux points de vue assez mitigés sur la question.

Le premier est que ça a été une année plutôt bonne dans la mesure où on a observé une adoption très significative du projet. Nous avons été packagé un peu partout de manière indépendante, les gens débarquent sur notre canal IRC et nous font découvrir des distributions qu'on ne connaissait même pas.

Je ne sais pas combien d'utilisateurs nous avions l'an dernier, je n'ai pas la moindre idée de combien nous en avons aujourd'hui, par contre je me rends bien compte que l’activité de notre mailing-list, de notre IRC ou de notre Twitter sont incomparables avec celle d'il y a un an. On me fait assez souvent tourner des liens vers des blogs et des forums où il est fait mention du projet, c’était beaucoup moins le cas avant. Et je ne te parle même pas de ma mailbox qui est devenue ingérable.

Je pense qu'un cap a été franchi : avant le projet n’était pas connu, le choix évident était dans la concurrence, maintenant quand quelqu'un est en train de choisir son MTA, on fait partie des solutions envisagées et notre simplicité nous donne beaucoup de poids dans la balance.

Là où c'est une moins bonne année c'est plus d'un point de vue personnel de développeur. Nous avons eu deux ans de développement sponsorisé nous permettant de se concentrer sur le projet avec deux développeurs à temps plein. Cela nous a permis de débuter et finaliser des gros chantiers, de rattraper notre retard vis-à-vis de la concurrence et globalement d'en arriver là où nous en sommes aujourd'hui. Ça a été une période vraiment chouette.

Depuis un an, nous ne sommes plus sponsorisés et nous sommes revenus en mode « boulot après le boulot ». Du coup, beaucoup plus d’hésitations quand il s'agit de débuter un truc qui va prendre un paquet d'heures, on fait en sorte de faire au mieux avec le peu de temps disponible. Tout prend forcément beaucoup plus de temps et c'est frustrant.

Maintenant cela ne nous empêche pas d'avancer, on prépare une grosse version majeure pour juin, elle est en phase de stress-test, et elle apporte son gros lot de nouveautés.

Le nombres de contributeurs est-il en hausse ?

Oui, très clairement.

Avant, les contributions externes étaient très épisodiques. Le nombre de contributeurs était restreint et ils provenaient presque tous de la communauté BSD, avec OpenBSD et FreeBSD en tête. Puis la situation a complètement changé.

Déjà, le taux de contribution a considérablement grimpé et est régulier depuis plusieurs mois avec très peu de semaines où l'on ne reçoit rien. Ensuite, les contributeurs sont beaucoup plus variés, ils viennent de différents systèmes, majoritairement Linux et FreeBSD, soumettent un diff pour fixer un problème et disparaissent. Ils s'ajoutent à la liste des contributeurs plus réguliers, qui eux restent toujours présents.

Enfin, les contributions sont aussi très variées, avant elles restaient relativement en surface, maintenant on reçoit aussi bien des fixes pour de la documentation que pour des améliorations dans les couches basses.

Quelle a été la fonctionnalité publiée la plus marquante cette année ?

Sans aucune hésitation et de très très très loin : les filtres.

Il y a 3 ans nous avons commencé à évoquer l’implémentation des filtres lors d'un hackathon a Budapest. La discussion ne tournait pas autour de l'API en elle-même mais de toute la plomberie interne sur laquelle elle serait basée et de ce que l'on devait pouvoir en attendre. Le filtering n’était pas encore une grande priorité, plutôt un sujet de fond pour lequel on savait ce qu'on voulait, ce qu'on ne voulait pas et pour lequel il fallait encore trouver le bon design.

Il y a eu des allers-retours entre nous pendant plusieurs mois avec des prototypes et on a fini par trouver le bon design qui respectait toutes nos contraintes et permettait toutes nos fonctionnalités. Le design est théoriquement simple, il offre de nombreux avantages mais impliquait un refactoring important des couches basses qui a pris beaucoup de temps car très invasif et devant s’opérer sans casser l'existant.

Ça a été assez pénible parce que c'est une fonctionnalité très demandée et il a fallu jongler entre le boulot qu'elle impliquait et devoir expliquer en continu pourquoi on préférait s'obstiner sur ce design plutôt que de se simplifier la vie et de charger des «  .so » comme tout le monde.

Finalement on a tenu bon, on a finalisé comme on le voulait et ce sont des mois de boulot qui seront concrétisés dans notre prochaine version.

Quelle est la feuille de route pour les prochaines versions d'OpenSMTPD ?

Rien n'est encore officiellement décidé, pour l'instant on se concentre sur la version de juin qui est assez chronophage.

Je pense que les filtres vont générer pas mal de demandes, et que ça va très certainement décider de notre roadmap à notre place.

Dans tous les cas, filtres mis à part, je sais qu'il y aura au moins :

• l'ajout du support de DANE ;
• différents travaux liés de près ou de loin à TLS ;
• la simplification de la couche de build portable.

Et pour ma part, j'aimerai exploiter un peu plus le mécanisme de queues custom, peut-être une queue «  _riak », ça dépendra de mon temps libre.

OpenSMTPD demain

Comme Gilles le fait entendre, la prochaine version de juin devrait apporter son lot de nouveautés. Mais le OpenSMTPD de demain est déjà présent aujourd'hui, il ne faudra pas attendre juin pour avoir un aperçu des efforts que la communauté a pu fournir. En effet, dans son souci de s'étendre sur de plus en plus de distributions et d'améliorer la branche portable du projet, OpenSMTPD a fait appel le 16 février 2015 (à 13:17) à sa communauté pour la location d'un serveur dédié. La réponse a été rapide de part l'envoi de liens vers des plate-formes de locations intéressantes jusqu'à des propositions de partage de ressources. Mais le 16 février (à 14:51), l'objectif (qui n'en n'était pas vraiment un) de couvrir les frais pour un an de location avait déjà été atteint !

Il est toujours possible de faire des donations pour le projet pour soutenir les développeurs et le projet à donations@opensmtpd.org (Paypal).

Aller plus loin

• OpenSMTPD (429 clics)
• Liste de diffusion d'OpenSMTPD (95 clics)
• Page de manuel de smtpd (109 clics)
• Unix Experience : [Serveur Dédié] Serveur Mail (337 clics)
• Unix Experience : OpenSMTPD, Premiers pas (299 clics)
• DLFP : OpenSMTPD : Premiers Pas (211 clics)
• Technoquarter (125 clics)