[expect] Fonctionnement différent entre Linux et NetBSD
Le
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"
expect
{
"250 *" { puts Nice }
timeout { puts error; exit }
}
send "MAIL FROM:<$EXPEDITEUR>"
expect
{
"250 *" { puts Nice }
timeout { puts error; exit }
}
send "RCPT TO:<$DESTINATAIRE>"
expect
{
"250 *" { puts Nice }
timeout { puts timeout; exit }
}
send "DATA"
expect
{
"354 *" { puts Nice }
timeout { puts error; exit }
}
send "X-content-type: $FILTRES"
send "X-sequence-id: $HASH"
send "X-sequence: $PAQUET"
send "X-last: $2"
send "X-hash: $(md5sum $1 | cut -f1 -d' ')"
send "X-in-reply-to: $IN_REPLY_TO"
send "X-expiration: $EXPIRATION"
send "Subject: $SUJET"
send "$CORPS"
send "."
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 et sous
NetBSD un 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_).
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"
expect
{
"250 *" { puts Nice }
timeout { puts error; exit }
}
send "MAIL FROM:<$EXPEDITEUR>"
expect
{
"250 *" { puts Nice }
timeout { puts error; exit }
}
send "RCPT TO:<$DESTINATAIRE>"
expect
{
"250 *" { puts Nice }
timeout { puts timeout; exit }
}
send "DATA"
expect
{
"354 *" { puts Nice }
timeout { puts error; exit }
}
send "X-content-type: $FILTRES"
send "X-sequence-id: $HASH"
send "X-sequence: $PAQUET"
send "X-last: $2"
send "X-hash: $(md5sum $1 | cut -f1 -d' ')"
send "X-in-reply-to: $IN_REPLY_TO"
send "X-expiration: $EXPIRATION"
send "Subject: $SUJET"
send "$CORPS"
send "."
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 et sous
NetBSD un 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'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 ?
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
Tanguy Ortolo
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
Tanguy Ortolo
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
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
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
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.
Tanguy Ortolo
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
Tanguy Ortolo
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
Alain Montfranc
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
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.