[{"uuid":"a150a0d3-caac-4d1f-915d-8d3c35624df1","slug":"postfix","title":"PostFix : serveur de messagerie sous Linux","category":"Informatique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2023-12-29 17:29:08","created_at":"2023-12-29 17:29:08","updated_at":"2023-12-29 17:29:08","tags":[],"plain":"Cet article est destiné aux débutants qui veulent configurer un serveur de messagerie électronique de base. Il est préférable d'avoir une connaissance élémentaire en administration système, ainsi que la capacité d'installer des logiciels et de modifier des fichiers de configuration. L'article a été rédigé en se basant sur Debian 11, mais les instructions devraient également convenir aux autres versions. Veuillez noter que des différences peuvent exister dans les autres versions. Postfix est un logiciel de serveur de messagerie open source largement adopté. En tant que \"MTA\" (Agent de Transfert de Message), il joue un rôle central dans le traitement, la transmission et la distribution des courriels. Doté de fonctionnalités avancées en matière de sécurité, de filtrage et de personnalisation, Postfix est un choix prisé pour la gestion des systèmes de messagerie. <nav stacked=\"true\"  fade=\"true\"> </nav>\nIntroduction\nL'objectif fondamental de cette procédure est de permettre à n'importe quelle machine ou serveur d'envoyer des courriels vers une adresse spécifique. Pour y parvenir, il est nécessaire de préparer le courrier électronique à l'aide d'un programme externe, puis de le transmettre efficacement au serveur de messagerie de destination en utilisant le protocole SMTP (Simple Mail Transfer Protocol). Le processus de l'envoi de courriel via SMTP s'articule comme suit, prenons un exemple concret avec un courriel destiné à l'adresse alice@example.com : 1. L'utilisateur ou un programme externe crée le courrier électronique, en spécifiant les informations du destinataire (alice@example.com), en rédigeant le contenu du message et en incluant d'autres détails nécessaires. 2. Le courriel est ensuite remis au serveur SMTP local, qui se trouve sur la machine ou le serveur à partir duquel l'envoi est effectué. 3. Le serveur SMTP analyse le domaine du destinataire (dans ce cas, \"example.com\") pour déterminer comment atteindre le serveur de messagerie de destination. 4. Le serveur SMTP établit un contact avec le serveur de messagerie de destination (le serveur SMTP de \"example.com\" dans cet exemple) en utilisant le protocole SMTP. 5. Le serveur de messagerie de destination accepte le courriel, le stocke temporairement, puis le transfère éventuellement dans la boîte aux lettres de l'utilisateur Alice, située sur son propre serveur de messagerie. 6. Si tout se déroule sans problème, le courriel est ainsi livré avec succès à Alice, qui peut alors le consulter dans sa boîte de réception. Ce processus est la façon dont le protocole SMTP assure la transmission de courriels, encheminant ces derniers de l'expéditeur au destinataire, en utilisant les serveurs de messagerie appropriés à travers Internet.\nAxe de travail\nIl existe de nombreuses configurations et combinaisons différentes possibles lors de la mise en place d'un serveur de messagerie électronique, bien trop nombreuses pour être toutes couvertes ici. Par conséquent, cet article effectue certaines choix fondamentaux pour vous, tels que les logiciels que nous allons utiliser (Postfix et Dovecot). D'autres options nécessiteront des modifications de la part de l'utilisateur, comme les adresses réseau et les noms de domaine. Les paramètres plus avancés, comme la gestion de domaines virtuels et des utilisateurs, ne sont pas abordés dans cet article et ne seront pas traités ici. Dans ce contexte, nous utilisons Postfix comme agent de transfert de messagerie (MTA). Dovecot est utilisé pour permettre aux utilisateurs d'accéder à leur courrier électronique via les protocoles IMAP ou POP. Nous partons du principe que le nom de domaine utilisé est example.com, mais cela devrait être adapté par le lecteur. Vous pouvez utiliser un véritable nom de domaine pour un serveur de messagerie pleinement qualifié ou un faux nom de domaine si vous souhaitez uniquement créer un serveur de messagerie interne. Notre exemple suppose que le serveur de messagerie physique (hôte) porte le nom mail.example.com et est situé à l'adresse IP privée 192.168.0.1 (veuillez personnaliser ces informations en fonction de vos besoins). Le serveur de messagerie fournira des comptes de messagerie basés sur les comptes système d'utilisateurs standards, et les utilisateurs accéderont à leur courrier en utilisant leur nom d'utilisateur et leur mot de passe de compte système. Nous illustrons cela avec un utilisateur nommé John Smith, qui dispose d'un compte système avec le nom d'utilisateur john.\nServeurs SMTP\nSous Linux Debian, il existe plusieurs programmes d'envoi de courriels, chacun avec ses propres fonctionnalités et avantages. Voici quelques-uns des programmes les plus couramment utilisés pour envoyer des courriels sous Debian : 1. ssmtp: Simple SMTP est un programme léger qui permet d'envoyer des courriels via SMTP. Il est particulièrement adapté aux tâches d'envoi de courriels automatisées et ne prend pas en charge la réception de courriels. 2. msmtp: MSMTP est un autre client SMTP léger qui facilite l'envoi de courriels depuis la ligne de commande ou depuis des scripts. Il peut être configuré pour transmettre des courriels à travers un serveur SMTP externe. 3. Postfix: Bien que Postfix soit principalement un serveur de messagerie, il peut également être utilisé pour envoyer des courriels depuis une machine Debian. Il offre une grande flexibilité en matière de configuration, mais sa configuration peut être plus complexe que celle des clients SMTP plus simples. 4. sendmail: Sendmail est un programme de messagerie historique sous Unix/Linux, bien qu'il soit maintenant souvent remplacé par des alternatives plus modernes. Cependant, il est toujours disponible sur Debian et peut être utilisé pour envoyer des courriels. 5. Exim: Exim est un autre serveur de messagerie qui peut être configuré pour envoyer des courriels. Il est également capable de gérer la réception de courriels, ce qui en fait une option plus complète. Le choix du programme d'envoi de courriels dépendra de vos besoins spécifiques, de votre niveau de confort avec la configuration et de la complexité de votre infrastructure de messagerie. Pour des tâches simples d'envoi de courriels depuis la ligne de commande ou depuis des scripts, ssmtp ou msmtp sont souvent des choix pratiques. Pour des besoins plus avancés, Postfix ou Exim peuvent être mieux adaptés.\nInstaller Postfix\nPour installer Postfix sur Debian, vous devez utiliser le gestionnaire de paquets APT (Advanced Package Tool). Voici comment vous pouvez procéder : La première commande  met à jour la liste des paquets disponibles dans les dépôts Debian, et la deuxième commande \"apt install\" installe Postfix ainsi que ces dépendances. Choisir  Entrer la valeur FQDN de votre adresse de serveur si vous devez relancer la configuration de Postfix\n  sudo dpkg-reconfigure postfix\n  \nPour supprimer Sendmail, vous pouvez utiliser la commande suivante : Cette commande supprime le programme Sendmail de votre système Debian. Après avoir installé Postfix, vous devrez configurer ces logiciels pour les adapter à vos besoins spécifiques.\nConfigurer Postfix\nLes fichiers de configuration de postfix sont stockés dans /etc/postfix. Les deux principaux fichiers de configuration de postfix sont master.cf et main.cf, bien que nous ne traiterons que de main.cf ici. Tout d'abord, nous allons ajouter ou modifier certaines lignes dans le fichier de configuration main.cf. Les lignes suivantes doivent être ajoutées, modifiées ou décommentées :\nTests\nFaire un essai d'envoi de mail\n  echo \"Le contenu du mail\" | mail -s \"ceci est le sujet\" mail@domaine.tld Le programme mail est une composante du package mailutils. Donc, si le programme n'est pas installer sur la machine, utilisez \n- Pour modifier un paramètre dans Postfix, il faut éditer le fichier de configuration\n  sudo nano /etc/postfix/main.cf\n  \nRedémarrer le service\n  sudo systemctl restart postfix\n  \n   Gestion des Alias\nAjouter dans le fichier de configuration de Postfix,    virtualaliasmaps = hash:/etc/postfix/virtual\n  \nPuis ajouter dans le fichier  les alias désirés tel que le modèle suivant : Enfin, exécuter le bloc suivant. Il sera nécessaire de l’exécuter à chaque modifications effectuées du fichier .\n  sudo postmap /etc/postfix/virtual\n  sudo systemctl restart postfix Mails en attente\nPour connaître les mails en attente\n  sudo postqueue -p\n- Pour traiter tous les mails en attente\n  sudo postqueue -f\n- Pour supprimer tous les mails en attente\n  sudo postsuper -d ALL Reprise de la configuration de Postfix\nLe fichier de configuration de Postfix est . Il est éditable par nano ou vim. On va le reprendre pour configurer Postfix.\n--   myhostname = myserver.example.com Il est important que l'option  corresponde au FQDN (fully qualified domain name) du serveur. La valeur à renseigner et celle qui renvoyée par la commande :\n  nslookup 91.134.243.56\n|\n  \nDans l'exemple précédent, le serveur est noté dans le  Cette information est gérée par le serveur DNS Cette option se trouve les paramètres , chez kimsufi.com \n| Cette option, reverse DNS, se trouve dans les options du serveur VPS de vos serveurs dédiés, chez ovh.com\n|\n|\n-- Configurer le nom du serveur SMTP, domaine à afficher dans le courrier sortant   myorigin = example.com Configuer le nom du serveur SMTP    mydomain = example.com Configure to which SMTP domains to relay messages to, for example:   relaydomains = example.com\n-- Configuration minimaliste du SMTP Greeting Banner:   smtpdbanner = $myhostname\n-- Limiter les attaques par déni de services : Consulter le fichier log\nLe fichier log standard de postfix est  Vous pouvez garder un oeuil sur les logs\n  sudo tail -f /var/log/mail.info&\n  \n  \nEnvoyer un mail\nIl y a deux possibilités :\nenvoie depuis un client : mail\nconnexion en Telnet sur le serveur SMTP L'utilitaire mail fait parti de la suite mailutils\n  sudo apt install mailutils\n-- Utilisation de l'utilitaire mail depuis un poste client. Pour envoyer un mail à  de la part de \n  echo \"This is the message body\" | mail -s \"This is the subject\" mail@example.com -aFrom:sender@example.com\n  \nPour envoyer un mail à \n   echo \"This is the message body\" | mail -s \"Hello World\" username\n-- Utilisation de telnet pour se connecter sur le serveur SMTP    telnet mail.mymailserver.com 25\n  \nPuis saisir les commandes SMTP   EHLO checkeremail.com   MAIL FROM:<sender@mailserver.fr>   RCPT TO:<dest@mymailserver.com>   DATA\n  Subject: Sending an email using telnet\n  Hello,\n  Here is my body? Do you like it?\n  Cédric\n  .   QUIT Vider tous les mails\nVider tous les mails présents dans la boite d'un utilisateur. On considère que la boite mail (mbox) de l'utilisateur  se trouve dans le fichier    sudo sh -c \"> /var/mail/www-data\" Gestion des certificats\nPour configurer Postfix et Certbot pour utiliser les certificats SSL/TLS de \"smtp.monserveur.fr\" avec Let's Encrypt, suivez ces étapes générales. Assurez-vous d'avoir les droits nécessaires sur le serveur et que vous êtes à l'aise avec l'édition de fichiers de configuration en ligne de commande. Configurer Postfix pour utiliser SSL/TLS\n1. Accédez à la configuration de Postfix:\nConnectez-vous à votre serveur en tant que sudouser.\nOuvrez le fichier de configuration principal de Postfix avec un éditeur de texte, tel que  ou . Le fichier est généralement situé à . 2. Définissez les chemins des certificats:\nLocalisez ou ajoutez les lignes suivantes dans  pour spécifier l'emplacement des fichiers de certificat et de clé privée (remplacez les chemins par les vôtres si nécessaire) :\nActivez l'utilisation de TLS en ajoutant ou en s'assurant que la ligne suivante est présente : 3. Redémarrez Postfix:\nSauvegardez vos modifications et fermez le fichier.\nExécutez la commande  pour appliquer les modifications. Configurer Dovecot pour SSL/TLS\nSi vous utilisez Dovecot comme serveur IMAP/POP3 : 1. Les fichiers de configuration de Dovecot se trouvent généralement dans . Le fichier principal de configuration est souvent nommé , et il peut inclure d'autres fichiers de configuration situés dans . 2. Dans les fichiers de configuration de Dovecot, vous devrez trouver et modifier les lignes qui définissent le chemin du certificat SSL et de la clé privée. Recherchez quelque chose comme ceci : Pensez à désactiver la configuration présente dans . 3. Redémarrez Dovecot avec . 4. Après le redémarrage, assurez-vous que tout fonctionne comme prévu. Vous pouvez vérifier que Dovecot écoute avec le nouveau certificat en vous connectant avec un client de messagerie ou en utilisant OpenSSL : Configurer Let's Encrypt pour le renouvellement automatique\n1. Certbot gère généralement les renouvellements automatiquement. Cependant, vous pouvez personnaliser ou ajouter des scripts de renouvellement dans le dossier de hooks de renouvellement. 2. Scripts de renewal-hooks:\nPlacez les scripts personnalisés dans . Vous pouvez avoir des scripts , , et  pour s'exécuter avant, pendant, et après le renouvellement.\nUn script typique dans  pourrait redémarrer Postfix et Dovecot pour appliquer les nouveaux certificats. Voir les pages : \nSi vous avez deux scripts distincts,  et  et vous souhaitez exécuter les deux après le renouvellement de certificat Let's Encrypt par Certbot, vous pouvez configurer les hooks dans le fichier de configuration de renouvellement de Certbot ou les placer dans les répertoires de hook appropriés. Vous devriez ajouter des lignes pour posthook dans la section . Votre fichier pourrait ressembler à ceci : 3. Tester le renouvellement:\nExécutez  pour tester le processus de renouvellement et s'assurer que tout fonctionne comme prévu. Vérification et maintenance\nVérifiez les logs de Postfix et Dovecot pour les erreurs liées aux certificats SSL/TLS.\nAssurez-vous que les certificats se renouvellent correctement en vérifiant les dates d'expiration et en observant le comportement du système lors des renouvellements planifiés. Remarques\nFaites toujours une copie de sauvegarde des fichiers de configuration avant de les modifier.\nLes chemins exacts et les commandes peuvent varier légèrement en fonction de votre distribution Linux et de la version de vos logiciels.\nAssurez-vous que les ports nécessaires sont ouverts sur votre pare-feu pour permettre les connexions TLS/SSL. En suivant ces étapes, vous devriez être capable de configurer Postfix et Dovecot pour utiliser les certificats SSL/TLS avec Let's Encrypt, améliorant ainsi la sécurité de votre serveur de messagerie. Assurez-vous de tester votre configuration pour vérifier que tout fonctionne correctement avant de la mettre en production. Biblio\nhttps:www.tecmint.com/install-postfix-mail-server-with-webmail-in-debian/\nhttps:*wiki.centos.org/HowTos(2f)postfix.html"},{"uuid":"104a8694-4268-4e0a-99c7-e7ecfd47af1e","slug":"auto-heberger-son-serveur-mail-en-2026","title":"Auto-héberger son serveur mail en 2026","category":"informatique","author":"cedric@abonnel.fr","cover":"cover.svg","published":true,"published_at":"2026-05-12 08:35","created_at":"2026-05-12 08:38:14","updated_at":"2026-05-12 08:40:06","tags":[],"plain":"Survivre aux règles de Gmail, Outlook et consorts\r\nContexte — Cet article de Clubic (lien) rappelle une vérité technique : SMTP date de 1982, n'a aucune sécurité native, et toutes les \"rustines\" (SPF, DKIM, DMARC, MTA-STS, DANE) ont été conçues par Yahoo, Cisco, Microsoft, Google. Depuis février 2024 (Google) et mai 2025 (Microsoft), tout expéditeur dépassant 5000 mails/jour vers Gmail/Outlook doit configurer SPF + DKIM + DMARC, maintenir un taux de spam < 0,1 %, et fournir un lien de désinscription en un clic.\r\nMais même en dessous de 5000/jour, ces règles s'appliquent en pratique : sans elles, ton mail finit en spam ou est rejeté. Ce dossier décrit comment monter son propre serveur mail tout en passant à travers ces filtres.\r\n--\r\n\r\nSommaire\r\n\r\n1. Avant de commencer : est-ce vraiment une bonne idée ?\r\n2. Prérequis techniques\r\n3. Architecture cible\r\n4. Choix du fournisseur et de l'IP\r\n5. Configuration DNS complète\r\n6. Installation du stack mail\r\n7. SPF, DKIM, DMARC : les rustines obligatoires\r\n8. MTA-STS, TLS-RPT, DANE : aller plus loin\r\n9. PTR (reverse DNS) et HELO\r\n10. Warmup d'IP : la phase la plus délicate\r\n11. Postmaster Tools, SNDS, FBL\r\n12. Liste de désinscription en un clic (RFC 8058)\r\n13. Anti-spam entrant et hygiène\r\n14. Monitoring, logs, alertes\r\n15. Que faire quand Gmail rejette quand même ?\r\n16. Checklist finale avant mise en prod\r\n17. Annexes : commandes utiles\r\n--\r\n\r\n1. Avant de commencer : est-ce vraiment une bonne idée ?\r\n\r\nL'auto-hébergement mail est techniquement possible, mais c'est probablement le service le plus pénible à maintenir en 2026. Avant de te lancer, lis ça :\r\n\r\nCe qui marche bien en auto-hébergé :\r\nRecevoir du mail (presque tout le monde te livre).\r\nEnvoyer vers d'autres serveurs auto-hébergés ou pros bien configurés.\r\nGarder le contrôle sur tes données, tes alias, tes domaines.\r\n\r\nCe qui est dur :\r\nEnvoyer vers Gmail / Outlook / Yahoo / iCloud sans atterrir en spam.\r\nSortir d'une blacklist une fois dedans.\r\nMaintenir un score de réputation IP correct sur la durée.\r\nSurvivre à un changement unilatéral des règles côté gros acteurs (cf. février 2024 et mai 2025).\r\n\r\nStratégie réaliste recommandée :\r\nRéception entrante : auto-hébergée à 100 %. Aucun risque, full contrôle.\r\nEnvoi sortant : deux options, selon ton volume et ton tolérance au risque.\r\nOption A — Pure auto-hébergée : tu envoies directement depuis ton serveur. Faisable, mais demande un warmup, une IP propre, et un suivi continu.\r\nOption B — Smart host sortant : tu envoies via un relais réputé (un autre de tes serveurs avec une IP qui a déjà sa réputation, ou un service type Mailjet/Sendgrid/SMTP2GO en bas volume gratuit). Tes mails sortent depuis l'IP du relais, qui a déjà sa réputation faite. C'est un compromis : tu perds une partie de la souveraineté technique, mais tu gagnes énormément en délivrabilité.\r\n\r\nLe reste du dossier suit l'option A — tout en t'expliquant comment basculer en B si nécessaire.\r\n--\r\n\r\n2. Prérequis techniques\r\nÉlément | Détail |\r\n---|---|\r\nDomaine | À toi, registrar peu importe, mais avec DNSSEC activable (cf. §8 pour DANE). |\r\nServeur | VPS ou dédié, 2 vCPU / 4 Go RAM minimum, Debian 12+ ou Ubuntu 24.04 LTS. |\r\nIP fixe v4 | Indispensable. IP \"résidentielle\" ou IP de datacenter récemment recyclée = exclues. |\r\nIP fixe v6 | Recommandée, mais désactivable si l'IPv6 du fournisseur est blacklistée. |\r\nPTR / reverse DNS | Modifiable par toi. Si l'hébergeur ne te le permet pas, change d'hébergeur. |\r\nPorts | 25, 465, 587, 993, 4190 ouverts sortants ET entrants. Le port 25 sortant est bloqué chez beaucoup d'hébergeurs grand public (OVH résidentiel, Free, etc.) : vérifie avant. |\r\nTLS | Certificat valide (Let's Encrypt suffit). |\r\n\r\nCompétences attendues : Linux en ligne de commande, DNS (champs A/AAAA/MX/TXT/SRV/CAA/TLSA), notion de TLS, lecture de logs  et .\r\n--\r\n\r\n3. Architecture cible\r\n\r\nUn stack standard, éprouvé, en logiciels libres :\r\n\r\n\r\n\r\nComposants :\r\nPostfix : MTA. Reçoit, route, envoie le SMTP.\r\nDovecot : serveur IMAP/POP3, livraison locale (LMTP), authentification SASL pour Postfix, gestion Sieve (filtres).\r\nRspamd : antispam moderne, fait aussi la vérification SPF/DKIM/DMARC entrante, le greylisting, et — option recommandée — la signature DKIM sortante (en remplacement d'OpenDKIM).\r\nLet's Encrypt (certbot) : TLS.\r\n(Optionnel) Roundcube ou SnappyMail : webmail.\r\n\r\nAlternative tout-en-un : Mailcow ou Mailu, basés sur Docker, qui empaquètent tout ça avec une interface admin. Si tu préfères ne pas tout configurer à la main, c'est légitime — la majorité des règles DNS et de délivrabilité de ce dossier restent identiques.\r\n--\r\n\r\n4. Choix du fournisseur et de l'IP\r\n\r\nLe choix de l'hébergeur conditionne la moitié de ta délivrabilité. Avant de prendre un VPS :\r\n\r\n1. Le port 25 sortant est-il ouvert ? Beaucoup d'hébergeurs le bloquent par défaut pour limiter le spam (Hetzner l'ouvre sur demande, OVH l'ouvre selon le produit, Scaleway l'ouvre selon le compte). Pose la question au support avant de payer.\r\n2. Le PTR est-il configurable ? Si non, change.\r\n3. L'IP a-t-elle été utilisée par un spammeur ? Avant d'acheter le VPS, demande l'IP qu'on te donnera. Vérifie sur :\r\nmxtoolbox.com/blacklists.aspx\r\nmultirbl.valli.org\r\ntalosintelligence.com (Cisco)\r\nsenderscore.org\r\n   \r\n   Si l'IP est listée sur Spamhaus, Barracuda, SORBS, SpamCop, demande à l'hébergeur de te l'échanger ou prends un autre VPS. Une fois listée, tu vas y passer des semaines.\r\n4. Réputation du subnet (). Même si ton IP est propre, si le  est pourri (beaucoup de spammeurs voisins), Gmail va te traiter avec méfiance. Vérifie sur senderscore.org en saisissant ton IP — le score du subnet apparaît.\r\n\r\nHébergeurs réputés corrects pour le mail : Hetzner, OVH (gamme dédiée, pas SoYouStart), Scaleway, Infomaniak (en VPS), Netcup. À éviter pour de l'envoi : DigitalOcean (subnets souvent grillés), Linode/Akamai (idem), AWS EC2 (le port 25 est limité par défaut, et la rate-limit est costaude).\r\n--\r\n\r\n5. Configuration DNS complète\r\n\r\nPour un domaine  avec un serveur mail sur  à l'IP  (et  en v6) :\r\n\r\n\r\n\r\nDétails dans les sections dédiées plus bas.\r\n\r\nÀ ne pas oublier : l'enregistrement PTR (reverse DNS) se configure chez ton hébergeur, pas dans ta zone DNS. Il doit pointer . C'est traité au §9.\r\n--\r\n\r\n6. Installation du stack mail\r\n\r\nSur Debian 12. Ce qui suit est volontairement condensé — pour une configuration ligne par ligne, suis le tutoriel de référence de Workaround.org qui est l'étalon depuis 20 ans.\r\n\r\n\r\n\r\nPostfix : configuration  minimale-mais-saine\r\n\r\n\r\n\r\nDovecot, Rspamd\r\n\r\nCes composants demandent leurs propres fichiers de configuration. Renvoi explicite vers les tutos qui font autorité :\r\nWorkaround.org / ISPmail : https://workaround.org/ispmail/ — référence francophone et anglophone, mise à jour à chaque version Debian.\r\nRspamd quickstart : https://www.rspamd.com/doc/tutorials/quickstart.html\r\nDovecot wiki : https://doc.dovecot.org/\r\n\r\nSi tu veux gagner du temps, Mailcow () est aujourd'hui la solution clé-en-main la plus fiable.\r\n--\r\n\r\n7. SPF, DKIM, DMARC : les rustines obligatoires\r\n\r\nSans ces trois enregistrements correctement configurés, Gmail et Outlook rejetteront ou marqueront en spam la majorité de tes messages — peu importe ton volume.\r\n\r\nSPF (Sender Policy Framework)\r\n\r\nDéclare qui a le droit d'envoyer du mail pour ton domaine.\r\n: autorise les serveurs listés dans le MX du domaine.\r\n: rejet strict de tout le reste. Indispensable pour la réputation. Ne jamais utiliser  (softfail) en prod : Gmail aujourd'hui considère  comme un signal faible.\r\n\r\nSi tu envoies aussi via un relais externe (smart host) : ajoute son , ex. .\r\n\r\nLimite : un enregistrement SPF doit tenir en 10 lookups DNS maximum. Au-delà, il est invalide. Vérifie avec https://www.kitterman.com/spf/validate.html.\r\n\r\nDKIM (DomainKeys Identified Mail)\r\n\r\nSigne chaque mail sortant avec une clé privée. Le destinataire vérifie la signature via la clé publique publiée en DNS.\r\n\r\nGénération de la clé (Rspamd, sélecteur , clé 2048 bits) :\r\n\r\n\r\n\r\nLe fichier  contient l'enregistrement DNS à publier :\r\n\r\n\r\n\r\nConfiguration Rspamd () :\r\n\r\n\r\n\r\nRecharge : .\r\n\r\nVérification : envoie un mail à check-auth@verifier.port25.com, tu reçois un rapport complet SPF/DKIM/DMARC en retour. Ou utilise https://www.mail-tester.com/ (note sur 10).\r\n\r\nDMARC (Domain-based Message Authentication, Reporting and Conformance)\r\n\r\nDit aux serveurs distants quoi faire en cas d'échec SPF/DKIM, et te renvoie des rapports sur ce qui passe et ce qui rate.\r\n: surveillance seule, à utiliser pendant 2-4 semaines en démarrage pour collecter les rapports sans pénaliser.\r\n: mise en spam des mails non authentifiés. Cible normale.\r\n: rejet pur. À atteindre en cible finale, après avoir vérifié 4 semaines de rapports propres.\r\n: adresse pour les rapports agrégés (quotidiens).\r\n: rapports forensiques (par message). Optionnel.\r\n: alignement strict — le domaine de signature DKIM et le domaine SPF doivent exactement correspondre au domaine .\r\n\r\nLecture des rapports DMARC : ils arrivent en XML, illisibles. Utilise un parseur :\r\nPostmark DMARC Monitoring (gratuit, agrège les rapports dans une UI).\r\nparsedmarc (auto-hébergeable, envoie dans Elasticsearch/Splunk/Grafana).\r\n--\r\n\r\n8. MTA-STS, TLS-RPT, DANE : aller plus loin\r\n\r\nCes standards sécurisent le transport entre serveurs (chiffrement TLS forcé). Gmail les regarde, Microsoft aussi. Pas obligatoires, mais ils boostent ta réputation.\r\n\r\nMTA-STS\r\n\r\nForce les serveurs distants à utiliser TLS pour t'envoyer des mails. Trois éléments :\r\n\r\n1. Enregistrement DNS TXT :\r\n\r\n\r\n2. Sous-domaine  servant un fichier en HTTPS à  :\r\n\r\n\r\n est la cible. En démarrage, mets  pendant 1-2 semaines.\r\n\r\n3. Certificat TLS valide sur ce sous-domaine (déjà fait via certbot au §6).\r\n\r\nTLS-RPT\r\n\r\nDemande aux serveurs distants de t'envoyer des rapports en cas d'échec TLS.\r\n\r\n\r\n\r\nDANE (DNS-based Authentication of Named Entities)\r\n\r\nEncore plus solide que MTA-STS, mais nécessite DNSSEC activé sur ton domaine. Si ton registrar ne supporte pas DNSSEC, oublie DANE.\r\n\r\nDANE publie un hash du certificat TLS dans un enregistrement TLSA :\r\n\r\n\r\n\r\nOu plus simplement avec https://www.huque.com/bin/gentlsa :\r\n\r\n\r\n\r\nVérification globale de tout ton setup TLS+DANE : https://internet.nl/mail/ (excellent, recommandé).\r\n--\r\n\r\n9. PTR (reverse DNS) et HELO\r\n\r\nLe PTR est probablement la cause la plus fréquente de rejet par Gmail/Outlook chez les nouveaux auto-hébergés.\r\n\r\nRègle absolue : , et tout doit être un FQDN cohérent.\r\n\r\nConfigure le PTR dans le panneau de ton hébergeur (chez OVH : \"IP\" → \"Reverse DNS\") :\r\n\r\n\r\nVérifie :\r\n\r\n\r\nDans Postfix,  et c'est ce qui est annoncé en HELO. Cohérence garantie.\r\n--\r\n\r\n10. Warmup d'IP : la phase la plus délicate\r\n\r\nUne IP neuve = pas de réputation = défiance maximale des gros acteurs. Tu ne peux pas envoyer 1000 mails le jour 1 sans te griller.\r\n\r\nPlan de warmup sur 4 à 6 semaines\r\nSemaine | Volume max/jour vers Gmail+Outlook | Volume max/jour total | Contenu |\r\n---|---|---|---|\r\n1 | 20-50 | 100 | Mails à toi-même, comptes test sur Gmail/Outlook/Yahoo. Réponds-y, marque \"non spam\" si en spam. |\r\n2 | 100 | 300 | Cercle proche qui sait répondre / interagir. |\r\n3 | 300 | 1000 | Élargissement progressif. |\r\n4 | 800 | 3000 | Ouvre aux usages normaux. |\r\n5+ | 2000+ | volume cible | Stable. |\r\n\r\nRègles d'or pendant le warmup :\r\nPas de mailing list, pas de notifs automatiques en masse. Privilégie des mails 1-à-1 conversationnels.\r\nDemande aux destinataires de répondre — un mail avec réponse a 100x le poids d'un mail ouvert silencieusement.\r\nAucun lien raccourci, aucun pixel de tracking, aucune image lourde.\r\nStop net si ton score Senderscore baisse ou si Gmail Postmaster Tools (cf. §11) montre du rouge.\r\n\r\nSi tu as un volume immédiat à envoyer\r\n\r\nBascule en option B (smart host) le temps du warmup, puis rapatrie progressivement en interne en répliquant les volumes ci-dessus.\r\n--\r\n\r\n11. Postmaster Tools, SNDS, FBL\r\n\r\nLes gros acteurs te donnent des dashboards dédiés. Inscris-toi à tous, dès la création du domaine.\r\nService | Acteur | Usage |\r\n---|---|---|\r\nGoogle Postmaster Tools | Gmail | Réputation IP+domaine, taux de spam, authentification, encryption. Indispensable. |\r\nMicrosoft SNDS | Outlook/Hotmail | Smart Network Data Services, qualité de l'IP. |\r\nMicrosoft JMRP | Outlook | Junk Mail Reporting Program, FBL Microsoft. |\r\nYahoo CFL | Yahoo | Complaint Feedback Loop. |\r\nValidity Sender Score | Indépendant | Score sur 100, à surveiller. |\r\n\r\nConfigure les feedback loops (FBL) : quand un destinataire clique \"spam\", tu reçois une notification. Ça te permet de désinscrire l'utilisateur avant qu'il ne dégrade ta réputation.\r\n--\r\n\r\n12. Liste de désinscription en un clic (RFC 8058)\r\n\r\nExigence Google/Microsoft pour les expéditeurs en volume, mais à mettre en place dès le début même en bas volume.\r\n\r\nAjoute deux en-têtes à tous les mails non-strictement-personnels :\r\n\r\n\r\n\r\nL'URL HTTPS doit accepter une requête POST (pas seulement GET) avec  dans le corps, et désinscrire immédiatement et silencieusement sans demander de confirmation.\r\n--\r\n\r\n13. Anti-spam entrant et hygiène\r\n\r\nUn serveur mail mal configuré côté entrée devient vite un relais de spam ou une cible. Configuration Rspamd minimale :\r\n\r\n\r\n\r\n\r\n\r\nActive aussi :\r\nVérification SPF/DKIM/DMARC entrante (par défaut activée dans Rspamd).\r\nRBL (Realtime Blackhole Lists) : Spamhaus ZEN, Barracuda. Attention à ne pas multiplier — 2 ou 3 RBL fiables suffisent.\r\nGreylisting : refuse temporairement les premiers contacts, ce qui élimine 80% du spam basique. Ne pas activer sur un domaine à fort volume transactionnel (gêne les notifs).\r\nBayes : laisse Rspamd apprendre via le dossier  de Dovecot (signal  / ).\r\n\r\nMises à jour :  activé, redémarrage planifié, lecture des annonces sécu Postfix/Dovecot.\r\n--\r\n\r\n14. Monitoring, logs, alertes\r\n\r\nSans monitoring, tu découvres les problèmes par les utilisateurs. À mettre en place :\r\nLecture des logs : , , web UI de Rspamd sur .\r\nMétriques : exporter Postfix/Dovecot vers Prometheus + Grafana (, ).\r\nAlertes sur :\r\nFile d'attente Postfix > 50 messages ().\r\nScore Senderscore qui chute.\r\nApparition sur une RBL : surveillance automatisée par https://multirbl.valli.org/ ou via un script qui interroge plusieurs DNSBL en cron.\r\nÉchec TLS-RPT (rapport entrant signalant une connexion non chiffrée).\r\nRapports DMARC parsés régulièrement (cf. §7).\r\n--\r\n\r\n15. Que faire quand Gmail rejette quand même ?\r\n\r\nÇa arrive. Diagnostic dans l'ordre :\r\n\r\n1. Lis le code de rejet SMTP dans . Gmail renvoie des codes très explicites :\r\n→ contenu jugé spammy. Revois le contenu, ajoute du texte conversationnel, retire les liens douteux.\r\n→ tu as dépassé un seuil. Ralentis immédiatement, attends 24-48h, reprends doucement.\r\n→ ton DMARC ne passe pas. Revérifie SPF/DKIM/alignement.\r\n→ tu es sur une RBL. Va sur spamhaus.org/lookup/ pour vérifier et demander la sortie.\r\n2. Va dans Postmaster Tools (§11). Si \"IP reputation\" est rouge ou orange, regarde le contenu et le timing de tes envois récents.\r\n3. Test mail-tester : envoie à une adresse fournie par mail-tester.com, obtiens une note sur 10. Vise 10/10. Toute case manquante doit être corrigée.\r\n4. Sortie de blacklist : la plupart des RBL (Spamhaus, Barracuda) ont un formulaire de retrait. Spamhaus retire en quelques heures si tu corriges la cause. SORBS est plus lent. UCEPROTECT exige souvent de payer — ignore-la, peu de serveurs sérieux la consultent.\r\n5. Si rien ne marche, change d'IP. C'est parfois la seule issue. Demande à ton hébergeur une IP fraîche, refais un warmup.\r\n--\r\n\r\n16. Checklist finale avant mise en prod\r\n\r\nAvant d'envoyer le premier vrai mail :\r\n[ ] Domaine avec DNSSEC activé.\r\n[ ] IP testée sur 5+ blacklists, propre.\r\n[ ] Port 25 sortant ouvert et testé ().\r\n[ ] PTR configuré et cohérent avec le HELO.\r\n[ ] MX, A, AAAA, SPF, DKIM, DMARC publiés et validés via mxtoolbox.com.\r\n[ ] MTA-STS publié (mode  au démarrage).\r\n[ ] TLS-RPT publié.\r\n[ ] DANE/TLSA publié (si DNSSEC OK).\r\n[ ] CAA publié.\r\n[ ] Test envoyé à  : tout en .\r\n[ ] Test mail-tester.com : 10/10.\r\n[ ] Test internet.nl/mail/ : 100%.\r\n[ ] Inscription Postmaster Tools, SNDS, JMRP, Yahoo CFL.\r\n[ ] DMARC  au démarrage, parser de rapports en place.\r\n[ ] List-Unsubscribe + List-Unsubscribe-Post implémentés.\r\n[ ] Plan de warmup affiché et respecté.\r\n[ ] Monitoring file d'attente + RBL en place.\r\n[ ] Backup chiffré des Maildir.\r\n\r\nAu bout de 4 semaines de rapports DMARC propres : passage à . Au bout de 8-12 semaines : .\r\n--\r\n\r\n17. Annexes : commandes utiles\r\n\r\n\r\n\r\nOutils web à mettre en favoris\r\nhttps://www.mail-tester.com/ — score sur 10\r\nhttps://internet.nl/mail/ — audit complet\r\nhttps://mxtoolbox.com/SuperTool.aspx — DNS, blacklists\r\nhttps://dmarcian.com/dmarc-inspector/ — vérif DMARC\r\nhttps://www.kitterman.com/spf/validate.html — vérif SPF\r\nhttps://postmaster.google.com/ — Google Postmaster\r\nhttps://senderscore.org/ — réputation IP\r\n\r\nDocumentation de référence\r\nISPmail / Workaround.org — https://workaround.org/ispmail/ — le tutoriel le plus complet et tenu à jour, par version Debian.\r\nMailcow docs — https://docs.mailcow.email/ — pour la version conteneurisée clé-en-main.\r\nPostfix officiel — https://www.postfix.org/documentation.html\r\nRspamd docs — https://www.rspamd.com/doc/\r\nRFCs essentielles** : 5321 (SMTP moderne), 7208 (SPF), 6376 (DKIM), 7489 (DMARC), 8461 (MTA-STS), 8460 (TLS-RPT), 7672 (DANE-SMTP), 8058 (One-Click Unsubscribe).\r\n--\r\n\r\nL'auto-hébergement mail en 2026 reste possible, mais c'est devenu un sport : les règles changent, les gros acteurs durcissent leurs critères, et l'écosystème pousse vers la centralisation. Si tu réussis le warmup et tiens 6 mois sans incident, tu as gagné — mais ne baisse pas la garde, un changement unilatéral de Google peut survenir à tout moment, comme en février 2024."},{"uuid":"1fbc16a5-27e0-46d7-b87b-e840e99419d1","slug":"configuration-de-postfix-avec-un-relais-smtp-externe-utilisant-l-authentification-login-ou-plain","title":"Configuration de Postfix avec un relais SMTP externe utilisant l'authentification LOGIN ou PLAIN","category":"Informatique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2023-05-14 07:52:47","created_at":"2023-05-14 07:52:47","updated_at":"2023-05-14 07:52:47","tags":[],"plain":"Par défaut, Postfix est configuré pour envoyer des e-mails directement au serveur de messagerie du destinataire. Cependant, il est parfois nécessaire de configurer Postfix pour utiliser un relais SMTP externe avec authentification LOGIN ou PLAIN. Éditer le fichier de configuration principal\nLe fichier de configuration principal de Postfix est généralement situé dans le répertoire . Ouvrez ce fichier à l'aide d'un éditeur de texte et recherchez les directives suivantes : Configurer le relais SMTP externe\nModifiez la directive  pour spécifier l'adresse du relais SMTP externe que vous souhaitez utiliser. Par exemple, si le relais SMTP externe est  et il écoute sur le port , la directive devrait ressembler à ceci : Activer l'authentification PLAIN\nDécommentez la directive  en supprimant le # au début de la ligne, puis modifiez sa valeur à  : Configurer les informations d'authentification\nAjoutez les informations d'authentification pour le relais SMTP externe en ajoutant les directives suivantes dans le fichier de configuration : Voici ce que font ces options : 1.  : Cette option active l'authentification SASL (Simple Authentication and Security Layer) pour les connexions SMTP sortantes. Cela permet à Postfix de s'authentifier auprès du relais SMTP externe en utilisant les informations d'identification fournies. 2.  : Cette option active l'authentification SASL pour les connexions SMTP entrantes. Elle permet à Postfix d'accepter les connexions SMTP entrantes et d'authentifier les clients qui se connectent. 3.  : Cette option spécifie que Postfix n'accepte pas les connexions anonymes lors de l'authentification SASL. Cela garantit que toutes les connexions SMTP doivent fournir des informations d'identification valides. 4.  : Cette option spécifie que lors de l'utilisation de TLS (Transport Layer Security) pour sécuriser les connexions SMTP, les connexions anonymes ne sont pas autorisées. 5.  : Cette option indique à Postfix où trouver le fichier de hachage contenant les informations d'identification (nom d'utilisateur et mot de passe) pour l'authentification SASL auprès du relais SMTP externe. Dans cet exemple, le fichier  est utilisé et doit être converti en un fichier de hachage à l'aide de la commande . 6.  : Cette option active l'utilisation de TLS pour chiffrer les connexions SMTP sortantes. Elle assure que les communications avec le relais SMTP externe sont sécurisées. 7.  : Cette option indique à Postfix d'émettre une offre STARTTLS lors de l'établissement d'une connexion SMTP sortante. Cela permet d'initier une négociation TLS avec le relais SMTP externe si celui-ci prend en charge TLS. 8.  : Cette option spécifie les mécanismes d'authentification SASL autorisés pour les connexions SMTP sortantes. Dans cet exemple, seuls les mécanismes \"login\" et \"plain\" sont autorisés. Ces options combinées permettent à Postfix de configurer un relais SMTP externe avec authentification PLAIN et d'établir des connexions sécurisées à l'aide de TLS. Cela garantit que les e-mails sont envoyés de manière fiable et en toute sécurité via le relais externe. Créer le fichier de mots de passe SASL\nCréez un fichier  et ajoutez les informations d'authentification suivantes : Remplacez  par l'adresse du relais SMTP externe,  par le port utilisé,  par votre nom d'utilisateur de messagerie pour le relais SMTP, et  par votre mot de passe associé. Générer le fichier de hachage des mots de passe SASL\nExécutez la commande suivante pour générer le fichier de hachage des mots de passe SASL à partir du fichier  : Cette commande va créer un fichier  contenant le hachage des mots de passe. Redémarrer POSTFIX"},{"uuid":"32242b73-c564-41b0-892a-ae97b0e1861e","slug":"spf-ou-comment-votre-boite-mail-repere-les-imposteurs","title":"SPF, ou comment votre boîte mail repère les imposteurs","category":"informatique","author":"cedric@abonnel.fr","cover":"cover.svg","published":true,"published_at":"2026-05-18 07:18","created_at":"2026-05-12 11:18:53","updated_at":"2026-05-12 12:58:33","tags":[],"plain":"Vous recevez un mail qui semble venir de votre banque. L'adresse a l'air correcte, le logo est bon, le ton est sérieux. Sauf que ce mail n'a peut-être jamais été envoyé par votre banque. N'importe qui, depuis n'importe quel ordinateur, peut techniquement écrire « De : votre-banque@exemple.fr » en haut d'un mail. C'est ce qu'on appelle l'usurpation d'expéditeur, et c'est à la base de la quasi-totalité des arnaques par mail.\r\n\r\nLe SPF, ou Sender Policy Framework, est l'un des mécanismes inventés pour limiter ce problème. C'est une technologie discrète, invisible à l'utilisateur, mais qui tourne en arrière-plan chaque fois qu'un mail arrive dans votre boîte.\r\n\r\nL'analogie de l'enveloppe et de la liste d'invités\r\n\r\nImaginez que chaque domaine de mail (par exemple ) soit une grande entreprise qui envoie du courrier. Cette entreprise a plusieurs bureaux de poste autorisés : son siège, sa filiale belge, son prestataire de marketing. Tous ces bureaux ont le droit d'envoyer du courrier en son nom.\r\n\r\nLe SPF, c'est tout simplement la liste publique de ces bureaux autorisés, affichée à la vue de tous. L'entreprise publie quelque part : « Le courrier authentique en mon nom ne peut venir que de ces adresses précises. Toute autre origine est suspecte. »\r\n\r\nQuand un mail prétendument envoyé par  arrive chez votre fournisseur (Gmail, Orange, Free…), celui-ci fait deux choses :\r\n\r\n1. Il regarde l'adresse IP du serveur qui lui livre le mail.\r\n2. Il consulte la liste SPF publiée par .\r\n\r\nSi l'IP figure sur la liste, le mail est considéré comme légitime de ce point de vue. Sinon, c'est un signal d'alerte.\r\n\r\nPourquoi ça existe\r\n\r\nÀ l'origine d'internet, personne n'avait imaginé que le mail servirait à frauder à grande échelle. Le protocole d'envoi (SMTP) a été conçu avec une confiance totale : on déclare son identité et on est cru sur parole. Aucun mécanisme natif ne vérifie quoi que ce soit.\r\n\r\nLe SPF a été ajouté par-dessus, dans les années 2000, pour combler ce trou. C'est volontairement simple : une liste, une vérification, un verdict. L'idée n'est pas de tout résoudre, mais de filtrer les usurpations les plus grossières — celles où un escroc envoie depuis un serveur quelconque en se faisant passer pour une grande marque.\r\n\r\nCe que le SPF fait, et ce qu'il ne fait pas\r\n\r\nLe SPF vérifie d'où vient le mail, pas ce qu'il contient. Un mail légitime envoyé depuis un serveur autorisé peut très bien contenir une arnaque (cas typique : un compte interne piraté). Inversement, un mail forwardé par un ami passe parfois pour suspect alors qu'il est inoffensif, parce que le serveur de transfert n'est évidemment pas sur la liste du domaine d'origine.\r\n\r\nLe SPF n'agit pas non plus sur le contenu visible. Il regarde une information technique — l'identité du serveur émetteur — que l'utilisateur ne voit jamais. C'est précisément ce qui le rend utile : un escroc peut falsifier le « De : » affiché, mais il ne peut pas falsifier l'adresse IP de la machine qui établit la connexion.\r\n\r\nPour une vraie protection, le SPF est combiné à deux autres mécanismes : DKIM (qui signe cryptographiquement le mail) et DMARC (qui indique au destinataire quoi faire quand SPF ou DKIM échoue). Les trois ensemble forment le socle de l'authentification mail moderne. Aucun n'est suffisant seul.\r\n\r\nCe qui se passe concrètement à la réception\r\n\r\nQuand votre fournisseur reçoit un mail, la vérification SPF aboutit à l'un de ces verdicts : autorisé, refusé, douteux, ou indéterminé. Selon le résultat, le mail peut être livré normalement, placé en spam, ou rejeté avant même d'arriver dans votre boîte.\r\n\r\nVous ne voyez jamais cette décision. Elle est inscrite dans les en-têtes techniques du mail, consultables si on creuse, mais transparente pour l'usage quotidien. C'est précisément le but : une protection silencieuse qui élimine une partie du bruit avant qu'il ne vous atteigne.\r\n\r\nEt pour les expéditeurs ?\r\n\r\nSi vous gérez un site, une newsletter, ou même simplement une adresse mail professionnelle sur votre propre domaine, configurer correctement le SPF est devenu indispensable. Sans SPF, vos mails légitimes ont de plus en plus de chances d'être marqués comme suspects par les grands fournisseurs. Avec un SPF bien réglé, vous dites au monde entier : « voici exactement qui a le droit d'écrire en mon nom », et le reste devient automatiquement reconnaissable comme une usurpation.\r\n\r\nC'est un de ces réglages qu'on fait une fois, qu'on oublie ensuite, mais qui décide silencieusement chaque jour du sort de millions de mails."},{"uuid":"092742d7-100b-46b2-acd6-0c0a432d2435","slug":"creer-un-script-de-hook-let-s-encrypt-pour-postfix","title":"Configurer un Script de Hook Let's Encrypt pour Postfix","category":"Informatique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2023-12-29 17:32:41","created_at":"2023-12-29 17:32:41","updated_at":"2023-12-29 17:32:41","tags":[],"plain":"Pour adapter l'article afin de créer un script de hook Let's Encrypt pour Postfix, voici une version modifiée du texte : Assurer la continuité et la sécurité de votre serveur de messagerie Postfix est crucial, surtout lorsqu'il s'agit de la gestion automatique des certificats SSL/TLS via Let's Encrypt. La mise en place d'un script de hook qui redémarre Postfix à chaque renouvellement de certificat est une étape essentielle. Voici les étapes pour configurer cela avec Certbot : 1. Élaboration d'un Script de Hook\nCréez un script qui initiera le redémarrage de Postfix une fois le certificat renouvelé. Voici un exemple de script que vous pourriez utiliser : Sauvegardez ce script dans un endroit sûr, tel que . Rendez le script exécutable : 2. Intégration avec Certbot\nLorsque vous exécutez Certbot pour le renouvellement des certificats, indiquez ce script comme un hook post-renouvellement. Si Certbot est configuré pour renouveler automatiquement vos certificats, ajoutez votre script dans la configuration de renouvellement de Certbot en modifiant le fichier de configuration du domaine concerné, par exemple, : 3. Exploitation des Directoires de Hooks\nCertbot recherche dans trois répertoires spécifiques des scripts à exécuter en tant que hooks :\n: Avant le renouvellement.\n: Après un renouvellement réussi.\n: Après toute tentative de renouvellement. Placer votre script dans  s'assure qu'il sera exécuté après chaque renouvellement, garantissant ainsi que Postfix redémarre avec le nouveau certificat. 4. Validation de la Configuration\nEffectuez un test de renouvellement pour vous assurer que tout fonctionne correctement : Si tout est bien configuré, Certbot renouvellera le certificat en mode test et exécutera votre script pour redémarrer Postfix. Vérifiez que Postfix fonctionne correctement après le redémarrage. Remarques Importantes :\nSécurité : Assurez-vous que seuls les utilisateurs appropriés ont des permissions d'écriture sur le script et les fichiers de configuration.\nLogs : Surveillez les logs de Certbot et Postfix pour tout problème éventuel lors des renouvellements et redémarrages.\nCompatibilité : Vérifiez que les versions de Certbot et Postfix en usage sont compatibles avec les méthodes décrites ici. En mettant en place un hook bien configuré, vous vous assurez que Postfix fonctionne toujours avec un certificat valide, maintenant ainsi la sécurité et la fiabilité de votre serveur de messagerie."}]