J'aurais tout autant aimé que l'e-mail soit décrit sur une seule et unique RFC mais c'est sans compter le legacy avec la RFC 822/2822, le MIME avec la RFC 2045 (2046 .. 2049), les patches comme la RFC 6532 ainsi que quelques arcanes de la RFC 5321 (SMTP) - je me suis amusé1 à faire un tri topologique des dépendances entres les RFCs d'ailleurs.
Et encore, ce n'est qu'une partie de l'iceberg. Le problème devient plus épineux avec l'encoding (Base64, Quoted-Printable, UTF-{7,8}, ISO ...) où tu peux prier que le mail spécifie la langue dans laquelle il te parle en lieu place de définir un standard partagé entre les développeurs-réptiliens s'échangeant en secret des règles tacites de ce que devrait être un e-mail en faisant fît du véritable standard (et le gagnant reste Outlook).
Bref, tu t'attaques à un gros morceau pour le coup et il existe déjà, je pense (je ne suis pas adepte du milieu CPP), des librairies qui font ça très bien, qui se sont posé les bonnes questions et qui connaissent ce qui révèle du cas particulier à une résilience assumé face aux erreurs possibles que tu peux retrouver dans les e-mails.
La question est clairement pas simple car, au delà du fait qu'il faut avoir une connaissance assez large de se que tu peux retrouver dans l'intermail (et donc avoir une bonne base, j'ai eu la chance d'avoir ~ 2 000 000 d'e-mails à ma disposition), tu dois aussi connaître au minimum 7 RFC différentes2 pour avoir une vision globale et te poser des vraies questions sur l'API, sur ce qui est acceptable (mais pas autorisé par le standard) et sur ce qui ne l'est pas et trouver un juste milieu qui ne dépends que d'une étude empirique de ce qu'est, dans la vraie vie, l'e-mail (donc au delà du standard).
Je continuerais toujours à dissocier le traitement automatique de l'e-mail du MUA d'ailleurs considérant que ces 2 parties sont déjà assez complexes intrinsèquement qu'une fusion nécessaire des deux demanderait un travail d'autant plus important. Pour le coup, je remets pas tellement en cause l'idée de refaire un MUA (même si d'autres diront que ça existe déjà) mais le traitement automatique d'un e-mail est un travail beaucoup trop conséquent qui fait toujours frétiller les développeurs qui ont été face aux dates de la RFC 822 ou encore à l'adresse e-mail en général1. Une question que je ne peux que te conseiller d'éviter donc.
# RFC 5322 et ... ?
Posté par Dinosaure (site web personnel) . En réponse au journal Epeios Meta Mail User Agent : le protocole IMAP.. Évalué à 4.
J'aurais tout autant aimé que l'e-mail soit décrit sur une seule et unique RFC mais c'est sans compter le legacy avec la RFC 822/2822, le MIME avec la RFC 2045 (2046 .. 2049), les patches comme la RFC 6532 ainsi que quelques arcanes de la RFC 5321 (SMTP) - je me suis amusé1 à faire un tri topologique des dépendances entres les RFCs d'ailleurs.
Et encore, ce n'est qu'une partie de l'iceberg. Le problème devient plus épineux avec l'encoding (Base64, Quoted-Printable, UTF-{7,8}, ISO ...) où tu peux prier que le mail spécifie la langue dans laquelle il te parle en lieu place de définir un standard partagé entre les développeurs-réptiliens s'échangeant en secret des règles tacites de ce que devrait être un e-mail en faisant fît du véritable standard (et le gagnant reste Outlook).
Bref, tu t'attaques à un gros morceau pour le coup et il existe déjà, je pense (je ne suis pas adepte du milieu CPP), des librairies qui font ça très bien, qui se sont posé les bonnes questions et qui connaissent ce qui révèle du cas particulier à une résilience assumé face aux erreurs possibles que tu peux retrouver dans les e-mails.
La question est clairement pas simple car, au delà du fait qu'il faut avoir une connaissance assez large de se que tu peux retrouver dans l'intermail (et donc avoir une bonne base, j'ai eu la chance d'avoir ~ 2 000 000 d'e-mails à ma disposition), tu dois aussi connaître au minimum 7 RFC différentes2 pour avoir une vision globale et te poser des vraies questions sur l'API, sur ce qui est acceptable (mais pas autorisé par le standard) et sur ce qui ne l'est pas et trouver un juste milieu qui ne dépends que d'une étude empirique de ce qu'est, dans la vraie vie, l'e-mail (donc au delà du standard).
Je continuerais toujours à dissocier le traitement automatique de l'e-mail du MUA d'ailleurs considérant que ces 2 parties sont déjà assez complexes intrinsèquement qu'une fusion nécessaire des deux demanderait un travail d'autant plus important. Pour le coup, je remets pas tellement en cause l'idée de refaire un MUA (même si d'autres diront que ça existe déjà) mais le traitement automatique d'un e-mail est un travail beaucoup trop conséquent qui fait toujours frétiller les développeurs qui ont été face aux dates de la RFC 822 ou encore à l'adresse e-mail en général1 . Une question que je ne peux que te conseiller d'éviter donc.
En passant, je me fais un peu de pub pour un projet que je viens de finir il y a quelques mois. ↩
Je ne sais jamais si RFC est féminin ou masculin ↩