Serveur Mail » Historique » Version 3
Version 2 (iku jam, 09/01/2012 16:22) → Version 3/11 (Laurent GUERBY, 09/01/2012 20:56)
h1. Serveur Mail
h2. [[Serveur Mail tetalab| proposition @tetalab]]
voici ce qui est en place pour le tetalab :
* basé sur courier-imap / postfix / postgrey / postgresql
* interface web pour gestion mailbox/alias/domaines - uniquement accessible via le vpn
* authentification centralisé dans la bdd pour imap & smtp
* antispam basique avec postgrey (délai de 10-15 minutes avant réception, si serveur distant est conforme RFC il renvoie le message)
* client webmail : "squirrelmail":https://tetalab.org/mail
solution mis en place sur différents serveurs (tetalab.org, ikujam.org, libre-services.fr), éprouvée
procédure de mise en place :
# ajout du domaine dans postfixadmin
# pointage MX vers tetalab.org
c'est tout ~
pour l'installation, il y a une bdd à mettre en place, faire pointer postfix & saslauthd sur celle-ci et installer les paquets listés dans [[Serveur Mail tetalab| proposition @tetalab]]
h2. Avis sur un MX redondant
<pre>
<guerby> Sp4rKy, tu gererai comment un MX haute dispo ? pas a haut traffic, juste pour gerer de maniere redondante les mbox de contact d'une asso
<guerby> (donc plusieurs MX sur plusieurs sites)
<Sp4rKy> guerby: version simple, un mta principal, les autres étant que des nullmailer qui gardent les mails infiniment
<Sp4rKy> ça suffit si tu es près à attendre que ton mta principal soit réparé en cas de casse
<guerby> Sp4rKy, ok je vois
<guerby> Sp4rKy, et le cas service continu ?
<Sp4rKy> ça implique d'avoir une synchro entre les différents noeuds
<guerby> Sp4rKy, yep
<guerby> le coeur du probleme :)
<Sp4rKy> j'ai jamais mis en place réellement (pour ce usecase), mais un truc style unison me semble à priori suffisant
<Sp4rKy> sachant que les MX sont priorisés dans les DNS, donc normalement pas de pb de "split brain"
<Sp4rKy> (tant que ton premier mx fonctionne lui seul sera utilisé)
<guerby> Sp4rKy, tu utiliserai quel format de mbox pour que unison marche bien ?
<Sp4rKy> maildir
<Sp4rKy> (chaque mail dans un fichier)
<guerby> Sp4rKy, ok, tu aurais une config nullmailer en distrib locale maildir sous la main ?
<Sp4rKy> nullmailer c'est juste un relais :)
<guerby> Sp4rKy, le unison c'est un cron ou un hook ?
<guerby> Sp4rKy, je suis une quiche en mail :)
<Sp4rKy> perso on le fait en cron
<Sp4rKy> (pas sur du mail par contre)
<guerby> Sp4rKy, l'alternative est je suppose drbd mais sur deux sites distants de 20ms de RTT je suppose que c'est pas forcement genial
<Sp4rKy> c'est faisable mais pas top
<Sp4rKy> et plus relou à gérer si ça remonte pas tout seul
<Sp4rKy> mais c'est faisable sur 20ms ;)
<guerby> Sp4rKy, je pensais un drbd juste pour pas perdre les mails, et la config nullmailer en secondaire
<guerby> Sp4rKy, en cas de crash tu reprends manuellement le FS drbd sur le secondaire
<Sp4rKy> c'est faisable aussi, pq avec un unison tu risqueras d'avoir une "latence" dans ta synchro
<guerby> Sp4rKy, oui unison en cron a une petite chance de perdre un mail
<guerby> Sp4rKy, ok en tous cas merci pour tes conseils, je paste la discussion dans notre wiki et on va jouer :)
<Sp4rKy> :)
<Sp4rKy> note quand meme que j'ai jamais mis ça en place (le nullmailer si, pas la synchro), donc y'a peut être de meilleures solutions que je connais pas
</pre>
h2. [[Serveur Mail tetalab| proposition @tetalab]]
voici ce qui est en place pour le tetalab :
* basé sur courier-imap / postfix / postgrey / postgresql
* interface web pour gestion mailbox/alias/domaines - uniquement accessible via le vpn
* authentification centralisé dans la bdd pour imap & smtp
* antispam basique avec postgrey (délai de 10-15 minutes avant réception, si serveur distant est conforme RFC il renvoie le message)
* client webmail : "squirrelmail":https://tetalab.org/mail
solution mis en place sur différents serveurs (tetalab.org, ikujam.org, libre-services.fr), éprouvée
procédure de mise en place :
# ajout du domaine dans postfixadmin
# pointage MX vers tetalab.org
c'est tout ~
pour l'installation, il y a une bdd à mettre en place, faire pointer postfix & saslauthd sur celle-ci et installer les paquets listés dans [[Serveur Mail tetalab| proposition @tetalab]]
h2. Avis sur un MX redondant
<pre>
<guerby> Sp4rKy, tu gererai comment un MX haute dispo ? pas a haut traffic, juste pour gerer de maniere redondante les mbox de contact d'une asso
<guerby> (donc plusieurs MX sur plusieurs sites)
<Sp4rKy> guerby: version simple, un mta principal, les autres étant que des nullmailer qui gardent les mails infiniment
<Sp4rKy> ça suffit si tu es près à attendre que ton mta principal soit réparé en cas de casse
<guerby> Sp4rKy, ok je vois
<guerby> Sp4rKy, et le cas service continu ?
<Sp4rKy> ça implique d'avoir une synchro entre les différents noeuds
<guerby> Sp4rKy, yep
<guerby> le coeur du probleme :)
<Sp4rKy> j'ai jamais mis en place réellement (pour ce usecase), mais un truc style unison me semble à priori suffisant
<Sp4rKy> sachant que les MX sont priorisés dans les DNS, donc normalement pas de pb de "split brain"
<Sp4rKy> (tant que ton premier mx fonctionne lui seul sera utilisé)
<guerby> Sp4rKy, tu utiliserai quel format de mbox pour que unison marche bien ?
<Sp4rKy> maildir
<Sp4rKy> (chaque mail dans un fichier)
<guerby> Sp4rKy, ok, tu aurais une config nullmailer en distrib locale maildir sous la main ?
<Sp4rKy> nullmailer c'est juste un relais :)
<guerby> Sp4rKy, le unison c'est un cron ou un hook ?
<guerby> Sp4rKy, je suis une quiche en mail :)
<Sp4rKy> perso on le fait en cron
<Sp4rKy> (pas sur du mail par contre)
<guerby> Sp4rKy, l'alternative est je suppose drbd mais sur deux sites distants de 20ms de RTT je suppose que c'est pas forcement genial
<Sp4rKy> c'est faisable mais pas top
<Sp4rKy> et plus relou à gérer si ça remonte pas tout seul
<Sp4rKy> mais c'est faisable sur 20ms ;)
<guerby> Sp4rKy, je pensais un drbd juste pour pas perdre les mails, et la config nullmailer en secondaire
<guerby> Sp4rKy, en cas de crash tu reprends manuellement le FS drbd sur le secondaire
<Sp4rKy> c'est faisable aussi, pq avec un unison tu risqueras d'avoir une "latence" dans ta synchro
<guerby> Sp4rKy, oui unison en cron a une petite chance de perdre un mail
<guerby> Sp4rKy, ok en tous cas merci pour tes conseils, je paste la discussion dans notre wiki et on va jouer :)
<Sp4rKy> :)
<Sp4rKy> note quand meme que j'ai jamais mis ça en place (le nullmailer si, pas la synchro), donc y'a peut être de meilleures solutions que je connais pas
</pre>