Re: Retour depuis le turfu

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".

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).

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.

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 le Subject: 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 le unstructured data 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 ?

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.

C'est là où nous avons un problème. Les seules en-têtes obligatoires selon la RFC5322 sont From: et Date: (dont certains emails se fichent d'ailleurs). Se rajoute ensuite le Content-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 avec XXX-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.

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.

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.

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 ?)).

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.