Alinea

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

Interfaces seules :

Notes variées :

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 :

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.

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.

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.

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…

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 postfix se 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.

Ce texte est placé sous licence CC0

CC Attribution-Noncommercial-Share Alike 4.0 International Driven by DokuWiki
pratique/informatique/quit_gandi.1687508333.txt.gz · Dernière modification : 23/06/2023 10:18 de Zatalyz