Reprise du message précédent :

bah si pour passer le /var/spool/mail/user vers le /usr/local/virtual/domaine/user@domaine/Maildir .
par contre pour les 'dossiers' au format mbox présent dans le /home/user j'y suis allé a la mano vu qu'ils avaient des noms exotiques o.O
 

en meme temps la configuration de courier-pop
apres si tu utilises du virtual , procmail ne sera pas le mda approprié a mon avis , il vaut mieux te tourner vers maildrop .

bah moi tous les mails sont dans /var/spool/mail/user
en maildir ils iront donc dans /home/user/maildir
 
 
je veux bien que tu m en dises plus sur le "pb" de procmail
pourquoi il n irait pas bien ??
c est ce qu on utilise hein

*si* tu passes tes users en virtuel il faut t'assurer que procmail puisse savoir ou aller déposer les mails donc connaitre le '$HOME' (maildir quoi ) de l'user en question . et a l'heure actuelle (a moins de surement gruiker comme un goret de chez goret ) procmail ne sait pas s'interfacer avec du mysql/ldap/postgrsql etc etc ) , virtual de postfix sait le faire de meme que maildrop .
après se pose deux problèmes :
1) la gestion des quotas virtuels , sur une Maildir (meme avec des users systeme d'ailleurs je crois mais a vérifier ) le virtual de postfix ne sait pas (encore )  le faire donc c'est du ressort du mda , et comme procmail lui ne sait pas le faire (& de toute maniere ne fonctionne pas en virtuel ) il ne te reste que maildrop .
 
2) le problème avec maildrop c'est qu'il ne sait pas créer la Maildir donc forcément il faut conf le maildroprc pour vérifier l'existence de dossiers quand tu veux créer un dossier avec de surcroit le fait que ne sachant pas créer la Maildir initiale ( les sous dossiers ne sont que des Maildir a l'intérieur ) se sera a toi de le faire .
 
 
 
 

en fait seuls les domaines sont virtuels, les users sont systemes, donc ils ont tous un /home/user
 
donc le pb ne se pose pas pour procmail (qui est utilisé a l heure actuelle)

pour les quotas, ce sont des quotas systeme

dans le cas d'un quota systeme , je pense (enfin a tester ) que les mails resteront simplement dans la mailq de postfix  et ne seront pas refusés tout simplement , et tu auras une mailq sans fin

nan ils arrivent bien dans le fichier mbox
 
sauf que la personne ne peut pas consulter son compte (a cause du .pop)

il faut lire la bible pardi , donc le readme de  ETRN dans le cas présent la rfc correspondante étant la  1985 il me semble
 

c'est fait de maniere automatique sauf configuration express des MX pour etre les MX finaux .
bref il suffit que le domaine soit dans le relay_domains soit correctement configuré et qu'évidemment le domaine en question  ne fasse pas partie de mydestination, ou de virtual_mailbox_domains notamment .
Bref dans le cas ou le SMTP en question ne voit pas le domaine dans l'une de ces variables plus haut , il va tenter de le remettre au MX ayant un poids MX inférieur .
le ETRN permet lui d'accéreler cette remise , forcant la décongestion de domaine précis .

 
A mon avis , le serveur POP doit avoir un p'tit smtpd qui tourne et qui n'accepte des mails que depuis les IPs des MX , et de meme pour les MX qui doivent relayer directement au serveur POP/IMAP .  
Donc les MX font office de ramparre/firewall .
 
A mon sens , cette disposition est la plus simple a faire .

ce doit etre le troll du vendredi

C'est pourtant simple , t'as un serveur smtp avec pop3/imap , pour plus de redondance et de secu. tu veux mettre en place des MX secondaires , le plus simples , c'est de mettre des serveurs SMTP devant le serveur pop/imap+SMTP , et faire relayer les mails vers ce dernier .  
 
Donc si un MX tombe , les mails continue a aller vers le serveur pop .

mettre d'autre smtp 'devant' celui ci ? et si il tombe ?
ce qu'il faut ce sont deux smtp qui déposent les mails sur une archi nfs par exemple . le serveur pop/imap servant les données a partir de cette archi nfs .
apres tu peux augmenter le nombre de serveurs devant , mais le coup de plusieurs smtp qui envoient les mails a _un_ serveur smtp donné , c'est plutôt bof si le dit serveur se casse la gueule .

ben j'ai pas dis le contraire , le principe est la , les MX ne stockent pas les mails mais les relay vers une archi NFS si tu veux . Parce si un MX venait a tomber , tous les mails qu'il contenait seraient indisponible .
 
Il faut a un moment que tout les mails soient centralisé quelque part ,sinon il y auras une c.....e . Ensuite tu creer autant de serveurs redondant que tu veux .

chouette jeune femme ?    
bon tennis time  

ceci dit c'est vrai que mon explication est peut etre un peu confuse
on va la refaire le temps que paulmuadib soit pret pour le tennis    

• d'abord le fonctionnement des MX

un MX secondaire est un smtp qui accepte de relayer les mails pour un domaine dont il n'est pas le maître ,c'est a dire un domaine qui ne se trouve ni au niveau de mydestination ou/et de  virtual_mailbox_domains .
il accepte de relayer le domaine si et seulement si le domaine se trouve spécifié au niveau de relay_domains .
Si par hasard un domaine se trouve au niveau de  relay_domainset de mydestination , c'est le mydestination qui a priorité , meme chose dans le cas de virtual_mailbox_domains . (entre virtual_mailbox_domains et  mydestination c'est mydestination qui est prioritaire
Bien ceci étant posé en admettant que le MX de poids le plus faible soit down , le comportement normal d'un smtp est d'envoyer vers le mx ayant le poids plus élévé qui suit ( bon les spammeurs lors de leur attaque au dictionnaire envoie souvent les mails vers le MX ayant un poids plus élévé que le premier ( souvent le plus élevé de la chaine d'ailleurs   ) car le MX relay n'a forcément pas la liste des récipients valides .
Une fois ce mail arrivé sur le MX relay , celui ci va tenter régulierement d'envoyer le mail vers le MX final ,où vers le MX de poids plus élevé que le MX final _a condition_ que le poids du MX visé est un poids inférieur au sien .(on peut bien sur modifier ce comportement par l'utilisation de la table transport .
Bref au final le MX relay finira bien par envoyer le mail au MX final , mais forcément il ne le fait pas de maniere 'idéale' , c'est a dire qu'il envoie les mails dans l'ordre ou ils sont dans sa mailq pour faire simple , c'est ici qu'intervient  ETRN .

• ETRN

c'est un protocole qui permet de demander a un MX relay de vider sa queue de mails pour un domaine précis . ainsi au lieu d'attendre que le mx envoie les mails l'un a pres l'autre , il vide sa queue de 'tous' les mails corresponds au domaine voulu .
ce qui est utile pour les MX situés sur des connexions en bois .
(bon paulmuadib est pres donc j'ai accéléré sur la fin )

hum là c'est moi qui t'attends mikala !!!
 
shalope (tm)

Tu passe le quota à 24mo et voila  

bon recentrons le topic sur mon pb

 
C'est souvent des petites erreurs comme ca qui te rendent fou

 
Oula oula !
 
Les MX c'est pour le SMTP pour les réceptions de mails, y'a pas de rapport avec le POP !
 
Ton problème semble plutôt être : comment les SMTP font pour synchroniser leurs réceptions sur un même endroit non ?

oui mais comme te le rappele sly, MX != POP !!
 
MX = SMTP

bah on dirait pas

en meme temps tu penses encore que procmail sert a déposer les mails dans le cadre d'users dans une base mysql alors qu'on te la répeter au moins 5-6 fois je veux pas dire mais  

ah vraiment ??
je vois pas marqué ca dans mon topic

et chez moi la base mysql ne sert qu a l authentification

http://forum.hardware.fr/hardwaref [...] tm#t532620

tu disais ?

oui d ou la question et non l affirmation ...

sauf que http://forum.hardware.fr/hardwaref [...] tm#t530858
bref je t'avais répondu a ceci bien avant que tu ne reposes la question

sauf qu on parle pas du meme pb en fait

   
tu demandes si pour un user virtuel on peut mettre un procmailrc .
moi je te dis qu'on ne peut pas utiliser procmail pour des users virtuels et on ne parle pas de la meme chose ?
on parle de quoi en fait ?

je croyais que tu parlais pour des comptes mysql
 
les users au taf sont tous systemes, leurs domaines sont virtuels

ok .

donc c est le bordel