GuiGui's Show

Dommage, je m'en servais pour régler en espèces et ainsi éviter de filer le numéro de ma CB à Valve / au ternet. :(

La décision rendue par le Conseil d'État le 5 juin 2026 est d'une concision remarquable. Elle rejette, pour incompétence de la juridiction administrative, le recours formé par l'association Sites et Monuments contre la décision du Président de la République de prêter la tapisserie de Bayeux, pour une exposition au British Museum.

L'association invoquait des motifs de forme, notamment l'absence de contreseing du Premier ministre et du ministre de la Culture au regard de l'article 19 de la constitution. Sur le fond, elle voyait une erreur manifeste d'appréciation dans la décision de prêter une oeuvre exceptionnelle, alors qu'un voyage comportait des risques pour sa conservation. On ne connaîtra jamais les réponses à ces questions, car le Conseil d'État déclare la requête irrecevable en considérant la décision du Président de la République comme un acte de gouvernement. […]

[…]

Le principe est donc clair. Ce n'est pas parce que le Président prend une décision qu'il faut en déduire l'existence d'un acte de gouvernement. Encore faut-il que l'acte se rattache, par son nature et son objet, soit aux rapports entre les pouvoirs constitutionnels, soit à la conduite des relations internationales. Dans l'affaire de la tapisserie de Bayeux, on a pourtant l'impression que le Conseil d'État estime que, puisque le Président est intervenu, c'est sans doute que sa décision relevait des relations internationales et qu'elle devait ainsi être qualifiée d'acte de gouvernement. Le raisonnement est inversé. Ce n'est plus le contenu de l'acte qui fait l'acte de gouvernement, mais essentiellement son auteur.

[…]

Sans doute, mais l'analyse se rapproche tout de même un peu trop d'une émission historique conçue par Stéphane Bern. Tout y est. Les décisions se prennent entre les autorités royales naturellement bienveillantes lors d'un dîner de Cour, où l'on rappelle l'histoire millénaire qui unit nos deux pays....

Hélas, il ne faut pas confondre Gala et l'Actualité Juridique Droit administratif. On devrait plutôt se demander si le ministre de la Culture n'était pas compétent pour décider du prêt de la tapisserie. En droit positif, le prêt d'une oeuvre appartenant à une collection publique pour des expositions temporaires à l'étranger relève de procédures administratives spécifiques, dans le but de répondre aux exigences liées à leur conservation et à leur sécurité. Le ministre de la Culture dispose en principe de larges prérogatives pour encadrer, autoriser ou refuser de tels déplacements d'oeuvres patrimoniales. En l'espèce, il a été totalement court-circuité.

Supposons un instant, rien qu'un instant, que le ministre de la Culture ait pris la décision de prêter la tapisserie au British Museum comme ses compétences l'y autorisaient. Dans ce cas, cette décision était susceptible de recours, et le moyen fondé sur l'erreur manifeste d'une telle décision au regard de l'état de conservation d'une telle oeuvre aurait été examiné.

En l'espèce, la décision est remontée jusqu'au Président de la République qui en a, évidemment, fait un élément de sa communication personnelle. Le résultat est que le ministre de la Culture n'était plus compétent que pour exécuter un acte du gouvernement qui échappait à son appréciation comme au contrôle du juge. Les prescriptions du code du patrimoine destinées à assurer la bonne conservation des oeuvres n'étaient plus pertinentes dans l'affaire.

La décision du 5 juin 2026 conduit ainsi à considérer l'acte de gouvernement comme un instrument du pouvoir d'évocation du Président de la République. Comme Louis XIV avant lui, Emmanuel Macron fait remonter les affaires qui l'intéressent au niveau diplomatique. Une promesse faite au château de Windsor devient un acte de gouvernement qui précisément contourne la compétence gouvernementale et interdit toute contestation.

On assiste ainsi au développement d'une diplomatie présidentielle dans laquelle le Président définit lui-même l'étendue de ses compétences. Il présidentialise les actes administratifs pour les soustraire au contrôle du juge et le Conseil d'État valide cette pratique sans se poser trop de questions. La compétence de l'auteur de l'acte, moyen d'ordre public par excellence, n'est pas évoquée, pas plus que l'absence de contreseing pourtant imposé par l'article 19 de la Constitution. Il valide ainsi un pouvoir présidentielle plus personnel qu'institutionnel. Quant à l'état de la tapisserie, il n'a pas besoin d'être examiné puisque le contrôle de fond n'a pas lieu. […]

#LLC

Une même URL excepté le protocole, deux fichiers au contenu différent.

Deux fichiers, nommés fichier et fichier.https.

Dans le VirtualHost https : Alias <URL> </chemin/vers/fichier.https>.

La directive étant absente du virtualhost http, c'est bien fichier, et non fichier.https, qui sera servi en HTTP.

Excellente vidéo de Scilabus sur les expériences spatiales ou en milieux analogues (station antarctique, sous-marins, alitement ‒ lit incliné à -6 degrés ‒, immersion sèche ‒ caisson d'eau avec isolement entre l'eau et un sujet ‒) : choix des expériences par les agences spatiales et par les astronautes (volontariat, avec les scientifiques qui pitchent), l'emploi du temps contraint d'un astronaute, la difficulté de préparer techniquement une expérience car un vol 0G ne met pas en exergue tous les problèmes (ex. : dépannage d'un casque VR entre l'ISS et la terre), coordination visio-manuelle en impesanteur, etc.

Il y a quelques années, j'apprenais, via Aeris, que des paramètres relatifs au chiffrement d'une partition chiffrée Linux (LUKS) sont déterminés à la création, qu'en fonction du contexte (vieille bécane, par ex.), ils peuvent être insuffisants, et qu'ils ne sont pas magiquement à l'épreuve du temps.

Notamment, il y avait un nombre d'itérations (devenu time cost) sur le keyslot (qui n'a rien à voir avec le condensant la clé du volume, « digest » dans luksDump). Depuis la version 1.7.0 de crypsetup, le minimum d'itérations doit représenter 2 secondes. Avec la fonction de dérivation de clé Argon2, il y a également un coût mémoire (memory cost) et un coût CPU (parallel cost). Par défaut : mémoire = 128 Mo ; temps = 0,8 s / 2s ; et parallel cost = nombre de cœurs, plafonné à 4 (sources : 1 et point 10.5).

La section 4 du RFC 9106 présente les paramètres recommandés : « Key derivation for hard-drive encryption, which takes 3 seconds on a 2 GHz CPU using 2 cores -- Argon2id with 4 lanes and 6 GiB of RAM. ». Au point 10.5 de sa FAQ, cryptsetup expose pour quoi il y déroge, notamment sur la quantité de RAM.

Je suis déjà passé à Argon2 (donc au format d'entête LUKS v2) en 2023.

Histoire d'être prévenant et à l'épreuve du temps, j'ai décidé de faire en sorte que le nombre d'itérations occupe environ 5 secondes : cryptsetup luksConvertKey /dev/sdXY --pbkdf argon2id --hash sha512 --iter-time 5000 (le changement se fait à chaud, sans perte de données).

Sur mon ordi à la maison, cela a donné : time cost = 19 ; memory cost = 1 Go ; parallel cost = 4. Cela prend environ 5 secondes pour monter la partition chiffrée.

Pour un disque dur USB utilisé sur cet ordi, cela m'a donné time cost = 17, le reste identique. Sur un autre disque dur USB sur ce même ordi, time cost = 19 (et le reste identique). :D Même remarque concernant le temps pour monter ces conteneurs chiffrés.

Sur ce même ordi, j'ai créé une partition chiffrée sur un disque dur interne SATA branché à un convertisseur USB. Puis je l'ai monté (avec VirttIO) dans une machine virtuelle distante. Time cost = 7, memory = 1G, et je n'ai pas relevé le parallel cost. Mais, sur cette VM, contrairement à l'ordi qui a créé la partition chiffrée, je n'ai qu'un cœur CPU et 1 Go de RAM (à l'époque). --iter-time 5000 m'a fait passer à time cost = 12 et memory = 680 Mo. Je voulais le même coût temporel que sur mon ordi à la maison (19). Je l'ai obtenu avec --iter-time 8000, pour 695 Mo de RAM et 1 cœur CPU. Cela prend environ 8 secondes pour monter la partition.

Sur une autre VM distante, avec 2 cœurs et 2 Go de RAM, --iter-time 5000 a produit un time cost = 4 ; memory = 258 Mo ; parallel = 2. Trouvant cela insuffisant, j'ai obtenu time cost = 20 et memory = 662 Mo avec --iter-time 10000. Conséquence : environ 10 secondes pour monter la partition.

On constate donc que, pour une même durée de dérivation de clé, 5 secs, on a bien des paramètres différents en fonction de la vélocité de la machine : time cost (= itérations) = 17 ou 19 pour 1 Go RAM et 4 cœurs ; time cost = 12 pour 680 Mo de RAM et un cœur, et time cost = 4 pour 258 Mo de RAM et 2 cœurs.

Note : la partition système de mon ordi à la maison utilise sha1 pour le condensat de la clé de volume. Le point 3.4 de la FAQ officielle consigne que cela ne peut pas être changé sans perte de données, mais aussi que cela est sans grande incidence sur la sécurité.

Il y a quelques années, j'ai constaté la réception de courriels depuis l'extérieur par des comptes systèmes (man, www-data, mysql, etc.) de mon serveur emails.

Néanmoins, c'était qu'un seul serveur sur les deux. Un test m'avait confirmé cela.

Cette divergence s'explique par le fait que, d'un côté, le MDA est Postfix, alors que, de l'autre côté, c'est Dovecot.

Or, le message d'erreur de ce dernier est limpide : « dovecot: lda(8499): Fatal: Mail access for users with UID 33 not permitted (see first_valid_uid in config file, uid from userdb lookup). »

Quant à lui, Postfix ne vérifie même pas, par défaut, qu'un répertoire personnel existe (paramètre « require_home_directory »). Cela se comprend pour quelques usages (notamment quand le maildir n'est pas dans le home).

Postfix ne propose aucune option équivalente à celle de Dovecot (sauf pour les boîtes aux lettres virtuelles, c'est-à-dire non-associées à un utilisateur du système, avec « virtual_minimum_uid »).

On peut utiliser « local_recipient_maps » avec un tableau associatif (map) qui contient uniquement les utilisateurs autorisés à recevoir des courriels. Mais flemme.

Au final, j'avais utilisé « header_checks » (dont j'ai déjà parlé ici et là pour d'autres cas d'usage). Jeter silencieusement (= action « DISCARD ») tous les messages dont l'entête « From » contient l'adresse d'un compte système (ce qui impose de tous les lister) ou qui ne contient pas les utilisateurs autorisés à recevoir.

Depuis, j'ai remplacé ce Postfix par OpenSMTPD dont le MDA Maildir ne délivre pas un courriel quand le Maildir n'existe pas.

J'ai entendu des militants, qui procèdent par des recours en justice contre des décisions de l'État (au sens large), se plaindre des pics d'activité estival et hivernal des juridictions administratives, notamment du Conseil d'État. Ces rushs témoigneraient d'une piètre qualité des décisions rendues. J'ai également entendu des avocats évoquer l'existence de ces pics. Certains de mes recours ont été traités au cours d'une telle ruée.

Il y a deux points à vérifier dans cette assertion : 1) l'existence de pics d'activité ; 2) leur lien avec des décisions médiocres (pas défavorables aux militants, mais médiocres). Ce deuxième point est difficilement démontrable, donc je vais me concentrer sur le premier.

Même si, à mon sens, l'existence de pics d'activité ne prouverait rien. Dans mes boulots salariés d'informaticien, que ce soit dans le privé ou le public, le milieu et la fin d'année sont utilisés comme des marqueurs temporels, ça serait bien de terminer tels travaux d'ici là. Cela se combine avec une baisse des sollicitations externes, ce qui permet d'avancer plus vite ce qu'on peine à réaliser le reste de l'année. Ça ne dit rien de la qualité, bien au contraire puisqu'on avait du temps.

Il pourrait en être de même des juridictions administratives : moins de recours, donc moins de travail immédiat (référés, tri par ordonnance, etc.), notamment pour les greffes, et moins d'interactions avec les administrations au ralenti, donc plus de temps pour préparer et communiquer les décisions de justice. D'ailleurs, au pénal a minima, il existe un service allégé 12 semaines par an qui « permet aux magistrats de rédiger leurs arrêts et jugements suite aux audiences surchargés du mois de juin ». C'est donc plus de l'organisation que de l'abattage des parties.

Plusieurs décisions fouillées, et/ou qui vont dans le bon sens, ont été rendues en fin d'année : CE 473506 du 31/12/2024 sur les drones policiers, CE 489990 du 21/12/2023 sur Briefcam, CE 447518 / 447515 / 447513 du 24/12/2021 sur les fichiers de police EASP, PASP, et GIPASP. De même, dans mes décisions CE 490189 et autres du 31/07/2025, surtout dans les conclusions (non-publiées), le CE a précisé le niveau information que doit délivrer la CNIL lors du traitement d'une réclamation.

Bref, l'hypothèse complète (médiocrité car rush) est compromise. On va voir que la minimaliste (existence de rushs) est cabossée.

Concernant le Conseil d'État (CE)

Toutes les décisions, et encore moins les ordonnances, ne sont pas dans le moteur de recherche du CE.

On peut utiliser le moteur de recherche de l'opendata de la justice administrative, mais il ne remonte pas avant septembre 2021.

C'est pour quoi je travaille sur la période 2022-2025.

Tableaux bruts

Pour info :

• Collecter les données. Pour les décisions : https://opendata.justice-administrative.fr/recherche/api/Date_Checkbox/openData/Date_Lecture/D%C3%A9cision/DATE_DÉBUT/DATE_FIN/null/200. Pour les ordonnances : https://opendata.justice-administrative.fr/recherche/api/Date_Checkbox/openData/Date_Lecture/Ordonnance/DATE_DÉBUT/DATE_FIN/null/200 ;

• Du coup, ça s'automatise bien avec bash (l'outil exige une date de fin valide, on ne peut pas considérer que tous les mois ont 31 jours) :

  for dateFin in 2025-01-31 2025-02-28 2025-03-31 2025-04-30 2025-05-31 2025-06-30 2025-07-31 2025-08-31 2025-09-30 2025-10-31 2025-11-30 2025-12-31
  do
    curl -s https://opendata.justice-administrative.fr/recherche/api/Date_Checkbox/openData/Date_Lecture/D%C3%A9cision/2025-${dateFin:5:2}-01/$dateFin/null/200 | jq .decisions.body.hits.total.value
  done

  
  

• Je suis passé automatiquement d'un tableur Calc à Markdown en utilisant le format CSV et pandoc : pandoc -f csv -t markdown_phpextra stats_CE.csv -o stats_CE.md. Pandoc ne prend pas en charge le format ods (tableur Calc) ;
  
  
• Je rappelle que, dans une formule pour tableur, on peut rendre variable ou invariable une ligne ou une colonne lors du remplissage automatique. « $B2 » = colonne invariable, ligne variable ; « B$14 » = colonne variable, ligne invariable.

Formatage conditionnel

Afin d'y voir plus clair, ajoutons du formatage conditionnel.

La couleur est par couple { colonne ; année }. Autrement dit, il n'y a pas de cohérence entre deux colonnes d'une même année, ni entre deux années. La graduation dépend des valeurs d'une colonne pour une année.

Pour info, LibreOffice Calc permet l'exportation direct en formats image, dont png.

Commentaires

On constate que les pics d'activité n'ont pas lieu aux mêmes moments entre les décisions et les ordonnances. Logique, ce n'est pas la même charge de travail, ni la même variabilité liée à l'activité des justiciables.

Même sur les décisions, on constate que les pics estival et hivernal n'étaient pas autant marqués en 2022 et 2023. Pour conclure, il nous faudrait les chiffres pour les années antérieures.

Concernant l'ensemble des juridictions administratives (dont le CE)

Je ne retiens pas l'année 2022 car l'open data des cours administratives d'appel commence en mars 2022 et celui des tribunaux en juin 2022.

Tableaux bruts

Mise en forme conditionnelle

Mêmes constats que pour le CE : le rythme des ordonnances est différent de celui des décisions, et, même pour les décisions, les pics ne sont pas forcément en juillet et décembre.

Et pour la Cassation ?

Même si les conversations auxquelles je me réfère au début de cet article portaient sur les juridictions administratives, et surtout le CE, la comparaison m'intéresse.

J'ai pris la même période que pour le CE.

Tableaux bruts

Pour info :

• La Cass propose une véritable API, mais il faut un compte sur un portail. Relou ;
  
  
• Contrairement au moteur de recherche de l'open data de la justice administrative, celui de la Cass retourne l'ensemble de la page HTML, pas les décisions en JSON. Un élément « span » avec un attribut « id » distinctif, « researchNbResults », contient le nombre de résultats ;
  
  
• On pourrait utiliser XPath pour le récupérer, mais les outils en ligne de commande xmllint et xmlstarlet, que j'ai déjà présentés ici ne tolèrent pas le HTML mal formé, dont celui de la Cass ;
  
  
• On pourrait dégainer DOMDocument et DOMXpath de PHP ou Beautiful Soup de Python, mais flemme, un peu ;
  
  

• On peut faire vite-fait mal-fait avec grep et une regex look-behind (dont j'ai déjà parlé là : grep -Po '(?<=researchNbResults">)[0-9]+' ;

• Pour passer la protection anti-robots de la Cass, il faut avoir des entêtes HTTP, dont des cookies, corrects. Le plus pratique et rapide est d'utiliser « Copier la valeur » -> « Copier comme cURL » de l'onglet réseau des outils de développement web de Firefox. On y chaîne la commande grep du point précédent, et on met ça dans une boucle. Là encore, il faut gérer la durée différente des mois. Ça donne ça :

  for dateFin in 2025-01-31 2025-02-28 2025-03-31 2025-04-30 2025-05-31 2025-06-30 2025-07-31 2025-08-31 2025-09-30 2025-10-31 2025-11-30 2025-12-31
  do
    curl -s "https://www.courdecassation.fr/recherche-judilibre?search_api_fulltext=&date_du=2025-${dateFin:5:2}-01&date_au=$dateFin&judilibre_juridiction=all&op=Rechercher+sur+judilibre" [TOUS_LES_ENTÊTES_ICI] | grep -Po '(?<=researchNbResults">)[0-9]+'
  done

  
  

• J'aurais également pu utiliser le parseur HTML pup (empaqueté dans Debian stable, site officiel) : pup 'span[id="researchNbResults"] text{}' (ou pup 'span#researchNbResults text{}').

Formatage conditionnel

Commentaire

Les pics d'activité ne sont pas réguliers et ne tombent même pas en juillet et décembre. :D

Je pense que cela s'explique en ce que la Cass n'est saisie que de pourvois de dernier ressort, alors que le CE est aussi saisi de recours en premier ressort (contre des décrets ou arrêtés ministériels, des décisions d'autorités administratives indépendantes, etc.). Du coup, la Cass doit être moins sensible à la variation de l'activité des justiciables.

Et pour les cours d'appel de l'ordre privé ?

Attention, en fonction de la matière, les décisions des cours d'appel ne sont pas encore publiées en open data, et celles des tribunaux ne le sont pas (source).

Je ne prends pas l'année 2022 car l'open data des cours d'appel commence en avril.

Tableaux bruts

Formatage conditionnel

Commentaire

À nouveau, difficile de parler de pics estival et hivernal…

Trouver la paix intérieure, c'est facile.

Rigolo, l'interception / l'écoute / la recopie de socket unix avec socat en mitm. :D

Sur mes infrastructures persos, j'essaye de diversifier les implémentations d'un même service. J'ai Apache httpd et nginx, BIND et nsd, etc. Objectifs : résilience et compétence.

Pour mes courriels, ce n'est pas vrai, j'utilise uniquement postfix (MTA), dovecot (IMAP et, sur un seul de mes domaines, MDA + Sieve), saslauthd (authentification SASL), et OpenDKIM (signature et vérification DKIM). Récemment, sur l'un de mes domaines, je suis passé de saslauthd à dovecot pour l'auth SASL.

J'utilisais policyd-spf-perl pour vérifier SPF, mais, en cas d'erreur dans la résolution de noms, ça rejette des expéditeurs légitimes dès la phase EHLO d'une transactions SMTP, et il n'est pas possible de débrayer cela. Il y a longtemps, sur l'un de mes domaines, j'utilisais procmail comme MDA et langage de filtre, mais la syntaxe est reloue et je n'ai pas besoin d'un filtrage poussé, donc je l'ai viré (postfix est MTA et MDA).

Sur l'un de mes domaines, j'ai décidé de remplacer Postfix par OpenSMTPD, sans d'autres motivations que les objectifs sus-mentionnés.

Pour ce faire, il y a le très complet tuto de Solène. Pour la signature DKIM, on peut utiliser dkimsign plutôt que rspamd. Pour la syntaxe des filtres, notamment pour FCrDNS, c'est ici. Comme pour les autres produits OpenBSD, les autres réponses sont dans le manuel.

Sur un système Debian, les paquets postfix et opensmtpd sont mutuellement exclusifs, mais la suppression de postfix ne purge pas sa configuration.

Pour inspiration, voici mon /etc/smtpd.conf :

# Taille max d'un courriel. Par défaut : 35M.
smtp max-message-size 15M

# Emplacement certifs et clé x509, et ré-activation de l'échange de clé DHE
pki "example.com" cert "/chemin/vers/chaîne/certificats.pem"
pki "example.com" key "/chemin/vers/clé/privée.pem"
pki "example.com" dhe auto

# Emplacement des alias
table aliases file:/etc/aliases

# Définition des filtres
filter "dkimsign"            proc-exec "filter-dkimsign -d example.com -s <SELECTEUR> -k /chemin/vers/clé/privée/dkim.pem" user _dkimsign group _dkimsign
filter "check_FCrDNS"        phase connect match !fcrdns disconnect "450 No FCrDNS"
filter "check_sender_isFQDN" phase mail-from match !mail-from regex ".+@.+" disconnect "500 FQDN required"
filter "check_sender_notMe"  phase mail-from match mail-from regex ".+@example.com$" disconnect "550 Wrong domain"

# Écoute
listen on eth0 port 25  tls         pki "example.com" filter { "check_FCrDNS", "check_sender_isFQDN", "check_sender_notMe" }
listen on eth0 port 587 tls-require pki "example.com" auth mask-src filter "dkimsign"
# listen on socket filter "dkimsign"

# actions possibles
action "local" maildir alias <aliases>
# action "local" mda "/usr/lib/dovecot/dovecot-lda -f %{sender} -a %{dest} -d %{user.username}" alias <aliases>
action "smtp" relay

# en entrée
match from any for domain "example.com" action "local"
match from local for local action "local"

# en sortie
match from mail-from spam@example.com auth tartempion for any action "smtp"
#match from local for any action "smtp"

Commentaires :

• Après « pki », il s'agit d'un label en libre choix. Par défaut, l'échange de clés DHE est désactivé, ne reste que ECDHE (variante sur courbes elliptiques de DHE). Si cette désactivation représente l'état de l'art, une configuration TLS trop exigeante fera que le courriel sera transmis en clair ;
  
  
• Dans Debian, le programme filter-dkimsign est dans le paquet logiciel opensmtpd-filter-dkimsign ;
  
  
• FCrDNS = forward-confirmed reverse dns. Nom DNS du SMTP distant = IP (A / AAAA) = nom DNS (PTR). Cohérence sur toute la chaîne. Au début, je le positionnais en phase « mail-from », car, en « connect », j'ai constaté des rejets illégitimes par manque de temps pour la résolution DNS (et que la phase intermédiaire existe en deux exemplaires, « ehlo » ou « helo », donc relou). Mais j'ai constaté cela aussi en phase « mail-from ». Je pense donc que le mieux est de renvoyer un code d'erreur temporaire (4xx). Je suis donc repassé en phase « connect » car, ainsi, ça permet de dégager très rapidement les robots qui ne font que des tentatives d'authentification. Je ne faisais pas cette vérification avec Postfix, il s'agit d'une nouveauté ;
  
  
• Le filtre « check_sender_isFQDN » est un équivalent perso de « reject_non_fqdn_sender » de Postfix : il vérifie que le MAIL-FROM (dans la transaction SMTP, il ne s'agit pas du champ « From » dans l'entête d'un courriel) est un domaine complet. Note : pour vérifier si un domaine émetteur existe réellement, il faut un script externe ;
  
  
• Le filtre « check_sender_notMe » est un équivalent maison de « check_sender_access » de Postfix (j'en parle ici). En résumé : dégager un client SMTP qui se présente avec notre domaine en MAIL-FROM durant la transaction SMTP ;
  
  
• Sur le port 25, on propose STARTTLS, avec la paire certificats+clé dont le label est « example.com », et on applique les filtres précédemment définis aux emails entrants par ici ;
  
  
• Sur le port 587 (submission), on exige STARTTLS et l'authentification (basée sur PAM), on retire l'adresse IP du client de l'entête « Received » (sur Postfix, j'utilisais un « header_check » pour ce faire et retirer aussi le User-Agent de mon logiciel de messagerie), et on appose une signature DKIM ;
  
  
• « listen on socket filter "dkimsig" » permet de signer (DKIM) les courriels émis par les programmes locaux (commande « mail », programme PHP, etc.). Je commente car mes programmes n'envoient pas de courriels à l'extérieur, donc je n'ai pas besoin de cette conf ;
  
  
• Dans les actions possibles, dont je rappelle que « local » et « smtp » sont des labels que j'ai choisis, j'ai défini opensmtpd comme MDA (première ligne), qui utilise la structure de stockage Maildir (mbox est également dispo), et la table d'alias définie plus haut. J'ai également défini, à la deuxième ligne et en commentaire, dovecot comme MDA, avec la gestion du délimiteur « + » (ex. : toto+dgfip@example.com). Je m'en expliquerai infra. Troisième ligne : opensmtpd est un client SMTP qui peut contacter directement l'extérieur ;
  
  
• Les règles d'entrée se comprennent facilement : les courriels pour le domaine « example.com », peu importe leur provenance, seront traités par le composant MDA défini plus haut. Idem pour les courriels émis par les programmes locaux à destination des autres comptes locaux ;
  
  
• La règle de sortie en commentaire permettrait aux programmes locaux (commande « mail », script PHP, etc.) d'envoyer des courriels à l'extérieur. Je n'en ai pas bessoin. La seule règle active dit que les courriels dont l'adresse d'expéditeur, dans la session SMTP (pas dans l'entête d'un email), est « spam@example.conf » et qui ont été remis par l'utilisateur authentifié « tartempion » peuvent être émis vers l'extérieur. Cette sur-déclaration, exhaustive, permet de retrouver le comportement de « smtpd_sender_login_maps » de Postfix : seul l'utilisateur tartempion peut utiliser l'adresse spam@example.com, pas les autres utilisateurs locaux ou authentifiés.

Voyons les différences avec Postfix.

Avec Postfix, je passe beaucoup de temps à définir la configuration TLS. OpenSMTPD se repose sur la libtls (libressl) qui prend en charge uniquement les versions 1.2 et 1.3 (source). De même, par défaut, les suites cryptographiques sont uniquement les suites AEAD de TLS 1.3 et 1.2 (sources : 1, 2, 3). Ça s'applique au serveur et au client SMTP. Depuis sa version 3 (empaquetée dans Debian 12), OpenSSL désactive aussi TLS < 1.2 au niveau du système, donc c'est cohérent, même si ça augmente la probabilité de courriels livrés en clair à cause d'exigences TLS trop élevées…

OpenSMTPD ne prend pas en charge le pipeling, donc pas de vulnérabilité SMTP smuggling à contrer. Idem pour l'absence de prise en charge de la commande VRFY, de l'exigence qu'un client se présente avec la commande EHLO (ou HELO) avant toute autre chose, ou le refus de livrer des comptes systèmes sans maildir : c'est natif.

J'utilise OpenDKIM également pour vérifier la signature des courriels entrants. OpenSMTPD délègue aussi cela (mais, a priori, la syntaxe des échanges n'est pas la même, donc un programme pour Postfix ne fonctionne pas directement avec OpenSMTPD). Soit à rspamd, soit à un programme dédié. Pareil pour la vérification SPF. Au final, je ne regarde pas le résultat de ces validations, donc je décide de ne rien mettre en œuvre.

Avec Postfix, j'utilise « header_checks » et « body_checks » pour filtrer sommairement le spam. Cela me suffit. Il n'y a pas d'équivalent avec opensmtpd car il est conçu pour manipuler uniquement les enveloppes, pas les courriels eux-mêmes. C'est pour cela que j'ai déjà préparé dovecot comme MDA : pour faire rapidement du Sieve en cas de pic de spam.

Les autres restrictions de Postfix sur l'émetteur ou le destinataire sont natives avec OpenSMTPD : « smtpd_reject_unlisted_sender » est englobée dans ma vérification d'une auth SASL ou d'un compte local ; « reject_unknown_sender_domain » ne s'applique que si Postfix n'est pas la destination finale ; Etc.

Commandes utiles :

• Vérifier la conf' : smtpd -n ;
  
  
• Consulter la file d'attente (pour Postfix, c'est ici) : smtpctl show queue ;
  
  
• Tenter de livrer les courriels en attente (idem) : smtpctl schedule all ;
  
  
• Vider la file d'attente (idem) : smtpctl remove all ;
  
  
• Après la création / suppression d'un alias, actualiser la table stockée en mémoire en partir du fichier : smtpctl update table aliases.