2026 : OpenClaw sur Mac Mini loué — Postmark Inbound, webhook, batch nocturne, fenêtre silencieuse et backoff

Pourquoi le mauvais hôte casse l’automatisation pilotée par e-mail

1. Pas d’auth. Une URL devinable accepte du bruit ; imposez TLS + secret de chemin (ou en-tête) avant de parser le JSON.
2. HTTP lent. Hors 2xx ou timeouts, Postmark retry : vous voyez des doublons si la dédup MessageID manque.
3. Pas de fusion. Chaque erreur de parse poussée telle quelle vers Slack ou SMS use la confiance des humains.

Où exécuter le consommateur Inbound

Routage Inbound et authentification

Dans Postmark, activez le flux Inbound, publiez les MX ou enregistrements de réécriture indiqués, puis renseignez l’URL du webhook sous la forme https://hôte/inbound/<secret-long>, derrière Caddy ou nginx en terminaison TLS. Refusez avec 401 si le segment secret ne correspond pas, avant toute désérialisation JSON : vous évitez le travail inutile et les journaux bruités.

Stockez l’empreinte MessageID dans SQLite ou LMDB avec une fenêtre de rétention (par ex. quarante-huit heures) supérieure aux fenêtres de retry Postmark. Séparez les locataires par secret de chemin et par label launchd afin que deux arbres OpenClaw (OPENCLAW_HOME distincts) ne lisent jamais la même file par erreur.

Modèle de script passerelle

La passerelle ne doit rien faire de lourd : vérifier le jeton, insérer l’idempotence, écrire queue/*.json, répondre 200. Le drain lourd et OpenClaw vivent dans un service séparé déclenché par launchd.

// Gestionnaire minimal (pseudo-code style Node)
app.post('/inbound/:token', (req, res) => {
  if (req.params.token !== process.env.INBOUND_TOKEN) return res.sendStatus(401);
  const id = req.body.MessageID;
  if (!dedupe.insertIfNew(id)) return res.sendStatus(200); // retry Postmark
  fs.writeFileSync(`queue/in-${Date.now()}.json`, JSON.stringify(req.body), { flag: 'wx' });
  return res.sendStatus(200);
});

En production, utilisez le corps brut signé si votre stack l’exige, et des écritures atomiques (fichier temporaire puis rename) avant la réponse HTTP.

Fenêtre nocturne et fusion des erreurs

Programmez le drain avec launchd et StartCalendarInterval entre 01h et 05h (fuseau du Mac Mini loué), sauf si l’objet du message contient un jeton d’override documenté. Regroupez les erreurs non fatales par clé locataire + segment et n’envoyez qu’un digest par fenêtre vers le canal choisi.

Lorsqu’un webhook de notification échoue (429, 5xx, timeout), appliquez un backoff exponentiel avec jitter (par ex. plafond soixante secondes, cinq tentatives max). Ajoutez une marge de quinze minutes après la fin prévue du batch pour une queue silencieuse : les uploads tardifs ne rouvrent pas la fenêtre d’alerte.

Étapes reproductibles (HowTo)

1. Terminez les tests DNS jusqu’à voir l’état Reçu sur un message test dans le flux Inbound.
2. Exposez TLS sur le Mini ; avec curl, vérifiez 401 sans le bon segment de chemin.
3. Déployez la passerelle avec dédup MessageID ; rejouez deux fois le même JSON, la seconde réponse doit être 200 sans nouvelle entrée de file.
4. Branchez OpenClaw sur le drain de queue/*.json (ex. extraction TextBody), launchctl bootstrap sur la plist nocturne, contrôlez log show pendant la première fenêtre.
5. Activez digest + backoff sur les sorties, archivez les journaux chaque nuit sur le nœud longue durée.

Repères chiffrés utiles : rétention dédup quarante-huit heures, cinq tentatives d’envoi digest maximum, plafond backoff soixante secondes, queue silencieuse quinze minutes, budget handler webhook deux secondes avant déport disque.

FAQ : idées reçues sur le DNS et SPF

Copier mon enregistrement SPF marketing sur le sous-domaine inbound améliore-t-il la délivrabilité vers Postmark ?

SPF décrit quels serveurs peuvent envoyer du courrier pour votre domaine dans des contextes d’enveloppe précis. La réception Inbound suit les MX et la configuration Postmark ; dupliquer SPF sans analyse casse souvent l’envoi sortant légitime tout en n’apportant rien au webhook HTTPS.

Le DKIM du message remplace-t-il un secret partagé sur l’endpoint ?

DKIM atteste le MIME côté expéditeur ; votre passerelle doit tout de même prouver que le POST provient du canal attendu (secret, signature documentée, mTLS si applicable).

Pourquoi vois-je des rafales de MessageID identiques après un déploiement ?

Vider la base de dédup ou raccourcir le TTL sous la fenêtre de retry du fournisseur garantit des doublons. Incluez le magasin d’idempotence dans la politique de sauvegarde comme le répertoire queue/.

OpenClaw doit-il parser le MIME dans la même réponse HTTP que Postmark ?

Non : séparez ingestion (200 rapide) et traitement OpenClaw (batch). C’est ce découplage qui rend le Mac Mini loué pertinent pour les pièces jointes et les reprises après incident.