Ç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…

• 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 dnsutils

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 snap_root_$(date --iso) /dev/VgPoste/root

S'il y a un souci, on revient en arrière :

sudo lvconvert --merge /dev/VgPoste/snap_root_XXX

Et s'il y a un souci pour recréer un snapshot après ça, c'est

sudo lvchange --refresh VgPoste

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.

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 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/jail.d/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.

À terme, voici à quoi ressemble mon fichier :

[DEFAULT]
ignoreip = 127.0.0.1

[sshd]
enabled = true
port = ssh, sftp, 22, 225
backend = systemd

[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
filter    = dovecot

[postfix]
enabled = true
port    = pop3,pop3s,imap2,imaps,submission,465,sieve
filter = postfix

[sieve]
enabled = true

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 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”.

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 (plus tard dans le tuto) :

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

Il y a plein de possibilité de panachages. J'ai fait un choix, ça m'aura pris des jours à me décider, plus des jours à adapter… Je vais essayer d'expliquer mais ce qui est fait pour un logiciel, peut s'adapter à un autre.

Bases de données :

• 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.
• Je pourrais évidement gérer les utilisateurs avec LDAP et je le ferais peut-être un jour… mais là vu le taf à faire, mariadb me suffit.
• redis-server gère plus du cache, façon dite plus rapide de gérer le spam et ses données.

Je fais le choix de Postfix (avec postfix-mysql pour parler à Mariadb) ; aujourd'hui pas mal de gens apprécieront plus Opensmtpd et c'est legit. Pourquoi j'ai finalement pris Postfix ?

• Énormément plus de tutos, à destination des noobs et des experts, sur tous les cas de figures
• J'aime la doc plus organique que des manpages
• En discutant avec des sysadmin connaissant les deux logiciels, leur avis n'est pas absolument tranché en faveur de l'un ou l'autre. Opensmtpd est effectivement considéré comme un challenger pertinent, mais la réputation de difficulté à paramétrer Postfix est un peu usurpée (et je confirme, c'est comme plein de logiciels…).
• Leur avis est aussi que Postfix est extrêmement puissant. Il permet de faire “tout” (y compris des conneries), c'est sa force et son risque. Opensmtpd est encore jeune et certaines options ne sont pas (encore?) possibles ; ceci dit rien qui bloquera la sysadmin hébergeant du mail familial.

Dovecot, tout le monde le plébiscite, et ce n'est pas celui qui m'aura posé de souci.

• 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.

La chasse aux spams se fera avec rspamd, un logiciel tiers qui traite les spams. Il gère aussi la signature automatique des clés de domaine (DKIM) MAIS je n'ai jamais réussi à le faire marcher de mon côté sur ça, et il m'a bien enquiquiné sur le reste. Donc, le DKIM est géré par Opendkim chez moi.

Quelques outils pratiques à avoir :

• adminer : remplaçant de phpmyadmin. On verra…
• swaks : “couteau suisse du mail”, fournit divers utilitaires
• bsd-mailx : permet de lire/envoyer les mails sur le serveur, en ligne de commande, utile lors des tests.
• mutt : autre logiciel pour voir les mails, plus “graphique” (mais en console), et pratique aussi à d'autres moment. Voir ma doc associée en cas de souci.

Le certificat SSL sera géré avec certbot, classique et fonctionnel.

On va avoir un peu d'apache pour quelques outils visuels de gestion (adminer, rspamd).

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 opendkim opendkim-tools

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

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”. Le détail de tout ça ci-dessous.

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

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

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

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');

Si on veut ajouter un autre utilisateur :

REPLACE INTO mailserver.virtual_users (id,domain_id,password,email)
 VALUES ('X', 'Y', '{BLF-CRYPT}$2y$05$.WedBCNZiwxY1CG3aleIleu6lYjup2CIg0BP4M4YCZsO204Czz07W', 'user@example.org');

• X est à incrémenter, c'est l'id de l'user
• Y est l'id du domaine, donc “1” si c'est le premier
• Le mot de passe à générer avec la commande dessus
• et le vrai mail.

É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.

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.

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

C'est bien beau tout ça, mais quand un mail interne au système (par exemple à root) est envoyé, il arrive où ? Nul part, et cette fois pas question de jouer avec Msmtp : le relai, ça sera “nous”. Mais, la logique n'est pas très différente.

On commence par éditer /etc/aliases :

/etc/aliases

mailer-daemon: postmaster
postmaster: root
nobody: root
hostmaster: root
usenet: root
news: root
webmaster: root
www: root
ftp: root
abuse: root
noc: root
security: root
default: admin@nomdomaine.org
root: admin@nomdomaine.org

Oui, sans le @ à la fin des alias, cette fois. Et vers admin@mondomaine ou autre, hein, tant que c'est un utilisateur présent sur le système.

Puis on régénère le fichier de postfix à propos des alias :

postalias /etc/aliases

Et on peut tester l'envoi d'un mail. J'ai craqué, installé bsd-mailx (dont la syntaxe pour l'envoi d'un mail test ne me pose pas de souci) et hop :

echo "Test" | mail -s "Test " root

Cela arrive bien dans la boite mail configurée !

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 et displayShortName
• Vérifiez que c'est bien ces ports chez vous… par défaut ça devrait. Et que c'est ouvert sur le pare-feu !

À noter, il y a potentiellement d'autres procédures, avec entre autre des ajouts à faire dans la zone DNS. Voir ceci :

• https://github.com/gronke/email-autodiscover
• https://allella.fr/technique/outils/2020/04/26/email_autoconfig.html

Mais, je m'embêterais avec ça si j'ai des soucis… pour le moment, ça suffit.

Voir la page dédiée : DNS, SPF, DKIM, DMARC et autres choses à configurer sur le mail

On en arrive au point vital. Et on va voir que ce n'est pas si simple.

Mais de quoi je cause ?

Il faut savoir que Gandi a une fonctionnalité épatante : l'alias avec joker.

Extrait de leur doc :

Un peu plus d'exemples. J'ai la boite mail vilain@mondomaine.org, qui me sert à recevoir les inscriptions des sites, newsletters, commandes internet… autant dire que c'est bien rempli. vilain@ n'est jamais exposé sur le net¹⁾, au lieu de ça, je donne des alias, dont voici une liste :

• nom.prenom@mondomaine.org
• autrealias@mondomaine.org
• news.*@mondomaine.org
• marchand.*@mondomaine.org
• wtf.*@mondomaine.org

Les deux premiers (nom.prenom@ et autrealias@) n'ont pas de joker, il faut avoir l'adresse exacte pour leur écrire. Les suivants par contre, je les adapte à la volée ; je donne marchand.site1@mondomaine.org à un premier site marchand et marchand.site2@mondomaine.org à un second site marchand, sans avoir besoin de créer les alias explicitement. Ensuite je m'en sert pour filtrer ce que je reçois dans ma boite mail et voir qui a revendu mon adresse (elles le sont rarement, en fait).

Je peux non seulement recevoir des mails à ces adresses avec joker, mais aussi répondre avec au besoin, bien que dans ce cas je sois dans l'obligation de déclarer l'alias dans Thunderbird (mais pas chez le fournisseur mail !).

Voilà la killer feature de Gandi, si difficile à trouver ailleurs.

Coup de bol pour moi, tous mes alias fonctionnels sont de la forme chaine.joker ; sans le point, j'allais avoir des soucis.

On va bidouiller quelque chose d'équivalent en deux temps :

• D'abord avec postfix : il y a moyen d'imiter ça. Ce n'est pas exactement pareil mais assez proche pour dépanner.
• Ensuite, on utilisera un service du type anonaddy. Mais c'est pour plus tard, on a pas mal de choses à vérifier avant.

C'est Dovecot qui débloque la solution.

sudo nano /etc/dovecot/conf.d/15-lda.conf

Il y a là la ligne recipient_delimiter = . (à décommenter et à mettre avec un point, donc).

Recharger dovecot et postfix.

En plus de la manipulation précédente, si on veut utiliser le + en plus du ..

Dans /etc/postfix/main.cf, modifier virtual_alias_maps pour ajouter regexp:/etc/postfix/point_addressing. Ça devrait ressembler à ça :

virtual_alias_maps = regexp:/etc/postfix/point_addressing, mysql:/etc/postfix/mysql-virtual-alias-maps.cf,mysql:/etc/postfix/mysql-email2email.cf

Modifier /etc/postfix/point_addressing en mettant les regexp suivantes (à adapter aux noms de domaines servis) :

/^(.*)\.(.*)@(mondomaine\.org|autredomaine\.fr)$/ $1+$2@$3
/^(.*)\+(.*)@(mondomaine\.org|autredomaine\.fr)$/ $1@$3

Le fait de déclarer des noms de domaine évitera qu'on permette n'importe quel alias à tous les domaines, cela offre un peu plus de contrôle.

Recharger postfix.

• Source (entre autre) : https://wiki.fiat-tux.fr/books/administration-syst%C3%A8mes/page/postfix

À la fin de https://workaround.org/ispmail/bullseye/relay-outoing-email-through-postfix/, il y a une note assez sibylline sur le sujet :

Dans un premier temps, j'ai laissé ça de côté.

Mais, il faut que nos alias puissent répondre. Si John reçoit un mail via son alias Jack, il faut qu'il puisse répondre avec Jack ; et je confirme qu'à ce stade, le serveur refuse que Jack envoie un mail.

Voici la méthode plus détaillée.

J'ai créé /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'

Pour le faire prendre en compte, modifions smtpd_sender_login_maps dans /etc/postfix/main.cf pour que ça ressemble à ça :

smtpd_sender_login_maps=mysql:/etc/postfix/mysql-email2email.cf,mysql:/etc/postfix/mysql-allow-alias-send.cf

Et ça marche. Mieux, si je déclare un alias forgé dans Thunderbird, par exemple si je lui dis que “joe” est un alias de John et que je tente d'envoyer un mail avec joe, le serveur éjecte Joe avec le message suivant dans les logs :

<joe@nordcantal.fr>: Sender address rejected: not owned by user john@mondomain.org; from=<joe@mondomain.org> to=<admin@mondomain.org> proto=ESMTP helo=<[192.168.1.89]>

Ouf ! Ça, ça marche !

Ce sera avec Anonaddy, mais c'est pour une autre fois. Voir la page dédiée.

Anonaddy va permettre d'anonymiser complètement l'adresse mail réelle, d'avoir uniquement les adresses jokers sur certains alias, et même de bloquer l'envoi vers certains alias avec joker. C'est encore mieux que Gandi.

L'outil https://nstools.fr/ liste divers points qui peuvent être améliorés.

(à vérifier, là je teste)

Cela sert à avoir la liste des mails valides sur un serveur. Utilisé par les spammeurs pour contacter les gens… Donc, le désactiver n'est pas vu comme une mauvaise pratique.

Dans /etc/postfix/main.cf, ajoutez la ligne

disable_vrfy_command = yes

Il faut camoufler les infos sur les versions des logiciels, pas besoin qu'on sache sur quelles failles compter. Rien de compliqué, il suffit de revoir le paramètre smtpd_banner dans /etc/postfix/main.cf.

On passe de ceci :

smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)

à cela :

smtpd_banner = $myhostname ESMTP

Ça devrait suffire.

Créer le fichier /etc/postfix/check/header_checks_out et mettre ces regexp dedans (source) :

/^\s*Received: from \S+ \(\S+ \[\S+\]\)(.*)/ REPLACE Received: from [127.0.0.1] (localhost [127.0.0.1])$1
/^X-Originating-IP:/ IGNORE
/^X-Mailer:/ IGNORE
/^Mime-Version:/ IGNORE
/^User-Agent:/ IGNORE

Dans l'absolu, ipv6, c'est mieux.

J'ai cependant rencontré un souci de taille : mon routeur n'est pas tout jeune, et ne me permet pas de déclarer l'ipv6 de ma machine. Pour le dire autrement, le réseau local n'est qu'en ipv4 (si j'ai bien compris), et je ne peux rien y faire. En attendant d'acheter un routeur plus optimum et de me former un peu plus à la partie réseau… il va falloir désactiver ipv6 sur mon service, au risque de rencontrer de vrais gros soucis.

La première chose à faire est d'éviter d'avoir une entrée AAAA vers le serveur dans son DNS ; ça, c'est facile.

Mais par défaut, postfix va quand même tenter d'envoyer certains mails en ipv6 (puisque notre serveur, lui, ne sais pas qu'on est fâché avec la technologie moderne). Cela va créer des erreurs de distributions… Car le reverse dns ne peux pas fonctionner sur l'adresse ipv6 à cause de ce fichu routeur !

Il faut donc ajouter ces lignes dans /etc/postfix/main.cf :

# Forcer ipv4 tant que je n'ai pas un routeur me permettant d'indiquer mon ipv6
smtp_address_preference = ipv4
inet_protocols = ipv4

Et déclarer uniquement le réseau en ipv4 (mais commentez la partie en ipv6, on espère un jour l'activer…) :

#mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
mynetworks = 127.0.0.0/8

On peut indiquer des règles spécifiques suivant la destionation. Par exemple pour forcer les communications avec Google à passer par ipv4, créer le fichier /etc/postfix/transport avec la ligne suivante :

gmail.com  smtp4:

Ajouter la ligne suivante dans /etc/postfix/main.cf :

transport_maps = hash:/etc/postfix/transport

Il faut aussi générer un fichier /etc/postfix/transport.db, avec cette commande :

postmap /etc/postfix/transport

Redémarrer Postfix.

C'est quand même plus pratique que de bidouiller la base de donnée, bien que la solution mérite d'être un peu améliorée. Mais, c'est du php : je peux y faire des choses. Et en attendant “ça marche”.

En profiter (si ce n'est déjà fait) pour sécuriser Apache d'après https://khaganat.net/wikhan/fr:apache.

En principe on a déjà un admin pour la base de donnée Mailuser si on a suivi le tuto plus haut.

Télécharger ISPMail Admin. Le dézipper et le mettre “où il faut” sur la partie web.

Dans cfg/config.inc.php :

1. Modifier db_user et db_pass pour mettre l'admin de la database “mailserver”.
2. Décommenter define('IMA_CFG_LOGIN', IMA_LOGINTYPE_ACCOUNT); (ou pas, cf la doc)
3. Modifier admin_user et admin_Pass en créant un truc rien que pour ça.

Dans la config apache de /etc/apache2/sites-enabled/monsite-https.conf, modifier/ajouter les détails suivants (à adapter au chemin) :

        <Directory /var/www/monsite/ >
                Options FollowSymLinks MultiViews
                AllowOverride All
                Order allow,deny
                allow from all
        </Directory>
        <Directory /var/www/monsite/isp/cfg/ >
                Require all denied
        </Directory>

Se rendre sur index.php (chemin vers isp) et admirer une interface plus commode pour ajouter users, domaines, etc.

• Paramétrage de rspamd, juste pour gérer les spams.
  • S'il gonfle on fera sans, il y a d'autres méthodes pour gérer (cf Evolix)
• Commenter postfix et nettoyer afin que ce soit plus facile à maintenir. Déplacer les fichiers personnalisés dans un dossier ?
• Voir les infos récupérés dans ce pdf pour améliorer les choses, ainsi que les autres blogs. pas urgent, quand on aura le temps.
• Mettre en place anonaddy et voir si ça permet de gérer les users
  • Sinon ajouter de quoi gérer les users aussi…
  • Vérifier que ça fait ce qu'on veut sur les alias
  • Notes sur cette page, ça commence à faire long ici et c'est un truc particulier.
• teste imapsync ou autre.
• Mettre en place le backup
• S'assurer que l'adresse mail pour les infos systèmes est bien configurée…
• Transférer mes vrais noms de domaines ?
• Mettre en place un webmail, à la fois plus pratique en déplacement, et puis pour pouvoir configurer les filtres SIEVE.
• Documenter les bidouilles sur ipv4 et iptable…