Totemomail und Kiteworks EPG: Mail-Gateway und Plattformwechsel

Totemomail war eine Produktfamilie der Schweizer totemo AG für zentrale E-Mail-Verschlüsselung. Nach der Übernahme durch Kiteworks wurde der Code laut Hersteller in die Kiteworks-Plattform integriert und als Email Protection Gateway, EPG, weitergeführt. Die Namen bezeichnen deshalb keine zwei völlig unabhängigen Produkte, aber auch nicht dieselbe Betriebsumgebung: Eine bestehende Totemomail-Appliance und ein EPG innerhalb der Kiteworks Hardened Virtual Appliance haben unterschiedliche Plattform-, Datenbank-, Administrations- und Recoverygrenzen (Kiteworks: FAQ for totemomail customers, Kiteworks: EPG capability brief).

Fachlich bleibt die Kernrolle ein Mail-Gateway: Es verarbeitet E-Mails nach zentralen Richtlinien und verwendet S/MIME, OpenPGP oder TLS; für Empfänger ohne passende Schlüssel steht eine WebMail- beziehungsweise Portallösung zur Verfügung. Die Herstellerunterlagen beschreiben automatische Schlüssel- und Zertifikatsverwaltung sowie eine Nutzung mit normalen Mailclients ohne EPG-spezifisches Client-Plug-in als Grundmodell (Kiteworks: Enterprise packaging and EPG features, Microsoft Marketplace: totemomail Encryption Gateway).

Für Messaging-Admins ist die Produktlinie vor allem eine Kette von Vertrauensgrenzen. Das Gateway nimmt eine Nachricht per SMTP an, klassifiziert Richtung und Identitäten, bestimmt eine Policy, sucht Schlüssel oder einen Ausweichkanal, verändert gegebenenfalls den MIME-Inhalt und übergibt die Nachricht an den nächsten Hop. Bei WebMail kommt ein eigener Web-, Konto-, Schlüssel- und Speicherzustand hinzu. Der Satz «die Nachricht ist verschlüsselt» ist ohne benanntes Verfahren, geschützte Strecke, Schlüsselinhaber und Zeitpunkt unvollständig (RFC 5321, RFC 8551, RFC 9580).

Die Erklärung folgt einer Nachricht durch EPG-Regeln, Schlüsselwahl und Verschlüsselungsverfahren bis zur direkten Zustellung oder WebMail. Der Wechsel von Totemomail zu Kiteworks, Betrieb, Diagnose und Recovery werden danach getrennt behandelt.

Totemomail und Kiteworks EPG sitzen als Inline-Gateway im SMTP-Pfad. Eine Nachricht wird angenommen, einer Identität und Policy zugeordnet, mit einem geeigneten Verfahren geschützt und danach per SMTP oder Portal bereitgestellt. Der Plattformwechsel verändert Implementierung und Betrieb, nicht diese Grundaufgabe.

Architekturansatz: Inline-Gateway mit zentraler Policy

Im Gatewaybetrieb sendet das interne Mailsystem ausgehende Nachrichten per SMTP an Totemomail oder EPG. Eingehende Nachrichten erreichen das Gateway direkt über MX oder über ein vorgeschaltetes Mail-Security-System. Das Gateway beendet die SMTP-Sitzung, verarbeitet die Nachricht und öffnet für die Weitergabe eine neue Sitzung. Ein erfolgreiches TCP- oder TLS-Handshake ist noch keine Nachrichtenannahme; die Verantwortungsübergabe erfolgt erst mit der positiven SMTP-Antwort auf das Ende der DATA-Phase (RFC 5321, Abschnitt 4.1.1.4, RFC 3207).

Die öffentliche EPG-Produktbeschreibung unterscheidet mehrere Schutzpfade. «Encryption Gateway» deckt externe Gatewayverschlüsselung und -entschlüsselung ab. «Internal Encryption» schützt Nachrichten auf dem Weg durch und bei der Speicherung in einer Cloud-Mailplattform. Weitere dokumentierte Komponenten sind Directory Proxy, Application Integration Proxy und ein Connector für RMS beziehungsweise Microsoft Information Protection. Welche dieser Rollen lizenziert und tatsächlich aktiviert ist, muss aus der eigenen Konfiguration und dem Vertrag stammen; der Produktname allein belegt sie nicht (Kiteworks: Enterprise packaging and licensing).

Für Microsoft 365 bleibt die Transportintegration ein Connectorproblem. Exchange Online muss Nachrichten gezielt zum Gateway routen und Rückverkehr anhand einer belastbaren Gegenstellenidentität akzeptieren. Ein MX vor einem Drittgateway verändert zudem, welche Quell-IP Exchange Online für Spam- und Spoofingbewertung sieht. Microsoft dokumentiert dafür Connectoren und Enhanced Filtering; beide sind von der EPG-Kryptopolicy getrennt (Microsoft: Configure mail flow using connectors, Microsoft: Enhanced Filtering for Connectors).

Technologiestack und nachweisbare Produktgrenzen

Für die historische Totemomail-Plattform ist der kryptografische Kern öffentlich gut belegt. Die NIST-CMVP-Unterlagen beschreiben das Totemo Cryptographic Module, TCM, als gemeinsame Java-Bibliothek der Totemo Security Platform, TSP. Die Validierung von 2019 nennt Totemo Appliance OS 2.3, JRE 8 und einen Software-Kryptomodul mit AES, RSA, ECDSA, SHA-Familie, HMAC und Zufallszahlengenerator; der Eintrag hat inzwischen historischen Status und ist daher kein Nachweis für eine heute zulässige Beschaffung oder einen konkreten installierten Algorithmusmodus (NIST CMVP Certificate 3500, Totemo TCM Security Policy).

Die NIST-Sicherheitsrichtlinie grenzt TCM ausdrücklich als eine Komponente der TSP ab. Sie dokumentiert keinen vollständigen Totemomail-Mailflow und keine allgemeingültige Queue-, Datenbank- oder MTA-Implementierung. Solche Details dürfen deshalb nicht aus einer fremden Apache-James-Installation oder einem einzelnen Feldbefund auf alle Totemomail- beziehungsweise EPG-Versionen übertragen werden. Für ein Betriebsdokument sind exportierte Produktkonfiguration, Supportmatrix, Paket- beziehungsweise Serviceinventar und Herstellerhandbuch der tatsächlich installierten Generation massgeblich.

Beim EPG verschiebt sich die Grenze auf die Kiteworks Hardened Virtual Appliance. Die Migrations-FAQ beschreibt, dass Betriebssystem, Webserver und Datenbank in der Appliance enthalten sind und Kundenadministratoren keinen direkten Zugriff auf Betriebssystem oder Datenbank erhalten. Updates werden als getestete Appliance-Einheit eingespielt. Das reduziert den kundenseitigen Komponentenbetrieb, macht aber die Appliance-Backup-, Cluster-, Update- und Supportverfahren zur primären Kontrollfläche (Kiteworks: FAQ for totemomail customers).

Die Gegenüberstellung folgt der Hersteller-Migrations-FAQ und den veröffentlichten EPG-Funktionsbeschreibungen. Wo Totemomail-Details installationsabhängig sind, bleibt dies bewusst als Prüfpunkt statt als erfundene Produkteigenschaft stehen (Kiteworks: totemomail-to-EPG migration FAQ, Kiteworks: Top reasons for EPG).

SMTP-Mailflow und Schleifenrisiko

Ein Gatewaypfad braucht für jede Richtung eine eindeutige Zuständigkeit. Ausgehend darf das Mailsystem nicht wahlweise direkt oder über EPG zustellen, wenn nur der Gatewaypfad die vorgeschriebene Policy ausführt. Eingehend muss feststehen, ob MX, vorgelagerte Filter oder EPG den ursprünglichen Absender authentisieren und welcher Hop den internen Mailserver erreicht. Mehrere bidirektionale Connectoren ohne klare Empfänger- und Domänenautorität können Nachrichten zwischen Systemen kreisen lassen (RFC 5321: Trace information and loop detection, Microsoft: Mail flow using a third-party cloud service).

Für jede produktive Route sollten Administratoren folgende Werte gemeinsam dokumentieren:

• Quellnetz beziehungsweise zertifikatbasierte Peeridentität und erwarteter EHLO-Name;
• lokale Annahmeadresse, Port, STARTTLS- und Clientzertifikatsanforderung;
• autoritative, Relay- oder Split-Domain-Verantwortung;
• Policyrichtung, Benutzer- und Empfängerklassifikation;
• nächster Hop, DNS- oder Smarthostauflösung und TLS-Vorgabe;
• Verhalten bei nicht erreichbarer Policy-, Schlüssel-, Verzeichnis- oder Portalkomponente;
• maximale Hopzahl, Queuealter, Retry- und Bouncezuständigkeit.

Die SMTP-Norm verlangt, Received-Zeilen bei jeder Weitergabe zu ergänzen, und beschreibt Schleifenerkennung anhand des Tracepfads. Für Diagnose und Audit muss die Gateway-Event-ID mit Internet Message-ID, Envelope, Zeitfenster und nachgelagertem Trace korrelierbar sein. Ein sichtbarer Betreff ist keine stabile Kennung und kann durch Policy oder Webzustellung verändert werden (RFC 5321, Abschnitt 4.4, RFC 5322: Message-ID).

Nach der SMTP-Annahme entscheidet die Policy Engine anhand von Absender, Empfänger, Verzeichnis und verfügbarer Schlüssel, welcher Schutzweg erlaubt und möglich ist.

Policy Engine und Identitätsentscheidung

Kiteworks beschreibt EPG als automatische, policygesteuerte Entscheidungsschicht. Regeln können sich je nach lizenziertem Funktionsumfang auf Domains, Benutzer, Orte, Inhaltsmerkmale oder Microsoft-Information-Protection-Labels stützen. Automatisierung beseitigt jedoch nicht die Notwendigkeit, die Eingaben zu vertrauen: Ein Absenderheader, ein Betrefftrigger oder ein von ausserhalb gesetztes Label darf nicht ungeprüft dieselbe Wirkung wie eine authentisierte interne Identität haben (Kiteworks: EPG capability brief, Kiteworks: totemo and Kiteworks better together).

Ein belastbares Regelmodell trennt vier Fragen:

1. Richtung: intern nach extern, extern nach intern, intern nach intern oder Applikation nach extern.
2. Identität: SMTP-Envelope, sichtbarer From:, authentisierte Sitzung, Connector, Verzeichnisobjekt und Tenant sind nicht dasselbe.
3. Aktion: signieren, verschlüsseln, umschlüsseln, Portalzustellung, unverändert weitergeben, temporär ablehnen oder dauerhaft bouncen.
4. Fehlerpfad: fehlender Schlüssel, ungültige Kette, nicht erreichbares Verzeichnis, Policyfehler und nicht erreichbarer Next Hop brauchen getrennte Ergebnisse.

Vor Änderungen sollte eine kleine Testmatrix mit exakt einem Sender und Empfänger pro Identitätsklasse ausgeführt werden. Für jede Zeile werden erwartete Regel, Verfahren, sichtbarer Absender, Empfängerkanal, Logmerkmal und Fehlerverhalten festgehalten. Erst wenn diese Ergebnisse reproduzierbar sind, ist die Policy nicht nur konfiguriert, sondern nachgewiesen.

Schutzverfahren und Umschlüsselung

S/MIME verwendet CMS und X.509-Zertifikate. Das Gateway braucht für Signatur oder Entschlüsselung einen privaten Schlüssel und für Empfängerverschlüsselung ein geeignetes öffentliches Zertifikat. Zertifikatspfad, Name beziehungsweise Mailadresse, Key Usage, Gültigkeit und Sperrinformation gehören zur Prüfung (RFC 5652, RFC 5280, RFC 6960).

OpenPGP verwendet ein eigenständiges Schlüssel-, Signatur- und Paketmodell. Fingerprint, User ID, Fähigkeiten, Ablauf und Widerruf müssen unabhängig von X.509 inventarisiert werden. Ein automatisch gelernter öffentlicher Schlüssel ist nur so vertrauenswürdig wie der dokumentierte Lern- und Bestätigungsweg. Die Produktunterlagen nennen S/MIME und OpenPGP nebeneinander, machen sie aber nicht zu austauschbaren Trust-Modellen (Kiteworks: Enterprise EPG feature matrix).

SMTP-TLS schützt eine einzelne Transportverbindung. Bei opportunistischem STARTTLS kann die Zustellung ohne zusätzliche Policy auf Klartext zurückfallen. Eine verbindliche Peeridentität kann je nach Umgebung über Zertifikatsprüfung, DANE oder MTA-STS festgelegt werden; sie schützt die Nachricht trotzdem nicht vor den beteiligten MTAs (RFC 3207, RFC 7672, RFC 8461).

Bei Umschlüsselung entschlüsselt das Gateway ein eingehendes Verfahren und erzeugt für den nächsten Abschnitt ein neues. Das ermöglicht Inhaltsprüfung oder Protokollwechsel, schafft aber einen Klartextmoment innerhalb der Gatewaygrenze. Der EPG-Funktionskatalog beschreibt ausdrücklich Szenarien, in denen intern geschützte Nachrichten am Gateway kurz entschlüsselt werden, um sie zu prüfen oder in den Standard des Empfängers umzuwandeln (Kiteworks: Internal Encryption and Encryption Gateway). DLP, Antivirus, temporäre Dateien, Speicherabbilder, Debuglogs und Administratorzugriff gehören dann zur Kryptogrenze.

Fehlt ein direkt nutzbarer Empfängerschlüssel, verschiebt die Portalzustellung den Klartextzugriff in eine Webanwendung. Dadurch werden Webidentität, Sitzung und gespeicherte Nachricht Teil des Betriebsmodells.

WebMail und Portalzustellung

Die offizielle Migrations-FAQ bestätigt, dass EPG eine Funktion entsprechend Totemomail WebMail für Empfänger ohne geeignete E-Mail-Verschlüsselung bereitstellt. Öffentliche Betreiberanleitungen für Totemomail zeigen den typischen Benutzerfluss: Benachrichtigung, Erstkennwort oder Registrierungslink, Passwortwechsel, Anmeldung am Portal und Auswahl zwischen WebMail, S/MIME oder OpenPGP (Kiteworks: Migration FAQ, Frage 7, L-Bank: Sichere E-Mail-Kommunikation).

Portalzustellung ist ein eigener Speicher- und Identitätspfad. Die Benachrichtigungsmail enthält nicht zwingend die vertrauliche Nachricht; der Inhalt kann auf dem Portal oder in einem passwortgeschützten Envelope liegen. Für Administratoren sind daher mindestens Hostname, TLS-Zertifikat, Kontostatus, Passwort- und Resetverfahren, Aufbewahrungsfrist, Nachrichtenschlüssel, Zustellhistorie und Löschprozess relevant. Die gewählte Variante muss aus der eigenen Policy stammen; externe Betreiberanleitungen belegen mögliche Totemomail-Funktionen, aber keine globalen Defaults.

Ein Portal-Healthcheck darf nicht bei HTTP 200 enden. Der synthetische Test muss Registrierung oder vorhandenen Testaccount, Login, Öffnen einer vorab bekannten Nachricht, Herunterladen eines Anhangs, Antworten und Abmelden umfassen. Nach einem Restore ist besonders zu prüfen, ob ältere Portalinhalte mit ihren historischen Schlüsseln weiterhin lesbar sind.

Verzeichnis und Schlüssel mit Lizenzzählung

Kiteworks dokumentiert LDAP/AD-Integration, Rollen und zentrale Policies auf Plattformebene. Für ein Gateway kann das Verzeichnis Absender und Empfänger klassifizieren, Gruppenbedingungen liefern und Identitäten mit Zertifikaten oder Schlüsseln verbinden. Sobald eine Regel von einer Verzeichnisabfrage abhängt, gehören LDAP-Endpoint, Search Base, Filter, Bindkonto, TLS-Vertrauen, Timeout, Cache und Failover zum Nachrichtenpfad (Kiteworks: security and integration overview, RFC 4511, RFC 4513).

Der Schlüsselbestand ist kein Nebenprodukt des Benutzerimports. Zu inventarisieren sind private Benutzer- und Domänenschlüssel, öffentliche Empfängerschlüssel, CA- und Intermediate-Zertifikate, Vertrauensstatus, Sperrinformationen, Keyserver- beziehungsweise MPKI-Verbindungen und Zuordnung zu historischen Nachrichten. Ein Verzeichnis-Cleanup darf nie ungeprüft einen für alte Nachrichten benötigten privaten Schlüssel entfernen.

Ein veröffentlichtes Kiteworks-Packaging-Dokument definierte EPG-Sitze so, dass ein interner Benutzer beim Senden oder Empfangen einer verschlüsselten beziehungsweise beim Senden einer signierten Nachricht einen Sitz verbraucht; unverschlüsselt und unsigniert durchlaufende interne Benutzer wurden dort anders behandelt. Das Dokument ist eine datierte Vertragsbeschreibung, keine zeitlose Lizenzgarantie (Kiteworks: Enterprise 8.0 licensing and packaging). Für den Betrieb sind deshalb drei Werte getrennt zu führen: technisch bekannte Identitäten, tatsächlich kryptografisch aktive Identitäten und vertraglich lizenzierte Metrik der eigenen Bestellung.

Beim Wechsel zu EPG müssen deshalb nicht nur SMTP-Routen, sondern auch Regeln, Identitäten, Schlüssel, Portalzustände und Nachweise übernommen oder bewusst neu aufgebaut werden.

Migration von Totemomail zu EPG

Kiteworks beschreibt die Migration nicht als In-place-Umbenennung. Ein automatisierter Transfer kopiert Informationen aus der bestehenden Totemomail-Datenbank in die EPG-Datenbank. Die alte externe Datenbank soll nach der Ausserbetriebnahme des Totemomail-Systems dekommissioniert werden, weil sie danach nicht mehr synchron ist. EPG selbst enthält Datenbank, Betriebssystem und Webdienste in der Hardened Virtual Appliance (Kiteworks: Migration FAQ).

Ein vollständiger Migrationsumfang besteht mindestens aus:

• Domains, Routen, Relay- und Connectoridentitäten sowie TLS-Policies;
• aktiven Regeln, Prioritäten, Triggern, Ausnahmen und Fehlerpfaden;
• S/MIME-, OpenPGP-, Domain-, TLS- und CA-Schlüsseln einschliesslich Historie;
• WebMail-Konten, Portalnachrichten, Aufbewahrung, Templates und öffentlichem Namen;
• Verzeichnis-, SSO-, SIEM-, Syslog-, DLP-, Archiv- und Applikationsintegrationen;
• Rollen, Administratoren, Audit- und Supportzugängen;
• Lizenzmetrik, aktivem Benutzerbestand und vertraglichen Grenzen;
• Backup, Restore, HA, DNS, Monitoring und Runbooks.

Der Abnahmetest muss neben Neumails auch historische Daten prüfen. Für jede alte Verschlüsselungsart wird eine vor der Migration erzeugte Nachricht geöffnet beziehungsweise entschlüsselt. Für jede Richtung wird eine neue Testmail mit und ohne vorhandenen Empfängerschlüssel gesendet. Zusätzlich werden negative Fälle wie ungültiges Zertifikat, nicht erreichbarer Next Hop und nicht verfügbares Verzeichnis geprüft. Erst danach kann das alte Gateway aus DNS, Connectoren, Allowlisten und Monitoring entfernt werden.

Hochverfügbarkeit mit Backup und Recovery

Die EPG-Migrations-FAQ nennt integriertes Clustering, Backup/Restore, Disaster Recovery, Hochverfügbarkeit und Distribution als Eigenschaften der Hardened Virtual Appliance. Sie sagt jedoch nicht, dass jede einzelne EPG-Funktion automatisch dasselbe RPO und RTO erhält. Mailqueue, Datenbank, Schlüssel, Portalinhalt, Auditlog, Konfiguration und externer Objekt- oder Dateispeicher müssen je nach Architektur separat zugeordnet werden (Kiteworks: Migration FAQ – Hardened Virtual Appliance).

Bei Legacy-Totemomail ist das Backupverfahren versions- und installationsabhängig. Die EPG-Aussage über integriertes Backup darf nicht rückwirkend auf eine alte externe Datenbank oder eine separate WebMail-Ablage übertragen werden. Der Hersteller-Supportpfad, die installierte Dokumentation und ein isolierter Restoretest sind hier die Primärquellen.

Monitoring und Sicherheitsbetrieb

Kiteworks bestätigt für EPG den Export zu einem oder mehreren Syslogzielen sowie Splunk-Integration. Die Plattformunterlagen beschreiben normalisierte Logs und Metadaten über E-Mail und weitere Kommunikationskanäle. Für Messaging-Admins bleibt die fachliche Korrelation entscheidend: Plattformaudit, SMTP-Ereignis, Policyentscheidung, Schlüsseloperation, Portalzugriff und nachgelagerter Message Trace müssen über Zeit, Identität und Nachrichtenkennung zusammengeführt werden (Kiteworks: Migration FAQ – syslog, Kiteworks: EPG logging and audit).

Ein Admin-Dashboard sollte mindestens Annahmen und Ablehnungen, Queuealter nach Next Hop, Policyfehler, Zahl und Art der Kryptoaktionen, fehlende oder ungültige Schlüssel, Zertifikatsablauf, LDAP-Latenz, Portal-Loginfehler, Platten- und Datenbankzustand, Clusterreplikation, Backupalter und Syslog-Verlust anzeigen. Eine leere Queue ist nur dann ein positiver Befund, wenn gleichzeitig Nachrichten angenommen und erfolgreich an den nächsten Hop übergeben werden.

Syslog über UDP bietet keine garantierte Zustellung. Für schützenswerte Auditdaten sind TLS-Transport, Pufferung, Zielauthentisierung, korrekte Zeit und ein Ausfallalarm zu planen (RFC 5424, RFC 5425). Logs können Absender, Empfänger, Betreff, Zertifikatsinformationen oder Portalaktivitäten enthalten; Datensparsamkeit und Zugriffsschutz gehören daher zur Logging-Policy.

Historische Sicherheitsmeldungen zeigen, dass auch die Weboberfläche Teil der Angriffsfläche ist. NVD-Einträge dokumentieren unter anderem frühere CSRF-, Objektzugriffs- und XSS-Schwachstellen in Totemomail-Webkomponenten. Daraus folgt keine Aussage über einen beliebigen ungeprüften Patchstand, wohl aber die dauerhafte Pflicht, Herstellerhinweise, Exposition, Supportstatus und Webportaltests in das Patchmanagement einzubeziehen (NVD: CVE-2018-6563, NVD: CVE-2020-7918, NVD: CVE-2024-28063).

Die Diagnose verfolgt eine Testnachricht von der Annahme über Policy- und Schlüsselentscheidung bis zum SMTP-Ausgang oder Portalzugriff.

Diagnosewerkzeuge

Die Diagnose beginnt beim veröffentlichten Mailweg und folgt danach den EPG-Ereignissen bis zur Zustellung oder WebMail. Plattformmigration und Lizenzzustand werden erst geprüft, wenn der betroffene Verarbeitungsschritt feststeht.

DNS und öffentliche Mailpfade

Resolve-DnsName -Type MX example.ch
Resolve-DnsName epg.example.ch -Type A,AAAA
Resolve-DnsName _25._tcp.epg.example.ch -Type TLSA

dig +short MX example.ch
dig +short A epg.example.ch
dig +short AAAA epg.example.ch
dig +short TLSA _25._tcp.epg.example.ch

Resolve-DnsName und dig zeigen öffentlichen MX, Gatewayadresse und gegebenenfalls DANE-TLSA. Interne und externe Resolveransicht sind getrennt zu prüfen. Bei Microsoft 365 beschreibt der MX nur den ersten Internet-Hop; Connectoren und Transportregeln bestimmen die weitere Route.

TCP-, SMTP- und TLS-Erreichbarkeit

Test-NetConnection epg.example.ch -Port 25 -InformationLevel Detailed
Test-NetConnection epg.example.ch -Port 443 -InformationLevel Detailed
curl.exe --verbose --ssl-reqd smtp://epg.example.ch:25

nc -vz epg.example.ch 25
nc -vz epg.example.ch 443
openssl s_client -starttls smtp -connect epg.example.ch:25 \
  -servername epg.example.ch -showcerts

Test-NetConnection und nc belegen nur den TCP-Pfad. Windows-curl.exe fordert SMTP-STARTTLS an; openssl s_client zeigt Fähigkeiten, Handshake, SNI und Zertifikatskette. Erst eine vollständige SMTP-Transaktion mit positiver DATA-Antwort belegt Annahme.

Autorisierte SMTP-Testnachricht

curl.exe --verbose --ssl-reqd --url smtp://epg.example.ch:25 `
  --mail-from test-sender@example.ch `
  --mail-rcpt test-recipient@example.net `
  --upload-file .\epg-test.eml

swaks --server epg.example.ch --port 25 --tls \
  --from test-sender@example.ch --to test-recipient@example.net \
  --data epg-test.eml

curl und swaks senden hier eine kontrollierte Testnachricht. Absender, Empfänger und Ziel müssen dafür ausdrücklich autorisiert sein. Zu protokollieren sind SMTP-Endantwort, Gateway-ID, ausgelöste Policy, verwendeter Schlüssel oder Portalpfad, nächster Hop und tatsächliche Ankunft. Ein 250 auf RCPT TO ist noch keine Annahme des Nachrichteninhalts.

WebMail- beziehungsweise Portalpfad

Invoke-WebRequest -Method Head -Uri https://securemail.example.ch/

curl --head --verbose https://securemail.example.ch/
openssl s_client -connect securemail.example.ch:443 \
  -servername securemail.example.ch -showcerts

Invoke-WebRequest, curl und openssl s_client prüfen HTTP- und TLS-Oberfläche. Ein erfolgreicher Statuscode belegt weder Login noch Schlüsselzugriff. Ein synthetischer Browsertest muss Anmeldung, Öffnen einer bekannten Nachricht, Anhang und Antwort abdecken.

Paketpfad an der richtigen Messstelle

pktmon filter remove
pktmon filter add EPG-SMTP -p 25
pktmon start --capture --pkt-size 0 --file-name epg.etl
pktmon stop
pktmon pcapng epg.etl -o epg.pcapng

tcpdump -ni any -s 0 -w epg.pcap 'tcp port 25 or tcp port 443'

pktmon und tcpdump sehen nur Verkehr an der gewählten Messstelle. Ein Adminclient beobachtet nicht automatisch den Pfad zwischen Exchange Online, Load Balancer und EPG. Für die Analyse eignen sich ein autorisierter Host, Port Mirror oder Cloud Flow Logs; SMTP vor STARTTLS und Webmetadaten sind entsprechend geschützt aufzubewahren.

Technische Geschichte

Totemo wurde 2001 in der Schweiz gegründet und entwickelte Lösungen für E-Mail-Verschlüsselung, Managed File Transfer und mobile Kommunikation. Die NIST-Validierungen von 2012 und 2019 dokumentieren die Entwicklung des Java-basierten Totemo Cryptographic Module und der Totemo Security Platform auf eigenen Appliance-Betriebssystemen (Entrust Partner Directory: Totemo, NIST: TCM Security Policy 2012, NIST CMVP Certificate 3500).

Kiteworks übernahm totemo im Januar 2022. Die Herstellerunterlagen beschreiben die Integration des Totemomail-Codes in die Kiteworks-Plattform und die Umbenennung zum Email Protection Gateway. EPG verband die bestehenden E-Mail-Verschlüsselungsfunktionen mit der Hardened Virtual Appliance, gemeinsamen Rollen, normalisierten Logs und weiteren Kiteworks-Kommunikationskanälen (Kiteworks: acquisition and EPG integration, Kiteworks: Migration FAQ, Kiteworks: January 2022 acquisition).

Der Übergang ist technisch relevant: Das alte Produkt konnte mit einer externen Datenbank betrieben werden; EPG übernimmt deren Daten in eine integrierte Datenbank und verlagert Betriebssystem- und Datenbankwartung in die Appliancegrenze. Runbooks, Monitoring und Recovery dürfen deshalb nicht nur Produktbegriffe ersetzen, sondern müssen Kontrollflächen und gespeicherte Daten und Konfigurationen neu zuordnen.