OpenSMTPD 5.3 est de sortie !

Posté par  . Édité par Pierre Jarillon, Benoît Sibaud, Nicolas Casanova, Florent Zara et baud123. Modéré par patrick_g. Licence CC By‑SA.
Étiquettes : aucune
42
25
mar.
2013
OpenBSD

SMTPest un protocole de communication utilisé pour transférer le courrier électronique. Le D final comme daemon signifie qu'il s'agit du logiciel pour serveur de messagerie.

Au cours de l'AsiaBSDCon, qui a eu lieu il y a quelques jours à Tokyo, Éric Faurot, l'un des développeurs, a annoncé la sortie d'OpenSMTPD 5.3 qui est la première version stable, prête pour la production, d'OpenSMTPD. C'est d'ailleurs celle-ci qui sera livrée avec la prochaine version d'OpenBSD (5.3).

Le développement de OpenSMTPD a été motivé par plusieurs constats concernant les serveurs de messagerie électronique actuels : configuration difficile, audit du code difficile, licence inadaptée. OpenSMTPD a été conçu afin de résoudre ces problèmes. Après une période de développement, OpenSMTPD est apparu pour la première fois dans OpenBSD 4.6.

Un serveur de courriel prometteur, dont voici la ligne de conduite :

  • Être aussi fiable et sécurisé que possible.
  • Être rapide et efficace.
  • Fournir des fonctionnalités suffisantes pour la plupart des utilisations.
  • Fournir un langage de configuration simple et puissant.

Beaucoup de gens l'utilisent déjà en production et les retours sont plutôt sympas.

Je vous invite donc à découvrir ce nouveau serveur SMTP, pour ceux qui ne le connaissent pas encore.

La liste des fonctionnalités est présente sur le site du projet.

OpenSMTPD

Aller plus loin

  • # Plus simple que Postfix ?

    Posté par  . Évalué à 5.

    J'ai pas trouvé (mal cherché) de doc directement sur le site.
    D'après ce que j'ai vu, au niveau de la configuration, ça ressemble quand même pas mal à Postfix qui pour moi est au top de la simplicité.
    Comment openSMTPD se situe par rapport à ce dernier ?

    • [^] # Re: Plus simple que Postfix ?

      Posté par  (site web personnel) . Évalué à 10.

      Postfix est assez simple oui, la configuration reste assez différente dans l'esprit.

      Dans OpenSMTPD, elle se divise en 4 parties:

      • Les interfaces d'écoute avec leurs options (local ? ssl ? auth ?);
      • les options (temps d'expiration d'une enveloppe dans la queue, …);
      • les tables de lookup utilisées pour à peu près tout (aliases, virtual, auth, …);
      • le ruleset qui défini les règles que doivent respecter les enveloppes pour être acceptées;

      On peut avoir des setups très simples, clairs et qui se lisent "presque" humainement:

      listen on all
      
      accept from any for domain example.org deliver to maildir
      accept from local for any relay
      
      

      ou encore:

      listen on all
      table mesdomaines { example.org, example.com }
      
      accept from any for domain <mesdomaines> deliver to maildir
      accept from local for any relay
      
      

      qui a priori se passent d'explications :-)

      • [^] # Re: Plus simple que Postfix ?

        Posté par  . Évalué à 3. Dernière modification le 25 mars 2013 à 11:41.

        Petite question, dans la forme from any for domain <mydomains> alias <aliases> : si je n’ai que cette directive, que l’utilisateur demandé n’est pas listé dans les aliases mais existe localement, le mail est-il transféré à l’utilisateur local ou rejeté ? Même question en remplaçant alias par virtual.

        De plus, l’articulation entre alias et deliver to ne me semble pas totalement claire : si j’ai un alias de type foo: bar@otherdomain.com dans une règle for ... to ... deliver to maildir, que fera OpenSTMPD quand il recevra un mail à destination de foo ? De même, entre deliver to maildir et ~/.forward, qui a la priorité ?

        • [^] # Re: Plus simple que Postfix ?

          Posté par  (site web personnel) . Évalué à 6.

          Petite question, dans la forme from any for domain alias : si je n’ai que cette directive, que l’utilisateur demandé n’est pas listé dans les aliases mais existe localement, le mail est-il transféré à l’utilisateur local ou rejeté ?

          Il sera transféré a l'utilisateur local, les aliases sont optionnels.

          Même question en remplaçant alias par virtual.

          Il sera rejeté, le mapping contient la liste exhaustive des utilisateurs du domaine virtuel.

          De plus, l’articulation entre alias et deliver to ne me semble pas totalement claire : si j’ai un alias de type foo: bar@otherdomain.com dans une règle for … to … deliver to maildir, que fera OpenSTMPD quand il recevra un mail à destination de foo ? De même, entre deliver to maildir et ~/.forward, qui a la priorité ?

          En fait, "deliver to" spécifie le comportement par défaut de la règle.
          Un alias ou un ~/.forward peut spécifier une méthode différente: adresse pour relai, fichier ou exécution d'un mda alternatif.

          • [^] # Re: Plus simple que Postfix ?

            Posté par  . Évalué à 2.

            Testé sur mon serveur perso, rien à dire, j’aime beaucoup niveau lisibilité de la configuration, surtout en tant que MSA (j’ai jamais aimé configurer l’authentification avec Postfix).

            Par contre, pour l’antispam, pas d’autre solution que d’avoir un postfix/sendmail en amont qui fasse du filtrage avec spamassassin ?

            • [^] # Re: Plus simple que Postfix ?

              Posté par  (site web personnel) . Évalué à 3.

              Yop,

              Je n'utilises pas spamassassin mais si tu peux le configurer en mode proxy, comme un clamavd ou un dkimproxy, tu peux le faire simplement.
              Tu fais tourner ton proxy spamassassin sur le port 80826 et tu le fais relayer vers le port 80825, ensuite tu configures OpenSMTPD comme suit:

              listen on all
              listen on 127.0.0.1 port 80825 tag SPAMASSASSIN
              
              accept tagged SPAMASSASSIN for domain example.com deliver to maildir
              accept from any for domain example.com relay via smtp://127.0.0.1:80826
              
              

              Une envelope provenant de la première interface n'est pas tagguée, elle ne matche pas la première règle accept. Elle se retrouve relayée vers ton proxy spamassassin qui la réinjecte dans ta deuxième interface qui elle applique un tag sur chaque enveloppes ce qui les fait matcher la première règle.

              Il y a peut-être d'autres solutions, mais celle ci est celle que j'utilise pour dkim-proxy et elle marche plutôt bien :-)

    • [^] # Re: Plus simple que Postfix ?

      Posté par  . Évalué à 2.

      Pas trouvé de doc non plus, dans le lien que tu indiques il y a quelque chose qui ne me parait pas des plus simple :

      As I understood it, the only way to deal with users is to create system users ; in /etc/passwd. They don’t have to be able to log in ; they just need a home, to store email, and a password, for authenticated smtp.

      Il faudrait que chaque compte mail soit un compte unix… Sans doute qu'il n'a pas trouvé la doc non plus ?

      • [^] # Re: Plus simple que Postfix ?

        Posté par  (site web personnel) . Évalué à 10.

        Attention, la page en question date de Juin 2012.

        La fonctionnalité à été ajoutée fin 2012:

        listen on all
        table myusers "/etc/mail/myusers" # ou .db, ou sqlite/ldap (experimental)
        
        accept from any for domain example.org userbase <myusers> deliver to maildir
        
        

        Le projet est très documenté, mais uniquement par le biais de ses pages de manuel.
        Il va falloir attendre un peu avant que la documentation en ligne s'étoffe ;-)

      • [^] # Re: Plus simple que Postfix ?

        Posté par  . Évalué à 1.

        As I understood it, the only way to deal with users is to create system users ; in /etc/passwd. They don’t have to be able to log in ; they just need a home, to store email, and a password, for authenticated smtp.

        Il faudrait que chaque compte mail soit un compte unix… Sans doute qu'il n'a pas trouvé la doc non plus ?

        Et pourquoi pas? Ça marche très bien.

    • [^] # Re: Plus simple que Postfix ?

      Posté par  . Évalué à -10.

      ça ressemble quand même pas mal à Postfix qui pour moi est au top de la simplicité.

      Heu… bof… la configuration utilise la syntaxe illisible de pf.

      • [^] # Re: Plus simple que Postfix ?

        Posté par  . Évalué à 8. Dernière modification le 25 mars 2013 à 17:23.

        Illisible ????

        Soit c'était du second degré et je suis stupide, soit tu es le seul au monde à trouver PF illisible.

        • [^] # Re: Plus simple que Postfix ?

          Posté par  (site web personnel) . Évalué à 7.

          Elle est très bien la syntaxe de PF. De plus si tu es dans un écosystème BSD c'est toujours bien de retrouver la même façon de procéder pour le filtrage (cd OpenBGPD qui utilise le même type de syntaxe pour la distribution des routes).

          Veepee & UNIX-Experience

  • # Fonctionnalités avancées?

    Posté par  . Évalué à 1.

    Quelqu'un sait ce que ça vaut niveau réécriture des mails (entetes) comparé à Postfix?

    Ex, sur postfix, pour modifier les entetes, pas possible de le faire juste pour les mails entrants (mais pas envoyés par les clients auth), et que pour certains domaines, on peut tout simplement pas tout faire à la fois.

    Est-ce que ça supporte le SRS et que pour certains domaines? (maintenant que spf est accepté de partout, il est ptet temps de s'occuper de srs?!)

    Postfix, c'est bien et simple, mais quand tu commences à combiner des fonctionnalités, tu te rends compte que tu peux pas, car la config est assez rigide.

    • [^] # Re: Fonctionnalités avancées?

      Posté par  (site web personnel) . Évalué à 0.

      Est-ce que ça peut faire du load-balancing IP sortant (pour ceux qui font du mailing, ça doit leur parler) ? Avec postfix sous Linux, la seule solution efficace est de passer par du bricolage avec iptables…

      • [^] # Re: Fonctionnalités avancées?

        Posté par  . Évalué à 1.

        Avec postfix sous Linux, la seule solution efficace
        est de passer par du bricolage avec iptables…

        J'utilise un système inspiré de celui-ci pour envoyer des myions de spams mails avec un seul serveur postfix et un pool d'adresses IP. Cela fonctionne bien. Après ça dépend de ce que tu entends par efficace bien évidemment.

        Il existe également un patch (payant) pour Postfix qui ferait à peu près la même chose sans la bidouille consistant à appeler un script externe.

        • [^] # Re: Fonctionnalités avancées?

          Posté par  (site web personnel) . Évalué à 1.

          Oui j'étais déjà tombé sur cet article à l'époque avec les tables TCP… pas satisfaisant à mon gout. La rotation d'IP se fait toutes les 30 secondes, j'ai pas trouvé de paramètre pour bidouiller ça ni même dans le source de postfix. La solution que j'ai trouvé est de bricoler avec le modules iptables nth en répartissant les TCP syn sur mon pool d'IP.

          Si ça te branche, je peux te filer ma config (email : emilien point mantel at gmail point com).

        • [^] # Re: Fonctionnalités avancées?

          Posté par  . Évalué à 0.

          Hmmm, il existe une solution plus propre avec postfix.

          Les dernieres versions de postfix, permettent du multi instances (postmulti). Chaque instance écoute sur une ip privée et sort avec une adresse IP publique.

          Avec Haproxy, on loadbalance sur sur les différentes instances.

      • [^] # Re: Fonctionnalités avancées?

        Posté par  (site web personnel) . Évalué à 5.

        Oui, ça peut faire du load-balancing IP sortant et ça peut faire correspondre un HELO-name.

        listen on all
        table addrs { x.x.x.x, y.y.y.y }
        table names { x.x.x.x = "mx1", y.y.y.y = "mx2" }
        
        accept for any relay source <addrs> helo <names>
        
        

        Ici les tables sont statiques, mais si elles utilisaient une source différente (sql, db, fichier, ldap, …) il deviendrait alors possible de les modifier en runtime.

        • [^] # Re: Fonctionnalités avancées?

          Posté par  . Évalué à 5.

          Ici les tables sont statiques, mais si elles utilisaient une source différente (sql, db, fichier, ldap, …) il deviendrait alors possible de les modifier en runtime.

          Quitte à faire du BSD, autant laisser les tables en statique et faire du CARP entre les différentes machines assurant le load balancing.

    • [^] # Re: Fonctionnalités avancées?

      Posté par  (site web personnel) . Évalué à 7.

      Et bien, on est loin derrière Postfix: on a pas encore …

      On a pris le parti de ne pas faire de modification du contenu depuis le daemon: le rewrite de contenu, d'en-têtes, ou encore de sender/recipient sur l'enveloppe sera fait depuis un filtre… mais le support des filtres est prévu pour la release stable 5.4 (et dans les snapshots !stable à venir).

      Les filtres pourront traiter les mails entrants / sortants différemment, ils sauront si un utilisateur est authentifié et ils devraient être plutôt simples à utiliser ET à écrire. En fait, je peux d'ores et déjà le dire parce que le code est en grande partie déjà écrit et juste désactivé ;)

    • [^] # Re: Fonctionnalités avancées?

      Posté par  . Évalué à 3.

      Ex, sur postfix, pour modifier les entetes, pas possible de le faire juste pour les mails entrants (mais pas envoyés par les clients auth), et que pour certains domaines, on peut tout simplement pas tout faire à la fois.

      Est-ce que ça supporte le SRS et que pour certains domaines? (maintenant que spf est accepté de partout, il est ptet temps de s'occuper de srs?!)

      A priori tout ça est faisable avec Exim.

  • # Slides de la conférence AsiaBSDCon

    Posté par  (site web personnel) . Évalué à 5.

    Eric Faurot à mis ses slides en ligne:

    https://poolp.org/~eric/asiabsdcon2013-smtpd/

Suivre le flux des commentaires

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