Merci pour cette belle découverte et le travail derrière !
merci <3
Quelle volumétrie peut-t-on adresser avec planka/ptar ?
En terme de volumétrie, la limite théorique pour plakar et ptar est aux alentours de 18EB, même si je pense que d'autres problèmes se poseront avant, il faut que quelqu'un teste :-)
En pratique, on teste jusqu'à du multi-TB, au dessus ça devient compliqué pour nous, mais considérant notre architecture logicielle, il n'y théoriquement rien qui permet de monter beaucoup plus haut..
Comment se comporte le format .ptar à l'ajout de fichier ? Le fichier est massivement modifié ? (Je pense notamment à de la synchro via syncthing par exemple)
Le format .ptar ne supporte pas l'ajout de fichier, il est immutable une fois crée: il s'agit en réalité d'un repo qui a été sérialisé et figé en lecture seule, toute modification produit des erreurs de sommes de contrôle.
Aujourd'hui, l'ajout d'un fichier revient à recréer un nouveau .ptar en utilisant en source un ancien .ptar en mode synchro et le nouveau fichier, avec du coup une réécriture complète. Techniquement, il est possible d'écrire une version un peu différente de l'outil qui sache faire cet ajout de manière un peu plus efficace, mais ce n'est pas le cas présentement.
Le nombre de snapshots est limité ou peut poser problème au delà d'un certain usage ?
Il n'est pas limité et j'ai monté le test à plusieurs dizaines de milliers en ce qui me concerne. Cela n'a aucune incidence sur la création de backup, la restoration et/ou la manipulation/navigation d'un snapshot en particulier.
Le seul problème est sur des fonctionnalités à la marge type "chercher un fichier dans l'intégralité des snapshots" ou "afficher une timeline de tous les snapshots qui possèdent un répertoire" parce qu'il n'y a pas de secret: il faut les ouvrir et ça sera lent.
Il y a un peu de cache là où c'est possible mais sachant que les repo plakar sont "stateless", il n'y a pas de base de donnée pour s'abstraire d'un serveur et pour limiter les pré-requis sur un nouveau poste, donc on est en environnement assez contraint.
Comment le projet plakar se positionne par rapport à borgbackup ou https://dvc.org/ par exemple ? (le format .ptar semble à première vue un gros avantage à mes yeux pour le partage/transfert et peut-être plus "léger" qu'avoir toute une arborescence à synchroniser)
Pas certain de comprendre la question du positionnement, désolé.
Le format .ptar a pour objectif de remplacer le format "repo" ?
Non, pas du tout, il s'agit vraiment du même format mais sous une forme transportable, les deux ont vocation a vivre en parallèle pour des usages différents, sachant que les améliorations apportés à l'un bénéficient à l'autre :-)
Est-t-il prévu d'intégrer un code correcteur d'erreur ? (je pense notamment à des backups sur clé usb plus ou moins fiables …) (oui, oui, 3-2-1-0)
Long débat, on n'est pas encore convaincu de l'utilité:
Les ECC ne permettent de corriger qu'un taux marginal d'erreur pour un overhead qui est significatif… si l'on considère qu'un second dépôt offre une correction totale.
On s'est réservé la marge nécessaire pour pouvoir ajouter si on change d'avis, pour l'instant la conviction est que c'est usine à gaz pour pas grand chose: le seul projet à le supporter à notre connaissance est kopia, en expérimental depuis très longtemps, et ça a plus l'air d'être fait pour dire "on le fait" que par bénéfice réel.
J'aime beaucoup l'ui intégrée également ! (ce que borg ne propose pas de mémoire)
Oui, les trois projets ont beaucoup de similitudes sur leur fonctionnement (repository de données, snapshot d'un delta avec un algo de CDC, …) mais des approches différentes pour résoudre le problème des sauvegardes et des philosophies différentes sur comment les utilisateurs voient les sauvegardes.
Je peux répondre à toutes vos questions là dessus :-)
Oui il y a quelques similitudes mais dans notre approche le format est verrouillé une fois crée, il n'y a plus d'append possible, l'archive est considérée comme "altérée" et corrompue en cas de modifications.
Pour produire un comportement à la zpaq, en ajout de donnée, il faut prendre en entrée un autre .ptar + le contenu à ajouter pour générer une nouvelle archive:
Je ne connaissais pas Zed, je vais regarder ca pour voir s’il y a un écart a combler en terme de fonctionnalités, mais je pense qu’on est déjà pas mal pratique :-)
Notre code est publie sous license ISC histoire de garantir que le format reste ouvert, je vais publier dans quelques jours une documentation du format pour permettre a quiconque d’écrire sa propre implementation.
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 :-)
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:
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 ;-)
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 :-)
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.
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
[^] # Re: Je trouve ce projet super intéressant !
Posté par Gilles Chehade (site web personnel) . En réponse au lien .ptar: archive format for a single self-contained, portable, immutable, deduplicated, encrypted file. Évalué à 4 (+3/-0).
merci <3
En terme de volumétrie, la limite théorique pour plakar et ptar est aux alentours de 18EB, même si je pense que d'autres problèmes se poseront avant, il faut que quelqu'un teste :-)
En pratique, on teste jusqu'à du multi-TB, au dessus ça devient compliqué pour nous, mais considérant notre architecture logicielle, il n'y théoriquement rien qui permet de monter beaucoup plus haut..
Le format .ptar ne supporte pas l'ajout de fichier, il est immutable une fois crée: il s'agit en réalité d'un repo qui a été sérialisé et figé en lecture seule, toute modification produit des erreurs de sommes de contrôle.
Aujourd'hui, l'ajout d'un fichier revient à recréer un nouveau .ptar en utilisant en source un ancien .ptar en mode synchro et le nouveau fichier, avec du coup une réécriture complète. Techniquement, il est possible d'écrire une version un peu différente de l'outil qui sache faire cet ajout de manière un peu plus efficace, mais ce n'est pas le cas présentement.
Il n'est pas limité et j'ai monté le test à plusieurs dizaines de milliers en ce qui me concerne. Cela n'a aucune incidence sur la création de backup, la restoration et/ou la manipulation/navigation d'un snapshot en particulier.
Le seul problème est sur des fonctionnalités à la marge type "chercher un fichier dans l'intégralité des snapshots" ou "afficher une timeline de tous les snapshots qui possèdent un répertoire" parce qu'il n'y a pas de secret: il faut les ouvrir et ça sera lent.
Il y a un peu de cache là où c'est possible mais sachant que les repo plakar sont "stateless", il n'y a pas de base de donnée pour s'abstraire d'un serveur et pour limiter les pré-requis sur un nouveau poste, donc on est en environnement assez contraint.
Pas certain de comprendre la question du positionnement, désolé.
Non, pas du tout, il s'agit vraiment du même format mais sous une forme transportable, les deux ont vocation a vivre en parallèle pour des usages différents, sachant que les améliorations apportés à l'un bénéficient à l'autre :-)
Long débat, on n'est pas encore convaincu de l'utilité:
Les ECC ne permettent de corriger qu'un taux marginal d'erreur pour un overhead qui est significatif… si l'on considère qu'un second dépôt offre une correction totale.
On s'est réservé la marge nécessaire pour pouvoir ajouter si on change d'avis, pour l'instant la conviction est que c'est usine à gaz pour pas grand chose: le seul projet à le supporter à notre connaissance est kopia, en expérimental depuis très longtemps, et ça a plus l'air d'être fait pour dire "on le fait" que par bénéfice réel.
Merci <3
[^] # Re: cette solution est un ptar (mouillé)
Posté par Gilles Chehade (site web personnel) . En réponse au lien .ptar: archive format for a single self-contained, portable, immutable, deduplicated, encrypted file. Évalué à 3 (+2/-0).
au contraire, cette solution va tout exploser :-p
[^] # Re: Super
Posté par Gilles Chehade (site web personnel) . En réponse au lien .ptar: archive format for a single self-contained, portable, immutable, deduplicated, encrypted file. Évalué à 4 (+3/-0).
On ne visait pas ces certifications mais pourquoi pas
[^] # Re: Super
Posté par Gilles Chehade (site web personnel) . En réponse au lien .ptar: archive format for a single self-contained, portable, immutable, deduplicated, encrypted file. Évalué à 5 (+4/-0).
haha, crédible néanmoins:
on a monté une boite et on bosse 100% sur plakar et liés, donc ça fait partie de notre taff de faire ce genre de choses en 10 jours :-p
[^] # Re: Super
Posté par Gilles Chehade (site web personnel) . En réponse au lien .ptar: archive format for a single self-contained, portable, immutable, deduplicated, encrypted file. Évalué à 5 (+4/-0).
Je prends notes pour le père noël :-p
[^] # Re: Super
Posté par Gilles Chehade (site web personnel) . En réponse au lien .ptar: archive format for a single self-contained, portable, immutable, deduplicated, encrypted file. Évalué à 4 (+3/-0).
Hier, j'ai commencé à écrire
kapsule
un outil spécifique à .ptar, j'espère avoir quelque chose de publiable dans les dix jours :-p[^] # Re: Super
Posté par Gilles Chehade (site web personnel) . En réponse au lien .ptar: archive format for a single self-contained, portable, immutable, deduplicated, encrypted file. Évalué à 3 (+2/-0).
Oui, les trois projets ont beaucoup de similitudes sur leur fonctionnement (repository de données, snapshot d'un delta avec un algo de CDC, …) mais des approches différentes pour résoudre le problème des sauvegardes et des philosophies différentes sur comment les utilisateurs voient les sauvegardes.
Je peux répondre à toutes vos questions là dessus :-)
[^] # Re: Super
Posté par Gilles Chehade (site web personnel) . En réponse au lien .ptar: archive format for a single self-contained, portable, immutable, deduplicated, encrypted file. Évalué à 3 (+2/-0).
Oui il y a quelques similitudes mais dans notre approche le format est verrouillé une fois crée, il n'y a plus d'append possible, l'archive est considérée comme "altérée" et corrompue en cas de modifications.
Pour produire un comportement à la zpaq, en ajout de donnée, il faut prendre en entrée un autre .ptar + le contenu à ajouter pour générer une nouvelle archive:
$ plakar ptar -o nouveau.ptar -k ancien.ptar /chemin/vers/les/donnees/a/ajouter
[^] # Re: Super
Posté par Gilles Chehade (site web personnel) . En réponse au lien .ptar: archive format for a single self-contained, portable, immutable, deduplicated, encrypted file. Évalué à 10 (+11/-0).
Hello, auteur de ptar ici.
Je ne connaissais pas Zed, je vais regarder ca pour voir s’il y a un écart a combler en terme de fonctionnalités, mais je pense qu’on est déjà pas mal pratique :-)
Notre code est publie sous license ISC histoire de garantir que le format reste ouvert, je vais publier dans quelques jours une documentation du format pour permettre a quiconque d’écrire sa propre implementation.
Merci pour le partage et le commentaire :-)
[^] # Re: Lignes en conflit
Posté par Gilles Chehade (site web personnel) . En réponse au message Serveur Opensmtp. Évalué à 1.
Salut,
C'est tout à fait ça :-)
[^] # Re: « Simple à administrer »
Posté par Gilles Chehade (site web personnel) . En réponse au journal Architecture locale de réception, envoi et filtrage de courriel. Évalué à 7.
Du coup je pose ca la ? :-)
Mettre en place un serveur de mail avec OpenSMTPD, Dovecot et Rspamd
[^] # Re: OpenSMTPD
Posté par Gilles Chehade (site web personnel) . En réponse au message Recherche serveur mail. Évalué à 2. Dernière modification le 20 novembre 2019 à 13:28.
Je pense que c'est un bon choix.
Gilles (@opensmtpd.org 😁)
[^] # Re: Merci pour ce logiciel !
Posté par Gilles Chehade (site web personnel) . En réponse à la dépêche OpenSMTPD un an et quelques mois après.... É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 Gilles Chehade (site web personnel) . En réponse à la dépêche OpenSMTPD un an et quelques mois après.... É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: Filtres ?
Posté par Gilles Chehade (site web personnel) . En réponse à la dépêche OpenSMTPD un an et quelques mois après.... Évalué à 10.
Ca désigne surtout les 3 premiers points, le dernier étant plutôt délégué au MDA.
[^] # Re: relais ouvert ?
Posté par Gilles Chehade (site web personnel) . En réponse à la dépêche OpenSMTPD : Premiers Pas. Évalué à 10.
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:
et
pour obtenir un open-relay il faut explicitement le demander:
# Pour te consoler ...
Posté par Gilles Chehade (site web personnel) . En réponse au journal Être averti de ses emails intelligemment. Évalué à 1.
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 ;-)
[^] # Re: Plus simple que Postfix ?
Posté par Gilles Chehade (site web personnel) . En réponse à la dépêche OpenSMTPD 5.3 est de sortie !. É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 :-)
# Slides de la conférence AsiaBSDCon
Posté par Gilles Chehade (site web personnel) . En réponse à la dépêche OpenSMTPD 5.3 est de sortie !. Évalué à 5.
Eric Faurot à mis ses slides en ligne:
https://poolp.org/~eric/asiabsdcon2013-smtpd/
[^] # Re: Fonctionnalités avancées?
Posté par Gilles Chehade (site web personnel) . En réponse à la dépêche OpenSMTPD 5.3 est de sortie !. É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 Gilles Chehade (site web personnel) . En réponse à la dépêche OpenSMTPD 5.3 est de sortie !. É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: Plus simple que Postfix ?
Posté par Gilles Chehade (site web personnel) . En réponse à la dépêche OpenSMTPD 5.3 est de sortie !. É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 Gilles Chehade (site web personnel) . En réponse à la dépêche OpenSMTPD 5.3 est de sortie !. É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 Gilles Chehade (site web personnel) . En réponse à la dépêche OpenSMTPD 5.3 est de sortie !. É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: OpenSMTPD
Posté par Gilles Chehade (site web personnel) . En réponse au message Installer son propre serveur mail farfelu. Évalué à 0.
Y a pas de mal, et de rien ! :-)