Dernières avancées du côté de Thunderbird

Posté par  . Édité par Yves Bourguignon, orfenor, tisaac, Sylvestre Ledru, Xavier Teyssier et Julien Jorge. Modéré par Pierre Jarillon. Licence CC By‑SA.
Étiquettes :
58
24
sept.
2022
Bureautique

Récemment la version 102 est sortie. Au fur et à mesure des mises à jours mineures, des choses se sont améliorées ici et là. Côté mail pas grand-chose n’a bougé de l’extérieur mais une réécriture de sections critiques en JavaScript est en cours. Du côté des contacts et de l’agenda, une gestion native des protocoles utilisés par les solutions de partage (tel NextCloud) vient changer la donne. Du côté des messageries instantanées la prise en charge de Matrix a été ajoutée.

Général

Ce qui se remarque d’abord dans une mise à jour, ce sont les changements d’interface. Dans cette nouvelle mouture du célèbre client mail on a droit à une nouvelle barre appelée « barre d’espaces », qui donne un accès rapide aux différents espaces accessibles : mail, contacts, agenda, tâches et messagerie.

Titre de l'image

Et puis il y a les changements que l’on remarque moins mais qui sont importants. Cette nouvelle version de Thunderbird ne sera pas décevante préparez-vous à modifier et simplifier toute votre configuration.

Mail

Pour des questions de sécurité, IMAP et SMTP ont été réécrits de C vers JavaScript.

Il n'existe toujours pas de gestion native d’Exchange via OWA / EWA mais deux plugins se démarquent :

  • OWL payant (10 € / an / compte) mais prend très bien en charge les mails, les contacts et le calendrier principal d’Exchange.
  • TBSync gère très bien Exchange via son sous-plugin mais est en retard pour la version 102, il reste des bugs. De très longues discussions se demandent que faire, car l’ajout de CalDAV et CardDAV rend ce plugin quasiment obsolète. De plus l’unique développeur est maintenant un employé Mozilla. Tous les détail sont dans la discussion Github.

Un afficheur de PDF a été ajouté de manière native, il est basé sur PDF.js

Agenda

Le support de CalDAV dans Thunderbird existait déjà mais sans découverte. Il fallait rentrer chaque agenda un par un à la main depuis un serveur. Maintenant il existe une découverte automatique, vous rentrez simplement l'adresse principale de votre serveur CalDAV et l'assistant vous proposera d'importer tous les calendriers qu'il trouve. Si jamais vous ne souhaitez pas en importer un tout de suite décochez le. Il vous sera toujours possible de l'ajouter plus tard en refaisant la manip'. Les calendriers déjà importé seront détectés et grisés.

Ajout d'un nouvel agenda

La prise en charge de Outlook CSV a été retirée.

Contact

Thunderbird est passé au format vCard pour stocker les contacts et l’ancienne librairie interne écrite en C, libical, a été remplacé par ical.js.
Ce changement a permis plus de stabilité et surtout un meilleur support du protocole vCard.

Avec la prise en charge native de CardDAV et notamment la découverte automatique il n'a jamais été aussi simple d'ajouter ses contacts stockés dans un NextCloud. Ce support existe depuis la version 91. Ce support a remplacé une autre utilisation de TBSync.

De plus une réécriture complète de la gestion des contacts permet d'avoir enfin une expérience utilisateur digne de ce côté là. Ce qui rend obsolète encore une autre extension : CardBook.

Messagerie

Du côté de la messagerie après Facebook c'est au tour de Google Talk d'être retiré. Dans les deux cas ces plateformes ont arrêté leur passerelle XMPP (Voir l'issue pour Google Talk)

Par contre Matrix a été ajouté aux protocoles existants XMPP, IRC et Odnoklassniki (c’est une messagerie basée sur un réseau social russe nommé ok.ru).

Le client XMPP reste assez pauvre. Par exemple, il n’y a pas de gestion des marque-pages et pas de découverte des groupes de discussions (MUC : Multi-User Chat).

Pour IRC le client est lui aussi très basique. Changement mineur : le serveur par défaut est maintenant LiberaChat. Et dans mon cas il a du mal à me connecter au serveur avec un mot de passe.

Le support des messageries n'a jamais été le grand fort de Thunderbird et, petit avis personnel, je me demande si Thunderbird ne devrait pas totalement laisser tomber ce pan là.

OpenPGP

Il y eu aussi pas de mal de boulot du côté d'OpenPGP :

  • une clé peut être rafraîchie depuis un serveur de clés,
  • une meilleure intégration depuis la fenêtre de composition des messages,
  • un message peut-être déchiffré de manière permanente.

Conclusion

L'extension TBSync qui était vitale avant si on utilisait un CHATONS pour stocker ses calendriers et contacts semble désormais inutile car le support des protocoles de base dans ce domaine est maintenant natif.

Ces dernières nouveautés ont énormément simplifié mon expérience utilisateur et ma configuration. On espère maintenant que ça va continuer sur cette lancée. Par exemple je trouve très étrange qu'il n'y ait pas encore de « Compte » (comme pour les mails et les messageries) pour un serveur CalDAV / CardDAV. Une fois ceux-ci ajoutés on ne peut rien modifier, on peut juste supprimer puis remettre.

De même l'interface d'ajout pour les calendriers et les contacts est bien différente alors que dans le fond ça pourrait être exactement la même du côté utilisateur.

Mais je reste positif et j'ai hâte de découvrir les nouvelles versions !

Aller plus loin

  • # CategoryManager pas compatible malheureusement

    Posté par  . Évalué à 4.

    Pour moi (du moins pour des utilisateurs que j'ai fait bsculer sur Thunderbird) il manque encore les catégories pour pouvoir migrer facilement sur la 102

    https://github.com/jobisoft/CategoryManager

    Mais vu que les différents modules dont tu parles et celui-ci ne sont plus à 100% utile, je sais pas ce qu'il va advenir de ce type de feature non disponible dans la 102.

    Wait and see.

  • # Pour des raisons de sécurité

    Posté par  (site web personnel, Mastodon) . Évalué à 10.

    Pour des questions de sécurité, IMAP et SMTP ont été réécrits de C vers JavaScript.

    Je croyais que c'était Rust qui était à la mode quand on voulait remplacer C pour des raisons de sécurité ?

    • [^] # Re: Pour des raisons de sécurité

      Posté par  (site web personnel) . Évalué à 8.

      J'allais poser la question

    • [^] # Re: Pour des raisons de sécurité

      Posté par  . Évalué à 5.

      Peut-être que c'est lié aux personnes "disponible" pour travailler sur ce sujet et/ou au fait que le langage soit déjà directement utilisable dans le projet.

      Mais en tous cas ça m'a aussi fait tiquer. J'aurais trouvé ça plus judicieux si Rust avait été utilisé pour la ré-implémentation de ses protocoles.
      Vu que se sont des composants de base de l'application, la sécurité la légèreté et la fiabilité poussé par Rust m'aurais semblé intéressant.
      Mais je ne connais pas toute les raisons de ce choix.

      • [^] # Re: Pour des raisons de sécurité

        Posté par  (site web personnel) . Évalué à 4. Dernière modification le 24 septembre 2022 à 12:41.

        Après, Rust est intéressant pour sa sécurité tout en gardant la vitesse d’exécution si j'ai bien lu.
        Peut être que les points ré-écrits de TB ne sont pas critiques du point de vue vitesse (comme Pitivi dont l'interface est en python mais le moteur est en C) ? En tout cas je n'avais aucune idée que JS était solide question sécurité, peut-être est-ce une caractéristique des langages interprétés ?

      • [^] # Re: Pour des raisons de sécurité

        Posté par  (site web personnel) . Évalué à 8.

        Vu que se sont des composants de base de l'application, la sécurité la légèreté et la fiabilité poussé par Rust m'aurais semblé intéressant.
        Mais je ne connais pas toute les raisons de ce choix.

        On peut discuter de la sécurité mais niveau perfs JS n'est pas un mauvais choix ici.
        Même si SMTP et IMAP sont des protocoles de base dans Thunderbird, on utilise essentiellement son interface ou ses données locales, les aspects envoyer / recevoir es messages sont finalement qu'une faible partie de l'usage de Thunderbird et dont les perfs sont bien moins critiques que pour HTTP pour Firefox par exemple.

        On passe peu de temps à utiliser ces protocoles avec Thunderbird, donc les perfs ça passe après.
        Niveau sécurité je n'en sais rien du tout, une implémentation en C étant risquée aussi.

        • [^] # Re: Pour des raisons de sécurité

          Posté par  . Évalué à 3.

          Secondé, d'autant plus que même si je ne connais pas vraiment ce cas je m'attendrais à ce que IMAP/SMTP soient limités par les accès mémoire et réseau et pas CPU bound

      • [^] # Re: Pour des raisons de sécurité

        Posté par  (site web personnel, Mastodon) . Évalué à 4.

        L'argument des personnes disponibles me parait faible puisque Rust est une création de Mozilla. Ils n'utilisent donc pas leur propre langage ?

        • [^] # Re: Pour des raisons de sécurité

          Posté par  (site web personnel, Mastodon) . Évalué à 10.

          Rust a bien été fondé par Mozilla, mais Thunderbird n'est plus développé par Mozilla depuis des années (10 ans peut être ?).

          Si je me souviens bien, la communauté Thunderbird s'est prise en main il y a quelques années en montant leur propre fondation (avant ils étaient encore lié fiscalement et avec les outils de développement à la fondation Mozilla).

          Personnellement, l'utilisation du JavaScript ne me choque pas: ils ont déjà dû remplacer toutes les définitions XUL/XML de l'interface graphique par du JavaScript pour pouvoir continuer à utiliser la plateforme Gecko.

          La petite équipe de Thunderbird a donc déjà des connaissances en JavaScript et continuera d'en avoir besoin encore pendant longtemps.

          Pour les add-ons, ils doivent également suivre la plateforme Gecko et donc suivre le nouveau système avec les API en JavaScript (manifest v2 et v3).

          Je pense en particulier à la partie agenda qui était l'add-on Ligthning auparavant. Il y a d'ailleurs déjà une bonne partie des fonctionnalités en JavaScript pour la gestion des agendas.

          La programmation asynchrone avec JavaScript est vraiment agréable et permet facilement de faire des interactions en gardant la fluidité visuelle et un code de bonne qualité. C'est vraiment efficaces pour avoir en même temps des interactions réseaux lentes et une interface graphique fluide malgré cette lenteur.

          Je vois leur utilisation de la plateforme Gecko un peu comme les autres utilisent Electron, mais avec les technologies de Mozilla. C'est donc il me semble naturel de privilégier le JavaScript dans cette situation.

          Regarder l'utilisation mémoire brute est une mauvaise mesure, puisque JavaScript a aussi son garbage collector et qu'il peut être plus efficace de garder les objets en mémoire plutôt que de constamment la vider.

          Bien sûr, si l'environnement mémoire est restreint le Garbage Collector nettoyera plus souvent la mémoire, mais ça implique que le processeur commence a passer plus de temps à faire des choses inutiles pour l'utilisateur…

          On en a parlé ici même et aussi là pour le fait d'utiliser la mémoire disponible.

          • [^] # Re: Pour des raisons de sécurité

            Posté par  . Évalué à 10.

            Si je me souviens bien, la communauté Thunderbird s'est prise en main il y a quelques années en montant leur propre fondation (avant ils étaient encore lié fiscalement et avec les outils de développement à la fondation Mozilla).

            C'est une histoire mouvementée, on dirait que Thunderbird est plus ou moins revenu dedans : « Thunderbird fait désormais partie de MZLA Technologies Corporation, une filiale détenue à 100 % par la Fondation Mozilla. »

            Ce qui ne change rien sur le choix des technos, ils font ce qu'ils veulent hein :)

    • [^] # Re: Pour des raisons de sécurité

      Posté par  (site web personnel) . Évalué à 10.

      Passer de C à Javascript c'est surtout encore consommer utiliser intelligemment plus de ressource processeur et de mémoire vive.
      Effectivement, Rust aurait été un meilleur choix risqué. Mais il y a aussi l'option d'auditer le code C et d'écrire une suite de test complète.

      Thunderbird fait partie de ces logiciels qui se dégradent lentement mais surement avec le temps qui migrent vers les technologies du web 3.0 . Pour gérer mes 4 boîtes emails, il s'accapare n'utilise admirablement qu' un unique gigaoctet de mémoire vive, a des lenteurs et crashs aléatoires incite son utilisateur a le fermer régulièrement dans un soucis d'optimisation des ressources.

      L'équipe de développement a clairement pris le chemin de la réécriture totale en JavaScript, une route sans retour au pays du typage dynamique et autres joyeuseté qu'il est bon de fuir quand on cherche à faire un logiciel performant et fiable des meilleurs logiciels actuels.

      Heureusement que l'on a de jolies icônes maintenant, merci la MZLA Technologies Corporation.

      • [^] # Re: Pour des raisons de sécurité

        Posté par  (site web personnel) . Évalué à 6. Dernière modification le 24 septembre 2022 à 13:06.

        Merci de m'avoir procuré ce rare mélange de rire et de peur :) :/

      • [^] # Re: Pour des raisons de sécurité

        Posté par  . Évalué à 6.

        Pour ma part je n'ai jamais de crash avec les binaires fournis par Mozilla, installés dans ~/bin/ (Je suis le seul utilisateur de mon PC).
        Et avec 6 comptes, c'est plutôt 400 Mo de RAM utilisés.

        • [^] # Re: Pour des raisons de sécurité

          Posté par  (site web personnel) . Évalué à 9.

          Et avec 6 comptes, c'est plutôt 400 Mo de RAM utilisés.

          De mon côté je suis aux alentours de 580M avec 7 comptes et des dizaines de milliers de mails, de plus je ne me souviens plus la dernière fois que j'ai eu un crash de Thunderbird (bon OK je ne l'utilise quotidiennement que depuis 17 ans à l'époque ou il s’appelait "Icedove")

          Perso je suis content que TB continue d'évoluer et même si pour des raisons de perfs j'aurais préféré un langage de plus bas niveau que le JS pour recoder certaines parties, je préfère 1000 fois les gens qui font quelque chose à ceux qui se masturbent les neurones sur des choix technologiques/techniques et au final ne font rien.

          D'autant plus qu'invoquer le besoin de perfs et d'optimisation de la mémoire pour un client mail franchement faut pas avoir honte :-D

          kentoc'h mervel eget bezan saotred

      • [^] # Re: Pour des raisons de sécurité

        Posté par  (site web personnel) . Évalué à 5.

        Pour défendre Javascript, c'est aussi une opportunité d'avoir plus de contributeurs.

        Rust aurait été un mauvais choix pour ce critère, car les devs risquent de mourir de vieillesse pendant une compilation.

        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

      • [^] # Re: Pour des raisons de sécurité

        Posté par  (site web personnel, Mastodon) . Évalué à 8.

        Pour gérer mes 4 boîtes emails, il s'accapare n'utilise admirablement qu' un unique gigaoctet de mémoire vive, a des lenteurs et crashs aléatoires incite son utilisateur a le fermer régulièrement dans un soucis d'optimisation des ressources.

        C'est ce côté poussif qui m'a fait tiquer en voyant débarquer du tout JS ; ça va être de moins en moins à portée de petites configurations. On n'arrête pas le progrès.

        “It is seldom that liberty of any kind is lost all at once.” ― David Hume

        • [^] # Re: Pour des raisons de sécurité

          Posté par  . Évalué à 3.

          Je partage cette inquiétude et confirme la conso mémoire (surtout quand il tourne depuis plusieurs jours). C'est de moins en moins bon. Et le passage en JS est d'autant plus inquiétant… Que se passe-t-il ???

      • [^] # Re: Pour des raisons de sécurité

        Posté par  . Évalué à 10.

        Je suis à l'origine de la dépêche mais pas le seul contributeur. J'avais à la base simplement noté que plusieurs bouts avaient été passé de C à JavaScript, comme la libical dont je parle dans la partie Agenda. La notion de sécurité a été ajouté par quelqu'un d'autre et cette personne semble bosser pour Mozilla. Je n'ai pas cru bon d'enlever car en effet au sujet de SMTP et IMAP je n'avais pas trouvé de raisons à ce changement. J'aurais sans doute dû reformuler car maintenant du coup la dépêche sonne un peu propagande et les commentaires ne parlent que de ça…

        De même un paragraphe un peu méchant dans la conclusion a aussi été retiré par la même personne (en gros je disais que jusqu'ici Thunderbird était sincèrement à la ramasse et que ça faisait du bien de voir bouger le produit vers les standards).

    • [^] # Re: Pour des raisons de sécurité

      Posté par  (site web personnel) . Évalué à -2.

      C vers Javascript ? Sérieux ? C'est franchement du n'importe quoi.

      Et quelle excuse complètement débile ils ont trouvé ? La "sécurité" ?? On dirait un politique qui tente maladroitement de justifier sa dernière loi pro-lobby.

      • [^] # Re: Pour des raisons de sécurité

        Posté par  (site web personnel) . Évalué à 10.

        D'un autre côté, laisser programmer des web developers agiles frontend/backend [TM] en C, en sachant pertinemment qu'ils n'auront ni l'envie ni la contrainte d'écrire une suite de tests… c'est très risqué, voir dangereux ;)

      • [^] # Re: Pour des raisons de sécurité

        Posté par  . Évalué à 10.

        J'imagine que l'argument ne porte pas sur le langage et que le débat interne n'a pas été C vs JavaScript. Mais plutôt implémentation maison avec des failles mémoires contre librairie largement utilisée par une communauté plus large.

        Si c'est bien ça, l'argument de la sécurité se défend, vraiment.

        Je rejoins l'avis général : c'est triste de voir du JS se faufiler partout y compris dans des clients natifs. Mais je me souviens aussi que Thunderbird (et Firefox avant lui) utilisaient XUL, qui était déjà un truc interprété, mal aimé pour sa lenteur et sa consommation mémoire - donc y-a-t-il vraiment une régression ici ?

        • [^] # Re: Pour des raisons de sécurité

          Posté par  (site web personnel) . Évalué à -10.

          Mais je me souviens aussi que Thunderbird (et Firefox avant lui) utilisaient XUL, qui était déjà un truc interprété, mal aimé pour sa lenteur et sa consommation mémoire - donc y-a-t-il vraiment une régression ici ?

          L'idée est donc que comme on reproche d'avoir une technologie lente et consommatrice de RAM, on la quitte pour encore plus lent et encore plus consommateur de RAM.
          Ou est donc le problème?

          Perso je me demande si face à la lenteur de la chose alors qui j'ai une grosse machine, je ne vais pas craquer et passer à Gmail (ou le exchange online de OVH) qui a défaut de consommer moins de RAM est plus réactif. Pas libre mais le libre est un moyen, pas un but, et si les libristes poussent leur utilisateurs à ça…

          • [^] # Re: Pour des raisons de sécurité

            Posté par  (site web personnel) . Évalué à 3.

            Je ne vois pas le rapport entre Thunderbird et Gmail ou Exchange Online.

            Il me semble qu'il est possible de se connecter à ceux-là avec Thunderbird. Du moins, c'est ce que j'avais il y a quelques années, quand c'était pas encore trop pénible. Ce n'est pas la faute de Thunderbird si la connexion à Gmail est lente. C'est un choix délibéré de Google. Et vu que maintenant il faut passer un captcha d'abord…

            Aucune idée de comment ça fonctionne avec Exchange, ça fonctionnait il y a quelques années. Depuis, j'utilise de vrais serveurs IMAPs.

            Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html

          • [^] # Re: Pour des raisons de sécurité

            Posté par  . Évalué à 3. Dernière modification le 25 octobre 2022 à 13:15.

            L'idée est donc que comme on reproche d'avoir une technologie lente et consommatrice de RAM, on la quitte pour encore plus lent et encore plus consommateur de RAM.

            XUL, ce n'était qu'un format permettant de concevoir une interface graphique décrite en XML style HTML mais en utilisant des composants natifs du système (enfin, aussi natifs que possible), animée avec JavaScript, par Gecko, le même moteur que pour HTML/JS. Je doute que passer de XUL à HTML/JavaScript entraîne des ralentissement. On peut d'ailleurs imaginer que c'est plus rapide, parce que les moteurs JS ont eu le temps d'être optimisés à mort depuis l'abandon de XUL, et le rendu HTML est probablement plus travaillé / optimisé que le rendu XUL dans Gecko. L'idée derrière passer de XUL à HTML était de permettre le retrait du support de XUL, on peut supposer que cette simplification permet aussi des optimisations. Mais je ne sais pas si ça a eu lieu, j'ai l'impression que XUL, ça traine encore dans Gecko.

            Après, je trouve ça dommage que XUL ait disparu et que des trucs comme Electron ont pris la place que XUL aurait pu prendre (c'était pratique XUL !), et que le passage à HTML dans Firefox/Thunderbird nécessite probablement la maintenance d'un toolkit graphique dédié (probablement moins prenante que la maintenance de XUL) mais ça c'est une autre histoire.

            Tout cela étant dit, là on parle d'un passage de C vers JS, pas de XUL vers HTML/JS, espérons que ce passage de C à JS pour l'implémentation des protocoles mail dans Thunderbird ne sera pas source de ralentissements / consommation mémoire significative. L'informatique doit s'alléger maintenant, pas l'inverse. Si ce passage permet de libérer du temps pour optimiser d'autres trucs (plus) significatifs, ça peut être gagnant, indirectement. Je doute que ça soit ça qui se passe, mais pourquoi pas.

          • [^] # Re: Pour des raisons de sécurité

            Posté par  (Mastodon) . Évalué à 3.

            C'est pas vraiment comme si gmail se bonifiait avec le temps, plutôt le contraire je dirais.

        • [^] # Re: Pour des raisons de sécurité

          Posté par  (site web personnel, Mastodon) . Évalué à 8.

          c'est triste de voir du JS se faufiler partout y compris dans des clients natifs

          Le JS dans Firefox et Thunderbird, ce n'est pas nouveau. Ça date de leur version 0.1, et même de leur ancêtre la suite Mozilla (donc depuis 1998…).

          Alors une lib de plus ou de moins en JS, ça ne va pas changer grand chose…

          Surtout que les moteurs JS d'aujourd'hui, n'ont plus rien à voir avec ceux d'antan, avec le JIT et cie…

          utilisaient XUL, qui était déjà un truc interprété

          Le XUL, c'était du XML. Un HTML++ (de l'époque) sous stéroïde. Rien de plus. Avec du CSS pour le design, et du JS pour le comportement (et un système de composant, XBL, ancètre des web components). Bref, ce qu'on appelle aujourd'hui une appli web.

          donc y-a-t-il vraiment une régression ici ?

          non.

    • [^] # Re: Pour des raisons de sécurité

      Posté par  . Évalué à 2.

      D'après ce que j'ai compris, c'est très difficile d'écrire une librairie pour imap et smtp à cause du nombre phénoménal d'entorses aux standards dans les serveurs. Je pense que mozilla a répondu à la question: quelle lib est moins pire que la notre mais marche quand même.

    • [^] # Re: Pour des raisons de sécurité

      Posté par  . Évalué à 2. Dernière modification le 03 novembre 2022 à 14:56.

      Surtout en considérant d’où vient Rust :o)

      Pas le seul surpris, donc! J'espère que cela ne cache pas le début d'une évolution fâcheuse (client lourd-> web app?).

      Mais il semble que JS sorte de plus en plus de son cadre de langage dédié au web dynamique côté client (pendant de PHP côté serveur), poussé par la masse de développeurs web? L'autre exemple en tête qui m'attriste c'est pour le protocole domotique ZWave (l'unique mainteneur de la librairie C++ Open-Zwave ayant claqué la porte depuis bientôt 2 ans) et zwavejs ou la situation est pire (faute de devoir déjà intégrer l'interpréteur, comme Thunderbird, donc pb de dépendances complexes ajoutées réglées malpropre à coup de docker vs la simplicité d'une lib compilée dans l'applicatif qui l'utilise).

      Surtout que si je suis assez peu confiant dans la capacité de Rust à remplacer le C dans le codage d'OS/modules/boot-loader, pour de l'applicatif réseau en frontal sur internet et en évolution rapide/constante il semble plus justifié de:
      -Se lancer dans un langage nouveau/offrant moins de liberté… et objet, qui a toujours posé le pb de la fine maîtrise de la gestion mémoire/allocations,
      -Accepter une petite baisse de perf contre la sécurité intrinsèque,
      -Ne pas devoir se reposer sur des outils d'analyse de code, coûteux en ressources, si on veut les perf maximales du C ET la sécurité (ce qui se justifie plus pour du code qui va moins changer dans le temps, ce qui est à mon sens la raison pour laquelle Rust ne percera pas là ou les performances sont le critère premier, car elles ont un coût matériel ajouté évitable donc in-fine évité par l'industrie).

      Mais la stratégie de Mozilla est parfois étrange.

  • # Messagerie

    Posté par  (site web personnel) . Évalué à 4.

    Comment écrire un plugin pour gérer un nouveau protocole?

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

  • # Tri des comptes

    Posté par  . Évalué à 9.

    Innovation majeure pour moi: plus besoin d'extension, le tri des comptes est désormais possible dans "account settings", à la souris.

    • [^] # Re: Tri des comptes

      Posté par  (site web personnel) . Évalué à 2.

      En espérant que ça fonctionne dans tous les cas de figure. Dans mon université, les comptes de messagerie liés à l'utilisateur sont ajoutés automatiquement. J'avais essayé le greffon et ça avait foutu en l'air tout le profil de la personne…

      • [^] # Re: Tri des comptes

        Posté par  . Évalué à 2.

        avant je faisais sans greffon et c'était chiant
        maintenant ça marche même avec mon compte outlook donc bon :-)

  • # Formats des boîtes locales

    Posté par  . Évalué à 10.

    Thunderbird s'est vachement amélioré, mais selon ma personne et moi-même, il manque un truc tout bête : quand on a sa mailbox en local, c'est une pseudo mbox. Il en découle que l'on ne peut pas partager l'accès à ses mails avec un autre MUA (mutt, par exemple).

    Pour décrire ma manière de faire, qui n'est sans doute pas habituelle :

    Quand je récupère mes mails (avec getmail en mode IMAP), je les efface du serveur (comportement à la POP3), parce que je suis parano et que je préfère les avoir sur MON ordi et dans mes backups. Le résultat est que quand mon ordi est éteint, mes mails sont inaccessibles, mais c'est justement ce que je veux.

    Getmail me fait donc un beau maildir (ou une mbox. Et mutt sait l'utiliser, normal, c'est un format standard. Et aussi formail, et aussi sans doute d'autres lecteurs de mail.

    Mais Thunderbird, lui, ne sait pas. Il lui faut soit un serveur IMAP local pour accéder au maildir, soit une version légèrement incompatible de mbox. Il y a un bug ouvert sur ce sujet dans le bugzilla de Thunderbird, mais ça fait genre 10 ans qu'il existe, et trop personne de motivé pour s'y atteler (mais je peux comprendre, en ce qui me concerne, ça dépasse de loin mes compétences en programmation).

    Ce qui fait que je ne peux alterner entre Thunderbird et Mutt. Donc je reste avec mutt exclusivement.

    • [^] # Re: Formats des boîtes locales

      Posté par  . Évalué à 0.

      Quel serait l'intérêt de pouvoir alterner entre Thunderbird et Mutt ?
      Ce que tu fais avec Getmail et Mutt je le fais avec Thunderbird tout seul.

      • [^] # Re: Formats des boîtes locales

        Posté par  . Évalué à 10.

        Mutt c'est un exemple, et c'est ce dont je me sers principalement. Pouvoir intégrer Thunderbird en tant que lecteur/rédacteur/expéditeur de messages dans un ensemble d'outils comme formail, procmail, getmail, offlineimap, sendmail (ou nullmailer), emacs-mail, ce serait cool.

        Parce que Thunderbird a des extensions chouettes, un moteur de recherche et de filtres assez bon, qu'il permet de visualiser simplement et sans dire des mots choquants à ses collègues les mails qui commence par "mes réponses aux commentaires vert kaki de Judith sont en bleu de Lectoure" :).

        Après, je comprend que l'aspect monolithique a aussi des avantages, et je comprend aussi que mon usage est un cas relativement rare.

        Je vais donner un exemple pratique, quand même.

        Imaginons qu'en temps normal, j'utilise Thunderbird, joie et bonne humeur.

        Un jour, je veux lire quelques mails, stocké sur mon ordi, mais mes gamins squattent mon ordi pour regarder un truc débile genre Métropolis de Fritz Lang. Au lieu de les déranger, je fais un ssh sur l'ordi sus-cité, je lance mutt et là, ben mutt aboie car la mailbox n'est pas une mailbox.

        Ok, je peux AUSSI faire un ssh -Y et lancer thunderbird en remote. Sauf qu'il faut un display X local, ce que je n'ai pas forcément (par exemple, si j'arrive depuis un Mac). Poussons le bouchon plus loin, je peux AUSSI lancer un serveur VNC pour pouvoir lancer Xorg pour pouvoir lancer Thunderbird dans une seconde session. Après tout, j'ai tout le temps, Métropolis dure 2 heures :). Je peux même proposer aux gamins d'enchaîner sur Salo ou les 120 jours de Sodome pour avoir le temps de finir de mettre en place un process permettant de pouvoir lire mon putain de mail, qui dit que mon train est à 19h07 et merde voilà il est 19h12 je l'ai raté, chômage, dépression, alcoolisme, suicide.

        Sinon, sur le principe, ça porte le doux nom de interopérabilité :D.

        En espérant que cette réponse te soit utile, bon week-end.

        • [^] # Re: Formats des boîtes locales

          Posté par  . Évalué à 5.

          Pas vraiment. J'aurais préféré un exemple sorti de la vie réelle. Là tu exposes un exemple de solutionnisme technologique à un hypothétique problème d'autorité parentale. Je ne vois toujours pas l'utilité de pouvoir accéder à son propre profil Thunderbird avec un autre logiciel que Thunderbird.
          Pour partager des données entre 2 clients mail, il y a IMAP, c'est fait pour, non ?

          • [^] # Re: Formats des boîtes locales

            Posté par  . Évalué à 6. Dernière modification le 25 septembre 2022 à 14:42.

            Un autre exemple, alors, très réel. À mon boulot, quand une personne s'en va de l'entreprise, j'archive ses données, puis suppression définitive après 2 ans. Les archives sont un joli tar compressé.

            Les données, ce sont :
            * le homedir
            * la mailbox
            * les infos LDAP

            De temps en temps, je dois retourner gratter dans la mailbox ainsi archivée pour retrouver une info (car hélas, car les boîtes à lettres sont utilisées comme le stockage fourre-tout/universel favori des utilisateurs, et contiennent parfois des infos qui n'existent nulle part ailleurs).

            Donc je untar la mailbox (en maildir), et je peux la lire directement avec mutt -f lerépertoire. Pour faire la même chose avec Thunderbird (par exemple pour mettre la boîte à dispo de quelqu'un qui n'apprécie pas le charme de mutt .), je dois passer par un plugin de conversion ou d'import, ou encore remettre la boîte à lettre sur le serveur IMAP, créer un compte bidon le temps de la recherche. Rien d'impossible, rien d'insurmontable. Juste un (petit) regret.

            Pour résumer, je trouve ça chagrinant de ne pas pouvoir lire une BAL qui soit dans un format standard directement avec Thunderbird.

            J'en profite pour faire la promo de l'extension ImportExportTools-NG, qui m'a servi à l'occasion.

            • [^] # Re: Formats des boîtes locales

              Posté par  (site web personnel) . Évalué à 2.

              Est ce que ce ne serait pas plus facile de faire synchroniser Thunderbird sur le serveur IMAPs les données locales, puis ensuite d'archiver ce qui est sur le serveur IMAPs?

              Si tu as accès au homedir de l'utilisateur, tu as aussi accès aux comptes mails avec les données locales, de Thunderbird, non?

              Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html

              • [^] # Re: Formats des boîtes locales

                Posté par  . Évalué à 10.

                Le plus logique, c'est quand même d'archiver ce qui est dans un format standard, afin de ne pas s'enfermer dans un unique logiciel.

                Je pense qu'il n'y a pas vraiment débat, Thunderbird devrait utiliser le format standard, point. Le reste n'est qu'un ensemble de bidouilles pour contourner ce manque…

                • [^] # Re: Formats des boîtes locales

                  Posté par  (site web personnel) . Évalué à 2.

                  Y a plus qu'à motiver un contributeur…

                  Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html

    • [^] # Re: Formats des boîtes locales

      Posté par  (site web personnel) . Évalué à -4. Dernière modification le 24 septembre 2022 à 17:37.

      Pour décrire ma manière de faire, qui n'est sans doute pas habituelle […] Le résultat est que quand mon ordi est éteint, mes mails sont inaccessibles, mais c'est justement ce que je veux.

      Wow, ha ouais, quand même, à l'heure du multi-device et connecté, on est pas mal dans l'imagination pour la compétition de trouver l'inconfort le plus bizarre.

      Il y a un bug ouvert sur ce sujet dans le bugzilla de Thunderbird, mais ça fait genre 10 ans qu'il existe, et trop personne de motivé pour s'y atteler

      Tu m'étonnes, vu que pour 99.999% de la population ils utilisent juste IMAP pour ce pour quoi il a été conçu. Et que pour 99.9% (j'enlève des 9 car pas assez de monde) des restants ils ne voient pas l’intérêt d'utiliser 2 logiciels pour faire la même chose.

      Du coup, va falloir trouver un autre cas d'usage pour motiver des tiers, ou t'y coller.

      • [^] # Re: Formats des boîtes locales

        Posté par  (site web personnel, Mastodon) . Évalué à 6.

        à l'heure du multi-device et connecté, on est pas mal dans l'imagination pour la compétition de trouver l'inconfort le plus bizarre.

        On peut choisir de nommer cela inconfort ou de l'appeler par son nom habituel : archivage…
        D'un autre côté, ce n'est pas parce-que tout le monde est éparpillé et à poil qu'il faut se sentir obligé-e de suivre la troupe…

        “It is seldom that liberty of any kind is lost all at once.” ― David Hume

        • [^] # Re: Formats des boîtes locales

          Posté par  (site web personnel, Mastodon) . Évalué à 5.

          Où être dépendant d'un appareil ! Une question à se poser est : est-il vraiment indispensable d'accéder tout le temps à sa messagerie électronique, la raison est, bien souvent, non !

          « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

          • [^] # Re: Formats des boîtes locales

            Posté par  . Évalué à 4. Dernière modification le 23 octobre 2022 à 21:05.

            est-il vraiment indispensable d'accéder tout le temps à sa messagerie électronique, la raison est, bien souvent, non !

            Tout dépend de ton mode de vie, de ton lieu d'habitation, de l'éloignement de tes proches, etc. Quand on sa famille à des milliers de Km, c'est un lien qui est plus qu'utile, surtout en période de COVID/confinement.

    • [^] # Re: Formats des boîtes locales

      Posté par  . Évalué à 2.

      Quand je récupère mes mails (avec getmail en mode IMAP), je les efface du serveur (comportement à la POP3),

      QUOI ?!

      "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

      • [^] # Re: Formats des boîtes locales

        Posté par  . Évalué à 5.

        Pour diverses raisons, je ne fais plus confiance à mon FAI pour conserver mes courriels, donc je les déplace ailleurs. Qu'est-ce qui te choque là dedans ?

        • [^] # Re: Formats des boîtes locales

          Posté par  (site web personnel) . Évalué à 6. Dernière modification le 25 septembre 2022 à 09:58.

          Généralement les gens qui n'ont plus confiance dans leur hébergeur mail (choix indépendant du choix de FAI, même si un FAI propose un oackage on n'a aucune obligation d'utiliser) changent d'hébergeur mail.
          Et si la personne est attachée à son indépendance ça sera transparent pour ses contacts çar elle aura pris soin d'avoir une adresse mail d'un domaine qu'elle possède (B.A.ba de l'indépendance depuis plus de 20 ans, depuis que les FAI utilisent leur nom de domaine pour attirer).

          Au final j'ai l'impression que l'argument sur le besoin montre in problème très différent.
          (Ce qui n'empêche pas de développer ou faire développer, si le besoin est réel, et si d'autres ont le même besoin le coût peut se mutualiser, mais changer d'hébergement mail sera dans tous les cas moins cher)

          Si que conserver, ben on peut backuper sans supprimer, difficile à suivre la logique.

          Qu'est-ce qui te choque là dedans ?

          En plus l'argument ne répond pas à la question de pourquoi ne pas utiliser POP3 pour faire comme du POP3, plutôt que de scripter IMAP.
          Ça doit plus amuser que choquer.

          • [^] # Re: Formats des boîtes locales

            Posté par  . Évalué à 9.

            pourquoi ne pas utiliser POP3 pour faire comme du POP3, plutôt que de scripter IMAP

            C'est aussi simple d'utilisation, point de scripting là-dedans, je fais getmail -d, ça récupère mes messages et les efface du serveur. IMAP prévoit plein de bonnes choses pour organiser ses messages en dossiers et faire de la recherche côté serveur, mais en aucun cas ne t'oblige à le faire. La fonction de suppression fait même partie du protocole depuis la première version ;).

            Après, on peut me considérer comme déviant :p de ne pas pouvoir accéder à mes mails de n'importe où n'importe quand. Perso je trouve que c'est un avantage, comme ne pas avoir de smartphone, par exemple.

            • [^] # Re: Formats des boîtes locales

              Posté par  . Évalué à 9.

              Ton cas d'usage est hyper-spécifique et je pense qu'il occulte le principal argument : ça serait cool que Thunderbird respecte les standards établis. Il existe mbox & maildir mais Thunderbird utilise un fake-mbox incompatible. Ne serait-ce que pour des questions d'interopérabilité il serait bon d'évoluer.

              mbox est antédiluvien, mon Inbox se retrouve stockée dans un unique fichier de plusieurs gigas. Alors que maildir a été créé pour le remplacer. Wikipédia dit même "Il est de plus particulièrement adapté pour les agents de distribution du courriel compatibles avec le protocole IMAP." Par exemple de mon côté, j'aimerais bien pouvoir faire des sauvegardes incrémentales automatiques pour ne pas transférer 2Go à chaque backup de mon profil TB.

    • [^] # Re: Formats des boîtes locales

      Posté par  . Évalué à 6.

      Pourquoi ne pas monter un serveur IMAP local ?

    • [^] # Re: Formats des boîtes locales

      Posté par  (site web personnel) . Évalué à 5.

      Thunderbird savait, mais la fonctionnalité a été retirée après la version 78: https://bugzilla.mozilla.org/show_bug.cgi?id=1727931

      Il y a 3 mois, ils parlaient de le remettre mais pour l'instant ce n'est pas fait…

      • [^] # Re: Formats des boîtes locales

        Posté par  . Évalué à 3.

        Il y a 3 mois, ils parlaient de le remettre mais pour l'instant ce n'est pas fait…

        La vraie question que je me pose : est-ce que ça sera ré-implémenté en JS ?

        ;-P

        • [^] # Re: Formats des boîtes locales

          Posté par  (site web personnel) . Évalué à 2.

          Je ne sais pas à qui jeberger répond, mais ça m'a permis de découvrir ce nouveau scandale, même si, vu le nombre de tickets ignorés(certains pendant 20 ans, de fonctionnalités essentielles comme le bug dans la notification de nouveaux courriels qui n'a lieu qu'une fois) ou rejetés, je n'ai pas attendu cela pour ne plus rien attendre de valable des développeurs Mozilla(ou leurs successeurs). Je rêve de passer à Sylpheed/Claws mais vu mon historique d'utilisation de Icedove/Thunderbird, j'ai trop peur de la migration.

          La vraie question que je me pose : est-ce que ça sera ré-implémenté en JS ?

          Tu ne crois pas si bien dire:

          A re-implementation in JS is also an option

          Ce qui semble être la liste des tickets que j'ai déposé est sur: ici

          et commentés

          Du coup j'ai retrouvé l'adresse du site avec mes extensions chéries
          Pas très sympa de sa part de pénaliser les utilisateurs, dont des libristes, pour lutter contre la dictature nazitaire

          • [^] # Re: Formats des boîtes locales

            Posté par  (site web personnel) . Évalué à 1.

            Le projet Betterbird m'a fait sa publicité car j'étais intervenu dans un des tickets suite à la série de commentaires ci-dessus. Je n'ai pas encore testé(notamment parce qu'ils n'ont pas de paquet Debian). C'est dans la pile des milliards de choses que je n'aurais jamais le temps de faire(et en plus ça rentre en concurrence avec mon rêve de passer à Sylpheed/Claws).

    • [^] # Re: Formats des boîtes locales

      Posté par  . Évalué à 6.

      Il faut aussi noter que le support Maildir à la sauce Thunderbird n'est pas encore stabilisé.
      Cf.
      https://support.mozilla.org/fr/kb/maildir-thunderbird

      Personnellement, pour les sauvegardes incrémentales, j'attends avec impatience.

  • # Authentification IMAP pour office365 (raison: inquiétude)

    Posté par  . Évalué à 3.

    J'ai cru voir passer il y a quelques semaines un avis sur l'obsolétisation (sic) prochaine sur Office 365 de l'authentification IMAP par mot de "passe de base". Est-ce bien d'actualité? Je ne parviens pas à retrouver l'article que j'ai vu passer, d'où ma question.

    L'extension OWL¹ (Chouette en français, apparemment), sous licence expire prochainement et j'observe des "bizarreries" du genre délais extrêmement longs à l'envoi de mails mais pas partout — du moins pas tout le temps mais j'ai du mal à détecter un motif. Est-ce toujours une solution viable? Ou bien le seul recours est-il d'utiliser l'interface web d'Outlook 365?

    ¹ Que j'ai installée sur un compte de test.

  • # OWA !!! Oh non !

    Posté par  . Évalué à 1.

    De mon côté il n’y a pas moyen (ni avec OWL, ni autre chose) de faire fonctionner mon compte pro OWA avec Thunderbird et j’en suis fâché. L’identification se fait bien avec OWL mais il n’arrive à récupérer les mails ensuite pour les intégrer dans thunderbird. Dommage.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.