Installation de Postfix

Installation en mode «Site Internet».

Par défaut, postfix réceptionne les messages concernant «mydestination» et les stocke au format «mailbox» orienté POP3. Nous préférons bien sûr le format «maildir» propre à IMAP. Potfix dispose de son propre LDA¹⁾, nous lui préférerons celui qui est proposé par Dovecot.

Ce fichier permet à Postfix de rediriger les e-mails destinés à certains utilisateurs locaux (existants ou non) vers d'autres utilisateurs (locaux ou non, mais existant). Par défaut, ce fichier contient ceci:

# See man 5 aliases for format
postmaster:	root

«postmaster» est à-priori inexistant, mais est redirigé vers «root» et ce n'est pas une bonne idée d'attribuer une BAL à «root». Nous créons pour l'instant un utilisateur «admin» sans droits particuliers et modifions ce fichier /etc/aliases comme suit:

postmaster:	root
root:		admin

Tous les messages qui devraient directement ou non atterrir dans la BAL de «root» iront désormais dans celle de «admin», si l'on n'oublie pas de mettre à jour la base de sonnée /etc/aliases.db avec la commande :

newaliases 

compatibility_level = 3.9
mydomain = home.nain-t.net
myorigin = $mydomain
smtpd_banner = $myhostname ESMTP $mail_name (Debian)
inet_protocols = all
mynetworks_style = host
mynetworks = 127.0.0.0/8 192.168.60.0/24 [::ffff:127.0.0.0]/104 [::1]/128 [2a01:e0a:875:b1d0::0]/64
mydestination = $myhostname, home.nain-t.net, localhost.home.nain-t.net, , localhost
mailbox_size_limit = 0
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
biff = no
recipient_delimiter = +
relayhost = 
cyrus_sasl_config_path = /etc/postfix/sasl
smtpd_tls_key_file = /etc/letsencrypt/live/home.nain-t.net/privkey.pem
smtpd_tls_cert_file = /etc/letsencrypt/live/home.nain-t.net/fullchain.pem
smtpd_tls_security_level = may
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
smtp_tls_security_level = may
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
myhostname = mail.home.nain-t.net
inet_interfaces = all
home_mailbox = Maildir/

• mydomain et myorigin permettent au serveur de poster les messages d'administration @home.nain-t.net plutôt que @mail.home.nain-t.net. Ce n'est pas fondamental et tout-à-fait optionnel.
• mynetworks définit les adresses de sous-réseaux dont fait partie le serveur. Les clients dont l'adresse appartient à l'un de ces sous-réseaux sont considérés comme sûrs et sont acceptés sans restriction pour l'envoi de messages.
• mydestination liste les destinations considérées comme locales dans les adresses entrantes et donc gérées par le LDA.
• smtpd_tls_key_file et smtpd_tls_cert_file indiquent les chemins d’accès à la clé privée et au certificat générés par «let's encrypt».
• home_mailbox indique à Postfix que les messages locaux sont stockés au format «Maildir».

Lorsqu'un client doit poster un e-mail, son MUA est configuré pour utiliser un MTA. Typiquement celui proposé par son fournisseur d'accès. Lorsque le client est connecté par l'entremise de son FAI, il dispose d'une adresse qui fait partie des réseaux du FAI et ce dernier peut user de cette particularité pour autoriser le relai de ce message.

En revanche, le client nomade, qui est amené à se connecter au Net par divers autre moyens, ne disposera pas forcément d'une adresse IP appartenant à son FAI. Dans ce cas, plusieurs cas sont possibles:

1. le client nomade utilise alors un «webmail» et s'authentifie via son adresse e-mail et son mot de passe,
2. le client nomade modifie son MUA pour utiliser le MTA proposé par le FAI qui le connecte (solution de type «shadoks»²⁾,
3. le FAI habituel du client nomade a mis à sa disposition le port «submission» qui permet au client d'utiliser TLS pour s'authentifier auprès du MTA avec son mom d'utilisateur (ou son adresse mail) et son mot de passe. Postfix sait faire, en s'appuyant sur le serveur IMAP associé. C'est cette technique que nous mettrons en œuvre.

Postfix propose une panoplie de restrictions applicables aux mails entrants:

• smtpd_client_restrictions,
• smtpd_helo_restrictions,
• smtpd_sender_restrictions,
• smtpd_recipient_restrictions,
• smtpd_relay_restrictions,
• smtpd_data_restrictions,
• smtpd_end_of_data_restrictions,
• smtpd_etrn_restrictions.

La plus importante étant smtpd_recipient_restrictions qui définit les restrictions applicables sur le contenu de l'en-tête «RCPT TO:»

(ou «blacklists») sont des listes de MX réputés arroseurs de spams proposées sur le Net. Postfix permet de tester lors d'un message entrant, s'il provient d'un de ces MX.

Première mesure: Ne pas se retrouver en situation de relais ouvert (open-relay). Autrement dit configurer correctement Postfix pour qu'il n'accepte pas de relayer des messages émis pas des gens inconnus. Ceci est déjà en partie réalisé avec le paramètre mynetworks qui; comme son nom l'indique, ne s'intéresse qu'à l'adresse IP de l'émetteur. Ce n'est pas suffisant, une station dans le réseau contaminée par un virus quelconque peut être amené à poster en douce du spam «à gogo». De plus, un client nomade ne pourra pas utiliser notre MX s'il n'est pas connecté à l'un de nos réseaux. Il faudra trouver une astuce.

Deuxième mesure: Le RDNS (reverse DNS) devrait être systématiquement mis en place. Autrement dit, une recherche DNS sur l'adresse IP du serveur doit renvoyer son nom. Ceci induit deux choses:

1. Le nom attribué au serveur MX doit être par un champ A (IPv4) ou AAAA (IPv6) et en aucun cas par un alias (champ CNAME);
2. il faut être en mesure de paramétrer le RDNS, ce qui n'est pas toujours possible lorsque l'on passe par un F.A.I et que celui-ci ne propose pas de solution. Free par exemple ne propose qu'une solution pour l'unique IPv4 fournie et actuellement rien pour IPv6. Les zones de définition des champs «IN PTR» ne pouvant se trouver (si elles existent) que sur les DNS du pourvoyeur d'adresses IP et non chez le gestionnaire du nom de domaine.
3. Au minimum configurer correctement SPF (Sender Policy Framework) autrement dit mettre en place un champ «TXT» sur le DNS du domaine permettant au MX du destinataire que l'émetteur a utilisé un MX dans le domaine de son adresse d'émetteur.

Il est possible de créer ses propres listes noires, il est tout de même intéressant d'utiliser avec discernement des listes publiques. Le projet «spamhaus» faisant référence dans le domaine.

Mot valise signifiant «Mail Filter» utilisent un protocole développé à l’origine par l’ancêtre Sendmail. Depuis sa version 3.2, Postfix a appris à utiliser cette méthode.

Par ce biais, il est désormais possible de greffer sur Postfix un filtre anti-spam (Spamassassin), un filtre anti-virus (Clamav)sans avoir à passer par les services du démon Amavis.

Le SMTP d'origine a été conçu pour le monde des bisounours. Porté dans le monde réel, il montre ses faiblesses en termes de sécurité, pouvant être détourné par un tas d'utilisations malveillantes.

Aussi a-t-il été ajouté quelques fonctions qui deviennent indispensables si l'on souhaite construire un MTA reconnu par ses pairs.

• SPF (Sender Policy Framework) est une norme de vérification du nom de domaine de l'expéditeur d'un courrier électronique, normalisée dans la RFC 72081 (section 3.1)2. L'adoption de cette norme est de nature à réduire le spam (Définition issue de Wikipedia).
• DKIM (Domain Keys Identified Mail) permet au serveur SMTP sortant de signer les e-mails qu'il émet avec une clé privée. La clé publique correspondante est accessible par le serveur DNS du domaine. Ainsi, le serveur SMTP destinataire peut s'assurer de l’authenticité su serveur émetteur. Il devient alors facile de comparer les domaines du serveur émetteur à la partie droite de l'adresse de l'adresse indiquée dans l'en-tête From qui devraient être identiques. Bien entendu, il faut abandonner la pratique consistant à utiliser par exemple le serveur SMTP de son fournisseur d'accès en présentant une adresse appartenant à un autre domaine.
• DMARC (Domain-based Message Authentication, Reporting, and Conformance) propose une solution de déploiement et de surveillance des problèmes liés à leur authentification, en s'appuyant sur SPF et DKIM.

Il faudra voir comment mettre tout ceci en œuvre.