Re: [FRnOG] [TECH] postfix - archivage des queues pour rejeu en cas d'incident
Destinataire. Et également le destinataire lui-même, en outrepassant le quota juste pour ce message d’avertissement. Enfin bref, on s’écarte du sujet, mais je pense que la demande de Jacques est motivée par le fait que d’un point de vue sécurité, SMTP est un peu resté bloqué dans les années 90. > Le 13 juin 2017 à 09:14, Alarig Le Lay a écrit : > > On mar. 13 juin 08:04:30 2017, David Ponzone wrote: >> On aurait pu imaginer un système qui prévient à la fois l'utilisateur >> et postmaster quand un mail arrive pour la boîte de l'utilisateur déjà >> pleine. > > Le postmaster du domaine émetteur ou destinataire ? > Pour le domaine destinataire, postfix sait gérer ça de base. > > -- > alarig --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] postfix - archivage des queues pour rejeu en cas d'incident
On mar. 13 juin 08:04:30 2017, David Ponzone wrote: > On aurait pu imaginer un système qui prévient à la fois l'utilisateur > et postmaster quand un mail arrive pour la boîte de l'utilisateur déjà > pleine. Le postmaster du domaine émetteur ou destinataire ? Pour le domaine destinataire, postfix sait gérer ça de base. -- alarig signature.asc Description: PGP signature
Re: [FRnOG] [TECH] postfix - archivage des queues pour rejeu en cas d'incident
Vincent Bernat (bernat) writes: > > Pour ce qui est de stocker tous les mails, c'est possible en utilisant > "always_bcc" vers un utilisateur local. Les mails seront alors > disponibles au format mbox. Ou maildir, hein, histoire d'utiliser un format semi moderne. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] postfix - archivage des queues pour rejeu en cas d'incident
Arnaud, C'est vrai, j'ai été un peu vite. Déjà le 4xx n'est effectivement pas toujours respecté, mais surtout, si la personne est en congés pour 2 semaines avec une boite pleine...le problème du système actuel est que la ré-émission dépend de l'expéditeur, qui ne comprend souvent pas le mail de mailer-daemon. On aurait pu imaginer un système qui prévient à la fois l'utilisateur et postmaster quand un mail arrive pour la boîte de l'utilisateur déjà pleine. David Ponzone > Le 12 juin 2017 à 22:45, Arnaud Launay a écrit : > > Le Mon, Jun 12, 2017 at 10:19:28PM +0200, David Ponzone a écrit: >> On peut d’ailleurs se demander pourquoi SMTP n’inclut pas un >> mécanisme de retry pour le cas de la boite pleine, au moins. > > Heu... > > Chez moi une boîte pleine ça génère un 4xx, pas un 5xx, donc il y > a bien du retry... Si la société qui gère vos mails donne un 5xx > quand la boîte est pleine, il faut changer de prestataire. > >Arnaud. > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] postfix - archivage des queues pour rejeu en cas d'incident
❦ 12 juin 2017 16:40 GMT, DELMAS JACQUES : > En effet notre souhait est de pouvoir rejouer l'intégralité des emails > même ceux délivrés afin de pallier le manque de solidité d'une > infra. Aujourd'hui nous gardons les emails pendant 4 jours si le > serveur ne répond pas mais notre objectif est d'être capable de > rejouer les emails lorsque la boite destination a été pleine ou que le > serveur renvoyait un rejet de l'email (blacklist du serveur > d'émission, faux positif en spam ou en virus ou autre problème de ce > type). S'il s'agit de reessayer les mails qui ont eu un 5xx, il y a smtp_delivery_status_filter (ou simplement soft_bounce = yes). Le soucis avec cette méthode, c'est que l'expéditeur ne sera pas prévenu immédiatement d'un problème trivial (typo dans l'adresse email). Cependant, smtp_delivery_status_filter devrait être assez flexible pour ne gérer que les cas de blacklist/boîte pleine. Pour ce qui est de stocker tous les mails, c'est possible en utilisant "always_bcc" vers un utilisateur local. Les mails seront alors disponibles au format mbox. C'est un généralisation de recipient_bcc_maps. -- Make it clear before you make it faster. - The Elements of Programming Style (Kernighan & Plauger) --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] postfix - archivage des queues pour rejeu en cas d'incident
On lun. 12 juin 22:19:28 2017, David Ponzone wrote: > En 2017, on peut considérer qu’il est effarant qu’un destinataire ne > reçoit pas un mail parce que sa boite est pleine…. > Imagine la même chose avec le courier postal. Ben, quand la boîte est pleine, où veux-tu que le facteur mette le courrier ? Je suppose que dans ce cas, ils doivent le garder au centre de distribution ou un truc du genre. -- alarig signature.asc Description: PGP signature
Re: [FRnOG] [TECH] postfix - archivage des queues pour rejeu en cas d'incident
+1 Protocoles, et politiques de retry pour "proteger" contre problèmes éphémères (bon francais ? ) devrait bien suffire. (Le reste, la responsabilité de l'émetteur.) Cheers, mh 12 juin 2017, à 21:37, Raphael Mazelier a écrit: On 12/06/2017 18:40, DELMAS JACQUES wrote: Bonjour, En effet notre souhait est de pouvoir rejouer l'intégralité des emails même ceux délivrés afin de pallier le manque de solidité d'une infra. Aujourd'hui nous gardons les emails pendant 4 jours si le serveur ne répond pas mais notre objectif est d'être capable de rejouer les emails lorsque la boite destination a été pleine ou que le serveur renvoyait un rejet de l'email (blacklist du serveur d'émission, faux positif en spam ou en virus ou autre problème de ce type). Conserver les emais reçus je comprends, mais tenter de conserver les emails non délivrés c'est assez étrange. Pour les cas d'erreurs temporaires tu peux augmenter le temps de retries et sécuriser ton infra. Pour les erreurs définitives l'expéditeur doit recevoir un bounce. De toutes manières il doit avoir son mail dans sa boite "Sent" ? Certains emails ne peuvent pas ou ne doivent pas être perdus ... Mauvais usage des mails à mon humble avis, et/ou mauvaises éducations des utilisateurs. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/ Le 12 juin 2017 à 21:37, à 21:37, Raphael Mazelier a écrit: > > >On 12/06/2017 18:40, DELMAS JACQUES wrote: >> Bonjour, >> >> En effet notre souhait est de pouvoir rejouer l'intégralité des >emails même ceux délivrés afin de pallier le manque de solidité d'une >infra. Aujourd'hui nous gardons les emails pendant 4 jours si le >serveur ne répond pas mais notre objectif est d'être capable de rejouer >les emails lorsque la boite destination a été pleine ou que le serveur >renvoyait un rejet de l'email (blacklist du serveur d'émission, faux >positif en spam ou en virus ou autre problème de ce type). >> > >Conserver les emais reçus je comprends, mais tenter de conserver les >emails non délivrés c'est assez étrange. > >Pour les cas d'erreurs temporaires tu peux augmenter le temps de >retries >et sécuriser ton infra. Pour les erreurs définitives l'expéditeur doit >recevoir un bounce. >De toutes manières il doit avoir son mail dans sa boite "Sent" ? > >> Certains emails ne peuvent pas ou ne doivent pas être perdus ... >> > >Mauvais usage des mails à mon humble avis, et/ou mauvaises éducations >des utilisateurs. > >-- >Raphael Mazelier > > >--- >Liste de diffusion du FRnOG >http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] postfix - archivage des queues pour rejeu en cas d'incident
Le Mon, Jun 12, 2017 at 10:19:28PM +0200, David Ponzone a écrit: > On peut d’ailleurs se demander pourquoi SMTP n’inclut pas un > mécanisme de retry pour le cas de la boite pleine, au moins. Heu... Chez moi une boîte pleine ça génère un 4xx, pas un 5xx, donc il y a bien du retry... Si la société qui gère vos mails donne un 5xx quand la boîte est pleine, il faut changer de prestataire. Arnaud. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] postfix - archivage des queues pour rejeu en cas d'incident
Je peux comprendre la philosophie. En 2017, on peut considérer qu’il est effarant qu’un destinataire ne reçoit pas un mail parce que sa boite est pleine…. Imagine la même chose avec le courier postal. On peut d’ailleurs se demander pourquoi SMTP n’inclut pas un mécanisme de retry pour le cas de la boite pleine, au moins. > Le 12 juin 2017 à 21:35, Raphael Mazelier a écrit : > > > > On 12/06/2017 18:40, DELMAS JACQUES wrote: >> Bonjour, >> >> En effet notre souhait est de pouvoir rejouer l'intégralité des emails même >> ceux délivrés afin de pallier le manque de solidité d'une infra. Aujourd'hui >> nous gardons les emails pendant 4 jours si le serveur ne répond pas mais >> notre objectif est d'être capable de rejouer les emails lorsque la boite >> destination a été pleine ou que le serveur renvoyait un rejet de l'email >> (blacklist du serveur d'émission, faux positif en spam ou en virus ou autre >> problème de ce type). >> > > Conserver les emais reçus je comprends, mais tenter de conserver les emails > non délivrés c'est assez étrange. > > Pour les cas d'erreurs temporaires tu peux augmenter le temps de retries et > sécuriser ton infra. Pour les erreurs définitives l'expéditeur doit recevoir > un bounce. > De toutes manières il doit avoir son mail dans sa boite "Sent" ? > >> Certains emails ne peuvent pas ou ne doivent pas être perdus ... >> > > Mauvais usage des mails à mon humble avis, et/ou mauvaises éducations des > utilisateurs. > > -- > Raphael Mazelier > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] postfix - archivage des queues pour rejeu en cas d'incident
On 12/06/2017 18:40, DELMAS JACQUES wrote: Bonjour, En effet notre souhait est de pouvoir rejouer l'intégralité des emails même ceux délivrés afin de pallier le manque de solidité d'une infra. Aujourd'hui nous gardons les emails pendant 4 jours si le serveur ne répond pas mais notre objectif est d'être capable de rejouer les emails lorsque la boite destination a été pleine ou que le serveur renvoyait un rejet de l'email (blacklist du serveur d'émission, faux positif en spam ou en virus ou autre problème de ce type). Conserver les emais reçus je comprends, mais tenter de conserver les emails non délivrés c'est assez étrange. Pour les cas d'erreurs temporaires tu peux augmenter le temps de retries et sécuriser ton infra. Pour les erreurs définitives l'expéditeur doit recevoir un bounce. De toutes manières il doit avoir son mail dans sa boite "Sent" ? Certains emails ne peuvent pas ou ne doivent pas être perdus ... Mauvais usage des mails à mon humble avis, et/ou mauvaises éducations des utilisateurs. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] postfix - archivage des queues pour rejeu en cas d'incident
Bonjour, En effet notre souhait est de pouvoir rejouer l'intégralité des emails même ceux délivrés afin de pallier le manque de solidité d'une infra. Aujourd'hui nous gardons les emails pendant 4 jours si le serveur ne répond pas mais notre objectif est d'être capable de rejouer les emails lorsque la boite destination a été pleine ou que le serveur renvoyait un rejet de l'email (blacklist du serveur d'émission, faux positif en spam ou en virus ou autre problème de ce type). Certains emails ne peuvent pas ou ne doivent pas être perdus ... Cordialement J.Delmas -Message d'origine- De : David Ponzone [mailto:david.ponz...@gmail.com] Envoyé : lundi 12 juin 2017 16:30 À : François Ranchin Cc : DELMAS JACQUES; frnog-t...@frnog.org Objet : Re: [FRnOG] [TECH] postfix - archivage des queues pour rejeu en cas d'incident A mon avis, Jacques devait avoir une idée précise derrière la tête, ou avoir un client avec un besoin particulier. Jacques, tu peux en dire plus ? > Le 12 juin 2017 à 16:15, Francois Ranchin a écrit : > > Salut David > > On 12 Jun 2017, at 4:19, David Ponzone wrote: > >> François, >> >> Ça fait un baille :) >> >> Dans la demande d'origine de Jacques, j'ai personnellement compris qu'il >> voulait être capable de rejouer tous les mails, même ceux correctement >> délivrés. >> Dans ton idée, ne subsiste-t-il pas un problème car entre la fin d'un find >> et le suivant (donc intervalle d'exécution+durée d'exécution en gros), il y >> a des mails qui vont arriver en queue et qui pourraient être perdus en cas >> de problème sur la machine. >> > > > Oui tout à fait. Bah comme il a des disques sécurisés si sa CM crame c'est > pas génant :) Apres c'est plus un pb d'archi ou d'infra générale de solidité > de ses serveurs que de rejouage. > > > Bisou > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ smime.p7s Description: S/MIME cryptographic signature
Re: [FRnOG] [TECH] postfix - archivage des queues pour rejeu en cas d'incident
Le 08/06/2017 à 07:51, DELMAS JACQUES a écrit : Bonjour à tous, Je souhaiterai mettre en place sur mes frontaux postfix un système de sauvegarde des emails afin d'être capable de rejouer certains mails sur quelques jours. Il existe une option alway_bcc mais cette option duplique le mail vers une autre boite ce qui n'est pas exactement mon objectif (rendant le rejeu laborieux) Si quelqu'un a une idée voir même une solution je suis plus que preneur. Merci Bonjour, avant de vous proposer une solution quelques hypothèses et questions : - volume à traiter : inconnu mais vous parlez de frontaux, pouvons-nous en déduire que la volumétrie est conséquente ? - les dd des frontaux sont physiquement sur le frontal ? ça m'arrange de dire oui ;-) - stockage des copies : sur le même serveur ? déportes ? la place disque n'est pas un problème de toute manière à partir du moment où on veut dupliquer. - délai entre la prise de décision qu'il faut rejouer et l'action ? - est-ce que ce système est permanent ? Je vais supposer que oui. La solution que je donne est théorique et je ne suis pas rentré dans les détails, forcement sales : c'est plus une piste, en sachant, circonstance aggravante, que je connais peu postfix mais bon "All programmers are optimists -- Frederick P. Brooks, Jr." ;-) J'interviendrais au moment de la création du message dans la queue en créant un patch dans postfix (qui pourrait s'intégrer dans le produit car si vous avez ce problème il y a des chances que vous ne soyez pas seul) : ce patch comporte l'utilisation de link(2) au moment de la création des fichiers liées au message dans la queue et le tour est joué. Si vous créez le lien dans la même partition le côut est de presque zéro à la création et est déporté au moment où le message est traité pour être envoyé dans la boite (qui est sûrement ailleurs : autre serveur, autre partition) Bon effectivement il faut tester le retour de link, indiquer en paramètre le répertoire de copie, prévoir l'option qui va bien au lancement de postfix, etc etc ... mais je trouve la solution assez simple à mettre en œuvre et relativement peu couteuse en développement et en consommation de ressources en exploitation. Mais vous disposez donc d'une copie parfaite de votre répertoire de spool que vous purgez ou déportez par la suite à votre convenance. Vous voulez re-injecter ? Rien de plus simple : MonShellQueJaime # cd spoolbis MonShellQueJaime # ln ListeQuiVaBien spool # comme ça on garde les copies originales au cas où. Avec une échelle de bêtise allant de 0 à 10 vous me donnez combien ? (0 = terriblement stupide, demeuré, 10 = why not ?) Emilio JD --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] postfix - archivage des queues pour rejeu en cas d'incident
A mon avis, Jacques devait avoir une idée précise derrière la tête, ou avoir un client avec un besoin particulier. Jacques, tu peux en dire plus ? > Le 12 juin 2017 à 16:15, Francois Ranchin a écrit : > > Salut David > > On 12 Jun 2017, at 4:19, David Ponzone wrote: > >> François, >> >> Ça fait un baille :) >> >> Dans la demande d'origine de Jacques, j'ai personnellement compris qu'il >> voulait être capable de rejouer tous les mails, même ceux correctement >> délivrés. >> Dans ton idée, ne subsiste-t-il pas un problème car entre la fin d'un find >> et le suivant (donc intervalle d'exécution+durée d'exécution en gros), il y >> a des mails qui vont arriver en queue et qui pourraient être perdus en cas >> de problème sur la machine. >> > > > Oui tout à fait. Bah comme il a des disques sécurisés si sa CM crame c'est > pas génant :) Apres c'est plus un pb d'archi ou d'infra générale de solidité > de ses serveurs que de rejouage. > > > Bisou > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] postfix - archivage des queues pour rejeu en cas d'incident
Salut David On 12 Jun 2017, at 4:19, David Ponzone wrote: François, Ça fait un baille :) Dans la demande d'origine de Jacques, j'ai personnellement compris qu'il voulait être capable de rejouer tous les mails, même ceux correctement délivrés. Dans ton idée, ne subsiste-t-il pas un problème car entre la fin d'un find et le suivant (donc intervalle d'exécution+durée d'exécution en gros), il y a des mails qui vont arriver en queue et qui pourraient être perdus en cas de problème sur la machine. Oui tout à fait. Bah comme il a des disques sécurisés si sa CM crame c'est pas génant :) Apres c'est plus un pb d'archi ou d'infra générale de solidité de ses serveurs que de rejouage. Bisou --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] postfix - archivage des queues pour rejeu en cas d'incident
François, Ça fait un baille :) Dans la demande d'origine de Jacques, j'ai personnellement compris qu'il voulait être capable de rejouer tous les mails, même ceux correctement délivrés. Dans ton idée, ne subsiste-t-il pas un problème car entre la fin d'un find et le suivant (donc intervalle d'exécution+durée d'exécution en gros), il y a des mails qui vont arriver en queue et qui pourraient être perdus en cas de problème sur la machine. David Ponzone > Le 11 juin 2017 à 18:00, Francois Ranchin a écrit : > > Bonjour, > > Et si on procédait autrement ? > 1 - les mails partent normalement de la file d'attente. Il reste "les > problèmes" > 2 - on déplace ces reliquats avec un find qui teste leur âge. Age à votre > convenance. Par exemple 6 heures. > 3 - on a un postqueue ou équivalent qui traite les reliquats avec une > fréquence différente. Par exemple toutes les 4 heures pendant 48H. > 4 - éventuellement encore un autre étage ralentisseur pour traiter les > reliquats de reliquats, avec une nouvelle file d'attente. Traitée cette fois > 1x par jour pendant 5 jours... > > Du coup vous avez une seule copie des mails, que vous déplacez dans des files > d'attente de moins en moins joueuses. Et autant de postqueue que vous avez > envie avec un nbre de tentative auto à votre convenance. Et si jamais le > client vous appelle vous avez toujours la possibilité de rejouer la musique à > la main, sans perturber la mécanique. > > Vous pouvez passer un répertoire de config à postqueue. Histoire de pas > bouncer les mails trop rapido etc. > > Bisou. > >> On 9 Jun 2017, at 8:34, DELMAS JACQUES wrote: >> >> Bonjour, >> >> Merci pour vos réponses cette liste est vraiment épatante ! >> >> Par rejouer j'envisage en effet la possibilité de réinjecter dans la queue >> certains mails (par exemple une boite mail pleine sur laquelle les mails >> n'ont pas été délivrés ou encore un serveur qui crash, la possibilité de >> réinjecter les mails reçus depuis le dernier backup). >> >> >> > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] postfix - archivage des queues pour rejeu en cas d'incident
Version alternative de la proposition d'Alarig afin d'éviter un cron toutes les secondes: lsyncd pour synchroniser automatiquement par rsync (grâce à inotify) les fichiers créés dans la queue avec bien sûr l'option delete=false pour ne jamais supprimer les fichiers sur la cible. David Ponzone > Le 8 juin 2017 à 09:25, Alarig Le Lay a écrit : > >> On jeu. 8 juin 05:51:11 2017, DELMAS JACQUES wrote: >> Bonjour à tous, >> >> >> >> Je souhaiterai mettre en place sur mes frontaux postfix un système de >> sauvegarde des emails afin d'être capable de rejouer certains mails >> sur quelques jours. >> >> >> >> Il existe une option alway_bcc mais cette option duplique le mail vers >> une autre boite ce qui n'est pas exactement mon objectif (rendant le >> rejeu laborieux) >> >> >> >> Si quelqu'un a une idée voir même une solution je suis plus que preneur. >> >> >> >> Merci >> >> >> >> JD > > Salut, > > rsync -aHAX /var/spool/postfix/ ${ailleurs} ? > > -- > alarig --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] postfix - archivage des queues pour rejeu en cas d'incident
Bonjour, Et si on procédait autrement ? 1 - les mails partent normalement de la file d'attente. Il reste "les problèmes" 2 - on déplace ces reliquats avec un find qui teste leur âge. Age à votre convenance. Par exemple 6 heures. 3 - on a un postqueue ou équivalent qui traite les reliquats avec une fréquence différente. Par exemple toutes les 4 heures pendant 48H. 4 - éventuellement encore un autre étage ralentisseur pour traiter les reliquats de reliquats, avec une nouvelle file d'attente. Traitée cette fois 1x par jour pendant 5 jours... Du coup vous avez une seule copie des mails, que vous déplacez dans des files d'attente de moins en moins joueuses. Et autant de postqueue que vous avez envie avec un nbre de tentative auto à votre convenance. Et si jamais le client vous appelle vous avez toujours la possibilité de rejouer la musique à la main, sans perturber la mécanique. Vous pouvez passer un répertoire de config à postqueue. Histoire de pas bouncer les mails trop rapido etc. Bisou. On 9 Jun 2017, at 8:34, DELMAS JACQUES wrote: Bonjour, Merci pour vos réponses cette liste est vraiment épatante ! Par rejouer j'envisage en effet la possibilité de réinjecter dans la queue certains mails (par exemple une boite mail pleine sur laquelle les mails n'ont pas été délivrés ou encore un serveur qui crash, la possibilité de réinjecter les mails reçus depuis le dernier backup). --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] postfix - archivage des queues pour rejeu en cas d'incident
Hello! Dans ce cas, le "mailid" devrait rester conforme a la source je suppose? A ta place je forkerai un petit bash en frontal avant le "transport" (inqueue) qui ferait un petit "postcat" des familles en out vers un /stockage/mes_mails_a_rejouer/ sans oublier une purge pour pas exploser la volumétrie Ca a l'avantage de purement et simplement copier ta queue avant traitement des éventuels milter et donc de pouvoir être totalement rejouée L'inconvénient est le fork externe qui peut donc bouffer pas mal de ressources... Envoyé de mon iPhone > Le 9 juin 2017 à 08:34, DELMAS JACQUES a écrit > : > > Bonjour, > > Merci pour vos réponses cette liste est vraiment épatante ! > > Par rejouer j'envisage en effet la possibilité de réinjecter dans la queue > certains mails (par exemple une boite mail pleine sur laquelle les mails > n'ont pas été délivrés ou encore un serveur qui crash, la possibilité de > réinjecter les mails reçus depuis le dernier backup). > > > > Cordialement > > J.D > > -Message d'origine- > De : Phil Regnauld [mailto:regna...@x0.dk] > Envoyé : jeudi 8 juin 2017 09:37 > À : DELMAS JACQUES > Cc : frnog-t...@frnog.org > Objet : Re: [FRnOG] [TECH] postfix - archivage des queues pour rejeu en cas > d'incident > > DELMAS JACQUES (jacques.delmas) writes: >> >> Je souhaiterai mettre en place sur mes frontaux postfix un système de >> sauvegarde des emails afin d'être capable de rejouer certains mails sur >> quelques jours. > >Salut, > >Définir "rejouer" ? Réinjecter dans la queue des mails ? > >> Il existe une option alway_bcc mais cette option duplique le mail vers une >> autre boite ce qui n'est pas exactement mon objectif (rendant le rejeu >> laborieux) > >Avec formail (qui fait partie de procmail) et un always_bcc vers >un Maildir, c'est assez trivial d'archiver et expirer automatiquement >(find . -type f -mtime +7d -delete, par exemple). > >> Si quelqu'un a une idée voir même une solution je suis plus que preneur. > >Comme décrit ci-dessous, sinon un quelconque filtre milter devrait >faire l'affaire (ou un content_filter à la amavisd avec deux smtpd >(un pre-filter, un post-filter, mais c'est plus de boulot et IO/2) > >http://www.findbestopensource.com/product/milter-archiver > >"Rejouer" est le mot clé. > >P. > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] postfix - archivage des queues pour rejeu en cas d'incident
Bonjour, Merci pour vos réponses cette liste est vraiment épatante ! Par rejouer j'envisage en effet la possibilité de réinjecter dans la queue certains mails (par exemple une boite mail pleine sur laquelle les mails n'ont pas été délivrés ou encore un serveur qui crash, la possibilité de réinjecter les mails reçus depuis le dernier backup). Cordialement J.D -Message d'origine- De : Phil Regnauld [mailto:regna...@x0.dk] Envoyé : jeudi 8 juin 2017 09:37 À : DELMAS JACQUES Cc : frnog-t...@frnog.org Objet : Re: [FRnOG] [TECH] postfix - archivage des queues pour rejeu en cas d'incident DELMAS JACQUES (jacques.delmas) writes: > > Je souhaiterai mettre en place sur mes frontaux postfix un système de > sauvegarde des emails afin d'être capable de rejouer certains mails sur > quelques jours. Salut, Définir "rejouer" ? Réinjecter dans la queue des mails ? > Il existe une option alway_bcc mais cette option duplique le mail vers une > autre boite ce qui n'est pas exactement mon objectif (rendant le rejeu > laborieux) Avec formail (qui fait partie de procmail) et un always_bcc vers un Maildir, c'est assez trivial d'archiver et expirer automatiquement (find . -type f -mtime +7d -delete, par exemple). > Si quelqu'un a une idée voir même une solution je suis plus que preneur. Comme décrit ci-dessous, sinon un quelconque filtre milter devrait faire l'affaire (ou un content_filter à la amavisd avec deux smtpd (un pre-filter, un post-filter, mais c'est plus de boulot et IO/2) http://www.findbestopensource.com/product/milter-archiver "Rejouer" est le mot clé. P. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] postfix - archivage des queues pour rejeu en cas d'incident
DELMAS JACQUES (jacques.delmas) writes: > > Je souhaiterai mettre en place sur mes frontaux postfix un système de > sauvegarde des emails afin d'être capable de rejouer certains mails sur > quelques jours. Salut, Définir "rejouer" ? Réinjecter dans la queue des mails ? > Il existe une option alway_bcc mais cette option duplique le mail vers une > autre boite ce qui n'est pas exactement mon objectif (rendant le rejeu > laborieux) Avec formail (qui fait partie de procmail) et un always_bcc vers un Maildir, c'est assez trivial d'archiver et expirer automatiquement (find . -type f -mtime +7d -delete, par exemple). > Si quelqu'un a une idée voir même une solution je suis plus que preneur. Comme décrit ci-dessous, sinon un quelconque filtre milter devrait faire l'affaire (ou un content_filter à la amavisd avec deux smtpd (un pre-filter, un post-filter, mais c'est plus de boulot et IO/2) http://www.findbestopensource.com/product/milter-archiver "Rejouer" est le mot clé. P. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] postfix - archivage des queues pour rejeu en cas d'incident
On jeu. 8 juin 05:51:11 2017, DELMAS JACQUES wrote: > Bonjour à tous, > > > > Je souhaiterai mettre en place sur mes frontaux postfix un système de > sauvegarde des emails afin d'être capable de rejouer certains mails > sur quelques jours. > > > > Il existe une option alway_bcc mais cette option duplique le mail vers > une autre boite ce qui n'est pas exactement mon objectif (rendant le > rejeu laborieux) > > > > Si quelqu'un a une idée voir même une solution je suis plus que preneur. > > > > Merci > > > > JD Salut, rsync -aHAX /var/spool/postfix/ ${ailleurs} ? -- alarig signature.asc Description: PGP signature
[FRnOG] [TECH] postfix - archivage des queues pour rejeu en cas d'incident
Bonjour à tous, Je souhaiterai mettre en place sur mes frontaux postfix un système de sauvegarde des emails afin d'être capable de rejouer certains mails sur quelques jours. Il existe une option alway_bcc mais cette option duplique le mail vers une autre boite ce qui n'est pas exactement mon objectif (rendant le rejeu laborieux) Si quelqu'un a une idée voir même une solution je suis plus que preneur. Merci JD --- Liste de diffusion du FRnOG http://www.frnog.org/