Skip to main content
Un serveur de messagerie fraîchement installé émet depuis une IP froide. Les grands opérateurs limitent ou classent en indésirable le courrier venu d’une IP sans historique, et la plupart des hébergeurs et fournisseurs d’accès bloquent entièrement le port 25 sortant : un nouveau déploiement ne peut donc souvent pas livrer du tout le premier jour. La réponse est celle que Postfix propose depuis vingt-cinq ans : continuer à recevoir et stocker son propre courrier, mais router le sortant via un relais (un smarthost) dont l’IP est déjà chaude. OxiMail distingue deux rôles, qu’un même serveur peut tenir :
  • La leaf relaie son sortant à travers un smarthost. Elle reste un serveur Primary normal : seule sa façon d’émettre change.
  • Le smarthost accepte le courrier relayé par les leaves. Accepter le relais est à la portée de tout Primary dès que des comptes relais existent ; un hub dédié tourne en [mode] role = "smarthost", un rôle à part entière : la soumission reste ouverte, les surfaces boîtes aux lettres et l’autoconfiguration des clients sont fermées, et son courrier sortant part par la file de remise ordinaire.
Le relais est entièrement optionnel. Une instance qui émet en direct n’est concernée par rien de cette page : aucune configuration, aucun changement de comportement.

​
Partie 1 : émettre via un relais (la leaf)

​
Choisir le mode à l’installation

oximail setup demande, après la topologie réseau, votre mode d’envoi sortant. Il sonde le port 25 sortant et recommande le relais lorsque la livraison directe est impossible. Le choix est neutre : le relais peut être un service smarthost géré, un ESP (Amazon SES, SMTP2GO…) ou un smarthost interne d’entreprise ; OxiMail demande ses paramètres de connexion de façon générique et ne pousse jamais un service particulier. Vous configurez le relais de deux manières :
  • Saisir les paramètres manuellement : hôte du relais, port, identifiant et mot de passe SMTP AUTH, et le terme SPF à publier. Fonctionne pour n’importe quel relais.
  • Utiliser un jeton d’enrôlement : pour un smarthost géré qui distribue des jetons d’onboarding. Vous collez l’URL du smarthost et un jeton à usage unique ; l’assistant récupère les identifiants automatiquement. Voir la Partie 2.

​
Ce qui est écrit

Un relais est une route [[smtp.transport_maps]] attrape-tout. Le mot de passe AUTH est écrit dans un fichier annexe (mode 0600), jamais en clair dans le TOML :
La livraison vers le relais est TLS obligatoire par construction : une route authentifiée n’a aucun repli en clair, le certificat du relais est vérifié via WebPKI, et les identifiants ne sont jamais transmis sur une connexion non chiffrée.
L’assistant refuse d’activer une route de relais tant que vos vérifications SPF et DKIM ne passent pas. Un relais dont la déclaration SPF n’est pas publiée émettra un courrier que les destinataires classeront en spam : le verrou existe pour empêcher précisément cet échec silencieux. Publiez d’abord les enregistrements DNS ci-dessous, ou passez --force pendant la propagation DNS.

​
Les enregistrements DNS à publier

Deux enregistrements sur chaque domaine émetteur : C’est le modèle où la leaf signe. Si le client ne sait pas signer (une application qui ne fait que soumettre du courrier), le relais peut signer à sa place : voir les clés de signature déléguées. Un smarthost géré demande en plus de publier une preuve de domaine relais, _oximail-relay.votredomaine TXT "<jeton>", qui prouve que vous contrôlez le domaine avant que le smarthost n’émette du courrier pour lui. L’onboarding fournit le jeton.

​
Passer en direct plus tard

Le relais est une configuration permanente prise en charge. Pour basculer vers l’envoi direct une fois votre propre IP chaude, vérifiez d’abord l’état de préparation :
Il vérifie que le port 25 sortant est joignable, que votre DNS inverse est confirmé à l’aller (le PTR se résout bien vers l’IP) et que l’IP n’est sur aucune liste noire DNSBL publique. Une sortie 0 signifie « prêt » : retirez la route [[smtp.transport_maps]] attrape-tout et émettez en direct. La bascule est réversible.

​
Modifier la route plus tard

Les routes sont lues au démarrage : le TOML est la base de la configuration, et aucune route n’est rechargée pendant que le service tourne. Tout changement d’une route [[smtp.transport_maps]] (hôte, port, identifiants, exemption) se fait par oximail check-config sur le fichier modifié, puis un redémarrage du service. La file garde votre courrier pendant ce temps ; rien n’est perdu.
  • Changer le mot de passe du relais sans coupure. Un smarthost sous OxiMail accepte plusieurs secrets pour un même flux d’envoi : demandez un second mot de passe à son opérateur avant de changer le vôtre, écrivez-le dans le fichier annexe auth_password_file, oximail check-config, redémarrez, et seulement ensuite laissez l’opérateur révoquer l’ancien. Il n’y a aucun moment où la leaf ne peut pas émettre.
  • Un smarthost avec une autorité de certification privée. Une route authentifiée vérifie le certificat du relais contre les racines WebPKI publiques et rien d’autre : pas de ca_file, pas d’épinglage. Un smarthost interne doit donc présenter un certificat publiquement valide pour son nom relay_host (celui qu’OxiMail obtient par ACME pour son propre nom d’hôte convient). Un certificat auto-signé ou d’autorité privée n’est accepté que sur une route non authentifiée, qui ne porte aucun identifiant et peut retomber en clair : pas un profil pour votre courrier sortant.
  • Un destinataire à la fois, ou vos propres serveurs. Une route avec action = "direct" est une exemption : ses domaines sont remis par MX même quand une route attrape-tout plus bas nomme le relais. C’est ainsi qu’on retire du relais un grand fournisseur à la fois, une fois votre adresse chaude chez lui, ou qu’on garde hors du relais le courrier entre les serveurs de votre organisation.
La première route qui correspond l’emporte, comme pour toute route. Une route directe ne nomme aucun relais : relay_host, les identifiants, fallback_hosts, implicit_tls, bind_addr et spf_mechanism y sont refusés par check-config.

​
Partie 2 : exploiter un smarthost

Un smarthost accepte le relais authentifié des instances leaf. Sur un Primary, l’activer revient à créer les comptes relais autorisés à relayer. Pour un hub dédié, l’assistant de setup propose une entrée Smarthost relay (dedicated hub) (premier démarrage) : IP d’egress collectées, enregistrement SPF du hub publié, et [mode] role = "smarthost" écrit. Le rôle décide : il ferme les surfaces boîtes aux lettres et l’autoconfiguration des clients en gardant la soumission ouverte, et chaque démarrage avertit quand [legacy] enabled = true rouvre IMAP/CalDAV/CardDAV ou quand [metrics] dnsbl_self_ips est vide (la réputation de sortie est le produit d’une telle boîte). L’ancienne déclaration [mode] profile = "smarthost" a été retirée et refuse désormais le démarrage, en nommant le rôle à poser à la place. Un serveur combiné boîtes + hub reste en role = "primary".

​
Comptes relais

Un compte relais est un compte de rôle service. Contrairement à un utilisateur de boîte, il ne détient aucun courrier ; il existe pour authentifier une session de relais SMTP. Créez-en un et marquez-le comme principal de service :

​
Domaines déclarés et prouvés

Un compte relais ne peut émettre que depuis des domaines prouvés. C’est là toute la frontière de sécurité : sans cela, un client pourrait émettre depuis votre IP partagée en usurpant le domaine d’un autre. La preuve appartient au domaine du tenant, pas au compte. Enregistrez d’abord le domaine sur le tenant (oximail tenant add-domain --kind send : un domaine n’a qu’un seul tenant, et une preuve ne s’empare jamais d’un domaine), puis déclarez-le. Tous les comptes relais de ce tenant utilisent alors les domaines prouvés du tenant.
Le client publie cet enregistrement TXT ; vous le vérifiez ensuite :
Un worker en arrière-plan re-vérifie chaque domaine déclaré deux minutes après le démarrage du serveur, puis toutes les six heures, et le suspend en mode fail-closed si la preuve disparaît. Une défaillance DNS transitoire ne suspend jamais : seule une réponse définitive « enregistrement inexistant » le fait, si bien qu’un incident de résolveur ne peut pas mettre un client hors ligne. Mais une preuve qui n’a pas été confirmée depuis 72 heures cesse aussi d’autoriser : des serveurs de noms qui ne répondent plus sont le prélude habituel d’un domaine expiré puis réenregistré. Un domaine suspendu ou périmé est un état réversible : son courrier est donc différé 451 4.7.1 en fin de DATA et la file du client retente pendant que la preuve revient ; un domaine jamais déclaré ou jamais vérifié est refusé 550 5.7.1. oximail account relay remove-domain --email … --domain … --yes retire un domaine : les comptes relais du tenant perdent aussitôt le droit d’émettre pour lui. account relay list affiche l’état périmé comme stale (--json ajoute last_verified_ok_at et proof_stale), et oximail doctor contrôle chaque preuve sous sender_domain_proofs : un échec nomme les domaines suspendus ou périmés, un avertissement ceux qui ont manqué deux re-vérifications, chacun avec la commande verify à lancer.
Un compte sans domaine vérifié ne relaie rien : l’ingress est deny-by-default. L’expéditeur nul (<>) est autorisé pour que les avis de non-remise puissent transiter.

​
Enrôlement à usage unique

Plutôt que de remettre au client des identifiants bruts, générez un jeton à usage unique. L’assistant du client le consomme et reçoit ses identifiants automatiquement.
Le jeton n’est affiché qu’une fois (seule son empreinte est stockée). Le client le consomme sur POST /relay/enrol : l’endpoint valide et consomme le jeton, provisionne le compte service et renvoie les identifiants une seule fois. Un jeton fuité se révoque avec oximail account relay revoke-tokens.

​
Quotas de destinataires et montée en charge

Sur une IP d’egress partagée, l’unité déterminante pour la réputation est le destinataire, pas le message. Chaque compte relais dispose d’un compteur journalier durable de destinataires assorti d’une rampe de montée en charge : un nouveau compte démarre à 200 destinataires/jour et double chaque semaine jusqu’au plafond [rate_limit] relay_max_rcpt_per_day (5000 par défaut). Au-delà du plafond, une soumission reçoit un 452 4.7.1 transitoire (une limite de politique, comme les plafonds de tenant et de compte) et la file de l’émetteur retente, jamais un rejet définitif.

​
Le terme SPF à publier

Publiez un enregistrement TXT spf.votre-smarthost.example listant votre ou vos IP d’egress, et remettez aux clients include:spf.votre-smarthost.example. Cette indirection vous permet de renuméroter les IP d’egress sans que chaque client édite sa zone. Le déroulé hub dédié de l’assistant publie cet enregistrement pour vous (via Cloudflare si un jeton est fourni, imprimé pour publication manuelle sinon). L’enregistrement appartient au hub, et l’assistant lit d’abord le nom : un enregistrement identique est laissé, un enregistrement v=spf1 différent est remplacé, et un second n’est jamais ajouté, puisque deux enregistrements SPF à un même nom sont un permerror pour chaque domaine qui l’inclut (RFC 7208 §4.5). Les autres enregistrements TXT du nom sont laissés en place.

​
Rétention : le relais n’est pas une archive

Le courrier relayé par un compte service est éphémère, et depuis ADR-149 la règle derrière est que l’emplacement d’un octet est une propriété de son possesseur : un message de passage appartient à sa ligne de file, il vit et meurt avec elle. Son corps n’entre jamais dans le magasin de blobs. C’est un fichier du spool du relais, {relay_spool_path}/{tenant}/_relay/{queue_id}, un fichier par ligne de file nommé par l’identifiant de la ligne, sans registre, sans dédup et sans compteur ; la ligne est sa seule référence, et le travailleur sortant son seul lecteur (JMAP et le lecteur de blobs ne voient pas le spool du tout). Au 250 du destinataire, ou à l’abandon ou à l’expiration, la ligne est supprimée et le fichier délié dans la même écriture terminale sous le jeton de réclamation ; un échec de suppression est un incident de volume compté dans relay_spool_unlink_failed, jamais une erreur par message.
  • La garde est là où l’octet s’écrit. oximail relay-spool init crée la racine (0700) sur le volume monté et est le seul endroit qui la crée. Une soumission est refusée 452 4.3.1 (transitoire, jamais 5xx) quand le chemin est absent de la configuration, manquant, sur le même système de fichiers que les blobs (st_dev), ancêtre ou descendant de blob_path, pas en 0700 pour l’utilisateur du service, ou au-delà du filigrane du tenant (par tenant, pour qu’un client ne puisse pas remplir le spool et faire refuser tout le monde). check-config refuse les mêmes cas avant l’arrêt du service, si bien que le point de montage précède le remplacement du binaire ; un MX de secours sans spool y est refusé aussi.
  • doctor relay_spool mesure la séparation : une ligne sans fichier, un spool injoignable ou en lecture seule, ou le même st_dev que les blobs est un échec ; des orphelins au-delà du plancher d’âge, un échec de suppression, une occupation proche du filigrane ou de mauvais droits un avertissement ; un spool non vide n’est jamais un avertissement. oximail relay-spool gc collecte les fichiers que plus aucune ligne ne possède (simulation par défaut, --apply supprime après relecture de chaque ligne, se met en retrait tant qu’un marqueur de sauvegarde est présent). relay-spool reabsorb retire le spool en ramenant chaque corps dans le magasin de blobs, serveur arrêté, sans toucher au schéma.
  • Le rapport d’échec ne porte rien du message, sauf son identifiant. Le rapport de non-remise d’un message relayé n’en contient aucune partie (RET=FULL n’est pas honoré, et le 250 de fin de DATA le dit) sauf le Message-ID d’origine : sa troisième partie est une section text/rfc822-headers qui porte ce seul en-tête, la clé par laquelle un traitement de rebonds comme MailWizz attribue le rapport, et rien d’autre du message (un identifiant qui ne ferait pas une ligne d’en-tête propre ne donne pas de troisième partie), sa propre ligne de file est éphémère, sa livraison locale est refusée, et aucun avis de retard n’est généré pour un parent relais ; il ouvre une seconde échéance, dix jours cumulés. Chaque voie d’abandon finit dans la même purge clôturée.
  • Le 250 est durable, fichier compris. Quand une porte SMTP figure dans [storage] durable_doors (les trois y sont par défaut), le fichier du spool et son répertoire sont synchronisés avant le 250, comme l’est le journal de la base : la barrière couvre la ligne, pas le fichier que la ligne désigne (courrier et SMTP).
  • Le contrat ne promet que ce que le serveur mesure. Le contenu réside sur un volume dédié exclu des sauvegardes (oximail backup n’inclut ni le spool ni les lignes du spool, sans drapeau pour les inclure) ; la référence quitte la base vive au 250 ; les journaux de livraison, email trace et queue list ne portent que l’identifiant de file et rédigent l’enveloppe d’une ligne éphémère ([ephemeral-redacted]) ; le service ne peut pas chercher le spool par adresse. Ce qu’il ne promet pas, nommé : la ligne de file vit dans data.db sur le système de fichiers racine, qu’un instantané de l’hyperviseur peut emporter. Les compteurs d’usage par jour (relay_account_usage) vivent douze mois et le journal des purges vingt-quatre, avec une jauge de fraîcheur. Le sortant non relayé n’est pas affecté : il conserve son enregistrement de livraison.

​
Transfert à l’identique et médiation des extensions

Deux garanties au niveau du fil encadrent ce qu’un saut de relais peut faire, ou non, à un message :
  • Le courrier d’un compte relais n’est jamais réécrit, ni re-signé. Ce qu’un compte role = "service" soumet suit le chemin de transit : le message est transféré octet pour octet, avec pour seul ajout la ligne Received: du saut, placée au-dessus, y compris quand le smarthost héberge lui-même le domaine du From:. Aucune DKIM-Signature du smarthost n’est ajoutée, aucune cosignature non plus : la signature du client reste la seule et demeure vérifiable de bout en bout (preuve d’intégrité : toute modification en transit est détectable). Cette promesse vaut pour ce chemin seulement : le courrier que ce serveur origine (celui d’une personne, ou celui d’une application via un compte ordinaire) est complété, signé et mis en file comme le dit la section suivante.
  • Les exigences ESMTP sont médiées, pas comblées en silence. Chaque saut sortant (feuille vers relais, relais vers destination) dérive ce dont le message a besoin de son contenu (une adresse ou un en-tête non ASCII exige SMTPUTF8, un octet à bit haut dans le corps exige 8BITMIME, la taille est déclarée quand le pair accepte SIZE=) et le confronte aux capacités annoncées de la destination. Un écart impossible à combler produit un rejet permanent (550 5.6.7 / 554 5.6.3 / 552 5.3.4) plutôt qu’un message remis mal encodé, avec une exception sur le chemin d’origine : vers une destination qui n’annonce ni 8BITMIME ni SMTPUTF8, un corps 8 bits est ré-encodé (quoted-printable pour le texte, base64 sinon, RFC 6152) pour que le courrier soit livré plutôt que perdu, comme le fait tout MTA en service ; mesuré sur une instance, chaque notification accentuée vers le MX d’un outil de support qui n’annonçait que STARTTLS était refusée par notre propre médiation puis perdue sans rebond. Le chemin de relais reste verbatim (la feuille a signé ces octets), un en-tête internationalisé reste un besoin SMTPUTF8 refusé 5.6.7, et un corps que l’analyseur ne sait pas ré-encoder rebondit toujours 5.6.3. Pour la même raison, l’EHLO n’annonce aucune promesse qu’il ne peut pas tenir vers l’aval. BINARYMIME n’est pas annoncé et BODY=BINARYMIME est rejeté 555 5.5.4. DSN (RFC 3461) est annoncé sur un primaire, où la ligne de file porte RET/ENVID et le NOTIFY/ORCPT de chaque destinataire et ne les réémet au saut suivant que si ce pair annonce DSN ; un MX de secours ne l’annonce pas, puisque son chemin de transfert ne les porte pas. Un paramètre DSN mal formé est refusé à la commande, 501 5.5.4, y compris un ENVID ou un ORCPT qui se décode en caractère de contrôle ou non ASCII et un ORCPT de plus de 500 caractères (RFC 3461 §4) : une telle valeur était auparavant acceptée puis ne produisait silencieusement aucun rapport.

​
Qui signe quoi

Le travailleur sortant décide à chaque tentative de livraison, selon le courrier dont il s’agit : La clé de l’opérateur l’emporte sur une clé déléguée. d= est toujours le domaine exact du From: (son A-label pour un domaine internationalisé), jamais un domaine parent. En plus, un message qui part par un pool de sortie qui nomme un cosign_domain reçoit une cosignature : une seconde DKIM-Signature au-dessus de la première, d= le domaine de cosignature, faite avec la clé [[smtp.dkim_keys]] de ce domaine, avec t= l’heure de signature et x= 72 heures plus tard. Les raisons sont celles des récepteurs : certaines boucles de retour attachent les plaintes au domaine signataire, donc un courrier signé seulement au nom de son client sortirait du relais sans aucun signal de réputation qui lui soit propre ; et l’expiration fait qu’un message capturé puis rejoué plus tard ne peut pas emprunter la réputation du relais au-delà de trois jours (un récepteur peut tolérer un peu de marge après x= : lisez-le comme un plafond, pas comme une garantie). La signature du client ne porte aucune expiration. Le courrier propre d’un pool (son From: sous le domaine de cosignature) porte une seule signature, pas deux. Le courrier d’un compte relais n’est jamais cosigné. Toute signature que le serveur écrit, celle du domaine du client comme la cosignature, couvre les mêmes en-têtes : From, Reply-To, To, Cc, Subject, Date, Message-ID, In-Reply-To, References, MIME-Version, Content-Type, les en-têtes de liste (List-Id, List-Help, List-Subscribe, List-Post, List-Owner, List-Archive) et List-Unsubscribe, List-Unsubscribe-Post, Feedback-ID et X-OxiMail-Flow. From, Reply-To, To, Cc, Subject, les deux en-têtes de désabonnement et X-OxiMail-Flow sont sur-signés : nommés une fois de plus qu’ils n’apparaissent, pour que personne ne puisse ajouter une seconde copie après coup sans casser la signature. Jamais l=. Un message que le serveur signe part avec des fins de ligne CRLF seulement : un CR ou un LF isolé est normalisé avant la signature, si bien que les octets signés sont ceux qui voyagent (RFC 5321 §2.3.8).

​
Clés de signature déléguées

Une application qui soumet via un compte ordinaire ne sait souvent pas signer, et vous ne devez pas demander sa zone à son propriétaire. La signature déléguée laisse le relais signer d=<le domaine exact du client> pendant que le client publie deux CNAME, et rien d’autre. Elle est provisionnée par l’opérateur, comme toute autorisation qui élargit ce qu’un compte peut émettre : il n’existe ni verbe côté client ni méthode JMAP. Le domaine doit déjà appartenir au tenant (oximail tenant add-domain, de n’importe quel type), et --email désigne n’importe quel compte de ce tenant : il sert seulement à dire à la CLI de quel tenant il s’agit.
add --apply génère la première clé RSA 2048 (une clé plus petite est refusée), la scelle, et affiche ce que le client publie, un CNAME par sélecteur :
  • Où les clés sont publiées. Les cibles vivent sous dkim.<[server] hostname>, dans la zone que le fournisseur [dns] écrit déjà. Avec Cloudflare, le relais écrit lui-même les enregistrements cibles ; avec tout autre fournisseur, add, verify et doctor listent les TXT à publier à la main, et un enregistrement publié à la main est reconnu quand il est relu. Chaque cible répond v=DKIM1; k=rsa; n=<label>; p=<clé> : la balise n= porte le label, si bien que lire <sélecteur>._domainkey.<domaine> à travers le nom du client prouve que ce nom mène à ce relais et montre quelle clé le monde voit, sans interroger le CNAME.
  • Pourquoi deux sélecteurs, et des labels aléatoires. Deux sélecteurs pour qu’une rotation ait toujours un sélecteur libre. Chaque label cible est aléatoire, unique dans la base et jamais réutilisé : les cibles d’un domaine retiré continuent de répondre p= vide, si bien qu’un CNAME oublié par un client parti n’atteste plus rien pour personne, pas même pour le prochain titulaire de ce domaine.
  • Quand une clé signe. Un passage a lieu deux minutes après le démarrage du serveur, puis toutes les heures (verify le lance à la demande). Une clé est préparée, puis publiée quand sa cible répond avec elle, puis active quand elle est visible à travers le nom du client depuis deux TTL de l’enregistrement (3600 s, donc deux heures) ; la clé précédente est en retrait jusqu’à revenir à vide. La preuve dkim du domaine est confirmée quand les deux sélecteurs mènent à ce relais, et suspendue dès que l’un s’arrête.
  • Rotation. Tous les 180 jours, une nouvelle clé est générée derrière le sélecteur libre et suit les mêmes étapes ; la clé précédente reste publiée sept jours, puis répond p= vide. Les CNAME du client ne changent jamais : une rotation ne demande rien au client.
  • Fail-safe, pas fail-open. Une clé que le monde ne voit pas (la clé publiée diffère de la clé de signature, ou la cible a disparu) ne signe pas, et doctor échoue. Une clé qui ne peut pas être lue ou descellée retient la ligne, différée : elle ne laisse jamais partir un message non signé. La clé privée n’est jamais exportée (aucun verbe ni aucune méthode ne la rend) ; elle est scellée sous la clé du tenant, liée à son domaine et à son sélecteur. Cette clé du tenant est elle-même protégée par la clé serveur, qui a son séquestre : une sauvegarde de volume emporte donc les deux, et c’est pourquoi une restauration les remplace (section suivante).
  • Limites. Une seule clé active par domaine ; les deux sélecteurs sont fixes (oximail1, oximail2) ; RSA seulement ; la publication automatique ne couvre que Cloudflare aujourd’hui ; la clé ne signe que le domaine From: exact pour lequel elle a été déclarée (pas un parent, pas un sous-domaine), que pour le courrier du tenant qui la détient, et seulement après les clés de l’opérateur.
  • doctor delegated_dkim échoue quand une clé de signature n’est plus ce que le monde voit ; il avertit quand un domaine déclaré n’a toujours pas de clé active après trois jours (le client n’a pas publié ses CNAME), quand la clé active a plus de 190 jours (rotation en retard), ou quand des enregistrements attendent d’être publiés à la main.
  • Retirer un domaine (remove --yes) efface ses clés et retire sa preuve dkim ; ses cibles continuent de répondre p= vide et ne sont jamais réutilisées.

​
Les clés de signature déléguées après une restauration

Une sauvegarde emporte les clés privées des domaines clients pour lesquels le relais signe (oximail account signing-domain), avec la clé d’organisation qui les scelle : après oximail restore, chaque clé créée avant la restauration est donc présumée exposée. Le passage horaire lit la date de restauration dans le marqueur que restore écrit à côté de la base, et les remplace. Une clé de réserve (préparée, publiée ou en retrait) revient à vide tout de suite et ne peut plus jamais signer. Une nouvelle clé de signature est préparée dans le même passage ; l’ancienne continue de signer jusqu’à ce que la nouvelle soit visible dans le DNS depuis deux TTL, puis se retire pendant deux jours au lieu des sept habituels. Rien ne change pour le client : ses CNAME restent les mêmes. oximail doctor nomme sous delegated_dkim les domaines qui portent encore une clé antérieure à la restauration ; une fois qu’il n’y en a plus, plus rien ne se passe.

​
Sur quelle famille IP le courrier part

La réputation se tient par famille d’adresses chez les grands fournisseurs et dans les listes de blocage : une IPv6 qui n’a jamais émis est froide, même si l’IPv4 de la même box est bien établie. Le courrier sortant part donc en IPv4 dès que la destination a une adresse IPv4.
  • auto (par défaut). Par domaine : quand un hôte MX a une adresse IPv4, seuls ces hôtes sont essayés, donc un MX IPv6 seul de priorité plus haute est ignoré ; un domaine dont tous les hôtes MX n’ont pas d’IPv4 est joint en IPv6. Un domaine dont on ne peut pas exclure l’IPv4 parce qu’une réponse DNS était illisible est différé, jamais joint en IPv6 sur une supposition (une réponse vide est une réponse, une réponse en échec n’en est pas une). Par hôte : ses adresses IPv4 quand il en a, ses adresses IPv6 sinon, jamais les deux, si bien qu’une IPv4 en échec diffère la ligne au lieu de retomber sur l’IPv6. La même règle par hôte s’applique à un relay_host. Les versions précédentes suivaient l’ordre du résolveur, qui met l’IPv6 d’abord pour un MX double pile : une box dotée d’une IPv6 globale envoyait déjà aux grands fournisseurs par elle, depuis son adresse par défaut. Chauffez une IPv6 volontairement, ou laissez-la inutilisée.
  • v4 et v6 figent la famille. Une destination sans adresse de cette famille fait échouer la tentative (journalisée) plutôt que d’utiliser l’autre en silence : une garantie qui retombe sur autre chose n’en est pas une.
  • Les pools de sortie gardent les deux familles. Un pool qui a une adresse IPv4 et une adresse IPv6 donne les deux sources au client SMTP, qui lie, pour chaque adresse de la destination, la source du pool de la famille de cette adresse : IPv4 dès que la destination en a une, et l’IPv6 du pool seulement pour une destination sans IPv4, qu’il ne pourrait pas joindre autrement. Une destination dans une famille que le pool n’a pas n’est jamais essayée depuis l’adresse par défaut de la box : la tentative échoue en nommant les familles résolues et celles que le pool peut lier, et la ligne est différée au rythme normal jusqu’à son expiration inchangée. Figé sur v4 ou v6, un pool sans cette famille retient la ligne (aucune tentative comptée).
  • oximail doctor --reachability exécute en entier le contrôle egress_pools : pour chaque adresse publique de chaque pool qui peut servir sous la famille configurée (donc les deux, en auto), il vérifie que son PTR est le nom HELO du pool, que le HELO se résout bien vers elle, et que le SPF du HELO la laisse passer : un rapport à expéditeur nul est jugé sur le HELO (RFC 7208 §2.3), donc une IPv6 que le SPF ne nomme pas y échoue. Sans --reachability, le contrôle vérifie seulement que chaque adresse locale de chaque pool est sur une interface.

​
Surveillance de réputation

Une IP d’egress partagée listée dégrade la livraison de tous les clients d’un coup. Activez l’auto-surveillance :
L’adresse IPv4 publique de chaque pool de sortie est surveillée aussi, sans être comptée deux fois (une adresse IPv6 est ignorée : les listes publiques sont en IPv4 en pratique). Un worker vérifie chaque IP contre Spamhaus ZEN, Barracuda et SpamCop toutes les quinze minutes et publie oximail_smarthost_ip_listed{ip,list}. Il lit les réponses comme le filtre entrant (anti-spam) : seul NXDOMAIN veut dire « non listé », et une liste qui refuse le résolveur de la box ou ne répond pas est comptée dans oximail_dnsbl_answers_total{source="self"} au lieu de se lire comme propre. Alertez sur > 0 et inscrivez vos IP aux programmes de retour des destinataires (Google Postmaster Tools, Microsoft SNDS/JMRP, Yahoo CFL) avant votre premier client.
Un smarthost partagé porte la responsabilité d’abus et de réputation de tout ce qu’il relaie. Surveillez l’IP d’egress, limitez le débit par compte et, pour un service géré, mettez par écrit les conditions de traitement des données (l’exploitant d’un relais est sous-traitant pour le courrier qu’il transmet).