Je reposte mon message, je ne sais pas ce qui est arrivé à celui que
j'ai posté hier soir ???
**********
Bonjour à tous,
petit problème irritant dont j'aimerais trouver la solution :
un collègue m'envoie régulièrement des messages avec pièces jointes
(généralement des .doc ou .rtf). Pour environ un message sur cinq, pas
de problème, je vois le message, je peux lire la pièce jointe,
l'enregistrer etc.
Par contre, 4 fois sur 5, le message m'apparaît comme complètement vide
(rien dans le corps du message, je ne peux lire le corps du message
qu'en passant par la source) et la pièce jointe s'affiche simplement
comme "attachment", sans extension. Elle existe, la taille du message le
confirme, je peux l'enregistrer, je peux l'ouvrir dans un éditeur de
texte (mais ça me donne en général quelques mots lisibles au milieu d'un
fouillis inommable), mais impossible de l'ouvrir ni sous word ni sous
openoffice même en la renommant par exemple en .doc ou .rtf.
J'ai comparé la source de deux de ces messages, l'un qui passait bien,
l'autre pas, et la *seule* différence que j'ai trouvée est celle-ci :
Donc dans un cas le "Content-Transfer-Encoding" est "base64", dans
l'autre "quoted-printable".
Cette différence peut-elle expliquer l'illisibilité du deuxième message
? Peut-elle venir d'une manipulation différente de mon correspondant
dans les deux cas (celui-ci n'a pas réussi à m'expliquer comment il
avait procédé) ? Que puis-je (ou plutôt l'expéditeur des messages plus
probablement) faire pour remédier au problème ?
Je précise pour finir que j'utilise Mozilla 1.4, et que mon collègue
utilise, d'après ses en-têtes, OE 6.00.2600.0000.
Merci d'avance pour votre aide, et désolée pour la longueur de ce
message, j'ai essayé d'être aussi claire que possible !
certes mais ce que je voulais dire, c'est, si tu attaches un fichier texte, est-ce que tu vas t'amuser à changer le format d'un réseau à l'autre ?
Ben non, puisqu'il y a un seul réseau. Le format d'échange des mails par SMTP, c'est ASCII avec CR+LF, point.
Un logiciel de courrier sur Unix doit savoir faire la correspondance entre son format interne (ASCII et LF seul) et le réseau (ASCII et CR+LF) sans se soucier des autres formats.
Un logiciel de courrier sur Mac doit savoir faire la correspondance entre son format interne (ASCII et CR seul) et le réseau (ASCII et CR+LF) sans se soucier des autres formats.
Un logiciel de courrier sur machine propriétaire IBM doit savoir faire la correspondance entre son format interne (EBCDIC) et le réseau (ASCII et CR+LF) sans se soucier des autres formats.
etc.
certes mais ce que je voulais dire, c'est, si tu attaches un fichier
texte, est-ce que tu vas t'amuser à changer le format d'un réseau à
l'autre ?
Ben non, puisqu'il y a un seul réseau. Le format d'échange des mails par
SMTP, c'est ASCII avec CR+LF, point.
Un logiciel de courrier sur Unix doit savoir faire la correspondance
entre son format interne (ASCII et LF seul) et le réseau (ASCII et
CR+LF) sans se soucier des autres formats.
Un logiciel de courrier sur Mac doit savoir faire la correspondance
entre son format interne (ASCII et CR seul) et le réseau (ASCII et
CR+LF) sans se soucier des autres formats.
Un logiciel de courrier sur machine propriétaire IBM doit savoir faire
la correspondance entre son format interne (EBCDIC) et le réseau (ASCII
et CR+LF) sans se soucier des autres formats.
certes mais ce que je voulais dire, c'est, si tu attaches un fichier texte, est-ce que tu vas t'amuser à changer le format d'un réseau à l'autre ?
Ben non, puisqu'il y a un seul réseau. Le format d'échange des mails par SMTP, c'est ASCII avec CR+LF, point.
Un logiciel de courrier sur Unix doit savoir faire la correspondance entre son format interne (ASCII et LF seul) et le réseau (ASCII et CR+LF) sans se soucier des autres formats.
Un logiciel de courrier sur Mac doit savoir faire la correspondance entre son format interne (ASCII et CR seul) et le réseau (ASCII et CR+LF) sans se soucier des autres formats.
Un logiciel de courrier sur machine propriétaire IBM doit savoir faire la correspondance entre son format interne (EBCDIC) et le réseau (ASCII et CR+LF) sans se soucier des autres formats.
etc.
DINH Viêt Hoà
certes mais ce que je voulais dire, c'est, si tu attaches un fichier texte, est-ce que tu vas t'amuser à changer le format d'un réseau à l'autre ?
Ben non, puisqu'il y a un seul réseau. Le format d'échange des mails par SMTP, c'est ASCII avec CR+LF, point.
Ce que je veux dire, c'est : tu emets un fichier texte d'un point du réseau d'un Mac, sur l'IBM, veux-tu l'altérer ou non ?
Je veux dire si tu fais un checksum (ou équivalent) du fichier d'un côté et de l'autre, sera-t-il le même ?
-- DINH V. Hoa,
"Vu que t'es physiquement intelligente, tu viens avec moi ?" - Brice
certes mais ce que je voulais dire, c'est, si tu attaches un fichier
texte, est-ce que tu vas t'amuser à changer le format d'un réseau à
l'autre ?
Ben non, puisqu'il y a un seul réseau. Le format d'échange des mails par
SMTP, c'est ASCII avec CR+LF, point.
Ce que je veux dire, c'est : tu emets un fichier texte d'un point du
réseau d'un Mac, sur l'IBM, veux-tu l'altérer ou non ?
Je veux dire si tu fais un checksum (ou équivalent) du fichier d'un côté
et de l'autre, sera-t-il le même ?
--
DINH V. Hoa,
"Vu que t'es physiquement intelligente, tu viens avec moi ?" - Brice
Je veux dire si tu fais un checksum (ou équivalent) du fichier d'un côté et de l'autre, sera-t-il le même ?
Ah oui, tiens ! Je serais curieux de savoir comment ça se passe. On ne tient pas compte des <fins de lignes> peut-être...
-- Olivier Zolli http://www.hamster-fr.org/
DINH Viêt Hoà
Le 14/11/2003 à 15:46 DINH Viêt Hoà écrivait :
Je veux dire si tu fais un checksum (ou équivalent) du fichier d'un côté et de l'autre, sera-t-il le même ?
Ah oui, tiens ! Je serais curieux de savoir comment ça se passe. On ne tient pas compte des <fins de lignes> peut-être...
le checksum prend le fichier comme étant un binaire. Donc si on altère les fins de lignes, le checksum est altéré. Quand aux formats semi-textes comme le RTF, même chose.
-- DINH V. Hoa,
"Vu que t'es physiquement intelligente, tu viens avec moi ?" - Brice
Le 14/11/2003 à 15:46 DINH Viêt Hoà écrivait :
Je veux dire si tu fais un checksum (ou équivalent) du fichier d'un côté
et de l'autre, sera-t-il le même ?
Ah oui, tiens ! Je serais curieux de savoir comment ça se passe. On ne
tient pas compte des <fins de lignes> peut-être...
le checksum prend le fichier comme étant un binaire. Donc si on altère les
fins de lignes, le checksum est altéré. Quand aux formats semi-textes
comme le RTF, même chose.
--
DINH V. Hoa,
"Vu que t'es physiquement intelligente, tu viens avec moi ?" - Brice
Je veux dire si tu fais un checksum (ou équivalent) du fichier d'un côté et de l'autre, sera-t-il le même ?
Ah oui, tiens ! Je serais curieux de savoir comment ça se passe. On ne tient pas compte des <fins de lignes> peut-être...
le checksum prend le fichier comme étant un binaire. Donc si on altère les fins de lignes, le checksum est altéré. Quand aux formats semi-textes comme le RTF, même chose.
-- DINH V. Hoa,
"Vu que t'es physiquement intelligente, tu viens avec moi ?" - Brice
Olivier Miakinen
Ce que je veux dire, c'est : tu emets un fichier texte d'un point du réseau d'un Mac, sur l'IBM, veux-tu l'altérer ou non ?
Lorsque tu émets un fichier texte par SMTP à partir d'un Mac, tous les CR sont remplacés par CR+LF. Si tu as envoyé le même message à quatre destinataires, un sur Mac, un sur Unix, un sur Windows et un sur IBM, ce fichier sera transformé de quatre manières différentes à la réception.
- pour Mac : remplacement de CR+LF par CR seul - pour Unix : remplacement de CR+LF par LF seul - pour Windows : aucun changement - pour IBM : remplacement des codes de quasi tous les caractères. Curieusement, le CR a le même code en ASCII et EBCDIC (0d) mais pas le LF (0a pour ASCII, 25 pour EBCDIC).
Noter qu'à l'affichage l'utilisateur ne verra aucune différence entre les quatre textes. Seul le format interne est concerné.
Je veux dire si tu fais un checksum (ou équivalent) du fichier d'un côté et de l'autre, sera-t-il le même ?
Non, aucune chance. Pour un fichier texte, ce qui doit être préservé, ce sont les caractères (un A doit rester un A) et pas leurs codes numériques (41 pour ASCII, c1 pour EBCDIC).
Note que j'ai commencé par défendre le format MIME quoted-printable, mais tout ce que j'ai écrit s'applique aussi bien à un message en text/plain 7bit.
Ce que je veux dire, c'est : tu emets un fichier texte d'un point du
réseau d'un Mac, sur l'IBM, veux-tu l'altérer ou non ?
Lorsque tu émets un fichier texte par SMTP à partir d'un Mac, tous les
CR sont remplacés par CR+LF. Si tu as envoyé le même message à quatre
destinataires, un sur Mac, un sur Unix, un sur Windows et un sur IBM, ce
fichier sera transformé de quatre manières différentes à la réception.
- pour Mac : remplacement de CR+LF par CR seul
- pour Unix : remplacement de CR+LF par LF seul
- pour Windows : aucun changement
- pour IBM : remplacement des codes de quasi tous les caractères.
Curieusement, le CR a le même code en ASCII et EBCDIC (0d) mais pas le
LF (0a pour ASCII, 25 pour EBCDIC).
Noter qu'à l'affichage l'utilisateur ne verra aucune différence entre
les quatre textes. Seul le format interne est concerné.
Je veux dire si tu fais un checksum (ou équivalent) du fichier d'un côté
et de l'autre, sera-t-il le même ?
Non, aucune chance. Pour un fichier texte, ce qui doit être préservé,
ce sont les caractères (un A doit rester un A) et pas leurs codes
numériques (41 pour ASCII, c1 pour EBCDIC).
Note que j'ai commencé par défendre le format MIME quoted-printable,
mais tout ce que j'ai écrit s'applique aussi bien à un message en
text/plain 7bit.
Ce que je veux dire, c'est : tu emets un fichier texte d'un point du réseau d'un Mac, sur l'IBM, veux-tu l'altérer ou non ?
Lorsque tu émets un fichier texte par SMTP à partir d'un Mac, tous les CR sont remplacés par CR+LF. Si tu as envoyé le même message à quatre destinataires, un sur Mac, un sur Unix, un sur Windows et un sur IBM, ce fichier sera transformé de quatre manières différentes à la réception.
- pour Mac : remplacement de CR+LF par CR seul - pour Unix : remplacement de CR+LF par LF seul - pour Windows : aucun changement - pour IBM : remplacement des codes de quasi tous les caractères. Curieusement, le CR a le même code en ASCII et EBCDIC (0d) mais pas le LF (0a pour ASCII, 25 pour EBCDIC).
Noter qu'à l'affichage l'utilisateur ne verra aucune différence entre les quatre textes. Seul le format interne est concerné.
Je veux dire si tu fais un checksum (ou équivalent) du fichier d'un côté et de l'autre, sera-t-il le même ?
Non, aucune chance. Pour un fichier texte, ce qui doit être préservé, ce sont les caractères (un A doit rester un A) et pas leurs codes numériques (41 pour ASCII, c1 pour EBCDIC).
Note que j'ai commencé par défendre le format MIME quoted-printable, mais tout ce que j'ai écrit s'applique aussi bien à un message en text/plain 7bit.
DINH Viêt Hoà
Je veux dire si tu fais un checksum (ou équivalent) du fichier d'un côté et de l'autre, sera-t-il le même ?
Ah oui, tiens ! Je serais curieux de savoir comment ça se passe. On ne tient pas compte des <fins de lignes> peut-être...
Ni des lettres majuscules ou minuscules, des signes de ponctuation, etc. ? Si on veut faire un checksum, alors il faut le faire sur un format commun, le plus logique me semblant être celui de SMTP (ASCII avec CR+LF).
je serai assez ennuyé qu'un logiciel se permette faire ce genre de transformations. De même si, à partir d'un unix, je veux envoyer un fichier avec les retours à la ligne en CR LF, j'aurai aimé qu'il conserve la même présentation finale.
Si les transformations CR LF se faisait, tout ce qui est signature électronique de documents textes attachés serait invalide. (à noter aussi que les signatures électroniques ne tiennent pas compte du fait que le document est texte ou binaire).
A noter qu'un checksum d'un fichier se fait quelque soit le type de fichier, on ne tient pas compte de paramètre du type "le fichier est un texte" ou "il est compressé avec telle méthode".
-- DINH V. Hoa,
"Vu que t'es physiquement intelligente, tu viens avec moi ?" - Brice
Je veux dire si tu fais un checksum (ou équivalent) du fichier d'un côté
et de l'autre, sera-t-il le même ?
Ah oui, tiens ! Je serais curieux de savoir comment ça se passe. On ne
tient pas compte des <fins de lignes> peut-être...
Ni des lettres majuscules ou minuscules, des signes de ponctuation,
etc. ? Si on veut faire un checksum, alors il faut le faire sur un
format commun, le plus logique me semblant être celui de SMTP (ASCII
avec CR+LF).
je serai assez ennuyé qu'un logiciel se permette faire ce genre de
transformations. De même si, à partir d'un unix, je veux envoyer un
fichier avec les retours à la ligne en CR LF, j'aurai aimé qu'il conserve
la même présentation finale.
Si les transformations CR LF se faisait, tout ce qui est signature
électronique de documents textes attachés serait invalide. (à noter aussi
que les signatures électroniques ne tiennent pas compte du fait que le
document est texte ou binaire).
A noter qu'un checksum d'un fichier se fait quelque soit le type de
fichier, on ne tient pas compte de paramètre du type "le fichier est un
texte" ou "il est compressé avec telle méthode".
--
DINH V. Hoa,
"Vu que t'es physiquement intelligente, tu viens avec moi ?" - Brice
Je veux dire si tu fais un checksum (ou équivalent) du fichier d'un côté et de l'autre, sera-t-il le même ?
Ah oui, tiens ! Je serais curieux de savoir comment ça se passe. On ne tient pas compte des <fins de lignes> peut-être...
Ni des lettres majuscules ou minuscules, des signes de ponctuation, etc. ? Si on veut faire un checksum, alors il faut le faire sur un format commun, le plus logique me semblant être celui de SMTP (ASCII avec CR+LF).
je serai assez ennuyé qu'un logiciel se permette faire ce genre de transformations. De même si, à partir d'un unix, je veux envoyer un fichier avec les retours à la ligne en CR LF, j'aurai aimé qu'il conserve la même présentation finale.
Si les transformations CR LF se faisait, tout ce qui est signature électronique de documents textes attachés serait invalide. (à noter aussi que les signatures électroniques ne tiennent pas compte du fait que le document est texte ou binaire).
A noter qu'un checksum d'un fichier se fait quelque soit le type de fichier, on ne tient pas compte de paramètre du type "le fichier est un texte" ou "il est compressé avec telle méthode".
-- DINH V. Hoa,
"Vu que t'es physiquement intelligente, tu viens avec moi ?" - Brice
Olivier Miakinen
Je veux dire si tu fais un checksum (ou équivalent) du fichier d'un côté et de l'autre, sera-t-il le même ?
Ah oui, tiens ! Je serais curieux de savoir comment ça se passe. On ne tient pas compte des <fins de lignes> peut-être...
Ni des lettres majuscules ou minuscules, des signes de ponctuation, etc. ? Si on veut faire un checksum, alors il faut le faire sur un format commun, le plus logique me semblant être celui de SMTP (ASCII avec CR+LF).
le checksum prend le fichier comme étant un binaire. Donc si on altère les fins de lignes, le checksum est altéré. Quand aux formats semi-textes comme le RTF, même chose.
Je ne connais pas ce format RTF. Ça veut dire quoi « semi-texte » ? Que certaines parties sont en texte, et peuvent donc subir des transformations de charset, alors que d'autres parties sont en binaire et doivent rester inchangées octet par octet ? Si oui, comment décide-t-on de ce qui est variable et de ce qui ne l'est pas ?
Note que dans les traces de Josie, le type MIME est "application", il devrait donc à mon humble avis être considéré comme du binaire. Si l'un des logiciels (émetteur ou destinataire) le traite comme du texte, alors oui ce logiciel est bugué.
Je veux dire si tu fais un checksum (ou équivalent) du fichier d'un côté
et de l'autre, sera-t-il le même ?
Ah oui, tiens ! Je serais curieux de savoir comment ça se passe. On ne
tient pas compte des <fins de lignes> peut-être...
Ni des lettres majuscules ou minuscules, des signes de ponctuation,
etc. ? Si on veut faire un checksum, alors il faut le faire sur un
format commun, le plus logique me semblant être celui de SMTP (ASCII
avec CR+LF).
le checksum prend le fichier comme étant un binaire. Donc si on altère les
fins de lignes, le checksum est altéré. Quand aux formats semi-textes
comme le RTF, même chose.
Je ne connais pas ce format RTF. Ça veut dire quoi « semi-texte » ?
Que certaines parties sont en texte, et peuvent donc subir des
transformations de charset, alors que d'autres parties sont en binaire
et doivent rester inchangées octet par octet ? Si oui, comment
décide-t-on de ce qui est variable et de ce qui ne l'est pas ?
Note que dans les traces de Josie, le type MIME est "application", il
devrait donc à mon humble avis être considéré comme du binaire. Si l'un
des logiciels (émetteur ou destinataire) le traite comme du texte, alors
oui ce logiciel est bugué.
Je veux dire si tu fais un checksum (ou équivalent) du fichier d'un côté et de l'autre, sera-t-il le même ?
Ah oui, tiens ! Je serais curieux de savoir comment ça se passe. On ne tient pas compte des <fins de lignes> peut-être...
Ni des lettres majuscules ou minuscules, des signes de ponctuation, etc. ? Si on veut faire un checksum, alors il faut le faire sur un format commun, le plus logique me semblant être celui de SMTP (ASCII avec CR+LF).
le checksum prend le fichier comme étant un binaire. Donc si on altère les fins de lignes, le checksum est altéré. Quand aux formats semi-textes comme le RTF, même chose.
Je ne connais pas ce format RTF. Ça veut dire quoi « semi-texte » ? Que certaines parties sont en texte, et peuvent donc subir des transformations de charset, alors que d'autres parties sont en binaire et doivent rester inchangées octet par octet ? Si oui, comment décide-t-on de ce qui est variable et de ce qui ne l'est pas ?
Note que dans les traces de Josie, le type MIME est "application", il devrait donc à mon humble avis être considéré comme du binaire. Si l'un des logiciels (émetteur ou destinataire) le traite comme du texte, alors oui ce logiciel est bugué.
Xavier Roche
DINH Viêt Hoà wrote:
Si les transformations CR LF se faisait, tout ce qui est signature électronique de documents textes attachés serait invalide. (à noter aussi que les signatures électroniques ne tiennent pas compte du fait que le document est texte ou binaire).
- Pour PGP, la signature se fait sur le format "canonique" du mail en mode texte (lignes terminées par CRLF) ; transformation content-encoding et en têtes compris (une gateway intermédiaire a donc l'interdiction de changer le CTE)
(rfc2015) (1) The data to be signed must first be converted to its type/subtype specific canonical form. For text/plain, this means conversion to an appropriate character set and conversion of line endings to the canonical <CR><LF> sequence.
De même, pour conserver un format spécifique de retour charriot (que des CR, ou que des LF) en mode texte, la seule solution propre est d'utiliser quoted-printable et d'encoder explicitement les CR et les LF.
Une partie texte non canonique (CR/LF) sans content-transfer-encoding est à priori invalide, il me semble?
DINH Viêt Hoà wrote:
Si les transformations CR LF se faisait, tout ce qui est signature
électronique de documents textes attachés serait invalide. (à noter aussi
que les signatures électroniques ne tiennent pas compte du fait que le
document est texte ou binaire).
- Pour PGP, la signature se fait sur le format "canonique" du mail en
mode texte (lignes terminées par CRLF) ; transformation content-encoding
et en têtes compris (une gateway intermédiaire a donc l'interdiction de
changer le CTE)
(rfc2015)
(1) The data to be signed must first be converted to its
type/subtype specific canonical form. For text/plain, this
means conversion to an appropriate character set and conversion
of line endings to the canonical <CR><LF> sequence.
De même, pour conserver un format spécifique de retour charriot (que des
CR, ou que des LF) en mode texte, la seule solution propre est
d'utiliser quoted-printable et d'encoder explicitement les CR et les LF.
Une partie texte non canonique (CR/LF) sans content-transfer-encoding
est à priori invalide, il me semble?
Si les transformations CR LF se faisait, tout ce qui est signature électronique de documents textes attachés serait invalide. (à noter aussi que les signatures électroniques ne tiennent pas compte du fait que le document est texte ou binaire).
- Pour PGP, la signature se fait sur le format "canonique" du mail en mode texte (lignes terminées par CRLF) ; transformation content-encoding et en têtes compris (une gateway intermédiaire a donc l'interdiction de changer le CTE)
(rfc2015) (1) The data to be signed must first be converted to its type/subtype specific canonical form. For text/plain, this means conversion to an appropriate character set and conversion of line endings to the canonical <CR><LF> sequence.
De même, pour conserver un format spécifique de retour charriot (que des CR, ou que des LF) en mode texte, la seule solution propre est d'utiliser quoted-printable et d'encoder explicitement les CR et les LF.
Une partie texte non canonique (CR/LF) sans content-transfer-encoding est à priori invalide, il me semble?
Olivier Miakinen
je serai assez ennuyé qu'un logiciel se permette faire ce genre de transformations.
Pourtant, ils le font tous sur les machines qui utilisent un format autre que ASCII avec CR+LF. Note que les Windows le font aussi, quand tu sauves un fichier en UTF-8.
Moi, je serais ennuyé qu'ils ne le fassent pas. Quand je lisais mon mail sur Unix, je n'aurais pas aimé que tous mes messages aient un ^M à la fin de chaque ligne. De la même manière, si quelqu'un m'envoyait "ABC<CR><LF>" à partir d'une machine EBCDIC, je n'aimerais pas recevoir "ÁÂÃ<CR>%" à la place.
De même si, à partir d'un unix, je veux envoyer un fichier avec les retours à la ligne en CR LF, j'aurai aimé qu'il conserve la même présentation finale.
Dans ce cas tu l'envoies en binaire, pas en texte.
Si les transformations CR LF se faisait, tout ce qui est signature électronique de documents textes attachés serait invalide. (à noter aussi que les signatures électroniques ne tiennent pas compte du fait que le document est texte ou binaire).
Je suis incompétent dans ce domaine. Tu es sûr que la signature ne se fait pas juste avant l'envoi, c'est-à-dire dans le format d'échange commun, plutôt que dans le format interne de la machine ?
je serai assez ennuyé qu'un logiciel se permette faire ce genre de
transformations.
Pourtant, ils le font tous sur les machines qui utilisent un format
autre que ASCII avec CR+LF. Note que les Windows le font aussi, quand tu
sauves un fichier en UTF-8.
Moi, je serais ennuyé qu'ils ne le fassent pas. Quand je lisais mon mail
sur Unix, je n'aurais pas aimé que tous mes messages aient un ^M à la
fin de chaque ligne. De la même manière, si quelqu'un m'envoyait
"ABC<CR><LF>" à partir d'une machine EBCDIC, je n'aimerais pas recevoir
"ÁÂÃ<CR>%" à la place.
De même si, à partir d'un unix, je veux envoyer un
fichier avec les retours à la ligne en CR LF, j'aurai aimé qu'il conserve
la même présentation finale.
Dans ce cas tu l'envoies en binaire, pas en texte.
Si les transformations CR LF se faisait, tout ce qui est signature
électronique de documents textes attachés serait invalide. (à noter aussi
que les signatures électroniques ne tiennent pas compte du fait que le
document est texte ou binaire).
Je suis incompétent dans ce domaine. Tu es sûr que la signature ne se
fait pas juste avant l'envoi, c'est-à-dire dans le format d'échange
commun, plutôt que dans le format interne de la machine ?
je serai assez ennuyé qu'un logiciel se permette faire ce genre de transformations.
Pourtant, ils le font tous sur les machines qui utilisent un format autre que ASCII avec CR+LF. Note que les Windows le font aussi, quand tu sauves un fichier en UTF-8.
Moi, je serais ennuyé qu'ils ne le fassent pas. Quand je lisais mon mail sur Unix, je n'aurais pas aimé que tous mes messages aient un ^M à la fin de chaque ligne. De la même manière, si quelqu'un m'envoyait "ABC<CR><LF>" à partir d'une machine EBCDIC, je n'aimerais pas recevoir "ÁÂÃ<CR>%" à la place.
De même si, à partir d'un unix, je veux envoyer un fichier avec les retours à la ligne en CR LF, j'aurai aimé qu'il conserve la même présentation finale.
Dans ce cas tu l'envoies en binaire, pas en texte.
Si les transformations CR LF se faisait, tout ce qui est signature électronique de documents textes attachés serait invalide. (à noter aussi que les signatures électroniques ne tiennent pas compte du fait que le document est texte ou binaire).
Je suis incompétent dans ce domaine. Tu es sûr que la signature ne se fait pas juste avant l'envoi, c'est-à-dire dans le format d'échange commun, plutôt que dans le format interne de la machine ?
Olivier Miakinen
- Pour PGP, la signature se fait sur le format "canonique" du mail en mode texte (lignes terminées par CRLF) ; transformation content-encoding et en têtes compris (une gateway intermédiaire a donc l'interdiction de changer le CTE)
Merci de confirmer ce que je soupçonnais.
(rfc2015) (1) The data to be signed must first be converted to its type/subtype specific canonical form. For text/plain, this means conversion to an appropriate character set and conversion of line endings to the canonical <CR><LF> sequence.
Je vais m'empresser de lire ce RFC.
De même, pour conserver un format spécifique de retour charriot (que des CR, ou que des LF) en mode texte, la seule solution propre est d'utiliser quoted-printable et d'encoder explicitement les CR et les LF.
Oui.
Une partie texte non canonique (CR/LF) sans content-transfer-encoding est à priori invalide, il me semble?
Il me semble aussi.
- Pour PGP, la signature se fait sur le format "canonique" du mail en
mode texte (lignes terminées par CRLF) ; transformation content-encoding
et en têtes compris (une gateway intermédiaire a donc l'interdiction de
changer le CTE)
Merci de confirmer ce que je soupçonnais.
(rfc2015)
(1) The data to be signed must first be converted to its
type/subtype specific canonical form. For text/plain, this
means conversion to an appropriate character set and conversion
of line endings to the canonical <CR><LF> sequence.
Je vais m'empresser de lire ce RFC.
De même, pour conserver un format spécifique de retour charriot (que des
CR, ou que des LF) en mode texte, la seule solution propre est
d'utiliser quoted-printable et d'encoder explicitement les CR et les LF.
Oui.
Une partie texte non canonique (CR/LF) sans content-transfer-encoding
est à priori invalide, il me semble?
- Pour PGP, la signature se fait sur le format "canonique" du mail en mode texte (lignes terminées par CRLF) ; transformation content-encoding et en têtes compris (une gateway intermédiaire a donc l'interdiction de changer le CTE)
Merci de confirmer ce que je soupçonnais.
(rfc2015) (1) The data to be signed must first be converted to its type/subtype specific canonical form. For text/plain, this means conversion to an appropriate character set and conversion of line endings to the canonical <CR><LF> sequence.
Je vais m'empresser de lire ce RFC.
De même, pour conserver un format spécifique de retour charriot (que des CR, ou que des LF) en mode texte, la seule solution propre est d'utiliser quoted-printable et d'encoder explicitement les CR et les LF.
Oui.
Une partie texte non canonique (CR/LF) sans content-transfer-encoding est à priori invalide, il me semble?
