[expect] Fonctionnement différent entre Linux et NetBSD

12 réponses
Avatar
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_).

Sur un serveur Linux, j'avais écrit :

expect << EOS 1> /dev/null 2>&1
set timeout 10
spawn telnet localhost 587
expect \
{
"220 *" { puts Nice... }
timeout { puts error; exit }
}
send -- "EHLO localhost\r"
expect \
{
"250 *" { puts Nice... }
timeout { puts error; exit }
}
send "MAIL FROM:<$EXPEDITEUR>\r"
expect \
{
"250 *" { puts Nice... }
timeout { puts error; exit }
}
send "RCPT TO:<$DESTINATAIRE>\r"
expect \
{
"250 *" { puts Nice... }
timeout { puts timeout; exit }
}
send "DATA\r"
expect \
{
"354 *" { puts Nice... }
timeout { puts error; exit }
}
send "X-content-type: $FILTRES\r"
send "X-sequence-id: $HASH\r"
send "X-sequence: $PAQUET\r"
send "X-last: $2\r"
send "X-hash: $(md5sum $1 | cut -f1 -d' ')\n"
send "X-in-reply-to: $IN_REPLY_TO\r"
send "X-expiration: $EXPIRATION\r"
send "Subject: $SUJET\r\r"
send "$CORPS"
send "\r.\r"
expect \
{
"250 *" { puts Nice... }
timeout { puts timeout; exit }
}
send -- "QUIT"

Ç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

10 réponses

1 2
Avatar
Tanguy Ortolo
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.

--
. o .
. . o Tanguy
o o o
Avatar
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...

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
Avatar
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.



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
Avatar
Tanguy Ortolo
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 ?

--
. o .
. . o Tanguy
o o o
Avatar
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
Avatar
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.
Avatar
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.

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
Avatar
JKB
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
;-)

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
Avatar
JKB
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.

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
Avatar
Cyrille Lefevre
Le 30/01/2013 21:38, JKB a écrit :

Oui, je sais. Mon cas est très spécifique puisque je bidouil leles
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 l a
commande sendmail ne me permet pas toutes les bizarreries voulues
;-)




Bonjour,

c'est quoi le pb avec ce qui suit ?
l'option -t permet de faire ce que l'on veux avec les entêtes, non ?

sendmail -t << EOF
From: <$EXPEDITEUR>
To: <$DESTINATAIRE>
Subject: $SUJET
X-content-type: $FILTRES
X-sequence-id: $HASH
X-sequence: $PAQUET
X-last: $2
X-hash: $(md5sum $1 | cut -f1 -d' ')
X-in-reply-to: $IN_REPLY_TO
X-expiration: $EXPIRATION

$CORPS
EOF

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.
1 2