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

55
3
juin
2015
OpenBSD

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

Logo 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 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).

  • # Filtres ?

    Posté par (page perso) . Évalué à 10.

    Puisqu'on parle de filtres, quelqu'un pourrait-il expliciter ce dont on parle ? Parce que bon, dans le domaine du courrier électronique, un filtre, ça peut désigner plusieurs choses :

    • des filtres spécifiques au MTA, par exemple un moyen de refuser tout le courrier qui provient de untel ;
    • des filtres externes branchés par relais SMTP (MTA → filtre → re-MTA) ;
    • des milters standard branchés par socket Unix ou réseau sans réinjection (MTA ↔ milter à un moment de la chaîne de traitement des messages), introduits par Sendmail ;
    • des règles définies par les destinataires pour la livraison et le tri de leur courrier, que ce soit par un logiciel externe (procmail, fdm…) ou par un système interne au MDA, et avec un langage spécifique ou standard (sieve).
  • # Merci pour ce logiciel !

    Posté par . Évalué à 10.

    J'ai des besoins extrêmement limité, je n'utilise un MTA que pour créer des addresses bidons pour les sites web qui demandent un compte, mon vrai mail est hebergé par gandi. Donc, je n'y connais pas grand chose et j'ai juste besoin de quelque chose qui travaille hors de la boite.

    Au début, j'utilisais sendmail, fournit par défaut par l'OS, mais c'était trop compliqué. Ensuite, on m'a conseillé postfix, ça marchait plutôt pas mal, mais j'avais l'impression d'avoir quelque chose d'un peu overkill pour mes besoins.

    Puis il y a 2ans, je suis passé à opensmtpd, attiré par la configuration "à la pf" et le support de privsep. J'ai une conf de 5 lignes, ça s'intègre automatiquement et par défaut avec les mails du système, et ça marche bien. Du coup j'en suis très content et je le conseille à tout les gens qui veulent mettre en place un petit serveur mail. (Non que je le déconseille à celles et ceux qui voudraient mettre en place un gros serveur mail, mais je n'ai pas de conseils à donner à ce sujet)

    • [^] # Re: Merci pour ce logiciel !

      Posté par . Évalué à 5.

      J'en profite également : merci aux développeurs !
      Je l'utilise depuis 1 an environ pour mon mail perso (sur une dedibox à 2€ sous FreeBSD) et j'en suis très content. Quelques minutes à peine de lecture de man et tout fonctionne.

      • [^] # Re: Merci pour ce logiciel !

        Posté par . Évalué à 2. Dernière modification le 04/06/15 à 11:08.

        Je ne connaissais pas. Je voulais savoir s'il fonctionnait bien avec spamassassin et consorts.
        J'ai alors trouvé ce tutoriel rassurant.

        J'utilisais Postfix avec grande satisfaction… tant que l'on ne change pas la configuration. J’essaierai openspmtpd pour des besoins plus petits en embarqué aussi.

        A t-on des statistiques sur la charge qu'il peut supporter ?

        • [^] # Re: Merci pour ce logiciel !

          Posté par (page perso) . Évalué à 10.

          Pas de statistiques/benchmarks non, par contre je peux te donner quelques petits chiffres non officiels ;-)

          J'utilise OpenSMTPD en routeur d'envoi en production depuis plus de 2 ans pour router quelques millions de mails par jour vers internet. Dans ces volumes, il n'y a aucun problème de charge, tu tapes les limites artificielles pour ne pas blaster les serveurs en face bien avant de taper une limite du soft en lui meme. Je ne saurais pas dire à quelle charge on satures parceque ca demande un volume d'envoi que je n'ai pas à disposition, seul un spammer ou un ISP pourrait nous renseigner là dessus je pense :-)

          Sur nos campagnes de stress-test twitter, sur une release stable, on encaisse tranquillement 2k sessions concurrentes en flux continu qui balancent des messages un peu aléatoires. La limite des 2k est artificielle, si on configurait notre VM pour mettre à disposition davantage de descripteurs de fichier, le logiciel prendrait davantage de sessions concurrentes, un de ces jours je ferais le test mais vu qu'on scale linéairement à priori et qu'on est à 10% de temps CPU pour le process sur 2k sessions super actives, je pense que même en dégradant non-linéairement on devrait pouvoir encaisser 4k/5k de connexions concurrentes super actives tranquillou.

          En gros, c'est plus que suffisant pour 90% des gens, pour les 10% restant on est juste dans l'incertitude :-)

          • [^] # Re: Merci pour ce logiciel !

            Posté par (page perso) . Évalué à 3.

            Tu fais tourner ça sur des machines de quel calibre ?
            Parce que 10% de CPU sur une machine modeste d'il y a 4 ans ce n'est pas la même chose que sur un octo-cœur d'aujourd'hui avec 32 Gio de mémoire.

            • [^] # Re: Merci pour ce logiciel !

              Posté par (page perso) . Évalué à 10.

              Ne t'attaches pas aux 10%, le but n'était pas de faire un benchmark: aujourd'hui le gros stress-test était sur une VM très costaude avec une TONNE de code de debug et de traces, hier c'était sur mon laptop core-i7 avec un peu moins de debug, demain ce sera sur un serveur low-cost de deditruc ou ovmachin, on lance les tests sur des setups différents en fonction des jours, de l'humeur, du lag sur notre connexion, etc…

              Ce que je voulais illustrer c'est que malgré une petite taille, il ne faut pas se dire que c'est un mini MTA qui ne sait gérer qu'une poignée de clients dans des petits setups, on s'en sert en vrai dans des setups où c'est sollicité de manière bien plus large que la majeure partie des gens qui l'installeront, aussi bien en émission qu'en réception.

              Des gens l'utilisent quotidiennement sur des raspberry, des serveurs cheap et des vieilles machines recyclees, je ne sais pas si elles peuvent gérer efficacement 2k clients, mais à priori je dirais qu'elles ne le feraient pas plus mal qu'un MTA concurrent ;-)

    • [^] # Re: Merci pour ce logiciel !

      Posté par . Évalué à 2. Dernière modification le 09/06/15 à 23:06.

      Je me rajoute à la liste des utilisateurs contents !

      Je n'ai connu que 3 serveurs mails :

      1. sendmail et sa config de merde (quelques mois).
      2. postfix : config très simple, (plusieurs années). Et à chaque modif, la config simple ne l'était finalement plus.
      3. opensmtpd : depuis 2 mois maintenant et ça sera mon dernier ;)

      À croire que seuls les mecs de chez OpenBSD savent écrire des trucs simples à paramétrer qui "juste marchent" et sans bouffer du CPU et 15.000 dépendances…

      Le coup de maître est sans hésiter la clarté du fichier de configuration :

      • on peut créer facilement ses alias pour n'importe quoi (domain, box, relay…) et de n'importe où (fichier plat, sql…).
      • des ordres simples : [ACCEPT|REJECT] FROM … FOR …
      • des options complémentaires qui répondent aux besoins des chieurs.

      Je ne retrouve plus la citation exacte mais elle prend tout son sens ici avec OpenSTMPD

      Les bons développeurs écrivent de nouvelles applications, les meilleurs les réécrivent.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.