note: ce journal est initialement un billet de glob lisible ici.
Ca fait maintenant quelques temps que le webmail de linuxwall est roundcube. J'aime bien cet outil car il est réellement épuré et ne reprend que les fonctions vraiment importante du mail.
Ici, pas de calendrier, de gestion partagées des taches, de notifications dans tous les sens comme on en trouve dans quasiment tous les webmails du moment, dans leurs folles courses vers le collaboratif.
Roundcube fait simplement son travail: envoyer et recevoir des emails, proprement, et gérer tout cela dans des dossiers IMAP.
Jusque récemment, certaines features me manquait tout de même cruellement. Et comme la sortie imminente de la 0.3 corrige certains de ces manquements, je me suis dit qu'il fallait bien que j'en parle :) (et puis, c'est l'été, tout calme au bureau, tout ça machin).
La demo
Parce que, les discours c'est bien mais le test c'est mieux, Roland Liebl à mis en ligne une demo de la version de dev de roundcube. Ca se trouve ici : http://mail4us.net/dev (avec le compte demo/demo).
Bon, alors là, Roland il a chargé tout plein de pleuguines, alors forcément ça fait un peu le café et le couscous. Mais dans sa version de base, roundcube est vraiment épuré.
Les Plugins
voir la liste, et pour les codeurs, c'est par là
C'est LA grosse évolution de la version 0.3. Une API de plugin permet maintenant de développer des composants sans toucher au core. C'est comme cela qu'en quelques semaines, le nombre de contributions a été multiplié par.... pfiou.... beaucoup ! (jetez un coup d'oeil sur la mailing list et vous verrez)
Parmi les plugins les plus intéressants, on a un module GnuPG en cours de développements, et un module managesieve pour *enfin* intégrer la gestion des filtres.
Managesieve
Parce que les gens de roundcube font les choses proprement, ils ont toujours refusé d'intégrer du filtering de mail coté client. Le filtrage en php, ca prend des ressources, et ca n'est actif que quand l'interface est ouverte.
Au lieu de cela, un protocole répondant exactement à ce besoin existe dans la grande majorité des serveurs mails (dovecot, cyrus-imap, ...), c'est Sieve.
Sieve, dont j'avais déjà parlé là-bas, est utilisable en ligne de commande via une sorte de shell qui permet d'entrer les règles de filtrage.
Mais, évidemment, c'est pas pratique pour des utilisateurs n'ayant pas accès au shell. Une interface pour sieve dans roundcube était donc indispensable, et c'est maintenant chose faite. Même si c'est assez limité en options de filtrage pour le moment.
Certificate Authentication
Ouais ! T'as bien lu ! l'authentification par certificat client. Bon, j'ai pas encore regardé ce qu'il y avait là-dedans, mais j'imagine qu'Apache (ou tout autre webserver) fait suivre les infos du certificat client envoyé lors du SSL Handshake à Roundcube, et ce plugin parse les champs X509 pour en sortie les infos d'authentification.
Bref, de la pure authentification forte comme on en met dans les banques et chez les impots. Faut absolument que je test ça !
Et pleins d'autres
La liste complète, et en constante évolution, est là. Pour le moment c'est un peu le far west, tout le monde code dans tous les sens. J'imagine qu'avec le temps, quelques gros plugins vont sortir du lot (j'ai d'ailleurs beaucoup d'espoir dans le plugin d'encryption).
Et les Core Features
J'en ai profité pour tester le STARTLS sur IMAP et SMTP. C'est une feature de la 0.2 mais comme je n'avais alors pas testé...
Pour imap, c'est super simple, il suffit de suivre les commentaires du code.
Pour smtp, j'ai un peu plus galéré (au point d'en faire un thread chez les devs) surtout parce qu'il existe deux supports différents pour SSL et TLS dans SMTP.
SSL signifie création d'un canal chiffré au début de la communication entre le client et le serveur.
TLS signifie réponse a la capability STARTTLS annoncée par le serveur, on a donc un début de communication en clair, puis un passage en mode starttls.
C'est de dernier mode que je voulais, et pour l'activer, il faut configurer le fichier main.inc.php de la façon suivante :
// use this host for sending mails.
// to use SSL connection, set ssl://smtp.host.com
// if left blank, the PHP mail() function is used
$rcmail_config['smtp_server'] = 'localhost';
// SMTP port (default is 25; 465 for SSL)
$rcmail_config['smtp_port'] = 25;
// SMTP username (if required) if you use %u as the username RoundCube
// will use the current username for login
$rcmail_config['smtp_user'] = '%u';
// SMTP password (if required) if you use %p as the password RoundCube
// will use the current user's password for login
$rcmail_config['smtp_pass'] = '%p';
// SMTP AUTH type (DIGEST-MD5, CRAM-MD5, LOGIN, PLAIN or empty to use
// best server supported one)
$rcmail_config['smtp_auth_type'] = '';
En supposant que le serveur SMTP (ici, postfix) soit configuré correctement :
# TLS server options
smtpd_use_tls = yes
smtpd_tls_auth_only = yes
smtpd_tls_security_level = may
smtpd_tls_key_file = [keyfile]
smtpd_tls_cert_file = [pemcert]
smtpd_tls_CAfile = [cafile]
smtpd_tls_loglevel = 2
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom
smtpd_tls_ask_ccert = yes
smtpd_tls_req_ccert = no
Le code de roundcube va appeler le mode STARTTLS lorsque l'authentification est demandée (les variables 'smtp_user' et 'smtp_pass' sont renseignées).
Si la configuration ne correspond pas exactement à cela (coté roundcube, et modulo l'adresse du serveur), alors le mode STARTTLS échoue. C'est un poil touchy mais assez logique au final.
De fait, lors de l'envoi d'un mail, on retrouve dans les headers les infos suivantes :
Received: from pki.linuxwall.info (localhost [127.0.0.1])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(Client did not present a certificate)
(Authenticated sender: julien@linuxwall.info)
by zerhuel.linuxwall.info (Postfix) with ESMTPSA id A5FAAEBC1B;
Thu, 6 Aug 2009 13:28:51 +0200 (CEST)
Comment ça "Client did not present a certificate" ?? Ha mais il va falloir corriger cela très vite ! J'espère, d'ailleurs, que cela fera parti du fameux plugin Encryption.
Et les threads ???
Haaa... les threads. Ca c'est, après le filtrage des mails, la feature qui me manque le plus. Mais, patience, car ça arrive ! En fait, c'est déjà développé et n'attend plus que la release de la 0.4 pour passer en stable.
Pour plus de lecture sur le sujet, voir ici : http://lists.roundcube.net/mail-archive/dev/2009-07/0000131.(...)
Voilà, j'espère que ça vous aura mis l'eau à la bouche. Roundcube, c'est bon, mangez-en !
# Pas suffisament épuré pour moi en tout cas...
Posté par beagf (site web personnel) . Évalué à 5.
MySQL est utilisé pour quoi ? Le carnet d'adresses (qui est basique d'après le site web) Les logins/mot de passe ?
C'est pas un peu prendre un marteau piqeur pour écraser une mouche, surtout pour un webmail qui fonctionne au dessus d'IMAP ?
[^] # Re: Pas suffisament épuré pour moi en tout cas...
Posté par jve (site web personnel) . Évalué à 1.
La base de données ne sert, à ma connaissance, qu'a conserver les préférences, les dossiers souscris ou encore le cache (important pour pas recharger complètement un répertoire de 5000 email à chaque ouverture).
[^] # Re: Pas suffisament épuré pour moi en tout cas...
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
Quant au SGBD… SQLite, vous connaissez ? RoundCube, lui, oui.
[^] # Re: Pas suffisament épuré pour moi en tout cas...
Posté par jve (site web personnel) . Évalué à 1.
Après, la guerre de religion entre sgbd....
ya quand même une table users qui stocke les logins et les préférences.
[^] # Re: Pas suffisament épuré pour moi en tout cas...
Posté par beagf (site web personnel) . Évalué à 1.
Ton commentaire, bien que légèrement sarcastique à un moment ou il fallait mieux pas me chercher ;-) m'a mit la puce à l'oreille. Je me rend donc sur leur site, et confirmation la page n'a pas changée...
Par acquis de conscience j'ai quand même été voir plus loin, et bien m'en à pris car, en effet la version 3-rc1 supporte sqlite. (en version 2 pas 3 hélas...)
Donc je viens de tester et en effet ça marche à merveille. J'ai plus qu'à attendre la version finale de la 3.0 pour tester ça un peu plus en profondeur et surement envisager une migration. Ça va faire plaisir à mes utilisateurs.
Et petite question, est-ce que quelqu'un ici à déjà mit en place roundcube sur une messagerie un peu importante, aux alentour de 1500 utilisateurs ? Qu'elle est la charge sur le serveur par rapport à squirelmail ? Est-ce qu'il est fiable ?
[^] # Re: Pas suffisament épuré pour moi en tout cas...
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
[^] # Re: Pas suffisament épuré pour moi en tout cas...
Posté par beagf (site web personnel) . Évalué à 4.
Mettre un peu plus en avant sqlite (au moins autant que les deux autres) ne pourrais que faire du bien roundcube.
[^] # Re: Pas suffisament épuré pour moi en tout cas...
Posté par yellowiscool . Évalué à 3.
Envoyé depuis mon lapin.
[^] # Re: Pas suffisament épuré pour moi en tout cas...
Posté par jeffcom . Évalué à 2.
Je ne sais pas si c'est exactement la même chose que tu as en tête, mais ovh le propose comme l'un des webmails disponnibles
# Demo
Posté par patrick_g (site web personnel) . Évalué à 6.
Tellement l'eau à la bouche qu'il n'est plus possible de se connecter à la démo tellement il y a de monde :-(
[^] # Re: Demo
Posté par jve (site web personnel) . Évalué à -1.
# Sieve
Posté par Sébastien Bonnefoy (site web personnel) . Évalué à 1.
Quel est l'intérêt de sieve par rapport au bon vieux procmail?
[^] # Re: Sieve
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
[^] # Re: Sieve
Posté par herodiade . Évalué à 10.
Procmail est un vénérable outil unix capable de faire un peu tout (et n'importe quoi, y compris exécuter des commande arbitraires). Son langage n'est pas normalisé autrement que par son implémentation, et je ne crois pas qu'il y ai beaucoup d'autres outils que procmail lui-même qui soient capables d'éditer visuellement un .procmailrc arbitraire (je ne parle pas d'outils capables d'éditer une petite partie de sa syntaxe, typoquement : uniquement des fichiers qu'ils ont généré eux même). Le dépot de script .procmailrc sur le serveur nécessite un accès au système de fichier (ou une bidouille "site spécifique" pour récupérer/déposer au bon endroit : la mise à jour du jeux de règles n'est pas prise en charge par procmail lui même).
Bref, procmail est puissant, souple, non standard et potentiellement dangereux.
Sieve est un langage de description de filtrage (tris, bounce, vacation/notification d'absence, forwards, ...) de mails coté serveur standardisé (décrit dans une foultitude de RFC en fait, à commencer par la RFC 5228), et conçu pour permet de déployer des jeux de règles écrits par des gens pas forcément de confiance sur un des serveurs qu'on ne veux pas compromettre (il ne permet pas l'exécution de commandes externes, évite les boucles infinies, ...), et pour permettre l'interopérabilité et l'édition/génération de jeux de règles à partir de clients divers (éventuellement graphiques : webmails...).
Le standard sieve a un petit frère nommé managesieve, pas encore majeur (c'est un draft de RFC, bien qu'il soit déjà implémenté dans plein d'outils libres), qui décrit un protocole de téléchargement/upload des jeux de règles sur les serveurs, assez insipré de l'IMAP (simplifié), sans que le client n'ai a accéder au système de fichier ni même à savoir où le serveur place ces fichiers.
Le support sieve et/ou managesive est implémentés dans divers clients (par exemples des plugins pour les webmails Squirrelmail, Horde, Roundcube, l'extension sieve pour Thunderbird, un support natif dans Kmail et Mullbery, dans divers LDA tels que celui fournis avec Dovecot, avec Cyrus, avec DBmail, avec Courrier, Exim ...), et normalement les jeux de rêgles uploadés par l'un sont téléchargeables et éditables tels quels par l'autre (c'est interopérable quoi).
Bref :
Procmail est très adapté sur une machine dont les utilisateurs sont de confiance, ou lorsque son utilisation et la mise à jour des ses rulesets est restreinte, limitée et sous contrôle (par ex. avec le subset de langage procmail implémenté par Horde IMP), ou écrit par l'admin pour faire de puissant traitements sur des mails transitant sur un serveur / sur une boite automatisée, ou lorsqu'on a besoin de brancher des filtres (par ex. antispam ou antivirus) au moment de la distribution du mail.
Sieve est plus adapté pour un serveur mail hébergeant une bonne brouette d'utilisateurs pas forcément "de confiance", et lorsqu'on apprécie les bénéfice d'une solution standardisé interopérable (pouvoir changer de client/webmail/LDA/etc... et continuer de pouvoir manipuler graphiquement ses règles de tris). Le fait d'être souvent implémenté par les LDA fournis par les divers serveurs IMAP le rends aussi plus adapté que procmail à l'hébergement virtuel de masse à mes yeux (le path des scripts, le path et le format des mailboxes/mh/maildirs, le séparateur IMAP, l'uid/gid de destination du mail, etc. lui sont alors directement indiqué par le serveur IMAP qui de toutes façons doit connaitre ces infos), alors que l'utilisation de procmail impose de forte contraintes sur l'hébergement virtuel.
[^] # Re: Sieve
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
[^] # Re: Sieve
Posté par nodens . Évalué à 2.
D'ailleurs un script sieve créé par un outil est rarement lisible par un autre (sauf si ils utilisent le même moteur, ou managesieve), même si les deux vont fonctionner sur le serveur.
Mais bon, il y a plus d'interface de gestion de filtres sieve que d'interface procmail. Et puis c'est quand même un standard. Et ça marche très bien :-)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.