Cédrix
1 line
35 KiB
JSON
1 line
35 KiB
JSON
[{"uuid":"b135816b-2a5c-4a5d-8e04-7b658ddb8775","slug":"20230122-zram","title":"Améliorer les performances Linux avec zRAM","category":"Journal geek","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2023-01-26 23:12:45","created_at":"2023-01-26 23:12:45","updated_at":"2023-01-26 23:12:45","tags":[],"plain":"zRAM (ou Compressed RAM) est un module du noyau Linux qui permet de créer un espace de stockage compressé en mémoire vive (RAM) pour améliorer les performances système. Il fonctionne en créant un ou plusieurs périphériques de swap virtuels (appelés zRAM) qui peuvent être utilisés comme un swap classique pour stocker des données qui ne peuvent pas être stockées dans la mémoire vive. Lorsque des données sont écrites sur un périphérique zRAM, ces données sont compressées avant d'être stockées en mémoire vive. Lorsque les données sont lues, elles sont décompressées avant d'être utilisées. Cela permet d'augmenter la quantité de données qui peuvent être stockées en mémoire vive, réduisant ainsi la pression sur la mémoire physique. La compression de la mémoire peut avoir un coût en termes de consommation de CPU, donc il faut configurer correctement la taille du swap ZRAM pour équilibrer les avantages de la compression de la mémoire avec les coûts de consommation de CPU. Pour activer zRAM sous Linux, vous pouvez utiliser les commandes suivantes :\nInstaller le paquet zram-config en utilisant le gestionnaire de paquets de votre distribution.\nActiver le module zRAM en utilisant la commande : . Cette commande va créer 4 périphériques virtuels : /dev/zram{0,1,2,3}. Le paramétré numdevices est optionnel et demande à zRAM de pré-créé un nombre de périphérique virtuel. La valeur par défaut est de 1.\n- Les différentes options suivantes permettent de configurer le module zRAM.\n<u>Configurer l'algorithme de compression</u> (compalgorithm) pour swap zRAM en utilisant la commande : (cette commande configure l'algo de compression de zRAM sur ). Afficher les algorithmes de compression supportés en utilisant la commande : \n<u>Configurer la taille du swap zRAM</u> (disksize) en utilisant la commande : (cette commande configure une taille de zRAM de 512 Mo). Il est généralement recommandé de configurer la taille du swap ZRAM pour être égale à environ 50% de la mémoire vive totale de votre système. Cependant, si vous avez des besoins spécifiques de mémoire, vous pouvez augmenter ou diminuer cette valeur en conséquence. Il n'y a pas beaucoup de sens à créer un zRAM de taille supérieure à deux fois la mémoire, car nous nous attendons à un ratio de compression de 2:1. Notez que zRAM utilise environ 0,1 % de la taille du disque lorsqu'il n'est pas utilisé, donc un zRAM énorme est gaspillé.\n<u>Afficher le nombre de flux de compression</u> (maxcomstreams). Indépendamment de la valeur passée à cet attribut, zRAM allouera toujours plusieurs flux de compression - un par CPU en ligne - permettant ainsi plusieurs opérations de compression simultanées. Le nombre de flux de compression alloués diminue lorsque certains des CPU deviennent hors ligne. Il n'y a plus de mode de flux de compression unique, à moins que vous ne fonctionniez avec un système UP ou avec un seul CPU en ligne. Pour découvrir combien de flux sont actuellement disponibles : \n-\nInitialiser et activer le SWAP zRAM en utilisant les commandes : \nDésactiver le SWAP zRAM en utilisant les commandes : \n-- Il existe plusieurs moyens de vérifier si ZRAM fonctionne sur votre machine Linux. Voici quelques commandes courantes pour vérifier l'état de ZRAM : . Utilisez la commande pour afficher la liste des périphériques de swap actuellement utilisés par le système, vous devriez voir un périphérique zram0 si zRAM est activé. . Utilisez la commande pour vérifier si le module zRAM est actuellement chargé dans le noyau. . Utilisez la commande pour vérifier l'utilisation de la mémoire physique et du swap. . Utilisez la commande pour vérifier la taille configurée pour zRAM.\n-- Ces commandes peuvent varier selon les distributions Linux. Il est donc préférable de consulter la documentation de votre distribution pour des instructions spécifiques, ou la documentation officielle https://www.kernel.org/doc/html/latest/admin-guide/blockdev/zram.html"},{"uuid":"c2d73c42-d1c4-470c-a7de-f5d3c1056f1a","slug":"comparer-ports-raspberrypi","title":"Comparaison des ports","category":"Électronique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2023-02-02 07:59:38","created_at":"2023-02-02 07:59:38","updated_at":"2023-02-02 07:59:38","tags":[],"plain":"Comparaison des ports des Raspberry Pi.\nRaspberry Pi 1 Model A | Raspberry Pi 1 Model A+ | Raspberry Pi 1 Model B | Raspberry Pi 1 Model B+ | Raspberry Pi 2 Model B | Raspberry Pi 3 Model B | Raspberry Pi Zero | Raspberry Pi 4 model B |\n---------------------- | ----------------------- | ---------------------- | ----------------------- | ---------------------- | ---------------------- | ----------------- | ---------------------- |\nUSB Ports | 1 USB 2.0 | 1 USB 2.0 | 2 USB 2.0 | 4 USB 2.0 | 4 USB 2.0 | 4 USB 2.0 | 1 micro USB 2.0 | 2 USB 2.0\\\\ 2 USB 3.0 | |\nEthernet | | | 10/100 Mbits/s | 10/100 Mbits/s | 10/100 Mbits/s | 10/100 Mbits/s | | 1 Gbits/s | |\nBluetooth | | | | | | 4.1 | | 5.0 | |\nWiFi | | | | | | 802.11n | | bi-bande 802.11b/g/n/ac | |\nAudio In | I²S | I²S | I²S | I²S | I²S | I²S | I²S | I²S | |\nAudio Out | I²S\\\\ Analog 3.5 mm jack\\\\ Digital HDMI | I²S\\\\ Analog 3.5 mm jack\\\\ Digital HDMI | I²S\\\\ Analog 3.5 mm jack\\\\ Digital HDMI | I²S\\\\ Analog 3.5 mm jack\\\\ Digital HDMI | I²S\\\\ Analog 3.5 mm jack\\\\ Digital HDMI | I²S\\\\ Analog 3.5 mm jack\\\\ Digital HDMI | Digital HDMI\\\\ Analog GOPI PWM | I²S\\\\ Analog 3.5 mm jack\\\\ Digital HDMI | |\nVideo In | CSI Camera Connector | CSI Camera Connector | CSI Camera Connector | CSI Camera Connector | CSI Camera Connector | CSI Camera Connector | | CSI Camera Connector | |\nVideo Out | HDMI\\\\ Composite RCA | HDMI\\\\ Composite TRRS | HDMI\\\\ Composite RCA | HDMI\\\\ Composite TRRS | HDMI\\\\ Composite TRSS | HDMI\\\\ Composite TRSS | Mini HDMI\\\\ GPIO Composite | 2 Micro HDMI 4K\\\\ Composite TRSS | |\nExternal Storage | SD | Micro SD | SD | Micro SD | Micro SD | Micro SD | Micro SD | Micro SD | |"},{"uuid":"da406813-bf15-4f4e-a700-2752550224bb","slug":"quand-la-3g-suffisait-et-qu-on-vous-fait-basculer","title":"Quand la 3G suffisait… et qu’on vous fait basculer","category":"télécom","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2025-11-05 08:38:25","created_at":"2025-11-05 08:38:25","updated_at":"2025-11-05 08:38:25","tags":[],"plain":"Une plongée scientifique et technologique dans l’évolution des réseaux mobiles et la stratégie des opérateurs.\r\n--\r\n\r\nIntroduction\r\nEn 2015, votre 3G suffisait pour le télétravail, la visioconférence et le streaming léger. Aujourd’hui, même pour un simple email, certaines zones semblent plus lentes qu’avant.\r\n\r\nL’histoire des télécommunications mobiles est jalonnée de révolutions techniques. Chaque génération de réseau – de la 2G à la 5G – a apporté des débits supérieurs, des latences réduites et de nouveaux usages. Pourtant, derrière la façade technologique, une stratégie commerciale se dessine : la migration forcée des utilisateurs vers les nouvelles générations. Ce dossier examine comment la 3G, la 4G et la 5G se succèdent, comment les opérateurs orchestrent le passage d’une technologie à l’autre, et quels impacts cela a sur l’expérience utilisateur.\r\n--\r\n\r\nLa 3G : une technologie encore performante… bridée par les opérateurs\r\n\r\nDéfinition et usages\r\n\r\nLa 3G (UMTS/HSPA) a marqué un saut qualitatif par rapport à la 2G. Développée à la fin des années 1990 et déployée massivement à partir de 2004, elle permettait :\r\n\r\n des débits théoriques de 384 kbit/s jusqu’à 42 Mbit/s pour les variantes HSPA+ ;\r\n des applications comme le surf web, la messagerie instantanée, les appels VoIP et la visioconférence légère ;\r\n une latence moyenne de 150–200 ms, suffisante pour la plupart des usages bureautiques.\r\n\r\nPour l’utilisateur lambda, la 3G suffisait amplement. Pourtant, à partir de 2016–2017, certains opérateurs ont commencé à réduire volontairement les performances.\r\n\r\nExemple concret : Free Mobile\r\n\r\nFree Mobile, en itinérance sur le réseau Orange, a progressivement bridé les débits 3G :\r\nAnnée | Débit descendant | Débit montant |\r\n----- | ---------------- | ------------- |\r\n2016 | 5 Mbit/s | 0,5–1 Mbit/s |\r\n2017 | 1 Mbit/s | 0,5 Mbit/s |\r\n2019 | 768 kbit/s | 384 kbit/s |\r\n2020 | 384 kbit/s | 384 kbit/s |\r\nSource : 01net – Free Mobile et bridage 3G\r\n\r\nLes utilisateurs constatent alors que leur expérience, auparavant fluide, devient frustrante : ralentissement du web, vidéos qui ne se chargent pas correctement, visioconférences de qualité médiocre.\r\n\r\nPourquoi un bridage ?\r\n\r\nLe bridage de la 3G s’explique par plusieurs facteurs :\r\n\r\n1. Refarming du spectre : libérer les fréquences 900/1800/2100 MHz pour la 4G et la 5G ;\r\n2. Coût d’entretien : maintenir un réseau 3G coûteux pour des utilisateurs minoritaires n’est plus rentable ;\r\n3. Incitation à migrer : les abonnés passent naturellement aux nouvelles technologies pour profiter de meilleurs débits.\r\n\r\nSchéma suggéré : flux de données et coût par bit en 3G vs 4G.\r\n--\r\n\r\nLa 4G : la révolution nécessaire\r\n\r\nDéfinition technique\r\n\r\nLa 4G, ou LTE (Long Term Evolution), est une avancée majeure :\r\n\r\n Débits théoriques : 100 Mbit/s → 1 Gbit/s ;\r\n Latence : 30–50 ms ;\r\n Architecture optimisée : eNodeB remplace le contrôleur RNC de la 3G pour réduire les goulots d’étranglement ;\r\n Utilisations : streaming HD, cloud computing, jeux en ligne, IoT.\r\nLa 4G a donc transformé l’expérience mobile et a rendu certaines limitations 3G plus visibles que jamais.\r\n\r\nStratégies de migration\r\n\r\nLes opérateurs incitent à la migration par :\r\n\r\n le bridage des anciennes générations ;\r\n la publicité sur les débits 4G/5G ;\r\n le lancement de forfaits “4G-only”.\r\nOpérateur | 3G moyen (Mbit/s) | 4G moyen (Mbit/s) |\r\n--------- | ----------------- | ----------------- |\r\nFree | 0,384 | 50–150 |\r\nOrange | 0,5–1 | 60–200 |\r\nSFR | 0,5 | 50–150 |\r\nBouygues | 0,5 | 50–150 |\r\nGraphique suggéré : part des abonnés 4G vs 3G (2015–2025).\r\n--\r\n\r\nLa 5G : promesse et réalité\r\n\r\nLes promesses\r\n\r\n Débits : 100 Mbit/s → 10 Gbit/s selon fréquence et densité d’antennes ;\r\n Latence ultra faible : 1–10 ms ;\r\n Fréquences : 700 MHz → 26 GHz (mmWave) ;\r\n Usages : cloud gaming, véhicules autonomes, IoT à grande échelle.\r\n\r\nL’expérience utilisateur\r\n\r\nMême scénario qu’avec la 3G : certaines zones restent en 4G bridée, incitant les utilisateurs à passer à la 5G. La promesse de la 5G ne se réalise pleinement que dans les zones très denses ou les zones pilotes.\r\n\r\nSchéma suggéré : architecture 4G vs 5G.\r\n--\r\n\r\nConséquences pour l’utilisateur\r\n\r\n Scénarios pratiques : visioconférence, streaming, cloud computing, IoT ;\r\n Expérience variable selon réseau : frustration sur 3G bridée, fluidité sur 4G/5G ;\r\n Témoignages utilisateurs : Reddit, forums français, témoignages directs.\r\n“Dès qu’on tombe en 3G, rien ne charge correctement… le réseau est volontairement dégradé.” – Reddit\r\n--\r\n\r\nSynthèse scientifique\r\nGénération | Débit théorique | Latence | Couverture | Usages possibles | Coût par bit | Bridage existant |\r\n---------- | ---------------------- | ---------- | ---------- | -------------------------------------- | ------------ | ---------------------- |\r\n3G | 384 kbit/s → 42 Mbit/s | 150–200 ms | Très large | Email, surf, visio légère | Élevé | Itinérance bridée Free |\r\n4G | 100 Mbit/s → 1 Gbit/s | 30–50 ms | Large | Streaming HD, jeux, cloud | Moyen | Bridage minoritaire |\r\n5G | 100 Mbit/s → 10 Gbit/s | 1–10 ms | Variable | IoT, cloud gaming, véhicules autonomes | Faible | Pas encore |\r\nLe bridage apparaît comme une stratégie commerciale autant qu’une conséquence technique, visant à préparer l’utilisateur à migrer vers de nouvelles technologies.\r\n--\r\n\r\nPerspectives et conseils\r\n\r\n Vérifier la couverture et la technologie disponible selon votre zone ;\r\n Questionner son opérateur :\r\n\r\n 1. Suis-je sur le réseau propre ou en itinérance ?\r\n 2. Quels sont les débits effectifs en 3G et 4G ?\r\n 3. Quand la 3G sera-t-elle désactivée ?\r\n Anticiper le passage à la 5G pour certains usages exigeants (IoT, cloud gaming, télétravail intensif).\r\nVous pouvez encore profiter de votre 3G… mais à quel prix ?\r\n--\r\n\r\nRéférences principales\r\n\r\n1. 01net – Free Mobile et bridage 3G\r\n2. Univers Freebox – Bridage 3G\r\n3. ARCEP – Gestion spectre et couverture\r\n4. Free Mobile – Fiche information standardisée 2020 (PDF)"},{"uuid":"ff9c1832-16a6-49e2-8a1f-40e894c1d7b1","slug":"ou-acheter-son-raspberrypi4","title":"Où acheter son Raspberry Pi 4 ?","category":"Électronique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2023-08-14 06:22:08","created_at":"2023-08-14 06:22:08","updated_at":"2023-08-14 06:22:08","tags":[],"plain":"Je vous propose une sélection de sites Internet vendant le Raspberry Pi 4, 4 Go en France Métropolitaine. Mais avant tout, je reviens sur les caractéristiques du produit. Caractéristiques principales : 1. Carte mère Raspberry Pi 4\nPocesseur : Broadcom BCM2711, quad-core Cortex-A72 (ARM v8) 64-bit SoC @ 1.5GHz\nRAM : 4 Go LPDDR4\nGPU : VideoCore VI prenant en charge OpenGL ES 3.0\nConnexion sans fil : Bluetooth 5.0, BLE\\\\ Wi-Fi 802.11b/g/n/ac de 2,4 GHz et 5,0 GHz\nConnexion filaire : Gigabit Ethernet (RJ45)\nLecteur de carte micro-SD (stockage non fourni)\nPort caméra CSI pour connecter la caméra Raspberry Pi\nPort d'affichage DSI pour connecter l'écran tactile Raspberry Pi\nAudio : AV 3.5 mm\nMultimédia : H.265 (décodage 4Kp60)\\\\ H.264 (décodage 1080p60, encodage 1080p30)\\\\ OpenGL ES, 3.0 graphiques\nPorts : 2 x USB 3.0 \\\\ 2 x USB 2.0 \\\\ 1 x USB-C (alimentation seulement) \\\\ 1 x GPIO 40 pin (compatibilité ascendante avec les cartes précédentes) \\\\ 1 x port quadripôle Audio/Vidéo composite \\\\ 2 x micro-HDMI\nAlimentation 5V / 3.1A (non fournie) par USB-C ou GPIO\\\\ Power over Ethernet (PoE) possible – (nécessite l'acquisition d'une carte PoE HAT)\nEnvironnement : Température de fonctionnement 0–50 ° C\n-- LDLC propose cette carte mère ultra-compacte au prix de 79,95€. Le site met en avant le processeur Broadcom BCM2711 gagne en performance par rapport à son prédécesseur pour une exécution des calculs encore plus fluide. Aucune date de disponibilité. https:www.ldlc.com/fiche/PB00273916.html\n-- McHobby propose ce Nano-Ordinateur mono-carte au prix de 59,90€. Le site met en avant le Raspberry Pi 4 qui est, aujourd'hui, vraiment en mesure de remplacer un ordinateur de bureau. Il est disponible sans être disponible .... https:shop.mchobby.be/fr/raspberry-pi-4/1610-raspberry-pi-4-4-go-de-ram-dispo-en-stock--3232100016101.html\n-- Kubbi propose cet ordinateur au prix de 58,95€. Le site met en avant le Raspberry Pi 4 modèle B qui offre des performances de bureau comparables à celles des systèmes PC d'entrée de gamme x86. Il est en pré-commande pour une livraison en septembre. https:www.kubii.fr/les-cartes-raspberry-pi/2677-nouveau-raspberry-pi-4-modele-b-3272496298750.html\n-- Elektor propose ce mutant au prix de 59,95€. Le site met en avant ce Raspberry Pi 4 B qui n’a plus rien à envier à un système PC x86 d'entrée de gamme. Il est en pré-commande pour une livraison le 19 août. https:www.elektor.fr/raspberry-pi-4-b-4-gb-ram\n-- 2019/08/02 23:38\\\\\nAucun lien sponsorisé"},{"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."}] |