16. Microsoft Exchange als Gateway

Pepsi kann als transparentes Krypto-Gateway vor und hinter einer Microsoft-Exchange- oder Exchange-Online-Installation sitzen: Eingehende Mail wird entschlüsselt und verifiziert, bevor Exchange sie speichert, ausgehende Mail wird signiert und verschlüsselt, nachdem Exchange sie gesendet hat. Benutzer bekommen S/MIME und OpenPGP, ohne ihre Clients anzufassen.

Warnung

Nichts in diesem Kapitel wurde gegen einen echten Exchange- oder Exchange-Online-Mandanten getestet. Pepsis eigene Testsuite verwendet einen einfachen SMTP-Stellvertreter und .invalid-Domains. Die untenstehenden Connector-Einstellungen folgen Microsofts dokumentiertem Verhalten, aber rechnen Sie damit, sie anzupassen, und lesen Sie Fehlersuche, bevor Sie schließen, dass Pepsi schuld ist.

16.1. Topologien

Drei Anordnungen werden unterstützt. Welche zutrifft, entscheidet, was der Rest dieses Kapitels Sie zu konfigurieren bittet.

Beide Richtungen (das vollständige Gateway). Eine Pepsi-Instanz ist der MX der Organisation und der Smarthost, über den Exchange sendet. Das ist die Anordnung, die Ende-zu-Ende-Krypto in beide Richtungen liefert.

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 folgt auf decrypt, weil es den Klartext braucht: Hier werden die Schlüssel von Korrespondenten aus eingehender Mail gelernt (ihr Autocrypt:-Header, angehängte Schlüssel, S/MIME-Zertifikate und das Autocrypt-Gossip: einer verschlüsselt eingetroffenen Nachricht), was der ausgehenden encrypt-Stage Schlüssel zum Verschlüsseln liefert, ohne das Netz zu fragen. Sie zeichnet außerdem den Nachweis auf, dass ein Korrespondent einen unserer Schlüssel besitzt (er hat Mail gesendet, die an ihn verschlüsselt und von ihm signiert ist); dieser Eintrag ist es, der ATTACH_KEYS_AS_FILES davon abhält, unsere Schlüsseldatei an Mail für ihn anzuhängen. Lassen Sie sie weg, gehen beide Hälften verloren.

Nur davor. Pepsi ist der MX und übergibt alles an Exchange; der eigene ausgehende Pfad von Exchange bleibt unangetastet. Eingehende Mail wird entschlüsselt und verifiziert; ausgehende Mail bleibt unberührt. Eine reale Installation für eine Organisation, die ihren ausgehenden Fluss nicht ändern kann.

Nur dahinter. Exchange behält den MX; Pepsi ist nur der Smarthost, über den Exchange weiterleitet. Ausgehende Mail wird signiert und verschlüsselt; eingehende bleibt unberührt. Passt zu einer Organisation, deren eingehender Verkehr bereits über ein Compliance- oder Filter-Gateway läuft.

Die beiden Teilfälle sind nicht zweitklassig: Die Routing-Stage, die Schleifenverhinderung und die ADDRESS_FAMILY-Steuerung verhalten sich in jedem Fall gleich. Unterschiedlich ist nur, welche Hälfte der Pipeline Sie konfigurieren.

16.2. Die Routing-Entscheidung

Ein Gateway vor einem anderen Mailsystem hat bei jeder eingehenden Nachricht eine Routing-Entscheidung: Gehört dieser Empfänger zu dem System hinter mir oder ins Internet?

Sie falsch zu treffen ist kein Zustellfehler. Die Domains hinter dem Gateway sind genau die Domains, deren öffentlicher MX das Gateway ist, sodass eine davon einem Direkt-zum-MX-Relay zu übergeben die Nachricht zurück in Pepsis eigenen Ingress schickt, der sie annimmt, wieder hinausleitet und das wiederholt.

pepsi-stage-route existiert für diese Entscheidung:

[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 fällt auf [pepsi-ingress] ACCEPTED_DOMAINS zurück, sodass die Menge der als „hinter dem Gateway“ behandelten Domains nicht von der Menge abdriften kann, die Ingress annimmt. Fügen Sie ROUTES nur für Ausnahmen hinzu — eine lokal zugestellte Alt-Subdomain, eine Partnerdomain mit eigenem nächstem Hop.

Teilen Sie Pepsi mit, wie es herausfinden kann, ob eine Adresse in Exchange existiert. Dann kann pepsi-ingress eine unbekannte ablehnen, solange der Absender noch verbunden ist, statt sie anzunehmen und Exchange sie später bouncen zu lassen — an einen Umschlagabsender, den Spam fälscht (siehe Ein entfernter Absender). RECIPIENT_CHECK = probe fragt Exchange mit RCPT TO und ohne Nachricht. Das hilft nur dort, wo Exchange selbst unbekannte Empfänger bei RCPT ablehnt: on-premises mit Empfängerfilterung oder Exchange Online mit Directory-Based Edge Blocking. Andernfalls exportieren Sie die gültigen Adressen in eine Datei und verwenden 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

Ohne beides wird wie bisher jede Adresse an den verwalteten Domains angenommen, und pepsi-setup run weist darauf hin.

In einer Installation nur dahinter gibt es keine Routing-Entscheidung zu treffen: Pepsi leitet nur nach außen weiter, und die Routing-Stage wird nicht gebraucht.

16.3. Exchange Online: der Mandanten-Endpunkt

Wichtig

Richten Sie den Smarthost auf den mandantenspezifischen Endpunkt, nie auf den öffentlichen MX Ihrer eigenen Domain.

Der MX-Eintrag Ihrer Domain zeigt auf Pepsi (das ist der Sinn des Gateways). Exchange Online als example-com.mail.protection.outlook.com zu konfigurieren erreicht Microsoft; es als mail.example.com zu konfigurieren erreicht Pepsi, und jede Nachricht läuft in einer Schleife.

Der Mandanten-Endpunkt wird im Microsoft-365-Admin-Center unter den DNS-Einträgen der Domain angezeigt und hat die Form <tenant>.mail.protection.outlook.com — wobei <tenant> normalerweise Ihre Domain mit Punkten durch Bindestriche ersetzt ist (example.com → example-com). Regionale Mandanten können abweichen (etwa <tenant>-ch.mail.protection.outlook.com); verwenden Sie, was das Admin-Center anzeigt, nicht eine konstruierte Vermutung.

[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 ist hier richtig: Exchange Online authentifiziert einen eingehenden Connector über die sendende IP-Adresse oder über das TLS-Zertifikat, nicht über SASL. Pepsi verwendet dennoch STARTTLS, das Exchange Online verlangt.

pepsi-setup lehnt einen Smarthost ab, dessen Host diese Maschine ist und dessen Port einer ist, an den ein Ingress-Listener gebunden ist, sodass die direkteste Form dieses Fehlers abgefangen wird, bevor er eine Schleife bilden kann.

16.4. Auswahl der Adressfamilie

Exchange Online lehnt Mail von einer sendenden IPv6-Adresse ab, deren Reverse-DNS (PTR) fehlt, mit einem 550 5.7.1 ... S820-Fehler. Ein Dual-Stack-Host bevorzugt IPv6, sodass eine Maschine, deren IPv4-Reverse-DNS korrekt ist und deren IPv6-Reverse-DNS nie delegiert wurde, an alle einwandfrei zustellt außer an Exchange Online.

Die Abhilfe ist, dieses eine Ziel über IPv4 zu erreichen. ADDRESS_FAMILY nimmt any (den Standardwert), ipv4 (auch v4/v4only geschrieben) oder ipv6 (v6/v6only).

Die Präzedenz ist: der ``[…-mta-*]``-Eintrag, dann der besitzende ``[stage-*]``-Abschnitt, dann ``any``. Die Ebene je Eintrag ist die, auf die es ankommt: Die ganze Stage auf IPv4 festzunageln zwänge auch jedes andere Ziel auf IPv4, einschließlich eines, das nur AAAA veröffentlicht.

Wenn eine Zustellung eine Familie verwendet, die Sie nicht erwartet hatten, prüfen Sie zuerst den MTA-Eintrag, dann den Stage-Abschnitt, und denken Sie daran, dass die konfigurierte Familie mit dem geschnitten wird, was der lokale Host tatsächlich routen kann — ipv6 auf einem Host ohne globale IPv6-Route festzunageln lässt nichts übrig, wohin man sich verbinden könnte.

Die bessere Abhilfe, wo Sie die Reverse-Zone kontrollieren, ist, den PTR-Eintrag zu veröffentlichen. ADDRESS_FAMILY ist für den Fall, dass Sie es nicht tun.

16.5. Schleifenverhinderung

Ein Gateway auf beiden Seiten eines anderen MTA ist die klassische Schleifentopologie, und Pepsi hat drei unabhängige Verteidigungen. Keine davon ist in dieser Installation optional.

1. Konfigurationsablehnung (``pepsi-setup``). Zwei Prüfungen, beide Fehler statt Warnungen:

• Eine Routing-Stage, von der aus eine bediente Domain pepsi-stage-relay-to-internet erreichen kann. pepsi-setup läuft von jeder Stage aus vorwärts, die ein verwalteter Empfänger erreichen kann, und lehnt ab, wenn ein Direkt-zum-MX-Relay darunter ist. (BOUNCE_STAGE wird nicht verfolgt — ein Bounce ist eine neue Null-Absender-Nachricht über eine bereits fehlgeschlagene Zustellung und erreicht legitimerweise ein Relay.)

• Ein Smarthost, dessen HOST dieser Host ist — sein [pepsi-ingress] HOSTNAME, localhost oder eine Loopback-Adresse — und dessen PORT einer ist, an den ein Ingress-Listener gebunden ist. Beide Hälften sind erforderlich: Ein Standort darf legitimerweise ein unabhängiges Relay auf demselben Host betreiben oder auf Port 25 eine andere Maschine erreichen.

2. Der Hop-Zähler (``MAX_HOP_COUNT``). Beide Relay-Stages zählen Received:-Header-Felder und weigern sich, eine Nachricht mit mehr als MAX_HOP_COUNT (Standardwert 30, RFC 5321 §6.3) weiterzuleiten. Das ist der Rückhalt, nicht die Verteidigung: Wenn er greift, haben dreißig Kopien der Nachricht das Gateway durchquert, und der Bounce, den er erzeugt, ist zurück in die Schleife adressiert.

3. Exchanges eigene Connector-Beschränkung. Beschränken Sie den eingehenden Connector auf Pepsis IP-Adressen (unten), sodass eine von anderswo eintreffende Nachricht nicht als Gateway-Verkehr behandelt wird.

16.6. Konfiguration der Exchange-Connectors

Die genauen Einstellungen hängen davon ab, ob Exchange an Pepsi sendet, von Pepsi empfängt oder beides.

16.6.1. Eingehend zu Exchange (Pepsi → Exchange)

In Exchange Online ist dies ein eingehender Connector (Exchange-Admin-Center → Nachrichtenfluss → Connectors → Von: E-Mail-Server Ihrer Organisation, An: Office 365):

Einstellung	Wert
Connector-Typ	Vom E-Mail-Server Ihrer Organisation zu Office 365
Wie der Absender identifiziert wird	Durch Prüfen, dass die IP-Adresse des sendenden Servers passt — führen Sie jede Adresse auf, von der Pepsi sendet (siehe PUBLIC_IP im eigenen [stage-<name>]-Abschnitt der Relay-Stage; es ist eine Option je Stage, gefunden über PROGRAM, nie über einen nach dem Programm benannten Abschnitt) —, oder vorzugsweise über den Zertifikats-Subject-Namen
Nachrichten ablehnen, wenn nicht über TLS gesendet	Ja

Bei On-Premises-Exchange ist die Entsprechung ein Receive Connector auf der Hub-Transport-/Frontend-Rolle, mit RemoteIPRanges auf Pepsis Adressen gesetzt und PermissionGroups einschließlich AnonymousUsers (mit gewährtem Ms-Exch-SMTP-Accept-Any-Recipient, falls Exchange für Domains annehmen muss, für die es nicht autoritativ ist).

Bemerkung

Wenn der Connector Pepsi über die IP identifiziert und Pepsi für dieses Ziel auf IPv4 festgenagelt ist (Auswahl der Adressfamilie), führen Sie die IPv4-Adresse auf. Nur die IPv6-Adresse eines Hosts aufzuführen, der sie nie verwenden wird, ist ein stillschweigender Authentifizierungsfehler.

16.6.2. Ausgehend von Exchange (Exchange → Pepsi)

In Exchange Online ist dies ein ausgehender Connector (Von: Office 365, An: Partnerorganisation), mit dem Routing auf E-Mail über diese Smarthosts leiten gesetzt, das Pepsis Hostnamen nennt, und Immer Transport Layer Security verwenden an, mit Zertifikatsprüfung gegen Pepsis Namen.

Auf der Pepsi-Seite trifft Exchange auf einem Submission-Listener ein:

[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. Den Connector authentifizieren

Es gibt zwei Wege, Exchange über Pepsi weiterleiten zu lassen, und sie sind nicht gleichwertig.

SASL mit einem eigenen Konto (empfohlen). Exchange authentifiziert sich mit Benutzername und Passwort. Da ein Submission-Listener RFC 6409 §6 durchsetzt — ein Absender darf nur eine Adresse verwenden, zu der die authentifizierte Identität berechtigt ist —, braucht das Konto des Connectors einen USERNAME_MAP-Eintrag, der die bedienten Domains erlaubt, sonst wird jede Nachricht, die Exchange weiterleitet, abgelehnt:

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

Ohne diesen Eintrag darf das Konto nur als es selbst senden, und die erste Nachricht, die Exchange weiterleitet, bekommt ein 550.

Netzwerkvertrauen (``MYNETWORKS``). Einfacher — führen Sie Exchanges Adressen auf und überspringen Sie die Authentifizierung —, aber es trägt das Selbst-Relay-Risiko, um das es in diesem Kapitel geht: Jeder Host, der den Listener von einer vertrauenswürdigen Adresse erreichen kann, kann darüber weiterleiten, und ein Fehler im Bereich macht aus Pepsi ein offenes Relay. Bevorzugen Sie SASL; wenn Sie MYNETWORKS verwenden, führen Sie einzelne Adressen statt Bereiche auf und schließen Sie nie das Loopback ein.

16.7. Das Outlook-Add-in

Pepsis Verschlüsselungs-Stage reagiert auf zwei Header, die eine Nachricht tragen kann: X-Pepsi-Sign und X-Pepsi-Encrypt. Das Add-in ist das, was einem Benutzer erlaubt, sie aus Outlook heraus zu setzen.

Aktivieren Sie die Routen und laden Sie pepsi-httpd neu:

[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

Das Manifest wird dann von https://<gateway>/addin/manifest.xml ausgeliefert, mit der Gateway-URL und einem installationsspezifischen Bezeichner für Sie eingesetzt.

Die Verteilung erfolgt per Sideloading. Gehen Sie im Microsoft-365-Admin-Center zu Einstellungen → Integrierte Apps → Benutzerdefinierte Apps hochladen, wählen Sie Link zur Manifestdatei angeben und geben Sie diese URL an. Es gibt keinen AppSource-Eintrag: Der Inhalt des Manifests hängt von der URL Ihres Gateways ab, es gibt also kein einzelnes zu veröffentlichendes Artefakt, und eine Store-Prüfung zwischen Ihnen und einer Fehlerbehebung ist ein schlechter Tausch für eine Seite JavaScript.

Benutzer ohne das Add-in erzielen dieselbe Wirkung mit einem Betreff-Schlüsselwort — [sign], [encrypt] oder [secure] irgendwo im Subject. Die Verschlüsselungs-Stage reagiert darauf und entfernt es, bevor die Nachricht gesendet wird, sodass der Empfänger es nie sieht. Die Schlüsselwörter sind konfigurierbar (SUBJECT_KEYWORDS_SIGN, SUBJECT_KEYWORDS_ENCRYPT, SUBJECT_KEYWORDS_BOTH).

Bemerkung

Ein Betreff-Schlüsselwort bedeutet erforderlich, nicht versuchen: Eine Nachricht, die ein Benutzer bewusst mit [encrypt] markiert hat, wird nicht im Klartext gesendet, wenn ein Empfänger keinen Schlüssel hat. Was stattdessen geschieht, ist Sache von ON_NO_KEY.

16.8. Der X-Pepsi-*-Header-Vertrag

Drei Felder in einem Namensraum, plus die Regel, die das Ergebnisfeld glaubwürdig macht.

Feld	Bedeutung
X-Pepsi-Sign	Anforderung: diese Nachricht signieren. no/yes/required.
X-Pepsi-Encrypt	Anforderung: diese Nachricht verschlüsseln. no/yes/required.
X-Pepsi-Crypto	Ergebnis: was die eingehende Stage gefunden hat. Durch Semikola getrenntes key=value.

Anforderungen werden nur bei lokal eingelieferter Mail (state.local_origin) beachtet und werden aus ausgehender Mail bedingungslos entfernt, was auch immer STRIP_REQUEST_HEADERS sagt: Ein Steuerkanal, der auf die Leitung überlebte, wäre einer, dem der nächste Hop zu gehorchen angewiesen werden könnte.

Dem Ergebnis-Header kann geglaubt werden, weil die eingehende Stage den gesamten ``X-Pepsi-*``-Namensraum aus jeder Nachricht entfernt, die sie sieht — auch aus einer, für die sie deaktiviert ist, aus einer, die an eine Domain adressiert ist, die sie nicht bedient, und aus einer, die sie gleich aufteilen wird —, bevor sie ihren eigenen hinzufügt. Daraus folgt, dass eine Nachricht, die keine Decrypt-Stage durchlaufen hat, keinen vertrauenswürdigen Ergebnis-Header trägt, und nichts sollte einen als maßgeblich darstellen.

Pepsi-Origin liegt bewusst nicht in diesem Namensraum und wird nie entfernt: Der Zahlungskorrelationspfad schlüsselt darauf.

Der signature-Wert des Ergebnis-Headers ist eines von none, valid, valid-untrusted, invalid oder unverifiable.

Gefahr

valid-untrusted bedeutet, dass die Signatur gegen einen Schlüssel verifiziert wurde, der in keinem Vertrauenspfad verankert ist — jeder kann eine solche erzeugen. Sie darf in einer Benutzeroberfläche, einem Aufgabenbereich oder einer Mail-Client-Regel nie als verifiziert dargestellt werden.

16.9. Automatische Identitätsbereitstellung

[pepsi-crypto] AUTO_CREATE_IDENTITY (standardmäßig an) lässt Pepsi einen Schlüssel für einen lokalen Absender erzeugen, der keinen hat. Wann, bestimmt ENABLE_PEP der Encrypt-Stage:

• ENABLE_PEP = yes (der Standard, die Voreinstellung im pEp-Stil): bei der ersten eingelieferten Nachricht des Absenders, gleich worum sie bittet. Hinter Exchange deckt das jeden ab, der über den Connector sendet, denn Mail, die der Connector weiterleitet, ist lokal eingeliefert, wie auch immer sich der Connector authentifiziert (SASL, MYNETWORKS oder ein Client-Zertifikat), und die Voreinstellung gilt auf jedem Einlieferungsweg – für jeden Absender, für dessen Domain Pepsi auch Mail empfängt.

• ENABLE_PEP = no: beim ersten Mal, dass dieser Absender ausdrücklich um Schutz bittet – mit dem Add-in oder mit einem Betreff-Schlüsselwort. Bei gewöhnlicher Mail greift es nicht.

In beiden Fällen bekommt eine Adresse, die bereits irgendeinen Schlüssel hat – einschließlich eines eigenen, aus dem Mail-Client registrierten Schlüssels eines Benutzers oder eines widerrufenen –, nie automatisch einen weiteren.

So bekommt eine Organisation Ende-zu-Ende-Abdeckung ohne Arbeit je Benutzer: Ein Schlüssel erscheint, und er wird veröffentlicht, damit Korrespondenten ihn nutzen können.

So veröffentlicht eine Organisation aber auch die Adresse jeder Person, die Mail sendet (oder, ohne die Voreinstellung, die je um eine signierte Nachricht gebeten hat). Eine automatisch angelegte Identität wird als published markiert, und eine veröffentlichte Identität wird aus dem eigenen Web Key Directory dieses Hosts ausgeliefert — was sie genau brauchbar macht und was die Adresse genau für jeden auffindbar macht, der sie errät. Sie wird nicht auf einen öffentlichen Keyserver hochgeladen, es sei denn, ihr Besitzer bittet darum (vks_wanted); [pepsi-keys] VKS_PUBLISH entscheidet nur über den Standard für von Hand erzeugte Schlüssel.

Beide Hälften sind für eine Allzweckinstallation erwünscht, und keine ist offensichtlich richtig für eine Organisation, deren Adressliste selbst sensibel ist, oder eine, die an eine Richtlinie zur Offenlegung von Mitarbeiteradressen gebunden ist. Die Stellschrauben, von am meisten zu am wenigsten automatisch:

• alles auf dem Standard belassen – jeder Absender bekommt bei seiner ersten Nachricht einen Schlüssel, auffindbar über das WKD dieses Hosts, sodass ein Rückzug heißt, eine Identität zu entveröffentlichen, statt einen Keyserver zum Vergessen zu bitten;

• [stage-encrypt] ENABLE_PEP = no setzen – Schlüssel erscheinen nur für Absender, die um Schutz gebeten haben;

• AUTO_CREATE_IDENTITY ausschalten – die Schlüsselbereitstellung wird zu einem ausdrücklichen Akt (eines Operators mit pepsi-keys oder des Benutzers über die Web-Konsole oder die Steueradresse pepsi-keys@), und ein Benutzer, der ohne Schlüssel um Verschlüsselung bittet, bekommt stattdessen, was ON_NO_KEY sagt.

16.10. Schlüsselverteilung

Ein Korrespondent kann nur an einen Schlüssel verschlüsseln, den er hat; deshalb reist der öffentliche Schlüssel des Absenders mit seiner Mail. Wie:

• Autocrypt (der Standard). Jede lokal eingelieferte Nachricht trägt einen Autocrypt:-Header mit dem minimalen OpenPGP-Schlüssel des Absenders ([stage-encrypt] AUTOCRYPT, Standard yes). Thunderbird, K-9/FairEmail, Delta Chat und andere Autocrypt-fähige Clients lernen ihn stillschweigend. Er fährt auch auf Klartext-Mail mit, und genau darum geht es: Solange ein Korrespondent den Schlüssel nicht hat, gibt es nichts, womit verschlüsselt werden könnte.

• Eine angehängte Schlüsseldatei (optional). Mit ATTACH_KEYS_AS_FILES = yes wird der Schlüssel zusätzlich als OpenPGP_0x<long key ID>.asc (application/pgp-keys) angehängt, der klassische OpenPGP-Weg, für Korrespondenten, deren Client Autocrypt nicht liest und Schlüssel aus Anhängen importiert. Bei verschlüsselter Mail liegt die Datei im Chiffrat; bei Klartext wird die Nachricht zu multipart/mixed. Sie wird nur so lange angehängt, bis der Korrespondent gezeigt hat, dass er den Schlüssel besitzt – er hat eine an ihn verschlüsselte und von ihm signierte Nachricht zurückgesendet, was pepsi-stage-autocrypt-learn auf dem eingehenden Pfad aufzeichnet –, sodass regelmäßige Korrespondenten sie nicht mehr erhalten und ein neuer Schlüssel sie erneut auslöst. Schalten Sie auch AUTOCRYPT ab, wenn Sie nur die Datei wollen.

• Das Web Key Directory, von pepsi-httpd für jede veröffentlichte Identität ausgeliefert, für Clients, die Schlüssel nachschlagen, statt sie aus Mail zu lernen.

Hat ein Benutzer seinen eigenen Schlüssel aus seinem Mail-Client registriert, ist dieser Schlüssel sein öffentliches Gesicht: Pepsi fügt dann keinen Autocrypt:-Header und keine Schlüsseldatei hinzu (der Client bewirbt seinen eigenen), und das Web Key Directory liefert nur diesen Schlüssel aus. Siehe Schlüsselverwaltung.

16.11. Fehlersuche

Nachrichten laufen zwischen Pepsi und Exchange im Kreis.

Der Smarthost ist auf Ihren öffentlichen MX statt auf den Mandanten-Endpunkt gerichtet, oder eine bediente Domain wird zur Direkt-zum-MX-Stage geroutet. Führen Sie pepsi-setup run erneut aus — dort wohnt die Konfigurationsvalidierung: Beides wird dort abgelehnt, sodass eine Konfiguration, die dennoch im Kreis läuft, bedeutet, dass die laufende Konfiguration nicht die ist, die Sie validiert haben. (pepsi-setup check ist ein anderer Befehl — es vergleicht das aktuelle DNS mit den Einträgen, die run veröffentlichen würde, und validiert keine Pipeline.) Suchen Sie die Schleife in pepsi-queue — eine Nachricht mit hoher Received:-Zahl ist das Anzeichen.

Exchange Online lehnt mit 550 5.7.1 … S820 ab.

Die sendende IPv6-Adresse hat keinen PTR. Veröffentlichen Sie einen, oder setzen Sie ADDRESS_FAMILY = ipv4 auf diesem MTA-Eintrag (Auswahl der Adressfamilie).

Exchange Online lehnt mit 550 5.7.64 TenantAttribution ab.

Der eingehende Connector erkennt den Absender nicht. Prüfen Sie, dass der Connector die Adresse aufführt, von der Pepsi tatsächlich sendet — die IPv4-Adresse, wenn ADDRESS_FAMILY sie festnagelt.

Alles, was Exchange weiterleitet, bekommt 550 5.7.1 Envelope sender not permitted.

RFC 6409 §6: Das SASL-Konto des Connectors darf nur als es selbst senden. Geben Sie ihm einen USERNAME_MAP-Eintrag, der die bedienten Domains abdeckt.

Eine Zustellung verwendet die falsche Adressfamilie.

Die Präzedenz ist der […-mta-*]-Eintrag, dann der [stage-*]-Abschnitt, dann any — und das Ergebnis wird mit dem geschnitten, was der Host routen kann.

X-MS-*-Header.

Exchange fügt eine Reihe von X-MS-*-Headern hinzu und verbraucht sie. Pepsi liest, schreibt und entfernt sie nicht; nur der X-Pepsi-*-Namensraum wird angefasst. Beachten Sie jedoch, dass das Neukodieren einer Nachricht für einen nächsten Hop ohne 8BITMIME den Nachrichtentext umschreibt und damit jede Signatur darüber entwertet — siehe SMTP-Protokollerweiterungen.

16.12. Was Pepsi nicht tut

Journaling und Archivierung liegen außerhalb des Geltungsbereichs. Exchange-Installationen haben häufig eine Aufbewahrungsanforderung, und Pepsi beantwortet sie nicht: Es gibt keinen Archivspeicher, keine Aufbewahrungsmaschinerie, keine Suche und keine Möglichkeit für rechtliche Sicherungspflichten. Siehe docs/ROADMAP.md.

Warnung

[pepsi] MAIL_LOG ist kein Archiv und darf einem Prüfer nicht als solches vorgelegt werden. Es hält bei keiner Einstellung Nachrichteninhalte fest — höchstens den Umschlag, das Ergebnis und (bei full) die Subject:-Zeile — und seine Datensätze werden nach [pepsi-admin] MAIL_LOG_RETENTION_DAYS entfernt, standardmäßig dreißig Tagen. Es ist ein Betriebsjournal mit einer Aufbewahrungs*grenze*, was das Gegenteil eines Aufbewahrungs*mechanismus* ist.

Wenn Sie eine Aufbewahrungspflicht haben, erfüllen Sie sie mit Exchanges eigenem Journaling oder einem dedizierten Archivierungsprodukt und behandeln Sie MAIL_LOG als etwas, das Ihnen sagt, was letzten Monat geschah, nicht was letztes Jahr gesagt wurde.

Die engere Frage, die ein Krypto-Gateway tatsächlich beantworten soll — war diese Nachricht verschlüsselt, und was haben wir darüber entschieden —, ist die, die MAIL_LOG beantwortet, wenn es aktiviert ist. Beachten Sie, dass es einzuschalten bedeutet, dass die Installation festhält, wer mit wem korrespondiert; pepsi.conf(5) erörtert diesen Kompromiss.