Gilles Chehade a écrit 27 commentaires

Salut,

C'est tout à fait ça :-)

Du coup je pose ca la ? :-)

Mettre en place un serveur de mail avec OpenSMTPD, Dovecot et Rspamd

Je pense que c'est un bon choix.

Gilles (@opensmtpd.org 😁)

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 ;-)

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 :-)

Ca désigne surtout les 3 premiers points, le dernier étant plutôt délégué au MDA.

Pas de souci, l'exemple reste correct.
Pour eviter les betises, le comportement par defaut est de considerer que toute omission signifie un comportement local par default:

accept for any relay == accept from local for any relay

et

accept from any == accept from any for local

pour obtenir un open-relay il faut explicitement le demander:

accept from any for any relay

Horreur ! J'ai l'outrecuidance d'avoir un nom de domaine et un nom d'utilisateur trop longs, et ça ne respecte pas la RFC!

Sur les derniers snapshots, la taille acceptée par OpenSMTPD pour les user et domain parts a été augmentée, du coup ton problème est temporaire et il deviendra du passé dans un futur pas trop lointain ;-)

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 :-)

Eric Faurot à mis ses slides en ligne:

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

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.

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é ;)

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.

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 ;-)

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 :-)

Y a pas de mal, et de rien ! :-)

Je me permets de taper l'incruste (merci google alertes) pour donner quelques précisions ;-)

Il y a quelques autres bons points :
* léger, se veut être rapide

Il se situe dans le même ordre de grandeur que la concurrence, ne pas s'attendre a de grosses surprises pour le moment.

• possibilité d'utiliser spamd pour faire du greylisting et dérouter les spammeurs pour pas cher. Bon, il faut accepter les défauts du greylisting, et en plus tu vas avoir besoin de pf.

Spamd et pf sont indépendants, OpenSMTPD ne connait ni l'un ni l'autre et peut être utilises sans.

• la configuration des alias se fait dans de simples fichiers textes, à passer dans une moulinette spécifique.

Il existe actuellement 3 méthodes de configuration d'aliases:
* fichier texte
* fichier db (crée avec makemap a partir d'un fichier texte)
* définition en statique dans le fichier { root => gilles }

Il existe dans une branche git un support LDAP et dans une autre branche git un support SQLite ;-)

Malheureusement, smtpd en est encore au stade du développement, bien que parfaitement utilisable (c'est lui qui fait tourner la ML de OpenSMTPD… comme par hasard). En plus, il est (avec les autres outils) assez spécifiques à OpenBSD. Les ports vers d'autres systèmes existent, mais on peut s'attendre à plus de bugs.

En réalité le stade de développement est bien avance, il y a eu plusieurs phases de stabilisations, d'appels au rapport de bugs, les derniers snapshots sont censés être stables. Il existe une version portable qui est aussi proche de la version native qu'openssh-linux ne l'est de openssh natif, donc il ne faut au contraire PAS s'attendre a plus de bugs et les remonter s'ils existent. Nous sommes très réactifs ! :-)

Je suis a peu pres sur que miod c'est pas un pseudo ;-)

Salut,

Je vais clarifier un peu ton post, la situation est un peu plus complexe que cela :-)

Jacek et moi avons de gros desaccords sur plusieurs points, en partie sur l'orientation du projet et la maniere dont on doit travailler. Il travaille enormement seul en faisant de gros changements qu'il communique uniquement une fois finis et il veut un code parfait et optimise immediatement.

En ce qui me concerne, je pense que l'optimisation ne sert a rien tant qu'on a pas deja un truc fonctionnel (je pense que gagner 10 ms sur une delivery ou 4 octets en memoire quand personne n'utilise smtpd parcequ'il manque pleins de features, c'est pas une priorite), et j'avance par petites iterations en communiquant a chaque etape. Je privilegie d'avoir un truc qui marche, quitte a passer une heure ou deux a nettoyer derriere.

Clairement, ces deux modes de travail sont incompatibles. Deja parceque je me retrouve exclu de toute decision, je n'ai mon mot a dire que sur des details mineurs une fois le fait accompli; mais aussi parceque generalement ses modifications sont des changements radicaux qui impactent ce sur quoi je bosse sans que j'en ai ete averti ... et ca se traduit generalement par moi qui fait une croix sur plusieurs jours ou semaines de boulot pour ne pas perdre encore plus de temps en discussions. Pour faire simple, il considere que mon code est mediocre (je le cite) et il est en train de reecrire progressivement l'ensemble en me laissant un minimum de marge de decision.

Mon fork n'en est pas reellement un, mon but est de pouvoir faire avancer le projet et combler mes propres besoins sans me prendre un mur tous les trois jours. Il suffit de voir que j'ai commite sur pSMTPD davantage de code que que sur OpenSMPTD en un an...

OpenSMTPD commence de plus en plus a ressembler a un projet mourrant, les personnes qui contribuaient ont arretees, ceux qui testaient regulierement n'envoient plus de rapports. En un an on est passe d'un projet super actif avec des contributions de plusieurs developpeurs (openbsd et autres) qui avancait chaque semaine a un projet qui voit des mois passer sans le moindre commit. On m'a demande par mail pas plus tard qu'hier si le projet n'allais pas etre abandonne ...

Je ne veux pas etre associe a ca, je prefere bosser sur ma version ou le projet est actif et si Jacek veut importer mon code, il pourra faire la demarche lui meme d'adapter son code au mien plutot que l'inverse. Mais ce n'est pas un fork, je ne suis pas en competition, je ne le distribue pas (meme si le cvs est accessible a tous) et je n'en fait pas vraiment la promotion a part communiquer mes modifs sur le blog.

je nie !

Pourquoi elle se fait au detriment des avancees du logiciel libre ?
Tu veux dire que plus de choix dans le logiciel libre nuit au logiciel libre ?

Pour ma part, je pense que configurer mon serveur de mail avec un fichier de 5 lignes lisibles est une avancee, au moins en ce qui concerne mon besoin, et au vu des mails que j'ai pu recevoir ces derniers mois, ca m'a tout l'air d'etre un sentiment partage par bon nombre d'admins et d'utilisateurs.

En fait je pense que ta reflexion est errone parceque tu pars du principe que le temps qu'un developpeur passe a coder un outil pour lequel il existe deja des alternatives est une perte de temps qui pourrait etre mieux depense ailleurs. Mais tu ne tiens pas compte du fait qu'un paquet de developpeurs opensource le sont par hobby et ne vont pas coder juste pour coder, mais vont le faire parcequ'un (ou plusieurs) sujet(s) les interessent. Je peux te garantir que si je bossais pas sur OpenSMTPD, je bosserai pas plus a essayer d'ameliorer Xorg ou a creer une alternative a Office, je passerai peut etre juste plus de temps a regarder la tele et a me mettre une murge dans un pub ;-)

Apres chacun a sa vision du truc, le declencheur c'est pas *juste* une incompatibilite de license, c'est la somme de plusieurs besoins.

ca veut juste dire que les binaires sont disponibles, mais OpenBSD utilise toujours sendmail et ca restera le cas tant que OpenSMTPD ne sera pas juge comme suffisament fiable et mature.

en d'autres termes, si tu veux tester tu peux facilement lancer OpenSMTPD mais faudra une action et une configuration manuelle de ta part pour le mettre a la place de Sendmail.

c'est linke au build pour permettre de tester, mais c'est pas production ready.
a vos risques et perils ... :-)

Je saurais pas te repondre, c'est surtout une question de temps et de motivation.

J'ai fait le portage NetBSD et FreeBSD un soir ou j'avais pas vraiment la motivation de faire autre chose, d'autres personnes ont ameliores, mis a jour et package le portage FreeBSD, mais pour etre honnete il n'est pas encore pret sous OpenBSD donc devoir gerer les autres systemes c'est pas specialement une priorite immediate pour moi ;-)

Le prochain portage devrait etre pour Linux, si je me motive ou qu'une ame charitable le debute[1] ... (quelqu'un ? :p)

[1] http://www.poolp.org/cgi-bin/cvsweb/opensmtpd
[2] anoncvs@cvs.poolp.org:/cvs co -P opensmtpd

\o/