Skip to main content
La délivrabilité se joue dans le DNS avant qu’un seul octet de courrier ne circule. Un serveur destinataire interroge votre domaine et lui demande qui est autorisé à envoyer pour lui, ce message est-il intact et authentique, et puis-je vous joindre sur du TLS imposé. Il répond à ces questions uniquement à partir des enregistrements que vous publiez. Cette page est le contrat DNS de l’opérateur : ce qu’il faut publier pour un domaine de courrier, pourquoi chaque enregistrement existe, comment OxiMail le génère et le sert, et comment vérifier le résultat. Deux commandes encadrent tout le flux :
  • oximail setup provisionne le jeu complet d’enregistrements. Avec un jeton Cloudflare, il les écrit directement dans la zone via l’API Cloudflare, en lisant d’abord la zone : un enregistrement n’est créé que là où la zone n’en porte aucun de son genre (publication). Sans jeton, il vous indique de créer les enregistrements à la main.
  • oximail check-dns effectue des résolutions en direct et note le domaine. Il interroge le résolveur validant de la machine elle-même (unbound sur 127.0.0.1, voir le résolveur), qui refuse une zone dont les signatures ne se valident pas et ne garde un « pas d’enregistrement » que cinq minutes au plus : un enregistrement tout juste publié est vu. Il interrogeait auparavant un résolveur public. Le rapport se termine par n/n -- Ready for production ou n/n -- Fix the items above.
Lancez oximail check-dns depuis le serveur après chaque changement DNS. Le DNSSEC est imposé sur les résolutions TXT : une zone au DNSSEC cassé remonte comme une erreur franche plutôt que d’accepter en silence des enregistrements falsifiés.

​
Le jeu d’enregistrements

Pour un domaine de courrier example.com servi par l’hôte mail.example.com à l’IP 203.0.113.10, le jeu complet provisionné par OxiMail est : Les sections ci-dessous expliquent les enregistrements qui portent une vraie politique. Les enregistrements MX, A et SRV sont mécaniques : publiez-les et vérifiez avec check-dns.

​
SPF

OxiMail publie un enregistrement SPF strict, à source unique :
ip4:203.0.113.10 autorise exactement votre hôte de courrier. -all est un échec strict : toute autre IP prétendant envoyer en tant que example.com est rejetée d’emblée. C’est le bon réglage par défaut pour un serveur auto-hébergé unique. Ajustez-le à la main si votre topologie est plus large :
  • Envoi depuis plusieurs IP (un hôte MX de secours, un relais séparé) : ajoutez chaque mécanisme ip4: / ip6:, par exemple v=spf1 ip4:203.0.113.10 ip4:203.0.113.20 -all.
  • Relais via un tiers (un fournisseur transactionnel) : ajoutez son include: publié, par exemple include:_spf.example-relay.com.
  • Expéditeurs en IPv6 : SPF n’autorise que ce qu’il liste. Si votre MX envoie aussi en IPv6, ajoutez le mécanisme ip6: correspondant, sinon le courrier IPv6 échoue strictement au SPF chez le destinataire.
À la réception, SPF est lu comme l’écrit la RFC 7208. Un enregistrement est analysé avec sa grammaire. La limite de dix termes qui interrogent le DNS compte chaque terme une seule fois : un domaine qui en a exactement dix passe. Un domaine qui ne publie aucun enregistrement est none, et non temperror. SPF, DMARC et ARC partagent un budget DNS de 20 secondes par message : au-delà, SPF et DMARC sont temperror et ARC ne donne aucun verdict, jamais un succès ni un échec.
check-dns évalue SPF par la présence directe de l’IP et +all uniquement. Il ne descend pas dans les directives include: ou redirect=. Si vous dépendez d’un include:, vérifiez aussi l’alignement avec un validateur SPF externe.

​
DKIM

DKIM signe chaque message sortant avec une clé privée. Les destinataires récupèrent la clé publique dans le DNS et vérifient la signature. OxiMail signe au moment de la remise, dans le worker sortant (voir la couche SMTP). Générez la clé et relisez l’enregistrement à publier :
Cela écrit la clé privée dans /etc/oximail/dkim/example.com.default.key et imprime l’enregistrement DNS correspondant :
  • Le sélecteur est default. Le nom DNS est toujours <sélecteur>._domainkey.<domaine>, donc une rotation publie un nouveau sélecteur à côté de l’ancien, laisse les deux vérifier pendant la bascule, puis retire l’ancien enregistrement.
  • L’algorithme est RSA par défaut (k=rsa). L’assistant setup complet publie l’enregistrement RSA automatiquement quand il est lancé avec un token Cloudflare.
  • Sursignature. La liste h= de la signature nomme From, Reply-To, To, Cc, Subject, les deux en-têtes List-Unsubscribe et X-OxiMail-Flow une fois de plus, pour qu’un acteur en aval ne puisse pas injecter une seconde copie d’un en-tête sur lequel le lecteur agit sans invalider la signature (RFC 6376 §8.15). Aucune action opérateur : c’est ainsi qu’OxiMail signe.
Côté entrant, dkim=fail dit pourquoi. Le motif de vérification voyage désormais à côté du verdict, jusque dans l’en-tête Authentication-Results et dans le résultat conservé par message. Une analyse après coup peut donc séparer des cas qu’un verdict nu confondait, et qui appellent des actions opposées : Trois lectures ont changé avec le passage aux suites de référence des RFC (les suites openspf, les vecteurs de dkimpy). Une signature c=simple hache chaque champ d’en-tête tel qu’il est écrit : ces signatures se vérifient, les nôtres comprises chez dkimpy. Une clé publique absente est permerror. Et une signature valide dont la balise l= laisse une partie du corps non signée est mise de côté (RFC 6376 §8.2 : le choix appartient au vérificateur). Elle est rapportée dkim=policy, une signature que la politique de ce serveur n’accepte pas (RFC 8601 §2.7.1), avec un motif tel que l=N covers N of the M octets, dans l’Authentication-Results, dans le verdict stocké et dans le rapport agrégé DMARC. Une telle signature ne compte jamais comme un succès ; elle se lisait dkim=none. Dans le résumé de plusieurs signatures, l’ordre est pass, fail, temperror, permerror, policy, none. Le motif retenu est celui de la première signature non passante. Un pass n’en porte aucun, délibérément : une mauvaise signature à côté d’une bonne est normale, les listes de diffusion resignent, et dkim=pass reason=... se lirait comme un défaut là où il n’y en a pas.
Quand vous ajoutez un domaine de courrier après l’installation initiale, générez et publiez son enregistrement DKIM explicitement. Un domaine dont la clé existe mais dont l’enregistrement TXT default._domainkey est absent signera du courrier que les destinataires rejetteront ensuite en dkim=fail (aucune clé trouvée). Lancez oximail check-dns pour chaque domaine afin de confirmer que la vérification DKIM passe.

​
DMARC

DMARC indique aux destinataires quoi faire quand un message échoue à l’alignement SPF et DKIM, et où envoyer les rapports agrégés. Le réglage par défaut d’OxiMail est :
p=quarantine dirige le courrier en échec vers le dossier Indésirables du destinataire. Adaptez la politique à votre étape de déploiement :
  • p=none : surveillance seule. Publiez ceci d’abord si vous n’êtes pas sûr que vos SPF et DKIM sont corrects. Lisez les rapports agrégés rua, puis durcissez.
  • p=quarantine : le défaut d’OxiMail. Le courrier en échec est mis en indésirable, pas refusé.
  • p=reject : le courrier en échec est refusé au moment du SMTP. Côté réception, OxiMail respecte un p=reject de l’expéditeur avec un rejet 550 5.7.26 (voir la couche SMTP).
À la réception, DMARC juge l’auteur que le lecteur voit. L’auteur est lu avec la grammaire de la RFC 5322 §3.4 : l’unique boîte de l’unique champ From:. DMARC prenait le domaine situé après le premier < de la valeur, même à l’intérieur d’un nom affiché entre guillemets ou d’un commentaire. Ainsi From: "x <x@attacker.example>" <ceo@victim.example> passait DMARC sur attacker.example pendant que le client de messagerie affichait ceo@victim.example, sous une politique p=reject. Et une seule ligne d’en-tête hors grammaire, n’importe où dans le message, transformait DMARC en none. Un message sans exactement un auteur (pas de From:, plusieurs champs From:, plusieurs boîtes, un From: ou un bloc d’en-têtes hors grammaire) est DMARC permerror, sans requête DNS, et le domaine d’enveloppe n’est jamais jugé à sa place. Il est refusé avant le 250, sur le chemin direct comme sur celui du MX de secours :
Le motif est un texte fixe pour chaque cas, jamais les octets de l’expéditeur. Les pairs de confiance ([security] trusted_ips, la boucle locale) en sont exemptés. Assurez-vous que la boîte rua existe et est surveillée. C’est là que vous apprenez qu’une source légitime est en échec, avant que les destinataires ne cessent de voir votre courrier. OxiMail lit les rapports d’agrégation qu’il reçoit et émet un événement par rapport, DmarcReport ou DmarcReportWithWarnings, séparés à l’émission sur un prédicat fixe qu’une chaîne d’alerte route sans interpréter un champ : des messages rejetés ou mis en quarantaine, ou des échecs d’alignement que personne n’explique. La policy_evaluated/reason du rapporteur (forwarded, mailing_list, local_policy, …) est conservée et transportée comme override_reasons, si bien que les échecs que le rapporteur a attribués, un redirecteur automatique qui s’annonce lui-même par exemple, restent visibles avec leur motif sur une ligne d’information au lieu de lever l’alarme ; mesuré sur un domaine de production pendant six jours, quatorze des quinze échecs signalés étaient le redirecteur d’un grand fournisseur. Les compteurs sont des messages, jamais des enregistrements, puisqu’un enregistrement peut en agréger des dizaines de milliers. Le miroir, les rapports que cet hôte envoie sur les domaines dont il reçoit (RFC 7489), est [dmarc_reports] enabled : une ligne par message évalué dont l’enregistrement appliqué demande des rapports, groupées par domaine de politique sur des journées UTC closes par un travailleur quotidien.

​
ARC et l’exception DMARC

Un transfert ou une liste de diffusion casse SPF, et souvent DKIM. ARC (RFC 8617) lui permet de témoigner de ce qu’il a reçu : quand DMARC échoue mais qu’une chaîne ARC valide dit que l’origine passait, le message peut être remis. Or n’importe quel domaine peut sceller une chaîne qui se valide : un faussaire d’un domaine en p=reject atteignait la boîte de réception en scellant sa propre chaîne. L’exception ne vaut plus que si le premier sceau de la chaîne (le d= de l’ARC-Seal i=1) est un domaine que vous nommez, une politique locale (RFC 8617 §7.2.1) :
Le premier sceau, pas le plus récent : un transfert honnête qui scelle à nouveau la contrefaçon en i=2 ne rend pas vraie l’affirmation de l’attaquant. Nommez les listes de diffusion et les transferts par lesquels vos utilisateurs reçoivent du courrier (google.com pour Google Groups, par exemple). Une entrée qui n’est pas un nom de domaine empêche le démarrage. Sans sceau listé, le verdict DMARC tient, p=reject compris, et le motif arc_sealer_untrusted dit pourquoi. Tout échec de validation ARC est désormais fail (RFC 8617 §5.2.1) ; none signifie une vérification coupée par le budget DNS. Les sceaux que ce serveur ajoute se vérifient, y compris quand un en-tête signé est répété.

​
MTA-STS et TLS-RPT

MTA-STS (RFC 8461) vous permet d’exiger que les autres serveurs utilisent un TLS validé quand ils vous remettent du courrier, fermant la fenêtre de repli en clair que le simple STARTTLS opportuniste laisse ouverte. Il a trois parties mobiles, et OxiMail sert lui-même la politique :
  1. L’enregistrement TXT _mta-sts.example.com = v=STSv1; id=<AAAAMMJJ> annonce qu’une politique existe. L’id change chaque fois que la politique change.
  2. L’hôte de politique mta-sts.example.com (un CNAME vers votre hôte de courrier) est l’endroit où les expéditeurs récupèrent la politique en HTTPS.
  3. Le serveur sert /.well-known/mta-sts.txt à partir du bloc de configuration [mta_sts] :
  • enforce : les expéditeurs qui respectent MTA-STS refusent de vous remettre du courrier sur du TLS non validé.
  • testing : la politique est publiée mais les échecs sont signalés, pas imposés. Utilisez ce mode pendant la validation, puis passez à enforce.
  • none : retire la politique.
TLS-RPT (RFC 8460) est le compagnon qui vous donne de la visibilité :
Côté envoi, OxiMail respecte les politiques MTA-STS des domaines vers lesquels il remet. Un motif MX de politique tel que *.example.com couvre exactement une étiquette, la plus à gauche (RFC 8461 §4.1) : la correspondance exige une étiquette non vide suivie du suffixe. Elle vérifiait seulement que le MX finissait par le suffixe. Un attaquant qui usurpait le MX du destinataire avec un nom tel que notexample.com, et un certificat valide pour ce nom, recevait donc le courrier qu’une politique enforce devait protéger. Les destinataires envoient des rapports quotidiens des échecs de connexion TLS à l’adresse rua. C’est ainsi que vous détectez une politique mal configurée ou une tentative de repli active. Comme pour DMARC, surveillez cette boîte.

​
DANE (TLSA)

DANE (RFC 7672) est l’alternative à MTA-STS ancrée dans DNSSEC : un enregistrement TLSA sous _25._tcp.mail.example.com épingle votre certificat, de sorte qu’un expéditeur valide le TLS contre le DNS plutôt que contre une liste d’autorités de certification publiques. Il exige une zone signée DNSSEC. Il exige aussi un résolveur validant sur la machine, y compris pour les dénis d’existence. « Pas d’enregistrement TLSA » doit être prouvé (NSEC/NSEC3) au même titre qu’un enregistrement doit être signé : sans cette preuve, « absent » et « retiré en chemin » sont la même réponse, et retirer le TLSA est précisément l’attaque de rétrogradation DANE. Certains stubs de transfert (systemd-resolved avec DNSSEC=no, les relais DNS des routeurs) valident les réponses positives signées mais resservent les dénis sans leur preuve. OxiMail pose donc toutes ses questions DNS à un résolveur à lui, et ne croit une réponse DNSSEC qu’une fois ce résolveur prouvé.

​
Le résolveur de la machine

Depuis ADR-165, le serveur pose toutes ses questions DNS à unbound sur 127.0.0.1:53, par un seul résolveur pour tout le processus ; il ne lit jamais /etc/resolv.conf. L’assistant de premier démarrage installe et configure cet unbound sur Debian ; ailleurs, il affiche la configuration et l’endroit où la placer. Une sonde décide si ses réponses valent quelque chose : le résolveur répond l’identité que l’installation a écrite dans /etc/unbound/unbound.conf.d/oximail.conf (un relais sur la boucle locale, dnsmasq ou un transfert, ne le peut pas), la racine revient validée, une zone non signée non, les zones qui ne se valident pas sont refusées, et les dénis d’existence sont prouvés. La sonde tourne au démarrage, puis toutes les heures, et toutes les cinq minutes tant que le résolveur n’est pas prouvé. Chaque changement d’état est journalisé, et oximail_resolver_trust{state} vaut 1 sur exactement un état parmi reliable, unreliable, mute et unmeasured. Rien de tout cela n’est fatal, et rien ne passe sans contrôle. Tant que le résolveur n’est pas prouvé, aucune réponse DNSSEC n’est crue, et le courrier vers un domaine qui a utilisé DANE dans les 30 derniers jours, qui publie un enregistrement TLSA, ou dont la résolution TLSA échoue attend en file au lieu de partir sans authentification. Il part de lui-même une fois le résolveur de nouveau prouvé. Le reste du serveur sert normalement. Quand cette attente coûte plus que le risque, levez-la pour une durée bornée :
Sans --yes, la commande ne fait qu’un essai à blanc ; elle fonctionne serveur arrêté. oximail resolver check exécute la sonde même du serveur (--json pour les scripts) : code 0 fiable, 1 non mesuré (le réseau a tenu un nom de test hors d’atteinte), 2 non fiable ou muet. Elle ne lit aucune configuration et fonctionne serveur arrêté ; en root, elle lit aussi le canal de contrôle d’unbound, dont les modules doivent inclure validator. Un déploiement peut la lancer avec le nouveau binaire avant la bascule, et refuser une box prouvée non fiable. Un enregistrement tout juste publié est vu en cinq minutes. La configuration que l’installation écrit plafonne à cinq minutes un « pas d’enregistrement » en cache, et désactive le NSEC agressif d’unbound. Actif, un NSEC en cache niait un nom pendant tout le TTL négatif de la zone (1800 secondes chez Cloudflare), au-delà de ce plafond : un enregistrement publié un instant plus tôt restait invisible une demi-heure. Une box installée avant garde son ancien texte : oximail doctor nomme sous resolver_config la première ligne qui diffère, et oximail resolver ensure --apply réécrit le fichier (l’identité conservée), le vérifie et redémarre unbound ; sans --apply, la commande dit seulement ce qui changerait. Après une publication dans une zone Cloudflare, l’assistant et oximail dkim publish vident aussi le cache du résolveur local pour cette zone : la vérification qui suit lit les nouveaux enregistrements. Chaque nom qu’OxiMail demande est absolu. Un nom relatif est réessayé par le résolveur du système sous chaque suffixe de la liste search de /etc/resolv.conf, sur toute erreur, et la dernière tentative l’emporte. Une résolution TLSA qui échouait à la validation revenait ainsi comme l’absence prouvée de _25._tcp.<mx>.<suffixe>, « pas de TLSA » : la rétrogradation même que DANE existe pour empêcher. D’autres programmes de la machine suivent encore cette liste, et divulguent les noms qu’ils demandent aux serveurs du suffixe : oximail doctor avertit donc sous resolver_search quand /etc/resolv.conf porte une ligne search ou domain. Aucune résolution TLSA n’est faite pour un hôte MX dont les enregistrements d’adresse ne sont pas signés (RFC 7672 §2.2.2), et une résolution d’adresse en échec rend cet hôte injoignable, comme une résolution TLSA en échec. oximail doctor rapporte l’ensemble : resolver_trust (échec quand le résolveur est non fiable ou muet, avertissement quand il n’est pas mesuré), dns_negative_proof (échec tant que les dénis reviennent sans leur preuve), resolver_config et resolver_search.

​
TLSA entrant et DANE sortant

OxiMail impose DANE sur le chemin sortant par défaut, et tient vos enregistrements TLSA entrants à jour automatiquement après chaque renouvellement de certificat. En sortie, les résolutions MX et TLSA sont lues avec leurs preuves DNSSEC : une destination signée reçoit DANE, une destination non signée reçoit du TLS opportuniste, et une réponse que le validateur ne peut pas croire (preuve bogus, déni sans preuve, SERVFAIL, délai dépassé) rend ce serveur injoignable pour la tentative, jamais « pas de DANE » : le MX suivant est essayé, puis le message attend en file et sera réessayé (RFC 7672 §2.1.2). Le journal nomme l’hôte et la raison. Comme la valeur épinglée suit la clé servie (une clé neuve à chaque renouvellement avec acme_reuse_key = false, une rotation de clé, un nouveau certificat venu d’un proxy), cela exige un fournisseur DNS configuré :
Quand dane_enabled = true (le défaut), [dns] provider doit être renseigné, sinon le serveur refuse de démarrer (fail-loud, ADR-027). Sans fournisseur, un renouvellement ACME laisserait en silence vos enregistrements TLSA périmés et casserait le courrier entrant pour tout expéditeur qui valide DANE.
Les options de fournisseur :
  • cloudflare : OxiMail écrit lui-même les enregistrements TLSA par l’API Cloudflare. Un domaine de courrier délégué comme sous-domaine est trouvé dans la zone qui le porte : b.example.org est publié dans la zone example.org, la zone la plus précise que voit le jeton l’emportant. L’assistant, oximail dkim publish et DANE y échouaient faute de zone trouvée.
  • rfc2136 : OxiMail les écrit lui-même sur votre propre serveur DNS faisant autorité, par une mise à jour dynamique signée TSIG (RFC 2136, RFC 8945). Voir plus bas.
  • manual : vous mettez à jour les enregistrements TLSA hors bande. Après un renouvellement, le journal dit si les enregistrements publiés correspondent encore.
Avec cloudflare ou rfc2136 et dane_enabled = true, OxiMail publie les enregistrements TLSA après chaque émission ou renouvellement ACME, après une rotation de clé, et quand un certificat [tls] cert_path change sur le disque. Les nouveaux enregistrements sont créés avant que les anciens soient retirés : un expéditeur qui valide ne trouve jamais un nom sans épingle qui corresponde. Avec dane_enabled = false, rien n’écrit les TLSA automatiquement, quoi que dise [dns] ; oximail dane publish publie quand même par le fournisseur configuré quand vous la lancez. oximail doctor saute alors sa ligne dane tant qu’aucun TLSA n’est publié pour les ports épinglés, et continue d’avertir pour un enregistrement resté publié, que plus rien ne re-signe au prochain changement de clé. Le réglage ne touche pas la livraison : le DANE sortant vers un MX de destination fonctionne de la même façon quelle que soit sa valeur.

​
RFC 2136 : votre propre serveur DNS

Pour une zone que vous hébergez vous-même (BIND, Knot, PowerDNS, tout serveur qui accepte les mises à jour signées TSIG), indiquez à OxiMail le primaire de la zone :
Les trois clés sont requises avec ce fournisseur, et celle qui manque est nommée au démarrage. Le fichier de clé contient une ligne au format nsupdate -y, [algorithme:]nom:secret-base64, par exemple hmac-sha256:oximail-update:<base64>. L’algorithme est hmac-sha256 (le défaut s’il est omis), hmac-sha384 ou hmac-sha512. Comme tout sidecar de secret, il est en mode 0600, propriété de l’utilisateur du service, sur une ligne ; un fichier lisible par le groupe ou les autres est refusé. oximail check-config le lit et refuse une clé inutilisable, et un serveur avec DANE actif refuse de démarrer quand il ne peut pas le lire. Un rfc2136_tsig_key écrit en ligne dans le TOML est refusé au démarrage ; oximail config externalize-secrets le déplace dans un sidecar (configuration). Avec BIND, tsig-keygen -a hmac-sha256 oximail-update affiche la clause de clé pour named.conf ; son secret est la partie base64 de la ligne ci-dessus. Sur le primaire, autorisez cette clé à mettre à jour les enregistrements TLSA aux noms qu’OxiMail épingle, et à rien d’autre :
OxiMail parle au primaire en TCP : la machine doit le joindre sur le port 53. Il lit les enregistrements actuels par une requête signée TSIG, puis ajoute et supprime des enregistrements un par un par des mises à jour signées TSIG. Une mise à jour doit revenir signée par la même clé avec le code NOERROR. Une lecture accepte aussi un NXDOMAIN signé, qui dit que rien n’est encore publié à ce nom. Cette lecture était prise pour une erreur et le port sauté : un nom jamais épinglé ne recevait jamais sa première empreinte. Toute autre réponse, non signée ou de refus, est une erreur qui nomme le code, jamais un succès ; une clé que le primaire ne connaît pas est nommée comme telle (NOTAUTH, non signé) au lieu de se lire comme une réponse forgée. L’échange a été vérifié contre un primaire Knot avec les trois algorithmes. Les noms TLSA doivent se trouver dans rfc2136_zone. La zone doit être signée DNSSEC : le primaire doit donc signer ce qu’il reçoit (le dnssec-policy de BIND, par exemple).

​
Quels ports sont épinglés

OxiMail publie un enregistrement 3 1 1 sous _<port>._tcp.<hôte> pour les ports SMTP que la box sert, et seulement ceux-là : 25, 465 et 587, ou le 25 seul sur un MX de secours, qui reçoit le courrier d’autres serveurs mais n’héberge aucun utilisateur qui en soumet. Il n’épingle pas le port HTTPS : aucun navigateur ne valide DANE, et la fédération entre serveurs OxiMail authentifie un pair par la clé épinglée quand les deux opérateurs ont appairé leurs serveurs, pas par le DNS. oximail dane verify, oximail dane publish et oximail dane rotate utilisent tous le même ensemble de ports. Un enregistrement TLSA sur un autre port n’est entretenu par personne : les crochets de renouvellement et de rotation n’y touchent jamais, si bien que le prochain changement de clé le laisse sur l’ancienne, et qu’un client qui valide DANE refuse alors la connexion. oximail dane verify interroge aussi les ports TLS que la box n’épingle pas (443, 993, 995, 143, 110, 4190, plus 465 et 587 sur un MX de secours) et liste ce qu’il trouve sous unmaintained_pins ; oximail doctor les signale sous dane_unmaintained_pins. Supprimez un tel enregistrement chez le fournisseur DNS. C’est ainsi qu’apparaît un _443._tcp laissé par une version antérieure. L’enregistrement et le fichier de certificat peuvent être d’accord alors que les clients rencontrent une autre clé : un écouteur resté sur l’ancienne, un proxy qui a repris le nom, un remplacement de certificat qui n’a pas eu lieu. oximail doctor --reachability lit donc aussi, sous dane_served_spki, la clé que chaque port épinglé sert réellement : il ouvre le port comme le fait un serveur expéditeur (STARTTLS sur 25 et 587, TLS d’emblée sur 465), mène la poignée de main à son terme et compare la clé présentée à celle du fichier de certificat. Une clé différente est un échec. Un port épinglé où rien n’écoute est un avertissement, puisque l’épingle n’y protège rien. Le serveur fait la même lecture toutes les heures et publie oximail_dane_served_spki_state{host, port, state} (match, differs, not_served, probe_error), pour qu’une alerte la surveille entre deux passages de doctor. Voir TLS et ACME pour l’émission et le renouvellement des certificats.

​
DNS inverse (PTR) et délivrabilité

Le DNS inverse est publié par celui qui contrôle le bloc d’IP (votre hébergeur : Hetzner, OVH, AWS…), pas dans la zone de votre domaine. C’est l’un des signaux de réputation les plus forts dont dispose un destinataire.
  • Réglez le PTR de 203.0.113.10 sur mail.example.com, le même nom que votre serveur utilise dans son HELO/EHLO SMTP. Beaucoup de gros destinataires rejettent ou pénalisent lourdement une divergence (absence de FCrDNS).
  • check-dns et doctor valident la vérification PTR quand l’enregistrement nomme exactement le nom d’hôte du serveur ([server] hostname, ou check-dns --hostname) ; confirmez aussi que l’enregistrement A direct pointe en retour vers la même IP. Le contrôle le comparait à un nom construit en mail.<domaine>, faux pour tout autre nom d’hôte.
  • Une IP neuve n’a aucune réputation d’envoi. Faites une montée en charge progressive et gardez un volume régulier. Un pic soudain depuis une IP froide ressemble à un hôte compromis.

​
Autodécouverte

Les clients de messagerie trouvent vos points d’accès à partir des enregistrements SRV et des CNAME autoconfig / autodiscover du tableau ci-dessus. Le oximail setup complet publie aussi un enregistrement CAA restreignant l’émission de certificats à Let’s Encrypt, ce qui durcit le domaine et correspond à la configuration ACME d’OxiMail. Aucun de ces enregistrements ne porte de politique ajustable : publiez-les et laissez check-dns confirmer.

​
Publier avec oximail setup dns

oximail setup dns relance l’étape DNS de l’assistant sur une box installée. Il lit d’abord la zone et ne crée un enregistrement que là où la zone n’en porte aucun de son genre : un second passage sur une zone configurée n’ajoute rien. Il envoyait toute sa liste à chaque passage, en comptant sur Cloudflare pour refuser un doublon identique. Or l’enregistrement MTA-STS porte la date du jour comme id : un nouveau passage ajoutait un second TXT v=STSv1 à côté du premier, ce qui laisse le domaine sans aucune politique MTA-STS (RFC 8461 §3.1). Un enregistrement TLS-RPT avec un autre rua était doublé de la même façon (RFC 8460 §3). Un TXT est comparé au sein de son genre (v=STSv1, v=TLSRPTv1, un path= DAV) ; un enregistrement MTA-STS est conservé quel que soit son id, puisque changer l’id revient à qui change la politique. Un enregistrement qui diffère de celui qu’OxiMail écrirait est montré et conservé, jamais doublé. Des enregistrements MX qui nomment un autre serveur, et que vous avez gardés, restent les seuls MX du domaine : celui de ce serveur ne s’y ajoute pas. L’étape se termine en nommant les vérifications encore en échec. Un essai à blanc de l’assistant (oximail setup --dry-run) lit la zone sans écrire et liste chaque enregistrement : à créer, déjà là, différent et conservé. L’étape fonctionne sans terminal : un script, un agent ou ssh sans tty peut republier les enregistrements d’une box. Des options répondent à chaque question qu’elle peut poser :
  • --replace-mx, --replace-spf, --replace-dmarc remplacent un enregistrement existant sans demander. Un enregistrement SPF est fusionné quand c’est possible : vos propres mécanismes sont gardés.
  • --public-ipv4 auto (la valeur par défaut) mesure si l’IPv4 publique est celle de cette machine ou prouvée redirigée vers elle, et demande quand rien ne le prouve ; forwarded dit que le routeur redirige ici les ports de courrier ; none ne publie que l’IPv6 (aucun enregistrement A, aucun ip4: dans SPF).
Sans terminal, une question de remplacement à laquelle aucune option n’a répondu garde l’enregistrement existant et est nommée à la fin (code 1), et une IPv4 publique que rien n’a tranchée arrête le passage avant toute publication, en nommant l’option (code 2). Le code 0 signifie qu’il ne reste rien à faire.

​
Vérifier avec oximail check-dns

--domain est le domaine de courrier, --hostname le nom d’hôte du serveur lui-même : la cible que ses enregistrements MX et SRV doivent nommer, et le nom que son PTR doit porter. --hostname vaut par défaut [server] hostname du fichier de configuration ; le nom d’hôte était construit en mail.<domaine>. Sur un serveur complet, le rapport exécute quinze vérifications en direct : MX, DNS inverse (PTR), SPF, DKIM, DMARC, TLS-RPT, MTA-STS (qui passe quand aucun enregistrement n’est publié, cette posture étant facultative), et les enregistrements qui configurent les clients de messagerie (les SRV _submission, _submissions, _imaps, _caldavs, _carddavs et _jmap, et le TXT path des deux enregistrements DAV). Sur un MX de secours, le contrôle MX exige que le MX du domaine nomme le secours, et SPF, DKIM et les enregistrements clients ne sont pas demandés : ils appartiennent au principal. Il imprime une ligne réussite/échec pour chacune, et --json donne le même rapport à un script (hostname compris ; code 0 si tout passe, 1 s’il reste un enregistrement à corriger) :
Le fichier de politique MTA-STS et les enregistrements TLSA DANE sont imposés par le serveur au moment de l’envoi et servis depuis l’hôte de politique, plutôt que re-vérifiés ici. Validez-les avec un vérificateur MTA-STS / DANE externe après publication. oximail doctor exécute les mêmes vérifications sous dns, pour chaque domaine de courrier que sert la box, face au nom d’hôte du serveur lui-même ; l’avertissement nomme les vérifications en échec. Il vérifiait le nom d’hôte comme s’il était le domaine de courrier, et avertissait sur chaque box saine. Le nom d’hôte lui-même, que l’installation enregistre comme domaine de l’organisation, est listé comme non vérifié tant qu’aucun compte ni alias n’existe sous lui ; tout autre domaine est vérifié, même avant son premier compte, puisque c’est à ce moment que son DNS se prépare. Échecs courants :
  • Divergence PTR : corrigez l’enregistrement inverse chez votre hébergeur, pas dans votre zone.
  • DKIM « no record » : vous avez généré la clé mais pas publié l’enregistrement TXT. Voir la section DKIM ci-dessus.
  • SPF « does not include IP » : votre IP d’envoi n’est pas listée. Ajoutez le mécanisme ip4: / ip6:.
  • « Lookup failed » : un délai de propagation (attendez et relancez) ou une zone au DNSSEC cassé (la résolution échoue franchement plutôt que de faire confiance à une réponse non validée).

​
Courrier signé et chiffré

Deux mécanismes au niveau du message côtoient ceux du DNS : le serveur vérifie les signatures S/MIME du courrier qu’il reçoit, et il cherche et publie des clés OpenPGP pour le compte de ses utilisateurs. Aucun des deux ne demande d’enregistrement DNS de votre part.

​
Vérification des signatures reçues

Chaque message signé que reçoit une boîte obtient le verdict RFC 9219 que lisent les clients (les messages signés) : le statut maintenant, le statut à la réception, les raisons d’un échec, et qui a signé. L’ingestion ne lit que le Content-Type de la racine et marque un message signé comme dû, avant le 250, sans aucun analyseur CMS dans la session SMTP ; un travailleur vérifie après la livraison et réévalue chaque verdict quand il peut changer (expiration du certificat, prochaine mise à jour d’une liste de révocation, réessai). Le verdict est un fait daté : il ne change jamais l’acceptation, le classement ni le score anti-spam.
  • Le magasin de confiance est embarqué dans le binaire : les racines « courrier » du programme Mozilla plus les intermédiaires publics déclarés au CCADB, car un message signé ne porte souvent que son certificat feuille et le serveur ne va jamais chercher un intermédiaire manquant à une adresse que donne le certificat (AIA). Chaque fichier remplace son seul jeu : trust_roots seul (la racine d’une autorité interne, par exemple) garde les intermédiaires embarqués, trust_intermediates seul garde les racines embarquées. Un fichier de l’opérateur ne porte pas de date : doctor smime_trust le dit, et avertit quand le magasin ne contient aucun intermédiaire. Un fichier nommé qui ne se charge pas est fatal au démarrage, jamais remplacé en silence. Quand le magasin de confiance change, les messages qui avaient échoué à la réception sous le précédent sont vérifiés à nouveau.
  • La révocation se contrôle par CRL, jamais par OCSP. Les listes ne sont récupérées que pour les points de distribution d’un chemin de certificats déjà validé, en http ou https par la porte de sortie unique du serveur, et gardées en cache jusqu’à leur nextUpdate : c’est le seul trafic sortant de la fonction. OCSP dirait à l’autorité qui lit quoi, et quand ; l’AIA laisserait le certificat de l’expéditeur choisir où le serveur se connecte. Par organisation, la clé de surcharge smime.revocation (un booléen) coupe le contrôle pour cette seule organisation ; coupé, une signature valide est signed/verified et son signataire dit revocationChecked: false.
  • oximail doctor rend compte du magasin sous smime_trust : le nombre de racines et d’intermédiaires, la source de chaque jeu, la date du paquet embarqué et l’interrupteur de révocation ; warn quand le paquet embarqué a plus d’un an ou que le magasin ne contient aucun intermédiaire, fail quand un fichier nommé ne se charge pas ou que le magasin ne porte aucune ancre, skipped avec verify = false. Sur un MX de secours ou un smarthost, qui ne stockent aucune boîte, ni le vérificateur S/MIME ni le résolveur de logos de marque ne tournent : smime_trust et bimi_trust disent tous deux skipped, et pourquoi, au lieu d’un ok sur une fonction que la machine n’a pas.
  • Métriques : oximail_smime_verdict_total{status}, oximail_smime_crl_total{outcome} et oximail_smime_worker_failed_total{reason} (les échecs du côté du serveur, qui ne ressemblent jamais à un échec de l’expéditeur). Les journaux portent l’identifiant du message, le statut et un code de raison, jamais une adresse ni le sujet d’un certificat.
Le courrier signé stocké avant la mise à jour qui a introduit la vérification ne porte aucun verdict, et le travailleur ne prend que les messages que l’ingestion a marqués. À lancer une fois, après la mise à jour :
Le serveur en marche les vérifie ensuite à son rythme. oximail smime verify revérifie depuis les octets stockés, avec le même magasin de confiance, le même cache de CRL et les mêmes écritures que le travailleur : tous les comptes de la machine, ou --account <adresse> ; essai à blanc par défaut, --apply pour vérifier et écrire. Un verdict déjà vérifié à la réception le reste. Les deux verbes prennent --json.

​
La recherche de clés OpenPGP

Les clients cherchent la clé OpenPGP d’un destinataire et publient celle de leur utilisateur par le serveur (RecipientKey/lookup, PgpKey/publish, voir les clés OpenPGP), si bien qu’un serveur de clés n’apprend ni l’adresse IP de l’utilisateur ni rien que le serveur ne relayait déjà. Une recherche interroge d’abord le Web Key Directory du domaine du destinataire (openpgpkey.<domaine>, puis le domaine lui-même), puis le serveur de clés configuré.
Un geste coupé répond forbidden et la session l’annonce fermé, si bien que les clients se taisent au lieu d’échouer à chaque destinataire. Le serveur de clés doit être une URL https, sinon le serveur refuse de démarrer. Chaque requête passe par la porte de sortie unique : https seulement, destinations privées refusées à la résolution, délai de 8 secondes, corps plafonnés à 512 Kio, aucune requête WKD pour un domaine qui est une IP littérale. Un résultat est gardé en cache dix minutes par adresse, jamais quand la source n’a pas pu être jointe.

​
Standards

  • RFC 7208 : Sender Policy Framework (SPF).
  • RFC 6376 : DomainKeys Identified Mail (DKIM).
  • RFC 7489 : Domain-based Message Authentication, Reporting, and Conformance (DMARC).
  • RFC 8461 : SMTP MTA Strict Transport Security (MTA-STS).
  • RFC 8460 : SMTP TLS Reporting (TLS-RPT).
  • RFC 7672 : SMTP Security via Opportunistic DANE TLS.
  • RFC 8550 : S/MIME 4.0 Certificate Handling.
  • RFC 9219 : S/MIME Signature Verification Extension to JMAP.
Pour savoir comment ces enregistrements sont consommés et imposés sur le fil, voir la couche SMTP. Pour l’émission des certificats, voir TLS et ACME. Pour le pipeline anti-spam que l’authentification alimente, voir anti-spam.