Bonjour,

j'ai chez OVH :

- un hébergement mutualisé 90plan,
- deux héberbements dédiés mini Superplan (Gentoo - OVH release2),

sur ces trois serveurs tourne une même application PHP qui peut envoyer des emails avec la fonction PHP mail(), avec signature graphique et pièce jointe (PDF)

le problème :
=> avec envoi par le serveur mutualisé les emails arrivent correctement dans Thunderbird, Outlook, Outlook-Express,
=> avec envoi par un des serveurs dédiés, les emails n'arrivent proprement que dans Thunderbird, les fichiers attachés n'arrivent pas proprement dans Outlook et Outlook-Express,


les configurations PHP des serveurs peuvent être lues à ces adresses :
=> mutualisé : http://90plan.ovh.net/test.php
=> dédié : http://ns367247.ovh.net/test.php


complément d'information :

code source d'un même email envoyé par chaque serveur (mutualisé & dédié),
par script PHP strictement identique sur le serveur mutualisé et sur un des deux serveur dédié,

la seule différence que j'ai pu constaté entre les deux codes sources des emails,
est que les lignes suivantes ne sont pas au même endroit :
ces lignes sont avant la première déclaration de "boundary" avec envoi par le serveur dédié,
et après la première déclaration de "boundary" avec envoi par le serveur mutualisé,
il me semble que c'est plus propre avant la première déclaration de "boundary" (serveur dédié),

code source des emails :

=====code source email serveur mutualisé
=====code source email serveur dédié

Chouette, un problème détaillé.

Alors j'ai fait un diff sur les deux versions.
Hormis les différences dûe au transit du mail, il y en a une majeure (bien que d'un caractère ) : Après un saut sur les RFC, apparement l'écriture "Champ :" n'est pas correcte, c'est "Champ:" qui est correct.
Alors, on va commencer par pourquoi est ce que ça marche sous Thunderbird et non sous Outlook. Il faut savoir que bien que les RFC soient considérées comme des standards, chaque client mail a sa propre implémentation, plus ou moins laxiste. Cela explique pourquoi Outlook, qui doit avoir une interprétation stricte, ne reconnaît pas les mails, alors que Thunderbird, qui apparement est plus laxiste, le reconnaît.
Ensuite, pourquoi est ce que cela marche sur le mutualisé et non le dédié. Là aussi, chaque serveur mail implémente les standards à sa façon. Et certains vont reconnaître l'erreur et la prendre en compte, d'autres ne vont pas trouver l'erreur. Cela explique aussi peut être (mais je le connais pas assez la norme pour l'attester) la différence de placement du Message-ID et de la Date. A savoir que si le serveur reconnaît le mail multipart, il peut placer ces informations au bon endroit.

Je pense donc que dans ton code tu as mis les champs sous cette forme : Je te suggère de corriger en : Voilà

Bonjour Sékiltoyai,

et mille merci, il semblerait bien que tu ais trouvé mon problème !,

tout d'abord, => "Chouette, un problème détaillé.",
et oui, je ne connais pas tout sur tout, mais malgré tout informaticien, donc, un problème exposé au mieux,

j'avais déjà noté ce détail, mais j'ai tellement trituré ces fichiers dans tous les sens, que j'en ai oublié cette vérif sur la dernière version mise en ligne,

effectivement, comme tu le dis, pour une fois, c'est MS qui est dans son bon droit !, c'est suffisamment rare pour le souligner,

par contre, pourrais-tu m'indiquer ta méthode de vérification des RFC ?,
as-tu utilisé google, ou bien sais tu à quel endroit il faut se rendre exactement ?,
je ne sais pas encore me servir de ces sites là,
je ne sais pas les trouver, et qu'en j'en trouve, je ne sais pas exploiter le contenu tellement il est riche,

en tout cas, encore merci, je ne voyais pas comment m'en sortir,
je vais maintenant pouvoir corriger mes autres scripts d'envoi d'email,

ha tient, pendant que je tiens un spécialiste,
j'ai analysé le code source d'un email envoyé par Outlook Express,
et j'ai vu qu'il écrivait un code que je n'ai pas pu interpréter et pour pour lequel je n'ai rien trouvé d'explicite sur le net,
regarde le code qui suit, tu y verras le code "3D" inséré un peu curieusement dans le code de la partie HTMl, sais tu de quoi il s'agit,
mais, même sans ce codage particulier, les emails sont maintenant propre dans les 3 clients cités, encore merci, à+ ...
Nils.

tout d'abord, => "Chouette, un problème détaillé.",
et oui, je ne connais pas tout sur tout, mais malgré tout informaticien, donc, un problème exposé au mieux,

Si tout le monde pouvait résumer comme toi…

j'avais déjà noté ce détail, mais j'ai tellement trituré ces fichiers dans tous les sens, que j'en ai oublié cette vérif sur la dernière version mise en ligne,

Avec un peu d'expérience, on repère rapidement les détails qui importent

effectivement, comme tu le dis, pour une fois, c'est MS qui est dans son bon droit !, c'est suffisamment rare pour le souligner,

Ne faisons pas d'anti-Microsoftisme de base. Il n'y a pas de bon droit, c'est une question de choix technique. Etre laxiste ou strict c'est juste question de politique.
Et puis il y a aussi quelques bons produits chez Microsoft.

par contre, pourrais-tu m'indiquer ta méthode de vérification des RFC ?,
as-tu utilisé google, ou bien sais tu à quel endroit il faut se rendre exactement ?,
je ne sais pas encore me servir de ces sites là,
je ne sais pas les trouver, et qu'en j'en trouve, je ne sais pas exploiter le contenu tellement il est riche,

Bah RFC dans google. Ou bien tu vas sur Wikipedia sur l'article du sujet qui t'intéresse, quasiment systématiquement tu trouveras les RFC dans les sources. Ou encore tu vas directement sur le site de l'IETF (organisme qui gère les groupes d'écritures des RFC).

en tout cas, encore merci, je ne voyais pas comment m'en sortir,
je vais maintenant pouvoir corriger mes autres scripts d'envoi d'email,

De rien.

ha tient, pendant que je tiens un spécialiste,
j'ai analysé le code source d'un email envoyé par Outlook Express,
et j'ai vu qu'il écrivait un code que je n'ai pas pu interpréter et pour pour lequel je n'ai rien trouvé d'explicite sur le net,
regarde le code qui suit, tu y verras le code "3D" inséré un peu curieusement dans le code de la partie HTMl, sais tu de quoi il s'agit,
mais, même sans ce codage particulier, les emails sont maintenant propre dans les 3 clients cités,

Code : Tout sélectionner

<META http-equiv=3DContent-Type content=3D"text/html; = charset=3Diso-8859-1"> <META content=3D"MSHTML 6.00.6000.16825" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT face=3DArial size=3D2>aaa<IMG alt=3D"" hspace=3D0=20 src=3D"cid:DF14BA90D7EA4806B3C300CB116F41EF@inspiron86" align=3Dbaseline = border=3D0></FONT></DIV></BODY></HTML>

Euh, le problème c'est que ça n'a aucun rapport. C'est purement un problème HTML. Certains logiciels Microsoft miteux généraient autrefois du code source HTML immonde, à base de <font> et d'attributs propriétaires. On peut supposer que c'est un héritage. Mais je n'ai aucune idée de ce que cela peut vouloir dire (d'autant plus que je suis vraiment mauvais en HTML…)

Salut Sékiltoyai,

un petit mot pour te dire que maintenant les scripts corrigés tournent depuis quelques semaines,

et il semblerait bien que tu ais trouvé mon problème,
plus de retour de la part des utilisateurs,

encore mille merci.
Nils.

De rien, content que ce soit résolu.