Sommaire
Introduction
Disposer de son propre serveur de mails permet de créer autant de compte mails que désirés, sans compter la possibilité de créer des alias. Néanmoins, de ce que j'ai pu voir, les webmails ne permettent de gérer qu'un seul compte à la fois, et les clients de messagerie desktop permettent d'avoir accès à plusieurs comptes mail à la fois, mais seulement indépendamment les uns des autres.
Une des principales fonctionnalités d'un MUA est le classement des mails, en les répartissant dans différents dossiers, dossiers que l'on peut eux-mêmes réorganiser à volonté. Chaque compte IMAP a sa propre arborescence de dossiers dans laquelle l'on peut répartir ses courriers. Néanmoins, un courrier d'un compte IMAP ne peut être placé dans un dossier d'un autre compte IMAP (pour autant que je sache…).
L'application
L'idée de départ est d'avoir une arborescence commune à plusieurs comptes mails, en proposant une vue globale de l'ensemble des courriers de l'ensemble des comptes mails dont l'application a la charge, tout en conservant la possibilité de distinguer les courriers en fonction du compte duquel ils sont issus.
A l'instar des autres MUA, cette application permet de répartir les courriers dans différents dossiers. Contrairement aux autres MUA (me semble-t-il), un même dossier pourra contenir des courriers issus de différents comptes mails.
En outre, cette application prendra, à terme, en charge toutes les fonctionnalités que l'on peut attendre d'un MUA (et je suis ouvert à toute proposition sur le sujet).
Avancement
Cette application n'en est qu'à ses débuts, mais la présenter dés maintenant facilitera la correction d'éventuels problèmes de conception, et permettra de la développer de manière à ce que les fonctionnalités auxquelles le développeur n'avait pas songé puissent être efficacement implémentées.
En l'état, l'application permet de prendre en compte plusieurs comptes mails (comptes POP3 uniquement ; les comptes IMAP seront pris en charge ultérieurement), de visualiser sommairement les courriers qu'ils contiennent, et de pouvoir répartir ces derniers dans une arborescence que l'on peut organiser à volonté.
Son apparence est très rustique, le développement d'interfaces graphiques étant un domaine qui ne m'est pas très familier, tant du point de vue design que technique. Cela a un impact sur l'ergonomie (comme l'utilisation de poignées pour le drag & drop), mais tout cela peut être aisément amélioré par quelqu'un d'expérimenté dans le domaine (contributions bienvenues).
Une démonstration en ligne est disponible pour ceux qui veulent voir l'application en action. Tout nouveau compte (dont la création est très simple) est préconfiguré avec des comptes mail de démonstration contenant quelques courriers. Vous pouvez également ajouter vos propres comptes POP3 (attention : les connexions chiffrées ne sont pas encore prises en charge).
Autre aspects
Outres les fonctionnalités présentées ci-dessus, cette application disposera de plusieurs frontends, chacun prenant en charge l'une des interfaces suivantes :
- graphiques (GUI):
- desktop,
- GNU/Linux (disponible),
- MacOS (disponible),
- Windows (disponible),
- web (disponible),
- mobile :
- Android (en cours de développement),
- iOS (en cours d'étude),
- desktop,
- console (CLI ; disponible).
Le framework employé pour les versions desktop de l'interface graphique ne propose pas, dans sa version GNU/Linux, d’implémentation par défaut des boîtes de dialogues. De ce fait, certaines ne s’afficheront pas (comme celles relatives à la sélection de fichiers, par exemple), et d'autre utiliseront la console à partir de laquelle le frontend a été lancé. Ainsi, le message de demande de confirmation pour quitter l'application s'affichera dans la console, dans laquelle vous devrez confirmer ou non votre intention de quitter l'application. A terme, l'application affichera ces boîtes de dialogues sous leur forme habituelle (dés que je saurais comment afficher une boîte de dialogue sous GNU/Linux ; toute information à ce sujet est la bienvenue).
Le frontend CLI (/frontend/CLI/mmuaqcli[.exe]) est à destination d'utilisateurs avancés. Cet utilitaire, qui s'appuie sur le backend au même titre que tous les autres frontends, permet de réaliser toutes les opérations disponibles avec l'interface graphique, mais à partir de la ligne de commande.
Tous ces frontends peuvent être lancés de deux manières différentes. Soit de manière autonome, c'est-à-dire que le frontend charge directement le backend ; on est alors là dans un cas d'utilisation mono-utilisateur (sauf pour le frontend web). Soit, au lieu de le charger, le frontend peut se connecter au backend, alors lancé comme daemon, via une connexion réseau. Cela permet, par exemples, d’accéder à l'application via l'interface desktop lorsque que l'on est chez soi, sur son ordinateur de bureau, via l'interface mobile lorsque l'on est à l'extérieur, ou bien, bien que cela soit sans doute passé de mode avec la démocratisation des smartphones, via l'interface web à partir d'un cybercafé (ou sur l'ordinateur d'une connaissance).
Il y a, en outre, un utilitaire en ligne de commande (/processing/mmuaq/mmuaq[.exe]) qui partage une partie du code avec le backend et qui facilite les tests, et donc le débogage des fonctionnalités clefs de l'application. Cet utilitaire peut être utile pour ceux qui veulent se plonger dans les arcanes de l'application.
A noter que l'application est multi-comptes. Elle tourne sous GNU/Linux (et probablement sous tout système d'exploitation POSIX), MacOS et Windows, sur architectures IA-32, AMD64 et ARM (Raspberry Pi, ODROID…).
Conclusion
Cette application est développée pour mon usage personnel, mais elle peut sans doute intéresser d'autres personnes, d'où sa présentation ici. Si c'est votre cas, n'hésitez pas à vous manifester.
L'application est, par défaut, distribuée sous licence AGPL. De ce fait, vous pouvez facilement en examiner tous les aspects, et les commenter ici même si vous le désirez, pour peu que vos commentaires soient, bien entendu, constructifs.
Des informations complémentaires, que je m’efforcerais de compléter en fonction de vos retours et au fur et à mesure de l'évolution de l'application, sont disponibles à l'adresse http://q37.info/computing/epeios/apps/mmuaq/, dont les liens suivant sont tirés :
- Téléchargement : http://q37.info/download/computing/apps/mmuaq/,
- sources : http://github.com/epeios-q37/epeios/tree/master/apps/mmuaq/,
- et, pour rappel, démonstration en ligne : http://q37.info/xdh/mmuaq.html.
# Si, ça existe.
Posté par ohm . Évalué à 5.
J'utilise personnellement claws-mail, qui permet à la fois de déplacer un courrier dans les dossiers de n'importe quel compte, mais également d'écrire un nouveau courrier avec n'importe quelle identité, que ce soit celle d'un des comptes déjà enregistrés ou une improvisée au moment de l'écriture (je ne sais pas ce que tu entends exactement par « indépendamment les uns des autres »).
[^] # Re: Si, ça existe.
Posté par Claude SIMON (site web personnel) . Évalué à 2.
Je viens d'installer Claws-Mail et, effectivement, contrairement à ce que je supputais dans le journal (et que j'entendais par « …indépendamment les uns des autres »), au moins avec ce logiciel, il est possible de déplacer un courrier d'un compte mail à un autre. Ceci dit, je ne pense pas que ce soit propre à ce logiciel ; cela doit être lié au protocole IMAP…
Néanmoins, dans Claws-Mail (à moins que j'ai loupé quelque chose dans ses options de configuration), chaque compte mail a sa propre arborescence, même si elles ne sont pas aussi imperméables que je le pensais. Or, je préfèrerais avoir une arborescence unique et commune à tous les comptes mail, même s'il doit rester possible de différencier les courriers en fonction du compte dont ils sont issus.
Pour ce qui est de l'écriture d'un nouveau courrier, je ne me suis pas encore penché sur la question, me concentrant pour l'instant sur la lecture de courriers (protocole IMAP et connexions chiffrées), mais je prend bonne note de la fonctionnalité décrite.
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: Si, ça existe.
Posté par cacatoès . Évalué à 4.
Oui, Thunderbird peut aussi déplacer les messages d'un compte IMAP vers une autre, ou bien vers un répertoire local. C'est le rôle «filtrage + livraison».
Bien que le protocole IMAP n'ait pas conservé d'instruction "Move", déposer un email, et effacer celui d'origine, ça revient à le déplacer.
Une fois livrés, plus rien n'indique de quel compte l'email est originaire. Les entêtes "Received-By" de l'email indiquent juste la série de serveurs SMTP via lesquels ils ont été transmis, mais il n'y a rien dans les entêtes mails qui corresponde au nom d'un compte email, sauf si ça a été ajouté par un filtre.
Tout ça pour dire que que mélanger les comptes ou avoir une arborescence commune, c'est en fait une situation naturelle pour l'email. Avec mutt, j'ai :
- une inbox (qu'on dira "principale"), qui contient des emails tout frais provenant de plusieurs comptes
- des inboxes pour mes listes de diffusion (peu importe le compte email d'origine, puis je ne vais pas m'inscrire 2 fois à la même liste.)
- et des inboxes qui correspondent à mes comptes email, et qui contiennent des emails plus vieux.
Comment je fais pour archiver les emails de l'inbox principale, et qu'ils retournent dans l'inbox du compte mail d'origine ?
Et bien je me sers d'une entête ajoutée par mon filtre (en l'occurence fdm).
Grâce à cette entête ajoutée, je pense que je n'aurais pas de difficulté à ce que mutt affiche le compte dont est issu l'email, mais je n'ai pas besoin de cette information.
[^] # Re: Si, ça existe.
Posté par Claude SIMON (site web personnel) . Évalué à 1.
Personnellement, le compte d'origine d'un mail m'importe peu, d'autant qu'il n'est pas rare que je change le compte d'affectation de mes alias. Faire passer ce lien entre courrier et compte au second plan est même l'un des objectifs de mon application. Mais la plupart des MUA sont, en quelque sorte, orientés comptes, donc, quelque part, je pense qu'il est préférable qu'un utilisateur qui utilisait ce genre de MUA puisse retrouver ce lien auquel il est habitué, bien que ce lien ne soit qu'accessoire au niveau de l'application.
Pour nous émanciper des géants du numérique : Zelbinium !
# Trojita
Posté par steph1978 . Évalué à 2.
J'adhère beaucoup aux principes du logiciel Trojita que j'utilise quotidiennement. Il simple (dépend uniquement de Qt), rapide (non, blazing fast) et conforme à la norme IMAP. Il supporte plusieurs compte en même temps mais pas avec une boite unifiée (et pas de stockage local).
Je n'ai que quelques défauts à lui reprocher dont je prévois de faire des remontés de but ou de pull requests.
Tout ça pour dire que le paysage des clients mail est déjà bien plein. Il faut trouver un positionnement pour trouver son public.
[^] # Re: Trojita
Posté par Claude SIMON (site web personnel) . Évalué à 1.
De ce que j'ai pu constater, on a, d'une part, les webmails, auxquels on peut accéder d'à peu prés n'importe quel dispositif connecté à Internet, mais qui ne sont, en gros, que des frontends IMAP, d'où le fait que l'on ne peut gérer qu'un seul compte mail à la fois, et, d'autre part, les clients natifs, qui peuvent proposer des fonctionnalités plus évoluées que celles disponibles avec IMAP, comme la gestion simultanée de plusieurs comptes en même temps, mais qui ne sont accessibles que d'une seule machine.
Ce que je cherche à obtenir, c'est le meilleur des deux mondes, c'est-à-dire pouvoir accéder à mon MUA d'un maximum de dispositifs connectés, et pouvoir cependant toujours disposer de toute les fonctionnalités de mon MUA, qui iront au-delà de celles disponibles IMAP.
C'est pour cela que mon MUA, contrairement aux MUA classiques qui accèdent directement aux serveurs POP3/IMAP, se connecte à un daemon, et c'est ce daemon se connectera aux différents comptes POP3/IMAP. Et comme c'est également ce daemon qui implémentera toutes les fonctionnalités de mon MUA, ces fonctionnalités seront disponibles quels que soient les clients utilisés (desktop, web ou mobile).
Pour nous émanciper des géants du numérique : Zelbinium !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.