Bonjour,
Je cherche une solution mail client / serveur de préférence gratuite qui me
permette:
- De stocker tous les messages entrants et sortants dans une base type
MySQL, pour pouvoir ensuite faire des recherche par requète SQL.
- De pouvoir synchroniser (réplication ?) les PC portables avec le serveur
central, un peu à la manière d'Exchange 2003, quitte à avoir MySQL sur
chaque portable, ce n'est pas un problème.
- Le serveur imap/smtp doit en fait n'être qu'un simple intermédiaire avec
celui de notre FAI. Par exemple quand un utilisateur relève son courrier, il
faudrait qu'il interroge ce serveur local qui lui-même appelle le serveur du
FAI, et stocke au passage les messages.
Les clients sont sous Windows, pour le serveur, c'est Windows 2003 ou Linux.
2.Poses-toi une question - comment google est foutu?
Justement, Google comme Yahoo utilisent massivement MySQL.
Calimero
Pour un usage individuel, le fichier texte peut suffire, beaucoup moins en entreprise, par exemple si on veut coupler avec une CRM ou des règles d'archivage ISO 9000, voir mettre en place une politique de sécurité / filtrage.
Pour un usage individuel, le fichier texte peut suffire, beaucoup moins
en entreprise, par exemple si on veut coupler avec une CRM ou des
règles d'archivage ISO 9000, voir mettre en place une politique de sécurité
/ filtrage.
Pour un usage individuel, le fichier texte peut suffire, beaucoup moins en entreprise, par exemple si on veut coupler avec une CRM ou des règles d'archivage ISO 9000, voir mettre en place une politique de sécurité / filtrage.
Calimero
P.S. dans 3-5 ans on reprogrammera linux kernel en Visual Basic ;)
Sans doute une perfidie sur ma supposition qu'un jour /etc sera remplacé par MySQL. Pour Sun a pris une licence auprès de MySQL dans ce sens pour les prochaines version de Solaris. Sans doute programmées en VB ;-)
Ca a commencé par OpenLdap, la suite va venir car tout est lié et on a besoin de tout centraliser. Et dans une base SQL, c'est mieux...
P.S. dans 3-5 ans on reprogrammera linux kernel en Visual Basic ;)
Sans doute une perfidie sur ma supposition qu'un jour /etc sera remplacé
par MySQL. Pour Sun a pris une licence auprès de MySQL dans ce sens
pour les prochaines version de Solaris. Sans doute programmées en VB ;-)
Ca a commencé par OpenLdap, la suite va venir car tout est lié et on a
besoin
de tout centraliser. Et dans une base SQL, c'est mieux...
P.S. dans 3-5 ans on reprogrammera linux kernel en Visual Basic ;)
Sans doute une perfidie sur ma supposition qu'un jour /etc sera remplacé par MySQL. Pour Sun a pris une licence auprès de MySQL dans ce sens pour les prochaines version de Solaris. Sans doute programmées en VB ;-)
Ca a commencé par OpenLdap, la suite va venir car tout est lié et on a besoin de tout centraliser. Et dans une base SQL, c'est mieux...
Nicolas Ecarnot
"Calimero" <Calimero> wrote in news::
A l'extrême toutes les bases de données peuvent se ramener à des fichiers à plat. Et pourquoi pas un cahier avec un crayon, avec un emploi jeune qui note ??
Ah non par pitié, pas ce genre d'argument qui énerve vraiment. Ca sent le pâté, ça sous-entend que les logiciels libres sont à la traine pour cause d'inertie. On peut tout de suite rétorquer que les "innovations" brillantes et clinquantes des logiciels propriétaires sont bien souvent des pièges à virus et des pièges à pognon (upgrade matériel obligatoire)
Franchement, tous les serveurs emails commerciaux utisent une db en backend, les plus gros ISP aux US utilisent Oracle et DB2 (je l'ai même vu sur des mainframes IBM),
Encore une fois, pitié, merci de ne pas baver d'envie sur les US, ça éverne aussi assez vite.
Je parie mon poids en cacahouètes que dans 3-5 ans, tous les serveurs libres auront une db en backend. Les bases de données, c'est le fondement de l'informatique,
Bon , si on revient au débat technique, maintenant, la question est *HYPER interessante* et j'aurais assez tendance à soutenir notre ami par curiosité. En effet, la vraie question est : Quelles fonctionnalités demande-t-on à un serveur de mail, dans toutes les tâches qui ne concernent pas le service de mail ? C'est-à-dire, parmi toutes les tâches annexes, lesquelles seraient avantageusement améliorées/rationnalisées par l'utilisation d'une DB ?
Si vous voulez, je commence la liste : - recherche basique de mail (critères détaillés) - statistiques hyper détaillées : * nombre, type et taille de pièces jointes * en entreprise, services les plus communiquants : Analyser les flux d'information - stockage/archivage - Ca se discute : un fichier texte est bien plus simple à archiver qu'une DB. Cela dit, il est plus simple de demander un archivage séléctif selon des critères complexes grace à une db. - ... (à vous)
-- Nicolas Ecarnot
"Calimero" <Calimero> wrote in news:0sydnTUq2d0yXqaiRVn-hQ@giganews.com:
A l'extrême toutes les bases de données peuvent se ramener à des
fichiers à plat.
Et pourquoi pas un cahier avec un crayon, avec un emploi jeune qui
note ??
Ah non par pitié, pas ce genre d'argument qui énerve vraiment.
Ca sent le pâté, ça sous-entend que les logiciels libres sont à la traine
pour cause d'inertie.
On peut tout de suite rétorquer que les "innovations" brillantes et
clinquantes des logiciels propriétaires sont bien souvent des pièges à
virus et des pièges à pognon (upgrade matériel obligatoire)
Franchement, tous les serveurs emails commerciaux utisent une
db en backend, les plus gros ISP aux US utilisent Oracle et DB2 (je
l'ai même vu sur des mainframes IBM),
Encore une fois, pitié, merci de ne pas baver d'envie sur les US, ça
éverne aussi assez vite.
Je parie mon poids en cacahouètes que dans 3-5 ans, tous les serveurs
libres auront
une db en backend. Les bases de données, c'est le fondement de
l'informatique,
Bon , si on revient au débat technique, maintenant, la question est
*HYPER interessante* et j'aurais assez tendance à soutenir notre ami par
curiosité.
En effet, la vraie question est : Quelles fonctionnalités demande-t-on à
un serveur de mail, dans toutes les tâches qui ne concernent pas le
service de mail ?
C'est-à-dire, parmi toutes les tâches annexes, lesquelles seraient
avantageusement améliorées/rationnalisées par l'utilisation d'une DB ?
Si vous voulez, je commence la liste :
- recherche basique de mail (critères détaillés)
- statistiques hyper détaillées :
* nombre, type et taille de pièces jointes
* en entreprise, services les plus communiquants : Analyser les flux
d'information
- stockage/archivage - Ca se discute : un fichier texte est bien plus
simple à archiver qu'une DB. Cela dit, il est plus simple de demander un
archivage séléctif selon des critères complexes grace à une db.
- ... (à vous)
A l'extrême toutes les bases de données peuvent se ramener à des fichiers à plat. Et pourquoi pas un cahier avec un crayon, avec un emploi jeune qui note ??
Ah non par pitié, pas ce genre d'argument qui énerve vraiment. Ca sent le pâté, ça sous-entend que les logiciels libres sont à la traine pour cause d'inertie. On peut tout de suite rétorquer que les "innovations" brillantes et clinquantes des logiciels propriétaires sont bien souvent des pièges à virus et des pièges à pognon (upgrade matériel obligatoire)
Franchement, tous les serveurs emails commerciaux utisent une db en backend, les plus gros ISP aux US utilisent Oracle et DB2 (je l'ai même vu sur des mainframes IBM),
Encore une fois, pitié, merci de ne pas baver d'envie sur les US, ça éverne aussi assez vite.
Je parie mon poids en cacahouètes que dans 3-5 ans, tous les serveurs libres auront une db en backend. Les bases de données, c'est le fondement de l'informatique,
Bon , si on revient au débat technique, maintenant, la question est *HYPER interessante* et j'aurais assez tendance à soutenir notre ami par curiosité. En effet, la vraie question est : Quelles fonctionnalités demande-t-on à un serveur de mail, dans toutes les tâches qui ne concernent pas le service de mail ? C'est-à-dire, parmi toutes les tâches annexes, lesquelles seraient avantageusement améliorées/rationnalisées par l'utilisation d'une DB ?
Si vous voulez, je commence la liste : - recherche basique de mail (critères détaillés) - statistiques hyper détaillées : * nombre, type et taille de pièces jointes * en entreprise, services les plus communiquants : Analyser les flux d'information - stockage/archivage - Ca se discute : un fichier texte est bien plus simple à archiver qu'une DB. Cela dit, il est plus simple de demander un archivage séléctif selon des critères complexes grace à une db. - ... (à vous)
-- Nicolas Ecarnot
DINH Viêt Hoà
Si vous voulez, je commence la liste : - recherche basique de mail (critères détaillés) - statistiques hyper détaillées : * nombre, type et taille de pièces jointes * en entreprise, services les plus communiquants : Analyser les flux d'information - stockage/archivage - Ca se discute : un fichier texte est bien plus simple à archiver qu'une DB. Cela dit, il est plus simple de demander un archivage séléctif selon des critères complexes grace à une db. - ... (à vous)
- avantage : IMAP permet de faire le travail du client, c'est-à-dire découper les mails suivant les découpages MIME, analyser les en-têtes afin d'en extraire les informations importantes. Pour un serveur IMAP, les informations relatives au découpage pourrait être stocké dans la base de données.
- avantage : stockage des flags des mails (lu, non lu, nouveau, marqué pour l'effacement, important, répondu), pas d'altérer le format standard des messsages (RFC2822) afin d'y intégrer les flags.
- problème si on change de base de données, migration à faire.
-- DINH V. Hoa,
"du sucre dans le pain brioché ???" -- groz
Si vous voulez, je commence la liste :
- recherche basique de mail (critères détaillés)
- statistiques hyper détaillées :
* nombre, type et taille de pièces jointes
* en entreprise, services les plus communiquants : Analyser les flux
d'information
- stockage/archivage - Ca se discute : un fichier texte est bien plus
simple à archiver qu'une DB. Cela dit, il est plus simple de demander un
archivage séléctif selon des critères complexes grace à une db.
- ... (à vous)
- avantage : IMAP permet de faire le travail du client, c'est-à-dire
découper les mails suivant les découpages MIME, analyser les en-têtes afin
d'en extraire les informations importantes. Pour un serveur IMAP, les
informations relatives au découpage pourrait être stocké dans la base de
données.
- avantage : stockage des flags des mails (lu, non lu, nouveau, marqué
pour l'effacement, important, répondu), pas d'altérer le format
standard des messsages (RFC2822) afin d'y intégrer les flags.
- problème si on change de base de données, migration à faire.
Si vous voulez, je commence la liste : - recherche basique de mail (critères détaillés) - statistiques hyper détaillées : * nombre, type et taille de pièces jointes * en entreprise, services les plus communiquants : Analyser les flux d'information - stockage/archivage - Ca se discute : un fichier texte est bien plus simple à archiver qu'une DB. Cela dit, il est plus simple de demander un archivage séléctif selon des critères complexes grace à une db. - ... (à vous)
- avantage : IMAP permet de faire le travail du client, c'est-à-dire découper les mails suivant les découpages MIME, analyser les en-têtes afin d'en extraire les informations importantes. Pour un serveur IMAP, les informations relatives au découpage pourrait être stocké dans la base de données.
- avantage : stockage des flags des mails (lu, non lu, nouveau, marqué pour l'effacement, important, répondu), pas d'altérer le format standard des messsages (RFC2822) afin d'y intégrer les flags.
- problème si on change de base de données, migration à faire.
-- DINH V. Hoa,
"du sucre dans le pain brioché ???" -- groz
DINH Viêt Hoà
Sans doute une perfidie sur ma supposition qu'un jour /etc sera remplacé par MySQL. Pour Sun a pris une licence auprès de MySQL dans ce sens pour les prochaines version de Solaris. Sans doute programmées en VB ;-)
oui, enfin pour cela, il faudra toucher un peu au standard POSIX qui définit son /etc
-- DINH V. Hoa,
"du sucre dans le pain brioché ???" -- groz
Sans doute une perfidie sur ma supposition qu'un jour /etc sera remplacé
par MySQL. Pour Sun a pris une licence auprès de MySQL dans ce sens
pour les prochaines version de Solaris. Sans doute programmées en VB ;-)
oui, enfin pour cela, il faudra toucher un peu au standard POSIX qui
définit son /etc
Sans doute une perfidie sur ma supposition qu'un jour /etc sera remplacé par MySQL. Pour Sun a pris une licence auprès de MySQL dans ce sens pour les prochaines version de Solaris. Sans doute programmées en VB ;-)
oui, enfin pour cela, il faudra toucher un peu au standard POSIX qui définit son /etc
-- DINH V. Hoa,
"du sucre dans le pain brioché ???" -- groz
Nicolas LS
Je vais même plus loin, un jour tout /etc sera dans MySQL. <TROLL>
Une Base de Registre peut-être ?... :-))) </TROLL>
Beurk... Et comment tu fais pour booter si jamais tu as besoin de réparer la base MySQL ? Il y en a qui ne sont pas net. D'ailleurs, je tiendrais a préciser qu'une des bases de données le plus sure, c'est UFS (bon ou XFS sous Linux), et que rajouter une couche, ca ne peut que rendre instable...
-- Nicolas Le Scouarnec http://nlsn.free.fr (Slrnfr, Docs Linux/BSD, La grippe, ... )
Je vais même plus loin, un jour tout /etc sera dans MySQL.
<TROLL>
Une Base de Registre peut-être ?...
:-)))
</TROLL>
Beurk... Et comment tu fais pour booter si jamais tu as besoin de
réparer la base MySQL ? Il y en a qui ne sont pas net. D'ailleurs, je
tiendrais a préciser qu'une des bases de données le plus sure, c'est
UFS (bon ou XFS sous Linux), et que rajouter une couche, ca ne peut que
rendre instable...
--
Nicolas Le Scouarnec
http://nlsn.free.fr (Slrnfr, Docs Linux/BSD, La grippe, ... )
Je vais même plus loin, un jour tout /etc sera dans MySQL. <TROLL>
Une Base de Registre peut-être ?... :-))) </TROLL>
Beurk... Et comment tu fais pour booter si jamais tu as besoin de réparer la base MySQL ? Il y en a qui ne sont pas net. D'ailleurs, je tiendrais a préciser qu'une des bases de données le plus sure, c'est UFS (bon ou XFS sous Linux), et que rajouter une couche, ca ne peut que rendre instable...
-- Nicolas Le Scouarnec http://nlsn.free.fr (Slrnfr, Docs Linux/BSD, La grippe, ... )
Thomas Pedoussaut
Calimero wrote:
Je vais même plus loin, un jour tout /etc sera dans MySQL.
/etc c'est quand meme bcp de lecture, tres peux de modifications.
Je parie plus sur un annuaire (LDAP ou autre) comme on en a deja un apercu pour password ou mail/virtusertable
-- Thomas Pedoussaut Dublin IRLANDE http://irlande.staffeurs.org/
Calimero wrote:
Je vais même plus loin, un jour tout /etc sera dans MySQL.
/etc c'est quand meme bcp de lecture, tres peux de modifications.
Je parie plus sur un annuaire (LDAP ou autre) comme on en a deja un
apercu pour password ou mail/virtusertable
--
Thomas Pedoussaut
Dublin IRLANDE
http://irlande.staffeurs.org/
Je vais même plus loin, un jour tout /etc sera dans MySQL.
/etc c'est quand meme bcp de lecture, tres peux de modifications.
Je parie plus sur un annuaire (LDAP ou autre) comme on en a deja un apercu pour password ou mail/virtusertable
-- Thomas Pedoussaut Dublin IRLANDE http://irlande.staffeurs.org/
Nicolas LS
Cyrus et Exchange utilisent un format de base de données propriétaire. Est-ce que ce choix est le plus judicieux ? Ne vaut mieux-t-il pas utiliser une base "standard" comme MySQL ? (Je ne saurai pas répondre à la question, c'est peut-être trop dimensionné ? Mais beaucoup d'applications de base de données n'exploitent peut-être pas toutes les capacités de la base. Le courrier électronique en serait une)
Si on regarde la doc de MySQL, on remarque que MySQL supporte 6 types de tables: Isam, MyIsam, BDD, Innodb, Hash, et 1 autre, je crois.
Isam est un type de table dépassé, remplacé par MyIsam MyIsam est non transactionnel, mais très performant, donc, on peut perdre des données, mais c'est rapide. BDD est transactionnel, mais pas performant. Innodb est transactionnel, moins rapide et plus lourd que *Isam, par contre, il est bourré de fonctionnalité. C'est sur pour les données, mais au niveau des perfs, on perd Hash, c'est une table pour travailler en mémoire, pas pour y placer des données importantes, c'est très très performant par contre.
Donc, au final, les types de base de données sont variés et ont des avantages et des inconvéniant , peut etre que celle de Cyrus a été étudié pour etre plus adapté que celles de MySQL au stockage de Mails, et on évite un Context-switch en n'appelant pas un autre programme, donc, ca a aussi un avantage au niveau perf.
Par contre, c'est vrai qu'on a pas SQL, qu'on ne peut pas faire de recherches complexes, mais a t'on vraiment besoin d'autant de fonctionnalité sur un serveur de Mail ? On n'a pas besoin de croisé des tables, et en général, vu qu'on ne doit pas faire de recherches sur le mails de ses utilisateurs, ca ne sert a rien a l'admin...
Il reste les fonctions de tri, mais la base de donnée de Cyrus inclut peut etre ca...
-- Nicolas Le Scouarnec http://nlsn.free.fr (Slrnfr, Docs Linux/BSD, La grippe, ... )
Cyrus et Exchange utilisent un format de base de données propriétaire.
Est-ce que ce choix est le plus judicieux ? Ne vaut mieux-t-il pas
utiliser une base "standard" comme MySQL ? (Je ne saurai pas répondre à la
question, c'est peut-être trop dimensionné ? Mais beaucoup d'applications
de base de données n'exploitent peut-être pas toutes les capacités de la
base. Le courrier électronique en serait une)
Si on regarde la doc de MySQL, on remarque que MySQL supporte 6 types
de tables: Isam, MyIsam, BDD, Innodb, Hash, et 1 autre, je crois.
Isam est un type de table dépassé, remplacé par MyIsam
MyIsam est non transactionnel, mais très performant, donc, on peut
perdre des données, mais c'est rapide.
BDD est transactionnel, mais pas performant.
Innodb est transactionnel, moins rapide et plus lourd que *Isam, par
contre, il est bourré de fonctionnalité. C'est sur pour les
données, mais au niveau des perfs, on perd
Hash, c'est une table pour travailler en mémoire, pas pour y placer des
données importantes, c'est très très performant par contre.
Donc, au final, les types de base de données sont variés et ont des
avantages et des inconvéniant , peut etre que celle de Cyrus a été
étudié pour etre plus adapté que celles de MySQL au stockage de Mails,
et on évite un Context-switch en n'appelant pas un autre programme,
donc, ca a aussi un avantage au niveau perf.
Par contre, c'est vrai qu'on a pas SQL, qu'on ne peut pas faire de
recherches complexes, mais a t'on vraiment besoin d'autant de
fonctionnalité sur un serveur de Mail ? On n'a pas besoin de croisé des
tables, et en général, vu qu'on ne doit pas faire de recherches sur le
mails de ses utilisateurs, ca ne sert a rien a l'admin...
Il reste les fonctions de tri, mais la base de donnée de Cyrus inclut
peut etre ca...
--
Nicolas Le Scouarnec
http://nlsn.free.fr (Slrnfr, Docs Linux/BSD, La grippe, ... )
Cyrus et Exchange utilisent un format de base de données propriétaire. Est-ce que ce choix est le plus judicieux ? Ne vaut mieux-t-il pas utiliser une base "standard" comme MySQL ? (Je ne saurai pas répondre à la question, c'est peut-être trop dimensionné ? Mais beaucoup d'applications de base de données n'exploitent peut-être pas toutes les capacités de la base. Le courrier électronique en serait une)
Si on regarde la doc de MySQL, on remarque que MySQL supporte 6 types de tables: Isam, MyIsam, BDD, Innodb, Hash, et 1 autre, je crois.
Isam est un type de table dépassé, remplacé par MyIsam MyIsam est non transactionnel, mais très performant, donc, on peut perdre des données, mais c'est rapide. BDD est transactionnel, mais pas performant. Innodb est transactionnel, moins rapide et plus lourd que *Isam, par contre, il est bourré de fonctionnalité. C'est sur pour les données, mais au niveau des perfs, on perd Hash, c'est une table pour travailler en mémoire, pas pour y placer des données importantes, c'est très très performant par contre.
Donc, au final, les types de base de données sont variés et ont des avantages et des inconvéniant , peut etre que celle de Cyrus a été étudié pour etre plus adapté que celles de MySQL au stockage de Mails, et on évite un Context-switch en n'appelant pas un autre programme, donc, ca a aussi un avantage au niveau perf.
Par contre, c'est vrai qu'on a pas SQL, qu'on ne peut pas faire de recherches complexes, mais a t'on vraiment besoin d'autant de fonctionnalité sur un serveur de Mail ? On n'a pas besoin de croisé des tables, et en général, vu qu'on ne doit pas faire de recherches sur le mails de ses utilisateurs, ca ne sert a rien a l'admin...
Il reste les fonctions de tri, mais la base de donnée de Cyrus inclut peut etre ca...
-- Nicolas Le Scouarnec http://nlsn.free.fr (Slrnfr, Docs Linux/BSD, La grippe, ... )
DINH Viêt Hoà
Par contre, c'est vrai qu'on a pas SQL, qu'on ne peut pas faire de recherches complexes, mais a t'on vraiment besoin d'autant de fonctionnalité sur un serveur de Mail ? On n'a pas besoin de croisé des tables, et en général, vu qu'on ne doit pas faire de recherches sur le mails de ses utilisateurs, ca ne sert a rien a l'admin...
recherches par mot-clef dans les mails ? quoique je n'ai pas vraiment noté précisément ce qu'étaient les recherches dans IMAP.
-- DINH V. Hoa,
"du sucre dans le pain brioché ???" -- groz
Par contre, c'est vrai qu'on a pas SQL, qu'on ne peut pas faire de
recherches complexes, mais a t'on vraiment besoin d'autant de
fonctionnalité sur un serveur de Mail ? On n'a pas besoin de croisé des
tables, et en général, vu qu'on ne doit pas faire de recherches sur le
mails de ses utilisateurs, ca ne sert a rien a l'admin...
recherches par mot-clef dans les mails ?
quoique je n'ai pas vraiment noté précisément ce qu'étaient les recherches
dans IMAP.
Par contre, c'est vrai qu'on a pas SQL, qu'on ne peut pas faire de recherches complexes, mais a t'on vraiment besoin d'autant de fonctionnalité sur un serveur de Mail ? On n'a pas besoin de croisé des tables, et en général, vu qu'on ne doit pas faire de recherches sur le mails de ses utilisateurs, ca ne sert a rien a l'admin...
recherches par mot-clef dans les mails ? quoique je n'ai pas vraiment noté précisément ce qu'étaient les recherches dans IMAP.
