16. Microsoft Exchange comme passerelle

Pepsi peut se placer devant et derrière un déploiement Microsoft Exchange ou Exchange Online comme passerelle cryptographique transparente : le courrier entrant est déchiffré et vérifié avant qu’Exchange ne le stocke, le courrier sortant est signé et chiffré après qu’Exchange l’a envoyé. Les utilisateurs obtiennent S/MIME et OpenPGP sans toucher à leurs clients.

Avertissement

Rien dans ce chapitre n’a été testé face à un véritable locataire Exchange ou Exchange Online. La suite de tests propre à Pepsi emploie un substitut SMTP simple et des domaines .invalid. Les réglages de connecteur ci-dessous suivent le comportement documenté par Microsoft, mais attendez-vous à devoir les ajuster, et lisez Dépannage avant de conclure que Pepsi est en cause.

16.1. Topologies

Trois agencements sont pris en charge. Celui qui s’applique décide de ce que le reste de ce chapitre vous demande de configurer.

Les deux sens (la passerelle complète). Une instance Pepsi est le MX de l’organisation et le smarthost par lequel Exchange envoie. C’est l’agencement qui donne de la cryptographie de bout en bout dans les deux sens.

Internet ──▶ pepsi-ingress :25 ──▶ arc ──▶ decrypt ──▶ autocrypt-learn
             ──▶ aliases ──▶ route ──┬─▶ exchange (smarthost)
                                     └─▶ internet (direct MX)

Exchange ──▶ pepsi-ingress :587 ──▶ encrypt ──▶ srs ──▶ dkim-sign ──▶ internet
             (authenticated)

pepsi-stage-autocrypt-learn suit decrypt parce qu’elle a besoin du texte en clair : c’est là que les clés des correspondants sont apprises à partir du courrier entrant (leur en-tête Autocrypt:, les clés jointes, les certificats S/MIME, et l”Autocrypt-Gossip: d’un message arrivé chiffré), ce qui donne à l’étape sortante encrypt des clés pour lesquelles chiffrer sans interroger le réseau. Elle enregistre aussi la preuve qu’un correspondant détient l’une de nos clés (il a envoyé du courrier chiffré pour elle et signé par lui) ; cet enregistrement est ce qui empêche ATTACH_KEYS_AS_FILES de joindre notre fichier de clé au courrier qui lui est destiné. Omettez-la et les deux moitiés sont perdues.

Devant seulement. Pepsi est le MX et remet tout à Exchange ; le chemin sortant propre à Exchange est laissé tel quel. Le courrier entrant est déchiffré et vérifié ; le courrier sortant n’est pas touché. Un déploiement réel pour une organisation qui ne peut pas modifier son flux sortant.

Derrière seulement. Exchange conserve le MX ; Pepsi n’est que le smarthost par lequel Exchange relaie. Le courrier sortant est signé et chiffré ; l’entrant n’est pas touché. Convient à une organisation dont l’entrant passe déjà par une passerelle de conformité ou de filtrage.

Les deux cas partiels ne sont pas de seconde classe : l’étape d’acheminement, la prévention des boucles et le contrôle ADDRESS_FAMILY se comportent de la même façon dans chacun. Seule diffère la moitié du pipeline que vous configurez.

16.2. La décision d’acheminement

Une passerelle placée devant un autre système de courrier a une décision d’acheminement à prendre sur chaque message entrant : ce destinataire appartient-il au système derrière moi, ou à l’internet ?

Se tromper n’est pas un échec de remise. Les domaines situés derrière la passerelle sont exactement ceux dont le MX public est la passerelle : en remettre un à un relais direct-vers-MX renvoie donc le message dans l’ingress de Pepsi lui-même, qui l’accepte, le relaie de nouveau vers l’extérieur, et recommence.

pepsi-stage-route existe pour cette décision :

[stage-route]
PROGRAM = pepsi-stage-route
# Recipients at a domain we serve go to Exchange...
MANAGED_STAGE = exchange
# ...everything else out to the public internet.
NEXT_STAGE = internet

MANAGED_DOMAINS vaut par défaut [pepsi-ingress] ACCEPTED_DOMAINS, de sorte que l’ensemble des domaines traités comme « derrière la passerelle » ne puisse pas dériver de l’ensemble qu’accepte l’ingress. N’ajoutez ROUTES que pour des exceptions — un sous-domaine hérité remis localement, un domaine partenaire ayant son propre saut suivant.

Indiquez à Pepsi comment savoir si une adresse existe dans Exchange. pepsi-ingress peut alors refuser une adresse inconnue tant que l’expéditeur est encore connecté, au lieu de l’accepter et de laisser Exchange la faire rebondir plus tard — vers un expéditeur d’enveloppe que le spam falsifie (voir Un expéditeur distant). RECIPIENT_CHECK = probe interroge Exchange avec RCPT TO et sans message. Cela n’aide que là où Exchange refuse lui-même les destinataires inconnus au RCPT : sur site avec le filtrage des destinataires, ou Exchange Online avec le Directory-Based Edge Blocking. Sinon, exportez les adresses valides dans un fichier et utilisez RECIPIENT_CHECK = map :

[stage-route]
PROGRAM = pepsi-stage-route
MANAGED_STAGE = exchange
NEXT_STAGE = internet
RECIPIENT_CHECK = probe
PROBE_HOST = example-com.mail.protection.outlook.com
# or: RECIPIENT_CHECK = map
#     RECIPIENT_MAP = /etc/pepsi/exchange-recipients

Sans l’un ni l’autre, chaque adresse des domaines gérés est acceptée, comme auparavant, et pepsi-setup run le signale.

Dans un déploiement derrière seulement, il n’y a aucune décision d’acheminement à prendre : Pepsi ne relaie que vers l’extérieur, et l’étape d’acheminement n’est pas nécessaire.

16.3. Exchange Online : le point de terminaison du locataire

Important

Pointez le smarthost vers le point de terminaison propre au locataire, jamais vers le MX public de votre propre domaine.

L’enregistrement MX de votre domaine pointe vers Pepsi (c’est tout l’intérêt de la passerelle). Configurer Exchange Online comme example-com.mail.protection.outlook.com atteint Microsoft ; le configurer comme mail.example.com atteint Pepsi, et chaque message boucle.

Le point de terminaison du locataire est affiché dans le centre d’administration Microsoft 365 sous les enregistrements DNS du domaine, et a la forme <tenant>.mail.protection.outlook.com — où <tenant> est normalement votre domaine avec les points remplacés par des tirets (example.com → example-com). Les locataires régionaux peuvent différer (par exemple <tenant>-ch.mail.protection.outlook.com) ; employez ce qu’affiche le centre d’administration, pas une supposition construite.

[pepsi-stage-relay-to-smarthost-mta-exchange]
HOST = example-com.mail.protection.outlook.com
PORT = 25
MODE = starttls
TLS_VERIFY = yes
AUTH = none
DOMAINS = example.com example.net
# Exchange Online rejects a sending IPv6 address with no PTR; see below.
ADDRESS_FAMILY = ipv4

AUTH = none est correct ici : Exchange Online authentifie un connecteur entrant par l”adresse IP émettrice ou par le certificat TLS, pas par SASL. Pepsi emploie tout de même STARTTLS, qu’Exchange Online exige.

pepsi-setup refuse un smarthost dont l’hôte est cette machine et dont le port est un port auquel un listener d’ingress est lié : la forme la plus directe de cette erreur est donc attrapée avant de pouvoir boucler.

16.4. Choix de la famille d’adresses

Exchange Online rejette le courrier venant d’une adresse IPv6 émettrice dont le DNS inverse (PTR) est manquant, avec une erreur 550 5.7.1 ... S820. Un hôte à double pile préfère IPv6 : une machine dont le DNS inverse IPv4 est correct et dont le DNS inverse IPv6 n’a jamais été délégué remet donc parfaitement à tout le monde sauf à Exchange Online.

Le remède est d’atteindre cette destination-là en IPv4. ADDRESS_FAMILY prend any (la valeur par défaut), ipv4 (également écrit v4/v4only) ou ipv6 (v6/v6only).

La précédence est : l’entrée ``[…-mta-*]``, puis la section ``[stage-*]`` propriétaire, puis ``any``. C’est le niveau par entrée qui compte : clouer toute l’étape en IPv4 forcerait aussi toute autre destination en IPv4, y compris une qui ne publie que des AAAA.

Lorsqu’une remise emploie une famille à laquelle vous ne vous attendiez pas, vérifiez d’abord l’entrée MTA, puis la section d’étape, et souvenez-vous que la famille configurée est intersectée avec ce que l’hôte local peut réellement router — clouer ipv6 sur un hôte sans route IPv6 globale ne laisse rien à quoi se connecter.

Le meilleur remède, là où vous contrôlez la zone inverse, est de publier l’enregistrement PTR. ADDRESS_FAMILY est pour le cas où vous ne le faites pas.

16.5. Prévention des boucles

Une passerelle des deux côtés d’un autre MTA est la topologie de boucle classique, et Pepsi dispose de trois défenses indépendantes. Aucune n’est facultative dans ce déploiement.

1. Refus de configuration (``pepsi-setup``). Deux vérifications, toutes deux des erreurs plutôt que des avertissements :

• Une étape d’acheminement depuis laquelle un domaine servi peut atteindre pepsi-stage-relay-to-internet. pepsi-setup parcourt vers l’avant depuis chaque étape qu’un destinataire géré peut atteindre et refuse si un relais direct-vers-MX s’y trouve. (BOUNCE_STAGE n’est pas suivi — un rebond est un nouveau message à expéditeur nul portant sur une remise déjà échouée, et il atteint légitimement un relais.)

• Un smarthost 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 : un site peut légitimement exploiter un relais sans rapport sur le même hôte, ou joindre une autre machine sur le port 25.

2. Le compteur de sauts (``MAX_HOP_COUNT``). Les deux étapes de relais comptent les champs d’en-tête Received: et refusent de relayer un message qui en compte plus de MAX_HOP_COUNT (30 par défaut, RFC 5321 §6.3). C’est le filet de sécurité, pas la défense : quand il se déclenche, trente copies du message ont traversé la passerelle, et le rebond qu’il produit est adressé de nouveau dans la boucle.

3. La restriction propre des connecteurs Exchange. Restreignez le connecteur entrant aux adresses IP de Pepsi (ci-dessous), de sorte qu’un message arrivant d’ailleurs ne soit pas traité comme du trafic de passerelle.

16.6. Configuration des connecteurs Exchange

Les réglages exacts dépendent du fait qu’Exchange envoie à Pepsi, reçoit de Pepsi, ou les deux.

16.6.1. Entrant vers Exchange (Pepsi → Exchange)

Dans Exchange Online, c’est un connecteur entrant (centre d’administration Exchange → Flux de messagerie → Connecteurs → De : le serveur de messagerie de votre organisation, Vers : Office 365) :

Réglage	Valeur
Type de connecteur	Du serveur de messagerie de votre organisation vers Office 365
Comment identifier l’expéditeur	En vérifiant que l’adresse IP du serveur émetteur correspond — listez chaque adresse depuis laquelle Pepsi envoie (voir PUBLIC_IP dans la section [stage-<name>] propre à l’étape de relais ; c’est une option par étape, trouvée par PROGRAM, jamais par une section nommée d’après un programme), ou, de préférence, par le nom de sujet du certificat
Rejeter les messages s’ils ne sont pas envoyés en TLS	Oui

Sur Exchange sur site, l’équivalent est un connecteur de réception sur le rôle Transport Hub / Frontend, avec RemoteIPRanges réglé sur les adresses de Pepsi et PermissionGroups incluant AnonymousUsers (avec Ms-Exch-SMTP-Accept-Any-Recipient accordé si Exchange doit accepter pour des domaines dont il n’est pas autoritaire).

Note

Si le connecteur identifie Pepsi par IP et que Pepsi est cloué en IPv4 pour cette destination (Choix de la famille d’adresses), listez l’adresse IPv4. Ne lister que l’adresse IPv6 d’un hôte qui ne l’utilisera jamais est un échec d’authentification silencieux.

16.6.2. Sortant depuis Exchange (Exchange → Pepsi)

Dans Exchange Online, c’est un connecteur sortant (De : Office 365, Vers : organisation partenaire), avec l’acheminement réglé sur Acheminer le courrier via ces hôtes intelligents nommant le nom d’hôte de Pepsi, et Toujours utiliser Transport Layer Security activé avec validation du certificat contre le nom de Pepsi.

Côté Pepsi, Exchange arrive sur un listener de soumission :

[pepsi-ingress-listener-submission]
SERVE = tcp
BIND_TO = 0.0.0.0
PORT = 587
MODE = starttls
SUBMISSION = yes
SASL_TYPE = dovecot
SASL_PATH = /run/dovecot/auth-client

16.6.3. Authentifier le connecteur

Il y a deux façons de laisser Exchange relayer par Pepsi, et elles ne sont pas équivalentes.

SASL avec un compte dédié (recommandé). Exchange s’authentifie avec un nom d’utilisateur et un mot de passe. Comme un listener de soumission applique la RFC 6409 §6 — un expéditeur ne peut employer qu’une adresse à laquelle l’identité authentifiée a droit —, le compte du connecteur a besoin d’une entrée USERNAME_MAP autorisant les domaines servis, faute de quoi chaque message qu’Exchange relaie est refusé :

# /etc/pepsi/username.map — the connector account may send as any of our users.
exchange-connector:   *@example.com *@example.net

Sans cette entrée, le compte ne peut envoyer qu’en son propre nom, et le premier message qu’Exchange relaie reçoit un 550.

Confiance réseau (``MYNETWORKS``). Plus simple — listez les adresses d’Exchange et sautez l’authentification — mais cela porte le risque d’auto-relais dont traite ce chapitre : tout hôte capable d’atteindre le listener depuis une adresse de confiance peut relayer par lui, et une erreur dans la plage transforme Pepsi en relais ouvert. Préférez SASL ; si vous employez MYNETWORKS, listez des adresses individuelles plutôt que des plages, et n’incluez jamais la boucle locale.

16.7. Le module complémentaire Outlook

L’étape de chiffrement de Pepsi agit sur deux en-têtes qu’un message peut porter : X-Pepsi-Sign et X-Pepsi-Encrypt. Le module complémentaire est ce qui permet à un utilisateur de les poser depuis Outlook.

Activez les routes et rechargez pepsi-httpd :

[pepsi-httpd]
ADDIN = yes
# Only needed when the request's own Host header does not name this gateway
# (for example behind a proxy that rewrites it).
# ADDIN_URL = https://mail.example.com

Le manifeste est alors servi depuis https://<gateway>/addin/manifest.xml, avec l’URL de la passerelle et un identifiant propre au déploiement substitués pour vous.

Le déploiement se fait par chargement latéral. Dans le centre d’administration Microsoft 365, allez dans Paramètres → Applications intégrées → Télécharger des applications personnalisées, choisissez Fournir le lien vers le fichier manifeste, et donnez-lui cette URL. Il n’y a pas de fiche AppSource : le contenu du manifeste dépend de l’URL de votre passerelle, il n’y a donc pas d’artefact unique à publier, et une revue de boutique placée entre vous et un correctif est un mauvais marché pour une page de JavaScript.

Les utilisateurs sans le module complémentaire obtiennent le même effet avec un mot-clé de sujet — [sign], [encrypt] ou [secure] n’importe où dans le Subject. L’étape de chiffrement agit dessus et le retire avant l’envoi du message, de sorte que le destinataire ne le voie jamais. Les mots-clés sont configurables (SUBJECT_KEYWORDS_SIGN, SUBJECT_KEYWORDS_ENCRYPT, SUBJECT_KEYWORDS_BOTH).

Note

Un mot-clé de sujet signifie exigé, non essayer : un message qu’un utilisateur a délibérément marqué [encrypt] n’est pas envoyé en clair si un destinataire n’a pas de clé. Ce qui se passe à la place relève d”ON_NO_KEY.

16.8. Le contrat des en-têtes X-Pepsi-*

Trois champs dans un seul espace de noms, plus la règle qui rend le champ de résultat crédible.

Champ	Signification
X-Pepsi-Sign	Requête : signer ce message. no/yes/required.
X-Pepsi-Encrypt	Requête : chiffrer ce message. no/yes/required.
X-Pepsi-Crypto	Résultat : ce que l’étape entrante a trouvé. Paires key=value séparées par des points-virgules.

Les requêtes ne sont honorées que pour le courrier soumis localement (state.local_origin) et sont retirées du courrier sortant sans condition, quoi que dise STRIP_REQUEST_HEADERS : un canal de contrôle qui survivrait jusque sur le fil serait un canal auquel on pourrait ordonner au saut suivant d’obéir.

On peut croire l’en-tête de résultat parce que l’étape entrante retire tout l’espace de noms ``X-Pepsi-*`` de chaque message qu’elle voit — y compris un message pour lequel elle est désactivée, un message adressé à un domaine qu’elle ne sert pas, et un message qu’elle s’apprête à scinder — avant d’ajouter le sien. Il s’ensuit qu”un message qui n’a pas traversé une étape de déchiffrement ne porte aucun en-tête de résultat digne de confiance, et rien ne devrait en présenter un comme faisant foi.

Pepsi-Origin n’est délibérément pas dans cet espace de noms et n’est jamais retiré : le chemin de corrélation des paiements s’appuie dessus.

La valeur signature de l’en-tête de résultat vaut none, valid, valid-untrusted, invalid ou unverifiable.

Danger

valid-untrusted signifie que la signature s’est vérifiée contre une clé qui n’est ancrée dans aucun chemin de confiance — n’importe qui peut en produire une. Elle ne doit jamais être présentée comme vérifiée dans une interface utilisateur, un volet de tâches ou une règle de client de messagerie.

16.9. Provisionnement automatique d’identités

[pepsi-crypto] AUTO_CREATE_IDENTITY (activé par défaut) permet à Pepsi d’engendrer une clé pour un expéditeur local qui n’en a pas. Le moment dépend de l’option ENABLE_PEP de l’étape de chiffrement :

• ENABLE_PEP = yes (la valeur par défaut, le préréglage à la manière de pEp) : au premier message soumis par l’expéditeur, quoi qu’il ait demandé. Derrière Exchange, cela couvre tous ceux qui envoient par le connecteur, car le courrier que relaie le connecteur est soumis localement quelle que soit la façon dont le connecteur s’authentifie (SASL, MYNETWORKS ou un certificat client) et le préréglage s’applique sur chaque route de soumission – pour chaque expéditeur dont Pepsi reçoit aussi le courrier du domaine.

• ENABLE_PEP = no : la première fois que cet expéditeur demande explicitement une protection – avec le module complémentaire, ou avec un mot-clé de sujet. Cela ne se déclenche pas sur du courrier ordinaire.

Dans les deux cas, une adresse qui a déjà une clé quelconque – y compris la propre clé d’un utilisateur enregistrée depuis son client de messagerie, ou une clé révoquée – ne s’en voit jamais attribuer une autre automatiquement.

C’est ainsi qu’une organisation obtient une couverture de bout en bout sans travail par utilisateur : une clé apparaît, et elle est publiée pour que les correspondants puissent l’employer.

C’est aussi ainsi qu’une organisation publie l’adresse de chaque personne qui envoie du courrier (ou, sans le préréglage, de chaque personne ayant un jour demandé un message signé). Une identité créée automatiquement est marquée published, et une identité publiée est servie depuis le Web Key Directory propre à cet hôte — ce qui est exactement ce qui la rend utilisable, et exactement ce qui rend l’adresse découvrable par quiconque la devine. Elle n’est pas téléversée vers un serveur de clés public, sauf si son propriétaire le demande (vks_wanted) ; [pepsi-keys] VKS_PUBLISH ne décide que de la valeur par défaut pour les clés créées à la main.

Les deux moitiés sont souhaitables pour un déploiement à usage général, et aucune n’est évidemment appropriée pour une organisation dont la liste d’adresses est elle-même sensible, ou tenue par une politique de divulgation des adresses du personnel. Les réglages, du plus au moins automatique :

• tout laisser à sa valeur par défaut – chaque expéditeur obtient une clé à son premier message, découvrable via le WKD de cet hôte, de sorte que le retrait consiste à dépublier une identité plutôt qu’à demander à un serveur de clés d’oublier ;

• définir [stage-encrypt] ENABLE_PEP = no – des clés n’apparaissent que pour les expéditeurs qui ont demandé une protection ;

• désactiver AUTO_CREATE_IDENTITY – le provisionnement de clés devient un acte explicite (d’un opérateur avec pepsi-keys, ou de l’utilisateur via la console web ou l’adresse de contrôle pepsi-keys@), et un utilisateur qui demande le chiffrement sans clé obtient à la place ce que dit ON_NO_KEY.

16.10. Distribution des clés

Un correspondant ne peut chiffrer que vers une clé qu’il possède ; la clé publique de l’expéditeur voyage donc avec son courrier. Comment :

• Autocrypt (par défaut). Chaque message soumis localement porte un en-tête Autocrypt: contenant la clé OpenPGP minimale de l’expéditeur ([stage-encrypt] AUTOCRYPT, par défaut yes). Thunderbird, K-9/FairEmail, Delta Chat et les autres clients compatibles Autocrypt l’apprennent silencieusement. Elle accompagne aussi le courrier en clair, et c’est tout l’intérêt : tant qu’un correspondant n’a pas la clé, il n’a rien avec quoi chiffrer.

• Un fichier de clé joint (facultatif). Avec ATTACH_KEYS_AS_FILES = yes, la clé est aussi jointe sous la forme OpenPGP_0x<long key ID>.asc (application/pgp-keys), la manière OpenPGP classique, pour les correspondants dont le client ne lit pas Autocrypt et importe les clés depuis les pièces jointes. Sur un courrier chiffré, le fichier se trouve à l’intérieur du texte chiffré ; en clair, le message devient multipart/mixed. Il n’est joint que jusqu’à ce que le correspondant ait montré qu’il détient la clé – il a renvoyé un message chiffré vers elle et signé par lui, ce que pepsi-stage-autocrypt-learn consigne sur le chemin entrant – de sorte que les correspondants réguliers cessent de le recevoir, et qu’une nouvelle clé le fait réapparaître. Désactivez aussi AUTOCRYPT si vous ne voulez que le fichier.

• Le Web Key Directory, servi par pepsi-httpd pour chaque identité publiée, pour les clients qui recherchent les clés plutôt que de les apprendre du courrier.

Lorsqu’un utilisateur a enregistré sa propre clé depuis son client de messagerie, cette clé est sa face publique : Pepsi n’ajoute alors ni en-tête Autocrypt: ni fichier de clé (le client annonce la sienne), et le Web Key Directory ne sert que cette clé. Voir Gestion des clés.

16.11. Dépannage

Les messages bouclent entre Pepsi et Exchange.

Le smarthost est pointé vers votre MX public plutôt que vers le point de terminaison du locataire, ou un domaine servi est acheminé vers l’étape direct-vers-MX. Relancez pepsi-setup run, qui est l’endroit où réside la validation de la configuration : les deux y sont refusés, de sorte qu’une configuration qui boucle malgré tout signifie que la configuration en fonctionnement n’est pas celle que vous avez validée. (pepsi-setup check est une commande différente — elle compare le DNS en vigueur aux enregistrements que run publierait, et ne valide aucun pipeline.) Cherchez la boucle dans pepsi-queue — un message au grand nombre de Received: est le signe.

Exchange Online rejette avec 550 5.7.1 … S820.

L’adresse IPv6 émettrice n’a pas de PTR. Publiez-en un, ou réglez ADDRESS_FAMILY = ipv4 sur cette entrée MTA (Choix de la famille d’adresses).

Exchange Online rejette avec 550 5.7.64 TenantAttribution.

Le connecteur entrant ne reconnaît pas l’expéditeur. Vérifiez que le connecteur liste l’adresse depuis laquelle Pepsi envoie réellement — l’adresse IPv4 si ADDRESS_FAMILY la cloue.

Tout ce qu’Exchange relaie reçoit 550 5.7.1 Envelope sender not permitted.

RFC 6409 §6 : le compte SASL du connecteur ne peut envoyer qu’en son propre nom. Donnez-lui une entrée USERNAME_MAP couvrant les domaines servis.

Une remise emploie la mauvaise famille d’adresses.

La précédence est l’entrée […-mta-*], puis la section [stage-*], puis any — et le résultat est intersecté avec ce que l’hôte peut router.

En-têtes X-MS-*.

Exchange ajoute et consomme un certain nombre d’en-têtes X-MS-*. Pepsi ne les lit, ne les réécrit ni ne les retire ; seul l’espace de noms X-Pepsi-* est touché. Sachez toutefois que ré-encoder un message pour un saut suivant dépourvu de 8BITMIME réécrit le corps et invalide donc toute signature portant dessus — voir Extensions du protocole SMTP.

16.12. Ce que Pepsi ne fait pas

La journalisation d’archivage et l’archivage sont hors du périmètre. Les déploiements Exchange ont fréquemment une obligation de rétention, et Pepsi n’y répond pas : il n’y a ni magasin d’archives, ni moteur de rétention, ni recherche, ni dispositif de conservation légale. Voir docs/ROADMAP.md.

Avertissement

[pepsi] MAIL_LOG n’est pas une archive et ne doit pas être présenté comme telle à un auditeur. Il n’enregistre aucun contenu de message, quel que soit le réglage — tout au plus l’enveloppe, l’issue et (à full) la ligne Subject: — et ses lignes sont élaguées après [pepsi-admin] MAIL_LOG_RETENTION_DAYS, trente jours par défaut. C’est un journal d’exploitation assorti d’une limite de rétention, ce qui est l’opposé d’un mécanisme de rétention.

Si vous avez une obligation de rétention, satisfaites-la avec la journalisation d’archivage propre à Exchange ou avec un produit d’archivage dédié, et considérez MAIL_LOG comme ce qui vous dit ce qui s’est passé le mois dernier, pas ce qui a été dit l’an dernier.

La question plus étroite qu’une passerelle cryptographique est réellement censée trancher — ce message était-il chiffré, et qu’en avons-nous décidé — est celle à laquelle MAIL_LOG répond, lorsqu’il est activé. Notez que l’activer signifie que le déploiement conserve la trace de qui correspond avec qui ; pepsi.conf(5) discute de ce compromis.