J'utilise un script pour envoyer des mails dans PHP...
Le texte (en html) est foutu dans une grosse variable "$message"
Pareil pour le titre..

Le comportement est assez bizare:
sous hotmail : impeccable, cela apparait.
sous yahoo: le mail est vide
sous free : le mail est vide, le message est en attaché (??)
sous un outlook: parfois ok, parfois vide....



Une question : Pourquoi?

Les \r ne servent à rien.

Donc ils ne sont pas la cause non plus?

justement si. Ils peuvent provoquer une malformation du header ce qui peux rendre le mail illisible.

mais c'est cela que je ne pige pas le mail est vide sauf le header qui est nickel:

Manque un c, mais a part ca...

'Content-type: text/html; Charset=iso-8859-15' . "\r\n";

J'utilise aussi php pour envoyer du mail html, pas de soucis mais mon header est bcp plus simple. Essaye avec un header simplifie, voir si ca passe mieux

"MIME-Version: 1.0\r\nContent-Type:text/html;charset=iso-8859-1\r\nFrom: xxx xxx@nowhere.com>\r\n"

cauet> les \r font partie de la spec...


Le problème est ailleurs, par exemple dans le message.
Blibli, tu peux montrer le contenu du message ou tester avec un message texte à la con ?

Marrant, si tu le rajoutes, skynet a tendance a te foirer tes mails... si tu le mets pas ça passe
Et bon pour un site belge de pas savoir écrire à skynet...

Bon, je ne sais pas non plus si le mail() de php ne rajoute pas lui-même des \r aux \n...
Auquel cas, il vaut mieux ne pas les mettre soi-même en effet.

Après vérification, les headers doivent contenir le \r, mais pas le message...
Mais surtout, je vois que la fonction mail() ne prend pas du tout les arguments que blietaer donne...
D'où vient le To: par exemple ?

Oublie la fonction mail() et utilise une classe toute faite telle que PHPMailer
Tu dois pas te casser avec les headers à ce moment-là. Tu tapes le corps du message en html, et il fait tout pour toi bien comme il faut

en fait les messages passent bien...yahoo ne les affichent pas parce que c'est du html...chiant

etik> oui sorry erreur de copier/coller
philfr> j'ai en effet juste copié les specs....
ovh> j'aime bien un header bien complet : quand je regarde passer mes messages à l'anti-spam j'ai une cote super basse de 0,09/10 !! dès que je retire des éléments du header je grimpe dans la cote de spam.
philfr> tester avec un truc à la con, c'est en effet le test à faire (demain)..je crois que le problème vient clairement des différentes manière de bien vouloir (ou pas) afficher un contenu pure HTML ...et de nouveau (comme pour l'utf-8) y 'a pas deux webmails qui suivent la même politique...grrr...le mail est vraiment de loin l'outil informatique le moins standardisé.

Le html dans les mails c'est le mal

ça je suis le premier à le dire....

avec partimonie moi je trouve ca mieux.
Ca donne un peu de formes et couleurs, un peu de visuel au lieu d'un simple texte monotone à la queue leu-leu.

Sans excès, bien-sûr!

On ne peut pas jetter le protocol (e)smtp et faire quelque chose de moins merdique déjà ?

T'en veux vraiment à tous les protocoles toi

Mais je plussoie pour qu'on remplace un jour le SMTP quand même, il se fait vieux de nos jours

+1 pour la mort du SMTP.
Mais y'a t'il quelque chose en cours de reflexion au moins?

le SMTP est-il vraiment à la base du problème incompatibilitée généralisée?
moi j'avais l'impression que le jour où hotmail lirait un header en entier et que les différents webmail et clients mails se parleraient, ça irait déjà mieux...

J'y peux rien si on continue à utiliser des protocols patchés des années 70

Ces protocoles font justement preuve d'une très grande souplesse et évolutivité pour être toujours parfaitement utilsables aujourd'hui.

À la fin de mes études, on enterrait l'obsolète TCP/IP au profit du modèle OSI, X.400...
Il y a moins longtemps, le WAP forum, victime du syndrome "Not Invented Here", redéfinissait chaque composant du stack IP/TCP/HTTP/HTML en y ajoutant un W...

Et qu'est ce qui tourne partout ?

Tous ceux qui font de la messagerie non (E)SMTP restent et resteront dans des niches propriétaires. (exchange, notes...)
Les problèmes liés à SMTP (spam, spoof & co.) ne sont pas dûs au protocole mais à son contexte d'utilisation, et doivent être résolus, non en changeant de protocole, mais en le complétant judicieusement par des ajouts spécifiques.

Dans le cas présent, SMTP n'est pas en cause dans le problème de blietaer.
Une fonction "view source" permettrait sans doute de voir que l'HTML est bien là mais pas rendered.

Une bonne pratique pour l'e-mail (qui il me semble est obligatoire, mais je ne me souviens plus dans quelle spec), est de toujours avoir une version text/plain dans un multipart/alternative. Beaucoup de mailers s'en passent, mais si l'un d'entre eux voulait respecter (ce que je crois être) le standard à la lettre, il pourrait refuser un content-type html pur.