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. C’est une capacité du rôle Primary, pas un mode d’installation distinct.
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 : 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.

​
Partie 2 : exploiter un smarthost

Un smarthost accepte le relais authentifié des instances leaf. L’activer revient à créer les comptes relais autorisés à relayer : il n’existe pas de rôle de démarrage ni de chemin d’installation distinct. Pour un hub dédié, l’assistant de setup propose une entrée Smarthost relay (dedicated hub) (premier démarrage, section « Déroulé smarthost ») : le même déroulé que le serveur principal avec des ajustements ciblés, IP d’egress collectées, enregistrement SPF du hub publié, surfaces boîtes aux lettres désactivées, et une déclaration [mode] profile = "smarthost" que l’audit de démarrage compare à la configuration à chaque démarrage (il avertit si les surfaces boîtes reviennent ou si l’auto-surveillance DNSBL est éteinte ; il ne change jamais le comportement). Un serveur combiné boîtes + hub laisse simplement le profil absent.

​
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 les domaines dont il a prouvé le contrôle. 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.
Le client publie cet enregistrement TXT ; vous le vérifiez ensuite :
Un worker en arrière-plan re-vérifie chaque domaine déclaré 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.
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 transitoire 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).

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

Le courrier relayé par un compte service est éphémère. À l’acceptation 250 du destinataire, sa ligne de file et son blob chiffré sont purgés : l’enregistrement identifiant est détruit et la clé de chiffrement du blob supprimée (le contenu devient indéchiffrable à cet instant). Sur le chemin de relais, les journaux de livraison ne portent que l’identifiant de file, jamais les adresses d’enveloppe. Un compteur de purge journalier non identifiant sert de trace d’audit. 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 relais ne réécrit jamais, et ne re-signe jamais. Un message relayé est transféré octet pour octet, y compris quand le smarthost héberge lui-même le domaine du From:. Aucune DKIM-Signature du smarthost n’est ajoutée : 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).
  • 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é. Pour la même raison, l’EHLO entrant n’annonce pas de promesses qu’il ne peut pas tenir vers l’aval : les paramètres DSN NOTIFY/ORCPT sont retirés plutôt que perdus en silence plus loin, et BODY=BINARYMIME est rejeté 555 5.5.4.

​
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 :
Un worker vérifie chaque IP contre Spamhaus ZEN, Barracuda et SpamCop toutes les quinze minutes et publie oximail_smarthost_ip_listed{ip,list}. 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).