Différences

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

--- pratique:informatique:serveur_mail [12/08/2023 08:55] – [Filtres SIEVE] Zatalyz
+++ pratique:informatique:serveur_mail [23/05/2024 10:37] (Version actuelle) – Zatalyz
@@ Ligne 32: / Ligne 32: @@
 ===== Installation de l'OS =====
+CF [[pratique:informatique:start_serveur]]. Détails propre au serveur mail :
    * 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.
+   * Dans l'absolu, 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. Mais dans les faits, hein...
    * Utiliser LVM, cela permettra les snapshots (entre autres avantages).
-Partitionner de cette façon :
+Pour le pare-feu : dans la majorité des cas, le serveur est déjà derrière un pare-feu (proxy, box), 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.
-  * 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é :
+Il faut tout de même s'assurer que certains ports seront accessibles (on redétaille plus loin ? il n'y a pas "tout") :
-  * 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 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 :
-<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 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
-===== 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 ====
-Tout est noté dans un article à part, parce que ça commençait à être long : [[pratique:informatique:fail2ban]]
-==== Pare-feu (iptables, nftable, ipset, etc) ====
-Bon, là, ça devient compliqué. Dans la majorité des cas, le serveur est déjà derrière un pare-feu (proxy, box), 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
@@ Ligne 169: / Ligne 50: @@
 ===== Systemd, ton univers impitoyable =====
-<WRAP center round help 60%>
+Parait que la commande suivante permet d'avoir les logs "mails" de postfix (plus tard dans le tuto) :
-Cette partie se discute. Personnellement, je ne supporte pas journactl. La manip suivant ne le désactive pas, elle permet juste d'avoir en plus des logs lisibles et faciles à consulter. Il me semble que c'est le meilleur des deux mondes : les fonctionnalités de journactl sont là au besoin, mais pour un check rapide de ce qui se passe, on a des logs faciles à lire.
-</WRAP>
-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 (plus tard dans le tuto) :
   journalctl -ru postfix@-.service
@@ Ligne 190: / Ligne 56: @@
 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
 ===== Logiciels à installer =====
@@ Ligne 493: / Ligne 355: @@
   mail_plugins = $mail_plugins imap_quota imap_sieve
+J'ai aussi affiné via Dovecot les valeurs par défaut. Modifier ''/etc/dovecot/conf.d/90-quota.conf'' pour avoir ce contenu :
+<code>
+plugin {
+  quota = maildir:User quota
+  # Mettre 5G de quota par défaut
+  quota_rule = *:storage=5G
+  # Ajouter 100M pour ce qui est dans la corbeille, ça permet de faire du tri sans "ranger" dans la corbeille.
+  quota_rule2 = Trash:storage=+100M
+  quota_status_success = DUNNO
+  quota_status_nouser = DUNNO
+  quota_status_overquota = "452 4.2.2 Mailbox is full and cannot receive any more emails"
+}
+service quota-status {
+  executable = /usr/lib/dovecot/quota-status -p postfix
+  unix_listener /var/spool/postfix/private/quota-status {
+    user = postfix
+  }
+}
+</code>
 ===== Paramétrer les alias systèmes vers admin@ =====
 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 [[pratique:informatique:mail_relai|Msmtp]] : le relai, ça sera "nous". Mais, la logique n'est pas très différente.
@@ Ligne 776: / Ligne 660: @@
 Redémarrer Postfix.
+==== Limiter l'envoi de mail dans un temps donné ====
+Là on est dans un truc entre sécurité et mesures antispam. Il est toujours possible qu'un compte mail se fasse pirater, et que le compte serve alors à flooder du spam à fond. Et ça, ce sera très, trèèès mauvais pour nous, parce qu'on va se faire bannir de partout et inscrire en block-list.
+Bref, il est temps de paramétrer la chose.
+La limite du nombre de mail envoyé à la minute est vraiment facile. Dans ''/etc/postfix/main.cf'', ajouter quelque chose comme :
+<code>
+smtpd_client_message_rate_limit = 10
+anvil_rate_time_unit = 60s
+smtpd_recipient_limit = 40
+</code>
+Ce qui ici, veut dire qu'on a le droit d'envoyer 10 mails à la minute, chacun à 40 destinataires au maximum. Faut arriver à les écrire, quand même.
+    * ''anvil_rate_time_unit'' : par défaut c'est de toute façon 60 secondes donc on pourrait aussi bien ne pas le déclarer. Cela sert à diverses choses, pas juste à la limite d'envoi de mail.
+    * ''smtpd_client_message_rate_limit'' : le nombre de messages autorisé dans cette limite. 2 est évidement mauvais pour la prod, mais cela permet de tester que tout marche : envoyez 3 mails différents depuis la même adresse, en moins d'une minute, et admirez le résultat. Postfix ne met pas vraiment de limite par défaut...
+    * ''smtpd_recipient_limit'' : Nombre maximum de destinataires qu'un serveur SMTP de Postfix accepte par requête de livraison de message (défaut : 1000). Il me semble que 40 est déjà énorme, mais ça arrive qu'on envoie un mail collectif à une grosse partie de notre carnet d'adresse.
+Il y a d'autres options similaires (cf http://www.postfix.org/TUNING_README.html#conn_limit ) mais cela me semble inutile.
+==== Limiter les tentatives de connexions des crackbots ====
+En regardant les logs on peut voir que tout le net tente de se connecter à notre pauvre serveur.
+Fail2ban éjecte les plus nuisibles (et stupides) mais on peut ajouter aussi ceci dans ''/etc/postfix/main.cf'' :
+<code>smtpd_error_sleep_time = 5s
+smtpd_soft_error_limit = 3
+smtpd_hard_error_limit = 10</code>
+  * ''smtpd_error_sleep_time'' :  la réponse du serveur SMTP n'est envoyée qu'après un délai lorsque le client a fait plus de $smtpd_soft_error_limit et moins de $smtpd_hard_error_limit erreurs, sans livrer de courrier (1s par défaut).
+  * ''smtpd_soft_error_limit'' :  Nombre d'erreurs qu'un client SMTP distant est autorisé à faire sans livrer de messages avant d'être ralenti par le serveur SMTP de Postfix (10 par défaut).
+  * ''smtpd_hard_error_limit'' : Nombre maximum d'erreurs qu'un client SMTP distant est autorisé à commettre sans livrer de message. Le serveur SMTP de Postfix coupe la connexion au delà de cette limite (20 par défaut).
+Là je me fais plaisir à bien baisser la limite... parce que les serveurs sérieux ne font pas d'erreurs. On verra si cela complexifie ma réception de mails.
+Attention cependant car cela peut aussi ralentir tout postfix et donc appliquer des délais à des clients légitimes.
+==== Avertir l'admin si y'a des abus/problèmes ====
+Dans ''/etc/postfix/main.cf'' :
+<code>error_notice_recipient = postmaster@mondomain.org
+notify_classes = resource, software,policy,bounce,delay</code>
+  * ''error_notice_recipient'' : par défaut les notifications sont délivrées à "postmaster" (en local), donc ça devrait arriver, mais on peut aussi indiquer une autre adresse mail, vu que de toute façon... ben on a un serveur d'envoi de mail...
+  * ''notify_classes'' : qu'est-ce qui va être notifié. Par défaut, ''resource'' (problème de ressources) et ''software'' (problème de logiciel). On peut ajouter ce qui suit :
+    * ''bounce'' : détails des en-têtes pour les messages rejetés à la livraison. Inclut le paramètre ''2bounce'' donc pas besoin de le mettre aussi.
+    * ''2bounce'' : avis de rejets non-livrables
+    * ''delay'' : à propos des messages retardés
+    * ''policy'' : à propos des messages rejetés pour cause de restriction. Genre trop d'envoi à la minute.
+    * ''protocol'' : erreur de protocole du client ou du serveur. Et là je crains que ça floode à mort sur les gens qui tentent de se connecter de façon non autorisée, alors je ne l'ai pas mis dans ma configuration.
+Cela peut faire pas mal de flood sur postmaster, mais permet aussi de voir rapidement si le serveur a un souci.
+Cf https://postfix.traduc.org/index.php/postconf.5.html#notify_classes pour la doc officielle traduite.
+==== Postscreen, pour filtrer plus de bandits ====
+Doc de référence : [[https://www.postfix.org/postconf.5.html]].
+<WRAP center round important 60%>
+Attention, c'est pas au point parce que je n'ai pas encore mis en place "subcleanin" comme proposé dans https://blog.debugo.fr/serveur-messagerie-optimisation-postfix/ et donc ben... c'est le bordel !
+</WRAP>
+Postscreen va appliquer des vérifications sur les domaines (entre autre) et faciliter le tri. On pourra ainsi déclarer certains domaines comme bloqués, et d'autres comme de confiance, et en mettre certains en liste grise. Pour chaque contrôle, on peut au choix :
+  * ''ignore'' : on ne fait rien
+  * ''enforcer'' : on bloque et on enverra un retour ''RCPT TO: 550 5.3.2 Service currently unavailable''
+  * ''drop'' : on répondra ''521 5.3.2 Service currently unavailable''
+Dans le fichier ''/etc/postfix/master.cf'', **commentez** la ligne :
+  smtp  inet   n   -   y   -   -   smtpd
+et décommenter
+<code>
+smtp  inet   n   -   y   -   1   postscreen
+smtpd pass   -   -   y   -   -   smtpd
+ -o cleanup_service_name=subcleanin
+dnsblog  unix   -   -   y   -   0   dnsblog
+tlsproxy unix   -   -   y   -   0   tlsproxy
+</code>
+<WRAP center round info 100%>
+Qu'est-ce qu'on est en train de faire ?
+Les colonnes se réfèrent aux informations suivantes :
+  * Nom du service (smtp, dnsblog, etc)
+  * Type de service : sur quel port/socket ce dernier écoute.
+    * ''inet'' passe par TCP/IP et est accessible depuis le réseau
+    * ''unix'' et ''pass'' sont des processus locaux. ''pass'' ne reçoit qu'une connexion par requête.
+  * Private : si le service est interne à postfix ou public. ''inet'' est forcément public. Par défaut sur "y" et par déduction je dirais que "y" veut dire "privé".
+  * Unprivileged : si le service tourne avec les privilèges root ou avec l'utilisateur postfix. Par défaut "y" et aucune idée de si c'est root ou pas, mais on va faire confiance aux tutos.
+  * Chroot : si le service tourne en version chrooté. Pour certains, il ne faut pas (cf manpage), sinon par défaut ça semble "y".
+  * Wake up time (default: 0) : réveille le service après ce nombre de secondes. Si on ajoute ''?'' ça indique qu'il ne faut pas le réveiller tant qu'il n'a pas été appelé par ailleurs. 0 indique qu'on ne fait pas de réveil automatique.
+  * Limite de processus : nombre maximum de processus simultanés sur ce service, défini par défaut ailleurs ; 0 indique de ne pas mettre de limite.
+  * Commande et arguments : la commande à exécuter. Les arguments demandent de revenis à la ligne.
+    * ''-o name=value'' (forme raccourcie, sinon il y a une façon longue de le raconter) : surcharge le paramètre en question de ''main.cf''. La doc conseille de ne pas en abuser.
+Source : le [[http://www.postfix.org/master.5.html|manpage]] et [[https://blog.debugo.fr/serveur-messagerie-policyd-spf-postscreen/|configuration de postcreen par Debugo]].
+Ici, donc, on va activer l'usage de postscreen (utile pour bloquer pas mal de spam), dnsblog pour filtrer les dns bloqués, et tls proxy pour le support de STARTTLS dans postscreen.
+</WRAP>
+On ajoute les lignes suivantes dans ''/etc/postfix/main.cf'' :
+<code>postscreen_access_list = permit_mynetworks, cidr:/etc/postfix/mycfg/postscreen_access.cidr
+postscreen_blacklist_action = drop</code>
+''/etc/postfix/mycfg/postscreen_access.cidr'' permet de bloquer des ip, selon cette forme :
+<code>xxx.xxx.xxx.xxx reject</code>
+Mais bon, ce travail est surtout réalisé par fail2ban en principe. Ne pas oublier de créer le fichier quand même !
+On ajoute ensuite une grande subtilité de postscreen : un petit temps de délai avant de répondre. Un serveur mail bien configuré attend poliment qu'on lui donne la parole... cela éjecte donc un certain nombre de "zombies". La "greet_banner" est le message envoyé lors de l'attente. Le temps d'attente (ici 3 secondes) permet aussi d'interroger si l'ip est blacklistée.
+<code>postscreen_greet_wait = 3s
+postscreen_greet_banner = Cool, we have time...
+postscreen_greet_action = drop</code>
+=== Listes de blocage ===
+Ensuite, on va ajouter des listes à interroger pour savoir si l'ip ne serait pas bloquée. Si oui, alors... on vire
+<code>postscreen_dnsbl_sites =
+ zen.spamhaus.org*2,
+ bl.spamcop.net,
+ b.barracudacentral.org*2
+postscreen_dnsbl_threshold = 3
+postscreen_dnsbl_action = drop
+</code>
+Ici, quelques subtilités (si j'ai compris, ce qui n'est pas certain !) :
+  * Si on rejette le mail, l'expéditeur aura l'information du nom de domaine ayant servi à la blocklist. Cela peut se cacher (via postscreen_dnsbl_sites) , mais personnellement je juge plutôt correct de dire "je ne te veux pas car tu est bloqué ici" ; si l'expéditeur est légitime et que c'est une erreur, il peut se faire débloquer.
+  * Interroger les listes demande du temps, pas la peine d'en ajouter trop, mais, on va le voir ensuite, pas la peine d'en mettre trop peu non plus.
+  * Forcément, on fait appel à un prestataire externe, avec ce que ça peut questionner sur la confiance. Les listes en question peuvent parfaitement faire une liste des ip qui contactent notre serveur. Personnellement je me dis que l'intérêt de l'information reste limité, surtout si peu à peu j'ai plus d'utilisateurs.
+  * ''postscreen_dnsbl_threshold'' indique la limite inférieure inclusive du score du domaine testé qu'on peut accepter. Et là ça demande un peu de détails.
+Si une ip est trouvée dans une des listes, ça va compter pour "1". Sauf si on ajoute un chiffre après le nom du domaine et l'astérisque ; dans ce cas ça sera pondéré d'autant. Dans l'exemple ici, si une ip est trouvée sur zen.spamhaus.org, ça va compter pour "2". Là, avec nos trois listes dont 2 pondérées à "2", si l'ip est listée partout, elle obtiendra un score de 5. C'est plus haut que 3 => c'est probablement une adresse louche.
+Interroger plusieurs listes augmente donc les chances que l'ip bloquée le soit pour des raisons légitimes.
+<WRAP center round todo 60%>
+Et c'est une partie que je dois améliorer dans ma config
+</WRAP>
+Mais, attention. Ces listes ne sont pas toutes gratuites, elles ont des conditions d'utilisation, bref pour ne pas se faire ban soi-même... il faut aller voir tout ça.
+=== Greylisting ===
+Enfin, quelques manip qui passent les ip en "greylisting" en attente d'en savoir plus. Attention, cela peut éjecter des serveurs légitimes mais configurés de façon un peu légère (d'ailleurs, moi-même, je donnerais quoi ?). Enfin, bon, comme cela risque surtout de concerner des copains et qu'ils savent comment me contacter autrement... perso ça ne me stresse pas. <WRAP center round important 60%>
+Ajout : ça risque aussi de foutre le boxon dans d'autres cas, car le serveur en face reçoit un message comme quoi "on peut pas recevoir" en premier. Et il doit retenter un envoi, ensuite, qui lui passera... si l'ip du serveur est ok. Or avec les gros, c'est bien possible que les ips tournent histoire d'arriver à envoyer. Bref, à tester mais c'est pas forcément une idée parfaite.
+</WRAP>
+<code>postscreen_pipelining_enable = yes
+postscreen_pipelining_action = enforce
+postscreen_non_smtp_command_enable = yes
+postscreen_non_smtp_command_action = enforce
+postscreen_bare_newline_enable = yes
+postscreen_bare_newline_action = enforce
+</code>
+Toutes ces actions demandent que le client en face agisse proprement : il passe le test, se déconnecte, et cause ensuite au vrai postfix. Cela ralentit les échanges et peut être coûteux en ressources (et en temps). Cependant une fois le test passé, l'ip est enregistrée comme "bonne" pendant un certain temps (paramètre ''postscreen_*_ttl'', 30 jours par défaut donc je ne change rien).
+  * **pipelining** : pour les clients qui envoient plusieurs commandes en même temps, au lieu d'attendre la réponse à chacune avant d'envoyer la suivante. Le mail n'est pas fait pour se presser ; ceux qui sont pressés sont souvent mal intentionnés.
+  * **non_smtp_command** : si le client envoie une commande qui n'est pas SMTP (voir [[https://www.postfix.org/postconf.5.html#postscreen_forbidden_commands)]]. Et ça, quand on regarde les logs, on sait qu'ils testent et que ce n'est **jamais** légitime.
+  * **bare_newline** : quand le client envoie un caractère de retour à la ligne, sans retour chariot avant. Ça doit filtrer ce qui est scripté avec les pieds ? Si on suit la norme, chaque ligne doit se terminer par <CR><LF> ; s'il n'y a que <LF> c'est sale !
-==== ISPMail pour gérer domaines et users ====
+Un petit ''postfix reload'' et... On espère que tout va bien !
+===== ISPMail pour gérer domaines et users =====
 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".
@@ Ligne 888: / Ligne 929: @@
   * 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 ?
+  * Commenter postfix et nettoyer afin que ce soit plus facile à maintenir. Déplacer les fichiers personnalisés dans un dossier ? (fait mais à documenter)
   * Voir les infos récupérés dans le pdf pour améliorer les choses, ainsi que les autres blogs. pas urgent, quand on aura le temps.
   * Mettre en place le backup
-  * Transférer mes vrais noms de domaines ?
+  * <del>Transférer mes vrais noms de domaines ?</del>
-  * Mettre en place un webmail, à la fois plus pratique en déplacement, et puis pour pouvoir configurer les filtres SIEVE.
-  * Et paramétrer Sieve
 Documenter :
@@ Ligne 903: / Ligne 942: @@
   * test imapsync ou autre.
   * reprendre ici et harmoniser les noms de domaine entre autre
+  * Mise en place du webmail, à la fois plus pratique en déplacement
+  * J'ai mis imapS (993) en place mais pas noté les détails. En même temps ça va avec la reprise de la config de dovecot et postfix en version plus détaillée ici.
 {{tag>Mail}}