Le courriel à la maison.

On veut du courriel !

On en fait souvent tout un cas, spéculant sur la difficulté d’héberger soi-même son courriel. Entre les différents MTA, leurs configurations exotiques et le dns à gérer, tout paraît tellement compliqué.
Et pourtant…

Postfix c’est bien, postfix c’est magique.
Au tout cas sur la Debian qui fait ça sur mon réseau.

Je vais ici décrire la configuration du courrier toutes destinations (courriers locaux compris), sur un réseau disposant d’une passerelle NAT connectée à internet, d’une Debian correctement paramétrée (serveur mail), ainsi que d’un nombre quelconque d’hôtes (qui seront clients du serveur) sur le même réseau.
Soit quelque chose de la forme :


┌───────────┐ ┌──────────────┐
│ Internet  │ │ Passerelle   │
├───────────┤ ├──────────────┤ ┌────────────────┐
│{0.0.0.0/0}├-┤ x.x.x.x.x/32 │ │ Réseau local   │
└───────────┘ ├──────────────┤ ├────────────────┤
              │ 192.168.1.1  ├-┤{192.168.1.0/24}│
              └──────────────┘ └─┬──────────────┘
                 ┌───────────────┘
┌──────────────┐ │ ┌──────────────┐
│ Client A     │ │ │ Serveur mail │
├──────────────┤ │ ├──────────────┤
│ 192.168.1.10 ├─┼─┤ 192.168.1.2  │
└──────────────┘ │ └──────────────┘
┌──────────────┐ │ ┌──────────────┐
│ Client B     │ │ │ Client C     │
├──────────────┤ │ ├──────────────┤
│ 192.168.1.11 ├─┼─┤ 192.168.1.12 │
└──────────────┘ │ └──────────────┘
                 …
  

Une fois appréhendées quelques notions touchant au réseau, au DNS, ainsi qu’à l’administration, l’unique chose nécessaire est un peu de temps.
Pour recevoir du courriel chez soi, on doit ainsi comprendre un minimum ce qui touche :

  • au NAT, afin de ne pas voir une FAI-box bloquer le courrier entrant ;
  • au DNS, et particulièrement aux champs A, AAAA, MX
  • à l’administration de la machine qui sert le courrier (sur Debian GNU/Linux, la connaissance de apt, dpkg-reconfigure, d’un éditeur texte et savoir redémarrer un service est suffisant)

À propos du NAT, il suffit de rediriger le port SMTP (25) de la box vers la bonne machine, et les ports qu’utilisent IMAP, si on met en place un service de ce type pour accéder à sa boîte.
Niveau DNS, on a besoin d’un champ A qui fait pointer un nom vers votre ip, ainsi que d’un champ MX pour le domaine, pointant vers le champ A.
Selon le FAI, on dispose ou non d’une ip fixe ; si c’est n’est pas le cas (chez Orange par exemple), le A doit être dynamique. Chez OVH, cela se fait en avec un dynhost, qu’on prend soin de mettre à jour lorsque l’ip changera, mais on peut très bien utiliser n’importe quel service semblable (noip par exemple).

D’où part-on ?

Il peut être pratique d’avoir un dns sur le réseau, offrant à chaque hôte un nom.

Alors qu’il y a quelques années j’utilisais un dhcpd avec bind. Je me contente maintenant du très simple et complet dnsmasq.

J’ai donc, avant de commencer à toucher à un quelconque MTA, un domaine configuré avec un sous-domaine pointant vers chez moi, qui est donné à tout le monde via dhcp, ainsi que le port 25 de ma passerelle joignable depuis internet, et redirigé vers la machine qui héberge le courrier.
Dans la zone qui gère le domaine « exemple.com », j’ai :

  • « mx0.exemple.com » également, avec un enregistrement A ou AAAA (un dynhost pour moi) ; cela ne peut pas être un CNAME, et doit impérativement pointer vers une ip ;
  • « exemple.com. MX 4 mx0.exemple.com. » ;
  • « sub.exemple.com. MX 4 mx0.exemple.com. » ;
  • éventuellement des enregistrements A/AAAA et MX (avec une priorité plus basse que le premier, soit un nombre plus grand) supplémentaires, afin continuer à recevoir le courriel lorsque la passerelle n’est plus connectée à internet ; pour mon cas, un « mx1.exemple.com » en plus pour chaque MX déjà en place, pointant ailleurs que chez moi ;

Et dans la zone chez moi, qui gère le sous-domaine « sub.exemple.com » :

  • « smtp.exemple.com » pointant vers le serveur mail ;
  • quelque chose qui ressemble à « clienthost.sub.exemple.com » pour toutes les autres machine.
    On peut très bien se contenter de « clienthost.exemple.com », mais comme je dispose de plusieurs réseaux séparés, je les associe à des sous-domaines différents ; puisque ce n’est pas pertinent en tout cas, on en tiendra pas compte ici.

Ce schéma précis n’est pas un passage obligé. Il est plus simple d’avoir des noms facile à retenir, mais on peut très bien utiliser les ip à la place.
Par contre, dès l’instant où on souhaite échanger du courriel depuis et vers internet, il est nécessaire d’avoir au moins un champ MX de renseigné dans le DNS, encore une fois, pointant vers un champ A/AAAA (une ip, donc).

Si simple…

Eh bien… oui.
Un petit coup de « apt-get install postfix mailutils  » installe tout ce qui est nécessaire pour gérer du courriel.
« dpkg-reconfigure postfix » aide à obtenir une configuration fonctionnelle, qu’on pourra affiner dans le fichier qui va bien : « nano /etc/postfix/main.cf ».

Site Internet

Pour recevoir et envoyer du courrier.

Nom de courrier :
exemple.com

Les adresses seront donc de la forme « user@exemple.com »

Destinataire des courriels de « root »
et de « postmaster » :

Vide ; je configure ça dans le fichier « /etc/aliases » (avec l’obligation de lancer la commande « postalias /etc/aliases », à chaque modification).
Cela sert à associer plusieurs noms à une seule boîte.

Autres destinations pour lesquelles le courrier sera accepté (champ vide autorisé) :
localhost exemple.com sub.exemple.com

Postfix acceptera d’envoyer les courriels pour ces
domaines.
Il acceptera ici le courrier pour des adresses de formes « user@localhost », « user@exemple.com » et « user@sub.exemple.com ».

Réseaux internes :
127.0.0.0/8 !192.168.1.1 192.168.1.0/24

Les réseaux de confiance, dont postfix acceptera de délivrer le courrier ailleurs que vers les domaines qu’il connaît.
Ici, seules les machines appartenant au réseau « 192.168.1.0/24 » pourront envoyer des courriels vers n’importe où. N’importe quel courrier, même venant d’un utilisateur authentifié, se verra refusé avec une erreur « Relay access denied ».
L’hôte « !192.168.1.1 » (dans la plupart des configurations, la passerelle internet) aura la même punition, empêchant ainsi tout courrier venant d’internet d’être envoyé ailleurs que vers votre domaine. Si on veut pouvoir envoyer du courrier depuis autre part que le réseau, cette directive est de trop.

Le reste sera laissé aux valeurs initiales.

Let’s send!

Une fois la chose fonctionnelle, un simple « dpkg-reconfigure exim4-config » sur les autres machines du réseau, avec les paramètres qui suivent, suffiront pour relayer tout les courriers (utilisateurs et systèmes) vers la se le serveur :

Envoi par relais (« smarthost ») — pas de courrier local

Nom de courrier du système :
exemple.com

Liste d'adresses IP où Exim sera en attente de connexions SMTP entrantes :
127.0.0.1

Autres destinations dont le courrier doit être accepté :


Nom de domaine visible pour les utilisateurs locaux :
sub.exemple.com

Nom réseau ou adresse IP du système « smarthost » :
smtp.exemple.com

Concrètement, cela autorise le courrier local vers n’importe où (ou reformulé : envoyé depuis la machine uniquement, vers n’importe où ailleurs), et l’envoie vers « smtp.exemple.com », en complétant les noms d’utilisateurs locaux avec le domaine visible « sub.exemple.com », pour former l’adresse expéditrice « user@sub.exemple.com ». Pour utiliser des adresses sans le sous-domaine, il suffit de modifier ce champ.
Les courrier envoyé à un utilisateur sans préciser le domaine, par exemple avec la commande « env | mail -s mailtest root », seront complété avec le nom de courrier système. Notre exemple enverra donc un courriel à l’adresse « root@exemple.com », expédié depuis quelque chose de la forme « user@sub.exemple.com ».

Je n’y comprend rien.

Ce n’est peut-être pas clair. Un cas plus concret n’est jamais de trop…
Alors allons-y.

Admettons que vous ayez donné votre adresse
« coincoin@exemple.com » à votre amie artiste CROCHE Sarah, et que cette dernière veuille vous montrer sa dernière création, en envoyant un lien depuis son adresse « sarah.croche@au-pinceau.fr ».
Le MTA de Madame Croche (ou de son fournisseur de courriel) va extraire le domaine de votre adresse, « exemple.com » ici, et chercher le plus petit enregistrement MX valide pour ce domaine.
Il va trouver « exemple.com. MX 4 mx0.exemple.com. », et ainsi essayer d’envoyer le courriel vers cette hôte (à la maison, donc). S’il n’y arrive pas, il essaiera le MX suivant, ou garder son courriel pour peut-être tout recommencer plus tard s’il n’en trouve pas.
Une fois envoyé, notre postfix rentre dans la partie. Il va vérifier plusieurs points :

  • que le domaine soit listé dans ses domaines à relayer (option relay_domains − la configuration par défaut autorise les mêmes domaines que « mydestination », soit le champ « Autre destinations » qu’on a définie avec « dpkg-reconfiguer ») ;
  • que la boîte aux lettre « coincoin » existe.

Étant donnée que le domaine est bien listé tout va bien, il suffit qu’il existe un utilisateur « coicoin » pour que postfix délivre le message à vers ce dernier.

Arrivé là, vous lisez ce courriel, et décidez de lui répondre à partir d’un hôte du réseau, avec l’utilisateur « coincoin ». Ici c’est exim4 qui envoie d’abord, vers « smtp.exemple.com » ; le postfix du serveur, donc.
Comme le nom de domaine visible est « sub.exemple.com » ici, l’adresse correspondante est « coincoin@sub.exemple.com ».
Ce domaine étant listé dans les destinations de postfix option (« mydestination », il envoie la réponse au plus petit enregistrement MX du domaine « au-pinceau.fr » qu’il arrive à joindre.
Notez que si Madame Croche essaie de vous joindre en répondant à cette adresse, au lieu de celle que vous lui avez fourni, son courrier ne sera pas livré, le domaine « sub.exemple.com » ne disposant pas de champ MX.
On peut éventuellement en ajouter un, si on souhaite pouvoir l’utiliser.

Aller plus loin.

À tout ça s’ajoute les différents systèmes d’authentifications.
Avec la configuration générée par dpkg, n’importe quel utilisateur local peut utiliser postfix pour envoyer et recevoir du courrier. Il suffira alors de préciser dans les paramètres sortants (SMTP) de votre client mail, la sécurité utilisée (SSL/TLS ou STARTTLS), ainsi que le nom d’utilisateur et son mot de passe, correspondant à un utilisateur de la machine où est postfix. Créer un compte sur le serveur mail revient alors à créer une boîte du même nom, à laquelle pourra s’ajouter d’éventuels alias (par exemple mon compte personnel est un pseudonyme, et des boîtes « mon_prénom », « mon_nom.mon_prénom » et « mon_prénom.mon_nom » en sont des aliases).
La plupart des FAI bloquant purement et simplement tout ce qui sort du port 25 de leur clients, il est aussi nécessaire de paramétrer un relais, avec les informations qu’il vous fournie.
Les capacités de postfix ne s’arrêtent évidemment pas là, et beaucoup de choses sont possibles. On aurait par exemple pu demander à postfix de relayer le courriel destiné aux hôtes vers ces derniers, afin que chacun puisse disposer de son courrier localement.

Publicités

Jeter un mot :

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s