Vous avez branché Hermes sur votre boîte de réception : le digest quotidien arrive, il lit, résume et mémorise. Après une mise à jour, plus rien n’arrive — pas même des expéditeurs de votre liste d’autorisation. Le seul indice est une ligne WARNING dans le journal, nommant un réglage que vous n’avez jamais configuré.

Le problème, c’est la question « qui a réellement envoyé ceci ? ». Hermes vérifie l’en-tête Authentication-Results pour établir l’identité de l’expéditeur, et cet en-tête est du texte brut qu’un expéditeur peut écrire lui-même. Quand votre serveur de réception n’appose pas sa propre version, une ligne injectée se retrouve au sommet et Hermes la traitait comme faisant autorité. Le correctif est sans détour : pas d’épinglage, pas de confiance.

Comment la falsification fonctionnait

Authentication-Results est l’en-tête qui atteste que « ce message a passé SPF / DKIM / DMARC ». Normalement, votre serveur de réception l’ajoute après l’arrivée du message — précisément parce que c’est le serveur qui a fait la vérification, son verdict est celui qui vaut la peine d’être lu.

Mais c’est un en-tête normal. Un expéditeur peut inclure sa propre ligne : attacker.self; dmarc=pass header.from=allowed.example. Si vous exploitez un MTA auto-hébergé qui n’appose pas son propre authserv-id (à la manière d’OpenDKIM / OpenDMARC), cette ligne reste au sommet. L’ancien comportement d’Hermes lisait l’en-tête le plus haut sans se soucier de qui prétendait l’avoir écrit, donc :

• l’attaquant falsifie From: pour correspondre à une adresse de votre liste d’autorisation ;
• il ajoute sa propre ligne dmarc=pass ;
• Hermes considère l’expéditeur comme authentifié et livre le message.

Le _verify_sender_authentication réécrit n’accepte que deux issues — il lit l’en-tête Authentication-Results le plus haut et exige que son authserv-id corresponde au vôtre exactement :

if not authserv_id:  # without a pin the topmost header may be one the sender wrote
    return False, _MISSING_AUTHSERV_REASON
if clauses[0].strip().lower() != authserv_id:
    return False, _UNTRUSTED_AUTHSERV_REASON

Deux voisins ont aussi été resserrés : deux résultats dmarc dans un même en-tête produisent désormais ambiguous dmarc result au lieu d’une supposition, et un dmarc=pass doit avoir chaque header.from aligné avec le domaine From: qu’Hermes a analysé.

Ce qui change réellement après la mise à jour

Il s’agit d’un changement de comportement, le rayon d’impact compte donc :

• Qui est concerné : les déploiements avec l’authentification de l’expéditeur activée et aucun épinglage défini. L’auth de l’expéditeur est activée par défaut, y compris dans les configurations à accès ouvert telles que EMAIL_ALLOW_ALL_USERS / GATEWAY_ALLOW_ALL_USERS.
• Ce qui se passe : chaque message nécessitant un From: authentifié est rejeté, expéditeurs de la liste d’autorisation compris, jusqu’à ce que l’opérateur fasse l’une de deux choses — définir EMAIL_AUTHSERV_ID (ou la clé de configuration platforms.email.authserv_id), ou renoncer explicitement à l’authentification de l’expéditeur.
• Ce que vous voyez : chaque compte non épinglé consigne un WARNING à la connexion, indiquant que l’authserv-id n’est pas configuré et qu’Hermes refuse de faire confiance à Authentication-Results, plus les deux échappatoires (définir l’authserv-id, ou régler require_authenticated_sender: false / EMAIL_TRUST_FROM_HEADER=true). L’avertissement se déclenche aussi quand la première connexion d’un compte échoue et que le guetteur de reconnexion le relance plus tard.
• Qui n’est pas concerné : les déploiements épinglés, et ceux qui avaient déjà renoncé. Ils se comportent exactement comme avant.

Trouver la valeur à épingler

Ne la devinez pas. Ouvrez un message que votre serveur a livré, affichez la source brute (« Show original » dans Gmail), repérez l’en-tête Authentication-Results le plus haut et prenez le jeton avant le premier point-virgule.

• Pour Gmail, c’est mx.google.com ;
• si le jeton change d’un message à l’autre, c’est un nom d’hôte propre à chaque relais. La bonne démarche est alors de faire apposer à votre MTA un authserv-id stable (AuthservID d’OpenDKIM, l’équivalent dans OpenDMARC) et d’épingler celui-ci.

Les deux configurations fonctionnent ; la variable d’environnement est plus pratique pour les conteneurs :

# .env ou environnement du conteneur
EMAIL_AUTHSERV_ID=mx.google.com

# config.yaml
platforms:
  email:
    authserv_id: mx.google.com
    # gardez le mode strict par défaut ; ne désactivez que si vous acceptez le risque de falsification
    require_authenticated_sender: true

La valeur est normalisée en minuscules, la casse n’a donc pas d’importance, mais le domaine doit correspondre — ne l’élargissez pas à un domaine parent pour économiser de la frappe.

Si vous avez vraiment besoin que le courrier reparte aujourd’hui

Définir platforms.email.require_authenticated_sender: false (ou EMAIL_TRUST_FROM_HEADER=true) fait qu’Hermes accepte à nouveau les expéditeurs non authentifiés. C’est une rétrogradation délibérée : sur un MTA auto-hébergé, cela signifie que n’importe qui peut falsifier un expéditeur de la liste d’autorisation. La meilleure alternative est un authserv-id stable sur votre MTA — configurez-le une fois et n’y pensez plus.

Pour d’autres correctifs de falsification d’identité de la même famille, voir les trois correctifs d’usurpation d’identité d’expéditeur ; le reste de la configuration de la plateforme email se trouve dans la référence des commandes Hermes.

En bref

• Authentication-Results est un en-tête que l’expéditeur peut écrire ; sur un MTA auto-hébergé sans tampon, il peut remonter au sommet ;
• Hermes exige désormais une correspondance exacte d’authserv-id et rejette le courrier nécessitant un expéditeur authentifié tant que vous n’en avez pas défini un, en consignant un WARNING ;
• copiez le jeton avant le premier point-virgule de l’en-tête Authentication-Results le plus haut (Gmail : mx.google.com) dans EMAIL_AUTHSERV_ID / platforms.email.authserv_id ;
• l’échappatoire est require_authenticated_sender: false ou EMAIL_TRUST_FROM_HEADER=true, et cela signifie accepter le risque de falsification.