Accéder au contenu.
Menu Sympa

fr - Re: [sympa-fr] messages html provenant d'Outlook

Objet : Pour les administrateurs de serveurs de listes utilisant le logiciel Sympa

Archives de la liste

Chronologique Discussions  
  • From: Jacques Deguest <adresse@cachée>
  • To: adresse@cachée
  • Subject: Re: [sympa-fr] messages html provenant d'Outlook
  • Date: Wed, 03 Jun 2015 23:21:34 +0900

Vu,

Commentant un peu plus sur le sujet après avoir vu le moduler perl Message.pm qui semble être responsable de l'analyse de message, on peut y lire :
"While processing a message in Sympa, we need to link informations to rhe message, mdify headers and such. This was quite a problem when a message was signed, as modifying anything in the message body would alter its MD5 footprint. And probably make the message to be rejected by clients verifying its identity (which is somehow a good thing as it is the reason why people use MD5 after all). With such messages, the process was complex. We then decided to embed any message treated in a "Message" object, thus making the process easier."

Il semble donc que Sympa fait attention de ne pas altérer le body du message.
Message.pm s'appuie lui-même sur MIME-tools et notamment MIME::Entity, une suite de module perl très fiables pour le parsing des entités MIME.

Je pense qu'il faut chercher le problème ailleurs, mais en faisant le test que j'évoquais précédemment, vous serez fixé.

Jacques

On 03/06/2015 23:07, Jacques Deguest (via sympa-fr Mailing List) wrote:
adresse@cachée"> Vu, le problème fondamental avec ces 2 messages est leur structure. La structure du premier message est :

Content-Type: multipart/related;
    boundary="----=_NextPart_000_0A7B_01D09D67.A40D9410"

------=_NextPart_000_0A7B_01D09D67.A40D9410
Content-Type: multipart/alternative;
    boundary="----=_NextPart_001_0A7C_01D09D67.A40D9410"

------=_NextPart_001_0A7C_01D09D67.A40D9410
Content-Type: text/plain;
    charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

------=_NextPart_001_0A7C_01D09D67.A40D9410
Content-Type: text/html;
    charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

------=_NextPart_001_0A7C_01D09D67.A40D9410--

------=_NextPart_000_0A7B_01D09D67.A40D9410
Content-Type: image/png;
    name="image001.png"
Content-Transfer-Encoding: base64
Content-ID: <adresse@cachée>

------=_NextPart_000_0A7B_01D09D67.A40D9410--


Le deuxième (mauvais) message a la structure suivante :

Content-Type: multipart/related;
    boundary="----=_NextPart_000_0A7B_01D09D67.A40D9410"

------=_NextPart_000_0A7B_01D09D67.A40D9410
Content-Type: multipart/alternative;
    boundary="----=_NextPart_001_0A7C_01D09D67.A40D9410"


------=_NextPart_001_0A7C_01D09D67.A40D9410
Content-Type: text/plain;
    charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

------=_NextPart_001_0A7C_01D09D67.A40D9410
Content-Type: text/html;
    charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

------=_NextPart_001_0A7C_01D09D67.A40D9410--

------=_NextPart_000_0A7B_01D09D67.A40D9410
Content-Type: image/png;
    name="image001.png"
Content-Transfer-Encoding: base64
Content-ID: <adresse@cachée>

------=_NextPart_001_0A7C_01D09D67.A40D9410--

------=_NextPart_000_0A7B_01D09D67.A40D9410
Content-Type: image/png;
    name="image001.png"
Content-Transfer-Encoding: base64
Content-ID: <adresse@cachée>

------=_NextPart_000_0A7B_01D09D67.A40D9410--


La première partie est un multipart/related définissant une relation entre les parties MIME (ici une image inline adresse@cachée).
J'ai mis en orange la 2eme partie MIME qui est multipart/alternative définissant une vue alternative entre texte simple et texte html.

Le problème du 2eme mauvais message vient du fait que l'image vient s'enchevêtrer dans la 2eme partie. On le voit tres clairement avec les boundaries.

Maintenant, il peut y avoir plusieurs intervenant entre le MUA sortant et le MUA recevant. Il peut y avoir des filtres sur les MTA qui altèrent les messages, tel que pour y ajouter des signature dkim, filter les virus ou spam, etc.
Chacun a une opportunité d'avoir endommagé le message.
Mais enchevêtrement de 2 parties MIME est tout de même grave, et je doute que Sympa en soit responsable.

D'où ma demande préalable d'envoyer l'exacte même message 2 fois 1) au destinataire finale sans passer par Sympa et 2) en passant par Sympa. Utiliser sendmail en ligne de commande permet de garantir qu'aucun MDA n'aura altéré le message entre les 2.

Cordialement,
Jacques Deguest

On 03/06/2015 23:02, Vu Ngoc VU wrote:
Je comprends votre raisonnement.
Mais dans notre cas, j'ai vérifié dans les logs, il n'y a pas eu deux messages envoyés par Outlook.
Les journaux confirment les dates des entêtes "Received: " des 2 dumps.

C'est le même message avec des destinataires directs et la liste en copie.

Date: Wed, 3 Jun 2015 15:38:17
From: Jacques Deguest <adresse@cachée>
To: adresse@cachée
Subject: Re: [sympa-fr] messages html provenant d'Outlook

Vu,

Un MUA est censé des Message-ID distinct, mais là n'est pas le problème.
Le problème se situe plutôt sur les parties MIME et leur possible altération par Sympa.
Il faut pouvoir comparer des mail dont le contenu initialement est exactement identique. Un MUA quel qu'il soit ne produira pas nécessairement le même contenu 2 fois de suite, et alors comment faire la part du changement entre celui causé par Sympa et celui causé par le MUA ?
Enregistrer un courriel dans un fichier et envoyer 2 fois ce courriel via sendmail permettra pour sûr de comparer apple-to-apple comme on dit.

Jacques

On 03/06/2015 22:26, Vu Ngoc VU wrote:
Mais le MUA qui envoie 2 message n'est-il pas censé utiliser 2 Message-ID distincts ?
Je crois savoir qu'Outlook est "réputé" pour ne pas respecter cette règle.

Je vais jeter un oeil à notre maillog pour voir s'il y a eu 2 soumissions ou un seul.


Date: Wed, 3 Jun 2015 15:09:00
From: Jacques Deguest <adresse@cachée>
To: adresse@cachée
Subject: Re: [sympa-fr] messages html provenant d'Outlook

Bonjour Vu,

Les 2 messages ont été envoyés avec Outlook disiez-vous. Probablement il s'agit de 2 messages avec le même contenu envoyé 2 fois par Outlook. Ce qui serait bien, c'est d'enregistrer un draft quelque part au format texte puis de faire un sendmail -oi -f adresse@cachée adresse@cachée < fichier-mail.txt d'une part et de refaire la commande, en l'envoyant ce coup-ci sur la liste, puis d'envoyer ici les 2 résultat en pièce jointe.
En effet, le formatage des css Windows n'est pas le meme dans chacun des messages. Pour éradiquer toute possibilité de cause provenant d'Outlook, et pour comparer des messages strictement identique, la procédure ci-dessus est très utile.

Cordialement,
Jacques Deguest

On 03/06/2015 21:42, Vu Ngoc VU wrote:
Voilà en pièce jointe les 2 messages (avec quelques remplacements sans conséquence).
Il s'agit de "dump" directement effectué sur le MDA (avec doveadm fetch).

Des recherches sur des chaînes comme "Calibri" ne trouvent du tout des occurences aux mêmes endroits dans le fichier.

Vu~ - sysadm

Date: Wed, 3 Jun 2015 14:31:36
From: Vu Ngoc VU <adresse@cachée>
Reply-To: adresse@cachée
To: Jacques Deguest <adresse@cachée>
Subject: Re: [sympa-fr] messages html provenant d'Outlook

bonjour et merci d'avoir répondu.

Effectivement il manque un tiret suite à mon copier/coller.

Mais ce n'est pas les "boundaries" qui posent problème selon moi.
C'est leur contenu.
Pourquoi n'y a t-il pas toute la partie /* Font Definitions */ quand le message passe par SYMPA ?

OK, je vais envoyer les sources des messages, je ne souhaitais pas le faire pour des raisons de confidentialité.
Tout de même, je remplacerai nos domaines par des example.*

Date: Wed, 3 Jun 2015 14:18:15
From: Jacques Deguest <adresse@cachée>
To: adresse@cachée
Subject: Re: [sympa-fr] messages html provenant d'Outlook

Bonjour,

Pour moi, ce sont les meme en-tete, mise a part que le separateur contient 6 "-" dans le premier et 5 dans le second.
Ce qu'il faudrait pour analyser correctement serait de nous envoyer ces 2 messages en pieces jointes pour preserver leur format.

Cordialement,
Jacques Deguest

On 03/06/2015 18:30, Vu Ngoc VU wrote:
bonjour à tous,

nous rencontrons un problème avec des messages HTML rédigés par Outlook 2010 (moteur html Word, mais je pense que ça n'influt pas) qui ne s'affichent pas correctement ni dans Outlook, ni dans un webmail comme Roundcube.

Pour exemple, un même message a été envoyé à une adresse e-mail individuelle ainsi qu'à une liste gérée par SYMPA.

J'ai comparé les entêtes Message-ID, Thread-Index, etc. qui sont identiques dans les 2 messages reçus.

Pourtant, celui qui a été délivré via SYMPA ne présente pas les mêmes parties MIME.

Voici un extrait du mail reçu directement (sans SYMPA au milieu) :
------=_NextPart_001_0A7C_01D09D67.A40D9410
Content-Type: text/html;
    charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta name=3DGenerator =
content=3D"Microsoft Word 14 (filtered medium)"><!--[if =
!mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
    {font-family:Calibri;
    panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
    {font-family:Tahoma;
    panose-1:2 11 6 4 3 5 4 4 2 4;}
...

Et un extrait du message message reçu mais via SYMPA :
-----=_NextPart_001_0A7C_01D09D67.A40D9410
Content-Type: text/html;
    charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta name=3DGenerator =
content=3D"Microsoft Word 14 (filtered medium)"><!--[if =
!mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
 3.5pt;height:38.9pt'><p =
class=3DMsoNormal align=3Dright style=3D'text-align:right'><b><span =
style=3D'color:black;mso-fareast-language:FR'>95,25%<o:p></o:p></span></b=
</p></td><td width=3D127 nowrap valign=3Dbottom =
style=3D'width:94.9pt;border:none;border-top:solid #DA9694 =
1.0pt;background:#F2DCDB;padding:0cm 3.5pt 0cm 3.5pt;height:38.9pt'><p =
class=3DMsoNormal align=3Dright style=3D'text-align:right'><b><span =
style=3D'color:black;mso-fareast-language:FR'>85,20%<o:p></o:p></span></b=
</p></td><td width=3D73 nowrap valign=3Dbottom =
style=3D'width:54.4pt;border:none;border-top:solid #DA9694 =
1.0pt;background:#F2DCDB;padding:0cm 3.5pt 0cm 3.5pt;height:38.9pt'><p =
class=3DMsoNormal><b><span =
style=3D'color:black;mso-fareast-language:FR'>&nbsp;<o:p></o:p></span></b=
</p></td></tr></table><p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p><p =
class=3DMsoNormal><span =

Pouvez-vous m'expliquer comment SYMPA altère ce message ?
J'imagine que ce sont des librairies Perl.
Y a t-il une option à désactiver pour éviter cela ou est-ce que ça a été "corrigé" dans des versions plus récente que la mienne (6.1.16) ?

D'avance, merci et bonne journée.


Vu~ - sysadm











Archives gérées par MHonArc 2.6.19+.

Haut de le page