cet article est plublié sur les deux forums fr.comp.mail.* car il
concerne un peu les deux forums, avec suivi sur fr.comp.mail qui me
semble plus... divers.
Voilà, j'ai besoin d'implanter l'accès aux fichiers spools de courrier
électronique de système unix (lecture+écriture). Ayant un peu fouillé
j'ai vu que normalement c'est le format "mbox" qui est utilisé.
Cependant voilà, j'ai fait un test avec postfix et mutt, et je n'ai
pas vraiment les résultats décrits par le format :
- Normalement, un "From_" doit être échappé en
">From_". Effectivement, cependant mutt n'a pas fait de transcodage
arrière, de sorte que le ">" reste à la lecture.
- Normalement, un ">From_" doit être transcodé en ">>From_". Moi je
veux bien, mais sauf si j'ai foiré mon test, il n'y a pas eu de
transcodage et j'ai toujours ">From_".
Bref, ca me semble bien imprécis tout ca. C'est pas critique puisque
la ligne vraiment critique "From_" est échappée pour éviter une
mauvaise lecture du spool, mais c'est imprécis, je n'ai pas les
comportements attendus concernant le format mbox.
Donc... comme je pense que je risque d'avoir des résultats différents
avec d'autres clients, voire d'autres serveurs, je souhaiterai avoir
des avis ou un lien sur la meilleure manière d'implanter ca. Ce que
les "bons" serveurs et "bons" clients implantent pour que je me calque
sur ce que eux font, sans avoir à tester tous les logiciels
existants.
Notamment, faut-il transcoder un >{n}From_ en >{n+1}From_ ou pas ?
Merci d'avance.
--
Un peu d'aléa dans ce monde de fatalité.
http://www.alea.net/usenet/
- Normalement, un ">From_" doit être transcodé en ">>From_". Moi je veux bien, mais sauf si j'ai foiré mon test, il n'y a pas eu de transcodage et j'ai toujours ">From_".
Notamment, faut-il transcoder un >{n}From_ en >{n+1}From_ ou pas ?
Il ne me semble pas qu'un >From soit encodé en >>From. Seul From est codé en >From. Du coup bien sure, il ne peut pas y avoir de décodage à la lecture, et le >From est laissé en l'état, comme le fait mutt dans tes tests. Bref, je ne crois pas que ça soit prévu pour être réversible...
C'est différent avec le "." en début de ligne en nntp (et en smtp aussi d'ailleurs je crois) que l'on code toujours en rajoutant un ".", et que l'on peut donc décoder en enlevant un "."
Vincent Hiribarren <vynce@alea.invalid> a écrit sur fr.comp.mail :
- Normalement, un ">From_" doit être transcodé en ">>From_". Moi je
veux bien, mais sauf si j'ai foiré mon test, il n'y a pas eu de
transcodage et j'ai toujours ">From_".
Notamment, faut-il transcoder un >{n}From_ en >{n+1}From_ ou pas ?
Il ne me semble pas qu'un >From soit encodé en >>From. Seul From est
codé en >From. Du coup bien sure, il ne peut pas y avoir de décodage à
la lecture, et le >From est laissé en l'état, comme le fait mutt dans
tes tests. Bref, je ne crois pas que ça soit prévu pour être
réversible...
C'est différent avec le "." en début de ligne en nntp (et en smtp aussi
d'ailleurs je crois) que l'on code toujours en rajoutant un ".", et que
l'on peut donc décoder en enlevant un "."
- Normalement, un ">From_" doit être transcodé en ">>From_". Moi je veux bien, mais sauf si j'ai foiré mon test, il n'y a pas eu de transcodage et j'ai toujours ">From_".
Notamment, faut-il transcoder un >{n}From_ en >{n+1}From_ ou pas ?
Il ne me semble pas qu'un >From soit encodé en >>From. Seul From est codé en >From. Du coup bien sure, il ne peut pas y avoir de décodage à la lecture, et le >From est laissé en l'état, comme le fait mutt dans tes tests. Bref, je ne crois pas que ça soit prévu pour être réversible...
C'est différent avec le "." en début de ligne en nntp (et en smtp aussi d'ailleurs je crois) que l'on code toujours en rajoutant un ".", et que l'on peut donc décoder en enlevant un "."
Vincent Hiribarren
Etienne de Tocqueville <et+ writes:
Notamment, faut-il transcoder un >{n}From_ en >{n+1}From_ ou pas ?
Il ne me semble pas qu'un >From soit encodé en >>From. Seul From est codé en >From. Du coup bien sure, il ne peut pas y avoir de décodage à la lecture, et le >From est laissé en l'état, comme le fait mutt dans tes tests. Bref, je ne crois pas que ça soit prévu pour être réversible...
Bon, le comportement que j'observe et ton sentiment confirme celà. Je trouve quand même que c'est pas très logique, on a un système qui empêche d'avoir un message identique à celui envoyé. Certes, la modification est plus que mineure, mais c'est dommage.
Merci.
-- Un peu d'aléa dans ce monde de fatalité. http://www.alea.net/usenet/
Etienne de Tocqueville <et+news@steph.teaser.fr> writes:
Notamment, faut-il transcoder un >{n}From_ en >{n+1}From_ ou pas ?
Il ne me semble pas qu'un >From soit encodé en >>From. Seul From est
codé en >From. Du coup bien sure, il ne peut pas y avoir de décodage à
la lecture, et le >From est laissé en l'état, comme le fait mutt dans
tes tests. Bref, je ne crois pas que ça soit prévu pour être
réversible...
Bon, le comportement que j'observe et ton sentiment confirme celà. Je
trouve quand même que c'est pas très logique, on a un système qui
empêche d'avoir un message identique à celui envoyé. Certes, la
modification est plus que mineure, mais c'est dommage.
Merci.
--
Un peu d'aléa dans ce monde de fatalité.
http://www.alea.net/usenet/
Notamment, faut-il transcoder un >{n}From_ en >{n+1}From_ ou pas ?
Il ne me semble pas qu'un >From soit encodé en >>From. Seul From est codé en >From. Du coup bien sure, il ne peut pas y avoir de décodage à la lecture, et le >From est laissé en l'état, comme le fait mutt dans tes tests. Bref, je ne crois pas que ça soit prévu pour être réversible...
Bon, le comportement que j'observe et ton sentiment confirme celà. Je trouve quand même que c'est pas très logique, on a un système qui empêche d'avoir un message identique à celui envoyé. Certes, la modification est plus que mineure, mais c'est dommage.
Merci.
-- Un peu d'aléa dans ce monde de fatalité. http://www.alea.net/usenet/
Jérémy JUST
On 07 Sep 2004 20:29:08 +0200 Vincent Hiribarren wrote:
Bon, le comportement que j'observe et ton sentiment confirme celà. Je trouve quand même que c'est pas très logique, on a un système qui empêche d'avoir un message identique à celui envoyé. Certes, la modification est plus que mineure, mais c'est dommage.
Et ce qui est drôle, c'est que ça pose de vrais problèmes: dans certains vieux articles de journaux écrits en TeX, on trouve parfois le caractère incongru qui résulte de la transformation:
From protégé en
From compilé en
¿From
-- Jérémy JUST
On 07 Sep 2004 20:29:08 +0200
Vincent Hiribarren <vynce@alea.invalid> wrote:
Bon, le comportement que j'observe et ton sentiment confirme celà. Je
trouve quand même que c'est pas très logique, on a un système qui
empêche d'avoir un message identique à celui envoyé. Certes, la
modification est plus que mineure, mais c'est dommage.
Et ce qui est drôle, c'est que ça pose de vrais problèmes: dans
certains vieux articles de journaux écrits en TeX, on trouve parfois le
caractère incongru qui résulte de la transformation:
On 07 Sep 2004 20:29:08 +0200 Vincent Hiribarren wrote:
Bon, le comportement que j'observe et ton sentiment confirme celà. Je trouve quand même que c'est pas très logique, on a un système qui empêche d'avoir un message identique à celui envoyé. Certes, la modification est plus que mineure, mais c'est dommage.
Et ce qui est drôle, c'est que ça pose de vrais problèmes: dans certains vieux articles de journaux écrits en TeX, on trouve parfois le caractère incongru qui résulte de la transformation:
From protégé en
From compilé en
¿From
-- Jérémy JUST
Fabien LE LEZ
On 07 Sep 2004 18:59:03 +0200, Vincent Hiribarren :
- Normalement, un "From_" doit être échappé en ">From_".
Normalement. Mais en fait, pas toujours. J'ai regardé ce que ça donne avec Mozilla, et on a bien des "From " en plein milieu d'un email. La seule assurance que j'ai trouvée (et encore, je ne suis pas 100 % sûr), c'est que "From " précédé d'une ligne blanche, indique le début d'un email.
-- ;-)
On 07 Sep 2004 18:59:03 +0200, Vincent Hiribarren
<vynce@alea.invalid>:
- Normalement, un "From_" doit être échappé en
">From_".
Normalement. Mais en fait, pas toujours.
J'ai regardé ce que ça donne avec Mozilla, et on a bien des "From " en
plein milieu d'un email. La seule assurance que j'ai trouvée (et
encore, je ne suis pas 100 % sûr), c'est que "From " précédé d'une
ligne blanche, indique le début d'un email.
On 07 Sep 2004 18:59:03 +0200, Vincent Hiribarren :
- Normalement, un "From_" doit être échappé en ">From_".
Normalement. Mais en fait, pas toujours. J'ai regardé ce que ça donne avec Mozilla, et on a bien des "From " en plein milieu d'un email. La seule assurance que j'ai trouvée (et encore, je ne suis pas 100 % sûr), c'est que "From " précédé d'une ligne blanche, indique le début d'un email.
-- ;-)
Vincent Hiribarren
Jérémy JUST writes:
[Mauvais transcodage des From dans le spool mail]
From protégé en
From compilé en
¿From
:-))) C'est excellent de pouvoir comprendre le pourquoi de ce machin, bien que je ne sois jamais tombé dessus :-)
Mais comment on en est arrivé là ? La rëponse m'intéresse. Certes, au niveau de l'implantation c'est peut-être embêtant (et encore...) d'avoir à vérifier si une succession de ">" est suivi par un "From ", mais quand même !
-- Un peu d'aléa dans ce monde de fatalité. http://www.alea.net/usenet/
Jérémy JUST <jeremy_just@netcourrier.com> writes:
[Mauvais transcodage des From dans le spool mail]
From
protégé en
From
compilé en
¿From
:-)))
C'est excellent de pouvoir comprendre le pourquoi de ce machin, bien
que je ne sois jamais tombé dessus :-)
Mais comment on en est arrivé là ? La rëponse m'intéresse. Certes, au
niveau de l'implantation c'est peut-être embêtant (et encore...)
d'avoir à vérifier si une succession de ">" est suivi par un "From ",
mais quand même !
--
Un peu d'aléa dans ce monde de fatalité.
http://www.alea.net/usenet/
:-))) C'est excellent de pouvoir comprendre le pourquoi de ce machin, bien que je ne sois jamais tombé dessus :-)
Mais comment on en est arrivé là ? La rëponse m'intéresse. Certes, au niveau de l'implantation c'est peut-être embêtant (et encore...) d'avoir à vérifier si une succession de ">" est suivi par un "From ", mais quand même !
-- Un peu d'aléa dans ce monde de fatalité. http://www.alea.net/usenet/
Solignac
Vincent Hiribarren wrote:
[Mauvais transcodage des From dans le spool mail]
From protégé en
From compilé en
¿From
:-))) C'est excellent de pouvoir comprendre le pourquoi de ce machin, bien que je ne sois jamais tombé dessus :-)
Plein d'articles scientifiques "non officiels" ou bouquins en ligne le contiennent.
Mais comment on en est arrivé là ?
Très simplement: avec LaTeX, le caractère '>' est compilé en '¿' en mode texte, alors qu'il apparaît "correctement" ('$>$' -> '>') en mode mathématique.
Normalement la rfc qui décrit le smtp stipule qu'aucune modification ne doit être apportée au message (en dehors de quelques trucs bien spécifiés). À l'origine c'est un bug (ou feature) de sendmail, longuement relaté dans le Unix Haters Handbook. Ce genre de feature ne se retrouve pas avec Postfix (test sommaire, j'en conviens).
bye
-- EMACS: Easily Maintained with the Assistance of Chemical Solutions
Vincent Hiribarren <vynce@alea.invalid> wrote:
[Mauvais transcodage des From dans le spool mail]
From
protégé en
From
compilé en
¿From
:-)))
C'est excellent de pouvoir comprendre le pourquoi de ce machin, bien
que je ne sois jamais tombé dessus :-)
Plein d'articles scientifiques "non officiels" ou bouquins en ligne le
contiennent.
Mais comment on en est arrivé là ?
Très simplement: avec LaTeX, le caractère '>' est compilé en '¿' en mode
texte, alors qu'il apparaît "correctement" ('$>$' -> '>') en mode mathématique.
Normalement la rfc qui décrit le smtp stipule qu'aucune modification ne
doit être apportée au message (en dehors de quelques trucs bien
spécifiés). À l'origine c'est un bug (ou feature) de sendmail, longuement
relaté dans le Unix Haters Handbook. Ce genre de feature ne se retrouve pas
avec Postfix (test sommaire, j'en conviens).
bye
--
EMACS: Easily Maintained with the Assistance of Chemical Solutions
:-))) C'est excellent de pouvoir comprendre le pourquoi de ce machin, bien que je ne sois jamais tombé dessus :-)
Plein d'articles scientifiques "non officiels" ou bouquins en ligne le contiennent.
Mais comment on en est arrivé là ?
Très simplement: avec LaTeX, le caractère '>' est compilé en '¿' en mode texte, alors qu'il apparaît "correctement" ('$>$' -> '>') en mode mathématique.
Normalement la rfc qui décrit le smtp stipule qu'aucune modification ne doit être apportée au message (en dehors de quelques trucs bien spécifiés). À l'origine c'est un bug (ou feature) de sendmail, longuement relaté dans le Unix Haters Handbook. Ce genre de feature ne se retrouve pas avec Postfix (test sommaire, j'en conviens).
bye
-- EMACS: Easily Maintained with the Assistance of Chemical Solutions
Laurent Wacrenier
Solignac écrit:
Normalement la rfc qui décrit le smtp stipule qu'aucune modification ne doit être apportée au message (en dehors de quelques trucs bien spécifiés).
Les messages ne sont pas stoqués localement "en smtp".
Normalement la rfc qui décrit le smtp stipule qu'aucune modification ne doit être apportée au message (en dehors de quelques trucs bien spécifiés).
Les messages ne sont pas stoqués localement "en smtp". stockés
Je ne vois pas le rapport avec la modification du From en >From, désolé.
-- We're Velvet Revolver and we play fuckin' rock n'roll. -+- Scott Weiland
Solignac
Vincent Hiribarren wrote:
Solignac writes:
Mais comment on en est arrivé là ?
Très simplement: avec LaTeX [...]
Euh, non, LaTeX je m'en doute même si j'ai tendance à ne pas l'utiliser et ne pas savoir comment se compile un ">", je voulais dire : comment des gens ont pu tomber d'accord pour normaliser ce transcodage foireux, qui forcément crée des problèmes ?
Ah désolé :) Ça s'appelle un mauvais compromis. Je n'en sais pas beaucoup plus, demande à Eric Allman (auteur de Sendmail si je ne m'abuse). Je crois qu'il y a un auteur d'un livre sur sendmail sur ce forum, il en sait peut-être plus.
Normalement la rfc qui décrit le smtp stipule qu'aucune modification ne doit être apportée au message (en dehors de quelques trucs bien spécifiés). À l'origine c'est un bug (ou feature) de sendmail,
Intéressant à savoir, merci (feature ? hum...).
'Dépend des points de vue :)
longuement relaté dans le Unix Haters Handbook.
Je dois l'avoir par là et vais y jeter un coup d'oeil, mais personne n'a fait une version plus récente ?
Non et la ML associée est close depuis environ 1996 je crois. Je dois avouer que pas mal de choses (en volume) relatées dans ce bouquin relèvent de la mauvaise foi ou de l'incurie, mais il relève de nombreux défauts, failles d'Unix.
Il commence à dater.
Ah mais sendmail est immortel ;-)
Ce genre de feature ne se retrouve pas avec Postfix (test sommaire, j'en conviens).
Hum ? Je me suis rendu compte du problème justement en utilisant Postfix. Postfix avec lecture par Mutt.
Ben pas chez moi c'est curieux, j'ai essayé avec un message du genre:
<<<<< toto From toto
From toto
Tu es sûr qu'il n'y a pas autre chose que postfix dans ta chaîne de mail?
bye
-- Bruce Wayne> Non, Dick. L'heure est aux loisirs, à la folie, à la pantalonnade, ... Dick Gracen> Oh non! Encore une soirée bowling-karaoke? -+- Batman & Robin -- Le monde de Monsieur Fred
Euh, non, LaTeX je m'en doute même si j'ai tendance à ne pas
l'utiliser et ne pas savoir comment se compile un ">", je voulais
dire : comment des gens ont pu tomber d'accord pour normaliser ce
transcodage foireux, qui forcément crée des problèmes ?
Ah désolé :) Ça s'appelle un mauvais compromis. Je n'en sais pas beaucoup
plus, demande à Eric Allman (auteur de Sendmail si je ne m'abuse). Je crois
qu'il y a un auteur d'un livre sur sendmail sur ce forum, il en sait
peut-être plus.
Normalement la rfc qui décrit le smtp stipule qu'aucune modification ne
doit être apportée au message (en dehors de quelques trucs bien
spécifiés). À l'origine c'est un bug (ou feature) de sendmail,
Intéressant à savoir, merci (feature ? hum...).
'Dépend des points de vue :)
longuement relaté dans le Unix Haters Handbook.
Je dois l'avoir par là et vais y jeter un coup d'oeil, mais personne
n'a fait une version plus récente ?
Non et la ML associée est close depuis environ 1996 je crois. Je dois
avouer que pas mal de choses (en volume) relatées dans ce bouquin relèvent
de la mauvaise foi ou de l'incurie, mais il relève de nombreux défauts,
failles d'Unix.
Il commence à dater.
Ah mais sendmail est immortel ;-)
Ce genre de feature ne se retrouve pas
avec Postfix (test sommaire, j'en conviens).
Hum ? Je me suis rendu compte du problème justement
en utilisant Postfix. Postfix avec lecture par Mutt.
Ben pas chez moi c'est curieux, j'ai essayé avec un message du genre:
<<<<<
toto
From
toto
From
toto
Tu es sûr qu'il n'y a pas autre chose que postfix dans ta chaîne de mail?
bye
--
Bruce Wayne> Non, Dick. L'heure est aux loisirs, à la folie, à la
pantalonnade, ...
Dick Gracen> Oh non! Encore une soirée bowling-karaoke?
-+- Batman & Robin -- Le monde de Monsieur Fred
Euh, non, LaTeX je m'en doute même si j'ai tendance à ne pas l'utiliser et ne pas savoir comment se compile un ">", je voulais dire : comment des gens ont pu tomber d'accord pour normaliser ce transcodage foireux, qui forcément crée des problèmes ?
Ah désolé :) Ça s'appelle un mauvais compromis. Je n'en sais pas beaucoup plus, demande à Eric Allman (auteur de Sendmail si je ne m'abuse). Je crois qu'il y a un auteur d'un livre sur sendmail sur ce forum, il en sait peut-être plus.
Normalement la rfc qui décrit le smtp stipule qu'aucune modification ne doit être apportée au message (en dehors de quelques trucs bien spécifiés). À l'origine c'est un bug (ou feature) de sendmail,
Intéressant à savoir, merci (feature ? hum...).
'Dépend des points de vue :)
longuement relaté dans le Unix Haters Handbook.
Je dois l'avoir par là et vais y jeter un coup d'oeil, mais personne n'a fait une version plus récente ?
Non et la ML associée est close depuis environ 1996 je crois. Je dois avouer que pas mal de choses (en volume) relatées dans ce bouquin relèvent de la mauvaise foi ou de l'incurie, mais il relève de nombreux défauts, failles d'Unix.
Il commence à dater.
Ah mais sendmail est immortel ;-)
Ce genre de feature ne se retrouve pas avec Postfix (test sommaire, j'en conviens).
Hum ? Je me suis rendu compte du problème justement en utilisant Postfix. Postfix avec lecture par Mutt.
Ben pas chez moi c'est curieux, j'ai essayé avec un message du genre:
<<<<< toto From toto
From toto
Tu es sûr qu'il n'y a pas autre chose que postfix dans ta chaîne de mail?
bye
-- Bruce Wayne> Non, Dick. L'heure est aux loisirs, à la folie, à la pantalonnade, ... Dick Gracen> Oh non! Encore une soirée bowling-karaoke? -+- Batman & Robin -- Le monde de Monsieur Fred
Vincent Hiribarren
Solignac writes:
Mais comment on en est arrivé là ?
Très simplement: avec LaTeX [...]
Euh, non, LaTeX je m'en doute même si j'ai tendance à ne pas l'utiliser et ne pas savoir comment se compile un ">", je voulais dire : comment des gens ont pu tomber d'accord pour normaliser ce transcodage foireux, qui forcément crée des problèmes ?
Normalement la rfc qui décrit le smtp stipule qu'aucune modification ne doit être apportée au message (en dehors de quelques trucs bien spécifiés). À l'origine c'est un bug (ou feature) de sendmail,
Intéressant à savoir, merci (feature ? hum...).
longuement relaté dans le Unix Haters Handbook.
Je dois l'avoir par là et vais y jeter un coup d'oeil, mais personne n'a fait une version plus récente ? Il commence à dater.
Ce genre de feature ne se retrouve pas avec Postfix (test sommaire, j'en conviens).
Hum ? Je me suis rendu compte du problème justement en utilisant Postfix. Postfix avec lecture par Mutt.
-- Un peu d'aléa dans ce monde de fatalité. http://www.alea.net/usenet/
Euh, non, LaTeX je m'en doute même si j'ai tendance à ne pas
l'utiliser et ne pas savoir comment se compile un ">", je voulais
dire : comment des gens ont pu tomber d'accord pour normaliser ce
transcodage foireux, qui forcément crée des problèmes ?
Normalement la rfc qui décrit le smtp stipule qu'aucune modification ne
doit être apportée au message (en dehors de quelques trucs bien
spécifiés). À l'origine c'est un bug (ou feature) de sendmail,
Intéressant à savoir, merci (feature ? hum...).
longuement relaté dans le Unix Haters Handbook.
Je dois l'avoir par là et vais y jeter un coup d'oeil, mais personne
n'a fait une version plus récente ? Il commence à dater.
Ce genre de feature ne se retrouve pas
avec Postfix (test sommaire, j'en conviens).
Hum ? Je me suis rendu compte du problème justement
en utilisant Postfix. Postfix avec lecture par Mutt.
--
Un peu d'aléa dans ce monde de fatalité.
http://www.alea.net/usenet/
Euh, non, LaTeX je m'en doute même si j'ai tendance à ne pas l'utiliser et ne pas savoir comment se compile un ">", je voulais dire : comment des gens ont pu tomber d'accord pour normaliser ce transcodage foireux, qui forcément crée des problèmes ?
Normalement la rfc qui décrit le smtp stipule qu'aucune modification ne doit être apportée au message (en dehors de quelques trucs bien spécifiés). À l'origine c'est un bug (ou feature) de sendmail,
Intéressant à savoir, merci (feature ? hum...).
longuement relaté dans le Unix Haters Handbook.
Je dois l'avoir par là et vais y jeter un coup d'oeil, mais personne n'a fait une version plus récente ? Il commence à dater.
Ce genre de feature ne se retrouve pas avec Postfix (test sommaire, j'en conviens).
Hum ? Je me suis rendu compte du problème justement en utilisant Postfix. Postfix avec lecture par Mutt.
-- Un peu d'aléa dans ce monde de fatalité. http://www.alea.net/usenet/
