Ceci est une ancienne révision du document !
Quitter Gandi
Ça sent le sapin, ça se précise… petites notes diverses pour gérer le bazar.
Mails
- Synchroniser des boites mails, pour ne pas perdre lors du transfert : imapsync
Prestataire mail : rien de bien pertinent la dernière fois que j'ai regardé, surtout vu qu'il me *faut* ces fichus jokers. Possible de transférer une partie des boites, temporairement, chez infomaniak ou autre… Ou simplement tout mettre en alias sur une seule, mais c'est pas top.
Il faut surtout apprendre à les héberger soi-même. Pas le choix. Et à cause de DKIM/DMARC il semble mieux de gérer les dns soi-même aussi dans cette affaire… mais on va essayer d'y aller petit à petit.
Serveurs mails
Besoins
- Mails avec joker ( moi.*@mondomaine.com et pas du “+” ! retrouver le nom de la fonction). C'est pas du “catchall” mais ça sert de piste. wildcard !
- pigeonhole (dovecot) a l'air de supporter ça : https://datatracker.ietf.org/doc/html/rfc5233.html
- pour opensmtpd il est très simple de changer le caractère + qui sert à dire d'ignorer tout ce qu'il a après, et proposer par exemple le point. Idem avec postfix.
- Multidomaine (gérer les autres aussi)
- Pouvoir faire des listes d'attentes pour limiter le nombre de mail sortant suivant les fournisseurs (moins de X par minute en direction des Gafams, bloquer temporairement en cas de fonctionnement bizarre) ; se paramètre sur postfix (cf doc Chatons)
Liste
À voir si ça répond aux demandes
- https://modoboa.org/fr/ : existe en version fr ce qui est un gros plus. Cependant, je ne suis pas certaine que l'interface m'apporte tant que ça par rapport à des trucs sur mesure… Mais pas éliminé pour autant.
https://mailinabox.email/: comme son nom l'indique, c'est une boite, et pas conseillé si on veut mettre les mains dans le cambouis.- https://www.iredmail.org/ : la doc est…. pas terrible…
https://github.com/sovereign/sovereign: playbooks Ansible, c'est sans doute bien à terme mais pas pour apprendre.https://www.mailpile.is/ : dev bloqué depuis pas mal d'années car ils attendaient de réécrire en python 3…-
- https://docs.mailcow.email/prerequisite/prerequisite-system/ : il n'aime pas les containers.
- proxmox mail : à première vue c'est un proxy qui permet de filtrer le trafic, ça ne dispense pas d'installer postfix/dovecot etc derrière, mais ça peut aider dans la gestion du flux. De bons retours sur cet aspect : https://forum.chatons.org/t/recette-pour-serveur-mail-securise/323/16
https://maddy.email/: juste en CLI, en beta… non.AlternCpas de MAJ depuis 7 ans, tourne sur du vieux debian, plein de tickets ouverts.. Non !- https://github.com/postalserver/postal ; actif et pas mal de choses sympa mais configuré pour tourner avec Docker. Ceci dit de ce que je vois sur l'installation, ça parait pas si bloquant… hum…
- https://mailu.io : j'avais testé, sympa de mémoire mais à voir si ça répondra aux besoins. Docker aussi.
- https://mailu.io/1.9/webadministration.html#aliases pour potentiel wildcard
- https://github.com/docker-mailserver/docker-mailserver : comme son nom l'indique.
https://poste.io/: fournit même le café, pardon le webmail. Enfin sauf que c'est du semi-open et que la version communautaire n'a pas tout. De toute façon c'est du Docker, sans regret !
Interfaces seules :
- Modoboa (listé plus haut)
- https://webmin.com/ qui a un script “usemin” semblant faire le taf (grosse surcouche par contre)
- Interface de gestion : https://mailboy.manurevah.com/
- https://www.ima.jungclaussen.com/ (ispmail)
- postfix admin
Notes variées :
- “mail en multi-domaine (TLS/SNI) avec la pile suivante: Postfix, Dovecot, Rspamd, Modoboa (donc avec NginX, uWsgi, Postgresql…).” Source
- L'ajout des antivirus fait monter énormément le besoin matériel (RAM, CPU). Mais vraiment, hein. “Prévoir minimum 4Go de ram de base, monter à 8Go si y'a du webmail et portail de configuration”
- Doc de référence :
- https://workaround.org/ “The ISPmail guide / A complete and educational guide to running your own mail server on Debian”
- https://rodolphe.breard.tf/article/mettre-en-place-un-serveur-mail-perso/ : OpenSMTPD/Dovecot/rspamd/
- https://blog.debugo.fr/serveur-messagerie-complet-postfix-dovecot-ldap-rspamd/ : Postfix/Dovecot/rspamd/Openldap
- Nécessité absolue de fail2ban et bien checker les logs, sinon on va se faire grave hacker la figure. https://forum.chatons.org/t/recette-pour-serveur-mail-securise/323/39
Alternatives
- Gestion du spam (rspamd) : https://www.mailcleaner.org/ ; amavis ?
- Intérêt de postfix, intégration d'outils comme postscreen (qui permet de mettre un délai avant de répondre, ce qui dégage des zombies)
Webmail :
- https://snappymail.eu est vraiment sympa, dans la démo que j'ai eu.
Nom de domaine
L'augmentation est énorme pour un service qui passe à zéro. Donc va falloir migrer… Vu qu'on va gérer ses propres DNS avec le mail, le seul impératif du registrar sera donc de pouvoir pointer son DNS.
https://www.bookmyname.com est une bonne possibilité. Prix coûtant, ça fait un peu bricolage de tech mais, ben… c'est presque à ce genre de personne qu'on peut le plus se fier ? Ça reste une filiale Iliad/Scaleway.
Bonnes pratiques pour ne pas passer pour un spammeur
Configurer le reversedns et, dans l'absolu, avoir un serveur dédié uniquement au mail, pas d'autres ports ouverts ni rien. C'est une marque de confiance et ça évite que les “gros” pensent qu'on s'est fait trouer parce qu'on a des ports bizarres ouverts.
Limiter l'envoi de mails à la minute, par utilisateur :
Voir aussi diverses astuces sur https://wiki.chatons.org/doku.php/heberger/administration_systeme_avancee/mail
Deux adresses mails sont nécessaires quand on gère son mail, afin de répondre à des RFC :
- postmaster@domain
- abuse@domain
Ça peut être des aliases, mais si ça n'existe pas et qu'un autre fournisseur veut me contacter, ça va baisser la réputation.
Anti-spammeurs de l'enfer
Les gens qui bloquent pour les autres, et dont il faut comprendre les règles :
- VadeSecure
- Directement tester chez plein de monde avec le lien pour débloquer : https://multirbl.valli.org/
- Au moment où je commence à mettre le serveur en place, mon ip est bloqué par 5 opérateurs, échoue ici et là, et est globalement valide sur la centaine d'autres. Je testerais la procédure une fois le serveur mail installé, car les liens sur lesquels je clique expliquent bien qu'ils ne débloquent que si on a un serveur mail. Bref, par défaut, on y sera forcément au début.
Pas à pas
Version en travail, non testée, reprenant les points clés vu dans les divers tutos et adaptés à ma propre façon de fonctionner.
Paramétrage des DNS, première partie
Ça peut se faire par la suite mais comme ça met toujours un peu de temps à se propager… et autant avoir rapidement le nom de domaine dispo.
- Nom de sous-domaine pour le serveur mail, MX en A et AAAA vers lui depuis le domaine principal.
- ReverseDNS sur la machine.
- Tester tout ça
Quelque chose dans ce genre :
mail.example.org. IN A a.b.c.d mail.example.org. IN AAAA 2001:a::b example.org. IN MX 10 mail.example.org.
Le faire sur ipv6 si possible… Aujourd'hui tous les serveurs devraient le permettre.
Il faut aussi configurer son Reversedns et ça, c'est permis ou non par l'hébergeur (dans l'interface web de gestion de la machine). La machine prend le “nom” du serveur mail.
Sur Oneprovider, pas de souci. Depuis OVH telecom, ça se fait aussi, dans la partie telecom justement.
Ensuite, pour tester :
dig +short -x "a.b.c.d" @9.9.9.9 dig +short -x "2001:a::b" @9.9.9.9
L'un et l'autre doivent donner le nom de domaine configuré pour les ip en question. Le “@9.9.9.9” à la fin permet de passer par l'extérieur, si on teste en local sur un ordi local, dig ne retourne rien…
Installation de l'OS
- Partir d'une installation fraîche, ne pas tenter de saut de version entre Debian (cf Migration, par ISPmailtutorial ).
- La machine hébergeant le mail ne doit servir qu'au mail : pas de site web etc. Même le webmail sera ailleurs. Cela améliore la réputation du serveur.
- Utiliser LVM, cela permettra les snapshots (entre autres avantages).
Partitionner de cette façon :
- sda1 en partition primaire pour /boot. 510MB minimum (option par défaut de Debian, en ext2) ; mais trop ça peut aussi poser souci.
- sda2 en LVM. Le VG sera divisé de cette façon côté LV (à adapter suivant la taille, je préfère prendre mes aises) :
/
pour la base du système, ext4, minimum 20 GB, prévoir direct 50 pour ne plus se poser de question/tmp
, 5 GB, ext4/var/vmail
(beaucoup, je commence avec 100 GB), ext4/var/log
: ça c'est si on se plante avec logrotate et autres données, ça évitera de casser le système. 10 GB.- swap : autant que de RAM ; ou si vraiment beaucoup de ram, au moins 2GB.
- Il faudra sans doute paramétrer fstab afin d'utiliser les labels et non les UUIDs et éviter les conflits lors de l'utilisation des snapshots
- Il est possible sans problème de faire un snapshot de root, puis de revenir en arrière. Je ne sais pas si le merge en arrière peut être pris en compte autrement qu'avec un reboot, par contre.
Une fois le système installé :
- Paramétrer Grub pour qu'il ne mette pas 4 secondes à se lancer…
nano /etc/default/grub
- grub-mkconfig -o /boot/grub/grub.cfg
- Installer sudo et y ajouter l'user de base :
apt install sudo
- usermod -a -G sudo zatalyz
- Paramétrer ssh.
- Remplacer
/etc/ssh/sshd_config
par celui personnalisé (ici) - Ajouter la clé ssh pour pouvoir se co :
mkdir /home/zatalyz/.ssh nano /home/zatalyz/.ssh/authorized_keys # Mettre la clé publique dans ce fichier chown -R zatalyz: /home/zatalyz/.ssh chmod 0700 /home/zatalyz/.ssh/ chmod 0600 /home/zatalyz/.ssh/authorized_keys
- Redémarrer SSH :
service ssh restart
Se connecter en SSH (on n'est plus root !) et finaliser la préparation préliminaire :)
sudo apt update sudo apt upgrade sudo apt install apt-listbugs debsums apt-listchanges
On peut aussi installer quelques outils utiles :
sudo apt install git binutils net-tools curl htop
Pour la suite et afin de ne pas se surcharger en paquets non voulu, on va désactiver “recommandés” et “suggérés” d'APT (on avisera suivant les recommandations). Créer un fichier dans /etc/apt/apt.conf.d/
:
sudo nano /etc/apt/apt.conf.d/00recommandperso
Mettre le contenu suivant :
APT::Install-Recommends "0"; APT::Install-Suggests "0";
Et sudo apt update
(je ne sais pas si c'est utile mais dans le doute…).
Et on fait un snapshot de root à ce moment, pour revenir “à zéro” si on se plante trop dans nos essais d'installation.
sudo lvcreate -L 20g -s -n root_snap_$(date --iso) /dev/VgPoste/root
S'il y a un souci, on revient en arrière :
sudo lvconvert --merge /dev/VgPoste/root_snap_XXX
Et s'il y a un souci pour recréer un snapshot après ça, c'est
sudo lvchange --refresh VgPoste
Sécurisation du serveur
Il y aura plusieurs itérations sur le sujet au fil des logiciels installés, mais il me semble important de partir sur une base déjà aussi saine et avec quelques outils que je trouve utile.
La configuration de SSH était la première partie (et changer le port SSH permet déjà de bloquer une partie des noceurs, les plus idiots, ok).
On va installer fail2ban, rkhunter, et vérifier que la configuration du pare-feu est bonne. Notez que sans les “recommands”, en cas d'erreur on n'aura pas de mail système sur le sujet, mais comme on va installer un vrai serveur mail derrière… on va éviter de mélanger divers paquets de MTA.
Par ailleurs, il y a débat sur l'intérêt de ce genre de logiciels. Je trouve que ça apporte un peu de surveillance voir de mitigation sur certaines menaces, sans nuire au système, donc… je les utilise. Je suis toujours intéressée par une discussion sur le sujet et à améliorer mes pratiques.
Rkhunter
rkhunter (pour Rootkit Hunter) est un programme qui essaye de détecter les rootkits, portes dérobées et exploits. Pour cela, il compare le hash SHA256, SHA512, SH1 et MD5 des fichiers importants avec les hash connus, qui sont accessibles à partir d'une base de données en ligne. Il alerte également l'utilisateur lorsqu'il trouve des permissions qu'il juge anormales, des fichiers cachés, des chaînes suspectes dans le kernel etc.
De par l'exhaustivité des tests qu'il effectue, et à cause du nombre de systèmes sur lesquels il tourne, rkhunter renvoie généralement de nombreux avertissements. L'analyse de ces avertissements (warnings) nécessite une bonne connaissance des systèmes Unix. Dans une écrasante majorité des cas, ces avertissements sont bénins et peuvent être ignorés.
Source : Ubuntu-fr
J'ai souvenir qu'il est effectivement bavard. Et aussi que ce n'est pas une sécurité en soi, juste un outil permettant de détecter certains problèmes.
sudo apt On le configure un chouia
sudo nano /etc/rkhunter.conf
Modifier les options suivantes pour qu'elles aient ces valeurs :
UPDATE_MIRRORS=1 MIRRORS_MODE=0 #WEB_CMD="/bin/false" ALLOWHIDDENDIR=/etc/.git ALLOWHIDDENDIR=/dev/.lxc ALLOWHIDDENDIR="/dev/.udev" ALLOWHIDDENDIR="/dev/.static" ALLOWDEVFILE="/dev/.udev/rules.d/root.rules" PKGMGR=DPKG ALLOW_SSH_PROT_V1=0
Après ces modifications, exécuter ceci :
rkhunter -C rkhunter --propupd
Modifier aussi /etc/default/rkhunter
.
CRON_DAILY_RUN=“true”
CRON_DB_UPDATE=“true”
APT_AUTOGEN=“yes”
Quand à envoyer un mail quotidien… ça fait du bruit, qu'il se passe un truc ou non. On verra par la suite, d'autant qu'il faut un service d'envoi de mail.
Et on se fait un petit test en mettant à jour l'ensemble puis en affichant juste ce qui est avec des warnings :
rkhunter --update rkhunter --list rkhunter -c --rwo
Fail2ban
Fail2ban va limiter les attaques d'entrée par bruteforce. En théorie, évidement, la configuration du système ne devrait pas permettre le moindre brut force, maiiiis bon, dans le doute…
apt-get install fail2ban whois python3-systemd
Les deux derniers sont des “recommands” qui semblent réellement utiles.
On crée un fichier dans /etc/fail2ban/custom.conf
[DEFAULT] ignoreip = 127.0.0.1 # ajouter votre propre ip si vous n'êtes pas en dynamique, ça évite de se faire mettre à la porte pour une bêtise [sshd] enabled = true port = 223 # Mettre son port "custom" si ce n'est pas celui par défaut (22) backend = systemd #vital pour que ça marche sauf si les logs etc ne sont pas gérés via systemd...
Relancez fail2ban et vérifier ce qu'il raconte :
sudo service fail2ban restart sudo fail2ban-client status
Il faudra ajouter les “jails” des services utilisés ici à mesure qu'on active des trucs.
Pare-feu
Bon, là, ça devient compliqué. Dans la majorité des cas, le serveur est déjà derrière un pare-feu, les ports autorisés le sont explicitement. Chez moi, derrière la box. Un coup de nmap ip
permet de vérifier les ports ouverts. Sur Numenaute, de la même façon, le proxy protège les containers et vm derrière ; mais là c'est sur lui qu'il faut vérifier que tout est propre.
Là, je ne vais pas trop m'y attarder, parce que ma box fait son taf…
Il faut tout de même s'assurer que certains ports seront accessibles :
- 25 : port smtp de base
- 143 : imap avec STARTTLS
- 587 : smtp avec STARTTLS
Vérifier l'host
Vérifier que /etc/hosts a un nom de domaine cohérent (si renseigné) avec notre reversedns. Dans mon cas il avait doublé “poste” ce qui faisait un domaine en “poste.poste.mondomain.org”.
En cours
Ispmail recommande Postfix et un webmail. Plus précisément cette liste : mariadb-server postfix postfix-mysql dovecot-mysql dovecot-pop3d dovecot-imapd dovecot-lmtpd dovecot-managesieved apache2 php7.0 adminer rspamd redis-server pwgen swaks mutt certbot ca-certificates fail2ban
Tycho, lui, semble installer (manque la vraie liste) : acmed (via git), opensmtpd, dovecot-lmtpd, rspamd
Mais, là, on va adapter. Et donc se compliquer un peu la tâche…
- Pas de webmail sur ce serveur, mais on va utiliser des outils graphiques sur une page web pour “voir” les trucs… Adminer/phpmyadmin, stats, etc. Donc, on met Apache. On va aussi utiliser deux domaines, un pour le mail (configurer avec le reversedns), et un pour ces logiciels (afin de séparer torchons et serviettes). Ce n'est pas obligatoire mais ça me plait.
- On va
tenter d'utiliser opensmtpd plutôt que postfixse simplifier la tâche à ce stade et rester avec postfix. Il est abondamment documenté, de façon officielle et officieuse, pas pire qu'un autre, extrêmement versatile. Certains sysadmins lui reprochent de venir “du fond des âges” et d'avoir cumulé pas mal de trucs au fil du temps, critique sans doute fondée vu comme elle est partagée, mais… il permet de faire ce qu'on veut, ce qui est le principal. - J'ai du mal avec mutt, on va rester avec bsd-mailx
- On va tenter d'utiliser ACMEd plutôt que certbot ? Non, pas pour le moment, je rame déjà assez comme ça…
Bref à ce stade, l'objectif est uniquement de faire tourner un serveur mail “perso”, une fois la base maîtrisée, on ajoutera des fioritures.
Descriptif des logiciels à installer
sudo apt install mariadb-server redis-server
- Avec postfix, mariadb ne sert qu'à stocker les infos des utilisateurs et des domaines (pas les mails), si bien que sa taille devrait rester très faible. À voir comment ça marche avec opensmtpd. Note : on se co en root à mariadb depuis le localhost, donc sans mot de passe, et ajouter un mot de passe à root peut ajouter du bazar.
- redis-server gère plus du cache, façon dite plus rapide de gérer le spam et ses données.
Pour Postfix :
sudo apt install postfix postfix-mysql
Pour dovecot, ça ne devrait pas changer :
sudo apt install dovecot-mysql dovecot-pop3d dovecot-imapd dovecot-lmtpd dovecot-managesieved
- dovecot-mysql : pour communiquer avec mysql et donc partager la même base d'utilisateurs
- dovecot-pop3d : qui utilise encore pop3 ? à voir si on le gère ou pas… je serais d'avis de laisser, pour le moment, et ajouter plus tard au besoin
- dovecot-imapd : pour utiliser l'IMAP donc obligé
- dovecot-lmtpd : une fois arrivé sur le serveur, va aiguiller les mails aux bons utilisateurs (MDA)
- dovecot-managesieved : permet aux utilisateurs de définir leurs règles de filtre.
Chasse aux spams :
sudo apt install rspamd
- rspamd : Un logiciel tiers qui traite les spams et gère la signature automatique des clés de domaine (DKIM).
Outils pratiques
sudo apt install adminer swaks bsd-mailx
- adminer : remplaçant de phpmyadmin. On verra…
- swaks : “couteau suisse du mail”, fournit divers utilitaires
- bsd-mailx : permet de lire les mails sur le serveur, utile lors des tests.
Tout un programme :
git clone https://github.com/breard-r/acmed
Il faut un certificat SSL et un truc aux petits oignons ça serait mieux. Mais ça va demander un peu de prise en main.
Logiciels à installer en une ligne
Allez, hop, on va tester ça : c'est peut-être “trop”, ça va peut-être poser plein de questions pénibles, mais on essaie…
sudo apt install mariadb-server redis-server apache2 php postfix postfix-mysql dovecot-mysql dovecot-pop3d dovecot-imapd dovecot-lmtpd dovecot-managesieved rspamd adminer swaks bsd-mailx
Note : il y a quelques bugs répertoriés à l'heure où j'installe ces lignes, mais pas sur des paquets dont je peux me passer…
bogues de gravité grave sur apache2 (→ 2.4.57-2) <En attente de traitement> b1 - #967010 - apache2: last debian 10.4 , last apache avail from repo hangs on install (and start phase) bogues de gravité serious sur dovecot-core (→ 1:2.3.19.1+dfsg1-2.1) <En attente de traitement> b2 - #895823 - cannot purge dovecot-common bogues de gravité grave sur libunwind8 (→ 1.6.2-3) <Transférés> b3 - #994510 - libunwind8 abuses setcontext() causing SIGSEGV on i386 with glibc >= 2.32 Résumé : apache2(1 bogue), libunwind8(1 bogue), dovecot-core(1 bogue)
Il va y avoir quelques questions de configuration mais vraiment rien de complexe.
Et dans l'absolu, acmed…
sudo apt install git libssl-dev build-essential pkg-config git clone https://github.com/breard-r/acmed
Mais… non, écoute, là, on va faire simple et moche, j'ai déjà assez de trucs à adapter.
sudo apt install certbot python3-certbot-apache python3-icu
Installation des logiciels
Finalement :
sudo apt install mariadb-server redis-server apache2 php postfix postfix-mysql dovecot-mysql dovecot-pop3d dovecot-imapd dovecot-lmtpd dovecot-managesieved rspamd adminer swaks mutt certbot python3-certbot-apache python3-icu
Quand Postfix demande sa configuration, répondre “Site Internet”. Vérifier le nom de domaine.
Faire de nouveau un petit sudo grep -nri "poste" /etc/ --exclude-dir=lvm
pour vérifier qu'il n'y a pas de doublon ou de nom bizarre qui traîne.
Refaire un snapshot parce que c'est long d'installer ces logiciels.
sudo lvcreate -L 20g -s -n snap_root_$(date --iso)_logicielsok /dev/VgPoste/root
Apache et certbot
Ouais, Apache, parce que je le connais, mais vu ce qu'il y a à faire, Nginx suffira aussi.
On se crée une entrée DNS pour un sous-domaine qui permettra de gérer la partie “web” du serveur (A et AAAA). Je l'ai appelé “lapin”. Ensuite, on crée un dossier et un index (avec un simple hello dedans à ce stade) et on paramètre apache en mode hyper basique (on y reviendra). On fait aussi une page pour la partie “mail”, cela permettra à let's encrypt d'avoir une réponse et à qui cherche le domaine de savoir “c'est quoi”.
Fail2ban
Puisqu'on a Apache, autant ajouter les lignes suivantes dans notre fail2ban. Ainsi que ce qui concerne les autres logiciels installés :
- /etc/fail2ban/jail.d/custom.conf
[apache-auth] enabled = true [apache-badbots] enabled = true [apache-noscript] enabled = true [apache-overflows] enabled = true [apache-nohome] enabled = true [apache-botsearch] enabled = true [apache-fakegooglebot] enabled = true [apache-modsecurity] enabled = true [apache-shellshock] enabled = true [dovecot] enabled = true port = pop3,pop3s,imap2,imaps,submission,465,sieve [postfix] enabled = true [sieve] enabled = true
Ne pas oublier de redémarrer fail2ban ensuite.
fail2ban-server -t systemctl restart fail2ban
Html
sudo mkdir /var/www/lapin sudo mkdir /var/www/poste
Une page web “propre” quand même…
sudo nano /var/www/poste/index.html
- /var/www/poste/index.html
<!DOCTYPE html> <head> <html class="js desktop" lang="fr" dir="ltr"> <meta http-equiv="Content-Type" content="text/html; charset=utf8" /> <!-- meta --> <meta name="description" content="Mail server."> <meta name="author" content="Lievre"> </head> <body> Ceci est un serveur mail. En cas de problème, merci de contacter l'adresse en abuse@. <br>This is a mail server. If you have any problems, please contact the abuse@ address. </body>
sudo nano /var/www/lapin/index.html
- /var/www/lapin/index.html
<!DOCTYPE html> <head> <html class="js desktop" lang="fr" dir="ltr"> <meta http-equiv="Content-Type" content="text/html; charset=utf8" /> <!-- meta --> <meta name="description" content="Ceci n'est pas un terrier de lapin."> <meta name="author" content="Lievre"> </head> <body> Lapin ! </body>
Puis les droits
sudo chown -R www-data: /var/www/lapin sudo chown -R www-data: /var/www/poste
Apache
sudo a2dissite 000-default.conf sudo nano /etc/apache2/sites-available/lapin.conf
Mettre ça :
<VirtualHost *:80> ServerName lapin.example.org DocumentRoot /var/www/lapin </VirtualHost>
Idem sur la poste.
sudo nano /etc/apache2/sites-available/lapin.conf
<VirtualHost *:80> ServerName poste.example.org DocumentRoot /var/www/lapin </VirtualHost>
Puis les commandes suivantes.
sudo a2ensite lapin.conf sudo a2ensite poste.conf sudo systemctl reload apache2
Se rendre sur le web et voir que la page “lapin” et “poste” sont bien là.
Et maintenant on crée un certificat mais juste pour le domaine (hé, on limite les trucs autogénérés dans Apache !) :
sudo certbot certonly --webroot --webroot-path /var/www/lapin -d lapin.example.org sudo certbot certonly --webroot --webroot-path /var/www/poste -d poste.example.org
Puis on crée le fichier apache pour https : sudo nano /etc/apache2/sites-available/lapin-https.conf
(et refaire pareil sur la poste).
<VirtualHost *:443> ServerName lapin.example.org DocumentRoot /var/www/lapin SSLEngine on SSLCertificateFile /etc/letsencrypt/live/lapin.example.org/fullchain.pem SSLCertificateKeyFile /etc/letsencrypt/live/lapin.example.org/privkey.pem </VirtualHost>
On va aussi modifier (re) /etc/apache2/sites-available/lapin.conf
(et poste…) et ajouter ça à la fin mais avant la fermeture de la balise </VirtualHost>
:
RewriteEngine On RewriteCond %{REQUEST_URI} !.well-known/acme-challenge RewriteRule ^(.*)$ https://%{SERVER_NAME}$1 [R=301,L]
Enfin on active ssl, le module rewrite, le site https puis on relance apache.
sudo a2enmod ssl sudo a2enmod rewrite sudo a2ensite lapin-https.conf sudo a2ensite poste-https.conf sudo apachectl -t sudo apachectl graceful
Enfin, vu qu'on a un certbot sur-mesure, il faut lui préciser de redémarrer les logiciels quand le certificat est renouvelé (en théorie rien à faire de ce côté, il gère seul quand demander le renouvellement à ce stade). On édite /etc/letsencrypt/cli.ini
et on ajoute cette ligne :
post-hook = systemctl restart postfix dovecot apache2
Base de donnée
On commence en ligne de commande. Ça va bien se passer.
Passons root afin de pouvoir bidouiller mysql sans mot de passe (sinon on ne peux rien faire), lançons mysql puis créons la première database.
sudo -i mysql CREATE DATABASE mailserver;
On va créer 2 users, mailadmin et mailserver (ce dernier ayant seulement le droit de lire la bdd du même nom). Comme mailadmin sera admin, trouvez-lui un nom personnalisé. Générez aussi une phrase de passe pour chaque utilisateur et stockez ça dans votre gestionnaire de clé.
Adaptez les commandes suivantes à ces personnalisations :
grant all on mailserver.* to 'mailadmin'@'localhost' identified by 'PHRASE DE PASSE'; grant select on mailserver.* to 'mailserver'@'127.0.0.1' identified by 'PHRASE DE PASSE';
Pour la suite, je suis presque bêtement ISPmail. Toutes les commandes sont dans mysql.
USE mailserver; CREATE TABLE IF NOT EXISTS `virtual_domains` ( `id` int(11) NOT NULL auto_increment, `name` varchar(50) NOT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; USE mailserver; CREATE TABLE IF NOT EXISTS `virtual_users` ( `id` int(11) NOT NULL auto_increment, `domain_id` int(11) NOT NULL, `email` varchar(100) NOT NULL, `password` varchar(150) NOT NULL, `quota` bigint(11) NOT NULL DEFAULT 0, PRIMARY KEY (`id`), UNIQUE KEY `email` (`email`), FOREIGN KEY (domain_id) REFERENCES virtual_domains(id) ON DELETE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=utf8; USE mailserver; CREATE TABLE IF NOT EXISTS `virtual_aliases` ( `id` int(11) NOT NULL auto_increment, `domain_id` int(11) NOT NULL, `source` varchar(100) NOT NULL, `destination` varchar(100) NOT NULL, PRIMARY KEY (`id`), FOREIGN KEY (domain_id) REFERENCES virtual_domains(id) ON DELETE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
Et on va à présent peupler notre base de donnée, et c'est là qu'on adapte un peu le tuto… Bien remplacer “example.org” par notre propre nom de domaine ! Et celui sans le sous-domaine, si j'ai bien suivi…
On quitte un instant mysql et on va générer un mot de passe salé avec dovecot :
sudo doveadm pw -s BLF-CRYPT
Bien le noter et le mettre à la place de celui de l'exemple…
Le code à adapter à présent ! On revient dans mysql
et :
REPLACE INTO mailserver.virtual_domains (id,name) VALUES ('1','example.org'); REPLACE INTO mailserver.virtual_users (id,domain_id,password,email) VALUES ('1', '1', '{BLF-CRYPT}$2y$05$.WedBCNZiwxY1CG3aleIleu6lYjup2CIg0BP4M4YCZsO204Czz07W', 'john@example.org'); REPLACE INTO mailserver.virtual_aliases (id,domain_id,source,destination) VALUES ('1', '1', 'jack@example.org', 'john@example.org');
Adminer
Étape facultative.
On va utiliser adminer pour nous aider un peu. On rebidouille /etc/apache2/sites-available/lapin-https.conf
pour ça. Comme toujours avant </VirtualHost>
, on ajoute une ligne de ce genre :
Alias /adminer /usr/share/adminer/adminer
Ça n'a hélas pas l'air de bien marcher si on met une autre adresse que “adminer” (souci de chemin de css codé en dur quelque part)… Comme mettre ce genre de logiciel ouvre une faille (suffirait de brute-forcer la page d'authentification) on va la désactiver une fois nos modifs faites. C'est le plus efficace. On pourrait aussi ajouter un mot de passe en plus, s'appuyer sur fail2ban, etc, mais condamner la porte est plus efficace que de rajouter des verrous, et puis là c'est aussi plus facile à tout point de vue.
Pour prendre ça en compte :
sudo systemctl reload apache2
La page devrait être accessible à l'adresse demandée. Rentrer l'identifiant de “mailadmin” et sa phrase de passe. Laissez “localhost” et “database” vide, on s'en fout.
On peut contrôler visuellement que les tables et leurs données sont cohérentes.
Postfix et Dovecot
Ici on suit très bêtement https://workaround.org/ispmail/bullseye/making-postfix-get-its-information-from-the-mariadb-database/ sans oublier de changer “example.org” par notre nom de domaine. La partie dite “facultative” n'est pas facultative (on ne crée pas d'alias catch-all mais on crée quand même de quoi gérer les alias et les redirections entre eux…).
Idem sur la suite avec Dovecot et LMTP, rien de nouveau face au tuto.
Quota
Je personnalise en français le message aux utilisateurs :
- /usr/local/bin/quota-warning.sh
#!/bin/sh PERCENT=$1 USER=$2 cat << EOF | /usr/lib/dovecot/dovecot-lda -d $USER -o "plugin/quota=maildir:User quota:noenforcing" From: postmaster@webmail.example.org Subject: Quota warning - $PERCENT% reached FR : Votre boîte aux lettres ne peut stocker qu'un nombre limité d'e-mails. Actuellement, elle est pleine à $PERCENT%. Si vous atteignez 100 %, les nouveaux courriels ne pourront plus être stockés. Merci de votre compréhension. EN : Your mailbox can only store a limited amount of emails. Currently it is $PERCENT% full. If you reach 100% then new emails cannot be stored. Thanks for your understanding. EOF
Et pour qu'imap affiche le quota restant :
sudo nano /etc/dovecot/conf.d/20-imap.conf
Avoir la ligne suivante :
mail_plugins = $mail_plugins imap_quota imap_sieve
Systemd, ton univers impitoyable
Par contre (et on aurait du le faire plus tôt…) on va se modifier le système de log histoire de suivre ce qui peut se passer
sudo apt install rsyslog sudo nano /etc/systemd/journald.conf
Décommenter et vérifier les 3 lignes suivantes :
SystemMaxUse=512M SystemMaxFiles=100 ForwardToSyslog=yes
Sinon, parait que la commande suivante permet d'avoir les logs “mails” de postfix :
journalctl -ru postfix@-.service
Le -r c'est pour inverser l'ordre, avoir les lignes les plus récentes au début.
En gros postfix.service ça doit être les logs du démon postfix, et postfix@-.service ceux de son pool de mails. Relancer systemd :
systemctl restart systemd-journald.service
Quelques tests
Vérifier que la config de postfix est propre :
postfix check
On fait un test de mail en local (pas sur example.org hein !) :
swaks --to john@example.org --server localhost
Et on peut même envoyer un vrai mail, depuis une boite “ailleurs”, vers cette adresse ! Ça marche ! Il est l'heure de faire une danse de la joie.
Mais ça ne suffit pas… Faut les envoyer aussi et c'est là qu'on attaque la partie sérieuse.
Permettre aux alias d'envoyer ?
Je ne le fais pas “là” parce que je ne suis pas sûre de moi… Fin https://workaround.org/ispmail/bullseye/relay-outoing-email-through-postfix/ c'est sybillin.
J'ai créé quand même /etc/postfix/mysql-allow-alias-send.cf
:
user = mailserver password = hosts = 127.0.0.1 dbname = mailserver query = SELECT email FROM virtual_users WHERE email='%s' UNION SELECT destination FROM virtual_aliases WHERE source='%s'
Mais pour le faire prendre en compte ? je crois que c'est “ça” :
postconf smtpd_sender_login_maps=mysql:/etc/postfix/mysql-email2email.cf,mysql:/etc/postfix/mysql-allow-alias-send.cf
Je le testerais… plus tard, si le reste marche.
Autodécouverte par Thunderbird etc
Les logiciels de courriel correctement fichus peuvent chercher leur info à https://example.org/.well-known/autoconfig/mail/config-v1.1.xml
. Notez la subtilité : pas le relais mais bien le domaine de base.
Donc, on ajoute ce fichier, soit directement “là”, soit dans un autre dossier et on fait un joli alias dans apache
- /etc/apache2/sites-enabled/monsite.conf
Alias /.well-known/autoconfig/mail /var/www/monsite.org/autoconfig-mail
Redémarrer Apache.
Dans ce dossier, on va donc mettre config-v1.1.xml
qui va contenir ceci (copié directement de https://workaround.org/ispmail/bullseye/mail-client-auto-configuration-2/ ) :
<?xml version="1.0" encoding="UTF-8"?> <clientConfig version="1.1"> <emailProvider id="workaround.org"> <domain>workaround.org</domain> <displayName>Christoph's Mail Service</displayName> <displayShortName>ISPmail</displayShortName> <incomingServer type="imap"> <hostname>webmail.workaround.org</hostname> <port>143</port> <socketType>STARTTLS</socketType> <authentication>password-cleartext</authentication> <username>%EMAILADDRESS%</username> </incomingServer> <outgoingServer type="smtp"> <hostname>webmail.workaround.org</hostname> <port>587</port> <socketType>STARTTLS</socketType> <authentication>password-cleartext</authentication> <username>%EMAILADDRESS%</username> </outgoingServer> </emailProvider> </clientConfig>
- Changez
workaround.org
par votre domaine principal - Changez
webmail.workaround.org
par votre relais - Adaptez
displayName
etdisplayShortName
- Vérifiez que c'est bien ces ports chez vous… par défaut ça devrait. Et que c'est ouvert sur le pare-feu !