85.1.35. pepsi-stage-route

route each recipient to a next hop by their domain

Section du manuel:

1

85.1.35.1.1. Nom

pepsi-stage-route - l’étape d’acheminement par domaine de destinataire du pipeline Pepsi.

85.1.35.1.2. Synopsis

pepsi-stage-route [GLOBAL-OPTIONS] worker

85.1.35.1.3. Description

pepsi-stage-route est un programme d’étape exécuté par pepsi-dispatch(1) comme un worker persistant lisant les identifiants de message sur l’entrée standard. Il charge cette ligne pepsi.workqueue (refusant d’agir sauf si son status est running), lit sa section [stage-<stage>], et choisit une étape suivante pour chaque destinataire d’enveloppe d’après le domaine de ce destinataire.

Elle existe pour une seule forme de déploiement : une passerelle placée devant un autre système de courrier, tel que Microsoft Exchange ou Exchange Online. Une telle passerelle a une décision d’acheminement à prendre sur chaque message entrant — ce destinataire appartient-il au système derrière moi, ou à l’internet ? — et se tromper n’est pas un échec de remise mais une boucle de courrier. Les domaines situés derrière la passerelle sont exactement les domaines dont le MX public est la passerelle : en remettre un à un relais direct-vers-MX renvoie donc le message tout droit dans notre propre ingress, qui l’accepte, le réachemine vers l’extérieur, et recommence jusqu’à ce que MAX_HOP_COUNT l’arrête.

L’étape ne réécrit jamais le message, ne le remet jamais, ne le fait jamais rebondir et n’en abandonne jamais un. La seule colonne qu’elle déplace est stage, de sorte que state — y compris state.dsn — est préservé exactement. Ni les en-têtes ni le corps ne sont chargés.

Contrairement aux autres étapes à métadonnées seules, elle n’a pas FUSION = yes par défaut. Une étape fusionnée s’exécute dans le processus worker de son prédécesseur, et l’éventail de destinataires de cette étape refuse de s’exécuter tant que des modifications de contenu d’un prédécesseur ne sont pas validées ; plutôt que de faire de cette interaction une surprise à l’exécution, l’étape est toujours dispatchée normalement. Voir pepsi-dispatch(1).

85.1.35.1.4. Acheminement

Pour chaque destinataire, dans cet ordre :

  1. les règles ROUTES explicites, dans l’ordre configuré — la première dont le motif de domaine correspond l’emporte ;

  2. l’ensemble des domaines gérés (MANAGED_DOMAINS, par défaut [pepsi-ingress] ACCEPTED_DOMAINS) — un destinataire de l’un de ces domaines va vers MANAGED_STAGE, lorsqu’elle est définie ;

  3. sinon NEXT_STAGE.

Les règles explicites sont consultées d’abord afin qu’une exception soit exprimable : un sous-domaine d’un domaine servi peut être envoyé ailleurs que vers le système situé derrière la passerelle, sans retirer le parent de MANAGED_DOMAINS, ce qui empêcherait aussi l’ingress d’en accepter le courrier.

Les motifs de domaine sont comparés sans tenir compte de la casse et peuvent contenir *, qui correspond à toute suite de caractères. Ce sont des globs, pas des expressions régulières, et ils sont ancrés aux deux extrémités : *.example.org correspond à mail.example.org mais ni à example.org lui-même ni à mail.example.org.evil.test. Un motif ayant l’allure d’une expression régulière est rejeté au moment de la configuration plutôt que de ne silencieusement correspondre à rien.

MANAGED_DOMAINS vaut par défaut ce qu’accepte l’ingress plutôt que de faire répéter l’opérateur : une table d’acheminement qui a dérivé d”ACCEPTED_DOMAINS est précisément un domaine dont le courrier part du mauvais côté de la passerelle. L’ensemble résultant ne doit pas être vide : pepsi-setup(1) refuse une étape de routage sans domaine géré, puisqu’elle ne pourrait ni distinguer les deux côtés ni détecter la boucle décrite ci-dessous.

85.1.35.1.5. Éventail des destinataires

Les destinataires qui s’acheminent vers la même étape voyagent ensemble. Lorsqu’ils divergent, le message est scindé : cette ligne garde le premier groupe et chaque autre groupe devient une ligne sœur pending vers sa propre cible, le tout en un seul appel à la base. Chaque ligne sœur ne porte que ses propres destinataires, et le state.dsn.rcpt de chaque ligne est découpé pour correspondre à son rcpt_to, de sorte qu’un rebond ou un rapport de remise ultérieur décrive toujours les bonnes adresses.

Le regroupement se fait dans l’ordre de première apparition, de sorte qu’un message réessayé conserve les mêmes destinataires sur la même ligne.

85.1.35.1.6. Prévention des boucles

pepsi-setup(1) refuse une configuration dans laquelle un message pour un domaine servi pourrait atteindre un relais direct vers le MX (pepsi-stage-relay-to-internet(1)). Il parcourt le pipeline vers l’avant depuis chaque étape qu’un destinataire géré peut atteindre, en suivant chaque option qui fait suivre le message lui-même : NEXT_STAGE, les cibles de toute autre étape de routage, les TRUE_STAGE et FALSE_STAGE de pepsi-stage-if(1), les ACCEPT_STAGE et QUARANTINE_STAGE de pepsi-stage-milter(1), le QUARANTINE_STAGE de pepsi-stage-decrypt(1), le SECURE_LINK_STAGE de pepsi-stage-encrypt(1), l”UNCHALLENGEABLE_STAGE de pepsi-stage-secretary(1) et le BOUNCE_TARGET_STAGE de pepsi-stage-anti-spam(1).

Trois sortes de cibles ne sont délibérément pas suivies. BOUNCE_STAGE et les options qui acheminent un destinataire en échec vers un rapport (le REJECT_STAGE de pepsi-stage-milter(1), les QUOTA_LIMIT_STAGE, SIEVE_REJECT_STAGE, NOTIFY_STAGE et UNKNOWN_MAILBOX_STAGE des étapes de remise locale) : ce qui y transite devient un DSN à expéditeur nul portant sur une remise déjà échouée, et non le message poursuivant son chemin dans le pipeline, et un DSN atteint légitimement un relais. RESPONSE_STAGE et ses semblables, qui injectent un nouveau message à destination de quelqu’un d’autre. Et les cibles qui réadressent le message à de nouveaux destinataires que le pipeline achemine à nouveau — le RESTART_STAGE de pepsi-stage-dot-forward(1) et les POST_STAGE, COMMAND_STAGE et DELIVERY_STAGE des étapes de listes de diffusion.

Séparément, pepsi-setup(1) refuse une section [pepsi-stage-relay-to-smarthost-mta-*] dont le HOST est cet hôte (son [pepsi-ingress] HOSTNAME, localhost, ou une adresse de boucle locale) et dont le PORT est un port auquel un listener d’ingress est lié. Les deux moitiés sont requises, car chacune seule est une configuration légitime.

Ce sont des refus, non des avertissements. Une boucle ne s’arrête que lorsque la garde MAX_HOP_COUNT des étapes de relais se déclenche, des dizaines de copies plus tard, et le rebond que cette garde produit alors est lui-même adressé de nouveau dans la boucle.

85.1.35.1.7. Configuration

Les options se trouvent dans la propre section [stage-<name>] de l’étape (PROGRAM = pepsi-stage-route) : ROUTES, MANAGED_DOMAINS, MANAGED_STAGE et le NEXT_STAGE obligatoire, plus RECIPIENT_CHECK (none, probe ou map) avec PROBE_HOST, PROBE_PORT, PROBE_TLS, PROBE_TIMEOUT et RECIPIENT_MAP. Le dernier groupe n’est pas lu par l’étape : il indique à pepsi-ingress(1) comment demander au backend si une adresse existe, afin qu’une adresse inconnue soit refusée au moment du RCPT plutôt que de rebondir plus tard depuis le backend. Toutes sont documentées dans pepsi.conf(5).

85.1.35.1.8. État

Entrées : les destinataires d’enveloppe (rcpt_to). Aucun membre de state n’est lu.

Sorties : aucune — state n’est jamais modifié, seulement découpé par groupe de destinataires lorsqu’un message est scindé. La disposition de l’état est décrite dans pepsi.state(7).

Transitions : avance vers l’étape que sélectionne le domaine de chaque destinataire, et scinde le message en lignes sœurs pending lorsque les destinataires divergent. L’étape ne met jamais en pause, n’échoue, ne réachemine ni ne termine.

85.1.35.1.9. Commandes

worker

Exécuté comme un worker persistant de pepsi-dispatch(1), lisant les identifiants de message sur l’entrée standard.

85.1.35.1.10. Options globales

-c FILE, –config FILE

Lit la configuration depuis FILE au lieu de parcourir les emplacements par défaut.

-L LOGLEVEL, –log LOGLEVEL

Règle la verbosité de journalisation (par défaut info).

-v, –verbose

Affiche les messages de journal de toutes les sources.

-h, –help ; -V, –version

Affiche un résumé d’utilisation / la version et quitte.

85.1.35.1.11. Code de sortie

0

Le message a été acheminé (avancé, et scindé au préalable si ses destinataires divergeaient).

1

Une erreur s’est produite (message introuvable ou non running, étape mal configurée — par exemple un NEXT_STAGE manquant — ou une erreur de base de données). La raison est écrite dans le journal.

78

Le worker a refusé de démarrer : sa section ne s’analyse pas. Le dispatcher remet en file ce qu’il lui avait confié et réessaie l’étape plus tard. Une erreur de base de données pendant le découpage d’un message est réessayée comme toute autre défaillance de cet hôte (voir pepsi-dispatch(1)) ; un réessai trouve la ligne déjà réduite aux destinataires restés et n’achemine qu’eux.

85.1.35.1.12. Exemples

Acheminer un seul message (il doit être running)

echo 42 | pepsi-stage-route -c /etc/pepsi/pepsi.conf worker

La topologie de passerelle en deux options — le courrier des domaines que sert cet hôte va vers Exchange, tout le reste part vers l’internet

[stage-route]
PROGRAM = pepsi-stage-route
MANAGED_STAGE = exchange
NEXT_STAGE = internet

La même chose, avec un sous-domaine hérité mis à part et un domaine partenaire recevant son propre saut suivant

[stage-route]
PROGRAM = pepsi-stage-route
ROUTES = legacy.example.org=maildir partner.example=partner-relay
MANAGED_STAGE = exchange
NEXT_STAGE = internet

85.1.35.1.13. Voir aussi

pepsi-config(1), pepsi-stage-if(1), pepsi-stage-relay-to-smarthost(1), pepsi-stage-relay-to-internet(1), pepsi-dispatch(1), pepsi.conf(5), pepsi.state(7), pepsi-setup(1)

85.1.35.1.14. Bogues

Signalez les bogues au gestionnaire de tickets de Pepsi.