[expect] Fonctionnement différent entre Linux et NetBSD
12 réponses
JKB
Bonjour à tous,
J'utilise dans un script expect pour envoyer un mail à un
utilisateur (je ne peux pas faire autre chose qu'un telnet sur le
port 587 pour des raisons trop longues à expliquer ici, donc me dire
d'utiliser la commande mail _n'est pas une solution_).
Ça fonctionne parfaitement (moyennant le positionnement des
variables en question). J'ai migré ce script sous NetBSD et là, j'ai
une surprise que je ne saisis pas.
La variable $CORPS contient un fragment de fichier encodé et
chiffré (longueur des lignes : 76 caractères). Il y a un md5 pour
s'assurer de la validité des données transmises.
Sous les deux OS, la variable CORPS est strictement identique.
Pourtant, dans la sortie d'expect, sous Linux, j'ai un \r et sous
NetBSD un \r\n d'où un saut de ligne supplémentaire qui me met ma
somme md5 par terre.
Je viens de lire et de relire la doc d'expect, visiblement, ça ne se
configure pas. Alors comment faire ?
Merci pour toute suggestion,
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
J'utilise dans un script expect pour envoyer un mail à un utilisateur (je ne peux pas faire autre chose qu'un telnet sur le port 587 pour des raisons trop longues à expliquer ici, donc me dire d'utiliser la commande mail _n'est pas une solution_).
J'imagine que tu n'as pas de commande sendmail non plus… En revanche, il serait peut-être pertinent d'utiliser netcat plutôt que telnet, dont l'interprétation de séquences de contrôle de terminal n'est pas franchement pertinente ici, n'est-ce pas ?
Sous les deux OS, la variable CORPS est strictement identique. Pourtant, dans la sortie d'expect, sous Linux, j'ai un r et sous NetBSD un rn d'où un saut de ligne supplémentaire qui me met ma somme md5 par terre.
Je ne sais pas si c'est lié, mais j'ai déjà eu des problèmes semblables en envoyant de façon plus « conventionnelle » un fichier texte en attachement, problème que j'avais réglé en gzippant ce fichier. Tout ce que je sais, c'est que pour transmettre un message en SMTP, on est censé mettre des rn. Lorsque tu soumets ton message avec des n simples, le serveur l'accepte en général, mais serait en droit de le refuser, et il n'est pas inimaginale qu'il remplace cela par des rn avant de le transmettre.
-- . o . . . o Tanguy o o o
JKB, 2013-01-30 16:24+0100:
J'utilise dans un script expect pour envoyer un mail à un
utilisateur (je ne peux pas faire autre chose qu'un telnet sur le
port 587 pour des raisons trop longues à expliquer ici, donc me dire
d'utiliser la commande mail _n'est pas une solution_).
J'imagine que tu n'as pas de commande sendmail non plus…
En revanche, il serait peut-être pertinent d'utiliser netcat plutôt que
telnet, dont l'interprétation de séquences de contrôle de terminal n'est
pas franchement pertinente ici, n'est-ce pas ?
Sous les deux OS, la variable CORPS est strictement identique.
Pourtant, dans la sortie d'expect, sous Linux, j'ai un r et sous
NetBSD un rn d'où un saut de ligne supplémentaire qui me met ma
somme md5 par terre.
Je ne sais pas si c'est lié, mais j'ai déjà eu des problèmes semblables
en envoyant de façon plus « conventionnelle » un fichier texte en
attachement, problème que j'avais réglé en gzippant ce fichier. Tout ce
que je sais, c'est que pour transmettre un message en SMTP, on est
censé mettre des rn. Lorsque tu soumets ton message avec des n
simples, le serveur l'accepte en général, mais serait en droit de le
refuser, et il n'est pas inimaginale qu'il remplace cela par des rn
avant de le transmettre.
J'utilise dans un script expect pour envoyer un mail à un utilisateur (je ne peux pas faire autre chose qu'un telnet sur le port 587 pour des raisons trop longues à expliquer ici, donc me dire d'utiliser la commande mail _n'est pas une solution_).
J'imagine que tu n'as pas de commande sendmail non plus… En revanche, il serait peut-être pertinent d'utiliser netcat plutôt que telnet, dont l'interprétation de séquences de contrôle de terminal n'est pas franchement pertinente ici, n'est-ce pas ?
Sous les deux OS, la variable CORPS est strictement identique. Pourtant, dans la sortie d'expect, sous Linux, j'ai un r et sous NetBSD un rn d'où un saut de ligne supplémentaire qui me met ma somme md5 par terre.
Je ne sais pas si c'est lié, mais j'ai déjà eu des problèmes semblables en envoyant de façon plus « conventionnelle » un fichier texte en attachement, problème que j'avais réglé en gzippant ce fichier. Tout ce que je sais, c'est que pour transmettre un message en SMTP, on est censé mettre des rn. Lorsque tu soumets ton message avec des n simples, le serveur l'accepte en général, mais serait en droit de le refuser, et il n'est pas inimaginale qu'il remplace cela par des rn avant de le transmettre.
-- . o . . . o Tanguy o o o
JKB
Le 30 Jan 2013 15:48:29 GMT, Tanguy Ortolo écrivait :
JKB, 2013-01-30 16:24+0100:
J'utilise dans un script expect pour envoyer un mail à un utilisateur (je ne peux pas faire autre chose qu'un telnet sur le port 587 pour des raisons trop longues à expliquer ici, donc me dire d'utiliser la commande mail _n'est pas une solution_).
J'imagine que tu n'as pas de commande sendmail non plus… En revanche, il serait peut-être pertinent d'utiliser netcat plutôt que telnet, dont l'interprétation de séquences de contrôle de terminal n'est pas franchement pertinente ici, n'est-ce pas ?
Sous les deux OS, la variable CORPS est strictement identique. Pourtant, dans la sortie d'expect, sous Linux, j'ai un r et sous NetBSD un rn d'où un saut de ligne supplémentaire qui me met ma somme md5 par terre.
Je ne sais pas si c'est lié, mais j'ai déjà eu des problèmes semblables en envoyant de façon plus « conventionnelle » un fichier texte en attachement, problème que j'avais réglé en gzippant ce fichier. Tout ce que je sais, c'est que pour transmettre un message en SMTP, on est censé mettre des rn. Lorsque tu soumets ton message avec des n simples, le serveur l'accepte en général, mais serait en droit de le refuser, et il n'est pas inimaginale qu'il remplace cela par des rn avant de le transmettre.
J'ai un sendmail des deux côtés (Linux et NetBSD). Je vais creuser par là. Merci pour l'info...
Le 30 Jan 2013 15:48:29 GMT,
Tanguy Ortolo <tanguy@ortolo.eu> écrivait :
JKB, 2013-01-30 16:24+0100:
J'utilise dans un script expect pour envoyer un mail à un
utilisateur (je ne peux pas faire autre chose qu'un telnet sur le
port 587 pour des raisons trop longues à expliquer ici, donc me dire
d'utiliser la commande mail _n'est pas une solution_).
J'imagine que tu n'as pas de commande sendmail non plus…
En revanche, il serait peut-être pertinent d'utiliser netcat plutôt que
telnet, dont l'interprétation de séquences de contrôle de terminal n'est
pas franchement pertinente ici, n'est-ce pas ?
Sous les deux OS, la variable CORPS est strictement identique.
Pourtant, dans la sortie d'expect, sous Linux, j'ai un r et sous
NetBSD un rn d'où un saut de ligne supplémentaire qui me met ma
somme md5 par terre.
Je ne sais pas si c'est lié, mais j'ai déjà eu des problèmes semblables
en envoyant de façon plus « conventionnelle » un fichier texte en
attachement, problème que j'avais réglé en gzippant ce fichier. Tout ce
que je sais, c'est que pour transmettre un message en SMTP, on est
censé mettre des rn. Lorsque tu soumets ton message avec des n
simples, le serveur l'accepte en général, mais serait en droit de le
refuser, et il n'est pas inimaginale qu'il remplace cela par des rn
avant de le transmettre.
J'ai un sendmail des deux côtés (Linux et NetBSD). Je vais creuser
par là. Merci pour l'info...
HJV
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Le 30 Jan 2013 15:48:29 GMT, Tanguy Ortolo écrivait :
JKB, 2013-01-30 16:24+0100:
J'utilise dans un script expect pour envoyer un mail à un utilisateur (je ne peux pas faire autre chose qu'un telnet sur le port 587 pour des raisons trop longues à expliquer ici, donc me dire d'utiliser la commande mail _n'est pas une solution_).
J'imagine que tu n'as pas de commande sendmail non plus… En revanche, il serait peut-être pertinent d'utiliser netcat plutôt que telnet, dont l'interprétation de séquences de contrôle de terminal n'est pas franchement pertinente ici, n'est-ce pas ?
Sous les deux OS, la variable CORPS est strictement identique. Pourtant, dans la sortie d'expect, sous Linux, j'ai un r et sous NetBSD un rn d'où un saut de ligne supplémentaire qui me met ma somme md5 par terre.
Je ne sais pas si c'est lié, mais j'ai déjà eu des problèmes semblables en envoyant de façon plus « conventionnelle » un fichier texte en attachement, problème que j'avais réglé en gzippant ce fichier. Tout ce que je sais, c'est que pour transmettre un message en SMTP, on est censé mettre des rn. Lorsque tu soumets ton message avec des n simples, le serveur l'accepte en général, mais serait en droit de le refuser, et il n'est pas inimaginale qu'il remplace cela par des rn avant de le transmettre.
J'ai un sendmail des deux côtés (Linux et NetBSD). Je vais creuser par là. Merci pour l'info...
Le 30 Jan 2013 15:48:29 GMT, Tanguy Ortolo écrivait :
JKB, 2013-01-30 16:24+0100:
J'utilise dans un script expect pour envoyer un mail à un utilisateur (je ne peux pas faire autre chose qu'un telnet sur le port 587 pour des raisons trop longues à expliquer ici, donc me dire d'utiliser la commande mail _n'est pas une solution_).
J'imagine que tu n'as pas de commande sendmail non plus… En revanche, il serait peut-être pertinent d'utiliser netcat plutôt que telnet, dont l'interprétation de séquences de contrôle de terminal n'est pas franchement pertinente ici, n'est-ce pas ?
Sous les deux OS, la variable CORPS est strictement identique. Pourtant, dans la sortie d'expect, sous Linux, j'ai un r et sous NetBSD un rn d'où un saut de ligne supplémentaire qui me met ma somme md5 par terre.
Je ne sais pas si c'est lié, mais j'ai déjà eu des problèmes semblables en envoyant de façon plus « conventionnelle » un fichier texte en attachement, problème que j'avais réglé en gzippant ce fichier. Tout ce que je sais, c'est que pour transmettre un message en SMTP, on est censé mettre des rn. Lorsque tu soumets ton message avec des n simples, le serveur l'accepte en général, mais serait en droit de le refuser, et il n'est pas inimaginale qu'il remplace cela par des rn avant de le transmettre.
Bon, c'était bien ça. J'aurais au moins appris quelque chose. base64 sous Linux a une sortie binaire alors que sous NetBSD, sa sortie est ascii. Il faut donc le recompiler avec FORCE_BINARY_IO pour obtenir le résultat attendu.
Le 30 Jan 2013 15:48:29 GMT,
Tanguy Ortolo <tanguy@ortolo.eu> écrivait :
JKB, 2013-01-30 16:24+0100:
J'utilise dans un script expect pour envoyer un mail à un
utilisateur (je ne peux pas faire autre chose qu'un telnet sur le
port 587 pour des raisons trop longues à expliquer ici, donc me dire
d'utiliser la commande mail _n'est pas une solution_).
J'imagine que tu n'as pas de commande sendmail non plus…
En revanche, il serait peut-être pertinent d'utiliser netcat plutôt que
telnet, dont l'interprétation de séquences de contrôle de terminal n'est
pas franchement pertinente ici, n'est-ce pas ?
Sous les deux OS, la variable CORPS est strictement identique.
Pourtant, dans la sortie d'expect, sous Linux, j'ai un r et sous
NetBSD un rn d'où un saut de ligne supplémentaire qui me met ma
somme md5 par terre.
Je ne sais pas si c'est lié, mais j'ai déjà eu des problèmes semblables
en envoyant de façon plus « conventionnelle » un fichier texte en
attachement, problème que j'avais réglé en gzippant ce fichier. Tout ce
que je sais, c'est que pour transmettre un message en SMTP, on est
censé mettre des rn. Lorsque tu soumets ton message avec des n
simples, le serveur l'accepte en général, mais serait en droit de le
refuser, et il n'est pas inimaginale qu'il remplace cela par des rn
avant de le transmettre.
Bon, c'était bien ça. J'aurais au moins appris quelque chose. base64
sous Linux a une sortie binaire alors que sous NetBSD, sa sortie est
ascii. Il faut donc le recompiler avec FORCE_BINARY_IO pour obtenir
le résultat attendu.
Cordialement,
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Le 30 Jan 2013 15:48:29 GMT, Tanguy Ortolo écrivait :
JKB, 2013-01-30 16:24+0100:
J'utilise dans un script expect pour envoyer un mail à un utilisateur (je ne peux pas faire autre chose qu'un telnet sur le port 587 pour des raisons trop longues à expliquer ici, donc me dire d'utiliser la commande mail _n'est pas une solution_).
J'imagine que tu n'as pas de commande sendmail non plus… En revanche, il serait peut-être pertinent d'utiliser netcat plutôt que telnet, dont l'interprétation de séquences de contrôle de terminal n'est pas franchement pertinente ici, n'est-ce pas ?
Sous les deux OS, la variable CORPS est strictement identique. Pourtant, dans la sortie d'expect, sous Linux, j'ai un r et sous NetBSD un rn d'où un saut de ligne supplémentaire qui me met ma somme md5 par terre.
Je ne sais pas si c'est lié, mais j'ai déjà eu des problèmes semblables en envoyant de façon plus « conventionnelle » un fichier texte en attachement, problème que j'avais réglé en gzippant ce fichier. Tout ce que je sais, c'est que pour transmettre un message en SMTP, on est censé mettre des rn. Lorsque tu soumets ton message avec des n simples, le serveur l'accepte en général, mais serait en droit de le refuser, et il n'est pas inimaginale qu'il remplace cela par des rn avant de le transmettre.
Bon, c'était bien ça. J'aurais au moins appris quelque chose. base64 sous Linux a une sortie binaire alors que sous NetBSD, sa sortie est ascii. Il faut donc le recompiler avec FORCE_BINARY_IO pour obtenir le résultat attendu.
Bon, c'était bien ça. J'aurais au moins appris quelque chose. base64 sous Linux a une sortie binaire alors que sous NetBSD, sa sortie est ascii. Il faut donc le recompiler avec FORCE_BINARY_IO pour obtenir le résultat attendu.
Puisqu'il s'agit de données en Base64, ne serait-il pas plus simple de faire la somme de contrôle sur les données hors Base64 ?
-- . o . . . o Tanguy o o o
JKB, 2013-01-30 17:20+0100:
Bon, c'était bien ça. J'aurais au moins appris quelque chose. base64
sous Linux a une sortie binaire alors que sous NetBSD, sa sortie est
ascii. Il faut donc le recompiler avec FORCE_BINARY_IO pour obtenir
le résultat attendu.
Puisqu'il s'agit de données en Base64, ne serait-il pas plus simple de
faire la somme de contrôle sur les données hors Base64 ?
Bon, c'était bien ça. J'aurais au moins appris quelque chose. base64 sous Linux a une sortie binaire alors que sous NetBSD, sa sortie est ascii. Il faut donc le recompiler avec FORCE_BINARY_IO pour obtenir le résultat attendu.
Puisqu'il s'agit de données en Base64, ne serait-il pas plus simple de faire la somme de contrôle sur les données hors Base64 ?
-- . o . . . o Tanguy o o o
Tanguy Ortolo
JKB, 2013-01-30 16:54+0100:
J'ai un sendmail des deux côtés (Linux et NetBSD). Je vais creuser par là. Merci pour l'info...
D'une façon générale, il me semble que la commande sendmail est vraiment le standard pour envoyer des messages depuis une machine disposant d'un serveur d'envoi local. Les logiciels que je connais (Mutt, tin, PHP…) utilisent cela plutôt que d'ouvrir une connexion SMTP à localhost je crois.
-- . o . . . o Tanguy o o o
JKB, 2013-01-30 16:54+0100:
J'ai un sendmail des deux côtés (Linux et NetBSD). Je vais creuser
par là. Merci pour l'info...
D'une façon générale, il me semble que la commande sendmail est vraiment
le standard pour envoyer des messages depuis une machine disposant d'un
serveur d'envoi local. Les logiciels que je connais (Mutt, tin, PHP…)
utilisent cela plutôt que d'ouvrir une connexion SMTP à localhost je
crois.
J'ai un sendmail des deux côtés (Linux et NetBSD). Je vais creuser par là. Merci pour l'info...
D'une façon générale, il me semble que la commande sendmail est vraiment le standard pour envoyer des messages depuis une machine disposant d'un serveur d'envoi local. Les logiciels que je connais (Mutt, tin, PHP…) utilisent cela plutôt que d'ouvrir une connexion SMTP à localhost je crois.
-- . o . . . o Tanguy o o o
Alain Montfranc
JKB a formulé ce mercredi :
Bonjour à tous,
J'utilise dans un script expect pour envoyer un mail à un utilisateur (je ne peux pas faire autre chose qu'un telnet sur le port 587 pour des raisons trop longues à expliquer ici, donc me dire d'utiliser la commande mail _n'est pas une solution_).
man telnet ?
crlf If this is TRUE, then carriage returns will be sent as <CR><LF>. If this is FALSE, then car- riage returns will be send as <CR><NUL>. The initial value for this toggle is FALSE.
crmod Toggle carriage return mode. When this mode is enabled, most carriage return characters received from the remote host will be mapped into a carriage return followed by a line feed. This mode does not affect those characters typed by the user, only those received from the remote host. This mode is not very useful unless the remote host only sends carriage return, but never line feed. The initial value for this toggle is FALSE.
JKB a formulé ce mercredi :
Bonjour à tous,
J'utilise dans un script expect pour envoyer un mail à un
utilisateur (je ne peux pas faire autre chose qu'un telnet sur le
port 587 pour des raisons trop longues à expliquer ici, donc me dire
d'utiliser la commande mail _n'est pas une solution_).
man telnet ?
crlf If this is TRUE, then carriage returns
will be
sent as <CR><LF>. If this is FALSE, then
car-
riage returns will be send as <CR><NUL>.
The
initial value for this toggle is FALSE.
crmod Toggle carriage return mode. When this
mode is
enabled, most carriage return characters
received from the remote host will be
mapped
into a carriage return followed by a line
feed.
This mode does not affect those
characters typed
by the user, only those received from the
remote
host. This mode is not very useful
unless the
remote host only sends carriage return,
but
never line feed. The initial value for
this
toggle is FALSE.
J'utilise dans un script expect pour envoyer un mail à un utilisateur (je ne peux pas faire autre chose qu'un telnet sur le port 587 pour des raisons trop longues à expliquer ici, donc me dire d'utiliser la commande mail _n'est pas une solution_).
man telnet ?
crlf If this is TRUE, then carriage returns will be sent as <CR><LF>. If this is FALSE, then car- riage returns will be send as <CR><NUL>. The initial value for this toggle is FALSE.
crmod Toggle carriage return mode. When this mode is enabled, most carriage return characters received from the remote host will be mapped into a carriage return followed by a line feed. This mode does not affect those characters typed by the user, only those received from the remote host. This mode is not very useful unless the remote host only sends carriage return, but never line feed. The initial value for this toggle is FALSE.
JKB
Le 30 Jan 2013 16:55:58 GMT, Tanguy Ortolo écrivait :
JKB, 2013-01-30 17:20+0100:
Bon, c'était bien ça. J'aurais au moins appris quelque chose. base64 sous Linux a une sortie binaire alors que sous NetBSD, sa sortie est ascii. Il faut donc le recompiler avec FORCE_BINARY_IO pour obtenir le résultat attendu.
Puisqu'il s'agit de données en Base64, ne serait-il pas plus simple de faire la somme de contrôle sur les données hors Base64 ?
Non, ce n'est pas possible. Cette somme de hashage sert à valider un fragment de mail. Il y a déjà une somme pour le message entier.
Le 30 Jan 2013 16:55:58 GMT,
Tanguy Ortolo <tanguy@ortolo.eu> écrivait :
JKB, 2013-01-30 17:20+0100:
Bon, c'était bien ça. J'aurais au moins appris quelque chose. base64
sous Linux a une sortie binaire alors que sous NetBSD, sa sortie est
ascii. Il faut donc le recompiler avec FORCE_BINARY_IO pour obtenir
le résultat attendu.
Puisqu'il s'agit de données en Base64, ne serait-il pas plus simple de
faire la somme de contrôle sur les données hors Base64 ?
Non, ce n'est pas possible. Cette somme de hashage sert à valider un
fragment de mail. Il y a déjà une somme pour le message entier.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Le 30 Jan 2013 16:55:58 GMT, Tanguy Ortolo écrivait :
JKB, 2013-01-30 17:20+0100:
Bon, c'était bien ça. J'aurais au moins appris quelque chose. base64 sous Linux a une sortie binaire alors que sous NetBSD, sa sortie est ascii. Il faut donc le recompiler avec FORCE_BINARY_IO pour obtenir le résultat attendu.
Puisqu'il s'agit de données en Base64, ne serait-il pas plus simple de faire la somme de contrôle sur les données hors Base64 ?
Non, ce n'est pas possible. Cette somme de hashage sert à valider un fragment de mail. Il y a déjà une somme pour le message entier.
Le 30 Jan 2013 16:57:09 GMT, Tanguy Ortolo écrivait :
JKB, 2013-01-30 16:54+0100:
J'ai un sendmail des deux côtés (Linux et NetBSD). Je vais creuser par là. Merci pour l'info...
D'une façon générale, il me semble que la commande sendmail est vraiment le standard pour envoyer des messages depuis une machine disposant d'un serveur d'envoi local. Les logiciels que je connais (Mutt, tin, PHP…) utilisent cela plutôt que d'ouvrir une connexion SMTP à localhost je crois.
Oui, je sais. Mon cas est très spécifique puisque je bidouilleles en-têtes SMTP (je parle d'un serveur à un autre que je maîtrise pour une transmission de données un peu particulière). Utiliser la commande sendmail ne me permet pas toutes les bizarreries voulues ;-)
Le 30 Jan 2013 16:57:09 GMT,
Tanguy Ortolo <tanguy@ortolo.eu> écrivait :
JKB, 2013-01-30 16:54+0100:
J'ai un sendmail des deux côtés (Linux et NetBSD). Je vais creuser
par là. Merci pour l'info...
D'une façon générale, il me semble que la commande sendmail est vraiment
le standard pour envoyer des messages depuis une machine disposant d'un
serveur d'envoi local. Les logiciels que je connais (Mutt, tin, PHP…)
utilisent cela plutôt que d'ouvrir une connexion SMTP à localhost je
crois.
Oui, je sais. Mon cas est très spécifique puisque je bidouilleles
en-têtes SMTP (je parle d'un serveur à un autre que je maîtrise pour
une transmission de données un peu particulière). Utiliser la
commande sendmail ne me permet pas toutes les bizarreries voulues
;-)
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Le 30 Jan 2013 16:57:09 GMT, Tanguy Ortolo écrivait :
JKB, 2013-01-30 16:54+0100:
J'ai un sendmail des deux côtés (Linux et NetBSD). Je vais creuser par là. Merci pour l'info...
D'une façon générale, il me semble que la commande sendmail est vraiment le standard pour envoyer des messages depuis une machine disposant d'un serveur d'envoi local. Les logiciels que je connais (Mutt, tin, PHP…) utilisent cela plutôt que d'ouvrir une connexion SMTP à localhost je crois.
Oui, je sais. Mon cas est très spécifique puisque je bidouilleles en-têtes SMTP (je parle d'un serveur à un autre que je maîtrise pour une transmission de données un peu particulière). Utiliser la commande sendmail ne me permet pas toutes les bizarreries voulues ;-)
Le Wed, 30 Jan 2013 21:32:59 +0100, Alain Montfranc écrivait :
JKB a formulé ce mercredi :
Bonjour à tous,
J'utilise dans un script expect pour envoyer un mail à un utilisateur (je ne peux pas faire autre chose qu'un telnet sur le port 587 pour des raisons trop longues à expliquer ici, donc me dire d'utiliser la commande mail _n'est pas une solution_).
man telnet ?
crlf If this is TRUE, then carriage returns will be sent as <CR><LF>. If this is FALSE, then car- riage returns will be send as <CR><NUL>. The initial value for this toggle is FALSE.
crmod Toggle carriage return mode. When this mode is enabled, most carriage return characters received from the remote host will be mapped into a carriage return followed by a line feed. This mode does not affect those characters typed by the user, only those received from the remote host. This mode is not very useful unless the remote host only sends carriage return, but never line feed. The initial value for this toggle is FALSE.
Telnet n'est pas le fautif dans cette histoire, mais base64. Voir mon message plus haut.
Le Wed, 30 Jan 2013 21:32:59 +0100,
Alain Montfranc <mort@aux.spammeurs> écrivait :
JKB a formulé ce mercredi :
Bonjour à tous,
J'utilise dans un script expect pour envoyer un mail à un
utilisateur (je ne peux pas faire autre chose qu'un telnet sur le
port 587 pour des raisons trop longues à expliquer ici, donc me dire
d'utiliser la commande mail _n'est pas une solution_).
man telnet ?
crlf If this is TRUE, then carriage returns
will be
sent as <CR><LF>. If this is FALSE, then
car-
riage returns will be send as <CR><NUL>.
The
initial value for this toggle is FALSE.
crmod Toggle carriage return mode. When this
mode is
enabled, most carriage return characters
received from the remote host will be
mapped
into a carriage return followed by a line
feed.
This mode does not affect those
characters typed
by the user, only those received from the
remote
host. This mode is not very useful
unless the
remote host only sends carriage return,
but
never line feed. The initial value for
this
toggle is FALSE.
Telnet n'est pas le fautif dans cette histoire, mais base64. Voir
mon message plus haut.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Le Wed, 30 Jan 2013 21:32:59 +0100, Alain Montfranc écrivait :
JKB a formulé ce mercredi :
Bonjour à tous,
J'utilise dans un script expect pour envoyer un mail à un utilisateur (je ne peux pas faire autre chose qu'un telnet sur le port 587 pour des raisons trop longues à expliquer ici, donc me dire d'utiliser la commande mail _n'est pas une solution_).
man telnet ?
crlf If this is TRUE, then carriage returns will be sent as <CR><LF>. If this is FALSE, then car- riage returns will be send as <CR><NUL>. The initial value for this toggle is FALSE.
crmod Toggle carriage return mode. When this mode is enabled, most carriage return characters received from the remote host will be mapped into a carriage return followed by a line feed. This mode does not affect those characters typed by the user, only those received from the remote host. This mode is not very useful unless the remote host only sends carriage return, but never line feed. The initial value for this toggle is FALSE.
Telnet n'est pas le fautif dans cette histoire, mais base64. Voir mon message plus haut.
ne peux-tu pas utiliser des entêtes mimes standard ? par ex. : MIME-Version: 1.0 Content-Transfer-Encoding: plain Content-Type: text/html; charset="ISO-8859-1" pour du HTML, etc. ça peut aider le voyage entre les passerelle SMTP .
Cordialement,
Cyrille Lefevre. -- mailto:Cyrille.Lefevre-news% supprimer "%nospam% et ".invalid" pour me repondre. remove "%nospam" and ".invalid" to answer me.
ne peux-tu pas utiliser des entêtes mimes standard ?
par ex. :
MIME-Version: 1.0
Content-Transfer-Encoding: plain
Content-Type: text/html; charset="ISO-8859-1"
pour du HTML, etc. ça peut aider le voyage entre les passerelle SMTP .
Cordialement,
Cyrille Lefevre.
--
mailto:Cyrille.Lefevre-news%nospam@laposte.net.invalid
supprimer "%nospam% et ".invalid" pour me repondre.
remove "%nospam" and ".invalid" to answer me.
ne peux-tu pas utiliser des entêtes mimes standard ? par ex. : MIME-Version: 1.0 Content-Transfer-Encoding: plain Content-Type: text/html; charset="ISO-8859-1" pour du HTML, etc. ça peut aider le voyage entre les passerelle SMTP .
Cordialement,
Cyrille Lefevre. -- mailto:Cyrille.Lefevre-news% supprimer "%nospam% et ".invalid" pour me repondre. remove "%nospam" and ".invalid" to answer me.
