Où l’on va voir comment mettre en place un serveur de courrier avec postfix et dovecot. Nous avons un serveur DNS, nous avons un serveur HTTP, nous avons un serveur LDAP. Il est grand temps de mettre en place un serveur de courrier. Celui-ci sera constitué principalement de postfix en guise de MTA1 et dovecot2 en guise de MDA2.
Installation de Postfix
Postfix est aujourd’hui certainement le plus utilisé des MTA (même s’il en existe beaucoup d’autres comme le vénérable sendmail, exim que l’on trouve par défaut sur les distributions Gnu Linux Debian, citons également qmail). Nous allons utiliser notre poudriere pour forger postfix comme nous le désirons.
Configuration des paquets postfix et dovecot-pigeonhole
Nous allons commencer, comme vous en avez maintenant l’habitude, par ajouter les ports dont nous aurons besoin à /usr/local/etc/poudriere/101Ramd64-list.txt
.
|
|
le paquet dovecot-pigeonhole comporte la gestion des filtres sieve qui facilite la gestion des messages en utilisant des filtres pour les classer dans les répertoires que vous avez créés. Sieve peut faire bien d’autres choses.
|
|
Dans les options, choisissez OpenLDAP, TLS, DOVECOT2. Et soyez cohérent pour la suite des options. Enfin, on lance la création des paquets :
|
|
Installation de postfix
Il est temps maintenant de procéder à l’installation de postfix.
|
|
Configuration de postfix
Nous allons commencer par une configuration simple de postfix, que nous allons rapidement complexifier pour y ajouter des dispositifs antispam.
Les fichiers de configuration se trouvent dans /usr/local/etc/postfix
. Les deux principaux sont master.cf
et main.cf
.
une modification de master.cf
impose un redémarrage complet de postfix alors que la modification de main.cf
n’oblige généralement qu’à un rechargement des options.
Il faut répondre y à la question Would you like to activate Postfix in /etc/mail/mailer.conf [n]?
.
Mise en place du démarrage au lancement de la machine
Cette étape est importante parce que nous allons non seulement demander le démarrage automatique de postfix, mais aussi demander l’arrêt du MTA par défaut, sendmail.
Nous devons éditer le fichier /etc/rc.conf
:
|
|
Et nous devons nous assurer de supprimer toutes les instances des sendmail qui pourraient tourner sur notre machine.
|
|
Édition des fichiers de configuration de postfix
Nous aurons besoin d’un utilisateur fictif qui aura accès aux boîtes aux lettres de chacun des utilisateurs. Notons dans un coin son UID et GID :
|
|
Nous allons sauvegarder les fichiers d’origine postfix :
|
|
Et commencer à éditer le fichier main.cf
3 :
je reproduis mon fichier main.cf
et je vais commenter les grandes lignes. Pour le reste, vous trouverez de l’aide dans la documentation de postfix.
On commence par la définition des paramètres du domaine :
|
|
smtpd_banner
→ description de la bannière qui est envoyée à la connexion sur le port smtp. Moins on en dit sur notre serveur, mieux on se porte. Toutefois, un minimum est requis pour que le serveur qui se connecte ait une idée des capacités du nôtre ;biff = no
→ les notifications de réception d’un nouveau message ne sont pas envoyées à l’utilitairebiff
;
|
|
append_dot_mydomain = no
→ postfix n’ajoutera pas .$mydomain à la fin des adresses emails ;message_size_limit = 20480000
→ définit la taille maximum des messages ;
Les paramètres qui suivent concernent la sécurité des connexions. Nous allons utiliser le protocole TLS (Transport Layer Security). Pour cela nous devons avoir un certificat TLS valide. Reportez-vous à mon article sur les certificats pour savoir comment obtenir le vôtre. Les étapes qui concernent Apache ne sont pas applicables.
|
|
smtp_use_tls = yes
→smtp
utilise tls ;smtpd_use_tls = yes
→smtpd
utilise tls ;smtp_tls_note_starttls_offer = yes
→ note le nom du serveur qui veut établir une session tls ;smtpd_tls_cert_file = /etc/ssl/certs/tamanoir.foucry.net.pem
→ chemin vers le certificat ;smtpd_tls_key_file = /etc/ssl/private/foucry.net.key
→ chemin vers la clef du certificat ;smtpd_tls_CAfile = /etc/ssl/certs/StartCom_Certification_Authority.pem
→ chemin vers le fichier contenant les certificats des autorités racines que nous reconnaissons ;smtpd_tls_loglevel = 2
→ le niveau de déverminage ;smtpd_tls_received_header = yes
→ nous désirons ajouter les en-têtes indiquant les paramètres négociés par tls ;smtpd_tls_mandatory_protocols = !SSLv2,!SSLv3
→ les protocoles que nous voulons absolument utiliser. PasSSLv2
, niSSLv3
(le point d’exclamation indique la négation). En effet, ces deux protocoles sont vieux et obsolètes ;smtpd_tls_session_cache_timeout = 360s
→ le temps pendant lequel les données de session sont conservées dans le cache ;tls_random_source = dev:/dev/urandom
→ la source nombre aléatoire nécessaire à tls.
Passons maintenant à l’authentification des utilisateurs et des serveurs :
|
|
smtpd_sasl_type = dovecot
→ c’est dovecot qui est chargé de l’authentification des utilisateurs ;smtpd_sasl_path = private/auth
→ méthode de transmission des données à dovecot ;smtpd_sasl_auth_enable = yes
→ postfix est autorisé à accepter des authentifications ;broken_sasl_auth_clients = yes
→ permets d’indiquer aux clients qui se connectent une erreur dans l’authentification ;smtpd_sasl_security_options = noanonymous
→ les connexions anonymes sont exclues ;smtpd_sasl_local_domain = $myhostname
→ le nom du domaine local qui accepte les demandes d’authentification.
Pour éviter que notre serveur soit ouvert à tous les vents, nous allons restreindre les possibilités d’envois :
|
|
Nous n’allons pas regarder chacune des restrictions dans le détail (l’aide de postfix
le fait bien mieux que moi), mais simplement regarder celles qui sont utilisées ici :
Nous avons trois types des restrictions (dont les actions se ressemblent beaucoup), celles qui s’appliquent au destinataire d’un message que reçoit le serveur (smtpd_recipient_restrictions
), celles qui s’appliquent à l’étape helo<
de la réception des messages (smtpd_helo_restrictions
et celles qui s’appliquent à l’expéditeur d’un message qui passe par votre serveur (smtpd_sender_restrictions
).
La phase helo
est celle qui permet à deux serveurs de courrier de se présenter l’un à l’autre. Nous n’entrerons pas dans les détails de ce dialogue.
sont regroupées ici les courtes explications à toutes les restrictions que nous utilisons, sans distinction de leur champ d’application.
- permit_mynetworks → autorisation de mes réseaux (la variable
mynetworks
est définie plus loin) ; - permit_sasl_authenticated → autorisation des connexions sécurisées ;
- reject_unknown_sender_domain → rejet des domaines expéditeurs inconnus ;
- reject_unknown_recipient_domain → rejet des domaines destinataires inconnus ;
- reject_unauth_pipelining → rejet des commandes en pipeline non authentifié 4 ;
- reject_non_fqdn_hostname → rejet des serveurs qui n’ont pas de nom de domaine pleinement qualifié 5 ;
- reject_unauth_destination → rejet des destinations non authentifiées ;
- reject_invalide_hostname → rejet des noms d’hôtes invalides ;
- reject_non_fqdn_sender → rejet des expéditeurs qui n’ont pas de nom pleinement qualifié ;
- reject_unknown_sender_domain → rejet des domaines expéditeurs inconnus ;
- permit → autorisation du reste.
Viennent ensuite des paramètres de configuration liés au serveur lui-même :
|
|
alias_database
→ une table d’alias d’utilisateur ;mydestination
→ indique quels sont les domaines pour lesquels nous recevons du courrier ;relayhost
→ si notre serveur n’est pas le serveur final d’expédition, nous indiquons ici quel est ce serveur ;mynetworks
→ les réseaux (au sens IP) pour lesquels nous acceptons d’envoyer du courrier ;mailbox_size_limit
→ taille limite des boîtes aux lettres ;recipient_delimiter
→ valeur par défaut ;inet_interfaces
→ les interfaces réseau sur lesquelles le serveur de courrier s’attend à recevoir des commandes ;inet_protocols
→ les protocoles utilisés par le serveur de courrier (ipv4
,ipv6
ou comme ici, les deux) ;mailbox_command
→ la commande utilisée pour délivrer les messages dans les boîtes aux lettres ;local_recipient_maps
→ indique où doivent être recherchés les destinataires locaux ;virtual_transport
→ nom du programme chargé du transport des messages pour les domaines virtuels ;sender_canonical_maps
→ une table de conversion des utilisateurs locaux en adresse de courrier valide ;header_checks
→ une table utilisée pour vérifier les en-têtes des messages. En y recherchant des mots clefs, on tente de déterminer s’il s’agit de messages acceptables ou non. S’ils ne sont pas acceptables, ils sont rejetés.
|
|
Arrivent les paramètres de postscreen
. Il s’agit d’un mécanisme interne à postfix
qui était extérieur dans les anciennes versions. Ce mécanisme permet de distinguer les émetteurs légitimes des émetteurs de de spam à l’aide de plusieurs heuristiques dérivées du greylisting 6. Nous n’allons pas étudier les paramètres en profondeur, mais simplement parler des access_list
et des dnsbli_sites
.
postscreen_access_list
→ on autorise sans vérification nos réseaux puis les réseaux décrits sous formecidr
dans un fichier spécifique. Dans ce fichier, on pourra mettre les sous-réseaux des serveurs de google par exemple ;postscreen_dnsbl_sites
→ c’est une liste de serveurs qui compilent les domaines connus pour êtres des spammeurs. Si le domaine de l’expéditeur est dans ces listes, le message ne sera pas accepté.
Ajout d’un webmail
Pour faciliter l’accès au courrier même si l’on dispose que d’une connexion restreinte (depuis un hôtel par exemple), nous allons ajouter à notre configuration un logiciel de webmail. Celui que j’ai choisi est roundcube.
Il facile à utiliser, passe par imap
et sait dialoguer avec un serveur LDAP
.
Installation de RoundCube
Le problème majeur est l’installation de php avec nginx. C’est pourquoi j’ai fait un article spécifique.
Devinez quoi, c’est notre poudriere qui va encore faire le boulot pour nous. Pour fonctionner, roundcube a besoin de MySQL
(déjà présent), d’un serveur web (nous avons installé ngnix
) et de php.
cette fois-ci, je vous laisse faire
En plus de mail/roundcube
, nous aurons besoin d’autres extensions de php56
:
-
sysutils/php56-fileinfo
-
security/php56-openssl
-
security/php56-mcrypt
-
graphics/php56-exif
-
graphics/php56-gd
-
ftp/php56-curl
Pour les options deroundcube
, nous allons choisir : -
LDAP
-
GD
-
SSL
Une fois que votre poudriere est prête, lancez simplement l’installation de roundcube
, le reste devrait suivre.
Configuration de roundcube
Normalement l’installation s’est faite dans le répertoire /usr/local/www/roundcube
. Nous allons donc créer un dataset ZFS pour cette installation :
|
|
Changement de propriétaire
Nous allons changer le propriétaire et le groupe de ce répertoire :
|
|
Création de la base de données
RoundCube
, comme Redmine
, utilise une base de données. Celle-ci sera gérée par MySQL
.
|
|
Configuration de nginx
Il est nécessaire de faire un hôte virtuel dans la configuration de nginx
. Comme nous l’avions fait pour Redmine, nous allons créer le fichier de configuration dans /usr/local/etc/nginx/sites-availables
.
Ce fichier comporte plusieurs blocs de configuration que nous allons analyser (plus ou moins profondément).
|
|
Ce premier bloc indique que le serveur écoute sur le port 80
et définit les actions à faire lorsqu’il y reçoit une requête.
Si la requête ne contient pas son nom (server_name
), la requête est passée au serveur suivant, ce n’est pas son problème.
En revanche, si la requête est bien pour lui, il la réécrit (rewrite
), pour le même serveur avec la même URI
demandé, mais pour le protocole sécurisé, sur le port 443
. On indique aussi au client que cette redirection est permanente. La prochaine fois, il devrait faire sa requête directement sur le port 443
.
|
|
Ce second bloc indique que le serveur écoute sur le port 443
pour des connexions sécurisées avec SSL
. On spécifie aussi le nom du serveur qui doit être le même que celui de la requête.
|
|
Ici sont définis les chemins et les noms des fichiers de trace. Nous avons deux fichiers :
webmail.example.com-access.log
→ qui conserve les informations d’accès au service (qui, quand, depuis où, pourquoi faire) ;webmail.example.com.net-error.log;
→ qui est utilisé pour savoir pourquoi le serveur refuse démarrer ou de répondre aux requêtes. Il est souvent utilisé en période de mise au point du service.
j’aime bien avoir ces deux fichiers pour chacun des services http
que je propose sur mon serveur, cela permet de trouver plus rapidement ce qui ne va pas, les messages génériques (de nginx
lui même) allant dans les fichiers /var/log/nginx-access.log
et /var/log/nginx-error.log
).
|
|
Ce bloc définit l’utilisation de SSL
(ssl on
) ainsi que les chemins vers le certificat propre au site et la clef du certificat.
reportez-vous à mon article sur les certificats pour savoir comment obtenir le vôtre.
|
|
Ici, nous indiquons les paramètres de fastcgi
(`php-pfm</code)>) :
*fastcgi_param HTTPS on;
→ mode sécurisé https
activé ;
*fastcgi_keep_conn on;
→ on garde les connexions ;
*fastcgi_cache_valid 200 302 304 10m;
→ le cache est utilisé pour les réponses de type … ;
*fastcgi_cache_valid 301 1h;
→ le cache est purgé après une heure en cas d’erreur 301
;
*fastcgi_cache_min_uses 2;
→ indique le nombre de requêtes dont les résultats sont mis en cache ;
*fastcgi_buffers 256 4k;
→ défini le nombre de buffers (256) et leur taille (4k) ;
*fastcgi_busy_buffers_size 8k;
→ limite la taille de buffer occupé à 8k
;
*fastcgi_temp_file_write_size 8k;
→ limite la taille des buffers écrits temporairement sur disque.
|
|
Enfin, nous passons aux définitions de sécurité (entre autres) pour les différents répertoires contenus dans le répertoire de roundcube
.
On commence par définir la racine (/
). Le fichier d’index, celui qui est servi en priorité au client est index.php
et la racine du site roundcube
se trouve sur la machine dans le répertoire /usr/local/www/roundcube
.
Pour tous les autres répertoires dont le nom contient bin
, SQL
, config
, logs
, l’accès est interdit (deny all
). Idem pour d’autres répertoires au bloc suivant.
Même interdiction pour les répertoires dont le nom commence par un point (.
). En plus, la requête n’est pas conservée dans les fichiers de trace (access_log off
) et si le fichier de trace n’existe pas aucune alerte n’est envoyée.
Enfin, pour tous les fichiers dont l’extension est .php
, on utilise php-fpm
, avec la socket que nous avions définie plus haut.
je n’ai pas inventé ces paramètres, j’ai fait comme tout le monde, je les ai recopiés d’un autre site explicatif.
Faisons un lien de notre fichier de configuration vers /usr/local/etc/nginx/sites-available
:
|
|
Création du fichier config.inc.php
Dans le répertoire /usr/local/www/roundcube/config
se trouve le fichier config.inc.php.sample
. Nous allons le copier en config.inc.php
puis l’éditer pour le rendre conforme à nos souhaits.
|
|
Il faut changer la chaîne pass
par le mot de passe d’accès à la base de données de roundcube
que vous avez défini plus haut et changer le nom de la base de données (roundcubemail
devient roundcube
si vous avez suivi mes exemples).
En fin de fichier, dans la définition des plugins, nous allons ajouter sieve
:
|
|
La ligne $config['enable_installer'] = true;
permets de lancer l’installation à partir du navigateur. Nous supprimerons cette ligne quand nous aurons fini.
Démarrage de RoundCube
Avant de démarrer (ou redémarrer) nginx
avec la configuration de roundcube
, nous allons vérifier la conformité de la syntaxe de nos fichiers de configuration :
|
|
Si nginx
n’est pas configuré pour être lancé au démarrage, c’est le moment de le faire.
|
|
Puis nous pouvons démarrer nginx
:
|
|
Configuration de roundcube
dans le navigateur
Il faut se lancer et taper dans la barre d’adresse celle de votre serveur roundcube http://webmail.tamanoir.example.com/installer
.
Vous devriez arriver sur une page qui vous indique ce qui est correctement installé et ce qui ne l’est pas. Par exemple, il me manque les modules FileInfo
, Mcrypt
, Intl
et Exif
.
Je vais donc les installer avant d’aller plus loin.
oui, poudriere
sysutils/php56-fileinfo
;security/php56-openssl
;security/php56-mcrypt
;graphics/php56-exif
;graphics/php56-gd
. La suite met en place les tables dans la base de données MySQL. Et enfin, vous pouvez tester l’envoi de messages et la connexion au LDAP. Si tout est bon, il faut changer la ligne qui autorise l’installation dans le fichier de configuration (/usr/local/www/roundcube/config.inc.php
) et vous rendre à l’URLhttps://webmail.tamanoir.example.com
.
|
|
-
le MTA (Mail Transfert Agent) est le logiciel chargé d’acheminer les messages de serveur en serveur. C’est également par ce biais que votre logiciel de traitement de courrier (MUA, Mail User Agent) envoi vos messages vers votre serveur. ↩︎ ↩︎
-
le MDA (Mail Delivery Agent) est chargé de la distribution des messages dans les boîtes aux lettres. Les messages arrivent sur le serveur grâce au MTA qui le donne au MDA pour que celui-ci les glisse dans les bonnes boîtes aux lettres, et le MUA vient les chercher pour vous les présenter et vous permettre de les traiter. ↩︎
-
il faut bien sûr remplacer example.com par votre nom de domaine réel. ↩︎
-
le pipelining est un technique qui permet d’envoyer une série de commandes
smtp
au serveur, sans attendre la réponse pour accélérer les échanges. ↩︎ -
les noms d’hôtes pleinement qualifiés (Fully Qualified Domain Name, FQDN) sont les noms des machines avec leurs noms de domaines. Voyez la note 1({{site.url}}/FreeBSD-bind/#fn:1) de l’article sur le DNS. ↩︎
-
le greylisting fonctionne sur le principe que les logiciels de spammeurs sont mal et vite écrits et ne respectent les RFC qui régissent les échanges entre serveurs de courrier. En voici le principe : à la connexion d’un expéditeur (serveur ou logiciel client), le triplet adresse ip, expediteur, destinataire est recherché dans une table dynamique. S’il est trouvé, le message est accepté. En revanche, s’il n’est pas trouvé, il est ajouté à cette table et le message “Le serveur est occupé, veuillez réessayer plus tard” est retourné au serveur émetteur. Les logiciels de spammeurs ne réessayent pas, les logiciels bien écrits et bien configurés réessayent. ↩︎