Cédrix
1 line
36 KiB
JSON
1 line
36 KiB
JSON
[{"uuid":"d9006eec-fc78-4e2f-9470-b0d173c68b7c","slug":"installer-mqtt-broker-mosquitto-linux","title":"Installer Mqtt Broker Mosquitto Linux","category":"Électronique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2023-02-18 07:56:13","created_at":"2023-02-18 07:56:13","updated_at":"2023-02-18 07:56:13","tags":[],"plain":"REDIRECT>informatique:applications:mosquitto"},{"uuid":"6016aa4b-f42b-43ef-9957-b893fa030a0c","slug":"mosquitto","title":"Mosquitto : client et serveur MQTT","category":"Informatique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2023-03-14 07:45:19","created_at":"2023-03-14 07:45:19","updated_at":"2023-03-14 07:45:19","tags":[],"plain":"Mosquitto est un courtier de messages (ou broker / serveur MQTT) MQTT open source. Plus d'infos sur MQTT à la page . Mosquitto peut être utilisé pour implémenter des scénarios tels que la collecte de données de capteurs, la surveillance de l'état des appareils et la gestion de l'IoT en général. Les clients MQTT peuvent se connecter à Mosquitto pour publier et/ou recevoir des messages sur des topics spécifiques, permettant une communication efficace et fiable entre les appareils. Dans cet article j'installe Mosquitto sur Rasbperry Pi. Le port par défaut 1883/tcp sera utilisé. Installer le service Mosquitto\nVoici les étapes générales pour installer Mosquitto sur Rasbperry Pi OS, Debian ou Ubuntu : Après l'installation, vous pouvez vérifier si Mosquitto est en cours d'exécution en utilisant la commande dans l'invite de commandes. Cela devrait afficher la version de Mosquitto et les informations de journalisation. Vérifier l’accessibilité du service\nPour vous assurer que le port Mosquitto est ouvert, vous pouvez utiliser un outil en ligne de commande comme nmap pour scanner votre adresse IP publique et vérifier si le port 1883 est ouvert. Par exemple, en utilisant la commande suivante : . Si le port Mosquitto est ouvert, vous devriez voir une ligne dans la sortie de la commande qui indique que le port 1883 est \"open\". Je conseille d’exécuter sur un autre ordinateur que celui qui exécute le service Mosquitto. Configurer la connexion identifiée\nLa connexion à Mosquitto peut être anonyme ou avec un nom d'utilisateur et un mot de passe, selon la configuration du serveur. Dans se paragraphe nous abordons la configuration d'un utilisateur. Pour créer un utilisateur et de définir un mot de passe afin d'accéder à Mosquitto, il faut utiliser l'utilitaire qui est installé avec Mosquitto et permet de gérer les informations d'identification des utilisateurs pour Mosquitto. sudo mosquittopasswd -c /etc/mosquitto/passwd UTILISATEUR Plus spécifiquement, cette commande effectue les actions suivantes :\npermet d'exécuter la commande avec des privilèges d'administrateur pour pouvoir écrire dans le dossier /etc/mosquitto où se trouve le fichier de mots de passe.\nest l'utilitaire de ligne de commande pour gérer le fichier de mots de passe.\ncrée un nouveau fichier de mots de passe s'il n'existe pas déjà, ou remplace un fichier existant.\nest le chemin d'accès complet au fichier de mots de passe à créer ou modifier.\nest le nom d'utilisateur à ajouter au fichier de mots de passe. Vous pouvez remplacer ce nom d'utilisateur par le nom que vous souhaitez utiliser. Une fois que vous avez créé le fichier de mots de passe et ajouté des utilisateurs, vous pouvez utiliser ces informations d'identification pour restreindre l'accès à Mosquitto, en configurant l'authentification basée sur le nom d'utilisateur et le mot de passe dans le fichier de configuration de Mosquitto. Cela est particulièrement important si vous utilisez Mosquitto dans un environnement de production ou si vous souhaitez sécuriser l'accès à votre broker MQTT. Vous devez modifier le fichier de configuration de Mosquitto pour autoriser l'authentification basée sur le nom d'utilisateur et le mot de passe. Ouvrez le fichier de configuration de Mosquitto. Le fichier peut être situé à différents endroits en fonction de votre installation. Par exemple, sur une installation standard de Mosquitto sous Linux, le fichier se trouve généralement dans . Ajoutez les lignes suivantes au fichier de configuration pour spécifier le chemin d'accès au fichier de mots de passe que vous avez créé avec , ainsi que les paramètres d'authentification : passwordfile /etc/mosquitto/passwd\n allowanonymous false Enregistrez le fichier de configuration et redémarrez le service Mosquitto pour que les modifications prennent effet :\n \n sudo systemctl restart mosquitto Après avoir suivi ces étapes, les utilisateurs devront s'authentifier avec un nom d'utilisateur et un mot de passe valides pour publier et souscrire à des messages dans Mosquitto. Si l'utilisateur n'a pas les bonnes informations d'identification, il sera refusé d'accès. Cette fonctionnalité de sécurité renforce la sécurité de Mosquitto et permet de restreindre l'accès à des utilisateurs de confiance uniquement.\n \nConfigurer la connexion anonyme\nLa connexion à Mosquitto peut être anonyme ou avec un nom d'utilisateur et un mot de passe, selon la configuration du serveur. Dans ce paragraphe nous abordons la configuration pour une connexion anonyme. Pour indiquer que la connexion au serveur MQTT est anonyme (sans nom d'utilisateur ni mot de passe), vous devez ajouter les lignes suivantes dans votre fichier de configuration : allowanonymous true Ceci autorisera les connexions anonymes au serveur MQTT. Si cette option n'est pas définie, toutes les connexions nécessiteront un nom d'utilisateur et un mot de passe valides. Assurez-vous de redémarrer le serveur MQTT après avoir modifié le fichier de configuration pour que les modifications prennent effet. Notez que l'utilisation de connexions anonymes peut présenter des risques de sécurité, car cela permet à n'importe qui de se connecter et de publier ou de recevoir des messages sans authentification. Il est donc recommandé d'utiliser des informations d'authentification sécurisées pour protéger votre serveur MQTT.\nEnvoyer / recevoir des messages MQTT\nMosquitto-clients est un outil en ligne de commande fourni avec le broker Mosquitto pour publier et souscrire à des messages MQTT à partir de la ligne de commande. En d'autres termes, Mosquitto-clients permet aux développeurs et aux administrateurs de système de tester et de déboguer des applications MQTT en utilisant des commandes simples pour publier et recevoir des messages. Cela peut être utile pour vérifier la connectivité, le flux de données et le traitement des messages entre les appareils et le broker Mosquitto. Pour installer les clients Mosquitto, y compris le client de ligne de commande et le client d'envoi , vous pouvez suivre ces étapes : sudo apt update\n sudo apt install mosquitto-clients Vous pouvez maintenant utiliser les clients Mosquitto pour publier et souscrire à des messages dans Mosquitto. Par exemple, vous pouvez utiliser la commande pour <u>publier des messages MQTT</u> à un topic : mosquittopub -h localhost -t sensor/elec -m 2546 Par exemple vous pouvez utiliser la commande pour souscrire au topic et <u>recevoir des messages MQTT</u> : mosquittosub -h localhost -t \"sensor/elec\""},{"uuid":"0a16a893-c6d1-49a9-b7bf-473a9b0bcbd3","slug":"les-sujets","title":"150 · Les sujets","category":"Électronique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2023-02-19 07:48:27","created_at":"2023-02-19 07:48:27","updated_at":"2023-02-19 07:48:27","tags":[],"plain":"En MQTT, un sujet (ou topic en anglais) est une chaîne de caractères qui identifie une catégorie ou un canal de communication. Les clients MQTT peuvent s'abonner à un ou plusieurs sujets pour recevoir les messages publiés sur ces sujets. Lorsqu'un client publie un message sur un sujet particulier, tous les clients qui se sont abonnés à ce sujet recevront ce message. Les sujets sont organisés sous forme de hiérarchie à l'aide de barres obliques (/) pour séparer les différents niveaux de la hiérarchie. Par exemple, le sujet pourrait être utilisé pour publier la température de la chambre 1 d'une maison. Les clients peuvent alors s'abonner à pour recevoir des mises à jour sur la température de cette pièce spécifique. Les sujets sont un élément clé de la flexibilité et de l'extensibilité de MQTT, permettant une communication efficace et ciblée entre les différents clients de l'écosystème MQTT. Sujets réservés\nMQTT définit plusieurs sujets réservés (ou reserved topics en anglais) qui ont une signification particulière et qui ne doivent pas être utilisés pour la publication de messages personnalisés. Voici quelques exemples de sujets réservés dans MQTT :\n: ce sujet réservé est utilisé pour publier des informations système sur le broker MQTT lui-même, telles que des statistiques de performance ou des informations de connexion des clients.\n: ce sujet réservé est utilisé pour publier la version du broker MQTT.\n: ce sujet réservé est utilisé pour publier le temps d'activité du broker MQTT.\n: ce sujet réservé permet d'accéder aux différents sous-sujets sous le répertoire , qui contiennent des informations système spécifiques. Il ne faut pas utiliser ces sujets réservés pour publier des messages personnalisés, car cela peut perturber le fonctionnement normal du broker ou des clients MQTT qui s'attendent à recevoir des informations système spécifiques sur ces sujets. Caractère générique #\nEn MQTT, le symbole est un caractère générique utilisé comme joker dans les noms de sujets pour s'abonner à tous les sous-sujets d'un certain niveau. Lorsqu'un client s'abonne à un sujet qui contient le joker , il reçoit des messages publiés sur tous les sous-sujets de ce niveau et de niveaux inférieurs. Par exemple, si un client s'abonne au sujet , il recevra des messages publiés sur tous les sous-sujets de , tels que , , , etc. L'utilisation du joker peut avoir des conséquences importantes sur le trafic réseau et la charge de travail du broker MQTT, en particulier pour les hiérarchies de sujets importantes avec de nombreux sous-sujets. Par conséquent, il est recommandé d'utiliser le joker avec parcimonie et de manière judicieuse, en fonction des besoins spécifiques de votre application MQTT. Lorsque le symbole est utilisé seul comme sujet, il est considéré comme un sujet non valide dans MQTT. En effet, MQTT spécifie que tous les sujets valides doivent commencer par un caractère non-joker. Ainsi, si un client s'abonne à comme sujet, cela n'aura aucun effet, car n'est pas un sujet valide en soi. De même, si un client publie un message avec comme sujet, le broker MQTT refusera le message car n'est pas un sujet valide. Il est important de se rappeler que le broker MQTT peut appliquer des règles spécifiques pour valider les sujets des messages, qui peuvent varier en fonction de l'implémentation spécifique du broker. Il est donc recommandé de vérifier la documentation du broker MQTT pour connaître les règles de validation des sujets. Caractère générique +\nMQTT définit un autre caractère générique, le symbole , qui est utilisé pour s'abonner à un sous-sujet spécifique dans une hiérarchie de sujets. Contrairement au symbole , le symbole ne correspond qu'à un seul niveau de sous-sujet. Par exemple, si un client s'abonne au sujet , il recevra des messages publiés sur tous les sous-sujets qui correspondent au modèle . Les sous-sujets qui correspondent incluent , , etc. Le symbole est donc utile pour filtrer les messages à un niveau spécifique de la hiérarchie de sujets, en s'abonnant à un seul sous-sujet plutôt qu'à l'ensemble du niveau comme avec le symbole . Il est important de noter que le symbole ne peut être utilisé que pour remplacer un seul niveau de sous-sujet, tandis que le symbole peut remplacer plusieurs niveaux de sous-sujets."},{"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":"55a2c5eb-74d2-4c58-a7d1-19d1d824adf1","slug":"incident-acegrp-lan-2-tout-s-explique-enfin","title":"Incident acegrp.lan (2) : Tout s’explique enfin !","category":"domotique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2025-04-30 18:01:00","created_at":"2025-04-30 18:01:00","updated_at":"2025-05-01 04:30:09","tags":[],"plain":"Nous sommes lundi matin. Le silence numérique est assourdissant. Aucun service interne ne répond, et les plateformes A5L sur Internet sont totalement inaccessibles. Rien ne fonctionne. C’est un black-out complet. Le genre de panne qui érode patiemment ton calme et ton raisonnement, heure après heure. La veille, j’avais déjà tout tenté ou presque, sans succès. Et maintenant, le temps presse. Je décide de rapatrier la machine hôte qui fait tourner le NAS, la pièce centrale du puzzle. Ce mini-serveur, habituellement discret et stable, est suspect numéro un. Peut-être qu’en le branchant localement, j’aurai enfin un retour vidéo. Je tente une nouvelle approche : je le connecte à un boîtier d’acquisition HDMI, en utilisant simplement un câble DisplayPort vers HDMI. L’idée est de faire apparaître quelque chose, n’importe quoi, dans OBS, sur mon poste de travail. Mais tout ce que j’obtiens, c’est un écran noir. Rien. Pas un pixel.\r\n\r\nÀ cet instant, tout devient flou. Je commence à remettre en question chaque élément de la chaîne. Le boîtier d’acquisition : fonctionne-t-il réellement ? Le câble : est-il compatible ? Le port DisplayPort : est-il actif au démarrage ? Et la machine elle-même ? Est-ce qu’elle boote seulement ? Je doute de tout. Ce sont les moments les plus pénibles. Quand la panne est silencieuse. Quand tout semble à la fois en cause, et que rien ne parle. C’est dans ces phases de doute profond que je suis le plus vulnérable. J’ai souvent réagi à l’instinct dans ces moments-là, en allant droit vers des actions irréversibles. Formater un disque, réinstaller un système, démonter un châssis complet… sans prendre le temps d’analyser, de poser les bonnes questions. Je le sais, je l’ai déjà vécu, mais aujourd’hui, j’essaie de faire mieux. Je prends une pause. J’observe. J’écoute.\r\n\r\nJe redémarre plusieurs fois la machine, et à chaque fois, j’entends trois bips, espacés, lents, presque inquiétants. Le disque dur semble tournoyer, sans conviction. Pas de réelle activité. L’écran reste noir. Et c’est là que je me souviens d’un paramètre que je n’ai pas vérifié : la configuration de sortie dans OBS. J’ouvre les paramètres d’entrée vidéo, et je me rends compte que la résolution, la fréquence, tout est réglé comme si j’attendais le signal d’une console de jeu en 1080p. Mais un BIOS ? Il sort en 640x480, peut-être 800x600 dans le meilleur des cas… Je change les réglages, ajuste la fréquence, et je relance.\r\n\r\nEt là, comme un miracle numérique, l’image apparaît. Épurée. Grise. En anglais. \r\n« Press <F2> to enter Setup or <F12> to enter Boot Menu. » \r\nEt puis s’enchaînent les erreurs : \r\nERROR - POST - Invalid date / time \r\nERROR - POST - Bad RTC Battery \r\nBIOS Settings defaults loaded. \r\nLa sentence est claire : la pile CMOS est à plat. Elle ne tient plus la date, plus les réglages, plus rien. C’est elle qui empêchait la machine de démarrer correctement, de retrouver ses marques. Quelle absurdité ! Une simple pile bouton de quelques grammes, dans un PC allumé 24h/24 depuis des années. Mais elle a rendu l’âme, discrètement, en silence, et tout s’est effondré autour.\r\n\r\nJe coupe l’alimentation, j’ouvre le boîtier, je localise la pile. Je la retire et la teste au multimètre : 2,5 volts. C’est insuffisant. Je la remplace immédiatement par une neuve, une bonne CR2032 à 3,1 volts. Je remonte le tout, referme le boîtier, rebranche les câbles, et relance. Et là, la magie opère : l’écran Proxmox s’affiche, le système boote, et — enfin — la machine répond au ping. C’est le genre de petit miracle qui donne envie de se lever et d’applaudir dans une pièce vide.\r\n\r\nJe replace donc le serveur à son emplacement habituel, je le redémarre avec confiance… et là, plus rien. Ping muet. Silence réseau. J’étrangle un soupir. Et si c’était… autre chose ? Mon regard se pose sur le switch réseau. Éteint. Plus une LED. Je débranche, rebranche, rien. Je prends un switch de rechange, je le connecte à la place du défaillant, je relie chaque câble avec soin. Et là, tous les services reviennent. Ping OK. Partages NFS OK. Proxmox OK. Le réseau reprend vie comme si de rien n’était.\r\n\r\nL’autopsie du switch est formelle : alimentation HS. Ce petit boîtier discret avait probablement commencé à agoniser lentement depuis plusieurs jours, provoquant des microcoupures entre le NAS et le serveur principal. Les VM avaient perdu l’accès à leur stockage. Les partages s’étaient effondrés. Et tout ça avait été pris pour un bug de Proxmox, un problème de VM… alors que tout partait d’une alimentation à 10 euros.\r\n\r\nAu final, tout s’explique. La pile. Le switch. Le lien entre les deux. \r\nEt moi, au milieu, à jongler entre câbles, BIOS, doutes et bips. \r\nUne tempête technique partie d’un simple maillon faible."}] |