Différences

Ci-dessous, les différences entre deux révisions de la page.

--- pratique:informatique:quit_gandi [23/06/2023 10:18] – [Serveurs mails] Zatalyz
+++ pratique:informatique:quit_gandi [23/09/2023 11:01] (Version actuelle) – [Serveurs mails] Zatalyz
@@ Ligne 3: / Ligne 3: @@
 ===== Mails =====
-  * Synchroniser des boites mails, pour ne pas perdre lors du transfert : imapsync
+  * Synchroniser des boites mails, pour ne pas perdre lors du transfert :
+    * [[https://imapsync.lamiral.info/|imapsync]]
+    * [[https://www.offlineimap.org/|offlineimap]]
+    * [[https://isync.sourceforge.io/|isync]] avec la [[https://wiki.archlinux.org/title/isync|doc courte]]
+    * Dans Thunderbird :
+      * Sauvegarde complète au format zip : menu Outils -> Exporter.
+      * Ou archiver les messages, tu les sélectionnes et tu vas dans Messages -> archiver. Ça les retire du serveur et tu les retrouves dans le dossier Archives. Par défaut, mais ça se configure, ça les range par année.
+      * [[https://www.frayssinet.org/2022/02/22/migration-de-ovh-vers-ouvaton/|Tutoriel]] sur une migration de OVH vers Ouvaton qui indique la procédure (et surtout l'ordre des opérations).
+    * fetchmail (daté dans la manip ?)
 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.
@@ Ligne 41: / Ligne 49: @@
   * Interface de gestion : https://mailboy.manurevah.com/
   * https://www.ima.jungclaussen.com/ (ispmail)
+  * https://mailadminpanel.org/
+  * postfix admin
 Notes variées :
-  * "mail en multi-domaine (TLS/SNI) avec la pile suivante: Postfix, Dovecot, Rspamd, Modoboa (donc avec NginX, uWsgi, Postgresql…)." [[https://forum.chatons.org/t/config-serveur-mail-en-2021/3095/2|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
-    * https://forum.chatons.org/t/recette-pour-serveur-mail-securise/323/41
-  * 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
@@ Ligne 68: / Ligne 71: @@
-===== 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 =====
-<WRAP center round todo 60%>
-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.
-</WRAP>
-==== Paramétrage des DNS, première partie ====
+Ça se passe sur la page dédiée pour ne pas mélanger notes de recherche et expérimentation : [[pratique:informatique:serveur_mail]].
-Ç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 :
+[[https://creativecommons.org/publicdomain/zero/1.0/deed.fr|{{ https://liev.re/imagesweb/licences/cc-zero.png?100 | Ce texte est placé sous licence CC0}}]]
-<code>
-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.
-</code>
-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 [[https://workaround.org/ispmail/bullseye/migrating-from-buster/|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é ([[https://alinea.ninm.net/dokuwiki/pratique:informatique:start_serveur#parametrer_ssh_sur_le_serveur|ici]])
-    *  Ajouter la clé ssh pour pouvoir se co :
-<code>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</code>
-    * Redémarrer SSH : ''service ssh restart ''
-Se connecter en SSH (on n'est plus root !) et finaliser la préparation préliminaire :)
-<code>sudo apt update
-sudo apt upgrade
-sudo apt install apt-listbugs debsums apt-listchanges
-</code>
-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 :
-<code>
-APT::Install-Recommends "0";
-APT::Install-Suggests "0";
-</code>
-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 ===
-<WRAP center round info 100%>
-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 : [[https://doc.ubuntu-fr.org/rkhunter|Ubuntu-fr]]
-</WRAP>
-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 :
-<code>
-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
-</code>
-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 :
-<code>rkhunter --update
-rkhunter --list
-rkhunter -c --rwo</code>
-=== 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
-<code>[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...
-</code>
-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 ====
-<WRAP center round info 100%>
-[[https://workaround.org/ispmail/bullseye/install-software-packages/|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 <del>tenter d'utiliser opensmtpd plutôt que postfix</del> 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.
-</WRAP>
-=== 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...
-<code>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)
-</code>
-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 ''<nowiki>sudo grep -nri "poste" /etc/ --exclude-dir=lvm</nowiki>'' 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 :
-<code txt /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
-</code>
-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
-<code 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></code>
-  sudo nano /var/www/lapin/index.html
-<code 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>
-</code>
-Puis les droits
-<code>
-sudo chown -R www-data: /var/www/lapin
-sudo chown -R www-data: /var/www/poste
-</code>
-=== Apache ===
-<code>sudo a2dissite 000-default.conf
-sudo nano /etc/apache2/sites-available/lapin.conf</code>
-Mettre ça :
-<code><VirtualHost *:80>
-  ServerName lapin.example.org
-  DocumentRoot /var/www/lapin
-</VirtualHost></code>
-Idem sur la poste.
-  sudo nano /etc/apache2/sites-available/lapin.conf
-<code><VirtualHost *:80>
-  ServerName poste.example.org
-  DocumentRoot /var/www/lapin
-</VirtualHost></code>
-Puis les commandes suivantes.
-<code>sudo a2ensite lapin.conf
-sudo a2ensite poste.conf
-sudo systemctl reload apache2</code>
-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).
-<code><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></code>
-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>'' :
-<code>
-RewriteEngine On
-RewriteCond %{REQUEST_URI} !.well-known/acme-challenge
-RewriteRule ^(.*)$ https://%{SERVER_NAME}$1 [R=301,L]</code>
-Enfin on active ssl, le module rewrite, le site https puis on relance apache.
-<code>sudo a2enmod ssl
-sudo a2enmod rewrite
-sudo a2ensite lapin-https.conf
-sudo a2ensite poste-https.conf
-sudo apachectl -t
-sudo apachectl graceful</code>
-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.
-<code>sudo -i
-mysql
-CREATE DATABASE mailserver;</code>
-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 :
-<code>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';
-</code>
-Pour la suite, je suis presque bêtement [[https://workaround.org/ispmail/bullseye/prepare-database/|ISPmail]]. Toutes les commandes sont dans mysql.
-<code>
-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;
-</code>
-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 :
-<code>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');</code>
-=== 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 :
-<code bash /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</code>
-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 :
-<code>SystemMaxUse=512M
-SystemMaxFiles=100
-ForwardToSyslog=yes</code>
-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'' :
-<code>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'</code>
-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.
-[[https://creativecommons.org/publicdomain/zero/1.0/deed.fr|{{ https://liev.re/imagesweb/licences/cc-zero.png?100 | Ce texte est placé sous licence CC0}}]]