Mettons tout de suite les choses au clair : on veut un client mail moderne, avec une jolie interface (qui fait wooosh wooosh, exactement) et orienté grand public. Dans cette optique, on va d'abord vouloir quelque chose d'ergonomique et d'utilisable dès le premier démarrage sans devoir installer un plugin ou aller bidouiller un fichier de config. Et l'importance de la gestion de GPG arrivera donc nettement après…
Donc, histoire que l'on se soit bien compris : on cherche un client mail pour la famille / les ami-e-s / un-e inconnu-e dans la rue, et pas pour un adminsys/dév/agnutollah qui n'arrive à pas comprendre que l'ergonomie et une jolie interface c'est important (et le pire, c'est que je sais très bien que même en écrivant ça, je vais avoir des retours me disant que Mutt c'est trop bien).
Et à voir certaines propositions/réactions sur twitter, il y a encore beaucoup trop de personnes qui n'arrivent pas à comprendre pourquoi Linux est aussi loin derrière sur le marché du desktop.
Faisons donc un tour de l'existant (si j'ai oublié quelque chose d'intéressant, n'hésitez pas à me contacter par mail/twitter) :
Logiciels
-
Astroid
- Interface pas top (mais GPG)
-
Bitmask
- VPN et GPG
-
Claws mail
- Interface pas top (mais GPG)
-
Evolution
- lourd O_o (mais GPG)
-
Geary (source)
- ça à l'air pas mal du tout, même si apparemment pas beaucoup de choix de configuration
-
Kontact (Kmail, intégré dans KDE)
- pas testé, donc pas de retour
- GPG
-
Mutt
- ah pardon, on cherche une interface grand public.
- mais GPG
-
Nylas N1 (source)
- Ça a aussi l'air pas mal du tout. Dommage, il faut obligatoirement un ID Nylas pour l'utiliser, et je ne sais pas vraiment ce qu'ils vont faire avec les données.
- Pantheon Mail (fork de Geary - source)
-
Thunderbird
- sight… apparemment toujours la référence sur Linux (j'avoue que mon expérience avec FirefoxOS pendant un an me donne envie de ###### Mozilla…)
Webmail
-
Mailpile :
- J'ai entendu pas mal de mauvais échos pendant un moment, si vous l'avez testé je veux bien des retours.
-
Rainloop
- Awwwww <3
- et GPG
-
Roundcube
- la référence du webmail libre, pas mal de thèmes disponibles, dont des sympas
-
SoGo
- mails + CalDAV + CardDAV + GroupDAV + Microsoft ActiveSync, plutôt orienté pro.
-
Zimbra
- l'autre référence du (pas que) webmail libre, mais seulement côté serveur (et beaucoup, beaucoup plus gros)
C'est intéressant de voir le nombre de logiciels avec une ergonomie poussive ou un design (un peu) vieux mais avec du support pour GPG. C'est quoi sa part de marché en dehors de notre petit écosystème déjà ?
Edit
- 2016-08-11 - ajout de Bitmask et de SoGo
# kmail
Posté par Goffi (site web personnel, Mastodon) . Évalué à 10.
Puisque t'as pas de retour, je te donne le miens.
Des clients que j'ai testé, c'est de loin mon préféré, sauf que des fois ça bloque et tu sais pas pourquoi, c'est peut-être juste ma config, mais c'est relou. 2 exemples très chiants:
des fois plus de courriel, suite à une mise en veille et un changement de réseau par exemple. Ça repart en relançant le serveur depuis akonadi console, donc pas franchement top et facile d'accès
sur mon ancienne machine j'avais beaucoup de problèmes réseau et je le configurais souvent à la main. Sauf que kmail ne détectait pas le réseau du coup, et refusait de sortir du mode hors ligne. Je n'ai plus ce problème sur ma config actuelle puisque je n'ai plus vraiment besoin de configurer à la main.
Sinon l'interface peut s'adapter (pour les listes de diffusion, on peut choisir comment c'est présenté par exemple), la recherche est simple et efficace (on entre un mot et ça donne les résultats immédiatement, c'est puissant (filtres, GPG, anti SPAM, etc), ça marche sans soucis avec plusieurs compte, et c'est bien sûr super intégré à KDE (que j'utilise aussi).
L'interface est peut-être pas super sexy par rapport à ce qui se fait aujourd'hui (je ne sais pas trop, je n'utilise que RoundCube et K9-mail à part Kmail, et il n'a rien à leur envier), et y'a des trucs pas forcément évident pour le grand public (le HTML est désactivé par défaut, à moins que j'ai configuré ça moi même je ne sais plus), mais ça reste un super client.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: kmail
Posté par karteum59 . Évalué à 3. Dernière modification le 16 août 2016 à 16:30.
La dernière fois que j'ai essayé KMail (ça date d'il y a de nombreuses années), le support du "disconnected IMAP" était complètement pété, et apparemment c'était un problème connu (ça m'avait flingué toute ma boite mail) => est-ce que ça s'est amélioré ?
(du reste, je me suis posé la question de mettre en place une sorte de proxy IMAP local avec KMail comme client lourd et offlineimap comme interface fiable avec le vrai service IMAP de mon ISP, mais j'ai toujours eu la flemme de le mettre en oeuvre…)
[^] # Re: kmail
Posté par Goffi (site web personnel, Mastodon) . Évalué à 5.
Je suis en IMAP avec téléchargement de tous les messages pour les lire hors ligne, ça fonctionne.
[^] # Re: kmail
Posté par gnumdk (site web personnel) . Évalué à 5.
Perso, depuis que j'ai migré de KDE vers GNOME, si il y'a bien un truc qui marche enfin, ce sont les mails/agenda/contacts (Geary/Gnome Calendar/Gnome Contacts)… Fini les recherches sur le web tous les mois parce que la synchro Akonadi a encore cassé…
Il y avait un article sur planet KDE il y'a quelques mois sur le fait que Akonadi était une bonne idée sur le papier mais bien trop complexe dans la réalité (et donc un échec).
[^] # Re: kmail
Posté par gyan000 (site web personnel) . Évalué à 7.
TL:DR : Kontact, ça semble refonctionner correctement. (chez moi)
J'ai également migré de KDE à GNOME Shell il y a quelques années à cause, entre autre, d'un KDE bordélique niveau options, pas du tout fini et, donc, vraiment buggé avec l'ensemble Nepomuk / Akonadi / Kontact complètement cassé et inutilisable. (et le thème par défaut oxygene était vraiment moche :) )
Depuis à peu près 2 ans je retente tous les 6 mois pour voir l'avancement et, à ce jour, cela fait 4 semaines, \o/, que je suis toujours sous KDE car :
- je n'ai pas eu de plantage de Plasma.
- les thèmes : plasma, icônes breeze et gtk / qt4 / qt5 breeze sont de plus en plus propres…
- … ainsi que les widgets genre celui gérant le son qui est enfin utilisable et pratique.
- akonadi gère parfaitement mes listes d’adresses et agendas (serveur sabredav) et mes comptes en IMAP et c'est la première fois que je n'ai aucun soucis avec akonadi.
-- à noter que depuis Frameworks 5.25.0, l'horloge numérique est de nouveau capable d'afficher les RDV et tâches des agendas distants
-- et kmail fait également des progrès : plus de problèmes avec les images intégrées aux emails. (jusqu'à maintenant)
- de plus en plus d'applications sont migrées vers KF5.
- baloo a rapidement et correctement indexé toute ma musique, mes vidéos, mes documents et mes contacts. (et ça fait beaucoup de fichiers)
- krunner est capable d'afficher tout ce qui est indexé par baloo et donc il est enfin capable d'afficher mes contacts : ça juste marche enfin correctement.
- Discover - le gestionnaire de paquets, basé sur package-kit est, certes, tout moche mais il marchotte enfin pas trop mal.
Bon, tout n'est pas parfait non plus. Par exemple, l'outil d'export / import de KDE PIM ne fonctionne pas vraiment… (Evolution est parfait pour ça) Toujours autant d'options dans tous les sens et la finition n'est pas aussi léchée que Gnome Shell mais je commence à retrouver un KDE qui fonctionne et ça, ça fait plaisir. Évidemment, comme c'est KDE, il faut passer du temps dans les options de configuration pour tout configurer au poil. Mais après, on a un environnement qui fonctionne comme on le souhaite.
Enfin bref, je trouves que ça progresse dans le bon sens en ce moment. Et oui, j'ai un peu débordé par rapport au sujet initial.
[^] # Re: kmail
Posté par MTux . Évalué à 2.
A une époque on ne pouvait pas avoir 1 arbo par compte mail comme dans Thunderbird , c'est toujours le cas ?
Et aussi le menu de configuration totalement surchargé et bordélique, KDE style.
# Rassurons-nous ...
Posté par dinomasque . Évalué à 6.
C'est pas mieux ailleurs !
Sous Mac, Apple Mail est un gros veau et la concurrence pas bien brillante (y compris les clients mails qui veulent ressembler à Twitter comme Geary sous Linux)
Sous Windows, Outlook est hors de prix et bien lourdaud pour un usage personnel.
Mon client mail idéal finalement, c'est le webmail de Fastmail (rapide, sobre, bien foutu). Je n'utilise de client lourd que sur mon ordi fixe pour avoir des archives locales de mes mails et sur smartphone.
PS: Claws c'est un truc de dino car il ne sait ni lire ni écrire de mails en HTML.
PPS: il y a 15 ans existant un client mail élégant, rapide et qui stockait les mails au format Maildir alors on pouvait faire ses recherches facilement
BeOS le faisait il y a 20 ans !
[^] # Re: Rassurons-nous ...
Posté par ianux (site web personnel, Mastodon) . Évalué à 1.
Claws-mail peut afficher du HTML via le plugin fancy.
Perso c'est le client que j'utilise depuis toujours (après être passé par Sylpheed), il fait le job sans être lourdingue. Le seul truc qu'on pourrait lui reprocher c'est le choix du format MH pour le stockage des mails. Et je ne vois absolument pas l'intérêt de rédiger un mail en HTML. Même l'utilisateur lambda n'y a aucun intérêt. Avez-vous jamais entendu quelqu'un se plaindre parce qu'il ne pouvait pas envoyer de SMS en Comic Sans ?
[^] # Re: Rassurons-nous ...
Posté par barmic . Évalué à 8.
Parce qu'il ne pouvait pas envoyer ou recevoir les smileys récents oui.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Rassurons-nous ...
Posté par Seb . Évalué à 10.
j'ai du mal à partager ce point de vue. Pouvoir mettre un peu de gras ou de souligné, un lien, ou une image ou un tableau dans un mail, c'est quand même pas anachronique en 2016.
[^] # Re: Rassurons-nous ...
Posté par groumly . Évalué à 10. Dernière modification le 17 août 2016 à 03:25.
Ca va quand meme.
striketrhoughc'est pratique sur un long threadApres c'est sur que si c'est pour envoyer du clipart, des fontes des bois ou changer la couleur a chaque fois, c'est pas tres utile. M'enfin, ca va, on est plus en 1998.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Rassurons-nous ...
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 4.
J'utilise aussi Claws Mail (après Sylpheed) j'y reviens toujours, c'est un client mail très bien mais :
- pas de possibilité de gérer des "identités" (adresses email expéditeur) sans créer un compte (SMTP) du coup quand on change son mot de passe SMTP faut remodifier les 20 comptes alors que le seul truc qu'on voulait c'est avoir une adresse expéditeur différente (mais sur le même SMTP)
- recherche fulltext pas top niveau interface, c'est un peu laborieux (mais y'a la recherche rapide qui est une tuerie, sérieux pourquoi y'a pas ça dans les webmail ?)
- j'ai pas trop réussi à avoir l'IMAP hors ligne complet (je suis souvent déconnecté) et qui marche, du coup j'utilise offlineimap et un dovecot local
- l'envoi de mail bloque un peu l'interface
Mais niveau bons côtés :
- très rapide (j'ai 15 ans d'archives mail, des dossiers avec plusieurs dizaines de milliers de mail, aucun souci)
- interface jolie, facile et personnalisable
- pas de HTML
- raccourcis clavier bien foutus
- bonne gestion des listes
- options complètes pour faire ce qu'on veut
- bon support GPG
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: Rassurons-nous ...
Posté par jyes . Évalué à 4.
Même retour d’expérience chez moi. Je reviens toujours à Claws-Mail. Juste un petit complément par rapport à deux points faibles que tu soulèves :
[^] # Si, c’est possible
Posté par Arthur Accroc . Évalué à 3.
Si, depuis la version 45. Il faut suivre, un peu… ;-)
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Si, c’est possible
Posté par jyes . Évalué à 2.
Merci du tuyau, je regarderai du coup. J’aimerai toujours Claws-Mail mais je ne vois aucun problème à apprécier plusieurs MUA :-)
[^] # Re: Rassurons-nous ...
Posté par Vroum . Évalué à 3.
De même, Claws-mail est le seul MUA que j'arrive vraiment à trouver exploitable.
Après plusieurs années avec Mutt, je désespérais de pouvoir écrire plus d'un mail à la fois sans avoir à recréer d'autres instances.
Les seuls désavantages sont pour ma part:
• l'interface en GTK2 vieillissante qui dénote un peu
• et la recherche un peu faiblarde (j'aimerais avoir que la liste des emails concernés et pas être obligés de naviguer à l'aveuglette)
Par contre, les options de configuration (et fichier clawsrc) sont assez riches et permettent pas mal de choses.
[^] # Re: Rassurons-nous ...
Posté par Storm . Évalué à 3.
Je rajoute à la liste le fait qu'il soit mono-thread : il devient passablement pénible à utiliser lors d'opérations un peu longues…
[^] # Re: Rassurons-nous ...
Posté par Astaoth . Évalué à 3.
Tu veux dire que c'est invivable quand t'as pas mal d'adresses courriels ! J'ai abandonné l'idée de l'utiliser, je suis retourné voir Thunderbird.
Emacs le fait depuis 30 ans.
[^] # Re: Rassurons-nous ...
Posté par Juke (site web personnel) . Évalué à 3.
Quel enfer ce truc, ça me ferait presque migrer.
[^] # Re: Rassurons-nous ...
Posté par zurvan . Évalué à 9.
oui, je ne comprends pas non plus ce journal, qui dit, en substance : « il n'y a aucun bon client pour le grand public sous linux, preuve s'il en est que linux n'est pas prêt pour le desktop, voici une liste de logiciels avec le détail, on voit que c'est que des trucs de geeks, bon pour thunderbird je ne mets pas de détails, ayant été déçu par firefoxOS ». Pourtant du grand public qui utilise Thunderbird sous windows ou linux, j'en connais, ça convient plutôt bien.
Thunderbird tout comme linux ne sont pas parfaits mais fonctionnent très bien dans la majorité des cas, et souvent mieux que ce qu'il y a en face.
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Rassurons-nous ...
Posté par skhaen (site web personnel) . Évalué à 2.
nope, j'ai dit que j'en voulais à thunderbird (il a tendance à crasher sur mon laptop), mais que l'expérience avec FirefoxOS n'aide pas).
Je l'utilise depuis, pfiouuu, au moins tout ça, et pour le moment je n'ai pas trouvé mieux.
# Mal au cœur
Posté par barmic . Évalué à 4.
Personnellement j'ai toujours mal au cœur quand on parle de MUA parce qu'il n'existe tout simplement aucun MUA qui correspond à l'utilisation que j'ai libre, non libre ou sous forme de service.
J'ai beaucoup utilisé gmail qui est vraiment bon sur le traitement et l'organisation des mails. La fusion des tags et des dossiers est vraiment agréable et permet de faire du 0-inbox de manière vraiment pratique (au lieu de ne pas faire de règles on crée des règles de tag, une fois que le mail est traité, on l'archive sans avoir à aller retrouver le bon tag dans l'interface), mais gmail est en fin de vie remplacé par inbox qui retire tout l'intérêt des tag (on passe de quelque chose de simple à quelque chose qui se croie intelligent, mais qui est moins simple à comprendre du coup), mais qui ajoute une fonction super de rappel (on peut dire à un mail de revenir ultérieurement - c'est vraiment chouette). Mais les 2 sont bugués (leur interface ne réagi pas toujours parfaitement et des fois la gestion du focus est mal foutue).
J'utilise thunderbird que je n'aime pas. Il ne me permet pas de rechercher mes mails efficacement (je ne sais pas comment rechercher les mails de foo.bar (at) exemple.com qui ont (ou non pas) de pièce jointe). Il y a quelques extensions mais quand je les ai essayées elles ne fonctionnaient pas.
mutt m'embête parce que je reçois des mails HTML et que ça m'embête d'avoir à changer de fenêtre pour voir les images…
Oui je pourrais et je devrais contribuer pour faire aller l'un des MUA dans mon sens, mais le travail me paraît tellement titanesque que je n'en ai pas le courage.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mal au cœur
Posté par Colin Pitrat (site web personnel) . Évalué à 2.
Tu es sur que inbox a vocation à remplacer gmail ? Je n'ai pas compris celà et vu que gmail est de plus en plus utilisé par des entreprises ça m'étonnerait. Personnellement j'ai testé inbox et j'ai bien aimé le concept mais je n'ai pas transitionné pour autant, trop habitué à gmail sans doute.
[^] # Re: Mal au cœur
Posté par Stibb . Évalué à 2.
Heureusement que Gmail n'est pas prêt d'être remplacé par inBox !
[^] # Re: Mal au cœur
Posté par barmic . Évalué à 2.
C'est ce que j'avais cru comprendre, mais si ce n'est pas le cas tant mieux.
GMail évolue encore du coup ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mal au cœur
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Pour commencer, tu peux mettre en forme une sorte de cahier des charges du meilleur mailer selon toi . Ensuite, c'est plus facile de parler technique, en partant d'une liste cohérente de fonctionnalités, rajouter des trucs "après coup" pouvant être super couteux.
gmail est le meilleur mailer que j'ai pu connaître. Le gros problème de gmail est bien sur l'absence de vie privé… J'aimerais parfois un peu plus de réactivité.
J'aurais aimer aussi l'intégration d'un service de dépôt de fichier temporaire (ou non ?) associé pour éviter les problèmes de la limite de 15 Mo. D'ailleurs, le moyen d'envoyer de gros fichiers sur internet, sont tous archaïque ou ultra-propriétaire. Il faut se monter un serveur ftp pour un copain, ou cliquer fichier par fichier pour envoyer des photos à une société d'impression.
"La première sécurité est la liberté"
[^] # Re: Mal au cœur
Posté par barmic . Évalué à 3.
Tu as raison, ça commence même avec un début de workflow (→ comment travailler avec les mails ?) qui part du très connu 0inbox. Ce serait marrant à faire et assez nouveau pour moi.
J'ai même l'impression que c'est déjà coûteux de modifier l'existant…
Clairement, l'API dans les mails (ce qui permet d'envoyer des mails qui ont des actions directs) est par exemple une excellente idée.
Je n'ai pas essayé, il ne le fait pas avec drive ? Office365 le propose (et ça n'a pas l'air bien foutu dans outlook vu qu'on me demande systématiquement de le renvoyer en tant que pièce jointe).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mal au cœur
Posté par Epy . Évalué à 2.
Quelque soit le client il faudrait intégrer la prise en charge de Filelink qui est dans Thunderbird depuis quelques versions
https://developer.mozilla.org/fr/docs/Mozilla/Thunderbird/Filelink_Providers
Ça semble vraiment pratique et bien foutu, surtout c'est ouvert pour l'auto hébergement. Les applis d'hébergement de fichiers vont s'y mettre d'autant plus vite qu'il n'y a de client qui supportent cette solution àmha.
Actuellement TB met un bandeau dans le mail en cours de rédaction dès que les pièces jointes dépassent un quota paramétrable et suggère l'un des services configurés dans ses paramètres
[^] # Re: Mal au cœur
Posté par Elwood_Blues . Évalué à 2.
La recherche est une catastrophe c'est vrai. Je passe par les filtres de messages, tu peux plus facilement retrouver tes mails.
[^] # Re: Mal au cœur
Posté par Bruno (Mastodon) . Évalué à 6.
| J'utilise thunderbird que je n'aime pas. Il ne me permet pas de rechercher mes mails efficacement (je ne sais pas comment rechercher les mails de foo.bar (at) exemple.com qui ont (ou non pas) de pièce jointe). Il y a quelques extensions mais quand je les ai essayées elles ne fonctionnaient pas.
Pas besoin d'extension, il suffit de cliquer sur rechercher dans le menu et de simplement mettre les conditions , dans ton exemple : DE contient FOO. bar at exemple.com et STATUT des Pièces est AVEC Pièces jointes (ou pas..)
Pour ma part j'utilise Thunderbird sous linux depuis toujours ;-) et il fait tout ce dont j'ai besoin dans un contexte professionnel y compris agenda partagé et synchro avec mon smartphone/tablette.
[^] # Re: Mal au cœur
Posté par barmic . Évalué à 2. Dernière modification le 17 août 2016 à 10:03.
Je trouve bien un "Statut", mais ça ne me permet que de rechercher les mails lu, non lu, nouveau, transférés, suivi,…
Comment je fais pour le « des pièces jointes » ?
Ou alors tu parle de la recherche via le Ctrl+k ? Je suis pas très alaise avec cette recherche (un champ texte pour tout faire et du filtrage après coup assez limité). J'aime bien par exemple éliminer le bruit (vu que l'affichage n'a rien de compact) en indiquant que le mot est dans le sujet.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mal au cœur
Posté par Bruno (Mastodon) . Évalué à 1.
C'est bien de cette recherche là dont je parle , ça doit être un souci de version car en V45.2 de thunderbird j'ai bien une option "statut des pieces jointes" ainsi que d'autres comme "statut indésirable"
[^] # Re: Mal au cœur
Posté par barmic . Évalué à 3.
Ben si pourtant… https://gist.github.com/barmic/6775d204cc33700e667efce0a7f05e96
C'est pas une extension qui te l'ajoute ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mal au cœur
Posté par Bruno (Mastodon) . Évalué à 1.
A priori non , en extension j'ai :
Lightning
Inverse Sogo Connector
Pas de plugins.
Dans les préférences onglet avancé, la recherche et indexation globale est activée mais je pense que ce n'est pas lié.
[^] # Re: Mal au cœur
Posté par JJD . Évalué à 1.
Attention au fait que les options de recherche ne sont pas les mêmes suivant que l'on coche ou pas la recherche sur le serveur.
Avec cette option, on n'a pas, par exemple, la possibilité de choisir le statut des pièces jointes ou des indésirables (mais on y gagne la recherche dans le corps du message).
[^] # Re: Mal au cœur
Posté par barmic . Évalué à 3.
Elle est bien cochée chez moi aussi.
J'ai pas trouvé l'option (ni dans les préférences globales, ni dans celle de mon compte), tu peux m'indiquer où elle est ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mal au cœur
Posté par fortytwo . Évalué à 4.
Tout aussi personnellement, j'ai du mal avec gmail, dont je trouve l'interface archi confuse. Exemple, quelle idée de cacher les contacts sous un bouton Gmail. Je n'aime pas non plus la confusion tags / dossiers, je préfère séparer les concepts. Analogie avec les docks qui fusionnent lanceur et applications lancées, et que je déteste … mais ce n'est qu'un point de vue.
Il est vrai que je n'utilise pas beaucoup Gmail, à cause de son interface mais aussi de la confidentialité. Je manque donc d'habitude et j'ai pu constater par le passé que l'utilisabilité est énormément liée à l'habitude. Argh quand ma propre mère m'a montré comment éjecter une disquette sur un Mac en glissant-déplaçant l'icône disquette sur la poubelle ! Ça ne me serait jamais venu à l'idée (ou alors pour effacer le contenu ?).
Sinon, pour les recherches sur Thunderbird :
- Ctrl F pour les recherches complexes
- premier champ de recherche avec "De" contient (ou est) foo.bar (at) exemple.com
- deuxième champ "Statut des pièces jointes" est "Avec pièces jointes"
Pour passer mes journées de boulot à criser contre Outlook et sa recherche, j'aime Thunderbird.
[^] # Re: Mal au cœur
Posté par fortytwo . Évalué à 1.
Oups : Ctrl Shift F au lieu de Ctrl F
[^] # Re: Mal au cœur
Posté par ArnY (site web personnel) . Évalué à 2.
Pour la recherche par expression à la gmail il y a "Expression Search / GmailUI: https://addons.mozilla.org/en-US/thunderbird/addon/gmailui/?src=ss cela te permet d'utiliser des expressions dans la zone de recherche de Thunderbird, pour reprendre ton exemple:
in:inbox from:foo.bar@exemple.com a:yes
Te donnera les mail de ta boite de réception provenant de foo.bar@exemple.com ayant un attachement.
# Mutt
Posté par Yuul B. Alwright . Évalué à 10.
Mutt c'est trop bien.
[^] # Re: Mutt
Posté par Juke (site web personnel) . Évalué à 10.
Trop, oui.
[^] # Re: Mutt
Posté par MyLordAngus . Évalué à 2.
Un peu trop bloat à mon goût, vive /usr/bin/mail :)
# Vue conversation dans evolution
Posté par azmeuk (site web personnel) . Évalué à 5. Dernière modification le 16 août 2016 à 15:43.
Ça fait des années que j'attends qu'apparaissent les super mockups pour une vue conversation dans evolution. D'ailleurs, j'ai du mal à comprendre que ce genre de fonctionnalités ne soient pas la priorité du projet GNOME. Le jour où cette vue arrive, je crois que je n'aurai plus de reproche à faire à evolution.
Du coup, j'ai mis un bounty dessus.
[^] # Re: Vue conversation dans evolution
Posté par Reihar . Évalué à 2.
Un add-on pour Thunderbird existe : Conversations. Ça fait parti des raisons pour lesquelles je suis repassé à Thunderbird depuis Claws, avec Lightning et la gestion de l'archivage des emails (pratique pour l'inbox 0).
Et depuis que j'ai découvert Cardbook, repartir semble difficile.
# Explication
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10. Dernière modification le 16 août 2016 à 15:43.
Concernant ta dernière question, ou plutôt ce qu'elle sous-entend :
Ça n'a rien d'étonnant. Un logiciel libre est fait pas un ou des auteurs, selon leurs désirs. La plupart du temps, les différents MUA ont une cible d'utilisateurs particulière et répondent à leurs besoins, mais dans tous les cas, il y a deux cibles particulières privilégiées :
Cela explique pourquoi, dans presque tous les cas, il y a une prise en charge d'OpenPGP : soit un auteur l'utilise, soit quelqu'un d'intéressé l'a non seulement demandé, mais codé. Que ça ne soit pas un besoin de la plupart des gens, ou même de la plupart des utilisateurs de ce logiciel, n'a aucune importance : une fonctionnalité a été proposée, et acceptée, indépendamment de l'avancement des autres fonctionnalités possible. Je veux dire pas là que cette fonctionnalité particulière n'entre pas en concurrence avec les autres, elle n'a pas été codée en priorité au détriment du reste, mais seulement que quelqu'un la voulait et était près à la coder.
Par ailleurs, concernant la question elle-même :
Je me dois de signaler que, quand on code un logiciel, on n'a pas forcément pour but de répondre à un besoin important. On peut aussi vouloir favoriser certains usages, et OpenPGP en est justement un parfait exemple, son implémentation initiale Pretty Good Privacy ayant précisément été développée par Phil Zimmermann pour promouvoir la cryptographie comme moyen de défense de la vie privée face à la facilité d'abus de la part des services d'espionnage. Et ce, à fort juste titre, comme l'histoire la récemment montré.
Bref, considérer une fonctionnalité comme peu importante parce que peu de gens l'utilisent, c'est une assez grave erreur.
# Sylpheed
Posté par glebelg . Évalué à 4.
j'ai installé Sylpheed sur le vieux pc de ma fille…et ca m'a l'air pas mal du tout (GPG ok de base)
Site officiel
[^] # Re: Sylpheed
Posté par Wendigo . Évalué à 2.
Dans le même genre, il y aussi Claws-Mail, qui est un fork de Sylpheed justement ;)
# RE Geary
Posté par Wendigo . Évalué à 2.
Geary a d'autres problèmes :
Sinon, j'utilise aussi Claws, il est franchement top, mais son interface a clairement besoin d'un rafraîchissement …
Et apparemment les devs ne sont pas du tout pressés d’adopter GTK3.
[^] # Re: RE Geary
Posté par Moonz . Évalué à 3.
Correction : il transmet un hash (SHA-1 je crois) de ton contact. C’est déjà vachement moins problématique (surtout qu’il n’a aucune idée de qui vient la requête).
[^] # Re: RE Geary
Posté par Wendigo . Évalué à 1. Dernière modification le 17 août 2016 à 01:13.
Merci de le préciser, je ne l'ai pas fait dans mon commentaire. Ça reste du MD5, c'est encore pire XD
Cela permet tout de même de créer un réseau et/ou utiliser une rainbow table si l'adresse se trouve dedans.
Chacun est libre de faire ce qu'il souhaite, mais personnellement, je ne le trouve pas trop idéal.
# Les "webmails"
Posté par Astaoth . Évalué à 2.
Dans ta partie "Webmail" tu y mélanges des groupwares. La différence entre les deux est que les webmails tournent sur un serveur web classique, là ou les groupwares ont leur propre serveur.
Une autre différence intéressante pour les utilisateurs entre les webmails et les groupwares est que ces derniers permettent généralement la relève imap de d'autres comptes, voir également l'envoie, comme un client lourd, dans la même vue.
De mon côté j'utilise justement SOGo pour pouvoir relever facilement tout mes comptes courriels. À côté je le trouve simple à utiliser mais configurable si besoin est, et c'est toujours pratique de pouvoir synchro ses contacts et son calendrier avec son tel.
Pour Rainloop j'aime beaucoup ce qu'ils font, j'attends juste que les features les plus demandées soient ajoutées pour migrer ;). À noter aussi que la création de filtres sieve est possible, et dans une interface pas trop dure à prendre en main.
Emacs le fait depuis 30 ans.
[^] # Re: Les "webmails"
Posté par Colargol . Évalué à 2.
Attention SoGo vient de changer de modèle économique(https://philippe.scoffoni.net/groupware-sogo-change-modele-economique ) L'installation des nouvelles versions risque de se compliquer.
# Le futur c'est demain
Posté par devnewton 🍺 (site web personnel) . Évalué à 10.
Comment est-ce que tu imagines le client mail idéal?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# Retour depuis le turfu
Posté par Dinosaure (site web personnel) . Évalué à 9.
Je viens à peine de terminer une mission pour un laboratoire qui consiste à implémenter un logiciel permettant de traiter des emails en OCaml: MrMime.
Cette mission m'a permis de comprendre quelque chose d'essentielle à propos des emails et des MUAs: un email, c'est extrêmement compliqué.
Tout le monde le sait plus ou moins et rien que parler d’adresse email, cela hérisse le poil de beaucoup de développeurs qui ont eu la curiosité de se renseigner sur le sujet (je ne parle pas, bien entendu, des personnes qui se contentent d'une regex).
En effet, on a environ 8 standards différents (selon ce qu'on souhaite gérer) à propos des emails avec des limitations datant de la RFC822. Cette dernière ayant pas mal de zones d'ombres (le folding-whitespace et les commentaires entre autre) heureusement clarifiées par la dernière RFC5322. On rajoute à cela le support de l'UTF-8 (depuis 2012 avec la RFC6532) sans oublié la RFC2047 (si on est resté old-school) à propos de l'inline encoded string et pour finir le couple RFC2045/RFC2046 concernant le format MIME. Après, il y en a d'autres ici ou là concernant certaines mises à jour.
Bref, un vrai bordel où il devient difficile d'allier compatibilité et performance, résilience et erreur - bref, tout les problèmes d'un développeur lambda.
Mais le point et c'est ce qui caractérise les emails, c'est que l'email reste le moyen de communication sur internet par excellence. En faite, sa complexité, pour moi, découle du simple fait que c'est le protocole de communication entre nous tous. En ce sens, il est tout aussi brouillon ou hasardeux que nos langues naturelles dans une moindre mesure (puisqu'il doit être compris aussi par un ordinateur).
En somme, je considère que faire un MUA est très/trop complexe dans le sens où la définition globale d'un email reste (heureusement) très informelle et qu'on peut difficilement trouver une façon de lire/traiter/manipuler des emails d'une manière qui conviendrait à tous. Il n'y a heureusement pas une manière standard d'extraire l'information que l'on cherche dans un email et que, même si on arrive à trouver des patterns (comme un
multipart/alternateavec le même message au format texte ou au format HTML) il n'empêche qu'on tombe toujours sur des surprises pas si exceptionnelles que ça.Tout ça pour dire que une large partie du problème (à savoir pourquoi on a pas un best MUA) reste enraciner dans le format même de l'email et que d'une certaine façon, c'est mieux comme ça.
[^] # Re: Retour depuis le turfu
Posté par Sufflope (site web personnel) . Évalué à 1.
Je ne suis pas d'accord (sur le retard en ergonomie des clients causé principalement par la vieillesse de SMTP, pas du bordel d'icelui).
Les tags au lieu des dossiers, une interface sympa, une intégration poussée avec d'autres services, une recherche puissante… c'est faisable même avec certains courriels legacy merdiques reçus (de toute façon si t'arrives même pas à les parser, même avec des fonctionnalités rudimentaires tu feras comment pour les afficher ?).
[^] # Re: Retour depuis le turfu
Posté par Dinosaure (site web personnel) . Évalué à 3.
Je parle pas de SMTP mais surtout de l'email à la base déjà - SMTP rajoute une autre complexité et des limitations qui se répercutent sur l'email d'ailleurs ou sur les protocoles (comme IMAP). Mais le fond du problème reste avant et pour tout cette définition informelle du standard de manière général et toutes les possibilités1 que peuvent proposer l'email de manière globale.
Ceci rajoute un bruit dans le traitement qui pourrait être ignoré mais c'est justement à ce moment là qu'on prends position. Mon point n'est pas de considérer que l'email et unparsable ou encore que le legacy email venant de la RFC822 pose fondamentalement un problème (il en pose un ceci dit mais pas fondamental) mais de signaler que la complexité du MUA vient en partie (mais pas que) de la complexité de l'email et pour une simple raison:
Les possibilités d'utilisation d'un email ne sont pas exhaustives.
En cela, on peut considérer comme tu le dis un système avec des tags (mais pourquoi on utiliserait pas les dossiers ?), une interface sympa, une intégration avec d'autres services (qui ne feront que traiter un subset de l'email) et une recherche puissante (qui se définira forcément sur certains axiomes).
Mais dans tout ces cas, il y a une prise de parti qui se fera forcément au détriment de d'autres possibilités des emails. Et c'est un peu là tout le mauvais côté mais aussi le succès de l'email. C'est que chaque utilisateur a sa propre utilisation des emails - et il suffit de voir la complexité des fichiers de configuration d'
eximetpostfixpour s'en rendre compte. Et c'est en cela que faire le best MUA pour tout le monde n'est pas possible.Et toutes ces possibilités de l'email ne sont que pas liées au MUA, ou encore au protocole ou même à l'environnement desktop qu'on utilise mais à l'email lui même en réalité. Et c'est bien pour ça qu'on l'utilise :) !
Après, bien entendu on peut faire tout ce que tu dis et ça correspondra à ton utilisation et si tu y trouves ton bonheur, tant mieux. Mais puisque le standard nous le permet, nous pourrions utiliser l'email d'une autre manière que la tienne et y trouver tout autant notre compte.
je pointe celle-ci particulièrement parce que beaucoup de site web ne la gère pas mais je vais pas vous lire toutes les RFCs non plus! ↩
[^] # Re: Retour depuis le turfu
Posté par Sufflope (site web personnel) . Évalué à 4.
On prend position sur "ce que mon MUA de 2016 arrivera à tirer de tes vieux mails" mais pas forcément "ce que tu seras encore en droit de faire avec ton logiciel qui te plait".
Parce qu'une hiérarchie de dossier n'est qu'une projection d'un système multi-dimensionnel sur une dimension, donc qui peut le plus peut le moins.
Oui et alors ?
Imaginons un MUA avancé A, qui me permet de rechercher sur un prédicat P qui m'intéresse. La détermination de la valeur de ce prédicat pour un courriel donné implique la disponibilité d'un en-tête H absent de la RFC originelle. Et un MUA classique B ne permettant pas cette recherche.
Imaginons un courriel C disposant du dit en-tête et un D legacy qui ne l'a pas.
Avec A je peux trouver C et pas D. Avec B je ne trouve rien du tout puisque je ne peux pas chercher suivant P. Tu pourras rétorquer qu'il peut être trompeur de trouver un des deux résultats avec A (je peux me dire "ah bah il n'y a que C alors" et complètement passer à côté de D). Je répondrai avec une stat Zénitramienne et rétorquerai que je m'en fiche, à part les ML de barbus qui de toute façon ont pour vœu secret de tuer SMTP au profit d'un autre machin, tout le monde ajoute H à ses courriels.
Non je ne vois pas pourquoi. Si, à la limite, si ton workflow est "j'ai absolument besoin de dossiers et surtout pas de tags" ; maintenant j'attends un exemple concret. Et si vraiment tu es dans ce cas-là, bah utilise pas mon MUA.
Non. Même si une RFC plus stricte permettrait sans doute de faciliter les choses, rien ne t'empêche d'avoir un MUA ultra avancé qui répond à 99% des attentes de 98% des gens grâce à de puissantes heuristiques (hormis le temps, l'argent et les compétences évidemment). Le tout sans empêcher quoi que ce soit (tu peux par exemple très bien implémenter ta super recherche à base d'Elastic Search en y dénormalisant les données de tes courriels, permettant ainsi de les lire avec un MUA rustique à côté (et les courriels pourris du millénaire dernier ne remonteront pas sur des recherches structurées, uniquement en fuzzy ; et ?)).
Tout à fait mais je ne vois toujours pas en quoi un MUA me satisfaisant t'en empêcherait. Et puis le sujet du journal étant "votre mutt là c'est de la marde et je veux gmail en libre" (je critique pas, j'ai à peu près la même position) je pense être plus en phase.
[^] # Re: Retour depuis le turfu
Posté par Dinosaure (site web personnel) . Évalué à 4.
Si on considère le vieux email comme marginal mais en vérité non. Le standard des emails est une évolution. Dans mon implémentation je ne pouvais strictement pas considérer seulement la RFC5322 (qui est le dernier vrai standard des emails) sans ses antécédents qui sont RFC2822 et RFC822 - dans la première, on fait une distinction entre règle obsolète (ce qui correspondrait à l'email legacy) et les règles de cette dite-RFC.
Donc en vérité, le legacy n'est certainement pas disjoint du dernier standard (comme peut l'être Python 2 et Python 3 par exemple) et il faut le gérer. Il faut le gérer d'autant plus que la RFC2045 qui parle du format MIME (donc l'essentiel de tes emails) se dit compatible avec la RFC822 (et non pas la RFC5322, donc la dernière en date). Donc en vérité, il n'y a pas de vieux/nouveaux mails mais des mails dont la définition s'étale depuis 1982.
La finalité est qu'on a un standard qui est décrit sur environ 8 RFCs différentes et qui définissent chacune certains aspects de l'email. Pour preuve, la RFC822 n'a jamais dit formellement si il devait y avoir des espaces entres l'en-tête et les deux points. La finalité est que certaines personnes ont mis des espaces et d'autres non et que la RFC2822 à considérer qu'il ne devait pas y avoir des espaces mais qu'un MUA devait les gérer. Alors oui, c'est de l'ordre du détail mais ça montre surtout une évolution à la fois basé sur des contraintes techniques (pour que l'email reste compréhensible pour l'ordinateur) et des comportements qui, à la base, étaient indéfinies.
La RFC2231 définit elle une contrainte technique qui n'a plus lieu d'être aujourd'hui si on considère la RFC5322 et la règle des 80 colonnes qui ne concernerait qu'une utilisation très marginale - quoique. Un MUA doit donc gérer ce cas même si il ne se présente que très peu.
Ces différents points (et tu peux en trouver pas mal sur l'histoire des emails) ont laissé place à une liberté très forte sur le format de l'email en général. Et de cette liberté, il y en ait résulté des manières d'utilisations différentes qui sont devenus la norme (leurs normes) pour certaines personnes.
Un MUA digne de ce nom n'a pas à essayer de tirer le mieux possible les informations d'un email. Il le doit. Et ce n'est pas une question d'user-experience mais vraiment une question du standard. Il s'agit même parfois de faire des concessions sur les règles elles-mêmes afin de fournir cette fois-ci le best-effort de traitement car il existe beaucoup d'emails qui ne respectent pas le standard - et je pourrais te parler de cas précis comme le préambule ou l’inexistence du close-delimiter dans un email multipart (dieu sait que ça arrive), pour le coup ce genre de cas qui sont hors des règles mais qui existent, il y en a beaucoup.
Ce qui fait que du bruit, il y en a et certains vont trouver ça normal d'avoir la possibilité de lire/écrire l'épilogue d'un multipart alors que concrètement, pour mon utilisation, ça ne sert strictement à rien. L'email se retrouve donc à la fois tirailler entre des règles qui doivent être strictes et bien définis pour qu'il puisse être manipuler par un ordinateur mais aussi par des cas d'usages qui se sont tout simplement définis avec le temps et qui sont hors du standard (ou à posteriori comme pour la RFC6532 et le support de l'UTF-8 - d'ailleurs on retrouve encore des emails qui utilisent le Latin1 alors que le standard ne l'autorise pas).
En vérité, la question à se poser est: qu'elle est le critère permettant de considérer que cette email appartient à tel tag ou pas (après, je suis d'accord avec toi sur l'histoire des dossiers). Et c'est une vraie question. On peut considérer que le
From:suffit alors que d'autres vont considérer qu'il faut aussi baser sa recherche sur leSubject:ou encore rajouter (et bon dieu que ça arrive) un en-tête hors de la norme qui puisse réellement correspondre aux axiomes qu'on souhaite. Sur ce dernier, c'est un peu les portes de l'enfer qui laisse place à une règle que j'apprécie vraiment qui est leunstructureddata où on a, à la fois, les commentaires, le folding-whitespace et une notion d'espace significatif ou pas selon la RFC2047 (quand bien même on ait la RFC6532 et le support de l'UTF8) ce qui laisse donc un degré de liberté phénoménal que les providers d'email usent et abusent.La aussi le MUA peut difficilement en tiré quelque chose de manière exhaustive puisque ce sont des règles considérées par le provider et la manière dont Google gère ces informations est différente de celle de Laposte. Lequel est le meilleur ? Lequel le MUA doit traiter, doit il le traiter ? Bref, des surprises qu'un MUA peut juste parser (et en soit, ce n'est pas difficilement parsable, il faut tout de même utiliser un certain trick) mais doit il considérer l'information comme pertinente ou pas ?
C'est là où nous avons un problème. Les seules en-têtes obligatoires selon la RFC5322 sont
From:etDate:(dont certains emails se fichent d'ailleurs). Se rajoute ensuite leContent-Type:de la RFC2045 mais qui n'est même pas obligatoire. Mais en vérité c'est les 3 seules en-têtes que tu es un peu près (oui parfois ils ne sont pas dans l'email) sûr de toujours retrouver. Difficile derrière de considérer une quelconque recherche avec ce peu d'information. Mais c'est le point de l'email. C'est que tu puisses justement laisser tes informations qui peuvent être en contradiction total avec d'autres MUAs - on peut imaginer que tu veuilles insérer des informations avecXXX-From:par exemple alors qu'il peut exister un provider ou un MUA qui traite cet en-tête selon sa norme (et pas la tienne), dans cette situation, comment doit réagir ton MUA ? Échouer ? Ignorer ? Essayer et mettre cette email sous le tapis ?C'est là où intervient une notion qui est, à la fois définit par le standard, et à la fois totalement extérieur. C'est les conventions d'utilisations. Elles existent puisque le standard le permet et ce sont des règles mais personne n'assure que tout le monde les respectent.
Ton MUA prends partie forcément. Après, on peut considérer qu'il se débrouille bien (ou pas) mais il essaye car le degré de liberté d'un email est bien trop grand pour qu'il puisse s'y appuyer et en sortir quelque chose de pertinent tout le temps - il va même utiliser ce degré de liberté dans la génération des tes emails (en tout cas, c'est ce que fait Google). Il va donc forcément omettre des cas d'utilisation (il va tout simplement omettre des en-têtes définis par d'autres providers) et quand bien même il essayerait d'en tirer le meilleur, ce sera jamais de manière exhaustive.
De plus en plus d'ailleurs germe l'idée du Machine Learning pour trier les emails - tu te doutes bien à partir de là de la complexité de la question.
Bah en faite, c'est ma comparaison avec les langues naturelles. Cela évolue avec le temps et les comportements. Il n'y a pas une définition claire et précise de ce que devrait être un email de manière canonique et en vérité, c'est normal. C'est un moyen de communication qui a évolué avec les moyens qui nous sont mis à disposition (rien que l'idée de pièce jointe). Et cela continuera à évoluer et cela continuera à être un bordel sans nom.
Le point particulier de l'email et c'est se qui fait sa force, c'est qu'il a réussi à être un tandem entre la rigidité d'une machine et notre liberté d'expression (que ça soit dans le fond mais surtout dans la forme) et c'est pour cette raison qu'il n'y aura pas de best MUA. Considérer qu'il n'y a qu'une façon de lire et d'écrire ses emails, c'est faux et le standard le montre rien que par son nombre hallucinant de RFCs (j'en ai fait des RFCs mais en faire une dizaine pour un seul format, c'est bien la première fois). L'idée qu'il n'y est une seule et unique manière de communiquer n'est pas envisageable. Et là, la meilleur preuve qu'on est c'est la manière dont on communique avec les gens autours de nous, il y a certes un socle universel (et c'est le propos de ces RFCs) mais tellement pauvre qu'on est limité (et c'est là où on est bien loin de se que devrait proposer un MUA). Donc on rajoute des règles (de manière illégitime souvent), on essaye de comprendre les autres tant bien que mal (selon leurs règles) et on essaye d'échanger quelque chose.
L'email n'est qu'une extension rudimentaire de notre moyen de communication, et de ce faite, il ne fait qu'en découler. Le standard essaye d'évoluer en bien, mais il doit rester accessible sans prendre partie d'où sont aspect très rustique (le
CC:par exemple veut dire Carbon Copy) et rudimentaire. Le MUA lui, est plus haut niveau mais il repose sur les libertés que lui offre le standard pour étayer son cas d'utilisation quitte à fermer les yeux sur d'autres règles.Une des plus parlante reste la RFC6532 avec le support de l'UTF8. C'était une vraie question surtout pour les asiatiques. On s'est bien contenté pendant longtemps de la RFC2047 (nous européen avec nos accents) mais comment faisait les asiatiques d'après toi pour communiquer ? Et, était-il légitime à l'époque de considérer l'UTF8 comme étant le standard de facto ? Comme il était légitime de considérer un email en Latin1 valide ? L'IETF a tranché en faveur de l'UTF8 (et c'est normal) mais non seulement on a attendu 2012 pour ça mais en plus, ça n'invalide en aucun cas le reste des emails (qu'on puisse le considérer comme legacy ou pas d'ailleurs).
Alors bien entendu, c'est facile (et même normal) de dealer avec l'UTF8 de nos jours. Mais ça montre surtout que ce n'est pas un simple standard fixe sur des règles strictes et qu'il évolue et qu'il a intérêt à évoluer et que ces évolutions ne font pas partie de quelque chose de définissable formellement.
[^] # Re: Retour depuis le turfu
Posté par barmic . Évalué à 4.
Et tout ça, ça empêche thunderbird ou gmail de réduire la priorité d'une adresse qu'il te propose que tu as déjà ?
Fait le test tu as 2 adresses paul.brasseur at provider.com et paul.foo at provider2.net. Tu veux envoyer un message aux 2, tu commence par écrire "paul". On te propose les 2 adresses triées par ordre alphabétique. Tu choisi le premier, tu valide. Tu recommence et là, on te propose la même foutue liste ! On est incapable de mettre les adresses déjà utilisées à la fin pour les 4 gars dans le monde qui se tapent des délire à mettre plusieurs fois le même destinataire ?
Il y a un gap immense entre la daube qu'on a aujourd'hui et ce sont vos parlez.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Retour depuis le turfu
Posté par zurvan . Évalué à 2.
oui on pourrait faire ça et il y aura sans doute un vieux geek qui ramènera sa fraise en disait que cette possibilité, lorsqu'il utilise une centaine d'adresses, ça fait ramer son pentium 300 mhz
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Retour depuis le turfu
Posté par barmic . Évalué à 1.
La recherche est déjà bien plus consommatrice de ressources, on peut imaginer pouvoir l'activer par une option,…
Le problème ce n'est pas la technique, ce ne sont pas les ressources,… Le problème c'est qu'on ne cherche pas à améliorer l’expérience de l'utilisateur.
« Il veut envoyer un mail, on envoie un mail et on lui propose ça gratuitement donc il va pas la ramener en plus ! »
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Retour depuis le turfu
Posté par zurvan . Évalué à 2.
oui, c'est sûr, d'ailleurs je la désactive toujours lorsque j'installe du thunderbird chez les gens, en revanche je leur explique comment utiliser le filtre, bien plus utile.
l'idée de filtrer les adresses déjà mises dans le champ d'expédition n'est pas bête, peut-être qu'une extension pourrait faire ça (je n'ai rien trouvé mais tu peux la coder, c'est libre toussa). Malgré tout, ça reste quand même assez marginal comme utilisation :
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Retour depuis le turfu
Posté par zurvan . Évalué à 6. Dernière modification le 17 août 2016 à 17:29.
finalement, je préfère me faire lapider et utiliser (et conseiller) thunderbird qui est plutôt complet, plutôt que de subir un webmail qui a prétendument une jolie interface qui fait wooosh wooosh mais qui va rester peu pratique au final (et qui sera abandonnée dans un coin de github dans 8 mois ou qui est lié à un service proprio)…
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Retour depuis le turfu
Posté par barmic . Évalué à -2.
hum hum…
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Retour depuis le turfu
Posté par barmic . Évalué à 3.
Sincèrement tu aspire les adresses mail pour que l'autocomplétion des mails soit si consommatrice ?
Non. Il suffit de connaître des Benoîts, des Benjamins, des Florents, Florients, Florence, etc Le fait que tu n'es pas rencontré le problème n'indique en rien que le problème n'existe pas.
Pourquoi 20 ? À partir de 2 c'est chiant parce que le comportement est juste ridicule. Quand tu envoi beaucoup de mail, tu as l'habitude d'ajouter les adresse en tapant 3 ou 4 caractères, puis entrée presque en automatique. Devoir naviguer dans une liste inutilement c'est juste bête.
Mais surtout…
Ouai, en fait ça ça a tendance à augmenter le nombre de collisions plus qu'autre chose, hein ? Et surtout il faut se former, il s'être défini un trigramme qui convient bien pour chaque cas tout ça parce qu'ils ne font pas un foutu
grepbasique…Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Retour depuis le turfu
Posté par zurvan . Évalué à 2.
je parlais de la recherche globale dans les emails
non aucune formation, la recherche est naturelle, ça fonctionne avec "pau bra ma" mais également avec "pa br m" ou même des parties du nom comme "sseur chin"
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Retour depuis le turfu
Posté par barmic . Évalué à 3.
Qu'est-ce que ça vient faire là ? On me dit que le filtre c'est trop lourd pour un 300MHz,je dis que la recherche dans l'index pour produire l'autocomplétion est bien plus lourde.
Pour l'autre si si il faut une formation, il faut que tu t'entraine à savoir que quand tu veux envoyer un message à tel Jacques c'est "dup" qu'il faut écrire et ainsi de suite. Non ça n'est pas naturelle d'appeler les gens par des vous de leur noms ou leur prénom. Et comme j'ai dis ça augmente le nombre de collisions.
Mais là je parle de choses triviales, hein ? De la même façon donner une importance plus élevée aux contacts que tu contact plus souvent ces derniers temps et à ceux à qui tu envoie souvent des mails ensemble c'est pas complètement fou comme idée (Gmail le fait je crois, il te propose des contacts, c'est bien mais ça casse un peu le flux de travail). C'est moins simple à implémenter par contre.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Retour depuis le turfu
Posté par Marotte ⛧ . Évalué à 4.
Outlook met trois plombes à démarrer mais il y a cette fonctionnalité.
[^] # Re: Retour depuis le turfu
Posté par Dinosaure (site web personnel) . Évalué à 3.
Je dis pas que c'est pas possible. Je dis juste que c'est complexe et que cette complexité est inhérente à l'email.
Et oui il y a un gap énorme entre ce dont je parle et ce que propose Thunderbird. Mais dans ce gap, il y a pas du vide mais du code.
Donc oui on peut faire un super MUA, mais:
* C'est très compliqué
* Ce MUA correspondra à votre utilisation
[^] # Re: Retour depuis le turfu
Posté par Sufflope (site web personnel) . Évalué à 2.
Désolé mais j'ai pas tout lu. Enfin j'ai lu pour de vrai la moitié, puis j'ai compris et j'ai donc arrêté. J'ai compris que tu as décidé de pondre un pavé parsemé de moi quand j'ai vraiment bossé pour de vrai sur les RFC j'ai vu ceci-cela pour essayer de gagner par KO poids + argument d'autorité.
Pas que ça soit inintéressant, un retour d'expérience, mais tu réponds à côté.
Ou alors malgré ton boulot apparemment technique, tu as une conception de l'architecture logicielle très archaïque et brouillonne où tout serait corrélé, où ton modèle de données ne serait pas séparé ni séparable de ton interface qui reçoit les courriels, donc si y a pas le champ tel que tu l'attends exactement tout pète. Ça me parait tellement basique que je sais même pas comment l'expliquer simplement. Pense aux compilateurs qui ont généralement un modèle interne AST qui permet plus de choses que le langage dans lequel le programmeur a écrit.
J'sais pas, regarde ce que fait gmail.
[^] # Re: Retour depuis le turfu
Posté par Dinosaure (site web personnel) . Évalué à 1.
Puisque je me réfère aux RFCs, oui c'est des arguments d'autorités.
Pour le coup, j'ai aussi pas mal d'expérience dans les compilateurs (et ce n'est pas très étonnant puisque je suis dans la communauté OCaml). Et oui, la résilience du logiciel par rapport aux emails est très importantes - encore aujourd'hui, j'y travaille car cela concerne surtout des cas particuliers issus d'emails spécifiques (c'est donc désormais un travail empirique).
Mais c'est tout mon propos, cette résilience s'applique avant même le MUA. Elle s'applique dès le standard. Ce qui fait qu'avant même le MUA, tu as déjà tout et n'importe quoi. Et c'est là où je dis que la difficulté d'un MUA est déjà, en partie, issue du standard.
Mon deuxième propos, c'est que de cette complexité inhérente, les concepteurs de MUA (ce dont je ne suis pas) font des choix sur la manière de traiter un email (avec ces histoires de bruit et de convention imposé par les providers) qui ne correspondent pas forcément à tout le monde - après, oui on arrive, après tant d'années, à trouver des concepts communs.
Enfin mon troisième propos, c'est de considérer cette caractéristique qu'est cette complexité comme une qualité appartenant complétement au medium de la communication et qu'on a besoin de cette liberté effroyable de la mise en forme d'un email - puisque les standards ne parle que de la forme.
PS: plus bas quelqu'un parle d'HTML. Mais en vérité c'est le même problème:
[^] # Re: Retour depuis le turfu
Posté par nalara . Évalué à 0. Dernière modification le 01 septembre 2016 à 22:53.
Ton propos est très clair, mais la prochaine parle peut-être par analogie. Les gens ont du mal à cibler ce dont tu parles. En gros tu expliques qu'écrire un client mail, c'est comme écrire un navigateur web, id est se taper une compatibilité obligatoire avec toutes les versions de css, html, xhtml, etc… Là par exemple Le Gab en dessous faite une analogie avec http, mais http c'est smtp ou imap, mais pas le contenu du mail, ce qui est interprété par le lecteur mail, qui se fout de smtp à la réception du mail. Et là ton propos sur la nécessaire anarchie d'un moyen de mise en forme universel quand tu vois le nombre d'extensions plus ou moins officielles du css.
Edit: je sais pas si tu as rajouté après l'analogie avec le html, mais je l'avais pas vue tout de suite.
[^] # Re: Retour depuis le turfu
Posté par Sufflope (site web personnel) . Évalué à 1.
Tout à fait, mais (contrairement à ce que tu espérais en disant ça), dans le pire sens du terme. Pour les RFC les plus récentes sur les technos les plus dynamiques, c'est comme Saint Paul qui écrirait son évangile en 2016 après que le Pape a accepté la communion des divorcés.
Je ne suis pas d'accord avec tout ce que tu dis. Dans le cas d'HTML (ou de tout autre langage du même style plus évolué) c'est du WYSIWYM (n'en déplaise aux initiatives bien évidemment heureuses comme CSS) et donc les différences de standard ont forcément un sens profondément sémantique. SMTP n'est ni WYSIWYM ni WYSIWYG et donc peut s'accomoder d'une couche de "si j'ai pu parser l'info elle est là sinon faisons comme si elle n'y était pas" sans impacter ni l'aspect What You Mean ni What You Get ; désolé ça fait très condescendant mais tu connaitrais mieux cette problématique si tu développais vraiment un logiciel en frontal avec les utilisateurs lambdas.
Sors des compilos et des implémentations de RFC en vase clos et viens dans le monde
de l'économie réelledu logiciel réel ; tu y abandonneras pas mal de dogmes et découvriras de nouveaux challenges, c'est pas mal non plus.[^] # Re: Retour depuis le turfu
Posté par Le Gab . Évalué à 3.
T'imagines la meme chose pour HTTP/HTML???
Donc non, je ne trouve pas la situation des MUA très heureuses. :/
# Trojita
Posté par potate . Évalué à 3. Dernière modification le 17 août 2016 à 07:47.
J'avais essayé et apprécié Trojita, un client mail (IMAP) rapide en Qt.
Le point qui me fait rester avec Claws mail est l’absence de support du multi-comptes (Bug 321374 - Multiple accounts).
# Qu'est ce que cela signifie : "créer des problèmes ?"
Posté par n0wic . Évalué à -8.
«Claws mail
Interface pas top (mais GPG)»
Les boutons "composer" ou "envoyer" sont énormes, comme le nez au milieu de la figure. C'est une fonctionalité très ergonomique bien moi évoluée dans d'autre clients (à l'instar de Zimbra qui encourrage ses propres outils tels que le partage de calendrier et consort).
# Deux et quelques autres
Posté par ZeroHeure . Évalué à 3. Dernière modification le 17 août 2016 à 12:13.
Manque Balsa, pas très beau, mais intégré à Gnome :
https://pawsa.fedorapeople.org/balsa/
et surtout l'élégant GNUMail, le client mail de Gnustep, largement débogué depuis le mois de mai :
http://wiki.gnustep.org/index.php/GNUMail
Il y en a d'autres encore… plus ou moins abandonnés, mais qui mériteraient d'être ressuscités (je dis pas ça pour ta recherche, mais pour les lecteurs ambitieux!) :
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Deux et quelques autres
Posté par Mikis . Évalué à 5.
Sans oublier Incredimail que personne ne cite (et c'est triste).
[^] # Re: Deux et quelques autres
Posté par El Titi . Évalué à 3.
Tu parles de cette saloperie ?
https://www.google.fr/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#safe=active&q=incredimail+crapware
[^] # Re: Deux et quelques autres
Posté par zurvan . Évalué à 8.
il faudrait que quelqu'un le porte sous linux. Heureusement que linux n'est pas prêt pour le desktop, sinon ça aurait déjà été fait.
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
# Nylas n1
Posté par flagos . Évalué à 2.
Sincèrement, ce Nylas,
c'estc’était du pas mal du tout.L'interface est jolie, pas mal de plugins, une vue thread pertinente, des fonctions de recherches qui marchent correctement. Ca s'integre pas trop mal avec du exchange (contacts, calendrier), pour ceux qui ont un travail ;-) Le seul souci que j'ai rencontre est un bug: de temps a autre, le CPU tournait a 100%
Malheureusement, l'architecture de ce software repose sur un serveur distant (quid des données ?), qui est devenu payant depuis un mois environ.
Pour le bien, ce serveur est également en partie open-source, on peut le lancer avec un docker. Il manque seulement le support exchange. Je ne sais pas quelle est la raison de ce non support, peut etre une obligation vis a vis de Microsoft ? En tous cas, ce qui a été bloquant pour moi et ce qui m'a fait retourner sur Thunderbird qui bien qu'imparfait, a le mérite d'exister.
# Claws-mail
Posté par Marotte ⛧ . Évalué à 1.
J’ai utilisé Thunderbird a une époque lointaine, c’était pas mal du tout… il faudrait que j’y jette un œil un des ces quatre… Mozilla a annoncé qu’ils arrêtaient de chapeauter Thunderbird, comment se passe le dév. depuis cette annonce ? C’est le client mail que j’ai installé sur le PC de ma mère (Ubuntu), claws-mail ça aurait piqué un peu quand même… pas eu de problème avec Thunderbird.
Le principal problème de Claws-mail pour moi, c’est le côté mono-thread… j’ai souvenir de ça… sauf que là je viens de tester et je peux aller lire les mails d’une boîte pendant que je fais une récupération globale (sur tous les comptes)… bon, il fait chaque compte l’un après l’autre quand même… m’enfin bref, ça fait un bail que je me suis pas retrouvé à pester sur ce @!#+*-!! de client, parce que j’étais "bloqué" dans l’UI… ça a peut-être évolué dans le bon sens de ce côté là… (version 3.14.0 ici)
Un autre truc que je n’ai pas testé c’est le plugin pour lire et écrire des mails en HTML, c’est clair qu’en milieu professionnel si je pouvais utiliser claws-mail ce serait un must. Pour mon usage perso le texte brut me va bien.
Sinon (pas chez moi) j’utilise le webmail Gmail qui est, il faut bien l’avouer, de fort belle facture.
# Rainloop
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 2.
Mais donc j'ai pas compris, c'est quoi le problème avec Rainloop? Chez moi c'est lui qui a gagné.
[^] # Re: Rainloop
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 3.
Il a longtemps été pas libre (CC-By-NC-SA), mais semble passé en AGPL, à part ça l'interface est un peu simpliste et il y a peu d'options à mon goût, mais je sais pas pour l'auteur du journal.
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
# drop in remplacement
Posté par steph1978 . Évalué à 4.
Je cherche à tester un client mail qui baserait son stockage sur un moteur de recherche comme solr ou xapian.
J'ai déjà prototype les fonctionnalité bas-niveau mais j'aimerai tester avec une interface utilisateur.
Selon vous, pour quel client mail desktop (ou webmail) il serait le plus simple modifier son système de stockage ?
[^] # Re: drop in remplacement
Posté par rakoo (site web personnel) . Évalué à 6.
As-tu déjà jeté un coup d’œil a notmuch ? Ça indexe les emails dans un xapian qui peut être accédée a l’extérieur par tout plein de moyens. Typiquement, il y a une UI pure web que je n'ai jamais utilisee, notmuch-web. Sur le desktop, tu as aussi Astroid, que j'aime bien après un test bref, qui est cité dans le journal.
Une autre possibilité que je vois est de bidouiller le système de stockage d'un serveur IMAP (plutôt qu'un client mail), et d'utiliser un client mail pur IMAP (dans le genre respect des standards, trojita est excellent). Avantage: c'est valable avec a peu près n'importe quel client !
[^] # Re: drop in remplacement
Posté par steph1978 . Évalué à 2.
You made my day !
J'ai testé (version 0.18.2 dispo sur Debian 8.5) en ligne de commande.
C'est très puissant. L'indexation a été rapide et les recherches sont instantanées sur ma machine pas très musclée.
La limitations que j'ai rencontré pour le moment : pas d'indexation du contenu html (merci aux client mails qui pratiquent le multipart/alternative, honte aux autres et à leurs utilisateurs).
# ma petite expérience...
Posté par Noobinux . Évalué à 1.
Salut,
En ce qui concerne le Webmail (ma petite expérience) :
– Roundcube 1.2 est fiable et éprouvé, beaucoup utilisé aussi. Enfin il ne gère le GPG pas de façon native, mais par extension (encore valable pour la version 1.2 ?)
– Si tu es patient, Roundcube Next (https://www.indiegogo.com/projects/roundcube-next--2#/) arrivera tôt ou tard (avec support natif GPG, appli mobile, design simple, tout semble idyllique)
– Rainloop est une très bonne alternative que j'ai pu tester/faire tester et approuver, les utilisateurs de Gmail y sont très rapidement accoutumés. À ma connaissance, pas de support GPG
Les clients lourds (ma petite expérience) :
– Thunderbird/Evolution représentent de loin la référence pour les utilisateurs “avancés/informaticiens”, les utilisateurs lambda n'aiment en général pas l'interface/la disposition/les menus, et puis c'est lourd comme tu le dis si bien… Mais support du GPG avec module
– Pour le grand public, Geary ou le fork d'Elementary OS ont une interface simpliste et agréable, le problème c'est qu'ils ne gèrent tous deux pas le GPG (sauf erreur, je les utilise peu/plus)
– Enfin, KDE Mail/KMail me semble l'alternative la plus plausible pour de l'utilisateur en client lourd commun, l'interface est dans les mœurs d'aujourd'hui et le GPG est natif
Mais des retours que l'on me fait souvent, beaucoup des utilisateurs allergiques à l'informatique préfèrent le Webmail, car ils n'ont pas conséquent pas à gérer la partie stockage de leurs mails en local…
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.