Worldlex Wiki Le courrier électronique HTML est l'utilisation d'un sous-ensemble de HTML pour fournir des capacités de formatage et de balisage sémantique dans le courrier électronique qui ne sont pas disponibles avec du texte brut : Le texte peut être lié sans afficher d' URL ou diviser de longues URL en plusieurs parties. Le texte est enveloppé pour s'adapter à la largeur de la fenêtre de visualisation, plutôt que de diviser uniformément chaque ligne à 78 caractères (défini dans la RFC 5322, ce qui était nécessaire sur les anciens terminaux texte ). Il permet l'inclusion en ligne d'images, de tableaux , ainsi que de diagrammes ou de formules mathématiques sous forme d'images, qui sont autrement difficiles à transmettre (généralement en utilisant l'art ASCII ).
Adoption
La plupart des clients de messagerie graphiques prennent en charge les e-mails HTML et beaucoup d'entre eux l'utilisent par défaut. La plupart de ces clients incluent à la fois un éditeur d'interface graphique pour la composition d'e-mails HTML et un moteur de rendu pour l'affichage des e-mails HTML reçus.
Depuis sa création, un certain nombre de personnes se sont opposées à tous les e-mails HTML (et même à MIME lui-même), pour diverses raisons. Par exemple, la campagne ASCII Ribbon a préconisé que tous les e-mails soient envoyés au format texte ASCII . La campagne n'a pas abouti et a été abandonnée en 2013. Bien qu'il soit toujours considéré comme inapproprié dans de nombreux messages de groupes de discussion et listes de diffusion, son adoption pour le courrier personnel et professionnel n'a fait qu'augmenter au fil du temps. Certains de ceux qui s'y sont fortement opposés lors de sa première apparition le considèrent désormais comme essentiellement inoffensif.
Selon des enquêtes menées par des sociétés de marketing en ligne , l'adoption de clients de messagerie compatibles HTML est désormais presque universelle, avec moins de 3 % des utilisateurs déclarant utiliser des clients texte uniquement. La majorité des utilisateurs préfèrent recevoir des e-mails HTML plutôt que du texte brut.
Compatibilité
Les logiciels de messagerie conformes à la norme RFC 2822 ne doivent prendre en charge que le formatage en texte brut, et non le formatage HTML. L'envoi d'e-mails au format HTML peut donc entraîner des problèmes si le client de messagerie du destinataire ne le prend pas en charge. Dans le pire des cas, le destinataire verra le code HTML au lieu du message prévu.
Parmi les clients de messagerie qui prennent en charge le format HTML, certains ne le restituent pas de manière cohérente avec les spécifications du W3C , et de nombreux e-mails HTML ne sont pas non plus conformes, ce qui peut entraîner des problèmes de rendu ou de livraison.
En particulier, la <head>balise, qui est utilisée pour héberger les règles de style CSS pour un document HTML entier, n'est pas bien prise en charge, parfois supprimée entièrement, ce qui fait que les déclarations de style en ligne sont la norme de facto , même si les déclarations de style en ligne sont inefficaces et ne parviennent pas à tirer le meilleur parti de la capacité du HTML à séparer le style du contenu. Bien que des solutions de contournement aient été développées, cela n'a pas manqué de provoquer une pénurie de frustration parmi les développeurs de newsletters, engendrant le projet de base Email Standards Project, qui note les clients de messagerie sur leur rendu d'un test acide, inspiré de ceux du Web Standards Project , et fait pression sur les développeurs pour améliorer leurs produits. Pour persuader Google d'améliorer le rendu dans Gmail , par exemple, ils ont publié un montage vidéo de développeurs Web grimaçants, ce qui a attiré l'attention d'un employé.
Style
Certains expéditeurs peuvent s'appuyer de manière excessive sur des polices de caractères de grande taille, colorées ou distrayantes , ce qui rend les messages plus difficiles à lire. Pour ceux qui sont particulièrement gênés par ce formatage, certains agents utilisateurs permettent au lecteur de contourner partiellement le formatage (par exemple, Mozilla Thunderbird permet de spécifier une taille de police minimale) ; cependant, ces fonctionnalités ne sont pas disponibles à l'échelle mondiale. De plus, la différence d'apparence optique entre l'expéditeur et le lecteur peut aider à différencier l'auteur de chaque section, améliorant ainsi la lisibilité.
Formats en plusieurs parties
De nombreux serveurs de messagerie sont configurés pour générer automatiquement une version en texte brut d'un message et l'envoyer avec la version HTML, afin de garantir qu'il puisse être lu même par les clients de messagerie texte uniquement , en utilisant le , comme spécifié dans la RFC 1521. Le message lui-même est de type , et contient deux parties, la première de type , qui est lue par les clients texte uniquement, et la seconde avec , qui est lue par les clients compatibles HTML. La version en texte brut peut toutefois manquer d'informations de formatage importantes. (Par exemple, une équation mathématique peut perdre un exposant et prendre un sens entièrement nouveau.) Content-Type: multipart/alternativemultipart/alternativetext/plaintext/html
De nombreuses listes de diffusion bloquent délibérément les courriers électroniques HTML, soit en supprimant la partie HTML pour ne laisser que la partie en texte brut, soit en rejetant l'intégralité du message.
L'ordre des parties est important. La RFC1341 stipule que : En général, les agents utilisateurs qui composent des entités multiparties/alternatives doivent placer les parties du corps par ordre croissant de préférence, c'est-à-dire avec le format préféré en dernier. Pour les e-mails multiparties avec des versions HTML et en texte brut, cela signifie lister la version en texte brut en premier et la version HTML après, sinon le client peut afficher par défaut la version en texte brut même si une version HTML est disponible.
Taille du message
Les messages HTML sont plus volumineux que les messages au format texte brut. Même si aucun formatage spécial n'est utilisé, les balises utilisées dans un document HTML minimal seront prises en compte, et si le formatage est utilisé de manière intensive, elles peuvent être beaucoup plus importantes. Les messages en plusieurs parties, avec des copies dupliquées du même contenu dans des formats différents, augmentent encore davantage la taille. La section de texte brut d'un message en plusieurs parties peut cependant être récupérée seule, à l'aide de la commande FETCH d' IMAP .
Bien que la différence de temps de téléchargement entre le texte brut et le message mixte (qui peut être un facteur de dix ou plus) ait été préoccupante dans les années 1990 (quand la plupart des utilisateurs accédaient aux serveurs de messagerie via des modems lents ), sur une connexion moderne, la différence est négligeable pour la plupart des gens, en particulier lorsqu'elle est comparée aux images, aux fichiers musicaux ou à d'autres pièces jointes courantes.
Vulnérabilités de sécurité
Le HTML permet de masquer un lien, mais de l'afficher sous la forme d'un texte quelconque, comme un nom de cible convivial. Cela peut être utilisé dans les attaques de phishing , dans lesquelles les utilisateurs sont trompés et se connectent à un site Web contrefait et révèlent des informations personnelles (comme des numéros de compte bancaire) à un escroc.
Si un e-mail contient du contenu en ligne provenant d'un serveur externe, comme une image , sa récupération nécessite une requête auprès de ce serveur externe qui identifie l'emplacement où l'image sera affichée et d'autres informations sur le destinataire. Les bugs Web sont des images spécialement créées (généralement uniques pour chaque e-mail) destinées à suivre cet e-mail et à informer son créateur que l'e-mail a été ouvert. Cela révèle, entre autres, qu'une adresse e-mail est réelle et peut être ciblée à l'avenir.
Certaines attaques de phishing s'appuient sur des fonctionnalités particulières du HTML :
- Usurpation d'identité de marque avec des graphiques générés de manière procédurale (ces graphiques peuvent ressembler à une image de marque déposée mais échapper à l'analyse de sécurité car il n'y a pas de fichier)
- Texte contenant des caractères Unicode invisibles ou avec une police de hauteur nulle pour perturber l'analyse de sécurité
- URI spécifique à la victime, où un lien malveillant code des informations spéciales qui permettent de personnaliser un site contrefait (apparaissant comme le compte de la victime) afin d'être plus convaincant.
L'affichage du contenu HTML implique souvent que le programme client fasse appel à des routines spéciales pour analyser et restituer le texte codé HTML ; un contenu délibérément mal codé peut alors exploiter les erreurs de ces routines pour créer des violations de sécurité. Les demandes de polices spéciales, etc., peuvent également avoir un impact sur les ressources du système.
En période de menaces accrues sur le réseau, le ministère de la Défense américain a converti les courriers électroniques HTML entrants des utilisateurs en courriers électroniques texte.
Le type multipart est destiné à afficher le même contenu de différentes manières, mais cette méthode est parfois utilisée à mauvais escient ; certains spams utilisent ce format pour tromper les filtres anti-spam en leur faisant croire que le message est légitime. Ils y parviennent en incluant du contenu inoffensif dans la partie texte du message et en plaçant le spam dans la partie HTML (celle qui est affichée à l'utilisateur).
La plupart des courriers indésirables sont envoyés au format HTML pour ces raisons, c'est pourquoi les filtres anti-spam attribuent parfois des scores de spam plus élevés aux messages HTML.
En 2018, une vulnérabilité ( EFAIL ) du traitement HTML de nombreux clients de messagerie courants a été révélée, dans laquelle le texte déchiffré des parties de courrier électronique chiffrées PGP ou S/MIME peut être envoyé sous forme d'attribut à une adresse d'image externe, si l'image externe est demandée. Cette vulnérabilité était présente dans Thunderbird, macOS Mail, Outlook et, plus tard, Gmail et Apple Mail.