Forum Linux.debian/ubuntu utiliser commande IMAP dans un script bash

Posté par  .
Étiquettes : aucune
0
4
oct.
2011

Sur mon serveur j'ai postfix-dovecot-squirrelmail
tout est fonctionnel

Dans un de mes script bash sur ce serveur j'ai besoin de récuperer les mails sur le serveur en IMAP.

ce que je veux automatiser dans un script bash sont les commandes suivantes:

telnet localhost 143
1 login toto password_toto
2 select inbox
3 logout

En mode graphique ca correspond à me connecter sur squirrelmail en donant identifiant et mot de passe, cliquer sur recevoir mails puis me déconnecter.

Le problème c'est qu'en faisant un telnet ca ouvre un prompt donc pas possible dans un script bash.

Si quelqu'un a une idée...
Merci d'avance

  • # expect

    Posté par  . Évalué à 3.

    Tout est dans le titre !

    Ptit exemple : http://osix.net/modules/article/?id=30

    • [^] # Re: expect

      Posté par  . Évalué à 2.

      Espèce de vil Spammeur !!!!!!!!!!!!! :)

      N'oublie pas de tester les codes retour envoyés par le serveur.

      Ah, autre chose : le mot de passe apparaitra en clair dans ton script : d'un point de vue sécurité ce n'est peu-être pas top : fais attention donc au compte mail que tu vas utiliser : ce sera un compte qui pourra potentiellement être corrompu.

    • [^] # Re: expect

      Posté par  (site web personnel) . Évalué à 2.

      Enfin, quitte à mettre du expect, autant tout faire dans un script Perl.

      • libmail-imapclient-perl - Perl library for manipulating IMAP mail stores
      • libmail-imaptalk-perl - IMAP client interface with lots of features
      • libnet-imap-client-perl - Perl module to communicate with IMAP servers
      • libnet-imap-simple-perl - Perl module to manage an IMAP account
      • libnet-imap-simple-ssl-perl - Subclass of Net::IMAP::Simple with SSL support
      • libnet-imap-perl - A client interface to IMAP (Internet Message Access Protocol)
  • # Respect

    Posté par  . Évalué à 0.

    Merci pour le piston,
    j'ai résolu mon problème grace au script suivant (je fait appel a ce script dans un script parent en bash):

    '#!/usr/bin/expect -f

    set server localhost
    set port 143
    set user {toto}
    set pass {toto_password}

    '# conexion IMAP via telnet
    spawn telnet $server $port

    '# login a dovecot
    send "1 login $user $pass\r"
    expect "1 OK"

    '# reception des mails
    send "2 select inbox\r"
    expect "2 OK"

    '# deconexion
    send "3 logout"

    Le password apparait en clair dans le script mais comme c'est pour une connexion sur localhost c'est pas trop risqué à priori.
    J'ai pas trop compris à quoi servent les commandes "expect" mais ca marche comme ca.
    Encore merci pour l'aide :)

    • [^] # Re: Respect

      Posté par  . Évalué à 1.

      J'ai pas trop compris à quoi servent les commandes "expect"

      Elles attendent que la chaîne de caractères indiquée apparaisse.

  • # Essaye nc, expect c'est overkill !

    Posté par  (site web personnel, Mastodon) . Évalué à 0.

    Tu peut utiliser netcat à la place de telnet même si ya quand même moyen avec telnet.

    nc localhost 143 <<IMAP
    1 login toto password_toto
    2 select inbox
    3 logout
    
    
    IMAP
    
    

    On ne peut pas mettre d'array dans le string...

    • [^] # Re: Essaye /dev/tcp, nc c'est overkill !

      Posté par  . Évalué à 1.

      A ce moment là, autant utiliser /dev/tcp

      echo -ne 'login toto password_toto\nselect inbox\nlogout\n' > /dev/tcp/localhost/143
      
      
      • [^] # Re: Essaye /dev/tcp, nc c'est overkill !

        Posté par  (site web personnel, Mastodon) . Évalué à -2.

        C'est pas standard comme truc et d'ailleurs désactivé sous Debian et dérivés.

        Il faut recompiler son bash avec --enable-net-redirections ( de mémoire )

        On ne peut pas mettre d'array dans le string...

        • [^] # Re: Essaye /dev/tcp, nc c'est overkill !

          Posté par  . Évalué à 2.

          désactivé sous Debian et dérivés

          J'utilise ce genre de chose sur des Debian depuis pas mal de temps sans problème dans des scripts cron plusieurs fois par jour. Y compris la version actuelle de Debian.

  • # en claire et sans additifs

    Posté par  . Évalué à -1.

    Voila une autre solution avec aucune dépendance :D

    typeset USER=$(grep prod ~/.netrc|cut -d " " -f4)
    typeset PWD=$(grep prod ~/.netrc|cut -d " " -f6)
    typeset cmd="ls"
    typeset cmd1="echo toto"

    (echo open ma_machine ;
    sleep 1 ;
    echo ${USER} ;
    sleep 1 ;
    echo ${PWD} ;
    sleep 2 ;
    echo ;
    echo ${cmd} ;
    sleep 1 ;
    echo ;
    echo ${cmd1} ;
    echo ;
    echo exit ) | telnet

    Et là tu peux même en trafiquant le contenu de ton .netrc faire une connexion "batch" et une connexion user.
    Le seul véritable intérêt c'est que ça marche avec tout les shell et tout les unix.

    • [^] # Re: en claire et sans additifs

      Posté par  (site web personnel, Mastodon) . Évalué à -1.

      telnet n'est pas installé de base partout.

      En tout cas pas sous archlinux...

      On ne peut pas mettre d'array dans le string...

    • [^] # Re: en claire et sans additifs

      Posté par  . Évalué à 2.

      L'inconvénient de cette méthode est que tu envoies tout à Telnet même si tu n'as pas un code de retour OK ...

      • [^] # Re: en claire et sans additifs

        Posté par  . Évalué à 1.

        Tu peux tester ta commande avant de passer à la suivante.

        Moi j'utilise cette méthode pour rafraichir des traitements entre 2 machine ou on ne m'a autorisé que telnet.

        ça marche très très bien. En plus cette méthode répond au besoin exprimé (ce qui est le plus important), sans additif (exemple expect que l'on a pas forcément sur sa machine, ni disponible à l'installation pour une raison quelconque)

  • # Fetchmail ?

    Posté par  (site web personnel) . Évalué à 0.

    Fetchmail permet de récupérer dans une BAL locale des mails distants, est-ce que cela répondrait à ton besoin ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.