Sujet: [php/mail] Pourquoi c'est instable?
31/05/2007 @ 15:28:11: blietaer: [php/mail] Pourquoi c'est instable?
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....

$entete = 'MIME-Version: 1.0' . "\r\n" .
'Organization: http://www.mon-site.be' . "\r\n" .
'X-Priority: 3 (Normal);' . "\r\n" .
'Mime-Version: 1.0' . "\r\n" .
'Content-Transfer-Encoding: 8bit;' . "\r\n" .
'Date:'.date("D, d M Y h:s:i").' +0300' . "\r\n" .
'Content-type: text/html; harset=iso-8859-15' . "\r\n";


$entete .= 'From: office@mon-site.be' . "\r\n" .
'Reply-To: office@mon-site.be' . "\r\n" .
'Return-Path: office@mon-site.be' . "\r\n" .
'X-Mailer: PHP/' . phpversion();

mail($email, $titre, $message, $entete);




Une question : Pourquoi?
31/05/2007 @ 15:42:09: cauet: [php/mail] Pourquoi c'est instable?
Les \r ne servent à rien.
31/05/2007 @ 15:46:31: blietaer: [php/mail] Pourquoi c'est instable?
Donc ils ne sont pas la cause non plus?
31/05/2007 @ 15:48:58: cauet: [php/mail] Pourquoi c'est instable?
justement si. Ils peuvent provoquer une malformation du header ce qui peux rendre le mail illisible.
31/05/2007 @ 15:54:40: blietaer: [php/mail] Pourquoi c'est instable?
mais c'est cela que je ne pige pas le mail est vide sauf le header qui est nickel:


Return-Path: <office@mon-site.be>
Received: (qmail 3091 invoked by uid 1002); 31 May 2007 13:49:02 -0000
To: blietaer@***********************
MIME-Version: 1.0
Organization: http://www.mon-site.be
X-Priority: 3 (Normal);
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit;
Date: Thu, 31 May 2007 03:02:49 +0300
Content-type: text/html; charset=iso-8859-15
From: office@mon-site.be Add to Address BookAdd to Address Book Add Mobile Alert
Reply-to: office@mon-site.be
X-Mailer: PHP/5.1.4
Content-Length: 944

31/05/2007 @ 17:05:28: etik: [php/mail] Pourquoi c'est instable?
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"
31/05/2007 @ 17:07:51: philfr: [php/mail] Pourquoi c'est instable?
cauet> les \r font partie de la spec...

3.2. HEADER FIELD DEFINITIONS

These rules show a field meta-syntax, without regard for the
particular type or internal syntax. Their purpose is to permit
detection of fields; also, they present to higher-level parsers
an image of each field as fitting on one line.

field = field-name ":" [ field-body ] CRLF

field-name = 1*<any CHAR, excluding CTLs, SPACE, and ":">

field-body = field-body-contents
[CRLF LWSP-char field-body]

field-body-contents =
<the ASCII characters making up the field-body, as
defined in the following sections, and consisting
of combinations of atom, quoted-string, and
specials tokens, or else consisting of texts>

August 13, 1982 - 9 - RFC #822


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 ?
31/05/2007 @ 17:19:51: zion: [php/mail] Pourquoi c'est instable?
cauet> les \r font partie de la spec...


Marrant, si tu le rajoutes, skynet a tendance a te foirer tes mails... si tu le mets pas ça passe :petrus:
Et bon pour un site belge de pas savoir écrire à skynet... :petrus:
31/05/2007 @ 18:38:39: philfr: [php/mail] Pourquoi c'est instable?
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 ?
31/05/2007 @ 18:49:33: ovh: [php/mail] Pourquoi c'est instable?
Oublie la fonction mail() et utilise une classe toute faite telle que PHPMailer :oh:
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 :dawa:
31/05/2007 @ 19:20:16: blietaer: [php/mail] Pourquoi c'est instable?
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é.

31/05/2007 @ 19:41:58: didix: [php/mail] Pourquoi c'est instable?
Le html dans les mails c'est le mal :oh:
31/05/2007 @ 21:02:38: blietaer: [php/mail] Pourquoi c'est instable?
ça je suis le premier à le dire....
31/05/2007 @ 21:55:45: Ppxl: [php/mail] Pourquoi c'est instable?
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!
31/05/2007 @ 23:46:17: Altar: [php/mail] Pourquoi c'est instable?
On ne peut pas jetter le protocol (e)smtp et faire quelque chose de moins merdique déjà ? :kiki:
01/06/2007 @ 10:28:10: zion: [php/mail] Pourquoi c'est instable?
On ne peut pas jetter le protocol (e)smtp et faire quelque chose de moins merdique déjà ? :kiki:


T'en veux vraiment à tous les protocoles toi :ddr555:

Mais je plussoie pour qu'on remplace un jour le SMTP quand même, il se fait vieux de nos jours :oh:
01/06/2007 @ 10:35:17: cauet: [php/mail] Pourquoi c'est instable?
+1 pour la mort du SMTP.
Mais y'a t'il quelque chose en cours de reflexion au moins?
01/06/2007 @ 10:40:13: blietaer: [php/mail] Pourquoi c'est instable?
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...
01/06/2007 @ 10:45:12: Altar: [php/mail] Pourquoi c'est instable?


T'en veux vraiment à tous les protocoles toi :ddr555:

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


J'y peux rien si on continue à utiliser des protocols patchés des années 70 :spamafote:
01/06/2007 @ 12:40:58: philfr: [php/mail] Pourquoi c'est instable?


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


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.
Retour