quelqu'un saurait il me dire comment je peux utiliser un cyrus imap en tant que proxy pour un autre cyrus imap. Le premier serait alors chargé d'établir des sessions en imapS.
Ta problématique m'étonne ... à quoi bon utiliser un Cyrus en proxy d'un autre ? Si il s'agit juste de SSLiser un service, stunnel y parvient à merveille.
Et d'ailleurs, AMHA, ce n'est pas le rôle de Cyrus que d'implémenter ce genre de fonctionnalités...
Derrière ça, je me souviens avoir répondu il y a peu à un de tes questions qui était assez "bateau" au sujet de Cyrus, je présume que ta lecture de la doc n'a pas été particulièrement assidue (si toutefois il y a eu lecture de doc).
Donc, ma réponse serait:
1/ Apprend à formuler tes questions ( c'est quoi ta version de Cyrus ? sur quelle distribution ? Quelle est ta problématique complète ? ...).
2/ Lis la doc.
Désolé pour cette réponse très peu cordiale, mais à mes yeux, la plus grande qualité d'un administrateur système est de savoir ce documenter par lui même. Si t'es pas en mesure de le faire, alors laisse l'administration du Cyrus a quelqu'un d'autre (surtout que ce dernier n'est pas réputé poru être "facile").
Il s'agit d'un problème dans le cadre d'un projet. Initialement, Courrier imap devait être utilis et apporte la fonctionnalité de proxy IMAP. Malheureusement, ce dernier n'est pas supporté pr RedHat (9).
L'architecture au niveau de tous les types de flux qui doivent circuler est à chaque fois à plusieurs niveaux, aussi bien pour les flux en eux même (pop, smtp, http, ...) et le premier niveau ne réalise que la partie SSL (ici IMAPS). Le second niveau réalise d'autrs opérations.
La communication entre le niveau 1 et 2 n'est plus en SSL après passage par pluseiurs pare-feux.
Au niveau de la documentation, si celle de Courrier est correcte, celle de Cyrus est quasi nulle (d'où le problème d'ailleurs de "facilité" mais je suis prêt à lire n'importe quelle doc plus complète.
L'utilisation de stunnel n'est pas possible dans ce cadre, sinon tous les flux auraient pu en bénéficier.
Ma question aurjourd'hui est donc de savoir si c'est possible, et dans le cas contraire nous nous tournerons vers Courrier, ce qui pose le problème du support.
RedHat 9 est encore supportée ? Incroyable !
La documentation de cyrus est on ne peut plus correcte.
Je ne comprend pas non plus ta problématique, tu restes encore une fois un peu trop évasif sur le contexte lui-même.
Qui a besoin du service IMAPS, qui a besoin du service IMAP (et pourquoi tout le monde n'utiliserait pas IMAPS ?) ?
Quel besoin y a-t-il d'interrompre ainsi de façon unilatérale les communications en SSL ?
Quant au problème de support, mauvais prestataire, changer prestataire.
Oops, erreur sur la version de redhat, c'est pas 9 mais enterprise 4 mais cela ne change rien au problème.
J'ai effectivement trouvé ces docs. J'ai plus l'impression que murder est utilisé pour récupérer les messages sur différents serveurs, mais pas en imap. Effectivement, ça se rapporche mais ce n'est pas exactement ça.
En fait mon post était surtout pour voir si quelqu'un l'avait déjà fait et me fournir un piste que je puisse fournir aux personnes chargées des installations / configurations.
Pour répondre à une autre question, on pourrait effectivement garder du Imaps sur tout la chaîne, ce qui 1) n'aurait pas d'intérêt puisqi'on considère que passé la première sécurité imaps n'est plus nécessaire
et 2) ceci ne résoudrait pas mon problème de proxyfication
Ah, parce qu'en plus, tu n'es qu'un intermédiaire...
Je comprends mieux pourquoi le contexte original est si confus.
Sérieusement, j'ai du mal à comprendre quel est le besoin d'avoir un tel service IMAP qui soit, depuis un niveau, en IMAPS puis, depuis un autre, en IMAPS...
Si c'était pour archiver les mails ou pouvoir à tout moment en contrôler le contenu (deux actions qui sont soumises à la loi, attention à ce qu'on fait), normalement, on peut déjà réaliser toute cette chaîne au niveau de SMTP. Je ne comprends donc vraiment pas l'intérêt...
C'est peut-être votre "architecture" qu'il faudrait revoir.
# re
Posté par LaBienPensanceMaTuer . Évalué à 3.
Et d'ailleurs, AMHA, ce n'est pas le rôle de Cyrus que d'implémenter ce genre de fonctionnalités...
Derrière ça, je me souviens avoir répondu il y a peu à un de tes questions qui était assez "bateau" au sujet de Cyrus, je présume que ta lecture de la doc n'a pas été particulièrement assidue (si toutefois il y a eu lecture de doc).
Donc, ma réponse serait:
1/ Apprend à formuler tes questions ( c'est quoi ta version de Cyrus ? sur quelle distribution ? Quelle est ta problématique complète ? ...).
2/ Lis la doc.
Désolé pour cette réponse très peu cordiale, mais à mes yeux, la plus grande qualité d'un administrateur système est de savoir ce documenter par lui même. Si t'es pas en mesure de le faire, alors laisse l'administration du Cyrus a quelqu'un d'autre (surtout que ce dernier n'est pas réputé poru être "facile").
[^] # Re: re
Posté par zurpa . Évalué à 1.
Il s'agit d'un problème dans le cadre d'un projet. Initialement, Courrier imap devait être utilis et apporte la fonctionnalité de proxy IMAP. Malheureusement, ce dernier n'est pas supporté pr RedHat (9).
L'architecture au niveau de tous les types de flux qui doivent circuler est à chaque fois à plusieurs niveaux, aussi bien pour les flux en eux même (pop, smtp, http, ...) et le premier niveau ne réalise que la partie SSL (ici IMAPS). Le second niveau réalise d'autrs opérations.
La communication entre le niveau 1 et 2 n'est plus en SSL après passage par pluseiurs pare-feux.
Au niveau de la documentation, si celle de Courrier est correcte, celle de Cyrus est quasi nulle (d'où le problème d'ailleurs de "facilité" mais je suis prêt à lire n'importe quelle doc plus complète.
L'utilisation de stunnel n'est pas possible dans ce cadre, sinon tous les flux auraient pu en bénéficier.
Ma question aurjourd'hui est donc de savoir si c'est possible, et dans le cas contraire nous nous tournerons vers Courrier, ce qui pose le problème du support.
[^] # Re: re
Posté par Raphaël SurcouF (site web personnel) . Évalué à 1.
La documentation de cyrus est on ne peut plus correcte.
Je ne comprend pas non plus ta problématique, tu restes encore une fois un peu trop évasif sur le contexte lui-même.
Qui a besoin du service IMAPS, qui a besoin du service IMAP (et pourquoi tout le monde n'utiliserait pas IMAPS ?) ?
Quel besoin y a-t-il d'interrompre ainsi de façon unilatérale les communications en SSL ?
Quant au problème de support, mauvais prestataire, changer prestataire.
[^] # Re: re
Posté par LaBienPensanceMaTuer . Évalué à 2.
http://cyrusimap.web.cmu.edu//ag.html
Puis ça:
http://cyrusimap.web.cmu.edu/imapd/install-murder.html
Le concept se rapproche à peu près de ce que tu veux faire dans le sens ou cela amène une architecture distribuée.
[^] # Re: re
Posté par zurpa . Évalué à 1.
J'ai effectivement trouvé ces docs. J'ai plus l'impression que murder est utilisé pour récupérer les messages sur différents serveurs, mais pas en imap. Effectivement, ça se rapporche mais ce n'est pas exactement ça.
En fait mon post était surtout pour voir si quelqu'un l'avait déjà fait et me fournir un piste que je puisse fournir aux personnes chargées des installations / configurations.
Pour répondre à une autre question, on pourrait effectivement garder du Imaps sur tout la chaîne, ce qui 1) n'aurait pas d'intérêt puisqi'on considère que passé la première sécurité imaps n'est plus nécessaire
et 2) ceci ne résoudrait pas mon problème de proxyfication
Merci en tout cas pour votr aide
[^] # Re: re
Posté par Raphaël SurcouF (site web personnel) . Évalué à 1.
Je comprends mieux pourquoi le contexte original est si confus.
Sérieusement, j'ai du mal à comprendre quel est le besoin d'avoir un tel service IMAP qui soit, depuis un niveau, en IMAPS puis, depuis un autre, en IMAPS...
Si c'était pour archiver les mails ou pouvoir à tout moment en contrôler le contenu (deux actions qui sont soumises à la loi, attention à ce qu'on fait), normalement, on peut déjà réaliser toute cette chaîne au niveau de SMTP. Je ne comprends donc vraiment pas l'intérêt...
C'est peut-être votre "architecture" qu'il faudrait revoir.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.