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.
Aller plus loin
- Site du projet OpenSMTPD (1167 clics)
- Annonce de la version 5.3 (105 clics)
- Journal d'OpenBSD (103 clics)
# Plus simple que Postfix ?
Posté par denxp . É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 Gilles Chehade (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:
On peut avoir des setups très simples, clairs et qui se lisent "presque" humainement:
ou encore:
qui a priori se passent d'explications :-)
[^] # Re: Plus simple que Postfix ?
Posté par Moonz . É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çantalias
parvirtual
.De plus, l’articulation entre
alias
etdeliver to
ne me semble pas totalement claire : si j’ai un alias de typefoo: bar@otherdomain.com
dans une règlefor ... to ... deliver to maildir
, que fera OpenSTMPD quand il recevra un mail à destination de foo ? De même, entredeliver to maildir
et~/.forward
, qui a la priorité ?[^] # Re: Plus simple que Postfix ?
Posté par Gilles Chehade (site web personnel) . Évalué à 6.
Il sera transféré a l'utilisateur local, les aliases sont optionnels.
Il sera rejeté, le mapping contient la liste exhaustive des utilisateurs du domaine virtuel.
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 Moonz . É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 Gilles Chehade (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:
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 wilk . É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 :
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 Gilles Chehade (site web personnel) . Évalué à 10.
Attention, la page en question date de Juin 2012.
La fonctionnalité à été ajoutée fin 2012:
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 Mme Michu-cide . Évalué à 1.
Et pourquoi pas? Ça marche très bien.
[^] # Re: Plus simple que Postfix ?
Posté par Anonyme . Évalué à -10.
Heu… bof… la configuration utilise la syntaxe illisible de pf.
[^] # Re: Plus simple que Postfix ?
Posté par Anonyme . É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 Loïc Blot (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 siegfried . É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 HanX (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 Amaury . Évalué à 1.
J'utilise un système inspiré de celui-ci pour envoyer des myions de
spamsmails 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 HanX (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 damstux01 . É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 Gilles Chehade (site web personnel) . Évalué à 5.
Oui, ça peut faire du load-balancing IP sortant et ça peut faire correspondre un HELO-name.
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 Kaane . É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 Gilles Chehade (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 siegfried . Évalué à 2.
C'est cool d'entendre ça, prenez votre temps! :)
[^] # Re: Fonctionnalités avancées?
Posté par Bernez . Évalué à 3.
A priori tout ça est faisable avec Exim.
# Slides de la conférence AsiaBSDCon
Posté par Gilles Chehade (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.