> ## Documentation Index
> Fetch the complete documentation index at: https://docs.oximail.ch/llms.txt
> Use this file to discover all available pages before exploring further.
# Relais sortant & smarthost
> Envoyer le courrier sortant via un relais (smarthost ou ESP) lorsque l'IP est froide ou que le port 25 est bloqué, et exploiter OxiMail comme smarthost pour d'autres instances : comptes relais, domaines prouvés par DNS, enrôlement à usage unique, rétention éphémère et surveillance de réputation.
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](#enrôlement-à-usage-unique).
### 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 :
```toml theme={null}
[[smtp.transport_maps]]
pattern = "*"
relay_host = "smtp.votre-relais.example"
relay_port = 587
auth_user = "votre-compte-relais"
auth_password_file = "/etc/oximail/relay.password"
implicit_tls = false # true pour le port 465
spf_mechanism = "include:spf.votre-relais.example"
```
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** :
| Enregistrement | Valeur | Pourquoi |
| -------------- | ---------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **SPF** | ajouter `include:spf.votre-relais.example` à votre enregistrement `v=spf1 …` | Autorise l'IP d'egress du relais à émettre pour votre domaine. Utilisez l'`include:` du relais (et non un `ip4:` en dur) pour que l'opérateur puisse renuméroter sans que vous éditiez votre zone. |
| **DKIM** | votre propre clé `d=votredomaine` (inchangée) | Le relais retransmet votre message **à l'octet près** : votre signature est préservée, donc DMARC passe par DKIM quelle que soit l'IP émettrice. |
Un smarthost géré demande en plus de publier une **preuve de domaine relais**, `_oximail-relay.votredomaine TXT ""`, 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 :
```bash theme={null}
oximail setup relay-preflight --ip
```
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](../first-boot), 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 :
```bash theme={null}
oximail account create --email relais-client@votre-smarthost.example --role service --tenant-id
oximail account set-role --account relais-client@votre-smarthost.example --role 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.
```bash theme={null}
oximail account relay add-domain --email relais-client@votre-smarthost.example --domain client.tld
# → affiche le jeton de preuve DNS à publier :
# _oximail-relay.client.tld TXT ""
```
Le client publie cet enregistrement TXT ; vous le vérifiez ensuite :
```bash theme={null}
oximail account relay verify --email relais-client@votre-smarthost.example
oximail account relay list --email relais-client@votre-smarthost.example # → « active »
```
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.
```bash theme={null}
oximail account relay mint-token --email relais-client@votre-smarthost.example --tenant-id --ttl-hours 24
```
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 :
```toml theme={null}
[metrics]
dnsbl_self_ips = ["203.0.113.10"] # votre ou vos IP d'egress
```
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).