UUCP à travers SSH: la meilleure configuration mail

Posté par  (site web personnel, Mastodon) . Modéré par Fabien Penso.
Étiquettes :
0
8
avr.
2001
Doc
Voici un petit document qui vous explique comment configurer UUCP à travers une connexion SSH. C'est la configuration idéale pour le mail, que ce soit pour quelqu'un qui se connecte à travers un modem, que quelqu'un qui se connecte en ADSL/Câble. Si vous avez un portable et que vous êtes nomade, c'est *la configuration* que vous devez utiliser. Cependant il vous faudra avoir la main sur votre serveur de mail, si ce n'est pas le cas vous pouvez toujours utiliser UUCP sans SSH en prenant un fournisseur d'accès tel que FRMUG ou FDN.
Commentaires bienvenues.

UUCP+SSH: La manière idéale de récupérer vos mails!



Fabien Penso
mailto:penso@linuxfr.org

07 Avril 2001


Un bref article sur la configuration d'une connexion UUCP à
travers SSH (sur IP) pour le rapatriement de ses mails chez soi.

1. Introduction



Voici un bref document qui explique comment utiliser UUCP à travers
SSH sur IP.

Je pars du principe que vous avez la main sur le serveur, et que les
machines sont installées sous Debian (Woody) avec les packages UUCP,
openssh et postfix. Cependant il ne devrait pas être difficile de le
faire marcher sur d'autres type de machines.

2. Avantages et inconvénients par rapport à d'autres systèmes



Les avantages de ce type de connexion sont multiples. En plus
d'être très efficace pour les personnes qui se connectent par modem,
il est aussi très intéressant pour ceux qui ont la chance, comme moi,
d'utiliser une connexion permanente type ADSL ou Câble.

En effet, beaucoup se posent la question sur la manière la plus rapide
et pratique pour récupérer leurs mails à travers une connexion cryptée
(POP ne l'est pas) tout en ayant ses mails sur sa machine (IMAP laisse
les mails sur le serveur). Il n'existe que peu de solutions
performantes, UUCP m'a semblé la meilleure.

L'autre solution qui parait possible est l'installation du logiciel
postfix-tls (encryption et authentification) cependant il faudra alors
que les deux postfix soient configurés avec l'extension tls. On pourra
alors faire en sorte que lorsque le serveur reçoit un mail pour
user@domain.fr il renvoie automatiquement sur user@posteclient.domain.fr
(en partant du principe que votre machine est connectée en permanence,
et dans le cas ou elle a une IP adressée dynamiquement qu'elle utilise
un service type dyndns pour avoir un domaine fixe). Cependant dans le
cas ou votre machine ne serait pas accessible pendant plus de 5 jours
(vacances, problème de connexion, etc) les mails seraient alors
renvoyés à l'expediteur avec un message d'erreur. Fâcheux ...

L'avantage de la solution UUCP est qu'elle ne vous oblige pas à avoir une
connexion permanente, ni un domaine associé à votre machine, ce qui
évite l'utilisation des services de DNS dynamiques. Cependant je
conseille pour votre confort de les utiliser quand même si vous êtes
câblé :-)

Il reste cependant un inconvénient, vous ne recevrez pas vos mails en
temps réel dès leur arrivé sur le serveur de mail, mais seulement quand
vous, poste client, lancerez votre commande UUCP. Chez moi mon crontab
est configuré pour le lancer toutes les 10 minutes, ce qui est largement
suffisant.

Résumons donc quelques avantages/inconvénients d'un système UUCP+SSH:



  1. Vous récupérez vos mails à travers une connexion cryptée

  2. Vous avez la certitude du poste client (grâce aux clefs
    RSA)

  3. Vous pouvez récupérer tous les mails pour votre machine,
    et avez donc la possibilité d'héberger plusieurs comptes (papa, maman,
    La femme, le chien, etc) dont vous recevez les mails en une seule
    fois.

  4. Vous pouvez ne pas être là pendant un long moment, les
    mails seront mis de côté pour vous sur le serveur.

  5. Vous pouvez taper vos mails sur le poste client, et ne
    vous connecter que plusieurs semaines après pour les envoyer,
    vous n'aurez pas de message d'erreur de votre postfix local.

  6. Un temps équivalent au maximum à l'intervalle de temps que
    vous avez configuré dans crontab est nécessaire pour que vous
    récupériez vos mails.


Bref, que des avantages ! :-)


3. Explication sur l'architecture réseau de l'exemple



Voici des détails sur l'architecture réseau utilisée dans l'exemple que
j'utilise dans cet article.

Nous avons deux machines:


  1. Le serveur connecté en permanence sur Internet. On l'appellera
    « serveur » et on considère que son domaine est machin.fr. Son nom
    complet est donc serveur.machin.fr. Cette machine tourne sous Debian,
    avec les packages UUCP, postfix, et openssh installés.

  2. La station de travail qui se trouve chez vous. On l'appellera
    « station », qui est le résultat de la commande hostname. Cette
    machine peut être connectée en permanence (Câble, ADSL) ou bien être
    derrière une connexion PPP par l'intermédiaire d'un fournisseur
    d'accès.



4. Configuration du client



Je considère donc que vous avez installé UUCP, postfix, openssh et que
postfix accepte les mails pour @station.machin.fr (attention: ceci est
important sinon le système bouclera!).

Éditez le fichier /etc/uucp/sys et ajoutez à la fin: 




              system serveur (serveur est donc à remplacer par le nom de votre machine serveur)


              alias serveur-ssh


              call-login *


              call-password *


              time any


              address serveur.machin.fr


              port SSH


              protocol t


              remote-send /


              remote-receive ~



Éditez le fichier /etc/uucp/port et ajoutez à la fin: 







              port SSH


              type pipe


              command /usr/bin/ssh -C -x -o batchmode=yes uucp@serveur.machin.fr



Éditez le fichier /etc/uucp/call et ajoutez à la fin: 




              serveur   votrelogin   votremotdepasse



Vous pouvez utiliser ce que vous voulez à la place de votrelogin et
votremotdepasse sachant qu'il suffira de mettre les mêmes du côté du
serveur, tout simplement.

Passez en utilisateur uucp (su - uucp) et lancez ssh-keygen. On vous
demandera un mot de passe, n'en tapez pas ! Il n'y a pas de problème de
sécurité si votre utilisateur UUCP n'a pas d'accès par mot de passe dans
/etc/passwd. Cette étape permet de générer une clef RSA qui se trouve
dans uucp/.ssh/identity.pub, nous en aurons besoin plus tard.



5. Configuration du serveur



Je considère que vous avez installé UUCP, postfix et openssh.

Éditez le fichier /etc/uucp/sys et configurez de la manière
suivante: 




            protocol gvG


            protocol-parameter G packet-size 1024


            protocol-parameter G short-packets


            


            # Client 1


            system station (station est donc à remplacer par le nom du client)


            time any


            port TCP


            protocol t


            remote-send ~


            remote-receive /





            # ... Autre clients (mêmes lignes)


Éditez le fichier /etc/uucp/passwd et rajoutez à la fin: 




            votrelogin votremotdepasse


Éditez le fichier /etc/postfix/transport et rajoutez: 




            station.machin.fr uucp:station


Éditez /etc/aliases et rajoutez: 




            votrelogin: votrelogin@station.machin.fr


Lancez postmap /etc/postfix/transport, postalias
/etc/aliases et relancez postfix. Désormais les mails qui sont
envoyés à votrelogin@machin.fr devrait être renvoyés à
votrelogin@station.machin.fr et mis dans le spool UUCP pour la machine
station dans /var/spool/uucp/station/ (voir
/var/log/mail.log). Si ce n'est pas le cas, alors quelque chose
ne va pas dans votre configuration postfix.


Ensuite allez dans /var/spool/uucp/ et créez un répertoire .ssh
puis un fichier authorized_keys (le répertoire et le fichier doivent
n'être en lecture que pour l'utilisateur uucp. chmod -R og-rxw .ssh
devrait faire l'affaire).

Dans le fichier authorized_keys, rajoutez la clef RSA de votre poste
client précédée de command="/usr/sbin/uucico -D -l", ce qui devrait
donner: 





                command="/usr/sbin/uucico -D -l" 1024 35  12006592125270333...


Attention, ça doit être sur une seule ligne !


6. On termine...



A partir de votre poste client, lancez la commande ssh
uucp@serveur.machin.fr -v et répondez oui à la demande de sauvegarde
de la clef RSA du serveur. Vous devrez ensuite avoir le prompt UUCP, si
vous ne l'avez pas, quelque chose ne va pas.

En tant qu'utilisateur uucp, lancez /usr/sbin/uucico -f
-sserver et vous devriez voir des mails arriver dans vos logs UUCP.

Si ça fonctionne alors vous avez gagné ! Mettez "default_transport =
uucp" dans /etc/postfix/main.cf sur la station de travail pour que les
mails sortants passent aussi par UUCP, et rajoutez l'appel à uucico
dans le cron de l'utilisateur uucp avec: 




       0-50/10 *       *       *       *       /usr/sbin/uucico -f -sserveur

Aller plus loin

  • # fetchmail par tunnel ssh ca marche aussi

    Posté par  . Évalué à 0.

    man fetchmail

    • [^] # Re: fetchmail par tunnel ssh ca marche aussi

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

      Rien à voir. UUCP permet la reception et l'envoi des mails. Il permet de plus de récupérer les news dans le même temps.
      De plus fetchmail ne permet la récupération que d'un seul compte, alors que UUCP permet de récupérer l'intégralité des adresses emails pour une machine associée.

      De plus, dans le cas d'une connexion asynchrone (portable), lorsque tu tapes tes mails, ton serveur de mail local générera une erreur car il n'arrive pas à effectuer une résolution de nom. Et si tu n'es pas connecté sous 4 jours, ton mail te reviendra en général dans la tête.

      • [^] # Re: fetchmail par tunnel ssh ca marche aussi

        Posté par  . Évalué à 0.

        > fetchmail ne permet la récupération que d'un seul compte

        fetchmail(1) en charge 8 chez moi. man 5 fetchmailrc.

        • [^] # Re: fetchmail par tunnel ssh ca marche aussi

          Posté par  . Évalué à 0.

          Rien à voir, le protocol POP ne permet de récupérer que les mails associés à un compte, celui que tu as. Evidemment fetchmail peut récupérer 100 comptes si tu en as autant, mais il faut que fetchmail check manuellement pour tous ces comptes, un par un.
          Pour UUCP comme le transfert de mail se fait de machine à machine, tu récupères tous tes mails ET et tes news en une seule fois. De plus UUCP met de côté tous les mails pour ta machine du côté serveur, ils sont là et ils attendent pour toi.

          Bien plus performant que POP qui est une merde comparé à UUCP. Utilises les deux et tu comprendras de quoi je parle...

      • [^] # Re: fetchmail par tunnel ssh ca marche aussi

        Posté par  . Évalué à 1.

        Enfin, IMAP peut être configuré pour ne pas laisser les méls sur le serveur et POP tourne très bien avec sslwrap.

        Mais UUCP est bien intéressant. Le problème est plutôt pour tous ceux qui utilisent des FAIs normaux et donc n'ont pas la possibilité de changer les serveurs SMTP distants.

        Pour ma part, j'ai un simple exim sur mon portable et je n'ai pas d'Internet chez moi. Je tapes mes méls tranquillement chez moi sans messages d'erreur jusqu'à ce que je retourne au bureau pour les envoyer. (Le délai des messages d'erreurs ça se configure :))

        Si c'est pour faire ton UUCP toutes les 10 minutes aussi je ne vois pas trop pourquoi il y a tant d'avantages. Pour récuperer usenet en même temps c'est peut-être pas mal mais je trouve que Fabien est allé un peu loin dans son éloge d'UUCP.

        "There's More Than One Way To Do It" comme on dit.

  • # Que demande le peuple...

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

    Depuis le temps que j'attends cette configuration :)

    je matte ca dés que possible :)

  • # Et si j'ai pas de Debian?

    Posté par  . Évalué à 0.

    Autrement dit, ca donnerait quoi la meme chose pour une distrib Linux quelconque?

    • [^] # Re: Et si j'ai pas de Debian?

      Posté par  . Évalué à 1.

      Pour les autres UNIX (y'a pas que Linux) c'est équivalent. Il faut juste installer les paquets nécessaires (postfix, uucp, cron...), et adapter l'emplacement des fichiers de conf à ton système.

    • [^] # Re: Et si j'ai pas de Debian?

      Posté par  . Évalué à 0.

      Aucun pb. Il y a un doc sur
      http:///www.linuxfr-france.org.invalid(...)
      qui explique l'istall d'uucp de facon suffisamment generique pour que tu puisses l'installer sur n'importe quelle distrib linux ou BSD :)
      J'ai meme installe des clients uucp sur des machine windows voire ms-dos. voir les ref (url) dans le doc en ligne sur linux-france (chapitre: "UUCP sur d'autres plateformes"). Le serveur sur lequel se connectent ces machines tourne actuellement sur Debian et tournait il y a un an a peine sur une Slackware 3.3 ! ;-)

      AmicaLinuXement
      Denis BRAUSSEN

  • # IBM Public License et consorts, le truc de la linuxexpo

    Posté par  . Évalué à 0.

    >Je considère que vous avez installé UUCP, postfix et openssh.

    Pourquoi oublier de rappeler que postfix est sous la licence IBM Public License ? Donc à banir !!

    http://www.gnu.org/philosophy/license-list.html#GPLIncompatibleLice(...)

    IBM Public License, Version 1.0
    This is a free software license but it is incompatible with the GPL.

    The IBM Public License is incompatible with the GPL because it has various specific requirements that are not in the GPL.

    For example, it requires certain patent licenses be given that the GPL does not require. (We don't think those patent license requirements are
    inherently a bad idea, but nonetheless they are incompatible with the GNU GPL.)

    Donc ce tutoriel doit être remanier.
    Est-ce que Exim peut être une solution ?

    philou

    • [^] # Re: IBM Public License et consorts, le truc de la linuxexpo

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

      1. Le document est tout à fait appliquable à n'importe quel mailer, cependant pour ma part j'utilise postfix. Si tu configures Exim pour utiliser UUCP en émission côté client, et côté serveur que tu le configures pour t'envoyer les mails, ca marchera parfaitement.

      2. La licence de Postfix n'est effectivement pas GPL. Mais je sais une chose, Debian considère cette licence libre, c'est tout ce que j'ai besoin de savoir pour l'utiliser.

      • [^] # Re: IBM Public License et consorts, le truc de la linuxexpo

        Posté par  . Évalué à 0.

        1. Précision donc judicieuse : valable pour l'ensemble des MTA. Même si pour certains c'est une évidence, cette précision permet, aussi, de calmer les ardeurs (avec un petit mot pour Exim, par exemple :-) ).

        2. Chacun sa source d'inspiration ...

        philou

    • [^] # Re: IBM Public License et consorts, le truc de la linuxexpo

      Posté par  . Évalué à 1.

      Pourquoi oublier de rappeler que postfix est sous la licence IBM Public License ? Donc à banir !!

      Relis toi-même le document que tu cites, ça commence par : "This is a free software licence".
      Note de plus que même pour une licence comme l'Apache Licence, qu'il déconseille pour les programmes qu'on écrit (ce qui n'est pas le cas pour l'IBM public licence), il indique qu'il n'y a pas de problème à utiliser les logiciels sous cette licence.

      L'idéal serait peut-être que tout soit GPL, mais du moment que c'est libre, c'est déjà très bien. À moins que tu n'aies l'intention de développer une super-extension à Postfix, l'incompatibilité avec la licence GPL n'est pas un soucis majeur...

      Sinon, commence par bien éplucher la distrib que tu utilises : il faut absolument que tu vires tout-de-suite tout ce qu'il n'est pas sous licence GPL : tous les logiciels sous licence BSD, Apache Licence, Netscape Public Licence, OpenLDAP licence, Qt Public Licence, voire même X11...
      Quand tu auras fini, reviens soutenir ton opinion ici s'il te reste assez de logiciels pour y arriver...

      Autre solution : prends ton calmant, ça ira mieux après...

      « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

      • [^] # Re: IBM Public License et consorts, le truc de la linuxexpo

        Posté par  . Évalué à 0.

        D'une part, le mot 'incompatible' t'as échapé.

        D'autre part, quand une solution _viable_ en GPL ou compatible (note la précision, ici, necessaire), je pense que celle-ci doit être mentionée en priorité. C'est le cas avec Exim.

        philou

        ps: j'aime bien ton humour.

        • [^] # Re: IBM Public License et consorts, le truc de la linuxexpo

          Posté par  . Évalué à 1.

          D'une part, le mot 'incompatible' t'as échapé.

          Meuh non, j'ai même écrit : À moins que tu n'aies l'intention de développer une super-extension à Postfix, l'incompatibilité avec la licence GPL n'est pas un soucis majeur...

          D'autre part, quand une solution _viable_ en GPL ou compatible (note la précision, ici, necessaire), je pense que celle-ci doit être mentionée en priorité.

          Oui, enfin Fabien prend le temps de faire un article décrivant ce qu'il utilise, c'est déjà sympa. Il n'a pas forcément le temps d'installer autre chose rien que pour tester.

          C'est le cas avec Exim.

          D'un autre côté, Exim, c'est un truc tout monolithique, comme sendmail (et sûrement setuid root aussi). Postfix, c'est un ensemble de petits démons spécialisés chargés chacun d'une tâche, tournant avec les droits minimum et communiquant entre eux. Non seulement c'est plus performant, mais ça limite aussi au maximum les possibilités de faille, un "root exploit" étant impossible.
          Par les temps qui courent, avoir un serveur bien sûr qu'on peut laisser tourner sans se poser de questions, c'est apréciable...
          Ça laisse encore largement de quoi s'occuper avec les serveurs FTP, DNS, RPC, les diverses cochonneries setuid root qui constellent les distributions, et même le noyau Linux...

          « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

          • [^] # Re: IBM Public License et consorts, le truc de la linuxexpo

            Posté par  . Évalué à 1.

            « Meuh non, j'ai même écrit : À moins que tu n'aies l'intention de développer une super-extension à Postfix, l'incompatibilité avec la licence GPL n'est pas un soucis majeur... »

            On peut effectivement ne pas observer plus loin que le bout de son nez et considérer que ce qu'il dans l'immédiat ne nous gene pas personnellement n'est pas d'importance.

            « Oui, enfin Fabien prend le temps de faire un article décrivant ce qu'il utilise, c'est déjà sympa. Il n'a pas forcément le temps d'installer autre chose rien que pour tester. »

            C'est très sympa de la part de Fabien d'avoir fait cet article. Il ne me semble pas que la critique portait sur cela.

            « D'un autre côté, Exim, c'est un truc tout monolithique, comme sendmail (et sûrement setuid root aussi). Postfix, c'est un ensemble de petits démons spécialisés chargés chacun d'une tâche, tournant avec les droits minimum et communiquant entre eux. Non seulement c'est plus performant, mais ça limite aussi au maximum les possibilités de faille, un "root exploit" étant impossible.
            Par les temps qui courent, avoir un serveur bien sûr qu'on peut laisser tourner sans se poser de questions, c'est apréciable...
            Ça laisse encore largement de quoi s'occuper avec les serveurs FTP, DNS, RPC, les diverses cochonneries setuid »

            Non. Soyons sérieux. On ne fait pas reposer de raisonnement solide sur du « surement setuid root aussi ».

            Je pense que ce qui suit suffit :

            [root@valkyrie root]# ps eaux | grep exim
            mail 4290 0.0 6.8 2696 964 ? S 17:45 0:00 /usr/bin/exim -bd
            root 4296 0.0 4.7 1808 664 pts/0 S 17:45 0:00 grep exim HOSTNAM

    • [^] # Re: IBM Public License et consorts, le truc de la linuxexpo

      Posté par  . Évalué à 1.

      y'a des extrémistes de la license GPL ici ?

    • [^] # Re: IBM Public License et consorts, le truc de la linuxexpo

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

      Tout dépend en fait de ton interprétation du besoin de compatibilité de licence. Actuellement, l'interprétation communément admise de la GPL (à part par les extremes intégristes, plus extremes que RMS) se limite à un lien fort entre deux portions de code : librairies statiques/dynamique, ou par exécution d'un programme externe très dépendant du code GPL.

      Donc, le fait qu'un logiciel soit sous une license libre incompatible avec la GPL ne doit pas t'empêcher d'utiliser ce programme. Par contre, cela t'empêche d'aller y piocher du code pour [l'intégrer dans/le lier à] un programme GPL.

      Voir la FAQ sur la GPL. Notamment : http://www.gnu.org/licenses/gpl-faq.fr.html#GPLPluginsInNF(...)


      Pour un autre débat sur le même thème :
      http://linuxfr.org/2002/08/29/9421.html(...)
      Et aussi : http://www.advogato.org/article/89.html(...)


      Olivier Mengué

      PS : pour ceux qui veulent la traduction en français des informations de compatibilité de l'IBM Public Licence :
      http://www.gnu.org/licenses/license-list.fr.html#GPLIncompatibleLic(...)

      Mainteneur de LiquidPrompt - https://github.com/nojhan/liquidprompt

  • # Merci

    Posté par  . Évalué à 1.

    Tous mes remerciements pour cet article. Ça faisait un bout de temps que je pensais mettre en place une telle solution, mais jusque là, je n'avais pas eu le temps ou le courage de me pencher d'assez près sur UUCP pour ça...

    Il y a juste une ou deux questions que je me pose, au niveau du comportement d'une telle solution dans des cas "hostiles" :
    - Que se passe-t-il si la connexion se coupe au milieu du transfert ?
    - Si on a 50 Mo de mailbombs dans la boîte, y a-t-il moyen de les supprimer avant de charger le mail ?

    « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

    • [^] # Re: Merci

      Posté par  . Évalué à 0.

      Si le connexion se coupe pas de pb. uucp est tres robuste et reprendra le reste a la prochaine connexion.

      Pour le spam, Etienne de Tocqueville "et#steph.teaser.fr" a ecrit un patch qui permet de filtrer les emails selon leur enveloppe. Il est dispo sur:
      http://www.teaser.fr/u/edetocquev/uucp/(...)
      Le contacter directement pour plus d'infos.

      AmicaLinuXement,
      Denis BRAUSSEN.

  • # Re: UUCP à travers SSH: la meilleure configuration mail

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

    Juste pour information, il y a (au moins) une association qui fournit
    ce type de service pour le mail et pour les news. Pour ceux qui sont
    sur Internet depuis longtemps, ca evoquera sans doute des souvenir: FDN.

    Ca doit bien faire... heu... 10 ans que FDN fournit UUCP (a l'epoque c'etait
    le moyen d'acces "normal" au mail), et ca doit faire un an ou deux que
    l'acces UUCP/ssh est en place.

    Pour ceux que ca interesse de voir comment ca peut se configurer sur des
    exemple reels:
    http://www.fdn.fr/supp.conn.html(...)

  • # Alternative + simple

    Posté par  . Évalué à 1.

    Pour ceux qui n'ont pas envie de jouer les barbus, y a no-log qui fournit POP crypté, IMAP crypté et SMTP crypté.

Suivre le flux des commentaires

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