Vous pouvez vouloir avoir un démon local de courrier pour qu'il puisse relayer les courriers envoyés localement à un autre système. C'est courant quand vous devez administrer un certain nombre de systèmes et que vous ne voulez pas vous connecter à chacun d'entre eux pour lire le courrier envoyé localement. Comme toute la journalisation de chaque système individuel peut être centralisée en utilisant un serveur de journalisation système centralisé, les courriers peuvent être envoyés à un serveur de courriers central.

Un tel système relais seulement devrait être configuré correctement pour cela. Le démon pourrait également être configuré pour n'écouter que sur l'adresse de bouclage.

Les étapes de configuration suivantes ne doivent être suivies que si vous configurez le paquet exim dans la version 3.0 de Debian. Si vous utilisez une version ultérieure (comme la version 3.1 qui utilise exim4), le système d'installation a été amélioré afin, si le MTA est configuré pour ne délivrer que des messages locaux, de n'autoriser des connexions que depuis l'hôte local et interdire toute connexion distante.

Sur un système Debian 3.0 utilisant exim, vous devrez retirer le démon SMTP d'inetd :

$ update-inetd --disable smtp

et configurer le démon de courrier pour écouter seulement sur l'interface de bouclage. Dans exim (le MTA par défaut) vous pouvez faire ça en éditant le fichier /etc/exim.conf et en ajoutant la ligne suivante :

local_interfaces = "127.0.0.1"

Redémarrez les deux démons (inetd et exim) et Exim n'écoutera que sur la socket 127.0.0.1:25. Faites attention, et avant tout désactivez inetd, sinon Exim ne démarrera pas étant donné que le démon inetd est déjà en attente de connexions entrantes.

Pour postfix éditez /etc/postfix/main.conf :

inet_interfaces = localhost

Si vous voulez seulement le courrier local, cette approche est meilleure que l'encapsulation TCP du démon de courrier ou l'ajout de règles de pare-feu pour limiter les personnes qui y accèdent. Cependant, si vous n'avez pas besoin d'écouter sur d'autres interfaces, vous pourriez envisager de le lancer à partir d'inetd et ajouter une encapsulation TCP pour que les connexions entrantes soient vérifiées par rapport à /etc/hosts.allow et /etc/hosts.deny. De plus, vous serez au courant quand un accès non autorisé est tenté sur le démon de courrier, si vous mettez en place correctement la journalisation pour n'importe laquelle des méthodes décrites plus haut.

En tout cas, pour rejeter les tentatives de relais de courrier au niveau SMTP, vous pouvez modifier /etc/exim/exim.conf pour inclure :

receiver_verify = true

Même si le serveur de courrier ne relaiera pas le message, ce genre de configuration est nécessaire au testeur de relais à http://www.abuse.net/relay.html pour déterminer que le serveur ne peut pas faire de relais.

Si vous voulez une configuration relais seulement, cependant, vous pouvez vouloir changer le démon de courrier pour des programmes qui ne peuvent être configurés que pour faire suivre le courrier à un serveur de courrier distant. Debian fournit actuellement les paquets ssmtp et nullmailer dans ce but. En tout cas, vous pouvez évaluer pour vous-même l'un de ces deux agents de transport de courrier ^[45]La liste n'inclura pas qmail, qui est distribué seulement comme code source dans le paquet qmail-src fournis par Debian et voir lequel correspond le mieux aux buts du système.

Si vous désirez donner un accès à distance aux boîtes à lettres, il y a un certain nombre de démons POP3 et IMAP disponibles^[46] Cependant, si vous fournissez un accès IMAP, notez qu'il s'agit d'un protocole générique d'accès aux fichiers, il peut devenir l'équivalent d'un accès à l'interpréteur de commandes car les utilisateurs peuvent être capables de récupérer n'importe quel fichier par celle-ci.

Essayez, par exemple, de configurer comme chemin de votre boîte de réception {server.com}/etc/passwd, si cela réussit, votre démon IMAP n'est pas configuré correctement pour empêcher ce genre d'accès.

Parmi les serveurs IMAP dans Debian, le serveur cyrus (dans le paquet cyrus-imapd) contourne cela en ayant tous les accès sur une base de données dans une partie restreinte du système de fichiers. Également, uw-imapd (installez soit uw-imapd ou mieux, si votre client IMAP le gère, uw-imapd-ssl) peut être configuré pour « chrooter » les répertoires de courrier des utilisateurs, mais cela n'est pas activé par défaut. La documentation fournie donne plus d'informations sur la façon de le configurer.

Vous pouvez également vouloir faire fonctionner un serveur IMAP qui n'ait pas besoin que des utilisateurs valables soient créés sur le système local (ce qui donnerait également un accès à l'interpréteur de commande), les paquets courier-imap (pour IMAP), courier-pop teapop (pour POP3) et cyrus-imapd (pour POP3 et IMAP) fournissent des serveurs avec des méthodes d'authentification en plus des comptes utilisateur locaux. cyrus peut utiliser toute méthode d'authentification qui peut être configurée par PAM tandis que teapop peut utiliser des bases de données (comme postgresql et mysql) pour l'authentification des utilisateurs.

FIXME : Vérifier : uw-imapd peut être configuré avec l'authentification utilisateur grâce à PAM également.

La lecture et réception du courrier sont des protocoles en texte clair parmi les plus courants. Si vous utilisez POP3 ou IMAP pour récupérer le courrier, vous envoyez votre mot de passe en clair à travers le réseau, et donc presque tout le monde peut lire votre courrier à partir de maintenant. À la place, utilisez SSL (Secure Sockets Layer) pour recevoir votre courrier. L'autre alternative est SSH, si vous avez un compte avec interpréteur de commandes sur la machine qui sert de serveur POP ou IMAP. Voici un fetchmailrc simple décrivant cela :

poll mon-serveur-imap.org via "localhost"
  with proto IMAP port 1236
      user "ref" there with password "hackme" is alex here warnings 3600
    folders
      .Mail/debian
    preconnect 'ssh -f -P -C -L 1236:my-imap-mailserver.org:143 -l ref
     mon-serveur-imap.org sleep 15 </dev/null > /dev/null'

Le preconnect est la ligne importante. Il lance une session SSH et crée le tunnel nécessaire, qui relaie automatiquement les connexions au port local 1236 vers le port IMAP du serveur de mail, mais chiffrées. Une autre possibilité serait d'utiliser fetchmail avec la fonctionnalité SSL.

Si vous désirez fournir des services de courrier comme POP et IMAP chiffrés, apt-get install stunnel et démarrez vos démons ainsi :

stunnel -p /etc/ssl/certs/stunnel.pem -d pop3s -l /usr/sbin/popd

Cette commande encapsule le démon fourni (-l) au port (-d) et utilise le certificat SSL indiqué (-p).