Patrick Stadelmann wrote:
> > En tout cas, avec cette option les PJ passe de "inline" (incluse dans le
> > corps) a "attachement" (pièce jointe séparemment) conforme à la norme.
> > <http://www.normes-internet.com/normes.php?rfc=rfc2183&lang=fr>
>
> Ca n'affectera que les clients qui ignorent l'HTML. Pour la plupart des
> clients, le mail étant disponible en text brut et en HTML c'est l'HTML
> qui sera préféré, et comme l'HTML qui contient une balise <IMG> pointant
> sur la pièce jointe, il faut renvoyer la pièce jointe avec la réponse
> pour ne pas avoir une lien cassé dans l'HTML.
Comme dis a coté, Mail.app dans ce cas ne renvoi pas l'image, ni de lien
cassé. Il remplace l'image pas son nom dans le renvoi (répondre).
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
> > En tout cas, avec cette option les PJ passe de "inline" (incluse dans le
> > corps) a "attachement" (pièce jointe séparemment) conforme à la norme.
> > <http://www.normes-internet.com/normes.php?rfc=rfc2183&lang=fr>
>
> Ca n'affectera que les clients qui ignorent l'HTML. Pour la plupart des
> clients, le mail étant disponible en text brut et en HTML c'est l'HTML
> qui sera préféré, et comme l'HTML qui contient une balise <IMG> pointant
> sur la pièce jointe, il faut renvoyer la pièce jointe avec la réponse
> pour ne pas avoir une lien cassé dans l'HTML.
Comme dis a coté, Mail.app dans ce cas ne renvoi pas l'image, ni de lien
cassé. Il remplace l'image pas son nom dans le renvoi (répondre).
Patrick Stadelmann wrote:
> > En tout cas, avec cette option les PJ passe de "inline" (incluse dans le
> > corps) a "attachement" (pièce jointe séparemment) conforme à la norme.
> > <http://www.normes-internet.com/normes.php?rfc=rfc2183&lang=fr>
>
> Ca n'affectera que les clients qui ignorent l'HTML. Pour la plupart des
> clients, le mail étant disponible en text brut et en HTML c'est l'HTML
> qui sera préféré, et comme l'HTML qui contient une balise <IMG> pointant
> sur la pièce jointe, il faut renvoyer la pièce jointe avec la réponse
> pour ne pas avoir une lien cassé dans l'HTML.
Comme dis a coté, Mail.app dans ce cas ne renvoi pas l'image, ni de lien
cassé. Il remplace l'image pas son nom dans le renvoi (répondre).
> Comme dis a coté, Mail.app dans ce cas ne renvoi pas l'image, ni de lien
> cassé. Il remplace l'image pas son nom dans le renvoi (répondre).
Je peux imaginer que Mail reconnaît qu'il s'agit d'un message composé
par Mail et que l'image référencée dans l'HTML est en fait une pièce
jointe. Si je fais "répondre" sur un message HTML composé par un autre
logiciel (une newsletter par exemple), mail conserve bien les images.
> Comme dis a coté, Mail.app dans ce cas ne renvoi pas l'image, ni de lien
> cassé. Il remplace l'image pas son nom dans le renvoi (répondre).
Je peux imaginer que Mail reconnaît qu'il s'agit d'un message composé
par Mail et que l'image référencée dans l'HTML est en fait une pièce
jointe. Si je fais "répondre" sur un message HTML composé par un autre
logiciel (une newsletter par exemple), mail conserve bien les images.
> Comme dis a coté, Mail.app dans ce cas ne renvoi pas l'image, ni de lien
> cassé. Il remplace l'image pas son nom dans le renvoi (répondre).
Je peux imaginer que Mail reconnaît qu'il s'agit d'un message composé
par Mail et que l'image référencée dans l'HTML est en fait une pièce
jointe. Si je fais "répondre" sur un message HTML composé par un autre
logiciel (une newsletter par exemple), mail conserve bien les images.
Le champs "Content-Disposition" n'a d'importance que dans le cas d'une
pièce jointe, c'est à dire qu'elle est indépendante du texte. Cela
indique au logiciel s'il faut l'afficher à la suite du message, ou s'il
faut juste afficher une icône.
Quelque soit le réglage, Mail en 10.6.8 passe automatiquement en HTML
quand on insère une image. L'image n'est plus alors une pièce jointe
indépendante, elle est référencée par le tag <IMG SRC> dans le texte, et
le champs "Content-Disposition" n'a alors plus d'importance.
Le champs "Content-Disposition" n'a d'importance que dans le cas d'une
pièce jointe, c'est à dire qu'elle est indépendante du texte. Cela
indique au logiciel s'il faut l'afficher à la suite du message, ou s'il
faut juste afficher une icône.
Quelque soit le réglage, Mail en 10.6.8 passe automatiquement en HTML
quand on insère une image. L'image n'est plus alors une pièce jointe
indépendante, elle est référencée par le tag <IMG SRC> dans le texte, et
le champs "Content-Disposition" n'a alors plus d'importance.
Le champs "Content-Disposition" n'a d'importance que dans le cas d'une
pièce jointe, c'est à dire qu'elle est indépendante du texte. Cela
indique au logiciel s'il faut l'afficher à la suite du message, ou s'il
faut juste afficher une icône.
Quelque soit le réglage, Mail en 10.6.8 passe automatiquement en HTML
quand on insère une image. L'image n'est plus alors une pièce jointe
indépendante, elle est référencée par le tag <IMG SRC> dans le texte, et
le champs "Content-Disposition" n'a alors plus d'importance.
C'est donc plus probablement que le "inline" n'est pas bien géré par de
nombreux courrieleurs.
C'est donc plus probablement que le "inline" n'est pas bien géré par de
nombreux courrieleurs.
C'est donc plus probablement que le "inline" n'est pas bien géré par de
nombreux courrieleurs.
> Quelque soit le réglage, Mail en 10.6.8 passe automatiquement en HTML
> quand on insère une image. L'image n'est plus alors une pièce jointe
> indépendante, elle est référencée par le tag <IMG SRC> dans le texte, et
> le champs "Content-Disposition" n'a alors plus d'importance.
Ah ?
Mon Mail.app Version 4.6 (1085) sur Mac OS X 10.6.8 ne fait pas du tout
ça. Et cela indépendament de l'option « Format de message » dans
l'onglet « Rédaction » des préférences.
> Quelque soit le réglage, Mail en 10.6.8 passe automatiquement en HTML
> quand on insère une image. L'image n'est plus alors une pièce jointe
> indépendante, elle est référencée par le tag <IMG SRC> dans le texte, et
> le champs "Content-Disposition" n'a alors plus d'importance.
Ah ?
Mon Mail.app Version 4.6 (1085) sur Mac OS X 10.6.8 ne fait pas du tout
ça. Et cela indépendament de l'option « Format de message » dans
l'onglet « Rédaction » des préférences.
> Quelque soit le réglage, Mail en 10.6.8 passe automatiquement en HTML
> quand on insère une image. L'image n'est plus alors une pièce jointe
> indépendante, elle est référencée par le tag <IMG SRC> dans le texte, et
> le champs "Content-Disposition" n'a alors plus d'importance.
Ah ?
Mon Mail.app Version 4.6 (1085) sur Mac OS X 10.6.8 ne fait pas du tout
ça. Et cela indépendament de l'option « Format de message » dans
l'onglet « Rédaction » des préférences.
Patrick Stadelmann wrote:
> > Comme dis a coté, Mail.app dans ce cas ne renvoi pas l'image, ni de lien
> > cassé. Il remplace l'image pas son nom dans le renvoi (répondre).
>
> Je peux imaginer que Mail reconnaît qu'il s'agit d'un message composé
> par Mail et que l'image référencée dans l'HTML est en fait une pièce
> jointe. Si je fais "répondre" sur un message HTML composé par un autre
> logiciel (une newsletter par exemple), mail conserve bien les images.
On doit avoir une config différente.
je prend un courrier reçu d'un client (qui utilise Outlook 14.0) et qui
contient 2 images (dont une dans la signature).
La composition du code est similaire à celle que je décris plus haut, en
plusieurs "Part" : texte brut, puis HTML, puis Images (avec content-type
mais pas de content-disposition)
Hormi que le HTMl est horrible (un mélange de CSS et de balise font et
couleur direc dans le HTML, mais bon) il contient des balises images qui
font liens vers les images plus bas (dans le code). C'est exactement la
même structure.
Et si je fais répondre, mail fait toujours pareil : pas de pièces
jointes (ici pas d'images) dans la réponse (avec HTML modifié).
Pour rappel, dans ma config l'option "Inclure les PJ d'origine dans la
réponse" est désactivé bien sur (comme indiqué plus haut dans
l'enfilade). Si je l'active j'ai le comportement que tu décris.
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
> > Comme dis a coté, Mail.app dans ce cas ne renvoi pas l'image, ni de lien
> > cassé. Il remplace l'image pas son nom dans le renvoi (répondre).
>
> Je peux imaginer que Mail reconnaît qu'il s'agit d'un message composé
> par Mail et que l'image référencée dans l'HTML est en fait une pièce
> jointe. Si je fais "répondre" sur un message HTML composé par un autre
> logiciel (une newsletter par exemple), mail conserve bien les images.
On doit avoir une config différente.
je prend un courrier reçu d'un client (qui utilise Outlook 14.0) et qui
contient 2 images (dont une dans la signature).
La composition du code est similaire à celle que je décris plus haut, en
plusieurs "Part" : texte brut, puis HTML, puis Images (avec content-type
mais pas de content-disposition)
Hormi que le HTMl est horrible (un mélange de CSS et de balise font et
couleur direc dans le HTML, mais bon) il contient des balises images qui
font liens vers les images plus bas (dans le code). C'est exactement la
même structure.
Et si je fais répondre, mail fait toujours pareil : pas de pièces
jointes (ici pas d'images) dans la réponse (avec HTML modifié).
Pour rappel, dans ma config l'option "Inclure les PJ d'origine dans la
réponse" est désactivé bien sur (comme indiqué plus haut dans
l'enfilade). Si je l'active j'ai le comportement que tu décris.
Patrick Stadelmann wrote:
> > Comme dis a coté, Mail.app dans ce cas ne renvoi pas l'image, ni de lien
> > cassé. Il remplace l'image pas son nom dans le renvoi (répondre).
>
> Je peux imaginer que Mail reconnaît qu'il s'agit d'un message composé
> par Mail et que l'image référencée dans l'HTML est en fait une pièce
> jointe. Si je fais "répondre" sur un message HTML composé par un autre
> logiciel (une newsletter par exemple), mail conserve bien les images.
On doit avoir une config différente.
je prend un courrier reçu d'un client (qui utilise Outlook 14.0) et qui
contient 2 images (dont une dans la signature).
La composition du code est similaire à celle que je décris plus haut, en
plusieurs "Part" : texte brut, puis HTML, puis Images (avec content-type
mais pas de content-disposition)
Hormi que le HTMl est horrible (un mélange de CSS et de balise font et
couleur direc dans le HTML, mais bon) il contient des balises images qui
font liens vers les images plus bas (dans le code). C'est exactement la
même structure.
Et si je fais répondre, mail fait toujours pareil : pas de pièces
jointes (ici pas d'images) dans la réponse (avec HTML modifié).
Pour rappel, dans ma config l'option "Inclure les PJ d'origine dans la
réponse" est désactivé bien sur (comme indiqué plus haut dans
l'enfilade). Si je l'active j'ai le comportement que tu décris.
J'ai vérifié, dans mon test ça n'est effectivement pas Mail qui effectue
la conversion en HTML, mais le serveur smtp.icloud.com qu'il utilise.
J'ai vérifié, dans mon test ça n'est effectivement pas Mail qui effectue
la conversion en HTML, mais le serveur smtp.icloud.com qu'il utilise.
J'ai vérifié, dans mon test ça n'est effectivement pas Mail qui effectue
la conversion en HTML, mais le serveur smtp.icloud.com qu'il utilise.
On Lun 24 février 2014 (09:27),
Patrick Stadelmann wrote:
> J'ai vérifié, dans mon test ça n'est effectivement pas Mail qui effectue
> la conversion en HTML, mais le serveur smtp.icloud.com qu'il utilise.
On arrive à un niveau dangereux avec ces clouds, qui se permettent de
manipuler le contenu de correspondances que l'on croit privées.
On Lun 24 février 2014 (09:27),
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
> J'ai vérifié, dans mon test ça n'est effectivement pas Mail qui effectue
> la conversion en HTML, mais le serveur smtp.icloud.com qu'il utilise.
On arrive à un niveau dangereux avec ces clouds, qui se permettent de
manipuler le contenu de correspondances que l'on croit privées.
On Lun 24 février 2014 (09:27),
Patrick Stadelmann wrote:
> J'ai vérifié, dans mon test ça n'est effectivement pas Mail qui effectue
> la conversion en HTML, mais le serveur smtp.icloud.com qu'il utilise.
On arrive à un niveau dangereux avec ces clouds, qui se permettent de
manipuler le contenu de correspondances que l'on croit privées.
Que le serveur SMTP soit dans un cloud ou pas change quelque chose ?
Que le serveur SMTP soit dans un cloud ou pas change quelque chose ?
Que le serveur SMTP soit dans un cloud ou pas change quelque chose ?
On Lun 24 février 2014 (12:50),
J.P wrote:
> Que le serveur SMTP soit dans un cloud ou pas change quelque chose ?
Etant donné que lors d'une transmission par SMTP, au moins deux MTA sont
impliqués, tout est possible, cloud ou pas.
Ton email s'il n'est pas signé, peut être modifié par le MTA de ton
destinataire, malgré que tu ais le contrôle de ton MSA.
La dangerosité provient des serveurs gratuits qui lors de l'acceptation
des conditions générales d'utilisation du service par l'utilisateur,
donne tout pouvoir sur le traitement de la correspondance. Ce que tu
penses avoir envoyé n'est plus; comme dans le cas de Patrick.
C'est comme si La Poste ouvrait tes correspondances pour y
ajouter/modifier du contenu. Tout le monde s'accorde à dire que c'est
inacceptable. Pourquoi donc ce serait différent pour le courrier
électronique ? Mystère. Seuls ceux qui pensent que c'est acceptable
peuvent y répondre.
On Lun 24 février 2014 (12:50),
J.P <jpp@gmail.com> wrote:
> Que le serveur SMTP soit dans un cloud ou pas change quelque chose ?
Etant donné que lors d'une transmission par SMTP, au moins deux MTA sont
impliqués, tout est possible, cloud ou pas.
Ton email s'il n'est pas signé, peut être modifié par le MTA de ton
destinataire, malgré que tu ais le contrôle de ton MSA.
La dangerosité provient des serveurs gratuits qui lors de l'acceptation
des conditions générales d'utilisation du service par l'utilisateur,
donne tout pouvoir sur le traitement de la correspondance. Ce que tu
penses avoir envoyé n'est plus; comme dans le cas de Patrick.
C'est comme si La Poste ouvrait tes correspondances pour y
ajouter/modifier du contenu. Tout le monde s'accorde à dire que c'est
inacceptable. Pourquoi donc ce serait différent pour le courrier
électronique ? Mystère. Seuls ceux qui pensent que c'est acceptable
peuvent y répondre.
On Lun 24 février 2014 (12:50),
J.P wrote:
> Que le serveur SMTP soit dans un cloud ou pas change quelque chose ?
Etant donné que lors d'une transmission par SMTP, au moins deux MTA sont
impliqués, tout est possible, cloud ou pas.
Ton email s'il n'est pas signé, peut être modifié par le MTA de ton
destinataire, malgré que tu ais le contrôle de ton MSA.
La dangerosité provient des serveurs gratuits qui lors de l'acceptation
des conditions générales d'utilisation du service par l'utilisateur,
donne tout pouvoir sur le traitement de la correspondance. Ce que tu
penses avoir envoyé n'est plus; comme dans le cas de Patrick.
C'est comme si La Poste ouvrait tes correspondances pour y
ajouter/modifier du contenu. Tout le monde s'accorde à dire que c'est
inacceptable. Pourquoi donc ce serait différent pour le courrier
électronique ? Mystère. Seuls ceux qui pensent que c'est acceptable
peuvent y répondre.