Est-ce que la façon dont est codé le mail ci-dessous est casher ou pas ?
Les caractères accentués dans la partie HTML apparaissent correctement
chez la plupart des destinataires, mais pas tous... Et bizarremment
uniquement depuis un changement de SMTP (c'est une newsletter).
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Olivier Miakinen
Le 23/05/2017 23:40, pehache a écrit :
Est-ce que la façon dont est codé le mail ci-dessous est casher ou pas ? Les caractères accentués dans la partie HTML apparaissent correctement chez la plupart des destinataires, mais pas tous... Et bizarremment uniquement depuis un changement de SMTP (c'est une newsletter).
Voyons voir...
==================================================================== > MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_bbb1f465d410c161fd408c7513182b31" This is a message in Mime Format. If you see this, your mail reader does not support this format. --=_bbb1f465d410c161fd408c7513182b31
Jusque là ça me semble correct.
Content-Type: text/plain Content-Transfer-Encoding: 8bit <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
??? Il y a du HTML, alors que ça devrait être du « text/plain ». Qui plus est, vu qu'aucun charset n'est annoncé, ça doit être de l'ASCII et l'encodage 7bit devrait suffire.
Ici il est annoncé de l'UTF-8. Et donc, au lieu de : Content-Type: text/plain il faudrait : Content-Type: text/html; charset=UTF-8 Conclusion : pas casher du tout. Non seulement à cause des caractères accentués, mais aussi et surtout les courrielleurs qui interprètent ce message comme du HTML ont tort. -- Olivier Miakinen
Le 23/05/2017 23:40, pehache a écrit :
Est-ce que la façon dont est codé le mail ci-dessous est casher ou pas ?
Les caractères accentués dans la partie HTML apparaissent correctement
chez la plupart des destinataires, mais pas tous... Et bizarremment
uniquement depuis un changement de SMTP (c'est une newsletter).
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
???
Il y a du HTML, alors que ça devrait être du « text/plain ». Qui plus
est, vu qu'aucun charset n'est annoncé, ça doit être de l'ASCII et
l'encodage 7bit devrait suffire.
Et donc, au lieu de :
Content-Type: text/plain
il faudrait :
Content-Type: text/html; charset=UTF-8
Conclusion : pas casher du tout. Non seulement à cause des caractères
accentués, mais aussi et surtout les courrielleurs qui interprètent ce
message comme du HTML ont tort.
Est-ce que la façon dont est codé le mail ci-dessous est casher ou pas ? Les caractères accentués dans la partie HTML apparaissent correctement chez la plupart des destinataires, mais pas tous... Et bizarremment uniquement depuis un changement de SMTP (c'est une newsletter).
Voyons voir...
==================================================================== > MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_bbb1f465d410c161fd408c7513182b31" This is a message in Mime Format. If you see this, your mail reader does not support this format. --=_bbb1f465d410c161fd408c7513182b31
Jusque là ça me semble correct.
Content-Type: text/plain Content-Transfer-Encoding: 8bit <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
??? Il y a du HTML, alors que ça devrait être du « text/plain ». Qui plus est, vu qu'aucun charset n'est annoncé, ça doit être de l'ASCII et l'encodage 7bit devrait suffire.
Ici il est annoncé de l'UTF-8. Et donc, au lieu de : Content-Type: text/plain il faudrait : Content-Type: text/html; charset=UTF-8 Conclusion : pas casher du tout. Non seulement à cause des caractères accentués, mais aussi et surtout les courrielleurs qui interprètent ce message comme du HTML ont tort. -- Olivier Miakinen
pehache
Le 25/05/2017 à 22:02, Olivier Miakinen a écrit :
Le 23/05/2017 23:40, pehache a écrit :
Est-ce que la façon dont est codé le mail ci-dessous est casher ou pas ? Les caractères accentués dans la partie HTML apparaissent correctement chez la plupart des destinataires, mais pas tous... Et bizarremment uniquement depuis un changement de SMTP (c'est une newsletter).
Voyons voir...
==================================================================== >> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_bbb1f465d410c161fd408c7513182b31" This is a message in Mime Format. If you see this, your mail reader does not support this format. --=_bbb1f465d410c161fd408c7513182b31
Jusque là ça me semble correct.
Content-Type: text/plain Content-Transfer-Encoding: 8bit <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
??? Il y a du HTML, alors que ça devrait être du « text/plain ». Qui plus est, vu qu'aucun charset n'est annoncé, ça doit être de l'ASCII et l'encodage 7bit devrait suffire.
Ici il est annoncé de l'UTF-8. Et donc, au lieu de : Content-Type: text/plain il faudrait : Content-Type: text/html; charset=UTF-8 Conclusion : pas casher du tout. Non seulement à cause des caractères accentués, mais aussi et surtout les courrielleurs qui interprètent ce message comme du HTML ont tort.
OK merci. Ca me semblait curieux aussi, même si je me disais que l'entête HTML prenait peut-être le pas sur ce qui précédait. C'est dans une newsletter d'association, gérée par un prestataire dont la compétence me parait de plus en plus douteuse... les gars ont déjà réussi à se griller auprès d'OVH (et à nous griller par ricochet) en ne gérant pas les bounces donc sans jamais nettoyer notre base d'abonnés des adresses en erreur, jusqu'au moment où OVH a tout bloqué vu les taux d'erreurs. Ils ne savaient pas non plus qu'il fallait des enregistrement SPF et DKIM sur le nom de domaine pour optimiser la distribution...
Le 25/05/2017 à 22:02, Olivier Miakinen a écrit :
Le 23/05/2017 23:40, pehache a écrit :
Est-ce que la façon dont est codé le mail ci-dessous est casher ou pas ?
Les caractères accentués dans la partie HTML apparaissent correctement
chez la plupart des destinataires, mais pas tous... Et bizarremment
uniquement depuis un changement de SMTP (c'est une newsletter).
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
???
Il y a du HTML, alors que ça devrait être du « text/plain ». Qui plus
est, vu qu'aucun charset n'est annoncé, ça doit être de l'ASCII et
l'encodage 7bit devrait suffire.
Et donc, au lieu de :
Content-Type: text/plain
il faudrait :
Content-Type: text/html; charset=UTF-8
Conclusion : pas casher du tout. Non seulement à cause des caractères
accentués, mais aussi et surtout les courrielleurs qui interprètent ce
message comme du HTML ont tort.
OK merci. Ca me semblait curieux aussi, même si je me disais que
l'entête HTML prenait peut-être le pas sur ce qui précédait.
C'est dans une newsletter d'association, gérée par un prestataire dont
la compétence me parait de plus en plus douteuse... les gars ont déjà
réussi à se griller auprès d'OVH (et à nous griller par ricochet) en ne
gérant pas les bounces donc sans jamais nettoyer notre base d'abonnés
des adresses en erreur, jusqu'au moment où OVH a tout bloqué vu les taux
d'erreurs. Ils ne savaient pas non plus qu'il fallait des enregistrement
SPF et DKIM sur le nom de domaine pour optimiser la distribution...
Est-ce que la façon dont est codé le mail ci-dessous est casher ou pas ? Les caractères accentués dans la partie HTML apparaissent correctement chez la plupart des destinataires, mais pas tous... Et bizarremment uniquement depuis un changement de SMTP (c'est une newsletter).
Voyons voir...
==================================================================== >> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_bbb1f465d410c161fd408c7513182b31" This is a message in Mime Format. If you see this, your mail reader does not support this format. --=_bbb1f465d410c161fd408c7513182b31
Jusque là ça me semble correct.
Content-Type: text/plain Content-Transfer-Encoding: 8bit <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
??? Il y a du HTML, alors que ça devrait être du « text/plain ». Qui plus est, vu qu'aucun charset n'est annoncé, ça doit être de l'ASCII et l'encodage 7bit devrait suffire.
Ici il est annoncé de l'UTF-8. Et donc, au lieu de : Content-Type: text/plain il faudrait : Content-Type: text/html; charset=UTF-8 Conclusion : pas casher du tout. Non seulement à cause des caractères accentués, mais aussi et surtout les courrielleurs qui interprètent ce message comme du HTML ont tort.
OK merci. Ca me semblait curieux aussi, même si je me disais que l'entête HTML prenait peut-être le pas sur ce qui précédait. C'est dans une newsletter d'association, gérée par un prestataire dont la compétence me parait de plus en plus douteuse... les gars ont déjà réussi à se griller auprès d'OVH (et à nous griller par ricochet) en ne gérant pas les bounces donc sans jamais nettoyer notre base d'abonnés des adresses en erreur, jusqu'au moment où OVH a tout bloqué vu les taux d'erreurs. Ils ne savaient pas non plus qu'il fallait des enregistrement SPF et DKIM sur le nom de domaine pour optimiser la distribution...
pehache
Le 23/05/2017 à 23:40, pehache a écrit :
Bonjour, Est-ce que la façon dont est codé le mail ci-dessous est casher ou pas ? Les caractères accentués dans la partie HTML apparaissent correctement chez la plupart des destinataires, mais pas tous... Et bizarremment uniquement depuis un changement de SMTP (c'est une newsletter).
Un truc que j'avais complètement zappé c'est qu'il y a deux blocs MIME qui se suivent et qui ont des contenus rigoureusement identiques, à part que le premier est déclaré en texte brut, et le second en HTML (mais toujours sans charset déclaré). C'est censé être interprété comment, ça ?? Dans les mails reçu je ne vois qu'une fois le contenu, pas deux. Pour info, ils ont ajouté "charset=UTF-8" au Content-Type du second bloc (celui déclaré en HTML) et ça semble avoir résolu le problème des caractères mal décodés. ================================================================ . . . MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_6fc4b161d4938105579eb4211e64e434" . . . This is a message in Mime Format. If you see this, your mail reader does not support this format. --=_6fc4b161d4938105579eb4211e64e434 Content-Type: text/plain Content-Transfer-Encoding: 8bit <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><title>xxxxxxxxxx</title><style type="text/css">body, #general { margin:0; padding:0; background-color: #1E72B2; font-size:12px; font-family: Arial, Helvetica, sans-serif; text-align: justify; } . . . </html> --=_6fc4b161d4938105579eb4211e64e434 Content-Type: text/html Content-Transfer-Encoding: 8bit <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><title>xxxxxxxxxx</title><style type="text/css">body, #general { margin:0; padding:0; background-color: #1E72B2; font-size:12px; font-family: Arial, Helvetica, sans-serif; text-align: justify; } . . . </html> --=_6fc4b161d4938105579eb4211e64e434--
Le 23/05/2017 à 23:40, pehache a écrit :
Bonjour,
Est-ce que la façon dont est codé le mail ci-dessous est casher ou pas ?
Les caractères accentués dans la partie HTML apparaissent correctement
chez la plupart des destinataires, mais pas tous... Et bizarremment
uniquement depuis un changement de SMTP (c'est une newsletter).
Un truc que j'avais complètement zappé c'est qu'il y a deux blocs MIME
qui se suivent et qui ont des contenus rigoureusement identiques, à part
que le premier est déclaré en texte brut, et le second en HTML (mais
toujours sans charset déclaré).
C'est censé être interprété comment, ça ?? Dans les mails reçu je ne
vois qu'une fois le contenu, pas deux.
Pour info, ils ont ajouté "charset=UTF-8" au Content-Type du second bloc
(celui déclaré en HTML) et ça semble avoir résolu le problème des
caractères mal décodés.
================================================================
.
.
.
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="=_6fc4b161d4938105579eb4211e64e434"
.
.
.
This is a message in Mime Format. If you see this, your mail reader
does not support this format.
Bonjour, Est-ce que la façon dont est codé le mail ci-dessous est casher ou pas ? Les caractères accentués dans la partie HTML apparaissent correctement chez la plupart des destinataires, mais pas tous... Et bizarremment uniquement depuis un changement de SMTP (c'est une newsletter).
Un truc que j'avais complètement zappé c'est qu'il y a deux blocs MIME qui se suivent et qui ont des contenus rigoureusement identiques, à part que le premier est déclaré en texte brut, et le second en HTML (mais toujours sans charset déclaré). C'est censé être interprété comment, ça ?? Dans les mails reçu je ne vois qu'une fois le contenu, pas deux. Pour info, ils ont ajouté "charset=UTF-8" au Content-Type du second bloc (celui déclaré en HTML) et ça semble avoir résolu le problème des caractères mal décodés. ================================================================ . . . MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_6fc4b161d4938105579eb4211e64e434" . . . This is a message in Mime Format. If you see this, your mail reader does not support this format. --=_6fc4b161d4938105579eb4211e64e434 Content-Type: text/plain Content-Transfer-Encoding: 8bit <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><title>xxxxxxxxxx</title><style type="text/css">body, #general { margin:0; padding:0; background-color: #1E72B2; font-size:12px; font-family: Arial, Helvetica, sans-serif; text-align: justify; } . . . </html> --=_6fc4b161d4938105579eb4211e64e434 Content-Type: text/html Content-Transfer-Encoding: 8bit <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><title>xxxxxxxxxx</title><style type="text/css">body, #general { margin:0; padding:0; background-color: #1E72B2; font-size:12px; font-family: Arial, Helvetica, sans-serif; text-align: justify; } . . . </html> --=_6fc4b161d4938105579eb4211e64e434--
Olivier Miakinen
Bonjour, Le 30/05/2017 14:05, pehache a écrit :
Un truc que j'avais complètement zappé c'est qu'il y a deux blocs MIME qui se suivent et qui ont des contenus rigoureusement identiques, à part que le premier est déclaré en texte brut, et le second en HTML (mais toujours sans charset déclaré).
Ah, ben si tu ne donnes pas toutes les infos, aussi ! ;-)
C'est censé être interprété comment, ça ?? Dans les mails reçu je ne vois qu'une fois le contenu, pas deux.
Au plus haut niveau, tu as un Content-Type: multipart/alternative, ce qui signifie que le courrielleur du destinataire choisira le contenu correspondant en principe à ce que le lecteur humain préfère voir. Dans sa configuration par défaut, Thunderbird affiche de préférence la partie en text/html, et la partie en text/plain est alors ignorée. Moi qui préfère réserver le HTML aux sites web et voir les courriels sans mickeys qui clignotent, je choisis de n'afficher que du texte simple. Du coup, Thunderbird affiche de préférence la partie en text/plain et ignore celle en text/html. S'il n'y a que du text/html, Thunderbird en extrait le texte et ignore la mise en page. Pour voir ce que cela donne toi-même : Affichage > Corps du message en > Texte seul C'est vraiment un réglage que je conseille à tous, d'autant que souvent cela permet de ne pas être agressé par un certain nombre de spams où la partie text/plain existe mais est vide ou constituée du seul message « votre logiciel ne sait pas afficher du HTML ». Il est toujours possible de revenir en mode HTML les rares fois où cela s'avère nécessaire.
Pour info, ils ont ajouté "charset=UTF-8" au Content-Type du second bloc (celui déclaré en HTML) et ça semble avoir résolu le problème des caractères mal décodés.
Ça marchera donc pour ceux qui ont la configuration par défaut de la plupart de courrielleurs récents. Mais pas pour les vieux cons comme moi qui préfèrent l'information brute aux spams colorés. -- Olivier Miakinen
Bonjour,
Le 30/05/2017 14:05, pehache a écrit :
Un truc que j'avais complètement zappé c'est qu'il y a deux blocs MIME
qui se suivent et qui ont des contenus rigoureusement identiques, à part
que le premier est déclaré en texte brut, et le second en HTML (mais
toujours sans charset déclaré).
Ah, ben si tu ne donnes pas toutes les infos, aussi ! ;-)
C'est censé être interprété comment, ça ?? Dans les mails reçu je ne
vois qu'une fois le contenu, pas deux.
Au plus haut niveau, tu as un Content-Type: multipart/alternative,
ce qui signifie que le courrielleur du destinataire choisira le
contenu correspondant en principe à ce que le lecteur humain
préfère voir.
Dans sa configuration par défaut, Thunderbird affiche de préférence
la partie en text/html, et la partie en text/plain est alors ignorée.
Moi qui préfère réserver le HTML aux sites web et voir les courriels
sans mickeys qui clignotent, je choisis de n'afficher que du texte
simple. Du coup, Thunderbird affiche de préférence la partie en
text/plain et ignore celle en text/html. S'il n'y a que du text/html,
Thunderbird en extrait le texte et ignore la mise en page.
Pour voir ce que cela donne toi-même :
Affichage > Corps du message en > Texte seul
C'est vraiment un réglage que je conseille à tous, d'autant que
souvent cela permet de ne pas être agressé par un certain nombre
de spams où la partie text/plain existe mais est vide ou constituée
du seul message « votre logiciel ne sait pas afficher du HTML ».
Il est toujours possible de revenir en mode HTML les rares fois où
cela s'avère nécessaire.
Pour info, ils ont ajouté "charset=UTF-8" au Content-Type du second bloc
(celui déclaré en HTML) et ça semble avoir résolu le problème des
caractères mal décodés.
Ça marchera donc pour ceux qui ont la configuration par défaut de la
plupart de courrielleurs récents. Mais pas pour les vieux cons comme
moi qui préfèrent l'information brute aux spams colorés.
Un truc que j'avais complètement zappé c'est qu'il y a deux blocs MIME qui se suivent et qui ont des contenus rigoureusement identiques, à part que le premier est déclaré en texte brut, et le second en HTML (mais toujours sans charset déclaré).
Ah, ben si tu ne donnes pas toutes les infos, aussi ! ;-)
C'est censé être interprété comment, ça ?? Dans les mails reçu je ne vois qu'une fois le contenu, pas deux.
Au plus haut niveau, tu as un Content-Type: multipart/alternative, ce qui signifie que le courrielleur du destinataire choisira le contenu correspondant en principe à ce que le lecteur humain préfère voir. Dans sa configuration par défaut, Thunderbird affiche de préférence la partie en text/html, et la partie en text/plain est alors ignorée. Moi qui préfère réserver le HTML aux sites web et voir les courriels sans mickeys qui clignotent, je choisis de n'afficher que du texte simple. Du coup, Thunderbird affiche de préférence la partie en text/plain et ignore celle en text/html. S'il n'y a que du text/html, Thunderbird en extrait le texte et ignore la mise en page. Pour voir ce que cela donne toi-même : Affichage > Corps du message en > Texte seul C'est vraiment un réglage que je conseille à tous, d'autant que souvent cela permet de ne pas être agressé par un certain nombre de spams où la partie text/plain existe mais est vide ou constituée du seul message « votre logiciel ne sait pas afficher du HTML ». Il est toujours possible de revenir en mode HTML les rares fois où cela s'avère nécessaire.
Pour info, ils ont ajouté "charset=UTF-8" au Content-Type du second bloc (celui déclaré en HTML) et ça semble avoir résolu le problème des caractères mal décodés.
Ça marchera donc pour ceux qui ont la configuration par défaut de la plupart de courrielleurs récents. Mais pas pour les vieux cons comme moi qui préfèrent l'information brute aux spams colorés. -- Olivier Miakinen
pehache
Le 30/05/2017 à 15:06, Olivier Miakinen a écrit :
Bonjour, Le 30/05/2017 14:05, pehache a écrit :
Un truc que j'avais complètement zappé c'est qu'il y a deux blocs MIME qui se suivent et qui ont des contenus rigoureusement identiques, à part que le premier est déclaré en texte brut, et le second en HTML (mais toujours sans charset déclaré).
Ah, ben si tu ne donnes pas toutes les infos, aussi ! ;-)
J'avais pas lu tout le source !
C'est censé être interprété comment, ça ? ? Dans les mails reçu je ne vois qu'une fois le contenu, pas deux.
Au plus haut niveau, tu as un Content-Type: multipart/alternative, ce qui signifie que le courrielleur du destinataire choisira le contenu correspondant en principe à ce que le lecteur humain préfère voir. Dans sa configuration par défaut, Thunderbird affiche de préférence la partie en text/html, et la partie en text/plain est alors ignorée. Moi qui préfère réserver le HTML aux sites web et voir les courriels sans mickeys qui clignotent, je choisis de n'afficher que du texte simple. Du coup, Thunderbird affiche de préférence la partie en text/plain et ignore celle en text/html. S'il n'y a que du text/html, Thunderbird en extrait le texte et ignore la mise en page.
OK... Bon, là vu qu'il y a bien une partie text/plain mais qu'elle contient le code HTML, j'imagine que le lecteur qui choisit le text/plain de préférence va en fait voir le code HTLM (?)...
Pour voir ce que cela donne toi-même : Affichage > Corps du message en > Texte seul
Je regarderai ce soir.
Le 30/05/2017 à 15:06, Olivier Miakinen a écrit :
Bonjour,
Le 30/05/2017 14:05, pehache a écrit :
Un truc que j'avais complètement zappé c'est qu'il y a deux blocs MIME
qui se suivent et qui ont des contenus rigoureusement identiques, à part
que le premier est déclaré en texte brut, et le second en HTML (mais
toujours sans charset déclaré).
Ah, ben si tu ne donnes pas toutes les infos, aussi ! ;-)
J'avais pas lu tout le source !
C'est censé être interprété comment, ça ? ? Dans les mails reçu je
ne
vois qu'une fois le contenu, pas deux.
Au plus haut niveau, tu as un Content-Type: multipart/alternative,
ce qui signifie que le courrielleur du destinataire choisira le
contenu correspondant en principe à ce que le lecteur humain
préfère voir.
Dans sa configuration par défaut, Thunderbird affiche de préférence
la partie en text/html, et la partie en text/plain est alors ignorée.
Moi qui préfère réserver le HTML aux sites web et voir les courriels
sans mickeys qui clignotent, je choisis de n'afficher que du texte
simple. Du coup, Thunderbird affiche de préférence la partie en
text/plain et ignore celle en text/html. S'il n'y a que du text/html,
Thunderbird en extrait le texte et ignore la mise en page.
OK... Bon, là vu qu'il y a bien une partie text/plain mais qu'elle
contient le code HTML, j'imagine que le lecteur qui choisit le text/plain
de préférence va en fait voir le code HTLM (?)...
Pour voir ce que cela donne toi-même :
Affichage > Corps du message en > Texte seul
Un truc que j'avais complètement zappé c'est qu'il y a deux blocs MIME qui se suivent et qui ont des contenus rigoureusement identiques, à part que le premier est déclaré en texte brut, et le second en HTML (mais toujours sans charset déclaré).
Ah, ben si tu ne donnes pas toutes les infos, aussi ! ;-)
J'avais pas lu tout le source !
C'est censé être interprété comment, ça ? ? Dans les mails reçu je ne vois qu'une fois le contenu, pas deux.
Au plus haut niveau, tu as un Content-Type: multipart/alternative, ce qui signifie que le courrielleur du destinataire choisira le contenu correspondant en principe à ce que le lecteur humain préfère voir. Dans sa configuration par défaut, Thunderbird affiche de préférence la partie en text/html, et la partie en text/plain est alors ignorée. Moi qui préfère réserver le HTML aux sites web et voir les courriels sans mickeys qui clignotent, je choisis de n'afficher que du texte simple. Du coup, Thunderbird affiche de préférence la partie en text/plain et ignore celle en text/html. S'il n'y a que du text/html, Thunderbird en extrait le texte et ignore la mise en page.
OK... Bon, là vu qu'il y a bien une partie text/plain mais qu'elle contient le code HTML, j'imagine que le lecteur qui choisit le text/plain de préférence va en fait voir le code HTLM (?)...
Pour voir ce que cela donne toi-même : Affichage > Corps du message en > Texte seul
Je regarderai ce soir.
Otomatic
Olivier Miakinen <om+ écrivait :
Mais pas pour les vieux cons comme moi qui préfèrent l'information brute aux spams colorés.
Mon courrielleur The Bat a quand même un onglet noté HTML au bas de la fenêtre de lecture des messages. Ça me sert de temps en temps. -- Plastifions le tissu social pour mettre en réseau les synergies intergénérationelles sur un plan proactif, induisant une sensibilisation citoyenne et interactive, garantie d'un véritable dialogue pluriel ! Ministère des Partenariats Durables - Objectifs 2015-2035
Mais pas pour les vieux cons comme
moi qui préfèrent l'information brute aux spams colorés.
Mon courrielleur The Bat a quand même un onglet noté HTML au bas de la
fenêtre de lecture des messages.
Ça me sert de temps en temps.
--
Plastifions le tissu social pour mettre en réseau les synergies
intergénérationelles sur un plan proactif, induisant une sensibilisation
citoyenne et interactive, garantie d'un véritable dialogue pluriel !
Ministère des Partenariats Durables - Objectifs 2015-2035
Mais pas pour les vieux cons comme moi qui préfèrent l'information brute aux spams colorés.
Mon courrielleur The Bat a quand même un onglet noté HTML au bas de la fenêtre de lecture des messages. Ça me sert de temps en temps. -- Plastifions le tissu social pour mettre en réseau les synergies intergénérationelles sur un plan proactif, induisant une sensibilisation citoyenne et interactive, garantie d'un véritable dialogue pluriel ! Ministère des Partenariats Durables - Objectifs 2015-2035
Olivier Miakinen
Le 30/05/2017 16:41, pehache a écrit :
OK... Bon, là vu qu'il y a bien une partie text/plain mais qu'elle contient le code HTML, j'imagine que le lecteur qui choisit le text/plain de préférence va en fait voir le code HT[ML] (?)...
C'est ce que je pense. D'ailleurs c'est ce que je t'écrivais dans ma première réponse, en supposant que cette partie était la seule existante : si un courrielleur affiche autre chose que le *code* HTML quand il affiche cette partie en text/plain, il est en tort.
Pour voir ce que cela donne toi-même : Affichage > Corps du message en > Texte seul
Je regarderai ce soir.
Tiens-nous au courant. Outre le fait que ça doit t'afficher le code HTML avec toutes ses balises, il risque d'y avoir encore un problème de charset puisque l'UTF-8 n'y est toujours pas déclaré. -- Olivier Miakinen
Le 30/05/2017 16:41, pehache a écrit :
OK... Bon, là vu qu'il y a bien une partie text/plain mais qu'elle
contient le code HTML, j'imagine que le lecteur qui choisit le text/plain
de préférence va en fait voir le code HT[ML] (?)...
C'est ce que je pense. D'ailleurs c'est ce que je t'écrivais dans
ma première réponse, en supposant que cette partie était la seule
existante : si un courrielleur affiche autre chose que le *code*
HTML quand il affiche cette partie en text/plain, il est en tort.
Pour voir ce que cela donne toi-même :
Affichage > Corps du message en > Texte seul
Je regarderai ce soir.
Tiens-nous au courant. Outre le fait que ça doit t'afficher le
code HTML avec toutes ses balises, il risque d'y avoir encore un
problème de charset puisque l'UTF-8 n'y est toujours pas déclaré.
OK... Bon, là vu qu'il y a bien une partie text/plain mais qu'elle contient le code HTML, j'imagine que le lecteur qui choisit le text/plain de préférence va en fait voir le code HT[ML] (?)...
C'est ce que je pense. D'ailleurs c'est ce que je t'écrivais dans ma première réponse, en supposant que cette partie était la seule existante : si un courrielleur affiche autre chose que le *code* HTML quand il affiche cette partie en text/plain, il est en tort.
Pour voir ce que cela donne toi-même : Affichage > Corps du message en > Texte seul
Je regarderai ce soir.
Tiens-nous au courant. Outre le fait que ça doit t'afficher le code HTML avec toutes ses balises, il risque d'y avoir encore un problème de charset puisque l'UTF-8 n'y est toujours pas déclaré. -- Olivier Miakinen
pehache
Le 30/05/2017 à 16:59, Olivier Miakinen a écrit :
Le 30/05/2017 16:41, pehache a écrit :
OK... Bon, là vu qu'il y a bien une partie text/plain mais qu'elle contient le code HTML, j'imagine que le lecteur qui choisit le text/plain de préférence va en fait voir le code HT[ML] (?)...
C'est ce que je pense. D'ailleurs c'est ce que je t'écrivais dans ma première réponse, en supposant que cette partie était la seule existante : si un courrielleur affiche autre chose que le *code* HTML quand il affiche cette partie en text/plain, il est en tort.
Pour voir ce que cela donne toi-même : Affichage > Corps du message en > Texte seul
Je regarderai ce soir.
Tiens-nous au courant. Outre le fait que ça doit t'afficher le code HTML avec toutes ses balises, il risque d'y avoir encore un problème de charset puisque l'UTF-8 n'y est toujours pas déclaré.
Gagné... Tous ces gars qui bossent dans les boîte de services web ils ont fait quoi comme études ? L'école du rire ?
Le 30/05/2017 à 16:59, Olivier Miakinen a écrit :
Le 30/05/2017 16:41, pehache a écrit :
OK... Bon, là vu qu'il y a bien une partie text/plain mais qu'elle
contient le code HTML, j'imagine que le lecteur qui choisit le text/plain
de préférence va en fait voir le code HT[ML] (?)...
C'est ce que je pense. D'ailleurs c'est ce que je t'écrivais dans
ma première réponse, en supposant que cette partie était la seule
existante : si un courrielleur affiche autre chose que le *code*
HTML quand il affiche cette partie en text/plain, il est en tort.
Pour voir ce que cela donne toi-même :
Affichage > Corps du message en > Texte seul
Je regarderai ce soir.
Tiens-nous au courant. Outre le fait que ça doit t'afficher le
code HTML avec toutes ses balises, il risque d'y avoir encore un
problème de charset puisque l'UTF-8 n'y est toujours pas déclaré.
Gagné...
Tous ces gars qui bossent dans les boîte de services web ils ont fait
quoi comme études ? L'école du rire ?
OK... Bon, là vu qu'il y a bien une partie text/plain mais qu'elle contient le code HTML, j'imagine que le lecteur qui choisit le text/plain de préférence va en fait voir le code HT[ML] (?)...
C'est ce que je pense. D'ailleurs c'est ce que je t'écrivais dans ma première réponse, en supposant que cette partie était la seule existante : si un courrielleur affiche autre chose que le *code* HTML quand il affiche cette partie en text/plain, il est en tort.
Pour voir ce que cela donne toi-même : Affichage > Corps du message en > Texte seul
Je regarderai ce soir.
Tiens-nous au courant. Outre le fait que ça doit t'afficher le code HTML avec toutes ses balises, il risque d'y avoir encore un problème de charset puisque l'UTF-8 n'y est toujours pas déclaré.
Gagné... Tous ces gars qui bossent dans les boîte de services web ils ont fait quoi comme études ? L'école du rire ?
