1. Introduction¶

1.1. Ce qu’est Pepsi¶

Pepsi est un agent de transfert de courrier (MTA) : il reçoit le courrier sur son propre serveur SMTP, l’authentifie, puis soit le remet dans une boîte aux lettres locale, soit le réexpédie vers les véritables destinations. Il est construit comme une série de petits programmes d’étape à usage unique, enchaînés autour d’une unique table de base de données partagée, de sorte que chaque étape de traitement — scellement ARC, réécriture SRS, signature DKIM, génération de rebonds, remise — est un programme indépendant qui peut être réordonné, remplacé ou étendu.

Lequel de ces deux rôles un déploiement emploie est une question de configuration. Pointez la fin du pipeline vers une étape de relais et Pepsi est un redirecteur placé devant un autre système de messagerie ; pointez-la vers une étape de remise locale et Pepsi est la destination finale. Les deux sont des configurations ordinaires, et un même déploiement fait couramment les deux, en choisissant par destinataire.

C’est aussi une passerelle cryptographique de bout en bout. Le même pipeline qui répare l’authentification peut signer et chiffrer le courrier sortant au nom de son auteur, et déchiffrer et vérifier le courrier entrant pour les destinataires que cet hôte sert, en OpenPGP ou en S/MIME — faisant sur le serveur ce qui exigerait sinon un greffon dans le client de messagerie de chaque utilisateur. Tout ce qui rend cela praticable fait partie du système : un magasin de clés, la découverte et la publication automatiques des clés, et un portail web pour le cas courant d’un correspondant qui n’a aucune clé. Voir Le problème du chiffrement ci-dessous.

Pepsi est écrit en Rust, organisé sous forme d’un espace de travail Cargo et distribué sous licence GNU Affero General Public License v3.0 ou ultérieure. Il réutilise les mécanismes de configuration, de CLI et de base de données des bibliothèques Rust GNU Taler intégrées.

1.2. Le problème de la redirection¶

Lorsqu’un MTA de bordure redirige du courrier, il l’envoie depuis ses adresses IP sous le domaine d’enveloppe de l’expéditeur original. Cela casse deux des trois grands mécanismes d’authentification :

SPF échoue, car l’enregistrement SPF du domaine original ne liste pas les adresses IP du redirecteur.
L’alignement DKIM est souvent rompu, car les logiciels de listes de diffusion et les redirecteurs modifient le message.

Un redirecteur naïf transforme donc du courrier légitime en courrier que le destinataire final juge falsifié. Pepsi traite ce problème sur deux fronts :

Il enregistre le verdict à la bordure — en vérifiant SPF/DKIM/DMARC à l’arrivée et en scellant le résultat dans une chaîne ARC (RFC 8617) — afin que le destinataire final puisse faire confiance à ce que Pepsi a constaté, même si la redirection a cassé les signaux d’origine.
Il répare l’enveloppe avec SRS (Sender Rewriting Scheme) pour que SPF réussisse au saut suivant, et re-signe en DKIM le courrier sortant sous un domaine que Pepsi contrôle.

1.3. Le problème du chiffrement¶

Le chiffrement de bout en bout du courrier existe depuis trente ans et reste à peine employé. La raison n’est pas la cryptographie, c’est que chaque participant doit installer, configurer et entretenir quelque chose — et qu’un correspondant qui ne l’a pas fait retransforme tout l’échange en texte clair.

Pepsi déplace le travail vers le serveur :

pepsi-stage-encrypt signe un message soumis localement avec la clé de l’auteur du From: et le chiffre pour chaque destinataire, en OpenPGP (PGP/MIME) ou S/MIME (CMS). Chaque destinataire chiffré reçoit son propre texte chiffré sur sa propre ligne de file, de sorte qu’il n’y a aucune divulgation de la liste des destinataires et qu’une fuite de Bcc est structurellement impossible.
pepsi-stage-decrypt est la moitié entrante : elle ouvre le texte chiffré arrivé, vérifie la signature qu’il porte, consigne un verdict délibérément précis, et retire tout indicateur de sécurité que l’expéditeur aurait falsifié. L’utilisateur lit du courrier ordinaire dans son client habituel.
Les clés viennent d’un magasin de clés rempli par une couche de découverte asynchrone — WKD, DANE (OPENPGPKEY/SMIMEA), le protocole de serveur de clés VKS, LDAP, et la moisson depuis le courrier entrant — chaque source étant classée selon ce que vaut sa provenance. Les clés de nos propres utilisateurs sont publiées par les mêmes voies. Gestion des clés est le chapitre consacré à tout cela.
Lorsqu’un correspondant ne publie aucune clé, le choix n’est pas seulement « texte clair ou rebond » : le portail Le portail de repli par lien sécurisé stocke le message chiffré sous un code PIN fraîchement engendré et envoie un lien au destinataire. Un message stocké ne peut pas être lu depuis la base de données ou une sauvegarde sans le code PIN — mais le serveur a manipulé le texte clair lors de la soumission du message, de sorte que cela protège contre un lecteur passif des données stockées, non contre l’opérateur.

Parce que la passerelle siège à la bordure plutôt que dans le client, elle fonctionne pour des utilisateurs qui n’installent rien, et elle peut être placée devant un système de courrier existant qui n’aura jamais ces fonctionnalités de lui-même — voir Microsoft Exchange comme passerelle. Ce qu’elle ne peut pas être, c’est du bout en bout au sens strict : le serveur voit le texte clair, c’est le compromis consenti, et Gestion des clés le dit sans détour.

1.4. La structure du système¶

Chaque composant partage une même base de données PostgreSQL (l’unique schéma pepsi) et un même fichier de configuration de style INI ; ils ne sont utiles qu’ensemble.

pepsi-ingress est le serveur SMTP entrant (MTA). Il accepte un message, l’authentifie, le stocke sous forme d’une ligne dans la table pepsi.workqueue et notifie le pipeline.
pepsi-dispatch est l’unique coordinateur. Il revendique les lignes nouvellement mises en file et transmet chacune à un processus worker persistant de l’étape de la ligne ; une étape qui en a fini avec un message fait elle-même passer la ligne à l’étape suivante, et le dispatcher l’y revendique à son tour suivant.
Les programmes pepsi-stage-* sont les étapes : ARC, SRS, signature DKIM, chiffrement et déchiffrement, génération de rebonds, expansion d’alias, acheminement par destinataire, filtres de politique (liste blanche, péage à l’envoi, confirmation à l’envoi, langue, milters après mise en file et paramètres par adresse), le répondeur d’absence, les étapes de listes de diffusion, deux étapes de relais externe, les étapes de remise locale (Maildir, LMTP, ~/.forward) et un puits de test. Chacune s’exécute comme un worker persistant (PROGRAM worker, lisant des identifiants de message sur l’entrée standard).
pepsi-keydisc est le service asynchrone de découverte de clés — une instance par méthode — auquel les étapes cryptographiques confient une consultation au lieu d’effectuer leurs propres entrées-sorties réseau, et pepsi-keys est l’interface en ligne de commande de l’opérateur pour le magasin de clés.
pepsi-httpd est le serveur HTTP/HTTPS : il sert le fichier de politique MTA-STS, les points de terminaison Web Key Directory qui publient les clés de nos utilisateurs, le portail Le portail de repli par lien sécurisé, et — sur les listeners explicitement marqués pour cela — une page Prometheus /metrics, l”L’API d’administration et le La console d’administration de navigateur.
pepsi-setup provisionne le schéma, les clés et le DNS ; pepsi-queue inspecte et répare la file d’attente.

Un message est une machine à états sur une table unique : sa colonne stage nomme la section de configuration du programme qui en est actuellement responsable, et sa colonne status indique si cette étape est pending, running, paused, failed ou timeout. Le modèle complet est décrit dans Architecture.

1.5. Fonctionnalités¶

Redirection préservant l’authentification. SPF, DKIM et DMARC sont vérifiés à l’arrivée et le verdict est scellé dans une chaîne ARC (RFC 8617).
Réparation de l’enveloppe. SRS réécrit l’expéditeur d’enveloppe pour que SPF réussisse au saut suivant, et le courrier sortant est re-signé en DKIM sous un domaine que Pepsi contrôle.
Chiffrement et signature de bout en bout, effectués par le serveur. pepsi-stage-encrypt chiffre le courrier sortant par destinataire en OpenPGP (PGP/MIME, RFC 3156) ou en S/MIME (CMS, RFC 8551), signé avec la clé de l’auteur du From: ; par défaut (ENABLE_PEP), chaque expéditeur local d’un domaine servi obtient automatiquement une clé. pepsi-stage-decrypt ouvre et vérifie le texte chiffré entrant et note le verdict. Aucun greffon client n’est nécessaire. Voir Gestion des clés.
Découverte et publication automatiques des clés. La clé d’un correspondant est trouvée par WKD, DANE (OPENPGPKEY/SMIMEA), le protocole de serveur de clés VKS, LDAP et la moisson depuis le courrier entrant, chaque source étant classée selon ce que vaut sa provenance ; les clés de nos propres utilisateurs sont publiées par WKD, par le DNS et — uniquement sur demande — par un serveur de clés.
Un portail à lien sécurisé pour les correspondants sans clé. Le portail de repli par lien sécurisé stocke le message chiffré sous un PIN fraîchement engendré et envoie un lien au destinataire, au lieu de choisir entre le texte clair et un rebond.
Listes de diffusion. Une réimplémentation de GNU Mailman 3 — modération, résumés, traitement des rebonds, une archive, et l’API REST propre à Mailman, de sorte que Postorius et HyperKitty fonctionnent avec elle — construite sous forme d’étapes de pipeline. Voir Listes de diffusion.
Une API d’administration et une console de navigateur. L”L’API d’administration expose la file d’attente, l’état de santé, le magasin de clés, les journaux et la configuration sous /api/v1, et la console La console d’administration est un client de cette même surface documentée — servie uniquement sur les listeners explicitement marqués pour l’administration.
Un pipeline d’étapes à usage unique. ARC, SRS, signature DKIM, expansion d’alias, liste blanche, détection de langue, une barrière anti-spam de péage à l’envoi, un défi de confirmation à l’envoi, la génération de rebonds, l’acheminement par destinataire et plusieurs dorsales de remise — chacune un programme pepsi-stage-* indépendant, câblé aux autres par la configuration.
Sécurité de transport moderne. STARTTLS et TLS implicite, MTA-STS, DANE/TLSA (RFC 7672) et rapports TLS sortants (RFC 8460).
Un SMTP complet du point de vue des normes. DATA et CHUNKING/BDAT, 8BITMIME et SMTPUTF8 avec rétrogradation par saut, prise en charge complète des DSN (RFC 3461), et la soumission de messages de la RFC 6409 avec authentification SASL.
Plusieurs dorsales de remise. Remise directe au MX, relais par un smarthost authentifié (nombreux mécanismes SASL, OAuth et TLS mutuel), ou remise locale — dans le Maildir d’un utilisateur, à travers un ~/.forward par utilisateur, ou par LMTP vers un MDA tel que Dovecot (qui exécute alors le script Sieve du destinataire).
Une file adossée à une base de données. Un seul schéma PostgreSQL est à la fois la file, la machine à états et la surface d’audit ; les opérateurs l’inspectent et le réparent avec du SQL ordinaire et les outils en ligne de commande fournis.
Extensible dans n’importe quel langage. Une étape n’est qu’un programme qui lit des identifiants de message sur l’entrée standard ; les nouvelles étapes n’ont pas à être écrites en Rust.

Danger

Pepsi est un logiciel hautement expérimental, immature et non pris en charge. Sa première version, 0.0.0, n’est pas une version stable, et il n’a pas été audité en vue d’un usage en production. Il n’y a ni garantie ni support. Ne placez pas Pepsi sur le chemin d’un courrier que vous ne pouvez pas vous permettre de perdre, et ne comptez pas sur lui pour quoi que ce soit d’important. Servez-vous-en pour apprendre, expérimenter et contribuer — non pour faire tourner une infrastructure critique.

Ce qui est promis, à partir de 0.0.0 : une version ultérieure met à niveau sur place la base de données d’une version antérieure, sans perdre la file d’attente ni rien d’autre de ce qu’elle contient (voir Mise à niveau). Les options de configuration, les options de ligne de commande et l’API d’administration peuvent encore changer d’une version à l’autre ; chaque changement est listé dans NEWS.

1.6. Pepsi comparé à d’autres conceptions de MTA¶

Pepsi est un point d’un espace de conception exploré de longue date. Le comparer aux systèmes de messagerie libres les plus connus — Postfix, qmail, sendmail, Exim et le plus récent tout-en-un Stalwart — montre les compromis que fait Pepsi. Chaque conception achète certaines propriétés au prix d’autres.

1.6.1. Des points dans l’espace de conception¶

Postfix est un MTA multi-processus. Un démon master supervise un ensemble fixe de démons spécialisés, pour la plupart de longue durée — smtpd pour recevoir, cleanup pour canonicaliser, qmgr pour ordonnancer, et des démons de transport tels que smtp et local pour remettre — qui coopèrent par des répertoires de file sur disque et un petit ensemble de protocoles de communication entre processus. C’est un MTA généraliste : remise locale, domaines virtuels, acheminement complexe, filtrage de contenu et relais sont tous des citoyens de première classe.

qmail pousse la modularité et le cloisonnement à l’extrême : une multitude de tout petits programmes, dont plusieurs tournent sous leur propre compte utilisateur dédié, chacun faisant un petit travail et communiquant par le système de fichiers et de simples tubes. La conception prise la sécurité par le moindre privilège et la simplicité, et une file de type Maildir qui évite les pièges du verrouillage de fichiers. Son cœur est pour l’essentiel figé depuis longtemps : les fonctionnalités modernes (TLS, SMTP AUTH, DKIM) arrivent donc par des correctifs et des enveloppes tiers plutôt que par la distribution de base.

sendmail est le MTA originel de l’Internet et l’archétype de la conception monolithique et infiniment configurable : un seul démon fait le travail, piloté par le fameux et abscons sendmail.cf (normalement engendré depuis des macros m4). Sa longévité est sans égale et il a introduit le protocole de greffons milter que Postfix et d’autres ont adopté ensuite, mais la complexité de sa configuration et son historique en matière de sécurité ont poussé la plupart des nouveaux déploiements vers d’autres conceptions.

Exim est un unique binaire monolithique dont le comportement est régi par un langage de configuration à l’exécution exceptionnellement expressif — expansions de chaînes et ACL évaluées à chaque phase SMTP. Les décisions d’acheminement et de politique n’ont besoin d’aucun programme helper externe, au prix d’une configuration facile à rendre subtilement fausse. C’est le MTA par défaut de Debian, avec une base installée vaste et mûre.

Stalwart est un serveur de courrier tout-en-un moderne écrit, comme Pepsi, en Rust. Contrairement à tous les systèmes ci-dessus, ce n’est pas seulement un agent de transfert : il regroupe l’accès IMAP4, JMAP et POP3, le stockage des messages et un filtrage de spam intégré aux côtés d’un serveur SMTP complet avec SPF/DKIM/DMARC/ARC natifs, MTA-STS et DANE. Il incarne une voie moderne différente de celle de Pepsi — un serveur intégré qui fait tout plutôt qu”une chaîne de petits programmes.

Pepsi conserve la philosophie des petits programmes mais remplace la file du système de fichiers par une unique table PostgreSQL qui est simultanément la file, la machine à états par message et le journal d’audit d’exploitation. Un unique coordinateur dispatch pilote des pools de programmes worker d”étape persistants, faisant avancer chaque message d’une étape à la suivante en mettant à jour sa ligne. L’authentification à l’époque de SPF/DKIM/DMARC fait partie de ce flux central plutôt que d’y être greffée. C’est comme passerelle cryptographique de bout en bout qu’il diffère le plus des autres : il signe, chiffre, déchiffre et vérifie OpenPGP et S/MIME sur le serveur, gère et découvre les clés nécessaires pour cela, et propose un portail de navigateur pour les correspondants qui n’ont aucune clé.

1.6.2. En un coup d’œil¶

Le tableau ci-dessous résume les points de divergence de ces conceptions. Les cases sont lapidaires — « intégré » face à « par extensions » masque énormément de nuances — mais elles montrent l’allure générale de chaque système : à la fois les capacités que Pepsi n’a pas et les deux ou trois qu’il a et que les autres n’ont pas.

Note

Seule la colonne Pepsi a été vérifiée contre cet arbre des sources. Les cinq autres colonnes résument la documentation propre de ces projets au moment de la rédaction ; elles sont offertes pour l’orientation, non comme un audit, et un projet ayant ajouté une fonctionnalité depuis sera sous-estimé ici.

Dimension	Postfix	qmail	sendmail	Exim	Stalwart	Pepsi
Langage	C	C	C	C	Rust	Rust
Modèle de processus	Ensemble de démons (maître + helpers)	Une multitude de petits programmes	Démon monolithique	Binaire unique, dupliqué par tâche	Un unique serveur asynchrone	Dispatcher + chaîne de programmes d’étape
Rôle principal	MTA généraliste	MTA généraliste	MTA généraliste	MTA généraliste	Serveur tout-en-un (MTA + IMAP/JMAP + stockage)	MTA + passerelle cryptographique ; redirection ou remise locale selon le destinataire
Configuration	`main.cf`/`master.cf` + cartes	Fichiers de contrôle + conventions du système de fichiers	`sendmail.cf` engendré par m4 (abscons)	Une configuration d’exécution : ACL + expansion de chaînes	TOML + administration web	Un fichier INI + base de données
File / dépôt d’état	Répertoires de spool sur disque	File de type Maildir	File sur disque	Spool sur disque + base d’indices	Dépôt embarqué / SQL	Table PostgreSQL (interrogeable en SQL)
Maturité	Des décennies ; très largement déployé	Des décennies ; cœur figé, écosystème de correctifs	Le plus ancien (années 1980) ; éprouvé mais en déclin	Des décennies ; défaut de Debian	Jeune ; mûrit vite	Expérimental ; première version 0.0.0
Performance	Élevée, bien réglée	Élevée, légère	Moyenne	Élevée	Élevée (Rust asynchrone)	Modeste ; limitée par la coordination et la base
Facilité d’installation	Facile ; empaqueté partout	Difficile ; compilation + correctifs	Difficile ; configuration abstruse	Paquet facile, configuration complexe	Facile ; binaire unique + configuration initiale	Moyenne ; exige PostgreSQL + `pepsi-setup`
TLS / MTA-STS / DANE	TLS, DANE ; MTA-STS par extension	Par correctifs	TLS ; STS/DANE par extensions	TLS, DANE ; MTA-STS par extension	TLS, MTA-STS, DANE intégrés	TLS, MTA-STS, DANE, TLSRPT intégrés
API d’extension / de filtrage	Milter + délégation de politique	Tubes / `QMAILQUEUE`	Milter (créateur)	Routeurs/transports + local-scan + tubes	Sieve + webhooks	Insérer un programme d’étape (entrée standard/base), n’importe quel langage ; client milter (après mise en file)

1.6.3. Fonctionnalités de MTA que Pepsi n’a pas¶

Postfix, Exim et sendmail couvrent un terrain que Pepsi ne couvre pas :

Formats de stockage des boîtes aux lettres. La remise locale propre à Pepsi n’écrit que dans Maildir/new ; il n’y a pas d’écrivain mbox. Il applique en revanche bel et bien des quotas de boîte aux lettres (voir pepsi-quota), au format maildirsize de Maildir++ que Dovecot, Courier et Exim lisent aussi, éventuellement adossé à la comptabilité quotactl(2) du noyau — et un refus pour dépassement de quota émis par un MDA joint en LMTP est toujours acheminé plutôt qu’empêché, puisque là c’est au MDA de tenir les comptes de la boîte.
Sieve, procmail et le reste de l’écosystème du filtrage par l’utilisateur. Pepsi n’implémente aucun moteur Sieve à lui. Il remet le message à un Mail Delivery Agent en LMTP — pepsi-stage-relay-to-lmtp, parlant généralement à Dovecot — qui exécute le script Sieve du destinataire au moment de classer le courrier. Un déploiement de Pepsi peut donc offrir Sieve ; le filtrage appartient au MDA, non à Pepsi. Il n’y a pas d’équivalent de procmail, même si les fichiers ~/.forward par utilisateur sont pris en charge par pepsi-stage-dot-forward, y compris les directives classiques |program et /file — chacune derrière son propre interrupteur ALLOW_PIPE / ALLOW_FILE, exécutée sous l’identité de l’utilisateur par un helper privilégié qui s’abaisse d’abord à lui. La seule action de filtrage par l’utilisateur que Pepsi implémente lui-même est le répondeur d’absence (pepsi-stage-vacation), parce qu’elle doit être une décision de pipeline : la réponse est un nouveau message qui doit être signé et relayé, et qui ne doit pas partir vers une liste de diffusion, un rebond ou un spammeur — un savoir que le pipeline possède et qu’un MDA n’a pas.
Acheminement et réécriture d’adresses arbitraires. Il n’y a pas de tables de transport, pas de tables canonical/relocated/rewrite ni de tables de relais par destinataire, et pas de rôle de MX de secours ou de file secondaire pour d’autres domaines. L’acheminement est un choix entre des étapes configurées — pepsi-stage-route en choisit une par destinataire d’après le domaine de celui-ci, ce qui suffit pour se placer devant un système de courrier existant — plutôt qu’une topologie arbitraire, et la réécriture se limite à SRS plus la carte d’alias.
Une interface de filtrage avant mise en file. Pepsi parle le protocole milter — pepsi-stage-milter est un client milter, de sorte qu’opendkim, rspamd, clamav-milter et les autres peuvent être employés sans modification — mais il les exécute après la mise en file, une fois que l’ingress a déjà accepté le message. Le REJECT d’un filtre produit donc un rebond là où un MTA aurait répondu 5xx à l’intérieur de la session SMTP. Il n’y a pas de socket de délégation de politique, et le point d’extension natif reste l’insertion d’un programme d’étape dans le pipeline.
Analyse de contenu intégrée. Au-delà des barrières facultatives de péage à l’envoi et de confirmation à l’envoi et des étapes de langue et de liste blanche, il n’y a pas d’analyse antivirale ou anti-spam intégrée, pas de greylisting, pas de vérification DNSBL/RBL ni de filtrage par réputation — on y accède en pointant pepsi-stage-milter vers le démon de filtrage correspondant.

1.6.4. Fonctionnalités qui résident habituellement hors du MTA¶

Plusieurs capacités ne font pas partie de ce qu’un MTA doit faire, et la plupart des systèmes de messagerie y accèdent par autre chose : un milter, un démon d’extension, l’agent de remise de courrier, ou le client de l’utilisateur lui-même. C’est là que Pepsi diffère le plus des conceptions traditionnelles. La mise en garde ci-dessus vaut aussi pour ce tableau.

Capacité	Postfix	qmail	sendmail	Exim	Stalwart	Pepsi
SPF/DKIM/DMARC/ARC/SRS	Par milters / extensions	Correctifs tiers	Par milters	DKIM intégré ; le reste par ACL/extensions	Intégré (tout)	Cœur intégré (vérification + sceau ARC + SRS)
Protection contre le spam	Milters, RBL/DNSBL, greylisting, politiques	Extensions (qmail-scanner, …)	Milters (SpamAssassin, …)	ACL, RBL/DNSBL, greylisting, analyse de contenu	Filtre anti-spam intégré, DNSBL, greylisting	Barrière de péage à l’envoi, confirmation à l’envoi, liste blanche, filtre de langue ; milters (après mise en file) pour RBL/antivirus/greylisting
Filtrage par l’utilisateur (Sieve)	Le MDA (Dovecot)	Le MDA (maildrop, procmail)	Le MDA (procmail)	Son propre langage de filtrage, ou le MDA	Sieve intégré	Le MDA en LMTP ; `~/.forward` et une étape d’absence s’exécutent dans le pipeline
Accès aux boîtes aux lettres (IMAP/POP)	Non (à associer à Dovecot)	Non (à associer à un serveur POP/IMAP)	Non (à associer à Dovecot)	Non (à associer à Dovecot)	Oui (IMAP4 + JMAP + POP3)	Non (à associer à Dovecot ; passage de relais LMTP intégré)
Chiffrement du courrier de bout en bout	Non (côté client, ou une passerelle distincte)	Non	Non	Non	Partiel (chiffrement au repos sous la clé propre de l’utilisateur)	OpenPGP et S/MIME côté serveur : signer + chiffrer en sortie, déchiffrer + vérifier en entrée ; portail à lien sécurisé pour un destinataire sans clé
Gestion des clés des correspondants	Non (clés TLS et DKIM seulement)	Non	Non	Non	Clés de ses propres utilisateurs, pour le chiffrement au repos	Magasin de clés + découverte (WKD, DANE, VKS, LDAP, moisson) + publication (WKD, `OPENPGPKEY`/`SMIMEA`, serveur de clés)
API d’administration / console web	Non (fichiers + `postfix`/`postqueue`)	Non	Non	Non (fichiers + utilitaires `exim`)	Oui (API REST + administration web)	Oui (`/api/v1` + une console de navigateur, listeners marqués admin uniquement)

Les listes de diffusion sont une autre capacité de ce genre, normalement un gestionnaire de listes séparé (GNU Mailman, ezmlm, Sympa) relié au MTA par des tables d’alias. Celui de Pepsi est une réimplémentation de GNU Mailman 3 qui s’exécute sous forme d’étapes de pipeline, achemine les adresses des listes à l’intérieur de son propre pipeline sans fichier d’alias à régénérer, et sert l’API REST de Mailman afin que Postorius et HyperKitty le pilotent sans modification ; voir Listes de diffusion.

L’appariement avec un MDA est direct. pepsi-stage-relay-to-lmtp remet les messages en LMTP (RFC 2033), qui est la façon dont Dovecot s’attend à les recevoir et ce qui lui permet d’exécuter le script Sieve de chaque destinataire en classant le courrier. pepsi-setup détecte un Dovecot local pendant le questionnaire et propose d’écrire la configuration de socket dont il a besoin, et pepsi-stage-relay-to-maildir écrit le Maildir directement pour un site qui préférerait que Dovecot se contente de lire le spool.

1.6.5. File et état : fichiers face à une base de données¶

Une file fondée sur des fichiers (Postfix, qmail, sendmail, Exim) n’a aucune dépendance externe, est bien comprise, et passe à l’échelle avec le système de fichiers ; chaque message est une unité indépendante, ce qui rend les modes de défaillance locaux et simples. En revanche, inspecter la file entière ou en rendre compte suppose de parcourir des fichiers, et les opérations portant sur plusieurs messages ne sont pas transactionnelles.
Une file adossée à une base de données (Pepsi) rend toute la file interrogeable en SQL, donne des changements d’état transactionnels sur plusieurs lignes (scinder un message par destinataire, éclater des rebonds) et rend l’outillage d’exploitation et les métriques simples. Le prix est une dépendance dure envers PostgreSQL, un composant partagé dont la disponibilité et les caractéristiques de montée en charge bornent désormais tout le système, plutôt que l’isolation par message qu’offre un répertoire de fichiers.

1.6.6. Modèle de processus : monolithe, ensemble de démons, ou chaîne de programmes¶

qmail et Pepsi privilégient une multitude de petits programmes : chacun est facile à auditer isolément, les fautes sont contenues, et les composants peuvent tourner à des niveaux de privilège différents. Le prix, c’est davantage de communication entre processus, davantage de processus à ordonnancer, et la logique de coordination qui les relie (les conventions du système de fichiers de qmail ; le dispatcher et la table partagée de Pepsi).
Postfix occupe une voie médiane : un ensemble fixe et soigneusement conçu de démons coopérants, plutôt qu’un monolithe unique ou une chaîne ouverte. Cela combine de bonnes performances avec un cloisonnement fort, au prix d’une conception fixe plutôt que librement recomposable.
La chaîne de Pepsi est recomposable par configuration : les étapes peuvent être réordonnées et de nouvelles insérées sans recompiler, et une étape peut être écrite dans n’importe quel langage puisque la surface d’intégration n’est que l’entrée standard et la table partagée. Le revers, c’est que le pipeline lui-même est le contrat d’intégration — le protocole milter est parlé en tant que client (après mise en file seulement) plutôt qu’offert comme surface native de greffons, et il n’y a pas d’interface de délégation de politique.

1.6.7. Périmètre et maturité¶

Périmètre. Postfix, qmail, sendmail et Exim peuvent faire tourner tout le système de messagerie d’un site, et Stalwart va plus loin encore en regroupant l’accès aux boîtes aux lettres. Pepsi en fait moins sur cet axe — la liste ci-dessus dit ce qui manque — et plus sur un axe que les autres n’ont guère : la cryptographie de bout en bout, la gestion de clés qui la rend utilisable, et la surface d’administration pour exploiter les deux. Exploiter Pepsi devant un système de messagerie existant est donc un déploiement courant, et Microsoft Exchange comme passerelle le traite.
Posture d’authentification. L’authentification moderne de la redirection — vérifier SPF/DKIM/DMARC et réaffirmer le résultat via ARC et SRS — est intégrée au flux central de Pepsi. Sous Postfix, sendmail ou qmail, le même résultat s’assemble à partir de milters, de helpers et de correctifs (Exim et Stalwart en apportent davantage en standard) ; c’est souvent plus de câblage, mais cela s’appuie sur des composants mûrs et largement déployés.
Maturité. C’est la différence décisive. Postfix, qmail, sendmail et Exim ont des décennies de durcissement en production, de vastes communautés d’opérateurs et une documentation abondante, et même le bien plus jeune Stalwart a connu de vrais déploiements. Pepsi n’a rien de tout cela (voir l’avertissement ci-dessus) : c’est une conception jeune et expérimentale dont la valeur tient à l’exploration de l’approche base-de-données-comme-file et pipeline-de-programmes, non à une maturité de production.

1.7. Comment lire ce manuel¶

Le manuel s’organise en sept parties, que la table des matières suit dans l’ordre :

Le guide — ce chapitre, Démarrage sur un VPS bon marché, Installation, Paquets Debian, L’assistant, Configuration, Exploiter Pepsi, Dépannage, Fonctionnalités prises en charge et Extensions du protocole SMTP : ce qu’est Pepsi, comment le mettre en marche (à partir des sources ou des paquets Debian, à la main ou via l’entretien de configuration), comment le maintenir en marche (journaux, surveillance, sauvegardes, mises à niveau) et l’ensemble des fonctionnalités au niveau du protocole et des politiques.
Cryptographie de bout en bout — Gestion des clés (identités, garde, découverte et publication des clés), Le portail de repli par lien sécurisé (le portail pour un destinataire sans clé), Interopérabilité des clients (quels clients tiers ont réellement été mesurés face à la sortie de Pepsi), Modèle de sécurité (le modèle de menace contre lequel tout cela est construit) et Microsoft Exchange comme passerelle (exploiter Pepsi comme passerelle cryptographique devant un système de courrier existant).
Listes de diffusion — Listes de diffusion (la réimplémentation de GNU Mailman 3), Archives (l’archive compatible HyperKitty) et L’API REST de GNU Mailman 3 (l’API REST de Mailman qu’utilisent Postorius et HyperKitty).
Administration — l”L’API d’administration et la console de navigateur La console d’administration, qui en est le premier client.
Rouages internes — Architecture (pipeline, base de données et dispatcher), L’état du message (le JSON par message), Étendre le pipeline (comment ajouter votre propre programme), ainsi que Suite de tests, Suite de benchmarks et Performance.
Un chapitre de référence pour chaque programme, suivi du tableau Stabilité des fonctionnalités et des pages de manuel (la référence man 1/man 5/man 7, reproduite intégralement).
Un index des normes que Pepsi implémente — Index des RFC — avec des renvois vers l’endroit où chacune est réalisée.

Par où commencer dépend de ce que vous êtes venu chercher :

Nouveau venu sur Pepsi ? Suivez Démarrage sur un VPS bon marché pour une présentation complète, du DNS au premier e-mail reçu, puis lisez Installation et Configuration pour approfondir et parcourez Fonctionnalités prises en charge pour les normes que Pepsi parle.
Vous exploitez Pepsi ? Lisez Exploiter Pepsi (journaux, surveillance, sauvegarde et restauration), Mise à niveau et Dépannage. Les chapitres par programme listent chaque fonctionnalité et option de chaque binaire, et les pages de manuel de section 1/5 donnent la référence exacte de la ligne de commande.
Chiffrer du courrier ? Lisez d’abord Gestion des clés, puis pepsi-stage-encrypt et pepsi-stage-decrypt ; Le portail de repli par lien sécurisé traite du repli pour un destinataire sans clé, et Interopérabilité des clients consigne quels clients tiers ont réellement été mesurés face à la sortie de Pepsi — et lesquels ne l’ont pas été.
Vous étendez Pepsi ? Architecture et Étendre le pipeline décrivent le contrat d’étape et comment ajouter votre propre programme.
Vous auditez la conformité aux normes ? Index des RFC associe chaque norme — les RFC, ainsi que les Internet-Drafts et les spécifications de fait qui comptent tout autant — à l’endroit où elle est réalisée, et consigne ce qui n’est délibérément pas implémenté. Extensions du protocole SMTP documente les deux champs d’en-tête privés que Pepsi définit pour l’échange entre déploiements, Pepsi-Origin: et Taler:.

1.8. Obtenir de l’aide et signaler des bogues¶

Le site web du projet est https://pepsi.taler.net/, et le code source est publié à l’adresse https://git.taler.net/pepsi.git.

Veuillez signaler les bogues, et proposer des améliorations, dans le gestionnaire de bogues public à l’adresse https://bugs.gnunet.org/view_all_bug_page.php?project_id=35. Un rapport utile indique la version (pepsi-setup --version), la partie pertinente de la configuration (secrets retirés) et ce qu’affichent pepsi-status et les journaux des services.

Une vulnérabilité de sécurité ne doit pas être signalée dans le gestionnaire public : signalez-la en privé par courriel, comme décrit dans Signaler une vulnérabilité.