Corps des emails systèmatiquement en attachement

[Romain]

Bonjour,

Chez certains fournisseurs de mail tel que Google par exemple il se peux que le corps des emails reçu d'ABM apparaissent en pièce jointe.
Le problème ne viens pas du serveur d'envoi (SMTP) mais du serveur de réception (POP).

Donc il n'y a pas réellement de solutions puisque tout dépend de la plateforme utilisée, certaines gèrent bien ce problème et d'autres moins.

Pour être plus technique, le Webmail que vous utilisez doit géré correctement le format MIME (Multipurpose Internet Mail Extensions). Si tel n'est pas le cas, le problème du corps de message en attachement sera présent.
Sur certains Webmail il est possible d'activer ou pas la gestion du format MIME. Vérifier donc qu'elle est bien activer.

Si rien y fait, 2 solutions: Changer de fournisseur, ou utiliser un autre Webmail/Logiciel.

Plus d'infos sur le format MIME: http://fr.wikipedia.org/wiki/Multipurpo ... Extensions


Plateforme/Fournisseur où le problème à été rencontré (liste non exhaustive):

Fournisseur | Outils
Google - GMail (Webmail)
xxx - Horde
xxx - Microsoft Outlook Web Access

Plateforme/Fournisseur ne posant pas de problème (liste non exhaustive):

Fournisseur | Outils
Free - Zimbra (Webmail)
xxx - Atmail
xxx - RoundCube
xxx - SquirrelMail
xxx - IlohaMail
xxx - Open XChange
GMX/Caramail - Webmail
xxx - Microsoft Outlook 2003
Hotmail - Webmail

[Romain]

Le problème ne viens pas du serveur d'envoi (SMTP) mais du serveur de réception (POP).

J'avoue que cette phrase ne veux pas dire grand chose.

j'apporte des éléments qui pourrons nous en dire d'avantages.

Après quelques tests, je dirais que le souci viens de la manière d'interpréter le message. C'est donc le Webmail (ou logiciel) qui est amener a mal interpréter le message et a le mettre en pièce jointe.
Après test avec un serveur Exchange 2007 qui est mal configuré, les emails sont systématiquement envoyés en pièce jointe. Cependant en essayant de lire les mails via plusieurs webmail, j'ai réussi a lire le message sans pièce jointe.
Les webmail que j'ai tester sont roundcube et Ilohamail. Ces deux webmail on bien interpréter le message.

Cependant je n'ai pas d'éléments de réponse sur le pourquoi les emails restent en pièce jointe avec d'autres webmail (y compris Outlook).

Vos tests et vos hypothèses sont les bienvenue.

[Romain]

j'ai quelques éléments.

Content-Transfert-Encoding

La spécification du MIME (RFC 2045) définit un ensemble de méthodes pour représenter des données binaires sous forme de texte ASCII. L'en-tête MIME Content-Transfert-Encoding indique la méthode utilisée. La RFC la liste de l'IANA définissent les valeurs non sensibles à la casse (typographie) :

* Appropriées pour l'usage avec le SMTP :
o 7bit - jusqu'à 998 octets par ligne dans la gamme 1...127 avec CR et LF (retour chariot et défilement de ligne - codes 13 et 10 respectivement) autorisés uniquement pour une fin de ligne CRLF. C'est la valeur par défaut.
o Quoted-Printable - utilisé pour encoder des séquences d'octets dans un format qui satisfait les règles de l'encodage 7bit. Étudié pour être efficace et lisible par un humain quand il est utilisé pour encoder des données comportant majoritairement du texte avec des caractères ASCII avec quelques caractères non ASCII.
o Base64 - utilisé pour encoder des données arbitraires dans une forme satisfaisant les règles de l'encodage 7bit. Sa taille est fixe par rapport à la taille des données initiales. Il est utilisé pour les données non textuelles ou des textes à base non ASCII.
* Appropriées pour les serveurs SMTP qui supportent le transport 8BITMIME comme extension SMTP :
o 8bit - jusqu'à 998 octets par ligne avec CR et LF (retour chariot et défilement de ligne - codes 13 et 10 respectivement) autorisés uniquement pour une fin de ligne CRLF.
* Non approprié avec SMTP :
o binary - séquence quelconque d'octets. Non utilisable avec les courriels SMTP.

Aucun encodage n'est spécialement spécifié pour l'envoi de données binaires arbitraires par les transports SMTP avec l'extension 8BITMIME. base64 ou quoted-printable (avec leurs inefficacités respectives) doivent être utilisées. Ces restrictions ne s'appliquent pas aux autres utilisations de MIME comme les services web avec attachement MIME ou MTOM.

Sur le message que j'ai en test dans le source j'ai

Return-Path: <agaphone@agaphone.com>
Delivered-To: toni@extenza.fr
Received: from b0.ovh.net (HELO queue) (213.186.33.50)
by b0.ovh.net with SMTP; 15 Jul 2009 12:17:52 -0000
Received: from srvmail.agaphone.com (81.80.75.118)
by mx3.ovh.net with SMTP; 15 Jul 2009 12:17:51 -0000
Received: from Agaphone (172.18.200.210) by SRVMAIL2.agaphone.local
(172.18.200.201) with Microsoft SMTP Server id 8.1.375.2; Wed, 15 Jul 2009
14:17:15 +0200
Reply-To: Agaphone <agaphone@agaphone.com>
Sender: Agaphone
X-Mailer: ICS SMTP Component V2.50
From: Agaphone <agaphone@agaphone.com>
To: toni@extenza.fr
Subject: test 2
Date: Wed, 15 Jul 2009 14:17:09 +0200
Message-ID: <614143093toni@extenza.fr>
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="StMime-00009C49-00001740-249B1475-7608"
Return-Path: agaphone@agaphone.com
X-Ovh-Tracer-Id: 14478791327368672256
X-Ovh-Remote: 81.80.75.118 (srvmail.agaphone.com)
X-Ovh-Local: 213.186.33.73 (mx3.ovh.net)
X-Spam-Check: DONE|U 0.5/N

--StMime-00009C49-00001740-249B1475-7608
Content-Type: text/plain
Content-Transfer-Encoding: 8bit
Content-Description:
Content-Disposition: attachment

test 2
test 2

Appel pour AGAPHONE

--StMime-00009C49-00001740-249B1475-7608--

On peut aisément lire Content-Transfer-Encoding: 8bit

Cependant le serveur doit supporté le transfert 8BITMIME.

La question est de savoir est ce que Exchange 2007 supporte donc ce type de transport ?????

[Romain]

A priori 8BITMIME est supporté par exchange. (en tout cas par défaut, sauf si désactiver).