5. L’assistant

pepsi-setup --wizard déroule un court questionnaire et écrit un pepsi.conf complet et déjà validé. C’est la manière prévue de produire une première configuration : le chapitre suivant, Configuration, décrit le fichier que l’assistant écrit, et celui-ci explique comment les réponses deviennent ce fichier.

Le pipeline d’étapes est assemblé à partir des réponses. Quelles étapes existent, et comment leurs options NEXT_STAGE et BOUNCE_STAGE se câblent entre elles, découle mécaniquement de la direction que sert l’hôte et des fonctionnalités activées. Il n’y a pas de menu de pipelines à choisir ni de modèle à remplir ; le graphe est calculé. Ce chapitre présente les trois pipelines que l’assistant peut construire, puis quelle question insère ou retire chacune de leurs étapes.

Note

Ce chapitre décrit ce que font les réponses. Le détail opérationnel de la commande — chaque indicateur, la migration du MTA, les raccourcis readline, le comportement des invites de secret, le format du fichier de réponses — se trouve dans pepsi-setup(1).

5.1. Déroulement d’une exécution

  1. Import. Sur un hôte encore dépourvu de pepsi.conf, l’assistant détecte un Postfix, un Exim, un Sendmail, un qmail ou un Stalwart existant et propose de reprendre ses paramètres comme valeurs par défaut du questionnaire. Rien n’est adopté silencieusement — chaque valeur importée est tout de même présentée à sa propre invite. Lors d’une réexécution, c’est la section [pepsi-wizard] du fichier existant qui fournit les valeurs par défaut.

  2. Questionnaire. Les questions ci-dessous, groupées en étapes numérotées. Chaque réponse est validée à la saisie, de sorte qu’un domaine ou un port malformé est détecté à sa propre invite.

  3. Rendu. Les réponses sont transformées en fichier de configuration — c’est là que le pipeline est assemblé.

  4. Validation. Le texte produit est chargé et validé par le chemin même qu’emprunte pepsi-setup run. En cas d’échec, l’assistant affiche la faute et reparcourt les questions avec les réponses précédentes pré-remplies : corriger une option revient à passer les autres en appuyant sur Entrée.

  5. Écriture. Le fichier est écrit, et les secrets qu’il contient (la clé HMAC SRS, les mots de passe du smarthost et de LMTP, les jetons du marchand et de /resume) sont sortis dans des fragments secrets.d/*.secret aux permissions restreintes, référencés par des directives @inline-secret@. Ce qui a été écrit est ensuite rechargé et revalidé, puisque le déplacement des secrets l’a réécrit.

  6. Proposition d’exécuter la configuration initiale. Installer le schéma, générer les clés DKIM, provisionner les certificats TLS et afficher les enregistrements DNS à publier relèvent de pepsi-setup run, pas du questionnaire. L’assistant propose d’enchaîner directement dessus.

Le même questionnaire est également posé par la console de configuration initiale du navigateur (voir La console d’administration).

5.2. Le même questionnaire dans un navigateur

Il n’y a pas de second questionnaire. Chaque question, sa forme, sa valeur par défaut, son texte d’aide et les conditions dans lesquelles elle est posée résident en un seul endroit sous forme de données (pepsi_setup_model::questions), et les deux frontaux rendent ce modèle — une question ne peut donc pas être ajoutée à l’un sans l’autre, et un test vérifie que les deux ensembles d’identifiants sont égaux. Seule la présentation diffère : le terminal pose une question à la fois sous les bannières d’étape listées ci-dessous, la console affiche son propre regroupement, plus grossier, des mêmes questions, une page à la fois.

L'étape « Identité du serveur » de la console de configuration initiale du navigateur

La première étape. Chaque champ porte la même aide que celle qu’affiche le terminal et — là où la réponse correspond à exactement une option — le [section] OPTION où elle atterrira, afin de retrouver ensuite le même réglage dans le fichier. Le bandeau du haut est le questionnaire entier, les étapes auxquelles il a été répondu étant marquées.

Le branchement appartient lui aussi au modèle : la console masque donc ce que le terminal ne demanderait pas. Ci-dessous, l’activation du blocage par langue a fait apparaître les champs de politique, de seuil et d’application — et a retiré la question localiser les messages de rebond, car le blocage implique déjà la détection et le terminal ne pose celle-ci que si le blocage est désactivé :

L'étape « Filtrage de contenu », avec les champs de politique de langue apparents

Filtrage de contenu, avec le blocage activé.

Deux points au sujet de la console :

  • Les réponses sont des brouillons. Chaque étape est déposée dans la base de données, non écrite dans /etc ; rien ne prend effet tant que le questionnaire n’est pas appliqué. Une session qui expire à mi-parcours n’a pas à moitié configuré un serveur de messagerie.

  • La console demande ; elle n’agit pas. Elle s’exécute sans privilège et ne peut ni écrire pepsi.conf, ni lancer certbot, ni installer le schéma. Enregistrer note une demande que pepsi-setup apply, démarré séparément et s’exécutant en root, valide et exécute. Sur un hôte où cette moitié privilégiée n’est pas installée — c’est un paquet Debian à part — les pages de configuration initiale s’affichent en lecture seule, montrant chaque valeur avec les contrôles désactivés et la raison à côté d’eux, plutôt que d’accepter des réponses dans une file d’attente que rien ne vide.

Les captures d’écran sont générées par contrib/screenshot-setup.sh à partir des modèles et de la feuille de style livrés, ce qui permet de les remettre en accord avec le code.

5.3. La première question décide de la forme

Avant toute bannière d’étape, l’assistant demande

Mail direction this host serves [both]: inbound | outbound | both

Tout le reste en découle. inbound signifie que cet hôte reçoit d’Internet le courrier destiné à vos domaines ; outbound, qu’il relaie ce que soumettent vos propres utilisateurs et les programmes locaux ; both — la valeur par défaut — qu’il fait l’un et l’autre, les deux flux étant séparés dès la première étape. La réponse décide quels listeners SMTP sont écrits, lesquelles des étapes suivantes sont posées, et lequel des trois pipelines ci-dessous est construit.

5.3.1. Pipeline : both

L’étape d’entrée est un branchement sur state.local_origin — l’indicateur que pepsi-ingress positionne pour une soumission authentifiée — de sorte qu’un message que cet hôte a reçu et un message que notre propre utilisateur a envoyé ne partagent jamais une étape. ARC existe pour transporter les verdicts d’authentification d’un domaine administratif amont à travers notre saut de redirection ; sceller les soumissions de nos propres utilisateurs publierait leurs résultats SPF/DKIM/DMARC à la face du monde.

                 pepsi-ingress
 Internet ──▶ :25           :465 / :587 ◀── your users
               │                 │       (and the local sendmail
               └────────┬────────┘        socket, always served)
                        ▼
                      init            pepsi-stage-if on
                        │             state.local_origin
         ┌──────────────┴────────┐
   false │                       │ true  (our own submissions)
         ▼                       ▼
the received branch              list-out            MAILING_LISTS
(second panel below)             │
                                 ▼
                                 wallet              WALLET_SELF_SERVICE
                                 │
                                 ▼
                                 edit-settings       EDIT_SETTINGS
                                 │
                                 ▼
                                 encrypt             CRYPTO
                                 │
                                 ▼
                                 auto-whitelist      LEARN_WHITELIST,
                                                     ANTI_SPAM or SECRETARY
                                 │
                                 ▼
                                 milter-*            imported
                                                     non_smtpd_milters
                                 │
                                 ▼
                                 dkim-sign           (always)
                                 │
                                 ▼
                                 internet            (always)

Et la branche de réception, où réside presque toute fonctionnalité :

(the false branch of the split above)
                │
                ▼
                arc                  pepsi-stage-arc
                │
                ▼
                decrypt              CRYPTO
                │
                ▼
                detect-language      LANGUAGE_BLOCKING
                                     or I18N_BOUNCES
                │
                ▼
                block-language       LANGUAGE_BLOCKING
                │
                ▼
                milter-*             MILTER_* (one per filter found)
                │
                ▼
                check-whitelist      ANTI_SPAM or SECRETARY
                │
                ▼
                secretary            SECRETARY
                │
                ▼
                anti-spam            ANTI_SPAM
                │
                ▼
                autocrypt-learn      AUTOCRYPT_LEARN
                │
                ▼
                list ──▶ list-post   MAILING_LISTS
                │        list-command
                │        list-bounce
                ▼
                aliases              ALIASES_ENABLED
                │
                ▼
                vacation             VACATION
                │
                ▼
                route ──▶ exchange   EXCHANGE  (our own domains)
                │
                ▼
                dot-forward          DOT_FORWARD
                │
                ▼
                reencrypt            REENCRYPT (before local delivery)
                │
                ▼
                local                LOCAL_METHODS (maildir)
                │
                ▼
                local-lmtp           LOCAL_METHODS (lmtp; the two
                                     methods run in the order chosen)
                │
                ▼
                srs                  (always)
                │
                ▼
                dkim-sign-relay      SIGN_RELAYED
                │
                ▼
                smarthost            SMARTHOST_HOST
                or internet          (otherwise)

Lecture des figures : une étape marquée (always) est inconditionnelle pour cette direction, et toute autre étape est présente exactement lorsque la réponse indiquée à côté d’elle le dit. Les étapes sont enchaînées dans l’ordre affiché, le NEXT_STAGE de chacune pointant vers la suivante qui a survécu — désactiver une fonctionnalité ne laisse donc pas de trou, cela raccourcit la chaîne. list-out est le même routeur de listes que list, placé en tête de la branche de soumission afin qu’un utilisateur local écrivant à une liste hébergée ici atteigne la liste au lieu d’être relayé vers son propre MX.

Trois contraintes fixent cet ordre :

  • decrypt est première sur la branche de réception et encrypt est la dernière des étapes propres à la branche de soumission à réécrire le message avant la signature. Tout ce qui est en aval de decrypt voit donc le texte clair (la détection de langue, la liste blanche, le paywall), et DKIM signe les octets qui partent réellement sur le fil.

  • auto-whitelist vient après encrypt. Elle note avec signature_required un destinataire pour lequel le message a réellement été chiffré, et c’est encrypt qui le dit (state.encrypted) ; placée plus tôt, aucune ligne ne le porterait jamais. Elle ne fait qu’insérer des lignes de liste blanche, si bien que le contenu produit par encrypt reste ce que dkim-sign signe. Un destinataire qu”encrypt envoie vers le portail des liens sécurisés ou fait rebondir part par cette autre voie et n’est pas noté.

  • srs et la destination de relais qui la suit sont inconditionnelles sur la branche de réception. Les destinataires que la remise locale n’a pas consommés ne sont pas des erreurs — un alias qui se déploie vers l’extérieur, un ~/.forward chez un autre fournisseur, ou (sans aucune remise locale configurée) tout le chemin de relais pur. Ils partent en redirection, ce pour quoi l’expéditeur d’enveloppe est d’abord réécrit par SRS.

5.3.2. Pipeline : inbound

Sans chemin de soumission, il n’y a rien sur quoi brancher : l’étape if disparaît et ARC devient elle-même l’étape d’entrée. La branche de réception est par ailleurs identique à celle ci-dessus, moins les questions qui n’ont jamais été posées : pas de encrypt, pas de auto-whitelist, pas de wallet ni de edit-settings.

Internet ──▶ pepsi-ingress :25
                │
                ▼
                init                 pepsi-stage-arc (the entry stage)
                │
                ▼
                decrypt              CRYPTO
                │
                ▼
                detect-language      LANGUAGE_BLOCKING
                                     or I18N_BOUNCES
                │
                ▼
                block-language       LANGUAGE_BLOCKING
                │
                ▼
                milter-*             MILTER_* (one per filter found)
                │
                ▼
                check-whitelist      ANTI_SPAM or SECRETARY
                │
                ▼
                secretary            SECRETARY
                │
                ▼
                anti-spam            ANTI_SPAM
                │
                ▼
                autocrypt-learn      AUTOCRYPT_LEARN
                │
                ▼
                list ──▶ list-post   MAILING_LISTS
                │        list-command
                │        list-bounce
                ▼
                aliases              ALIASES_ENABLED
                │
                ▼
                vacation             VACATION
                │
                ▼
                route ──▶ exchange   EXCHANGE  (our own domains)
                │
                ▼
                dot-forward          DOT_FORWARD
                │
                ▼
                reencrypt            REENCRYPT (before local delivery)
                │
                ▼
                local                LOCAL_METHODS (maildir)
                │
                ▼
                local-lmtp           LOCAL_METHODS (lmtp; the two
                                     methods run in the order chosen)
                │
                ▼
                srs                  (always)
                │
                ▼
                dkim-sign-relay      SIGN_RELAYED
                │
                ▼
                smarthost            SMARTHOST_HOST
                or internet          (otherwise)

dkim-sign et internet sont tout de même écrites bien qu’aucune soumission ne les atteigne : elles forment la queue que descend chaque rebond (voir La queue commune et les rebonds), et internet est aussi la destination de relais lorsqu’aucun smarthost n’a été configuré.

5.3.3. Pipeline : outbound

Seule la branche de soumission est construite. L’étape if est tout de même émise, car pepsi-ingress positionne toujours state.local_origin et un message qui ne le porte pas doit aller quelque part — mais sur un hôte de soumission seule un tel message ne peut normalement pas survenir : cette branche tombe donc directement dans la queue de signature plutôt que dans une chaîne entrante qui n’existe pas.

your users ──▶ pepsi-ingress :465 / :587
               (and the local sendmail socket, always served)
                 │
                 ▼
               init                  pepsi-stage-if on
                 │                   state.local_origin
        ┌────────┴────────┐
  false │                 │ true
        │                 ▼
        │                 wallet        WALLET_SELF_SERVICE
        │                 │
        │                 ▼
        │                 encrypt       CRYPTO
        │                 │
        └────────┬────────┘
                 ▼
               dkim-sign               (always)
                 │
                 ▼
               internet                (always)

Remarquez ce qui n’est pas là. auto-whitelist est absente bien qu’elle soit une étape sortante : elle n’est proposée que comme le côté écriture d’une liste blanche de correspondants dont le côté lecture (check-whitelist) réside sur le chemin entrant, et la question qui l’activerait est posée à l’intérieur de l’étape anti-spam, réservée à l’entrant. edit-settings est absente aussi, et EDIT_SETTINGS n’est pas posée : chaque étape qu’un titulaire de compte peut modifier est une étape entrante, de sorte que sur cet hôte sa liste d’autorisation serait vide (voir EDIT_SETTINGS ci-dessous). Il n’y a pas d’étapes milter-*, car le scan des milters comme la reprise des milters importés relèvent de l’étape de remise locale, réservée à l’entrant. Un hôte purement sortant n’a pas non plus de srs : SRS réécrit l’expéditeur du courrier que nous redirigeons, et cet hôte ne redirige rien.

5.3.4. La queue commune et les rebonds

dkim-sign ──▶ internet est écrit dans toutes les directions, car c’est ce que descend chaque rebond généré. Les étapes de rebond elles-mêmes sont émises par fonctionnalité susceptible d’en produire un :

bounce             (always)           ─┐
bounce-language    LANGUAGE_BLOCKING   ├──▶ dkim-sign ──▶ internet
bounce-payment     ANTI_SPAM          ─┘

discard-rejected   any milter stage     (drops it; never bounces)

Quelle étape achemine vers laquelle est fixé par la même passe de rendu : block-language rebondit vers bounce-language et anti-spam vers bounce-payment ; l’étape Maildir, dot-forward et toute étape de relais rebondissent vers le simple bounce. L’étape Maildir y pointe en outre UNKNOWN_MAILBOX_STAGE — un destinataire sur l’un de nos domaines qui n’a pas de boîte aux lettres doit être refusé, non relayé, sinon la résolution DNS trouverait notre propre MX et nous réexpédierait le message — et les deux méthodes locales y pointent également QUOTA_LIMIT_STAGE, afin qu’un site qui définit un quota plus tard n’ait pas en plus à découvrir ce cas limite. L’étape LMTP n’a aucun BOUNCE_STAGE (elle ne construit jamais de DSN elle-même, elle achemine ce que le MDA a refusé) : ce sont donc ses QUOTA_LIMIT_STAGE et SIEVE_REJECT_STAGE qui pointent vers bounce.

discard-rejected fait exception. Un verdict de milter arrive après que Pepsi a accepté le message : « rejeter » ne peut donc pas signifier un 5xx dans la session SMTP, et rebondir enverrait du backscatter à quiconque un expéditeur falsifié a nommé. Le courrier rejeté par un filtre que le scan de l’hôte a trouvé est donc supprimé, le verdict restant noté dans state.milter et dans le journal. Pointer le REJECT_STAGE d’un filtre vers bounce est une modification d’un mot si vous voulez que les expéditeurs soient prévenus. Un filtre repris d’un import de MTA garde REJECT_STAGE = bounce, puisque prévenir l’expéditeur est précisément le comportement repris.

5.4. Les questions

Ci-dessous, toutes les questions que le questionnaire du terminal peut poser, dans l’ordre où il les pose, avec la clé [pepsi-wizard] sous laquelle la réponse est mémorisée. Une étape n’est montrée que lorsque la direction (et, pour une étape, la présence d’un Dovecot local) la rend applicable ; la bannière Step X/Y ne compte que les étapes qui seront réellement posées.

5.4.1. Étape : Identité du serveur

Posée dans toutes les directions.

HOSTNAME — Nom d’hôte du serveur de messagerie (nom MX / EHLO)

L’identité de l”hôte, par opposition aux domaines qu’il sert : le domaine de scellement ARC, chaque SERVER_NAME de relais et de rebond, et le sujet du certificat TLS de repli. La valeur par défaut vient du DNS inverse, pas de /etc/hostname, car les serveurs destinataires comparent le nom EHLO au PTR de l’adresse qui se connecte et rejettent en cas de désaccord. Si la valeur par défaut proposée contredit le PTR, l’assistant nomme les deux et dit pourquoi avant de poser la question.

DOMAINS — Domaine(s) pour lesquels nous acceptons le courrier (séparés par des espaces)

Devient [pepsi-ingress] ACCEPTED_DOMAINS, et par là le LOCAL_DOMAINS par défaut des étapes de remise locale, l’ensemble des hôtes de politique mta-sts.* et les domaines routés vers Exchange. Le premier est le domaine principal : les adresses de rapports TLS, les adresses de commande des étapes en libre-service et le SIGNING_DOMAIN de l’étape de signature des messages transférés en découlent tous, et c’est la valeur proposée par défaut pour SRS_DOMAIN.

POSTMASTER — Adresse du postmaster

Nommée par les étapes de rebond et le relais direct vers le MX.

PUBLIC_IPS — Adresse(s) IP publique(s) d’émission pour SPF

Détectées automatiquement et proposées pour confirmation, à partir des enregistrements A/AAAA du nom d’hôte réunis aux adresses d’interface globalement routables de cet hôte (et, sur un hôte en NAT sans IPv4 publique, l’adresse WAN que rapporte la passerelle UPnP locale). Seules des adresses publiques sont pré-remplies : elles atterrissent telles quelles dans l’enregistrement SPF, si bien qu’une adresse privée y ferait échouer SPF partout pour votre propre courrier sortant. La réponse d’une exécution précédente est revérifiée plutôt que tenue pour acquise, car un hôte a pu être déplacé depuis qu’elle a été écrite.

DB_CONFIG — Chaîne de connexion PostgreSQL

Forme libpq ; la valeur par défaut postgres:///pepsi utilise l’authentification par pair (peer) sur la socket locale, ce qu’attendent les comptes de service empaquetés. Une chaîne contenant un mot de passe est refusée à l’invite, car elle aboutirait dans [pepsi-postgres] CONFIG, lisible par tous. Pour une base de données distante, donnez à chaque rôle son propre certificat client ou fichier de mots de passe au moyen de l’espace réservé {role}, par exemple postgres://db.example.org/pepsi?sslmode=verify-full&passfile=/etc/pepsi/postgres/{role}.pgpass (voir CONFIG dans pepsi.conf(5)).

5.4.2. Étape : Système de messagerie existant

Posée sur le chemin entrant uniquement, et posée avant la remise locale car la réponse décide s’il y a seulement une question de remise locale.

EXCHANGE — Y a-t-il un système de messagerie Exchange / Microsoft 365 existant derrière cet hôte

Non par défaut. Répondre oui fait de cet hôte une passerelle transparente devant Exchange : il devient le MX, Exchange garde les boîtes aux lettres. Cela insère l’étape route et un relais exchange dédié dans la branche de réception (voir Pipeline : both), et cela supprime entièrement les questions de remise locale — proposer d’écrire des boîtes aux lettres pour des domaines qui appartiennent à Exchange produirait une configuration où un destinataire est servi deux fois ou pas du tout. Les destinataires qui n’appartiennent pas à Exchange (un alias qui se déploie vers l’extérieur, une redirection) partent toujours par la queue de relais. Voir Microsoft Exchange comme passerelle.

EXCHANGE_HOST — Hôte Exchange (point de terminaison du locataire, ou le serveur sur site)

Le point de terminaison propre au locataire, pas le MX public de votre domaine. Ce MX est cet hôte, et y repointer Exchange fait boucler chaque message.

EXCHANGE_PORT — Port SMTP d’Exchange

25 par défaut.

EXCHANGE_ADDRESS_FAMILY — Famille d’adresses IP par laquelle joindre Exchange

any (par défaut), ipv4 ou ipv6. Exchange Online refuse le courrier venant d’une adresse IPv6 d’émission dépourvue d’enregistrement PTR : épingler ce seul saut suivant à IPv4 est donc une réponse courante et légitime ; les autres destinations ne sont pas affectées.

5.4.3. Étape : Remise locale

Chemin entrant uniquement, et les questions Maildir/LMTP sont sautées lorsqu’on a répondu oui à Exchange.

Maildir — Remettre le courrier des comptes système locaux dans leur Maildir

Ajoute local à la branche de réception. Nécessite l’étape SGID et le helper setuid que provisionne make install (groupe pepsi-maildir).

DOT_FORWARD — Honorer les fichiers ~/.forward de chaque utilisateur pour les comptes Maildir

Non par défaut ; proposée uniquement aux côtés de Maildir, puisque ce sont les répertoires personnels des comptes système eux-mêmes qui sont lus. Ajoute dot-forward immédiatement avant la remise locale, de sorte qu’un destinataire ayant un ~/.forward est dévié avant l’écriture dans la boîte aux lettres. La section générée redirige vers des adresses uniquement ; ALLOW_PIPE et ALLOW_FILE sont laissées désactivées, car chacune exécuterait une commande ou écrirait un fichier sous l’identité de l’utilisateur cible.

LMTP — Remettre le courrier localement via LMTP à un MDA (Dovecot, qui exécute Sieve)

Ajoute local-lmtp. Pepsi n’implémente pas Sieve lui-même ; ceci confie le message à un MDA qui le fait. Lorsqu’un Dovecot local est détecté, la question de suivi porte seulement sur le chemin de sa socket LMTP (LMTP_SOCKET) ; sinon une cible TCP distante est collectée — LMTP_HOST, LMTP_PORT, LMTP_TLS, LMTP_AUTH et, là où le mécanisme les exige, LMTP_USERNAME et LMTP_PASSWORD. Pepsi ne configure pas Dovecot : si les sockets sur lesquelles il s’appuiera sont absentes, un 10-pepsi.conf suggéré est affiché à la fin de l’exécution.

Ordre — Les deux méthodes locales sont activées — laquelle est essayée en premier ?

Posée uniquement lorsque les deux ont été activées. Les méthodes sont chaînées dans l’ordre donné, chacune remettant ce qu’elle peut et redirigeant le reste vers la suivante ; ce qui reste à la dernière part vers la queue de relais. Stockée dans LOCAL_METHODS.

ALIASES_ENABLED — Activer les alias / listes de diffusion (développer les destinataires via un fichier de correspondance)

Non par défaut. Ajoute aliases après les barrières anti-spam et juste avant l’acheminement et la remise, de sorte que les barrières voient l’adresse à laquelle l’expéditeur a écrit tandis que l’ensemble développé est acheminé par destinataire. Le fichier de correspondance est créé à côté de pepsi.conf et relu automatiquement lorsque sa date de modification change.

MAILING_LISTS – Héberger des listes de diffusion sur ce serveur (un remplacement de GNU Mailman 3)

Non par défaut. Ajoute le routeur de listes au pipeline — sur les deux branches, afin qu’un utilisateur local écrivant à une liste hébergée ici atteigne la liste au lieu d’être relayé vers son propre MX et de revenir comme courrier étranger — ainsi que les quatre étapes derrière lui : l’envoi (chaîne de modération, pipeline de gestionnaires, éclatement par membre), l’interface de commandes par e-mail, la remise par membre avec le désabonnement en un clic, et le traitement des rejets. Il écrit aussi [pepsi-list], dont le UNSUBSCRIBE_SECRET est produit une fois, stocké dans secrets.d/pepsi-list.secret plutôt que dans pepsi.conf, et conservé d’une exécution à l’autre — le faire tourner invaliderait chaque URI de désabonnement déjà remise.

L’activer configure la machinerie ; les listes elles-mêmes sont créées ensuite avec pepsi-list. Un serveur qui n’en héberge aucune paie une vérification d’enveloppe par message. C’est distinct de ALIASES_ENABLED, qui ne fait que réécrire des destinataires. Voir Listes de diffusion.

MILTERS_ENABLED — Reporter les milters dans le pipeline

Posée uniquement lorsqu’un import de MTA en a trouvé. L’invite avertit du changement de moment : Pepsi exécute les filtres après avoir accepté le message, si bien qu’un filtre qui rejetait dans la session SMTP sous l’ancien MTA produit ici un rebond (c’est pourquoi les filtres détectés sont plutôt câblés vers discard-rejected — voir La queue commune et les rebonds).

MILTER_GREYLIST, MILTER_REGEX, MILTER_CLAMAV, MILTER_SPAMASSASSIN, MILTER_RSPAMD, MILTER_MIMEDEFANG, MILTER_AMAVIS

Une question oui/non par démon de filtrage qu’un balayage de cet hôte a trouvé installé et répondant. Chaque filtre accepté devient une étape milter-*, placée selon ce qu’il fait — la politique d’abord, puis le virus, puis le spam, puis les cadres généralistes — les filtres importés dont l’objet est inconnu gardant l’ordre relatif dans lequel leur ancien MTA les exécutait. Tous sont à oui par défaut sauf MILTER_GREYLIST : le greylisting fonctionne en refusant la remise dans la session et en pariant qu’un moteur de spam ne réessaiera pas, or après la mise en file il n’y a rien à refuser et c’est Pepsi lui-même qui réessaie, si bien que le pari est toujours gagné et qu’il ne reste que le délai. Les filtres dont Pepsi assure déjà la fonction (opendkim, openarc, opendmarc, les démons de politique SPF, les outils de réécriture SRS) sont reconnus et signalés comme supplantés plutôt que proposés. Voir pepsi-stage-milter.

ALIAS_STYLE — Qualifier les noms d’alias importés

Uniquement lorsqu’une migration a fourni des noms d’alias nus tels que postmaster ou root, que les clés de Pepsi ne peuvent pas utiliser puisqu’elles portent un domaine : per-domain (une entrée par domaine servi), wildcard (un unique joker @) ou primary.

VACATION — Répondre au courrier des destinataires absents (réponses d’absence du bureau)

Non par défaut. Ajoute vacation après l’expansion d’alias et après les barrières anti-spam, de sorte qu’un avis n’est jamais envoyé au nom d’un alias ni en réponse à du courrier que les barrières auraient refusé. L’activer ne répond à personne : les dates d’absence sont une configuration ordinaire par adresse, définie ensuite avec pepsi-settings, à la portée du domaine avec pepsi-config pour un congé commun, ou par les utilisateurs eux-mêmes par e-mail. Sur un hôte sans remise locale, la section générée pose également VACATION_TAG = none, car marquer le sujet réécrit un en-tête que couvrent à la fois la signature DKIM de l’auteur et notre propre sceau ARC — sans conséquence lorsque le courrier s’arrête ici, visible au saut suivant lorsqu’il est relayé plus loin.

Smarthost — Relayer également vers un smarthost les destinataires que la remise locale ne traite pas

Facultatif lorsque la remise locale ou Exchange traite vos domaines, auquel cas il ne sert que ce qu’aucun des deux n’a traité ; obligatoire, et non demandé, lorsque ni l’un ni l’autre ne le fait, puisqu’un relais pur doit avoir un endroit où envoyer. Répondre oui collecte SMARTHOST_HOST, SMARTHOST_PORT, SMARTHOST_MODE (starttls / tls / plain), SMARTHOST_AUTH (none / plain / login) et, en cas d’authentification, SMARTHOST_USERNAME et SMARTHOST_PASSWORD. Les identifiants sont vérifiés sur-le-champ auprès du vrai relais : un refus propose de nouveau le mot de passe, tandis qu’un relais injoignable ne dit rien du mot de passe et ne vous pousse pas à ressaisir un mot de passe qui fonctionne.

5.4.4. Étape : Authentification des soumissions

Posée uniquement sur le chemin sortant, et uniquement lorsqu’un Dovecot est installé sur cet hôte.

DOVECOT_SASL — Authentifier les soumissions auprès de la socket SASL locale de Dovecot

Oui par défaut. Impose AUTH obligatoire auprès d’une socket SASL Dovecot propre à Pepsi (/run/dovecot/auth-client-pepsi) sur les listeners 465 et 587, de sorte que les comptes de messagerie et les comptes IMAP sont les mêmes comptes. Refuser laisse dans les listeners un renvoi en commentaire vers les solutions de rechange (Dovecot SASL configuré à la main, ou certificats client TLS).

5.4.5. Étape : Confiance à la boucle locale

Posée uniquement lorsque l’hôte dessert les deux directions, et c’est une question plus étroite qu’il n’y paraît : la réponse devient MYNETWORKS sur le listener MX du port 25, que seul un hôte entrant possède, et elle ne vaut d’être posée qu’à un hôte qui soumet également du courrier.

TRUST_LOOPBACK — Faire confiance aux connexions en boucle locale sur le port 25

Non par défaut, et cette valeur par défaut est la bonne réponse pour presque tout le monde. L’assistant ne demande pas si les programmes locaux peuvent soumettre du courrier — ils le peuvent toujours : pepsi-ingress sert inconditionnellement la socket UNIX qu’utilise /usr/sbin/sendmail, et le noyau lui indique quel compte l’a ouverte, si bien qu’un appelant ne peut jamais envoyer qu”en son propre nom. Cette question ne porte que sur le mécanisme supplémentaire, plus faible, consistant à faire confiance à une adresse — une entrée MYNETWORKS pour 127.0.0.0/8 ::1/128 sur le listener du port 25 — qui authentifie une position réseau plutôt qu’un utilisateur : tout processus local, y compris une application web compromise, peut alors envoyer au nom de n’importe qui. C’est aussi ce qui permet à un message que cet hôte se relaie à lui-même de rentrer comme une nouvelle soumission et de boucler. Ne répondez oui que pour un logiciel qui exige de parler SMTP à 127.0.0.1 et qu’on ne peut pas orienter vers la socket.

5.4.6. Étape : Courrier redirigé

Chemin entrant uniquement.

SIGN_RELAYED — Signer en DKIM le courrier que cet hôte redirige, au nom du domaine propre à cet hôte

Oui par défaut. Le courrier que cet hôte ne fait que rediriger — un alias qui se déploie vers l’extérieur, un ~/.forward chez un autre fournisseur, tout le chemin de relais pur — part par la branche de réception, que le dkim-sign sortant ne touche jamais ; sans cela il arrive au saut suivant avec notre enveloppe SRS mais un dkim=none de notre part. Répondre oui insère une seconde étape de signature, dkim-sign-relay, entre srs et la destination, avec SIGNING_DOMAIN épinglé au domaine servi primaire. La signature est fail-closed et le domaine de l’auteur appartient à quelqu’un d’autre : un domaine de signature dérivé d’un From: étranger ferait échouer chaque message redirigé faute de clé.

SRS_DOMAIN – Domaine sous lequel placer le chemin de retour du courrier transféré

Par défaut le domaine principal servi. Devient [pepsi-srs] SRS_DOMAIN. Le courrier transféré part avec son expéditeur d’enveloppe réécrit en SRS0=…@SRS_DOMAIN pour que la vérification SPF du saut suivant passe, ce qui fait de cette adresse un chemin de retour : chaque rejet de courrier transféré lui est adressé. Le domaine doit donc recevoir du courrier sur cette machine, et le domaine principal le fait déjà – ses enregistrements MX, SPF et DMARC existent et il n’y a rien de plus à publier.

Un sous-domaine dédié comme srs.<primary> fonctionne aussi et garde le trafic de rejets du courrier transféré hors de la réputation du domaine principal, mais il lui faut un enregistrement MX propre. Cet enregistrement est la seule chose que pepsi-setup ne peut pas vous suggérer — où le courrier d’un domaine est routé est votre décision et non la sienne —, aussi l’assistant affiche-t-il l’enregistrement à publier lorsque la réponse n’est pas un domaine accepté ici, et pepsi-setup(1) avertit à chaque exécution tant qu’il n’existe pas. Sans ces deux rappels, un domaine se retrouve avec des enregistrements SPF et DMARC corrects, aucun MX, et chaque rejet de courrier transféré silencieusement perdu.

Une nouvelle exécution ne déplace jamais d’elle-même un SRS_DOMAIN existant : les expéditeurs réécrits restent vérifiables pendant MAX_AGE_DAYS (21 jours par défaut), le changer laisserait donc en plan chaque rejet encore en vol. Lorsque [pepsi-wizard] n’en enregistre pas, la valeur déjà présente dans [pepsi-srs] est proposée par défaut.

5.4.7. Étape : Sécurité du transport

Toujours posée ; la première question seulement sur le chemin entrant.

MTA_STS — Servir une politique MTA-STS en HTTPS

Oui par défaut. Pose [pepsi] MTA_STS_MODE = enforce et émet pepsi-httpd avec une section de certificat mta-sts.<domain> par domaine accepté, provisionnée par pepsi-setup comme toute autre. Vous devez pointer le DNS de chaque nom mta-sts.<domain> vers cet hôte pour que la politique soit joignable. Les hôtes que la politique autorise ne sont pas demandés : ils sont lus dans les enregistrements MX réels des domaines servis et écrits sous [pepsi] MTA_STS_MX, ou omis (la politique nomme alors HOSTNAME) lorsqu’aucun enregistrement MX n’existe encore.

TLS_REPORTS — Envoyer et annoncer les rapports TLS SMTP (TLSRPT, RFC 8460)

Oui par défaut ; émet [pepsi-tlsrpt]. S’applique à tout hôte qui envoie, la question est donc posée dans toutes les directions. Ajoutez l’entrée cron quotidienne pepsi-tlsrpt report que l’assistant vous rappelle.

Refuser MTA-STS écrit tout de même les sections pepsi-httpd : HTTPS sur le port 443 (avec le certificat de l’hôte) et la socket UNIX de la console d’administration. pepsi.target démarre le serveur HTTP sur chaque hôte, et sans listener il échouerait et redémarrerait indéfiniment.

SHARE_TELEMETRY — Partager avec le projet Pepsi une télémétrie anonyme d’usage des fonctionnalités

Non par défaut, et c’est sur consentement explicite au sens strict : un opérateur qui traverse tout le questionnaire en appuyant sur Entrée ne partage rien. La question explique ce qui serait envoyé avant de la poser. Oui fait frapper à pepsi-setup run un SYSTEM_ID aléatoire de 256 bits et arme le démon pepsi-telemetry-client, qui rapporte périodiquement quelles fonctionnalités ce déploiement a exercées et à quelle fréquence, sous cet identifiant — aucune adresse, donnée de message, nom d’hôte ni adresse IP. Non signifie qu’aucun identifiant n’est généré et que rien n’est envoyé, et relancer l’assistant pour répondre non notifie un démon en cours d’exécution, qui devient aussitôt dormant (en abandonnant ce qu’il n’avait pas envoyé) plutôt que d’attendre qu’il s’en aperçoive. Le démon lui-même reste en marche si l’opérateur l’a démarré : dormant, il ne soumet rien, et c’est lui qui permet à la console du navigateur de proposer cet interrupteur (voir pepsi-telemetry-client).

5.4.8. Étape : Filtrage de contenu

Chemin entrant uniquement.

LANGUAGE_BLOCKING — Rejeter le courrier selon la langue humaine détectée

Non par défaut. Ajoute detect-language et block-language.

I18N_BOUNCES — Localiser les messages de rebond dans la langue de l’expéditeur

Posée uniquement lorsque le blocage est désactivé, puisque le blocage implique déjà la détection. Ajoute detect-language seule, qui annote state.language et ne refuse rien.

DETECT_LANGUAGES — Langues que le détecteur doit reconnaître

Posée lorsque l’une ou l’autre des questions ci-dessus a activé la détection, après affichage de la liste complète des codes ISO 639-1 pris en charge. * (la valeur par défaut) désigne toute langue que le détecteur prend en charge ; en nommer moins coûte moins de mémoire par worker. Un code non pris en charge est rejeté à l’invite. Seule une langue détectée peut ensuite être autorisée ou bloquée, d’où la place de cette question avant la politique.

LANG_POLICY — Politique de langue (+autoriser / -bloquer, p. ex. “+en +fr -“)*

Une seule réponse combinée, scindée en WHITELIST et BLACKLIST de l’étape. Un unique joker -* ou +* couvre toute autre langue détectée : +en +fr -* n’autorise donc que l’anglais et le français ; le littéral none peut être listé pour décider du sort du courrier dont aucune langue n’a pu être détectée.

LANG_THRESHOLD — Seuil de score (le courrier doit obtenir un score strictement supérieur)

-0.1 par défaut.

LANG_ENFORCEMENT — Appliquer la politique de langue strictement ou faiblement

hard (par défaut) refuse le courrier que la politique recale, en l’acheminant vers bounce-language. soft marque à la place exactement le même courrier — un indicateur [!LANG] dans le sujet et un en-tête X-Pepsi-Detected-Languages — ce qui permet d’ajuster les listes et le seuil sur du trafic réel sans que le courrier de quiconque soit jeté entre-temps. L’étape de rebond est écrite sous soft également, de sorte que basculer plus tard est une modification d’un mot.

5.4.9. Étape : Paywall anti-spam

Chemin entrant uniquement.

SECRETARY — Demander aux expéditeurs inconnus de confirmer par une réponse avant que leur courrier soit remis (confirmation à l’envoi)

Non par défaut. Posée en premier dans cette étape. Ajoute check-whitelist et secretary à la branche de réception et, lorsqu’il existe aussi un chemin sortant, auto-whitelist à celle de soumission, toutes trois sur la liste blanche correspondents : le courrier de quiconque n’est ni en liste blanche ni confirmé est retenu, et son expéditeur est prié de répondre une fois (voir pepsi-stage-secretary). Le [stage-secretary] généré n’a pas de BOUNCE_STAGE (un message expiré est supprimé : un défi resté sans réponse signifie en général un expéditeur falsifié), et son UNCHALLENGEABLE_STAGE provient des autres défenses anti-spam de la même exécution, la première correspondance l’emportant : le paywall lorsque ANTI_SPAM est activé (le courrier auquel on ne peut pas demander de répondre est prié de payer, et secretary s’exécute alors avant anti-spam) ; sinon le propre NEXT_STAGE du secrétaire lorsqu’un milter anti-spam ou de framework a été accepté, parce que ce filtre s’est déjà exécuté avant check-whitelist ; sinon il reste non défini, ce qui est le chemin d’expiration. Un commentaire au-dessus de la section nomme ce sur quoi repose ce choix ; Filtres anti-spam et secrétaire décrit l’autre placement possible des filtres. Inscrire l’étape dans la liste d’autorisation d”EDIT_SETTINGS permet aux utilisateurs de définir leur propre texte de défi et leur PENALTY.

ANTI_SPAM — Activer le paywall anti-spam GNU Taler (péage à l’envoi)

Non par défaut. Ajoute deux étapes à la branche de réception — check-whitelist et anti-spam — et, lorsqu’il existe aussi un chemin sortant, auto-whitelist à celle de soumission. Les trois ne forment qu’une fonctionnalité : l’étape sortante note tous ceux à qui vous écrivez, l’entrante reconnaît leurs réponses, et seul ce dont ni l’une ni l’autre ne s’est portée garante rencontre la barrière de paiement. Elle émet aussi l’étape bounce-payment et donne à pepsi-httpd un jeton de webhook /resume.

MERCHANT_BACKEND_URL — URL du backend marchand Taler

Posée en premier et vérifiée sur-le-champ, car son /config indique les monnaies dans lesquelles le prix peut être libellé — le backend doit donc être connu avant que le prix puisse être validé.

MERCHANT_ACCESS_TOKEN — Jeton d’accès marchand (“secret-token:…”) ou mot de passe de l’instance

L’un ou l’autre est accepté : un jeton d’accès tout fait est vérifié auprès du backend, un mot de passe d’instance est échangé contre un jeton d’accès à portée restreinte.

PAYMENT_AMOUNT — Prix par message (montants Taler séparés par des espaces)

Chaque montant devient un choix dans le bon de commande généré : EUR:1 CHF:1 KUDOS:10 laisse donc le payeur choisir une monnaie. Validé au regard des monnaies annoncées par le backend.

PAYMENT_DEADLINE — Combien de temps retenir un message en attente de paiement

48 h par défaut. Heures, minutes et secondes uniquement — l’analyseur de durée n’accepte pas les unités calendaires.

LEARN_WHITELIST — Apprendre une liste blanche de correspondants à partir de votre courrier sortant

Posée à la place des précédentes lorsque le paywall et SECRETARY sont tous deux refusés (l’un ou l’autre l’active de toute façon), et uniquement lorsqu’il existe aussi un chemin sortant. Elle ajoute auto-whitelist seule : les correspondants sont notés, et rien ne consomme encore le verdict. C’est une chose raisonnable à activer tôt, puisqu’une liste blanche n’est utile qu’une fois qu’elle contient un peu d’historique.

5.4.10. Étape : Libre-service des comptes

Chemin sortant uniquement, et EDIT_SETTINGS seulement sur un hôte servant les deux directions. Les deux sont à non par défaut, et toutes deux sont des étapes qui laissent passer le courrier ordinaire sans le toucher — elles n’agissent que sur un message qu’un compte local a envoyé à leur propre adresse de contrôle.

EDIT_SETTINGS — Permettre aux titulaires de comptes de modifier eux-mêmes leurs paramètres par e-mail

Ajoute edit-settings. Un message adressé à pepsi@<domain> depuis un compte local modifie les redéfinitions pepsi.settings propres à cette adresse, restreintes à une liste d’étapes autorisées que l’assistant dérive des barrières entrantes que vous avez réellement activées — les étapes de liste blanche, de blocage par langue, de secrétaire, de péage et de congés, toutes entrantes, ce qui explique qu’un hôte purement sortant ne soit pas interrogé. Lorsqu’aucune d’entre elles n’est dans le pipeline, cette liste est vide, et répondre oui n’émet aucune étape, seulement un commentaire disant pourquoi : un EDITABLE_STAGES vide est une adresse de contrôle qui ne peut rien changer. Voir pepsi-stage-edit-settings.

WALLET_SELF_SERVICE — Permettre aux titulaires de comptes d’utiliser leur wallet GNU Taler par e-mail

Ajoute wallet. Un message adressé à pepsi-wallet@<domain> avec une commande dans le Subject opère le wallet propre à l’expéditeur : solde, rechargement, paiements pair-à-pair. Voir pepsi-stage-auto-pay.

5.4.11. Étape : Cryptographie de bout en bout

Toujours posée — le chiffrement sert ce que vos utilisateurs envoient et le déchiffrement ce qui leur arrive, et un déploiement qui fait l’un sans l’autre est assez rare pour ne pas valoir deux questions. Les moitiés réellement émises suivent toujours la direction.

CRYPTO — Chiffrer et déchiffrer le courrier de bout en bout (OpenPGP / S/MIME)

Non par défaut. Sur le chemin entrant, elle ajoute decrypt en premier, de sorte que tout ce qui est en aval voit le texte clair ; sur le chemin sortant, elle ajoute encrypt en dernier avant la signature, de sorte que DKIM couvre ce qui part réellement sur le fil. Rien n’est chiffré tant que la clé d’un destinataire n’est pas connue — les clés viennent de la découverte (WKD, DANE, VKS, LDAP), de pepsi-keys, ou du courrier que vos correspondants vous envoient. Le magasin de clés, le démon de découverte et la clé de chiffrement de clés sont provisionnés par le reste de la configuration initiale dans les deux cas ; cette réponse décide seulement si les étapes sont dans le pipeline. Voir Gestion des clés.

AUTOCRYPT_LEARN — Apprendre les clés des correspondants à partir du courrier qu’ils nous envoient

Oui par défaut, posée uniquement lorsque CRYPTO est activé et qu’il existe un chemin entrant — sans étape de déchiffrement il n’y a pas de texte clair d’où lire le gossip, et sans étape de chiffrement rien ne dépenserait jamais une clé apprise. Ajoute autocrypt-learn après toute étape capable de former une opinion sur le spam et avant tout ce qui répond ou remet, ce qui est exactement l’exigence d’Autocrypt niveau 1 : un message tenu pour du spam n’enseigne rien, et une clé apprise après la remise l’est trop tard pour chiffrer la réponse avec. Les clés apprises occupent les échelons les plus bas de l’échelle de confiance — une telle clé ne peut jamais déplacer une clé issue de la découverte, et une signature vérifiée contre elle n’est jamais rapportée comme vérifiée.

REENCRYPT — Rechiffrer le courrier déchiffré vers la propre clé de client de messagerie de l’utilisateur avant de le déposer

Oui par défaut, posée uniquement lorsque CRYPTO est activé et qu’il existe un chemin entrant, et émise uniquement devant une méthode de remise locale. Ajoute reencrypt immédiatement avant la première étape de remise locale — après toutes les étapes qui lisent le contenu ou peuvent en faire suivre une copie — de sorte qu’un message que la passerelle a ouvert avec la clé MTA d’un utilisateur est déposé scellé avec la clé MUA que cet utilisateur a enregistrée. Les utilisateurs sans clé MUA reçoivent toujours le texte en clair ; la section est écrite avec BOUNCE_STAGE = bounce afin que ON_NO_CLIENT_KEY = bounce, défini pour tout le site ou par utilisateur avec pepsi-settings, puisse refuser à la place. Voir pepsi-stage-reencrypt.

PEP – Chiffrement automatique à la manière de pEp : donner une clé à chaque expéditeur et l’envoyer avec le message (ENABLE_PEP)

Oui par défaut, posée uniquement lorsque CRYPTO est activé et qu’il existe un chemin sortant. Chaque expéditeur d’un domaine servi reçoit une clé OpenPGP à son premier message, annoncée dans un en-tête Autocrypt: ; le courrier est chiffré chaque fois que la clé d’un destinataire est connue ou découvrable, et signé à l’intérieur du chiffrement (le courrier en clair part non signé). Un utilisateur qui enregistre sa propre clé la conserve, et rien n’est téléversé vers un serveur de clés sauf si son propriétaire le demande.

La question est posée explicitement, son coût étant énoncé au préalable : la création de clés devient anticipée – toute personne qui envoie du courrier reçoit une clé, qu’elle utilise ou non le chiffrement, servie par le Web Key Directory du déploiement, et chacune de ces clés privées se trouve dans la base de données, enveloppée sous la clé de chiffrement de clés, de sorte qu’une compromission de cette clé les exposerait toutes. Non ne crée de clés que pour un utilisateur qui demande une protection. La réponse est écrite dans les deux cas, ENABLE_PEP = yes ou ENABLE_PEP = no, dans [stage-encrypt] de pepsi.conf – où elle prend effet, puisqu’aucun fichier config.d ne la définit – plutôt que laissée à la valeur par défaut de l’étape. L’étape de chiffrement reçoit aussi RESPONSE_STAGE = dkim-sign pour ses avis et ses réponses aux commandes de clés par e-mail. Voir « Clés automatiques à la manière de pEp » dans Gestion des clés.

ATTACH_KEYS_AS_FILES – Joindre aussi la clé publique de l’expéditeur sous forme de fichier

Non par défaut, posée uniquement lorsque PEP est activé. La manière classique d’OpenPGP, pour les correspondants dont le client ne lit pas les en-têtes Autocrypt ; le fichier est joint jusqu’à ce que le correspondant ait montré qu’il détient la clé (il a envoyé une réponse chiffrée et signée). Écrit sous la forme ATTACH_KEYS_AS_FILES = yes uniquement lorsqu’il est choisi.

5.4.12. Étape : Options expertes

Affichée uniquement lorsque --expert en a nommé. Ce sont de véritables options Pepsi sur lesquelles le questionnaire ne porte pas d’ordinaire — MAX_MESSAGE_SIZE, MYNETWORKS, RECIPIENT_DELIMITER, MAX_LIFETIME, DMARC_ENFORCE, HELO_NAME, TLS_CERT/TLS_KEY, DNS_TIMEOUT, MAX_CONNECTIONS, MAX_OPEN_SOCKETS, DKIM_SELECTOR, KEY_DIR, MAILBOX_QUOTA, MAILBOX_OVER_QUOTA, CRYPTO_ALLOW_DOWNGRADE — dont chacune sait à quelle section elle appartient. Une valeur déjà portée par les valeurs par défaut (d’une exécution précédente, ou d’un import de MTA) est appliquée que --expert la propose ou non ; l’indicateur décide seulement lesquelles reçoivent une invite. Laisser une réponse vide restaure la valeur par défaut propre à Pepsi. Voir pepsi-setup(1).

5.5. Ce que l’assistant ne demande pas

Certaines choses sont volontairement absentes du questionnaire :

  • La socket de soumission locale. pepsi-ingress la sert inconditionnellement, en dérivant le chemin de [pepsi-sendmail] SOCKET : aucune section de listener n’est donc écrite et rien ne peut être en désaccord avec quoi que ce soit d’autre.

  • SRS. La réécriture est branchée automatiquement partout où du courrier peut être transféré, avec un secret HMAC produit pour l’occasion. Le seul choix est le domaine sous lequel vit le chemin de retour réécrit (SRS_DOMAIN, ci-dessus) ; le branchement n’en est pas un.

  • La manière dont les listeners s’attachent. Un hôte qui exécute systemd (détecté par /run/systemd/system) reçoit des listeners activés par socket (SERVE = systemd, un FD_INDEX par listener) ; tout autre reçoit des attachements directs. La numérotation d’ingress est fixée pour correspondre au pepsi-ingress.socket livré, qui liste les trois ports sur chaque hôte : FD_INDEX 0 est le port 25, 1 le 465 et 2 le 587, quelle que soit la direction que sert l’hôte. Un hôte purement sortant écrit donc 1 et 2 pour ses listeners de soumission, et un hôte purement entrant 0 pour son MX. Avec l’activation par socket, vous devez installer les unités .socket correspondantes dont l’ordre des ListenStream= s’aligne sur les valeurs FD_INDEX — l’assistant affiche un rappel, et pepsi-ingress avertit au démarrage de tout descripteur qu’aucune section n’a revendiqué (les ports qu’un hôte à direction unique ne sert pas).

  • Clés, certificats, schéma et DNS. Tout cela relève de pepsi-setup run, sur lequel l’assistant propose d’enchaîner. Les certificats TLS sont provisionnés via certbot ; un certificat qui ne peut pas être obtenu est reporté plutôt que d’interrompre l’exécution, de sorte que le schéma, les clés et la sortie DNS ont tout de même lieu.

5.6. Le relancer

Le questionnaire note chaque réponse non secrète dans une section [pepsi-wizard] à la fin du fichier qu’il écrit, et une exécution --wizard ultérieure les importe comme valeurs par défaut — relancer pour changer une seule chose revient donc à descendre jusqu’à cette question en appuyant sur Entrée. Les secrets sont traités séparément et n’y sont jamais écrits : un secret généré (la clé SRS, le jeton /resume, le UNSUBSCRIBE_SECRET des listes de diffusion) est relu et conservé, car renouveler la clé SRS invaliderait tout expéditeur réécrit encore en vol ; un secret saisi (un mot de passe de smarthost ou de LMTP, le jeton du marchand) est reproposé à sa propre invite sous la forme ***, si bien qu’appuyer sur Entrée le conserve sans qu’il soit jamais affiché ni ressaisi.

Deux formes non interactives existent pour le même questionnaire. --answers FILE fournit les réponses par clé depuis un fichier JSON, en court-circuitant toutes les invites (une question sans réponse prend sa valeur par défaut ; une clé inconnue, une réponse malformée ou une réponse obligatoire sans valeur par défaut est un échec net plutôt qu’une invite que personne n’est là pour voir), et c’est ainsi qu’une configuration peut être reproduite d’un hôte à l’autre. --import nomme explicitement un MTA d’où migrer, au lieu d’en détecter un. Les deux sont documentées dans pepsi-setup(1).