Pourquoi y a-t-il un problème ?

Le problème est que contrairement aux machines Windows (habituelles), les machines Linux sont presque toutes capable d'envoyer et recevoir directement du courrier (à l'aide de leur démon sendmail), sans passer par un serveur relais.

Deux problèmes principaux avec cette approche dans un environnement "étudiant" :

(il y a d'autres raisons)

De la même façon que le routeur de l'École (irts.ens-cachan.fr) ne permet le trafic web que vers et à partir de zamok, seul zamok a le droit de parler SMTP vers des machines hors du réseau Cr@ns.

Oui, bon, alors, comment on fait ?

Deux solutions possibles. La première, faire comme sous Windows et utiliser un monolithe comme Netscape, et lire son courrier en POP3 sur zamok et le réémettre directement sur zamok en SMTP (mais ni pine(1) ni mail(1) ne fonctionneront). La seconde, un peu plus complexe mais nettement plus puissante, est décrite ci-dessous.


(ou : sendmail n'envoie pas mon courrier jusqu'au bout, je vais le chercher)

Il faut installer l'excellent logiciel fetchmail(1) de l'illustre Eric S. Raymond (ou encore sur Freshmeat). Fetchmail est un complément à sendmail : en gros, sendmail "pousse" le courrier, "fetchmail" le tire (il a plein d'autres fonctions fort puissantes, mais voici l'essentiel).

Un des avantages de cette approche est que si on est là, son courrier arrive chez soi directement, tout le temps, et que si on n'est pas là, zamok conserve tout bien sagement.

1° étape : mettre en route fetchmail

Ensuite, il suffit de créer le fichier $HOME/.fetchmailrc comme suit :

poll zamok with protocol pop3: user chepelov there has password MON_MOT_DE_PASSE is chepelov_c here

(hélas, il faut mettre le mot de passe en clair. Un petit chmod 600 $HOME/.fetchmailrc s'impose donc).

C'est presque de l'anglais ! Si je traduis mot à mot, ça donne à peu près :

interroge zamok suivant le protocole pop3: l'utilisateur chepelov là-bas a comme mot de passe MON_MOT_DE_PASSE et est chepelov_c ici.

Remarque : Mon compte sur Zamok est "chepelov". Sur ma machine, c'est "chepelov_c". Comme on peut le voir, ça ne pose aucun problème.

Taper une fois fetchmail -v pour voir si ça marche.

2° étape : garder secrets les passwords, dans le fichier de config et lors de la connexion.

Pour éviter que quand on laisse sa machine 2 minutes, un voisin vienne lire ~/.fetchmailrc et récupère tous ses passwords, on peut le crypter et le décrypter automatiquement juste avant de lancer fetchmail (ça oblige alors à taper _un_ mot de passe, pour décrypter le fichier, _une_ fois si on opte pour laisser tourner fetchmail en daemon, ie. en arrière-plan, et en permanence.) Exemple avec GnuPG pour crypter (il y a bien des softs spécialisés pour crypter des fichiers, je prends GnuPG parce qu'il sert aussi au mail, est assez universel et bien documenté, et mérite d'être compris... )

  1. On encrypte le fichier: gpg -r [ cle_pour_fetchmail ] -o crypted_rc -e .fetchmailrc Pour créer la clef PGP, c'est assez simple. Voir la rubrique "sécurité".

  2. On créé un script basique, disons "fetch" (faire chmod +x fetch apres, ou bien l'exécuter par "./fetch" ) 
      gpg -o ~/temp_rc -d ~/crypted_rc;  
  chmod go-rwx ~/temp_rc;  
  fetchmail --fetchmailrc ~/temp_rc $1 $2 $3 $4 $5 $6 $7 $8 $9;  
  rm ~/temp_rc
  3. voir plus bas pour faire en sorte que la connexion soit cryptée par ssh, pour éviter que tout le réseau capte les passwords...

Et je crois que c'est bon... Pour vérifier si ça marche, sans effacer de messages: fetch -N -v -k . (N = pas en daemon, v=verbose, k= keep. (Attention "-K" ferait l'inverse, nokeep..)

Sécuriser la connexion au serveur POP :

Pour ne pas transmettre le password "en clair" sur le réseau (auquel cas toutes les machines du sous-réseau peuvent l'intercepter, voir Linux-Security-Howto-Sniffers ), il y a plusieurs solutions :

  1. Utiliser une variante de POP appelée "APOP" (supportée par fetchmail. Par contre sous Windows, les clients supportés sont rares. Eudora...) Ce protocole n'encrypte pas toute la connexion mais ne transmet pas le password (à la place, elle l'utilise pour calculer la réponse à un test du serveur.)

  2. Utiliser la sécurisation SSL. Un tunnel SSL (fourni par le package "stunnel" ) tourne sur zamok.crans.org, et forwarde ainsi les connexions cryptées au port pop3s (995, port pop3 sécurisé standard) vers le port pop3 en décryptant au passage.
    Ainsi, la connexion au serveur POP est cryptée de A à Z. Cela sollicite plus le serveur que la méthode APOP, mais est plus universelle.
    La plupart des clients windows gère ce protocole, et fetchmail aussi.
    Par exemple :
    ## .fetchmailrc pour pop3 + SSL poll zamok with proto pop3: user krempp is samy here password "pasFOUnon" options ssl

    Malheureusement, le support SSL de fetchmail nécessite parfois de le patcher à cause de restrictions sur la crypto. Dans ce cas fetchmail se contentera de POP normal, sans rien dire... Du coup il vaut mieux vérifier qu'il utilise effectivement SSL. (par exemple faites netstat sur votre machine juste après une connexion en POP de fetchmail, et vérifiez que la ligne contenant Zamok indique le port 995 (ou pop3s), et non 110 (ou pop) ).
    Si l'option SSL de fetchmail ne marche pas, et que vous voulez pas le patcher ou attendre qu'une mise à jour corrige le problème, vous pouvez installer stunnel sur votre machine, puis :

    ## .fetchmailrc pour pop3 + ssl VIA STUNNEL poll zamok via localhost port 13110 with proto pop3: user krempp is samy here password "pasFOUnon"

    Et tapez stunnel -c -d 13110 -r zamok:995 avant de lancer fetchmail.

  3. Dans les cas où aucun protocole sécurisé n'est offert directement par le serveur, il est posible d'utiliser ssh pour crypter la connexion. Cependant, cette méthode est très lourde pour le serveur, et est à éviter. (si 300 personnes faisaient ça toutes les 3 minutes, ça chargerait beaucoup et inutilement le serveur). La méthode est expliquée ici pour le cas où cela serait utile.
    Il faut :

    1. avoir configuré ssh pour pouvoir se connecter à Zamok sans taper de password. (cf la doc Cr@ns sur SSH)

    2. avoir réglé fetchmail pour passer par une connexion ssh. Pour ça, utilise l'option "preconnect" pour lancer un ssh en lui demandant de transmettre tout ce qui va dans tel "port" local vers "tel port, de telle machine", en cryptant la communication entre la machine locale et zamok.

      Exemple de fetchmailrc: 
      set postmaster "samy"
set bouncemail
set properties ""
set daemon 180

poll pop.free.fr via localhost port 11114 with proto imap:
	user "s.krempp0" there with password "toto2000" is samy options keep
	preconnect "ssh1 -f krempp@Zamok -L 11114:pop.free.fr:143 sleep 5";
	user "s.krempp1" there with password "toto2001" is samy
	user "s.krempp2" there with password "toto2002" is samy options keep

poll zamok via localhost port 11110 with proto pop3:
	user krempp password "toto2000" is samy
	preconnect "ssh1 -f krempp@Zamok -L 11110:Zamok:110 sleep 5"

      Remarques : comme l'exemple pop.free.fr le montre, il suffit de forwarder un port pour le premier compte sur un serveur, si on possède plusieurs comptes sur un même serveur.

    3. Ensuite, préparer ssh-agent pour permettre les connexions ssh automatiques: eval `ssh-agent1`; ssh-add1; ( à nouveau, cf la doc Cr@ns sur SSH) pour que ssh garde en mémoire l'autorisation d'utiliser la clef ssh.
      Bien sûr, cette dernière étape est à refaire quand on redémarre la machine..

Puis, si le fichier de config est crypté comme indiqué au-dessus, taper fetch , ou fetch -N -v -k pour vérifier que ça marche...

3° étape : fetchmail tout le temps

Si votre fetchmailrc n'est pas crypté, ce qui implique de lancer explicitement fetch et de lui refiler le password pour décrypter (après s'être occupé du ssh-agent...), on peut lancer automatiquement fetchmail dès qu'on se loggue. Il suffit d'ajouter ceci dans un des fichiers de démarrage (dans .zlogin pour /bin/zsh, par exemple) : 

fetchmail -d 180

On peut mettre ça dans .profile ou .zlogin par exemple. Le -d 180 spécifie qu'il doit se reconnecter toutes les 3 minutes, et rester actif en background, ce qu'on appelle "daemon". Ça revient au même de mettre "set daemon 180" dans le fichier de config.

puis dans .zlogout (pour être poli) : 

if [ `tty` = "/dev/console" ]; then
    fetchmail -q
fi

(Quand on se connecte souvent chez soi depuis l'extérieur, on ne coupe le fetchmail que si on se déconnecte depuis sa machine physique).

Le MTA (Mail Transfer Agent) est le programme chargé de transférer les e-mails. Exim, sendmail et postfix sont les MTA les + classiques, et postfix est le plus conseillé.

Ici, on parlera uniquement de postfix, et de sendmail.

Note de vocabulaire pour briller en société :
Outre 'MTA', il y a 2 autres sigles utilisés pour désigner les différents rôles des programmes nécessaire au fonctionnement du mail. Le MDA (D comme Delivery) le délivre à chaque utilisateur, et bien souvent c'est un programme inclus dans le package du MTA (mais remplaçable, par exemple par procmail..). Enfin, le MUA (U comme User) est le programme utilisé finalement par l'utilisateur pour lire ses mails, comme Pine, Mutt, Kmail, ..

Utiliser Postfix

Postfix est un remplaçant de sendmail, beaucoup plus facile à configurer et plus sûr. Voir Postfix.org pour plus d'infos.

Si vous voulez un exemple, voilà comment je l'ai configuré, de manière à pouvoir envoyer du courrier vers l'extérieur sans que mon adresse apparaisse comme "samy@marvin.crans.org". Les réglages principaux se font dans /etc/postfix/main.cf :

"myorigin" : personnellement je laisse comme valeur $myhostname, comme ça le mail ne remonte pas tout seul vers Zamok lors de la livraison à l'user final. (ce qui arrive si on choisit =$mydomain, sans adapter des règles supplémentaires ("virtual", "canonical" ..) adaptées pour garder le mail local en local)

"mydestination" : a priori on peut le laisser tel quel. Postfix ne livrera le courrier qu'aux utilisateurs de la machine locale, donc la valeur par défaut $myhostname localhost.$mydomain marche très bien.

"relayhost" : bien évidemment, = [zamok.crans.org:25]

Par contre, il reste à modifier l'apparence de l'adresse des expéditeurs, sinon, sur les mails envoyés par ma machine, le destinataire verra comme adresse un truc comme : 

Return-Path: samy@marvin.crans.org
From: samy@marvin.crans.org (Samuel Krempp)

ça marcherait même si 'samy' était un user ou alias valable sur zamok (par le biais du dns, zamok déclare que c'est à lui qu'il faut envoyer les courriers aux machines en .crans.org). Mais c'est pas propre, et il faut éviter.

Pour cela, le mécanisme "sender_canonical" se montre facile et suffisant. On créé un fichier /etc/postfix/sender_canonical (ou autre, ce qui compte est d'indiquer ce fichier dans /etc/main.cf de toute façon..) qui contient une liste de user local / adresse réelle dans le genre de: 

root		Samuel.Krempp@Crans.org
samy		Samuel.Krempp@Crans.org
esso		Olivier.Saut@Crans.org

On transforme ce fichier en fichier "db" par postmap hash:sender_canonical. On inclut alors dans main.cf la ligne : 

sender_canonical_maps = hash:/etc/postfix/sender_canonical

Voilà, un petit postfix reload pour relire le fichier de config, et ça roule. Un dernier conseil: au moins dans les premiers temps, garder un oeil sur /var/log/mail donne beaucoup de renseignements, et permet de bien cerner les éventuels problèmes. Laisser un "tail -f /var/log/mail" tourner en permanence dans un coin fait ça très bien, on peut aussi utiliser un équivalent graphique (ktail, kwatch, .. )

Pendant qu'on y est, si postfix n'est destiné qu'à prendre en charge les mails venant de votre machine, il vaut mieux lui dire de ne pas accepter les connexions sur le port 25 venant de l'exterieur, comme ça tout risque d'abus par d'autres machines du LAN est évité. Si il y a un firewall installé sur la machine, on peut l'utiliser, sinon il suffit de modifier /etc/postfix/master.cf comme ceci : 

localhost:smtp   inet  n       -       -       -       -       smtpd

(simplement rajouter "localhost:", en bref.)

Sendmail

Là, on rentre dans le domaine du cauchemard. Réellement. Un des rares domaines de Linux où la configuration est aussi difficile que ce que les FUDmongers voudraient nous faire croire.

Deux solutions:

Utiliser le Kit Jussieu

Installer le Kit Jussieu sur son sendmail pour créer un fichier /etc/sendmail.cf disant à sendmail d'envoyer son courrier à zamok (règle RelaisExterieur)

La doc du Kit est simple à lire, fort instructive, et l'ensemble est trivial à mettre en oeuvre. En plus, c'est ce que fait zamok : voir donc sur zamok /etc/CRANS/regles.CRANS et /etc/CRANS/zamok.config pour avoir un exemple.

Voici par exemple un fichier de configuration type pour une feuille du réseau : 

#
# Configuration du sendmail de daemon
# 
# - on garde juste les messages entre users de daemon
# - on renvoie le reste sur Zamok (zamok.crans.org)


Host='daemon' 
Domaine='crans.org' 


AdressesLocales='HOST'
AdressesInternes='RIEN' 
ReecritureAdressesLocales=$Domaine

RelaisExterieur="smtp.[zamok.$Domaine]"

# Pour trouver cette valeur faire "grep '^Mlocal' sendmail.cf" sur le
# fichier fourni avec l'OS
MailerLocal='/usr/libexec/mail.local lsDFMAw5 mail -d $u'

# Pour utiliser procmail a la place
# MailerLocal='/usr/bin/procmail SAw5:|/@glDFMPhsfn procmail -Y -a $h -d $u'

# Les locations des fichiers (Attention ca depend de l'OS)
Aliases='/etc/aliases' 
SendmailSt='/var/log/sendmail.st'
SendmailHf='/usr/share/sendmail/sendmail.hf' 
Mqueue='/var/spool/mqueue'

# les revaliases 
# login -> Prenom.Nom...
RevAliases='hash -N /etc/revaliases'

 

top documents home dernière modif le 06.08.01 par K.

 

Linux : configurer son mail
presentation
liens
informations
vie
annuaire
pages perso
webmail
ssh