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'exim et postfix pour 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 Dinosaure (site web personnel) . En réponse au journal À la recherche des clients mail sous Linux. É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és 1 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! ↩